React

之前简单的对比过React和Vue.js。React组件化程度很高，粒度很细，“模板”分散在整个JS文件中。Vue.js模板和JS文件分离，看上去要清晰不少。当时比较倾向于Vue.js。
近期又去了解了一下两个框架。Vue.js居然也计划要支持JSX了，模板和JS分离这本是我偏好Vue.js的一个重要原因。此外就网上的评价来看Vue.js的坑也并不比React少。考虑到React的背景，以及周边成熟的生态环境，决定再给React一个机会。
把React的《QUICK START》完整的看了一遍。React的入门并不难。如果不想将系统改造成“单页面应用”，只将页面上部分功能组件化也不存在困难。React的粒度很细，但拆分完后各部分会比较简单。
按照React的说法，React会颠覆大家对传统Web开发的认知，但一旦熟悉就会发现这很棒。
React是否真的很棒？因为没真正用过，还不敢断言。但React的组件化思想还是有些意思，本身的概念也比较清晰，加上并不复杂，或许值得一试。

LBForum更新Django1.10支持

前一段时间公司需要上线一个论坛系统。公司系统采用Django开发，因此考虑集成一个论坛的App，另外出于一部分私心，最终采用了LBForum。
之前LBForum很久没有维护，很多依赖包的版本已经不对，导致已无法正常运行。这次更新修正了之前的一些bug，另外对依赖进行更新。现有的依赖包都明确指定版本，避免因依赖包更新导致无法运行。

这次升级后对演示站点同步进行了更新，演示站点地址： http://lbf.haoluobo.com/

LBForum的主要更新

  • Django更新到1.10
    • 目前只测试了1.10，不确定在其他版本下是否可以正常运行
  • 出于工作量的考虑，只保留v2ex主题，不再提供FluxBB主题的支持
    • 如果你想使用FluxBB主题，可切换到v1.0分支，里面有老代码
  • 去掉django-simple-avatar，使用easy_thumbnails提供用户头像支持
  • django-helper、django-lb-attachments使用django-lbattachment、django-lbutils进行替代
    • 前面的两个包是我很早之前维护的工具组件，现在已不再维护。后面的是现在新维护的工具组件
  • 去掉django-onlineuser
    • 这个用户在线模块一直有些问题，在想好怎么优化前暂不增加在线用户统计功能
  • 使用django-el-pagination替代django-pagination
    • django-pagination已经近乎不维护的状态，django-el-pagination在功能以及活跃度方面都要更好一些
  • 去掉South
    • Django自带的数据库结构维护已经很成熟了
  • 使用bower管理第三方JS库
    • 使用bower，避免将大量的第三方库直接塞到代码库中。
  • 上传组件替换为jQuery-File-Upload
    • 之前的上传组件依赖Flash。在Flash越来越不流行的今天，依赖Flash不再是一个好选择。
  • 使用MediaElement增加视频支持
  • 使用Pygments提供语法高亮支持
    • 在安装Pygments后，可对代码进行语法高亮

lbforum-site的主要更新

对应的演示站点也做了相应的更新。

  • LBForum、django-lbattachment、django-lbutils使用Submodule的方式导入
    • 相比采用pip方式安装，使用Submodule的方式对子模块的更新和修改起来要方便的多。
  • 使用django-allauth替代django-registration
    • django-registration老早就不再维护了。django-allauth在功能以及活跃度上都还不错。
  • 针对注册，加了一个简单的校验
    • 网络上的垃圾爬虫无处不在，之前的演示站点已成了垃圾广告的集散地。这次在注册的时候加了一个简单的校验，必须在captcha内填写captcha才可正常注册。因为刚更新，还不知道效果如何。注：现在的爬虫似乎很智能了，这个功能似乎并不太有效，还是不定期会有爬虫上去发帖。

其他一些问题

  • 一直想把文档给整“好看”一些。不过写文档并不是一件轻松的事情，面对懒癌文档的事情只能继续挂起。
  • 目前主流的Python库已经都支持Python3了，增加Python3算是挺有必要的一个工作。根据之前Python3支持的经验，要同时支持Python2和Python3还是得花费一些时间。由于我主要还是用Python2，因此也先挂起了。

