关于大规模聊天的一些想法

IRC是一个概念上简单的协议,很棒! 不幸的是,我们不得不在其之上构建各种奇怪,复杂的软件:用于名称和频道注册的服务,用于跟踪用户离开状态的服务,日志记录服务,用于改善消息表示的更好的前端等。 因此,到了某个时候,人们开始意识到所有这些复杂的软件都使这个简单的协议成为配置和使用的噩梦,并决定制作自己的捆绑聊天应用程序。 因此,我们有了Slack,HipChat和Discord,它们基本上是IRC重新打包的。 您仍然有频道(在Slack和Discord中,这些频道甚至仍带有井号),您可以单击以查看当前对话。 现在,至少,您不必带上自己的记录器或IRC保镖,就可以通过脱机时错过的消息进行回读,并且它会记住您上次阅读的消息以及所有其他小细节,但是这仍然是用户的核心体验:完全独立的渠道。 如果您像Slack或HipChat的所有产品屏幕截图中一样,具有一些小的渠道,则此方法很好用: 告诉我#general,#random和#watercooler基本相同 但是当您拥有658个在线用户和60-70个频道时,效果就不太好了,就像Reactiflux社区的Discord一样。 那里的渠道清单庞大,艰巨,很难跟上。 关心#testing,#typescript,#redux,#webpack,#tooling,并希望在#need-help和#code-review中提供您的帮助吗? 希望您记得记住所有7个频道,并在方便时通过它们进行浏览。 不仅如此,在高速渠道中,跟上讨论也很痛苦。 随便的人都投下了巨大的代码片段,并获得了指向GitHub页面的大型嵌入式链接,从而破坏了您与其他几个人的对话流程。 错过讨论点很容易,因为聊天在您有机会查看和阅读之前已经滚过它。 这是与聊天进行交互的不良方式。 这并不是一个真正的新问题,而是其他地方已经解决的问题。 Reddit就是一个很好的例子:您有一个由提交开始的单独讨论线程,这些讨论线程按主题分组为subreddit。…

个人组织以及我从飞行员那里学到的东西

首先,我要说的是,我不认为要遵循的是管理您的工作负载的最佳解决方案,这只是对我有用的一种方法。 我发现它强加给自己的方式很有趣,并认为它也可能与其他人相关,因此我在本快速阅读中分享了它。 像许多对寻找最好的清单管理者感兴趣的人一样,我尝试了数十种模拟和数字系统。 我尝试了许多应用程序,其中许多实际上设计得非常好。 但是每次,我都错过了了解,了解自己的内在感觉以及什么是最重要的事情的感觉,因此我错过了确定自己在做正确的事情的宁静。 有一天,当我正在重新设计飞行包(又称飞行员执行其任务所需的所有信息,这些信息都包含在他的论文或他的iPad中)时,我注意到(揭示了)一位飞行员的真知灼见,我的注意力。 长话短说,除其他外,在起飞之前,飞行员需要了解飞机,评估其状况并正式接受飞机。 为此,他将检查日志,飞机的“运行状况日志”,以及在X时刻需要修复的事物清单(其中X始终是未来日期) )。 是的,我知道这听起来有点疯狂,但是我们的汽车也是如此,在不久的将来可能需要修复某些零件,而且您仍然可以安全地驾驶它。 这里是一样的,除了在某些情况下,飞行员将不得不调整某些程序,并且必须避免其他程序。 并且他需要充分意识到这些变化,以防流量控制要求他做可能违背日志建议的事情。 因此,我问他:“您如何确保您正在考虑等待的修复程序和程序调整?”他对此回答: “在公司内部,我们有一个过程,包括取走日志(这是座舱中的一个大文件),阅读最后一页,然后进行上一次维护期间未解决的问题,然后重新复制一个新页面”。 请注意他说“重新复制”的方式 ,我实际上是第一次错过了。 该项目继续进行,几周后,我们将一个数字原型带到了试点中,这使日志变得非现实,并简化了公司,维护人员和试点之间的协作。 听到飞行员说了什么之后,我们创建了飞行员必须完成的特定手势,以验证日志清单上的每个点。…