March 2008 Archives

【现在是广告时间】应朋友之托，代为发布两则招聘信息。都是 PHP 开发工程师，招聘地点为杭州、上海，两家不同的公司。感兴趣的朋友请根据合适的地点选择吧。

杭州招聘信息

招聘职位： PHP网站开发工程师
工作地点： 杭州市
招聘人数： 3
工作年限： 二年以上

职位描述

岗位职责：

1、有PHP/MYSQL/Apache/Linux开发经验，具有良好的编程风格；
2、熟练使用Javascript，CSS，SQL；
3、逻辑思维能力强，做事有条理性，有较强的分析问题和解决问题的能力；
4、强烈的责任心，良好的沟通能力，良好的团队合作精神，对工作有激情；
5、有开发过大中型互联网站经验者优先；
6、熟悉 Web 2.0

资历要求：

1、计算机相关学历或有相关的工作经验；
2、对软件开发工作有富有热情，工作责任心强，富于团队精神和敬业精神；
3、良好的执行能力，较好的完成预定任务；
4、具有良好的自学能力和独立解决问题的能力；
5、正直，坦诚，实事求是；
6、有项目管理经验者优先。

电子邮箱： [email protected] (请注明 refer 自 dbanotes.net )

上海招聘信息

这是 BlogBus 的招聘信息。请参考 CTO 车东 的招聘要求 , 这个职位是"欢迎毕业生"的。

南京招聘信息

1. 旅游电子商务网站的开发
2. B/S架构的旅游业务系统的开发
3. 其他应用软件的开发

职位要求：

熟悉WEB开发流程，有丰富的 PHP/MYSQL/Apache/Linux 平台开发经验；
拥有优秀的数据库设计能力；
熟悉 Linux 平台下的系统配置者优先；
学习能力强，拥有优秀的逻辑思维能力；
自我管理能力强，有良好的时间意识；有较好的沟通交流能力

这是 途牛旅游网的 招聘信息。有意者请邮件发送至 david.chenfuwei AT gmail.com

希望对正在找工作的 PHPer 朋友有用...

--EOF--

今天在无聊的售前演示中看完了一篇技术文档 All About Oracle's In-Memory Undo，关于 Oracle 的 In-Memory Undo (IMU)，记得几年前讨论过，大部分基于猜测，这算是看到的第一篇比较细致的东西。

Oracle 公司在 10g 推出 IMU 这个特性（已经申请了专利）。Undo 作为最重要的组成部分之一，其高效与否直接关系到整个 DB 的能力。Undo 旧有的基于 Block 的段(Segment，指存储层的概念)管理模式方式，UNDO 本身的变化要记录到 Redo Log Buffer 里，而 IMU 避免了这个操作(因为是内存而不是存储)，从而减小了生成的 Redo 量。

另外，因为读一致性开销直接到了内存里而不再依赖存储段, 整体也大大降低，CPU 的负荷也会有效降低。其应用模式应该说是适合一致读的需求量比较大的 OLTP。

Oracle 10g 默认是使用 IMU 这个特性的。通过隐含参数 _in_memory_undo 可以关闭这个特性。因为是隐含参数，也侧面反映出该特性并非那么成熟。搜索一下 Metalink，有不少关于 IMU 的 Bug，而 UNOD 的 Bug 一旦遇到，不停 DB 恐怕都很难解决。所以，对于可用性要求比较高的系统，现在起用该特性还是需要三思。

附: 全部机制在专利全文里。谁有兴趣仔细读一下吧.

--EOF--

这一期的《收获》上有篇小说叫做《天上人间》，故事的主人公是两位混在北京办证的年轻人。或许你比较痛恨满大街的"办证"牛皮癣广告。可一旦你有在北京办理证件的体会，就会明白那些办证的存在是多么的合理。

周一一大早，我第一站先到海淀人才中心，准备借出我的户口卡。借这个东西先要存档单位开介绍信(如果是个人存档倒是不用的)。尽管这次遇到的大婶态度没有去年的小姑娘好，但是咱已经吸取了去年的教训，打电话给上一家公司的同事给我发一份传真过来。然后跑到楼下收传真，等了花儿也谢了总算等来了。就这样，终于借到了我的户口卡。首战告捷。

