Shell's Home

硬盘底座入手

Aug 11, 2011 - 1 minute read - Comments

贝壳买的新硬盘底座入手了,质感不错,很沉,只是在插入硬盘的时候对准不是很方便,总是要对一下才能对准。而且硬盘插上去有点摇晃,如果长时间使用还是会伤硬盘的。不过针对短时间使用,底座正是一个好解决方案。 硬盘底座,就是将硬盘插上去,然后接入电脑的器件。现在大部分硬盘底座都是sata接口的,以前有IDE接口的,贝壳试过,不稳。IDE本身就不支持热插拔,硬做上去当然好不到哪里去。通常而言,硬盘底座/移动硬盘/sata热插拔是三种相关又各有特点的解决方案。底座的目标是使得硬盘可以更换,使用底座的人,多数希望在一台电脑上更换使用一个接一个的硬盘,对硬盘没有特殊要求。移动硬盘,基本就是把底座的硬件和硬盘捆绑到一起。使用移动硬盘的人,是希望一个硬盘在一台台的电脑上使用,对电脑没有特殊要求。而sata热插拔是强调热,即可以不关机接入设备,对台式机用处不大。通常是现场空间不足了,不能关机增加存储设备造成的需求,对插拔次数支持并不好。有资料说,普通sata接口大概能承受50次的插拔。普通硬盘安装而言,50次是一个非常足够的数目了,但是移动硬盘使用的话,几天就用光了。 底座支持两种接口,usb2.0和esata。前者的速率是480bps,后者速率是3.0Gbps,合前者最高60M/s,后者最高375M/s。一块民用硬盘的突发速率往往高达150M/s,usb对于普通台式机而言显然是远远不足了。而且esata直接挂入硬盘控制设备下面,而USB则是挂入USB控制器链,效率上说差了一点不说,而且esata是作为普通硬盘对等管理的。 贝壳本次的方案,是通过一根sata 2 esata接线,将mini-itx主板上的一路未使用的sata引出机箱,连接到底座上。但是linux下要支持esata,必须在BIOS中将SATA设备模式改为AHCI,而后重启进入系统,可以看到设备变了。当然,这个改变对于windows系统来说是个灾难,但是linux系统完全不在乎这个事情。 debox:\~\# lspci | grep -i sata 00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 01) debox:\~\# lsmod | grep ahci ahci 25089 2 libahci 22767 1 ahci libata 149043 2 ahci,libahci 这次更改造成的一个额外效果就是,机器上的普通sata硬盘速度也上升了。从原来的71M/s到了115M/s,提升相当惊人。

读一读我的blog用户

Aug 10, 2011 - 1 minute read - Comments

好吧,应该是viewer,姑且称为user。谢谢你们的关注,这个blog才撑的下去。坚持写blog,尤其是技术blog,是个很辛苦的事情。查证技术很花时间,也没什么回报,一不留神还会成了各大互联网公司的免费写手。不过看看每个月的ip和pv,好吧,还是值得的。 说是读一读,当然,我不会有你们的名单。我做的是审计,可不代表我会审查来的每个人。但是我的blog里面安装了统计系统,google还有个webmaster。我们来看看数据报表。 首先是,大概1/3的我的读者是geek,或者足够geek,其余是麻瓜。各种windows系统占了2/3,我觉得普通blog不会出现这个比例… 然后,firefox家族占了一半不到一点的流量,chrome占1/4,一点的safari,其余的IE。感谢党,感谢国家,感谢CCAV,这样的比例让我在抛弃IE的时候决定不会太艰难。 来源,google不计,第一是baidu,其次twitter,然后豆瓣。google不计是因为通过google过来的人都算不出来…. 爬虫上说,google占了一半,其次是sogou(这个混帐爬虫占了1/3的流量却没带来几个ip/pv)。然后是Yahoo和baidu,两个没差多少。 google reader订阅数是180,平均每周更新3.3篇,我还算努力吧? 最后是很丢脸的ip/pv,上个月ip2700/pv8900,本月预期ip3300/pv8600。

linux下多种文件系统在小规模追加写下的性能

Aug 9, 2011 - 1 minute read - Comments

