-
混乱的中文——“标签”是什么?
我觉得中文本来就够混乱不堪的,到了计算机及其它现代科学的世界里,就完全是一团糟了(也许我说的有点过了,呵呵)。今天在网上闲逛看见这么一个比较典型的代表,就拿它举个例子。 假如做产品的跟做页面的交流,说:“这里需要一个标签。”请问这个“标签”指的是什么?我想到的有这么几种可能: tab. 不了解的请看这篇“如何处理海量tab?”,我就是看到这个想到写一写这个话题的 🙂 tag. Web 2.0 时代被滥用的东西,实际上就是更随意的分类,我在很久以前写过一篇日志“标签(tag)真的那么重要吗?”。看,当时我就怕读者搞不清楚,于是在括号里标注了英文。 label. 一个 HTML tag,用在表单中。写过不少 HTML 的人还不知道?赶紧看去。 平心而论,单单说中文混乱是偏激的。一词多义在一般自然语言中都存在,甚至在编程语言中不也很常见吗?就拿上面第二点提到的 tag 来说,在第三点里也出现了(HTML tag),不过是不同的含义。而 label 也解释为第二点的意思,和 tag 互换使用。Google 的产品就习惯把 tag 叫做 label. 这么理智地一想,又觉得英文也似乎好不到哪儿去……哦,我自己都快绕不过来了,想说服别人,却连自己都说服不了了 🙁 总起来说,结合上下文语境,英文还是更清楚一些。这些差异主要是因为计算机世界里新创造了许多概念和词汇,而某些是在中文里没有对应的,或者对应得不好。如果留心的话,就会发现台湾人有许多名词的译法跟大陆不一样,也许值得参考。有些东西不好办,还是保留原词比较好,例如 “hack” 这个词。 混乱,还是博大精深?我的思想又彪得更远,觉得语言对一个民族的性格特点有很大的影响力。中文是很善于模棱两可的,在古代更是这样,连标点符号都没有,不知道古代多少人因此吃过亏。由于交流的工具——语言本身就是很模糊的,人与人之间就是你说我猜,又怕猜错,于是孔老夫子就总结出来一套非常非常科学的行事方法,叫做中庸,一直被我们葱白到今天。 扯太远了,全是愚见,仅供一笑 🙂 做过技术书籍翻译的同志们才更有发言权。
-
葱白
前些天 Kaven 写了一篇文章 “JavaScript大牛:Douglas Crockford“。过了几天,大牛 Douglas Crockford 跑过来看,真是仔细,不光看文章,还翻到下面的评论,对这句话产生了强烈的好奇心: 不得不说,我葱白他。 于是大牛就到处找翻译,Yahoo/Google 的翻译都很糟糕——你能想象有翻译软件能搞对这句话吗?令人惊讶的是,微软的 Windows Live Translator 竟然给翻译出来了! 大牛显然是谦虚中有睿智,睿智中有自信,认定微软是正确的。 我一位同学又试了一下这句网络语言:“我稀饭你”,结果它又翻译得不错——”i’m crazy about you”. 让我葱白一下微软!
-
return 一个空的集合,而不是 null
想想几天前的天气,阳光明媚,万里无云,真是让人有辞职的冲动。到了这个小假期,似乎人间的幽怨又郁积起来,天地转入混沌,一篇迷茫。我决定窝在家里,学点东西。 这个话题对于程序员来说是家常便饭,设计许多函数、方法的时候都会遇到。实际上这是极其基本、极其容易理解的一个问题,不过有些人还没有意识到,仍然随意乱写。拿 Java 举个最简单的例子: [code lang=”java”] public List getTopUsers(int limit) { if (limit < 1) { return null; } // … } [/code] 这个例子里首先判断传入的参数 limit,如果它小于 1,那后面的工作就不需要了,这里用了 return null 来处理这种情况。这个方法可能在许多地方被调用,每次调用结束,都要判断一下返回值是不是 null,如果不是 null,才可以进行正常的处理。这是多么繁琐的事情。 [code lang=”java”] // The tedious way: List topUsers = xxx.getTopUsers(limit); if (topUsers == null) { // … } else { for (…) {…} }…
-
设想一下网络身份的高效管理及利用
使用网络服务的目的,应该是利用它们高效、及时地交流有用的信息,获取和分享知识,能够结交到志同道合的朋友也是非常好的事情。 前阵子有不少朋友加了我 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 发展比较多,但是真正在使用的服务还是很少的,现阶段主要也就是…
-
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 也有 twitter 功能
点击 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 中使用搜索引擎的经验,希望对朋友们有所帮助。 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号就收到了,速度很不错。而且包装也相当安全,里面是两块为马克杯量身定做的模具一样的细泡沫塑料,外面还有一层泡泡纸——这天下班回来的路上我就是靠挤爆泡泡消磨时间的,哈哈。 杯子实际上也就放在那儿当个摆设,像我这么能喝水的人,那一杯还不够我一口喝…… 话说惠普为这个咔嚓鱼的推广真是费尽心机,免费冲洗,免费杯子,但是用户享受完免费的服务,还会接着去买东西吗?至少我没太大的需求。
-
Web framework 过度集成 JavaScript/Ajax
前文提到 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”.…
-
Java web framework 之选择
相比 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…