Here comes the Sun

某人已经发展到上班时间写blog了。 继续说验证码服务，找到两个比较典型的。recaptcha非常著名，是twitter和facebook使用的验证码服务（不知道现在的情况。。。），vidoop提供了一种很有特点的验证码机制。 两个服务都提供了python的接口封装便于接入，通过api接口可以管中窥豹，大致了解这两个验证服务的机制。 recaptcha 下面是一段结合了web.py的简单调用 public_key = “******” private_key = “********” class Recaptcha(object): def GET(self): r = recaptcha.displayhtml(public_key) return render.recapt(r) def POST(self): params = web.input() recaptcha_challenge_field, recaptcha_response_field = params.recaptcha_challenge_field, params.recaptcha_response_field remote_ip = web.ctx.ip result = recaptcha.submit(recaptcha_challenge_field, recaptcha_response_field, private_key, remote_ip) return result.is_valid 我在GET请求中获取验证码，在POST请求中提交验证码。 recaptcha返回的是一段recaptcha自己风格的html片段，效果大家参考twitter的验证码，实际上是一个iframe，iframe的url中包含了哈希串。其中的字段名也自然被写死成recaptcha_challenge_field和recaptcha_response_field，考虑到应用服务器无需验证这两个field的输入，所以也无可厚非。recaptcha_response_field用于输入字符，recaptcha_challenge_field在载入时被修改为一个唯一key。 提交验证时，recaptcha需要提供以上两个用户输入和应用的privatekey以及浏览器ip。recaptcha通过recaptcha_challenge_field 应用的private key以及用户出口ip可以唯一标示用户，并包含一些冗余实现安全相关策略。 Vidoop Vidoop提供的服务机制与recaptcha大同小异 customer_id = “***” site_id = “localtest” api_username [...]

方式1，应用服务器负责生成验证码字符，验证码服务器主要负责验证码图片生成。 用户浏览器向应用服务器请求包含验证码的页面； 应用服务器生成验证码字符，存储在session中；应用服务器发送相关图片参数（验证码字符、宽、高、复杂度、背景色等）到验证码服务器； 验证码服务器返回图片地址到应用服务器； 应用服务器将包含验证码地址的网页发送给用户浏览器； 用户浏览器通过img的src方式向验证码服务器请求验证码图片； 验证码服务器输出验证码图片流到用户浏览器； 用户判读验证码图片，提交表单； 应用服务器取出session中的验证码字符比对，返回结果。 这种方式的优点： 较少的HTTP请求调用 替换原应用中独立的验证码功能相对容易 验证码服务器相对简单 方式2，验证码服务器承担验证功能，应用服务器在验证中仅起到传递作用。 用户浏览器向应用服务器请求包含验证码的页面； 应用服务器发送相关图片参数（宽、高、复杂度、背景色等）到验证码服务器； 验证码服务器返回图片地址、惟一的会话id到应用服务器； 应用服务器将包含验证码地址的网页发送给用户浏览器； 用户浏览器通过img的src方式向验证码服务器请求验证码图片； 验证码服务器输出验证码图片流到用户浏览器； 用户判读验证码图片，提交表单； 应用服务器将第三步获得的会话id和用户输入的验证码字符传给验证码服务器； 验证码服务器进行验证，返回通过或拒绝； 应用服务器根据验证码服务器结果进行响应。 这种方式的优点： 验证码服务功能完善，涵盖整个验证流程； 验证码服务端有详细的验证日志记录，便于数据分析； 欢迎大家就两种方式发表意见～

今天下午看到了这个豆瓣架构发展历程的PPT，是今年上半年QCon上的，看了以后感觉很有启发意义。随着用户量的增大，压力的增加，功能的扩展，豆瓣架构上做出相应的变化，从最初一台机器上跑lighttpd/mysql/Quixote/memcached到现在的DoubanFS存储，DoubanDB分布式Key-Value Store，加上多台mysql，多台appserver，专门的后台运算服务器等等。 PPT地址： http://www.riawork.org/iarch/douban/douban_qcon2009_beijing.pdf 可惜因为字体的问题好像在Evince里很多中文字看不到，还得开一下虚拟机。

早晨八点半下楼开自行车锁，突然听见背后有微弱的声音。回头一看是个老太太坐在轮椅上，眼睛直直地盯着我，嘴里含糊不清地发出阿巴阿巴的声音。我自然是听不懂她说什么了，继续开锁。十月份虽然还是阳光普照，但是风里已经有点肃穆的意思了。这样的天气，年纪大了的人独自在外面这么坐着，想起来还是很残酷的。我推车要走，老太太还是盯着我阿巴阿巴地喊。假日的早晨小区里空空荡荡，遇到这样的场面还真有点超出“奇怪”能表达的意思。我又不好意思头也不回就走，推着自行车走上前去，想问老太太点什么，但是好像又无从问起，最后大约问了些“您怎么在这里”，“您的家里人在哪”这类的问题。最终都没有形成对话，老太太还是自顾自颤颤巍巍地喊阿巴阿巴。这个时候旁边单元出来个中年妇女远远说了什么一句，我听不懂，只是听到“神经病”三个字。一看有亲戚在旁边，我想眼前这一切大约都还在别人的可控范围里，可以走了。 也不知道这个阿巴到底是什么意思，或者说于老人自己是什么意思。路上我故意想得戏剧性一些，难道是老太太的什么亲人，早年走失的儿子？当然了，很有可能只是一个老人丧失语言能力之后惟一能发出的声音而已。