因为公司需要,所以贝壳最近做了一个比较。多种文件系统,在小规模写下的性能。 首先要说明的一点是,贝壳的blog为了保持便于传播,因此惯例是不贴图。这次的图,全部在blog同空间的相册上,通过引用方式放原始连接,可以保持原味查看。我知道中国不少站长复制粘帖大法厉害,不过大家手下留情,可以的话自己找个图床,贝壳可以提供所有原始图片。万一相册过载,blog也会跟着挂掉,谢谢谢谢。 这次的内容,对于有些类型的应用很有价值,具体哪些——懂行的自然了解,就不多嘴了。测试的目标,是测试在同样的环境下,不同文件系统对于散碎的写文件的支撑能力。测试方法如下。 首先,贝壳写了一个程序,可以开N个子进程。每个进程打开4个文件,分别写出16, 32, 64, 256字节大小的块。间隔m秒写一次。当磁盘吞吐耗尽的时候,大量的线程会排队在iowait上,因此造成iowait和loadavg快速上升。当loadavg明显超过CPU数时,宣告文件系统压力达到极限。具体测试方法,使用自己设计的压力系统对磁盘造成压力,然后通过压力读取系统读取系统参数,输出到文件。通过一个filter重新组织文件,计算移动平均数等。最后通过gnuplot输出图像。由于具体有些涉及公司业务,贝壳避嫌,就不贴出源码了。draw.plot的代码在最后。 这个业务情况的核心问题是,对同一个文件,在一段时间内会写多次。正常情况下,这些数据会堆积在系统的Dirty区域,直到dirty_ratio的限制到了,或者dirty_expire_centisecs的限制到了,系统才会开始强制写出。否则每隔dirty_writeback_centisecs的时间,系统会写出部分数据。虽然理论上说,一个磁盘的IOPS应当在每秒600-700次上下,但是实际上并不是只能支撑150个并发的。然而设计的好的文件系统,支撑并发数会比设计的差的文件系统明显高。 这个测试环境和实际的另一个差异,在于读写平衡上。这个业务和大部分的日志系统是很类似的(其实我们系统的业务就是日志)。但是商业用日志系统的特点是在高散碎文件写的情况下还有高随机读。这点在测试中并没有涉及,测试是单纯的大量文件追加写,请读者自行注意。 首先是400进程,间隔1秒写出,测试对象是ext3, ext4, ntfs, jfs, xfs, btrfs,基本涵盖常见的linux文件系统。ntfs不属于常见的linux文件系统,本轮只做对比测试。首先可以看到的是ext3糟糕到吐血的表现,磁盘写io只有500上下,400个进程最多有280多个在排队。这货不是坑爹呢么。ext4的结果就正常很多,io在100上下,开始的高开是因为前一个测试的静默时间不足。jfs的结果很搞笑,队列load倒是不高,可是Dirty缓存一路上涨,让人不禁怀疑到底有没有写出。xfs的表现中规中矩,半分钟一次写出,和贝壳机器上的dirty_expire_centisecs相吻合,Dirty也不高。btrfs和jfs的情况类似。 上一轮中,筛掉ntfs和ext3,其余进行1000进程,间隔1秒写出测试。测试对象是,ext4, [jfs](), xfs, btrfs。这次ext4也表现出了坑爹的一面,Dirty最高250M多,load也明显超过了2,写io大约在700上下,就此出局。btrfs这次的Dirty控制还不错,在25-40M徘徊,写出也不多。看似情况略好,实际上暴露出btrfs一个非常大的弱点,突发响应能力差,服务不稳定。一次集中写出,就能让排队数飞速上涨。jfs虽然曲线类似,但是队列可从没有超过1。综合考虑,后期平均load也明显超过了2,一样出局。xfs还是一样中规中矩的写出,非常低的io和Dirty。jfs依然是高速上涨的Dirty和超级低的io。 测试到这里,只剩下了jfs和xfs。jfs的特点是大量使用Dirty,平均io很低。xfs的特点是Dirty使用比较低,io输出比较平均。不过我们的服务器内核对xfs的支持比jfs要好一点,所以使用xfs已成定局,下面就是测试两者的极限性能而已。 第三轮的参数是2000个进程,0.75秒间隔。jfs和xfs表现非常相似,让贝壳差点怀疑自己是测试错了东西。核查之后,确实没有。所以就下狠手,测试了一把高压力的。 第四轮的参数是3200个进程,0.5秒间隔。从绝对量上,大概是基础测试的16倍。在jfs测试开始后的三分钟内,load上升到了60,宣告出局,因此贝壳这里没有jfs的图像。但是xfs还是完美的顶住了压力。Dirty已经上涨到了80-120M,平均io也到了300。然而平均load只有1左右,最高load也只有1.4。 最终测试的参数是4000个进程,0.5秒间隔,基础测试的20倍。xfs的表现万分惊艳,平均io300-400,Dirty100-160M,平均load大约是1,最高也只有2。也就是说,到最后贝壳还是没有测试出xfs的最高压力。 另外,贝壳也通过iozone对两者进行了测试,结论是,xfs在读写性能上比ext3高一些,但是在随机读写上大幅低于ext3。无论哪个数据,都无法出现这种20倍以上差距的现象。因此贝壳又对文件系统选择发生了兴趣,具体写在下一篇blog上。 从最终结论上说,我们确定了xfs比ext3的巨大提升(20倍以上),并准备对xfs进行可用性测试。如果您有什么经验,欢迎和我联系。 -------------draw.plot------------- set terminal png size 1920,1080 set output "out.png" set xdata time set timefmt "%H:%M:%S" set y2tics set origin 0,0 set size 1,1 set multiplot set origin 0,0.5 set size 1,0.5 plot 'out.dat' using 1:2 with lines title 'Buffer', 'out.dat' using 1:3 with lines title 'Cached', 'out.

