最近发生了一些不大不小的事，老余说你应该写一写留作纪念，想想也是，站在黑漆漆的电脑屏幕前洞察到的人性，当然值得大书特书。
具体事情按下不表，得出的经验如下：
1、洞察人性最好的方法就是杀入商场，没有什么比利益的诱惑更能激发出人性的黑暗面。
2、天底下没有永远的朋友或永远的敌人，你看好的背后可能捅你刀子，你憎恨的也许反而有做事的边界。都不重要，重要的是你要想好自己的底牌和后招。
说白了，一切都是博弈。你推我挡，玩得一手好太极，不动声色之下牢牢握住自己的底牌和后招方为上策。
3、做人不能太贪婪，太贪婪什么都得不到，做人也不要太聪明，聪明反被聪明误。
4、凡做过必留下痕迹，墨菲定律是对的，你害怕它发生的往往最终会发生，所以做坏事之前自己先掂量掂量善后能不能做好，否则干脆别做。
5、渠道的力量不可忽视，不会借助别人力量来做事的人做不了大事，也永远无法成功。
自学Photoshop已经有一段时间了，将一部分习作整理在此。这些图片分别应用在了我自己的淘宝店铺，以及自己独立运营的微信公众号“好多肉”中，虽然还都比较简单，但是还是很自豪滴~嘻嘻~
Aliexpress 速卖通店招（自己开的店铺）：
模仿的天猫双11专题页头
自己运营的微信公众号“好多肉”做活动时做的宣传图，运用于文章封面：
帮一个法语老师做的法语在线课程宣传图：
有需要psd源文件的同学可以在文章评论里留言哦~~~
老余说今天值得记上一笔，因为我人生中第一次用技术赚到了钱！实实在在的，用自学了好久的Photoshop帮别人做了一张banner图。
吭哧吭哧的做了2小时，得报酬50，不多，但足以让我乐了个半死。持续学习，并有产出，产出还有人愿意商用。这真是世界上最快乐的事。
有图在此，纪念我的第一次！
一个企业，首先要知道的是为谁而生。企业的直接客户是谁，潜在客户是谁，客户的特征是什么，这是否是一块盐碱地，还是一片蓝海？
即使是传统成熟行业，作为一个新入者，如果他还有所追求，为谁而生这个问题一定是淌出来的，而不是想出来的。
不怕路远，路难，方向要对。为谁而生这个问题想对了，路就走对了，企业的价值观也会依附于它。而这个问题想错了，企业之路必然会更加崎岖不平。
X毕业一流大学，光学专业，从事的是照明行业。他的企业之路颇有意思。2年前他想做一件照明领域的工具产品，提供给别人用。却又发现如果做出来了，用户在哪里却不知道。于是转型，借着微信的东风专注于创建照明领域的内容开发，主要就是通过微信公众号，结合志愿者模式做内容传播，前半年主要靠自己，后来逐步有了影响力，开始有大量志愿者通过公众号平台聚集到一起，从事更多翻译和创造性的工作。有了这个基础，事业开始步入正轨。
照明行业，聚集了众多中小企业，从上游芯片厂商到中游设计到下游施工队，整体比较浮躁浅薄，国内产业以抄袭为主。鲜有人静心想为行业做点什么，内容贡献就更不用提。这便是X的机会。
建立行业影响力后，这些中小企业就增加了一个媒体渠道，这时候公司就能够有一些基本的现金流。但是，仅仅是媒体渠道，还不足以让体现一个公司的理想，一个有理想的公司，应该是能够变革行业的。下一步怎么走？玩法很多。
很久以前整理的，一直在更新。
github地址： https://github.com/justjavac/free-programming-books-zh_CN
来源：http://www.v2ex.com/t/143671
我在github上fork了一个分支：https://github.com/raywill/free-programming-books-zh_CN
在OceanBase0.5开源版本中，RPC其实是有一个层次的。自底向上，分别是：
Network Framework — libeasy，负责底层网络框架，packet级别
Client Manager — 负责跟libeasy交互，封装了回调逻辑、异步/同步逻辑
Rpc Stub — 封装了请求的序列化、反序列化逻辑，是应用代码与网络代码的粘合剂
应用代码直接使用Rpc Stub来使用网络最方便，跟调用本地函数区别不大。不需要关心序列化、反序列化过程中的内存问题。但是，应用层如果希望获得一些更为复杂的网络交互逻辑时Rpc Stub则不能提供。比如，希望在A函数post一个请求，然后希望在B函数里wait这个请求的返回值，rpc stub无能为力。
应用代码也可以直接用Client Manager，可以获得很大的灵活性。上一个例子中Rpc Stub搞不定的情况，Client Manager可以搞定。但是直接使用Client Manager会增加一些代码复杂度，例如：需要自己分配DataBuffer，如果追求高性能，还需要自己管理Thread Specific Buffer。
当业务逻辑的对网络需求的复杂度超过Client Manager能力范围时，可以直接用libeasy来解决问题。这是终极方案。在0.5中的SQL模块里用到了该方法，但使用经验证明这种方法可维护性很差，必须对其进行一定的封装。
思考是技术进步的阶梯
A向B机器发送一个plan执行的时候，随着plan本身还需要发送哪些结构？
分析：
OB0.5开源版中发送了SimpleScanParam，但这个参数并不是单独发送的，而是包装在了一个ObHuskTabletScan运算符中，在CS端根据运算符中的参数重新构造子Plan。
答案：
只需要发送plan本身即可。其余要发送的内容都应该封装到operator内部。
进一步发问：
operator内部要封装什么呢？
答案：
比如，读数据超时时间。在运行时用户可以通过命令修改读超时时间，需要将新的时间让plan知晓，以便序列化到B端。
再比如，读数据的版本号。随着时间流逝plan被反复执行，plan需要携带的版本号应该要随时间变化。
这些内容的变化，都应该封装到operator内部。具体做法可以是设置一个IParamProvider()给operator，operator可以随时通过IParamProvider获得最新的数据。IParamProvider的实现比较简单，它持有整个SQL Plan运行时环境的引用，可以随时从中获得最新的参数提供给operator。这个细节不需要scheduler关心。
结论：
从尼泊尔归来已经快一个月了。我和raywill都没有撰文记录一下，实为可惜，在尼泊尔发生了几件有意思的事儿，记录在此：
1、在加德满都经历了第一次停电，后来才知道尼泊尔并没有自己的电力系统。这个国家的电能由印度供给，基本属于印度一拉闸，这里就完蛋的状态。尼泊尔每个区都会在每个时段定点停电。尼泊尔的每个旅馆都会在贴上旅客须知告知大家：抓紧时间充电哦~
2、尼泊尔所有的路都没有红绿灯和指示牌，那么是否会出现交通堵塞呢？当然了！想什么呢你，当然会堵塞，可是有意思的是，不管路上怎么赌，我都不曾见过一个尼泊尔人生气，骂街，吵架的。大家永远乐呵呵的在灰尘漫天，拥挤不堪的路上奔驰。
3、在加德满都逛猴庙的时候我遭遇了惊醒一幕，被一个猴子狠狠的抓了一把背，导致直到现在背部还留着一道特别醒目的大抓痕。因为这件事，我和老余还体验了一把尼泊尔的医院。被抓的当下老余猴子身上带有病毒，坚持让我去医院给医生看看，我们在好心肠的旅馆前台小哥的带领下，杀到了一个看上去像烂尾楼的建筑门口。我和老余面面相觑：这能是医院？Bingo！这里就是如假包换的医院了，我心里一阵嘀咕，这个烂尾楼一样的地方能给看好么，事实证明，花了不到5块钱人民币买了一针疫苗，在众目睽睽之下，医生充满鄙视的给我打了一阵，她心里一定在想：不就给猴挠了一下么，有什么好来医院的！小题大做！后来我们才知道，尼泊尔的医疗条件很差，医疗系统还处在十分不健全的时代，这个被我瞧不起的烂尾楼已经是加德满都很不错的公立医院了。医院里没有一个人会说英语哦~感谢当地热情的大爷大妈帮我和老余翻译。
4、在博卡拉登山经历了毕生最狼狈的时刻，在大暴雨中浑身湿透手脚并用的爬山，我都很奇怪我们居然都没有滑下悬崖摔死。一众人都冷得浑身哆嗦，老余买了一瓶威士忌，每个人都猛灌了几大口，活过来了。
5、头一次尝试在海拔3000米洗冷水澡，绝对的清新亮，透心凉。最后都不知道在干嘛了，听着自己上下牙齿的磕巴声，面色发白的冲出洗澡间，居然也就没有感冒，不知道是不是那针猴疫苗的功能呢？
6、在博卡拉的lakeside遭遇了一大群中国人，导致我一直有错觉我是不是在颐和园泛舟。
最近在做OceanBase RootServer重构后的测试，主要测试工具是用我们牛逼QA开发出的obtest神器。
测试结果总是不太稳定，各种细节错误且不完全复现，很耗人。导致积极性下降。
调整策略：测试期间给自己安排一些优化/重构的活儿，穿插着做事情。