• 无聊翻了下书,貌似出现 Song object 的很少,第一次出现的是这个地方:

    虽然看不清楚代码和普通文字是否有字体差异,但我觉得这个地方用 Song object 也算合理和容易理解。因为代码里也只有一个类,Song object 算是个泛指。

  • @jasl Medium 和简书都不支持代码高亮吧。还得贴 gist 链接。除此之外都不错。

  • Emacs 闲谈 (二) 自如的分屏 at 2017年11月21日

    主力用 Neovim + VimR ,最近二次入 Spacemacs 的坑。Spacemacs 的快捷键助记性非常不错,实际上这是它的核心理念之一:Mnemonic,Discoverable,Consistent,Crowd-Configured 。所有快捷键都归类分组,比如 SPC b 是 buffer 相关,SPC w 是 window 相关,下层键位都有视觉上的提示的(which-key) 。

  • Ruby 爬虫框架 at 2017年11月06日

    @tony612 我也想到这个了。Elixir 的并发模型应该是很适合爬虫的场景。

  • 你这只能看出 content download 时间很长,其他的信息都是无意义的,别人没法帮你。你得一步步从外到内追踪一下,看 Nginx log 和 Rails log 哪里慢,缩小范围定位问题。

  • 有一定影响,不过问题大不大,还是取决于人。

    你是否会因为一个软件有一些高层抽象而看不清楚全貌?这取决于软件的复杂程度,也取决于开发者的设计水平和抽象能力。好项目会先给告诉你有哪些大块,等了解深入后再去探索每一块的内部分层。你也许无法看清楚软件的每一块细节,但肯定能看清楚大体由哪些组件组成,以及它们是如何协同运转的。

    前端工程化是同样的道理,想了解每一块的 html 是怎么样的也许把项目跑起来看比追述源码更方便。但要了解一个页面由哪些组件组成其实反而更简单。这时候 50 行的高度组件化的代码比 500 行的 html 模板更容易看懂。

    当然,开发者的抽象能力得基本靠谱。坏的抽象不如没有抽象。

  • 不管喜不喜欢这种方式,建议先尝试一下 React 。对后端分层的理解套用到前端并不是完全适用的。另外,严格来说,在 React 里写的不算 html ,而是用 xml 的方式描述组件嵌套关系,并且最终会编译成 javascript 。

    对后端而言,view 层的最终任务都是渲染出一段 html ,然后就没事了,所以相对简单一些。但对前端而言,渲染出 html 只是开始,后面还会继续处理交互逻辑,更新内部状态,重新渲染 UI 。所以前端的 view 层不仅要处理展现,还要响应一些行为(并不仅仅是底层事件),这两者密不可分,很多时候需要一起修改。但模板和 javascript 分开的项目需要分两个文件,如果是按类型分的项目结构,两个文件还安排在不同的目录下,比如 app/templatesapp/views ,再加上负责纯展现的 css 甚至可能在另一个地方,这在实际开发的时候并不方便。

    这也是前端推崇组件化的原因之一,把本来就该在一起的东西放一起。React 给出的解决方法是 JSX ,抛开成见看还是很方便的。另外可以带来一些额外的好处,比如用 javascript 作为一门完整的语言比受限的模板语法可以做的更多。所有对 javascript 代码组织的技巧都可以用来描述 view 层。这对喜欢这种模式的开发者来说是极大的方便,不过也提高了对人的要求。

  • 如果是备份和还原,pg_dump/pg_restore 够用了。pgAdmin 实在太丑……

  • 心疼自己,Ruby 程序员-1 at 2017年10月26日

    Ruby-1, C+++1 。这貌似加得有点多

  • 如何从 MongoDB 迁移到 MySQL at 2017年10月26日

    @Draveness 对 MySQL 不是很熟,不知道现在有没有原生 uuid 的支持(之前我记得是没有)。相比之下 Postgres 的 uuid 是 binary 的,也支持自动生成。性能没测试过,不过作为官方支持的特性想来也不会很差。