翻譯：Java簡史(A Brief History of Java) by Jeff Foster

文章：A Brief History of Java（Java簡史）
日期：2010.08.13
作者：Jeff Foster
作者的部落格：Fatvat : Exploring functional programming


Java簡史

話說當年1995之時，昇陽(Sun)公司釋出Java程式語言，做為整個Java平台策略的一部分，當初喊著“一次編寫，到處運行”的口號，要讓Java遍地開花，從腕錶到手機到筆電到超級電腦，隨處皆可運行。

剛開始時Java的接受度有高有低，當出現Java力有未逮之處，就會有福音天使出來保證這技術將會改變世界，你看，靠Java運作的烤吐司機就在不遠的角落了。

隨著時間演進，為了守住“一次編寫，到處運行”的承諾，Java也逐漸背上更多的負擔，標記為廢棄的方法(deprecated methods)到處可見，但昇陽必須留下這些功能來保持向後相容性；java.util.DateTime此套件變成了劣質設計的同義字，差勁的命名規則總是在修正中（叫它size好還是length好呢？）。

微軟(Microsoft) 的.NET開始蠶食Java的領地，微軟團隊導入delegates，一種有做型別確認的函式指標，使得事件處理(event handling)變得容易許多；Java要趕快反擊，所以在版本1.1時，Java生出了inner classes，能夠有類似的效用，但以一種較有限制與用起來較麻煩的方式出現，一份Java白皮書斷定地說『bound method references是不必要的東西....這玩意減損了Java語言的簡單性與一致性』，但與此同時，將bound method references放進Java裡的勢力從沒消失過。

當Java到了版本1.4時，為了對抗微軟的.NET，昇陽決定要有一套新的策略手段，思索良久之後，昇陽將版本1.4改成“5”，試圖一舉超前.NET的2.0。

同時間附帶了另一個決策，實作generics，一種能夠有額外的型別安全檢查的技術，不幸的是，隨型別安全而來的代價是要多打字，工程師引入generics後，每次又要寫一遍List<Foo> foos = new ArrayList<Foo>敘述時，就會常被聽到咒罵聲。




大學很快地就接納了Java；學生們不再需要學習手動記憶體管理與指標的種種艱澀難懂的奧祕，反之，他們可以依賴Java來做這些苦功夫，集中精神在解決問題上，不幸的是，這也導致一批同等級的開發者，被稱作“設計模式使徒(Patternistas)”，手上只有鎚子且把所有問題都看做釘子去敲，在他們的領導下，Java命名規則越來越可笑，當這種類別名“RequestProcessorFactoryFactory”成為一種常態時，一些開發人員開始質疑無限制地構築抽象化高塔是否真為明智之舉。

當開發人員意識到他們終日所為僅是把數千行的程式碼搬來搬去而已，他們需要一個字眼來辯護他們的存在意義，那個字就是“重構(refactoring)”，所有的設計模式使徒欣喜不已；他們不但能運用工廠的工廠模式(factory factories)、獨身模式(singletons)與訪問者模式(visitors)來解決問題，而且還能朝三暮四改變心意，並用個時髦字眼來正當合理化！

整個產業的演進方向只是為了滿足設計模式使徒們而已，跟別人與別的語言比起來，老鳥們覺得Java越來越弱，所以新型開發環境出現了，IntelliJ與Eclipse的目標是將開發人員受的傷害最小化，靠著極佳的程式碼自動補足機制(code completion)與重構功能，只需按幾個鍵而不用輸入一長串的程式碼來達到那想要卻沒有的語言功能。




Java開始向企業端進攻，招攬了一些有領導地位的的架構大師，打造出一套會造成典範轉移的協同式架構方法來建置企業軟體，其結果不小於一場革命；爪哇豆(beans)現身了，Beans顯然是一種伺服端的元件架構，用來當企業應用軟體的建構基本模組。

使用generics所帶來的角括號障礙一旦減低之後，Java邁步向前跳上了XML的列車，藉由使用XML，開發人員就能將簡單明瞭的概念表達成一整個龐大囉嗦的角角惡夢，好處是XML檔案（不同於其他檔案類型）可以輕易地被電腦看懂處理，至於對人難以閱讀這種小代價是值得的，像是Ant和JBoss這些軟體都是由可執行的XML所建構出來的。

與此同時，在這些架構大師的宇宙之外，一群新種程式員認為將該死的工作完成遠比一整天都花在打字重要，這種想法誕生出一些框架，例如Rails，設計的重點在於不擋路讓你能解決真正的問題，其中心思路以“約定俗成先於設定(convetion over configuration)”之名廣為人知，Rails獲得正面的迴響，而且至少有一些Java信徒轉投向Ruby的陣營；Java不再能緊抓人心的第一個徵兆開始浮上檯面。

