2014年5月6日 星期二

如何扮演程式經理的角色? - How to be a program manager

如何扮演程式經理的角色? - How to be a program manager


Scott Berkun,  Making Things Happen
Steve Krug, Don’t Make Me Think
Joel Spolsky, User Interface Design for Programmers
Dale Carnegie, How to Win Friends & Influence People


怎麼學習當個程式經理?

作為程式經理是一種學習:學習技術、了解人性、搞懂怎麼在組織政治裡有效率的做事。好的程式經理能把工程師的想法整合到設計裡,並像政治家一樣把人聚在一起並建立共識。當你在做這些事情的時候,可以讀一讀這些書:
Scott Berkun 的「Making Things Happen」是唯一一本內容涵蓋了程式經理所要做的事情的書。所以從這一本開始吧。Scott 曾經在 Internet Explorer 團隊擔任多年的程式經理。
程式經理的一大部分工作是設計使用者操作介面。首先可以讀 Steve Krug 的「Dont Make Me Think」,然後是我寫的「User Interface Design for Programmers」。
最後,我知道這聽起來很俗氣,不過 Dale Carnegie 1937 年寫的「How to Win Friends & Influence People」真的是的超棒的人際關係入門書。這是我所指定的在 Fog Creek 裡受訓的經理人要閱讀的第一本書。這些人一開始總是在私底下竊笑,不過大家在讀完之後都會愛上這本書。


2014年5月4日 星期日

找尋偉大開發者 - Finding Great Developers

 找尋偉大開發者 - Finding Great Developers  (翻譯中)


偉大的開發者,事實上,每個領域最優秀的人才,根本從來不曾出現在人力市場上。

平均來說,偉大的開發者在他們整個職業生涯裡,總共也許只會應徵四份工作。
優秀的大學畢業生會被與業界關係良好的教授拉進暑期實習,他們很早就拿到合約,從不用煩惱找工作的事兒。如果他們離開原本那家公司,通常去跟朋友合作創業,或跟著頂頭上司跳槽到另一家公司去,或者他們真的決定想要,例如,替Eclipse工作,只因為Eclipse很酷,所以他們去BEAIBMEclipse相關的工作,因為他們非常優秀,當然就拿到工作了。
如果你夠好運,真的真的很好運的話,他們會在公開的人力市場上露一次臉,他們的另一半決定要接受地點位於安克拉治(阿拉斯加的一個港口)的醫學實習,他們才會真的送出求職信到少數他們認為在安克拉治可以工作的地方。

但大部分時候來說,這些偉大的開發者(這幾乎成了贅詞),嗯,很偉大(好吧,這真是個贅詞),而且,未來的雇主通常很快的認識到這些人的偉大之處,意思是說,基本上他們想要就可以找到工作,所以他們實在不需要投一大堆履歷或申請一大堆工作。

這聽起來像你想要雇用的那種人嗎? 鐵定是的。


有個獲取潛在的傑出人才的好方法 -- 
在他們出現在人力市場上以前就先得到他們:從大學裡。

一些人力資源主管不愛雇用實習生。他們認為實習生尚未成熟且技能不足,在某種程度上這個想法並沒有錯。實習生不比資深員工來的有經驗。(真的嗎?)你需要在他們身上多投資一些,而且要花點時間讓他們上軌道。好消息是,在我們圈子裡,真正偉大的程式設計師通常從10歲開始寫程式。其他同年齡的小鬼們還在「踢足球」的同時(足球是許多不會寫程式的小鬼玩的遊戲,玩法涉及用腳踢一個叫做「足球」的球狀物體 -- 我知道這聽起來很怪)他們卻在老爸的工作室內試著編譯Linux Kernel呢。與其在操場上追逐女孩,他們在 Usenet上和網友論戰著程式語言若沒有 Haskell 風格的型別推斷是全然的墮落;與其在車庫裡練團,他們修改了韌體讓偷用未加密的無線網路頻寬的鄰居,看到的圖片會是上下顛倒的。姆哈哈哈!
所以,不像法律或醫學領域,軟體開發領域裡的學生們,在大二、大三時就已經是超「棒」的程式師了。

....
當動用到親自面談時,我們有很高的機會雇用這個人,該是啟動正式招聘的時候了。我們在機場碰面,並由穿著制服的轎車司機連同行李將他們送往市中心鬧區(可能是他們看過最豪華的)酒店。隨時有時尚名媛進出、別緻的衛浴裝飾可能是博物館的典藏展品,他們可能要花點時間在五星級酒店裡學著刷牙。我們在客房內留給他們一個包裹:一件T恤、Fog Creek員工寫的紐約必遊景點地圖、2005年實習生紀錄片DVD。房間內的DVD播放機放著前屆實習生的有趣畫面。
經過一天的面試,我們邀請這些學生留在紐約幾天免費遊覽(如果他們想看看這城市)然後再由豪華轎車接送機場飛回家鄉。
雖然只有三分之一的面試者通過這些階段到最後面對面的面試,但讓這些面試者有好的體驗是很重要的。
即使面試失敗回到校園,他們仍然會認為我們是個好公司,並告訴他們的朋友在大蘋果待的飯店有多豪華,增加他們同儕明年也申請實習的意願(儘管他們可能只想來紐約享受這趟豪華旅行)


軟體人員面試教戰守則(第三版) - The Guerrilla Guide to Interviewing (version 3.0)

 軟體人員面試教戰守則(第三版) - The Guerrilla Guide to Interviewing (version 3.0)

每個被雇用的人選都應該至少和六個人面談,六個人裡至少要有五位會和應徵者共事的人(也就是其他程式員而非經理)。你知道那種只靠幾位老鳥(salty)經理和應徵者面談,一試定生死的那種公司嗎?這些公司裡頭不會有非常優秀的工作人員。要瞞過一場面試實在太容易了,特別是由非程式員面試程式員時更是如此。

如果六次面談中有兩人認為對方不值得用,就不要錄取。這表示當你不打算錄用某位應徵者時,在兩次面談後就可以技術性地結束「整天」的面試,這並不算是壞事。不過為了避免流於殘酷,最好不要事先告訴對方要面談的次數。我還聽過有些公司允許任何一個面試官把人選刷掉。我覺得這有點太過頭了;對我來說,或許可以容許讓資深人員刷掉應徵者,不過不會只因某個新進人員不喜歡而否決。


軟體產業的變化太頻繁又太快,所以你需要那種任何編程工作都可以勝任的人。如果基於某種原因,你發現一個非常非常擅長SQL,但是完全無法學習其他主題的白痴學究,不錄用。否則就會就是拿長痛去換短痛。


錯失好人選比錄用不適合的人要好太多了。不對的人會耗用很多錢和精力,還會讓其他人浪費時間去修正所有的問題。錄用錯人要開除得花上好幾個,而且會非常的困難(當他們決定對簿公堂時更是格外麻煩)。在某些情況下也有可能完全無法開除任何人。不好的員工會破壞好員工的士氣。而且他們可能是個爛程式員,同時卻又是個真正的好人或是極度需要這個工作,所以你根本不忍心開除他們,不然就是一開除就會犯眾怒,或是其他種種的窘境。反正很慘就是了。
反過來說,如果你否決了一個好人選,我是指我認為有些地方不太公平,不過如果他們真的這麼聰明就不用擔心,他們有很多好的工作機會可以挑。別害怕會因為拒絕太多人而找不到人用。這在面談過程中並不是你的問題。當然找到好的人選非常重要。不過當你實際面試某人時,要假裝門外還有900個人排隊等著和你面試。不管優秀人選似乎有多麼難找,也不要降低你的標準。
好了,我還沒有告訴你最重要的部份:如何知道是否要錄用某人?
原則上很簡單。你要找的人必須聰明,而且能把事做完。

你要如何在面談中察覺聰明這回事呢?頭一個徵兆就是你不必再三地說明事情。對話會很流暢地進行。應徵者經常會說出某些很有見地有思想或是心思敏銳的話。所以面談的重點之一就在於建立情境,讓受試者能向你展示他有多麼聰明

