lambdaj – Project Hosting on Google Code.

看過好幾個 LINQ like closure solution on Java 的 syntax

用 lambdaj 的實現的 “Hello World” 也可以說是最簡單和和 Programmer Friendly

Java 相比 C# 係實現 LINQ / closure 最大問題係原自 Language Syntax

在不改變 Java Language 本身嘅情況下, 最多都只係類似 lambdaj 那種 很多很多 (((會眼花) 好易打錯(的多層 static method lambdaj)) 寫法
而且大量利用 Proxy 和 static method 的情況下, 程式的可讀性會出現問題

C# 有 delegate (a.k.a function pointer), 而且 delegate 都是 strong typed 的, 有很多都可以利用它來簡化
C# 甚至加入近幾狂亂的 Expression 去簡化往日很多由  programmer 的好多手工作業 (雖然我唔知道除左 LINQ 重有咩地方會想去用 Expression….PF? WF?)
C# 加入了 Extension Method 去修正先後次序的可讀性問題

我最近在 C# 實作了動態 ExpressionTree Builder ……..對把這種功能整合到 Syntax 和 Compiler 有很深的體會, 那真的簡單很多很多很多

C# 3.0 很美, 但 Visual Studio 卻…..唉~~~ 都是 Eclipse 的錯………寫不到 C#

Java 7, 依目前我所知的, 是跟不上 C#

No tags Hide

早幾天看到朋友 forward 過來的一個只用純 JavaScript 實作的NES Emulator (No Flash, No Applet, No SliverLight, No ActiveX, No Native Client)

以前都沒有想過 Script on Web 都可以寫到這樣的程式

今日清理 Feed 時又看到 HTML5 的 News。

突然想到如果 Google 可以成功爭取 3D engine 同一大堆表面上對建網站沒有甚麼用功能加進去會如何？

不得了，那有可能全面替代 Rich Client 的地位。有部份應用程或是 client app 的原因只是 API 支持不足(另外就是檔案存放的機密性)，只能寫個 exe 或 plugin 來實現。例如 GTalk 或其他 IM，Adobe Reader, Google Earth, MS Office Reader, 各種的 Game 和 media player。

如果是在 LAN 的話，network 的 latency 和 broadwidth 該不是個大問題。

Google Earth 整合進 Google Map 不是不可能。Web Office 也能在無 plugin 之前進行很多操作。

再過五年 IPv6 和 Internet 都該有很大的進步。Browser 和入門硬件的世代替換。那樣的話，對軟件開發者來說用甚麼都是開發和發佈的影難度的決定了。

Flash 可以說已步入未期，獨佔太久市場卻沒有甚麼大作為…..這間公司只會賣開發/editor工具和硬件 license 賺錢。

JavaFX 我完全不看好….我完全找不到 killer application….而且Oracle 未必會跟著 Sun 的路走。

Sliverlight, MS 持著 .NET 統一開發的語言環境和技術，該有作為…..問題就是潛在昇温的 non-windows platform (Linux, Chrome OS, Apple) 特別是手機和 mobile device 的性能和市場越來越大。

HTML5 的問題就是開發難度。Javascript 的奇怪和 Cross browser 的困難可不是說笑的（其實不是 Web 也有 Cross OS, Shell, Theme 和 service pack 的問題）。但如果是像 GWT 一樣利用整合簡易化的方式呢？

如果 HTML5 提供的API完全做到 Fat OS 的 80%的事，那樣用 Chrome OS 也很合理。Cloud Computing 也很付合環保的原則。

Google 的野心和目光真的很大很遠

BTW….會有一天出現 SNES, GBA, SS, PS, PSP, NDS 的 Javascript 版 emu 吧… If there is a  possibility to happen, it will happen.

No tags Hide

Doug on the Eclipse CDT: Eclipse OS?.

突然想到，Chrome OS 這一類 Application OS 不只可以用在小形硬件上。而且還可以用在 Visual Machine 上。只要 overhead 做得夠少、夠快，利用 VM Cluster 實現 hardware resource management 的潛力還不少。

遠比 Terminal Server 更加減少配置沒有用到的 resource，彈性更高。

Terminal Server 配置了 4GB 就是 4GB，不會因為負載少而可以把 memory 空出來；負載高的時候，也必需設置另一台 Server 來分流。

但 Application OS 就可以做到，只需把 VM Host 的 cluster 加大／減少即可。
而且閒置了的 resource 是可以被任可 VM Guest 便用。人再多，開的程式更多，也不需要 user 重新登出登入另一台 server 來再分配。

Cons: 每個應用都有一個固定的 memory space 上限，而不能動態負載。

chrome os, Eclipse, vmware Hide

Official Google Blog: Introducing the Google Chrome OS.

我想 Chrome OS 最大的目的，不是甚麼進佔ＯＳ界／Linux 。
而是更大限度的消除由 “甚麼都沒有” 到連上網絡到 Google 的總成本。

可能有人會問，Linux 不是已經是免費的嗎？

但事實上，不用買不代表不用花費去管。

Windows 很易用沒錯，可是還有管理、防毒、安全、更新、錯誤更用等等潛在成本。這種成本在 Linux 上就更高了。

一個簡單而有效率的 OS  去運行 web apps 對 Google  來說是十分重要的。也就是不會死掉，出問題不用拿去修理，也不會出現安裝了一大堆垃圾而 unstable 或變慢。像電視機一樣。（…….目標大概比大家的手機要好吧？）

而在 Linux 為本而再發的原因，大概是成本的問題吧？ Don’t reinvent the wheel….unless it has problem/ it won’t fit.

google, google chrome Hide

Case of the Unexplained 3 [WCL303] – Microsoft® Tech·Ed Online.

windows Hide

Life’s Passion » Blog Archive » Eclipse VE gets revived!.

Welcome back of VE in Eclipse stream after more than two years’ sleeping

Eclipse, Java, VE Hide

網摘: The Joel on Software Translation Project:無痛軟體時程 – The Joel on Software Translation Project.

9)把除錯時間排入時程！除錯是最難估計的。回想一下你前一個專案。除錯所佔的時間很可能是把程式寫出來的一到兩倍。所以時程中一定要加這一項，而且這有可能是最大的一項。