目前项目用的一些东西

项目基于Django构建，如果你们也在用Django，可以参考下。

源代码管理 HG

之所以用HG完全是因为公司代码库用的是HG，如果让我选当然更愿意用Git。大多情况下HG也已经够用了。
项目中开发的Python公共模块使用submodule的方式引入。采用submodule的方式对子模块的更改和更新都会比较方便。

JS等静态资源管理 Bower

作为一个Web项目自然少不了用到jQuery等第三方JS库。将这些第三方库全部下回来丢到代码库里一是让代码库变的不必要的臃肿，另一方面库之间的依赖关系也不容易管理。引入Bower后代码库要干净很多。

Web前端框架 Bootstrap

现在用Bootstrap的网站有些太多了，以至于Bootstrap让人有些审美疲劳，不过对于缺少专业前端的团队来说Bootstrap绝对是个利器。

JS/CSS压缩 django-compressor

使用django-compressor可以对JS/CSS进行压缩，加快网站加载速度。

表单 crispy_forms

如果是做互联网应用crispy_forms的作用可能不大，但是对管理后台来说crispy_forms非常棒。

django-impersonate

让你可以方便的切换成其他用户。在系统维护的时候会方便很多。

异常日志 Sentry

Sentry 是一个实时的事件日志和聚合平台，基于 Django 构建。Sentry可以将程序的所有异常自动记录下来，然后在一个好用的 UI 上呈现和搜索。如果你还没用过Sentry，强烈推荐一定要试试。

为什么没有用

  • React/Angular
    • 我们的应用场景还是传统的WEB应用，React/Angular可能更适合Web APP的场景，应用起来可能不能带来太多的便利性。
  • Webpack
    • Webpack 是当下最热门的前端资源模块化管理和打包工具。也曾想试试，不过我们这里前端部分还不算太复杂，冒然引入Webpack似乎也不是太必要。目前Bower+django-compressor已可以较好的满足我们的需求了。

Swift

最近在看Swift。已经很久没有这么“悠闲”的看一本书了，从头开始认真的看一本书的感觉还不错。
Swift给我的感觉是一门挺“特别”的编程语言。Swift是一门动态语言却加入了很多静态语言的特性，从一定程度上说Swift比很多静态语言还更严谨。

  • 在Swift里所有数据都是有类型。Swift有着强大的“类型推导”，因此很多地方是不需要指定数据类型的。也正是因为所有数据都有类型，相比大多脚本语言，编译器能检查出更多的问题，IDE的自动化程度也很高。
  • Swift和Objective-C采用ARC进行垃圾回收。以极低的性能损耗换取了接近全自动垃圾回收的便捷性。（注：官方宣称Swift比Objective-C要快很多）
  • Swift有这众多的动态特性以及语法糖，使用便捷且功能强大。

Swift中的?以及!

之前在其他语言中没有见过类似语法，初次接触时非常困惑。但一旦理解了之后就会发现这其实非常简单。
String?表示String或nil。首先要理解 String? 同 String 并不是同一个类型。 ?是一个封包的操作符号，将String封装成 ? 类型。（注：有点类似泛型，按照泛型的写法是 ?<String> ）
!则是解包操作，将String?转换为String。如果被解包的数据是nil，则会解包失败抛出异常。

var s = "abc"  // s被自动推导为String类型
s = nil  // nil本身也是一个类型，类型不相等，将抛出错误。
var ss: String? = "abc"
let x = ss!  // ss 有值，可正常解包不报错。
ss = nil  // String?允许值为nil，不报错
let y = ss!  // 报错，无法对nil进行解包

Swift中的Dictionary以及NSDictionary

