Unix

前不久某南方省份的客户反馈说我们的产品对某些生僻字(如“赟”)的转码支持的不好，终端收到后无法显示这个字。 经分析，发现类似“赟”这样的字在GB2312编码标准中并未收录，要想支持这样的生僻字的内码转换需要产品支持目前最新的中文编码标准GB18030。而我们的产品在诞生到现在就一直只支持GB2312，这就是导致这一问题的直接原因。 ...

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内码文件的读写。 ...

目前部门还没有采用Pair Programming那种时时刻刻都在review代码的工作方式，代码Review多采用走查方式，即代码写完后召开一个Code Review的Meeting，集中时间和经验丰富的人力对重点代码进行筛查，这种方式的代码Review有利，但也有弊。其弊端在于低效和覆盖面小。做一次走查需要N多人参与若干个小时，而在这段时间里不是每个参与者都能极其高效的参与到走查中的，实践证明只有少数几个人能真正在一次代码走查会议上起到关键的作用。另外走查一次能覆盖的代码范围又较小，一些看似不重要却很可能带来BUG的代码在走查会上很容易被遗漏。 ...

部门服务器资源向来都比较紧张，每当忙碌季节到来，服务器资源消耗都较大，开发人员总是抱怨编辑代码慢、Build慢以及磁盘空间不足等问题，严重时甚至无法工作。部门也一直在尝试改善这个问题，无非加服务器、加磁盘等，但是这些措施似乎都难以满足开发和测试人员日益增长的对服务器资源的索求。 ...

周六，对于上班族来说是多么好的日子，能在家里享受自由的无拘无束的生活而且不用担心第二天的工作，应该说是一周中最没有压力的一天。六点半起床，慢慢喝下一杯225ml左右的凉白开（保健医生说20-25摄氏度的凉白开比较适宜作为起床后的第一杯水），套上运动短裤和上衣，打开MP3播放器，塞上耳机，出门在园区内慢跑。昨晚下了一场雨，所以园区早上的空气很好。耳畔酷玩乐队的“Viva La Vida”让我跑起来很轻松，30分钟的有氧慢跑能让我的大脑和心脏获得足够的氧气，心情也变得更好。最后绕着园区走上一圈结束锻炼。 ...

比较以下两组代码，你认为哪组运行的更快些呢？ Example1： int n = 100; int n4 = n » 2; int i = 0; int a[100]; for (i = 0; i < n4 ;i += 4) { a[i] = i; a[i+1] = i+1; a[i+2] = i+2; a[i+3] = i+3; } ...

直接操作C标准库提供的字符串操作函数是有一定风险的，稍有不慎就会导致内存问题。这周用业余时间写了一个小型的安全字符串操作库，但是测试之后才发现自己的实现有很大的性能缺陷。 在Solaris上初步做了一个简单的性能比对，以下是得到的性能数据(以strlen的数据为例)： 当传入的字符串长度为10时，执行100w次： strlen 执行时间是：32762毫秒 my_strlen执行时间是：491836毫秒 ...

近日，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，发挥其功用。 ...