Dennis' Blog of Indiscriminate | I thought what I’d do was, I’d pretend I was one of those deaf-mutes

TAG | programming

Sep/09

10

最近都在寫 C#

唔係好習慣, 特別係 naming 同 IDE 嘅用法。始終 Eclipse 實在太好用啦。

的確 C# 係 language 同 syntax 上面都比 Java 先進,不過個 VS 實在太大食,而且個 Internet 同部機實在太慢啦!!

I miss Eclipse, 我每日至少會講一次

好在我重未老,學習能力同上手能力都依然好高。但係個 Internet 同部機實在太慢啦 (x2)

Java 7 聽左咁耐,都唔知幾時先至有。但另一邊 C# 4.0 好快接近。我係唔係要改我自己嘅 major language 呢?

或者 Ruby?, Python?, JavaFX? 定係 Android? Java ME? 甚至 C++ 呢?

, , , , Hide

Sep/09

4

Code Jam

係極度唔夠訓加差D唔記得情況之下, 做左個 qualification round
總算 Pass 左….

A => easy
B => 睇唔明……
C => small 無問題, 但係個 large set 好慢; 唔知用咩演算法先至會快

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

Hide

Introduction:

A lot of us heard the word cache and when you ask them about caching they give you a perfect answer but they don’t know how it is built, or on which criteria I should favor this caching framework over that one and so on, in this article we are going to talk about Caching, Caching Algorithms and caching frameworks and which is better than the other.

Yet Another Java Blog: Intro to Caching,Caching algorithms and caching frameworks part 1.

, Hide

Nov/08

11

My comment on JavaFX

10 years before, Sun was too early to press RIA with Applet.
10 years after, Sun was too late to press RIA with JavaFX.

I don’t think I’ll use JavaFX. And I don’t think it will not be a success RIA.
But I think that Sun can try. JavaFX will benefit feature improvement on Swing/JMF.

JavaFX will be useful, IF it is the widely used in Netbeans it self.
They will find what’s the problem with it and fix it.

We will have a standard of describe the GUI in Java (even if another JSR to replace the JavaFX later).

JavaFX is “programming” the GUI. but not simply describe it statistically.

Personally, I prefer something like XUL even XAML over JavaFX.
I don’t see how JavaFX can abstract the UI to “any implementation”.

There is an implementation that can almost render XAML in Swing and SWT already.


Please correct me if I wrong.
Is JavaFX Script more like “the ActionScript in Flash”, but it isJava rather then ECMAScript ?

, , Hide

Coding Horror: Programmers Don’t Read Books — But You Should

  1. Most programming books suck. The barrier to being a book author, as near as I can tell, is virtually nonexistent. The signal to noise of book publishing is arguably not a heck of a lot better than what you’ll find on the wilds of the internet. Of the hundreds of programming books released every year, perhaps two are three are truly worth the time investment.
  2. Programming books sold by weight, not by volume. There seems to be an inverse relationship between the size of a programming book and its quality. The bigger the book, somehow, the less useful information it will contain. What is the point of these giant wanna-be reference tomes? How do you find anything in it, much less lift the damn things?

Hide

Mr./Ms. Days (MMDays) – 網路, 資訊, 觀察, 生活 » Blog Archive » [MMDays 專欄] 版本控制,版本升級是不是個問題?

Posted by Mr. Saturday

Mr. FridayJava會步上 COBOL 的後塵嗎? 一文還真是引起了相當多的討論,連在 FunP 上面都有一些高手們長篇大論的回應,另外我也看到了 qing 前輩也寫了篇文章 (剛剛也看到他來留言了) 來參與討論,Friday 也針對一些問題跟我私底下聊了一下.正好我自己也有一些淺薄的經驗,這邊就斗膽拿出來跟大家分享一下.不過我先開門見山地表明自己的觀點好了,基本上我覺 得拿兩個程式語言來比較好壞,就跟拿英文和中文來比較好壞一樣,意義不大.每種語言有他存在的目的和當初被創造的理由,也各有其優缺點,而且語言會因為使 用者而呈現出不同的面貌,真實生活中的語言如此,程式語言自然也不例外.

