Rei

Stand with Hong Kong, but which side?

Fri, 11 Oct 2019 00:00:00 +0000

Foreword

This article was first published in reddit hearthstone community, but after a day, the article has been downvote to invisible.

https://www.reddit.com/r/hearthstone/comments/dfwkka/stand_with_hong_kong_but_which_side/

The cause of the incident was that Blizzard banned a player who promoted political slogans during the game.

https://playhearthstone.com/en-us/blog/23179289/

My original intention was to provide different information for reddit, and I hope that the community will not be overly emotional. But soon I was labeled as “brainwashed”, “political propaganda” and so on.

The communication is failure, but it shows a biased group, how to eliminate dissent, repeat their lies and then strengthen their bias.

Hi, Hearthstone players.

I’m very surprised that the Hearthstone community has been very keen on discussing Hong Kong in recent days. But when I see “Stand with Hong Kong”, I’m confused, which side is standing on? It is on the side of the people who are destroying Hong Kong, or on the side of the people who are building Hong Kong.

I know that you have a passionate heart and want to speak justice for this world, but I am worried that you have stood on the wrong side because you don’t understand the actual situation.

Position statement: I’m Chinese living in Shenzhen, a city close to Hong Kong. I watched Hong Kong TV from an early age, so when I travel to Hong Kong, I am not unfamiliar. Hong Kong is more free than the mainland, has a more complete legal system. But due to violent demonstrations, these advances have been destroyed in the past few months. Now I dare not go to Hong Kong because the demonstrators are hunting different dissidents.

To prove my point, let me show some violent demonstrations. I try not to quote bloody scenes because it may make you uncomfortable. But because of the violent nature of the demonstration, I can’t avoid it. This is not a complete event record, I just pick out events that may be selectively ignored by the media.

2019-06-12 Attacking the Legislative Council

Outside the Legislative Council, the police were on the line of defense, and the demonstrators continued to approach and throw debris, iron pipes and even bricks.

Video: https://www.youtube.com/watch?v=FwbtLs8Toqw

In the evening, the demonstrators beat the police and the police were bloody.

Video: https://www.youtube.com/watch?v=2f3kur1DGeA

You may have heard another story: the Hong Kong police unscrupulously beat the demonstrators and released tear gas. I am not saying that all demonstrators are violent, but I saw that the demonstration was accompanied by violence almost from the beginning.

2019-07-01 Destroy the Legislative Council

After several attacks, the demonstrators finally entered the Legislative Council.

Video: https://www.youtube.com/watch?v=JMCHTjsdMr0

After they entered the Legislative Council, they destroy, graffiti and steal some government equipment. The demonstrators withdrew from the Legislative Council at midnight because of fear of being arrested. The next day, the demonstrators condemned the police for not protecting the Legislative Council. In fact, the police guarded the whole day and finally retreated in order to avoid serious conflicts.

2019-07-21 Hong Kong Dark Night

There have been many serious violent clashes this night, and violence has spread from targeting police to targeting other people.

You may have seen reports of people wearing white clothes in Yuen Long beating people wearing black clothes, as far as I know, 28 white clothes have been arrested. But there are other things have happened.

On the same night, in another place, the demonstrators blocked the road, beat a driver who was dissatisfied, and smashed the car：

Video: https://www.youtube.com/watch?v=jHgFbJoz8do

The driver just wants to go home. The demonstrators were angry and felt that the driver did not support his actions, so beat him.

After this day, violence is getting out of control.

2019-10-06

This is the most recent and most violent incident I quoted.

A taxi driver was surrounded by demonstrators and attacked. Taxi was out of control and hit to the demonstrators. The demonstrators beat him to serious injuries.

Video: http://news.tvb.com/local/5d9b7a2de60383eb0f7b1fdb/

The violence has continued and escalated, and Hong Kong citizens live in fear.

There are still many similar incidents. Because this is not to record the entire event, I don’t want to list them here. Let me talk about what I really want to express.

Politics is very complicated

In the past few months, there have been too many things in Hong Kong. You can’t simply judge right or wrong based on intuition. There are too many historical reasons for the problems that are happening in Hong Kong. I cannot explain them here. It may take time to come to a conclusion.

No media is completely neutral. If you want to know the truth, you need to spend a lot of time identifying different sources of information. This is far from being as easy as calling out a free slogan.

If you simply scream “I support the people of Hong Kong to fight”, you may be hurting people who want to live a peaceful life in Hong Kong.

Respect is mutual

In this incident, I found that the Chinese and Western people have great cultural differences. The West often said that the Chinese do not understand freedom of speech, but I must point out that the West does not understand the Chinese people’s desire for peace and unity.

China has experienced many disasters in modern times, finally have a peaceful period to develop the economy and improve people’s livelihood, Most people don’t want to destroy it.

In essence, I don’t think there is much difference between people around the world. We want to be friendly, peace, and freedom. Freedom is one of the common needs of mankind, and I believe that society will become more and more free. However, different countries have different development processes and cannot be rushed, or they will cause turmoil and even war.

When I saw a lot of people in reddit said to support Hong Kong to fight, I am very distressed. I am distressed for the people of Hong Kong because the riots will not end in a short time, Hong Kong people must continue to live in fear. And I also know that there are many Chinese Hearthstone players who feel distressed. Things should not be like this.

I think Blizzard is doing right things. It is not because of its operation that people feel that its position is biased toward China, but that it faithfully follows the rules. If someone promotes a political position that favors China in the game, I also support Blizzard to ban him. The game is not a platform to promote political positions.

We live in different places and meet through games. We need to be more inclusive of each other’s culture. I hope that the Hearthstone community can restore peace. Thank you for reading here. My English is not good, it took an afternoon to write this article.

I stand with Hong Kong, standing on the side of peace.

香港的支付方式

Sat, 11 Aug 2018 00:00:00 +0000

上周我终于达成到香港旅游的目标，在香港期间对不少事情留下深刻印象，例如住宿环境、消费水平、广告牌丛林、迪士尼……只是三天时间比较少，还不足够深入了解香港，好在我住在深圳，计划多去几次把香港逛个遍。这里特别想记录的，是香港的支付方式。

在口岸等待我同行的朋友的时候，朋友发来消息问我：换好港币了没，不少地方需要现金。我一愣，虽然可以预料支付宝微信支付不会是主流，但我还带有 Visa 卡，手机有 Apple Pay，还不足够实现无现金支付吗？

随后的三天行程发现，在香港游玩确实不能脱离现金。我们行程主要的支付场景有：

地铁买票：只看到两个站台有微信支付宝购票机，大部分是现金支付/充值（单程票/八达通）。
便利店（7-11）：支持所有支付方式，支付宝、微信、银行卡、八达通、现金……所以我买饮料都在 7-11 买。
商场/餐厅：支持银行卡、现金。
网红美食店：基本只支持现金。
住宿/门票：国内代购网站事先网上付费。

总的来说，越高档的场合支付方式越多，只逛商场的人可以不用担心没带现金；大陆游客多的商店通常会支持支付宝微信，但也不一定；小店、路边摊基本只支持现金，想要逛遍香港每个角落的人就一定要带现金了。

而我们游览过程也体验到了现金的不便利，经常要开钱包找散钱，收到散钱太多弄得钱包鼓鼓的，收到不少硬币差点要买个硬币包。

我对此感到一些困惑，诚然我已经被支付宝微信惯坏了，在深圳生活近两年没有使用现金，以致我对香港的期望更高，因为香港是个国际化、自由竞争的大都市，我希望看到比支付宝微信更好的方案——其实我也不是很喜欢生活方方面面被支付宝微信统治。但实际上香港的支付方式大概停留在内地一线城市5年前的状态，移动支付还在萌芽阶段。

我在网上搜索到了这篇文章《为什么香港人爱用现金？》，里面主要说了两点：

本地商家和消费者太习惯现金，不信任移动支付。
本地支付方式太多，没有哪家可以一家独大。

这两点在内地早前也是一样的，通过支付宝微信的推广最终改变了人们的观念，我觉得香港迟早也会拥抱移动支付。

而在这篇文章《你问我答：说香港的“无现金”发展落后？是误会》中提到了另一种观点：

至于会否被政府监控的问题，李兆波指出，国际公司的数据收集做法，相对较透明，用户可清楚了解，但对中国大陆的公司，很多港人都会有质疑，觉得“阿爷一定知”（中央一定会知道）。