愛吹牛的人是最差勁的面試官。這種人在面談時都在胡扯,應徵者只來得及說「是的,這實在是對極了,我衷心的同意你的看法。」吹牛專家什麼人都會錄用;他們認為應徵者一定很聰明,因為「他的想法和我很像!」

益智問答型的面試官是第二糟的。這種人認為聰明表示「知道很多事實」。他們只會問一堆瑣碎的編程問題,答對就加分。純粹好玩提一下世界上最爛的面試問題:「Oracle 8i裡的varcharvarchar2有何差別?」這是個爛問題。會知道這種芝麻小事的人和你真正想用的人完全不會有任何關聯。誰會在乎有什麼差別?你只要約15秒就可以在線上找到答案!記住,聰明並不等於「知道瑣碎問題的答案」。

總而言之,軟體團隊是要雇用有才華而非會某種特定技能的人。畢竟所有能用在工作上的特定技能,就技術而言都會在數年內過時,所以最好雇用能學習任何新技術的人,而不是此刻剛好知道如何讓JDBGMySQL資料庫溝通的傢伙。

不過大體來說,要深入瞭解一個人的方法就是讓他說話,要提出開放性的問題與難題。


2014年4月20日 星期日

卓越客戶服務的七步驟 - Seven steps to remarkable customer service

卓越客戶服務的七步驟 - Seven steps to remarkable customer service

建議吹掉灰塵

某個顧客抱怨鍵盤不會動。原因當然是因為沒有接線。如果你問他們線有沒有接好,「他們會覺得被侮辱,氣沖沖地說『當然接了!我像個白癡嗎?』而不去檢查。」
Chen的建議是「換一種說法『好,有時候接頭會有點灰塵而鬆掉。你可以把接頭拔下把灰吹掉再插回去嗎?』」
「然後他們就會爬到桌子下,發現自己忘了接線(或是插錯洞),就會吹一吹插回去然後回答『嗯,耶,這樣就好了,謝謝。』」

很多要求客戶進行某些檢查的動作都可以用這種方式表達。不要叫他們檢查某個設定,而是要他們把設定改掉再改回去,目的「只是要確定軟體有確實把設定存起來。」

讓錯的程式看得出錯 - Making Wrong Code Look Wrong (命名規範)

讓錯的程式看得出錯 - Making Wrong Code Look Wrong


我是故意用種類(kind)這個詞,因為Simonyi在他的文章中誤用了型別(type),結果好幾世代的程式師都誤解了他的意思。

如果你仔細讀Simonyi的文章,就會發現他所講的和我之前範例所用的命名規範是一樣的,
在我的範例中把us和s分別定義為不安全字串和安全字串。這兩者的型別都是字串。

如果你把某種字串指派另一種,編譯器並不會給任何警告,Intellisense也不會說些什麼。
可是他們的語意是不同的;他們解讀和處理的方式都不同,要把兩種字串互相指派時還要某些轉換函數做轉換,否則就會有執行時期的問題。






明確型別宣告(explicit typing, 要求程式員必須宣告型別)


2014年3月17日 星期一

爪哇學校的危害 - The Perils of JavaSchools

爪哇學校的危害 - The Perils of JavaSchools

有些小孩高中就在自己的Apple II上,用BASIC寫出很棒的乒乓遊戲。當這些孩子上大學修CompSci 101(一門資料結構的課程),接觸指標這玩意之後,轟!他們的大腦馬上被炸成一堆豆腐渣,接下來都跑去修政治學,因為法學院似乎是個更好的主意。我看過CS科系退學率的各種數字,通常介於40%到70%之間。大學當局通常認視之為浪費,我則認為這是必要的排除手段,讓那些往後無法樂於編程職業或因此成功的人及早出局。

對許多年輕的CS學生來說,另一個難題是教授functional programming(包括遞迴編程在內)的課程。MIT對這些課程的要求很高,不但創造了必修課程(6.001),還編寫出一本教科書(Abelson & Sussman的Structure and Interpretation of Computer Programs),被數十甚至數百所一流CS學校拿來作為CS入門教材。

不瞭解function programming,就無法發明MapReduce這個讓Google具備驚人擴充性的演算法。Map跟Reduce是從Lisp和function programming來的。修過相當於6.001編程課程的人,如果還記得純functional programs沒有什麼副作用,不會影響並行的函式,因此可以輕易地平行化同步處理。在他們回想之際,MapReduce實是是顯而易見的演算法。Google發明了MapReduce而微軟沒有,這個事實可以解釋為何當微軟仍在嘗試讓基本搜尋功能能運作時,Google已經進到下個領域:建立Skynet這個世界上最大的平行處理超級電腦,我不認為微軟真正瞭解他們在這波競爭中落後了多少。


利誘管理法 - The Econ 101 Management Method

利誘管理法 - The Econ 101 Management Method


一個大的問題是:這方法會導致內在動機被外在動機取代掉。

人們將會傾向去尋找局部的最大獲益,他們會找到一些方法,去尋求最佳化某些你正獎勵他們的特殊事情,而不是完成你真正意圖要達成的事。


當你使用利誘管理法時,你等於在鼓勵開發者玩弄制度。

假定你決定獎賞寫出最少臭蟲的開發者,那麼當測試人員要回報一個臭蟲時,就成了大問題了,開發著通常會說服測試員這並不是真的臭蟲;或者測試員會同意,在回報給臭蟲管理系統之前,先非正式地提報臭蟲給開發人員,那麼現在就沒有人會使用臭蟲管理系統啦,雖然記錄中的臭蟲數量降低,但實際的數量並沒有任何改變。

開發者在這方面可是相當有天分的,無論你想要測量什麼,他們總是可以找到方法最大化此數值,而你永遠也無法獲得真正想要的東西。




讓你的履歷有可讀性 - Getting Your Résumé Read

 讓你的履歷有可讀性 - Getting Your Résumé Read


大量散發的垃圾履歷,或是任何顯示你正在申請100個職缺的跡象,都只是讓你看起來自暴自棄而更使你顯得不夠格。你想讓自己看起來像一個搶手人才,正在決定要去那裡工作,因為你夠聰明可以在這方面做個選擇,所以你只需要申請一或兩個職位。


一封顯示你知道公司業務的個人化求職信是很有幫助的,表示你很在乎這個工作,值得給予一次面試機會。


我們真正尋找的是有熱情而且在任何他們想做的事上都會成功的人。我們喜歡對軟體有熱情的人。對我們來說,十幾歲時就寫出共享軟體是個跟進麻省理工學院一樣好的指標。這是你的生命故事,而在你申請工作時多半已經來不及改變了。


2014年3月16日 星期日

開發抽象層 - The Development Abstraction Layer

開發抽象層 - The Development Abstraction Layer


程式員的工作層次(比方說,Emacs)實在太過於抽象了,抽象到做不了生意。在抽象層工作的軟體開發者,還需要一個實作層 -- 一個能將程式碼轉換成產品的組織。

桃莉巴頓(Dolly Parton)是在”唱好歌”那一個層次的,她也需要一個龐大的實作層,來幫她灌唱片、訂演唱會場地、賣票、音效、宣傳、收版稅。

任何成功的軟體公司都會包括薄薄一層的開發者,這些開發者散佈在巨大管理組織抽象層之上建立軟體。這個抽象層存在的目的,只是為了建立一種假象,讓大家覺得一個程式員的日常活動(程式碼的設計及撰寫,程式碼的簽入、除錯等等),就是建立軟體產品並將之引入市場的一切。

這一點讓我得出本文最關鍵的重點:
身為軟體團隊經理,你的第一要務是建立開發抽象層。

大多數軟體經理新人都未察覺這個重點。他們只會一直想由好萊塢電影學到的傳統命令式管理模式。

