All Stories
学Go语言已经有一段时间了，其实之前就一直在改Yiili就是用Go语言写的，但毕竟只是在别人已经比较完整的程序上修修补补而已。从周日开始总共花了近3天时间，把公司那个项目的消息转发服务器用Go语言实现了。主要还是不够熟练，很多基本的东西仍然要不停地翻说明文档和在网上查解决方案，所以比较慢，相信熟练起来后这个时间可以大大缩短。这个服务器只是个RESTful API服务器，功能也非常简单，包含了操作数据库和memcached，代码量总共才几百行，真爽快，如果用C++实现肯定不止这么点。
QtQuickCompiler出来有一些日子了，自从istkani在iOS App Store上架后，就没怎么关心过Qt的进展，只是差不多每天例行扫一遍Qt的邮件列表而已。昨天心血来潮想试试QtQuickCompiler到底有多神，首先快速浏览了一下官方文档，发现使用还是很简单的，然后开始照文档的说明一步一步操作。
花了好几天时间，终于给Yiili的程序加上了Memcached和Redis的支持。前面也说过，我只是用它们来实现缓存的功能，把一些本来需要查数据库得到的数据缓存起来，比如帖子列表、话题列表、分类列表等，目前看来，效果确实是有一点的，但因为测试环境的帖子太少，还不能看出来以后帖子多起来的时候效果有多少。另外就是Memcached和Redis在效率上的区别也基本看不出来，估计也得是比较大数据量和查询操作才能比较明显得体现出来。
公司里一个小项目的方案，原本就强烈建议小正太把业务逻辑提出来，单独写个server，不要把应用层代码写到nginx push stream module里去，让人家module只做单纯的协议层数据转发。小正太一直以性能消耗要多一次请求为由想把业务逻辑合到nginx的module里去，我真是无语透了，这是多丑多dirty的设计和实现啊！好在昨天又讨论这个方案时，另一个同事基本上同意我的说法，然后两个人把小正太说得哑口无言。现在公司里的人，上到boss、CTO、Director，下到team leader、PM、普通developer，几乎都对软件工程、架构设计毫无概念，脑子里眼里只有source code。很久以前我就在想，如果有人说公司能做出现在这种产品真不容易，我肯定竭力赞同，在条件这么恶劣的情况下一群水平这么次的员工还是能开发出来每年卖上千万刀的产品，确实很不容易啊！
自从知道nginx后，就再也不愿意用Apache了，总觉得Apache配置复杂、体积笨重、运行缓慢，当然这些只是我的无根据臆想。原本用nginx只是用来做静态站，做反向代理，今天zhangh说想要个Wordpress做产品展示页面，于是只好弄一下。顺便感叹一下他的执行力。
周日去电影院看了《沉睡魔咒》。本来打算周六去的，结果相当不愉快的一次网上订票，先去大众点评网上买了两张团购券，还以为每张可以便宜7元钱，结果到嗨电影网上订票还要再付12元，也就是说每张票才便宜了1元钱，还花了一些时间折腾微信支付什么的，我只能说这两家网站的用户体验做得很烂。而且当时没订票成功，我又看手机上收到了两条短信以为已经订票成功了，其实是大众点评网发来的，于是兴冲冲跑去电影院，然后妹子发脾气了，关在卧室里整整一个下午。叹气。
Yiili和MiaoCoffee是基于同一个codebase，目前的区别主要在描述性文字等周边部分。现在Yiili和MiaoCoffee都算正式上线了，之后的工作重心就在运营上了。MiaoCoffee的运营我肯定基本上是不管的，那个其实不算我自己的项目，我的主要精力将放在Yiili上，Yiili上我才有绝对的控制力和话语权。总的说来，我也只是因为有Yiili才会顺便花点时间给MiaoCoffee做些技术支持工作。我在人脉方面几乎没有任何基础，所以很难直接拉些人来活跃气氛。于是我想着前期只能自己生产些内容来吸引流量了，而内容生产是件不容易的事，对我来说有两条路可以走，一是找那些还算有交情并且交情还不错的又在某方面的知识掌握得比较多的朋友，请他们偶尔抽空写点两三百字的超短篇，再配张图就算是图文并茂了，二是从国外找内容自己翻译。前者产量极不稳定，后者产量要稳定得多但要占用大量时间。除了通过生产内容吸引流量外，另外我想到的一个也许效果并不怎样的办法是同步SNS，比如微博，微信等等。等项目起步后，就可以开始考虑推出移动app了，这样既能显示专业和认真，又能降低使用门槛和提高用户体验。大体思路就是学v2ex那样通过技术手段来弥补一些资源上的不足。
Yiili论坛程序是从wetalk改过来的，所以是用了beego这个Web Framework的。前两天Beego从1.2.0升级到1.3.0，有一个用到的接口被删了，用另一个新增的接口替代，于是Yiili就编译不过了。其实据说这个被删掉的接口已经有3，4个版本标记为deprecated了，只是我才接触beego差不多1个月，所以肯定不会知道这回事的，于是即使自己照猫画虎地尝试修改，即使能编译通过了，运行也仍然不正常。Beego的官方论坛上也有人在喊这个问题，一直到第二天，Beego的作者astaxie大概实在受不了人的呱噪，直接把wetalk的不兼容代码给改了。这次事件给我的感觉非常不好，还跑到Go的中文邮件列表去问遇到这种第三方库接口变化引起不兼容的问题该怎么解决。结果有人说，官方的做法是把第三方库在自己的代码库里copy一份，唔，这是我最不喜欢的做法，像svn external，git submodule不都是为了避免这种做法吗！但是go get不支持版本，所以是没办法做到的。还有人提出个我觉得还能接受的办法，在GOPATH里加3个路径，第一个专门放go get取下来的第三方库，里面的东西随时可以删掉，第二个专门放被自己修改过或认为是stable的第三方库，可以保证自己的项目能编译通过的，第三个专门放自己的项目代码。
前几日在重构一个小模块。这个模块的架构本来就很畸形，因为它被要求在不同的设备不同的平台不同的endpoint上运行不同的逻辑，却要做在一个模块里，能给用户一个.a或.lib就可以使用。于是第一版的实现中就有一个变量来区分当前endpoint是哪个，开始还好，后来越来越多的if条件判断endpoint来运行不同的逻辑，代码就丑到令我觉得恶心。于是我就蠢蠢欲动了好久，最后看重构的工作量也不是很大，就跟design这块的小leader打了个招呼开始重构了。