“数据是否会向政府开放？这是很多人担心的。”李兆波说：“虽然内地也有私隐保障的法例，但最终，还是对内地的法制有没有信心的问题。”

无需多言，我完全理解这种担忧，这也是为什么我期望到香港能看到更好的方案。但现实来看，香港并没有更好的答案，还在问题边缘小心试探。那么我认为，如果没有更好的方案，香港迟早会接受支付宝微信的移动支付，因为支付宝微信相比香港现有的支付方式有明显的优势：

不用带钱包：没体验过的时候可能会觉得身上带个钱包没什么问题，但一旦体验过就会觉得多带一张卡都是麻烦。
点对点支付：聚会 AA 制不用掏钱找钱，也不用问银行账号。
收款门槛极低：路边小贩只要打印一个二维码即可收款，不需要购买特殊硬件，个人手机就可以立即查看流水。

曾经我对支付宝微信非常抗拒，我生活在大陆，对于这两家公司的认识比香港人更有发言权，但最终还是败在了“便利”上面。懒就是社会发展的一大动力，现金最终也会跟音乐、电影、书籍一样电子化的。这个过程会挣扎，但不会倒退。

考虑到隐私问题，在支付宝微信以外的方案其实不多，我觉得就只有 Apple Pay 和 Android Pay，因为他们有较高的装机率，但现时这两个 Pay 还要解决三个问题才能跟支付宝微信抗衡：

支付场景急需扩充，目前基本是银行卡的子集。
提供点对点支付。其实已经在推进，进程需要加快。(Apple Pay，Android Pay)
给路边小贩提供极低门槛的收款成本。路边小贩不会接入收款设备，成本不能超过一张打印纸。如果普及不到小贩的层面，那么是无法跟支付宝微信抗衡的。支付宝微信可以同时向高低端扩展，基于收款设备的只能向高端扩展。

说到这里，庆幸我住在深圳，可以方便观察到两个城市、两种体制的发展，希望香港能找到属于自己的移动支付之路。香港明天会更好。

容器也许是未来，但不是当下

Sun, 08 Jul 2018 00:00:00 +0000

自从 Docker 发布以来，我已经看到很多次“容器是未来”。随着了解越来越深入，我的态度也从怀疑转到肯定。容器确实有很多优点，包括但不限于：

容器可以让运行环境用文件的形式固化，并提交到代码库。
容器可以确保开发环境和生产环境一致，而不是到部署的时候重新搭建一套类似的环境。
容器可以秒级扩展，而虚拟机创建通常需要几分钟。

有这个几个优势，即使不考虑追踪、日志、服务治理等平台化的功能，我也相信容器会是未来。不过，尽管我已经在开发环境使用 Docker 两年多了，却一直没有把部署环境切换到 Docker，原因是部署平台不完善。

可能有人会提起 kubernetes。kubernetes 已经在编排领域胜出，各大云服务商都已经推出或者预览托管 kubernetes 集群功能。看来 kubernetes 已经为生产环境准备好了？

最近我尝试将一个小应用部署到 Google kubernetes Engine 上，但过程只能用痛苦来形容。概括来说需要做这些事情：

创建 kubernetes 集群，选择需要的虚拟机配置和数量。
学习 CloudSQL 的 Proxy 验证。（Google Cloud 特有）
编写 Deployment，Service 和 Ingress 配置。（需要学习一大堆 kubernetes 知识）
将 Docker image push 到合适的仓库。
执行 kubectl apply。

这个小项目的配置开源在 https://github.com/getcampo/campo-gcloud ，但不指望没有 kubernetes 基础的人能看懂。还有一些想做但还没做的事情：

自动领取 SSL 证书（Let’s Encrypt）。
CI/CD 集成。

但我已经放弃再继续摆弄下去，因为发现：1）kubernetes 完全没有减少部署的工作量，说不定更多了。2）太多配置和操作是由人来完成，出错几率加大。我对 kubernetes 的了解还不够深，不确定遇到问题的时候是否能快速解决。曾经就因为一个配置写了布尔值而 kubernetes 只认字符串而报错，让我调试了一小时。

kubernetes 是不是太难了？每个技术人员都不会轻易开口说这句话，因为这会显得自己不够聪明。不过有篇文章说明这不是我一个人这么想：Will Kubernetes Collapse Under the Weight of Its Complexity?。

However, I felt there was an underlying problem with the whole spectacle: everyone I talked to was either an operator or an SRE. Where were all the application developers? Aren’t those the people that all this complex infrastructure is supposed to serve? Is this community really connected with the needs of its users? And it made me wonder: is Kubernetes too complex? Will it end up collapsing under the weight of its own complexity? Will it fade away as OpenStack has seemed to since 2014?

看了这个 Cloud Native 大会的景观图，我倒觉得前端的混乱状况有点可爱了。到底需要学习多少工具，添加多少抽象层才能把容器用起来？

不过让人欣慰的是，至少有一个厂商作出了开发者需要的产品：Heroku。

Heroku 是 2007 年推出的云平台服务，可能很多人对 Heroku 的印象还停留在它的 buildpack 机制上：通过 Git 把代码 push 到 heroku repo，heroku 执行 buildpack 把应用构建部署到它的平台上。在 Docker 兴起后，一度有人认为 Heroku 要完了，因为围绕 Docker 完全有可能搭建一套开源的 Heroku 平台。相比之下，buildpack 只是 Heroku 自家的技术，人们不想被绑定在一个平台上。

如果近几年你没有使用 Heroku，那么你可能需要更新认识，因为 Heroku 已经完全拥抱 Docker。在 2015 年，Heroku 已经实现 Docker Deploy，而不需要 buildpack。到了 2017 年底，Heroku 又推出了 heroku.yml build manifest。

heroku.yml 是啥？看例子最直观：

build:
  docker:
    web: Dockerfile.web
    worker: Dockerfile.worker
release:
  image: web
  command:
    - bin/rails db:migrate

这几行配置已经实现了前面说的一大坨 kubernetes 的配置。heroku.yml 配置很简洁，没什么学习成本。开发人员不用学习 Deployment、Service、Ingress 还有其它一大堆概念，只要告诉 Heroku 需要什么进程，该进程的镜像通过什么 Dockerfile 构建，Heroku 就自动把工作做好。另外只要绑定 GitHub，就可以很容易地把 CI/CD 跑起来。Heroku 背后完成了很多工作，留给开发人员简洁的界面，这才是平台需要做的事情。

当然，Heroku 也不完美：

平台绑定的问题。（其实哪个云平台没有？）
只对企业客户开放美欧以外的区域，没有中国。

所以，目前我也只能把业余项目放到 Heroku 上，并且羡慕用 Heroku 就能满足需求的地区……

在容器混战时代，Heroku 像一股清流，在所有人找不清方向的时候给出了接近完美的答案。希望更多云平台商能向 Heroku 学习，让开发者不再受部署所困，放更多精力放在开发上。容器也许是未来，希望这个未来能早点到来。

Stimulus 框架简介

Sat, 24 Feb 2018 00:00:00 +0000

2018 年年初，Basecamp（开源 Ruby on Rails 的公司）开源了 Stimulus 前端框架，为前端大战再添一员。

Stimulus 是一个轻量级前端框架，其用法用一张图就可以概括：

这个框架通过 data-contoller data-target data-action 等属性，把 HTML 元素和 JavaScript 行为绑定。图例使用的是 ES6 的语法，这并不是必须的。

由于官方教程也只有六页，所以关于用法不做展开。

Stimulus 解决的问题

和热门的 JavaScript 框架（例如 React、Vue）相比，Stimulus 本身不处理 HTML 渲染，而是为已渲染的 HTML 添加行为——大部分情况下，就是跟服务端渲染配合。

Stimulus 是从 Basecamp 中抽取出来的，这意味着它被测试过和 Ruby on Rails 的其它前端组件相处融洽，这包括 Assets Pipeline、Turbolinks、SJR。同时，它补全了 Rails 前端方案缺失的一环，也就是 Turbolinks 环境下如何组织 JavaScript。

如果你不知道 Turbolinks，它是一个可以加速页面加载的前端库。但同时它让应用的前端变成类似单页应用，换页不会触发 DOMContentLoaded 事件，需要重新考虑 JavaScript 的组织方式。

举个例子，假设我们要为一个按钮绑定点击事件，在引入 jQuery 的时候可以这么写：

