• 结果就是你所谓的 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 的影响,但更耗内存。

  • 编程语言拔河比赛 at 2015年02月05日

    最终是 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 …… 还是只有我邪恶了?

  • Service Object 整理和小结 at 2015年01月23日

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

  • Service Object 整理和小结 at 2015年01月22日

    @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 AppsSupersonic。前者是不依赖于 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 就不会默认集成。

  • Node.js 2014 这一年 at 2014年12月22日

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