从 information_schema 到自动生成的 web dao

一般的 web 项目大概会被分为这么几层: > dao/model > service/logic/repository > controller > view 大多数项目会做前后分离,所以后端作为 api 就剩下了三层。实际上这三层里除了 logic/service 之外都和具体的业务逻辑没什么关系。controller 负责参数绑定/校验,dao 负责和存储打交道。之前在 ast 一文中已经讲了怎么样减少 controller 中的工作。这里来说说怎么能够自动生成 dao 层代码。 可能平常只在固定的框架和 orm

golang 和 ast

大多数编译型的语言都逃不开词法分析,语法分析(语义分析)、编译链接几个阶段。学生时代如果学习过编译原理,啃过龙书,接触过 lex 或者 yacc 的话,一定还对当初要求一周做出一个编译器这种任性大作业的噩梦记忆犹新。编译原理这个领域本身有一定的门槛,随便给你一段程序,你也不太好说就能很快地给出一个可用的词法分析器语法分析器(里面还有相当的体力活成分)。 幸运的是,我们抱到了亲爹 google 的大粗腿。在 golang 里官方已经提供了一套非常友好的词法分析和语法分析工具链。可以很方便地帮助你得到你想要的语法分析的结果:ast。有了 ast 我们就可以上天了(笑。正经点说,是我们可以基于 ast 做很多静态分析、

分布式锁

大多数应用开发人员(特别是php开发人员,不是我黑php orz)对锁可能都没什么概念,如果说有,那大概也只知道数据库 transaction 里的锁。即使是知道 db 的锁,了解也非常得粗浅(比如去年的我)。 实际上数据库的锁非常的复杂,和 os 的锁的概念完全不是一回事,具体实现还和存储引擎、事务的隔离级别相关。所以这里还是不谈这个orz。等我有机会总结了之后再说。 我们这里要说的是分布式锁。分布式锁是什么呢? 在分布式系统中,某个任务可能会因为正确性或者效率两方面的考量,在同一个时刻内只允许一个实例执行。 正确性 :例如有个游戏,每天凌晨0点,向所有玩家发放20金币的奖励,防止玩家输光了家当对游戏失去性趣。注意了,

关于go的包管理

以前在给开源项目贡献代码的时候,遇到过因为 golang 的 import path 导致的问题,详细可以参考这里 [http://xargin.com/egg-hurting-golang-import-problem/]。 由于 golang 本身没有像 java 或者 java 的儿子 javascript 那样集中式的包管理方式,例如 maven/gradle 或者即使是稀烂的 npm。便导致了 import path 里有各种网址开头的包。github.com/xxx/

业务系统错误设计

最近和同事讨论了几句错误设计的问题,感觉有必要写写自己的看法。 举几个例子,一般你的系统在运行的时候可能会有下面这些种类的错误/失败发生: > 依赖组件挂了,可能是 db,可能是 mq,可能是 cache > 依赖服务挂了,可能是别人给你提供的 http/rpc 服务挂了 > 可能是你的依赖方超时了 > 可能是调用方的参数有问题 > 可能是调用方的参数无法正确地通过校验 > 可能是用户的某种操作在业务逻辑上不具有合理性,不能够接着让他执行下去(例如你就给他一天一次抽奖机会,他不知道从哪里拿来的链接或者api又向你发送请求 > 还可能是程序自身出错了,比如数组越界,对字符串和数字进行加和操作,或者是把 null 当成了某种合法的数据结构,通过点或者下标来获取某种属性 上面这些情况都是有很大概率发生的,当这种情况发生的时候,