電車男的故事，不就是因為保護愛馬士小姐受醉漢騷擾而開始的嗎？怎麼到了今天竟淪落到成為非禮犯罪者的地步了？

via 電車男變成了甚麼 – 無神論者的巴別塔 – 興建巴別塔的人，都是真心相信神的人.

電車男, 香港 Hide

每日一膠．荒謬的香港

via 每日一膠．荒謬的香港: 瘋狂駕駛罪修例刻不容緩.

駕駛罪行 駕駛罪行最高刑罰
不小心駕駛 六個月 罰款 $5000
酒後駕駛 三年 罰款 $25000 取消兩年駕駛資格
危險駕駛 三年 罰款 $25000 取消六個月至十八個月的駕駛資格
危險駕駛（引致他人死亡） 十年 罰款 $50000 取消兩年至三年的駕駛資格
狂亂（瘋狂）駕駛 兩年 + 留有案底

相對於其他「不小心」的犯罪，這種蓄意的罪行絕對冇理由判得更輕；相比起可能由於疲倦引起的意外，為何這種蓄意的行為卻可以輕輕放過？

首先，可以肯定的講『合法賽車場』係解決唔到問題。因為，合法賽車場只能合法開快車，而不可以合法賭車。我未去見識過，不過聽講加推理都知唔會係一班守法安已嘅人。＂公路賽車場＂還是會出現，而且還真的會增加賽車／贈車的人數。

點睇點想都只係有部份人想借題發揮。
如果話『賽車場』目的係為左帶旺旅遊業／增加馬會收入，我倒是能夠理解。

執法上，其實要打擊公路賽車簡單到不得了，每固定星期在不同的熱門地點守候就好。最重要係貴多，不貴精。只是多幾個路障，又花多少人力物力？

不設路障都可以影相和用其他方法追蹤等等。車再快，也快不過一通電話。只係警方做野又懶散又無效率。(你想想是那一個部門，那一個區去處理這次的事)。咁嘅表現都想話加人工？計我話應該減人工，加人數。好似日本電影咁，有事就幾十幾十部車出動。

回到主題，法例不平衡，絕對係立法局的負任。點解條條例可以被忘記？我以為佢地都係有專業知識（雖然事實上絕無可能），或者有專業人仕比意見／做手下。點會唔加重依一條嘅最高刑罰？
雖說取消駕駛資格未必有用（因為非法賽車不用考牌），但至少能減少有興趣參加的人數。

香港 Hide

網摘：SID uso‧班門弄斧談翻譯 (紫熊部屋).

『鋼的鍊金術師 FULLMETAL ALCHEMIST』的片尾曲－《嘘》的翻譯

No tags Hide

網摘: 加國研究：正面思考可能使部分人更悲觀 – Yahoo! 新聞.

加拿大    滑鐵盧大學（University of Waterloo）的李伊（John Lee）與伍德（Joanne Wood），及新布朗斯    威克大學（University of New Brunswick）的貝魯諾維克（Elaine Perunovic）等心理學家合作完成的研究指出，複誦正面、自我鼓勵的話，會導致自我評價不足的人感覺更糟，而不是更好。

伍德告訴「法新社」：「我認為道理出在，一個自我評價不足的人在不斷覆誦正面思想時，可能造成他們思路的矛盾。」

她說：「所以，他們若複誦『我是可愛的人』這句話時，心裡卻可能同時有『我並不總是這麼可愛』或『我這方面並不可愛』等想法，並且這些矛盾的思路會壓過正面思考。」

心理, 網摘 Hide

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

windows Hide

網摘: The Joel on Software Translation Project:激勵有害 – The Joel on Software Translation Project.

在我工作過的兩家公司裡面，壓力最大的時間就是每年兩次的績效評估期。不知怎麼回事，Juno和微軟的人事部門的的績效評估系統一定是從同一本呆伯特式管理書籍上抄的，因為兩邊的作法完全一樣。首先你要「匿名」地向上評估你的直屬經理(假裝這樣就能很誠實的進行)。然後再填好一個可有可無的「自我評估」表格，讓你的經理在評估你的績效時可以「參考」。最後你會在多個不可量化的項目(如團隊合作)得到一個1到5的分數(不過實際上只會出現3分或4分)。經理會把建議獎勵名單往上送，接下來名單會被完全忽視，然後每個人都會拿到完全隨機的獎金。這樣的系統從未考慮一個事實，就是人各有不同而獨特的天賦，需要各種天賦才能讓一個團隊好好運作。

No tags 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