qyb的博客

关于电子邮件

  1. 思科收购 PostPath。这是 Yahoo 收购 oddpost、zimbra 后,我所听说的电子邮件领域又一个重量级的收购(貌似 google 和 ms 也偷偷摸摸的收购不少和邮件相关的厂商)。更重要的是,收购方并不是一个传统意义上的软件/服务提供商。
  2. 最近装了 xobni,一个 outlook 插件。它带给我自 Gmail、plaxo 后,第三次的惊喜——原来邮件还可以发掘这样的应用!另外,如果哪一天有第三方能为 webmail 开发出类似重量级的插件应用,才能表明 webmail 是可以代替客户端的,以这个标准衡量,我们要走的路还很长。
  3. 今天参加了一个 epsilon 赞助的会议。本来不太清楚他们,但从这次的情况看,还是一个挺靠谱的公司,不晓得中国地区的业务能运营的怎么样。如果想做电子邮件直销的话,可以和他们合作试试。
  4. 直到现在,和世界上任何一个人通信,电子邮件仍然是最快速、简易、廉价的解决方案。IM 何时才能做到这一点?我觉得要等到 EMAIL+XMPP 来引爆。

最后,当初几个一起做邮件的同事都不再和邮件有关系了,9年后只剩我还停在这个"板块"... :(

不过从增长潜力看,我觉得这个板块蛮有前途的。:)

走过渐渐熟悉的街头,十年之后。。。

南开数学系94级毕业十周年聚会

聚会时间:中秋节假期(9.13-9.15,根据国家规定调整)

地点:天津

日程安排:
第一天中午1:00报道,之前来的同学自由活动(打牌、聊天叙旧)。
下午1:00 - 2:00,简单午餐。
下午2:00 - 4:00  友谊赛(足球、篮球)

晚上6:00- 晚餐(喝酒)

第二天:
上午9:30 -12:00 与老师座谈
致母校及同学词(选出代表)
给母校、老师送纪念品(给每位老师礼物的价位:300左右 )
请院长及班主任老师讲话
各班代表发言,介绍班上同学大概的10年经历
根据时间安排,自由发言
最后大合唱:南开校歌
中午 12:00- 2:00 与老师一起午餐
下午 2:00 - 3:30 游南开
下午 3:30 - 6:00 小班聚会
老师讲话
自由发言,介绍10年经历
合唱:南开校歌

晚上 6:00- 12:00 晚餐 + 娱乐(卡拉ok、打牌、麻将等)

第三天:返程

准备工作:

1、收集签名定做10周年t恤
2、统计通信地址及联系电话,落实是否参加、并汇总制作通信录
3、确定老师参加人数、会场及食宿安排
4、外地同学需预定返程车票
5、给母校及老师的礼物
6、致母校及同学词
7、各班代表的发言
8、联系摄像的准备工作,后期摄像、照相、光盘编辑制作

9、设立账户,参加的同学开始汇款

费用:
1、路费自理
2、礼品费用
3、餐费
4、其他娱乐费用
5、t恤制作费用

6、摄像费用,后期制作费用

预算:在聚会人数超过40人情况下,按人均400元以上预算。

Topic: 生活

Gears 0.4!!

自从 gears 0.3 发布的时候宣称下一版本将会有 Blob() 支持的时候,我就在一直等着 0.4 的到来,还为此特意加入了它的 google group。

现在,无需自己编写浏览器插件,就可以利用 gears 方便的实现 web 的文件断点上传了(我今天已经写了一个小例子验证)。甚至 gears 还拟定了一个 ResumableHttp Upload 的协议规范

如果没有许可协议的限制,以后我们就会鼓励用户下载 gears 来上传大附件了。

现在发现 Gears 的目标是给浏览器打 patch,让老古董们能跟得上 HTML5 的进展。以前觉得它只是一个 offline 应用的框架,理解还是狭隘了。

Topic: 技术

现在实施的技术交流会

小熊留言问到 screen 是不是窦窦同学的报告,这里说一下我们现在的技术交流会形式:

定期指定一个技术课题交给某人做研究,大概三周后把其研究结果给所有技术人员做报告。

1. 这个技术课题是未来工作中可能会应用,但现在大部分同事还没有接触过的领域

2. 该流程的目的是开拓大家的技术知识面,所以研究工作会交给本来对该方面不太熟悉的人进行——虽然 screen 这个软件窦窦很早以前就用过,但这个做报告的同学是对 screen 一无所知的

3. 该流程的另外一个目的是给每个人上台做演示的机会。增强各个小组之间的交流

4. 三周时间准备是不是有些太短?从研究的角度来看,是有点短;但另一方面这样每个季度也就不过4次集体交流,我觉得周期不能再长了。所以我们不会选太高深的课题。另外,该研究完全可以在上班时间来进行,这是工作任务的一部分。

4. 三周时间是不是有些长?因为在第二周会首先试讲一下,听众是他的leader和我。我们会指出一些问题,帮助他下一次能在众人面前做更好的表演

5. 技术课题是谁提出的?现在还是由我来提出,希望以后这个事情可以交由邮件中心技术委员会来讨论决定。

6. 该活动我们已经进行了两次。第一次是 mysql-proxy,第二次是 screen,下一次是 javascript 混淆工具

7. 上面提到的"邮件中心技术委员会"是个什么机构?我们是一个很官僚的部门,因此成立这个委员会展示我们的行政作风。

