Shell's Home

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

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

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

Jul 21, 2011 - 1 minute read - Comments

上面一篇,贝壳说了说老板搞外行指挥内行的问题。这篇反过来,是我一个朋友X的经历。他经历的更加的传奇一些,是一个内行指挥外行的经历。 X是一家外企的程序员,原本这家外企没有IT部,后来为了做市场,于是成立了IT部。他是头一批的老员工,情况和贝壳类似。在他们之后,进来了一个很有水平的程序员Y。Y的水平很高,所以很快的就成了IT部实际的领导人。原本的外企中方经理很是器重,承诺分一定的公司股份,但是要求IT部能够达到一定目标。例如流量多少,来多少IP访问等等。Y很快就带领整个IT部开始行动了,需求分析,计划制定,时间节点分布,系统架构,都很中规中矩。SSH开发网站本身就是一个中规中矩的过程,没有太多的创意可说。半年不到,系统就上线了,基础测试通过,公司上下都很开心。 问题发生在Y拿到公司股份之后,通常按照协议,股份是不能很快变现的。我不知道Y和公司怎么谈的协议,X君作为一个局外人,也只能告诉我一些小道消息。据说Y的股票居然很快就出手了,而后Y君很快的辞职,开了家咨询公司。 而后公司系统陆续发生了一些问题,本来很稳定的流量一下缩水到几分之一,而X君说,他们的营销策略从未有大的改变。更麻烦的是,系统总是出一些莫名其妙的小问题,经常无法访问。公司没办法,只能高价请回Y君来解决。每次都是问题很快解决,但是另一个问题又再出现。几次往返后,公司实在不堪忍受,就再找了一个高手进来看看系统。X君说,人家上午过来,下午走人。说从未看过如此混乱不堪的代码,几乎没有可维护性,建议直接重写。 然后公司就陷入了两难,要不要重写呢?不重写,这个系统显然没有任何继续发展的可能。重写,又如何保证新来的工程师不会搞出这种不可维护的系统。 据说,到X走的时候,中方经理已经被迫辞职了,外方决定找印度阿三来解决这个问题。当然,后面就是一个新的传说了。 整个事情好像是一个职场阴暗面的故事,感觉平平无奇。不过实际上,整个故事还是有几个神奇的地方存在的。首先,公司没有做过Y君的背景调查么?还是说Y君以前一直OK?其次,通常股份都是不可立刻变现的,必须经过三到五年,其目的就是防止这种事情。类似的条件还有无法转让什么的,都跑到哪里去了?最后,公司所有人,包括X君在内,没有发现Y君的系统是不可维护的么?我始终感觉这个故事的背后还有其他故事,只是这已经不是我们讨论的要点了。

重分区和lvm

Jul 20, 2011 - 1 minute read - Comments