Swift中的Dictionary同NSDictionary可以通用（NSArray类似），但实际上它们并不是同一个东西。它们在混用的时候，编译器是需要对数据进行转换的。如果你代码中涉及大量的Dictionary/NSDictionary转换，很可能导致你的代码出现性能问题。（注：据说Swift中JSON处理速度慢就是该问题引起的）

django-lbutils

在Github上公开了不少项目，不过其中大多都算不上“开源”。在我看来开源也应当是一件认真的事情，需要对项目持续的维护，同时也需要提供必要测试用例及文档以保证项目的质量。
最近打算将自用的Django工具组件做个简单的整理然后发布了。为了让项目不要太“随意”，开始补测试用例及文档。因为是自用，测试用例和文档几乎为零。最初只是想简单的修葺，不想真正做起来工作比预期的要高出很多。整了许久代码中的注释依旧很不全，测试的覆盖率都还未达到80%，文档更是没开始动。因为文档还没弄完，所以项目也不算正式发布，如果你感兴趣可以先去看看django-lbutils。
为了这个项目，尝试了一些之前经常看到却一直没怎么使用过的工具。

Tox

Tox是一个Python的自动打包测试用具，用来测试Python库在不同环境下的兼容性。因为是自用，本机环境跑起来是没啥问题。不过在兼容性测试时部分测试用例在Python3以及Django的某些版本下跑起来会有问题。为了搞定兼容性花费了不少时间。

Travis CI

Travis CI是一个在线的持续构建平台。Travis CI会检查你在Github上项目的变化，每当有新push的时候进行自动编译。我现在是每次改动后，直接在Travis CI看测试用例的执行情况。

Coveralls

Coveralls测试覆盖率查看工具。结合Travis CI，可在每次测试完成后将测试覆盖率信息推送到Coveralls。在Coveralls可方便查看当前的测试覆盖率。

Read the Docs

Read the Docs文档托管服务。可从Github抓取文档并自动编译好生成在线文档，目前几乎所有的Python库都将文档托管在上面。

畸形的中国房价

年后，有是一轮房价的快速上涨。上海、北京城区的房价轻松破5万每平米，北京更是创造了“11平学区房卖530万”的天价。在我看来现在中国的房价真是贵，贵的离谱，这时候如果想买房投资绝不会是一个很好的选择。

相比房租，房价高的离谱

近年来银行利率一降再降，但也保持在5%左右。如果你贷款120w买房，这意味着你每年单银行利息就得支付6万，平均每月还贷5000。在中国的1~2线城市里，120万装修好的房子顶多也就能租到3000。如果不考虑房价上涨，每月投资收益就损失40%（这还不考虑租房的空窗期）。
再参考一下国外的房价和房租。日本人口密度很大，寸土寸金，国人印象中日本房价一直居高不下。日本房价可以参考知乎的问题日本房产是否比北京上海便宜？具体原因是什么？。从里面可以看到，中国北京、上海的房价已经成功赶超东京。另外从东京和北京、上海在物价上差别有多大？这个文章里可以大致了解到东京租房价格。“家住千叶县市川市靠近浦安 距离东京都心地铁半小时左右 房租5万4 不到20平米”换算成人民币和国内的房租面积算法，也就是30平米不到，3000千的房租。大致推算下来，房价相当的情况下，日本的房租比国内的房租要贵到近一倍。
注：日本的房子面积不算公摊，因此房子面积相比国内要乘以个1.4左右。日本尽力过房价的暴涨以及崩盘（理性房价的回归），对国内的房价走势有一定的参考价值。如果真有100万现金，可以购买银行的信托基金，通常收益回报率是可以大于房贷利率的。

中国的房价为什么如此的贵？

一般大家都在说房价贵，一边又都在买房。你说房价高，却又一山更比一山高。中国的房价贵，自然有贵的理由。