第二站，海淀派出所。先是取我一年前办理的二代身份证。上次托同事帮我取，告知集体户口必须要本人来拿，一拖拖到了现在。然后问能给开一份户籍证明否，一位刀条脸的民警大婶用北京口音儿不耐烦的说 "户籍证明？什么户籍证明？我们这儿根本就不开这东西。给你盖什么章啊？"，陪着笑脸解释，我要做什么事情，这个事情在杭州必须用到咱派出所的这个证明..."，虽然 "这儿根本就不开这东西", 刀条脸大婶还是很不耐烦地在电脑上打印出来一张单据，盖上了宝贵无比的大印。看着手起章落，总算长出了一口气。

在派出所看到的另外一件事情是，另一位民警大婶在接电话，"单身证明？我们这里开不了这个，谁知道你是否单身啊？让你单位开去，你单位开不了？那我不管"，挂了电话还说呢，"他爹妈都证明不了他单身，谁给证明啊？"

出得派出所大门，已经快中午了。吃过饭休息了一会儿，起来杀向出入境管理中心准备办理护照。

之前在网上已经查询如何办理护照的流程。也问了同学是否有需要注意的地方。到了现场还是让我懵了一下。拍照的时候被告知，现在我这种情况需要到下面各个分局办理。这次来北京，时间是按照小时为单位计划的。如果再跑到分局，这一下午其他事情就搞不了。看看旁边有值班领导，赶紧去说明情况，"我户口在京，偶尔才能回北京来一次，晚上的飞机，再去分局可能来不及了..."，迫不得已，撒个谎。这位值班领导要过我的证件看了半天，总算"批复"，心里这个侥幸啊。

递交申请后，准备交钱。把回执递过去，人家扫了一眼说，等到下个月 2 号才能交钱。一口鲜血差点没吐出来，明天我就要回杭州了，难不成再跑一趟? 到旁边的领证服务台问，结论是一样的。感觉这也太荒谬了，换个人问，这个人仔细看了一下回执，"你这个原来不是港澳通行证啊？那可以在楼下办理快递的，你把手续费和快递费在楼下交了就行了"。一边埋怨自己的无知，一边感慨：都是一样的规矩，为啥人家这里就能把你搞晕呢？BTW, 在办证大厅看到了一个人特像丁俊晖。

下一站，匆匆赶往国贸，到一家人力资源提供商那里拿取调档函。穿越了半个北京城。咨询人家这里的专业人力资源人士，原来只调档案还是解决不了我的问题。具体如何解决？谁也不知道。我的问题是什么呢？就是原来的档案是在上一家服务单位投档的，一个疑虑是万一这家公司不存在了，那么我如何再次借用户籍证明呢? 车轱辘话说了半天，还是没折腾明白。给前同事打了个电话，告诉我他的档案已经办成了"个人存档"，这和我在人才中心听到的反馈是相反的。不管怎么说，还是有些思路了。

这一天的感觉就好像走进了迷宫。面对着这台复杂无比的行政机器，除了小心翼翼的尝试，别无它法。任何一个环节，如果顺利，可能你感觉不到什么，可万一出现一点异常，简直找不到北。而这些平时似乎无关紧要的东西，比如户口、档案、介绍信......看似是上个世纪的遗产，一旦挡在某处，你只有栽跟头的份儿。

有的时候看到街边的办证小广告，还真想不如直接一次办全了算了...至少不用受这份儿气

--EOF--

PS. 周二下午，咨询了半天，补交了一大笔存档费用之后，终于拿到了一份个人存档证。

从 798 出来，打电话和北京的几个同学联络晚上聚一下。同学 Xin 携夫人从顺义赶来，等了一会儿，同学 Bei 驾车赶到，在女人街走了一段，大家同意吃蜀地传说。吃到一半, 女同学 Xiu 上完课也杀来了. 当年一个班的在北京的这几个基本齐了.

如果考虑到北京之大，糟糕的交通情况，就会知道同学聚会是一件比较费力的事情。同学聚会, 自然要聊聊这个这个圈子的事情. 我们的专业统一可以算是生物技术, 现在同学中快有一半是博士(我开玩笑说毕业早的可都能带研究生了). 另一半大部分也都是硕士, 剩下的几个本科, 可以算寥寥可数. 这次居然有三个本科男，不容易。

