之前就想为Berkeley DB写一个SQL前端+JDBC Driver。真的动手去做了，发现并不是很困难。不用花两天就可以写一个支持最简单SELECT、INSERT、CREATE TABLE语句的前端了。还包括一个可以运行的JDBC Driver。虽然要完善还需要做大量的工作，但是可以肯定的是，并不是一件困难的事情。
突然有点轻视MySQL，MySQL也是基于别人的引擎，不过也是如此吧了。
也许是我无知，无知者无畏！
文章来源:
http://jobs.cnblogs.com/archive/2006/04/14/375637.html
XP所强调大多观点我都是十分认同并且应用在实际工作中，包括作Code Review、测试驱动等等。
但对于其中的结对编程，向来是冷眼相对，没看出这是什么好主意。
看了电影《断背山》之后，更是觉得，结对编程，也许是两个男人在一起交流感情的好方式吧。
文章来源:
http://jobs.cnblogs.com/archive/2006/04/23/382824.html
今天重新阅读罗素《西方哲学史》下卷关于卢梭的部分。
卢梭早年曾当过一个贵妇的男仆，那贵妇死去时，发现卢梭有一个贵妇的纽扣，其实是他偷来的。卢梭一口咬定是某个他喜欢的女仆送给他的，结果那个女仆受到了处罚。卢梭说：“从来没有比在这个残酷时刻邪恶更远离我了；当我控告那可怜的姑娘时，说来矛盾，却是实情：我对她的爱情是我所干的事的原因。她浮现在我的心头，于是我把罪过推给了第一个出现的对象。”
在卢梭道德观中，这是一个以“善感性”替代一切平常道德的好实例。卢梭认为他永远有这一副温情心肠，然而温情心肠却从未阻碍他对最好的朋友有卑鄙行动。
在我们周围，也有很多人，有一副温情心肠，有善感性，被人认为是好人，或者纯朴、或者善良的人，但这并不会妨碍他们对自己的朋友或者亲人有卑鄙的行动。
文章来源:
http://jobs.cnblogs.com/archive/2006/04/24/383110.html
CMPP和SMPP协议比较
并非同类型协议
CMPP和SMPP都是短信协议中的一种，但它们不是同一类型的协议。SMPP和ESME和SMC（短信中心）之间的协议，而CMPP是SP和中国移动ISMG之间的通讯协议。
以下是CMPP 3.0文档中的图示。
与CMPP对应的协议有，联通的SGIP协议，中国电信的SMGP协议，网通的CNGP协议。
作为SP，只需要了解CMPP，不需要了解SMPP。
最新版本和兼容
SMPP协议是一个国际标准，有SMS论坛制定，官方网址为smsforum.net，截至2006年7月2日，最新版本是5.0。曾经流行的版本是3.3、3.4。SMPP协议向后兼容的。
CMPP最新版本似乎是3.0。现在（2006年7月），大多数还是使用CMPP 2.0。CMPP协议没有做到向后兼容，3.0的文档本身也没有讲到兼容的问题，甚至认为，协议制定者压根没想过要兼容。CMPP
3.0没做到向后兼容导致了一个问题，就是SP无法平滑升级。
PDU格式
PDU是协议数据单元的缩写，SMPP和CMPP都使用最先一个4位的长度标志整个PDU的长度。
SMPP是一个国际标准，不同的SMC的是实现可能要增加特定参数，为了具备更好的扩展性，SMPP 3.4以上版本，增加了可选参数，在5.0中，可选参数叫做TLVTable。
CMPP是中国移动定义的其内部ISMG之间、ISMG与SP之间的通讯标准，涉及一些具体的计费信息，但没有可选参数。
在SMPP中，消息头包括4部分：PDU长度、Command_Id、Command_Status、Sequence_Id。其中Command_Status字段，只在回应消息中使用，存在冗余。
CMPP中，消息头部包括3部分：PDU长度、Command_Id、Sequence_Id。个人认为，CMPP中的消息头，不包括Command_Status，似乎更好一些。
消息传输模式
SMPP和CMPP都支持异步传输，CMPP中，建议异步传输的窗口大小为16。
CMPP使用一个连接发送短信息和接收短信息。
SMPP支持多种的连接，其中TX类型的连接，只能发送短信息，RX类型的连接只能接收短信息，TRX类型的连接支持接收和发送短信息。
SMPP 3.4中，消息传输模式分三中：Store And Forward、Datagram、Forward。分别用在大吞吐量、可靠性保证等不同的应用场合。
CMPP没有规定其消息传输的模式，根据实际使用的情况看来，华为的网关的消息传输模式类似SMPP协议中规定的Datagram模式。
文章来源:
http://jobs.cnblogs.com/archive/2006/07/02/440902.html
刘小枫在北师大的开讲座讲尼采如是说，人类写东西并不仅仅想要人懂，也肯定想要人不懂。
理所当然，人类写的东西，也包括代码！
文章来源:
http://jobs.cnblogs.com/archive/2006/07/03/441087.html
GSM 03.40规范（TP-06 1999-12-15 7.4.0）中规定了SME对于超长短信的合并处理。规范制定至今，已经超过6年，绝大多数正在使用的手机，都支持这一功能。
CMPP协议中，CMPP_SUBMIT_MESSAGE中有两个字段pk_total和pk_numer，恰看起来，这就是发送超长短信的设置参数，其实不然，这两个参数的设置，应该是没有用处。
发送超长短信，需要做两件事情：设置TP_udhi的值设置为1，在消息正文中增加协议头。协议后可以两种格式，分别是长度为6和长度为7的协议头。格式如下：
6位协议头格式：05 00 03 XX MM NN
byte 1 : 05, 表示剩余协议头的长度
byte 2 : 00, 这个值在GSM 03.40规范9.2.3.24.1中规定，表示随后的这批超长短信的标识位长度为1（格式中的XX值）。
byte 3 : 03, 这个值表示剩下短信标识的长度
byte 4 : XX，这批短信的唯一标志，事实上，SME(手机或者SP)把消息合并完之后，就重新记录，所以这个标志是否唯一并不是很重要。
byte 5 : MM, 这批短信的数量。如果一个超长短信总共5条，这里的值就是5。
byte 6 : NN, 这批短信的数量。如果当前短信是这批短信中的第一条的值是1，第二条的值是2。
7位的协议头格式：06 08 04 XX XX MM NN
byte 1 : 06, 表示剩余协议头的长度
byte 2 : 08, 这个值在GSM 03.40规范9.2.3.24.1中规定，表示随后的这批超长短信的标识位长度为2（格式中的XX值）。
byte 3 : 04, 这个值表示剩下短信标识的长度
byte 4-5 : XX XX，这批短信的唯一标志，事实上，SME(手机或者SP)把消息合并完之后，就重新记录，所以这个标志是否唯一并不是很重要。
byte 6 : MM, 这批短信的数量。如果一个超长短信总共5条，这里的值就是5。
byte 7 : NN, 这批短信的数量。如果当前短信是这批短信中的第一条的值是1，第二条的值是2。
发送的短信这么处理，接受短信反过来就可以了。上述内容，在CMPP协议以及多款手机上经过测试验证。
文章来源:
http://jobs.cnblogs.com/archive/2006/07/07/445584.html
之前就想为Berkeley DB写一个SQL前端+JDBC Driver。真的动手去做了，发现并不是很困难。不用花两天就可以写一个支持最简单SELECT、INSERT、CREATE TABLE语句的前端了。还包括一个可以运行的JDBC Driver。虽然要完善还需要做大量的工作，但是可以肯定的是，并不是一件困难的事情。
突然有点轻视MySQL，MySQL也是基于别人的引擎，不过也是如此吧了。
也许是我无知，无知者无畏！
文章来源:
http://jobs.cnblogs.com/archive/2006/04/14/375637.html
1、整表查询
把整个表数据列出来，不知道为什么，BerkerlyDB 比 SQL Server还慢，没理由的，可能我没用好。
2、getByPrimaryKey
33606条数据的表，共19个字段的情况下：BerkerlyDB的性能要比SQL Server快10倍左右。（SQL Server数据库也是部署在本机）
33606条数据的表，共2个字段的情况：BerkerlyDB的性能要比SQL Server快500倍左右。（SQL Server数据库也是部署在本机）
（待继续补充中）
3、使用索引。
33606条数据的表，共19个字段的情况下，返回两条记录，使用字符串索引：BerkerlyDB的性能要比SQL Server快50~100倍左右。（SQL Server数据库也是部署在本机）
4、插入数据
插入2000条输入到数据表，共19个字段。SQL Server使用JDBC的executeBatch，每批1000条。Berkerly DB使用comiteNoSync的方法提交每次插入的数据。BerkerlyDB大约比SQL Server要快10~20倍。
文章来源:
http://jobs.cnblogs.com/archive/2006/03/29/361406.html
1、易于学习
2、支持主流数据库，包括MS SQL Server 2000、Oracle 9i、DB 2 7、Sybase、My SQL 5.0。应该有良好的支持多数据库方式，而不是现在一些流行O-R Mapping多数据库支持方式那么笨拙。
3、包括数据查询和对象查询。明确区分两种查询，他们对应的OQL功能应该有所不同。
4、能够处理复杂对象。例如多层一对多包含关系。评注，现在流行的O-R Mapping引擎处理复杂对象都不好，包括Hibernate 3.0。
5、有较为完整的DSL。不单应该包括用于运行时数据处理的OQL，还应该包括定义期的语言。
6、不完整装载。
7、对Event-Driven模型有良好的支持，并且支持请求合并
8、O-R Mapping应该更像一个“编译器”和“执行引擎”的组合，这个编译器输入是OQL，编译时使用各种技巧进行优化，编译的中间结果可以存储，可以生成存储过程。甚至可以根据执行过程的统计信息，采用不同的优化手段，调整最终的执行计划。
9、应该有良好的性能
我认为，一个实现良好O-R Mapping引擎，可以运用大量的优化技巧，其中一些优化技巧，是相当多开发人员都不掌握的，还有一些优化技巧，使用起来比较复杂，开发人员为了兼顾开发效率，不予以使用的。所以，一个实现良好O-R Mapping引擎，应该能够比大多数开发者直接使用JDBC要快。
文章来源:
http://jobs.cnblogs.com/archive/2006/01/13/317007.html
有朋友问过我，怎样学习多线程编程，我总结了一下，列了一下知识点：
1、synchronized
2、Runnable、Thread、Thread.sleep、Thread.yield、Thread.join
3、wait、notify、notifyAll（注意其中锁的获得和释放）
4、Mutex、Semaphore
5、BlockingQueue （十分有用，必须掌握）
6、ThreadPool
7、ExecutorService
8、Future （十分重要，必须掌握）
9、ReadWriteLock
10、Lock、condition。这是很多线程库都包含的内容，概念和synchronized、object.wait、object.notify那套咚咚类似，不过是通过库的方式展现，更加灵活。
、死锁、哲学家就餐问题
12、TSL汇编指令、JDK 1.5中的compareAndSet(java.uti.concurrent.atomic)、Windows API中的InterLock
13、工作线程+请求队列的应用
14、用户线程、内核线程，fork时用户线程问题 （很多Unix和早期的Linux不支持内核线程）
15、Windows Thread API，特色API：WaitForMultiObject
相关的书籍有：
《JAVA多线程设计模式》 结城浩 中国铁道出版社 （这本书讲得很清楚形象，十分适合初学者阅读）
JAVA并发编程—设计原则与模式（第二版） Doug Lea 中国电力出版社 （不可以不看，同时要配合阅读util.concurrent包的源码或者JDK 1.5的源码）
《JAVA线程编程》 Paul Hyde 人民邮电出版社 (我觉得这本书也不错)
《POSIX多线程程序设计》 David R.Butenhof 中国电力出版社
《WINDOWS核心编程》 Jeffrey Richter 机械工业出版社
《UNIX系统编程》 Kay A.Robbins, Steve Robbins 机械工业出版社
《现代操作系统》 Andrew S.Tanenbaum 机械工业出版社
《UNIX 网络编程（第二版）第2卷：进程间通信》W.Richard Stevens 北京科海电子出版社
文章来源:
http://jobs.cnblogs.com/archive/2006/01/09/313535.html