<button id="btn"></button>
<script>
  $('#btn').on('click', function() {} );
</script>

通常 JavaScript 会打包到单独的文件里，在 <head> 引入，执行的时候不能确保 HTML 已经解析完成，所以会使用 jQuery 的 ready 方法确保逻辑在 HTML 载入完成后执行：

<script>
  $(document).ready(function() {
    $('#btn').on('click', function() {} );
  });
</script>
<button id="btn"></button>

但是，在 Turbolinks 环境下，以上代码不能正常工作，因为 Turbolinks 换页不触发 DOMContentLoaded 事件。一个解决方法是使用 Turbolinks 事件：

<script>
  $(document).on('turbolinks:load', function() {
    $('#btn').on('click', function() {} );
  });
</script>
<button id="btn"></button>

或者换个思路，绑定事件到 document 元素上：

<script>
  $(document).on('click', '#btn', function() {} );
</script>
<button id="btn"></button>

把这个模式推广到更普遍的场景：

<script>
  $(document).on('click', '[data-behavior~="btn"]', function() {} );
</script>
<button data-behavior="btn"></button>

上面这段代码看起来已经很像 Stimulus 了，实际上 Stimulus 就是脱胎自 data-* 事件绑定模式。没有 Stimulus，你也可以用这种方式整理 Turbolinks 环境下的前端代码；有了 Stimulus，Rails 就有了一套前端代码规范，而不用每个团队自己制定。

另外，绑定 document 事件有个潜在问题，随着组件逻辑增加，每次事件都要经过 document 的事件托管，这是不必要的消耗。

Stimulus 使用了 MutationObserver，这是一个新的 DOM API，作用是监视 DOM 上的元素插入和删除，并提供钩子方法，这样就可以实现页面插入一个元素的时候绑定，删除一个元素的时候解绑。

所以，用 Stimulus 实现的组件 HTML，既可以是服务端渲染，也可以是前端动态插入，跟 Turbolinks 和 SJR 完美结合。

我需要 Stimulus 吗？

评估 Stimulus 不能脱离 Rails 的整套前端方案：

Turbolinks + Stimulus + SJR + WebPacker(Vue, React...)

可以看到，Stimulus 只是解决一部分问题，即非内容渲染（服务端渲染）、非 AJAX 请求（SJR）、非复杂交互（Vue, React）的前端逻辑。Rails 提供了一系列组件，让我们根据不同情况挑选不同的工具。

如果你已经在使用 Turbolinks + SJR，那么可以马上使用 Stimulus，它会让前端代码更规范。

如果前端需求非常复杂，需要处理大量客户端状态，那么应该求助于前端渲染框架（Vue，React）。

如果你的团队已经使用前后端分离的方式开发、不需要 SEO、没有对前后端分裂感到痛苦，那么就不需要 Stimulus。

你的前端需求也许没那么复杂

什么样的前端需求是复杂？处于不同阶段的人会得到不同的答案。对于刚接触 HTML/CSS/JavaScript 的人来说，做一个点击弹出窗口就是复杂；而对于写过可视化编辑器的人来说，做一个网页游戏才是复杂。

在我看来，现在大部分前端的复杂，来自工具产生的附属性复杂，而非需求的本质性复杂。人们在选择工具的时候，很容易陷入一个误区：如果选择能处理最复杂情况的工具，那么面对简单情况也能同样处理。这种想法忽视了如果选择了复杂的工具处理所有事情，那么再简单的事情也会变得很复杂。

Rails 的前端方案是一个提供各种选择的方案，解决问题的方法并不只有一个。我们可以先用一个工具，不合适再换另一个工具。关键在于认识到没有银弹，简单的问题用简单的方法解决。

如果你厌倦了臃肿的前端应用，痛恨它浪费掉的大量时间，那么是时候走一下 Rails 的道路。

前后端分裂

Sun, 07 Jan 2018 00:00:00 +0000

让我先讲一个真实故事。

有一天，我接到一个业务需求，给某个表单的下拉框增加一个选项。比较特别的是，这是一个前后端分离的项目，分离得非常彻底——维护前端的人甚至不跟我在同一个项目组，前端页面独立开发独立部署，我能够修改的只有 API，并且前端页面不会把内容直接提交到后端，而是经过一层 node.js 中转……

我试图搞明白这个表单怎么工作，发现当初设计这个表单的人非常“聪明”，已经预料到下拉框内容要改动的情况了，所以这个下拉框内容是动态的，根据后端另一个 API 的输出来渲染。那么看起来我只要修改这个 API 的输出，前端就能自动更新下拉框内容。于是我找到前端同事确认是不是能这么改，得到答复是：

“不行，前端这边加了缓存，你如果更改了 API 输出，需要通知我刷新缓存。”

好吧，为了性能考虑，加缓存是非常正确的选择。那么接下来我想先在测试环境修改联调一下，不要影响生产环境。这时候我才发现，测试环境是坏的！于是我又开始修测试环境。联调过程有点像乒乓球，我改一点东西，让前端刷新，然后发个请求测一下，如果有问题，再重复这个流程。

猜猜我完成这个需求花了多少时间？前前后后一共花了……3 天！这里面还有一个原因是前端同事并不是 100% 投入这个项目，有很多时间我都在等待他空出时间处理，而等待时间我也可以处理别的问题。但是，WTF 我居然改一个下拉框用了三天时间，这正常么？

从这故事可以得到的教训有：

不要把核心业务功能交给项目外的人负责。
不正确的分离会大大降低开发效率。

这篇博客主要想讲第二点。

分离狂热

现在对前后端分离的追捧已经到了狂热的程度。虽然“现代前端”拥护者会告诉你，什么样的场景用什么样的工具，前端框架是为复杂场景考虑的，并且给你展示一个复杂的、很适合用前端框架的场景。但是当你要编写一个简单应用的时候，这些拥护者这又会告诉你最好选用 Blabla 框架，因为这是市场“主流”，开发者众多，而你的应用总有一天会变得复杂的。

如果只是一昧鼓吹什么是主流和现代还不至于有很多人上当，真正戳中技术管理者痛点的地方是分工。当我们要处理一个很庞大的问题，以至于一个人、一个团队不能掌控的时候，自然会想到将系统拆解为几个模块进行分工。但问题是，前后端分离分错了方向。

人们很容易认为前后端是个不同的领域，因为一个在浏览器执行，一个在服务器执行，它们不是两个东西吗？

这是不对的，前端和后端都属于 Web 应用的一部分，不能脱离对方存在，前端代码需要通过后端发送。对于大多数内容型网站，如官网、电商、视频等等，为了 SEO，需要后端渲染。为了性能，需要后端缓存。为了安全，需要通盘考虑浏览器的安全机制，包括 CSRF、CROS、CSP 等。前后端分离的项目，都会由前端维护一个 node.js 中间层，就是证明了这一点。如果拍脑袋前后端分离，不协调就会出现在开发、测试、部署，功能开发的整个生命周期。

如果认为前后端分离可以增加并行投入的人力，从而加快开发进度，很遗憾，根据我的观察并不能达到这个目的。我曾经目睹一个功能用前后端分离的方案，轻易估算出了 150 人天的工作量，并且这又是合理的。前后端分离的项目一开始就要基于远程调用进行设计，而这是一般软件设计中极力避免的。开发过程中有很多逻辑是重复开发，前端实现一次，后端也实现一次，然后还要考虑远程调用的错误处理。最后，测试联调的时候也会出现大量问题。这个项目如果用传统集成式的方式开发，根据我的经验应该在 50 人天左右的工作量。

最后，还有一种观点是认为开发者是可以轻易替代的，并且职责分得越细，越容易替代。所以前后端分离描绘出一种梦幻情景：前端和后端只处理一部分，任何成员离开都可以轻易补上。事实上，分离后的项目变得更难理解了，前端不知道后端的处理，后端不知道前端的实现。调用关系越简单，层级越少，才会越容易理解。

正确的分割方法是按功能划分，一个人员负责某个功能的整个流程，前至用户如何填写表单，后至数据如何写入数据库和执行后台任务。如果单个项目过于巨大，就把一些业务独立的功能提取成项目。（很容易想到 Microservice，但这又做过头了，具体看 Martin Fowler 的 MonolithFirst，不在这里展开）

前端怪圈

