2008年9月4日
偶然间看到下面有一个网友慨叹普元的强大，而开发人员的渺小。
小弟刚刚参加工作，也在项目中接触到了普元的EOS。普元的这个东西怎么说呢，就是乱用XML然后Spring没做好就变成那个样子的，同时失去了类型的表述，一部机器要进行装配需要组件和零件，软件应该自上而下，分而治之，这是上个世纪70年代，学者们就达成的共识，所以关于“银弹”神话的唯一结论就是——“没有银弹”。
为什么说EOS是没有做好的Spring？
Spring简化了对象的装配，强调重用，是建立在面向对象基础上的，是建立在敏捷测试基础上的，是建立在强类型基础上的；
而EOS则是建立在面向过程的基础上的，建立在不可测试的基础上的，建立在毫无类型基础上的（全是String）
然而EOS也有很多的优点（据小弟不完全发现）：
1）EOS固化的开发流程强制一个team从一种易于维护的结构组织Web，包括页面，表示层，逻辑层等等。否则的话就需要一个架构师来做出规约，但仍不易于管理；
2）EOS的画图功能让人耳目一新，从“代码即文档”的哲学出发，这些画图很好地诠释了代码表述的内容和结构，给程序的维护带来便利。
3）相对于OO和J2EE传统开发，EOS易于上手，学习曲线较短。但是这一点有争议，EOS的知识不具备通用性。
综上，根据2-8的关系法则，在某些领域EOS的确有其优点，但是认为EOS完全“解放”了程序员，则是不负责任的说法。
这只是我的个人看法，欢迎大家就此话题讨论。
2008年9月3日
联合国是国家间的标准化组织，可惜一超多强们只把它当作是一个道具，需要时拿来用一下，不需要时完全可以踢到一边。
历史上，每个朝代都认识到失败的教训，却最终都迎来了相似的结局。
有人说，软件行业是一个天生的垄断行业，其特质是，产品研发的过程异常的（因IE8出现异常，下述文字用图片代替）
希望这些大软件厂商们能够吸取教训，也希望小软件厂商们将来不要走入历史的怪圈。
2008年3月5日
在远古时期人们靠结绳纪事，据说美洲的玛雅文明在覆灭之前都一直没有自己的文字，而采用这种古老的方法。
后来我们的祖先发明了文字，在竹简上，布帛上书写文字，竹简和布帛就是信息的载体，这样的载体造价不菲，所以我们的文言和白话就有这么大的差距，留下的论语也要微言大义。再后来我们的祖先发明了纸张，严重地降低了承载信息的开销，于是人类的文明得以更好地记录和更快地发展。今天，我们的信息载体又有了新的变化，一张光盘，一个硬盘都可以承载无数的学问。
信息有了载体，随之产生了信息管理的问题：
如何对信息进行增删改查的操作？如何处理附加在信息上的工作流？如何管理权限？
在IT系统出现之前，人们通过图书馆管理图书，通过搬运工进行信息流动，通过钥匙和锁头管理权限。
在IT系统出现之后，人类可以通过计算机来完成这些操作。这其中数据库系统，工作流系统帮了我们大忙。
IT系统处理信息的过程是：
多样式的文档（抽象为XML）-> 内存数据 -> 持久化（文件数据库）->内存数据 -> 多样式的文档(抽象为XML)
我们让用户在我们设定的UI窗口进行输入，然后通过报表的形式产生各种各样的输出。中间一个步骤一个步骤，一个环节一个环节的走下去。
这其中，我们把很大一部分精力消耗在，如何让用户舒服的输入，和产生用户所需要的输出上。
于是人们就要思考，难道不可以直接编辑一种全世界认可的文档形式（大家现在正在和MS争吵的东西）通过网络流转，然后获得结果吗？为什么要从程序员的角度加给用户数据库，工作流，录入界面这些繁杂的东西？
从这点意义上说，我推崇Sharepoint或者Google sites。
就拿google docs来说吧，在线编辑word，每个环节通过分享的形式进行编辑，授权这部分可以通过历史记录来找到，随时恢复到历史版本，因此也不怕误操作和无权限操作，真正的所见即所得，支持50人同时在线编辑。这难道不是OA的杀手级应用吗？
2008年1月16日
学习这些框架技术，我觉得归根结底就是做什么的，为什么做，如何做
前人说读书有三个层次，我看这大概可以总结为是新的三个层次：）
因为没有搞清楚为什么要用，就会误用，用了还不如没用。其实我觉得学spring读读rod那个原著挺好的，比单纯学spring有帮助，最好自己有体会。比如你开发网站很熟练了，自然就知道为什么要用spring了。等完全领会了他那两本书后，再读读他们的reference book应该差不多了。
这个过程其实就是做什么->为什么->怎么做的过程
2008年1月7日
最近在研究关于系统的基于日志的故障恢复，无意间在网上发现一篇论文中对于系统日志模型的精彩论述，翻译过来并附上我的思路：
『
一个系统是一个具有明显的边界的实体，它根据一定的输入，自身运行逻辑及系统的内部时钟变化来产生相应的输出。
所谓“明显的边界”是指系统所产生的输出是明确而无二义性的。我们称这个边界为系统的设计规范（specification）。一个系统通过与其所处环境进行交互，从而获取输入并产生输出。一个系统可以被拆解为不同的子系统。这些子系统通常被称为系统模块（system components），每个模块又独立地成为一个系统，作为一个系统，这个模块又会和它的相关环境进行交互（比如，一个更大的系统中的其他的模块组件）来获取输入并产生输出，这些模块还可以继续被分解为更小的子系统。
一个系统可以被建模为一个状态机（state machine），其中的状态包含了系统所持有并处理的数据。这些状态的迁移被分为两大类：由系统内部逻辑所触发且对外部环境透明的迁移和直接与外部环境相接触的迁移。前者的例子如内存数据和寄存器数据的转换，内存中数据结构的重组。第二种迁移的例子包含了各种各样的系统和环境之间的交互，一般来说，如果这个过程能被建模成系统的I/O操作，则应属于这一类别。因此，一个消息内容的形成是一个或多个第一类别状态迁移的结果，但将消息输出到系统的环境则是属于第二类迁移。
第二类别的状态迁移可以捕获交互事件（interaction events），或者简单的事件（events）。这些事件可以由系统外部的观察者（observer）来获取。显然，这里的事件是消息、信号、数据及其内容以及一切系统和其环境交互（如机器人运动手脚，报警器报警，打印机打印等等）的发送和接受的模型。此外事件还可以用来描述系统缺乏交互的时间，比如一个计时器在日志中输出系统的空闲时间等。
当一个大的系统被拆分成多个模块时，每个模块都被赋予了整个系统所处理数据的一部分，正因为模块和模块间的接口衔接和数据感知，一些原来属于第一类别的状态转换，因为系统的拆分在更低的层次上变成了第二类别，成为系统和环境之间的交互。
对于一个特定的系统，他对于输入的形式和获取时间是不可预知的，但是这个系统却应该能够做到根据一个特定的输入以及系统当前的特定状态获取一个特定的输出。因此系统的执行可以被建模为状态转换序列，每个状态的输入是一个不确定性事件。为了记录日志并做到故障恢复，我们还应做到能够在环境中捕获这个不确定性事件输入。
此外，在系统与系统间进行交互式，事件的传递时间也应该是不确定性的。
』
怎样用日志来预防系统崩溃，在崩溃后如何还原系统，我想关键问题就是怎么做好内存的快照，这样，在断电重启后可以通过日志来还原内存的信息这样第一步就是确认内存中的数据结构，哪些是必不可少的。确定系统恢复的粒度，按照子系统的分割和事件的记录来进行replay，根据子系统的划分，可以找出每个子系统中第二类别的事件进行记录。
以向数据库系统提交作业为例，实际上在整个作业提交的过程中，每个层次都要做到可以在失败的情况下重现，这个功能在完善的数据库系统和集群批处理系统中当然已经很完善。但如果是针对web系统的作业提交，则需要针对Web的作业持久方案，做一个日志恢复处理。需要特别指出的是，对于数据的查询是不需要做备份的。
在具体实现上，我想应该包括：日志记录，故障检测，日志持久三个部分。一份日志就是一个对于系统检查点（checkpoint）的连续记录。日志记录者负责记录日志到日志持久者，故障检测器随时监控系统，发现故障后，从日志持久者中读取日志，进行replay.
2008年1月4日
摘要: 自己以前翻译的文章，转贴过来集中管理。
阅读全文
2008年1月2日
2007年12月30日
总算找到了工作.
我会好好努力的.
此时此刻,更加明白,以往的一切荣与辱都成为过去.
又要踏上新的征程.
2007年12月28日
刚看了myeclipse，eclipse是一个很可怕的东西，它试图让所有的开发人员一打开电脑就不能够离开它，还要在里面完成所有的工作。人们不至于反感它的原因是它是开源的，不受商业控制的。如果我们对于myeclipse过度依赖，必然最终走向对微软严重依赖的老路。我不反对利用软件盈利。但是自由的精神不应被改变。
微软和我们
是原始的猎人与猎物之间的关系，虎与伥的关系，最终极的占有。我们这才生是MS的人，死是MS的鬼。
2007年12月12日
摘要: 这篇随笔谈一谈如何在Java环境下利用Unix/Linux的用户名和密码对用户的权限作出过滤。为方便大家学习交流，本文中给出了源代码，借此抛砖引玉，欢迎大家对这个简单的登录模型做出改进或者设计出自己的技术方案。
由标题我们不难看出，与本文相关的知识点主要有3个：
1 JAAS这个解耦设计的多层验证方法（1.4后已归入Java核心库中）
2 应用JNI访问底层代码，及JNI中简单的类型匹配
3 在shadow模式下，Unix/Linux系统的用户验证
阅读全文