技术志

使用何种工具做Feature或Defect或Task的跟踪一直是挺让我闹心的一件事。用Excel记录，但却不便于共享、统计和直观展示；Jira算是做的好的工具之一了，但无奈它是商业软件，咱没付那份儿钱，所以也就"无福享用"；Mingle是著名的Thoughtworks公司的产品，虽说不到5个license是可以免费使用的，但它却是出了名的"内存杀手"，无奈我的机器配置太差，运行起来实在太慢，遂没有坚持下去(我"眼冒金星"的渴望着更换一台无所不能的超级计算机^_^)；甚至我曾经用过ONENOTE来做跟踪，可是条目多了后，就基本不可用了。寻觅依旧进行中，这不Trac这款软件进入了我的视线中。 网络让我知道了"Trac"。“Trac"这个名字，估计与Track"异曲同工”。至于Trac具体能做什么，你可以到其Demo站点去体验一下。简单的说，Trac = wiki + 问题处理工作流；Wiki可以用来做知识积累和管理；问题处理工作流恰是我需要的功能。但到底Trac做到啥子程度，那还需要用起来后才能知道。还有一件让我觉得很"幸福"的事，那就是Trac自带一个独立的web server程序Tracd，并且Trac可使用Python 2.5.x自带的SQLite，这样我可以不用安装和配置庞大的Apache和MySQL了。让用户能快速上手应该是Trac值得其他开源软件学习和参考的一个亮点，要知道一些庞大的开源软件繁复的安装和配置过程让很多使用者产生了"挫败感"而"另辟蹊径"了。 ...

近日，Bash Shell正式发布了其4.0版本，该版本可以看作3.x的bugfix版，同时增加了诸如"Associative Arrays"等新特性。在Bash Shell的官方站点你可以下载到最新的4.0版本，不过在GNU的Bash主页上，似乎还找不到4.0版本的所在。Bash作为Linux系统默认Shell，一直受到广泛关注，而且它还是目前几大Shell(Bourne Shell, C Shell、Korn Shell、Bash Shell)里唯一还继续维护和更新的Shell版本了，目前其主要维护者是Chet Ramey，Bash的两个原始作者之一。 ...

拥有了某种工具，往往不等于就能使用好这种工具。拥有工具简单，用好工具、发挥出最大作用则较难。CSCOPE让VIM的使用者有了与SourceInsight"平起平坐“的机会，但是能否将CSCOPE的功能发挥出来还要看你是如何使用它了。 自从VIM”重装上阵“以后，我一直在使用CSCOPE。在使用过程中还是发现了一些”别扭“的事情。一般我会在一个大型Project的源代码的顶层目录使用CSCOPE -Rbq来生成cscope.out文件，如果你在cscope.out所在目录执行VIM的话，VIM会优先将cscope.out作为”符号交叉索引库“(与ctags相比)，但是如果你在某个子目录下执行VIM进入编辑状态的话，因当前目录没有cscope.out，所以VIM无法加载cscope.out文件，也就无法在文件间跳转。而必要时你还需要手动执行命令行:cs add {TOP_LEVEL_PATH}/cscope.out才能连接到cscope，发挥其功用。 ...

国内很多学习Python的人都喜欢看"A Byte of Python"，这是一本由印度小伙儿Swaroop C H写的书，之所以受到大家关注和欢迎，想必其简单而实用的写作风格是其中的重要原因吧，作为入门书很适合。我的Laptop中就有一本中文翻译版，不过书中用的还是Python 2.3.4版本。本月3日(2008-12-3)Python 3.0 Release版祭出，Swaroop C H也在其站点上增加了A Byte of Python for 3.0版。在下载新版"A Byte of Python"的同时，我又发现了Swaroop C H的另外一部作品"A Byte of VIM"。 ...

