商业

搜狐邮件中心开发以前是分成两个小组，一拨C/C++程序员，一拨Java程序员，技术上两者间没什么共同语言。因此我力主引入 python，是想弥合双方的技术范围，让每个程序员，都可能尽多的去接触 E-Mail 的所有业务领域。

一开始是 Twisted 应用，某 java 程序员用它实现了一套监控系统，实时注册IP黑名单系统；MTA 那里则是用它来做 tcptable 查找表的接口。

后来 MTA 那里更夸张的用 pymilter 粘合postfix 和过滤系统，直到我们的某供应商提供了 API 后才不得不改回 C

虽然计划增加 Python 的应用范围，但在规划 AjaxMail 的时候，一开始的确是打算沿用 Java 开发的。原因是三点：
A. 不管 Python 有多少优点，但都绝不应该抛弃以前的旧代码
B. 现有WEB开发人员的知识结构完全是基于Java的
C. 不管 Python 在语言方面有多少优点，但由于主要的业务逻辑都在 Javascript 上，后台究竟用什么语言开发反而是无所谓了。换句话说，Python带来的好处不明显，但风险是极高的

转折点出现在 10 月，两个主力 Java 程序员离开了团队，一个去了微软，一个去了新加坡。我的选择就变成：
1. 招Java程序员，从0开始熟悉现有的代码，学习邮件业务，然后摸索着前进
2. 依赖以前的关系，找几个邮件系统很熟悉的C程序员，用Python或者PHP(类似的事情我在04年干过一次，用PHP替换了eyou.com的CGI)或者什么什么开发，但肯定不是JAVA。

还有一点，我自认永远也不会太深入Java，不可能带着程序员在这条道路上走远。

说起来有点儿造化弄人，我心里确实想全面铺开Python，但理智上还是选择保守，可现实把我推向自己真正想去的地方。

关于这个选择我想更重要的是：万一不得已重头再来，怎样才能尽可能的降低风险呢？
1. 经验。我在这个领域8年了，技术上能做到什么样子还是有把握的。
2. 人才。如果不是因为有一个很得力的程序员，俺就要被迫亲自操刀了；虽然走了两个人，但配了一对更好的组合。
3. 信心。把自己的信心带给团队所有人，消除大家的不确定性。
4. 兼容。代码虽然有变化，但数据格式基本没有变，老的Java代码仍然还是可以使用——我想它应该至少还有半年的生命期。

To be, or not to be. 不管怎么选择，都要事先准备好面对接下来的挑战。

延伸阅读：lighttpd 2.0

7月24日的新闻

暂不说这个企业如何，就业绩来看，实在是里程碑式的事件

能让你乖乖的登录上去，主动填上你最亲密的四个人的手机号码.
上次听过类似的事情是 gmail 的注册邀请.
这次是北京移动的 i-home 家庭计划套餐

我家每个月ADSL上网费用是100元；每个月电话月租+通话费用是 30-40 元，加上IP卡，顶多也就是60元
现在每个月手机费用是120元左右，绝大多数是月租+通话费，我想十年后我的手机数据费用肯定会超过通话费，那时候手机上网会是什么样子呢？？

前天接到一个内部电话，是询问怎样支持英文用户使用搜狐通行证的。事情起源也很简单，为了奥运的需要，访问英文页面的记者们或许有登录的需求。

所以说不管怎么评论这届北京奥运会，必然它会吸引更多的外国人试着了解中国（好像很多人喜欢来类比 88 年的汉城，哦，应该说是首尔奥运会）；另一方面也会让更多的中国人去主动加深和国外的交流。

不知道这是不是首次下命令让交互产品部门试着对英文用户更友好，今天看到这么一则消息：搜狐与中国日报战略合作 协作报道奥运——"...搜狐网的独家内容和博客也将被翻译成英文供《中国日报》转载...张朝阳表示...提高搜狐的全球视野"

看中国的这些互联网企业，国际竞争力最厉害的应该的是阿里巴巴，它一直在做的就是一个接入全球供应链的业务；其次是百度，至少已经走出去了；网游公司做东亚市场勉强还行吧，我觉得比腾讯有底气；ctrip 应该也能做得很好，但它真能算互联网公司么；...

现在看老板好像已经觉得可以适时的推进这个过程了，是好事情，但对搜狐这样的本地门户出身的人家来说，路还要慢慢摸索

今天在 techweb 里看到一则消息

尊敬的用户：

我们非常抱歉的通知您，由于前段时间硬件故障，导致部分用户数据丢失，经
过工程师们的不懈努力，目前已经恢复了大部分的数据，但仍有小部分数据无
法恢复。所有恢复的邮件我们都会放入您的收件箱里，请及时将重要的邮件下
载保存或者转发到其他第三方邮箱；将我们的邮箱设置为安全邮箱的用户也请
及时更改您的安全邮箱，建议使用网易的163邮箱或者126邮箱。我们的邮箱将
在2008年6月1日起正式停用，请务必在这之前做好邮件备份和邮箱转移的工作；
对于期间给您带来的不便，我们表示深深的歉意！

