qyb的博客

习惯了 mysql 的转义函数，在开发 PyMobileSync 的时候碰到了问题。最后在一篇中文blog里面发现了方案——表示成两个单引号来转义，相应的别的字符就不用转义了..

另：Python 2.5 final 正式发布了！

从 Techweb 上看到的新闻：facebook 起诉faceben，说的是哈佛的华人学生做了一个类似 facebook 的网站，叫"face本"，让 facebook 十分不爽——由于faceben和Facebook在发音和文字上都十分相似，很可能导致他人以为faceben是Facebook在中国的分站。 Facebook认为，这对Facebook会造成许多伤害。

起诉这个事情其实无所谓，关键是这里面凸显出 Facebook 对中国市场的态度。我特地去 Facebook 查了一下，现在它已经支持数所中国大学的注册了。

当然现在就说威胁还差的很远很远，即使是 Yahoo 和 Google 在中国本土市场做的也相当的弱智，更别提还非常幼稚的 Facebook 了。随便一想就面临三大困境：
1. 邮件地址注册障碍
2. 本地化障碍
3. CERNET 流量收费政策和速度的障碍

但人家的优势是：可以和西方帅哥美女交友啊，去学校网络中心弄个邮箱花不了多少钱，以后只需要克服时差的困扰就可以在网吧里面泡哈佛的MM了，就算是我现在也觉得动心... :)

今天突然想到，类 Facebook 网站的压力是很大的，因为每年老用户都必然会流失（好比腾讯），每个新学年开始要考虑怎么做新增用户，有点象农业靠天吃饭的意思。所以 Facebook 要想法去做高中，做社区，做公司，做全球业务。中国的同类公司们，你们做好了应付这么复杂多变竞争激烈的环境的准备了么？

最后，建议再看看鄙人写的 I18N 和 L10N，面对国际化竞争，没有人能幸免。

最近碰到了三件事情，它们都指向同一个话题...

首先是和老冒gtalk，他向我抱怨他先后培训四个研发经理的失败经历：
- 第一个盗走了源代码搞起了仿冒产品
- 第二个被竞争对手挖走
- 第三个遇到些困难，最早离职了
- 第四个是老好人，自己累死，别人幸福死

其次是："The Hardest Lessons for Startups to Learn"：
It seems to me the only limit would be the number of people who want to work that hard.

最后是叶忻：
他用装修工人打比方（当然他立刻提出他完全没有侮辱这个群体的意思，这个态度我很欣赏），说恨不得用鞭子驱赶才能工作

现在我指出我的想法：一个公司能发展到多大，做成多大的事业，取决优质的中层经理的数量

这里优质的经理的意思是，他能驱动他手下的人发挥出 80% 的能力。老冒后来也总结说：世界是少数人推动的，也就是领袖和中层们

优质的经理首先要有极强的追求自我价值实现的内驱力，然后就是要有坚韧不拔的意志，还得认同组织（或者领袖）的价值取向，其它的技巧和经验都是后天可以学习和完善的。

为什么现在感觉这样的人很难找？老冒说：中国普遍缺乏做好中层的心态，也缺乏足够多中层成功的故事；从小的教育也夸大了领袖和群众的力量。老冒也半开玩笑的反省：归根结底是我自己不会带人

另外我觉得一个关键还是在很多企业对中层的价值认识还不够深刻，假设一个经理管3个员工，缺省状态下3个员工只能发挥 50% 的能力(其实可能更糟，听说过三个和尚的故事吗？)，而这名经理让他们都发挥出了 80%，那么这个经理的管理绩效奖金是不是应该相当于两个员工的收入呢？（3*80% ≈ 5*50%），实际上有多少公司能做到这点？要知道他替老板节省的不仅仅是人力成本，还大大提高了运营的效率——速度，这个在当今的竞争中越来越显得重要。（微软似乎只要有3个程序员以上的团队就一定会设置一个项目经理的角色）

回到本文的题目：你数数公司里有多少算是我所说的优质经理的，把他们的数目乘以7，你公司有这么多人就足够了，再多只会让事情变糟...当然现在对你来说可能幸运的是，竞争对手的情况比你更差劲。

