结果就是你所谓的 a

%w[MonPointName Real_CO Real_NO2].map { |key| monitor[key].presence || '-' }

notification 一般是用在什么情况下呢？可以讲讲应用场景么？另外，为什么不考虑按 feature 组织目录结构呢？

建议看看 这篇文章 ，作者做了两个例子讲解多进程和多线程的区别。注意例子里面用 fib 代替 sleep 让 CPU 持续工作。

简单地说，Ruby MRI 因为有 GIL 的限制，导致运行 CPU 密集型任务时没有办法发挥 thread 的优势。但如果是 IO 密集型任务或者调用外部服务的任务，GIL 对 thread 的影响就没那么大。process 不会受 GIL 的影响，但更耗内存。

最终是 Go 赢了啊。

年初决定学 Elixir，最近已经快把 Elixir 的 Getting Started 看完了。本来学这门语言是想看看它的高并发能不能达到高性能的同时避免 Node.js 的 callback hell。接触了一下后发现这门语言还挺有意思的。函数式编程的思维方式跟命令式编程完全不一样，即使单从扩展视野方面考虑，学 Elixir 也值得了。

BTW ElixirConf 2014 上 Dave Thomas 的 Think Different 视频值得一看。

@lgn21st 你这话让我想起以前碰到的时区问题了。Rails 的时区字符串是跟标准不同的，ActiveSupport::TimeZone 文档里提到了这个：

The TimeZone class serves as a wrapper around TZInfo::Timezone instances. It allows us to do the following:

• Limit the set of zones provided by TZInfo to a meaningful subset of 146 zones.
• Retrieve and display zones with a friendlier name (e.g., “Eastern Time (US & Canada)” instead of “America/New_York”)

TZInfo 文档里使用的才是标准的时区，Rails 做了简化处理。不过设置时区时既可以传 Rails 定义的简化版本也可以用 TZInfo 的标准版本。这点还是挺方便的。

www.淫王.org …… 还是只有我邪恶了？

@pishilong 能说下 Wisper 这种思路的应用场景吗？ BTW 看了下你的博客，不过貌似有点问题，每次切换页面都提醒我“请设置正确的 data-thread-key 属性” 。

@lgn21st 谢谢！

@chenge 这是个有意思的东西，不过我不了解，待我看过后再做评价。我引用的文章中，有一篇就提到如果 Service Object 和数据库耦合比较紧，可以采用 repository pattern。那是我下一步准备看的东西。估计那又是一个很长的话题了。

flexbox 在移动设备上就不用考虑兼容性了，浏览器基本都支持。相比其他方法又能减少 dom 数量，实在是布局利器。

You Don't Know JS ，是一个系列，完成度很高，讲的比较细，而且包含比较新的知识。

BTW 这是我去年准备看完的书，可惜后来没时间看了，最后学万恶的 Vimscript 去了……

@hbin 神补刀……

新语言准备学 Elixir，然后深入看看 JavaScript。

iOS 不越狱应该是不能装第三方应用的吧。除非用户自己有开发者账号，并且账号是可以安装到真机的。略嫌麻烦。

@JeskTop 不需要特意学什么，找个项目实际用就肯定可以到的。中途碰到的问题会逼迫人去思考怎么解决。 说起来现在这个时候是学 Ember 比较好的时候，经过几个版本的打磨之后框架已经很稳定了，好些新特性都即将加入。Ember Data 也比较稳定了。作为前端方面下个两年使用的主要工具毫无问题。

@imlcl 那个项目最开始叫 PhoneGap。然后被 Adobe 看中收购了，它仍是一个开源项目，但交给了 Apache 基金会维护了。因为 Adobe 拥有 PhoneGap 的版权，所以 Apache 维护的版本改名叫 Cordova。Adobe 的 PhoneGap 是基于 Cordova 又包了一层，其目的是整合 Adobe 的 PhoneGap Build 服务。Cordova 和 PhoneGap 的关系可以近似理解成 Webkit 和 Safari。

Cordova 和 PhoneGap 的关系很复杂，到现在也不清不楚的。比如：

