有時樹會倒下，某片天頃刻明亮
去年5月份的时候日淘了一台 KPW，但如今回想起来去年到现在好像也没读完多少书。看了不少福尔摩斯，一些胡适的书，还有漫画——进击的巨人。小说还看了动物农场、未央歌。最近还看了一本结构化拖延法。实体书好像一本也没有读完，看来看了那么些拖延症的书我的拖延症还是一点也没有缓解，不过心态上倒是变得无所谓了，也算是这些书的正面作用吧。
去年看了多少书没有作记录，现在要回想起来很困难，一直没有可以很方便记录的东西真是很可惜。
我读书还有个怪癖，一些书总不舍得读完，读到最后一章就得歇一歇便不再读下去了，后来又彻底忘了，结果一年两年都没再拿起来，现在想到的就有中有百年孤独，未央歌，禅与摩托车维修艺术，如果能有个东西来提醒就好了。
去年竟然一本与 CS 相关的书都没有，那今年要好好补回来，还是要继续打牢计算机基础，深入理解计算机系统已经蒙尘多年了，不好意思让它继续躺在书架了。如果今年要读一本 CS 的书的话，那就是它了。
这篇文章还有上一篇，文章写得太长看起来太累，还是一分为二较好。这篇就直接说说用 ruhoh 来搭建自己的笔记系统（同文中 notes）的不足和一些解决的想法。去年还在这里大谈静态生成页面的种种好处，如今想来未免太过理想。
Ruhoh 提供了完善的命令行接口，实际使用中会发现，操作文档是在 Terminal，编辑文档是在 Emacs，预览文档是在 Chrome，经常需要不断地切换上下文，悲催的是这三个软件都是操作系统般的存在，特别是 Chrome 很容易走神。一旦切换后走神，就会走得很远，短时间内都回不来。这样带来了很大的上下文切换成本，要保持专注就得尽量把时间控制在编辑器内(全命令行自然更少干扰，不过全命令行操作的理想早已离我远去了)。首先要简化操作文档的命令行，个人使用 ruhoh 这个命名空间就可以省略，之前就做个一次简化，但是 notes 方面的操作命令还是很不方便需要进一步修改。至于预览切换方面，得益于 Markdown 的可读性，更多问题像是强迫症，一点点改动就要切换去看效果了，必须暗示自己只有格式方面的修改才需要去看预览。把命令行接口整合进 Emacs 确实是可行的，但是作为一个这么美好的愿景，当前还是想想就好。
git 是一个非常流行的版本控制工具，功能强大适用广泛。但有时太强大也不是好事，notes 最需要的还是同步功能，也就是说 git 只是用来构建一个分布式仓库，版本控制反而不是很重要，但现在做一次同步太过繁琐（add、commit、push），每次还都必须写上 comment，而且提交到服务器后都会自动编译发布，一次同步要花费几十秒十分恼人。
# time git push
0.02s user 0.02s system 0% cpu 21.367 total
无奈 cdnjs 被墙，只能选用国内的静态文件加速服务，可惜都不理想。
幸好发现了 staticfile.org，他引用了 cdnjs 的仓库，同时也拥有自己的国内仓库，库度数量比较多，用了七牛的服务，速度应该可以。
考虑写个 Ruby 的工具方便 ruhoh 使用。
Google I/O 2013 放出的新 Android IDE，基于 IntelliJ IDEA，现在还只是早期预览版本。断断续续用了几天后，得出一个结论，强烈不建议用来作正式开发工具。当然，这个其实看它的版本名就知道。一方面是不完善，从建立一个新项目到打包运行，遇到问题不断。另一方面，也是最不可接受的一点，就是打包速度慢。一台 E5200 的 Win7，一次 clean 要10秒以上，然后 compileDebug 要30秒。一台 i5-3550 同时配备有固态硬盘的 Hackintosh， clean 一次仍要5秒，compileDebug 要15秒。而且花在 checkSource 上的时间很多。做一个小改动再重新运行也要等很久，这一点严重拖慢开发效率（有这个空隙总会不自觉地去刷刷 reader，从而导致更多的拖延）。目前没有方法，一方面可能是 groovy 、gradle 本身的局限，一方面是现在这个 New Build System 也还不完善，现在版本才是0.3，还是有很大的改进空间的。另外，用 daemon 模式也可以加速。
不过，Android Studio 还是很让人期待的，特别是看过 "What's new in Android Developer Tools" 里面介绍的那些很酷的特性。终于可以摆脱 Eclipse 的一些顽疾和那老气沉沉的 UI 了（我是 Swing 爱好者，没做 Android 之前 Netbeans 才是我的日常IDE，可惜 ADT 没 Netbeans 的份）。摆脱了 Eclipse 后，Android IDE 才能有更大发挥，比如说新 Layout Design ，不必再望 Interface Builder 空叹了。而 JetBrains 也是声名在外，上次它在国内做活动的时候，差点买了 AppCode 和 RubyMine。至于 IntelliJ IDEA 我算是久仰其名，未见其面吧，其实也试用过，不过当时是非 Android 官方支持的，不敢随便就切换过去。最值得一提的是，从 Eclipse 切换 到 IntelliJ IDEA 的成本其实不高，有一些概念的混淆。但都有 Emacs Keymap，还有最蛋疼的一点，现在 Android Studio 还只是个「编辑器」，最容易导致问题的打包、依赖问题，现在做到 New Build System 了，目前还没整合进 Android Studio。所以打包依赖问题，不但要在 IDE 里配置一遍，还要自己写上一遍 build.gradle。
以加入 ActionBarSherlock 为例，一开始不了解，尝试了多种方法，四处碰壁。用配置 IDE 的方法只能解决编码时的引用问题，最后只有 @froger_mcs 的方法是可成功打包运行的。才发现要用 Android Studio 了解下 gradle 是必须的（在这之前我还没听说过 gradle）看一下 Gradle User Guide，最少看完第六章，就有点概念了。后来再看了 I/O 的讲座 "The New Android SDK Build System"，豁然开朗。才知道原来 Android 推出了个新的基于 gradle 的构建系统。这里是详细的文档。还有，New Android Build System 需要 gradle 1.6， brew 只能下载到 1.5。
IntelliJ IDEA 默认的 Emacs Keymap 比 Eclipse 默认的好用，虽然还比不上 Emacs+，比如c-x c-b 不好用，但胜在足够稳定，贴合系统。不过在 Mac 下就没那么好了，option 键仍与 meta 键冲突（Aquamacs 中不会有这个问题），最后只能用一个新的 keyboard layout 屏蔽掉 option 输入字符快捷键（option 配合字母键输入特殊字符，我怎么觉得是个不怎么实用的功能），才能作为 meta 键使用。具体操作按照 @dan 的方法实现。但是这个 layout 不能在 Aquamacs 中输入字符，来回切换也麻烦。
本来只是想总结一下年前一直折腾的静态博客系统，恰好碰到了谷歌打算关闭 reader，一闪念便打下了这个题目，毕竟突如其来的感觉就像敲响博客的丧钟，难免抒怀。
现在最依赖 Google Reader 的就是上下班在公车上的那两个小时，配合 gReader 的离线功能在手机上阅读十分舒服。我订阅一些 IT 资讯，其实我也不是特别关心，但他会成为我的一些谈资，毕竟在别人眼中我的工作就应该了解这些资讯，订阅在 Reader 可以强迫我阅读。另外还有一些二手交易论坛，之前想收电子产品，持续一段时间关注二手信息，可以帮你买到比较靠谱的东西，不过不关心的时候还得全部标记为已读，幸好 gReader 有过滤功能。我发觉论坛的 RSS 配合 Reader 的搜索非常实用。
剩下的就是我真正关心的主题，这些内容都是随着时间慢慢沉淀下来的，现在有些 apps 通过学习你的阅读习惯来推送内容。我有点抵触这样的形式，平常浏览网页，正文之外也充满推荐链接，强迫你去接受那些信息，你总会被其中某些吸引，不自觉的点来点去。如一个吞噬时间的黑洞。个性化推荐就是更小范围内的同样模式。
相对比内容，我其实更对人也很感兴趣。我订阅了不少独立博客，从他们技术文章之外透露出来的只言片语，去了解他们的生活，对自己也是一种勉励和指导。技术上的问题则越来越被动了，大多都是遇到问题才会去解决问题，搜索引擎实在是太强大了，基本都能找到解决方法，这个也是博客的一种作用。同时也会发现自己所做的事涉及的问题实在是太多太杂但又流于表面，，所以相比折腾一个具体的问题，我会更偏向于用一段持续的时间去系统的了解一个主题，站在更高的维度才能看到更清楚，而且不仅限于计算机。当然这样是不适合于在这个快节奏的市场生存的，至少目前看来很吃亏。在爱好与利益之间我也摇摆不定。毕竟现在生活一片空白，一点钱换来一些生活的基础对我来说还是很重要的。这与以前所认为的注重基础又不一样，以前遇到问题就习惯了去深挖他，现在会让自己避免深陷这样的泥潭。
此时此刻，道不出心境如何。纳兰一首词倒可算作一种隐晦的写照
谁翻乐府凄凉曲，风也萧萧，雨也萧萧。瘦尽灯花又一宵。
不知何事萦怀抱，醒也无聊，醉也无聊，梦也何曾到谢桥。
为文章生成目录，即所谓的 TOC（Table of Contents）， 可以在前台或后台实现。显然在前台，即用 javascript 实时生成目录，更简单明了，而且 @brianclapper 早已提供一个在 Octopress 上实现的方法，在 ruhoh 上可以用 widgets 实现，但是要实现根据 page 参数来开启关闭还是比较麻烦，因为现在 ruhoh 的 widgets 不能读取到 page 的数据，不过这也只是小问题，不是我选择后台实现的原因。
为何要在后台生成目录？首先，我觉得目录应该和正文一样是属于文章的一部，所以我不能接受需要一个 javascript 解析器才能把文章显示完整。另外，我一开始是希望能有很高的灵活性，支持三种开启目录的模式，分别是自动，强制开启，强制关闭，后来觉得只有标题超过一定的数量才生成目录，也就是自动这一个模式就已足够，最重要的是这一部分的代码之前我已经实现好了。还有，用插件实现编译一次搞定，不用每次访问都浪费计算资源去生成目录，这也算是优点之一吧。
一开始没想那么多，直接用 Markdown Converter 来生成目录，把目录代码直接加入到 Markdown 转换后的最终文档上，但是这种做法有很大的缺陷，目录不能与文章内容分离出来放在页面的其他地方，毫无灵活性可言。理想中的做法，是可以用在模板中指定目录的位置，通过 partial 来定制 toc 的模板，后来做了笔记系统需要两个不同风格的目录，这个问题更不能回避了。
为了通过 mustache 标签来载入 TOC，就得牺牲一下效率了，因为 ruhoh 的编译流程所限，不能做到将 Converter 工作后的产生的数据，为 Mustache 解析器所用。这样表达好像不清楚，换句话说因为目录的数据是需要 Markdown Converter 来生成，就是说将 markdown 转换为 html 后，才知道目录是长什么样的，而这个过程是在 mustache 的 render 方法里，所以 mustache 无法获取到 Converter 里的数据，于是当模板需要目录的时候，只能再去解析一遍 Markdown 文件，也是说一个 Markdown 文件必须经过两次解析才能生成目标页面，不过目前效率还远远不是问题。
又在京东败了300元的书，当然了实付一半。如今每每买书内心必感愧疚，究其原因，正如豆瓣某读书小组之名：买书如山倒，读书如抽丝。就今年而言，大大小小分了几次，买了50来本书，见此豆列。虽说不多，但也不少。少年时代的书架早已支撑不了这些书，只能任凭堆积在房间角落。
如今2012已接近终点，那么这些书到底看了多少 ？其实若以翻阅论，每本书大抵也都翻过。若算从头到尾看完，则便只有寥寥数本，而且都是散文，随笔，传记，看我豆列便知里面专业性的大部头不少，这些书大多只翻翻序言，或开头几页便难以再续，每次想看书总是在书堆里随手一拿，翻个过瘾，放下后不知下次拿起是何时，可惜没有靖節先生不求甚解的淡泊，最后只能不断悔恨。我的时间呈碎片化，而且每日看书的时间很少，上班便要占据掉一天中的黄金12个小时，其中2个小时禁锢在颠簸摇晃的公车上，书勉强可看，但也只能是在我3.7寸手机上看电子书。回家后又要投入新一轮的折腾，看书的时间也只能挤出来了，如此看来看去只看完随笔散文就不足为怪了，根本没有时间系统地看一本书嘛，那些需要几个月甚至几年持续投入才能看完的书也就只能在角落里蒙尘了。
再者就是读书笔记引起的拖延问题了。一本书看过后，时常觉得就像过眼云烟，看的时候颇有触动，但看完后想写什么竟什么也写不出来，自比猪八戒吃人参果，尝不出滋味，皆是快、浅、散所致。于是，便想每本书都留下个记录，以读书笔记组织之。但是个人对工具要求太叼，工具未成形时，无法下笔，便连读书也拖累了。如今基于 ruhoh 写了个笔记系统，接近完成，用起来颇为顺手，希望此问题再也不会威胁到读书。
今日将书整理了一番，按功能分可分为兴趣类和技术类两类，兴趣类有诸家散文随笔杂文，增长见闻和拓宽知识面的各类专著。技术类则为数学计算机，技术类书大抵厚如砖头，用层次较难区分，只能以薄厚分，薄的甚少，倍显珍贵，技术求精，书每次只能读一本，包括大量电子书中的经典。从薄的开始逐个击破最是容易。而以兴趣为目的书大可如从前随意读之，不过以后每本书都要在此留下痕迹。
这里也许会成为我第一篇ruhoh的博客，先罗列一下常用的命令吧。
rackup -p 9292 # 启动 web 服务在 9292 端口
ruhoh page about.md #创建一个页面，支持子目录
ruhoh post "The Greatest Post Ever" #通过标题创建文章，将会生成 the-greatest-post-ever.md
ruhoh draft #快速建立一个草稿，生成untitled-draft-1.md
ruhoh titleize #快速为草稿文件命名