作者归档：raywill

2015年总结&2016年展望

发表回复

 

2015年总结&2016年展望
 
== 2015 ==
 
除了工作，不记得2015年做过什么了。那么就说说工作吧。今年全部的工作内容都围绕SQL的设计和实现展开，解析器啦，生成器啦，执行器啦，扎扎实实步步为营，做设计，写代码，帮助一下新人成长，并没有什么大的可圈可点之处，都是分内之事。2015年五月份，OB 过了五周年的生日，北京的同学们还开了一个简短的生日party；2015年五月份，白哥离开了我们，我很想念他。到了年关，白哥已经很少被提到，明年的端午还有中秋，再到年关，不知是否还会被想起；2015年7月份，又搞了一次996运动，说实在话，比起上一次的996工作强度还好，就是家属工作比较难做一些；2015年1212，顶着巨大的工作压力任性地去了趟四川南充，支援支付宝线下支付活动，竹翁忧心忡忡地问聿明，你们去几天？晓楚的活儿还没干完呢。
 
 
除了雾霾，不记得2015年的生活是什么颜色了。2015年，除了一趟福鼎团队团建，太原朋友婚礼，并没有远游，每空出一丁点时间都是回家，1月一次，2月一次，5月一次，10月一次，12月一次。一来人大了更喜欢故乡的宁静，二来有空尽可能多陪陪父母，谁知道将来的时间会如何流淌？2015年的雾霾，让生活变得毫无意义，2015年的雾霾，并没有在2016年消散，2016，该如何继续面对？想必，每一个能够做选择的人，都有自己心中的答案。
 
2015年，看东西很杂，不成系统，大部分是Article，很少是Book。Article分为两个主要来源，朋友圈，虎嗅掘金Medium等专业App。读Article的收获都是浅刺激，读完发表一下感叹评论，然后就忘得一干二净，能内化的少之又少。读Book太少了，特别是专业书太少了，一大缺憾。 （顺便说一下，虎嗅彻底垃圾了，以前每日必看，现在我觉得每一篇都在浪费我的时间。多好的媒体，一遇到资本，真是让人悲伤。人，独立的人，又何尝不是）
 
2015年，公司工作之外，学习了两个新鲜玩意儿：Docker，React，都很屌。
 
2015年，几乎不写生活博客，技术博客倒是经常更新。不过都是流水账，记录些结论。
 
2015年，认识了很多朋友，世界的色彩更加斑斓多彩。
 
2015年，尽最大努力为老婆创造了自我成长的空间，monkey同学心智的成长，是这一年最大的收获。不要以为成年人的心智就可以停止生长，你我，何尝不是要继续成长。然而，能不能成长，会不会定格，就看命了。命不好的，凑合稀里糊涂往前过，也未尝不可。心智成长，得靠自己去悟，也得靠去跟生活交锋。没有悟性，生活是生活，我是我，老死不相往来；不接触乌七八糟的生活，悟出来的也只能是个温柔乡，或是一部连续剧，远没有实实在在的第一人称体验来得深刻。2015年，在生活的熏陶下，monkey对人对事的认识，较之从前，有质的飞跃。善哉善哉。
 
 
总之，2015年之于我，就好比微博时代的阅读，是碎片化的，散了时间一地。
 
 
== 2016 ==
 
如果延续2015的工作学习生活模式，自己会给自己打负分。
 
2016年，工作要更系统，更具有连贯性，还要多看相关的书。拓宽对OB的学习边界。
 
2016年，博客要更系统，要写一些高质量的、系统的文章来，写中学，学中写，少写流水账。
 
2016年，回馈那些信任和支持我的朋友。
 
2016年，要改变节奏，过健康、高效的生活。
 
2016年，要带monkey冲出亚洲。
 
 
—
2016年1月3日，@武汉汉口火车站

可复用的web代码结构

发表回复

