09 2012 档案
摘要：抽空来分析一下目前的12306的状况昨天，记者登录铁道部唯一官方订票网站12306.cn准备订购一张9月30日北京到南京的T65次车票。进入订票程序后，订票页面显示硬卧无票，硬座有票并且第一次显示“1张”余票的字样。在 记者输入姓名、身份证号并提交订单后，页面上弹出对话框，上面提示“尊敬的顾客，本次列车您选择的席别尚有余票1张，无座0张，目前，排队人数已经超过余 票张数，请您选择其他席别火车次，特此提醒。”由于前面提交订单的旅客超过了余票数，所以记者这时只能选择取消选项，而不能再继续提交订单。此前，达到同样步骤时，对话框提示的内容为“今日该车次和席别已有超过***人次先于您提交订票请求，至处理
阅读全文
摘要：网络上有不少人曾经提出可以把“车票”预先生成并缓存起来。其实这里典型是出现了线下思维和经验对线上系统设计的阻碍作用。并且是由于对于铁路区间售票的情况了解不充分造成的误解。
从传统经验上，如果某个车次是热门，那么为了加快出票速度（窗口买票速度），车站可以采用事先将一定量的车票打印完毕，从而节约一点售票环节和时间。
这里的前提是能预测并估算数一定量的“车票”。这种功能在12306系统里也是一种可选的功能，但是绝不是能立刻实现的。因为准确估计要生成哪些“车票”并不容易。或者应当有一种调节机制来发挥作用，当预估的车票与实际订票请求冲突时候的动态调节。
所以本系列会给予不生成固定车票的方式。当然，也欢迎讨论各种车票的实现方式。
阅读全文
摘要：前言 中国铁道部，3亿RMB。 12306又一次成功地吸引了全国人民的眼球。自然，不同身份的人从中有着各自的解读。 2011年的一波，如今的又一波。可以预计的两个月后还有一波。 做为一个IT从业人员看着很多专业或非专业的评论和分析文章，其实内心也早有自己的想法。毕竟曾经有幸参与过一个小规模的票务系统，虽然小道不起眼，但至少还是接触了不少有关票务的领域知识。 一个人的知识和认识一定比不过一个公司和团队，但是软件创新靠的是点子，不是票子。而好点子是人人都可能想到的，无非因为各自的背景知识以及掌握的需求细节不同而导致提出的解决方案各有差异。不过也正因此，有些意见其实并不是很合理，铁道部和太极公司其实
阅读全文
摘要：但是，软件源码是写给人看的，不是写给CPU看的。
曾几何时，代码是写给CPU看的。比如机器码，比如汇编。
到了C/C++的时代，这种资深程序员们的编码习惯被继承了下来。并且一定程度上成了“正确”的选择。
阅读全文
