作者文章: Fenng

《简单法则》不简单

《简单法则》这本书只有 100 多页，一个睡前的阅读时间即可看完。

法则1 是：精简(Reduce) ，原文翻译做”减少”，有些山寨的感觉，当然作者肯定经过斟酌的，我还是觉得”精简”比较好。如无必要，勿增实体。然后的指导方法是：SHE，这不是指那个流行偶像团体，而是指缩小(SHRINK)、隐藏(HIDE)、赋加(EMBODY)。

HIDE

看书的过程中，这是第一处让我产生很深印象的地方。用 Twitter 改版后的界面来说说 “隐藏”:

Simple_Example.png

注意右上角的处理部分。鼠标移动上去才会显示可操作内容(这一点国内的几个模仿者还没有跟进呢)。再去看看 Facebook ，对这一点也有很好的提现。当然，类似的设计不是对所有 Web 站点都适用，必须要考虑用户群的 Web 使用经验。Twitter 是个很容易让人产生信息过载的地方。不过设计者在很多地方都体现了《简单法则》一书中的观点，大道至简，殊途同归吧。

BTW: Twitter 界面上的消息发布时间用斜体字我觉得很不协调。

时间

这一点和很多时间管理的思想是相近的，大部分看我网志的人都知道 GTD 的吧? 只是执行起来的人很少，执行好的人也不多。这一原则相当再一次提醒我们。

信任

为什么在网上会出现 Paypal、支付宝这样的服务? 那是因为人们彼此间的信任程度不够，这样对整个交易的成本也是增加的，事情也自然复杂化。

最后的法则?

远离(Away)，我觉得应该把这一条单独提出来。

写到这里，我发现这本书还是很适合做产品设计的朋友看看的，体会一下其中的思想。不要因为实现某些垃圾功能而把产品设计的那么臃肿，那么难用。

–EOF–

《Web 信息架构》 读后随感

IA.gif这本书也不写书评了，写也写不过小容的这篇《敢问北极熊，路在何方？》，何况小容在信息架构方面已经有比较深入的钻研了。

小容把这本书列为信息架构师必读书之一。我也是因为这个豆列对这本书感兴趣的。之前，什么是信息架构，什么人是信息架构师，还真是不容易搞明白(我曾经接到过的名片中，也没有一个人自称是信息架构师的)。

什么是信息架构呢? 这本书其实也没给一个清晰的定义，似乎有些可意会不可言传的意味。我的理解信息架构做的事情就是组织、梳理总体信息使之达到更可用。如果这样说的话，大一点的面向内容的 Web 站点（比如淘宝）都需要信息架构师的。又比如中大型门户网站，如果缺乏整体的内容梳理、组织，访问用户就不能得到更好的用户信息获取体验，甚至会信息偏差、缺失，对于网站来说，是无形中的损失。

信息架构师，国内有哪家公司有这样的职位么? 应该没有。

这本书也是我认为的 Web 2.0 网站架构不可或缺的图书 之一。当然，CTO 们是最应该看看洗洗脑，问题是，CTO 们都在开会呢，哪有时间看书哇。

附注： 购买《Web 信息架构》请点击。在下一篇，我可能说一下有关时间管理。

–EOF–

浙大招聘见闻 

如果你是Google日历的用户，请订阅这个支付宝2008校园招聘行程表。

今天晚上和公司招聘团队到浙江大学（玉泉校区）进行招聘。

现在的学生基本都不带纸质的简历了，问了几个同学，都说在网上投递了简历。其实随身带着简历还是有用处的，有句话说得好，”机会只给有准备的人”，多和招聘公司的人聊聊，还是会给自己和招聘公司很大机会的。毕竟校园招聘其实是个误差很大的事情。

有些简历其实没有加任何心思。只是简单的罗列了一些课程和自己的知识背景，如果几百封简历放到一起，如何脱颖而出呢? 我倒是抓了点机会和现场的同学聊了一下。写简历其实是有点讲究的。

和学校里的志愿者聊了一会儿，发现现在的学生其实信息挺闭塞的。工作轻松，赚的钱多，是大多数人的不切实际的梦想。

现场效果不错。有个同学问的问题很中规中矩。现在是笔试时间，估计今天要后半夜回家了。明天是现场面试，所以一大早就要起来准备。招聘是个体力活。

浙大的校园无线网络很好，所以上来写几句。对了，在邵逸夫科技馆里还看到了常书鸿的塑像，注意到常先生卒年是 1994 。

–EOF–
补充一些：

我也是今天晚上才看到的笔试题目。怎么说呢…题目应该是内部收集上来的，主观题部分还是有些……虽然考场内空气不是非常好，留下来参加笔试的同学都挺认真，找工作也不容易。

到了阅卷的时候，发现有的人主观题部分其实已经拿到足够多的分数了，而客观题的回答千奇百怪。到这个部分阅卷评分也只好”主观”一些了。

可能是信息不对称的原因，几乎绝大部分人都是奔着开发工程师去的，而关于系统工程师、安全工程师、UED 的投递者非常少，稍微透漏一下，因为投递者太少，导致这几个岗位竞争一点都不激烈。实际上在支付宝这几个岗位的成长性也都是非常棒的。

