作者文章: Fenng

从选择 Java 框架谈谈技术人员的”舒适区”

[前言: 技术人员的舒适区是本文的要说的一点内容, 至于 Hibernate 是否优秀, 那是”专家”才有资格讨论的问题]
这几天, 一位 DBA 朋友很是苦恼. 起因是他所在的开发团队的架构师与程序员准备在接下来的项目中继续采用 Hibernate 作为 Java 框架 . 众所周知(有人说,他没有听到过类似的说法, 所以不能是”众”), 从 DBA 的角度来看, Hibernate 对 DBA 来说如同噩梦, 非常的不友好, 所以 DBA 极力推荐 iBatis . DBA 看来, 在该应用场合下, 应用 iBatis 更容易控制数据库的性能, 而程序员们也不用因为性能低下的 SQL 而一遍遍返工修改程序. 可是开发人员们罗列了各种 Hibernate 的优点证明使用 Hibernate 将会是正确的, 带来的开销是值得的.
DBA 也知道, 在过去几年的时间里, 这个开发团队一直在使用 Hibernate , 开发人员熟悉 Hibernae 的方方面面, 他们自认为针对 Hibernate 有足够的控制能力, 不愿意离开现在的技术环境, 这才是他们反对更换到其他环境下的主要原因.
当然, 今天我不是要比较这两个框架的优缺点. 而是要说说技术人员都会面临的一个很有趣的问题:舒适区.
最近几年, 舒适区这个词我们经常从一些”培训大师”的口中听到,引起了无数渴望成功者的共鸣.其实说的倒是自古以来人皆有之的一个共性.

引用I : 现代西方认知心理学认为”舒适区” (Comfort Zone)是指人们一定限度的感知和联想的范围,在这一范围里,个人或集体能有效地运作,不会出现不自在和恐惧,所以人们会本能地寻找自己的”心理舒适区”。

从”舒适区”的角度上看, 架构师/程序员不愿意更换到其他框架下无疑也有一部分心里因素的问题. Hibernate 已经使用了几年, 对他们来说已经相当熟悉了, 迁移到其他环境下不确定性因素很多, 这样”不确定性因素”给他们带来了不安全感. 所以, 他们自然会熟记 Hibernate 的各种优点, 并期望一直使用下去.
不过换个角度上看, 这种保守性无疑在需要快速面对变化的软件业有一定的风险.

引用 II: 每当人们处在舒适区中,就会有安全感、自信心,觉得自己能够胜任所担当的一切。但如果长时间 处于这样的状态,就像留恋在温水盆里游泳的青蛙一样,等有一天自己想跳出来时却已经太迟了!

就拿这个 Hibernate 来说, 最近就有 FireStar 软件公司在指控 JBoss 公司的 Hibernate 3.0 软件侵犯了其连接关系数据库与面向对象的软件的技术专利, 如果 FireStar 胜诉并要求停止开发该软件, 依赖于 Hibernate 的程序员们该怎么办呢? 这个事情就好比青蛙泡在缓慢加热至沸腾的水中一样,代价恐怕是惨痛的.
作为技术人员, 积极的心态面对变化是必需的. 如果死死的守住一个小技术环境, 回报率自然会下降. 从软件业的发展来看, 也是这样.
oops, DBA 也不要把自己捆在一种数据库上……
–End.
–Updated:
针对 一本正经地道听途说 的回复:

我说的“众所周知”的”众”指DBA 而言, 当然,如果用你没有听过就不算”众”倒也说得过去.
你应该不是DBA吧 ? 从一个开发人员看问题,自然是另外一回事。我们曾经面临这样一个案例: 数据库执行计划走错, 需要修改 SQL, Hibernate 上作这样的修改,并不是很快捷(因为不是直接的数据库SQL, 当然现在的 Hibernate 3.0 支持naive SQL 了)。这个案例,如果放到 iBatis 上,可能只是几分钟的事情. 或许,你已经把 Hibernate 玩得灵活无比, 做起变更灵活无比, 那只能说佩服了。真希望每个项目中的人员都能够有这样的天才.
另外,也不一定是 Hibernate “专家”才可以发表评论. 每个人看问题的角度不同. DBA反对 这个东西,或许有他的理由(正如那篇Blog讨论的”舒适区”) . 不要忘了,一个领域是所谓的专家,可能另一个领域就是新手.
或许你认为别人没引用英文信息就是”道听途说”, 那么 “主观推测’ 算什么呢?

7-Zip 罢工, 系统也闹罢工, 我也罢工了