1. 后端代码可复用问题

 * 业务逻辑复用

    – 一次性逻辑

    – 多种场景出现的逻辑

 

 

 * 基础功能复用

    – composer方案

 

2. 前端代码复用问题

 * CSS问题

    – 展现独立于所有代码

 * 组件复用问题

    – Webpack + AngularJS + React  [1][2][3]，其中React可能是一种很有前途的方案。具体可以看看React-Bootstrap项目就能理解。

 

 

[1] http://webpack.github.io/

[2] http://www.shmck.com/webpack-angular-part-1/

[3] http://react-bootstrap.github.io/getting-started.html#browser-globals

想起小时候一件事

发表回复

小时候，是很顽皮的。小学的时候，是有派别的。我很多时候跟那几个”最有势力“的娃儿不是”一班儿“的，特别是打架的时候。

校园里，有一根铁棒，相隔1米5的两个方形水泥柱子，就是一个单杠。为了适应不同年级身高的学生，柱子上从高到低有三个水平洞眼，需要不同的高度，就把铁棒插到不同的眼中。

单杠

  单杠只有一个，同时最多只能容纳两个人玩，孩子却有一群，于是，便生出许多事端来，最常见的，就是想独占，你不让，我便抢，口角开路，棍棒随行。

  那一日，不记得是何原因，我和一个娃儿争抢起铁棒，把铁棒从柱子中抽出来，继续你拉我扯，从操场追扯到教室走廊，然后他们一派的还加入了另一个小朋友帮忙抢，不知怎么回事，一拉一扯，我的脑袋被铁棒打中，瞬间天旋地转，昏倒。吓得老师迅速召集了两个高年级的小朋友背着我往医院赶。

  印象最深刻的是，背着我跑的时候，我觉得更昏了，就喊着说”别跑，别跑，不好过“，于是他们就改走，然而我还是觉得他们在跑，一个劲喊”别跑，别跑“。

  到了医院，被放在医生的办公桌上看了一把，被定义为轻微脑震荡，休息一下就罢了。

  不记得第二天有没有接着去上课。

  如今，那两个小伙伴都在同一个城市打工，前不久还在微信的一段小视频里面看到了他们俩。

 

 

 

 

 

 

学习SQLSTATE

发表回复

1. 什么是SQLSTATE

shell> SELECT * FROM no_such_table;
ERROR 1146 (42S02): Table ‘test.no_such_table’ doesn’t exist

上面执行一条SQL语句出错后的显示。1146是MySQL自己定义的错误码，42S02是ANSI SQL和ODBC定义的错误码，“Table ‘test.no_such_table’ doesn’t exist”是MySQL返回的错误原因。

其中，42S02就是本文要讨论的SQLSTATE

 

2. 为什么要有SQLSTATE

42S02是ANSI SQL和ODBC定义的错误码，可以理解成是错误码标准。假设没有SQLSTATE，世界会是什么样子？你开发了一款数据库驱动程序，希望兼容MySQL、Oracle、SQLServer。对于锁冲突，MySQL返回错误码2011，Oracle返回9912，SQLServer返回3231（以上3个数据为杜撰），如果你希望检查到锁冲突后，立即执行do_something()，那你需要这样写代码：

if (2011 == conn.errno || 9912 == conn.errno || 3231 == conn.errno) {
    do_something();
}

如果还希望支持Postgre，则需要增加Postgre的错误码处理。这是个悲伤地故事，不想再讲。

可见，数据库自定义错误码是靠不住的，他们各自为政。也许你会想，为什么这些数据库厂商不能协调一下，统一一下错误码呢？理想很丰满，现实很骨感。因为在某个特定数据库内部实现中，可能内部定义了四五个不同的错误码来表示锁冲突，用一个错误码无法满足内部逻辑的需求。所以，完美的解决方式是：

*. 内部，用数据库自己的错误码，爱怎么用就怎么用，当需要把这个错误码输出到外部的时候，先做一个转换，将内部错误码转换成SQLSTATE。
*. 数据库驱动程序只看SQLSTATE，忽略数据库自定义错误码。

 

