星月轮转

使用网络服务的目的，应该是利用它们高效、及时地交流有用的信息，获取和分享知识，能够结交到志同道合的朋友也是非常好的事情。 前阵子有不少朋友加了我 Gtalk. 最近我也在不断地通过 Google reader 中朋友们的分享扩大自己订阅的范围，新加了不少优秀 blogger 的 RSS. 很多人会在 blog 上留下自己的 twitter 帐号，我如果发现有价值就会 follow. 另外 Fenng 当前正在进行他的每日推荐一位推友计划，也让我收获不少。 问题 现在一个比较烦恼的问题是，这些人在不同的网站有不同的身份，没有一种机制很好很方便地将它们关联起来。举个不太恰当的例子，Fenng 的 blog 叫做 “DBA notes“，而 twitter 账户名就是 Fenng. 当然了，Fenng 的名气比较大，一般不会搞混的，并且 blog 的 RSS 输出中也包含了作者名，所以说举这个例子不是太恰当。对于普通人，可能就很难讲两个账户关联起来。有时候在 twitter 上看到一条引人注目的 tweet，都想不起来这是谁，还得到他的 twitter 主页去看，如果上面有 blog 链接还好。有时候某人接连几个月没有更新 blog，猛然更新一下，在 Google reader 里是很陌生的感觉，假如 blog 里没有个 about 页面，说不定还真想不起来这是谁。对了，我也希望把 Flickr 的账户也关联一下。 我虽然关注 web 发展比较多，但是真正在使用的服务还是很少的，现阶段主要也就是…

我感觉有些人学了 PHP 再学 ASP.NET 又学 J2EE，学了 struts 1.x 学 2.x，每学一种新的 web 开发技术都像是学一种完全陌生的技术一样。 实际上这么多种语言、框架并存，各有各的优缺点。然而所有这些语言、框架的基石，都是 HTTP 协议。最起码的，一个 web 开发者要知道，它是无状态的 (stateless)。客户端向服务器发起请求，通常是 GET/POST 方式，服务器通常返回一个 HTML 文档，有时候就是随意一种格式（比如图片、二进制或者纯文本）。HTTP 协议需要特别注意的地方还包括缓存 (cache control) 以及跳转 (301/302) 等。 我觉得，框架应该是归纳整理重复性的劳动，吸纳优秀的设计模式，而不是努力掩盖 HTTP 协议的本质。对 Web 开发者掩饰 web 的本质，是非常邪恶的一件事情。ASP.NET 就一直不遗余力地朝着这个目标发展，硬要把桌面程序的编程模式搬到 web 开发上来，Windows form、web form 的概念混为一谈，毒害了无数无辜的程序员。程序员接触到新的开发环境时，很可能到处碰壁，满地找牙（这个牙，可能就是 ASP.NET 给装的假牙——Event）。前段时间看了一下 Tapestry，发现该项目的老大有和 ASP.NET 类似的理念，按照他的说法，页面上的链接宁可在服务器端被 OnClick 处理一下然后 302 redirect，也不舍得直接指向实际的链接——声称这样更符合思维习惯。看到这个，我就明白了为什么 JavaEye 上有人惊呼，Tapestry 有点像 ASP.NET 啊，真好！说实话，看到这样的赞美，我就慌了。要…

点击 Google Reader 左侧栏最上面一块中的 “Your stuff” 链接，即可看到类似上图的界面。我这个截图是在点击了 “Show Options” 链接之后的情况，默认只有一个输入框，没有标题、tag. 这不就是 twitter 吗？呵呵。 我是昨天才发现 Google Reader 还有这么一个功能，平常我也就点点 share 按钮，分享些自认为有用或有趣的东西。看到这个界面上那个 bookmarklet 了吧？使用它可以分享任意一个链接，即使它不在任何一个 RSS 中。 另外 Google Reader 最近刚刚发布了 comments 功能，许多人欢呼雀跃，我却觉得没啥用处。虽然将某 item 的 comments 汇集到一起容易造成信息泛滥，但是分散在各个 share 中形不成规模，不利于思想的碰撞与融合，这样更不好。 如果 Google Reader 能够像某些 RSS 阅读器那样让 blog 作者们 claim 自己的 RSS，然后看到所有在 Reader 中收到的评论，那是多么好的事情。我想许多读者也想在 Reader 中直接与作者交流，而不需跑到该 blog post 的页面。这牵扯的东西又太多了，如果这样，blog 的流量可能大减，等等。 Reader…

