再见 申江服务导报

今天听到说,申江服务导报,要停刊了。

的确是从前一段非常难忘的回忆,印象中这是一厚摞的报纸,虽然广告很多,看看也很好玩,里面内容也是五花八门,什么都有。虽然大学时代已经习惯看计算机世界、中国计算机报这样的厚厚一叠,体会完全不同。

2001年,刚到 Chinapay 的时候,应该是每周二吧,总有同事会买,我倒是偷懒,就借同事的申江看,反正厚,分着看,没问题。怀念那段开心的可以分享申报的时光。

一切总是这样离去,感觉突然,回忆都是十年二十年为单位,让人为难。

再见,申江服务导报!

 

今年的作品

从三月份立项开始,中间有几个月略有停滞,加上压力很大的工作,几乎所有的晚上的业余时间和周末,都耗费在今年的这本书上,很高兴和阿里云的伙伴以及身边聪明、勤奋的同事一起,撰写这本书。

如今,终有小成。在设定这个提纲之初,实在对自己有所高估了,这本书是按照道法术器的结构来编纂的,因此有些内容的深度超过我们的想象,写的比较辛苦。同时,IT 书籍怎么写得比较生动,但是又不能流于肤浅,也实在是个难题。希望这次的探索能够让读者届时有所收益。

在长达 8 个月的写书过程中,还有着几方面的变化:

  1. 我自己的思想在发生变化,有的更加成熟,也有一些新的变化;
  2. 阿里云的产品还在不断演进升级,伴随着我们的实践,有很多新的实践方式;
  3. 公司在发生的变化,业务系统、实践理念、组织结构等都有一些令人兴奋的变化,对于我们的理解有促进,有反思。

很早就发现自己是个矛盾的合体,有时候激情洋溢,呼朋唤友,高谈阔论;有时候也是静如处子,在从小就喜欢的程序的海洋中游弋,也不知疲倦。

金庸大侠 一路走好

想起来,这才是我的大偶像啊。

前周和新员工培训,提到倚天屠龙记,提到金庸。

没想到,金大侠今天就离我们而去。

初中时候,看的第一本金庸的书是“连城诀”,好像是班会的时候吧,调皮的我们。

有一次放学,有个同学在看“天龙八部”, 和他一起从序言开始看,看到天昏地暗,实在不敢不回家了。

高一军训,有同学带了四本盗版的“笑傲江湖”,于是我们一人一本,分头开始看,其实拿到第二三四本的人,比如我也是,根本搞不清楚在说什么,还被军训的排长抓到,被臭骂一顿。

工作没几年,当年还在用易趣,从网上买了一套金庸全集,一个人到南市区卖主的家里去拿货,虽然那套书不在我身边了,记忆犹新。

以前每次做大项目前,都要看金庸的书,最近一年又重新看了“倚天屠龙记”、“神雕侠侣”等,每次看的都是心潮澎湃。

人生多么有趣,不知道明天会发生什么,且谁都不能永生。


2018.10.31 后来又想起初中时候爸爸从香港带回三本一套的“碧血剑”,竖排繁体字,也是硬着头皮看了,与“连城诀”谁前谁后,已经无法考证了。

忘记他是她是那么样

下午,写东西的时候,习惯性的放音乐,习惯用网易云音乐。

网易云音乐的确做得很成功,特别是他们的评论,很有趣,很煽情。

我喜欢在没有满 999 的歌曲下面做评论,也算是一种小小的癖好吧。

突然发现,达明一派的歌又出现了。

自然,忘记他是她是不会被淹没的。

1989年,现在看来当时的猜测都是对的,果然说的明哥的取向问题。

这么玲珑的歌曲,或再难有了。

想起超人

偶然在爱奇艺上看到新版本的超人电影,好像还有好几部,其实也看过几遍了,不过总不如当年第一次看到电影超人时候那么震惊。

记得大约是初二时候,所谓的内部片吧,我是跟着姑妈姑父去看的,震撼,对于特技、对于故事,对于超人!

兴奋的不得了,看完电影居然在地摊上买了一个 TOFEL 的单词书,虽然之后几十年没有翻到过第二页。

今天给新员工培训,说了很多,感觉说的有点多了。或许是在他们身上,感受到一点自己当年的影子吧。

记得2011年的那个冬天。

人么,总还是要有点情怀的。

2018 第二次美国之行

十四个小时的飞行,说不累是假的,回到家,还是立刻吃了正宗的中国菜。

美国的确是地大物博,太大了,去的时候先到 LA,再到 Vegas,差不多就两天时间没有了,还是要把身体锻炼好,开车如果4小时可以到达的话,做他们的国内飞机不太划算。

走出去,才能看到更多,不管好坏与否,才能感受一下。

在 LA 的主要行程就是参观,Getty Center、历史博物馆、格里菲茨天文台,都不错,科普教育这方面,美国还是非常领先。

碟中谍 6

阿汤哥真的是拼啊。

