车厢调配问题 与 “谁在用”代码发芽网页面
目标：我想在 “谁在用”代码发芽网 页面采用表格布局，每行三个链接(也就是html里面的三个td)
问题：代码发芽网基于Django，其模板系统的语法很弱，不支持对循环因子的操作操作不容易实现
首先想到的解决方案: 考虑到有cycle，就这么做：
{% for w in wum %}
{% cycle '<tr>' '' '' %}
<td>
<span style="font-size:large"><a href="{{w.website}}">{{w.title}}</a></span><small>
<a href="{{w.blog_url}}">:)</a></small>
</td>
{% cycle '' '' '</tr>' %}
{% endfor %}
</table>
紧跟着发现，这样做是有问题的：当链接数不是正好三个的时候就会出现”tr”标签开始和结束不是匹配的
真是个烦人的问题，虽然在Django的View里面很好解决，我却不想这么做。
无意之间想到了前几天看过的文章，那是Dijkstra大师关于火车调配实践的一段描述：
一个寓言
多年以前有一个铁路公司，它的一位领导（可能就是商务方面的头儿）有了这样一个
发现，如果只给百分之五十的车厢配备厕所的话，原始投资将会大大地减少。于是，
他们决定就这么做了。公司执行这项措施之后不久，关于厕所的抱怨就接踵而至。经调查发现，实际情况是
尽管这家公司还很年轻，但它已经存在严重的内部沟通问题，因为上头关于厕所的决
定并没有传达给调度室，所有的车厢都得到了同等的对待，于是有时候一列车中几乎
没有一个厕所。为了解决这个问题，给每个车厢都加上了一些信息，用于区别这个车厢上是否有厕所，
调度室则需要在列车编组的时候尽量保证两种车厢的数量是相等的。这对调度来说无
疑是个麻烦事，不过问题解决之后，负责调度过程的人们都为此而非常得意。新的调度过程实施之后，关于厕所的抱怨却依然没有平息。新的调查发现，尽管在一
列车中确实有一半的车厢有厕所，但有时候却把所有的厕所都编组在了列车的一头。
为了对此加以补救，上头又有了新的措施，规定带厕所的车厢和不带厕所的车厢应该
交替编组。这个方法的复杂度对于调度人员来说实在是太恐怖了，不过在最初的一番
唧唧崴崴之后，他们最终还是搞定了。然而，抱怨仍在继续。调查出来的原因是，对于那些有厕所的车厢来说，厕所都位于
车厢的一头，列车中两个相邻厕所的距离仍然可能会有三个车厢的长度。对于那些有
紧急需要的抱小孩儿的妈咪们——尤其是过道上充塞着行李箱的时候——就会导致灾
难性的后果。结果是，给那些带厕所的车厢又加上了一点信息，将它们变成了带方向
的物体，新的规定是，在每个列车中，所有带厕所的车厢都必须是同向的。这一次，
调度人员收到新的指示的时候就差没疯掉了，因为调车转台的数目刚刚够用，如果要
完全公正地说的话，我们必须得承认，按照任何合情合理的标准，调车转台的数目是
不够用的，调度人员必须发挥极大的创造力才能勉强搞定。等到所有的厕所都均匀地分布在列车中之后，公司有理由确信所有的事情都OK了，不
过乘客们依然在抱怨：尽管没有乘客离最近的厕所会超过一节车厢，乘客们（尤其是
有紧急需要的）不知道该向过道的那个方向开始他们的冲刺！为了解决这个问题，
写有“TOILET”的箭头被固定在了过道上。这就让另一半的车厢也变成了带方向的物
体，调度过程也必须对它们的方向进行正确地排列。收到新的指令之后，调度室里充斥着绝望和反抗的情绪：这是不可能的！在这个关键
时刻，有个人站了出来，他的名字已经被遗忘了，而且也无从查证，他做出了以下的
分析。当每节带厕所的车厢都在它的有厕所的一头和另一节没有厕所的车厢配好对之
后，调度室根本无需再为N个两种类型的带方向的车厢而烦恼了，因为他们面对的将
是N/2个同样的单元，不管从哪个方面说，这些单元都可以被认为是对称的。这个分析
搞定了所有的调度问题，不过稍微有点代价，首先是每次只能向列车上加挂偶数个
的车厢——由此而增加的少量车厢可以从商务头目最初省下的那笔钱里面报销！——
其次，假定所有厕所的尺寸都是相同的。不过，谁会在乎那最后的三英尺呢？尽管在发生这个故事的时候人类还没有计算机，但发现解决方案的那位匿名人物可以
当之无愧地被视为全世界第一个合格的程序员。
呵呵，然后呢，我就想，把<tr>和</tr>强制扭到一起不就行了？
所以得到了现在用的方案：
{% for w in wum %}
{% cycle '</tr><tr>' '' '' %}
<td>
<span style="font-size:large"><a href="{{w.website}}">{{w.title}}</a></span><small>
<a href="{{w.blog_url}}">:)</a></small>
</td>
{% endfor %}
</tr></table>
</center>
–
代码发芽网： http://www.fayaa.com/code/ （无需插件在blog上贴语法高亮的代码，百种语言，多种配色）
Loading ...
汽车与山羊(Car and Goat / Monty Hall problem)
刚刚看到joyloft写的“汽车与山羊”，来掺和一下。
很多人听到过这样类似的题目：（来源）
在一个类似于开心词典的节目中，挑战者突破重重难关终于来到了奖品面前。可是在他和奖品之间还隔一扇大门。他必须从三扇大门之中选择一扇打开，其中只有一扇大门通往大奖。挑战者随意选择了一扇，并且说任意一扇的概率都是33.3%。这个时候，已经知道答案的主持人决定帮他一把，主持人从剩下的两扇门中打开了一扇Goat的门，告诉挑战者可以更改他的选择。挑战者立即要求换到另一扇没有打开的门，并声称其概率是66.7%。
这里不说为什么这个结果是对的，这是概率论的问题。
这个题目的比较完整的资料在维基百科上。
我当初听到这个问题不是完整版，没有关键的这句话：“已经知道答案的主持人决定帮他一把”。
所以我当时觉得不一定是66.7%，还专门跟当时的概率论老师争论，写了一篇类似小论文的东西。很失望的是，当时的概率论老师完全无视这篇文章，直接说：就是66.7%，你回去好好体会体会。
现在换一些情况来说一下，为什么这句话很关键（wikipedia上也有详细讨论）：
情况0. 主持人知道答案，并且总会打开没有奖的门，那么选择者更换的结果就是2/3的机会中奖
情况1. 主持人知道答案，并且只在挑战者选择了有奖品的门的情况下提供重选机会，那么更换选择就是100%挂掉
情况2. 如果主持人知道答案，并且只在挑战者选择了没有奖品的门的情况下提供重选机会，更换选择就会100%中奖
情况3. 如果主持人也不知道答案，纯粹瞎蒙蒙找到了一个没奖的门，这时换不换都是50%
情况4. 如果主持人在日期为单号的时候按情况1处理，在日期为双号的时候按情况2处理，那么。。。。。。
大家看出来了吧，概率论很重要，体会主持人的意思更关键:D
代码发芽网 代码高亮核心模块(Pygments)升级到最新版(1.0 dev 20080727)
最近收到反馈说代码发芽网不支持Fortran、Python3000和汇编。
今天从天津赶回来，发现Pygments已经更新到了1.0版，1.1版也在开发之中。
看了一下最新的更新内容，决定把代码发芽网所用的pygments版本升级一下。
主要更新：
添加了Nasm(汇编)，Python 3000, Smalltalk, YAML, Tcl, Fortran, ActionScript3 等语言的支持
新增三个高亮配色主题：vs(Visual Studio) / bw(Black and White) / manni
其他更新：
其他语言支持列表：
* Cheetah/Spitfire templates
* Lighttpd config files
* Nginix config files
* Gnuplot plotting scripts
* Io
* Darcs patches
* Matlab
* Matlab sessions
* XSLT
* tcsh
* NumPy
* S, S-plus, R statistics languages
* Logtalk
一些小更新：
* C语言高亮支持库函数和C99的类型了
* Makefile高亮兼容BSD和GNU格式了
* C / 批处理 / CSS的一些bug fix
所有更新列表参见：http://dev.pocoo.org/projects/pygments/browser/CHANGES
代码发芽网最近一次更新中所遇到的问题
首先说一说怎么缩小生成代码的体积：
1. 生成的结果去除生成的html中的class，因为动态主题切换是依赖这个的。后来做了一个backup才搞定
2. 空格不需要span，这个比较容易，一个正则表达式就可以搞定，难以搞定的是firefox和IE的操作方式不同，骂一句，继续
3. merge相同style的span，这个没有做，因为各个主题不一致，吃力到不了多少好:D
最终结果里，一个四百行左右的代码生成的页面从100K减至50K，已经不错了
虽然还是比较肥，但是所有直接生成HTML所有做高亮的工具，都避免不了这个问题
因为代码被分割成一片片，每一片加上span以后都肥了十倍左右。
只有使用JavaScript的可以避免这个问题，但是现有的JavaScript高亮工具有两个致命的缺点：
1. 代码行数稍多就会很慢，几百行就有很明显的感觉，有时甚至造成浏览器假死
2. RSS中无效
再说一说界面的改进：
1. 改进这个界面比原来的好，普遍反馈如此
2. 论坛里的很多建议和批评，很不错
3. 功能性主导的网站还是以功能改进为主
个人想法是：又不是搞设计的网站，不对功能产生障碍就行了
在我自己的功底没有进步之前更改只能是凭运气，不如将精力放在功能改进上。
另外，很多现在运行良好的站点，界面在我看来糟透了，但是这又如何？
最后说一下遇到的一些问题：
1. jQuery的问题：
是的，jQuery非常好用，但是不适合做代码高亮时使用
看过jQuery的代码就会知道它对每个操作过的元素都会加上jQueryxxxxxxxx=”xxxx”这样一长串
这个严重的导致了生成的代码肥胖，所以做高亮的代码就不用jQuery了
2. 收藏本站代码：不多说了，好不容易找到一个可用的Javascript: IE和Firefox下都有效的“收藏本站”代码
3. IE下用removeAttribute来干掉class的问题，最后终于找到了一位老兄调侃IE的同时提供的答案：同时删”class”和”className”
4. BBcode的实验(chinaunix上的帖子)：
找了很多网站，知道了大家虽然都用BBcode，支持却是相差万里，交集很小，在这个交集里，没有背景色
本来用table的背景色挺好用的，但是不是所有的论坛都支持
有的论坛甚至不支持[b]和[i]，真是晕啊，安全再重要，也要考虑可用性吧。
最后做成的东西能在ChinaUnix和大多数Discuz!论坛上使用，也能够支持phpBB的论坛
如果不禁html的论坛，直接贴HTML代码好了
做这个的时候，放弃了jQuery，最终使用的是正则表达式替换，现在还在担心是否有bug
5. Django的is_ajax判断很有意思，jQuery等ajax会在请求头上加上一些标志
Django判断这个标志看看是否是Ajax请求，用了一下（复制裸代码的功能），感觉还不错IE6.0的支持
IE中调试javascript真是不爽啊，给出来的都是神秘的行号错误，比起firefox的firebug差远了，IE8不知道会怎么样。