hehe,大型 E-Mail 系统是一个涉及面很广的项目,在 N 个方面都需要有技术专家来支撑,需要有一个核心团队来推动提升部门的技术能力

Topic: 技术

深入浅出 screen

这周的内部技术交流会,是一个同事介绍 screen 的使用。俺一时嘴痒,就从怀旧开始,给大家从终端开始发散:

十年前,刚接触 UNIX 主机的时候,机房里的终端已经基本不再使用了。但调试维护路由器交换机总偶尔会碰上忘带串口线或者针头不匹配,前辈就从一堆老终端里翻出台合用的代替。第一次看见别人用终端印象非常深刻——总算知道windows那个“超级终端”,或者 telnet.exe 里的 vt100 对应的实物是什么了。

从形态上,terminal 和 console 是一致的,就是输入设备和输出设备的组合。它自己没有计算能力,任务在主机上执行。

在终端键盘上敲一个字符,比如 'a',首先把 'a' 送到主机上,主机再把这个 'a' 回显(echo),然后我们才能在终端屏幕上看到这个 'a'。和在编辑器里输入并看到一个 'a' 相比,是完全不一样的概念。

最近几年入行的新人是不太可能有机会亲手摸一下终端了(可在 google 上图片搜索 vt100 或 vt220 过过眼瘾)。但如果安装过 Linux 操作系统,它的文本控制台(console)可以很好的帮助理解 screen。

A. Linux 控制台,缺省有 6 个虚拟终端,我们可用 Alt-F1/F6 来依次切换;在 screen 里就可以这么干。

B. Linux 控制台的某虚拟终端上,登录进去,然后拔掉键盘,拔掉显示器,再把它们插上,你会发现刚才登录的状态还保持在;screen 也是这样的——在不可靠的网络环境下想长时间的在终端前台执行某程序,screen 就是必须的工具了。

C. 最后,刚才拔掉键盘显示器,再插回去的动作,用英文怎么说?不就是 detach 和 attach 么

在该同事演示的过程中,screen -x 命令效果是最让人震撼的。我开玩笑说,以后大家都必须在 screen 里工作,这样我就可以做一个真正的监工了。昨晚回家骑车的路上想,这就是远程 PP 啊!如果不得不在不同地点办公,同时又想执行结对编程的团队,是可以考虑利用这个功能来结对的。 只是不知道 X Terminal或远程桌面是否也能实现这样完整共享设备的特性

UPDATE: 有人指出 Eclipse 有一个叫 DocShare 的插件;我看了看,觉得还是不像真正的 PP 那样两人共享一个终端的感觉。
想象一下,甲和乙在地球的两端,开着 screen-x,头戴耳机通过skype通话。
甲:(疯狂击键ing)
乙:停一下,你这里好像忽略了一个情况
甲:(stop typing)..好的,你来吧...(然后看着编辑器光标向上移动了两行,增加了一个判断)
乙:现在好了
甲:我想想,你为什么这样处理...(恍然大悟)...没错没错...不过最好这里再加一个注释.
乙:下面你接着来
.......
纯属 YY

Topic: 技术

Why Python?


去年10月份,我做了一个决定——用 python 来构建搜狐的新一代WebMail系统,替代以前的 java 代码。不得不说这相当冒险,但不管怎么样,它现在运行的还不错,从程序的角度来看,好像代码前途还挺光明。据我自己估计,论部署规模/管理的数据容量/每日登录用户数,在国内 python 开发的网站里,应该是排名第一。 :)

在进入搜狐之前,我的 python 经验十分有限。就是会做做 base64.decodestring;学习 pymsnt 的时候接触了一下 twisted;以及,也是比较搞笑的一点,我用 python 最熟的地方居然是 windows 下的开发——访问注册表,用wxPython写界面,用ctypes访问DLL...

搜狐邮件中心开发以前是分成两个小组,一拨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

Topic: 商业 技术

64-bits 是王道啊

由于奥运流量大涨,搜狐原来的pv统计程序有点力不从心,这两天用 python 重写了这部分的代码。

恶心的是每日汇总,本来信心满满,但很快发现数据量太大了,内存瓶颈很难绕过去。除了尽力在3G可用内存里辗转腾挪外,还顺便看了看 Python 的 dict 实现,把它的 dictionary load radio 上限从 2/3 改成了 32/33,可还是不够用。不用那么多内存,改用磁盘对换也成,但性能这样就会很糟。

低性能版本运行了几个小时后,实在受不了,就找人要了一台16G内存,64位的服务器。

结果耗了10G内存,6分钟运算完毕(利用 marshal 保存的每小时统计结果)

Topic: 技术

有梦想谁都了不起

在电视上断断续续看过几次《北京欢迎你》的mv,今天第一次听了完整版。觉得比《油&米》好听。

而且发现原来还是林夕填词,没想到他主旋律+国语还写得那么好

为什么卡拉OK的分类没有"作曲","填词"?hehe,可以唱林夕唱个昏天黑地

Topic: 音乐

firefox 上 <script> 要支持 defer 了...

看到最近的 trunk build 里面包括

Fixed: 28293 - Add support for the "defer" attribute on <script>.

我觉得这还算一个挺重要的特性

不过这个特性就有点变态了:Fixed: 113934 - Drag & Drop tabs between browser windows.

真有人会在两个窗口之间拖拽 Tab 吗?好比 Linux 在几个虚拟 Desktop 之间拖拽窗口那样...

Topic: 技术
订阅 RSS - qyb的博客