徒步雨崩

总是感觉雪山美丽且神秘。很早之前走过一次川藏线。那次一路上天气不是太好，雪山只是偶尔露个脸。看雪山本是那趟旅行的一个重要目的，最终却没怎么看到。
这次趁着淡季的机票折扣去了上次旅行中错过的雨崩。虽未看到日照金山让旅程不够完美，但总的来说是一次不错的经历。路上的风景很美，路上遇到的人也都很友好。

Tips：

  • 飞来石观景台￥60的门票不是很值得花，飞来寺客栈的顶楼就是最好的观景台。
  • 网上一些人气比较高的客栈，可能由于人气比较旺打理不过来，反而不如其他的客栈值得入住。飞来寺入住的“吉祥客栈”只要￥40一个人，景观非常棒。开窗即可看到连绵的雪山，楼顶更是极佳的观景台。
  • 在上雨崩入住的“小明的暖屋”。新开的客栈，房间很干净，老板娘很热情。房间的景观很好，开窗即可看到雪山。他们家还有粘人的漂亮喵喵，见人就过来讨吃的。
  • 如果不怕累，一大早进雨崩还是来得及去神瀑的。夏季的时候8:30才天黑，其他季节请注意安排好时间。下雨崩到上雨崩有近一个小时的路程，如果打算进雨崩的当天去神瀑，最好还是住下雨崩。


在飞来寺远眺对面的雪山


日照金山。云很多，山峰始终不肯露脸。


雨崩客栈拍的日照金山。山峰依旧是不肯露脸


在神瀑拍的冰川


只有在月下卡瓦博格才肯露脸。这次旅行的另一个期望是可以看到漂亮的星空。可惜去的时候是满月，皓月当空，只能看到星星点点的星星。


第一次看到这么漂亮的蜥蜴。在此之前我印象中的蜥蜴都是又丑又恶心。

Mark-关于技术发展趋势

前一段时间和朋友讨论技术的发展趋势。
在这里做个记录，等3年之后再回过头来看看今天的预测。

我认为：

  • 近几年JS(HTML5)的发展速度很快。虽然JS有各种天生的缺陷，但JS在进化，在特定的场合中JS的某些缺陷问题不是太大。
  • JS或许并不是一个完全体，但JS是目前的各种开发技术中很有潜力的一个（特指UI部分）。至少目前还未看到比JS在UI方面更有潜力的东西出现，在今后几年会不会有也很难说。
  • 今后JS的应用还会持续走高。采用存JS开发或是混合应用（或类似React Native的技术）会越来越多，很占领很大一部分的开发市场。
  • 不太看好JS在服务端的发展，至少我不是很喜欢写Node.js。

朋友认为：

  • JS有很多天生缺陷，成不了主流
    • 注：我个人觉得目前JS已经很主流了。
  • 巨头间的博弈。一旦跨平台，平台独占的优势将不再明显。处于优势地位的巨头不欢迎跨平台技术。
    • 注：iOS和Android已不存在谁是绝对优势。且即使是Apple平台也有桌面和移动端的跨平台需求。或许巨头们不是很心甘情愿的跨平台，但也很难阻止。

注：

有一种说法是当你做出选择后就会在潜意识里不自觉的强化自己的选择。
在我看来因为朋友是做Apple平台的Native开发，因此会不自觉的对Web技术有所抵触。
我Web和Native开发都做过，自我感觉会相对公正些。

开始写lbworkflow的文档

文档是一个开源项目很重要的一个组成部分，在我看来一个没有文档的开源项目不是一个合格的项目。最近开始给 django-lb-workflow 写文档。

对我来说喜欢写代码多过写文档，特别是在我英文不灵光的情况下。工作流本身就是一个挺复杂的东西，也不知道最终写出来的文档别人能不能看懂。

目前文档只完成了很小的一部分。里面有一个简单的例子，照葫芦画瓢应当也基本能知道怎么使用了。
文档地址： http://django-lb-workflow.rtfd.io/

lbworkflow预览版

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

挖了一个新坑-Django的工作流引擎

Python和Java相比资源的丰富程度还是要差非常多。就如工作流引擎，Java下商业和开源实现都非常多，Python的就要少很多。因为工作的关系，当初将Python下的开源工作流引擎研究了一遍，始终没有找到合适的解决方案。最终系统中的工作流模块还是自己开发的。

近来决定挖个新坑，开源一个工作流引擎。我希望这是一个认真的开源项目，也希望这个项目能帮忙有相关需求的人解决具体问题。作为一个认真的开源项目，除保证代码质量外，单元测试，文档也都将是必须的。预计这个项目的工作量会有些大，前前后后应当会持续挺长一段时间，希望不要烂尾了。

目前已经开始码代码了，如果感兴趣可以先过去看看： https://github.com/vicalloy/django-lb-workflow