突然发现我笔记本上的 7-Zip 不干活了. 随便选择一个目录, 右键 “add to archive” 之后什么反应都没有.
搜索了半天, 没有找到任何有效的信息. 这几天笔记本就频繁出问题. 先是 Windows 登陆特别慢. 输入密码后, “正在加载个人设置” 要等将近两分钟。
查杀木马, 病毒, 没发现。
注册表翻了个底朝天, 最后还真找到点问题: npkcrypt 服务启动失败. 据说这个 npkcrypt 是 QQ 的的键盘加密程序, 有病毒的性质。还是上次找一个同学的联系方式,临时安装了一下 QQ ,没想到就中了招. 把这个问题解决掉. 登录慢的问题还是没有解决.
最后只得怀疑显卡驱动程序有问题。Log 里能看到: ati2mtag BIOS TV signature not found 之类的字样.
Windows 用一段时间总会有这些莫名其妙的问题, 一向自认为自己还算有点安全意识, 可还是防不胜防.
什么时候用 Linux 作桌面工作站或许会好一些 ?
今天很巧, 好几个同事的笔记本都出了问题,有硬盘坏的,有风扇坏的,难道都是天热的问题 ?
不管这么多了,明天随团队黄山 Outing. 有三天的时间可以离开电脑,离开网络。放松一下.

了解一下 Technorati 的后台数据库架构

Technorati (现在被阻尼了, 可能你访问不了)的 Dorion Carroll2006 MySQL 用户会议上介绍了一些关于 Technorati 后台数据库架构的情况.
基本情况
目前处理着大约 10Tb 核心数据, 分布在大约 20 台机器上.通过复制, 多增加了 100Tb 数据, 分布在 200 台机器上. 每天增长的数据 1TB. 通过 SOA 的运用, 物理与逻辑的访问相隔离, 似乎消除了数据库的瓶颈. 值得一提的是, 该扩展过程始终是利用普通的硬件与开源软件来完成的. 毕竟 , Web 2.0 站点都不是烧钱的主. 从数据量来看,这绝对是一个相对比较大的 Web 2.0 应用.
Tag 是 Technorati 最为重要的数据元素. 爆炸性的 Tag 增长给 Technorati 带来了不小的挑战.
2005 年 1 月的时候, 只有两台数据库服务器, 一主一从. 到了 06 年一月份, 已经是一主一从, 6 台 MyISAM 从数据库用来对付查询, 3 台 MyISAM 用作异步计算.
一些核心的处理方法:
1) 根据实体(tags/posttags))进行分区
衡量数据访问方法,读和写的平衡.然后通过不同的维度进行分区.( Technorati 数据更新不会很多, 否则会成为数据库灾难)
2) 合理利用 InnoDB 与 MyISAM
InnoDB 用于数据完整性/写性能要求比较高的应用. MyISAM 适合进行 OLAP 运算. 物尽其用.
3) MySQL 复制
复制数据到从主数据库到辅数据库上,平衡分布查询与异步计算, 另外一个功能是提供冗余. 如图:
InnoDB MyISAM 拓扑
后记
拜读了一个藏袍的两篇大做(mixi.jp:使用开源软件搭建的可扩展SNS网站 / FeedBurner:基于MySQL和JAVA的可扩展Web应用) 心痒难当, 顺藤摸瓜, 发现也有文档提及 Technorati , 赶紧照样学习一下. 几篇文档读罢, MySQL 的 可扩展性让我刮目相看.
或许,应该把注意力留一点给 MySQL 了 .
–End.

全球 IT 公司 100 强

商业周刊 2006 年 IT 公司一百强出炉了. 这是 IT 公司的兵器谱.
宏达国际 (HIGH TECH COMPUTER) 这家台湾公司是增长最快公司回报最高公司的双项第一。 在 收益增长最快 一项中排在第七位。厉害!
Google增长最快公司的第二名. 苹果公司则排在增长最快公司的第六。
以销售额来衡量,最大的 IT 公司是 HP 。Dell 第三, Nokia 第七, 微软则排在第八.
Amazon 是收益增长最快的公司第一名. Dell 第二 .
回报最高的公司软银名列第八.
Oracle 排在总榜单的 51 。有的 IT 巨头很是陌生.
大陆唯一入榜的 IT 公司是中国移动。 第 8 名。给的评论是:

It operates in a huge mainland market. But only 29% of the population has a cell—so China Mobile has lots of room to grow

依靠垄断总算弄出来一个巨无霸. 谁让咱大陆人多用的手机也多呢.
下载 PDF 文件.
–End.