将服务器迁移到linode后， jstwind.com 就一直有些问题。因为没有什么人访问也懒得去改了。后来想想，既然没什么人用，也懒得维护，还是把网站关了。
“似水流年”是我做的一个用于编辑时间线的网站，用户可以在上面创建和分享时间线。网站前端用的是Bootstrap，当时Bootstrap刚出来没多久，我也是第一次使用Bootstrap，因此前端部分写的非常烂。为了保证良好的用户体验，时间线的编辑部分采用了AJAX，当时很多时间都花在了这上面。
网站关了，域名还会继续留着，说不定哪天用来做个新“玩具”。
代码托管在Github上，你可以在这里找到： https://github.com/vicalloy/timeline-site
总是感觉雪山美丽且神秘。很早之前走过一次川藏线。那次一路上天气不是太好，雪山只是偶尔露个脸。看雪山本是那趟旅行的一个重要目的，最终却没怎么看到。
这次趁着淡季的机票折扣去了上次旅行中错过的雨崩。虽未看到日照金山让旅程不够完美，但总的来说是一次不错的经历。路上的风景很美，路上遇到的人也都很友好。
Tips：
在飞来寺远眺对面的雪山
日照金山。云很多，山峰始终不肯露脸。
雨崩客栈拍的日照金山。山峰依旧是不肯露脸
在神瀑拍的冰川
只有在月下卡瓦博格才肯露脸。这次旅行的另一个期望是可以看到漂亮的星空。可惜去的时候是满月，皓月当空，只能看到星星点点的星星。
第一次看到这么漂亮的蜥蜴。在此之前我印象中的蜥蜴都是又丑又恶心。
前一段时间和朋友讨论技术的发展趋势。
在这里做个记录，等3年之后再回过头来看看今天的预测。
我认为：
朋友认为：
注：
有一种说法是当你做出选择后就会在潜意识里不自觉的强化自己的选择。
在我看来因为朋友是做Apple平台的Native开发，因此会不自觉的对Web技术有所抵触。
我Web和Native开发都做过，自我感觉会相对公正些。
文档是一个开源项目很重要的一个组成部分，在我看来一个没有文档的开源项目不是一个合格的项目。最近开始给 django-lb-workflow 写文档。
对我来说喜欢写代码多过写文档，特别是在我英文不灵光的情况下。工作流本身就是一个挺复杂的东西，也不知道最终写出来的文档别人能不能看懂。
目前文档只完成了很小的一部分。里面有一个简单的例子，照葫芦画瓢应当也基本能知道怎么使用了。
文档地址： http://django-lb-workflow.rtfd.io/
django-lb-workflow 是我开发的一个工作流组件。目前还有很多工作要做，不过主体功能已基本可以使用了。在我看来还远没有到可以发布的阶段，不过还是很想先宣传一下，也希望能收到一些反馈。
关于为啥要挖这个坑，以及一下想法可以见之前的博客： 挖了一个新坑-Django的工作流引擎
演示项目地址：
http://wf.haoluobo.com/
管理员用户：
用户名：admin 密码：password
登陆后快速切换用户：
http://wf.haoluobo.com/impersonate/search/
http://wf.haoluobo.com/impersonate/stop/
流程配置信息查看：
http://wf.haoluobo.com/admin/lbworkflow/
目前还处于零文档的情况，用法只能先看代码了。
测试用例里是一个请假的演示：
https://github.com/vicalloy/django-lb-workflow/tree/master/lbworkflow/tests/leave
Python和Java相比资源的丰富程度还是要差非常多。就如工作流引擎，Java下商业和开源实现都非常多，Python的就要少很多。因为工作的关系，当初将Python下的开源工作流引擎研究了一遍，始终没有找到合适的解决方案。最终系统中的工作流模块还是自己开发的。
近来决定挖个新坑，开源一个工作流引擎。我希望这是一个认真的开源项目，也希望这个项目能帮忙有相关需求的人解决具体问题。作为一个认真的开源项目，除保证代码质量外，单元测试，文档也都将是必须的。预计这个项目的工作量会有些大，前前后后应当会持续挺长一段时间，希望不要烂尾了。
目前已经开始码代码了，如果感兴趣可以先过去看看： https://github.com/vicalloy/django-lb-workflow
关于这个项目
DPress 是我很早之前用Django写的一个博客系统。这个博客系统更接近于一个Django入门用的演示程序。管理后台直接使用Django的Admin加少量的定制。页面展示部分，Tag和翻页用的开源APP。系统后台部分的代码极少，主要工作都在前端。
系统开发的初期相关依赖库都只指定了所要求的最低版本，随着相关依赖库的升级，系统已经跑不起来了。
今天把项目重新梳理了一遍，让项目重新跑起来。主要做了下面的一些调整：
调整好后并未进行严格的测试，如遇到什么问题，可以直接在GitHub上提交Issue。
看了一下自己在Webfaction的余额还有23$，既然剩余的钱不是太多，倒不如直接迁移到linode。
目前迁移已经全部完成，感觉迁移后访问速度提高不少。
将服务全部重新部署一遍虽不算多麻烦，但作为纯体力劳动多少有些枯燥。之前就在想用Docker来部署自己的服务，这样迁移的时候要方便很多。考虑到主机羸弱的性能，且迁移服务器毕竟是小概率事件也就作罢。
此次迁移顺便给博客加上了HTTPS的支持，证书用的是 Let’s Encrypt 。
一直用的是 WebFaction 的共享主机。WebFaction可能算是共享主机里功能最强大的，Python/Ruby/PHP啥的各类服务都可以支持。WebFaction总体使用还行，但总是有些不是很爽的地方。
今天去 linode 看了一眼，居然出了 5美元/月 的方案。其实很早之前就已经考虑过linode，只是当时 20美元/月 还是感觉有些小贵。一时心动，立马把linode账号注册好，就等什么时候有时间去把服务器迁过去了。
最近看到一篇文章，里面谈通过Java替换之前的Python实现使服务的响应速度得到了很大的提升。同时又看到有公司通过Go替换Scala，取得了不错的效果。
似乎是Go>Java>Python？显然不是。
在项目启动的初期你很难预计到自己的项目最终将长成什么样子，最终能达到多大的规模。你能做的只是给出一个较清晰的中短期规划以及一个较模糊的长期规划。然后思考如何在满足要求的情况下尽快的把东西做出来。毕竟事情不会不完全按照你的预期发展，看上去在完美的构架也不可能一直完美下去。根据需求持续的演进才是正道。
关于性能：
由于需要服务海量用户，因此在提到互联网应用的时候很多人都对高性能有着异常的执着。经常听到有人说XX语言慢，XX框架慢。但实际上脱离了需求和构架单纯谈的语言/框架性能是没有意义的。就如Instagram至今依旧用着以慢著称的Django（注：其实我也挺好奇为啥没有将Django换掉。按照我的理解Django的有点是功能及资源丰富，性能方面确实没啥优势。按说Instagram对Web框架的功能需求应当非常少，换个更轻量高效的似乎会更好些？）。
另外优化的成本实际上也挺高，在早期用户不多的时候对性能的优化或许还不如直接加硬件来的实惠。