那么，又想贪图WordPress本身的对文章的管理组织功能（WordPress最好用的地方就在于后台，不管是编辑器还是组织堪称优秀实践。），又想让站点性能比较好应该怎么办呢？

我的思路是这样的：

1. 直接用wordpress模板系统做一个rest风格（伪rest。。）的调用接口，可以返回json，也可以返回序列化后的php变量。因为WordPress本身模板系统很简单，很容易就能控制路由，而且这样做最大的好出在于，可以直接用wordpress提供的各种内容调用方法，不再需要自己再去直接操作数据库了（就是个ORM），php输出json也很方便，直接json_encode就好了，配合web服务器的访问控制就能很好的控制调用范围了。

2. 用框架做一个文章站，这时候就不需要经典MVC中的M了，所有的数据直接从rest接口调，封装一个curl就好了，难过来数据解包直接使用，只要做好C和V就好了。那么这样做其实还没有解决性能问题，只是做了解耦，让架构清晰了。至于性能，对于文章站这种情景，我们只要再再做一个缓存就好了，一般web开发框架都有很好的缓存方面的支持，可以用文件缓存，也可以用KV数据库缓存，思路很简单，就是用接口url作为k来缓存数据，然后设定一定的时效，或者更具文章的刷新去刷新缓存，总之文章站的内容变动频率并不高，缓存对于提整站性能作用很大。而且这样做的缓存内容很单一，流程很透明，控制很容易。

这样的架构，性能上应该比DX2的门户还略好一些，而且复杂度要低很多，两边低耦合，如果觉得再要拓展，就算是利用接口在框架这边再持久化一遍数据都是很方便的。最主要的搭建速度快，也不糙。


Markdown 还是 reST
====================

*胡言乱语，未完待续，之所以发出来是因为不想再像其他文章一样，一直在草稿箱里直到只剩删除的价值。*

什么是什么？
——————–

Markdown和reST都是标记语言（markup languages）。什么是标记语言？等会儿再说。

Markdown就叫Markdown，而reST是个缩写，reST的全称是reStructuredText。

什么是标记语言？
~~~~~~~~~~~~~

我们知道作为直接映射自然语言的文本语言在直接书写为纯文本以后，实际上这样文本的所能表达的意义往往不能达到我们需要的标准。

我们引入标记，是为了扩展语义。最简单的就是空格、换行、符号。 但是这还是不够用。 所以我们有了更完备的标记语言，比如LaTex、XML，但是问题来了，这样过于复杂了，首先是书写上复杂了，比如XML，已经很难直接去手动编辑原始XML文本文件了，只能依靠工具了。原始文本的理解难度也增加了，比如你要看懂一个复杂的LaTex源文件确实需要一些功夫，原本文本直接表意的功能就丧失了。

什么是Markdown？
~~~~~~~~~~~~~~~

什么是reST?
~~~~~~~~~~~~~

都是完美惹的祸
——————-

我为什么要说这个题目呢？很难表达清楚，只是隐隐约约觉得需要喷，或者说是吐槽。

而且，这篇文章成稿已久，我觉得如果想很多稿子一样放到只有被删的价值，那还不如一吐为快。

尽快，我已经知道这又是一篇断断续续毫无章法的胡言乱语。那么开始吧。

那么，我想说什么呢？

我想说

在这个不完美的世界，作为力求完美的人，真他妈的是个令人焦虑的事情。

现状
————-

现状就是很多事实交织在一起，你不去伸出手摸摸，根本无从了解，当然，就算是摸了也不免瞎人摸象，当然，听我说那就更是隔靴搔痒了。

首先说Markdown，

简单的说，Markdown现在火的没有道理，单单从语言特性方面分析，列表里面的大伙也讨论过这事，结论是最大的原因是Github的强烈推广，Markdown算是Github的官方标记语言了。

不得不说ReST有一个比较悲剧的名字，用全称太长，用缩写如果用rest，很容易和同字母英语单词“其余”混淆，如果用REST，呃，REST也早有了约定俗成的含义，指的是一种网络接口的设计风格。所以，大家一般就用ReST，或者用rst来称呼reStructuredText。

ReST是Docutils的标记语法，二Docutils是Python世界的文档工具集。

也因为这样ReST在Python界中被广泛应用，比如Sphinx–这个基于Docutils的文档工具–事实上作为Python中的标准文档工具被广泛使用了。比如Python官方文档。因为Sphinx可以生成多种格式，

设计思路对比
—————

先来看一下Markdown，

官方的说法直截了当，Markdown就是个 text-to-HTML 的工具。

所以说，从一开始，Markdown 就确立了它与HTML的亲缘性。这是 Markdown 的设计立足点。

Markdown包含两个部分，

1. 文本结构化格式，也就是标记语言

2. 另外与之配套的生成HTML的 perl 程序。

作为标记语言，Markdown的目标

相比与 Markdown ， reST 显然是经过精心设计的。

reST的目标是，建立一套标准文本结构化格式用以将文档转化为有用的数据格式。

