运行Java代码——在Javascript里
Joho Resig (即 JQuery 之神)，是一位知名的“ JavaScript is the next big things”论者。他最近有机会参加了一个日本的 JavaScript 交流活动，给我们带回了一个有趣 JavaScript 项目 orto 的介绍。
这个名字看起来特别象 orz 的日本项目，可比它的名字看起来可要牛逼不少，它的野心是能让 java 代码运行在 JavaScript 之上，我的意思是 —— 用 JavaScript 做一个 JVM 出来。虽说可能不会全面支持 java 的所有特性，但至少能做一些有意思的东西，比如这个性能还不错的俄罗斯方块。
它的做法相当有意思，乃是将 java 的 byte code 转换为 JavaScript 代码，比如，你会看到这样的代码：
var orto336=orto350(orto333);
if(orto336.orto340!=orto310){orto223("java/lang/IllegalThreadStateException",null);
return ;
}
...
case 117:orto246[orto247-2]={high:(~orto246[orto247-2].high)
&0xffffffff,low:(~orto246[orto247-2].low+1)&0xffffffff};
if(orto246[orto247-2].low==0){orto246[orto247-2].high++;
orto246[orto247-2].high&=0xffffffff;
orto246[orto247-2].low=0;
}break;
...
case "CHECKBOX":orto171=orto188["orto/ui/CheckBox"];
break;
case "IMAGE":orto171=orto188["orto/ui/ImageButton"];
break;
case "RADIO":orto171=orto188["orto/ui/RadioButton"];
break;
显然“不是给人读的程序”(因为是给机器读的嘛)。orto 的特性包括：
* The result is able to handle threaded application code (translating the threads into a series of yields with setTimeout (mentioned in the presentation and demonstrated in the Tetris example).
* The application can use regular Java conventions for designing and constructing the UI (as shown here, as well). User Interface components are translated to, similar, HTML ones. It’s not apparent to what extent functionality is implemented, but it is to a certain degree.
* Keyboard interactions are able to be handled and translated to normal Java callbacks.
说起来，这和 gwt 很有一些“异曲同工”的意思。这让我联想到了 rhino，呵呵，你来实现我，我又来实现你，真是一个互操作的时代。畅想一下，如果在 rhino 的基础用上跑 orto 又或者在 orto 的基础上跑 rhino ，那会是一副什么光景，又有着怎样的意义呢？
也许是我个人食古不化的误解——私下里，个人认为 orto/gwt 这种项目让我有种“狗拿耗子多管闲事”的感觉，JavaScript 这样的脚本语言，不是正好适合于“需求变化迅猛”以及“强调快速原型化开发”的 UI 层么？找两个美工，一个 js 程序员就能做界面，不正是又快又好用么，为啥非要用 java 来写？追求语言上的纯粹？又或者是 js 程序员太难找？从后端的业务逻辑到前端的用户界面，全部都用 java 来包打天下，这是合适的做法么？如果说传统“应用程序”界面的程序，用用 swing/swt 什么的还可以理解，而在 web 一桶糨糊的现如今，这语言的 babel 之塔，就这么难以建立？
呵呵，JavaScript，我支持你。
[荐]如何给你的奶奶解释“云计算”
大道至简，简单是美。在下一直以为，能“把复杂的东西解释得很简单”是件很了不起的事，远比“把简单的东西解释得很复杂”要牛逼很多倍(后面一种事，好像每天有很多人都在做)。
王小波善于通过小说将复杂的社会政治问题给广大长期被洗脑的人民解释得一清二楚(这里)，而 highscalability.com 的 Todd Hoff 则善于通过博客将复杂的软件技术问题给毫无技术背景的奶奶解释得明明白白(这里)。在其中的任何一个领域，要干好这件事都需要相当的智慧，殊为不易，同样都值得推荐。
恩，推荐阅读的文章地址在[这里]。
PS. 不知道为了什么，象 highscalability.com 这样的纯技术站点也被我们“伟大的防火墙”(不知道的自己去google英文版)挡在了外面，国人无缘得见。(科技领域也搞闭关锁国？)各位无法访问的朋友，要么使用“伟大的过墙梯”(不知道的自己去google英文版)自己翻墙去看，要么看下面我“被迫的盗版”。
[blah] REST —— 一个实用主义者的思考
这几天在考虑“虚构ajax 聊天室”的 uri 设计，想用 rest 风格来试试，时髦一下嘛。但对 rest 有很多地方其实都是一知半解，于是去问老朋友—— rest in action 上的 dlee 同学——拽着问了一大堆初级问题(见这里，以及这里)，回头又啃了一些文章，也算是对 rest 进行了一番独立思考吧。想到整个过程对于其它人或许也有用，于是 blah 之。
需要说明的背景是：我是一个实用主义者。也就是说：搞开发不求纯粹但求实用。乃是在“多快好省”实现需求的前提下，顺便向“有风格”的方向靠，能靠上最好，靠不上拉倒。重点不在结果，而是在过程——也就是说，设计决策中，如果我选择了 free mobile phone ringtones | cricket free phone ringtones | 1600 nokia ringtones | madonna ringtones | free ringtones converter | cheap virgin mobile ringtones | free ringtones 3gforfree | mobile phone ringtones virgin | sprint pcs ringtones | free nokia mp3 ringtones | download free ringtones nokia | download free ringtones to cellular phone | free lg ringtones verizon wireless | get ringtones | free composer ringtones | gold mp3 ringtones | motorola ringtones | alltel free music ringtones | cingular free ringtones wireless | free boost mobile ringtones | rest ，那么借鉴的是什么，如果我选择了不遵循它，那么理由又是什么。另外一个需要说明的是，尽管这几天啃了不少 rest 的文章，但“每个人的心中都有一个 xxx”(请自行将 xxx 替换为你喜欢的任何词语)，加之对 rest 可能仍未吃透，所以大家凑合着看，或许某天夜里悟透了，爬起来把这里的思考全都推倒重来亦无不可能(免责声明了啊)。如果发现有错误，那太好了，欢迎之至，请随时指出。
下面就是“虚构 ajax 聊天室”的 rest 设计之旅。
CouchDB Language Change
续CouchDB 的作者 Damien Katz 炮轰 Erlang 的语法后，现在发布了消息CouchDB Language Change
I’m somewhat sad to say that Erlang will not be used in future releases of CouchDB. We are switching the whole codebase to (…drumroll..) Java.
最大的原因似乎是Erlang开发人员不足
But perhaps the biggest problem with Erlang is the relative lack of Erlang developers. Developers in the US who’ve worked on a successful Erlang project probably number less than 10.
[荐]RESTful Services with Erlang and Yaws
说来也巧，刚刚推荐过 InfoQ 的 The Power of Javascript 隔天就看到 InfoQ 又发了 Steve Vinoski 的一篇 RESTful Services with Erlang and Yaws ，地址在[这里]，说不得，只好再次推荐。
和 Javascript/Ajax 一样，RESTful 也是风头正劲的 buzz words 。一言以蔽之，其实质就是回归 http 协议的本质，尽量在其框架之内解决问题。首先就是要 uri 化应用本身的资源，确保一个资源只有一个 uri ，以达致简洁。其次就是在 http 协议的 GET/POST/PUT/DELETE 动词(请求方法)上做文章(与之相对应的就是用户埋在 form 中的 act/op/delete/edit/modify/change/update/… 等千奇百怪的自定义参数)，将其映射为 CRUD 的常规操作，再就是对 http 协议的 content-type 进行严格的清晰化，针对不同客户端的请求，返回不同“格式”的数据，除此之外，对于 status code 和 header 之类也做一番“依照规范”的改进。相比 post 带上一大坨自定义参数的“老旧风格”，不规范之余，也会让参数越来越冗长以及自定义的格式越来越糟糕， RESTful 风格则显然更多的发掘了 http 协议本身已经内置的潜力，可谓正本清源。
但我还有一个小小的疑问。RESTful 之中只定义了4个“动词”，如若我的应用更为另类，需要更多的“动词”，又该如何？自定义新的 HTTP Method 引入更多的自定义 Method 是否会破坏 RESTful 想要“规约简化”的本意？希望有人能够解答此疑惑。
Recent Comments