2006年8月，Java 7計畫啟動，很多開發人員都要求一個叫做lambda expressions的功能，毫無疑問地會簡化很多原先Java搞的很痛苦的撰碼作業，可惜，Java委員會四年後還在為這項功能的細微差別爭辯不休，而且有可能會被排除掉，Java 7的無作為引出了新一代更迷人的語言，例如Clojure和Scala，設計在Java環境中運行，但不需要Java語言。

2009年4月，甲骨文(Oracle)公司宣布計畫將收購昇陽，此乃敲下棺材釘的最後一鎚，由“黑暗王子拉瑞”所領軍的甲骨文是一部併購機器，擅長於企業軟體與賺進大筆鈔票，當甲骨文的律師們了解一份份的軟體專利文件，他們會挑個大目標然後引起戰鬥，而還有哪個目標比谷歌(Google)更大呢（一家網路廣告的領導品牌），所以甲骨文的律師猛撲而出，戰爭就此展開。

這會給Java帶來什麼後果呢？從15年前的小小開端起，在昇陽的領導下，Java爬上了最熱門的程式語言的頂端，而在甲骨文的控制下，不但到底會不會有下一版的Java情況不明，更別提開發人員渴望許久的功能了，這是Java的新開始還是結束呢？

翻譯：命名專案的十項提示(10 Tips for How To Name Your Project) by J Wynia

文章：10 Tips for How To Name Your Project（命名專案的十項提示）
日期：2006.06.22
作者：J Wynia
作者的部落格：The Glass is Too Big


命名專案的十項提示


這已經是數年前我寫的一系列文章中的一篇， 但我想要再次分享出來，考慮到有這麼多人開發的產品與服務的名字，居然需要落落長的解釋與說明，才能夠了解、念出來或是正確寫出來，我想這篇的內容仍然還是跟我當初寫的時候一樣重要。


命名你的專案的方法（與避免事項）


1. 如果你想到的名字是直接取自於某科幻或奇幻小說、電影、漫畫等等題材，放棄吧，在軟體業中這些都已經被用爛了，不僅想出有原創性的名字的可能性相當低，而且，科幻題材中大部分的角色與地點名稱都已經被註冊了，你有被告的風險。

2. 如果你是從希臘、羅馬或古北歐神話中取材，再嘗試別種作法看看，我們不知收到多少封談到以“墨丘利(Mercury)”命名的軟體的電子郵件。

3. 拜拜股溝(Google)大神，找找你想要取的名字，找到的項目越少越好，如果什麼也沒找到，恭喜你囉。

4. 如果你想要錯拼幾個字母來打造獨特的名字，別！把你嶄新的視窗膽案系統稱作Phat32，使用者在搜尋引擎只會看到關於“fat32”的結果，你覺得他們會高興嗎。

5. 如果你取的名不能在五零或六零年代的電視上說出來，你的方向大概是錯的，特別是當你想要產品在工作環境中被每一個人使用，如果單單念出產品名就有可能會被告性騷擾，那自然沒人會推薦給同僚。

6. 如果你的產品名連發聲念出來都是件不可能的任務，你就得不到口耳相傳帶來的好處，同樣的，如果沒人知道怎麼念，人們也就不會試著大聲說出來詢問相關疑惑。你怎麼念MySQL？PostgreSQL？GNU？幾乎所有地球上有人用的語言都是有某種子音/母音的音節系統，輪流使用子音與母音來拼名字是個相當好的方法，確保某人可以發音出來。

7. 跟女人的裙子一樣，越短越好。

8. 查看看.com的網域名稱是否可用，如果已經被申請走了，這是一項很好的指標，表示某人已經想到這個名字而且比你搶先要用它。做這個動作即使你不打算申請網域名。

9. 別把產品本身的限制條件加在名字上，把產品叫做LinProduct或是WinProduct的話，那將來要釋出跨平台版本怎麼辦。

10. 別把你自己的姓名用在開放原始碼計畫上，如果將來你不再參與，那這計畫就必須改名，或是你的名字將會以你不喜歡的方式被運用。