今天是冬至，也是入冬以来感觉最冷的一天，毫不夸张的说：你一张嘴，牙就冻上了。上午LP在家收拾卫生，我继续用Scons改造现有的项目。下午出去理发，头发长长了后，似乎会造成思维迟钝^_^。 试验性的用Scons改造现有的project，过程中对Scons了解又多了一些。上篇文章对Scons的性能没有给出定论，经过对Scons的深入后，发现Scons在执行初始时的性能的确不够快，这是因为Scons启动后，会对全部SConstruct以及下面子目录中的SConscript进行分析，子目录越多Sconscript文件个数越多，性能也就越差。但是这种分析也有一个优点，就是能帮你提前发现你SConscript中的一些“语义”错误，比如如果你在编译两个基础库，一个叫add，一个叫sub，这个基础库源码分别分布在两个目录add和sub中，编译后将分别生成libadd.a和libsub.a的库文件，但是如果你马虎了，在编写SConscript时将target都写成了’add’或都写成了’sub’，则Scons会在执行gcc之前就帮你找出这个"语义"错误，提示如下： /export/home1/tony_bai/xxlib>scons -f SC*t scons: Reading SConscript files … scons: *** Multiple ways to build the same target were specified for: /export/home1/tony_bai/xxlib/lib/libsub.a (from [’/export/home1/tony_bai/xxlib/add/libsub.a’] and from [’libsub.a’]) File “/export/home1/tony_bai/xxlib/sub/SConscript”, line 3, in ...

部门的一套基础库刚刚移植到Linux上，为了测试该库，我将工作环境切换到了Ubuntu Linux下面。切换后居然发现Ubuntu下的Firefox访问网页巨慢无比，Firefox显示时明时暗，总是被挂起。同样的公司网络环境在Windows下使用Firefox访问互联网很顺畅，没有卡的现象。看来是时候给Ubuntu下的firefox提提速了。 ...

发现或者说知道SCons是缘于Google的comp.lang.c group上的一则名为"Best Build Tool for large C projects “的帖子，帖子的作者列出了11条他认为"Best Build Tool"应该具备的特点，并欲找到这样的Build Tool。在该帖子的回复中，有人提到了Scons，说来惭愧，这是我第一次听说到有这样一个工具。一直在Unix下编写C程序，习惯了Make，也对Make的复杂度和较为陡峭的学习曲线有所了解，曾经尝试使用Autoconf和Automake，但是都因上手困难而放弃。自己心底也一直想找到一个更简单一些的但又不失功能的适合C的Build Tool，Scons是否能满足的需要的呢？好奇心驱使着我去发掘一下Scons。 ...

今天闲时写了一个Demo测试程序，目的：测试64位编译下使用mmap映射共享内存的能力。程序很简单，大致如下结构： #define MAP_SPACE_SIZE (4*1024*1024*1024) unsigned long int ms_sz = MAP_SPACE_SIZE; …. …. ptr = mmap( NULL, ms_sz, PROT_READ|PROT_WRITE,MAP_SHARED, fd, 0 ); ...

最近在思考改进项目中一模块的实现，该模块维护起来让我很是头疼，所有才有了整体换掉它的想法。设计和实现中利用了内存对齐的技术。关于内存对齐，我曾经写过三篇文章，第一篇介绍了计算内存对齐的方法和例子，第二篇说了一个内存对齐的应用；三谈内存对齐时，则从其本质上做了阐述，而这次实际上是继续在其本质上的做文章，结合本质谈谈为什么内存对齐的计算方法就应该是第一篇中所讲的那两条。 如果对内存对齐本质还不清楚的话，就看看我的内存对齐系列的第三篇吧。如果你清楚了本质，那么我们结合第一篇中交待的内存对齐计算方法来进一步探究，为什么计算的方法就是这个样子的。 ...

一口气读了七章"Code Complete 2nd(以下称CC2e)“中的内容，从第七章的"高质量的子程序"到第十三章的"不常见的数据类型”。之所以一口气读这么多，是因为被其中的内容吸引了。这两天的下午一直在做代码评审，所以晚上看CC2e的时候，思维不停的在项目代码和书中内容之间跳转。一直把"代码大全2nd"当作一门百科全书式的手册类图书，买回来后一直陈放在书架上没有问津。直到今天在考虑一个关于断言使用的问题时，才想起来去查查这本百科全书，想看看书中是如何阐述断言的。于是便拿起了这本书。 ...