分类 技术 下的文章

因为最近工作原因今晚和在不同公司的老同事一起review了一个晚上的一个老系统的代码，感想如下。
1 往回看，总是发现以前的工作做的很多问题，不够好，蛮丑的。
2 原来的系统搞的挺复杂的，对老东家的技术团队表示担心。
3 要不断回顾过去，不断总结，多交流
4 不同公司的人一起codereview其实有蛮多交流，但是因为商业原因难有机会，交流设计的机会都不多。

最近订购服务器，从朋友那了解了一些服务器的新技术，发现大学学的计算机体系结构中的知识不少已经old了。
可能也很难有书籍对新的体系结构作归纳总结的吗，还是只能看企业的文档和博客文章。
http://en.wikipedia.org/wiki/Intel_Nehalem_%28microarchitecture%29
Nehalem

我可能是国内最早(08年)在实际项目(海内饭否)中部署thrift的人(之一)。 根据我自己的体验给出如下介绍和评价
0 本质上他是一个跨语言序列化和反序列化封装，网络和服务器封装，简单RPC封装，提供的功能和以下关键词近：ACE，XML，joson，json，sokcet库，CORBA，通信协议
1 实用：互联网公司非常适合使用，见过很多公司自定的通讯协议非常不灵活和容易出错。
2 轻便：虽然目前没有正式文档，但是阅读白皮书之后，看看Tutorial和代码很容易上手。并且抽象层次清楚(可分成通信协议，传输方式，server模式，其他util），复用方式灵活(可只使用一部分功能，比如只用它的序列化封装用来存储对象)，编译部署方便(lib级别的服用，C++库只使用boost不依赖其他东西)。
3 跨语言特性： 在实际使用中用了PHP，python,C++三种语言，都非常方便
4 漂亮完善：thrift代码不论从模式、风格、设计、语言特性利用都相当漂亮，读起来赏心悦目，很容易理解思路。同时对线程，并发等的一些封装也很好用（你可不用他通信功能）。对协议变更等的考虑也相当完善。
5 性能：由于是内部的服务其实不容易有连接性能，传输性能和协议处理性能在实际使用中都没发现瓶颈，做过简单测试（简单的服务，每秒在内外可以完成10万次请求）。
6 不足：
纯c++/C实现的内部协议对POD对象(扁平的对象)可以不用解析对收到的内存指针强制类型转换，这样能更快一些，同时解析部分可以选择性解析；
听说windows下支持不够良好，我没试验；
python版本的soket封装有默认使用ipv6本机地址，在未装ipv6模块机器上会出错
结论：快去了解试用吧！
在我使用之前看的一些文档：
. thrift 主页  http://incubator.apache.org/thrift/
                   http://developers.facebook.com/thrift/ (被我好啊党墙了看不到)
  . protocol buffers  主页
                  http://code.google.com/apis/protocolbuffers/

  . 无责任比较 thrift 和 Protocol Buffers   http://blog.scaner.i.thu.cn/index.php/2008/07/10/thrift-vs-protobuf/
  . 使用thrift python版本来调用HBase http://yannramin.com/2008/07/19/using-facebook-thrift-with-python-and-hbase/
  . thrift vs protocol buffers:  http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers
  . google的二进制编码格式 http://space.itpub.net/?uid-14420698-action-viewspace-itemid-410106

http://incubator.apache.org/thrift/

最早是
wget  + find
后来是 rgex
再后来找文本前后缀，找xpath，vpis
再后来分化了
有人网自动提取发展（规则+统计）， 有人做更好的标注工具（做的像样的我只知道某著名的论坛搜索）生成regex或者xpath模板
但是都遇到js和富客户端的逻辑的问题。
从人肉分析 到用jscenter 做js render。不过遇到js事件都没辙。
最近我在想，应该把标注工具更进一步发展为actionRecorder，做到能记录人访问到信息的步骤和特征（url输入变化，js事件变化，表单提交，所选中的xpath）来提取。这是比较近能看到的大幅度提高生产力的方法。
就说到这。

酷讯最早的5个人都离开酷讯了（创始人陈华11月离开），所以我可以比较不顾忌的发一点博客，做一点总结。

以前和某人聊天，问到为什么5460会输给chinaren，某人说5460的国有体制就是一个基本的问题。

酷讯虽然不是国企，原因也类似。
房产产品是少数在酷讯较长时间直接负责研发的项目，所以安居客这个房产垂直网站我很早在它刚上线不久就注意了。今年听说他去年有400多万的收入（第一年就有这么这么多，不少），并且最近又获得了1千万美元的投资。可是这个网站至少在07年和酷讯房产频道相比在用户市场上根本不是一量级的，酷讯仅房产每日独立IP数是它的20倍，有效覆盖城市是它10倍，中介注册用户数数万。不过它的产品做的确实不错（这个不要紧是可以学的），所以当时我还特地在周末组织一个沙龙探讨如何向安居客学习。但是这些都是没有帮助的。从07年初开始，经过第二轮融资的酷讯已经成为一个高估值的像样公司。并从各路请来了一堆总监，副总，体制上已经不是一个车库文化的创业公司，部门的概念增强，空话废话增多，一句话：像个大公司的潜目标被抬上桌面。事实证明，这对事情本身发展帮助甚微。
为什么呢？
1 像样公司的错误体制
   事情刚起步，还未度过开拓阶段还未建立壁垒走向规模化阶段，过早脱离“车库”创业公司进入规模化的像样公司则拓展无力。因为很多事情，并不是大能干出来的。只有真正深入才能拓展开来，没有特别魄力的一般大公司怎么能够深入敏锐呢。当时把酷讯定位一个已经进入规模化阶段的公司是很没有道理的，真正潜在的机会只能被安居客这种新兴企业把握住（当然安居客最后也未必胜出，酷讯当时也不只这一个机会）。
2 人事错位
  在我的角度看来，基本上07年后期除了少数例外（这个例外我稍后说），酷讯其余一无进展。
  为什么呢，还是那句话，错位。当时以为公司已经像样，最需要看上去level很高的人，把事情弄顺做大。事实上真正需要拓展的事情根本几乎深入触及，而最简单的常规事情倒是在进度里面天天看见。我想和听说的安居客一定不一样，创始人有机会直接面对用户和拜访客户，直接体验和判断产品和市场。如果不这么做只能是在会议上拍脑袋，邮件里想当然。
3 激励无效
  定位错误，把公司做成像样的公司的体制，是无法激励的根本原因。因为没有盈利无法用现金激励，因为定位和估值过高，期权激励几乎无效（除了被忽悠的除外）。

那个例外是什么？
是机票产品。为什么机票产品是例外呢。
机票原来是被产品部门不看好的一个方向，并且事实上也不能算是特别好的方向。
但是这个团队有一个比较好的小体制。有一个关键的人XF（未和他打招呼，先不实名），他可以说当时在酷讯做的很不起劲，于是忍了一口气做一个独立的事情
争取了1.5个研发（是的我也不是很看好，只安排只有1个工程师和一个实习生），1个pm，在不健康的大环境里打造一个相对健康的小环境小体制。
这个小团队尽量的都不要其它部门和管理人员的插手，XF把关系控制好，把饼画给团队，争取资源。所以是的，就那么3，5个人就
有成效，从头做起（系统也是比较独立的，虽然简陋）也是从几百IP的访问量，几千的收入开始做起。让同样是看上去像样的公司-qunar 紧张。

所以我走的时候觉得，酷讯几乎在任何一个领域都很难成功，无论是否领先，就像国产手机无法战胜山寨。因为壁垒没有建立的情况，体制不好的公司，好的人和事有起色都会被人模仿挖走，或者出来自己创业。
小鱼吃大（胖）鱼在依赖人力资源高度竞争的IT行业是很正常的。这个故事一再发生，非产多，将来会发生的更多。
PS
1 推荐一偏文章 我为什么我喜欢车库，不过这位也只说外显和感性部分。
2 博客系统有点问题，无法回复，刚好我也不希望公开回复，欢迎私下讨论，请见谅。

经历过2个项目
一个是js ajax dom based的框架， 当初还没有ajax这个词，一个台湾的公司写了一个页面开发框架（作者好像还是各博士），理想情况下说能够让页面开发很好。做的非常抽象和搞了一堆技巧，用于3-7层网关系统的的管理界面，当时我还写了一个学习手册。后来这个公司放弃了，再后出了很多js框架，和原来的方向一致，但是却是比较漂亮的实现了一整套框架。
第二个情况类似，也是按自己想象抽象一个框架，写了一个可以说是有点难度有点复杂也不少错误的东西。
这两个情况下最关键的一点还是，当时提出和主导这个东西的人（往往还比较强）走开，这个东西就注定要扔掉，要不就勉强修修补补。
其实如果让我重写酷讯系统，我也会把70%的东西扔掉，只把算法和处理流程提炼出来在新的结构上实现。
所以掂量自己的能力和水平，不做太高的抽象。大多数时候，灵活比体系完整更好。

btw code.google.com 还真不错

beanstalk 类似 windows 2003 server 的 Message Queue,或者 amazon的SQS
特点：
未提供持久化
c语言编写(代码风格类似memcached 我不太喜欢)
有几乎各个语言的client（质量不一定好）
不过如果只是简单需求，用thrift自己编写也很容易（thrfit是好东西，更倾向这么做）。
东西虽然简单但是很有作用：
Queue适合job队列，处理流水化的设计要用到。
进程分开的好处，主程序退出，数据不会丢
32位机器节省寻址空间，用socket通信利于分布式
以前一般用常用数据库队列表(很多网站)，文件做队列（qmail）

逐个增强
1 边际成本逐渐降低，但是门槛又要足够高
反例：视频网站（成本不降门槛不高），下载站（成本不降成本不高），网址站（门槛不高）
正例：百度，腾讯，校内
2 越多人用越好用
反例：酷讯火车票搜索，房产搜索，机票搜索，bbs社区（会水化）百度（须不断改进，搜索质量不能明显差下）
正例：迅雷，世纪佳缘， ppstream，adsense，淘宝，liba（团购会员购），分类社区，大众点评
3 用户粘性大，留下个人数据和用户关系
反例：暴风影音，foxmail，wps，博客网站（RSS烧录，搬家工具）
正例: 淘宝（交易记录，评价），腾讯，开心（用户关系）

以上3点可以构成先发优势，2，3容易不被大公司入侵，如果资本人才流动效率足够高，剩下就看团队了。

IT创业团队难点废话
作者： onebird
发布时间： 2008-11-13 00:59
分类： 互联网

首先来说是找到好的事情，或者说好的方向。
前好几年这件事情问题不大，因为太多领域空白了。随便选个地界都行（当然别选太超前的，如比较购物之类）。
不靠谱的事情再努力也难。
其实是找到好的人和团队。
有的时候明明方向行，如搜索引擎，可能就是干不过别人
再其次是要足够的投资
比如腾讯就差点黄了 搜房也是
再其次是要时机合适
最起码卖个好价钱，如鲨威体坛。。
事 人 钱  时机  ，可以衡量一下：）

  1. 1
  2. 2
  3. 3
  4. 4
  5. ...
  6. 6