在命令式的作法中,經理/團隊領隊會找出公司的目標,然後對副官下達適當命令把公司往讓方向移動。副官接下來會細分工作再命令下屬執行。這個過程會沿著組織圖往下重複進行,直到最後某個在最底層的人實際做事為止。在這種模式之下,程式員就是機器中的一根齒輪牙:一個執行管理階層命令中某一部份的打字員。


對一家軟體公司而言,管理的第一要務就是替程式員建立那樣的抽象層。

如果某個程式員正為椅子壞掉而操心,或是因為等Dell送新電腦來閒置,表示這個抽象層已經有了裂縫。

把你的開發抽象層想像成一艘具備超級馬力的美麗大遊艇。遊艇的維護無懈可擊。美食準時送上。包廂每天有兩次整理服務。導航地圖隨時更新。全球定位系統和雷達從不出問題,就算壞了艙內也有備份。而在艦橋上則是只需要考慮速度方向以及午餐吃鮪魚還是鮭魚的程式員。同時有一大隊身著漿硬白制服的專業人員在甲板下悄悄活動,維持所有事情的運作、填滿油槽、刮除藤壼、熨平午餐餐巾。這個支援團隊知道要做什麼,不過全都聽從臭屁老領隊(salty old fart)的指示。後者只要往某個方向輕輕點頭,整隊人就會完全協調演出,讓程式員能把遊艇的細節全部抽象掉,只要管速度和方向,以及午餐要吃些什麼。
最需要為建立程式員的抽象層負責的就是軟體公司的管理階層。我們建造遊艇,我們服務遊艇,我們就是遊艇本身,不過我們不駕駛遊艇。我們做的每件事都是要為程式員提供一個無縫隙的抽象層,讓他們能創造出偉大的程式,再讓那些程式抵達能因而獲益的客戶手中。

程式員需要Subversion儲存庫。建立一個Subversion儲存庫意味著你需要一個網路和一台伺服器,必須去採購、安裝、備份,還要配置不斷電系統;伺服器會產生很多熱,表示你得準備一個有額外空調的房間去放;而空調得連接到大樓外,表示大樓外牆外面要裝一個80磅的風扇;安裝這東西會讓屋主緊張,所以他們得帶自己的工程師來,協調要在哪裡安置空調設備(決策結果:要裝在往上到18樓的外牆上,可能是最不方便的位置),而屋主也會拉律師進來,因為我們得付出許多才獲淮進行;然後當空調安裝人員出現了,還帶著有如芭比玩具組的吊索機具,讓我們的建築工頭緊張起來,不肯讓他們穿著半吋粉紅塑膠製的美泰兒(Mattel,譯註:著名玩具商)繫具爬出18樓窗外,於是有人得再把包商找來,搞清楚他們為什麼在施工12週後,會突然發現得為這該死空調再次修改合約,而且這東西早在耶誕節前就知道要裝但是剛剛才弄清楚。而這件事即使只讓你的程式員花一分鐘去想都嫌太多。
就你的團隊中的軟體開發者而言,這一切都必須被抽象化成只要在命令列鍵入svn commit。

這就是要有管理階層的原因。

管理階層就是為了那些沒有公司能避免的事,不過如果讓你的程式員為此而操心,那麼管理階層就算失敗了。這就像如果百萬富翁船主得下去引擎室建造引擎,這台一百英呎長的遊艇也算失敗了。


要讓一位程式員發揮最大的生產力,必須搭配一間安靜的個人辦公室、一台強大的電腦、無限制的飲料,華氏68到72度的室溫、螢幕上沒有反光、一張極舒適而不會感覺到的椅子、一位替他們帶來信件和訂購的書籍手冊的管理者,一位讓網際網路讓氧氣般隨時可用的系統管理者、一位能找出他們自己看不到的臭蟲的測試人員、一位讓他們的畫面美麗悅目的繪圖設計師、一組讓大眾想要他們產品的行銷團隊、一組確保大眾能拿到這些產品的業務團體、幾位協助客戶使用產品,並讓程式員瞭解導致客服電話的問題,極具耐心的技術支援聖人、以及其他十幾位支援及行政人員,而這些在一家典型的公司裡總共會佔用八成的薪資支出。羅馬軍隊中每位士兵配置四名僕人的比例並非巧合。這並不是墮落。現代軍隊的比例可能高達7:1。

沒有人期望桃莉巴頓知道如何接上麥克風。她背後有一個無法想像,由經理人、音樂家、錄音技師、唱片公司、巡迴演出經紀人、美髮師、宣傳人員組成的基礎結構,這全部的一切只是要在她唱歌時建立那種抽象性,好像數百萬人會聆聽只是因為是她在唱歌。這所有讓桃莉巴頓得以實現的支援人員和管理階層所能做的最佳工作,就是提供最完美的抽象:那種桃莉巴頓為我們而唱的完美假象。這就是她的歌。當你用你的iPod聆聽她的歌,其實是有個巨大的基礎結構讓這件事實現,不過這個基礎結構所能完成最棒的事就是完全消失。只剩下桃莉巴頓獨自對我們唱歌這個完美的抽象意念。

===

由程式員驅動,在組織上讓程式員坐上駕駛座,同時卻有優異的抽象層能在甲板下完成所有把程式碼轉成產品的苦工。

2014年3月14日 星期五

開發人員完全指南 - A Field Guide to Developers

開發人員完全指南 - A Field Guide to Developers


程式員在組織中是怎麼被看待的?

他們是明星還是打字員?公司經理是由工程師或曾任程式員的人組成的嗎?開發者能乘坐頭等艙去參與研討會嗎?(我不在乎這是否像是在浪費錢,明星就該坐頭等艙,要逐漸習慣這樣的思維!)當他們飛抵機場準備來參與面試時,將會有輛轎車來接送呢?還是得自己想辦法到達公司?基於相同的背景條件下,開發者傾向於選擇將他們當成明星的組織。假若你們公司的執行長是個壞脾氣的銷售員,他不能理解為何這些嬌貴的開發人員會持續的爭取類似腕墊、大螢幕跟舒適椅子等等之類的東西,他們以為自己是誰呀?那麼你的公司或許需要好好的調整態度,如果你不尊重他們,你將永遠無法獲得優秀的開發人員。



他們的同事是哪些人?
程式員在面試的那天還會密切注意他們所遇見的任何人。他們友善嗎?更重要的是:他們都聰明機靈嗎?我曾經在Bellcore暑期實習過,我遇到的每個人都一遍又一遍地告訴我相同的事:能遇到這兒的人們是他們在Bellcore工作時最美好的事。

這告訴我們,不要讓無法駕馭、怪脾氣的開發人員參與任何面試活動,相反的,記得找具有親和的、社交能力強、個性溫和等特質的人一起參與。隨時提醒自己,當你的求職者們回到家並且要決定到哪兒上班時,若是他在你的公司遇到的每個人都是陰沈憂鬱地,則他們絕不會有正面印象。

另外,原本Fog Creek公司預想的徵人規則(這概念是從微軟偷來的)為「聰明、可將事情做好」,但就在我們正式讓公司營運之前,我們理解到還應該加上第三個規則:「不要討人厭的怪喀(譯註:jerk,粗魯、不顧別人感受、讓人厭惡的人)」。回想起來,想在微軟獲得一份工作,不是怪喀向來不是個必要條件;雖然我很肯定他們會客套地說:能對他人友善是件重要的事,但真實情況為:他們絕不會只因某人惹人嫌就開除掉他,事實上,當個怪喀有時還會是個進入高階管理階層的先備條件。從管理角度來看這似乎是無害的,但從招募的角度來看卻是有害的:有人願意在一家容忍怪喀的公司上班呢?

測測你自己 - Test Yourself

測測你自己 - Test Yourself


Top Coder

求職信排序 - Sorting Resumes

 求職信排序 - Sorting Resumes