临毕业的时候，我还以为同寝室的几个兄弟很快都能出国呢(用 Bei 的话说，"起得早不一定身体好")。这么多年过去，一回首发现也就 Xin 一个有出国的经验--去非洲做了好几年的贸易，有所斩获，回到国内又转回本行(我对非洲的很多鲜活印象都来自小 Xin 的生动描述)；Bei 在专业范围内没干多久，也转身投入 IT 了，现在就职微软，前途大好；同学 Xiu 在读人大的 MPA，用不了多久，在座的就她学历最高了 :) 或许当初毕业的时候，每个人都有自己发展想法，不过到了今天，回头看看，没有什么是一成不变的。

菜还不错，后来才知道，这个店还是个"名人"开的呢。忘了一件事情，小 Xin 说从非洲给我带回来一个小鼓，不知道还有不...

--EOF--

周日，京城各大衙门都不办公。计划好了要带着 Laura 去 798 工厂看看，假装一次小资。外面阳光充足，也非常适合出行。

798 里面，慕名而来的老外、艺术青年、有钱有闲小资一如既往的多。沾了奥运的霉气，798 厂区内的道路都被挖开了，偶尔一股小风吹过，尘土满脸。我以前倒是一个人逛过，这次来基本还是找不到北，新展览层出不穷，个人觉得比较经典的几个场景都看不到了。

从进门开始就看到《占卜者之屋：黄永砯回顾展》的广告牌子，这是唯一的一个收门票的展览，收门票没啥，关键是里面的东西真的没什么意思。那些东西展示"文化撞击"的东西估计老外看了还有兴趣。

看了黄永砯，没劲，顺便对尤伦斯当代艺术中心也比较反感。基本上看不到原来厂房的模样了，有些类似于原木凳子刷了油漆的感觉。

有体育迷么（准确一点说是乔丹迷）？"铸造传奇" 迈克尔·乔丹展览 绝对值得一看，我和 Laura 对乔丹这尊神的确不太感兴趣，也还是进去看了一圈儿。

比较可惜的是没看到吴冠中的新作展。

附：几张照片(大部分都是 Laura 拍的，个别图片俺提供一点创意。还没 PS，光线似乎有问题，拍照这事儿我不懂):

--EOF--

周六下午到的北京。一出机场，顿时感觉北京真是和杭州不一样，天灰蒙蒙的，相比之下，杭州的天空算得上"蓝天"了。与几年前相比，交通还是那个老样子。12 点的飞机，大约 4 点半才赶到预定的汉庭安顿下来。晕机，加上稍微有点冷，一趟下就睡了两个多小时。

起来，网上搜索了一下附近的饭店，在北京工作的时候，有次租房子就在这附近，所以感觉相对比较熟悉(除去那些新拔地而起的高楼)。虽然海底捞据说不错，不过不能多吃火锅了，最后折衷一下，去权金城吃烤肉。回到北京，顿时感觉比南方豪放多了，菜谱都 1 米来长，翻着都有些费劲儿。值得一说的是，点了个"老虎菜"，好几年没吃到这个东北常见菜了。

汉庭的服务应该说是不错的，最大的毛病和如家是一样的--隐私性差很多。走廊有人路过听的清清楚楚，说话都不太敢大声...从 80-20 的原则出发考虑，门的因素很关键。如果装修上能稍微用一点隔音效果更好点的材料，估计就能起到很好的效果。想想这个价位，咱就别挑毛病，知足吧...

--EOF--

现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。

如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。

独立，独立的服务器

无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。

如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。

独立，独立的域名

如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。

前几天有个朋友在线上问我，"一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?" ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉的留言】

雅虎 Web 优化 14 条

关于雅虎 YSlow 工具倡导的 优化 14 条规则，建议每个 Web 维护人员必须倒背如流，当然也应该辩证来看--介绍这 14 条规则的页面本身也只能得到 70 多分...其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

有效利用客户端 Cache

