四有新人

八 16

Wang Wen Hao杂谈 htc, 自我疗伤, 钻石 No Comments

2010年8月15日，抗日战争胜利65周年纪念日，甘肃舟曲全国哀悼日，在这个感情复杂的日子里，我的HTC Diamond2用它自己的方式进行了纪念……

我是被一个短信吵醒的，半睁着眼睛拿起手机，屏幕亮了，但是没有丝毫反应。好久没关机，累死了吧，我想。于是就关机重启，关机需要点屏幕确认……只能拔电池了。重新开机以后，依然如故，我顿时睡意全无。开了灯，发现屏幕里面竟然有一滩水渍……在灯光下隐约还能看到触摸屏的触点。Oh My God，手机被我的汗淹死了。

我拿出电吹风，看看能不能吹干，吹了一会儿没见好转。看来只能拆机了，打开后盖，取出电池，SIM卡，SD卡，拿起很专业的小内六角起子，嗖嗖嗖嗖，拧走4个角上的小螺丝。

本来想拍照留念下的，可是用来拍照的手机已经被我拆了……

从电源键那里轻轻掰开暗扣，轻轻地把后面板取下，主板就暴露了出来。拔掉几根线，把主板取下，下面就是屏幕，注意轻拿轻放……这时候，那根小键盘，音量键，电源键可以拿下来。把显示屏拿走，最后剩下的就是有水渍的触摸屏。可恶的是，水渍在屏里面，我的心凉了。用电吹风继续吹吧，横着吹，竖着吹，水渍岿然不动。估计这屏没救了，就在淘宝搜了一块屏，准备换新的了。原样装好，哀悼了一天。

奇迹就在今天早上出现了，我拿起手机，水渍还在，我下意识得摸了一下屏幕，其中一块很小的水渍不见了，我很好奇，再摸两下，全没了，再开机，正常了！原来，需要的是爱抚啊！

刚刚，新屏到了。现在，我正在纠结于要不要换新屏了……

八 14

Wang Wen Hao互联网, 我的工作 jQuery No Comments

为了让移动设备也能用上jQuery，jQuery开发团队发布了jQuery移动设备版开发项目jQuery Mobile Project（http://jquerymobile.com）。jQuery Mobile不仅会给主流移动平台带来jQuery核心库，而且会发布一个完整统一的jQuery移动UI框架。

对于大名鼎鼎的jQuery开发团队来说，当然要让jQuery Mobile支持全球主流的移动平台，而不仅仅是北美流行的移动平台。想要知道jQuery Mobile项目将要做些什么吗？请看jQuery移动平台策略；想要知道jQuery Mobile项目将会支持哪些浏览器吗？请看Mobile Graded Browser Support。

jQuery Mobile开发团队正在紧张工作，准备那些要支持的移动设备并针对这些设备进行测试。他们争取在今年晚些时候发布jQuery Mobile。如果你想为jQuery Mobile提供帮助，请加入jQuery Mobile社区的讨论组。

jQuery Mobile项目已经得到了Palm, Mozilla等移动浏览器厂商的赞助。

jQuery Mobile开发团队说：“能开发这个项目，我们非常兴奋。移动Web太需要一个跨浏览器的框架，让开发人员开发出真正的移动Web网站。我们将尽全力去满足这样的需求。”

八 12

Wang Wen Hao胡扯 雅俗共赏 No Comments

八 10

Wang Wen Hao我的工作, 杂谈 Handover, 困扰, 项目 9 Comments

首先，这件事情与我无关，只是有些困扰。

这是一个规模不大的项目，现在是在维护阶段。前维护的人小A已经离职了，离职前花了不到一下午把项目移交给小B和小C维护，由于小C有其他项目，所以小B一直是一个人在维护（其实小B也有其他项目），但是最终，这个项目是要交给小C的。现在小B马上又要走了，理所当然，就要移交给小C。这次，却花了4天。