實際的作法如下。讓我們假設一位開發人員正在做某件工作。Orig Est是16小時，不過到目前為止已經用了20小時，而且恐怕還要再做10小時。所以開發人員在Curr Est和耗時欄分別輸入30及20。

等到達里程碑(milestone)時，這所有的「落後」加總起來可能會有相當數量。理論上為了因應這些延誤，我們必須削減功能才能準時上市。幸運的是可以削減的第一項功能就是名為緩衝(buffer)的功能，而這個項目一開始就排了很多工時。

原則上，開發人員會在寫程式時除錯。程式員在應該除錯時絕對不該寫新程式。基於兩項原因，隨時都應該讓錯誤數目儘可能的少：

1)在寫出程式的同一天除錯會比較容易。如果一個月後當你忘記程式運作細節時再來除錯，就會變得非常困難而且要花很長的時間。

2)修正錯誤就像科學活動。不可能估計何時能有發現並解決問題。如果隨時都只有一兩個主要的問題，表示未來無法估計的項目不多，所以很容易估算產品推出的時間。反過來說，如果主要的問題有幾百幾千個，根本就不可能預測什麼時候才能把問題全部修好。

如果開發人員總會在寫程式時就把問題修好，為什麼還要加上除錯項目呢？有道理，不過即使在寫程式時儘量修好所有的問題，在到達里程牌時，測試人員(內部或外部)總還是會找到真正困難的錯誤，難免要有許多除錯的動作。

10)把整合時間排入時程中。如果你的程式員不只一位，難免會有兩人不一致的事情需要協調。他們會各自建立功能近似的對話框，這當然需要協調。必須有人細查所有功能表、鍵盤快速鍵、工具列工具等等，並且整理及組織所有大家不得不加的新功能表項目。另外只要有兩個人把程式登入就會出現編譯錯誤。這也得有人修正，而且應該列入時程。

11)在時程中加上緩衝時間。事物總是容易用完。你可能要考慮兩種重要的緩衝。第一種：預防工作耗時超過預期的緩衝。第二種：針對未預期但必要的工作的緩衝(這通常是因為管理階層決定某功能超級重要，絕對不能等到下一版)。

你可能會很驚訝地發現、休假、國定假日、除錯、整合還有緩衝時間加起來超過實際做事的時間。如果被嚇到表示你程式寫得還不夠久，不是嗎？你要忽略這些項目的話後果自行負責。

12)絕對不要讓經理叫程式員縮減估計時間。很多菜鳥軟體經理認為能用精細「緊密(短得不切實際)」的時程，「激勵」程式人員做得更快。我認為這種激勵根本是腦袋壞掉。當我進度落後時，我會覺得內疚消沈毫不積極。當我進度超前時，會非常快樂而且充滿生產力。時程可不是玩心理遊戲的地方。

programming Hide