很多网站的 UI 设计人员为了达到某些视觉效果，会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况，研究表明，对于用户粘度比较高的站点， 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的，大量带宽就这么节省下来，费用也节省了下来。顺便说一下，对于验证码这样的东西，要加个简单的规则过滤掉。

服务器端的 Cache

在国内，CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务，国内还没有出现。所以，充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器，缓冲图片效果应该说尚可，新浪技术团队贡献的 Ncache 据评测，效果更佳。

服务器端做Cache的好处是显而易见的，一个数据对象的请求时间会控制在 100ms 以内，否则的话，至少要几百个 ms 甚至更长。

高解析图片问题

如果网站存在大量高解析度的图片，那么有必要考虑部署 IIPImage 或者类似的软件。

运营问题

很多比较有规模的网站对于用户上传的图片不做任何处理，结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)...这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块，对那些"截屏"得来的图片做个转换，投入成本可能远比存储上的开销小，而用户再访问该图片，质量未必能有什么损失，浏览速度无疑好多了。哪种处理方式更让人接受，不言而喻。

--EOF--

图片处理工具的选择

可能大多数网站都是选择 ImageMagick 做为基础库，不过这里也有一篇 GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report，如果图片处理量巨大，性能问题又怎能不考虑?

Lighttpd 的 ModCache 模块非常值得推荐。

Updated: 对于创业团队来说，推荐又拍云服务，用了都说好。

五月杭州，侠客行。第二届网络工程师侠客行大会 即将在 2008 年五月二十四号举行(旧贴日期有误)。

这可能是业界最有可能全部面向技术层次的会议，去年 来了很多业界牛人。相信今年能更加务实一些

希望能拉来更多业界"乐于分享"的技术高手，而不要通过简单的 Google 搜索来判断某人在业界的影响力。

非常值得关注的是 Flickr 的架构师 Cal henderson 今年会来。另外 Terracotta 的 Ari Zilka 的演讲也值得期待。

最新动态请关注 官网地址

豆瓣上该活动的信息

--EOF--

来杭州三年了，三年前，当自己做了那个决定，从没想过究竟能在这个当时看似神秘的公司工作多久。从第一年的有些不适应，到第二年想着"自己的浴室"，第三年，终于有个初步的打算在杭州安家。我想我应该是严格的"漂一代"，在任何一个地方(即使是家里)都找不到什么家的感觉，在杭州更是这样。

一位在业界爬摸滚打多年的多年的前同事曾经跟我说，"在一家公司，最多工作两年，时间太久，技术就老化了，人就混油了"，很庆幸，我还有点学习的劲头。只是，忽然间，我已经成了三年陈了。有人说，在互联网的一年，相当于七个狗年，那么我在这里工作了 "21 个狗年" 了。

或许，多少年以后，自己也能写本关于这段时间内的故事。这辈子未必再有机会经历一次这样的过程，能看到一个互联网应用从小到大，从几百万的交易额到几个亿的交易额...三年里，看到、学到的东西太多了，这是最大的的一笔财富。如何让这笔财富发挥出更大的价值，这是需要考虑的问题...3 年前找工作，有位老大姐说，"寻找那个机会来证明自己"，下句话是告诉我在那之前只有忍耐。

三年了，每天都在担心数据库的问题，担心那悬在头上的达摩克利斯剑会掉下来。或许，从现在开始，期待能够摆脱这个焦虑。所谓面朝大海，春暖花开，别到明天，从现在气，就开始做个幸福的人吧。结婚登记、房子装修、锻炼身体...工作、生活，必需要找到那个平衡点。

拥抱任何变化，适应任何可能的变化.

--EOF--

中午去银行转房子首付款，看到日期的时候注意到是 3 月 13 号，挺巧的，三年前的今天，我来到杭州。

回想起来，挺佩服自己当时光脚不怕穿鞋的那股劲儿。最近一段时间也在为支付宝招聘 DBA ，很多人一考虑到离开现在生活的城市来到杭州，退缩之意就很明显了。

同事发来邮件，要回答几个问题，其中一个问题是"你在阿里巴巴最大的收获是什么?" 回复了这句话: "现在支付宝有超过 6000 万用户，想到这里面有我的一份努力，偷偷自我满足一下：总算为中国电子商务做了点贡献。"