熱情。 我們尋找求職者對電腦充滿熱情與真正喜歡寫程式的證據.
典型的證據是:
1. 電腦相關工作或寫程式的經驗可以回溯到年紀很小的時候. 偉大的程式設計師很可能花一個暑假在電腦營,或為他的牙醫叔叔建立一個線上預約系統,而不是在香蕉共和國(註:成衣連鎖店)打工折衣服。
2. 課外活動. 喜歡寫程式的人通常會利用閒暇時間投入他自己的程式計畫(或是在開放源碼的專案中有所貢獻).
3. 在他們的求職信上,說明他們如何的被電腦程式的結構與闡釋感動落淚

英文。對我們來說用英文技巧來評分履歷是一個難以下的決定,因為電腦程式設計是不會說英文的移民一樣可以做的好的一門領域。與程式設計師工作的多年經驗教會我,能清楚地溝通他們的想法的程式設計師遠比只能跟編譯器溝通的程式設計師更加有效。為程式寫文件是很關鍵的,撰寫其他人能審閱的規格與技術設計文件也是關鍵的,甚至對那些你們只是坐著討論如何做較佳的會議也是關鍵的:對解釋想法有困難的聰明程式設計師無法提供更多貢獻。在這個類別,我們也只考慮履歷是否清爽易懂。一個充斥文法錯誤的無組織履歷只會啟動一個大紅標幟:這是一個思想毫無組織的人或一般的懶人;這對許多工作來說也許沒關係但是對軟體開發者來說不行。特別是我們常常完全剔除充滿英文錯誤的履歷。就算對一個非英文母語的人來說,找一個人檢查你的履歷也不是困難的事,這件事也不做常表示你對你做的事非常缺乏對品質的關心。.


他們花時間認識 Fog Creek 並寫一篇為我們量身訂做的求職信表示他們對自己的能力有很大的信心,所以他們只申請少數的職缺,而不是寄一大堆給上千家公司。同時發出一堆的履歷是絕望的徵兆。更重要的是,一個量身訂做的求職信是一個徵兆:如果我們真的錄取這個應徵者,他們很可能會接受。這增進我們的投資報酬率。如果我只有夠面試六個人的時間,面試者其他條件均相同,我較願意面試六個真的想要為 Fog Greek 工作的人,不是一般也同時應徵其他工作的聰明人。


記得這件事真的是非常非常重要:
這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結,不論如何,重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試,然後決定他們是否值得錄取。記得這件事真的是非常非常重要:這些類別─熱情、只挑選少數公司、英文能力、頭腦、經過汰選、硬底子與多樣性─並不是雇用人的標準。做為標準這些都太不足了。有太多的優秀人才在考試中拿低分或差勁程式設計師在考試中拿高分。在你動紙去咆哮約耳如何認為你應該只雇用來自長春藤名校或約耳有某種成績情結,不論如何,重要的是瞭解這清單並不是雇用某人或拒絕某人的理由清單。這所有的只是一個目標導向且公平的方法可以為一大疊求職信做排序來找出最有可能來你公司工作的候選人優先安排面試,然後決定他們是否值得錄取。

Rick Chapman在尋找愚蠢 - Rick Chapman is In Search of Stupidity

Rick Chapman在尋找愚蠢 - Rick Chapman is In Search of Stupidity


如果你問我並讓我偏私的回答,我會說除非有個程式師掌舵,否則沒有軟體公司會成功的。到目前為止的證據都可以支持我。

不過這些要命的錯誤中有許多也是程式師搞出來的。Netscape重寫瀏覽器而不去改善原有的程式碼庫,這個不朽的神經病決定花了他們好幾個年的Internet時間,在這期間他們的佔有率由大約九成掉到4%左右,而這是程式師的點子。當然啦,該公司裡面非技術又無經驗的管理階層完全不知道這為什麼是個爛點子。還是有很多程式師為Netscape徹底重寫辯解。「舊的程式真的很爛耶,約耳!」是,嗯哼,這種程式師應該因熱愛乾淨的程式而被讚賞,不過絕對要禁止他們接近任何商業決策100呎的範圍內,因為對他們來說,乾淨的程式碼顯然比讓軟體出貨重要多了。

所以我會對Rick稍微讓步地說,如果你想要在軟體業成功,必須有一個完全瞭解並熱愛程式設計的管理團隊。不過這個團體也必須瞭解並熱愛商業。要找到對兩邊都很有天賦的領導者並不容易,不過只有這樣才能避免這些被Rick親切地列在書中的錯誤。所以讀吧,笑一笑。如果你的公司是某位豬頭在經營,就把履歷整理一下開始在Redmond(譯註:微軟公司所在)找房子吧。

雙元文化主義 - Biculturalism (Windons, Unix)

雙元文化主義 - Biculturalism


Unix文化重視對其他程式師有用的程式,而Windows文化重視對非程式師有用的程式。

--

我們寫程式究竟是為程式師還是為了一般使用者?除了這個問題之外其他的都只是詮釋。

--

因為可以進入程式庫除錯所以Unix比較好。因為張阿姨可以看到提示確認她的電子郵件真的送出去了,所以Windows比較好。事實上沒有誰比誰更好,他們只是擁有的價值不同:Unix的核心價值是製作有助於其他程式師的東西,而Windows則把製作有助於張阿姨的事視作核心價值。

----
Raymond說「典型的Unix文件會寫得簡潔而完整...這種風格假設讀者夠積極,可以推導未寫出的推論,並且有自信信任這些推導。小心的閱讀每一個字,因為一件事很少會講兩遍。」天啊,我認為他其實是在教年輕的程式師寫出更不人性的man說明文件。
這對一般使用者而言是絕對行不通的。雖然Raymond可能說這是「過於簡化的屈就」,不過Windows文化瞭解一般使用者不讀文件,即使不得不看也是愈少愈好,因此你必須不斷重複的解釋... 事實上在良好的Windows說明檔中,必須每個主題都能讓一般讀者直接看懂,不必先看懂其他任何的說明主題。

----

Unix的程式文化格外重視可由命令列呼叫的程式,這種程式可以用參數控制各種動作,其輸出可以擷取成一般機器可讀的純文字格弋。這種程式之所以會被重視式,是因為可以讓其他程式師輕易地整合進別的程式或較大的軟體系統中。舉個很小的例子,Unix文化中有一個Raymond稱之為「沈默是金」的核心價值,是說當程式成功地完成你所交付的事時應該不要有任何輸出。不管是在命令列輸入300個字元的命令建立檔案系統,還是建立並安裝了一套複雜的軟體,或是把載人火箭送到月球,全部都一樣。只要成功執行就不要有任何輸出。使用者看到下一個命令列提示就會推論一切正常。

由於你是為其他程式師寫程式,所以這才會是Unix文化的重要價值。就如同Raymond所說的:「喋喋不休的程式不太能和其他程式好好合作。」 相較之下在Windows文化中是為張阿姨而寫程式的,而張阿姨搞不清楚程式是因為執行成功而沒有任何輸出,還是因為出錯了所以無法顯示任何訊息,或是因為誤解你的要求而沒有輸出。

同樣的狀況,Unix文化欣賞保持文字介面的程式。他們不是很喜歡圖型介面,不過在純文字介面程式上漂亮地塗一層GUI口紅可以例外,另外他們也不喜歡二位元檔案格式。因為文字介面比較好用程式控制,而圖型介面除非提供其他機制(如內建腳本語言),否則幾乎不可能用程式控制。我們在這裡又再次看到,Unix文化重視有助於其他程式師的程式,而這一點很少會是Windows程式設計的目標。


約耳測試:邁向高品質的12個步驟 - The Joel Test: 12 Steps to Better Code

 約耳測試:邁向高品質的12個步驟 - The Joel Test: 12 Steps to Better Code


約耳測試 (Joel Test)
你有使用原始碼控制系統嗎?
你能用一個步驟建出所有結果嗎?
你有沒有每天都重新編譯建立(daily builds)嗎?
你有沒有問題追蹤資料庫(bug database)?
你會先把問題都修好之後才寫新的程式嗎?
你有一份最新的時程表嗎?
你有規格嗎?
程式人員有沒有安靜的工作環境?
你有沒有用市面上最好的工具?
你有沒有測試人員?
有沒有在面試時要求面試對象寫程式?
有沒有做走廊使用性(hallway usability)測試?



