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

TAG | programming

Oct/07

27

Google Collections Library

http://www.javalobby.org/articles/google-collections/

http://code.google.com/p/google-collections/

 

原來 Google 也有以 Apache License 推出的 collection library。

讀了一下上文和它的 API ,的確是一套不錯的 collection framework

  1. 它以 Java 5 為目標,不像其他已流行的 library 為了向 1.4 相容而浪費 Java 5 的 Generic Type
  2. 有很多常用實用而卻沒有通用的元件,例如 MultiMap 和 Join
  3. 以 Apacle Style Licnse 2.0 發佈,應用起來沒有版權的問題
  4. It is Google
  5. 可惜就是還太早了,還是 0.5(alpha)。也就是可能到能流行之前可能會有大改動。

 

, , , Hide

網摘: IT亂談 – 網絡暴民 Jacky’s Blog

早前聽回 Talkonly 談本地 IT ,討論到其中一個痛點是:香港普遍不太尊重 IT人才,但在這個資訊科技的年代,往往有很多 mission critical 的工作其實都落在 IT 人手上。近年也開始有這些新聞,如市民私人資料洩漏到網上、八達通增值失誤等等。然後節目談到專業人員如律師、醫生等會有工會組織、專業認可等等以保持質 素。

其實單單說 IT 界是很模糊的,寫軟件的、做硬件的、做維修的也可以說自己是 IT 人,當中包含的工種十分多。因此在這裏先將範圍收窄到寫軟件的吧!要問的是,既然現時資訊科技影響越來越重要,我們要如何確保軟件的品質?老闆在請人時又 如何以確保那個人是合符標準的?其一最簡單直接的就是認證。

先說個人方面,市面上有很多不同的認證,有網絡、伺服器、特定軟件操作、 程式語言的認證等等。我覺得如果是一些管理工作的如 network admin、db admin,這些認證會相對的「穩定」,變化可能不太大。但對於實戰人員 programmer、SA 等等,變化會很大。突如其來一個 web2.0、ajax、ror… 技術越來越多樣化。市面上的認證又能追得多快?提供多少保證呢?

節目中也有提到市場上有很多 java programmer,這可能是因為本地的程式主要為企業應用相關,要考慮到如 transaction、messaging 等等的要求,而如 j2ee 就提供了方案。如果只是做簡單的網站,則未必會考慮到使用 java。然而,java 世界也是變化萬千,幾年前大家埋頭苦幹寫 ejb,到現在 spring 大行其道,受到 ror 影響而令人注意的 scripting language 如 groovy 或 jruby,提倡 tdd、agile 開發等等。技術更新得太快,無論是老闆或是開發的,也許都未及反應,也不知道那些認證真的能保證些甚麼。 (當然老闆在挑選人才時應該不單單看認證,還要看人的質素之餘此類,但眼光並非個個有。這可以扯到另一個節目談到的話題:全人教育之上。)

從 企業層面去說,要確保軟件的品質,除了要請對了人,也要做對了事,也就是企業內各種工作、程序有沒有被管理好?標準化?其中有一些認證如 CMM 就是用來確保企業的工序品質。我不太清楚有幾多香港公司會拿 CMM 認證,但也曾在認證是 CMM Level 3大機構待過,感覺是的而且確會很有幫助,但必需要有全面的配套配合,如軟件、人手、分工等等。因為 CMM 事實上會做很多 documentation,而如何又快又有效地寫這些文件,則成為實作成功的關鍵之一。可是,這往往是大機構才會有人力物力去搞,中小企搞起上來如果不 知其法,可能吃力不討好,反而增加了工作量。

這些證認或許能提供參考,但是否能提供很好的保證呢?能否有效防止軟件漏洞做成的衝擊?這是很難解答的問題,但也是必需回答的問題,因為我們已經走上不歸路。

P.S. 本篇沒有甚麼數據支持,因此有可能推論出錯。有錯的話還請大家指正。

 

 

, Hide

網摘:What’s the definition of "code reuse"?

The fact of the matter is everybody’s code sucks except your own. That why nothing is ever re-used. What’s more important though is that this doesn’t matter as long as the tests are re-used. That’s the real value of old code…

, Hide

在我接觸過、正式上課/自修學過、拿過 O’Reilly 的書反復讀過、真實應用當中使用過這麼多種要非Script/非洐生工具類的(要編譯的)程式語言當中。

我始終還是覺得 Java 最好(只限語言本身~!)

主要是因為它的簡單語法和其易讀性吧?雖然它也有不少問題,但相比其其他現代程式語言(.NET),用Java 寫出來的碼的可能有的隱性的潛在問題相對會比較少,易讀和未執行前預料執行結果。

注1:  Script 用法有別所以不比較
注2: 洐生工具是指 JSP, ASP.NET 或類似的

, , , , , , , , Hide

Sep/07

8

在 Java 中時間的不可信

或許沒有太多人留意這一點,相比起其他程式語言或執行平台,你在 Java 中得到的時間或作出時間運算會相對地不準確,甚至會變成一件十份危險的事。

先簡單講一下在 Java 有關取用時間的基本方法。

在 Java SE (a.k.a. J2SE) ,主要有三種方法取得 “系統目前時間”

  1. new Date()
  2. Calendar.getInstance() (since JDK 1.1)
  3. System.currentTimeMillis()
  4. System.nanoTime() (since JDK5)

而當中,頭兩種方式都是 currentTimeMillis() 的洐生工具,所以正確來說,在 J2SE 1.4 或之前的系統只有一種方法取得系統時間。