我们老板总说，叶忻可算是"中国CTO第一人"。这个称呼怎么来的不去细究，但先后在搜狐、中关村科技、掌上灵通担任 CTO 之职，可见确有独特之处。

其实仔细回想，今天的会议里叶忻并没有什么特别出彩的地方，就是一个观点和我不谋而合——"一堆程序员捆在一起封闭开发没有好结果"。自己的想法能亲耳听到一个牛人也同意，小小得意一下。另外就是他非常强调开发人员(其实包括任何工种)的责任感和自主能力，具体技术反而没有怎么说。和新浪李嵩波相比是两种完全不同类型的人，不过他们俩我都很喜欢。

叶忻说：百度的发展途径很好，非常稳健，不要急于扩张。

还提到：cisco 购并公司后，能把原来公司的领导留下来继续做老大，但 CA 合并公司后人事动荡就很厉害。所以 cisco 做的好。

回头搜索了一下叶忻的资料，发现多年前的一篇专栏《程序员》：直面CTO，里面的一些观点还是挺有趣的，推荐阅读

另外，叶忻说起他的女儿现在高二，每天泡 myspace，立刻让我想起了以前看到的麦田的文章..看来 myspace 就是美国的 QQ 啊..怪不得火

知道李嵩波这个名字是因为他去年替换严援朝成为新浪的 CTO，当时以为是一位海龟，特地搜索一下，没想到是新浪的老臣子。辛苦近十年，终于修成正果走上台面。

周一去新浪，在别人的介绍下就网站的研发和运营维护去请教，双方进行了热烈友好而又卓有成效的会谈。可能是担心自己并不是在第一线工作，李嵩波特地找了一位新浪具体负责运营的同事参与了讨论，但实际上这位发言的机会很少，绝大部分的技术细节李嵩波都很清楚，这着实让我有些吃惊，可以看出虽然他在比较高的位置上，但还是掌握的东西还是很细致全面，这里小小的表示佩服一下。

不过李嵩波应该是更偏重于运营，所以我这里的佩服也是有限度的——比如网易的云风我是真正佩服的。从李嵩波顶替严援朝开始，就能看出新浪把技术的重心更多放到了运营而不是产品开发上。另一方面，那批老同志其实也早就在互联网里面落伍了。

会议室据说就在黄冬附近，但他重感冒，没有见到，有些遗憾。

附：最近见到另外两个技术总监级的人物，一个公司吵吵嚷嚷计划上市，另一个是 Web2.0 后起之秀貌似很有前途，和他们接触以后让我感觉如果我去找个 CTO 干干似乎还是很可以很安全的混下去的，哈哈..

背景：原文作者就是那个把贝叶斯反垃圾邮件宣传到全世界的人，前 Lisp 程序员，现在领导着一个投资公司。原文很长，只好就要点意译，而且打乱了原来的次序重新编排

创业最大的三个威胁：内部思想不统一、惰性、忽略用户，其中最为恶劣的是忽略用户
这里有一份给处于困境中的创业公司的千金药方：创业者们一起研讨那些会让每个用户都喜爱的点子，然后立即去做

向访问者清晰的阐述你的网站是什么，并且积极向他展示
创业公司需要只用一两句话就可以描述出它正在做的业务，除了用户，还需要向投资人、购并方、合作伙伴、分析家、雇员以及潜在雇员...
如果你有什么让人印象深刻的东西，那么把它放到主页上让更多的人看到它

及早发布
尽可能早发布你的应用，然后根据用户的反馈进行改进...
或许及早发布的最重要之处在于，它会驱动你更辛苦的工作

不断进步
如果不持续改进，那么及早发布就成为了笑话...
还记得 Gmail 的横空出世么？在任何看似已成定式的领域都有无穷完善的可能

总会有更多的空间
现在已经有了 Google、Yahoo、MSN，还有无数同样的创业公司，看似每个领域都很拥挤了，果真如此么？其实在任何时候都可以做任何东西，唯一的限制在是否有足够多愿意辛苦工作的人。

