又一篇讲为什么从 Python (文中的观点也可以适用于 Ruby) 迁移到 Erlang 的文章

defmacro — Thu, 07 Jul 2016 09:53:18 +0800

https://ourway.ir/Why_And_How_I_Switched_From_Python_To_Erlang.html

注意我的 Chrome 直接打开这篇会崩不知道为什么，要 Safari 才能顺利打开。

通常情况下对这种文章我是直接忽略的，因为多半是神经病一样的“看我的 Hello World 请求在 BEAM 下跑的飞快，再看你那慢如狗的 Rails”。。。但是这篇文章说到点子上了，而且很多对于 Python 的论据也适合于 Rails，或者是 Ruby(是的我天天鼓吹的 Cuba 架构也有这个问题)。Rails/Ruby 发展到现在，绝大多数问题都是有解决的方案的，Sidekiq，Russian Doll Caching 等等都是为了解决所谓的慢而出现的。但是在工程圈里，有解决方案并不是唯一的 metric，很多时候我们要考虑投入产出比。虽然用上面的许多方案可以解决 Rails 的问题，但是考虑这样的场景：一个资深工程师充分设计并调优之后的一个 Rails codebase，可能也就是跟一个初学者随便写写的 OpenResty，或者是 node.js 框架跑的差不多快，我不知道大家，这时候我是很有挫败感的。

所以我最近反思的一个主题是：是不是真的有必要追求 Rails/Ruby 那可能只有 10% 或者 20% 的生产力提升，而抛弃整个框架设计层面的许多可能性。这已经不是 Rails 刚出现的那个时代了，现在其他语言的框架 (包括 Java) 也充分吸收了 Rails 的很多优点，生产力也已经大幅提升，Rails 已经没有那种数量级上的差距了 (当然从这个角度来说 Rails 很成功，这个我十分赞同)。说的偏激一点，这 10% 或者 20％现在是否存在，也是一件有争议的事情，并不是每个人都认同。

当然也不是说 Ruby 就这样完了，我觉得 HTTP/2 就是一个 Ruby 可以利用的好机会，配合 HTTP/2 带有 Push 机制的架构，这正是一个我们反思 Rack 是不是适合 HTTP/2 的机会，完全可以趁这股潮流重新设计 Rack，做一个基于 Fiber 的结构，虽然这样跟 HTTP/1 会有非常大的冲突，但是这给了 Ruby 社区一个可能性：传统项目完全可以继续走 HTTP/1 以及 Rack 1.x 继续走原来的路，如果想做新一代的 web app，这样的全新架构也可以提供跟 OpenResty，Elixir 竞争的底气。

无奈现实不给力，现在 Ruby 社区对 HTTP/2 的使用真的很让人痛心：一部分人在忙着把 Rack 的 API 从 hash-based 改成 object-based，另一部分人把 nginx 换成新版本然后就此标榜 Rails 是 HTTP/2 的了，这是在过家家么 -_-

另外我在广义层面上不赞同 "Right Tool For The Right Job" 的观点。这个观点只适用于大公司，初创企业即使有工程师出身的开发人员，也要身兼数职，更何况很多初创企业是其他行业的人半专职过来写代码，这种情况下面对 HTML/JS/CSS/Ruby 就已经很头痛了，我们还不帮忙把这个 list 减少反而要引入更多的工具，究竟是在做项目还是在玩工具。。。

求大神把我骂醒

[远程] CitrusByte 招聘 Simplicity Driven Developer

defmacro — Tue, 14 Jul 2015 09:58:16 +0800

首先，我想说，我不是专职的 HR 人员，我只是一名工程师。所以这里我不想发一个传统的招聘广告，如果大家喜欢传统的招聘广告的话，我老板在这边已经发过一个很好的招聘广告了，欢迎大家直接去那边应聘。这里我只想从一个工程师的角度出发，跟大家聊一下我在 CitrusByte 的一些感受。

这是一个什么公司？

先讲一个大家可能熟悉的：之前有一篇 Ruby China 上蛮流行的文章：How to write a template engine in less than 30 lines of code 就是我们老大写的。大家可以点击这里看到原文。同时 mote 这个库也是由之前在我们公司任职的工程师开发的。

