还是喜欢工作两个月玩两个月的生活

以前习惯了，连续两个月很有热情的投入一个项目，改设计写代码，两个月之后就累了就不想做了，就算没做完也没激情了。然后开始打机，很专心的玩一个游戏，大概玩两个月又发现这个游戏不过如此，就回去做项目了。（Coo好像说过他也是这样。）

从寒假开始，接外面的东西做，其实平均下来一个月就￥400，也就是￥400分量的工作（就是隔几天做一点也行的那种），但是连续做几个月就很累，想放松，完全不想写代码。当然这也和最近写代码的方式有点相关。

以前用ASP写代码，虽然不算得上面向存储过程（因为Access根本没有Stored Procedure这个概念），但也差不多吧，反正就是我需要什么样的SQL语句，就写怎么样的，用得多的SQL语句就封装起来成为一个VBScript Function。现在用ASP.NET 2.0，尝试按照TimeTracker Starter Kit那种简单的3层架构写，但就发现写类代码就真的很累，或者应该叫做“累代码”。首先，看起来把逻辑都封装成累，对于UI代码来说是很爽的，因为UI代码再也不用管持久层需要怎样格式的数据，反正就是组织对象，用对象方法来存取数据，那就行了。但是写类代码时就会比较头痛，因为重复写那些Property并不简单，而调用方法基本上就是直接调用当前DataProvider的同名方法然后把数据传递过去。到了持久层，也就是DataProvider，需要进行类与平板的关系型数据进行交换，也是很头痛的，其实UI表现本来也是平板的嘛，对一层立体转换并不好过。还有就是，直接用存储过程可以使用一些复杂的，例如SELECT ... IN (SELECT ...)这样的嵌套语句，但是如果要先获取内SELECT的对象集合，然后for/foreach循环来获取外SELECT结果，那就惨咯。

据说有一些中型项目的项目经理还是偏好于面向存储过程设计，而不是面向对象，不知道大家看法如何。

VeryCD做开放式中文IMDB以及吃素网站

http://base.verycd.com，和IMDB非常类似的功能，主要按照作品、人来收录，然后链接作品和人的关系（例如导演、演员、配音）。不过IMDB的资料（特别是照片）都来自官方，或者专业记者，能够拿着Invitation甚至VIP证出入各种尊贵场合的那些，而VeryCD的照片则靠网友上传。

不过VeryCD的资料应该是自动从IMDB同步获取的，所以看上去更加像一个“IMDB中文外挂”。也就是说，VeryCD从IMDB的网站获取所有IMDB的文字资料，然后同步到自己的数据库，同时在自己的数据库增加IMDB没有的字段（主要是电影/演员中文名和中文简介之类的字段），然后评论是VeryCD的而不是IMDB的。还有就是，用户能够好像修改wiki那样修改VeryCD上的资料，但如果用户修改了资料然后IMDB也更新了资料，那么是不是又用IMDB的覆盖，那就不知道了（反正就是wiki类的东西，覆盖来覆盖去都没所谓）。

正所谓弱肉强食，那些靠养着一群编辑的网站已经变成绿色植物成为了食物链的源头，过去dot-com的投资已经足够多也就造成了绿色植物过多，现在是时候为了平衡一下生态环境削弱一下它们的优势了。所谓的食肉动物，就是那些打着share或者aggregate旗号直接利用别人站点内容的站点，把植物拿过来消化一下，然后变成自己的组织和能量，真是个不错的主意。既然现在绿色植物过剩，那么在接下来一段时间做做吃素网站也不错，起码不用养着一身的叶绿素，吃就行了。至于再以后，就想想办法如何做肉食动物吧，那是以后的事了……其实我是很赞成研究企业生态学的，如果一个企业能够维持好和其他有利害关系的企业的关系，不把自己的食物吃紧，同时又保证有天敌存在帮忙吃掉一些自己的同行竞争者确保这一样不过过度繁殖，那就够了。

ClaimID.com - 声明哪个是你

很有趣的服务，我是听Inside the Net的podcast听到的，可以来看看Inside the Net主持人Leo Laporte的页面：
http://claimid.com/leo
又或者ClaimID负责人之一的Fred Stutzman的：
http://claimid.com/fred

因为在线有很多同名称或者同ID的人，甚至有些是恶意冒充你的名字和ID的情况，于是有了claimID这样的服务——注册一个页面，声明哪些页面是我的或者提到的是我（例如我发布在各处的blog、我参加的项目、别人对我的评论），当然还可以声明哪些不是我。甚至，你把你的公钥（例如PGP Key）发上去也可以，这样别人就可以随时到该页面下载你的公钥，用于解密你发给他的邮件，或者其他加密信息。反正只要是URL，你就可以发上去，类似del.icio.us，不过你不是声明该URL的内容性质如何，而是该URL与你的真实身份有什么关联。

顺便说一句，我的claimID页面在这里：
http://claimid.com/cat

英语国家开发人员总是不注意Encoding的问题

英语国家开发人员通常都不考虑需要Encoding的情况，因为他们开发的软件不需要Encoding，也不一定有机会测试Encoding，这真是麻烦。

任何一段开源代码到手后你首先要考虑它是否涉及文件读写或者HTTP收发等操作，如果涉及，就必须考虑Encoding，特别是对于有多种Encoding方式的语言（例如中文有）。如果很不幸那段开源代码对Encoding没有支持，那么你就必须自己动手去增加Encoding的支持。

如果Encoding涉及的地方只有几处，那改就是了。如果Encoding遍布整个代码，那就几乎不是改的问题了，而是重写，哎……做开发不能不懂Encoding，但Encoding实际上又真的是一个大问题。有很多与计算机架构有关的问题仅限于某些计算机，因为只有那类计算机使用该架构而需要考虑该架构的问题，这是很灵活的。但是字符是任何计算平台都要交换的，不可能强制要求所有平台都转用Unicode或者一种指定的Encoding，于是设备与设备之间沟通就必须支持Encoding之间的转换。优秀的设备（例如PC）必须支持多种Encoding共存，所以运行在这些设备的软件业需要有处理多种Encoding的能力，这看起来成了一个永远无法解决的问题……