囧主题餐厅

这是个囧的年头,我家旁边居然开了一家以囧为主题的主题餐厅,名字还叫 – “囧囧有神”
菜单里居然有:

麦当劳的东东 价格: 原价格+5

问了一下,服务员说,他们会去麦当劳买来。5块钱就是跑腿费。

知道互联网有mashup和聚合,没想到餐厅也可以!待续。

SOA 就是 OpenAPI

两个时髦的玩意,原来就是一回事。并不是很难理解,只是大家习惯了接受各种各样新名词,而又惯性的没有去把二者联系起来。知道在wikipedia的SOA词条里看到这句话:

A mature rollout of SOA effectively defines the API of the organization.

任何系统无论是复杂的商用系统还是简单的个人博客,都在提供或多或少的服务。将这些服务分割成独立的,无状态的服务单元,然后通过HTTP(webservice)或者是其他的连接方式连起来。接下来,如何compose这些服务单元又是新的问题,ESB和BPM就大行其道了。将来有一天,用网站提供的OpenAPI进行网站之间的整合,互操作,信息交换一定会催生出更多有趣的东西。

中心思想:互联网和企业应用同样都需要整合,而且整合方向和方法应该都是一样的。

纯属YY

辩论

上周和侯斌同学在饭桌上捏起一个题目然后好一顿大辩,结果最后发现我们的自足点有真根本的不同。大抵上饭桌上这种辩论都是会引向这个结果,因为出发点比较随意。不过让侯斌同学以为我们在群起而攻击之,到真的是出乎我的意料。看似人高马大还挺“脆弱”,真的出乎我的意料。当别人将思想强加于你的时候,应该怎么做?这个是另一个话题了。

我们的话题是关于中国铁路改革的,(后来在网上搜搜看,这还是个很严肃的话题),源于我们对现在铁路运营模式的不满,我认为是垄断加上行政运营不清晰造成的进步慢(但是很客观的说中国的铁路已经做的很不错了),应该引入竞争,将铁路资源的经营权和监督权分离,然后引入私有经济。当然我不提具体的操作,也不解决具体的问题,这个前提应该是所有辩题的基本。我们可以举一些已经存在的成功或失败的例子,来反驳对方,但是不能说质问对方某某问题应该怎么解决?如果对方不能(当然不能,因为还没有发生,已经发生了我们的辩题就变成“会不会成功”,同样你可以问同样的问题),那么就认为对方说的都是无意义的。

侯斌同学反复问的问题就是“怎么分?怎么分?很不现实的。。。”,我没想到一个只比我小一岁的人的思维居然会这么保守,而且是在国外留学回来的。看来留学和见地是不相关的。其实从一开始,他就没有搞清楚到底是不是在辩论(当然谁也一开始没想辩)。我们是在探讨某件事的可能性而不是决定这件事能不能做。

当一件事还没有发生的时候,很多保守的人都会问很多具体的问题,然后要求那些革新派去回答。这是改革最大的阻力,因为我发现二者的立场和方法论就有着根本的不同。革新派的人会说我们的确会有很多问题,但是我们倾向于建立一个模型先,然后不断的修正,改进,最后达到系统的平衡和最优。保守派的方法论则是,我要一步一步走到目标,所以无论路上有什么问题无论巨细,我都要事先都解决。(虽然很多时候这种言论只是保守派用来挑战革新派观点的论调,实际情况是他们自己在解决问题时都不大会用这种方法)。

当然我不是说侯斌同学是保守派,这个帽子太高的。我们目前都还没有足够的知识去戴这样的帽子。

铁路和航空资源其实本质上是类似的,都是一种适合用寡头市场来配置的资源。政府可以将铁路使用权根据地域、流量等标准分割,然后让企业竞争某一段时间的使用权,企业需要在竞标时要做好所有关于各种目标指标的计划,当某段时间结束后,政府来看企业是否达到了政府和企业自己制定的指标,进行评估。之后再重新竞标。现在最缺的是一整套运作机制以及风险控制机制。多个铁路公司的例子最简单的就是香港的mtr和kcr(去年合并了),没有了解过很具体的铁路运作模式,所以权当yy了。

鸟巢为什么没叫“凤巢”

很多中国人可能觉得“鸟巢”这个名字有点“鸟”,按说,照中国人的思维应该叫“凤巢”。可能更让人觉得有中国特色。猜想不用这个名字是因为凤凰属火,和旁边的水立方(属水)相冲吧,而且二者又在“中轴线”上。从风水的角度也不太好吧。纯粹YY了。

API or ABI

API – Application Programming Interface – 应用程序接口

那么ABI是什么?

Application Business Interface

没有这个词,只是自己随便想起来的一个词,因为昨天看了一些关于DSL(领域建模语言)的文章.如果说程序语言是给程序员(AD)用的,那么DSL就是给业务分析师(BA)用的.

BA和AD的沟通不是那么容易,像现在这样单纯依赖AD去实现,领域知识的传递很成问题,常常是BA不知道应该是什么样子(表现为系统行为频繁变更-程序员最厌恶的),程序员想当然的去实现.
除非遇到暴牛的BA – 业务分析师+系统设计师+架构师(国内好像很多人都想成为这种”组合体”).但毕竟这种”暴牛”不是到处都有的,现实一点还是从分工上入手.

如果说API是建构在程序语言上,那么”ABI”就是建构在DSL上.
顺道说一下所谓的”组合体”,因为BA和archtect所需要的知识结构是本质不同的,BA要对某一纵向的相关行业,领域有深厚的理解,而architect可能更多的注重系统设计和广博的知识面和经验,当然领域知识也是必不可少的(但是来自自然积累).所以最好还是不要期望往这种组合体上发展,毕竟鱼和熊掌,如果能在某一方面有所造诣就已经很不错了.

就好像从前大家都要渡河或者在岸边喊话来沟通,现在DSL怎是在河上建一座桥,两边的人可以随时沟通交流,而且也不容易出现沟通上的偏差.也许再往后,大家会觉得桥(DSL)太多了,浪费了很多钱,于是筹钱建一座大的,也许就是Unified DSL了.