Good good study, day day up

JCA 1.5 规范定义了WorkManager API，能方便的进行任务的(多线程)并行处理。按照JCA规范的原意，WorkManager是仅提供给Resource Adapter使用的，容器会提供WorkManager实例并通过BootstrapContext注入到adapter中。可是，有时在其他场合，例如EJB、Servlet中，也希望能将请求拆分，使用WorkManager并行处理，但JEE规范中并没有提供这样的机制。

WebLogic提供了CommonJ WorkManager API，可用于任意应用中，但这个API不在JEE规范之中，因此GlassFish是不支持的。而且，使用WebLogic CommonJ WorkManager时需要在ejb-jar.xml中加入一个类型为commonj.work.WorkManager的resource reference，这样同一个ejb包就不能在不同application server间通用了，因此我还是希望能找到一种通用的方法。

SpringFramework的org.springframework.jca.work包为GlassFish和JBoss提供了在Resource Adapter外部使用JCA 1.5 WorkManager的简便方法。看了for GlassFish的源代码，发现它其实是调用了GlassFish内部的factory去直接创建WorkManager，那么对GlassFish是否也可以这样做呢？

反编译WebLogic的jar包，发现commonj WorkManager和connector WorkManager实际上都是delegate到一个weblogic.work.WorkManager实现的，也就是说在WebLogic里，CommonJ和JCA的WorkManager的底层实现其实都是同样的。接下来找到了weblogic.work.WorkManagerFactory，它有find和findOrCreate方法可返回weblogic.work.WorkManager实例，也许就是可以拿到weblogic-ejb-jar.xml里面定义的weblogic WorkManager。拿到了内部的weblogic.work.WorkManager实例后，再调用weblogic.connector.work.WorkManager的create方法，将这个内部WorkManger包裹到JCA WorkManager中，那么我们的应用就可以使用这个JCA WorkManager了，通过Spring的WorkManagerTaskExecutor来很方便的调度任务，上层的逻辑就可以做到与应用服务器无关。看起来很美。

关注我之前写的Android翻墙系列文章1, 2, 3的朋友请留意一下这个应用：TransProxy。这个应用的v3版本集成了HTTP transparent proxy (使用Transproxy)、HTTPS/SOCKS redirector (使用redsocks) 、iptables script 并提供了配置、控制的界面。理论上，结合TransProxy和ConnectBot就可以实现Android上通过SSH tunnel翻墙，请参考这里的第二张图片：ConnectBot实现了SSH client，TransProxy提供了transparent socks proxy并且设置iptables。

不过，我刚刚将TransProxy和ConnectBot配合运行起来试了一下，并没有成功，并且手机又遇到了100% CPU占用的问题，只能手工将ConnectBot kill了。ConnectBot当前最新的snapshot版本都还是没有解决这个bug，大家快去给这个bug加星，促使开发者优先解决吧。

鉴于我目前暂时处于肉身翻墙状态，没有积极性去进一步实验了，各位动手试试吧，有结果记得共享出来。另外，目前TransProxy的作者还在相当勤快的改进这个应用，不妨到xda-developers论坛与他交流。

在上次写下进展之后，就真的没有任何进展了。本来打算完成之后会发布成开源软件的，但现在看来遥遥无期。有人问我iptables命令怎么写，就把简要介绍放这里吧。

1. 首先确认你有Android系统的root权限，下面的操作要以root身份登录到shell进行
2. 将transocks_ev放到Android系统中，目录随你喜欢。这里下载已编译的transocks_ev for Android可执行文件，解压后文件的MD5：6a0c3500bcd24ab7b706c8caf34f15ba
3. 从Android Market下载ConnectBot，配置好你的ssh帐号，记得设置port forwarding，端口为9050
4. 在ConnectBot中连接ssh
5. 在shell中运行transocks_ev:

transocks_ev -S 127.0.0.1 -s 9050

6. 在shell中执行iptables命令：

iptables -t nat -F 
iptables -t nat -A OUTPUT -m owner --cmd-owner transocks_ev -j RETURN 
iptables -t nat -A OUTPUT -m owner --cmd-owner org.connectbot -j RETURN 
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 1211 
iptables -t nat -A OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 1211

几天前去游泳，连续游了四十分钟，没有感觉到累，倒是游得很无聊。一路就是看着池底白晃晃的瓷片和黑色的泳道线，到头了转个身一蹬池壁，又是单调的白与黑。见不到养眼的泳装美女来分散一下注意力，一路只好默念着这是第十个来回，第十一个来回，目标是十五个，目标是十五个……游得无聊，倒是有了两个想法。