1. PhoneGap 的文档里的命令一半是 cordova xxx 一半是 phonegap xxx 。
2. 很少见到项目维护者写 Cordova 的博客（他们老是把博客放到 PhoneGap 官网上）。
3. PhoneGap 3.6.3 以前，两者的 CLI 是有点不一致的，而且 PhoneGap 要滞后 Cordova 一些。这点可见 这篇博客 。3.6.3 之后 PhoneGap 在 CLI 设计上完全跟 Cordova 保持一致了，也支持代理命令给 cordova，但偶尔也会碰到只有用 cordova 命令才能解决的问题。

因为诸如此类的蛋疼原因，建议不用 PhoneGap Build 的开发者都直接用 Cordova。事实上很多开源项目都是直接使用 Cordova 的。

跟 speakerdecker 好像…… 我比较喜欢 http://slides.com/，基于 reveal.js 开源项目做的服务。不知道这个封了没。

@HungYuHei 谢谢，希望你们的音乐平台一切顺利！

@paul_king 我能说最初是听汪峰的歌很有感觉才想到看这书的么……我就这种照着兴趣做事的人，不过之后在豆瓣上查了一下，感觉书的视野挺奇特，而且很多人对这本书评价挺高。就把它列在书单里啦。

@fantasticfears 谢谢，也祝你顺利毕业~

@hz_qiuyuanxin 最开始是 08 年 7 月正式工作的，算下来 6 年半。

我待过所有公司都算创业公司，知道创业不易，而且有想法的人很多，实干的挺少。支持一下。

看了你的产品和博客，发现你真挺喜欢 Foundation，专注于前端的话，也可以看看 Foundation for Apps 和 Supersonic。前者是不依赖于 Cordova 的 web app 框架，后者是混合 native 和 web UI 组件的解决方案。不过是否放入个人技术栈就见仁见智了。

@meeasyhappy @fewspider @special @appell @jicheng1014 @chankaward 谢谢你们！结婚了确实是意料之外的事情，也是我觉得今年最重要的收获。

之所以说比较平淡，是因为大部分事情都是时间积累自然完成的，没什么超出预计的部分。

看了评论，如果我理解得没错，你说的“app 后台”是供 mobile app 使用的 API server ?

我觉得，如果是做技术选型，你随便挑一个都可以。或许不同的技术有些差别，但还没大到选错了你要付出不可想象的代价的程度。相比之下，不要在琐碎的问题是浪费时间精力，早点把东西做出来更重要。

如果是为了通过别人的讨论去快速了解每种技术的优劣，就更没必要了。自己没经历过的东西没法感同身受。别人的建议只会让你“知道”，不会让你“懂得” 。相比之下，自己动手试试这种 hard way，有时候才是 easy way。

所以，自己试试吧。

@luckyyang 这点同意，选择困难在于什么都不了解。这种情况下还花时间比来比去没什么意义。先选一个攒经验更有价值。

浮点数精度是所有语言都有的问题。在 Ruby 里面你可以用 Decimal 类。

@lyfi2003 我这段时间也在想 Rails 做 API 方面的未来。从目前来看前景还不好说。抛开语言层面的原因，我觉得最主要和最致命的原因，是 Basecamp 目前用 SJR 用的挺好。短期内他们没理由把 Rails 往 API server 的方向推。

@luckyyang @lyfi2003 最开始的原因是项目同时有 web 和 mobile 版本，所以打算前后端分离，Rails 提供统一的 API，web 和 mobile 都用 Ember 做。但现在我觉得工程角度来讲，前端的归前端更加方便。细节方面过段时间我准备写点东西，目前大概说说，最典型的两个例子：

1. UI component，把 html + css + js 组织在一起，提供一个功能。Rails 处理比较尴尬，如果纯前端渲染 html 就没法重用 helper/partial 等 view 层的代码，如果一半放前端一半放后端就有可能一套逻辑 ruby 和 js 代码各重复一次，只有纯后端渲染可以最大程度上利用 Rails 的功能（partial/helper 等）。这就涉及到后端渲染好 html + js 再推到前端去，才有了 SJR。但 server render page 不管怎么写在页面状态控制上都没与纯前端方便。
2. 传统的 website 和 web app 有根本的理念差别，一个是 stateless 的，服务器不记录状态，处理完请求就忘掉一切，一个是 stateful 的，用数据抽象页面状态（或者说应用程序状态）进行精细控制。服务端渲染有时在涉及到前端页面状态时会无能为力。这个用两种思路分别写过代码的才会有体会。

