这次Ruby的更新主要是修复Bug，一共修复了100多个Bug，并修复了之前1.9.1版本的Heap Overflow漏洞，所以建议升级到p376版本。Changelog
我也在第一时间更新到了p376版本：
wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p376.tar.bz2
tar -xvf ruby-1.9.1-p376.tar.bz2
cd ruby-1.9.1-p376
./configure –bindir=/usr/bin –sbindir=/usr/sbin/
make -j3
make install
Windows VPS都有图形化界面（GUI）的远程桌面，Linux VPS就只有SSH和像Hyper-VM这样的web面板。今天我就用一个闲置的VPS安装了KDE+Gnome+VNC的环境。
安装所需环境：
需要至少256m的可用内存
CentOS或类似OS（Debian的话改成apt-get应该也可以）
1，安装KDE
yum install kdepim
（或）安装Gnome
yum groupinstall gnome-desktop
yum install gnome-session
2，安装VNC和其他
yum -y install vnc vnc-server firefox x11-xorg
yum -y install fonts-chinese
3，配置
运行
vncserver
设定好你的密码，然后程序会建立一个.vnc的目录，一般情况下是/root/.vnc
杀掉VNC的进程并删除临时sockets
pkill -9 vnc
rm…
物理中力是功的导数、加速度是速度的导数、位移是速度的积分。可见其实这种导数与积分的函数关系是在宇宙中很常见的。
那么，假设人生可以被看作一个以时间t为自变量的函数f(t)，那么我们的功绩可以被看成是函数与时间轴所围的面积（就像做功那样），也就是一个定积分，即
而且，对于某一确定时刻t(t>=0)，人生的发展轨迹的方向总是确定的，对于我们的人生函数，人生发展方向（或者说是我们的发展目标）就是导数，即
明显的，人人生来平等，即
这样看来，其实我们的人生函数表示的是你的强悍值。就比如说一个NB人士的f(t)会很高。同样的，那些伟人的F(t)会很大。但对于我们这些常人，要想做到F(t)大（有成就），就要做到f(t)大（更强悍），但是归根结底还是要做到f’(t)大。f’(t)是什么？它就是我们的目标！
现在的各种车轮都是圆的，很容易理解——圆上每点到圆心的距离相等，所以车轮在路上滚的时候才不会颠。但是，如果车轮并非圆形，比如说正方形，那么有没有哪种特殊构造路面可以让其在上面平稳的滚动呢？
答案是肯定的，请看下图：
不过，还就真有人做出了这样“囧”的自行车和路面模型！请看下图：
那么这种路面是怎么样的一个曲线呢？答案是——悬链线（Catenary），其形状与双曲余弦（cosh）一样。
具体证明请看下面的一个PPT：http://www.snc.edu/math/images/SquareWheelMath.pdf
通过Google Docs：http://docs.google.com/viewer?url=http://www.snc.edu/math/images/SquareWheelMath.pdf
那么如果我们的路面是锯齿形的呢？请看下图：
事实上，每一种车轮都会对应一种路面，使得车轮可以在路面上平滑地滚动！[1]
半题外话：前几篇文章我写了“等宽图形”（英文：Shape with Constant Length，不过貌似现在还没有正式的中文翻译，暂时叫它这个吧。或者翻译成“定宽”）。这样的“定宽图形”由于具有宽度恒定的性质，它其实可以垫在两平面之间使两平面平滑的做相对运动。
[1] Riding on Square Wheels - http://www.sciencenews.org/view/generic/id/4877/title/Riding_on_Square_Wheels
Google对366个日期的收录数有什么不同？
下面的图是我用程序抓取的Google对全年366个日期的收录量（网页数）统计图。我原以为像圣诞节等重大节日的日期的收录量会很高，但是结果却出乎意料！！
网页嵌入版：
网页版：http://spreadsheets.google.com/ccc?key=0AhwZjz8wu-DXdGFSN1lxUUh1S1FjczJ4aF9RMWJvbFE
或者里：
日期 网页数
January 1 236000000
January 2 213000000
January 3 211000000
January 4 213000000
January 5 208000000
January 6 210000000
January 7 209000000
January 8 210000000
January 9 208000000
January 10 210000000
January 11 212000000
记得前一段时间听到过这样一个问题，说：在一张硬板上剪下一块如上图所示阴影的图形，它一定不能穿过刚才所剪出的洞，请问为什么？当时我拿到了这道题，想了想，把问题简化成了：证明这个图形在任何方向直线上的投影得到的线段长度恒定。（然后的证明我就在这里省略了）当时我想，这确实是一个很有趣的性质，挺有研究价值。今天突然看到了等宽（Constant Width）这个概念（参考：Curve of constant width）。
首先，我们先来定义什么是“宽度”：一个封闭的图形，在图形外取两条平行的直线，然后把直线向中间的图形移，并保持直线方向。当两条直线都恰好接触图形时，平行线间的距离就是该图形在平行线方向上的“宽度”。而等宽图形就是在任何方向上宽度都相等的图形。
曾经因等电梯被困在某大厦的高层？或因电梯的不智能而导致时间的浪费？相信很多人都遇到过这类问题。电梯的运行效率问题在那些层数多、人流量多的建筑中尤为体现。写字楼等高层建筑离不开电梯，更高效的电梯管理与运营方案可以方便人们，更可以节约能源！
首先，为了更好地讨论关于电梯效率的问题，我们得先定义电梯的效率。本文假设电梯的效率与电梯的总运行时间、乘客平均与最大等待时间有关。并且，对于同一的客流量（或者说同一组电梯请求，因为不止在数量上相等），一个建筑中的电梯组总运行时间越少、乘客等待的平均与最大时间越少，其效率越高。
传统的电梯每层会有两个按钮，上和下（在这里不讨论极为低效的每个台电梯对应两个按钮的情况）。每当电梯遇到有请求的楼层、并且当电梯运行方向与请求方向一致时，就会停下。但是这样的电梯组并没有被“规划”，每个电梯相对独立的运行，在客流量很大的情况下会导致电梯资源分配不均匀[1]，并导致电梯总运行时间增加、效率降低。那么究竟怎么样才能提高电梯的运行效率呢？
简单的对传统的电梯系统做下分析，乘客只需输入上或下，但也正是这种过于简单的输入而导致系统无法进行电梯运行的优化。那么，如果我们增加乘客可提供的信息呢？比如提供所要去的楼层？
目的楼层请求系统（Destination Call System）就是一个为增加电梯运营效率而设计的系统，其不同点在于——当你想乘坐电梯时，你需要输入你想去的楼层而非只是提供上和下。然后系统会自动根据情况把最合适的电梯非配给你。然后你只需要等待该电梯的到来然后电梯就会把你带到你想要去的楼层了。其实现在有很多写字楼都配备了这种电梯系统，如北京的欧美汇大厦，研究试验表明这个系统确实要比普通的电梯系统要高效[2]。
目的楼层请求系统（Destination Call System）的实现
首先，将每台电梯的运行路线看作一个数组，其中每个元素表示一个楼层。如[1,3,5,2]就表示电梯的运行路线为1-3-5-2。每当系统得到一个新的请求时，系统会根据所提供的起始楼层和目的楼层模拟分配给每一台电梯，然后模拟出每台电梯的新运行路线，并算出每台增加的运行时间，其中增加运行时间最短的方法最优。然后系统就会将最该请求分配到那台电梯。
[1]、[2]：参考文献：http://www.matheon.net/preprints/4684_rt_group_elevator.pdf
前段时间看到一个php的飞信模拟接口，可以实现免费短信发送，所以我就将其拿来做了个自己用的API。
前一段时间由于各种事务的繁忙，我几乎没有什么时间来查邮件，现在趁着这几天难得的假，我就写了一段用Ruby的Mechanize来获取Gmail或Google Apps Mail的代码。
这种模拟登录抓取网页内容的程序写出来就是比较乱，写注释以后自己都不一定记得，呵呵。
前期写模拟抓取网页和登录的时候还算顺利，但是抓取到的信息就是死活发不出去。（我用的是一个web接口，实际发短信部分是用php实现的，不是我写的，但我忘了是从哪里拿来的了，原作者看到请联系我。）
经过调查发现原来得到的信息不是纯的UTF-8编码，必须要转成纯UTF-8的形式才能顺利在手机端被识别。代码如下：
require ‘rubygems’
require ‘mechanize’
require ‘iconv’
def check(address,email,passwd,phone,phonepw)
agent = WWW::Mechanize.new
agent.user_agent = ‘Opera Mini’
agent.follow_meta_refresh = true
…
今天看到某两人的对话，大概是这样的：
现在得甲流的80%都发烧！
楼上说得不对吧，应该是现在80%发烧的得的都是甲流！
仔细想想，这个问题其实很有趣。设想：如果以上两条都成立，也就是得甲流80%发烧、发烧的80%是甲流，我们能推出什么结论呢？
其实这是一个典型的条件概率问题。一般的，在B发生的情况下A发生的概率可以表示为P(A|B)。那么“得甲流80%发烧”可以表示为P(发烧|甲流)=0.8。不妨用P(甲流)来表示得甲流的概率（得甲流人数与总人数的比值，下似），那么P(甲流)×P(发烧|甲流)就是既得甲流又发烧的概率，既P(甲流)×P(发烧|甲流)=P(甲流∩发烧)。同样的，“发烧的80%是甲流”可以表示为 P(甲流|发烧)=0.8、P(发烧)表示发烧的概率，那么P(甲流∩发烧)又可以表示为P(发烧)×P甲流|发烧)。于是，我们得到了一个这样的推论：P(甲流)×P(发烧|甲流)=P(发烧)×P(甲流|发烧)。由于P(发烧|甲流)=P(甲流|发烧)=0.8，所以P(甲流)=P(发烧)
而刚才我们得到的推论，也就是贝叶斯定理，其一般形式为：
请设想下面一个情景：某种酒精检测仪在对吸烟的人使用时99%报阳性、1%报阴性，而在对不吸烟的人使用的时候99%报阴性、1%报阳性。已知学校中吸烟的学生大概占1%，请问如果对某学生的检验程阳性，那么该学生吸烟的概率是多少？
肯能你会很果断得从直觉判断99%，但是有时候人的直觉却是错的。
其实如果检验程阳性学生吸烟的概率就是P(吸烟|阳性)。根据贝叶斯公式：P(吸烟|阳性)=P(阳性|吸烟)P(吸烟)/P(阳性)。P(阳性|吸烟)和P(吸烟)都是已知条件，而P(阳性)其实就是P(吸烟)×P(阳性|吸烟)+P(不吸烟)×P(阳性|不吸烟)。化简整理，P(阳性|吸烟)P(吸烟)/[P(吸烟)×P(阳性|吸烟)+P(不吸烟)×P(阳性|不吸烟)]=(0.99×0.01)/(0.99*0.01+0.01*0.99)=50%！远远低于99%！而如果把原数据中的“学校中吸烟的学生占1%”改成“0.5%”，所求概率将进一步降低到33.22%！
另外，贝叶斯定理还在中文分词、机器翻译、垃圾邮件过滤和人工智能方面有着很多的应用。在这里我就不多写了，更多请看这篇强文！
今天突然了解到原来Wordpress从2.7开始就开始支持回复嵌套了，但是这个主题却没有支持回复嵌套功能。
没办法，只好自己来做了。
首先要改 comments.php
post_password)) { // if there’s a password
if ($_COOKIE[’wp-postpass_’ . COOKIEHASH] != $post->post_password) { // and it doesn’t match…
