Remy Sharp wrote a web service to look up HTML Entity Character. The service “allows you to quickly find the entity based on how it looks”. There is also an OpenSearch plugin and MacOS Dashboard widget. Kudos to Remy!
I figured a Firefox extension clone would be handy, and it wouldn’t be too difficult to make one, thus:
This extenion is simple: a GUI wraps and calls the Javascript code Remy wrote (with a little modifiication, basically renaming global variables to make them unique) and then displays the result. The code is licensed under Creative Commons by-sa 2.5, same as Remy’s code.
It should work on Firefox from version 1.5 and above (have tested on 3.0aPre7 too), also on Netscape Navigator and Flock, let me know if you have any problem using it.
To try out, go to the extension’s home page and click install (it’s currently hosted on my server, so you have to let Firefox allow download and install extension from my server).
I could have made the extension remotely invoke Remy’s web service, parse the return html and present the result, but it might not be a good option, because:
- I need it work while off-line (too much distraction online);
- HTML entities character set doesn’t change that often, what’s the last addition? € maybe?
- Overhead from network traffic and CPU cycles parsing html;
- Not really a reason though: I could later make use of the new Online and Offline Events and provide user the options;
Update (09/09/2008):
You should be able to have it run on Firefox 3.0.1 and above.
雅虎今天推出了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上已经被扩展机制证明了。
“如果还没有搬过家，那你还不算是个blogger。”
去年网志年会的时候，我引用嘻哈哈的张扬这句话做的开头，刚过半年多，王佩的网志光荣了，幸好他还有另外一个域名，于是挤出写论文的时间，备份和转移之后，还立刻写了一篇《Wordpress整站搬家心得》。建议所有使用Wordpress的朋友们收藏，因为
你不知道要遵守什么样的规矩才能不挨枪子，活着就是你最大的危险，因为你随时随地都可能成为猎杀取乐的目标，朋友缅怀的对象。
— 王佩
关于blog转移，还有一些大部分blogger们还不了解或者没考虑到的地方，这里做点补充。
-
如果你能控制，把Blog的feed的输出设置为全文输出（至少提供一个全文输出的选项），而不是只输出简要。想靠只提供简要而提高点击率和PageView的念头是过时和无效的。而且，当遇到要转移Blog的时候，所有大的在线阅读服务(Google Reader, Bloglines, Zhuaxia等）和订阅了你的blog的朋友的桌面阅读器(比如SharpReader, RSSBandit等)都已经读取并保留了你的blog的全文，当你无法通过直接转移数据库的办法迁移blog的时候（大部分使用BSP服务的blogger们），至少还有把RSS文档导入新blog的一个选择；
-
如果你用某个BSP服务，而这个BSP没有提供全文的feed输出，这样除了把你拴住，并且利用你来吸引点击率然后赚广告的钱以外我想不出其他理由要这么做，所以想办法换个地方吧；
-
使用Feed合烧服务，比如最近被Google收购的Feedburner，国内的Feedsky。为什么要合烧Feed，而不直接提供自己的Feed？不考虑其他理由，只考虑搬家来说，一旦你有了一个烧制的Feed，那么当你从A.com搬到B.com的时候，那些直接订阅你在A.com的Feed的读者就看不到在B.com上的更新了。而如果你用的是合烧服务提供的Feed，那么只要在合烧服务上把B.com的feed加进去，那么，你的忠实的读者们不需要在他们的阅读器里做任何添加或者修改，就能继续看到更新了；
-
已经有了一个合烧的Feed之后还没完全结束，因为大部分的blog系统都会在页面里提供类似下面的一段代码，这个代码通常叫做Autodiscovery Link，就是为了实现Feed自动发现机制。
<link rel="alternate" type="application/rss+xml" title="白板报 RSS Feed" href="http://www.wangpei.net/?feed=rss2" />
这段代码告诉访问这个页面的程序(Feed阅读器和搜索引擎），这个网页的Feed的地址在http://www.wangpei.net/?feed=rss2 （Firefox和IE7就是通过发现这个link才决定在地址栏上显示那个橘黄色的Feed图标的）。这么做的好处是，当我要订阅wangpei.net的feed的时候，我就直接让google reader或者bloglines订阅wangpei.net，而不需要找到最后的真正的http://www.wangpei.net/?feed=rss2这个地址。好，如果你已经改用合烧的Feed，除了把那个合烧的图标和地址放在边栏之外，还可以动手把这个autodiscovery link的href改成你的合烧的feed的地址，这样，读者就不用拷贝你的合烧Feed的地址，直接输入你的网站地址就可以订阅了；
- 如果你不打算用合烧服务，却希望能够让订阅A.com的读者继续看到B.com的更新呢？或者你采用了合烧服务但是已经有很多读者已经订阅了你的A.com上自带的feed呢？那么你可以试试看修改A.com上的服务器配置文件(.htaccess)，设置重新定向（比如用mod_rewrite的rewrite_rule）把A.com上的feed的地址转向到B.com的feed的地址或者你的合烧Feed的地址上，比如：
RewriteEngine On
RewriteRule ^/?feed=rss2 http://www.b.com/feed [R=301,L]
注：R=301表示永久转移，如果是暂时转移，用302。
当然，这些建议对在BSP上写blog的朋友们没有什么帮助，但是这些功能对BSP们来说是能够做到的也应该做到的。这样的要求在2005年的网志年会上已经提出过，可惜，到现在还没有哪家BSP做到或者说愿意做到。
P.S. 对Feed的了解，可以看和菜头的这篇文字里的介绍，提供合烧服务的Feedburner的中文文案也是由他翻译的。
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来改装网页，你会改装国内的哪个网站？怎么改？
My programmer personality type is:
DHSB
You’re a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.
自我评论：这个不准，虽然我是很希望自己完全是这样的。
You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.
自我评价：差不多吧，Java, PHP, Javascript, C#… 想low level也难不是？
You work best in a Solo situation.
The best way to program is by yourself. There’s no communication problems, you know every part of the code allowing you to write the best programs possible.
自我评价：是这样的，过几天关于这点要专门写一些。
You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We’re not writing on paper anymore so we can take up as much room as we need.
自我评价：原则如此，但不喜欢太多和不必要的空白和注释。