Home

自从西甲变成西超二人转，意甲变成屌丝互搏，德甲一直不甚感冒后，我就基本只看英超了。（上一篇关于英超的blog中很多预测还是挺正确的嘛，哈哈。）今天以一个纯球迷的角度，胡乱侃几句，为什么英超现在是世界第一联赛。

最近读了刘同的新书《谁的青春不迷茫》。

和大多数人一样，知道刘同这个名字是通过「职来职往」。开始对他也并没有太多的关注，直到12月初某天，豆瓣上首页推荐他的这本新书。

这本书选取了他04年到12年的诸多随笔文章，按照时间排序。从这点上来说，相似行文风格的书并不算少，读这些书带来的感悟因人而异，或多，或少，或感同身受，或隔靴搔痒，不一而足。但这本书稍有不同的是，在每篇文章的末尾，都有一段类似「点评」的文字：以现在的人生处境和心境去看待过去的思考。

最近越来越多的非专业作家（只相对于其本身职业而言，没有别的意思）在出书，有豆瓣上的红人，有传媒人士，也有大学教授。

既然是书，而且很多都是畅销书，必定是有可取及吸引人之处。或妙语连珠，或思想深刻，不一而足。

可他们写的书好像有一些问题：仅仅是把自己某个时空下的感悟，思想，影评「拼凑」在一起，然后就有了一本书。显著的特点是：书名或许就是书中某一篇文章的标题。换句话说，这本书的书名完全是随机的。。。

所以这类书的模式大概是这样的：把自己过去N年写的随笔整理出来，然后写个随机函数，取书中某篇文章的标题作为书名，这就是一本书了。齐活儿。

以这个角度来看最近流行的几本书，你就能分辨出作者的用心程度。有些书，虽然也是由彼此无联系的文章组成，但能看出来作者在花时间，尽可能将它们组织成一本有血有肉，有主题的书。或许并不能尽善尽美，但还是很好的。而有的皆是赶工之作，像在做一个幼儿园的拼图游戏。

出书是一件很严肃的事情。尽管我们可以用诸如「读书这么好的事」，「只要有一点收获就值回书价」来安慰自己，但书毕竟是一件艺术品。我想说的是，不要把出书这件事也拖入这个快餐化的社会。其实每个有能力出书的作者都可以多用心，把书「组织」得更好。

书不是一系列评论，思想，博客的集合。如果仅仅是打包，不要也罢。

PS：这篇文章是最近读「如何阅读一本书」的一点感悟。虽然只读了1/4，但算是我今年读过最好的书。

在Java 6的java.util.zip.ZipOutputStream#finish()实现中，若ZipEntry为空，会抛出异常：

if (xentries.size() < 1) {          
	throw new ZipException("ZIP file must have at least one entry");           
}

1. OSGi Terms

• OSGi, Equinox and Eclipse
  从历史上来说，OSGi和Eclipse一开始都是独立发展的。OSGi首先是一套规范，核心在于它模块化，松耦合的理念，而Eclipse致力于构建一套基础的工具平台。
  在2003年，基于Eclipse出现了Eqinox项目：其最初的目的是解决当时Eclipse的一些运行时问题，而OSGi以清晰的组件模型，强大的执行规范为选为最可能的实现参考。
  之后就是两个组织间理念的碰撞及融合，Equinox借鉴了很多OSGi的思想，反过来也影响了OSGi的发展。OSGi的R4版本就是二者相互影响后的一个结果。至今，Equinox依然是OSGi规范的参考实现(Reference Implementation)。
  而在Eclipse这边，其运行时在3.1后就被替换成Equinox——完全基于OSGi的运行时实现。
• Plugin and Bundle
  二者在概念上来说，其实都是「模块」的同义词。只不过从历史上来说，OSGi喜欢用Bundle这个词，Eclipse则更喜欢用Plugin这个词。
  而Plugin作为一种特殊的Bundle，特殊在其有一个特殊的描述文件：plugin.xml。
• plugin.xml and MANIFEST.MF
  在Eclipse的3.0或之前版本，是只有plugin.xml的。因为如前面说到的，从3.1开始其运行时才完全开始采用Equinox。
  而在Eclipse完全基于OSGi后，二者的差别就比较小了。
  • MANIFEST.MF是作为最核心的组件描述符存在的：Bundle Version, Name, Dependency等等都在其中定义
  • plugin.xml是作为MANIFEST.MF的一个补充。除了OSGi的标准Service模型，Equinox还有一套自己的机制：Equinox Extension Registry。也就是我们常用的Eclipse扩展点机制，在功能上它是对OSGi的一个很好补充。

由于长期间的思维惯性和对Java程序缺乏足够的性能重视，导致我在处理Java集合类时经常想当然的只使用List。

例如经常有这样的场景：给定一个集合M，要遍历其中的每一个元素是否在集合N中（需要自己创建）是否存在。那么可能就会机械性地写出以下代码：

// construct the collection N       
List<MyObject> list_N = new ArrayList<MyObject>();        
for (int i = 0; i < N; i++) {        
	// construct or get an Object[i]        
	list_N.add(MyObject_i);        
} 
// check the element in M is in collection N or not       
for (Object o : collection m) {        
	if (list_N.contains(o))        
		...        
	else        
	...   
}

1. 为什么写这篇文章

这篇文章的根源是在产品中发现了一个诡异的bug：只能在产品环境下重现，在我的本地开发环境无法重现，而双方的代码没有任何区别。最后用remote debug的方法找到异常所在：

Exception in thread “main” java.lang.IllegalArgumentException: Comparison method violates its general contract!

Google了这个错误，是由于Java 7内置的新排序算法导致的。这才猛然想起产品的编译环境最近升级到了Java 7。

前两天在suse 64位机器上安装DB2 10.1时发生一个奇怪的现象：安装成功，但只能服务器端操作，客户端JDBC连接，或是catalog后db2cmd的连接皆无果。

例如：在安装过程中会添加一个db2instX的帐户，及一个db2 instance，监听在5000X端口。但客户端catalog完这个node再connect总显示TCP/IP communication错误。在检查完防火墙，并telnet XX.XX.XX.XX 5000X后确定客户端及网络没有问题。

那么就应该是服务器安装后的一些冲突或bug：