从C++的一个特性到设计原则再到哲学

Aug 8, 2011 - 1 minute read - Comments

最近在看C++的设计和演化,里面讲到算符重载。关于这个,Effactive C++里面明确说明,不要试图重载&&和||算符。因为这个重载造成的结果和默认不符(Not same with the default)。 &&和||有什么特殊?熟悉C的朋友考虑这么一个问题。if(i && ++i)的作用是什么?基本来说,这个语句是判断i是否为0或者-1的,并且有个额外效果就是对i进行自增。但是,如果i == 0,则不进行自增,这就是&&的短路求值原则。这个原则产生了一系列写法,例如sh中常见的[ -z “\$ABC” ] && { … }。 不过当重载了&&或者||后,就破坏了短路求值原则。因为C系列语言是应用序语言,参数先求值。所以后参数*一定*会被求值,无论前参数的值是多少。 更加悲崔的是,这个破坏了最小惊讶原则,或者叫做知识内隐原则。当你使用一个知识的时候,你会根据自己的经验对这个知识做内隐的预期。例如,虽然螺丝有左螺纹也有右螺纹,然而你在拧螺丝的时候,多数预期是顺时针拧紧。不论其理由,这个已经成为常态。同样,有下压把手的门是扇页门,画着杯子的店家是咖啡店和茶馆,画着裙子的厕所是女厕,这些都是你对知识内隐的预期。破坏这个预期,相当于把螺丝改为反向,下压把手的门改成移门,画着杯子的店家是古董店,男厕画裙子一样,会让人感到不知所措。大家会莫名其妙的绕出去,确认门上画的确实是裙子,走进去再看到男厕,感到世界莫名其妙。 同样的道理,如果一个对象使用了&&重载,程序员唯一能够快速发现的机会就是在调试时单步了&&的语句。如果他运气不好,可能在数个小时内都找不到理由,直到反汇编目标代码为止。 那C++为什么设计算符重载?那是设计给需要的算符用的。其实C++一直是一个矛盾的设计,一方面他认为,程序员是不可信的,所以C++里面有隔离保护系统,例如私有成员函数和变量。另一方面,他又认为程序员应当对自己的行为负责,因此他设计了复杂的算符重载,复杂的继承系统,并期待程序员能够按照正确的方法使用。这是一个奇妙的,矛盾的设计思路,反映设计者自身的冲突(例如多人设计),或者C++设计者的实用主义倾向(选择最实用的设计)。python语言的思路相对统一,他认为程序员应当为自己的行为负责,所以python的隔离系统都是伪系统。而java的思路也相对统一,他认为程序员是不可信的,所以java才会搞出复杂的架构哲学。

估算(一)

Aug 4, 2011 - 1 minute read - Comments

