Archive for September, 2010

DokuWiki – 知识管理(整理)工具有着落了

2010-9-27 21:14 | by 2ndboy

  最初接触 Wiki 是在 2004 年左右,那时候用的是 UseMod Wiki。当时就觉得 Wiki 是一个知识管理的好工具,而且非常方便多人协作来贡献信息(Google Docs 的多人实时协作编辑何尝不是一种对 Wiki 的增强呢?!),所以就想尝试用 Wiki 来管理和整理自己平时的一些积累。但是当时一来没有稳定可用的空间,二来我对当时接触到的一些 Wiki 系统不太透明的数据存放方式不太感冒,觉得编辑者无法完全掌控数据的存储层次关系,所以后来就没有了下文。

  最近工作上打算跟跨分公司的同事一起编辑一些文档,所以就又捡起 Wiki 来研究了一番,这一研究不要紧,让我这跨度达 6、7 年的寻找知识管理工具之旅有了个结果。

  一开始为了安装配置简单,所以就比较随便的找到了 PmWiki 来用,搜寻的主要方向当然是在我比较熟悉的 PHP 领域了,PmWiki 是用 PHP 实现的,而且不依赖于数据库,是把所有 page 保存在磁盘上的 TXT 文件中的。这一特性相当的吸引我!因为我在工作以后的一段时间里,逐渐形成了记工作日志的习惯,这样有些事情在时隔数月已经忘记的情况下仍然可以通过使用 Windows 自带的文件内容搜索回想起来。这些工作日志都是记在 TXT 文件里,按年份和月份分目录存放的。所以我现在仍然可以很轻松的查到自己在 2003 年的某一天里遇到和解决过什么棘手的问题:) 不得不表扬一下自己,这是个好习惯,虽然有时候你会觉得“浪费”了一点时间:)

  用了几天 PmWiki 之后偶然的看到了 Riku 的这篇“用 DokuWiki 打造个人知识管理系统”,于是很幸运的认识了 DokuWiki。(推荐另外一篇不错的比较 PmWiki 和 DokuWiki 的文章——“优秀的 Wiki 程序:PmWiki 和 DokuWiki”)

  试用之下惊喜异常:) 因为俺觉得,这下找到真正想要的东西了!跟 PmWiki 一样,DokuWiki 也是用文本文件来存储 Wiki pages 的,但是 DokuWiki 的 Wiki Page 文件是纯粹的 Wiki content,而 PmWiki 的 page 文件里同时混杂了 page 的修订历史记录,其实就凭这一条就能吸引住有数据洁癖的我:) DokuWiki 这种把 page 数据和 page 修订数据分开存放的方法其实相当科学,既方便了数据备份和迁移也方便了修订数据的清理(个人认为 Wiki 的这个类 VCS feature 在某些情况下很有用,但是在另外一些场合下是完全多余的)。另外 DokuWiki 对于中文的支持比 PmWiki 要好,虽然在 DokuWiki 里对中文 page name 或者 namespace 的支持也“不好”,但是个人认为这其实不算什么缺点:) DokuWiki 的 namespace 也深得我心,namespace 在 DokuWiki 里就是给 page 进行分类的,而在存储系统里它们二者就对应着文件夹和文件,这跟我记工作日志的习惯简直太一致了!大爱!

  其它优点还包括了数量众多的 plugin 支持,强大的 ACL 控制能力等等。说到 plugin,DokuWiki 里有很多 export to PDF plugin,这个特性也非常吸引我,想想你编辑和整理的众多信息可以很轻松的做成 PDF 文件保存和分发,而且所用的编辑语法又是简单的 Wiki 语法而非天书般的 DocBook,简直是太爽了!这方面,时间关系我只尝试了 dw2pdf,而且暂时没找到支持中文的方法,最终格式效果方面也还有瑕疵,就留待以后去研究了。

  我在空间里装上了 DokuWiki,地址是 http://wiki.2ndboy.net(也可以点 blog 顶上的链接进入),今后会陆续记录一些 blog 不方便和不适合记录的东西,欢迎有空坐坐:)

Hudson 的分布式 build

