2013年12月

一个快速、简洁和强大的新博客框架

新的博客已经使用了很长时间,回头一想,竟然未记录下任何东西,以至于当间隔两个月回来写篇文章要提交时出现了波折,甚至生成命令也忘的差不多了。果然是好记性不如烂笔头!

基于静态文件的博客引擎已经有很多了,譬如一开始我使用的 Liquidluck 。Liquidluck 提供了静态博客生成,提交 Github ,而且还提供了 Webhook 方式的接口,使生成的静态文件自动同步到 Github上。然而其最大的缺点是,未支持 Windows 系统。以前我只能 SSH 到 VPS 上进行各种操作,直接将静态文件生成到 Nginx 下,而与 Github 的同步功能则显得多余。

这一切直到遇到了 Hexo 框架才改变,而她却是一个台湾大学生使用 Node.js 编写的,心中不免产生无限敬意。

Hexo 框架使用 Github 的 page 服务,但是却并不像 Octopress 那样复杂,既需要懂得一些 Ruby 的知识,又需要一些繁琐的配置。使用 Hexo 框架你只需知道 Github 的 Page 服务,以及几个命令即可。下面就是本博客的创建过程,仅当自己以后方便,更详细的内容还是去查看官方文档吧。

1. 安装前的必备工作

Hexo 使用 node.js ,所以 安装 node.js 是必须的,此外还要有 Git 工具。

1.1 安装 Git

  • Linux (Ubuntu, Debian): sudo apt-get install git-core
  • Linux (Fedora, Red Hat, CentOS): sudo yum install git-core

1.2 安装 Node.js

$ curl https://raw.github.com/creationix/nvm/master/install.sh | sh

或者

$ wget -qO- https://raw.github.com/creationix/nvm/master/install.sh | sh

最后安装 Node.js

$ nvm install 0.10

2. 安装 Hexo

$ npm install -g hexo

3. 配置 Hexo

使用以下命令生成静态博客所使用的所有文件:

$ hexo init <folder>

目录结构说明:

.
├── _config.yml // 全局配置文件
├── package.json  // 
├── scaffolds // 生成文件时的头格式
├── scripts
├── source 
|   ├── _drafts
|   └── _posts // Makedown文章
└── themes 

全局配置文件中提供了多种参数配置,包括站点信息,作者,个性化静态地址,标签,分类,高亮,甚至 Disqus 的评论,谷歌统计等。

4. 开始写文章

$ hexo new [layout] <title>
// [layout] 是指 scaffolds 中定义的格式
// <title> 是指文件名称

$ hexo generate
// 生成静态文件

$ hexo deploy
// 将静态文件上传到 Github 中

广州之行

广州小蛮腰

从广州回来已经快一个月了,我才想起要总结一下的。

是的,很需要总结一下。不必说我们团队一起度过的无眠的夜晚,也不比说广州的现场环境的千奇百怪的复杂,单单只说上线晚上我紧急发布的补丁个数,就与别的省份的情况不可同日而语了。当然,我只去过广州,别的省份没有切身的体会,但从各种道听途说的消息来判断,也可见一斑。

十月八号到达广州,而月底是我们的上线时间,一开始我们不说信心满满,至少心里有底,因为我们在公司这边已经进行了三轮测试,虽然还存在Bug,但都不是什么严重问题。然而,事情并不是我想象的那样简单。首先的就是数据迁移这座大山挡在了我们面前——广东的数据在所有省份中是最多的,也是最为复杂的。经过千辛万苦,ESA的数据迁移过来了,然而LDAP的数据却成了难题,尤其是authorizations那个节点下的授权关系数据,UDI迁移工具跑了一个晚上,到第二天一不小心由于网络断开,一晚上的时间就白搭上了。就这样一次次的虐心,一次次失败。测试部的人因为没有测试环境只能在那尴尬的闲着,而我们开发的同样如此,那段时间真是让人“难忘”。于是第一周,我们的进度几乎为零。然而万幸的是最后终于在LDAP上添加了vlv索引,并修改UDI同步工具,总算把第一个测试环境的数据整了出来。

本以为测试的数据整出来我们可以轻松一把,没想到他们的WAS打包的那么不靠谱。测试的人测完了第一轮,晚上,我检查测试环境的更新情况时却发现之前给的补丁包并没有打上去。于是,第一轮的测试以“白测”而告终。不得已,我直接接手了他们的测试环境,什么事情还是自己来才放心。这得多亏了我以前对于WAS以及Linux的学习和了解,这下终于派上了用场,在输入命令轻敲回车的瞬间,心中充满了惬意。渐渐的,测试环境终于在我手中变的非常顺滑,各种问题可以很快定位原因并解决。

第二轮测试的时候,时间已飞快的来到了月底。测试紧张的进行,Bug数很多,但是测出的Bug质量却不高,很多重复的,很多边缘但并不严重的。看着那些Bug单,然后回想主线代码的杂乱无章,各种功能代码的交叉提交,心中无限忐忑。前路总是艰难,迷茫,既然走在了这条路上,我们唯有勇往直前,脚踏实地的走下去。改Bug,上传代码,打补丁包,更新,测试,回归,一步一个脚印。有句话叫你为什么要爬那座山,因为山在那里!而我那时最想说的是,为什么要熬夜去改Bug,因为问题在那里!

上线前几天,经过几次的上线演练,我们信心倍增,特别是我,对于UDI工具的使用,Radis的配置,已经达到了得心应手的程度。而亚坤他们的升级脚本,ESA数据以及刷数据工具,都已成熟起来,没有什么问题了。把几次演练的过程,汇聚起来,我写了份升级手册,在十一月四号晚上终于迎来了上线的时间。晚上九点,我们开始了升级。执行数据库脚本,同步ESA数据,运行UDI迁移工具,执行刷数据脚本...这些如期的顺利执行完后,开始测试。当晚即测出多个问题,有的甚至非常严重几乎要导致回退的地步,比如casp导致的单点登录失败,iam因工单窗口无反应而无法进行操作授权等,上线当晚即提交了7个补丁,不得不感叹计划不如变化快。在不知不觉中,天亮了,当最后看到领导发出的邮件了,那个不算很大的红色的上线成功四个字时,即使熬夜心中悠然