挺久没写了。一直忙着各种杂事。
最近稍微安定下来了，胡乱写些最近的想法吧。
大公司与小公司
就我个人的感受，小公司的人与人的联系要更紧密。因为人少，而且业务导向，人与人之间的直接交流会比较多，互相比较熟悉。
以前在网易的时候，大多数工作都在popo上，一天难得说几句话。很多人我只知道名字。。。
大公司流程比较多，小公司不太在意这些，只要能完成任务就行。这点我比较不习惯，一些项目没有文档／jira，只靠口口相传。。。没有需求／设计的过程，直接码代码。。。
我的感觉，流程不能过多，但也不能完全没有，这是个取舍的过程。
更多的流程会减少出错的概率，但也带来很大的overhead。没有完美的方案。
我讨厌开会，很多会议跟我关系不大，只是“为了以防万一”叫上尽可能多的人。。。就像转发邮件要cc尽可能多的人，事后如果出问题可以免责。。。这点小公司比较有优势。
大公司遇到牛人的概率会大点。大公司做事有些偏向于研究的性质，而小公司更多关注业务。如果能用很low的技术实现一个需求，小公司就会一直重复着这个技术，能用就行。久而久之，很多人技术上也不会有长进。这是要警惕的。
倒不是说小公司技术不行，而是缺乏动力去升级技术方案，除非被逼急了，随着业务的扩张，老的方案已经hold不住。
当然也要看场景，过度优化／设计也是不行的。
另外最近我看到了一些奇葩的代码，不得不吐槽，extends Object是要闹哪样。。。
感觉很多人脱离spring就不会写程序了啊，觉得java就是tomcat。。。
我在网易也见过一些奇葩代码，比如6个嵌套的for循环。。。
好的代码总是相似的，烂的代码各有不同。还是见识的太少啊。
关于MAC
特指macbook。
mac真的是生产力工具啊，创业公司配置mac不是没有理由的。
用熟了之后，效率比windows上升不知几个档次，非常适合程序猿。
键盘＋触控板，完全不需要鼠标了。
而且mac下有好多神器：
- brew/brew cask。包管理工具。我发现很多系统都有包管理啊apt-get/yum/pip/gem/npm，这是发展的必然趋势？
- Alfred。无法形容。。。什么都能干。。。关键是可以自己扩展。
- HammerSpoon。有点类似alfred的workflow，但是更面向程序员，更加强大，可以自己写lua脚本控制系统的方方面面，相当于系统和用户的一个中间层。用的好的话，hammerspoon可以代替其他很多程序。
- Vagrant。本质上是一个虚拟机管理工具。我想搭一些测试环境，但又不想弄乱本身的系统。本来想用docker的，更轻量级，也更流行。但mac不支持lxc，不能直接用docker，很蛋疼，要通过一个虚拟机中转，不如直接用vagrant了。
还有更多神奇的东西。不一一介绍了。
hexo历史版本
在mac上写blog，安装hexo的过程中碰到一些问题。由于我用的主题与hexo最新版不兼容，要安装2.8.3版本：
|
|
加上registry参数是因为国外的镜像很慢。
记录下。
python和ruby
最近想挑一门动态语言深入学习，在python和ruby之间犹豫了下。
二者其实我之前都有接触过，但浅尝辄止。
python用来写简单的运维脚本，还折腾过一段时间Django。
ruby折腾Jekyll时了解过一点。
ruby很像perl，让我不爽。我对perl是敬而远之，能写perl的都是大神。
但又听说ruby有很多好玩的特性，学ruby能开阔眼界，尤其对我这样用惯了java的，有点心动。
ROR也很让人流口水。。。
以前一直以为ruby大部分是做web开发，但ruby也能实现brew这种神器，顿时对ruby改观了。就像我第一次知道nodejs，知道js也可以写后端一样。
但python似乎应用更广泛，类库更多。
而且spark官方提供python接口。
蛋疼的是python2和python3，不知道社区怎么搞成这样的。。。
至于网上其他人讨论的缩进／end／效率什么的，对我而言都不是事。
我觉得选择一门语言，主要看它的“哲学”。
语言能改造我思考问题的方式。
继续纠结。。。
更新：选了python，因为spark。
另一个原因是我还要研究下scala，还是因为spark。。。
感觉scala和ruby有点像，都是特别灵活，都是混合多种范型（真OO无双但是又支持函数式编程），都是many ways to do one thing。二者择其一，而scala是无法放弃的。
关于读书
以前我很喜欢买纸质书，虽然完整看完的不多。。。
后来就更喜欢电子书了，因为纸质书搬家太麻烦了。。。
最近在看《Hadoop Application Architectures》，非常赞，近期写个读书笔记吧。
希望以后还能有充足的时间看书吧。
吐槽一些书，明明很简单的事情，偏偏说的很复杂。想起以前看的某本js教程，章节名字都是类似“沙场秋点兵”这种，各种引经据典，各种比喻、类比，看得非常累。。。反正我翻了几页就拿去垫高显示器了。。。
也许那些书适合完全不懂的人吧。对我这样稍微有些基础的，直接讲技术就好了。
我宁愿去看官方文档。
另外中文书真的是很多坑。。。我买的书多，踩的坑也多。不是我不想支持正版，有些根本就是粗制滥造，大段的代码，大段文字都是抄官方文档。这种东西也好意思拿出来卖？
比如前段时间研究Jersey，搜了半天中文的书只有一本《Java RESTful Web Service实战》。60多块钱买来一看，真特么后悔。。。
所以买书之前预览下电子版还是很有必要。。。
这些年买的最有诚意的书是《锋利的jQuery》。
如果是翻译的，可能更头痛。比如《Hadoop权威指南》，各种名词译的非常奇怪。。。我得先看英文版，找到那个单词，才知道中文版是什么意思。。。你不会译就保留原文不行么。。。所以我向人推荐的时候都说直接看英文版。不知道后几版的翻译有没有改进。
也有翻译的好的，《HBase权威指南》就还行。
翻译的书更大的问题是版本落后于原书。比如《Hadoop权威指南》英文已经出到第四版了，而中文还停留在第二版，其中很多用法已经过时，甚至被移除了。对hadoop/spark这种快速发展的项目，这个问题很严重。
总之，买书还是要谨慎。。。
吐槽MVC
最近参与一些小项目，发现还在用jsp、freemarker、velocity之类做视图层。我怎么感觉这是上个世纪的技术了。。。
传统的三大框架SSH，感觉已经是老大哥一样的存在了。
个人感觉，web应用中，越来越多的逻辑都移到前端了。以MVC架构而言，后端往往只负责M，只提供数据接口，而VC都完全由前端控制。原来后端负责的一些业务逻辑，现在都是在前端用js实现的，比如各种单页面应用。
这样前端和后端的耦合也比较小，只要定义好数据接口就可以了。而且无论app还是web，都可以使用同样的后端接口。
什么时候有这种趋势的？是随着移动互联网开始的？我也不知道。
其实是将以前后端的很多工作转移到前端了，导致前端越来越复杂，都出现自己的MV*框架了。。。
另外前端的xxx框架太tm多了，都自成一派，没有能一统江湖的。我还是老老实实用jquery算了。。。