可能是小A走得太急，只给小B半天时间来熟悉项目，但是从小A走到现在小B把项目维护得有条不紊。

现在小C来接手了，其实很简单，因为小A走的时候移交他也在，这次的移交理应只需要知道之后小B又改了啥东西就可以了。可以这次，却花了4天。

那这4天，小B和小C都干了些什么呢？

首先小C还在忙着他自己的项目，小B在小C的Leader的要求下，给只需要一个人维护的项目建立一个自动的Daily Build。小B之前没有配置过Daily Build工具，于是自己在那里查资料，建环境，写测试脚本，就这样2天过去了。

我觉得Handover时候并不需要帮以后的人把以后的环境都建好吧，特别是现在没有的环境，以后这个项目怎么操作是你们以后的事情，Handover应该是使以后的人明白这个项目里面的业务逻辑，编码规范，技术框架，接口定义方式等这些和项目有关的东西。

而且只有一个人维护的项目需要一个自动的Daily Build吗？我高兴的话，一天Build他个200次？够不？

接着，小C又让小B把现在所有的issue都处理掉再给他，可以，很合理，但是你是不是也要同时了解一下这些issue是什么呢？

又花了1天，小B处理好了所有issue，小C来了，耷拉着脑袋，很不情愿得搬着椅子在小B边上坐下，开始Handover的最后步骤，介绍项目。

我承认，小C确实很细心，用软件录了一下午小B的操作和讲解，就是不知道以后有没有时间看。

我的困扰是：有些事其实可以做得很简单，但是有的人就是喜欢弄得很复杂，这是不是和自己的前途紧紧相连的呢？每天讲流程流程，有的流程是不是必要的呢？在当我们把时间都花在流程上的时候谁来干活呢？质量如何保证呢？成本如何降低呢？

八 09

Wang Wen Hao互联网 URL 1 Comment

URL设计是Web设计中常被忽视的东西，事实上URL非常重要，这不仅是一个网页唯一的路径，还涉及到你的站点是否干净，友好。本文讲述URL这个司空见惯的Web元素中包含的大量不应为忽视的知识，准则与最佳实践。需要注意的是W3C建议使用URI取代URL一说。

关于URL的一些准则

首先是与URL有关的一些准则。

一个URL必须唯一地，永久地代表一个在线对象

URL的最基本的使命是唯一地代表Internet上的一个对象，URL必须和Internet上的对象一对一匹配。然而现实中，这很难实现，我们经常可以通过多个URL到达同一个页面，比如，http://mysite.com/product/tv 和http://mysite.com/product?name=tv，这种情形在现代CMS中更是比比皆是，针对这个问题，SEO moz有一篇很好的文章，讲到了如何使用Canonical URL机制解决站点中的重复URL问题。

URL应该是永久的，这就要求你在站点上线前就非常严谨地规划URL。如果有一天，你不得不更改URL，一定使用HTTP 301机制，告诉浏览器和搜索引擎，你的那个URL 所代表的对象，已经搬迁到新地址，这个机制可以保证你旧地址所获得PR不会被清零。

尽可能用户友好

这是URL设计的根本，你的URL应该为最终用户而设计。保持URL友好的一个好办法是在保证可读性的同时让它尽可能短。比如/about 就好过/about-acme-corp-page，当然，保持简短不能牺牲可读性，/13d2一类的地址短则短矣，但并不友好。如果要在Twitter，Facebook一类的社会媒体网络分享你的URL，可以使用Bit.ly一类的网址缩短工具，但这种工具产生的缩短URL 并不友好，在WordPress一类的CMS 中，可以使用PrettyLink Pro或Short URL plugin一类的可控制的地址缩短插件。

URL 的设计切忌使用一些对用户来说没有意义的内容，比如数据库的 ID 号，/products/23这样的URL地址对用户是极不友好的，应当使用/products/ballpoint-pen一类的地址。