7.你有規格嗎?
寫規格像用牙線:大家都同意這是好事,卻沒有人真的在做。
我不知道為什麼,或許是因為大多數程式人員都討厭寫文件吧。所以當全是程式人員的團體面對問題時,自然傾向用程式碼而非文件來表示答案。他們寧願跳進去寫程式也不願先寫規格。
在設計階段發現問題時,只要改幾行就能輕易修正。等程式寫出來之後,修正的代價就高得多了,代價包含了情感(人們討厭拋棄程式碼)和時間,所以會抗拒修正問題。通常未依據規格製作的軟體最後的設計都很糟,而且進度完全無法控制。這似乎就是發生在Netscape上的問題。它的前四版變得一團亂,結果管理階層愚蠢地決定把程式丟掉重新開始。然後他們在Mozilla上又重蹈覆轍,造出了一個無法控制的怪物,而且耗了幾年才進入alpha測試階段

我的拿手方法是把程式人員送去上密集的寫作課程,讓他們變得不那麼排斥寫作,就可以解決這個問題。另一個方法是雇用聰明的專案經理來寫規格。不管用哪一種方法,你都應該強制執行「沒有規格不寫程式」這個簡單的規則。

軟體人員面試教戰守則 - The Guerilla Guide to Interviewing

軟體人員面試教戰守則 - The Guerilla Guide to Interviewing

有頭腦,並且能完成工作 (Smart, and Gets Things Done.)

2014年3月10日 星期一

不用測試人員的五大(錯誤)藉口 - Top Five (Wrong) Reasons You Don't Have Testers

不用測試人員的五大(錯誤)藉口 - Top Five (Wrong) Reasons You Don't Have Testers


1. 問題是懶惰的程式師弄出來的。
2. 我的軟體放在網路上。即使有問題也馬上就能修好。
3. 客戶會替我測試軟體。
4. 有資格可以勝任的人都不想做測試人員。
5. 我請不起測試人員!

給資訊科系學生的建議 - Advice for Computer Science College Students

給資訊科系學生的建議 - Advice for Computer Science College Students


修要寫大量程式的課

(前略)

這個故事的教訓是資訊科學並不等同於軟體開發。如果你真的非常幸運,你的學校可能會有一套合宜的軟體開發課程,不過大概是不會有的,因為精英學校認為技職教育和犯人改過自新計劃才需要教導實務技能。只不過是寫寫程式而已,到處都可以學。我們可是耶魯大學,身負鑄造未來世界領袖的重責大任。你覺得 16 萬美元的學費是讓你來學 while 迴圈的嗎?你以為這是什麼?某個在機場旅館舉辦的騙人 Java 研討會嗎?哼。

問題在於我們並沒有真正的專門軟體開發學校,所以如果你想當個程式師,可能還是得主修資訊科學。這是個好的主修學科,不過跟軟體開發是兩回事。

不過如果你幸運的話,可以在資訊科系找到很多密集寫程式的課程,就像你可以在歷史系找到很多能學會寫作的課一樣。這些是最好的課程了。如果你喜歡寫程式,修 lambda 演算或線性代數這種不碰電腦的課時,有些地方搞不懂不必難過。去找那些課程名稱有 Practicum 的 400 等級課程。這些課用這個拉丁文只是想弄個漂亮的課程名稱,好瞞過那些愛跩文的屁管理階層。

----

給資訊科學系學生的七個免費建議(物超所值哦):
在畢業前學會寫作。
在畢業前學會C。
在畢業前學會個體經濟學。
不要因為非資訊課程無聊就放棄。
修要寫大量程式的課。
別擔心所有工作都會外流到印度。
不管你做什麼,去找個好的暑期實習工作。

接下來是解釋,除非你好騙到只因為我叫你做就去做。萬一你真的那麼天真,那就再來一個吧:8. 自尊心受損時要尋求專業援助。

大麥克對原味主廚 - Big Macs vs. The Naked Chef

大麥克對原味主廚 - Big Macs vs. The Naked Chef



1. 有些事需要天份才做得好。
2. 天份很難複製。
3. 有人嘗試複製天份,要有天份的人建立規則讓普通人照著做。
4. 結果所得到的產品品質很低。

麥克不太高興。他請了一個大型IT顧問公司來建立系統。他請的IT顧問都很無能,只會一直講「方法論(Methdology)」,花了幾百萬美元還做不好一樣東西。 還好麥克找到一位真正聰明又有天份的年輕程式師。這個年輕人只拿了20美元和一塊披薩,一天內就把整個系統架好了。麥克高興得不得了,就把年輕的程式師推薦給所有朋友。 年輕的程式師開始大賺銀子。不久工作就多到做不完,所以請了一堆人來幫忙。厲害的人股票選擇權要太多了,所以他決定請些更年輕剛畢業的程式師來「訓練」六星期。 問題是「訓練」並不真的能產生一致的結果,所以年輕的程式師就開始建立規則和流程希望產生更一致的結果。幾年下來規則手冊愈來愈厚,不久就變成後一套叫做「方法論」的六冊巨書。 過了幾年,當初的年輕程式師現在已經成為巨大無能的IT顧問,帶著一本「方法論」和一堆盲從方法論的手下。即使方法論行不通的時候這些人還是硬幹,因為他們根本不知道其他方法。何況他們也並不是真有才能的程式師,只是受過六星期訓練,好心的政治學科系畢業生而已。 而這個新的巨大無能IT顧問公司也開始陷入困境了。他們的客戶都很不高興。於是又出現另一個新興的天才程式師把客戶都搶光,然後整個循環又重來一遍。


這個故事的教訓是?小心方法論。方法論可以讓每個人的表現都提升到不佳但可接受的程度,不過同時也會產生很多約束而激怒更多的聰明人。就我而言,有才華的廚師顯然不會樂於在麥當勞做漢堡,原因正是麥當勞的規則。是否如此IT顧問才如此吹噓他們的方法論呢?


工匠技藝 - Craftsmanship

工匠技藝 - Craftsmanship

這個故事的教訓是修正一個1%的問題可能會用掉500%的工夫。這種狀況並不只軟體業會發生。敢這樣講是因為我現在就在管理這些建築工程。上星期我們的包商終於完成Fog Creek新辦公室的最後修飾工程。內容包括在前門安裝閃亮的藍色壓克力,旁邊圍著鋁框,鋁框上每20公分就鑲有一顆螺絲。如果你仔細看照片,會發現每片門都會被鋁框整個包住,當門關起來時,兩片直框會併排在一起。雖然圖上看不出來,不過中間鋁條上的螺絲幾乎但沒有確實對齊。差了大概有2公釐。負責這件事的木匠很小心的測量,不過裝鋁框時門是放在地上,並不是等好門裝好再當場裝的。所以等到要把門裝上去時,才發現螺絲並沒有對齊。

這或許並不罕見;;我們辦公室裡很多門的螺絲都沒有對的很好。問題是當洞鑽好之後,要重新修正的代價貴得離譜。由於正確的螺絲位置離原來的洞只有幾公釐,所以不能直接在門上再鑽一個,可能得把整個門換掉才能解決。這實在是很不值得。這正是另一個修正1%的問題會用掉500%工夫的例子,而且這也解釋了為何這世上很多人造物都是99%好而非100%完美。(不過建築師倒是不斷吹噓,說某些亞歷桑那州的高貴金屋裡每根螺絲都排得很整齊。)

這點出了軟體的一項特性,一項大部份人都視為工匠技藝的特性。當軟體是由真正的工匠製作時,所有螺絲都會對得整整齊齊..當你做些很罕見的事時,應用程式會表現得很聰明。作者會投入更多的工夫去正確處理特的狀況,而不光是讓主要的程式會動。即使要額外再花500%的力氣去處理1%的狀況也在所不惜。

