摘要: Groovy 是一種利用其他語言（如 Ruby、Jython 和 Smalltalk）中的特性的動(dòng)態(tài)語言。Groovy 在 Java VM 上運(yùn)行，并使任何現(xiàn)有的 Java 對(duì)象（以及所有 API）可用于 Groovy。Groovy 當(dāng)前遵循 JSR-241 中的標(biāo)準(zhǔn)；您可以在 Groovy 網(wǎng)站及其項(xiàng)目主管 (Guillaume Laforge) 的網(wǎng)志中了解有關(guān)該語言的詳細(xì)信息。

Grails 之于 Groovy 相當(dāng)于 Ruby on Rails 之于 Ruby。（該名稱最初為“Groovy On Rails”，現(xiàn)在已改為“Grails”以避免混淆/競(jìng)爭(zhēng)。）與 Ruby on Rails 一樣，Grails 用于創(chuàng)建 CRUD（創(chuàng)建、讀取、更新、刪除）Web 應(yīng)用程序。您可以在 Grails 網(wǎng)站及其項(xiàng)目主管 (Graeme Rocher) 的網(wǎng)志中了解有關(guān) Grail 的詳細(xì)信息。
  閱讀全文      摘要: Groovy 的 Eclipse 插件能夠編輯，編譯以及運(yùn)行 groovy 腳本和類  閱讀全文      摘要: 經(jīng)典大片，國(guó)人驕傲，不容錯(cuò)過！  閱讀全文      摘要: 今天我無意間看到了一個(gè)Grails與RoR(Ruby on Rails)的性能比較，覺得有必要與各位還不了解Grails的朋友分享一下，以消除對(duì)Grails的神秘感甚至誤解：  閱讀全文      摘要: Groovy: The Sleeping Giant  閱讀全文      摘要: Groovy輕松入門系列教程之Grails實(shí)戰(zhàn)基礎(chǔ)篇，高效開發(fā)不是夢(mèng)！  閱讀全文      摘要:   閱讀全文      摘要: 多次轉(zhuǎn)載，鏈接與題目均已丟失，無法注明，向原作者致歉！
聞?wù)邆模娬吡鳒I～  閱讀全文      摘要: Groovy輕松入門系列教程之搭建Groovy開發(fā)環(huán)境  閱讀全文      摘要: 將Spring2.0.2升級(jí)至2.0.3須謹(jǐn)慎！  閱讀全文      摘要: 2007年Groovy好事連連，不容錯(cuò)過！  閱讀全文      摘要: 通過比較Groovy與Java的不同點(diǎn)和相同點(diǎn)，快速掌握Groovy :-)  閱讀全文      摘要: 讓我們來回顧一下主流語言的發(fā)展歷程：機(jī)器語言(由01組成) -> 匯編語言 -> ... -> C語言 -> C++ -> Java -> ?
不知道大家有沒有發(fā)現(xiàn)在語言發(fā)展過程中，存在這么一個(gè)規(guī)律：  閱讀全文      摘要: Groovy高效編程之統(tǒng)計(jì)單詞頻率，展現(xiàn)Groovy的魅力 :-)  閱讀全文      摘要: 想必關(guān)注Java的朋友不會(huì)沒有聽說過Groovy吧？的確，由于Groovy的語法與Java極其相近，所以對(duì)于我們這群Java狂熱分子特別友好。Groovy對(duì)于有Java基礎(chǔ)的朋友來說，幾乎可以說是唾手可得！  閱讀全文 Ruby的語法可以借鑒，但其本身的實(shí)現(xiàn)就免了

說Ruby是一種沒有光明前途的語言的原因：
Ruby的Thread是偽線程,不管代碼中寫了多少個(gè)Thread.new,Ruby都只啟動(dòng)了一個(gè)線程去運(yùn)行這些Thread的代碼。
這樣做的確使得Ruby的Thread很容易控制，程序也不容易產(chǎn)生類似死鎖這類嚴(yán)重的線程問題。但是效率始終無法提高，因?yàn)樵趓uby進(jìn)程中，實(shí)際上只有一個(gè)真實(shí)的線程在運(yùn)行，同樣的代碼在那么多核或者多cpu的電腦上運(yùn)行效率和單核cpu的電腦上的效率并不會(huì)相差多少。

你目前在工作站上用的CPU時(shí)鐘速度是多少？10GHz么？ 2001年8月Intel芯片就達(dá)到2GHz，按照2003年前的CPU發(fā)展趨勢(shì)推算，到2005年初，我們就能擁有第一塊10GHz的Pentium芯片。但實(shí)際上沒辦到。而且情況好像越來越糟——我們根本就不知道到底在什么時(shí)候這樣的芯片可以出現(xiàn)。

那么放低期望，4GHz又如何呢？目前我們已到3.4GHz——那么4GHz已經(jīng)不遠(yuǎn)了吧？唉，好像4GHz也遙不可及。可能你知道，Intel首先于2004年中將4GHz芯片的發(fā)布時(shí)間推遲到2005年，而到了2004年秋季，則徹底取消了4GHz計(jì)劃[譯注11]。在本文寫作的同時(shí)，Intel宣布計(jì)劃到2005年早期，實(shí)現(xiàn)到3.73GHz（即圖中的右上最高處）的微量提升。所以，至少就目前來說，時(shí)鐘速度的競(jìng)賽實(shí)際上結(jié)束了，Intel和其他大多數(shù)處理器廠商將把旺盛的精力投入到多核等方向去。