不要让希望飘的太高("Don't get your hopes up")
当有人说"我要投资你"或者"我要购买你"，希望"don't get your hopes up"这句话会自动出现在你脑海里。继续去运作你的业务，当这件事从来没有发生过...
创业公司应该把目标专注在取悦更多用户，然后尽快的向这个目标前进，不论前进道路两旁的投资者和买家怎样在你眼前挥动钞票

信义(这一节里面有两个概念：commitment 和 determination，姑且翻译为"信义")
让所有人(包括投资者)都信服你的方法只有一条：就是让他们感觉你已经准备坚持到最后一刻。

燃烧生命(没有按字面来翻译"Speed, not Money"，这一部分是全文的精华)
经济学上看，创业公司存在的理由并不是因为它会让人富有，而是因为它驱动某项使命得以更快完成...
创业公司最重要的就是速度...
把无趣但又是必须的任务压缩在尽可能短的时间里面完成，这是对生命的尊重，也是生命本身的光辉

本来写了一个 Python 2.4.x 的 patch，让 Python 可以 native 支持 IrDA socket。但是 Python 的维护者告诉我 Python 2.5 早就 freeze，除非 bugfix 否则不考虑接受新的 feature。因此就做了一个 Python 扩展，至于维护人员认可会这个 patch 并加入到 2.6 里面去就看我的努力吧。

扩展大约一周前就做好，在邮件列表上发布了，但是无人响应，似乎是 Python-CN 的用户有红外设备的不多。所以还是在 Blog 上贴出来：如果你希望用脚本语言对红外设备（手机、PALM、PDA）通信编程，请考虑我的这个扩展。

扩展这部分的代码大部分是修改 Python 的 socket 模块的，所以 License 当然也是 Python 的。

代码 checkout 地址：
http://pymobilesync.googlecode.com/svn/trunk/irdasocket/

预编译好的 Py2.4 for Win32 的包下载：
http://www.dup2.org/files/irda-0.1.win32-py2.4.exe

该 win32 版本是在 Visual C++ Toolkit 2003 + .NET SDK 1.1 + Windows Platform SDK 环境编译。感谢Compiling Python 2.4 extensions with Microsoft VC Toolkit 2003这篇文章教我们如何让 distutils 和这些免费工具一起工作。

下面是测试代码：

为了防止有读者只订阅我的 blog，而没有订阅我和我弟的合集，所以这里重复发一遍《推出“DUP2推荐软件”》。

虽然踏入互联网服务业有 8 年了，但这才是首次独立以个人的力量推出一项互联网服务。在断断续续筹备了 2 个多月后，终于可以说我也是"个人站长"了。

目标服务对象：喜欢自由软件，而且对软件许可很在意的朋友们。

在以下情景中请考虑使用这项服务：
* 给亲戚朋友装机的时候
* 在公司 IT 部门预制 Ghost 镜像的时候
* 当您需要某项软件，在使用华军、天空... baidu、google 之前

如果您认可这项服务，请帮助我们推广它。

最后，如果您觉得本项服务中应该增加某个软件，请和我们联系。但是这里有一条原则：软件必须是我们所亲身使用过的，而且确实感到非常有帮助的软件。当然，我们也欢迎任何人成为该项服务的正式维护者。

前不久从老板那里学习到这么一个 phrase 的发音，"[dju:] [di:]"。大意是投资方在对目标进行投资之前，需要走一道程序来考察公司的运营、资产负债状况。对于高科技公司而言，主要的资产可能是知识产权、人力资源，所以甚至会出现投资方到目标公司里观察办公流程，挨个同核心员工聊天的事情。

虽然我能很熟练的吐出"[dju:] [di:]"这个发音，但对于"[di:]"究竟代表什么单词却一直没有任何概念(due这个单词倒是能猜出来)。更为搞笑的是有次当我在对话中引用这个短语后，另外那人仿佛赞同似的说了一句"[di:] [di:]"，然后我们双方互相疑惑的对视，各自揣摩洋泾浜水平有没有在这次交锋中落于下风。

今天终于在最近展开的英文学习过程中读到了这个短语——"Due Diligence"。下回如果有人敢在我面前说 "D-D"，我一定用 "Due Diligence" 杀他个溃不成军。^_^