不得不说的是这句话一点都不Pythonic，和政治书上的句子似的。

所以Pythoner给出了更具体的阐述：

按重要程度依次罗列：

1. Readable，是可阅读的，reST的原文本必须可以很容易的直接阅读而不需要了解reST的标记语法。

2. Unobtrusive，不突兀的，reST 所使用的标记应该是尽量简单并且不突兀的。越是常用的标记越应该简单和不碍眼的。不太常用的标记，或者是表达特殊意义的标记应该鲜明。

3. Unambiguous，没有歧义的，标记规则是确定的，不能再重载定义，对于给定的一个输入，只有一个可能的输出，包括输出错误。

4. Unsurprising，不出乎预期的，非“魔法”的，标记语言可以不输出不想输出的内容。所以，需要一个方式（标记）作为标记不期望输出标记之用。比如，当你想要向别人展示reST源代码时，你要标记这块reST源码不需要被结构化。

5. Intuitive， 直观的，标签应该尽可能的容易被记住。人们可以在文档中直接使用。

6. Easy，简单，

通过一段时间的使用，我觉得Markdown和reST都可以说达到了他们的既定目标。

进过一段时间的使用，我觉得reST基本达到了预定的目标。

权衡的艺术
~~~~~~~~~~~

通过以上的比较，我们发现，reST承载的目标要比 Markdown 多很多。最重要的不同就在于 Markdown 只是为了输出 HTML ，而 reST 的目标之一就是可以转化为其他格式。

当然，说权衡是艺术，还不如说其实就是瞎子摸象弄出一些聊以自慰的藉口罢了。

不过从已经获取到的相关信息，我们可以初步做一个判断，用Markdown作为中心书写工具（一般是配合Pandoc）相对于使用reST做中心书写工具是不佳的。何况，又引入了新的工具（Pandoc）和语言（Haskell），这都是非必要的正熵，背离了KISS原则。

说了这么多其实就一句话：

我们选择标记语言实际上是在表意与简便之间做权衡，我们的理想目标是即表意丰富又使用简便。

但是，这个世界上鱼和熊掌得兼的事情不多，往往我们只能根据自己的需要去寻找一个最优平衡点来决策。

其实，我只是想写个reST就是好啊就是好的吐槽文，没想到还是逼着自己去把相关的资料翻阅了一下，查阅这些资料不是为了更好的吐槽，是为了让自己心里更踏实一些。

另外这篇文章同时符合markdown和reST语法。

网上看了一下除了项目官网貌似很少有被提到，那么我就来写吧。

系统：Ubuntu Server 11.04

首先装msgpack c++的库。

sudo -s #图个方便
apt-get install gcc g++ make automake libtool pkg-config #编译用到的工具
apt-get install lua5.1 lua5.1-policy-dev #lua和lua开发包，编译需要用到
wget http://msgpack.org/releases/cpp/msgpack-0.5.7.tar.gz #下载msgpack c++库源码
tar zxvf msgpack-0.5.7.tar.gz #解压
cd msgpack-0.5.7
./configure
make
make install #编译安装

接下来是mplua的安装

cd ..
git clone https://github.com/nobu-k/mplua.git #没有git就安装一下git： apt-get install git
cd mplua

这里和项目官网写的就不一样了。官网里直接configure编译。

./autogen.sh
./configure
make
make install

然后提示lib是编译好了，但是链接没有做好，因为目录不存在，然后手动建立一个软连接/usr/local/lib/lua/5.1/msgpack.so -> /usr/local/lib/libmsgpack-lua.so

进入lua命令行测试一下

lua
> require "msgpack"
> a, b, c = msgpack.unpack(msgpack.pack(1, 2, 3))
> print(a)
1
> print(b)
2
> print(c)
3

好了，可以用了。

http://xdmc.org

顺带着的还有新版的数谷论坛

http://forum.xdmc.org

内容还在充实，细节仍在调整中。

有什么建议、或者意见可以直接在这里留言。

等忙完这段时间我会把这次做的东西都开源，并附上一些心得。

准备工作
============
#. 安装配置nginx
– Ubuntu下源中有nginx安装方便
– CentOS可以用epel源、第三方源或者编译安装
– 具体细节另论
#. 安装mercurial
– Ubuntu下源中有 sudo apt-get install mercurial
– CentOS下源中也有 yum install mercurial

建立仓库
============

假设仓库位置为/var/repo

#. 初始化
$cd /var/repo
$hg init

#. 配置仓库本地用户
$vim /var/reop/.hg/hgrc

::
[ui]
username = yourname

#. 添加文件
$hg add .
$hg ci
`输入提交信息`

#. 建立hg serve配置文件
$vim /var/repo/hgweb-conf

::
[web]
push_ssl = false
allow_push = *
encoding = “UTF-8″
[paths]
/hg = /var/repo

[hooks]
changegroup = hg update

#配置了一个hook，用于每次客户端push时，都自动update，方便。

#. 启动hg serve

$hg --cwd /var/repo serve -d -a localhost --webdir-conf hgweb-config