也許，我們某天在主流PC里能裝上4GHz的CPU，但2005年別想。Intel實(shí)驗(yàn)室里的確已經(jīng)有運(yùn)行在更高速度的芯片——不過代價(jià)是驚人的，比如龐大數(shù)量的冷卻裝置。你想不久在你的辦公室里就有這樣的冷卻設(shè)備，坐飛機(jī)的時(shí)候，就把它們放在你膝蓋上？別做夢(mèng)了！

如果應(yīng)用程序想充分利用CPU吞吐增加量，那它們就必然日益需要并發(fā)，這種形勢(shì)逐漸明朗，并將在接下來的數(shù)年里深入發(fā)展。Intel已經(jīng)揚(yáng)言未來他們會(huì)推出集成100顆內(nèi)核的芯片，那么單線程應(yīng)用最多就只能利用這種芯片1/100的潛在生產(chǎn)力。“哦，性能沒那么重要吧，計(jì)算機(jī)總是跑得越來越快”的論調(diào)已經(jīng)變得天真而可疑，甚至在未來不久將完全錯(cuò)誤。

總結(jié)一下我的觀點(diǎn)：
CPU性能提升途徑主要是靠實(shí)現(xiàn)多核，靠提高主頻是沒有多大希望了，而單線程僅僅能利用單核資源，嚴(yán)重浪費(fèi)了多核CPU提供的性能，不幸的是，Ruby的線程是偽線程，即始終僅有一個(gè)線程在執(zhí)行，隨著軟件的日益龐大，Ruby將不得不求助于CPU主頻的提升，但像前面所說的那樣，4G都是一個(gè)遙不可及的目標(biāo)，別提10G甚至更高了。我堅(jiān)信，RoR終有一天不堪重負(fù)，被Java擊潰！?      摘要: 迅雷一道算法題的解答 :-)   閱讀全文 ??????? 每個(gè)問題有很多種解法，但其中存在一種最優(yōu)的算法，據(jù)我觀察和思考，‘懶人’是寫不出那種最優(yōu)算法的，為什么呢？因?yàn)樽顑?yōu)算法有一個(gè)很明顯的特點(diǎn)就是算法本身集結(jié)了人類的聰明才智，讓我來用一個(gè)實(shí)例來證明這個(gè)觀點(diǎn)：

問題：
請(qǐng)計(jì)算當(dāng)參數(shù)為 n(n很大) 時(shí), 1-2+3-4+5-6+7+......+n 的值

‘懶人’解法：
public class Lazy {
? public static void main(String[] args) {
??? int n = 10000;
??? int result = 0;
??? for (int i = 0, flag = 1; i < n; i++) {
????? result += flag * (i + 1);
????? flag =?-flag;
??? }
??? System.out.println(result);
? }
}

‘勤人’解法：
public class Diligent {
? public static void main(String[] args) {
??? int n = 10000;
??? int result = 0;
??? if (0 == n % 2) {
????? result = -n / 2;
??? } else {
????? result = -n / 2 + n;? //由于-n / 2會(huì)舍棄小數(shù)部分，所以無需寫成-(n - 1) / 2
??? }
??? System.out.println(result);
? }
}

人類的智慧為計(jì)算機(jī)擔(dān)負(fù)了不少的計(jì)算量，“懶人”算法的時(shí)間復(fù)雜度為O(n)，而“勤人”算法的時(shí)間復(fù)雜度僅為O(1)，這題的最優(yōu)算法出世了！
忠告各位喜愛編程的朋友，在解決問題之前，請(qǐng)可憐可憐您使用的那臺(tái)精疲力盡的計(jì)算機(jī)吧，花些時(shí)間思考一下，您付出的一分一秒都會(huì)有回報(bào)的 :-)      摘要: 如果您對(duì)選擇Ruby還是Python猶豫不決的話，這篇文章很適合您 :-)
如果想找一種能與Java真正無縫結(jié)合的動(dòng)態(tài)語言，我吐血推薦Groovy ( http://groovy.codehaus.org )，JVM上的JCP官方標(biāo)準(zhǔn)語言。  閱讀全文      摘要: 小弟關(guān)注Groovy已有數(shù)月(您可以到Groovy官方網(wǎng)站 http://groovy.codehaus.org 下載)，發(fā)現(xiàn)其極具魅力，故在我參加的學(xué)校'創(chuàng)新試驗(yàn)項(xiàng)目'中，就用它來實(shí)現(xiàn)最簡(jiǎn)易的ORM，做的非常簡(jiǎn)單，主要原因是沒有時(shí)間，因?yàn)樾〉軐W(xué)業(yè)繁重，所以抽出一個(gè)下午的時(shí)間來實(shí)現(xiàn)一個(gè)簡(jiǎn)易版的ORM，數(shù)據(jù)庫用的是MySQL。現(xiàn)在簡(jiǎn)單說明一下所示代碼，將User類的一個(gè)實(shí)例通過save方法保存到數(shù)據(jù)庫中，然后再根據(jù)給定條件通過findBy方法從數(shù)據(jù)庫中取出實(shí)例，最后刪除一個(gè)特定實(shí)例。由于深知通過XML文件進(jìn)行配置的痛苦，所以在設(shè)計(jì)時(shí)沒有用到任何XML文件。此程序讓程序員只需關(guān)注自己要處理的對(duì)象，而不用關(guān)心數(shù)據(jù)庫方面的東西，簡(jiǎn)化開發(fā)過程。最后我想說明的是，由于時(shí)間問題，所以編碼方面只注重算法的體現(xiàn)，沒有考慮其他方面。下面給出的代碼僅供演示及參考(源碼已經(jīng)上傳，點(diǎn)擊下載)：  閱讀全文