怎么记得看碟中谍1,好像是20多年前了,盗版的 vcd,关键是第一遍看完没有看懂,那时候脑子比较简单吧。没想到是这样的好中有坏,反转反转,以及当时看的目瞪口呆的易容术。也还记得当时逛淮海路时,看到国泰电影院这里大大的广告。

以及第一部中,惊为天人的女演员艾曼纽。

作为一个没什么音乐细胞的我来说,碟中谍的电影音乐只要想起几个音符,就不会听错。

没想到一部一部,阿汤哥已经不那么年轻了,但是越来越拼了,故事也很精彩,怪不得网上有评论说,比007系列还要精彩。

电影中的感情描写也是胜过绝大多数动作片的,每个人在世界上都有自己的定位。还有么,有些往事就是往事了。

世界在巨变

有时候,我已经完全放弃了预测未来的想法,世界变化太快了,或许因为互联网,或许别的原因,或许是自己的年龄关系。感觉就是世界变化的太快了,而我只想守住自己内心的平静。

但也很难,那么多诱惑,那么多让你无奈的事情。

最近几年,还是很高兴自己有所改变:

1 上下班坚持走路或者公共交通,尽量不开车。平时大约每天可以走到5000步左右,和很多人比还是不足一提,不过自己感觉身体机能已经略略提升了。
2 每周看一本书,十几年了,继续坚持。
3 坚持写作,只能说在技术人员里面,文笔还算不错的了,blog 写的少了,因为这几个月在准备一本新书,到了最后冲刺的时候。每天不写一些,有点难受了,我想这绝对是个好习惯。
4 对物质的欲望降低很多,发现美亚的账号已经大约三年没有买过什么,包括其他电子设备,不知道使它们越来越耐用了,还是我真的控制了购买的想法,断舍离是说说容易做到很难的。我一条牛仔裤穿了四年,几乎所有场合,几乎每天,终于破的不太行了,所以又上美亚买了两条,那么估计还可以穿个八年至少。
5 对情绪的控制,那么多麻烦事情,发火或者各类情绪还是不可避免,情绪不过夜是肯定的,现在基本上不超过1小时也就淡然了吧,不过最好是不发脾气,喜怒不形于色更好。这个东西,真的是要历练的,经过的事情多了,自然会好些。

旧文:DSL 初步的设计和探索 1-3

(2018.7.18 7.31 最近半年,关于 DSL 的研究已经有了我们认为的重大变革和场景突破,我们的 DSL 已经可以直接支持 Python 脚本,并通过生成中间语言 IC 的方式来最终通过运行 IC 来生成终极产出物。等这几个月写作的债还了,好好思辨和分享一下。下面的文章作为之前探索的记录。)

你知道 DSL 技术么?我认为 DSL 是适应目前多变的业务需求和需要稳定的底层系统的一座桥梁。

DSL,Domain Specific Language,领域特定语言。

DSL,是否可以简化常规开发的复杂度?到底是否存在终极武器?从 dos 年代到现在的云,开发越来越复杂。

开发一个可视化的 web 系统,来完成一些业务场景的定制,其实是非常耗费资源的。简单的例子如报表中心,每一份报表需要定义数据来源、呈现格式和计算规则、查看权限等,通过程序来实现这些功能,提供给报表制作人员的确是一个很好的注意,很多的报表类产品也是这样做的,但是我觉得这样系统的复杂度以及本身要考虑的细节非常之多。我们之前使用过 Oracle 的 BIEE,功能强大,但是用户体验很不好,造成的结果是制作一个报表的时间很长,如果需要修改的话,大部分的业务逻辑需要使用报表的人员向制作报表的人员提出,周而复始。面向大众的软件,即便是 Microsoft Office,也是需要学习曲线的,并且微软基本上也不会为用户来做功能定制,因为 Office 软件有强大的 VBA 来完成这些。

我们要做一个报表系统,但我们不是提供一个可视化的编辑系统,也不提供复杂的数据库连接工具,当然也不需要用户有太多 SQL 的知识。用 DSL,提供一种简单的接近自然语言的描述,然后通过解析,生成用户所需要的报表。我们开发这个系统的工作量主要是设计 DSL 以及解析引擎,当然一个包含主要功能的外壳还是需要的。实际上,我们已经在一些报表呈现,传统上所说的 Dashboard 上进行了实践,从概念到如今,也有四年之久,在最近的一个项目中,通过还略显粗糙的 DSL,从数据库连接到界面呈现,都自动化完成,传统意义上制作页面、切页面、写 SQL 都通过 DSL 的原理基本半自动化了。很感谢这些聪明的同事们。接下来的挑战自然越来越大。如何构造一套更加容易使用的 DSL、用在更加复杂的场景、提高解析效率等。只是用 DSL 来构造用户界面、固定的用户操作以及数据库连接,我们不太满足。

说说容易,以上这些是对于业务系统设计多年的反思,除了耳熟能详的那些中间件和越来越成熟也越来越复杂的云技术以外,系统业务逻辑的复杂和多变是事实,人工智能除了人脸识别以外可以做的事情太多了,而大数据不光是 hadoop 这六个字母,他们是真正的自动化、推理、演绎的基础。