从本质上来讲，我们是一个咨询公司，而不是像 Github 一样的创业公司。但是我们自己在内部也会做一些类似创业性质的项目，比如这里以及这里。所以大家也不用太担心一直做外包会不会烦，这边总有有趣的项目可以做。同时由于老板们很有经验，大家也不用担心客户会不会有不合理的需求，我老板曾经对我说，如果你觉得客户是错的，那你应该先去说服客户做正确的事情，而不是在错误的路上挖坑再尝试填坑（当然这里是我翻译的。。。我老板并不这么了解中文-_-）

我们公司基本上就是一个分布式的公司，工程师遍布在美国，阿根廷，乌拉圭，希腊，菲律宾，以及中国（当然就是我）。公司总部在洛杉矶，但是在纽约也有办公室，取决于不同的项目，可能会有需要飞到美国在现场办公，但是其他时间就可以在自己喜欢的地方干活了。当然，如果想去美国的话，公司也会协助办理 H1B，但是受限于小公司的问题，可能没有办法直接办 L1。这个如果有兴趣的话可以直接在面试时咨询下，我暂时没有去美国工作的打算所以就没问 -_-

我们这里很倡导开源文化，许多大牛在我们公司任职，或是曾在我们公司工作过（虽然大牛的最终去向基本都是去创业。。。），比如 Vagrant 的作者 Mitchell Hashimoto; Cuba 以及 ohm 的作者，Openredis 的 co-founder Michel Martens 等等。由我们公司现任或是前任开发人员开发并维护的开源软件包括但不仅限于：

Cuba: 类似于 Sinatra 的 Web 框架，但是比 Sinatra 要精简许多，可以做到熟读之后精通每一个细节 :)
ohm: 基于 Redis 的 ORM，我们相信 Redis 不仅仅可以用做 cache，Redis 也完全可以用作数据库。
dep: 一个超轻量化的 Gem 依赖管理工具，配合 gs 使用可以达到 Bundler 绝大部分的功能，并避免 Bundler 的一些问题。
Auto-Importer-for-Xcode: 自动帮你做 XCode import 的工具。

就如同职位名称中提现的一样，我们公司崇尚 Simplicity 的文化。我们相信软件中的很多复杂度，是我们自己引入的，这些复杂度对完成软件的功能没有任何帮助。通过精准的理解并定位需求，我们可以使用一些精简的，只包含所需功能的库组合起来，完成软件的开发，并将这些额外不需要的复杂度控制在最小。一个例子是我们并不会认为现在在 Rails 是一个 safe default，很多时候，我们并不是需要 Rails 的全部功能，我们完全可以用更简单的工具，比如 Cuba，实现我们需要的那部分需求。这样的结果是更简化的代码库，与更少的复杂度。

吹了这么多，待遇呢？

首先，最重要的薪资部分。抱歉这里我没有得到我老板的许可谈论这个（也可能是他没在 Slack 上回我我想多了 -_-）。但是基本上我想说：对于优秀的人才公司是绝对不会亏待的。我记得上次涨薪的时候老板跟我说：“我们希望你在公司长期的工作，所以我们打算给你一个让你不需要有太多别的顾虑的薪水”，然后薪水就涨了一大截。。。一个不负责任的观点是我觉得可以轻易秒杀市面上 80% 到 90% 的公司。

当然，这么说我个人还是感觉有点虚，我回头会再问问我老板如果可以的话再来把具体的范围补上。

然后就是远程公司应有的待遇了：你可以在地球上任何地方工作，只要能保证跟其他开发人员和客户有一定的 sync 时间即可。然后如果有项目需要的话会有去美国出差的机会。另外如果你有需要，也可以办理 H1B（当然，这个需要有运气抽中，还是上面说的，小公司有可能没办法办 L1）。

如果再说点虚的，就是技术上的追求了。你可以跟很多优秀的开发人员一起工作，我们对于最好的开源软件永远是毫不犹豫的引入项目使用的。所以在 CitrusByte，你可以期望工作中会用到各种新技术以及开源库。同时虽然我们公司内部很多人使用 Ruby，但是如果你喜欢的是 Python，或者 JavaScript，那也没有问题。对于项目的技术选型永远是开发人员做主，不会有别的 "政治因素"。

