最近公司迁移机房，不知道为何用google
authenticator来做验证。这下直接导致我们在这个公司有三种形式的token。。。实体token、宁盾和ga。真够麻烦。
不过迁移机房之后至少我们可以不用登陆windows
server来做跳板，所有过程在终端完成。那么就可以直接用expect脚本来实现自动化了。问题就剩下怎么生成这个随时会变的token。
去github上找了找，结果发现离线生成ga的token竟然是可行的。这点和我当初想的不太一样。之前道听途说，token在服务端和客户端都用了非常牛逼的加密算法，所以才导致其破解不了。但实际上看来加密算法竟然是可以直接公开的。。对于这种算法而言，必须的条件就只有一个，就是分发给你的独一无二的key。用这个key在服务端和client端每30s进行一次计算，然后就可以得到一个六位数字，关心具体算法的可以看这里：
> https://github.com/cch123/googleAuthenticator
两边进行匹配即可。而在服务端识别key和用户身份则是通过当初把这个key分发到哪一个账户下了，也就是把key发给了哪一
elastic官方为了统一混乱不堪的技术栈版本号直接来了个大跃进，把logstash/kibana/elasticsearch之类的东西统统变成5.0。
说起来我们用es也有一段时间了，感觉一路用下来总结的话，最坑的还是数据同步和各种深度翻页导致的full
gc问题。再回头看看当初在博客上写的es相关的文章，感觉真是水orz，哪天有闲就删掉吧。。
这次升级5.0，官方把原来的marvel搭配了几方新药(security、alerting、graph等)作为一个新的组件x-pack进行发布。如果想要用x-pack的话，需要在es和kibana里分别用plugin进行安装。然后，因为穷逼们付不起一年好多好多刀的license，所以可以用最简单的free
license凑乎一下。free license里只包括了monitoring，其实就是以前的marvel了吧。
要说对于使用方最大的变化嘛，就是什么head、kopf之类的插件这次全都不能用了。。。。官方表示site plugin有安全性问题，
最近接手其他人做的项目，导致之前的一些幻想破灭了。因为刚工作的时候做项目是php，而php本身的web框架一般只简单区分mvc，稍微麻烦一些的会多个library或者helper之类的。这样分层很少有优点同时也有缺点。当然了，现代的框架一般支持namespace，你也完全可以借鉴其它语言来做自己的内部框架。这里先不说这个。
mvc的优点自然是简单，无论一个新人有没有做过相关的工作，你只要跟他简单说明每一层的职责是什么，马上就可以开始工作。缺点也非常明显，因为太简单，所以代码在累积到一定量以后会变得难以控制复杂度。同时容易让没什么经验的程序员把代码写得难以维护。
所以之前听说java的框架这方面做得好一些，然后对部门的java项目抱有一些幻想。不过在实际接手后，发现理想和现实真是有比较巨大的鸿沟。所以先来总结一下共通的初级程序员比较容易犯的错误吧。如果哪天自己带团队了，面试别人也可以拿这些题作为区分人的一种界限。做项目的时候有思考的人和不思考的人还是会有不小的区别的。
命名太啰嗦，或者不规范
这个问题其实挺普遍的，即使是科班出身的人，工作了很多年的人，写程序也可能冒出来一堆var
刚毕业的时候在迅雷工作了半年，因为一些特殊原因，还是回北京工作了。中间乱七八糟的东西就不说了。
因为只在这个公司待了半年。。所以可能也不算学到了什么东西，只是大概地对这个公司的业务流程有了一些了解，写下来做个记录吧。
对于一般的用户来说，迅雷就只是个简单的下载工具。当年迅雷能干掉网络蚂蚁和快车成为最流行的下载软件，主要还是因为自身做的比较好(其实上市的时候ceo说是因为快车作者沉迷魔兽世界顾不上维护软件我会跟你讲？
作为一个从共享软件年代一路走到互联网时代的工具，迅雷还是有自己的一些创新点的。里面最重要的大概就是用base64加密磁力链接转成thunder链接了(误)。说正经的，其实是自称的p2sp。P2SP(Peer
to Server &
Peer)，看全称，其实就是在p2p里加入了server来参与用户的下载流程。当然有人会说，一般的bt服务也会有tracker服务参与啊，你这个好像不算创新。那还是不一样的。tracker服务器实际上并不会存储具体的文件内容存储。只会存一些torrent的元信息。但是在迅雷的p2sp里，
es的DSL实在是过于难用，相信使用过的同学都会有这种感受。而sql对于99%的程序员来说没有什么学习成本。
所以在工作需要的情况下，完成了这么一个简单的项目：
> https://github.com/cch123/elasticsql
把sql转换为es的DSL，这样你就不用每次都去写那个痛苦的DSL了。
这个库可以用来做什么呢？嗯，比如你在业务中用到了es，又不想去为了这套es培训所有人学会es的dsl，那么你可以使用它。再比如你想要实现一个支持sql的es的proxy，也可以把它当成你的一个模块来使用。
当然目前项目还在初期阶段，只实现了取数据部分。就是指定where条件，获取数据这种逻辑。count/sum/min之类的聚会还没有做，回头会加上。
不过where条件的话自我感觉支持还算完美，虽然目前还有点纠结sql里的equal应该用match phrase还是用term来做(因为match
phrase要涉及到分词之类的逻辑，