本文分享一下我在 Firefox 中使用搜索引擎的经验，希望对朋友们有所帮助。 Firefox 界面右上角的搜索栏可是我严重依赖的东西。我不会先打开 google.com 然后再输入关键字搜索。不管你在做什么，有东西要搜索的时候，只需按下组合键 Ctrl+E 或者 Ctrl+K，焦点就会定位到搜索栏，输入你的关键字，回车，搜索结果就列出了。你可能不希望搜索结果在当前页面打开，很简单，在 Ctrl+E/Ctrl+K 之前按下 Ctrl+T，新建一个 Tab 就可以了。还有一个更便捷的方式是不用事先新建 tab，输入关键字之后按 Alt+Enter，搜索结果会自动在新 tab 页打开 (Alt+Enter 同样适用于地址栏)。 如何快速使用非默认搜索引擎搜索？ 点击搜索栏左侧的小按钮打开搜索引擎列表，然后点击最下面的 “Manage Search Engines…”，选中你需要使用的搜索引擎，然后点击右侧的 “Enter keyword…”，输入一个关键字，越短越好，一个字母就足够了，如下图所示： 依我之见，默认的 Google 就不需要设置 keyword 了。keyword 有啥用呢？举个例子，我给 Wikipedia 的搜索引擎指派了关键字 “w”，那么在地址栏 (location bar) 输入 “w Java” 然后按下 Alt+Enter，就会在新 tab 打开 wikipedia 的搜索结果（实际上是直接 redirect 到 Java 词条的页面）。 还不知道怎么快速定位到地址栏？至少有三个快捷键：Alt+D/F6/Ctrl+L 搜索指定版本的 Java…

杯子是免费的，不过要5元运费。本来我也没太大兴趣做个印着照片的杯子，不过去年年底的时候买了个麦当劳的优惠卡，送一张咔嚓鱼的优惠券，可以免费得到一个拼盘照片马克杯，只需支付5元运费，还不错。这个杯子好像原价要三十多块呢。 上周末我才打起精神翻看我的照片，从里面找了几张看起来还可以的——那么多照片，想找几张能拿出来看的，还真是不容易啊，由此说明，数码代替了胶片造成了照片平均质量的大幅下滑。 大致的步骤： 首先上传要印在杯子上面的照片 然后按照优惠卡上的地址去输入优惠码 成功后就得到了优惠产品的链接 顺着链接点过去，选择照片，定制杯子样式，最后 checkout 在订单信息那一页下面有个填写优惠码的地方，比较容易迷惑人（如果优惠码填写在这里，是会报错的），实际上不要理会这个字段，空着它点击继续，在下一步结算的时候就可以发现咔嚓鱼已经把优惠计算进去了，最后账单总额是5元。 然后就等着收杯子吧。我是15号下午订制，17号就收到了，速度很不错。而且包装也相当安全，里面是两块为马克杯量身定做的模具一样的细泡沫塑料，外面还有一层泡泡纸——这天下班回来的路上我就是靠挤爆泡泡消磨时间的，哈哈。 杯子实际上也就放在那儿当个摆设，像我这么能喝水的人，那一杯还不够我一口喝…… 话说惠普为这个咔嚓鱼的推广真是费尽心机，免费冲洗，免费杯子，但是用户享受完免费的服务，还会接着去买东西吗？至少我没太大的需求。

前文提到 Matt Raible 在比较 Java web framework 的时候有一个重要的指标（他将之排在第一个）： Ajax Support: Is it built-in and easy to use? 与 JavaScript 有关的指标还有一个： Validation: How easy is it to use and does it support client-side (JavaScript) validation? 我个人却觉得服务器端的框架不应该对 JavaScript/Ajax 如此高度地集成，它们毕竟是客户端的东西。程序员必须有清晰的概念，什么是服务器，什么是客户端，它们之间是怎么交互的。微软的 ASP.NET 做了一个很不好的表率，将 web 开发用 Windows 桌面程序开发的理念来进行，迷惑了不少程序员——就连官方翻译 “Form” 成中文也是“窗体”，真是不伦不类。而程序员需要深究其运行机制的时候，就不得不折腾 POSTBACK 那一坨屎了。Ajax 开始流行之后，微软又不失时机地在 ASP.NET 加入了 Ajax 的控件，广受那些喜欢拖拖拽拽像搭积木一样“编程”的程序员的欢迎——这就是 “The Microsoft way”.…