关于这个项目

  • 基于Django且完全不考虑移植到其他框架。
    • 如果考虑移植性系统要复杂很多，也很难保证易用性。
  • 采用半可配置方案以平衡开发及使用的便利性。（注：“半可配置”是我自己取的名字）
    • 数据模型，表单布局，数据校验规则，特殊处理采用编码方式实现。
      • 这部分如要做灵活可配置，配置工具的开发会非常复杂，且配置项非常多，在具体配置的时候也会很麻烦。
      • 这部分功能在开发后改动的情况较少，使用代码实现要灵活的多。
    • 流程节点，审批人，流转关系采用配置方式实现。在管理后台直接通过管理界面进行配置。
      • 根据公司规定，组织结构的变更流程的流转规则，审批人的变动较为频繁，使用代码实现很不灵活，也不方便。
      • 流程节点及节点间的流转这对各类型的流程来说操作都是比较一致的，比较容易采用配置的方式实现。
      • 使用配置实现可以方面的自动画出流程图。
    • 代码生成器
      • 提供代码生成器，只需要完成数据模型的编码，代码生成器会自动生成流程的提交/查看/报表等所有框架代码。

DPress更新Django 1.10支持

DPress 是我很早之前用Django写的一个博客系统。这个博客系统更接近于一个Django入门用的演示程序。管理后台直接使用Django的Admin加少量的定制。页面展示部分，Tag和翻页用的开源APP。系统后台部分的代码极少，主要工作都在前端。
系统开发的初期相关依赖库都只指定了所要求的最低版本，随着相关依赖库的升级，系统已经跑不起来了。
今天把项目重新梳理了一遍，让项目重新跑起来。主要做了下面的一些调整：

  • Django升级到1.10。
  • 原翻页APP似乎已经不再维护，进行了替换。
  • Markdown编辑组件直接使用现成的APP，进一步简化程序代码。
  • 相关的依赖库都明确指定了版本，以免再出现因相关库的升级导致系统跑不起来的情况。
  • 对项目的目录结构做了调整。除默认主题外，其他主题都以APP方式进行安装。
  • 很久没有用过SAE，不知道之前的SAE支持代码还能不能用，因此直接去掉了SAE相关支持。

调整好后并未进行严格的测试，如遇到什么问题，可以直接在GitHub上提交Issue。

迁移到linode

看了一下自己在Webfaction的余额还有23$，既然剩余的钱不是太多，倒不如直接迁移到linode。
目前迁移已经全部完成，感觉迁移后访问速度提高不少。

将服务全部重新部署一遍虽不算多麻烦，但作为纯体力劳动多少有些枯燥。之前就在想用Docker来部署自己的服务，这样迁移的时候要方便很多。考虑到主机羸弱的性能，且迁移服务器毕竟是小概率事件也就作罢。

此次迁移顺便给博客加上了HTTPS的支持，证书用的是 Let’s Encrypt 。

计划将服务器迁移到linode

一直用的是 WebFaction 的共享主机。WebFaction可能算是共享主机里功能最强大的，Python/Ruby/PHP啥的各类服务都可以支持。WebFaction总体使用还行，但总是有些不是很爽的地方。

  • 访问速度非常的慢。
  • 相比VPS自由度还是要低不少。前一段时间想给Blog加上HTTPS的支持，不过由于共享主机的限制，非常麻烦。

今天去 linode 看了一眼，居然出了 5美元/月 的方案。其实很早之前就已经考虑过linode，只是当时 20美元/月 还是感觉有些小贵。一时心动，立马把linode账号注册好，就等什么时候有时间去把服务器迁过去了。

最好的技术构架

最近看到一篇文章，里面谈通过Java替换之前的Python实现使服务的响应速度得到了很大的提升。同时又看到有公司通过Go替换Scala，取得了不错的效果。

似乎是Go>Java>Python？显然不是。

在项目启动的初期你很难预计到自己的项目最终将长成什么样子，最终能达到多大的规模。你能做的只是给出一个较清晰的中短期规划以及一个较模糊的长期规划。然后思考如何在满足要求的情况下尽快的把东西做出来。毕竟事情不会不完全按照你的预期发展，看上去在完美的构架也不可能一直完美下去。根据需求持续的演进才是正道。

关于性能：

由于需要服务海量用户，因此在提到互联网应用的时候很多人都对高性能有着异常的执着。经常听到有人说XX语言慢，XX框架慢。但实际上脱离了需求和构架单纯谈的语言/框架性能是没有意义的。就如Instagram至今依旧用着以慢著称的Django（注：其实我也挺好奇为啥没有将Django换掉。按照我的理解Django的有点是功能及资源丰富，性能方面确实没啥优势。按说Instagram对Web框架的功能需求应当非常少，换个更轻量高效的似乎会更好些？）。

另外优化的成本实际上也挺高，在早期用户不多的时候对性能的优化或许还不如直接加硬件来的实惠。