为什么我们会想到要用 DSL 呢,最早是在制作很多产品的控台的时候,一个产品需要一个给商户使用的控台,一个给内部人员使用的控台。

然后带来以下的问题:

相似的页面的重复制作,虽然用了 MVC,但是不同项目的定制依然存在,一个新项目的流程时间还是长,对于一些查询条件和显示的改变的修改和测试耗用了很多资源。
和数据库的连接部分,需要对数据表有比较清楚的了解,数据库部分发生变化,会导致从后至前的不少修改。
和传统开发项目一样,从产品经理-项目经理-程序员-测试,整个过程耗费时间,且修改总是容易引入新的错误。
我们将控台系统分为:

web 界面
接口层
数据库
web 界面层通过调用接口层来完成业务逻辑,接口层读取数据库来进行数据库操作。

整个基于 DSL 的设计流程如下:

使用 DSL 描述 web 界面,能够描述界面包含的元素。实际上,界面模板是固定的,另外制作好,我们需要填充的是左边栏的菜单,右边栏需要哪些标签、文本框、日期选择等,以及显示查询结果的表格。
我们有一个通用的 DSL 的语法检查器和解析器。根据我们预定义的 web 规则检查语法,然后将其再解析为 html 代码片段,便于填充到界面模板中。除了 html+css+js 以外,同时生成调用接口获得数据的 php 代码。
目前的 DSL 除了 for web 以外,就是 for sql 了,通过 for sql 的 DSL 来生成 sql 语句,然后通过另外一个通用查询接口,获得数据。
这个通用查询接口输入为 sql,输出为 json 的数据集,怎么和数据库连接,具体数据库位于哪里等细节都被隐藏起来,通过配置文件来设置。
应该说,开发这样一套系统,其实工作量并不小,有以下的好处:

一旦开发完成后,用其生成的系统,因为将业务逻辑和数据库逻辑做了彻底的分离,因此很多的修改变得非常容易,真正的通过 DSL 就可以修改业务逻辑。业务程序通过 DSL 来调用 DSL 的解析器,这些都有 Restful 接口实现,也算是一种专注于自己业务逻辑的准微服务架构。
复用性。在开发第二、第三套系统的时候,我们就会享受到这样设计的便利性了,特别是前面说到,类似于控台这样基本框架一致的系统。只要后台提供接口,通过 DSL 、html 模板等,访问数据库或者访问接口。有了这样的引擎,大大减少重复的工作量。
这算是我们对 DSL 来简化业务系统流程的初步思考,之后会再举例。而我们对于 DSL 的思考这还是第一步,我们也不满足这类技术只能做相对简单的控台。

DSL 是一个好东西,之前几年零零星星的只是探索,虽然也用在了一些项目中,但是总觉得有些不完美。

首先我们定义了一个 DSL 的语言,称之为 r2,r2的解析是通过一个配置文件来定义语法,r2从某种程度上更像一个命令行的定义工具。

然后我们将 r2的解析器和编译器分别定义为 c1和c2,c1是负责解析语法,根据配置文件,配置文件定义了所有参数的名称、允许值类型、允许值范围等;c1会将解析通过的 r2命令生成 json 格式对象,然后 c2会将这个 json 根据业务场景来生成sql 语句或者 html 等。我们目前的应用场景就是 sql 的生成和 html 网站的生成。

r2 作为 dsl 的问题在于:

r2的问题在于虽然形式上和一般的命令行没有差别,但是还是需要学习的。
r2的配置文件虽然可以定义各类需要的参数和取值范围,很灵活,但是其定义还是有不低的学习曲线。
因为 r2是类似命令行的方式,所以缺乏基本语言的判断、循环、分支等,更不要说面向对象继承等这些了。
c1的问题:

配置文件随着语法表现力的需要的增强,解析复杂度陡然上升。对于 sql 和 html 这样的互相关联性不强的场景还可以应付,但是如果要把 dsl 用在业务逻辑的描述,c1已经显得有点力不从心。
c2的问题:

目前 c2在实现 sql 和 html 的生成时候,用的是基于模板的配置方式,实现上还是比较复杂的,从中间状态 json 到这些最终文件,这里是借用了一些编译的基本原理,问题是 json 描述 key-value 的确不错,但是对于语法的描述就比较弱了。
综上所述,我们继续探索新的 dsl 的实现方式和更广阔的应用场景。

ps

2015年用了半年业余时间,开发了 r2的定义和 r2c1,然后其他同事继续开发了 r2c2等,2017年,同事们将 r2这个 dsl 模式应用到一些业务场景中,这三年,对我们来说,还是走出了艰难的第一步。从2015-2016年中间,还是浪费了一些时间,当时一些同事对于 dsl 整体的理解或许还有所欠缺。所以不管之后怎么继续,先用这些文字来将思想统一。