翻譯：專案之名有什麼意涵？(What's in a Project Name?) by Jeff Atwood

命名，看似簡單卻絕不容易，啟動新專案要有個codename（內部專案代碼），寫程式要替變數、函式、類別取名，當專案完成變成產品，那也要有個又酷又炫的名號；取的好心情佳，取的不好整天就不順；看看這篇關於專案命名的文章吧。


文章：What's in a Project Name?（專案之名有什麼意涵？）
日期：2007.11.12
作者：Jeff Atwood
作者的部落格：Coding Horror


專案之名有什麼意涵？

從我進Vertigo公司以來，曾經參與過這些個專案：

• 米開朗基羅(Michelangelo)
• 納許(Nash)
• 威士忌小鎮(Whiskeytown)
• 超大硬糖(Gobstopper)

這些我們內部使用的專案代碼，是從一份放有各種“東西”的清單中按照字母順序選出來的，每個新專案都是這樣被命名的，我們從A開始用，當到Z用完時，我們會選出一組新的清單，作為命名專案的靈感來源，你可以猜出上述專案名的靈感清單從何而來嗎？別偷看啊！

關於專案命名，我們有以下這些鬆散的方針：

1. 我們偏好一個單字的名字。
2. 必須相當容易就可以念出名字來，拼出來也很簡單。
3. 對客戶來說須是親切適宜的。
4. 在整個公司內這名字必須是獨一無二的，沒有重複使用。
5. 我們需要一個夠多的靈感清單可以選，照字母順序。

當然，一篇關於命名的文章若要說得上完整，就一定要引用於達康(dot-com)狂熱之最高峰時出現在線上雜誌-沙龍(Salon)的經典大作，命名競賽(The Name Game)：

最後，嘗試將命名一個專案所帶來的利益加以數字化，就如同試著量化一個名字所能帶來的好處，可能兩者同樣都很眼光狹隘，對一個找到跟他們一拍即合的命名商的幸運客戶來說，其邊際效益遠超出單純的取個名字，有新的詞彙字可以學，好玩的遊戲可以參與；還有，以百猴（一家幫人命名的公司）的例子來說，無可懷疑的溫暖與關懷，『我們得到的遠超出單單一個名字』九十八點六(98point6)的羅賓巴爾這麼說，『我是說，我替我女兒找了個好名，我們一個資深董事對‘梅斯卡蘭札(Mescalanza)’有強烈的認同歸屬感，大家不再稱呼他為吉姆(Jim)，他的名字就是梅斯卡蘭札。』與此同時，她還說，『我們網路開發部門的資深經理就莫名地愛上了‘果醬餅乾(Jamcracker)’，以致於，哈維(Harvey)會議已經改稱果醬餅乾會議，這家公司有三百個人將果醬餅乾視做哈維的代名詞。』

巴爾用手捂住嘴巴，『喔天啊，』  她說，『我忘了，我不應該向一個記者提到這些名字，技術上來說，我們沒有這些名字的所有權，果醬餅乾這名字仍然是百猴的資產。』

巴爾停頓了一下，好像在思考些什麼，然後她爆笑起來，『聽著，』她說，『我收回剛說的，你想寫啥就寫啥，如果外面真有人想要將他們的公司命名為果醬餅乾，願神保佑，也祝他們幸運。』

不論如何，困難點在於，如何生出一些新的靈感用來激發專案命名時的來源，我們先看看微軟的專案代碼以及蘋果的專案代碼，當做想法的出發點，

這裡是過去不同時間點時，我們考慮用來命名專案的各種想法：

食物種類 電玩遊戲（Atari 2600，大型機台， 等等） 啤酒品牌 羅馬帝王 卡通人物 / 節目 神話中的名字 / 神祇 汽車 GUIDs （個人最愛之一） 寶石 咖啡飲品的種類 州名 鄉村名 植物 希區考克的電影

狗的品種 顏色 著名的探險家 樹木 美國稅務表 英國君王 名人（例： 沙岡） 維基百科文章名 單一字母（包括萬國碼） 無線電通訊的字母系統 糖果品牌 恐龍 歷史地點 城市街道名 IKEA宜家家居產品名稱

扣件種類（螺帽，螺栓，鉚釘，等等） 滑雪度假村 國家公園 山之顛 第二次世界大戰時代的船隻 鳥類 海灘 橋 Web 2.0的命名 魔獸爭霸的王國名 起司 國家 穀類早餐品牌名

如果有我沒列出來，但你認為是命名專案的好點子的話，還請留言。

開新專案之時，挑選一個新名字總是有其樂趣所在，我很驚訝我們很快就用光一整個A-Z循環，從我進公司的2005年算來，我們已經經歷過4次循環了，那是我們的作法，那麼，你又是怎麼命名你的專案的呢？