“现代”前端已经成功把自己逼迫到非常窘迫的地步：前端框架层出不穷，曾经大热的 Angular 已经边缘化；为了处理请求不得不引入 Node.js Server，但是很谨慎将自己称为全栈，而是叫做“中间层”，因为前不久才用“全栈就是坏”的口号带歪了不少全栈程序员；为了 SEO 不得不引入服务端渲染，但又不能走传统模版渲染的老路，发展出来同构——把前端框架放到后端渲染，开发难度指数上升。

我已经听到有前端开发说不想碰 Node.js Server 了，他们想专注于处理交互（这也是前端职位的本意）。后端开发一开始很乐意把工作分出去，觉得工作量少了，实际开发才发现一点没少，以前一个变量传递就能完成的事情，现在要写一个 API。需求没完成，没有人会是轻松的。

现在这个境地，与其说是前后端分离，不如说是前后端分裂。大家都觉得不对，但是沟壑已经很深。一旦分开，融合就不是容易的事。

那怎么办……

出路其实每个人都看见过，但有的人选择视而不见，因为这会让人怀疑这几年是不是浪费掉了。

回想一下前后端分离被炒热之前的那个时代，我们是这样做 Web 应用：以服务端渲染为基础，加上少量 JavaScript 交互，对于特别复杂的组件使用前端框架，这就已经满足绝大部分 Web 应用的需求。

这个方案的问题是，不像前后端分离那样有浏览器/服务器这么明显的界限，没有一个简单标准判断哪一部分应该占多少比例，这取决于场景。另一个问题是，优秀的全栈工程师是稀缺品，培养起来需要时间。这就让人犯难了，一不小心就会掉入分离的陷阱。但是，能正确划分系统的人更是稀缺品……

现在是全栈开发备受质疑的日子，分离方案占据了制高点。但是技术潮流就像钟摆，说不定过两年又会摆回来。不要一直追着热点，而是要看清自己的需求。

软件开发没有银弹。

会议视频录制指南

Sun, 12 Nov 2017 00:00:00 +0000

我们已经看过不少技术会议录像，像 RubyConf China 2017 的录像：

这样一边演示一边人物的录像是怎么实现的呢？以下分享我的经验。

需求

会议录像跟一般录像相比，有以下特点：

需要同步录制人物视频和演示文稿视频。
演讲者电脑是自备的，可能需要代码演示。
拍摄对象位置比较固定。

方案

针对会议录像的特点，我摸索出以下录像方案：

除了演讲者自备的电脑和场地提供的投影外，录制方需要准备的硬件有：

录制电脑 x 1，由于要实时处理视频编码，所以性能需要较好，并且提供的接口会影响采集卡的选择。
HDMI 分配器 x 1，用于将演讲者电脑的视频输出一分为二，一边输出到投影，一边输出到录制电脑。
视频采集卡 x 2，用于将视频信号转换为电脑能识别的编码。
摄像机机 x 1，用于拍摄演讲者。
三脚架 x 1，需要是摄像三脚架。
足够长的 HDMI 线等等。

应对不同规模的会议需要的硬件级别也许不一样，不过软件的选择相对单一。下面先讲软件的使用，然后推荐适合不同规模的会议的硬件。

软件设置

目前我只用过一款录像软件：OBS（Open Broadcaster Software），这是一款开源的录像/直播软件，支持 Windows、Mac 和 Linux 三个平台。

安装好后，打开 OBS 可以看到这个界面：

目前需要了解的功能有：

中间黑色部分是预览区域，可以看到合成后的视频预览。
场景：不同的来源变换、移动后的布局称为场景，录制过程可以切换场景。
来源：视频源、音频源、图片以及其它想要合成到视频的素材都称为来源。
混音器：用于设置需要采集的音源，并可以设置噪声过滤器。
开始推流/开始录制：推流直播和录制视频的开关，这里只关注录制。
设置：视频分辨率、编码器、码率等详细设置。

添加来源

如何添加来源取决于连接了什么设备，不过在不连接任何外设的情况下，也有两个视频源可以用来练手，那就是电脑本身的屏幕和摄像头。

添加录屏

点击“来源”左下角的“+”号，在菜单中选择“显示捕获”。
接下来两个对话框中选择“确定”。
这时候屏幕显示被捕获到预览窗口中，也许显示有些乱，先把捕获视频缩小，在预览窗口中右键->变换->比例适应屏幕。
进一步缩小捕获窗口，移动到合适的位置。

操作完成后，软件界面如下：

添加摄像头

点击“来源”左下角的“+”号，在菜单中选择“视频捕捉设备”。
第一个对话框点击“确定”，第二个对话框选择当前电脑的摄像头，然后确定。
调整窗口大小，移动到合适的位置。

操作完成后，软件界面如下：

添加背景

点击“来源”左下角的“+”号，在菜单中选择“图像”。
第一个对话框点击“确定”，第二个对话框选择需要显示的图像，然后确定。
调整窗口大小，让其适应屏幕。
在“来源”列表中，将图像拖放到最后，以免遮挡别的视频源。

操作完成后，软件界面如下：

添加麦克风

点击“来源”左下角的“+”号，在菜单中选择“音频输入捕获”。
第一个对话框点击“确定”，第二个对话框选择电脑内置麦克风，然后确定。

操作完成后，软件界面如下：

开始录制

点击开始录制后，OBS 将会录制当前场景的视频和音频，视频文件将会存到 OBS 的默认目录内，可以在“设置->输出->录像->录像路径”改变位置。

其它

其它视频分辨率、视频格式等设置，都可以在“设置”中找到。我们还可以裁剪视频、给声音添加噪声过滤等操作，这里不再展开。

硬件选择

上面已经讲述了如何通过 OBS 录制视频，但在会议录制中我们不能单靠电脑录屏和摄像头，还需要外置设备。下面我介绍我用过的设备。

采集卡

Blackmagic UltraStudio Mini Recorder

参考价：

¥1230

优点：

专业领域的大牌。
价格适中。

缺点：

分辨率最高只支持 720p/60fps 或 1080p/30fps，需要调整演讲者电脑的输出分辨率，操作很繁琐。
雷电接口只适用于 2015 年款 Macbook Pro。

评价：

我的第一代设备，因为分辨率设置繁琐已经退至备用设备，目前不建议购买。

Magewell USB Capture HDMI Plus

参考价：

¥2600

优点：

分辨率最高支持 4k/60fps，不用调整演讲者电脑。
带环路输出，离输出设备近的情况下可以节省一个 HDMI 分配器。
使用 USB 3.0 接口，兼容性好。

缺点：

价格昂贵。

评价：

我当前使用的设备，满足一切需求。

摄像机

Canon LEGRIA HF R86

参考价：

¥1999

优点：

价格便宜。

缺点：

麦克风指向性不好，且没有麦克风接口，扩展性差。

评价：

我的第一代设备，适合用于录制小型会议。但对于 500 人的会议，环境噪声变得非常大，缺乏 XLR 接口无法接入会场的麦克风输出。

Canon XA30

参考价：

¥11999

优点：

专业级设备，扩展性强，提供 XLR 接口。

缺点：

价格昂贵。

评价：

我当前使用的设备。对于会议录制，其实对声音的要求比视频更高，专业级设备提供的丰富接口可以轻松接入会场的麦克风输出。

如果会议规模不大，或者场地没有提供麦克风输出，那么用家用机已经足够。

其它

绿联（UGREEN）HDMI分配器一进二出

参考价：

¥188

评价：

够用。

云腾（YUNTENG） VT-6008 摄像三脚架

参考价：

¥179

评价：

够用，我能找到的最便宜的摄像三脚架。

总结

实际录制过程中还有很多需要注意的地方，例如提前搭设备、让讲师测试设备兼容性、调整摄像机的白平衡、调整合适的视频码率、后期裁剪多余的视频等等，不能一一在此叙述。

网上关于如何录制会议视频的资料较少，我也是一步步摸索，所以方案还有很多不成熟的地方，欢迎留言交流，一起提高中文技术会议的录像质量。

用 Docker Compose 搭建 Rails 开发环境

Mon, 24 Apr 2017 00:00:00 +0000

Docker 是目前最热门的容器格式，Docker Compose 是用于管理包含多个 Docker 容器的应用的工具，借助 Docker 和 Docker Compose，我们可以轻松搭建可复现的开发环境。

这篇教程展示如何从零开始用 Docker Compose 搭建 Rails/PostgreSQL 开发环境。

