“A language that doesn’t affect the way you think about programming， is not worth knowing”. — Alan Perlis(ACM 第一任主席，图灵奖得主，1922-1990) 《程序员修炼之道》这本书建议程序员每年应至少学习一门新的语言，以拓宽思维，避免墨守成规。今年我选择了函数式编程语言Haskell。选择Haskell的理由正如Alan Perlis所说的那样，Haskell是一门可以影响程序员编程思维的语言，我也期望通过学习Haskell来拓宽我的思维。 ...
今天下午花了一个小时分别和两位同事做了一些代码讨论，这两位同事正在编写的代码都具有一定的试验性质(暂不能进入项目代码库)。这里不谈代码如何如何，而是就我发现的一个问题谈谈我的看法。 ...
每次安装Ubuntu后，主文件夹(你的$HOME目录)下都会默认建立起一些目录，诸如：下载、音乐、图片等，这些目录的用途通过其名字都可以猜个八九不离十，只有一个叫作“模板”的目录一直让我摸不到头脑。直到这次彻底迁移到Ubuntu，我才发现这个“模板”目录的妙用！ 平时工作中常常需要新建一些文档，以前用Windows时都会使用右键菜单，点击“新建”，然后选择不同的文档类型。但在Ubuntu上却发现右键快捷菜单中“创建文档”的二级菜单项中默认只有"空文件”这一种文档类型，这显然不能满足我的需求！ ...
今天做了一些项目版本库的搭建工作，主要是将相关模块和库目录建立好，将Makefile编写好，并添加到SVN库中。 工作接近尾声时，无意中发现提交到SVN库中的文件居然都带着可执行权限(以下称x属性)，如： -rwxr-xr-x 1 tonybai tonybai 203 2010-04-21 17:26 Makefile* 这着实让人觉得别扭！Svn居然记录了文件的权限信息，至少我以前还没有关注过这点。 ...
安装Ubuntu已有一周多，无论是在工作单位还是在家里，Ubuntu都作为我的第一OS，Win7基本上处于被打入“冷宫”状态。事实证明对我来说，Ubuntu完全可以取代Windows。 公司提供有线和无线网络两种接入方式，对于致力于追求“理想的无线世界”的我来说，无线接入是我的第一选择。公司的无线接入采用TTLS认证方式，在WinXP和Win7上都有相应的客户端(SecureW2)可供使用，但在Ubuntu上是否有此类客户端我还不知道，咨询了公司的IT服务部门，得到的回答也是“不知道”（想必在公司内部像我这样使用Linux OS的少之又少）。在网络上寻找答案也未果。我之前对无线接入认证那些术语了解甚少，甚至不知道公司采用的是哪种认证方式，但通过SecureW2官方站以及Wikipedia了解到了公司用的是TTLS认证。我无意中打开Ubuntu无线网络连接配置，在连接“编辑”对话框的“无线安全性”标签中居然看到了"隧道TLS"方式，难道Ubuntu内置就支持TTLS？于是我就按照Windows上的配置方式尝试配置了一下，包括密钥协议和内部认证等，点击连接，哇，居然真的连上了！打开Firefox测试了一下，一切OK，问题解决。我将配置方法简单写成了一个Mail发给了公司IT服务部门，希望能为公司其他同遇到这个问题的同事提供一些帮助。 ...
今天下午例行项目例会，例会内容乏善可陈(但都还是比较重要的事情^_^)，无非是跟踪进度、跟踪之前未解决的问题等。近几次的例会或技术交流会我都会给大家分享些东西，哪怕是告诉大家如何从C Shell迁移到更高效的Bash Shell这样的小事情。 ...
近期在为一个新项目作版本库规划，并策划一些即将应用于该项目的版本控制和发布流程的Rules。借此机会我也花上一些时间对我们之前的版本控制和发布流程进行一下反思，也翻看了一些书籍(比如《版本控制之道-使用subversion》、社区自由图书《Subversion与版本控制》等)，了解一下Best Practice是什么样子的，同时也纠正一下我之前理解不正确的地方。 ...
自从知道Ubuntu这个linux发行版后，就有了彻底迁移到Linux上的想法。但迫于各种各样的因素一直未能下定决心，这期间Ubuntu发行版已经从6.10进化到了10.04。经过长时间(近四年，时间长的的确有些夸张^_^)的准备，再借着Ubuntu 10.04 LTS发布的东风， 我终于下决心彻底走进Ubuntu的世界。 安装Ubuntu对我来说已经是驾轻就熟的事情了，这里也没什么好说的。对我来说，迁移到Ubuntu的主要工作集中在： 1、完成两个平台数据共享和迁移 2、选择和安装用于替代Windows上常见应用的软件 ...
一直以来我们对项目代码的提交管理都是粗放型的，即对大家提交代码的时间、频率和提交日志的形式都没有严格的要求，可谓比较随意。主要发现的问题包括： - 某些提交没有规划，甚至随意增加一些并无太大意义的注释都作一次提交。 - 提交的代码甚至没有经过REVIEW和UT，这样的代码即使内部发布，也会带来后续工作量的严重浪费（测试、发现问题、定位问题、重新fix、重新验证等）； - 提交日志无实际意义，如commit log为空、commit log没能真实反映出这次提交的真实目的和意义、多次提交却采用同一条提交日志等等； … … ...
最近收到客户的一个需求，要求我们将产品的系统配置数据和业务配置数据定期导出备份，以防万一数据库宕掉后可以用来"救火"。产品从起初0.1版本就一直延续着一种"section-key-value"的配置文件方式，同时我们也有可复用的库来完成配置数据的读取，可是在长期的使用过程中我们发现的不少问题，特别是在存储多样化的业务数据的时候，这样的配置方式带来维护上的很大不便。 ...