56.COM客户服务部

1. 兔死狐悲.. 免费邮箱这个职业不好做啊
2. 不好看 56 的视频业务。既然它不能体面的结束免费邮箱业务，说明它的团队还是有缺陷的。
3. 赶紧查了查 56 这个公司是在哪里——不出所料，果然是在广州——可惜无法乘机去挖人了，可能会便宜 QQ，呵呵

几个月前看到一家 Email Hosting 服务商 FastMail.FM 专门设了一个 http://status.fastmail.fm/ 来报告网站的维护和故障情况。当时觉得挺有意思的，还订了它的 RSS 输出。

今天看到 SaaS 的代表 salesforce 也有这么一个网站：http://trust.salesforce.com/. 难道向公众(包括客户和潜在客户)报告服务器运行状态会是一项很重要的公关和宣传手段？就好比现在的企业 blog 一样。

附：知道 FastMail.FM 是因为他们付钱给 nginx 开发出了 pop3/imap4 的反向代理，还有 FastMail.FM 的网站好像需要翻墙才能去看.

有两件事情让我相当的郁闷——或者用网络流行用语——相当的纠结

睡一觉醒来后就好多了
现在回头再想，对于我的主要目标来说，这两件事情都是小事。可以放在一边

但使得思考的是引发这两件事情的起因，希望以后少犯类似的错误，用科学的手段去做决策。

最后要说的是，我们一家三口已经成功在北京生存了三周了，现在没有父母帮忙，也没有保姆小时工...对于我们这样一个互联网一个电信行业的家长来说，应该够少见了吧..

最重要的当然就是 IE8 beta1 的发布
本来不想尝鲜的，但发布第二天就有人在论坛上反馈 IE8 无法使用搜狐通行证。无奈装一个看看，最后发现是 IE8 beta1 的 bug——table Element 里面的 rows 无法访问，然后去报 bug 的地方看了看，有另外几例相关的bug报告。
不过 IE8 缺省带的 Development Tools 还不错，调试 CSS/JS 功能已经很齐全了。

和 IE8 beta1 呼应的是，firefox3 升级到了 beta5pre，beta4下周应该就发布了吧

第二重要的事情是：AOL 开放了它的 IM 协议。

第三：Google 开放它的 Contact API

第四：iphone SDK

十几年前我一直为一件事情困惑：就是我们那里(算是三级市场吧)卖的碳酸饮料只有百事，而没有可口可乐。以至于我们认为百事可乐是一个在低端市场铺货的普通品牌，而可口可乐是比较高级的东西。直到去天津上大学，一下火车遍地红色的可口可乐标志，这才觉得原来可口可乐也是很普通的嘛.

可能正是因为这个小事，使得我长期来对商品是怎么流通到顾客手中十分感兴趣。昨晚就网上找了半天资料，总结了一下生活中的零售业态。

* 超级市场(supermarket)
经济不景气的产物，降低流通成本，满足居民基本日常需求。
其特点是自服务、薄利多销策略、食品为主。
北京的连锁超市包括顺天府、京客隆等。

* 大卖场(hypermarket)
超级市场的升级版，商品种类更全面
比如家乐福、沃尔玛，虽然被称为超市，但实际它的业态属于大卖场这个范畴
除了销售分成外，比如家乐福还向供应商收取进场费，据说占其收入的1/3

* 便利店
强调满足即时消费需求(对应超市的满足客户的批量廉价消费需求)
快速消费食品(比如没有生鲜)、香烟啤酒、报刊杂志
北京常见的便利店有快客、倍顺好邻居等，还有 7-Eleven 这个最有名的牌子啦

* 折扣店
关于什么是“折扣店”，定义比“超市”更加模糊
这里说的折扣店是指和超市、卖场、便利店经营范围类似的一种业态
据说其低价折扣的能力是通过大规模定制销售自我品牌实现的
迪亚天天号称自己是根正苗红的折扣店；但按照上面标准来看的话，我觉得屈臣氏才是

* 百货商店(Department Stores)
百货店是指在一个建筑物内，实行统一管理，按楼层、区位和专柜销售若干类别商品，并为便利顾客选购提供必要服务的零售业态；百货商城主要通过专柜销售收入的分成方式获利
四大需求衣食住行，超市已经解决了吃饭问题，百货商店就只能着眼在“穿”上了
以前住积水潭的时候总去中友、崇光；天津就是伊势丹

* 购物中心(Shopping Mall)
目前看，这是商业地产/物业的超级形态；体现“一站式消费”；集旅游、购物、休闲、娱乐、饮食等各种商业功能于一体。
通过分租物业的租金收入方式获利。
中关村购物广场、金源燕莎