首先是想为什么没有音乐听听呢？跑步的时候可以戴着耳机听音乐，游泳也应该可以才对。做防水的播放器和防水的耳机，难度应该不大，说不定已经有这样的产品了，只是没有普及。

第二个想法有意思些。我在海里看过珊瑚，离岸不远的浅水，只要把头沉入水中，就能见到海底犹如大花园一般的珊瑚世界。如果整个游泳池底铺上大显示屏，游泳池也可以变身为虚拟海底世界。五彩斑斓的珊瑚随着水波微微摇曳，鱼群在其中穿梭。假若结合电脑控制的虚拟现实系统，加上感应器，还可让鱼群在你游近时飞快逃开，而海豚就伴在你左右。

家里的松下H540U波轮洗衣机，使用了大概一年半左右开始出现撞桶现象，就是在洗衣的过程中，每次波轮起动（或反转）时，洗衣桶会碰撞到箱体。因为箱体相应位置贴了防撞海绵，摩擦时发出很大很难听的”吱吱”的声音。打开上盖检查过，发现是箱体吊挂系统变形所致，我觉得这属于设计上的缺陷。

如果不清楚波轮洗衣机吊挂系统的结构，可以看看全自动波轮洗衣机培训手册的3.1节。洗衣机的桶体是靠四根吊杆悬挂在箱体的四个角上的，如果吊杆的长度不一致就会造成桶体不平衡。

从照片中可以看出，箱体前面两个角用来悬挂吊杆的角铁都已经变形下沉，而后面的两个角则正常，这样就造成桶体前倾，在洗衣的时候不平衡自然就频频撞击箱体了。

为了外形美观，箱体前面的两条边做成了大圆弧，也许是为了加工方便的缘故，悬挂吊杆的角铁在圆弧部分并没有与箱体接触，是悬空的，起到支撑作用的只有侧面的一部分，由于强度不足在使用一段时间后就变形了。这款洗衣机在最高水位时桶内的重量超过50公斤，平常洗衣就算不满也有30～40公斤。箱体后侧两条边是直角，箱体支持角铁的的长度足够长，就没有发生变形。

This picture was taken at 18:44 18-Jun-2010, when I picked up the geocoin ALEUNG 1 from the cache Golden Triangle. The coin has traveled for two and a half years and over 21 thousand kilometers fromVeneto, Italy before it came to Guangzhou, China.

If you don’t know what is Geocaching, please refer to the definition on Wikipedia. In simple saying, it’s a game that someone hide something (a cache) and publish the coordinate (latitude and longitude) on Internet and then other players seek it with help of a GPS receiver. Geocoin is a special kind of coin each has an unique number that can be traced on geocaching website. Geocaching players pick up a coin from one cache and drop it into another cache, so that the coin can travel from cache to cache, even around the world.

The story began from Oct 2006, Italian geocacher i5fzi came to Guangzhou for the Canton Fair. He contacted me on geocaching.com.He didn’t know me before, but I was almost the only cacher in Guangzhou at that time. So it was geocaching that make us know each other. He kindly invited me for dinner and I suggested him some caches to find.

After i5fzi came back to Italy, he sent out several geocoins as present to me and Cherrie, who was his translator in Guangzhou. The goal of these coins are to reach my caches in Guangzhou. But unfortunately most of the geocoins were missed in there trip, this one I got is the only survival – I am so lucky to get it.

我管理待办事情的基本方法是维护一个列表，将所有要做的事情都记录下来，然后安排具体的时间来处理它们。传统的时间管理工具分为任务管理和日程管理两大类，相互独立，而我需要将它们结合起来用，故此以前写过为什么不能合在一起一文。后来，也发现Outlook 2007已经将两者做了一定程度的整合。

今天又再思考了一下：任务管理就是一个逐步细化的过程，包括执行时间的具体化和操作步骤的细化（拆分子任务）。理想的工具应该对整个过程都提供支持。

当新增一个任务时，外界往往并没有指定执行任务的具体时间，可能会有一个deadline，只要在deadline之前完成都是可以的，这时就是传统时间管理工具说称的 task。为了完成此任务，需要安排一个具体的时间段去执行它，在传统的时间管理工具上，就是要为此任务创建一个日程安排 (event)。但在实际操作中，你往往不能一下子就确定在哪个明确的时间去执行任务，而是先确定一个大概的时间范围，再逐步的精确。目前我还没有见到哪个工具能够为这个过程提供支持。

