雅虎今天推出了YSlow插件（这名字不错：Why Slow? ），需要先装Firebug，YSlow其实是它的“插件”。YSlow从Firebug收集当前网页和该网页的访问信息后进行分析，如有必要则给出如何提高页面加载速度的建议，比如减少DNS查询，使用外部并压缩Javascript等。这些建议是根据13个提高网页速度的指导原则，其内容已经在Yahoo Developer Blog上系列连载了一段时间，最近更新速度快了很多几乎每天一篇（是为了配合YSlow的推出？）。除此外还有专门一本书：《High Performance Web Sites》，内容就是这个系列（多了一个关于Ajax的专题），应该有更深入的分析和解释（这本书是Rough Cut，所以有O’Reilly Safari帐号的可以先睹为快了）。
这个High Performance系列说明网站开发者（包括我自己）非常需要深入了解HTTP和HTML。对Java尤其尤其是J2EE程序员来说，不要只是build around the web, 而是build for the web。很多程序员（尤其是刚毕业的大学生）不在意HTTP的细节，从所谓的“企业级开发”的角度把HTTP请求仅仅当作作一种函数调用，导致能提高性能的所有HTTP的特性都被“抽象”掉了，也就不了解或者利用这些属性。比如，我常在面试的时候问：HTTP GET和POST的区别在哪里？大部分的回答只有参数大小和位置的不同。
YSlow上的指导原则里的内容还有些可以补充的（很多东西应该都放到那本书里去了吧），比如在High Performance Web Sites: Rule 13 – Configure ETags里，作者建议在Apache上把ETag关掉，实际上只需要告诉Apache不要用Inode信息生成ETag就可以。还有其他一些，回头写上来。这里，这里，和这里也有很多非常好的建议。
另外要注意的是，网页速度跟网站性能是不同的概念，网页在浏览器上加载得快，并不能保证网站的性能就好，虽然二者之间有密切的关联。
P.S. 关于网站的延展性(scalability)和速度(performance)，O’Reilly已经出了两本，另一本是《Building Scalable Web Sites》，都是雅虎员工写的，在这要赞一下雅虎对Web开发社区的贡献。
昨晚下载了Apple最新的浏览器Safari的Windows版，试了一下，可能是习惯了Firefox，感觉一般，而且中文显示还有问题（也许是我没设置好）。但用是肯定会用的，因为现在不用专门找台Mac或者跑虚拟机来测试网页在Safari上的显示效果了，这算最大最直接的好处了，赞一下。
又搜索了解了一下，发现Safari：
-
像Firefox有扩展一样，有自己的plugin平台，PimpMySafar是专门收集和推广Safari plugins的网站;
-
像Firefox基于Gecko一样，基于开源的引擎Webkit，btw, Windows上也有个基于Webkit的开源的浏览器Swift（在中文显示上似乎比这Windows版的Safari还糟糕）；
但是Safari有Firefox完全没有的优势：iPhone。据说iPhone上的开发将是Web application，而不是提供运行iPhone的MacOS的本地的SDK/API，如果真是这样（也许Jobs过几个月又会改主意），那么Apple的用意也很明白了：利用iPhone的Cool Factor（就像MacBook一样），吸引更多的开发者开发基于iPhone的Safari的plugin，让Safari成为一个平台（嘿，关于这方面针对Firefox我曾经写过类似的）。而这些plugins也会在MacOS和Windows上运行，从而建立起Mac之外Apple的更大的开发者社区和Safari生态圈，像曾经的微软一样，Embrace and Extend。
接下来会怎么样？
Safari的Plugin会像Firefox扩展一样甚至更容易开发么？会不会有软件能移植或者部分转换扩展到Plugin？Firefox的扩展界面是XUL，也就是XML，XML是可以（即使不容易）转换(通过XSLT)的……
业界的开放标准会因此得到推动么？iPhone肯定要存储地址簿和日历的，那么读取和存储页面上的Microformats比如hCard和hCalendar的plugin肯定会有的（如果不是已经集成在Safari之内）……
出版商如O’Reilly会出版Safari Hacks，Safari Cookbook，Safari For Firefox Developer，Manning出版Safari In Action？Apress出版Beginner/Professional Safari？;-)
当然，就算这个策略不成功，Apple也还有像微软提供Windows CEMobile的SDK一样提供iPhone SDK的选择。
如果不能在iPhone上开发，那花那么多钱买iPhone，跟作Apple的凯子有啥区别？:-P
UPDATE: 在O’Reilly Radar上看到这篇XULRunner for the iPhone，Marc Hedlund说：
I suspect that the real and right desire is to connect all of the capabilities of the iPhone to the Internet.
仅仅是Web页面是不能充分做到这点的，只有能够跟iPhone本地结合，才能做到这点，增加更多iPhone的价值，激发更多的想象力，这在Firefox上已经被扩展机制证明了。
So, people who make conferences: listen up. I think that there are lots of sysadmins and ops people who would go to a conference solely about web operations.
— John Allspaw
今年的网志年会已经开始筹备了，这一次，我们能不能做一个真正的有纯技术(开发，运行，维护等)话题和参加者的年会呢？
我个人想感兴趣的话题：
- 开发的平台，框架和工具，SCM的环境的选择；
- 网站性能优化；
- 技术团队的成长；
- 技术趋势（Atom, OpenID, REST, Microformats等)的演示；
- 好玩的新技术；
如果真的能够有完全让技术人员感兴趣和交流的演讲和讨论，相信年会的影响力和凝聚力会更大提高，而我也会争取让我们团队和认识的其他程序员一起去参加。
为了更方便阅读网页(”Improves readability”)，有人专门针对Lifehacker.com（我每天必看的网站）页面写了个Greasemonkey用户脚本，把多余的页面元素删除掉(”Removes various elements from the Lifehacker site”)。
猜猜看Lifehacker的反应是什么?
It removes too many elements of the site’s design, but this custom Lifehacker user style is still a compliment. You like us enough to mod us!
稍微有点不满意(删除掉太多页面设计元素了)，但这对Lifehacker.com还是一个认可，因为用户喜欢Lifehacker到了改装页面（mod的感觉没翻译出来）的地步。
所以：
- 如果有用户用user script改装你的页面，那这是一件好事情（你提供了他们不愿意放弃的内容），同时也是一件需要考虑的事情（页面设计也许太花哨或者色彩搭配不够好）；
- 页面的mark up不能太复杂，否则user script不好写 ;)
- 页面的mark up不能经常变动，否则user script会失效；
这就让我想起几天前看到的一句话：
Your Markup is an API. With all the hype about APIs and mash-ups, it’s easy to forget that your HTML is also an API, and your users are experimenting with it right now.
— Matthew Magain
但页面设计和编写的重要性绝对不仅仅在为了考虑用户使用Greasemonkey user script（毕竟这样用户比例特别小），在结构化的数据的发布和读取上，尤其是microformats的推广更是证明了“页面是API”。下一个版本的Firefox，Firefox3.0，已经在考虑集成对microformats的支持，这里有一些Firefox3在支持microformats的用户界面设计模拟图，已经包括hCard, hCalendar等格式。
话说回来，无聊一下，如果写Greasemonkey user script来改装网页，你会改装国内的哪个网站？怎么改？
Q: What’s the difference?
A: A mime-type.
— Joe Gregorio
Although things have been pieced and formed up together in my mind for months, still have to say, it was one of aha! moments when I read that.
Further reading:
为了能够在blog里显示代码，一直没有找到理想的解决方案，因为没能满足以下三个要求：
- 能够根据语法高亮或者着色；
- 不在代码里添加内嵌的css代码；
- 没有副作用（比如第二点，在代码里直接插入渲染的代码，要修改可能就比较麻烦），包括增加服务器的压力；
今天找到一个满意的方案：google-code-prettify，很好地满足了前面三个要求，使用方法很简单。
当然，如果在RSS阅读器里看代码，是看不到语法着色的（这是第二个要求的代价）；如果浏览器关掉了Javascript，也看不到（这是第三个要求的代价）。
例子：
PHP:
require_once 'Url/PathVars.class.php';
...
require_once 'View/SearchPage.class.php';
class Controller_Dispatcher
{
public static function handle_request($url)
{
$pv = new Url_PathVars('/');
// TODO:this is ugly, got to change it
if (substr(strtolower($pv->fragment), 0, 8) == '/search?')
{
self::handle_search_request($pv);
return;
}
switch ( strtolower($pv->fetchByIndex(0)) )
{
case '':
self::handle_default_home_request($pv);
break;
case 'people':
self::handle_people_scope_request($pv);
break;
...
}
}
Javascript:
window.addEventListener(
"load",
function()
{
twsstopper = new TWSStopper(window);
window.twsstopper = twsstopper;
twsstopper.startUp(window);
var appcontent = window.document.getElementById("appcontent");
if (appcontent)
{
if (!appcontent.TimeWastingSiteStopper)
{
appcontent.TimeWastingSiteStopper = true;
appcontent.addEventListener("DOMContentLoaded", twsstopper.onAction, false);
}
}
},
false);
bash:
cd $TMP_DIR
if [ -f "chrome.manifest" ]; then
echo "Preprocessing chrome.manifest..."
# You think this is scary?
#s/^(content\s+\S*\s+)(\S*\/)$/\1jar:chrome\/$APP_NAME\.jar!\/\2/
#s/^(skin|locale)(\s+\S*\s+\S*\s+)(.*\/)$/\1\2jar:chrome\/$APP_NAME\.jar!\/\3/
#
# Then try this! (Same, but with characters escaped for bash :)
sed -i -r s/^\(content\\s+\\S*\\s+\)\(\\S*\\/\)\\s*$/\\1jar:chrome\\/$APP_NAME\\.jar!\\/\\2/ chrome.manifest
sed -i -r s/^\(skin\|locale\)\(\\s+\\S*\\s+\\S*\\s+\)\(.*\\/\)\\s*$/\\1\\2jar:chrome\\/$APP_NAME\\.jar!\\/\\3/ chrome.manifest
# (it simply adds jar:chrome/whatever.jar!/ at appropriate positions of chrome.manifest)
fi
BAT?:
xcopy build\skin build\chrome\skin /i /e
...
rmdir /s /q build\locale
rmdir /s /q build\skin
cd build\chrome
7z a -tzip "%x%.jar" * -r -mx=0
cd ..\..
一直热情支持OpenID的Zola在呼吁给OpenID起个中文名，因为：
OpenID是为广大网民服务的，支持OpenID能让服务提供者和网民都得到好外，需要推广才能让广大网民尽早享受到这一个新东西。
…
像一个场景：在网吧，去问一个正在玩跑跑卡丁车的人有没有OpenID，他会怎么想？如果我问他”有没有可以作为用户名的网址”会不会更容易让他明白我在问什么？
Zola的另一个理由是不能让又（我为什么说又呢？）一个词被垃圾译法给劫持（这字眼是俺用的）了。
伍岭老师（真的是老师）认为没有必要：
用户最关心的，是服务是否满足需要，而不是好听的名字；服务有效，再生造的外文词汇也可以琅琅上口；服务低能，再典雅的中文名字也玷污口舌。
…
更何况OpenID这个单词本身已经足够便于理解，而但凡连这个词都理解不了的用户根本不会关心OpenID。
我还没想好OpenID在大陆的推广和发展是否需要中文名，倒是刚刚想到一句台词：
“IP卡，IC卡，IQ卡，统统告诉我密码。”
《天下无贼》里这句台词出现的时候，大家都笑了。
笑了就说明大家都听懂了。
是否要给OpenID一个中文名，如果要的话用什么，我想还是依靠大众的智慧(The wisdom of crowds)来决定吧。OpenID的推广，有个准确的约定的中文名称也许重要，但更重要的还是用中文来准确、清晰、简单、易懂地解释给普通网民，即使他只是个“在网吧正在玩跑跑卡丁车的人” 。
谁来试试看？:-)