--EOF--

前天终于收到一封邮件：

Domain Registration Transfer COMPLETED for dbanotes.net

在经历过几个月断断续续的折腾之后，这个域名终于 Transfer 到国外。有好几次真忍不住想骂人。整个过程曲折复杂，如果你有耐心看流水帐，我就继续。

第一回合

大约去年 11 月份，域名要到期了，我突然有了要把国内注册的这个域名 Transfer 到国外的念头(原因)。如何 Transfer ，我自己不太清楚的，搜索了一下，大致知道需要先拿到域名的密码(Authcode)，然后还需要当前的注册商解锁。

我这个域名，之前为了省钱，续费的时候是转到了代理商下面的。于是联系了代理商，代理商告诉我"寄资料给注册商索取转移密码"，然后我联系注册商，注册商告诉我域名要到期了是不能 Transfer 走的，必须先续费，确保不欠费了才可以。

联系代理商，续费。接着打电话给注册商，他们告诉我到什么地方下载表格(传真件还不可以，必须是手写的原件)，然后告诉我必须要代理商盖章才可以。再联系代理商，再次告诉我不需要盖代理的公章。我被打败，第一回合结束。

第二回合

我这个人有个毛病，越惹我恶心的事情，我越要搞定它。忙过了几天之后，又想起来这事情。再次联系代理商，一听我要转走，根本都不愿意理我。我说要不你把"域名转到非代理管理"的状态下吧，这样我就不需要你的公章了。过了一会儿，代理商告诉我，"解锁了，以后不要再来烦我了"(原来代理商下面还有一道锁的)。

打电话给注册商，告诉我现在"还在代理商管理"下，吐啊吐，我说那边都给我解锁了啊，"那你在我们的网站有账户么? 你需要用账户把这个域名管理起来，也就是'转进来'--要多交一年的注册费用..." 吐，多续费一年...100 多人民币又花出去了.

第三回合

几天后，我继续折腾。这次你总要让我转移了吧? 下载并填写好了相关表格，快递过去，接着打电话问注册商。告诉我"你是刚续费的，至少要等 45 天才可以转移的"，我怒之，你大爷的，你这是 Catch 22 啊? 注册商客服象弹簧，你弱他就强，你强他自然就软了。告诉我"要写个免责声明, 这段时间如果转移出问题，责任自负"。我写...注册商大爷，你就给我密码吧！

第四回合

话说，终于拿到了域名密码。喜不自胜，心说这下子总算可以转移了，时光如水，岁月如梭啊，不知不觉就快到春节了。赶在春节前在 Dreamhost 上填好了 Transfer 申请，几天后终于收到了 Dreamhost 发来的邮件：

Domain registration transfer for dbanotes.net has been rejected by your current registrar!

这个气啊, 发邮件问注册商客服，到底咋回事? 那边信誓旦旦的说 "已经给你解锁了呀,重新试试看", 我重新试试看，眼看着雪灾日益严重，我终于把这个事情暂时忘了。年都过完了，又一次失败。如是者多次，我只能认为是我 RPWT 了。期间用我的洋汀浜英文与 Dreamhost 客服沟通了几次，不赘述。

第五回合

放假归来，再发邮件问，给我回复说，密码和域名状态都是对的。"那为什么总被拒绝呢? 这很明显就是你们不让我转出嘛！" ，你强它就弱，这真是真理。再次尝试，终于(不拒绝了)，终于，终于，收到了转移成功的确认邮件。

--EOF--

最近一次域名转移的经历实在把我恶心透了。如果有可能，千万不要再在国内注册域名了。

1) 费用贵！ 在国内注册一个域名起码要 100 多 RMB，国外很多注册商都不超过 10 美元，现在人民币升值，美元贬值呢，而且大多都有折扣代码，还要更便宜。国内如果通过代理走，有的时候是能便宜一点的。但是有后顾之忧--我在后面会写出来. 有得朋友因为没有信用卡而不能境外支付，那就办理一个好啦，现在信用卡发放就和卖白菜差不多。

