Dec 1st, 2009
by Fan Fan.
这个模式主要是来对付Listener Patter（或者Observer Pattern），具体来说，后者的缺点在：
产生了很多的类，比如很多情况下，一个event source只对应一个listener，这种浪费在手机这种受限设备上是一个不得不考虑的问题。
event source和listener的管理复杂，比如注册和注销，因为这两者可能都很动态，不能保证自己需要对方时对方是工作的，或者说难以达到消息的可靠性。这两者之间的依赖太明显，太直接。
White Board引入了event broker，作为两者间的桥梁，保存消息和分发消息，走向了subscribe/publish模式。
图摘抄至OSGi in Practice。这并无神奇的地方，只是把复杂的代码挪到了broker。OSGi则在这个地方加上了比如异步，有顺序的分发和可靠的分发这些功能。还有Topic的功能，比如有一个topic: a/b/c/*，这样event source和listener直接就靠这个纽带来进行交互，在Android中把这个抽象成URI，感觉几乎是一样的。
倒不清楚Android是一个OSGi的实现？还是只是把OSGi作为一个templete拿来模仿？
Oct 14th, 2009
by Fan Fan.
最近在考虑做一个手机上的“可同步的“的记事本，因为感觉的android上的通讯录和邮件功能确实很cool，在PC上面修改Gmail的通讯录马上就可以同步到手机上，这样手机丢了或者刷机后，同步一下就可以了：信息只存在一个地方（这让我想起了TDD中的消除重复…）。
如果记事本里面的内容保存在网络上，在普通的pc上也可以编辑，那么势必还有一整套的相关事情：1）得有记事本的web界面，主要在PC上使用；2）如何说服用户使用这个网站，没有人愿意把私有数据放到一个不知名的网站或者不知道哪里的“云”上；3）还得有 firefox的插件，方便操作；4）如何避免滑入一个信息孤岛，如何和其他app分享数据。
结论是：手机只是网络的延伸，只是PC机不在时的一个补充（或者说当我们不在cloud中时）。PC机上好的应用，可以迁移到这个平台上来，反之则不大可能的。
当然这只是一个例子，只是技术上的可行性验证，不用考虑太多。
Jun 16th, 2009
by Fan Fan.
如果没有源代码，分析问题就不能追本溯源，就会流于表面。
虽然自己不一定会从头到尾的看代码，但是有源代码在那里，让人总觉得有安全感。
代码的开源，还表示了一种“授之以鱼，不如授之以渔”的态度。源代码提供了更多的信息，提供了解决问题的方式。虽然功能不是最强大的，而自有的产品更多的只是关于配置相关的文档，其后的原理一般人不甚了了。Dan Farion谈及MySpace架构时说到：“我们尝试了某个东西之后就从中学到些东西，然后可能就会把其中有价值的地方给剥离出来，再为了达到我们的性能或伸缩性需求重新写一个。” Open Source则可以充当学习的例子。项目中总会有让人感到棘手的问题，这些问题超出了框架之外，是不能用常规方法解决的，如果而源代码这个时候就能作为特例中的一般例子，让我们有一个改进的基础。
Aug 1st, 2007
by Fan Fan.
How let your changed java code updated to server? It is a big problem in develpping any non-trivial JEE project.
Resently, I run a JBoss 4.04 outside of Eclipse. The application archive(EAR) is so big that we can not run it in IDE environment. Then the debug process is boring. After having modify the java code, [...]