保持一致性

站点内的所有URL必须保持一致的格式和结构，这样可以为用户带来信任感，如果你必须更改URL格式和结构，需要使用HTTP 301机制。

可预测的URL

这也是URL一致性的一个表现，如果你的URL拥有很好的一致性，用户可以根据URL猜测别的内容的URL，假如/events/2010/01指向2010年1月份的日程内容，那
/events/2009/01应当指向2009年1月的日程。
/events/2010应当指向2010年全年的日程。
/events/2010/01/21应当指向2010年1月21日的日程。

URL中的关键词

URL中应该包含本页重点内容的关键词，比如/posts/2010/07/02/trip-best-buy-memory-cards一类的URL本身就是对页面内容的反应。在URL包含重点内容关键词，也可以提高SEO性能。SEO的一个很重要的原则就是，在URL地址中包含内容关键词。

关于URL的技术细节

下面说的是有关URL 的一些技术细节。

URL不应包含.html,aspx,cfm一类的后缀

这类信息对最终用户是没有意义的，却占了额外的空间，一个例外是.atom,.rss,.json 一类的特殊地址，这类地址是有特别的意义的。译者注：在某些虚拟主机式Web 服务器，这种做法未必现实。

URL不应包含WWW部分

WWW 部分并不包含任何意义，是一个额外的负担，不友好。可以使用HTTP 301机制，将www.domain.com 定向到domain.com 。

URL的格式

URL 的格式如下:

domain.com/[key information]/[name]/?[modifiers]

Key information部分一般代表信息的类型或类别。Modifiers部分则属于查询字符串范畴，它不应当代表数据结构，应当代表数据的修饰。Key information部分应当尽可能简短，同时应当表现出一种层级关系，比如http://domain.com/posts/servers/nginx-ubuntu-10.04，或 http://domain.com/news/tech/2007/11/05/google-announces-android。

Google News对新闻源有一个有趣的要求，Google要求新闻源页面的URL 中必须包含至少3位唯一的数字，因为他们会忽略年份数字，因此，应该使用一个5位或5位以上的数字。另外，也应该提供Google News 站点地图。如果你想向 Google 提供新闻，必须按这样的结构提供URL，当然保持一致性，可以预测性也是必需的。

使用小写字符

URL中所有字符都应使用小写，这更容易阅读。

URL中包含的行为元素

URL查询字符串中可能包含一些表示行为的元素，比如 show, delete, edit 等。非破坏性的行为可以体现在URL中，破坏性的行为应该使用POST 。

使用URL友好字符

在URL中体现网页标题的时候，往往会用到一些特殊字符，应当把它们转换为URL友好字符：
全部大写字符换成小写
诸如é一类的字符应转换成对应的e
空格使用短划线代替
诸如!,@,#,$,%,^,&,*一类的字符应该使用短划线代替
双短划线应该使用单短划线代替
另外，没有必要的话，避免使用%20一类的URL逃逸符。

更多观点

Chris Shiflett建议，可以使用一些类似句子的URL，如：chriscoyier.net/authored/digging-into-wordpress/
chriscoyier.net/has-worked-for/chatman-design/
chriscoyier.net/likes/trailer-park-boys
jacobwg.com/thinks/this-post/is/basically-done

译者补充：URL 的长度上限

URL的最大长度是多少？W3C的HTTP协议并没有限定，然而，在实际应用中，经过试验，不同浏览器和Web服务器有不同的约定：
IE 的URL长度上限是2083字节，其中纯路径部分不能超过2048字节。
Firefox浏览器的地址栏中超过65536 字符后就不再显示。
Safari 浏览器一致测试到80000字符还工作得好好的。
Opera 浏览器测试到190000字符的时候，还正常工作。

Web 服务器：
Apache Web服务器在接收到大约4000 字符长的URL时候产生413 Entity Too Large错误。
IIS 默认接收的最大URL是16384 字符。