2) 服务差 先是技术服务差，对比一下国外的域名服务，国内的限制非常多。管理面板里的功能少的可怜。其次是售后服务差，经常在规则里下拌儿。很多域名注册商都没有正规的呼叫中心，电话经常打不通，打通了等半天，好不容易和人接上话后，敷衍你几句了事。

3) 不安全 去年国内的几个域名注册商就出过好几次技术故障，还有些朋友时不时的域名被劫持一下。另外，国内的"非理性"因素太多，说不上什么时候你的域名可能被强制停掉也说不定。

虽然之前，我曾经推荐过几位朋友在国内注册算了，"省事"，现在看起来，我错了。

--EOF--

这两天 Firefox 突然变态，时不时的占用接近 50% CPU 资源，带来的现象是系统应用程序响应极慢。开始还以为是个别页面带来的问题，后来发现原来是普遍现象。这类问题开始不好求助于 Google ，说实话，不知道用啥作关键字搜索。

忍无可忍，赶紧调用 Process Explorer ，发现单个 PID 占用大量的 CPU 上下文交换资源，如图：

看了一下，不知道 "jpeg_free_large" 是干啥的，遂用 "Firefox jpeg_free_large" Google 一下，出来的一堆东西里有帖子说可能和 Apple 的 QuickTime 插件有关。我也不知道如何删除该插件，到 Firefox 安装目录下的 Plugins 里看了一下，还真有一堆文件是 QuickTime 相关的插件，版本号不同而有不同的文件。

删掉。重启动 Firefox ，OK。

这个问题估计对于使用了 iPhone 的用户比较容易中招。

--EOF--

虽然奋斗多年，依然是无产者一个。最近据说杭州的房价在飈涨之后终于有点一点点回落，也感觉总不买也不是那么回事(如果全国人民都不买可能还有点用)，再这样下去人家都不愿意嫁给我了。去年上半年其实倒是可以买的。只是那段时间忙于工作，等清醒过来发现房价已经高不可攀了。谁让我总是后知后觉呢。

从现在住的小区出去，向西，平均不到 10 米就能看到家房地产中介。在房源比较集中的几个小区门口，三三两两的路人口中谈论的几乎都是关于房子的事情，正所谓，"十亿人民九亿炒房，还有一亿中间商"。有的时候一个房源几乎几拨人马一起杀到。

周五晚上到今天下午，一共看了五处，在各个小区间转悠，上楼下楼，腿肚子转筋。老实说，按照现在的建筑质量，98 年以前的房子基本都破得不太像样子了，但价格可都不低。破破烂烂的也都 15K 起，好一点的小区，基本有钱也没人卖，当然我也没那么多钱买。

接下来有时间准备去滨江看看，滨江最大的麻烦倒不是上班路远，而是很多小区空置率太高--即使你住进去了，装修噪音总要忍受的。每新搬进来一家，装修总要持续一个月吧，那些空房大都是有钱人买来投资的，什么时候出手还都不一定呢。可以想见那些已经住进去在未来的几年中在家里就要时不时的听电锯声了。

谨以一首周云蓬的《买房子》送给天下同样可怜的人：

买房子
买了一套房子，花了三十多万，买房子的钱，全靠银行贷款
从今天以后，不能随便请客吃饭了，不能多喝酒，不能去旅游
从今天以后，我要去上班了，我要努力地还钱，我要还清贷款
不管风雨雷电，我要去上班，不管天塌地陷，我要去上班
不管洪水滔天，我要去上班，不管海枯石烂，我还是要上班
我努力地还，我拼命地还，我要一直还钱，我要还清这贷款
直到有一天，所有的钱都还完了，头发也就白了，嘴里没有牙了

(唯一需要更改的是, "三十多万", 现在在一般的中型城市买房子恐怕也有些吃力了)

--EOF--

时间：明天(3 月 8 号) 下午两点。