附：我老板来自波士顿，那个说"D-D"的家伙可能发音来源于硅谷，现在相当怀疑东部西部有不同习惯的缩略发音。

从 Oversized/Undersized explanations - Doom9's Forum 翻译而来

XviD 论坛有一个问题被反复提出：压缩后的文件大小和和指定的大不相同。本文试图解释文件大小不一致的原因，并指出解决之道。

让我们从基础知识开始，要知道弄明白问题发生的根源后就离解决它很近了。

基础知识

1. 量化
XviD 属于有损压缩，即它会把一些认为无用的画面细节忽略掉。每一帧画面会指定一个 quantizer (中文翻译为"量化因子")，然后据此进行压缩。
那么：
量化因子为 1("Q1") 意味着最高质量的图象和最大的文件(高码流)
量化因子为 31("Q31") 意味着最低质量的图象和最小的文件(低码流)

我们的目标是尽可能高的质量，以及尽可能低的码流...
=> 通常不用 Q1 做压缩，因为码流太高了(如果要备份 DVD，还不如保留原始的 MPEG-2 流)
Q2 则能得到很好质量的图像，而且比 Q1 来要小很多(quality/bitrate并不是线型的)。MPEG-4 被设计为低码流应用(相比较 MPEG-2 而言)，我们可以假定对于 XviD 压缩来说，Q2 就是最高质量的压缩了。

2. 文件大小
相同的量化因子前提下，不同的视频源压缩后的大小也是不一样的。有的容易压缩，而高分辨率、大量细节、快速动作、明暗变化大的电影则很难压缩。

3. two-pass 压缩(或写成 2-pass)
为了在指定文件大小的情况下得到最大的质量，XviD 提供了 two-pass 处理模式。
- 首先固定量化因子为 2 压缩一遍，产生一组参考数据(stat 文件)
- 根据参考数据进行二次压缩，编码器不断调整码流来优化整体质量

那么就产生了三种情况：
● 1st pass 得到的文件比预料的大，在 2nd pass 压缩中编码器就不得不采取更高的量化因子
● 1st pass 得到的文件比预料的小，那么 2nd pass 中编码器就会在某些帧用 Q1 进行压缩
● 1st pass 得到的文件和预料的一模一样...当然从统计学上来说这是不可能发生的，而且这种情况下我们也不用再继续讨论了

现在问题发生了

有的视频太容易被压缩了(或者说 1st pass 得到的文件比指定的要小很多)，于是过多的 Q1 帧被产生，但这会扰乱编码器的码流控制系统，最后就得到了一个 oversized 结果。

oversize的解决方案

1. overflow treatment 设置的调整
该设置被用于在 2nd pass 压缩中，设定码流控制进行调整的强度。取值越大，越能有效平衡 Q1 帧。
那么我的建议值是：
("Encoding type" > Two-pass - 2nd pass > "more...")
- overflow control strength: try 10 or 20
- Max overflow improvement: try 10 or 20
- Min overflow degradation: try 10 or 20

2. Quantizer capping
很简单，就是避免 XviD 用 Q1 压缩。
把每种帧类型[I/P/B]的最小量化因子都设成 2 (最大值还是保留 31)
1.1.0-final 之前是
("Advanced option" > Quantization)，
从它以后是
("Quality preset" > Userdefined > "more..." > Quantization)
这样就不再会得到一个超大文件了。但...这种方式也导致根本不再有提高质量以得到预期码流的余地了。

除了上述两种编码器相关的解决方案，其实还有更好的思路：我们的目的是填充剩余的空间，那么就可以用更高的分辨率，更高的音频质量，更高质量的定制矩阵...等等

undersize的解决方案
从上面说的去举一反三吧...

如何提前预料到文件大小无法控制呢？
上面已经提到，1st pass 将产生一个日志文件，里面就包括 Q2 压缩结果的大小。那么如果这个数字和你预期的相差非常远，就很可能发生该问题了。

怎么看到 "size" 信息呢？
用 StatReader 打开该日志文件就可以看到了。该程序被包含在 official release 里面(比如 Koepi build)