工匠技藝當然是非常昂貴的。唯一負擔得起的方法就是針對大量的客戶開發軟體。很抱歉,不過保險公司開發的內部人事管理程式絕對不可能達到這種工藝的境界,因為就是沒有足夠的使用者來分散額外的成本。不過就套裝軟體公司而言,這種工藝境界可以讓使用者高興並提供長期的競爭優勢,所以我願意花時間並正確地執行。請容忍我吧。


墨菲定律發威的一週 - A Week of Murphy's Law Gone Wild

墨菲定律發威的一週 - A Week of Murphy's Law Gone Wild


差的系統可能表現完全正常,不過等相鄰的系統故障時就會出事。有過敏和背痛的人可能好幾個有都沒事,不過一患乾草熱打噴嚏就會背痛到不行。這種事在系統管理中到處都有。可以利用這種機會把所有問題一次修好。

幫你所有的PC都加裝RAID並且定期備份,不要使用EFS,要買很大的硬碟(這樣就永遠不必停下工作來升級),另外要再次確認rdist的命令列選項。安裝導風管並且把水管隔熱做好。把你重要的伺服器移去安全的代管設施並且在辦公室改用Verizon的T1服務。



約耳的程式師書櫃 - Book Reviews

約耳的程式師書櫃 - Book Reviews


Helplessness: On Depression, Development, and Death

Martin E. P. Seligman

良好UI設計之所以重要,是因為它會讓大家快樂。
如果你的UI設計良好,使用你的軟體的人就會比較快樂。
如果設計不良,他們就會不快樂。
這個講憂鬱症的書有什麼關係呢?是這樣的,當人們感覺無法控制自己的生命和環境時,
就會轉變成臨床上的憂鬱症。而Seligman這位先驅發現,對抗憂鬱已知最有效的非藥物療
法,就是鼓勵人們小幅地逐漸控制他們的環境。



Influence: The Psychology of Persuasion
Robert B. Cialdini

Robert B. Cialdini的經典作品Influence是另一本值得一讀再讀的書。慈善組織請求你捐款時幾乎都會在信封裡附一個「禮物」,比如印有你的地址的自黏標籤或是幾張空白賀卡。他們會送禮物給你是基於互惠的社會性原理;因為這樣你就會覺得要回饋一些東西。你也可能常常在電視購物頻道上聽過「快快快,數量有限!」這種台詞,聽到都沒感覺了。不過這種台詞是基於罕見(scarcity)原理,也就是你會自然地假設罕見的物品會比較值錢。業務員,行銷人員以及廣告主會運用這些手法以及其他技倆,影響人們進行某些行為。Cialdini出色的書中討論了影響其他人行為的科學與實務背後的心理學理論。你得趕快在他們進行之前先看這本書!


程式設計領域的帕麥爾斯頓勳爵 - Lord Palmerston on Programming

程式設計領域的帕麥爾斯頓勳爵 - Lord Palmerston on Programming


所以當我們遇到某個只有NT 4.0才發生的怪問題時,我只花了三分鐘就解決了,因為我知道如何使用VMWare,而且我有一套用VMWare灌的乾淨NT 4.0機器,另外我也知道如何用Visual C++做遠端除錯,還知道可以由EAX暫存器知道函數的回傳值。完全沒接觸過這些東西的人要抓同一個問題,恐怕得花一個小時或更多的時間,不過我已經知道了很多很多「東西」,那些基本上是從1982年拿到我第一台IBM-PC和那本Norton書時就開始學的東西。
有漏洞的抽象表示我們面對一個直線上升的學習曲線:你可以用一星期學到每天工作所需知識的90%。不過其他10%可能得要好幾年才能補齊。有些人會說:「不管你要我做什麼,我都可以拿本書來就學會了。」真正有經驗的程式師超越這種人的地方就在這裡。如果你正在建立一個團隊,當然可以找一堆經驗較少的程式師用抽象工具製作出一大堆程式碼,不過如果少了經驗老到的人去做真正困難的事情,這個團隊是做不起來的。
程式設計有很多不同的世界,每個世界都需要大量的知識才能真正的精通。

2014年3月7日 星期五

在公司裡當個寫程式的工程師

http://mmdays.com/2013/12/22/be_a_programmer_in_company/


在公司裡當個寫程式的工程師,首先要能做到如下事項:用其專業知識,開發與設計新功能與產品;計劃、設計、撰寫與測試軟體系統,能符合需求;參與團隊開發專案,符合時程;維護既有產品;提出建議,改善既有流程;能解決煩雜的問題;在專案團隊裡,支持與協助新想法的實做與推廣;可以學習快速,在有限的時程完成重要的任務指派;能規劃工作的先後順序;能順暢地與無技術背景的人員溝通;在自己參與開發的產品上,可以預測並避免將發生的商業問題。在公司裡當個寫程式的工程師,想被公司當作不可替代的人,作為公司維護營運的要件,以上是基本要求。

程式人產能之謎

程式人產能之謎
文/林信良 2014-02-07

http://www.ithome.com.tw/node/84963

不想畢業就失業?這五件事你該越早做越好

http://www.thenewslens.com/post/26544/


但其實對企業來說,給一個完全沒經驗的人這樣的錢根本是不合理的。
他不知道你的工作表現如何,何況現今人人有大學念,
這張畢業證書也不能為你證明什麼。
對於你的老闆來說,你不是什麼頂尖人才,只是一個小菜菜而已。

---

這裡自私的定義是指所有的思考角度都從自己出發。簡單來說就是任何公司的好處都要拿
盡,自己的義務卻不願盡。很敢要求公司配合卻又不想被要求,覺得公司給你的都是應該
,你犯的錯也只是還好而已。自己永遠是對的,錯永遠是別人造成的。
這種態度,老闆們都請不起你啊。

2014年3月4日 星期二

Software design

http://en.wikipedia.org/wiki/Software_design

http://en.wikipedia.org/wiki/Software_design_pattern


格言



懂得寫程式,只是程式設計的一半,另外一半是與人類溝通。   by  Shih-Hao Hung

2014年3月3日 星期一

Android APP 上架流程

Android APP 上架流程
http://xyz.cinc.biz/2013/06/android-app.html


企業 Android App 上架 Google Play 軟體市場的流程說明
APP上架前相關準備工作
http://www.webmobi.com.tw/push-android-app-google-play-market/


Android 開發筆記 - APP 的上架與更新
http://blog.changyy.org/2012/08/android-app.html

[Max的Android心得筆記] 安裝 Eclipse 教學

Max的Android心得筆記
http://imax-live.blogspot.tw/2012/11/install-android-eclipse.html

2014年3月2日 星期日

抽象滲漏法則 - The Law of Leaky Abstractions

抽象滲漏法則 - The Law of Leaky Abstractions

所有重大的抽象機制在某種程式上都是有漏洞的。

例子: 下雨天時開車沒辦法開得和平常一樣快,雖然車上有擋風玻璃雨刷有頭燈有車頂還有暖氣,這些裝備應該是讓你可以忽略下雨這個事實(他們把天氣抽象化了),不過看吧,你還是得擔心天雨路滑,有時候雨甚至會大到你看不遠,所以在只好慢慢地開,因為基於抽象滲漏法則,天氣永遠不能完全被抽象化。
抽象滲漏法則會造成問題的原因之一,是因為它說明了抽象機制並不真能照原構想簡化我們的生活。當我想訓練某人成為C++程式師時,最好能完全不教char*和指標運算,直接去學STL字串。問題是總有一天他們會寫出"foo" + "bar"這樣的程式然後看到怪事出現,於是我就得停下來教他們有關char*的事情。他們也可能會試著呼叫某個需要OUT LPTSTR參數的Windows API函數,於是又得把char*、指標、Unicode、wchar_t以及TCHAR含入檔搞懂,才會知道如何呼叫。而這些全都是漏洞。

