C

安装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服务部门，希望能为公司其他同遇到这个问题的同事提供一些帮助。 ...

近期在考虑对底层函数库进行一些重构，今天下午花了两个小时考量现有的函数库的接口设计，发现目前函数库的实现存在着一个普遍的问题：与特定的内存分配实现耦合的太紧。 我们的应用是多进程结构的，并使用了共享内存这种最快捷的IPC机制，鉴于此很多同事在实现一些数据结构或者算法时可能只考虑到了我们常见的应用场景-多进程共享，而对非共享内存分配的情况考虑不足。那如何将目前某些库函数实现与内存分配之间的强耦合解开呢？针对这道题我发起了一次mail讨论。 题目再重述一下：“目前底层库中的一些数据结构，比如xx_tree、xx_hash_table等，在它们的实现中都会有“分配内存空间”的需求，现有的实现多是直接调用已有的xx_shm_malloc和xx_shm_free在共享内存上动态申请和释放内存，但实际上有些场合我们并不需要在共享内存上分配内存，进程私有堆上的内存完全可以满足需求。如果让大家考虑修改目前xx_tree的实现或重新设计xx_tree的接口，以达到让xx_tree支持多种内存分配策略的目的，你是如额考虑的，请谈谈你的设计思路。" ...

今天下午例行项目例会，例会内容乏善可陈(但都还是比较重要的事情^_^)，无非是跟踪进度、跟踪之前未解决的问题等。近几次的例会或技术交流会我都会给大家分享些东西，哪怕是告诉大家如何从C Shell迁移到更高效的Bash Shell这样的小事情。 ...

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，也没有用过。 ...

本周二，我们产品在某省的一个节点应用运行时出现了“死锁”情况，由于监控得力，我们在“死锁”后一分钟内就发现了这个情况，并及时重启了这个节点应用。由于是集群式系统，一个节点的故障对整个系统业务的运行几乎没造成什么影响。不过，这确是一个潜在的隐患。 ...