可复用的web代码结构
1. 后端代码可复用问题
* 业务逻辑复用
– 一次性逻辑
– 多种场景出现的逻辑
* 基础功能复用
– composer方案
2. 前端代码复用问题
* CSS问题
– 展现独立于所有代码
* 组件复用问题
– Webpack + AngularJS + React [1][2][3],其中React可能是一种很有前途的方案。具体可以看看React-Bootstrap项目就能理解。
[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的啊?
两个小朋友的创业
疲倦
最近突然有了岁末年初的疲倦。连着两周,一场接一场的生病。身体似乎一下到了负荷的临界点。
目睹了太多的污秽与丑陋,只想关掉和世界连接的窗口找个地方静一静,休息休息。
前段时间老余问我,有没有在这种沸腾燃烧之后沉静下来想一想,自己又没有错过或失去什么。当然的我踌躇满志,意气风发的说,没有!
昨晚,一个人坐在沙发上,心神不宁的看着电影,突然发现,我已经很久都没有坐下来看一部电影了,这个我曾经自诩为人生最大的爱好的事我居然很久都没做了。
我用力奔跑着前进,来不及也顾不上看身边的风景,我得到了一些想要的,也得到了更多不想要的。
老余的问题是有深意的,是的,我想我已经失去了它们。
【商业的秘密】2015年1月review
1月份过去了,这一个月学到的做到的感受到的比去年一年都多。记录一点感受在此:
1、1月份主要的业绩集中在一个高ARPU值的模块产品上,用户数减少,但收入增多。可见产品的定价策略很重要。定价可以传递出极其丰富的信息,对于产品的格调、筛选用户、提高收入、降低成本都有着非常重要的意义。
2、在销售方面,是否还要采取走量的销售模式值得思考。理想的方式是通过提高定价、丰富服务内容、丰富功能层级的方式包装出不同的价值的产品,销售给不同需求层次的用户。比如:基本版、升级版、黄金版等等。减少产品的销售量,提高每个用户的服务质量。
3、逼格非常重要,产品不必迎合所有人的胃口,而应该去寻找真正理解产品价值的用户,他们能把产品玩出花样,实现甚至提高产品的附加价值,这样也是间接为自己的产品树立了范例和标杆,是良性循环。
4、产品盗版问题,首先对于盗版产品,发现了应该给予坚决的回应,这个是一个维护自己声誉和原创精神的机会,借由这种回应可以做很多事件营销活动。一方面是博取公众的同理心和同情心,另外一方面是广告效应。其次要从技术方面去做防范,不要顾虑有人会见招拆招就不去做。技术上的防范可以让盗版商产生一定的忌惮心理,但最主要的是这样做是给已经付费的用户立一个姿态,你对于他们的权益是很重视的。
5、题外话:多和人聊天,在聊和交流的过程中会得出很多新的想法,碰撞出火花是一定的。另外应该思考,在团体合作的时候,如何能用机制去规避或防范人性的贪婪和欲望,虽然,这个可能是永远无解的难题。
商业的秘密
最近发生了一些不大不小的事,老余说你应该写一写留作纪念,想想也是,站在黑漆漆的电脑屏幕前洞察到的人性,当然值得大书特书。
具体事情按下不表,得出的经验如下:
1、洞察人性最好的方法就是杀入商场,没有什么比利益的诱惑更能激发出人性的黑暗面。
2、天底下没有永远的朋友或永远的敌人,你看好的背后可能捅你刀子,你憎恨的也许反而有做事的边界。都不重要,重要的是你要想好自己的底牌和后招。
说白了,一切都是博弈。你推我挡,玩得一手好太极,不动声色之下牢牢握住自己的底牌和后招方为上策。
3、做人不能太贪婪,太贪婪什么都得不到,做人也不要太聪明,聪明反被聪明误。
4、凡做过必留下痕迹,墨菲定律是对的,你害怕它发生的往往最终会发生,所以做坏事之前自己先掂量掂量善后能不能做好,否则干脆别做。
5、渠道的力量不可忽视,不会借助别人力量来做事的人做不了大事,也永远无法成功。