而另外,有主要兩種基本 Timer (定時執行) 的 Class (JMX 那個不算基本)

  1. java.util.Timer
  2. javax.swing.Timer

而它們有甚麼問題呢?如果你有留心而認真讀過 API 的話 (我想大多人都沒有),就會發現大部份 Java SE 的 native method 的定義都不清楚不仔細,甚至模糊不清。而 System.currentTimeMillis() 可說是其中的代表:

Returns the current time in milliseconds. Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds. See the description of the class Date for a discussion of slight discrepancies that may arise between “computer time” and coordinated universal time (UTC).

那裡模糊不清了?…the value depends on the underlying operating system and may be larger…也就是說,假如某某自行實作了一個 JRE,但 currentTimMillis() 的準確度可以是千份之一秒,百份之一秒,秒,分,時,日,月,甚至年,跟本沒有上限或參考值。雖然說,在現實應用不太可能會出現如此瘋狂的情形,可是,差 50 份之一秒的準確度,對現實應用可能有很大的影響……例如音效或動畫播放、微統計、Game 甚至一般 Log、Concurrency 或 Transaction 也會被這個數字影響。別忘了,你的電腦的運算速度是以 MHz 和 GHz 為單位的。

它很危險的第二個原因是,它取得的是系統目前時間。(舊)書本和例子會告訴你,要知道它花了多少時間,或等侍一段時間,可以取得兩個 currentTimeMillis 然後相減。很簡單而合理對不對?可是呢,因為它是系統目前時間,所以如果系統時間在過程中間有所更改的話,得到的數字就一定是錯的了,甚至你會得到負數的運算時間。可能你會說這沒甚麼大不了,我們很少會改動系統時間。如果你這樣認為的話就錯了,事實上現在的電腦的系統時間經常更新,現在大多 OS 都已內置 NTP Client,每一段時間就會自動嘗試和 server 同步,如果你發現電腦的時鐘突然向前或向後跳動十數秒的話不用害怕。雖然科技很先進,但 NTP本身有一定誤差,而 hardware clock 每星期有幾秒誤差也很平常(因為是平民用而要求不高的科技)。而上述提到的 Java SE 內置的兩種方法,在 Sun 的JRE實作直至 Java SE 6.0 都是用 System.currentTimeMillis() ,這會在 Java SE 7才會等到修正。

那有甚麼方法去修正呢?如果你想到 Loop + sleep/wait 的話,你就走進了另一個模糊不清的陷阱-它們都是不準確的。

精明的你可能留意到我還沒有提到第四種方法:System.nanoTime()。沒錯,它不但單位比較仔細,而且它不使用系統時間,而是一個相對的任意時間。我個人比較相信,Java 引入這個 method 的原因只是 為了滿足 java.util.concurrent (源自 Doug Lea’s util) 的需要,所以他們沒有在 J2SE 1.5 版本把 JRE 當中其他 currentTimeMillis 相關的程式碼修正。

幸好,其實這個問題早在遠古時期已有人發現而且作出 bug report(但沒有修正),多年後隨著 JSR-310 Date and Time API(未完成) 的討論和發展而將會得到解決。

在 Java 7 以後,終於可以不用再和垃圾和煩人的 java.util.Date 和 java.util.Calendar 搏鬥,也可能不必再用 long 來作時間運算。JSR310 將會引入幾種新的概念入 Java:

  • Instant
    • 即 timestamp,用 ns 為單位而支持比宇宙年紀更長的時間。這一下再沒有千年蟲了吧?
  • Human-scale datetime
    • 年用日時分秒等等相關的概念和 API
    • 例如 “四月一日”可以不再指明是那一年
    • 例如 “9 am – 11 pm” 之類時間可能有一個通用的 object 和運算 API
  • Interval
    • 大概是 “日曆” 之類的,不知道中文如何說
    • 例如:今日下午3時開一小時會議
    • 例如:今日 1500-1600 有一個會議
  • Duration and Period
    • 這兩個好像是時間的長度
    • Duration 是數學/科學上用的
    • Period 則是用生活上的時間
      • 例如: 一日, 15 minute, 半年

好像越說越遠了,先回到主題-在 Java 中時間的不可信。

在其他語言或平台,不是運用的方式不會要求太高即時準確度(如 Perl),就是已經有不錯的 API(例如  .NET ),甚至只因為有 OS 依賴而擁有確實能參考的準確度,也有很多不同的方法去取得不同的時間(例如: system uptime, process uptime, hardware clock)。而 Java 則受 JVM 和 Cross-platform 的自我要求所限而必需透過 JRE 更新來修正。

上文提到的是,在 Java SE 的場合。而在更複雜的應用當中,會出現 Client, Server, Cluster 和 Network 等等多部機器,多個時鐘和 latency 而引起更多問題,不過這就不是 Java 單獨面對的問題了。

參考:

P.S.

很久沒學/寫技術相關的東西,怕自己越來越懶散……..

, , Hide

  1. The Law of the Ritalin Child
  2. The Law of the Distracted Spearfisherman
  3. The Law of the Overstocked Haberdashery
  4. The Law of South African Crime
  5. The Law of the Leaked Memo
  6. The Law of the Corrupt Politician
  7. The Law of the Micromanager
  8. The Law of Greek Driving
  9. The Law of Sudden Riches
  10. The Law of the Uneaten Spinach

, , Hide

<< Latest posts

Older posts >>

Theme Design by devolux.org