Event Sourcing 主要是用记账式实现业务过程，Audit Trail 支持 属于天生附带技能。

支持，这是一家有技术追求的公司。 并且在帮助员工成长方便非常舍得投入。

Functional Programming? Don’t Even Bother, It’s a Silly Toy

https://medium.com/better-programming/fp-toy-7f52ea0a947e

支持

是有些片面，但很赤裸裸的直接。

你看看身边的 java 程序员，是不是至少八九成都只是个 spring 框架的使用者？有多少会写单元测试，功能测试，关注架构？

别说 TDD (Test Driven Development)，连 DDT (Development Driven Test) 都做不到。

java 开发人员离开了 Spring, 是不是大部分都得直接跪在那里。

这个东西，没有什么可比性。

java 面向就业岗位和简历编程。

我推荐使用 Cucumber，并非单纯从一个技术的优劣性的角度。比它更方便、更高效的工具一大堆 (MiniTest Rspec RobotFramework .....)。单独讨论这一点就如同讨论 PHP 是不是宇宙最好的语言一样意义不大。

如果我们没有真正玩敏捷之前，我们也没有多少使用 Cucumber，更多使用 RSpec.

你 get 到点了。但是需求沟通，写写用户故事就够了吗？仅仅是用户故事，效果还不如传统的软件规格书来的好。

cucumber 并非是最好的测试工具/框架，用它的原因是正好，我们在用 Scrum，用户故事的另一个极其重要衍生物，可以直接用起来，这是我训练的 Scrum 团队能够真正玩好 Scrum 的重要原因。

大部分的 Scrum 团队，都只是在玩 Scrum 过程的团队而已。

cucumber 本身不复杂，网上资料很多，通常的问题是出在你们的系统架构上，要做到端到端的测试，对后端系统是有些小要求的。

可以先看看我简书里面的那几个文章，基本上可以去动手尝试了。能搞定也就可以把钱省下来了，带着团队去撸串。

微信可以找到我 edwardzhq

看清楚，我简书里面的内容。不是单纯的从一个技术问题角度去处理。

如果你没有 Scrum 中的用户故事与验收标准的概念和认识，那么你说的是对的，无需再讨论。

面向想做自动化验收测试的人群。你这么说，否则某种程度上说明你们的 UI 测试人肉居多。或者浪费严重。

https://www.jianshu.com/p/fd17c1bb6806

追求过细的分工，才是一种伤害。

我带的开发人员，分析得了需求，写的了故事，编的了代码，干得了测试 (自动化测试，单元测试)，部署得了生产 (半自动化运维)。

激动啥，这只是个噱头。难道包分配？

能干活对福利好 匹配才是王道。

Elixir 要不要？

Your App, your gem, your framework have to be nice.

Be Nice

Be Nice to Each Other

We Can Be Stronger By Being Nice

Being nice including:

• Moving Forward to Survive

• Keeping Compatibility

• Gradual Changes

• Providing Benefits to Users

Also includes:

• Form the community

• Help each other

• Share your effort

Let's Move Forward To Survive

“Elixir 的发明人 Jose 的入门课程”请问这个课程的连接在哪？

加我微信 edwardzhq

能说说 erlang 的服务发现吗？

此时我想说 Elixir 的 Umbrella Project 恰好是 Monolith 与 Microservice 之间的一个不错的平衡。

+1

要不要过来加入我们叻

台风预警，下午会如期还是取消？

ngrok 花生壳等 优先都试过，不稳定。也看了 frp，没选 frp（go）的原因，是我们在探索 Elixir + Phoenix, 希望能把我们在 Rails 的成功方案转移到 Elixir Phoenix 上面，自己撸一个，一举多得。

我的工作重心与兴趣是 scrum 敏捷过程，TDD CI CD。

需要自己动手的代码也就那么几十简单代码行（十来条语句），谈不上高效。

小众语言，国外情况是另一回事，在国内的情况，Ruby 也依然是归在小众语言行列，市场就业机会多少也远排在 Python 之后。 当初，我们提出 php 转 ruby 时，后端人员立马走掉一半，最直接的理由就是搞 ruby 之后出去工作不好找。

我一直在所在的公司推行 Ruby(Rails)，在享受高生产率，高回报的同时，缺无可避免的需要面对，在市场上招不到更多的 Ruby 人员。

但我依然喜欢用 Ruby，并认为喜欢用 Ruby Python 这类语言的人员，比其他 (如 php。。。。) 人员更有技术追求，更贴近工程师文化。

然而，这并不影响我喜欢 Elixir Phoenix，而从运维成本的角度考虑，我个人认为 Elixir Phoenix 会更优于 RubyOnRails. 其并行处理能力也明显占优势。

大疆不也因为这样那样的原因，在尝试 Elixir Phoenix 吗？能说说为何考虑 Elixir 这个更小众语言的理由吗？

请求处理时间长的，即便通过线程方式，同一时间能接入更多请求，但也只能是接入，并不意味着能并发在处理这些请求，其结果是，请求接入数增加，请求处理的等待时间也在增加，超时数也在增加。

按钮被点击（这个怎么处理？？？）

是测试脚本要发出点击指令，而不是判断按钮被点击了。

简书的排版是不错，我也直接在简书上写分享文章

开始有点语言之争的味道。已准备好板凳瓜子