出租车价又涨了,贝壳好奇出租车上面水到底多深,就找几个师傅了解了一下行情,大家看看吧。 首先是油价,目前是7块多,不到8块,按照7.5算。出租车都不太新,每百公里油耗不小,按照8-10算不过分。一般出租,只要在市区跑着,平均速度大约是40公里/小时。司机都是24小时轮班制的,做一休一。平均做一天,大概上缴330-380不等的出租车管理费。以上就是大致的原始数据。 一天24小时,大约要跑960公里。乘上油耗,大约是86.4升的油。折合价格,大概是650上下。这是工作一天的油价。 师傅做一休一,一个月只能做15天。按照税前4500的工资算,一天要赚300才能做平。对于老驾驶员,还做一休一来说,这个价格不算太高。去掉三金和税,还剩下3650。 一天管理费350,一个月师傅这里能缴5250的管理费。但是三金就要缴掉2000,还剩下大概2000是真正的管理费。 我们综合来算,一天的成本是1300。 平均里程费用的问题,其实有点复杂。不考虑夜程,大概可以用3.5算。大概原理是这样的。 3公里以内,14元。就算正好3公里,费用还是4元多。不足3公里平均费用更高。 3-10公里,一公里2.4。最低值平均费用4.6,最高值平均费用3.1,最终得到的平均费用都介于两者之间,里程越长,平均费用越低。 10公里以上,一公里3.6元。总平均费用会从3.1逐步上升到3.5左右的样子。 从区间函数变化可以发现,出租车费用最低的区段大约在9-11公里之间。6公里以内的费用最高,12公里以上的费用就平均了。注意,以上计算都是时间-距离折算计算,即时间延误被乘以系数加到距离上了。实际出租车计价表也是采用的这种算法。 中途插播一句,如果是多人短途,例如三四个人2公里多。或者8-10公里的地理距离,价格在28-35上下,都是比较合算的坐法。出租替代公交的成本不高。 1300的成本,除以3.5的公里费用,得到371公里。加上各种余量考虑,出租车司机一天最高驾驶1000公里,实际400公里有客就可以收回成本,即空载率不应低于40%,否则就亏本了。 我们观察成本,发现一半多的大头多来自油价。难怪每次油价变化出租车师傅都一脸郁闷。 对抗油价变化的方法也很简单,就是等车,减少空乘移动。从上面数据可以看出,每公里载客可以赚入2.8元,一天的除油费成本650。如果每次载客结束都是当场熄火等待乘客,只要232公里就可以收回成本。所以我们经常可以看到机场或者各个地方的司机师傅,排长队等车。而且油价越高,师傅移动拉客的成本越高,越趋向于等车。 一个师傅每个月缴2000的管理费,上海大约是5万到10万辆出租,一辆出租两位师傅轮流开。一个月给各个出租公司上缴的管理费大约是2亿到4亿。 出租公司要负责车辆管理,叫车电话服务,人力资源,还有无线电调度,是有一定开销的。车辆管理的费用浮动,不大好算,然而普通人的车辆,一次养护成本大约是1200,一年一次。我们假定出租公司成本翻倍,一辆一个月200,全上海的车辆维护大约是1000-2000万。叫车电话,调度管理按照1:100的管理比例,需要500人持续管理。按照合三金工资4000(对于无技术的接线员来说,会比需要技术,连班转的出租师傅工资低)计算,大约是200W一个月。无线电调度不是很清楚,应该没有特别高的成本——除了牌照一类的问题外。 满打满算,各家公司的总开销,加上正常盈利,一个月5000万已经足够。那么2-4亿中的其余部分到哪里去了呢?是成为了出租公司盈余,还是成为政府管理拍照费用,这就不得而知了。 以上数据,都是2011年5-7月间,和各个出租师傅聊天时提到的。大部分数据都是经过一位以上师傅的口中说出,有一定准确性。然而由于仅听取了同一利益倾向的所有当事人,所以数据可能有一定误差。

如果你的python项目一定要源码保密,你一定用错语言了

Aug 3, 2011 - 1 minute read - Comments

python的特征在于快速编写代码,快速运行得到结果。通常而言,就是高开发速度。 如果你的项目需要源码保密,那通常不会是高速开发的项目。因为能够高速开发的,就能够高速复制。别人在看到你的概念和基本逻辑后,可以非常快的抄一份出来。代码什么的根本是浮云。

除虫故事(二)

Aug 2, 2011 - 1 minute read - Comments

