之前JBoss拒绝了IBM和Oracle两个大佬,看来文化的认同和商业模式的匹配更为重要。
另外一方面,Redhat和几个巨头的关系开始微妙起来。在这之前,Redhat是以IBM为盟主的反微软阵营扶植起来的过河卒。这次闯入企业级中间件市场,意味着会与以前罩自己的老大发生正面冲突。
把最近频繁的收购联系起来看,大鱼开始吃小鱼,软件市场空间在缩小。谁能幸存成为战国七雄?
之前JBoss拒绝了IBM和Oracle两个大佬,看来文化的认同和商业模式的匹配更为重要。
另外一方面,Redhat和几个巨头的关系开始微妙起来。在这之前,Redhat是以IBM为盟主的反微软阵营扶植起来的过河卒。这次闯入企业级中间件市场,意味着会与以前罩自己的老大发生正面冲突。
把最近频繁的收购联系起来看,大鱼开始吃小鱼,软件市场空间在缩小。谁能幸存成为战国七雄?
回到北京后杂事很多,看生物信息的论文,还看完了《基因组:人种自传23章》,暂时把《Modern C++ Design》放下了。昨晚没写BLOG,看完了剩下的几章:Object Factory、Abstract Factory和Visitor,这几个模式的Policy不多,相对简单。
泛型技术没有想象的那么难,只要把前三章的基础啃下来了,后面都是应用。设计模式不是教条,而是根据实际情况调整的策略。C++0x标准放弃Loki的智能指针,而采用Boost的auto_ptr和shared_ptr,不喜欢
MySQL终于对Oracle咄咄逼人的收购攻势做出反应,收购了Netfrastructure, Inc.,也就是Firebird(开放源码版的InterBase)创始人Jim Starkey的公司。
看看Jim Starkey给Firebird社区的公开信,提到Netfrastructure和Firebird几乎不可能融合,暗示MySQL此举不是针对Firebird的。众多回复比较好玩,比如Cantu这么写:
| I’m not sure about what exactly will be Jim’s work at MySQL, but look:
1) Oracle bought InnoDB Both are used as “enhanced” MySQL engines, offering Transaction Control and other “advanced” features to the basic MySQL. Now MySQL AB gets Jim Starkey, a man with great knowledge of how to implement all of this “hard stuff” (versioning, transactions, etc). Will MySQL start their own “enhanced” engine? Will Jim lead this work? Was MySQL worried about Firebird 3? Just some thoughs… |
《史记》里有一段:孔子得知齐国要进攻他们鲁国,就派子贡到诸侯中间搞风搞雨,居然挑动齐、吴、晋几个大国群殴,搞得个个灰头土脸。最惨的倒霉蛋是吴王夫差,连续打背靠背的客场比赛,却被早就卧薪尝胆的越王勾践抄了后路,弄到灭国……反而是弱小的鲁国安然无恙。说起来,这段历史的前因后果很有戏剧性,牵涉到不少大名鼎鼎的风云人物,比如恐怖分子专诸,女子特种部队指挥官孙武和他的《孙子兵法》,悲情复仇叛国者伍子婿,美女间谍西施,下海从商创业成功的前政府官员范蠡,以及两者之间的八卦恋情,还有死抱铁饭碗最终兔死狗烹的公务员文种,再加上孔圣人一门的外交手腕,很适合拍电影……停,扯远了。
Oracle的死对头SAP开放MaxDB源代码送给MySQL,两者结盟针对谁不言而喻;于是刚结束PeopleSoft吞并战,Oracle就转过头来买下InnoDB和BerkeleyDB,断了MySQL的粮道;没想到MySQL不肯下嫁,又抄了Firebird的后路……后续剧情上演中。猜猜看,到底谁会是吴王夫差?
现在可用blog.joyfire.net访问我的BLOG页面,用rss.joyfire.net订阅RSS种子。
joyfire.net的ICP备案刚通过。注册了joyfire.org、lehuo.com、lehuo.net、lehuo.org、lehuo.cn、lehuo.com.cn、lehuo.net.cn这几个域名,目前都转发到joyfire.net。停顿两年后,joyfire.net再次启动,大家多支持:)
补:事实证明备案也没用。目前这几个域名还没有被转到海外,还不可用。我正在办理。
以前提到过,GFS分布并行、高度容错、海量I/O、“重”插入查询“轻”删除、面向廉价PC集群的特点,很适合生物信息方面的应用。
最近构建在GFS基础上的BigTable受到关注。简单地说,BigTable提供稀疏表形式的数据存取服务,除了拥有GFS的原有特点,更适合存放半结构化的数据。所谓半结构化数据,和关系数据 库的表一样是二维的,有字段(列)和记录(行)的概念,但每个字段不限制长度,适于存储HTML和RSS(XML)。而生物信息应用中,肽、质谱、酶、修 饰等都是由一组或多组不定长字符串表达的半结构化数据。
Google进军生物信息领域,看似隔行,其实门槛很低,因为原有核心竞争力在此领域同样有效。
到海外发展的职业球员一般在转会第二年遇到瓶颈。对于系统分析员有个类似规律:小心进入新领域后的第二次设计。
刚涉及陌生领域,战战兢兢,因此放低期望值,尽量采用熟悉可靠的设计和技术,遇到变化能容忍妥协。而到了“第二个赛季”,虽然客观上面对前一版剩下的“难啃的骨头”,但由于对领域知识有所了解,半瓶水晃荡,需求分析时就会有意无意添上很多漂亮但不重要的内容,设计时也总想用时髦的新技术弥补上一版的遗憾……眼高手低往往搞砸。就连成熟的大公司开发的软件产品,“2.0”都是危险阶段。
到目前为止,在生物信息组的工作还算满意,但接下来进入深水区,必须加倍谨慎。
找到BUG就好象发现孩子得病,你提醒他家人一样,人家只会感激你。
1. 软件作者和你一样,都是追求完美注重细节的人,都希望自己的作品不断改进。
2. 老板不会用BUG绝对数量衡量工作成绩。开发的代码越多,越重要,发现的BUG机会自然就越多,一行代码不写就没BUG了,没人用的代码也找不出BUG。
3. 修正BUG会增加作者的工作量,这没那么郁闷,可以往后排进度或找人帮忙;就算实在没时间,至少可以明确“这里不完美”。
4. 也许这不是BUG?没问题,你不会丢面子或者让别人感觉爱找麻烦,BUG等级里本来就设置了“可疑”,提出问题,说明你认真对待这个软件,我很高兴可以多交流。
5. 真的很感谢你关心我的工作成果,这太好了,我宁愿和挑剔但负责任的客户打交道,也不愿意碰上没有进取心的家伙。请参考第1条。
我就是负责整个系统的工程师,最终梦想是实现世界上最好的软件。我很乐意改进自己的代码,也很乐意帮同伴改进他的模块,但首先,请帮个忙,告诉我BUG在哪。
前一阵传统媒体和网络的关系是焦点。我开始系统地收集订阅BLOG种子以后。
以前通过《程序员》杂志跟踪最新的技术趋势,每个月读的时候都有种兴奋感。但是最近两期买来一看,40%以上的内容都已经发表在作者的BLOG上了。
《经济观察报》是新浪的合作伙伴,每期新闻都能上网看,这并不影响我周末去买报纸,因为喜欢他们的社论和专栏。但是,自从订阅了“思维的乐趣”,很多小品和书评第一时间就能看到,阅读报纸的乐趣就减少了。
除了速度,BLOG代表个人,不掩饰身份,所以读起来很有现场感;而发表在纸上的东西,总会尽量修剪个人化内容,不好玩。
客观中立?我可以多定几个种子,罗生门,看看甲方乙方各持一词,一样可以做出自己的判断。
BTW:粘贴一段不相关的文字,无论以前的报纸专栏,还是现在的BLOG,我都是许知远的忠实读者:
| “……是什么导致了明朝的崩溃,它拥有百万军队,而北方的满族入侵部队不会超过十五万人?大清帝国在19世纪中叶仍占据着世界1/3的 GDP,却为何在西方的挑战面前束手无策?这种问题必然拥有复杂的答案,而且永远相互争论不清。但一些意外和重要的因素却经常被忽视掉。如果不是全球白银 的供应量在17世纪时骤然减少,或许明朝不会覆灭得那么快,在一个所有税收都以白银结算的经济体制中,拉丁美洲白银产量的减少,将使中国百姓的压力陡然增 加,而且这一事件可能也与西班牙的衰落不无相关系,这个海上的帝国与由盛转衰几乎明朝的的覆灭同时发生。在解释十九世纪的清朝中国时,这一点不能忽略:正 是人口在过去一个世纪的倍增,才使得整个帝国的压力剧增。生存环境的紧张感可能比外来者的到来更加令人不安。同样,你也可以说,通货膨胀可能与毛泽东的军 事战略一样,在击败国民党的统治时发挥了不可磨灭的作用。……” |
读The Software Architect’s Profession An Introduction时,贝聿铭设计卢浮宫博物馆的案例给我留下了很深的印象。今天在书店看到一本Conversation with I.M.PEI,买回来看。
有很多有关构造技术(Firmitas)的内容,比如材料、光线、形状、结构;也少不了设计美学(Venustas)的描述,比如 儒家思想、西方音乐、纪律和热情、人际关系甚至政治;但毫无疑问,贝聿铭最关注的是对结构功能的需求(Utilitas),更确切的说,就是建筑和人的关 系:建造者是谁,拥有者是谁,使用者是谁,浏览者是谁,评论者是谁……架构师不应该为了设计而设计,所有的技术方法和设计模式都是满足功能需求的手段。
有很多戏剧性的对比:
软件业从建筑业学借鉴了很多的东西,甚至直接拿来了Architecture和Pattern这样的词汇和思维方式。但还不够,尤其是在把握Firmitas、Venustas和Utilitas三者关系上,需要更成熟的原则。