地点：文三路、万塘路交汇处两岸咖啡。(平时没怎么注意两岸咖啡文三店是否有 Wi-Fi, 如果没有 ，就移师第五大道咖啡馆，那里的无线速度还凑合。二者对面遥望不到 20米）。

暗语：Web 2.0 . (进门问服务员即可)

事由：今天 ITluck 约我周六聚一下，聊聊互联网。虽然杭州有很多网上认识的朋友，但见面的机会还真不多。趁这个机会不妨发起个小聚会。针对 Web 2.0 扯扯淡、聊聊天，探讨合作，交流资源。费用 AA 制。欢迎有兴趣的朋友前来。

--EOF--

这两天关注了一下基于 SAN/NAS 的集群文件系统的产品。找到了关于 Alexa 的一则旧闻，之后又发现了一篇关于 AOL 部署 SAN 文件系统的文章。

Alexa 的相关数据

Alexa 超过 1000 台 Linux 服务器 Farm，每半年增长 300T 新数据。经过了同类产品的选型后，最后选择了 Ibrix 融合文件系统。

SAN 使用的是 HP Modular Smart Array (MSA1000) ，最大支持 12T ，Cache I/O 最大 3 万个，算是个中低端的阵列。Amazon 没有透漏这套系统的吞吐能力，只是说 Ibrix 这套系统能达到 1T 的 I/O 聚合能力，单个 NameSpace 可达 16PB 容量。

不过从现在的一些迹象上来看，Amazon 对存储层重新做了改造。这套解决方案被替换掉了也说不定.

AOL 的相关数据

原有状况：3000 台主机通过 10000 多个光纤通道端口连接到传统的 SAN 上。其中有 8PB 的非结构化数据，分布在大约 1000 台 文件服务器上。管理维护的复杂度可想而知。

解决方案：文件服务器采用直连的磁盘，每个 12 块 700GB 的 ATA 磁盘，然后通过 Ibrix 融合文件系统进行集群化。

看起来，Ibrix 提供的解决方案很有竞争力。现在一些比较大的用户对于存储层的集群的需求越来越多，快成为趋势，一揽子解决方案还是有必要的，毕竟不是每家技术能力都强如 Amazon、Google ，有的时候用第三方的成本是能小于自己动手 DIY 的。

--EOF--

偶然发现了这个 NagiosChecker ，更方便的显示 Nagios 报警信息的 Firefox 插件。

这个插件几乎能搞定 Nagios Alert检查的方方面面，具备足够丰富的的过滤规则与显示条件；还能够定期调度；有趣的是，居然还提供声音报警。

一般人我不告诉他！

--EOF--

在公司洗手间看到一个关于“密码提示问题”的笑话。不过仔细一琢磨发现不是这回事儿。电子商务网站几乎都设置密码提示问题的。一个有趣的现象是有些 UE(或交互设计师？反正是干这个活儿的人) 工程师自己都没搞清楚这个 "密码提示问题“ 要给用户什么。

对于 UE 我是门外汉，不过我理解的这个过程就是建立公钥和私钥：公开的密钥即“密码提示问题”，是其他用户也可以看到的)，只有自己知道的叫私钥，也就是答案。很明显，既然说到私钥，那么私钥的保护就是关键。设计者有必要引导用户保护好自己的私钥。

我们先看个例子(类似的网站很多，就别说具体哪家了，都那鸟样)：

告诉我，用户需要填入"正确"的还是"错误"的答案?

就这个密码提示问题来说，如果没有直接明白的告诉用户正确的使用方式(你的用意!），那么很多用户还是输入“真实”的答案。除了第一个和第四个问题之外，其他几个问题我想在SNS 网络如此盛行、搜索引擎如此强大的今天，要得到答案是不存在什么障碍的。用户并不傻，但用户也不是都会耍小聪明，如果你去做个统计，我相信会有大量的用户输入的答案是可以猜到的。

或许有人会说，"没事啊，即使别人猜到了这个答案，密码最后也会发到原用户自己的信箱里的啊"。拜托，安全本来就是一环套一环的，这个如果被搞定了，你能确保用户的信箱不会被搞定么?

到各个站点查看帮助说明，发现原易趣的说明还是比较到位的(是否在用户设定问题的时候提示，我就不知道了)：

选择一个容易回答但其他人难以猜到答案的问题。
密码提示问题与任何其他机密信息一样重要，所以不要向其他人透露。
为安全起见，可以为问题提供并不正确或答非所问的回答。

前几天白鸦有篇文章《跟着用户走到沟里》，其实很多时候网站是设计者把用户带到沟里。

--EOF--