第二个故事,是一次oracle数据库的紧急损坏抢修问题。 当时客户紧急保修,系统无法继续工作,重启后无效。我们就找了DBA赶快飞去客户那里。客户有两台应用服务器和两台数据库,应用服务器组成热备的态势,数据库组成RAC。数据保存在一个SAN盘阵上,LogFile放本地,ArchivedLog使用备份脚本复制到备份服务器后删除。听起来是挺靠谱的方案,没想到就坏了。 去了后,客户说暂时恢复了运作。然而我们还是要出具详细的报告,因此赶快去了机房。贝壳第一眼看的东西,就是/var/log。里面的报告是err9,也就是文件读写错误。oracle一切正常,应用发布服务器一切正常。 这下有点抓瞎了,难不成要出具一份报告说SAN盘阵损坏?可是损坏也得有厂商来维修,说坏得有真凭实据阿。现在SAN一切正常,这个报告怎么写呢? 说来算巧合,贝壳检查磁盘的时候,顺手打了一句df -h进去,看到磁盘空间已经用掉了80%以上,顺口问了句DBA,如果空间耗尽会如何。DBA说会挂起,和目前状况一致。贝壳顿觉狐疑,是不是空间耗尽呢?是的话,为什么会神秘的恢复呢? Oralce的运作非常精巧,也非常复杂。当一条SQL语句执行的时候,先写LOG,然后操作数据,最后再将结果写入LOG。当出现问题需要复原的时候,根据某个时间点的数据备份,和整个运作过程中的所有Log,就可以复原。但是LOG写出的时候量非常大,没有无限的空间给他写阿。所以LogFile的设计是文件循环,当写满一个文件,切换下一个文件。一个文件写满后,就会有一个服务,趁着磁盘空闲,将Log压缩备份为ArchivedLog,然后再将这个文件的状态变为Empty。 我们的设计,是通过脚本备份ArchivedLog,除去最后一个文件外,复制到备份服务器上,然后删除。但是我们对ArchivedLog的量估计不足,一天清理一次,分配空间只有20G出头。系统开始的时候压力不高,因此绰绰有余。后来压力逐渐升高,这天的操作比较多,ArchivedLog量大了点,导致空间写满。当ArchivedLog空间满之后,备份进程就会报告错误,这就是/var/log下面err9的来历,因此LogFile无法备份出来。当所有的LogFile被循环写满后,SQL执行前试图写入LogFile失败,执行就会失败,然后挂起在那里。这导致了所有应用发布服务器的失效。 备份脚本的设计是定时和开机结合的,在客户第一次重启设备的时候,已经执行了备份脚本。然而备份动作需要执行相当久,中间客户又重启了几次,导致备份工作进展缓慢。直到半个小时后,第一份ArchivedLog才备份出去。然后清理文件,开始LogFile的备份,大约执行了一个小时多。此时服务就突然恢复了,因为空间问题已经暂时解决。而后是不断的ArchivedLog备份和LogFile的备份的平衡,直到我们到的时候,LogFile已经全部空了,ArchivedLog还没有完成备份。因此我们才能抓到最后的尾巴。 反过去检查备份脚本的执行记录,基本验证了这个想法,客户也接受了我们的报告,不过还是要责令修改系统——这是后话不提了。 这个故事里面,至少有几个教训。 对于所有编程时无关紧要的假定值,在开发时可以胡给一个差不多就行,但是上线的时候必须重新分配合理的值。因此必须将这些假定值记录出来,否则从程序中找出假定值来本身就是一个非常困难的事情。 确实运作一下,搞清楚运作方方面面的问题,不要想当然,觉得没问题。就算运作了没问题,在时间的考验前都没人敢保证没事。 一套系统,尤其是大型复杂系统,必须有懂得运维的人员接手管理。检查磁盘IO,CPU压力,内存和磁盘用量,数据量,网络响应速度等等问题。 废物Log不要乱出,太多的Log和没有无异。如果早关注备份脚本的执行记录,就能早找到问题。可是由于量太大,我都是过滤掉了看的。

除虫故事(一)

Aug 1, 2011 - 1 minute read - Comments