买房实际上是在做风险投资
既然短期内无法通过房租获利，那就只能寄希望于房租或房价的上涨了。按照现在的租金情况，租金至少要上涨一倍才有希望获利。按照中国目前的薪资水平，如果房租真上涨一倍，立马很多人无家可归。想要实现房租的翻番需要漫长的等待。既然考租金获利不靠谱，最直接的就只能是房价上涨后赚差价了。目前的房租收益已到了一个非常糟糕的情况，如果房价继续快速上涨，房租收益情况必然更加恶化。既然买房如此的不“合算”为何还要买房？房租虽然无法决定房价，却又不可避免的会影响房价。
从经济的角度来讲，不管是房租的上涨还是房价的上涨都需要靠国家经济的快速增长为前提。投资房地产实际上是投资“国家”这个“创业公司”，预期国家在今后可以继续的快速增长。

国人“有钱”
中国的独生子女制度，让一个房有机会耗干两个家庭的所有积蓄。同时又是独生子女制度让大家能接受花干了所有积蓄也只能买89方的小户型的现实。

租房的困境
从经济的角度讲现在买房很不合算，但如果你真不买房问题不少。
不规范的租房市场
租房虽然省钱，但并不省心。在中国你想安心的长期租住并不容易。由于房租不赚钱，房东大多想着等房价涨了卖出去赚一笔。租房意味着你随时都可能被房东扫地出门被迫搬家。

资源（尤其是教育）的不平衡
如果没有房，孩子上学都是个问题。

今后

简单的说我并不认为中国房价可以持续的快速涨下去。中国的房地产有着太多的问题，太过脆弱，犹如美丽的肥皂泡，一不小心就会被戳破。但我也并不认为房价会崩盘。中国经济及房价的发展轨迹像日本，但中国不是日本。日本崩盘了，中国未必。中国ZF更不市场，有着更大的调控能力。

房价稳中有升
高存量，房租不赚钱，房价不涨，难免会引发一定量的抛售，搞不好就真崩盘了。因此我觉得房价稳中有升，即给买家一些希望（大多已经买房的人都希望涨），又不至于让房价相比租金继续太过畸形。
当然，这是我说的理想情况，就实际情况来说房价下跌的压力可能比预期的还要大。
注：“快速平稳”的降低房价的手段之一是“货币贬值”。现在的中国早已不是上世纪90年度的中国，中国的经济体量在这里，一旦主动大幅度货币贬值很可能是灾难性的。

中国经济的不确定因素-人口红利
然后就如国家自己说的一样“中国的经济到了拐点”，中国传统粗放型的增长难以继续支持中国的快速发展。然而转型又岂是如此的容易。
中国的经济增长想来都是靠资源推动，其中最重要的一个资源就是“人力”。长期以来中国有着丰富的人口红利，中国的人口红利在近几年就将达到高峰，再之后就要开始衰减了。随着人力红利的到期，中国能否继续高速增长就更依靠“产业升级”，但中国所谓的“产业升级”似乎走的并不顺。
人口增速的降低带来的另一个问题是住房需求降低，需求的降低也必将对房价产生不利的影响。中国目前人口迁移的形式是逐步向各大中城市迁移。现在不少农村几乎已成了空村。可以预见，中国的一二三线城市的人口还将继续增加，但增速会有一定程度的减慢。四线城市以及乡镇的人口甚至会有一定的减少。

人口政策的转变
中国近期全面开放了2孩，不管大家愿不愿生，多生孩子多种树都今后的主旋律。一旦2孩，之前的小户型必然无法满足居住需求。相对而言，人们对房价单价的承受能力就变弱了。之前的一套房已经将很多家庭的家底掏空（贷款都没还完），这时在面对几个孩子的情况时必然无法同现在一样给孩子如此大的支持力度。

城市发展模式的转变
中国长久以来都是城市的巨型化。随着信息技术的发展，让城市的中心优势变的不再明显。或许今后中国的城市会逐步走向“泛中心化”，大量的公司移到郊区，除了周末逛街，大家不用都挤到中心城区。城市范围扩大后，土地的紧缺的可得到一定程度的缓解。

最后

中国房子只有70年产权-_-!

眼镜验光配镜须知

每次换眼镜都要配坏好几幅眼镜，这次在配坏了两副眼镜后决定自己去买了验光眼镜来对度数进行微调。
既然决定要自己验光，有些验光常识还是需要知道的。