上篇btrfs会导致虚拟机慢死的blog都看到了吧?看到了就不多解释。 首先,删除掉cache数据,还有冗余数据,使得数据可备份化。然后执行rsync -av /home /mnt/mdisk/sync,将数据同步到备份的移动硬盘上。之所以用rsync,是因为我在备份的时候还能看看网页什么的。等第一次备份完成,关闭所有X程序,退出shell这个用户的所有进程,然后再次执行rsync,就可以保证同步。同步完成后,注销/etc/fstab下面的/home和swap项目,重启。 系统启动后,先登入root用户,因为此时/home已经恢复到了/下面,所有shell用户的home路径不存在。建立/home/shell目录,并且复制/etc/skel配置,修改owner后,shell就可以登入了。当然,此时是系统默认环境,并没有定制化。没有关系,我们只需要terminal。在terminal中执行gparted,会出现图形的分区管理工具。当然,理论上说,如果你够熟悉,使用fdisk完成全部操作也是可以的,这免除了初始化shell用户和登入图形界面的麻烦。删除原先的/home所在分区和swap所在分区,切割一个ntfs分区用于将来安装windows(回头可以打游戏),剩余的全部切割,而后开启lvm标记。当然,这一步贝壳当时不知道,而是创立了一个未知分区,再用fdisk调整分区类型为8E。而后系统会提示你,不能保证内核数据结构更新,需要执行kpartx /dev/sda。无论如何,此时我们已经有了一个lvm分区。 lvm的结构是pv -> pg -> lv,也就是物理卷->物理组->逻辑卷。物理的各个分区首先被组织成物理组,再被划分为逻辑卷。这样设计是因为可能有多个磁盘上的空间,被划分为多个逻辑卷。在不改变逻辑的情况下,lvm的默认组织构型是raid0的。不过这对我不是个问题,我只有一个磁盘。 首先创建pv,使用命令pvcreate,没什么好多说的。然后是产生vg,使用vgcreate main /dev/sda7,之所以需要main,是因为需要一个vg命名。而后我们需要从这个vg中创建出一个lv来,执行指令lvcreate -L150G -nhome main,设定lv的名字叫做main-home,大小150G。此时在/dev/mapper/main-home,就产生了一个设备文件,大小150G,可以当作/dev/sda1之类的设备一样使用。不过,这个设备没有经过任何格式化过程,所以还需要mkfs.ext3 /dev/mapper/main-home。在这个指令后,我很习惯的跟了一个tune2fs -c 0 /dev/mapper/main-home来关闭重启检测。使用blkid,发现这个设备已经成功创立,并且有了ID。把UUID复制进(这时就知道X的好处了,console下面比较绕路)/etc/fstab,并且修改刚刚被注释掉的/home一行,更改UUID和分区格式。贝壳当时光记得复制,忘记改分区格式,导致系统进不去。不过也不困难,修改/etc/fstab后mount -a一下就可以了。 此时我们已经建立了有效的逻辑卷,并且正确配置。下面要创建一个交换分区,并且挂上去。废话不多说,lvcreate -L6G -nswap main,mkswap /dev/mapper/main-swap。而后一样blkid和vi /etc/fstab。系统就基本配置好了。验证一下看看。 shell-deb:\~\# pvs PV VG Fmt Attr PSize PFree /dev/sda7 main lvm2 a- 229.19g 73.19g shell-deb:\~\# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert home main -wi-ao 150.00g swap main -wi-ao 6.00g 而后就是新系统的启用过程,首先要退出X,注销shell用户的所有进程,然后以root删除/home下的所有数据。如果不删除的话,重启后,这里的数据无法访问,变成垃圾。而后重启,就可以看到正确结果了。不过还不要着急登入shell。首先执行rsync -av /mnt/mdisk/sync/home /home,将备份同步回去。这样我们登入shell的时候就可以看到有效的定制化界面了。另外一点细节是,mdisk使用了ntfs格式,所以导致数据恢复后属性混乱。使用find . -type d -exec chmod 755 {} ;和find .

btrfs上使用虚拟机效率很差

Jul 19, 2011 - 1 minute read - Comments

试图在linux中使用虚拟机的同学请注意,刚刚测试下来的结果,vmware和kvm在btrfs上的IO效率极端的差。 首先是vmware,win2003,512M的实例,开机大约需要40分钟。这种效率已经远远超出了我的预期,于是我改用libvirt管理的kvm。结果依然出乎意料,debian实例的安装需要超过5分钟。由于怀疑是raw格式而非qcow2格式造成的速度差异,因此新建了一个实例,一时偷懒就放在了/下面,这个分区是ext3而非btrfs。结果安装大约在3分钟内结束,这似乎证明了我的猜想。于是我开始使用btrfs下的raw格式进行安装,结果速度依然异常缓慢。由此我怀疑到是btrfs文件系统的问题。 在ext3上创建一个qcow2格式的实例后,证实了我的猜想。问题在于btrfs的某种机制上。在网络上寻找类似问题,并没有发现。因此在blog上提出警告和问题。 有人知道为什么在btrfs上使用虚拟机会导致极端的效率问题么?hdparm和文件读写测试表明btrfs的平均效率并没有问题,磁盘也没有问题。

一个初学者的问题

Jul 18, 2011 - 1 minute read - Comments