2010-9-14 22:18 | by 2ndboy

  前段时间一直比较忙,最近几天利用稍稍松下来一点的时间研究了一下 Hudson 的分布式 build。同样,以下内容都只在 Windows 平台下验证通过。

  一般来说,如果项目需要在不同的平台上进行编译的话,分布式 build 就比较有用了。假设某项目需要在 Windows、Linux 和 Mac 进行编译,那么可以拿一台 Windows 主机安装 Hudson 做 master,同时进行 Windows 平台上的 build。然后再分别在一台 Linux 主机和一台 Mac 主机上配置 Hudson salve。之后就可以在 master 上创建 job,然后在不同的平台上做 build 了。

  另外一种用途就是纯粹的负载均衡了,默认情况下 Hudson 在一台主机上只允许同时进行两项 job(当然这个可以在系统设置的“# of executors”里进行修改,但是这个数字肯定是跟主机的配置情况相关的),如果你有数十个 job 需要同时做 build 的话,为了便于统一管理,这时用到分布式 build 也是个不错的主意。

  下面就是一些设置步骤的记录:

Slave 端主机的设置

Hudson 在 Windows 平台下是通过 DCOM 对 slave 进行操作的,所以首先要保证 slave 主机的 DCOM 相关 service 可以正常工作。

Master 在操作 slave 主机时需要以 slave 主机上的用户身份登录进行,所以要在 slave 主机上为 Hudson 创建一个管理员帐号。

在 slave 主机上为 Hudson 无色一个栖身之所,比如 D:\HudsonSlave。这个目录无需手工创建。

Master 端的设置

以管理员身份登录 Hudson 的 master 端,进入“系统管理”->“管理节点”->“新建节点”,如下图:
新建节点
注意“节点名称”不能随便写,因为我们后面要创建/连接的是一个 Windows 平台的节点,所以节点名称一定要用 IP 地址或者主机名称。“Dumb Slave”一定要选,否则无法继续。

新建节点的填写例子见下图:
节点设置
“Remote FS root”填写的是位于 slave 主机上的路径,就是刚才你为 slave 选的那块宝地。
“Labels”比较有用,它是用来描述 slave 的一些标签,在绑定 job 时用于标识节点,不填的话默认就是节点名称。
“Usage”有两个选项,分别是不绑定 job 和只能跑绑定 job,按照实际需要选择。
“Launch method”我们这里选择“Let Hudson control this Windows salve as a Windows service”,这样设置成功以后 slave 主机上的 slave 进程会被作为服务来运行。
“Administrator user name”和“Password”填写你在 slave 主机上为 Hudson 创建的用户名和密码即可。
保存以后 Hudson 就会尝试连接 slave 主机,然后用设置的管理员用户身份登录 slave 主机,创建 slave 目录,上传 slave 程序,把它作为 service 安装。

节点创建成功以后你就会在 Hudson master 界面左边的生成状态栏里看到 salve 了。同时在 slave 主机上你会发现 Hudson 已经建好了给 slave 使用的文件夹并且上传了一些文件,同时你会在 slave 的 service 列表里看到一个新 service,如下图:
Hudson slave service

Slave 的使用

Slave 连好以后,你就可以给它分配活儿干了。当然,这个新“奴隶”能干什么活儿跟你在创建它的时候的设置很有关系,如果你创建它的时候在 Usage 里选的是“Utilize this slave as much as possible”的话,那么普通的 job 不用做什么额外设置就可以跑在这个 slave 上了。但是如果你在 Usage 里选的是“Leave this machine for tied jobs only”的话,那么只有跟这个 slave 进行了绑定的 job 才能跑在这个 slave 上。

其实由于配置和程序安装的情况不同,一般来说让 job 跑在特定的 slave 上更常用些。把 job 跟 slave 绑定很简单,进入 job 设置,在“Tie this project to a node”里选中某个 salve(或者 master)就可以了。这样这个这个 job 以后就只能跑在某个特定的节点上了。

Slave 的删除

在 master 的管理节点页面里删掉 slave 只会让 slave 在 master 上不可见、不可用,但是 Hudson 不会对 slave 上的文件和 service 做任何删除操作。

在 slave 主机上彻底删除 slave 需要两个步骤,删除 service 和删除 slave 程序。由于 Hudson slave service 的名称里有盘符和路径分隔符,所以用“sc delete xxx”是不管用的,需要在命令行下进入 slave 目录运行“hudson-slave.exe uninstall”,之后就可以把整个 slave 目录干掉了。

后记

结合之前的那篇“用 Hudson 实现 Visual Studio (C++) 项目的 daily build”,看完这两篇 post 以后在日常工作里应用 Hudson 应该已经没什么大问题了。我陆续抽时间把我使用 Hudson 的过程写出来,希望对想要学习使用 Hudson 的同道有所帮助,同时也为这个优秀的持续集成工具的普及做些事情,Hudson 是个好东西:D

自由日

2010-9-11 13:18 | by 2ndboy

两年啦!!!