– 其中–cwd 为仓库目录，serve为启动hg http服务器，-d为以守护进程启动，-a 为使用域，配置为localhost可以禁止直接访问，–webdir-conf为指定hg serve 配置文件
– 可以将此命令写入/etc/rc.local （或者是/etc/rc.d/rc.local）中，使其开机自动启动

配置nginx反向代理
================

#. 修改nginx主配置，添加如下配置

::
location /hg {
proxy_pass http://localhost:8000;
auth_basic “Restricted”;
auth_basic_user_file htpasswd;
}

– auth_basic_user_file htpasswd; 为指定验证配置文件，用于仓库权限管理。

#. 配置访问验证
– 下载http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py 脚本到/etc/nginx
– 执行 $python htpasswd.py -c -b yourname yourpasswd
– 其中，-c为创建文件，所以再添加用户则不需要-c参数，-b为直接添加用户和密码，不必等待提示再输入。

#. 重起Nginx
– $service nginx restart
– 应该也可以reload， $ /usr/sbin/nginx -s reload

完成
=============
这样就可以通过 http://你机子的地址/hg 来访问仓库了。

另外
============
使用TortoiseHG连接词ci co都需要密码不方便。

可以这样设置。
在TortoiseHG 配置path时，配置default地址为 http://yourname:yourpasswd@你机子的地址/hg 保存且不移除头部信息。

这样就可以不用每次都输入用户名密码了，十分方便。

心急火燎的整出一些糟絮，没头没脑的干一些烂事，还有怨气。

回头一想，唉，应该是我又做错了。

其实应该遵循的道理都明白，也就那么几条。

但是就是做不到，这也许就是我等凡人与牛人的区别吧。

就是这样，记录一下常看看，思维的局限得要自己才能跳出去，常看常新吧。

有时候想，不管是博客，还是微博，毕竟都是写给别人看的，很多要对自己的说的东西不足为外人道也。

自己整理思绪所需的记录，也可以有更好的途径来完成，所以这么看来，博客的荒芜好像是必然的。

当然时常还有一些工作、技术、学习方面的心得值得记录，但是往往自己都觉得单薄，不好意思拿出来献丑，只能标记一下扔进碎片笔记库里。

最近在readthedocs上无意看到了一些统计学和R相关方面的文档，或者也可以说是书，作者是在github上建的源文件文档，利用的是python标准文档格式rst和Sphinx进行书写，这是我所心仪的方式，所以我既没有与作者联系，也没有考虑版权方面的东西就径直fork了源文档库出来，并开始翻译。不过翻译了一些以后发现这些文字还是不那么令我满意的，你懂得，正像我这般没什么成绩的人，对什么东西都好像心存不满，不过我还是会继续翻译下去的，为的是更加熟悉ReST以及更好的使用Python、Sphinx、Readthedocs这些切实可以提高生存率的东西，当然这是后话了。

有感兴趣的朋友可以联系我，也可以看这里Little Books of R(zh_CN) 。

最近还有很多计划内的事务需要完成，也有一些必须要实践而非空想的事情需要去做。

听到这些话，纵有千言，一个字也憋不出来，低头挠了一下脑门，叹了一口气，走了。

关于理由一，确实这个无力吐槽，GPL也可以卖钱，你要愿挨就不能怪人家想打。
关于理由二，我心说，操，要是哪天SQL Server insert不成功，那才叫爽呢。

就像遇到其他问题，面临无法表达的问题，也需要仔细考量，以期寻找解决办法。

解决办法一，多写，不管写的怎么样尽量多多写。

以前，除了发一些垃圾牢骚在博客上，也就是把博客当备忘录用一下，记一些技术相关的东西，但是现在Evernote等碎片记录工具太过方便，也便不用再在博客上记一些无聊的东西了。

而且，自己才疏学浅没有什么可以拿出来展示的积累，一些平时遇到的问题和解决问题的方法也没有什么值得说的，所以博客内容太过贫乏。

以后，应该调整态度，不管是什么东西总有可以说的，不管有没有营养，为了磨砺自己的表达，也就不再顾及冗余的繁絮了。

解决方法二，写点不同的东西。

没办法，仔细反省，每当手扶键盘，心有所思的时候，往往是延续着是小学、中学那种面对作文纸的心理状态，我也许是很容易执着的人，往往陷入我执，让以往那种不健康的心态感染自己，难以自拔。当然在做什么事情的时候都是对以往经验的延续，只是小学和中学的语文教育让我对于文字的把握非常吃力，进而产生恐惧，难以前进，只得徘徊。

既然如此，那么只好跳出这种不健康的状态，我所想的方式便是利用表达方式即文本形式的转变来改变书写心理状态。

我想到二种可行的文体，其一，进行短而主管的评论，其二，问答体。对于评论，主管而为意在肆意，不求深刻只求流畅。对于问答体，我想，不管是对于自己的命题还是对于自己所听到的命题都应该有所质疑，也就是问，所以问答体，在形式上就可以逼近我所希望的这种功效，不妨一试。

以上即为今日琐记。

后台字体很难看。