矫正视力到多少合适

通常大家都会希望矫正视力越清晰越好，但对于近视的患者来说如果“过矫”会导致看近处的时候眼镜更容易疲劳。现在大家成天都盯着电脑手机，因此矫正视力到0.8~1.0就可以了。

正规的验光过程是怎么样的

知乎上的这个问题“一个完整的眼睛验光流程是怎样的？”里有详细的验光说明，大家可以去详细了解下。
下面把几个重要的步骤简单的说一下。这里列出的只是一些比较重要的步骤，如果连这些步骤都没有，那么这个验光流程是非常不正规的。

  • 测瞳距
  • 电脑验光
  • 散光轴位和度数初步检测 看一个放射图，调整到所有线都一样清楚
  • 红绿平衡 看红色及绿色背景的视标。如果绿色比红色清楚，说明过矫了。
  • 试戴调整度数 带验光用的插片眼镜最最终的度数调整。

自己验光

由于长期配镜，加上去眼镜店验过，对自己的度数基本了解，因此直接跳到最后一步，使用验光眼镜对眼镜度数进行微调。验光眼镜可以很容易的在淘宝上买到。
验光眼镜每侧可以插3个镜片，因此在购买插片的时候可以再买两片25度的插片用来做对比测试。眼镜上有两个旋钮，用来调整轴位。如果有散光，可以反复调整轴位直到确认最合适的轴位。

近期配镜体验

上一副眼镜在“亿超眼镜”配的，当初验光还算仔细，这次配镜还是找他们家。哪知他们对加盟店几乎没有任何管理，验光过程及不正规，最终拿到的眼镜非常不合适。之后去了“毛源昌”。毛源昌的验光流程比较正规，拿到的眼镜佩戴也还比较舒适，和自己通过反复试戴确认的度数基本一致，轴位方面有10~15度的差距。验光师没有考虑我长期使用电脑的实际情况，眼镜度数给的“太足”，实际使用中存在过矫。

镜片

镜架方面主要是舒适、好看，个人感觉贵的和便宜的差别不大。镜片方面需要关注的是镜片的折射率和阿贝数。阿贝数越高越好。折射率越高镜片越薄，但通常情况下阿贝数会越低。国外知名品牌的镜片价格相对昂贵，且假货多。除要求特别高，一些国产知名品牌的镜片也是个不错的选择。从网上看国产的里面“明月”、“万新”的镜片相对较好。

注

红绿视标
红绿视标2
散光放射图
fs
视力表
psd6615

Bye, 2015

2015算是平静的一年，却也发生了一些事情。

我的第一辆车

有朋友说车代表自由，有了车后可以方便的去很多之前不方便去的地方。不过我对车一直都不太感兴趣。我总感觉车本身也是一种束缚，很多地方即使有车也去了。我期待着背上背包说走就走的自由。
因为老婆怀孕，第一次有了买车的计划。杭州的限号，加上“小气”的我舍不得花钱去购买车牌，因此打起了电动汽车的主意。2015年我有了第一辆四个轮子的车，虽然是租的。
拿到车的第一天就发生了一起车祸，把他人的车给刮了。我的车胎破了，动弹不得，保险公司的拖车不肯过来，加上手机没电让我一时没招。被迫将车丢到景区，先回公司查找资料，看附近是否有修车公司可以过去。同事说看着我撞了车还一脸淡定感觉很好笑。

宝宝

既在计划之中，又在计划之外的宝宝。一直认为宝宝应当是生活的一部分，不应当是全部。当宝宝真正到来的时候生活还是不可避免的被改变了不少。
宝宝并不如之前预期的那样省心，私人时间少了不少，今年的出行计划全部泡汤。

工作