今天挺高兴的,因为我看到了一个新手在我的blog上面留言提问。问题摘抄如下,我想他应当不会介意我合理引用吧。 贝壳老师,我是一名大三的学生,下半年马上找工作了。没做过什么项目,编码能力较差但是对技术还算热忱,您觉得在国内做技术40年现实么? 我觉得他的问题比较散,题目也比较大,就专门开了一篇来回答这个问题。 技术40年是个梦想,电脑出现不过60多年的事情,做40年技术的本身就是凤毛麟角,没什么可比性。我认识的做技术的人,最多的是做了将近20年,已经是超级老程序员了。以中国的状况,对做技术的不怎么有利。通常而言,如果你做了五年程序,还是没有什么大的进展,你就会主动的换岗位。因为一般人做了五年程序,却还没有达到一定的程度,周围房子妻子日子会一起压过来,不由得你不担忧你的将来。国外程序员并不背负这么大的压力,而且工资相对平均而言比中国要高一些(当然,国外程序员的工资也在逐渐降低,因为大量的离岸外包)。一般来说,程序员转行最多的是去做管理,也有不少做风投的。出结果的少,多数就默默无闻,只有少数日子过的很惨。 如果你在五年程序生涯后,逐渐确立了自己的风格,并且取得了一定的成就,多数人也不见得继续做程序。大部分人都开了公司,给自己当老板。中国的劳资关系很奇怪,资方比劳方有利的多。混的不错的人,但凡手里有点积蓄的,无不想成为一个资方。我认识的很多老程序员,大都自己开了公司。或者是外包公司,或者是技术公司,但是持续在一线写代码的人却不多了。除去自己开公司的,大部分在大型外企做了技术总监,这些一般是比较有志于技术的。在私企混技术总监的,如果有点年纪,多数都是靠着人脉而非技术坐稳位置的。当然,这不代表我看轻私企的技术总监们的技术。 中国做技术转型快的根本原因,在于不成比例的回报。技术人员要承受长达五年左右的成熟期(http://shell909090.org/blog/archives/139/ ),而且必须全力投入。相反,通常成熟程序员的工资,在写文的时候只有6-8k。加上经验积累,大概在10-12k左右的样子。而做的好的销售可以轻松拿到15k以上的工资,其他途径(大家心照不宣)更多。技术人员还需要忍受技术退火的问题,每五到十年需要重新学习大部分知识。这使得技术人员的投资回报比例低的不像话。 另一个雪上加霜的问题,是中国的盗版问题。中国目前不仅在操作系统领域盗版,而且美剧、动漫、音乐,乃至于创意,皆是盗版,无不山寨。作为用户来说,这给你很廉价的服务。不过对产业而言,这是致命的。目前中国根本没有人真的是做产品的,基本都是抄产品的。产品经理最大的任务,就是根据已有的产品抄一个,然后做一些细节修改,并试图用细节打败对方。在这种思路下面,谁需要用高薪的,有经验的程序员呢?新毕业的学生足以胜任大部分工作,关键是新鲜热辣成本低廉。 上面说了一大通,其实根本没有说到关键问题。你说自己对技术还算热忱,我不知道你热忱的原因。如果你因为技术能赚钱或者很酷,我强烈建议你放弃。和电影里的不同,技术并没有那么大的好处。真正能赚钱的不是技术,而是能用技术解决问题,这个所需要的能力和技术截然不同。也许你会举出Bill Gates和Steve Jobs的例子,我知道你还能举出很多,但这不改变一个事实。他们是用技术解决问题的人,而非仅仅有技术的人。反例你可以看看SGI和SUN这两家公司,都是技术人员的圣地,然而都是悲惨收场。所以如果你打算赚钱,技术不是你要追求的第一要素。也许你会关心,什么才是用技术赚钱的第一要素。这个问题没有标准答案。google用丰富好用的程序赢得用户,apple用良好的设计赢得用户。每个人对这个问题的解答各自不同,知道正确的解答,基本就可以迈入赚大钱的门槛。你觉得我像赚了大钱的样子么? 如果你觉得会技术很酷,我觉得你会落入嬉皮士和脚本小子的范畴。国内能用各种工具扫描网络,破解密码的人非常多,但是能知道各种工具背后工作机理的就相对少。至于能够研究出一种机理,并且写成工具的,可以说屈指可数。实际上,真正酷的是最后一种人。然而大部分人,仅仅是拿着写好的工具,偷盗别人的密码,或者是删除别人的数据,就感到自己似乎拥有力量。这是一种错误而危险的想法。好比你买了一把万用开锁工具,和一把电锯。趁着屋主不在,偷偷溜进人家家里大肆破坏,你觉得有什么成就感呢?这和偷密码,破坏数据是同一类事情,为什么大家会觉得入侵服务器很酷呢?反之,如果你用三年的所有休假,研究了市场上所有的锁,并且一一给出了开锁方法。我想电视台会对这个主题更加有兴趣一点。如果你真的觉得技术很酷,我想你应该仔细研究技术,成为最后一种人。哪怕你最后成为了一个黑帽子(利用技术作恶的黑客),也好过仅仅做一个脚本小子。当然,如果可以的话,白帽子更好。 最后一种可能,是因为你真的喜欢编码。那么,你就必须忍受长时间的编码,旁人怪异的眼光,家人的不解,没有MM,没有休假。在这里要感谢我的老婆,感谢她对我爱好的支持和理解(虽然她不能理解这些技术),否则我得继续打光棍到不知道什么时候。不知道你是否听说过RubyvsPython,我们这帮宅男把编程作为工作,把下了班凑在一起写程序作为一种娱乐。如果你真心喜欢这样,我很欢迎你加入我们这个圈子——当然,多数情况下,这意味着平庸的,和投入不成比例的工资,还有无尽的bug地狱和加班。 如果你没有做过什么项目,我建议你看看我前面写的,如何参与一个开源项目( http://shell909090.org/blog/archives/1848/)( http://shell909090.org/blog/archives/1821/),找一个合适的项目先做起来。你甚至不需要有编码经验,别人也会欢迎你的工作。这对你找工作很有帮助。 另外,如果你打算找一个编码工作,实际的演练一下编码会比较好一点。无论是需要你进行编码的厂商,还是技术上的进步,编码能力都是一种必须的,重要度远远超过英语的能力。当然,比这更重要的能力是阅读代码的能力。当你能够从读者角度考虑,写出适合人类阅读的代码,这就意味着你开始迈向一个新的编码境界。

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

Jul 14, 2011 - 1 minute read - Comments

贝壳做程序员到现在,没去过国企(好吧,和他们有过合作,可实在看不惯他们的作派,死也不去),没去过外企(也是有合作,可惜英语太差),全在各种私企里面打转。从初创公司到中型外包都呆过,还曾是某初创公司的第一个员工,可惜结局不怎么好——关门了。初创公司的一些问题,可谓前仆后继,大家的死法差不多。当员工时,不好给老板直接提意见。现在私下里偷偷说说,有想开公司的当故事听吧。 初创公司第一怕,就是没有经验。没有经验的程序员,没有经验的经理,所以很多事情都不知道怎么办,只能摸着石头过河。实话说,完全摸石头的,还不如不开了。最起码最起码,老板做什么,就必须熟悉这行。想干互联网,必须熟悉互联网。想干企业,就必须熟悉企业。没这个要求,不如不干。至于技术上没经验,可以找合适的程序员。如果老板熟悉互联网,很多做阿里巴巴阿,做腾讯之类的傻话都不会说出来了,他要做的一定是个没有的东西,或者说在中国没有,或者有,但是市场刚要起步。在一个饱和市场内挑战一个巨头,这和唐吉柯德挑战风车是一样的,能得到的只是海明威笔下的鱼骨头。 初创公司没有人熟悉技术怎么办?这就要看你的公司类型了。如果你决定以业务为核心,可以找个诚实可靠(别说看人看不准,如果人看不准,公司哪里都会碰壁)有经验的程序员做主管,记得谈分红或者股份,然后放手给他。他会帮你管理的很好的。不过记得偶尔就他的做法咨询一下其他懂行的朋友。通常这类程序员最好是来自于大型企业IT部或者大型互联网公司,他们会把大型互联网公司的规范带过来。当然,也不要无条件的接受。先文档后程序,重测试轻代码之类的东西对初创是不适用的。起码要等公司有10来个程序员再回头补课。这些人构成的程序部是写不出什么天才程序的,但是可以有效廉价的把你要做的业务做起来。 如果你决定以技术为核心(实话说,中国这种公司比例不高),你起码得有一个高手在手里,才能谈公司的问题。而且公司开起来,你得分给他很高比例的股份。大部分这类创业老板,都是自己就是高级程序员,觉得挺了解程序了。这种情况下的建议反过来,你要找熟悉市场的人,不要觉得你很熟悉市场。程序员不是一个典型用户,除非你的用户都是程序员,否则大部分的需求需要重新考虑,甚至商业模式都未必成立。 初创公司最怕的情况,就是老板不懂技术,也不找人,胡乱指挥。贝壳呆的头家公司,现在已经关门了,所以说说问题也不大。老板决定做销售管理软件,实话说这个决定没什么问题,问题是老板的生产过程。他先找了三个程序员过来(两个新手一个老手,贝壳就是第一个员工,当时年轻,什么都不懂),然后请一个大学教授当顾问。由于大学老师都比较忙,因此他让其中一个比较有经验的程序员负责平时管理,不过还是按照员工待遇。然后他开始做需求,结果时间太少,需求做半本就开始做程序。一下就犯了大忌,需求未系统化。老程序员心知肚明,可是能说什么呢?自己连合伙人都不是,根本说不动老板。 然后制定计划的时候,老程序员制定了一个相对保守的计划——这是当然,因为只有一个老程序员和两个新手,他怎么也不敢激进阿。老板当场否决,把时间提前了两个月,变成三个月完成,并且承诺会加派招程序员。又是一个大忌,拍脑袋决定周期,也没有标杆事件控制。当天我就看到老程序员白着脸进去黑着脸出来,然后很郁闷的修改时间。不过后面的事情好玩的很,程序员来一个走一个,基本留不住人。现在想起来,当时工资实在太低了。工资低是有理由的,贝壳当时基本什么都不会,光学SSH就学了一个多月——还基本不大会用。 做产品的时候,考虑使用数据库,一下子居然挑中了oracle。现在反观,我也不知道怎么做的决策。用oracle做互联网的公司,目前为止我还没听说过第二家,因为oracle的长处在于事务和稳定性,而不是性能。由于维护麻烦,因此也没有买oracle自己的授权,而是第三方公司卖的5W的版本。就贝壳后来所知,oracle从未有这个级别的版本,他们的产品都是20W一个CPU,可以支持25个同步连接来卖的。天知道这个所谓第三方公司是怎么回事。由于配置麻烦(当时还是8),因此抽调我过去处理oracle的安装问题。贝壳就花了一个多月,把linux和oracle安装学了一遍。不过这一来,一个多月贝壳就基本没怎么写代码。一个初创公司一个员工一个月不写代码,可谓是很无谓的损失了。 更夸张的是,由于老板考虑部署的时候,立足点都是——用户太多怎么办,压根没考虑过没用户的问题。所以他开始就自己买机器进行IDC部署。偏偏普通服务器他又觉得太贵,所以还自己装服务器。贝壳再跑了好几次电脑城,买服务器装。虽然采购还是按照采购流程走的,但是又大概一周不干程序。服务器终于全部搞定上线了,贝壳大概一个月花掉了。几个月过去,老板发现进度跟不上计划,就先推迟了发布计划,然后找大家紧急开会。结论是,他加速做需求,我们加班搞定代码。可是有用么?完全没用。下面几个月糊里糊涂,贝壳都不记得自己做了点啥了。发布计划一推再推,贝壳一点信心都没有,就辞职走人了。 后来听说,在长达一年多的开发后,他们还是搞定了系统,并且正式上线销售。但是只有几个客户愿意付钱。坚持了一段时间,老板看实在赚不到钱,只有关门走人。 回顾整个里面的问题,关键是外行领导内行。做顾问的教授是内行,但不是搞互联网的,又没时间。老程序员名义上是经理,却不能否决提议。实际上是最不懂互联网的老板自己在做决策,导致最关键的几个问题上,压根没有发现决策是错的。次之的问题,是为了省钱而浪费时间。程序员出价太低,招的都是新手。买oracle舍不得买原厂带服务的,非要自己搞。服务器都不买现成的,自己组装。这里面能节约的时间,绝对不是花钱能买到的。里面还有什么老板策划需求拍脑袋,听风就是雨,甚至要求我们做一个子功能,叫做”中国地图在线”之类的小事就不提了。 虽说不想埋怨老板,不过贝壳确实在那家公司浪费了生命中的八个月,除了自学linux和oracle安装外没有剩下任何有用的技能。现在这段事情也被贝壳当作一个教训,很多事情不是看起来好就好的,如果事情看起来不靠谱,早点割肉退出不失为一个好的方案。

初创公司的九句傻话

Jul 13, 2011 - 1 minute read - Comments

人都有小时候,初创公司会说些傻话,没啥好奇怪的。不过如果老板持续说傻话,没意图深入学习互联网业,你还是考虑跳了吧。 1.我要做个淘宝/阿里巴巴/百度/腾讯那样的网站/产品。 通常这句傻话下面,往往还跟着,10W块,三个月,够不够?没说后半句就已经够傻了,说了差不多够格上春晚了。你当自己是腾讯啊,没管理没技术的初创公司,靠抄袭,和各大IT巨头的拳头产品拼,没有比这个更傻的了。要抄的对象是外国公司还算合理,具体情况具体分析。 2.我们有来自名校出身的CXO——XXX,来自海外大公司的技术总监——XXX,前XXX公司创意总监——XXX,在他们的带领下,我们一定能XXXXXX。 好吧,有的时候,这句话不是那么傻。问题是,说这句话的人,十个里面大概会失败九个。一方面,来自名门不代表能力超群,有时也可能是能力/人品问题而被踢出来的。另一方面,牛人多了也不行。俗话说,别带两个闹钟出海,带一个或三个。到时候财务总监说砍,业务总监说干,两个人谁都不让谁,老板的头一个比三个大。要是两个牛都在同一个部门,例如两个技术总监,那就更有趣了。 3.我有个创意,不过最近很忙,没法详细整理出来。我大概讲一下,你们先做起来,回头我给你们补充。 连创意细节都不重视,或者不愿意说,还创业呢,失业吧。 4.这里有份策划,你看看要多久?半年?不行,太长了。给你们加20个人,三个月给我做出来,早出来有奖金。 很明显,这老板肯定没看过brooks的那本《人月传说》。通常这份策划一年能出来就算幸运了。 5.暂时没有工资/工资不高,不过我们有原始股份,将来考虑上市。 明显忽悠傻小子呢,一穷二白一起创业,是要双方彼此熟悉和信任对方为前提的。人都要吃饭,光给股份不给钱,来的是什么人就不用多说了吧。 6.恩,策划大概是这样。服务器准备怎么搞?租用?太花钱了。我们自己组装服务器好了,反正不复杂,你就顺手搞了吧,便宜多了。 创业初期,专心自己的业务。一会想自己搞服务器,一会想自己搞所需要的业务库,一会又想把某个功能做成独立网站做接口,你真的想明白自己要干什么了么? 7.我要做一个产品,界面要炫,一定要好看。操作要人性化,要让用户满意。功能要全,人家有的我们都不能少。 老板,您这产品是做什么的? 8.马云当年十八罗汉闯天下,我们为什么不行。豆瓣开始三台服务器顶住了所有业务,我们为什么不行。 是啊是啊,朱镕基当了总理,你为什么不行?释迦摩尼当了佛祖,你为什么不行?抛开各种因素分析,就想着和别人比,你真的有那个条件么? 9.钱不是问题。 恩,多数问题是没钱。

设计的一些原则

Jul 11, 2011 - 1 minute read - Comments

IETF的RFC文档是整个互联网的基石,在RFC1958中,对于其中的一些原则做了总结和讨论。我觉得非常有意思,因此做一下摘抄和讨论。 保证它可以工作。首先做出原型系统,并成功运行,再着手标准化,而不是相反。 尽可能使它简单。如果一项特性并非绝对本质的特性,那么就不应该考虑,尤其是通过组合其他特性也能够获得同样效果的前提下。 做出明确的选择。如果有几种方法可以完成同样的事情,选择其中一种。 尽可能做到模块化。每个协议独立于其他的协议。改变其中一个,其他不受影响。 期望具备异构性。 避免使用固定不变的选择和参数。如果需要使用参数,最好的方法是让发送和接收方协商一个值。 寻找一个好的设计,不必是最完美的。如果有一个好的设计,但是不能够处理一些特例。那么应当坚持这个设计,让怪异的特例自行解决问题。 对于发送一定要严格,对于接收有一定的容忍度。 要考虑伸缩性。尽量去中心化,必要时将负载尽量均匀的分布到所有可以利用的资源上。 要考虑性能和代价。 第二条听起来好像CISC和RICS之争,虽然现在最流行的处理器是一款CISC,但是这并不妨碍RISC成为优美和进化方向的象征。 第三条在两种不同的语言上,有不同体现。python认为Simple is better than complex,ruby认为Simple is boring。具体可以看这里(http://automation-excellence.com/blog/zens-python-and-ruby)。 模块化是一个非常好的主意,但是同样,非常难实现。 第七条在设计大型系统中非常重要,不要为了一点小小的瑕疵破坏整个系统。 joel on software中,提到了第八条。joel认为目前网页格式凌乱的根源有部分来源于此。第八条鼓励人们在建立浏览器的时候,尽量兼容各种格式变化,而不是对每个不符合标准的进行报错。这导致了各种兼容变化。 第九条所有架构师都应该看看。与其购买昂贵的机器和服务,不如在设计系统的时候,就假定系统中的部分会发生故障。使用设计将负载分布到所有可利用的资源上。此条的推论是,大部分设计良好的系统都具有级联失效的可能。因为一旦发生失效,压力会分布到其他资源上。如果这超出了他们的能力,就会导致他们一起失效。

讨论时的态度

Jul 5, 2011 - 1 minute read - Comments

发觉错误要认错,不要在乎面子。死不认错才最丢面子。 不要编造事实。如果你不确定,可以给出参考意见,但是不要说,我确信XXX。更不要为了面子问题而编造一个不存在的事情,大家都会验证的。 别怕专家。专家也是人,专家也会错,更别提里面还有不少的“砖家”。 不随便显露自己的身份。说不赢别人就拿出XX博士XX专家来压人最没意思。除非你们讨论的话题说不大清楚,最后归结为“在XX领域的经验谁更丰富”。 对事不对人。关于某个问题,你可以和人在论坛上吵的很凶,但是转头又是一起吃饭的朋友。不过关于这点,中国人有所谓面子问题。你要先掂量对方是不是个死要面子的家伙。如果是,你让人下不来台导致被绝交,请不要怪我。 不要人身攻击。这里包含了不要质疑对方的出身,动机,等等。例如说不赢就骂对方是猪,猪说的话没听的价值,等等。最常见的,也是最容易发生的人身攻击是质疑对方的动机。例如讨论一个政策问题,说不赢对方,就骂对方五毛,收了好处帮政府说话。这种东西是永远辩不清的,听的人只有明者自明。讨论时你只能就事论事说对方错在哪里,而不是扯到对方动机上去。 不要过度扯无关问题。闲聊时候怎样都好,讨论的时候有关话题适当扯,无关的就不要长篇大论了。 谁主张谁举证。千万别搞倒置了。倒置的话我可以先说你是猪,你举证一下为什么你不是? 不要“敌视”持不同意见者。没有人会永远正确,持有不同意见多数情况下只是意见不同,不是阵营不同。 不要说教,搞一言堂。那是宣讲而非讨论。