抽象滲漏法則表示,當某人發明一套神奇的新程式產生工具,可以大幅提升效率等等,就會聽到很多人說:「應該先學會如何手動進行,然後才用這個神奇的工具來節省時間。」 程式產生工具假裝抽象掉某些東西,和其他所有抽象機制一樣都有漏洞,而唯一能適當處理漏洞的方法,就是弄懂該抽象原理以及所隱藏的東西。所以抽象機制雖然替我們節省了工作的時間,不過學習的時間是省不掉的。
而這一切都似非而是地表示,即使我們擁有愈來愈高階的程式設計工具,抽象化也做得愈來愈好,要成為一個純熟的程式師卻是愈來愈難了。

測量 - Measurement

測量 - Measurement

軟體組織通常會獎勵(a)寫大量程式以及(b)修正大量問題的程式師。想在這種組織中出頭,最好的方法就是寫一大堆錯誤百出的程式之後再全部修好,而不是多花些時間在一開始就把東西做好。如果想懲罰產生問題的程式師來避免這個問題,就為他們創造了一個墮落的動機,讓他們努力隱藏問題,或者寫了程式卻不告訴測試人員,好讓測到的問題少一點。你是不可能贏的。

財星前500大公司執行長的報酬通常都是底薪加股票選擇權。股票選擇權通常價值數千萬或數億美元,相較之下底薪幾乎無關痛癢。結果執行長就會花招百出炒高股價,即使會毀掉公司或讓公司破產都在所不惜(就像這個月一直上頭條的新聞一樣)。即使股價只是暫時上升也照做不誤,因為他們會在高點賣掉。獎懲委員會的反應很慢,不過他們最新的好點子是要求執行長要一直持有股票,直到離開公司才能脫手。了不起啊,現在等於要他們短線炒高股價然後趕快走。同樣的,你也是不可能贏的。

油漆工Shlemiel演算法

油漆工Shlemiel的演算法。

Shlemiel是誰?他是下面這個笑話的主角:
Shlemiel得到一個在路上塗油漆的工作,他要漆在路中間的間斷分隔線。第一天他拿了一罐油漆去漆好了300碼的路。「做得真好!」他的老闆說「你手腳真快啊!」然後就給他一個銅板。
第二天Shlemiel只漆了150碼。「這樣啊,沒有昨天好,不過也還是很快。150碼也很了不起。」也給他一個銅板。
第三天Shlemiel只漆了30碼。「只有30碼而已!」老闆就哇哇大叫了。「這實在是無法接受!第一天你漆了十倍的長度耶!究竟怎麼回事啊?」
「我也沒辦法啊,」Shlemiel說「我每隔一天就離油漆罐愈來愈遠啊!」

2014年2月27日 星期四

沒有事情像表面看起來那麼簡單 Nothing is as Simple as it Seems



沒有事情像表面看起來那麼簡單 - Nothing is as Simple as it Seems
http://tinyurl.com/38nl9u3


如果你這輩子寫過20分鐘以上的程式,可能已經發現這個很好的基本原則:沒有事情像表面看起來那麼簡單.
就連複製一個檔案這麼簡單的動作都充滿陷阱。如果第一個參數是目錄會如何?如果第二個參數是檔案又如何?如果目的地已經有相同檔名的檔案又會怎樣?萬一沒有寫入權限又怎麼辦?
如果檔案拷到一半出錯要如何?如果目的地是需要認證才能繼續的遠端機器又如何?如果檔案很大而連線很慢,必須顯示進度欄時又會如何?萬一傳輸速度慢到幾乎完全不動...你要等多久才放棄並傳回錯誤訊息呢?
有個好方法可以用來面試應徵測試工作的人,就是要他針對一件簡單的操作,把所有可能出錯的地方全都列舉出來。微軟對面試測試人員有個經典題目:如何測試開檔對話盒?優秀的測試人員可以滔滔不絕地列出幾十種測試項目(在你選好檔案,要按「開啟」之前,另一個使用者把原本存在的檔案殺掉了)。


你必須先做設計再去實作。
我很抱歉讓你失望了。沒錯,我知道你看過Kent Beck的書,而且現在認為不先設計而直接實作是正常的。很抱歉,這並不正常。改程式就是沒法子和改設計文件「一樣簡單 」。大家一直都這樣說,不過這並不對。「現在我們都用Java和XML這種高階工具,幾分鐘就可以改好程式,為什麼不直接在寫程式時做設計呢?」我的朋友,你可以替你老媽裝上輪子,不過她並不會因而變成巴士。另外如果你自認能把錯用執行緒的檔案複製函數,重整改正成先佔多工的作法,而且速度和我寫這個句子一樣快,你根本就在自己騙自己(deep denial)。

人的工作切換有害無益 Human Task Switches Considered Harmful

Human Task Switches Considered Harmful
http://www.joelonsoftware.com/articles/fog0000000022.html


人的工作切換有害無益 
http://tinyurl.com/3u4mktf


如果你給某人兩件工作,應該要感謝他們只做一件工作而放棄另一件,因為這樣能做好更多的事,而且平均上也能更快完成工作。事實上這一切的重點就是絕對不要讓人同時做一件以上的事。請確定你有明白它的意思。好的經理人會認為自己的責任是消除障礙,好讓大家都能專注在一件事情並把它真的完成。遇到緊急狀況時,請先想想能不能自己處理掉,真的不行再丟給深陷在專案中的程式師吧。

揭露冰山般的秘密 The Iceberg Secret, Revealed

揭露冰山般的秘密

http://tinyurl.com/b2clht

關於軟體的客戶(或非技術經理)以及程式師兩者間語言翻譯的秘密。

你知道冰山有90%是在水面下嗎?沒錯,大部份的軟體也是這樣。那些漂亮的使用介面只
佔10%的工作,而其他90%的程式設計都是看不到的。如果再考慮到一半時間在抓蟲這個事
實,使用介面就只佔了5%的工作。如果只計算使用介面中的視覺部份(能在PowerPoint裡
看到的部份),其實就不到1%了。
這並不是秘密。真正的秘密是非程式人員並不知道這件事。



重要的推論二:把使用介面的畫面展示給非程式人員看時,如果這個介面非常漂亮,對方會認為這個程式幾乎已經完工。
非程式人員只會看著畫面,他們看到的是一堆像素的組合。如果那些像素看起來像個有功能的程式,他們就會認為:「哦,要讓這個程式真的動起來應該不會有多難吧?」 這裡有一個很大的風險:如果你先做出使用介面的原型,認為這樣就能與客戶進行討論,結果每個人都會認為你幾乎都做完了。接下來你花了整整一年去做「裡面」的事,卻沒人會看到你的工作成果,大家還以為你什麼都沒做。

重要推論四:因為政治因素要求由各技術經理或客戶「啟動」專案時,可以提供數種美術設計讓他們選擇。
改變某些元件的擺設方式,改變外觀和字型,移動標誌位置,標誌也可以變大或變小。拿些無關緊要的家家酒內容給他們玩,讓他們覺得自己很重要。這些他們就不會嚴重影響你的時程了。好的室內設計師會定期拿些樣本之類的小東西給客戶選,不過從來不會跟客戶討論洗碗機的位置。不管客戶想怎樣,反正洗碗機就是放在水槽邊,沒必要浪費時間去爭論,就是得放水槽邊,連擺高一點都免談;客戶想玩設計就讓他去碰些無害的東西,比如流理檯面要選義大利花崗石,還是用墨西哥瓷磚還是挪威木砧板,這種事他改變主意200次都沒關係。


The Iceberg Secret, Revealed by Joel Spolsky
http://www.joelonsoftware.com/articles/fog0000000356.html


Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.

People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"

The big risk here is that if you mock up the UI first, presumably so you can get some conversations going with the customer, then everybody's going to think you're almost done. And then when you spend the next year working "under the covers," so to speak, nobody will really see what you're doing and they'll think it's nothing.


Important Corollary Four. When politics demands that various nontechnical managers or customers "sign off" on a project, give them several versions of the graphic design to choose from.