* 其它零售业态
家电大卖场，比如国美、苏宁，不知道是不是也有进场费这个东东
家居超市/卖场，对照hypermarket/supermarket来看，宜家可以说是家居超市而百安居算是卖场
服装卖场、工厂折扣店等，我对这些概念还不是太清晰，只去过 Outlets、上品折扣，只有多逛街才有发言权
动物园这样的批发市场也有相当规模的零售份额，它应该算什么业态呢？
网络卖场，比如淘宝。.. :)

有朋友刚刚从程序员提升到经理，面对这次角色变换他有些困扰，毕竟要自我发展出新的技巧去处理新的问题。我仔细回忆 8 年前我的菜鸟经理起步过程，然后在 MSN 上给他建议：每天一会(daily meeting)

99 年 12 月，我刚刚满 22 岁，没有任何管理经验(准确的说我在 21 岁之前几乎是可以用宅男来形容)，拿现在的眼光看甚至还不能算得上一个好程序员。但受某种野心的驱使，我受命领导 4 名更加没有经验的程序员(大三的学生)去进行一个软件项目——该项目最初的代码是在地球的另外一端进行的，没有面对面的代码交接，只是有那么一点儿文档；雇佣方担心我们经验不够，于是还另外从清华大学找了个靠谱的人每周来一次天津指导我们工作；我、指导者、原始开发者也就是架构设计者仅仅是通过 smth bbs 上的站内信件和消息进行日常沟通。

还要加一个限定条件：除了那四个大三学生，我当时也是 part time 做这份经理工作。怎么看怎么会是一个注定失败的软件项目，但该项目在 2000 年 4 月份上线，这就是 eyou.com；而我们最后成功的形成了一个胶冻团队，"邱哥"的称呼就是从那时候开始的。

那么想想能够值得别人借鉴的经验吧：

* 热情。经验不是问题，能力不是问题，兼职工作也不是问题，是那种迫切希望在某个领域取得成功的欲望支持我克服了许多困难，并给团队其他人增加信心。一开始我没有意识到这点，直到 2001 年初，老板让每个员工用一个英文单词来表达自己，我才从自己身上找到 passion，而不是什么 smart、friendly...之类。无独有偶，伟大的 Joel，还有其他人也是这么认为的。

* daily meeting。由于这个项目的特殊性，使得我必须每天和这四个小伙子开会讨论最新的进度和碰到的问题，而他们也很乐意跟我吃一顿免费的晚饭。团队就是在会议讨论和聚餐中形成的；我也慢慢形成了和下属打交道的风格，并巩固了这种工作上人际交往的自信。

不过也是直到这次有人问起，我才感到 daily meeting 的重要性。尤其是对只专注在一个项目(或者说虽然多个项目但是同一个业务领域)上的团队来说，daily meeting 就更切合实际了——团队所有人都清楚的知道别人在进行什么工作，碰到什么难题以及可能解决的方向。

* daily code review。回忆中最让人惊奇的是，我们居然一直在做 code review，虽然这也是因为项目的特殊性导致的——大家都不在一起工作，而且代码迟迟不能组装到一起，所以我必须一个模块一个模块的检查，当场编译和修改。在这个过程中，不仅仅是我一个人在看那个倒霉家伙的代码，Toshiba 笔记本屏幕旁边还有另外三个脑袋也在研究。

由于 code review，我们的 daily meeting 大大超过了半小时（Scrum 的建议上限），但如果团队规模比较小，每天花一个小时做这项工作是完全没有问题的（假设一个程序员的生产力是 300 行/日，花 10-15 分钟做 review）。

这种每日的团体代码评审可能真的是个好主意：每个程序员每天都要训练如何向大家发表自己的意见；虽然没有 pair programming，但我们很快彼此熟悉代码风格，学习最酷的 shell 和编辑器命令技巧；大家对彼此的工作更加了如指掌；的确可能有人会打哈欠，但注意观察那些对别人的代码也满怀好奇的程序员，他们将会是日后你的好帮手。

写到这里，我决定给我所有的一线经理都申请笔记本，不过好像要等到下半年预算了——搜狐在很多方面都可担得上十佳雇主的称号，但在提高员工生产率方面稍微僵化了一点点。

* 每日集体午餐。如果做不到每日集体代码评审，那这个就是最低要求了。

==========这是华丽的分隔线========

* daily blog。上面的这些为什么我没能早些总结出来？每日三省吾身很重要啊..hehe

Update:
* 更新了一张来自 http://martinfowler.com/articles/itsNotJustStandingUp.html 的照片
* 另外有人说我们的座位都靠在一起，每日例会还需要到会议室去开吗？我的直觉是：需要，一定要有一个正式的会议形式，Same Place, Same Time——而且每天早上 9:00-10:00 有大把空闲的会议室可用。