相比 PHP, Ruby, Python 等语言，用 Java 来做 web 开发面临着太多的选择。不过也许正因为 Java 的选择更多，所以才有更多的人选择 Java？这一点不能确定。来这里看看，光是持久层的 ORM 工具就有这么一大坨。当然这里面还是 Hibernate 为王，这个选择比较容易做。 然而到了表现层，虽然框架不是那么多，但是选择起来可不容易。每个框架需要评估的方面至少包括性能、学习/开发速度、可维护性、用户群体 (community) 等。 Matt Raible 曾经对 Java web framework 们做了比较 (PDF 下载，建议右键另存为)，我觉得这个 presentation 可以从39页开始看。第43、43页的建议和 tips 非常有价值： Don’t believe blogs and articles – 也就是说，该 presentation 39页之前的内容要谨慎对待 🙂 Try it yourself Believe developers, not evangelists Believe developers that are experienced with…

Trac is an enhanced wiki and issue tracking system for software development projects. Redmine is a flexible project management web application. 实际上 Redmine 应该是 Trac 的 clone，基于 RoR. 它们都是对项目开发、管理非常有帮助的系统，可不仅仅是 bugzilla + wiki，Timeline 这个 feature 将 bug tracking system, wiki, 以及版本控制系统的最新动态整合起来，让你一眼看到项目的最新进展。 我用 Trac 多一些，现在也在用，也更倾向于 Trac，而 Redmine 只是短暂地用过一段时间，下面简单地对二者的重要特性做一下比较。实际上 python/ruby 我都不熟悉，所以下面的比较如有错误请多多指教 🙂 svn 支持 Trac 只支持本机，通过 python 直接读取目录中的数据…

在 Windows 下面，TortoiseSVN 应该是最常用的 Subversion 客户端了。但是安装完成的时候它都会要求重启计算机，连 FAQ 上都是这么说的： You rebooted your PC of course after the installation? If you haven’t please do so now. 不过我觉得实际上并不需要重启。它要求重启只是为了跟 explorer 的绑定生效，而为了重启 explorer 去重启计算机显然有点得不偿失。 只需打开任务管理器，找到 explorer 进程并结束它，然后点击菜单“文件-新建任务(运行…)”，输入 explorer 回车，等一下任务栏出来的时候，一起就都 OK 了。

随着前端开发在 Web 开发中的地位日渐重要，前端相关的资源部署也成了各大网站开始重视的一步。 对于一个访问量相当大的网站来说，从前端方面考虑，除了使用 CDN 向客户端分发 JavaScript/CSS 资源，充分利用客户端浏览器缓存也是减轻服务器压力的一个重要途径。 首先按照我们的“常识”，认为 JavaScript/CSS 默认就是在浏览器中缓存“很长”一段时间的，作为最简单的策略，我们就依赖这种缓存机制来降低服务器的压力。然而，对于一个不断改进、更新的网站来说，JavaScript/CSS 的变动是相当频繁的。 如何让浏览器知道这些静态资源的改变呢？让我们从最简单的解决方案开始摸索和学习，慢慢改进。 刀耕火种的方式 把这件事扔给开发者吧。以 JSP 页面为例，首先在一个统一的 jsp 文件（例如 version.jsp）中定义所有静态资源的版本号： [code lang=”html”] [/code] 然后在每个用到 JavaScript/CSS 的页面中包含该文件并且给静态资源加上版本号： [code lang=”html”] … … [/code] 开发者负责在每次 commit 代码前检查自己修改过的静态资源，去修改相应的版本号。这给本来就不堪重负的开发者又增加了一项艰巨任务，他们难免会有疏忽的时候，等到有客户反馈问题，才想起来——哦，忘记改版本号了！ 自动化 一个成熟的开发团队应该使用版本控制工具来管理代码，一般最常用的是 Subversion. 除此之外，还应该有一套完善的部署脚本，执行一两个命令即可完成整个部署过程，而不是手动地去复制、修改代码。这个过程可能包含从 svn 检出代码、编译（解释型语言则省去了这一步）、选择性的复制（避免覆盖生产环境中的特定配置）等等。 有了这些基础，把上面手工修改版本号的工作交给自动脚本去做就可以了。”svn info” 命令可以列出文件最后被修改的版本号，我们只要得到这个版本号，把它写在 version.jsp 中即可。写这个脚本可能稍微麻烦一点，不过 python, perl, bash, ruby, 随便什么语言都可以，或者是一个 ant task. 这是一劳永逸的事情。开发者们可以把精力集中在真正的前端开发商了。 不要用 query…