不管这是不是30号下午我伸直了脖子期待的国庆假期，总之伴随明天早晨8点45分打卡机一声鸣音它是要见鬼去了。8号？8号用来中和后一天的周一综合症吧，不指望了。今年国庆真是无聊到一定程度了，我印象中似乎从来都还没有这么无聊过。本来还想着靠自己一些勉强存在的兴趣爱好来抵抗无聊的，后来发现是不堪一击。概括地说这六天看了整整六天的喜羊羊。上帝啊。好像也不完全是，还听了很多革命歌曲看了一些老电影。总之正经事是没有什么明显的进度，哎呦不说了，我现在连什么是正经事都说不清楚。 在上海一点出门的欲望了都没有，六天以来取得最远的地方就是旁边的超市，其中还有包括今天在内的三天连楼都没下去。豆瓣上本来还有个老电影的活动来着，结果正好是明天加班，想去也去不成。形势危急，主办方发了三封豆邮说大家快去，不然这个活动办不下去了。我想着在北京的时候还有点兴趣爱好什么的，那么严酷的斗争环境，周末还去听个讲座参加个沙龙什么的，在上海就一点胃口都没有了。要不以后还是找机会去北京吧，但是去干什么呢，真无聊。 今天突然冒出个想法，要是能重活一次的话，我马上毫不犹豫爬到楼顶跳下来reset。 好在好在，明天就回公司了，要试着配一下ehcache的集群，有时间的话比较一下RMI方式和JGroup方式的性能，再做下一步打算。对了，还有一个系统的维护指南要写。 我还是想想明天上班Syu时的情景吧。 PS:此文是用Firefox的插件ScribeFire发的

针对地理数据的ORM，有一个Hibernate的扩展HibernateSpatial项目可以将JTS对象映射到MySQL/PostGIS/Oracle中。这个扩展同样可以用在Grails里，这里有一篇简单的介绍，关于在Grails和MySQL中管理地理数据： http://www.grails.org/MySQL+GIS-Geometry+with+Grails 不过按照这个文章里介绍的方法用，很可能会遭遇这样的报错： org.hibernate.MappingException: No Dialect mapping for JDBC type: 2003 这个问题最终在这里得到了解答： http://n2.nabble.com/No-Dialect-mapping-for-JDBC-type-2003-td1141106.html 按照邮件列表里的反映，上面的配置在Postgis里是可以work的，但是如果用Mysql还需要指定JPA的columnDefinition，对应的Hibernate属性是sql-type。虽然作者承诺会在今后的版本里修改这个问题，不过眼下的M2版本还没有修正这个问题。为此，Grails的用户特地提出在Grails中加入sql-type的支持： http://jira.codehaus.org/browse/GRAILS-3201 现在按照下面文档的说明，可以在mapping里指定sqlType了： http://grails.org/doc/latest/ref/Database%20Mapping/column.html 实例代码里的domain定义应该改成： import com.vividsolutions.jts.geom.Polygon import org.hibernatespatial.GeometryUserType public class MyPoly { String name Polygon poly static mapping = { poly type: GeometryUserType， sqlType:”GEOMETRY” } } 于是，再也没有莫名其妙的No Dialect报错了。

废话不说了，直接上code吧： import com.drew.imaging.jpeg.*; import com.drew.metadata.*; import com.drew.metadata.exif.*; file = new File(“sample.jpg”); meta = JpegMetadataReader.readMetadata(file); gpsdir = meta.getDirectory(GpsDirectory.class); lat = gpsdir.getRationalArray(GpsDirectory.TAG_GPS_LATITUDE); lon = gpsdir.getRationalArray(GpsDirectory.TAG_GPS_LONGITUDE); lats = lat[0].doubleValue() + lat[1].doubleValue()/60 + lat[2].doubleValue()/3600; lons = lon[0].doubleValue() + lon[1].doubleValue()/60 + lon[2].doubleValue()/3600; println(lats); println(lons); metadata-extractor似乎是现在惟一的读取exif信息的java库。在ivy中可以添加这样一个依赖： <dependency org="com.drewnoakes" name="metadata-extractor" rev="2.4.0-beta-1" conf="runtime"/>

续昨，好吧，这个无聊的国庆假期就献给karmic了。gnome-shell已经可以在软件仓库里找到了，apt-get安装即可。要使用gnome-shell可以执行 gnome-shell –replace 要把gnome-shell作为默认的窗口管理器，打开gnome的配置编辑器，找到/desktop/gnome/session/required_components，把panel和windown-manager全部改成gnome-shell，重新登录即可。 上个图： 当然了，还没有正式release，大家试用尝鲜注意安全第一。

续昨，虽然昨天升级到了gnome2.28，也安装了libchamplain，但是却没有发现这个库应用。Ubuntu上的Empathy似乎是没有把location support编译进去。看不到效果怎么办，好在libchamplain的作者还提供了另一个应用。这是一个eog的插件，用于读取照片的exif信息中的gps latitude和longitude，进而将他显示在libchamplain的地图里。 安装这个插件可以follow官方网站上的做法，当然开发包、头文件之类的东西要齐备。 libchamplain使用了clutter，在载入地图的时候还有fadein的效果。clutter是将要应用在下一代桌面gnome shell中的图形特效库。 插件是用C写的，可以看成是libchamplain的一个例子，作者说已经有了其他语言的binding，如此未来在gnome桌面上开发tile地图程序会变得简单。