我比較想要談的,是像 Java 語言版本升級的問題,這也是 qing 前輩著墨甚多的一個問題,底下引述一段:

你沒有必要苦苦追趕Third party程式庫的新版本。通常,在產品開發之前,你就會決定你的技術解決方案,確定你所用的程式庫可以滿足你的需求。在產品開發中途決定更換所用程式庫的major version或到minor version是滿嚴重的事。大多數會需要選定新版的程式庫,多半是發生在選定開發一個新產品的時候。這麼一來,又怎麼會有「程式老跳訊息告訴你這個jar檔版本太舊不是他要的」的問題呢?

對於版本升級這個問題,我認為這絕對是個對工程師影響重大的事情.這邊我想舉出一個另外的例子和切入點,大家就會知道為什麼版本控制和升級會是個大問題.

大家的討論通常會把程式語言聚焦在產品上面.在單純地開發一個產品這方面,可能就像 qing 所講的,你一開始可以選定技術方案,確定所用的程式庫,中途不要亂更換版本,就不會有什麼問題,不過多數的時候在實際上,世界並沒有這麼美好.程式語言的 升級有的時候不只是更改語法或是加入新的 language feature 和 library,很多時候伴隨著升級而來的,是去除舊版本的 bug 和替換舊的 library,甚至於改變某些 function 的行為.這並不是你是否要當一個新版魔人的問題,當 你發現舊版本的 bug 可能會引響你的產品,甚至於你原本用的 function 被 deprecated 掉的時候,你必須去考慮升級,確保日後的相容性和穩定性.即使這件事情是發生在你的開發過程中,你也必須花費心力去評估或做修正,這當然是個大問題.不過 當然,如果你開發的產品是如此地完美,以致於以後所有的版本更新都不會影響到你,那麼以上我說的對你來說就不成立.但我相信大多數的人不是如此.

以上的討論只放在用程式語言開發一個一個獨立的產品上面,各位是否想過,當一個語言成為你全公司的 infrastructure 的時候, 狀況又會是怎麼樣?小弟任職的軟體公司,很不幸地就以 Java 去打造至關重要的 infrastructure.也就是說現在我們公司的工程師不只是用原生的 Java 去開發一個一個的產品而已,Java 這個語言本身已經擴展到全公司,成為很多環境的基礎,包括 parallel programming 的 framework 如 MapReduce;Remote Procedure Call 的 framework 等等,都是 based on Java 打造出來.這種規模和等級已經不是單一產品的問題,而是牽涉到以後所有還沒出現的產品和既有的產品,和全公司上千甚至上萬名工程師每天如何去寫程式的問題.

也因此,小弟公司內部有一個 team 叫做 Java Infrastructure Team,每次 Java 預定要推出升級的版本時,他們就如臨大敵,工作量暴增,必須立刻評估新版本對於全公司的影響,立刻做出反應,這牽涉到的問題多如牛毛,在管理上:有沒有必 要升級是一個問題;什麼時候升級是一個問題;其餘合作廠商是否升級也是一個問題;在技術上:新版本的 performance 是否有差異是一個問題;新版本是否又會帶來新的 bug 是一個問題;對於既有產品的影響又是一個問題;在人員教育上:升級之後的磨合期也是一個問題.請注意,我不是在談單一個人去開發單一產品,我是在說版本升 級 (即使是一點點最細微的更動) 如何同時影響到數千個產品,數千位工程師.在這種規模之下,很不幸地,你必須去苦苦追趕程式語言的升級.我想這也是為什麼 Mr. Friday 會提出版本升級的問題.

也因此,我認為版本升級,當然是個非常重大的議題.

—————————-

這也是我個人不喜愛 SWING 的原因,SWING 在不同版本之間的行為方式差異很大。重點不是畫面!而是操作的方式,一個簡單的 double click, select, highlight, 中文輸入, File Dialog, default look and feel…..等等,完全都不在控制之中。Sun 官方好像沒有想過每次都沒有想過每次亂來都會影響到多少人。

 

, , Hide

Older posts >>

Theme Design by devolux.org