2006年2月13日
#
Borland公司准备剥离IDE开发工具，而专注于application lifecycle management，现在Borland公司正在寻找合适的买家。对于一个Borland产品的老Fans，看到这条新闻还真有些吃惊，这意味着Delphi, JBuilder, C++ Builder, C# Builder, Kylix和Interbase等产品线要再易其主了。不禁让人回想起，多年前Borland曾经被Inprise收购并更名为Inprise，在经历了一次失败的转型后(中间件业务)，又再次改回Borland。如今这家有着传奇经历的公司再一次站到了十字路口前。
http://www.eweek.com/article2/0,1895,1922016,00.asphttp://www.borland.com/us/company/news/press_releases/2006/02_08_06_borland_acquires_segue_software.html
2005年4月5日
#
When OOP Becomes POO -
http://www.developer.com/net/vb/article.php/3494001
作者受 "
OOP is Much Better in Theory Than in Practice" 一文的启发，提出一些自己想法：
1. OOP的程序员应该分成OOP的使用者(Consumers)和OOP生产者(Producers)。
2. 创建一个类很容易，但建造一个类库或者一个架构完备系统则是出乎意料得难。
3. OOP的使用者未必能成为OOP的生产者
如果所有的使用者OOP都变成生产者POO，项目十有八九不成功。
我认同两位作者的观点，虽然也已经习惯了OOP的思维方式。从技术角度看，一个成功的项目需要的是一个健全的框架，而不是单纯的OOP。
2005年2月16日
#
See in: Exclusive Interview with Anders Hejlsberg: Getting Reacquainted with the Father of C#
http://www.sys-con.com/story/?storyid=48156&DE=1
2005年1月8日
#
在最近的TSS访谈中, Anders Hejlsberg叙述了Aspects在C#未来版本中的位置:
“It is not something that we are actively looking at implementing at this point, so we are sort of if you will in wait and see mode”
http://www.theserverside.net/talks/videos/AndersHejlsberg/dsl/q21.html
2004年12月31日
#
印度洋海啸12.5万人遇难，帮助他们！
2004年12月29日
#
现在模式和架构是个热门话题，也来凑个热闹。
模式和架构属于较高层次的应用，但并不是非学不可。
出现下列情形时，当不学：
. 程序员初学者，不学。并非学不会，而是不要被模式禁锢了自己的头脑。
. 为扬名立万填补知识空白，不学
. 不写代码，不走程序员之路者，不学
. 无恒心、信心和热情者，不学
不要期望优雅的代码里能到处看到模式的应用。模式就像钻石，镶满钻石的东西好看，未必好用。
当你准备用某个模式的时候，如果有下列情形，当不用：
. 为模式而模式，不用
. 为扬名立万，不用
. 不清楚模式适用场景，不用
. 不清楚模式约束条件，不用
. 翻书才知道怎么写的，不用
. 会增加代码复杂性的，不用
. 会导致代码可读性变差的，不用
. 模式所带来的扩展性和灵活性不可预见的，不用
. 见不到明显益处的，不用
. 同事看不懂，不利于团队交流的，不用
最后用模式要记得写注释，写清名称和出处，足矣。
最近blog里有很多人在谈论模式(pattern)和架构(architecture)，其中不乏刚入程序员行列的同学，目标都是希望提升自己的开发水平。由于担心初学者过于看重模式，有舍本求末之嫌，特写此文。
模式和招式
不知有多少程序员学过武术，其中有句话：“力不敌法，法不敌功”。意思是说：使蛮力敌不过会招法的，会招法敌不过基本功 厚实的。其实编程也是如此，如果放着基本功不练，拼命研究模式，最终只是一身花架子。
见过很多国内大型软件企业程序员的代码，很少有上乘表现的。主要原因我觉得和国情有关：
1)业务和编码一把抓，结果编程技术平平，却个个精通业务；2)急功近利，为赶工期不顾质量；其结果就是忽视基本功的学习和练习。
什么是软件领域的基本功？
Steve McConnell在《After the Gold Rush》一书中提到：
-- 一个人要成为某一领域的专家，大致需要五万个知识点。在那些成熟的领域，通常需要10年才能获得足够的知识点。
-- 其中超过一半的知识点会随着时间的流逝而废弃，如C++、JAVA、Perl、HTML、LINUX、Microsoft Windows。
-- 剩下的那些被称为Stable Core的，则会使你终生受用。
-- 哪些是软件领域的Stable Core?
Software Requirements Engineering
Software Design
Software Construction
Software Testing
Software Evolution and Maintenance
Software Configuration Management
Software Quality Engineering
Software Engineering Management
Software Engineering Infrastructure
Software Enineering Process
-- 不用精通所有的上述领域，但至少所有的都要了解，同时要精通其中某一些。
基本功便是Stable Core中和我们工作内容相关的知识点。
试举一些和编码(Software Construction)相关的基本功：
. 标识符命名，变量类型选择
. 好的编码风格
. 基本的算法，如表驱动、树遍历、排序等
. 基本的编程技巧，如Assert、Trace等
(这些基本功不能光知道不练)
程序员从哪里入手？
有本老书一直觉得很受用：《Code Complete》(中文版《代码大全》)
最近出了第二版，内容大致相同，是学习编码(Software Constuction)基本功的宝典。
学习模式没有什么不好，但有个时机和火候的问题。就像练武术，先得从站桩、盘架子开始，基本功扎实后，再学招法是事半功倍。照我看，前三年不用专门学什么模式。多写代码，多看代码，不断改进自己的代码；到时自然水到渠成。
2004年12月15日
#
在http://spaces.msn.com/上blog，你MSN7的名字后面会有颗小星星，我喜欢这个功能。
乘现在注册的人少，赶快抢个好名字。
2004年11月28日
#
从哪里入手看上去是个问题，在中国做咨询有点难。有人建议先从一些高端或覆盖率最广的IT杂志上推agile...，办事处在北京还是上海也是未知。知道
www.thoughtworks.com的人不多，知道Martin Fowler的人不少。
2004年11月24日
#
“How do you make two systems loosely coupled? Don't connect them.” -- David Orchard, BEA
“Objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space.” -- Waldo et al, 1994
“Sometimes you want things to break when they change" -- ThoughtWorks
2004年10月26日
#
2004年10月20日
#
生平第一次用BLOG
，作为.net的爱好者，这里也许是不错的选择，有感于dudu的“创建属于自己的博客堂”。
msolap