本文主要参考了 Quickstart: Compose and Rails。但原文有一点问题，于是我加上自己的见解写成这篇博客。

安装 Docker

首先，需要在自己的开发机上安装 Docker，你可以在 https://www.docker.com/ 找到适合自己操作系统的 Docker 安装方式。

安装完毕后，可以在命令行中使用 docker 命令：

$ docker --version
Docker version 17.03.1-ce, build c6d412e

创建项目

创建项目目录：

$ mkdir myapp
$ cd myapp

接着，创建一个 Gemfile 文件，包含以下内容：

source 'https://rubygems.org'

gem 'rails', '5.1.0.rc2'

然后，创建一个空的 Gemfile.lock 文件：

$ touch Gemfile.lock

之所以这么做，是因为不希望在主机环境安装 Ruby 和其它依赖，而是都放到镜像中。这两个文件用于在镜像中安装 Rails。

接着，创建一个 Dockerfile 文件，该文件用于定义如何构建 Rails 镜像：

FROM ubuntu:16.04

RUN apt-get update && apt-get install -y curl apt-transport-https && \
  curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && \
  echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list

RUN apt-get update && apt-get install -y \
  build-essential \
  libpq-dev \
  nodejs \
  ruby \
  ruby-dev \
  tzdata \
  yarn \
  zlib1g-dev

WORKDIR /app

RUN gem install bundler
ADD Gemfile /app/Gemfile
ADD Gemfile.lock /app/Gemfile.lock
RUN bundle install
ADD . /app

这个 Dockerfile 基于 Ubuntu 16.04，安装了创建 Rails 项目所需要的基础包，并将项目目录设定在 /app。你可以阅读 https://docs.docker.com/ 学习怎么定制 Dockerfile。

然后，创建一个 docker-compose.yml 文件，该文件用于定义 docker-compose 如何启动应用：

version: '2'
services:
  web:
    build: .
    command: bundle exec rails s -p 3000 -b 0.0.0.0
    volumes:
      - .:/app
    ports:
      - 3000:3000
    depends_on:
      - db
  db:
    image: postgres

在这个文件里，我们定义了两个服务。web 服务用于运行 Rails，镜像将根据当前目录的 Dockerfile 构建；db 服务用于运行 PostgreSQL 进程，镜像使用 Docker 官方提供的 postgres。你可以在 https://docs.docker.com/compose/compose-file/ 找到其它配置的定义。

接下来，执行以下命令：

$ docker-compose run web rails new . --force --database=postgresql

该命令会在当前目录创建 Rails 项目：

$ ls -l
total 72
-rw-r--r--   1 rei  staff   522  4 25 22:59 Dockerfile
-rw-r--r--   1 rei  staff  1989  4 25 23:02 Gemfile
-rw-r--r--   1 rei  staff  4847  4 25 23:03 Gemfile.lock
-rw-r--r--   1 rei  staff   374  4 25 23:02 README.md
-rw-r--r--   1 rei  staff   227  4 25 23:02 Rakefile
drwxr-xr-x  10 rei  staff   340  4 25 23:02 app
drwxr-xr-x   9 rei  staff   306  4 25 23:03 bin
drwxr-xr-x  14 rei  staff   476  4 25 23:02 config
-rw-r--r--   1 rei  staff   130  4 25 23:02 config.ru
drwxr-xr-x   3 rei  staff   102  4 25 23:02 db
-rw-r--r--   1 rei  staff   206  4 25 22:59 docker-compose.yml
drwxr-xr-x   4 rei  staff   136  4 25 23:02 lib
drwxr-xr-x   3 rei  staff   102  4 25 23:02 log
-rw-r--r--   1 rei  staff    61  4 25 23:02 package.json
drwxr-xr-x   9 rei  staff   306  4 25 23:02 public
drwxr-xr-x  11 rei  staff   374  4 25 23:02 test
drwxr-xr-x   4 rei  staff   136  4 25 23:02 tmp
drwxr-xr-x   3 rei  staff   102  4 25 23:02 vendor

接着，重建 Docker 镜像：

$ docker-compose build

每当修改了 Dockerfile，你都需要重建镜像。如果修改了 Gemfile，还需要先在容器内运行 bundle，然后重建镜像：

$ docker-compose run web bundle
$ docker-compose build

连接数据库

现在我们已经可以让 Rails 跑起来，但还需要修改一些配置让 Rails 连上数据库。默认情况下，Rails 的 development 和 test 环境会连接 localhost 主机上的数据库，根据之前的 docker-compose.yml 配置，我们需要将数据库的主机名改为 db。另外，还需要修改 username 以适配 postgres 镜像的默认配置。修改后的 database.yml 配置如下：

development:
  <<: *default
  database: app_development
  host: db
  username: postgres

test:
  <<: *default
  database: app_test
  host: db
  username: postgres

现在可以启动 Rails 进程了：

$ docker-compose up

如果一切正常，你会看到一些 postgres 的日志，然后是 Rails 启动日志：

web_1  | => Booting Puma
web_1  | => Rails 5.1.0.rc2 application starting in development on http://0.0.0.0:3000
web_1  | => Run `rails server -h` for more startup options
web_1  | Puma starting in single mode...
web_1  | * Version 3.8.2 (ruby 2.3.1-p112), codename: Sassy Salamander
web_1  | * Min threads: 5, max threads: 5
web_1  | * Environment: development
web_1  | * Listening on tcp://0.0.0.0:3000
web_1  | Use Ctrl-C to stop

如果你需要运行数据库迁移，可以打开另一个终端运行：

$ docker-compose run web rails db:create
$ docker-compose run web rails db:migrate

TIP: 以后运行 rails 命令，都需要在前面加上 docker-compose run web。

用浏览器访问 http://localhost:3000 ，你会看到 Rails 的欢迎信息：

将 Dockerfile docker-compose.yml 与项目文件一并提交到版本控制里，这样新开发者参与项目的时候就可以用 docker-compose up 一键启动开发环境。

Ruby China 正在衰退吗？

Sun, 12 Mar 2017 00:00:00 +0000

Ruby China 是一个非营利的开源社区，不知不觉已经成立了 6 年。作为管理员之一，我一直不觉得是由管理员创建了这个社区，而是 Ruby 爱好者自发聚集组成了社区，我在里面只是担任了清洁工一类的角色。

我最近经常被问到的一个问题是：

Ruby China 活跃度是不是越来越低了？

主观上我也觉得 Ruby China 的热度有所降低，由于此前没有具体的数字，所以我做了一些调查。

访问量总体还是呈上升趋势，因为论坛上积累了很多内容，形成了长尾效应。

注册人数平稳，除了某个月份有点异常，先忽略。不过下面两个图看出了问题：

糟糕，话题数和回复数从 2013 年开始就一直在下降。从这个数据上看，Ruby China 确实是活跃度越来越低。但……我并不认为这是个大问题。一直以来活跃度都不是管理员们关注的指标，相应的我们关心社区里的人实际在交流什么，有什么建设性的想法，哪里要举办线下聚会，哪个公司使用了 Ruby 正在招人。一些会让社区很热闹，但实质上没有营养的帖子会被毫不犹豫的移到 NoPoint 节点。所以 Ruby China 一直在技术圈有良好的口碑，并且每年举办 RubyConf。

不过我想大家真正关心的是：Ruby 是不是正在衰退，毕竟这关系到新手能不能找到工作、老手以后会不会失业。我觉得需要认识到两点：

Ruby 确实已经不热门了。Ruby 在国外 07 ～ 09 年就达到了宣传的巅峰，我在 09 年刚接触 Ruby 的时候就看到国外对 Ruby 狂热的反思，有人花了两年用 Rails 重写网站失败，然后又用两个月回到 PHP。支持我学下去的原因是对我来说 Ruby 比 Java/PHP/Python 好学（没错，我都学过，没学会），用 Rails 我第一次做出了有 CRUD 的完整网站。

标志性的事件是在 11 年 Twitter 从 Ruby 向 Scala 迁移，Ruby 的狂热破灭了，Ruby 被烙上了性能不佳、无法扩展的印记，每个 Ruby 项目似乎迟早要被替换。不过，也有一些成熟的公司一直在用 Ruby：Basecamp，GitHub，Shopify，Airbnb，Twitch，SoundCloud……