汽车对冰淇淋过敏的传说都听说过吧,贝壳也说几件故事。寓意什么的就别提了,当个故事听吧。 第一个故事,是一个传奇的问题。贝壳早在02年的时候,就在家里弄了两台电脑。互相用网线一连,组成局域网打游戏。当时流行的游戏还是Diablo II,当然,这东西的III已经叫了10年,还没出来,接近永远的毁灭公爵。两台机器之间的游戏打的很流畅,一点异常都没有。 当年文件共享还是有很多问题的,尤其是连续的几个蠕虫,有志一同的使用了windows的samba系统。所以安全上说,贝壳舍弃了windows文件共享,使用ftp方案。当年还流行用ftp开自己的文件资料共享站,贝壳就用雷电自己开了一个。现在基本看不到了,基本都是用网盘或者p2p。问题就出现在这个文件传输上。 文件传输的速度常常限制在1-3K之间,速度死活上不去。结合Diablo II可以正常工作的事实,贝壳的初步结论是ftp系统问题。然而从外网测试的结果,ftp站点一切正常。那么ftp客户端呢?经过测试,这个客户端软件和配置在外网上访问贝壳自己的站点是正常的。 那么从表象上看,问题就在客户端所在的机器上了。贝壳检查了机器的网卡和系统驱动,又重装了系统,问题仍旧没有消除——似乎有点奇怪吧。而且推理上说,如果机器有问题,Diablo II也不会运行的如此流畅的。 好吧,我们揭晓谜底。问题出在两台机器相连的一根网线上。这根网线质量不好,有一根线时通时断。结果导致ip数据包概率性不一致。ip是不管peyload一致性的,但是tcp管阿,结果导致大量的tcp重传。tcp是一种慢启动协议,因此速度死活上不去。 至于Diablo II可用的问题,则是因为游戏的数据量少,包也小。因此即使慢启动,数据也可以很快重传,导致虽然有问题,却不能很直观的被发现。 这个问题,直到贝壳无意中更换网线才被发现。但是细究推理,却是合情合理。算是一场灯下黑吧。

给初创小公司的几句话(三)

Jul 27, 2011 - 1 minute read - Comments

第三篇故事,是来自于贝壳自己的惨痛经历,在另一位朋友那里也有类似教训,可惜他未及早听我一句。 贝壳原来在一家公司里面做项目经理,公司做企业定制开发,现在仍在,所以具体情况隐去不表。因为某些情况,老板叫贝壳做了项目经理,按照资历和能力来说,其实并未足够。贝壳精通的是C++开发,而项目是使用.net技术做的。因此贝壳对项目的管理能力实际上打了一个折扣,只能负责结构设计和协调。当时对项目管理也不是很精通,可以说是半吊子水平。公司承接了一个企业的业务系统开发,经过前期准备,我们团队就开去了客户那里进驻。客户要求,界面一定要漂亮。因此我们选型下来的结果,使用了.net 3.5的wpf开发。开发过程中其实还是有很多问题,很多都是新手问题,暴露贝壳总体设计和项目把握的缺陷。不过这和今天主题无关,就略过不谈了。主要是.net 3.5开发,到了最后发生了几个严重问题。 首先第一个问题,是客户有很多win2000机器,甚至还有一些win98。这个在当初系统设计的时候完全没有考虑。我们开发的机器一律全是winxp,.net 3.5 wpf可以完全的运行在上面。而对于win2000,wpf是无法安装的。于是,我们就必须要求客户升级到winxp。企业用户,他们还必须使用正版。其次,.net 3.5在进行远程SOAP调用的时候,会出现严重的内存泄漏。其实并不是真的泄漏了,.net 3.5的SOAP系统没有考虑调用接口可能多达数百个的情况,对每个函数都进行了序列化器缓存。这个缓存会耗费100-200M的空间,加上其他开销,我们的系统总开销是200-300M,比大部分游戏还高。这个直接导致客户运行我们系统的时候,必须多加一倍的内存。 更郁闷的问题还在后面,wpf是使用dx渲染的系统,因此如果客户没有独立显卡,系统速度就会慢如龟速。wpf的部署必须使用完整sdk,2.0的runtime安装包只有20M,而3.5的完整sdk高达350M。我们在每台机器上安装的时候都是用U盘完整安装350M的sdk。不过这都不是最郁闷的,最郁闷的是,我们项目最后问题实在太多,有个员工做了一个web版的。界面难看很多,但是方便移植部署,内存消耗小。瞬间得到全企业上下一致支持,他们的老板还问我们,当初为什么不这么设计。贝壳哪里好意思说,您不是要漂亮么? 实话说,要不是老板和客户关系好,我们非要给愤怒的客户踢出大门不可。这一个项目,成功的是老板,失败的是贝壳。 总结下来,两个教训。首先是设计必须实地的调查一线需求,不能光听上面的就得出结论,也不能光看部分典型用户就得出结论。如果有一些关键用户对构架支持不良,业务上又不能放弃,就必须权衡得失,甚至修改构架。如果当时我们知道win2000乃至win98的事情,就压根不会考虑使用wpf来做界面。第二个,就是不能迷信技术,或者激进的使用无法掌控的技术。宁可使用最土的办法,老老实实的把业务做出来。新技术由于刚刚出现,因此很多问题都没有完全暴露,很多领域也没有经验积累。例如这个例子里面的内存占用问题,安装包问题,系统问题,都是到了部署时才发生的问题。使用新技术,就会随时面对无人发现的问题,这和RPG的踩地雷战斗是一样的经历。只是这里不但没有经验值,而且踩多了还会直接挂掉。