我设想的时间管理系统应该用一个统一的模型来存储任务与日程，因为它们本质上是同样的东西。任务有一个属性，是计划执行的时间。计划执行时间可以为空，说明还没有为此任务指定执行时间。计划执行时间不一定是精确时间类型，可以有不同精度级别的时间类型，包括：年 / 季度 / 月份 / 周 / 天 / 时间段 / 时 / 分。随着计划的逐步细化，赋予任务计划执行时间越来越高精度的时间。

例如，我和Bob很久没见，想一起吃午饭聚聚旧，于是电话联络。Bob刚好出差了，要下个月中旬才回来，所以我们初定时间在下个月的第四周（Week 29），我在时间管理系统中添加了 Dinner with Bob 这一项，并设计划时间为 W29。到了week 28的周末，我review任务时看到了这项，就跟Bob再确认时间，发现周一中午大家都有时间，但是具体几点钟要看周一早上与餐厅订座时才能确认，于是我把这项任务的计划时间更新为周一，但这还不是最精确的时间。周一早上，订座确认了，再把任务的具体时间12:00～13:00设置上去。

在上一篇博客中，我提出了在Android手机上使用SSH tunnel的想法。几天下来有了一些进展。

首先，非常感谢Sunner，他帮忙编译出Android平台的transocks_ev binary，并且解决了一些在Android平台上运行的问题。

在实验中，用ConnectBot + transocks_ev + iptables，HTTP和HTTPS请求都能重定向到SSH tunnel了，测试了浏览器和其他一些应用，无需任何额外设置就可正常访问网络。不过目前没有考虑使用非HTTP/HTTPS的应用。但现在还有两个问题：

1. DNS查询还是直接出去，不能避免DNS污染
2. 现在用ConnectBot作为ssh client，并不合适：
   * 在port forwarding时ConnectBot CPU占用非常高，达到99%，估计是有bug。
   * ConnectBot的连接和断开需要手动控制，密码也要在界面输入，无法做到整个翻墙过程单击执行。

对于第一个问题，transocks_ev 不支持UDP，因此无法tunnel DNS查询请求。我在考虑参考CMWrap的方案，做一个DNS proxy，转成TCP请求发出去。

目前在PC上使用SSH tunnel翻墙是一个相当广泛使用的方案，国外SSH帐号的获取不是太难，购买起来价格也比VPN帐号要便宜。但是在智能手机上目前还不能使用SSH方案，只能用VPN。Android系统是基于Linux的，特别是root了之后，基本上要玩什么都随心所欲了。因此Android上是应该也可以使用SSH tunnel的。

先看看Windows上是怎样设置SSH翻墙的：

• 首先需要有个支持dynamic port forwarding的SSH client，这个SSH client能开放出SOCKS服务
• 如果浏览器(或者其他程序)支持使用SOCKS proxy，设置使用SSH client开放出来的SOCKS端口，就可以使用了
• 如果浏览器(或者其他程序)不支持SOCKS proxy，只支持HTTP proxy，就需要再运行一个支持SOCKS的代理程序（例如Privoxy），将HTTP转成SOCKS

在Android上就要麻烦一点了，因为需要网络通讯的不仅仅是浏览器，很多Android application都需要访问网络，但是它们并不支持proxy—-连HTTP proxy都不支持，更不用说SOCKS了。它们只会直接连接目标站点，如图中虚线所示，然后撞墙。

昨天终于拿到了Google赠送的Nexus One手机了，Google做事也够拖拖拉拉的，确认信说两个星期左右会寄到，实际上用了两个多月。不过还是得感谢Google，我去年开通Android Developer帐号的时候还埋怨，我只是发布免费软件，都要我交25美元才能开通。Google送我手机的原因是因为我符合它的Android开发者推广计划的条件：开发的Android应用下载量超过5000，用户评价高于3.5星。我的 HereIm Map Helper 和 Wallpaper Label 都符合条件。

原来用的G1因为内存太小，运行速度很卡。Nexus One用起来的第一感受就是顺畅，另外就是屏幕显示效果很艳丽。

机器是2.1的系统，但是没有root，因此正式使用前的第一件事情就是刷机。上网看了一些文章，大部分写得罗里罗嗦的，完全没有重点，真正动手做其实就是简单几步。下面不写具体操作过程，因为网上一大堆。

准备

PC上要安装好USB驱动和fastboot、adb工具。工具是Android SDK附带的，装好SDK就有。