@yukihiro_matz 我挺看好 Angular 2.0，甚至比 Ember 2.0 更看好。但我觉得 breaking change 就是最大的问题。生产环境的东西不是说句“我们要用最先进的技术就必须抛弃包袱”就能果断升级的。等 2.0 出了，目前用 Angular 1.0 写的项目都会碰到这些问题：

1. 升级？怎么升？重写。
2. 不升级？需要用到一个只有 2.0 支持的新特性怎么办？找第三方库吧。或者升级？
3. 打定主意就用 1.0 了，碰到一个 1.0 的 bug，虽说 1.0 会继续维护 1 年（可能更多）但维护期过了之后碰到框架 bug 怎么办？别人只会在 2.0 上修复。要知道那继续维护的一年就是给人升级用的，不是 LTS（不过照框架火热程度说不定真会有）。
4. 想用一个第三方插件，只支持 2.0 版本，怎么办？

其实我觉得用 Rails 的应该对此深有体会才对，太旧的 Rails 版本 = 某些 bug 不会修复 + 某些新的 gem 不能用。而且升级这种事情，不会因为拖了一年而变得更容易。

Ember 这方面我觉得还算做的挺好的，不管他们的 2.0 plan 和 stability without stagnation 的口号。从我 0.9 到 1.8 的升级经验来看，大部分时候就是改个版本号，有时间就修复下 deprecation 的事情。deprecation 还是我看提示看烦了改的。最近框架升级 HTMLBars，为了不造成大的破坏，core team 的人把 HTMLBars 拆成了 3 个部分放到 3 个版本里渐进升级。我个人比较喜欢这种平滑过渡的方式。

扯多了，说说正题，Ember Data 还没出 1.0，最近 issue 里面有计划 1.0，但……别期待具体什么日期为好。不过可以确定的是不会有大的改动了。而且现在的版本已经比较稳定，可以考虑用在项目中了。但用之前最好了解下它干了什么，不能干什么。

用了一年多了。

我就是在项目中期加测试的。前期开发大半年，为了开发速度完全没有任何测试，纯肉测……

加测试没必要一步到位（也不可能一步到位），你做什么功能，就把相关的测试补上，没改动的地方可以暂时不加。

另外如果新功能涉及到重构原有的老代码，一定要先写测试！测试最好由外而内写，没时间写完全部的，就写外部功能测试，并把各种 edge case 都加上。没 mock 没关系，构造真实数据没关系，测试慢点也没关系。重要的是保证结果正确。测试写完跑通了，然后再重构，分离耦合度高的代码，然后再重构测试代码，逐渐地由一个大的功能测试文件转成一个适当 mock 的功能测试，和若干个模块的单元测试。

老板/客户那边，如果碰到过加一个功能就 break 一些东西的黑历史，应该是很能说通的。否则就把实现功能加测试的时间评估成功能开发时间。至少在我看来测试代码也属于功能的一部分。

Ember+1

现在选择 Angular 可能是最不好的时候。为了轻量级不如 React，为了全面不如 Ember。关键是考虑 2.0 出了之后如何升级的问题。这是任何一个打算维护几年的项目都需要考虑的事情。

Rails 的特点就是它是从实际项目中抽出来的，Rails 的发展方向也很大程度上取决于 Basecamp 用什么。虽然也有很多其他选择，但他们都只会以第三方 gem 的形式存在。Basecamp 团队一天不考虑前端 MVC，Rails 就不会默认集成。

异步代码不好维护，这点目前似乎还没什么解法，ES6 时代 Promise 也只解决了部分问题。Generator 可以模拟写同步代码但有点麻烦。除非 ES7 的 async/await 被广泛支持（貌似这个特性也是 C# 最开始搞起来的？），那真不知道等到哪年去了。