近年来，新语言新框架层出不穷，Go、Node.js、Elixir，很多新技术都在冲击 Ruby 的强项 Web 端。新技术最常见的推销方法就是写一个 Hello World 的性能测试跟 Rails 比较。从企业角度使用 Rails 不再代表团队的有多先进，从新手角度学习 Ruby 不再代表将来有很多工作机会。

Ruby 正在走向成熟。技术热门度曲线模型认为，一门技术的发展要经历五个阶段：启动期-泡沫期-低谷期-爬升期-高原期。据 State.of.dev 的分析，Ruby 正处于低谷期：

StackOverflow 和 Discourse 的创始人 Jeff Atwood 写道：

Ruby 不再酷了，追酷的人几年前都到了 Scala 或者 Node.js。我们的项目也不酷，只是一坨老旧的 Ruby 代码。从个人角度，我很庆幸 Ruby 已经成熟到不需要把自己打扮成最酷的孩子。这意味着我们这些只想把事情搞定的人可以专注做正经事，不用再去找下一个闪光点。 ——Why Ruby

不止一个人跟我说过，在 Ruby China 上好像没什么好讲了，该踩的坑已经踩过，该吐的槽都吐过。但是，他们都在工作中使用 Ruby，用 Ruby 开发商业项目不再被怀疑是个很大风险。到招聘板块看看，Ruby 已经走入各行各业，也许每天使用的服务后面就有 Ruby 的应用。

当然，Ruby China 作为最大的 Ruby 中文社区，有义务跟上 Ruby 的发展。17 年至今已经做了以下事情：

上线打赏功能。
上线头条功能。
赞助 Rails Guides 翻译。
设计新的 LOGO 和 UI（进行中）。

这些改进都是为了方便让新手能找到学习资料，老手能分享行业经验，企业能找到适合的人才。我们利用业余时间维护 Ruby China，只为了让社区发展更好，毕竟我们已从开源获益良多。

最后，我贴一下我面试现在这家公司时回答的最后一个问题：

“你觉得 Ruby 好在哪里？”

“我觉得 Ruby 好的地方，是它被设计为让程序员快乐。Ruby 有很多便利的语法，但语法很容易被别的语言借鉴，唯有它的理念独树一帜。Ruby 一直让我觉得编程很快乐。”

测试指南

Mon, 26 Oct 2015 00:00:00 +0000

测试有很多种，像用户测试，A/B 测试等等，这里说的是由开发人员自己实行，用于确保开发过程没有引入错误的代码测试。

测试不是一个新概念，相反部分社区可能过度狂热，制造了太多的测试框架和库，增加了很多复杂性，以至于让人敬而远之。其实测试只是一个简单的概念，这篇文章尝试说明这一点。

测试

先看一个例子，假如我们需要实现一个方法 fizz_buzz(n)，要求 n 是一个整数，如果 n 是 3 的倍数，就返回 'Fizz'；如果 n 是 5 的倍数，就返回 'Buzz'；其余则返回 n 本身。这个方法没什么实际作用，但用来做例子很合适，我们假设这个方法是某个生产应用的关键算法。

这个方法很简单，一会就能写出来：

# fizz_buzz.rb
def fizz_buzz(n)
  if n % 3 == 0
    'Fizz'
  elsif n % 5 == 0
    'Buzz'
  else
    n
  end
end

要验证这个方法是否正确，可以在终端执行这个方法查看结果：

> require './fizz_buzz.rb'
> fizz_buzz 1
=> 1
> fizz_buzz 2
=> 2
> fizz_buzz 3
=> "Fizz"
> fizz_buzz 4
=> 4
> fizz_buzz 5
=> "Buzz"

看起来没问题，于是就把这个方法用到产品环境中了……然后有一天，需求更改了，要求增加一个逻辑：如果 n 同时是 3 和 5 的倍数，就返回 FizzBuzz。而当前的实现只会返回 Fizz：

> fizz_buzz 15
=> "Fizz"

于是修改这个方法：

# fizz_buzz.rb
def fizz_buzz(n)
  if n % 3 == 0 and n % 5 == 0
    'FizzBuzz'
  elsif n % 3 == 0
    'Fizz'
  elsif n % 5 == 0
    'Buzz'
  else
    n
  end
end

然后到终端调试：

> require './sum.rb'
> fizz_buzz 15
=> "FizzBuzz"

但是这个修改有没有破坏以前的行为呢？这时候再用以前的数据调试一下：

> fizz_buzz 1
=> 1
> fizz_buzz 2
=> 2
> fizz_buzz 3
=> "Fizz"
...

这里遇到一个问题，我们在重复以前的调试内容。重复一两次还没问题，三次以上就很烦人了。并且随着代码量上升，越来越难确定修改会影响什么地方的逻辑，容易引入 bug。

高效程序员会将调试代码固化下来，写成测试代码。

新建一个文件，写入测试代码：

# fizz_buzz_test.rb
require './fizz_buzz.rb'

fizz_buzz(1) == 1 ? print('.') : raise("fizz_buzz 1 should be 1")
fizz_buzz(3) == 'Fizz' ? print('.') : raise("fizz_buzz 3 should be Fizz")
fizz_buzz(5) == 'Buzz' ? print('.') : raise("fizz_buzz 5 should be Buzz")
puts 'done'

这个脚本会对比程序输出和预期结果，如果结果一致就会打印一个点.，否则会抛出异常，中止测试并打印错误信息。

$ ruby fizz_buzz_test.rb
...done

我们可以故意把方法写错，看看有什么结果：

# fizz_buzz.rb
def fizz_buzz(n)
  n
end

再次运行，结果就是：

