接近一年没有更新过这个blog了，时间过得真快，也是有史以来荒废得最久的时间。
虽然没有写文章，在上半年还是断断续续的花了点时间升级了blog系统。原本用的是Octopress，但Octopress的3.0版本开发基本上处于废弃状态，想换回正宗的Jekyll，Jekyll 3.0的发布也是从2004年底一直等到2005年底，试用过测试版本很多不兼容问题。从去年以来，工作重点切换到node.js平台，于是自己的项目也选择node.js好了，最后选用了Hexo作为blog系统。Hexo还有个优点就是render速度比基于Ruby的Jekyll/Octopress快了起码一个数量级，我这里三百多篇文章，以前启动预览得大概一分钟，现在几秒钟。
装了一台黑苹果在公司里用，幸福指数大大提升。
硬件选型参考tonymacx86的CustoMac Mini)，算下来主机不足4000元。要保证安装顺利、功能正常和稳定，最重要的是选择推荐的主板型号，可以找到详细的安装配置教程，各种可能的坑都有人给出解决方案了。安装过程一律依据tonymacx86的guide进行，没有任何问题。SSD和机械硬盘组成fusion drive，在较低的成本上达到不错的性能和容量的兼顾。唯一问题是用了fusion driver之后hibernate就不能用了，因为Clover认不出fusion driver，找不到上面的sleep image。
以下内容均针对 El Capitan。
因为训练得少，一直担心跑全程会很辛苦，预计430完成就不错了。
周六寒风冷雨，幸好周日放晴了，早上起床气温12℃，穿了长袖。存包时感觉不冷，就没有套雨衣。今天气温很适宜跑步，既没有冷得发抖，也没有很热。
起跑很保守，慢慢跑，想着按430的话全程也就是6分配速。跑了两三公里自然而然的快起来，渐渐进入6分配速以内。
10km 感觉自己状态还好，一小时内完成了；一直心率都保持在150以下，心中欣喜；下了猎德桥后16km起左膝盖有点不适，受膝痛影响精神也不那么轻松了，后面过两次隧道下坡时小心翼翼。
20km 发现自己居然比2小时少了七八分钟，按照一小时十公里预算，又赚了好些时间。渐渐膝盖感觉也不明显了。
24km 左右吃能量胶，过25km 比预计早了10分钟，没有见到小云和小春天，拿了李莹一根香蕉。25km 补给点吃盐丸，想把粉末倒水杯里，发现很难倒出来，整颗扔水里也融不开，有点狼狈，还浪费了一分钟时间。
28km 起进入滨江路老城区路段，开始跑得不轻松了，这时候我就喜欢一个人孤独的靠着马路中线跑，不管路边加油的观众。左小腿有点发硬的感觉，每个站都淋湿小腿裤子，风干时就很冰冷。
33km 过人民桥，慢慢跑上去，盘算着完赛时间是多少，好像跑回以前最好的412是有可能的。剩下不足10km，感觉能量不是问题，但想想还是再吃一个能量胶，也吃一颗盐丸。
在沿江路跑，看着34km，35km 过去，觉得剩下路程不多了，想如果后面我能维持6分配速，就可以进410，但状态也确实不再轻松，最担心是小腿会抽筋。
后面各跑群的补给点很多，一会就见到一个，过了江湾，一会就到海印。想着去年在这里见到小春天，当时已经抽筋了好久。没见到她们，想她们是不是又错过时间。
数着一公里又一公里，接近广州大桥，终于40km 啦，剩下没多远，就算抽筋怎么也可以熬过去，何况我配速都还能维持在5:45左右。突然听到有人喊艳阳天，看到了李莹和小云，兴奋的举起手跑过去让她们拍照，但想着最后2km 要一鼓作气完成，就没有停留，小春天在后面大喊回来合影。没有跟小云合影真辜负了她这么费心为我准备加油。
从二沙岛过桥进入海心沙，41km，居然海心沙那段路就有一公里，不过都能看到前面的路拐个弯就到了，感觉也不长。最后一段告诉自己没必要加速，根本差不了几秒钟。后面的摄影师真对，一会一个，都没有什么其他姿势可以做了，表情是很轻松的。
最后一个拐弯后，一大堆美女啦啦队热情的喊，从她们手上接过一个气球，跑完最后一段。拿着气球这个点子不错，拍照效果应该好吧。冲线后，一按手表，居然是4:02:02，完全没有想到居然能够 PB 还快了10分钟。官方净成绩是4:01:53.
这次还是首次全马没有上厕所。前十几公里是有一点想尿的，厕所要排队想后面的人少，但跑到后边就没有尿意了，省了一分钟 :)
尽管气温不高，从第一个海绵站（7.5km）开始就拿海绵降温，开始是淋头部。到小腿出现发硬，怕抽筋，就给小腿和大腿也淋水。大概30km 处拿了半瓶水来淋小腿，弄得鞋袜都湿了，幸好也没有带来什么影响。后来就不敢直接淋，用手捧水在腿上抹。
一切都起源于 flyisland 转的这篇文章：从零开始，给自己设计一台3D打印机，大量的图文细节和制作过程描述吸引了我，门槛似乎也不怎么高，于是产生了做一台的想法。看了 Thingivers 这个网站，更是发现了新的世界，打消了“有3d打印机不知道用来做什么”的疑虑，对喜欢搞制作的人来说3d打印机太有用了。
于是开始网上查找资料，了解相关信息。一开始的想法是做像那篇文章中的 XYZ 结构，大一点的打印体积（开始都是贪心的），看了 RepRap 论坛发现关于 delta 结构的讨论很热门，了解多一些后知道 delta 结构打印机的打印速度快，成本比较低，制作也不复杂，于是锁定了 Kossel 机型，心想先做一个出来练练手，小一点也够用了，以后真玩起来有需要再做大机器。
接下来在寻找国内的资源的时候知道了 K800 打印机，这是国内爱好者 maximscy 在 Kossel Mini 基础上改进的以降低成本为目标的机型，原本 K800 的意思就是人民币800元可以做出来的 Kossel，但实际上基本上也还是要上千元。
K800 应该说对于推动3D打印机在国内普及有不少功劳，淘宝上有不少卖套件的。K800 降低了成本，但是毕竟还是以牺牲一点精度为代价，因此卖家也有不少“升级套餐”，例如将打印制作的元件换成铝合金元件，滑轮换回直线导轨等等。我对成本还不算很敏感，想做出来的机器质素好一点，但看下来发现套件的价格水分又太大了，而且配置不一定跟自己要求一致，于是决定自己采购元件。
在软件企业中开发产品/项目，做技术选型时经常会听到的一个说法是：选择开源自由软件，会不会质量不够有保障？还是我们自己做好一些。
自由软件遵循的是完全的市场经济，面对的是残酷的竞争。如果项目做得不好，满足不了需求，就会无人问津而最终被废弃掉，使用者才不心痛已经有多少人力物力已经投入到这个项目中。项目设计太差，代码太烂，同样也吸引不了贡献者，导致原有贡献者的离开或者另起炉灶。对比的看，软件企业中开发的软件项目就如受着国家保护的国企，虽然也面临外部竞争，但在内部怎么也还是自家孩子，再烂也很难让大家承认它的失败，要放弃更加是艰难的决定，往往意味影响好些人的仕途。因此，你会看到很多企业开发的软件项目很烂，因为它们本来应该死掉的，但被强制维持着生命。
从软件开发者的平均水平这个角度来看，自由软件项目也优于企业开发的软件项目。当然，这里谈的自由软件项目是指有一组稳定贡献者有明确蓝图的，这样才能与企业项目相比较，个人练手的项目不算在内。试想一下，在一个软件企业里面，水平足矣为自由软件提交代码的开发者占了多少比例？但是那些尚不能为自由软件项目提交代码的开发者，在企业里面可是天天写代码的，甚至大部分代码是出自他们之手。
泛泛的说，在某个领域，如果可选的自由软件有不少，那么排名前列的项目，质量基本上不需要太过担心。
上面是我对自由软件质量担忧的看法，但这当然不代表就可以随意选择使用自由软件，技术选型中需要评估的东西还有很多。
上次提到用 HTML 做的 presentation，是在公司里做的关于持续学习的一个分享。
注意：看绿色导航箭头，是可以向下翻页的。有些背景图片可能需要翻墙才能看到，否则会变成空白。
最近要做一个分享，需要做个有趣一些的 slides。工作上的 slides 都是用 PowerPoints 来做的，但 ppt 放网上分享不方便，而且也不 cool，因此琢磨着弄个什么来玩玩。开始打算想用 markdown 来写，一方面是习惯了，另外也够简便。几年前就曾试过用 markdown 写一个简单的 slides。
上网搜索一圈，发现这种打着 “HTML presentation framework” 名号的工具还真多，近些年来 HTML5、CSS、JavaScript 的广泛应用，这些基于 HTML 的演示可以做得很炫，让人耳目一新，例如这个 50 Years of the Rolling Stones 和 Mass of Planets (要允许网页使用摄像头)。
比较了一下，感觉 reveal.js 不错，也很受欢迎。后来又发现另外一个后起之秀 bespoke.js，影响力不够 reveal.js 大，但它的插件式设计更胜一筹。对了，这些工具基本上都是用 JavaScript/Node.js 等一套工具链的，前端相关的技术 js 独霸天下了。
先试了一下 bespoke.js。看到 reveal.js 能使用 Leap Motion Controller 来手势控制，演示起来会比较出彩，正好同事有一个 leap motion，可以借来玩，但是却找不到 bespoke.js 支持 leap motion 的插件。查了一下，原来 leap 有 JavaScript API，在浏览器里面能够通过事件监听获得双手各个手指的位置和手势动作的信息，API 暴露出来的已经是处理后的双手模型了，应用用起来相当方便。于是就简单的 port 了一个 bespoke-leapmotion 插件出来。但说实在的，leap motion 这东西还是中看不中用，用手势切换页面根本就不如手指头按个按键快捷和省力，手势的辨别也不够精准（这方面应用在数据处理上是可以下些功夫的）。
更新一致性问题发生在多个实体同时更新同一数据，出现写冲突。并发环境下维护数据一致性所用的方式通常分为悲观和乐观两种。
悲观方式就是避免发生冲突，例如采用 write lock，根本不让写操作同时发生。排在后面的操作者需要检查最新数据来判断是否继续更新。
乐观方式是先让冲突发生，然后检测冲突并处理。例如用条件更新，仅当数据库中的数据当前值与之前读出的值相同时才对此执行更新操作。另一种方法是记录不同版本的数据，当不同版本数据发生冲突时需要采取某种策略去合并（merge）数据。
在存在数据复制的分布式系统中，需要保证不同节点的更新操作顺序是保持一致的，否则无法解决数据一致性。但分布式系统中顺序一致性往往难以保障，常用的方法是将某份数据的所有写入操作都交由一个节点来完成（数据分片机制）。
花了几天空余时间，看完了阿西莫夫的科幻小说《永恒的终结》。
在我的印象中，阿西莫夫的科幻小说是以逻辑严谨为特征的。他的好多作品都是设定在未来背景的侦探推理小说。小学时代读他的“机器人系列”，还以为机器人三大定律真的是生产机器人都需要固化的逻辑。总之，感觉他的书基本上都是烧脑之作，读起来要细细思考琢磨的。
Swagger 是被广泛使用的用于 REST API 描述和文档化的框架。它制定了一个用于描述 REST API 的规范，提供了一组工具用于编辑 API 描述文件、生成测试客户端、生成文档等等。Swagger UI 是其中的用于生成文档的工具。
Jekyll 是深受程序员喜爱的静态网站生成工具，通常用来做 blog 站点，我们的工作团队也用它来做内部的技术文档库。
在 Jekyll 里描述我们产品的 REST API，编辑排版是比较繁琐的事情，不同的 API 描述也没有统一的风格，因此考虑到引入 Swagger 来规范化 API 定义。
为此，写了一个简单的 Jekyll 插件，只要像下面例子那样在 markdown 中简单的插入 swagger tag，指定 API 描述文件，相应的 API 文档就会由 Swagger UI 生成并嵌入在页面中。
1 | {% swagger /api/my-api.json %} |