工作方面虽然遇到了一些小困难，好在最终也算是有惊无险。
领导希望公司的办公平台能成为公司的数据中心，各业务平台都可接入公司的办公平台，由办公平台做业务及数据的整合。要实现这个目标用第三方的业务平台自然是无法做到了，于是就有了采用自建平台替换现有第三方平台的方案。
由于部门人太少，还得引入第三方开发商合作开发。找供应链部门一起折腾许久才将合同敲定。
技术方案相对来说倒还简单。开放框架自然还是我最熟悉的Django，前端用的AdminLTE，静态资源用Bower管理，sentry啥的APP自然也是少不了的。流程引擎方面还是之前我们自己开发的那一套。
公司在流程方面有着各类“变态”的需求。在经过这次的洗礼之后我们的流程引擎在功能方面算是比较完善了。或许在今后工作不是那么忙的时候可以将这个流程引擎开源掉。
真正麻烦的是公司流程的梳理。公司流程梳理的难度远大于预期，甚至让我有些后悔选了自建平台的方案。最后阶段调整计划，优先保证重要流程上线，其他流程上线时间延后。虽然总体计划有些延后，但平台总算是顺利上线。

Other

2015年有写一些Objective-C。一个编程语言难的不是它的语法，而是习惯它的思维方式。

开始使用Feedly

Google Reader关闭后之前订阅的feed全部丢失，已很久没读过博客了，似乎也是从那时起自己的个人博客也很少更新。

前一段时间看到湾区日报在V2EX介绍自己网站一周年的运营情况。很早之前就知道这么个网站，但一直没怎么认真看过上面的东西。无偿的将一件事情坚持做下去并做好并不容易。可能是出于好奇又去网站看了下。上面的文章确实还有些意思，另外湾区日报的博客似乎也还挺有意思，一时让我有了重新启用Feed阅读器的想法。相比微博的嘈杂，博客要清净的多。

Feedly据说是Google Reader的最佳替代。在Feedly上加了我在Github上关注的几个用户的博客，想之后的订阅应当会慢慢增加吧。

股市入市一年回顾

从上月中旬开始，股市忽然急转直下，哀鸿遍野。网友们感叹，给不了慢牛至少也得给个慢熊啊。
在经过一段时间的观望后我已不再相信近期的股市还有机会。昨天将所有股票清仓，这波的行情到此为止，耐心的等待下次机会。在下波行情到来之前股市的涨跌已与我无关。
去年9月2300点入市，股本2w，在3000点前增加到5w。在股市的最高点股票总值差不多有8.5w+。清仓时是7.6w，刚好达成最初的50%收益预期。
我对股市的观点和刚入市差不多，这里再简单的说一下。

  • 不被外界的各类因素干扰，做自己认为正确的决定。
    在股市下跌一段时间后，我感觉行情不太对，让老妈赶紧将股票清掉。老妈很不开心的说：早些时候不叫她清，现在跌的这么惨才要清，她不干，一定要涨回去才行。
    作为一个普通人，我们几乎没有可能在第一时间发现机会和危险，我们能做的只是不要落后太多。一个股票卖与不卖的关键在于“该卖了”，并在在于你赚了多少或亏了多少。如果你觉得行情不对了即使亏的再多也应当果断的出掉及时止损。
  • 在自己能接受的风险范围内投资股票。
    买股票很重要的一点就是能客观的判断形势。如果投资在股市里的钱过多，股市的每次涨跌都将直击你的心脏，让你无法客观判断。
  • 少看K线，股评
    资本市场里聚集了世界上最聪明的一票人，妄想在短线操作上胜过庄家也职业操盘手几乎是不可能的任务。更糟的是做短线会让人的心态变差。涨的时候后悔自己卖早了，跌的时候后悔为啥没早卖，不管股市是涨是跌你都开心不起来。你要做的只是把握股市的大行情，跟着行情能赚到一些省心的小钱就已经不错了。

PS:
这次股市崩盘的速度远超乎大多人的预期，国家频频出手都未见成效。或许真同网上说的一样再这么跌下去国家得出大问题。所以虽已经逃离股市但也不希望股市跌太惨。跌到3000点国家应当还顶的住，如果跌破2500点就真不好说了。