Linux

有了BuildBot搭建的持续集成环境还远未结束，具体的构建脚本还得自己来写。我们用的是Make工具，对应要编写的脚本就是Makefile。 Make是日常代码构建常用的工具，尤其是绝大多数C和C++项目都会将Make作为首选构建工具。平时多数情况大家都是直接敲入make命令便开始了构建过程，很少有人为make传入什么参数的（调试Makefile的情况除外）。但是有些时候自定义的Make命令行变量还是很有用处的，特别是在将Make与持续集成环境集成的时候。 ...

今天是Ubuntu 11.04版本(Natty Narwhal)发布的正日子！想必全世界的Ubuntu Fans们都会或多或少的兴奋上一阵儿。我接触Ubuntu这个Linux发行版较早，甚至可以追溯到Ubuntu 5.10。不过真正将Ubuntu作为我日常工作学习的第一操作系统还是在去年Ubuntu 10.04LTS版本发布之后。从那时起到现在整整有近一年时间了。这里我也来说说这一年来使用Ubuntu的感受。 ...

今天上午处理了一个线上产品的故障。分析来分析去，最后定位问题还是出在字节序转换的环节上。 其实测试组早在产品上线前就曾报告了这个问题，但是对应的开发人员并未对该问题进行深入地分析，而是有些草率地将该问题归结为客户端模拟器的实现不符合标准。因为这位同事比较资深，所以当时我也没有给予足够关注。 ...

部门一直使用Subversion作为源码版本的管理工具。说实话，Subversion比较适合目前部门的绝大多数项目：没有异地团队开发，代码中心化管理；基本上都在trunk上开发，较少使用分支，基本上没有在各个branch间切换的成本。但对于我来说，有些情况下Subversion并不能满足我的需求。 问题主要集中在本地代码的备份和版本管理上。也就是说对于尚未或暂无法提交到Subversion服务器的本地代码来说，存在着被误删除和版本更新无法回退两大杯具情形。而对于这些情况，Subversion工具是无能为力的。 这时我们就需要借助其它工具来帮我们解决问题。Git就是这样一款很给力的工具，它是一款分布式版本管理工具，由linux的缔造者Linus Torvalds设计并实现，具体关于Git的介绍和使用方法可参见其官方站。这里要说的是Git是如何做到既可以管理好本地代码又可以与已有的SVN中心库进行同步的。 ...

下班前，一位同事发来的mail中提到这样一个问题：在Solaris上，新添加到Project中的一段代码编译有Warning，由于我们在Makefile的GCC命令行中设置了"视警告如错误“的-Werror编译选项，导致了项目无法成功Build。 这个Warning内容如下： warning: `0’ flag used with `%s’ printf format 产生这个Warning的那行代码大致是类似这样的：printf("%05s%06s\n”, “11”, “222”); 其实这段代码是从老项目中Copy出来的，在老项目中，这段代码运行的很是正常，也许它在老项目Build时也会产生Warning，不过之前大家也都没有关注。 ...

除了autoconf和automake，GNU的autotools工具包中还有一种工具，它就是libtool。顾名思义，libtool是一个关于库文件制作、安装和使用的工具，它屏蔽了各个平台在库制作、安装和使用方面的差异，为上层提供了统一的接口。你可以直接使用libtool创建静态或共享库，也可以将libtool与autoconf、automake结合在一起使用。第二种方式显然更具实际意义，也更为简单。 在一个使用autoconf和automake构建的编译环境中添加libtool的支持，只需改动几处即可： 首先，你需要在configure.in(或configure.ac)中添加AC_PROG_LIBTOOL宏(注意：去掉AC_PROC_RANLIB宏)。 其次，修改Makefile.am： 如果是建立库文件，则需将lib_LIBRARIES改为lib_LTLIBRARIES，同时将库的后缀名由.a改为.la，这将告诉automake采用libtool来创建相关库： lib_LIBRARIES = libfoo.a => lib_LTLIBRARIES = libfoo.la libfoo_a_SOURCES = libfoo.c => libfoo_la_sources = libfoo.c ...

近两天一直在考量产品安装包改进的事宜。说实话，我们的安装包做得不够"专业"，不仅没有按照各个平台的标准安装包形式(比如redhat的rpm，debian的deb或solaris上的pkg包)制作，而且安装包在生产环境中还需要再进行一次链接才能得到最终的可执行程序。这样一来，每次制作安装包都很费时费力(虽然有自动打包脚本)，安装包的"体积"也很是庞大，因为包中要包含所有.o目标文件和一部分自有库以及第三方库的.a文件。 ...

近期有了在TeX文档中插入源代码的需要。TeX的\verbatim可以帮助你保留输入text的原始格式，但用于输入源代码还是显得不够专业。Google了一下发现TeX中支持插入源代码的包也有不少，如LGrind、Listings等。LGrind似乎没有包含在TeX Live的默认安装包中，用apt-get尝试安装LGrind，发现居然要占用近200M的空间，遂放弃之，最后我选择了Listings宏包。 Listings宏包短小而强大，其典型应用方式如下： ...

自从有了For book的中文TeX模板后，我对TeX的热情便"继续"一发而不可收拾^_^。上周原本计划为内部的一个交流准备一个PPT，但在开始构思之前却突然想到：是否可以使用TeX完成幻灯片制作呢？Google了一下，果然有成熟解决方案-使用BEAMER。 有了TeX基础后，学习使用Beamer构建幻灯片就显得容易了许多，用TeX创建幻灯片文档与编写普通文档差别并不大。TeX制作的幻灯片文档也是由三个部分组成：文档类声明、Preamble区和正文区。 文档类声明中的选项为beamer，表示我们要创建幻灯片文档。 \documentclass{beamer} % 文档类声明 Preamble区甚至可以复用普通TeX文档中的那些设置，这里不再赘述^_^。 ...

与"Hello World"作为编程入门时迈出的第一步相似，"Hello TeX“也只是学习博大精深的TeX的一块儿敲门砖，离真正的实用还差的远。 两周前开始体验TeX，直到今天才东拼西凑地倒腾出一个够自己使用的且相对实用的基于XeTeX和xeCJK的小模板。这里分享一下，希望能给大家带来一些帮助，同时对自己也算作是一个备忘。关于TeX网上资料很多，这个模板里的东西也都是参考和融会各种资料并试验后总结而成的。如果你是TeX方面的高手，大可不必理会下面内容^_^。 ...