Vary the placement of some things, change the look and feel and fonts, move the logo and make it bigger or smaller. Let them feel important by giving them non-crucial lipstick-on-a-chicken stuff to muck around with. They can't do much damage to your schedule here. A good interior decorator is constantly bringing their client swatches and samples and stuff to choose from. But they would never discuss dishwasher placement with the client. It goes next to the sink, no matter what the client wants. There's no sense wasting time arguing about where the dishwasher goes, it has to go next to the sink, don't even bring it up; let the clients get their design kicks doing some harmless thing like changing their mind 200 times about whether to use Italian Granite or Mexican Tiles or Norwegian wood butcher-block for the countertops.



2014年2月25日 星期二

無痛軟體時程 Painless Software Schedules

Painless Software Schedules  by Joel Spolsky
http://www.joelonsoftware.com/articles/fog0000000245.html


無痛軟體時程
http://tinyurl.com/2u9mpwx

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

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

12)絕對不要讓經理叫程式員縮減估計時間。

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

如果你的經理要求你縮短估計時間,這裡告訴你要怎麼做。
在時程表上加一個叫Rick的估計(當然是假設你叫Rick)的新欄位。把你的估計填進去。
隨便經理怎樣要求,直接把她定的時間填入Curr Est欄位後就不要管了。
等專案結束時再看看誰的估計比較接近實際狀況。我發現光是威脅說要這樣做,效果就很驚人了,特別是當你的經理瞭解到,他們剛參加了一個看你能做得多慢的競賽時更是有效!


為什麼不適任的經理們總會試圖要程式員縮短估計時間呢?

當專案開始時技術經理會去見經營人員,然後會得出一個他們認為三個月(實際上要9個月)做得到的功能列表。

如果你認為寫程式不需要先想清楚所需步驟,然後估算出來某工作需時n,實際上很可能會耗時超過3n。

在訂定真正的時程時,把所有工作加總起來,就會瞭解專案耗時遠比想像中多得多。歡迎光臨真實世界。

不適任的經理的處理方法是想辦法讓員工做得更快。這一點其實不太實際。你或許能雇用更多員工,不過他們需要時間適應,

可能前幾個月都只有一半的效率(還會拖慢必須引導他們的其他員工)。而且無論如何,在這個業界得要6個月才找得到好的程式員。

你可能可以讓員工在一年內全力以赴,暫時提高10%的初版程式(譯註:指未整理除錯的程式)產量。算不上是什麼大躍進,而且這樣有點太短視了。

你可能可以懇求員工不計辛勞超努力地工作,提高20%的初版程式產量。砰!可惜除錯時間倍增了。真是了不起的自爆蠢方法。

不過你絕對絕對不可能由n變成3n,如果你自認有這種本事,請寫信告知貴公司的股票代碼好讓我放空。

2014年2月21日 星期五

中文亂碼解決方法:環境編碼設定改 UTF-8

http://www.onejar99.com/2011/12/eclipse-file-encoding-utf8.html


有時候打開一些別人的專案,或是以前所寫的程式,會發現怎麼中文都變成亂碼,不僅無法辨識,也無法編譯,Eclipse 的程式檔的圖示上,會有一個紅色的小叉叉。這是由於檔案的編碼和開發工具的環境編碼不一致的緣故。

比如檔案原本的編碼是 UTF-8,開發工具的環境編碼設定卻是 MS950 ( MS950 是繁體中文 MS Windows 作業系統的編碼)。

解決方法很簡單,將開發工具的環境編碼也改為 UTF-8 就行了。

Step 1. 首先選擇上方選單中的「Window」->「Preferences」,開啟設定視窗。

Step 2. 選左邊樹狀結構中的「General」->「Workspace」。

Step 3. 在右邊有一個「Text file encoding」,將 Default (MS950) 改成「Other:」,並選擇「UTF-8」。

Step 4. 之後按下「Apply」就設定完成。


http://tomkuo139.blogspot.tw/2012/01/eclipse.html

Books 書櫃


約耳的程式師書櫃
http://tinyurl.com/jwkhfkh

必看!IT好書101
http://www.ithome.com.tw/itadm/article.php?c=63952

iThome 2012年 iT人必看的好書(上)
http://www.ithome.com.tw/itadm/article.php?c=76293

iThome 2012年 iT人必看的好書(下)
http://www.ithome.com.tw/node/76438#.UwdAifmSyCk





約耳 (Joel Spolsky):
「如果你在這個業界待得夠久,幾乎無可避免地突然發現自己得管理一大筆錢。如果你不想把事情搞砸,有幾件事是一定得知道的。
噢,不過你會說這些東西看起來如此地複雜,怎麼比得過那麼吃人不吐骨頭的華爾街狡猾老狐狸呢?光是想投資獲得合理收益,似乎都得不斷的研究,研讀,工作,閱讀還有學習才做得到。有那麼多的年度報表。而你還得訂閱各種寫得密密麻麻的無聊報紙,上面滿是用小字印刷的專欄。
如果我說你只要讀一本書就能學到管理投資所有必須瞭解的東西,你覺得怎麼樣?我是說所有東西哦。沒錯,這是事實。答案就是這本書。如果你沒工夫去看其他有關投資的東西,就讀這一本書吧。」
A Random Walk Down Wall Street by Burton Gordon Malkiel

Joel on software

http://www.joelonsoftware.com/


http://local.joelonsoftware.com/wiki/%E9%A6%96%E9%A0%81


Use spaces instead of tabs in Eclipse

http://stackoverflow.com/questions/407929/how-do-i-change-eclipse-to-use-spaces-instead-of-tabs

On Eclipse 3.6

 Window->Preferences->General->Editors->Text Editors->Insert spaces for tabs

===

 “Window -> Preferences -> Java -> Code Style -> Formatter”

Active Profile:
new a profile  => choose "spaces only" for "tab policy" in the first tab "Indentation"

====

If you havent got too much code, you could do a search and replace manually.

Find: \t
Replace: (4 spaces)

and check the "Regular expressions" option.

[API 19] ApiDemo Build Error : android.support.v4"

ApiDemo Build Error

import android.support.v4.print.PrintHelper;   <=  Build Error

google " add library eclipse android.support.v4"


Project > Properties > Java Build Path > Libraries
Add External jars

<sdk>\extras\android\support\v4\android-support-v4.jar
e.g.  C:\Users\KOD\android-sdks\extras\android\support\v4\android-support-v4.jar

Done


====

https://developer.android.com/tools/support-library/setup.html

http://developer.android.com/tools/support-library/index.html

If you are including the v4 support and v7 appcompat libraries in your application, 
you should specify a minimum SDK version of "7" (and not "4"). 
The highest support library level you include in your application determines the lowest API version in which it can operate.




Java Source Code Attachment in Eclipse

How to change Eclipse's “associated source” for debugging?

In the package explorer, where the jar is in a library (JRE, Maven dependencies, etc...);
right click => properties => java source attachment.

Alternately in the project properties => Java build path => Library tab => select the jar => edit.

====
http://www.cavdar.net/2008/07/14/3-ways-of-jdk-source-code-attachment-in-eclipse/     (for eclipse 3.4)
as for eclipse 4.3.1, only method 1 works.

打開某class   (e.g. import android.app.ActionBar; )
會跳出 source file not found錯誤訊息的那頁 有個可以讓你設定的按鈕
"change attached source"

External Folder
choose
<sdk>\sources\android-19

=========

不必再用External File (add external jar)

即以下都不必做  (不必再另外下載jar檔)

browse android source eclipse
Where can I browse Android source code on-line
http://stackoverflow.com/questions/449763/where-can-i-browse-android-source-code-on-line


I usually refer this site for the android source code.
http://grepcode.com/snapshot/repository.grepcode.com/java/ext/com.google.android/android/4.0.3_r1/
http://grepcode.com/snapshot/repository.grepcode.com/java/root/jdk/openjdk/7-b147/

// http://grepcode.com/snapshot/repository.grepcode.com/java/ext/com.google.android/android-apps/4.2.2_r1