3. SQLSTATE数据格式详解

SQLSTATE包含5个字母，前两位表示错误类别，后三位表示子类，均有0~9，A~Z(大写)这些字符组成。00000表示没有错误。

前两个字母定义的错误类别：

00 = 没有错误

01 = 有WARNING

02 = 游标NOT FOUND

> 02 表示某种异常，MySQL的异常，详细见http://dev.mysql.com/doc/refman/5.6/en/error-messages-server.html  这里定义了MySQL内部800多个错误码与SQLSTATE的映射

 

并不是每一个内部错误码都能明确映射到一个有意义的SQLSTATE，对于这一类内部错误码，统统都映射到HY000这个SQLSTATE上去，意思就是：我也不知道咱们这个错误码对应哪个SQLSTATE好，就这么凑合着吧。例如：Error: 1004 SQLSTATE: HY000 (ER_CANT_CREATE_FILE)

 关于SQLSTATE的格式，还有很多讲究，详细参考这篇文档，比较清晰：https://mariadb.com/kb/en/sql-99/sqlstate-codes/  


4. 数据库中如何实现SQLSTATE

可以创建一个Map，将错误码映射到SQLSTATE即可。如果错误码的规划设计正好是从0~N，或者0~-N，那么可以直接用数组来实现这个映射，错误码即为数组的下标；更通用的方式，还是用数组，只不过查找方式是二分查找，也很方便。

MySQL中的实现，详见share/errmsg.txt和include/sql_state.h 。

 

5. OceanBase中如何实现SQLSTATE

参见lib/ob_errno.cpp

可以看到，与MySQL相比，OB还多了一个负担：把OceanBase内部错误码尽可能映射成MySQL内部错误码。啥时候别人写数据库的时候能把内部错误码映射成OceanBase的啊？

 

 

 

商业的秘密

发表回复

最近发生了一些不大不小的事，老余说你应该写一写留作纪念，想想也是，站在黑漆漆的电脑屏幕前洞察到的人性，当然值得大书特书。

具体事情按下不表，得出的经验如下：

1、洞察人性最好的方法就是杀入商场，没有什么比利益的诱惑更能激发出人性的黑暗面。

2、天底下没有永远的朋友或永远的敌人，你看好的背后可能捅你刀子，你憎恨的也许反而有做事的边界。都不重要，重要的是你要想好自己的底牌和后招。

说白了，一切都是博弈。你推我挡，玩得一手好太极，不动声色之下牢牢握住自己的底牌和后招方为上策。

3、做人不能太贪婪，太贪婪什么都得不到，做人也不要太聪明，聪明反被聪明误。

4、凡做过必留下痕迹，墨菲定律是对的，你害怕它发生的往往最终会发生，所以做坏事之前自己先掂量掂量善后能不能做好，否则干脆别做。

5、渠道的力量不可忽视，不会借助别人力量来做事的人做不了大事，也永远无法成功。

 

为谁而生

发表回复

一个企业，首先要知道的是为谁而生。企业的直接客户是谁，潜在客户是谁，客户的特征是什么，这是否是一块盐碱地，还是一片蓝海？

即使是传统成熟行业，作为一个新入者，如果他还有所追求，为谁而生这个问题一定是淌出来的，而不是想出来的。

不怕路远，路难，方向要对。为谁而生这个问题想对了，路就走对了，企业的价值观也会依附于它。而这个问题想错了，企业之路必然会更加崎岖不平。

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的层次

发表回复

在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关心。

结论：

  1. 需要发送plan到B端，而不是自己裸发operator tree到远端。因为plan里面提供了一套遍历op tree（序列化）、分配operator（反序列化）的机制。相当于是一个query的管理器。
  2. 发送到B端的plan并不是一个全功能的plan，有精简的空间。
  3. plan之外并不需要传额外的东西到B端。