尤其是 UED 和前端的一些知识，我相信大多数学校教的东西都是很肤浅的，但是，如果平时能多关注网上的一些东西，考卷上体现出来的东西还是很容易让人眼前一亮。只可惜，今天晚上很少让我看到眼前一亮。

我相信考试只是一个手段，是否能完全体现出所有人的能力? 肯定不能。但是几百号人，怎么能做出有效的筛选? 看简历? 误差会更大。可能考试是唯一的过滤办法了。

以上都只是我的个人看法。

最新的招聘活动更新请参考支付志(支付宝官方网志)

–EOF Again–

PHP 中执行排序与 MySQL 中排序

此文首发在 InfoQ 中文站。作者：明灵(dragon) , Fenng . Note：要转载的朋友请注意注明这篇文章的第一作者!
这篇文章是dragon 朋友来邮探讨后他做的一个总结。在 DB 中排序还是在 应用程序中排序是个很有趣的话题，dragon 第一份邮件中其实已经总结的很好了，我添加了一点建议而已。现在放上来，与大家共享。这篇文章也投稿到了 InfoQ 中文站 。

Q：列出在 PHP 中执行排序要优于在 MYSQL 中排序的原因？给一些必须在MYSQL中排序的实例？

A：通常来说，执行效率需要考虑 CPU、内存和硬盘等的负载情况，假定 MYSQL 服务器和 PHP 的服务器都已经按照最适合的方式来配置，那么系统的可伸缩性（Scalability）和用户感知性能（User-perceived Performance）是我们追求的主要目标。在实际运行中，MYSQL 中数据往往以 HASH tables、BTREE 等方式存贮于内存，操作速度很快；同时 INDEX 已经进行了一些预排序；很多应用中，MYSQL 排序是首选。而在应用层（PHP）中排序，也必然在内存中进行，与 MYSQL 相比具有如下优势：

  • 1、 考虑整个网站的可伸缩性和整体性能，在应用层（PHP）中排序明显会降低数据库的负载，从而提升整个网站的扩展能力。而数据库的排序，实际上成本是非常高的，消耗内存、CPU，如果并发的排序很多，DB 很容易到瓶颈。
  • 2、 如果在应用层(PHP)和MYSQL之间还存在数据中间层，合理利用，PHP会有更好的收益。
  • 3、 PHP在内存中的数据结构专门针对具体应用来设计，比数据库更为简洁、高效；
  • 4、 PHP不用考虑数据灾难恢复问题，可以减少这部分的操作损耗；
  • 5、 PHP不存在表的锁定问题；
  • 6、 MYSQL中排序，请求和结果返回还需要通过网络连接来进行，而PHP中排序之后就可以直接返回了，减少了网络IO。

至于执行速度，差异应该不会很大，除非应用设计有问题，造成大量不必要的网络IO。另外，应用层要注意PHP 的 Cache 设置，如果超出会报告内部错误；此时要根据应用做好评估，或者调整Cache。具体选择，将取决于具体的应用。

列出一些 PHP 中执行排序更优的情况：

  • 1、 数据源不在 MYSQL 中，存在硬盘、内存或者来自网络的请求等；
  • 2、 数据存在 MYSQL 中，量不大，而且没有相应的索引，此时把数据取出来用PHP排序更快；
  • 3、 数据源来自于多个 MYSQL 服务器，此时从多个 MYSQL 中取出数据，然后在PHP中排序更快；
  • 4、 除了 MYSQL 之外，存在其他数据源，比如硬盘、内存或者来自网络的请求等，此时不适合把这些数据存入 MYSQL 后再排序；

列出一些必须在 MYSQL 中排序的实例：

  • 1、 MYSQL 中已经存在这个排序的索引；
  • 2、 MYSQL 中数据量较大，而结果集需要其中很小的一个子集；比如 1000000 行数据，取TOP 10；
  • 3、 对于一次排序、多次调用的情况，比如统计聚合的情形，可以提供给不同的服务使用，那么在 MYSQL 中排序是首选的。另外，对于数据深度挖掘，通常做法是在应用层做完排序等复杂操作，把结果存入MYSQL即可，便于多次使用。
  • 4、 不论数据源来自哪里，当数据量大到一定的规模后，由于占用内存/Cache 的关系，不再适合 PHP 中排序了；此时把数据复制、导入或者存在 MYSQL ，并用 INDEX 优化，是优于 PHP 的。不过，用 Java，甚至 C++ 来处理这类操作会更好。 [有些类似大数据集聚合或者汇总的数据，在客户端排序得不偿失。当然，也有用类似搜索引擎的思路来解决类似应用的情况。]

从网站整体考虑，就必须加入人力和成本的考虑。假如网站规模和负载较小，而人力有限（人数和能力都可能有限），此时在应用层（PHP）做排序要做不少开发和调试工作，耗费时间，得不偿失；不如在 DB 中处理，简单快速。对于大规模的网站，电力、服务器的费用很高，在系统架构上精打细算，可以节约大量的费用，是公司持续发展之必要；此时如果能在应用层(PHP) 进行排序并满足业务需求，尽量在应用层进行。

–EOF–