| author | author_link | categories | date | layout | title | excerpt |
|---|---|---|---|---|---|---|
George Mantzouranis |
review |
2019-06-06 |
post |
Reviewing Elixir Conf EU 2019 |
ElixirSchool was invited to participate in a conference for the first time! Our own @gemantzu was there, and has a lot to say!
|
去年是我第一次参加这个会议。我想去看看这个社区能给我带来什么，因为 Elixir 是我认真考虑过的第一个作为专业工作的语言。所以，2019 年是我第二次背靠背参加，我想可以对欧洲加入 ElixirConf 的情况做一个直接的比较。
首先，我们想感谢 ElixirConfEU、Erlang Solutions，尤其是 Lawrence Ansell 提供的两天免费门票，让我们有机会写一篇关于会议的评论。顺便说一下，我们从来没有被要求在会议评论中带有偏见，而且我将一如既往地尽量使其客观。
今年的会议在捷克共和国首都布拉格这座宏伟的城市举行。这座城市令人赞叹，是我参观过的城市里面最完整的之一。与华沙相比，它简直是小巫见大巫，由于二战的破坏和后来的重建，华沙的面貌更加现代化。布拉格到处都是古老的大建筑，有大量的奇迹可以让你投入时间。从老城广场，到皇家城堡，你可以享受旧时的体验，也可以享受新的体验，从乐高博物馆到钢铁人物画廊。城市的地铁帮了大忙，因为你可以跳进去，很容易就能在城市里找到路。
和去年一样，会议组织者和与会者大量使用了 Whova 应用。Whova 允许用户在整个会议期间组织或参与对话和活动。人们使用该应用来分享往返机场的出租车，安排晚上到城市散步，素食者的晚餐，失物招领等。
会议在布拉格会议中心举行，该中心位于市中心南部的普拉哈 4 号，地铁站就在外面，非常方便，中心外的风景也很好。
主办方从会议中心订了两个大厅，论坛厅和南厅。
论坛厅是一个巨大的中庭大厅，可以轻松地将我们所有人一坐而尽。它对演讲者和他的笔记都有很大的可视性。它的音响效果也很好。
而南厅则是一个台阶。它要小得多，有三个中等显示器，你可以看到演讲者的笔记。遗憾的是，它里面还安装了一些柱子，而且是平的，这对观看演讲者和他的 PPT 都是一个挑战。
从会议一开始，我就看到了一些去年熟悉的面孔，这让我舒服了许多。我觉得今年的会议人比较多，但要跟主办方确认一下官方统计的参会人数。
我和所有在会场有展位的赞助商都聊了起来，这真的很有趣。Cultivate、solarisBank、coders51、bitcrowd、ScoutAPM、Erlang Solutions 和 Toyota Connected，他们正在用 Elixir 做一些伟大的事情，其中一些也在招聘。他们很友好地给我们提供了一些小礼物，包括一些非常漂亮的 T 恤和一吨的贴纸！请看：Coders51、bitcrowd、ScoutAPM、Erlang Solutions 和 Toyota Connected。来看看吧：
总的来说，一年比一年好，这是一个更好的会议。我敢说，我从每一场讲座中都学到了一些东西，同样，让 Chris 结束会议是一个明智的决定，因为他总是能给出精彩的讲座。讲座的内容确实比去年好，说实话，我也很喜欢第一天结束时的闪电式讲座。
一切都很完美吗？不，我们作为一个社区，在演讲方面还有一些工作要做，这部分我们可以从 Ruby 同事那里学到很多东西。我觉得很多人站在那里觉得他们应该用信息轰炸我们--大量的幻灯片和大量的代码。这是一个教程的工作，或者一个培训课程，而不是一个演讲。
如果你问我，这就妨碍了最好的会议。我们应该怎么做呢？我认为，每一个要站在上面的人，都应该把它钉在几件他们想传递给观众的事情上，并围绕这些事情来做。神奇的数字是什么？大概不到五个关键点应该就够了，而且不要太多，不要让参会者不知所措。记住，在几天的时间里，一个人要看 20 多个演讲。
我们还应该想办法在这几天里多进行合作。会议人员可以专门抽出一两个小时，让与会者加入小团体，一起做一些小型的开源项目，这样也可以互相了解。
和去年一样，演讲的内容非常广泛。你几乎可以找到任何东西。
一如既往，José 在他的演讲中做得非常出色，带领我们走上了 Broadway 的创作之路。
他首先解释了他的语言关于集合的最初目标是什么，使它们成为多态的、可扩展的/开放的、通用的（在内存中和通过资源）和可调整的。可调优是最终目标，他希望逐步让 Elixir 集合从 Eager 到 Lazy，再从 Concurrent 到Distributed。Eager 和 Lazy 从 1.0 开始我们就可以通过 Enum 和 Stream 模块来实现，而 concurrent 则是后来通过 GenStage 和 Flow 来实现的。
之后，他们没有直接去找分布式的解决方案，而是等了一段时间，看看社区的用例会把他们引向何处。分析了这些用例之后，他们想到了 Broadway，这是一个用于并发和多阶段数据摄取和处理的外部库。
有人可以从 Broadway 中期待的是后端压力和并发，在管道末端的自动 ACK，最小化数据损失的容错性（例如，如果你正在做一些疯狂的事情，某个节点宕机了），优雅的关机，批处理和分区开箱即用。目前有几个可用的 Producer （Amazon SQS 和 RabbitMQ），这意味着这方面还有发展空间。
Chris 是我在这个社区最喜欢的演讲者之一。他的演讲总是很有趣，内容精彩，而且经常使用现场演示来让事情变得更有趣。今年，他的 LiveView 演讲在大多数与会者的意料之中，他当然没有让任何人抱怨。
他首先向我们展示了一些社区提出的 LiveView 的 demo，其中有些是游戏! 他继续介绍了这项技术的闪光点，那就是在一个需要一些简单的实时功能的应用中，大部分功能可以通过服务器渲染的 HTML 来处理。然后，他给我们展示了一个应用实例，一个实时恒温器，我们看到了库的实际工作原理。
他向我们展示了这个库是如何在服务器和客户端实现轻量级的，充分利用了 Elixir 的强大功能，同时，每个组件都是受监督的，并且在崩溃时可以恢复。
我们还了解到，该库不会影响 SEO，因为组件的初始加载是作为标准 HTML 处理的。LiveView 的测试也真的很简单，真的不需要用无头浏览器启动等方式进行测试。
Ju Liu 给大家讲了一个非常好的讲座，讲的是如何用矢量、鱼的形象和风景画来画一个简化版的 Escher 的鱼画。他的演讲与 Scenic 关系不大，更多的是关于 Vector 理论和如何使用小的图形资产来组成更复杂的结构。
他首先展示了如何用 Scenic 制作一个简单的屏幕，然后他讨论了向量代数的基础知识，以及如何在屏幕上绘制简单的向量和缩放它们，接着介绍了 Box Model 如何使用向量。
讲座的其余部分都是关于如何利用 Box Model 中的一幅鱼的图片，并不断地建立更多的副本，旋转它，缩放它，并把它放在屏幕上，你可以制作出这幅画的简化版本。
Renan Ranelli 给我们提供了一些非常有见地的信息，告诉我们如何在 Elixir 中重写关键软件，而旧系统仍然是一个移动的目标。Renan 在一家 IP 电话公司 Telnyx 工作，他们的旧 python 系统因为技术债务而发展缓慢。
他开始给我们介绍一些关于 IP 电话的工作原理，以及他们的 Dialplan 服务的功能，他们的 Dialplan 服务是要重写的。那个服务几乎是无状态的，对延迟超级敏感，而且每个服务器的吞吐量比较低。该服务产生了一个 xml 文件，其中包含了交换机操作呼叫所需的所有信息。
案例研究的第一步是获得利益相关者的认同，让他们相信公司需要放慢功能开发来偿还技术债务，他们完成了用商业术语来表述所有利益。下一步是投入资源，这是非常关键的，因为当你在追逐一个移动的目标时，重写是一个巨大的工作量。另一个步骤是持续编写和部署。
Telnyx 所做的是将新的服务沿着旧的服务运行，在它们前面放一个代理，将流量导向它们两个，并将请求，以及它们两个的响应记录到数据库中。这样一来，Telnyx 就可以进行最后一步--验证功能对等--找到响应中的差异性，并进行修复，为这个差异性写一个回归测试，以防止将来出现这种情况，并在 TDD 和重写/清理代码的帮助下，对这些修复进行迭代，他们的 "TDD 式" 循环，看起来真的很接近常规的 TDD。
这个过程的结果是，在切换到新的服务之后，几乎没有发生任何事故，100% 的 Elixir 代码库带来了更好的运行时，可观察性得到了巨大的改善（例如通过 wobserver），新功能的发布速度更快，并行化的成本低得离谱，也更简单，所有这些都使客户更加满意。
好吧，我承认，我是个老古董，是 GameBoy 的第一个真正粉丝，这也是我去听 Tonći Galic 演讲的原因。
他给了我们一些关于如何对专用机架构进行逆向工程和修补的见解。他所追求的是，从他的项目中打开一个（显然是他自己的）rom，并模仿原来的 GameBoy 行为。
他为我们提供了大量的信息，包括如何检查架构和指令集，如何用 Scenic 在屏幕上显示东西，以及 Scenic 与原始 GameBoy 的不同之处（立即模式与保留模式）。
当然，他的项目还远远没有完成，但无论如何，这是一个非常有趣的演示。
我从来没有修饰过 Erlang 的启动过程，但我想看看另一位 Elixir 核心团队成员的演讲。我得到了一场精彩的演讲，尽管我对 Erlang 应用程序在接触你的代码之前的所有步骤几乎一无所知，但 Michał 还是设法让我的兴趣一直保持着。
他谈到了启动过程本身，以及如果有人想为虚拟机做贡献，就会发现一些怪异的东西。随着 Erlang Ecosystem 基金会的发展，越来越多的开发者加入进来，对于更多的高级开发者来说，这可能是一个很好的机会来接触 Michał 在演讲中提到的主题。
Chris 是目前在 Bleacher Report 工作的开发人员，他在第一天的演讲（除了闪电演讲外）结束时，演示了如何在暴风雨来临的时候睡个好觉，也就是如何构建一个强大的系统，能够优雅地处理故障，向其他系统提供反馈，并给运营提供洞察力。
他在演讲开始时说，复杂系统在退化模式下运行，扩展是处理故障的问题。题目中提到的堆栈式设计的齿轮，都是在应用启动前可以做的一部分事情：启动运行时和配置，启动依赖关系，连接外部系统，设置报警并向我们显示反馈，以及与我们不控制的服务进行通信。
关于启动，他讲到我们应该避免通过 Mix 来完成运行时的配置，以及如何通过一个 Config 模块来配置我们的应用，这个模块是由我们的应用来监督和启动的。
关于启动依赖，他展示了我们如何在我们的应用前面有一个负载平衡器，我们的应用可以有一个 UpController，平衡器可以检查应用是否已经完全启动了一切。
然后，关于与外部系统的连接，他演示了我们的数据库连接应该如何始终以断开模式启动，因为 "监督者是关于保证的-- Fred Hebert`，这意味着当我们启动应用程序时，数据库可能因为某些原因不可用或加载，所以我们应该使用一个模块来检查数据库是否可用，然后开始有真正的流量。
关于报警，如果发生了前面的问题，我们无法控制数据库，系统应该通过报警的方式向操作者提供反馈。这可以通过有一个看门狗的过程，不断监控数据库的状态，并根据它来切换报警。
最后，他谈到了我们的系统应该如何通过使用断路器（比如Fuse，erlang的断路器）来处理外部服务的故障。这可以根据每个应用的情况而定，但我们可以一直有一个写通缓存，这意味着你可以把最后一个好的外部服务响应写到一个 ETS 表中，万一下游服务宕机，我们可以提供给最终用户。
他在演讲的最后说，通过事先解决所有这些潜在的问题，我们可以防止未来发生大量的问题，我们的运行时有非常强大的工具，我们应该利用这些工具来构建更强大的系统。
John 在他的演讲中给出了一个真实的例子，说明他们如何在 Change.org 中使用 Flow 来处理大量存储在 SQS 中的消息。他们有一个 Ruby/JS 网站，在这个网站上，人们的行为会产生并在 SQS 中存储消息，然后由 Elixir/Flow 系统进行处理。
他们学到的 3 条经验，是以下几点。
1）让 Flow 来做工作 2）整理你的流程 3）调整你的流程
在第 1 课中，我们了解了 GenStage/Flow，以及他们的惊人功能如何帮助这样一个大型的长期运行系统。并行性变得很容易，通过使用 Flow，你可以保护自己不被 DDoS 攻击，因为现在你不是通过流从一个系统推送到另一个系统，而是尽可能多地拉取消息。
在第 2 课中，John 谈到了应该如何很好地了解自己的系统，这样才能为它提供正确的配置。例如，通过使用 SQS，你每次只能接收 10 条消息的批次，所以你必须围绕这一点进行构建。另一个有用的技巧是使用 token，意思是一个结构，通过整个系统推送下来，每一步都会改变，这使得对消息的处理和模式匹配变得非常容易（这和 Plug 使用 Conn 结构的做法是一样的）。错误应该在整个流程中传递，不在确认中，所以 SQS 会重新发送，你可以再次处理它们。
在第3课中，他谈到了每个系统都是不同的，没有一个神奇的解决方案来微调你的应用程序，在引擎盖下，Flow 如何将一个流分解成3个部分 :GenStages，生产者，生产者_消费者和消费者，以及如何在所有这些不同的部分中玩弄 :max_demand 参数来获得更好的结果。
作为额外的奖励，我们可以看到他们已经在玩 Broadway 了，而且很容易把它换成 Flow，以及他们作为系统的差异。
Arkadiusz Gil 的演讲是关于 Telemetry，一个用于度量和仪器的动态调度库。
他首先谈到了监控，以及监控对提高性能的重要性。我们的目标是在项目生命周期的早期就使用监控（就像我们已经在测试和部署方面做的那样），这样我们就可以把它作为另一种形式的验证。接下来，他向我们展示了我们今天如何使用自定义函数来做指标（比如请求的数量，成功响应的数量，我们向数据库等外部系统推送了多大的负载，如何从 vm 跟踪内存或 cpu 的使用情况等等）。
但随着我们添加的内容越来越多，这种自定义设置就会变得重复。Telemetry 使用从我们系统的各个部分发出的事件，然后通过使用处理程序附加到这些事件上，再将这些事件推送到像 statsd 这样的报告系统。
一个 Telemetry 事件由三部分组成，事件名称、测量值（可测量的属性，如有效载荷）和一些元数据。各种库都开始在其中添加对 Telemetry 发射事件的支持，比如 v3.1 的 Ecto，v1.5 的 Phoenix 和 1.8 的 Plug。Arkadiusz 还向我们展示了 Telemetry.Poller，它每隔几秒钟就会从 BEAM 中选取一些指标，并将其作为遥测事件发射出去，以及 Telemetry.Metrics，它允许我们指定如何随着时间的推移对遥测事件进行汇总。一些指标的例子是 last_value、sum、counter 和 distribution，这让我们对统计有了一些了解。
最后，他演示了如何通过使用 Phoenix 编程书中的 Rumble 应用程序将 Telemetry 插入到项目中。很简单，只要在 mix.exs 中添加依赖关系，做一个自定义模块，定义我们想要哪些指标，在 application.ex 中进行监督，从应用的角度来看，我们就可以了。困难的部分是设置报告器，就像 statsd 一样，但是 Phoenix 中也会包含一个报告器，我们将能够从一个路由中访问它。
正如他们在 CODE BEAM SF 大会上所做的那样，我们得到了关于新的 Erlang Ecosystem Foundation 的介绍。他们再次表示，事情还有点模糊，我们可能会在未来几个月内得到更多的信息，但看看演讲的视频就知道会发生什么了。
这些并不是会议的全部演讲，还有一些，你可以在 Code Sync 的 Youtube 频道中查看。感谢他们组织了一个伟大的会议，如果你在欧洲，你可以在他们的网站上查看他们举办的所有其他会议。