动车追尾事故的几句

Jul 25, 2011 - 1 minute read - Comments

扯死多少人追责是没意义的,搞清楚究竟死了多少人,他们都是谁比较有意义。反正我们都知道,中国官场历来有控制死亡人数的习惯,去佐证这个有任何意义么?我对死亡和失踪人员名单更有兴趣点。如果家属觉得感情难以接受,隐去具体姓名并注释即可。至于死亡人数,我估计在不到百人左右。两辆可乘千人的动车相撞,又都基本满载。在对撞的时候,释放的能量是速度的平方。速度增加一倍,破坏力大概增加三倍。加上前面说漏嘴报的是63,估计差不多吧。 新浪的一个图转了一个机车人员对事故的看法,实话说没看懂。但是有一点很有意思,为什么同样被雷劈,前车无动力,后车却高速撞了上去?如果雷击集中在前车,导致车上所有电子设备全部损坏,也是说不过去的。就同一个图所描述的,还有一个装置判断两车距离,方法是使用电阻。实话说这个方法太漂亮了,基本只用到高中知识就能想通,展开说一下。 两个平行铁轨,我们可以看作是一个无限长电阻。不考虑岔道的情况下,两个铁轨间的电阻应当是无穷大。如果有列车在上面驶过,就会接通铁轨,导致电阻下降。利用这个原理,在铁轨上每一段距离就设一个电器设备,计量电阻。如果有列车试过,电阻下降,灯就从正常转入黄色,红色。驶过后电阻恢复,灯又转入正常,后车只要看前面一段距离的铁轨设备就知道是否无障碍了。不仅是火车,上面有卧轨应当也有可能查出来。如果前方铁轨装置损坏,那么后车什么都看不到,一样应当停车。 结论?这必然是切掉设备辅助,人力操控才能发生的故障。 上次落雷停车,有专家出来说是好事。某种意义上说,他是对的。如果不是因为落雷导致停车给铁路部门太大压力,有可能,当然,只是有可能,这次落雷就不会有人要求强行运行。老老实实的停车,也不会死这么多人。 舆论杀人?别逗了,落雷停车一次是正常,一个月连着两次,是设计问题。 埋火车的事,先别着急定论。毕竟这是埋掉,而不是烧掉。现场还在地下,同类火车也有不少,说湮灭罪证不合情理。但是要说恢复通行,更加不合情理。地面上难道放一节车厢的地方都没有么?还是埋车厢比拖走更加省力? 主管官员走了谁又来了谁很重要么?你觉得换上谁才能让我安心坐火车? 飞机票又要涨价了。五年前,我说飞机比火车安全,大家不信。现在出了事情,估计大家要去坐飞机了吧?现在我说飞机比火车危险。国航的老飞行员,原先是属于空军的。飞行时间非常长,经验丰富。后来中国飞行事业蓬勃发展,飞行员供不应求,后面的飞行员都是标准培训出来的了。不是我鄙视培训学员,但是要他们和数万飞行时间的老飞行员比,还不够格。问题是现在只有培训学员。 从北京到上海的最佳方法是什么?火车会被雷劈,飞机会误点,开车交不起高速费,走路不安全。从一个海中城市到一个海边城市,最好的方法当然是坐船。