$ ruby fizz_buzz_test.rb
.fizz_buzz_test.rb:4:in `<main>': fizz_buzz 3 should be Fizz (RuntimeError)

有了测试脚本的帮助，我们就能知道对代码的修改有没有破坏以前的逻辑。修改了代码之后，别忘了加上新增部分功能的测试：

fizz_buzz(15) == 'FizzBuzz' ? print('.') : raise("fizz_buzz 15 should be FizzBuzz")

再次运行测试：

$ ruby fizz_buzz_test.rb
....done

assert（断言）

之前的测试代码里面有不少重复代码，例如 print，raise 等等。我们可以把这些跟测试用例没有直接关系的代码抽取出通用方法，这类方法有一个惯用名称 assert，于是测试代码简化成：

def assert(test, msg = nil)
  test ? print '.' : raise(msg)
end

assert fizz_buzz(1) == 1, "fizz_buzz 1 should be 1"
assert fizz_buzz(3) == 'Fizz', "fizz_buzz 3 should be Fizz"
assert fizz_buzz(5) == 'Buzz', "fizz_buzz 5 should be Buzz"
assert fizz_buzz(15) == 'FizzBuzz', "fizz_buzz 15 should be FizzBuzz"
puts 'done'

测试代码多了之后，会发现有一类测试有固定的模式，例如上面的测试就是判断一个方法的输出跟另一个值是否相等，这样又可以抽取出一个 assert_equal 方法：

def assert(test, msg = nil)
  test ? print '.' : raise(msg)
end

def assert_equal(except, actual, msg = nil)
  assert(except == actual, msg)
end

assert_equal 1, fizz_buzz(1), "fizz_buzz 1 should be 1"
assert_equal 'Fizz', fizz_buzz(3), "fizz_buzz 3 should be Fizz"
assert_equal 'Buzz', fizz_buzz(5), "fizz_buzz 5 should be Buzz"
assert_equal 'FizzBuzz', fizz_buzz(15), "fizz_buzz 15 should be FizzBuzz"
puts 'done'

这里看起来好像没减少代码，不过起码不用怕写错 == 号了。常见的 assert_* 方法还有：

assert_nil(object, msg) 测试对象是否 nil。
assert_empty(object, msg) 测试对象调用 .empty? 是否返回 true。
assert_includes(collection, object, msg) 测试集合 collection 是否包含 object。
assert_throws(exception) { } 测试执行一个 block，是否会抛出某个异常。

这些方法都不过是 assert 的包装，只要知道 assert 的原理，这些辅助方法都能自己实现，或者实现其他适合场景的断言方法。

现在每个主流语言都会有一个测试库，在 Ruby 中就是 Minitest。测试库除了包含一些断言方法外，还提供测试代码隔离、测试环境重置、更好的错误提示等功能，你可以阅读文档了解详情。

TDD

TDD 是 Test-driven development（测试驱动）的缩写，它是一种开发方法，提倡在实现功能之前先写测试，从而实现更好的程序质量和接口设计。它的流程可以简化如下：

写测试
运行测试（失败）
写功能
运行测试（通过）
回到 1

这种方法在一定程度上是有效的，先写测试可以提供高覆盖度的代码测试，减少 bug。并且写测试的过程就是在实际调用程序接口，有助于理清设计思路。要详细了解 TDD，可以读《测试驱动开发》这本书。

不过如果片面追求测试覆盖率，就很容易写出比功能代码多几倍的测试代码。测试也是代码，代码就有维护成本，过多的测试反而降低编码效率。对此《测试驱动开发》的作者 Kent Beck 有过解释：

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence. （我的薪水是付给能用的代码，而不是给测试的，所以我的哲学是在可信赖的程度上，尽量少写测试。） http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests

另外，TDD 也可能对设计产生误导，变成追求测试的简洁而不是接口简洁。DHH 在 RailsConf 2014 上举了一个例子：

class Person
  def age
    Date.today.year - birthday.year
  end
end

test "a person's age is determined by birthday" do
  sevent_niner = Person.new birthday: Date.new(1979)
  travel_to Date.new(2009)
  assert_equal 30, sevent_niner.age
end

在这个例子中，Person#age 的返回结果是会随着时间变化的，为了保证测试的可靠，需要使用 travel_to 这个 hack，把测试用例的时间固定在某个值。

这时候为了写出优美的测试代码，可能会想到另一个接口设计：

class Person
  def age(now = Date.today)
    now.year - birthday.year
  end
end

test "a person's age is determined by birthday" do
  sevent_niner = Person.new birthday: date.new(1979)
  assert_equal 30, sevent_niner.age Date.new(2009)
end

通过给 age 添加一个参数，让测试代码避免了 hack，似乎是一个更好的方案。但实际上，在正常的调用中，age 并不需要参数，这个参数完全是为了测试而添加的，这给原先的设计增加了不必要的复杂性。这就是测试驱动开发误导了设计的例子。

总结

以上内容就是关于测试必须了解的内容，至于 DSL、Mock/Stub、Factory……之类的工具都是锦上添花，不是必须的。

为了项目的可维护性，也为了节约自己的时间，应该积极的拥抱测试。但也不要忘了测试只是辅助开发的工具，不要本末倒置，使用太复杂的测试工具增加维护难度。

安装和配置 Postfix

Wed, 22 Apr 2015 00:00:00 +0000

Postfix 是一个 MTA（Mail Transfer Agent），可以用来收发邮件。开发网站多少都需要收发邮件的功能，例如邮件验证、找回密码等。

配置邮件系统过程比较复杂，而且需要很多维护工作，如果发送量不大，可以先用 Mailgun，Mandrill 等第三方邮件发送服务，在遇到以下情况的时候，再考虑自建邮箱系统：

第三方服务费用太高。
QQ 邮箱对第三方服务拒信率高。
邮件排队时间过长，发送不及时。

自建邮件系统可以处理这些问题，有更多优化空间。

系统需求

Ubuntu LTS 14.04 。

设置 hostname

事先设置好 hostname 的话，Postfix 可以自动配置好很多参数，节省时间。假设你的网站域名是 example.com，要搭建独立的邮件服务器（推荐），就把主机名设置为 mail.example.com。

# echo 'mail.example.com' > /etc/hostname
# hostname -F /etc/hostname

安装 Postfix

# apt-get install postfix

安装过程会弹出设置窗口，全部回车确认既可。

基本配置

Postfix 的配置文件位于 /etc/postfix 文件夹。先看 main.cf 文件，有几个重要的配置。如果事先设置了正确的 hostname，那么这些配置已经自动设置好了。

`myhostname`

myhostname = mail.example.com

myhostname 让 Postfix 知道自己主机的名字。

`myorigin`

myorigin = /etc/mailname

myorigin 的值存放在另一个文件中，打开这个文件可以看到一行内容 mail.example.com。

在通过 Postfix 发送邮件的时候，如果 From 字段不完整，例如 From: user，Postfix 会根据 myorigin 的值将地址补全为 From: user@mail.example.com。

* 发邮件的时候 From 字段是可以随意指定的。

`mynetworks`

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

mynetworks 指定了本地网络的 IP 段，默认只包含主机自己。

`smtpd_relay_restrictions`

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

smtpd_relay_restrictions 指定了 Postfix 在作为邮件发送方的时候，只接受通过以下规则的发信请求：

permit_mynetworks 允许 mynetworks 包含的主机发信。
permit_sasl_authenticated 允许通过 SASL 身份验证的主机发信。
defer_unauth_destination 不符合其它转发规则的时候拒绝发信。

`mydestination`

mydestination = mail.example.com, localhost.example.com, localhost

mydestination 指定了 Postfix 在收到这些域名地址作为目标地址的邮件时，作为接收方收下邮件。

如果收到的邮件既不符合转发规则，又不符合接收规则，则会拒绝收信。

由于我希望这台服务器能接受主域名 example.com 的邮件，所以将这个配置修改为：

mydestination = example.com, mail.example.com, localhost.example.com, localhost

重载 Postfix：

# service postfix reload

为了检查安装情况，现在先做一些测试。

测试一：发邮件

用 sendmail 命令给自己的邮箱发送一封空邮件

# sendmail youremail@gmail.com
.

输入第一行的时候，sendmail 会等待输入邮件内容，此时直接输入一个 . 结束输入，这会产生一个空邮件。

登录你的邮箱，如无意外可以在垃圾邮件箱找到这封邮件。这说明 Postfix 已经具有发送能力。

测试二：收邮件

由于还没有配置 DNS，其它邮件服务商还无法识别这部主机，先在另一台主机用 telnet 进行测试，假设邮件服务器的 IP 是 192.168.33.10：

$ telnet 192.168.33.10 25
Trying 192.168.33.10...
Connected to 192.168.33.10.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Ubuntu)
MAIL FROM: youremail@gmail.com
250 2.1.0 Ok
RCPT TO: root
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
text
.
250 2.0.0 Ok: queued as 651FE22162
QUIT
Connection closed by foreign host.

加粗部分是需要输入的内容。

在邮件服务器上检查信件：

# tailf /var/mail/root

大概会看到这样的内容：

From youremail@gmail.com  Wed Apr 22 16:13:33 2015
Return-Path: <youremail@gmail.com>
X-Original-To: root
Delivered-To: root@mail.example.com
Received: from unknown (unknown [192.168.33.1])
        by mail.example.com (Postfix) with SMTP id 651FE22162
        for <root>; Wed, 22 Apr 2015 16:13:13 +0000 (UTC)

text

Postfix 默认使用 mbox 格式将系统用户的邮件存放到 /var/mail 目录下。

MX 记录

如果你的邮件服务器已经部署到公网上，要用来接收其它邮件服务商发来的邮件，那么需要到域名的 DNS 服务器进行修改。

首先给邮件服务器设置 A 记录（自行替换为真实 IP）：

mail.example.com. IN A 192.168.33.10

然后给主域名设置 MX 记录：

example.com. IN MX 10 mail.example.com.

在本地测试更新状况：

$ dig example.com mx

如果返回了正确的 MX 记录，则邮件服务器已经可以被识别，但不同服务商所用的 DNS 更新状况不一样，全部生效也许要过一段时间。

在本地测试邮件服务器是否能收到邮件：

$ sendmail root@example.com
.

`aliases`

用登录 ssh 的方式收邮件不方便，我们可以使用 aliases 功能将邮件转发到自己的个人邮件地址。

打开 /etc/aliases 文件，目前应该是这样：

# See man 5 aliases for format
postmaster: root

将 root 作为别名，转发到个人邮件地址：

# See man 5 aliases for format
postmaster: root
root: youremail@gmail.com

这样以 root@example.com 作为目的地址的邮件将会转发到 youremail@gmail.com。

别名支持多个地址，所以一个简易的邮件列表可以这样实现：

# See man 5 aliases for format
postmaster: root
root: youremail@gmail.com
support: youremail@gmail.com, another@gmail.com

这样以 support@example.com 作为目的地址的邮件将会转发到 youremail@gmail.com 和 another@gmail.com 。

修改 /etc/aliases 文件后，需要运行一条命令让它生效：

# newaliases

SASL 身份验证

目前 Postfix 只能为本地应用发送邮件，还不接收为远程应用发送邮件。如果你的应用跟 Postfix 装在同一个服务器，那么无需身份验证既可发送邮件；而如果不在同一个服务器，则需要配置某种验证方式验证发信者的身份。

一个方法是配置 mynetworks，把应用服务器纳入本地网络，以 192.168.33.11 为例：

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.33.11

mynetworks 的值还支持掩码，如果应用服务器位于同一个网段，这种方法比较方便。

我比较习惯帐号密码的方式验证，在 Postfix 可以使用 SASL 模块实现帐号密码验证。SASL 模块支持多种帐号密码储存方式，这里只介绍用独立数据库文件（sasldb2）存放的方式。

安装 SASL

首先安装一些工具用于创建 SASL 专用的帐号密码。

# apt-get install sasl2-bin

创建 SASL 帐号密码

# saslpasswd2 -c -u example.com postmaster
# cp -a /etc/sasldb2 /var/spool/postfix/etc/

* Postfix 的 smtpd 进程默认使用了 chroot，所以要把数据库文件拷贝到 /var/spool/postfix/etc 目录内。

输入后会提示输入两次密码，创建成功后帐号为 postmaster@example.com，密码为所输入的密码。

为了让 Postfix 能读取这个文件，把 postfix 加到 sasl 组，并设为只读：

# gpasswd -a postfix sasl
# chmod 640 /var/spool/postfix/etc/sasldb2

检查现有的帐号：

# sasldblistusers2 -f /var/spool/postfix/etc/sasldb2

配置 Postfix

在 /etc/postfix/main.cf 添加以下内容：

# SASL
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = yes

这些配置打开 SASL 登录，并且只允许 TLS 安全传输的情况下进行验证。之所以强制 TLS，是因为默认的 PLAIN 校验传输的几乎是明文密码。

新建文件 /etc/postfix/sasl/smtpd.conf，添加内容：

pwcheck_method: auxprop

这个配置指定使用数据库文件读取帐号密码信息。

修改配置后，重载 Postfix 让配置生效：

# service postfix reload

测试登录

首先准备 SASL PLAIN 验证需要的帐号密码字符串，输入以下命令：

printf '\0%s\0%s' 'postmater@example.com' '123456' | openssl base64

实际中替换你需要的帐号密码，输出结果即为登录字符串。

由于设置了强制 TLS 登录，用 telnet 就不那么方便了，这时候可以用以下命令连接：

openssl s_client -connect mail.example.com:25 -starttls smtp

这条命令打开到服务器的 smtp 连接，并且完成 starttls 过程，之后界面跟 telnet 类似。完成校验的命令如下：

auth plain AHBvc3RtYXRlckBleGFtcGxlLmNvbQAxMjM0NTY=
235 2.7.0 Authentication successful

看到 Authentication successful 即为通过校验。现在远程主机可以通过帐号密码登录，使用 Postfix 发信了。

SPF 记录

SPF 记录是一种通过 DNS 记录，验证邮件发送主机的 IP 是否可信的方法。之所以需要额外的验证方式，是因为 Email 的发送地址很容易伪造，没有有效 SPF 记录的邮件很可能被归为垃圾邮件。后面的 DKIM 也是验证邮件可信度的一种方式。

配置 SPF 记录分为设置发信和校验来信两种情况。

设置发信 SPF

发信的 SPF 记录不需要 Postfix 设置，而完全在 DNS 上。

为自己的域名添加一条 TXT 记录：

example.com IN TXT "v=spf1 mx ~all"

这条记录表示域名自身 MX 记录指向的主机为可信主机，~all 表示除此以外的主机为软拒绝。

SPF 记录的语法规则可以查阅 http://www.openspf.org/SPF_Record_Syntax 。

校验来信 SPF

Postfix 需要安装一个组件以支持 SPF 校验。

# apt-get install postfix-policyd-spf-perl

添加 Postfix policy：

# postfix-add-policy spfcheck nobody /usr/sbin/postfix-policyd-spf-perl

在 /etc/postfix/main.cf 添加以下内容：

# SPF
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_policy_service unix:private/spfcheck
spfcheck_time_limit = 3600

重载配置：

# service postfix reload

现在 Postfix 每收到一封邮件都会进行 SPF 校验，然后在邮件头部加入类似 Received-SPF: pass 的信息。

DKIM 签名

DKIM 是另一种验证邮件有效性的方法。跟 SPF 不同，DKIM 在 DNS 公开一个公钥，然后用私钥对自己的邮件进行签名。收信者查询发信方域名获得公钥，然后校验签名是否有效。

为 Postfix 添加 DKIM 支持需要用到 opendkim 这个包。

安装 opendkim

# apt-get install opendkim opendkim-tools

配置 opendkim

打开 /etc/opendkim.conf，添加以下内容：

Domain example.com
KeyFile /etc/mail/dkim.key
Selector mail

Domain 为自己的域名，KeyFile 为域名对于的私钥，Selector 为公钥存放的主机名（这里设置为 mail._domainkey.example.com）。

打开 /etc/default/opendkim，添加以下内容：

SOCKET="inet:8891@localhost" # listen on loopback on port 8891

这里让 opendkim 的守护进程监听 8891 端口，用于和 Postfix 通信。

* 你应该配置防火墙禁止外部访问白名单以外的端口。

生成密钥和配置 DNS

生成密钥：

# mkdir /etc/mail
# cd /etc/mail
# opendkim-genkey -s mail -d example.com
# cp mail.private dkim.key

查看 mail.txt 文件，里面有 dkim 的公钥，将它添加为 DNS TXT 记录，类似于：

mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PpYHdE2tevfEpvL1Tk2dDYv0pF28/f5M..."

重启 opendkim：

# service opendkim restart

配置 Postfix

打开 /etc/postfix/main.cf，添加以下内容：

# DKIM
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

这为 Postfix 加上了 DKIM 的过滤器，发信的时候签名，收信的时候校验。

重载 Postfix：

# service postfix reload

现在 Postfix 会自动为发出的邮件签名，校验收到的邮件。

总结

现在已经利用 Postfix 搭建了一个邮件服务器，我们可以使用它收发网站邮件。但搭建完毕只是第一部，接下来还需要观察送达情况。最重要的一点，不要发送垃圾邮件，不要让网站有漏洞让用户发送垃圾邮件，否则会拉低所有邮件的评分，导致正常邮件也发不出去。

要深入了解 Postfix 的使用，推荐书籍：《Postfix 权威指南》。看完这本后就可以看官方文档：http://www.postfix.org/documentation.html 。

Rei

Stand with Hong Kong, but which side?

Foreword

2019-06-12 Attacking the Legislative Council

2019-07-01 Destroy the Legislative Council

2019-07-21 Hong Kong Dark Night

2019-10-06

Politics is very complicated

Respect is mutual

香港的支付方式

容器也许是未来，但不是当下

Stimulus 框架简介

Stimulus 解决的问题

我需要 Stimulus 吗？

你的前端需求也许没那么复杂

前后端分裂

分离狂热

前端怪圈

那怎么办……

会议视频录制指南

需求

方案

软件设置

添加来源

添加录屏

添加摄像头

添加背景

添加麦克风

开始录制

其它

硬件选择

采集卡

Blackmagic UltraStudio Mini Recorder

Magewell USB Capture HDMI Plus

摄像机

Canon LEGRIA HF R86

Canon XA30

其它

绿联（UGREEN）HDMI分配器一进二出

云腾（YUNTENG） VT-6008 摄像三脚架

总结

用 Docker Compose 搭建 Rails 开发环境

安装 Docker

创建项目

连接数据库

Ruby China 正在衰退吗？

测试指南

测试

assert（断言）

TDD

总结

安装和配置 Postfix

系统需求

设置 hostname

安装 Postfix

基本配置

myhostname

myorigin

mynetworks

smtpd_relay_restrictions

mydestination

测试一：发邮件

测试二： 收邮件

MX 记录

aliases

SASL 身份验证

安装 SASL

创建 SASL 帐号密码

配置 Postfix

测试登录

SPF 记录

设置发信 SPF

校验来信 SPF

DKIM 签名

安装 opendkim

配置 opendkim

生成密钥和配置 DNS

配置 Postfix

总结

`myhostname`

`myorigin`

`mynetworks`

`smtpd_relay_restrictions`

`mydestination`

测试二：收邮件

`aliases`