2008年末和一位同事在山西出差，发现那位同事在用TiddlyWiki写一些日记，那时候算是第一次知道TiddlyWiki，但不知是为什么，当时的我并没有被TiddlyWiki所吸引，也就失去了一次使用TiddlyWiki的机会。 近期新启动了一个产品版本的开发任务，该版本是对之前遗留系统版本的重构和优化，我们想趁此机会将梳理遗留系统时总结下来的东西以及一些新的设计想法记录下来，以便于后人参考并迅速上手。曾经使用Confluence搭建过一个Wiki，但是该系统因公司政策被取消了。公司一年多以前建立了一个知识管理系统，不过我们发现这个系统极其难用，完全不能满足我们需要，这时我们又想起了TiddlyWiki。 ...
近期在为一个新项目作版本库规划，并策划一些即将应用于该项目的版本控制和发布流程的Rules。借此机会我也花上一些时间对我们之前的版本控制和发布流程进行一下反思，也翻看了一些书籍(比如《版本控制之道-使用subversion》、社区自由图书《Subversion与版本控制》等)，了解一下Best Practice是什么样子的，同时也纠正一下我之前理解不正确的地方。 ...
自从知道Ubuntu这个linux发行版后，就有了彻底迁移到Linux上的想法。但迫于各种各样的因素一直未能下定决心，这期间Ubuntu发行版已经从6.10进化到了10.04。经过长时间(近四年，时间长的的确有些夸张^_^)的准备，再借着Ubuntu 10.04 LTS发布的东风， 我终于下决心彻底走进Ubuntu的世界。 安装Ubuntu对我来说已经是驾轻就熟的事情了，这里也没什么好说的。对我来说，迁移到Ubuntu的主要工作集中在： 1、完成两个平台数据共享和迁移 2、选择和安装用于替代Windows上常见应用的软件 ...
这周五工作状态实在不好，也许是工作得有些疲劳的缘故。没有了心思工作，那莫不如利用这些时间读读书。在存储电子书的目录中左翻翻右看看，发现了那本久违了的中文版VIM手册，我决定索性打开温习一下，拣一拣那些已经生疏了的但却极其实用的命令。 ...
一直以来我们对项目代码的提交管理都是粗放型的，即对大家提交代码的时间、频率和提交日志的形式都没有严格的要求，可谓比较随意。主要发现的问题包括： - 某些提交没有规划，甚至随意增加一些并无太大意义的注释都作一次提交。 - 提交的代码甚至没有经过REVIEW和UT，这样的代码即使内部发布，也会带来后续工作量的严重浪费（测试、发现问题、定位问题、重新fix、重新验证等）； - 提交日志无实际意义，如commit log为空、commit log没能真实反映出这次提交的真实目的和意义、多次提交却采用同一条提交日志等等； … … ...
昨天一位同事发了一篇小文档，文档中介绍了一种开源格式化代码的工具，名为Artistic Style(astyle)，功能看起来还是很不错的。之前我写代码时比较注意代码的风格，一直按照自己的思路来美化自己的代码，用的最多的辅助工具就是Vim自带的indent功能，对这之外的格式化工具少有涉猎。记得几年前部门曾推广一款名为checkstyle的Java代码格式规范检查工具，由于当时基本不接触Java，也没有用过。 ...
对于我个人来说，将工作环境切换到Ubuntu上来有几个“坎儿”要迈过，其中最为迫切的一个就是Mail如何在Windows和Linux下共享的问题，今天我找到了解决方法。 Thunderbird和Firefox一样，都来自Mozilla组织。和Outlook等软件不同的是，Thunderbird是可以跨平台的，更有甚者，Thunderbird可以帮助我们在Windows和Linux共享邮件，当然需要作简单设置。 我的机器上安装了三系统：WinXP、Ubuntu 9.10和Slax，其中常用的是WinXP和Ubuntu。在Windows上最常用的Mail Client端软件为Outlook 2003，但Outlook是收费软件，不支持夸平台，更谈不上Mail跨平台共享。而这些恰恰是Thunderbird吸引眼球之所在。 ...
Ubuntu 9.10版本在10月29日发布，虽然没有太多吸引我的地方，但是看了网上很多关于Ubuntu 9.10的文章后，心里面还是痒痒的，终于在上周五我用午间休息时间完成了Ubuntu 9.10版本的安装。 ...
Review Board安装成功至今已半月有余，这期间我一直在试用它，虽欣喜于其提供的强大的功能，但还是有若干使用中的问题一直让我头痛不已，同时也阻碍了在部门推广该工具的进程。 ...
安装完中文语言包支持后，Ubuntu的默认locale是zh_CN.UTF-8(即简体中文语言环境，字符集内码UTF-8)。这与我们日常开发环境中Unix设定的环境有所区别，我们日常使用的环境一般为zh_CN.GBK或zh。我们的源代码文件的字符编码也都是GBK的编码，直接在Ubuntu下用默认设置的VIM打开后，中文的注释会显示乱码。如果你直接编辑这个文件并提交，那么其他在Unix下开发的同事Checkout这份源码后打开也将显示乱码（你新增的中文内容会是乱码）。 解决这个问题至少有两种方法：一种是为Ubuntu新增加一个zh_CN.GBK的locale的支持，内码使用GBK；另外一种就是通过设置VIM，在不变换Ubuntu所支持的locale(内码依旧是UTF-8)的情况下支持对GBK内码文件的读写。 ...