一个简单的例子是 AT&T M2X 这个系统。这个系统包含前端 UI 部分的 Portal Server，与后端的 API Server。前端服务器曾经是基于 mote 与 Cuba 的传统的服务器端渲染页面的架构，但是在 React 出现之后，我们觉得 React 很适合这个项目，于是 Portal Server 部分就用 React 重写了。现在使用 mote 的部分仅仅是少量的页面与文档了，绝大部分已经迁移到 React 在浏览器端直接渲染了。另外在这个项目成功引入 React 之后，公司内部的很多其他项目也已经开始使用 React。

同时老板也非常 nice，如果新接项目的话，老板都会来找工程师问大概时间预估多少，有没有什么隐含的技术难点，觉得一切都 okay 之后再开工。另一个好处是因为老板都是美国人，所以对工作与生活的平衡很看中。比如临时突然有会，要熬夜到 1 点，这时老板会专门感谢来感谢你熬到这么晚，并在开完会之后马上敦促你睡觉，下次开会时可能还会先来问问时间晚不晚，如果晚的话他们早起一点提前。还有一次周六上午的时候（洛杉矶还是周五晚上），老板发邮件说事情，我这边还在写邮件没写完，老板就发来另一封邮件，说：我突然意识到你那里已经周六了，你别在周六干活了，等周一再说把。

我知道大家可能觉得这是理所当然的，下班时间就应该休息不干活，但是我想如果大家接触过国内的一些客户的话，大家应该知道我在说什么了。

然后现在是大家都不爱看的要求部分

老板让我招人的时候，没有提到经验，学历什么的任何部分，只不停的强调 Culture Fit，那什么是所谓的 Culture Fit 呢？我个人概括可能有如下几点：

首先就是技术上足够的好，你可以喜欢 Ruby，或是 Python，或是 JavaScript，或是其他任何什么语言（比如我最近在关注 ClojureScript），但是一定要技术够好。我现在越来越觉得虽然工程师之间可能喜好不同，但是如果大家都达到一定程度的话，那对项目的技术选型，时间预估，与架构的设计会有惊人的相似。虽然大家有可能觉得我在吹牛，但是我想说我们公司都是这样的工程师，所以大家交流起来非常畅快。
其次就是要喜欢 startup 的文化。通常情况下我们对于一个项目的开发团队只有 2 - 3 个人（不包括设计师与 PM），这样的好处是便于交流，不会有太多沟通成本，坏处就是可能每个人什么事情都要做。比如做后端的虽然不需要精通前端，可能也须要了解一点点，虽然通常情况下可能大家在一个 branch 下分别做前后端就可以了，但是在紧急情况下，可能也许要做后端的修改一下前端的代码。对于前端同学可能也许要同样的需求。
最后，英语一定要好，这个是硬性要求。公司现在只有我一个中国员工，当然我可以讲中文，但是在工作的时候如果我们并不时常在一个项目组工作，那英文还是要用的。但是考虑到公司有许多阿根廷，乌拉圭，菲律宾员工，如果你会讲西班牙语或者菲律宾语更好 :P

如果大家不被我说的烦了还能看到这里的话，欢迎发简历到 rafael@citrusbyte.com 来应聘~

跟大家来分享下我最近在做的项目：webruby

defmacro — Wed, 19 Dec 2012 22:29:40 +0800

大家好~

本人在 RubyChina 潜水有一段时间了，作为一个懒人 + 吃货，通常只是看看贴（惭愧啊），今天决定勤快一把来跟大家分享下我在做的东西：webruby

简单的来说，这是个让 Ruby 跑在浏览器里的项目。跟opal不同的是，webruby 基于 mruby 的实现，并利用emscripten把全 C 的实现编译成 JavaScript 来运行。如果大家有兴趣，这里有很多基于 emscripten 的demo，原始的代码都是 C/C++ 的。

目前为止 webruby 里面只有简单的 build script 和一些辅助的代码。我还在逐渐增加新功能，接下来准备做的一个东西是在 ruby 中直接调用 JavaScript 的函数。如果大家感兴趣的话，这里有一个demo，这是一个跑在浏览器里的 mruby 的 irb。欢迎大家来试用~如果有建议的话也欢迎大家来告诉我~

希望大家玩 Ruby 玩的开心~