回顧2007年

2007年,自己給自己訂了一些目標,檢視成果.

跟GF去日本東京玩. (O)

因為 GF 換工作請假不方便,外加我倆其實都沒有定期存旅遊基金,七月我一度已經放棄此計劃,把去玩的錢拿去買 D50(自暴自棄). 今年九月,倆個人硬是湊出一小筆錢,跟我老媽硬衝了一趟日本,雖然沒有多餘的錢亂敗家,每天走到腳斷掉,回想起來嘴角還是忍不住的上揚!

2007東京流浪-相片篇
2007東京流浪-美食篇
東京流浪第一天
東京流浪第二天
東京流浪第三天
東京流浪第四天
東京流浪第五天
2007東京流浪-最後一篇

成為有經驗的 Java Programmer . (X)

SCJD 十月報名至今也快三個月了! 最近根本沒進度! 八千有如肉包子打狗的感覺! 等最近身體狀態調好一點! 再來加油吧!

體重減至70公斤. (?)

入院前量是71公斤,住院都沒啥吃(怕得在床上解大小便 Orz),下巴都尖回來了! 但目前腳上一塊大石膏沒有辦法量出正確體重. Orz

回到籃球場. (O)

腰今年狀況是比去年好多了! 外加我也不強求,一酸就收手不打了! 但福無雙至但禍總是不單行-腳爆了! 回到籃球場...勉強算有成功過吧!

XX成功. (O)

求婚成功!! 雖然人不浪漫!! 但求婚的地方一定要浪漫!! 台場-彩虹大橋,雖然講的很不浪漫,也沒準備東西,也沒跪下來!! 但應該能永遠記得這件事吧!! 別忘了彼此的"承諾"啊!!

完成度: 3/5

2007 年!! 真的是酸甜苦辣的一年!!

入院三部曲

想逃跑

不想被開

開完了

接下來要做月子兩個月! Orz

阿基里斯戰記-開刀完小心得

不要鐵齒!

要鐵齒就早點要求照超音波或 MRI.

不要拖太久!

原本可能只要皮下修補就能縫合好,我搞成開了約七公分的阿基里斯腱重建手術(拿自身肌腱修補). 拍 MRI 時間隔只有 2cm 才過 10 天就變成 4cm(醫生說的),再拖就變成要用人工肌腱或是要等別人捐 Orz,更不敢想傷口長度.

開刀只是開始!

之後還要打好久石膏,做好久復健,又怕再踩斷一次. 這次讓家人跟自己那麼擔心,真的很不划算,不能再這樣揮霍我的健康了!

苦!

還要好久!好痛! 囧rz

(待續)

阿基里斯戰記-開刀

這部份我心情上之複雜(很怕->豁出去->歡樂)我就不陳述,大概就流程紀錄一下.

班長會推一張床來接你去開刀.

進入預備開刀的地方. 裡面的人都忙進忙出的,會有人確定你的身份,開刀部位(開錯邊就爽了),等待送入手術房.

你要從病床上滾過像一個銀行櫃台的地方躺上一張很窄的床上(開刀床?). 然後推進手術房.

麻醉師來幫你上麻醉. 我做的是半身麻醉,網路上查到是打脊椎,我的麻醉師很好,還安慰我麻醉針沒點滴那支針粗,我沒什麼感覺就打完麻醉了. 有些人打完麻醉會吐,我打完是全身抖很厲害. 接下來,下半身就熱熱麻麻開始失去感覺,有種下半身變成紙黏土很腫的感覺.

麻醉完就開始開刀了. 我是趴著開所以完全看不到開刀情形(我也不敢看),感到後面就是再切紙黏土,剩下的問醫生應該比較清楚.

開完就又要滾過櫃台進入觀察室等麻醉開始退掉.

整個流程,我自己感覺約一個小時. 但實際上我從下午4:30進去出來已經8:30,整整四個小時. Orz

推回病房,先看看喝水會不會排斥,不會才能進食. 麻醉退前不能起身頭不能抬起來. 我麻醉退了之後,就完全睡不著到現在,夭受痛.

痛的感覺: 事發當天斷掉又硬去跑步的感覺,一直有人再切你腳跟的感覺,神經痛的感覺,痛到想殺人...etc

就這樣,從入住榮總至今,我渡過了兩個無眠的夜!

(待續)

阿基里斯戰記-等待

確定了完全斷裂後,就又是一連幾天難眠的夜. 雖然這一個月也沒幾天睡好,但總是抱有不開刀會好的希望. 沒有選擇的選擇,算是我出生以來至少最大的路障吧!

這一個月來,最常做的夢就是,我在跑,我在打球. 不過醒來,腳頂多抽痛一下,還是沒有辦法出力. 剛受傷時會想沒辦法打球了,到最後就跟鷹村減重到最後只會想喝水一樣-我只想要能正常走路. 平時在簡單不過的小事-走路,現在是我最大的夢想!

確定要開刀後,先是拿我的 MRI 報告給一個 MB01 的網友-台北聯合醫院的羅浩儒醫生,羅醫生真的很熱心,我是不小心爬到他的文才寫信問他的. 但羅醫生很熱心且提供我很多相關的資訊. 原本是想找他在台大的老師-王崇禮醫生,但因為家裡人的關係,最後是跑去台北榮總看陳正豐醫生.

台北榮總,以前還蠻愛來這地方,吃吃醫院裡的漢堡王,去石牌夜市買 SS 台片要不就去天母晃晃,沒想到現在會那麼害怕來這個地方. 陳醫生看到我的腳後,就馬上說要動手術,但他並非專門"做這個"的,所以他把我轉給了馬哥-馬筱笠主任. 馬主任看完之後,當然是沒有我心中所想的歷史大翻盤,"星期二住院,星期三開刀",三審上訴失敗-我的心情就是這樣!

另外寫一下,簡單自我判斷阿基里斯腱有無斷裂的方式.

• 跪坐在椅子上.
• 大腿跟小腿呈90度.
• 用手捏你的小腿肚.
• 此時,腳有被牽動到代表你的阿基里斯腱還健在.

"你看!斷掉的人就不會有反應!!" - 馬主任如此跟旁邊的實習醫生解說著,我只能尷尬的假裝無事. Orz

人回到家裡,但魂不知道在哪裡. 本是出門狂歡在家吃大餐的聖誕夜,但我滿腦子都在想著已經躲不掉的兩個字-"開刀". 能不能送我一隻聖誕老公公來代替我開刀? 還記得那天看了 UBA 北科對世新-熱血不起來, NBA-轉台,男女糾察隊-笑不出來,人生-黑白. 只希望眼睛一閉醒來就是開刀完的隔天,沒想到眼睛一開,只看見榮總的大門,為何我會走到這一步. Why~

開刀前一晚,眼睛沒闔上過,不想要一睜開眼就要進手術房. 九點浣腸,十二點後不能吃飯喝水,早上六點換手術衣,打點滴. 只知下午要被開,但不知道幾點. 心情從很害怕等到更害怕,更害怕等到有點生氣. 生氣因為感覺被玩了,快四點都還沒被推過去,有點腦羞成怒了!

"該33床了!!",而我還是沒有回到 OB 賽前一天阻止意外的發生,也沒有等到最高法院遲來的誤判通知. 眼睛看到的是天花板,我被推進去了.

現在寫得很輕鬆,但昨天真的不知如何形容我當下的心情. Orz

(待續)

阿基里斯戰記-MRI

等了快兩個星期,我終於排到 MRI 了. 原本髖關節常有聲響,一直在想是不是腰酸的病源,本想說難得拍是否能能順便拍 MRI . 在這邊小弟已經幫大家問過了,一次就只能拍身體的一部份,不用再想說一次乾脆全身都做檢查這種傻事了.

我不知道斷層掃描跟 MRI 差在哪,也因為白色巨塔的關係,我一直以為只要我人進去出來就拍好了,不過完全不是這麼一回事. 我拍的部位只有右腳踝,就要花費30分鐘,而且機器無敵吵,雖然工作人員會拿給你一副耳機要你聽音樂睡覺. 但我只能說音樂是1那吵雜聲至少是10,更無言的是那片CD長度根本沒有30分鐘,到最後那副耳罩就只有少得可憐的防護效果.

五天後,回診看報告. 有圖有真相,再鐵齒也不能什麼沒斷這種騙自己的話了. "阿基里斯腱完全斷裂,上下的差距已達2cm,最好趕快開刀!" 很明顯沒辦法自欺欺人,也打破了我不開刀它自己會好的美夢. 累積且 Lag 一個月的負面情緒,只能說路是自己選的,自己做的自己受.

(待續)

阿基里斯戰記-診斷

台中澄清醫院的骨科醫生,在聽完我的敘述,看完我的 X 光片確定骨頭沒斷,摸了我的腳跟. 就很清楚地說了一句 "阿基里斯腱斷了!這要開刀!你可以慢慢考慮!" . 接著,我們到了復健科去訂做了副木.

反正經驗分享,就順便提一下,副木就是上圖我腳上的東西. 健保一個部位一輩子只給付一次,而已你在哪裡訂作的就只能拿回原醫院調整,若同部位你重新要做就要自費. 我那支若自費要新台幣 2000 元整.

在復健科,我還死八著職能復健師問問題. X 光是否能真的確定我阿基里思腱斷了?(不能) 斷了它會不會自己長回來?(會長肌肉纖維) 斷了會怎樣?(就失去作用) 問的答案都讓人頗為絕望,回答的都很輕鬆,但我聽完都很沉重.

因為沒有影象確定我的腳真的必須開刀. 所以隔了幾天我跑到新竹省立醫院看骨科,期待聽到不同的答案或者是安排我做進一步的檢查.

一開始,跟醫生解釋了我的情況,也暗示了我想要做進一步的檢查. 但卻被醫生反醮了回來,說我是不是就是不相信前一個醫生...云云,一時之間不知我是來看病還是來被質詢. 最後得到的結果就是,他摸了一下我的腿,說斷了要開刀.

一方面是害怕開刀,一方面是度爛這個醫生很硬的態度. 就這樣摸了一下被酸了一道,我要開也不會找你,我是這樣想的.

又隔了幾天(事發也一個多星期了),我跑去新竹馬階看復健科,醫生摸了一下說可能斷裂了,但詳細情形要做進一步檢查才能知道,他能安排我做超音波檢查. 跑了三家終於有一家可以讓我做檢查了. 雖然能公費照超音波,但我還是選擇了自費做 MRI ,新台幣 12000 元整,"蹦!!" 我聽到皮夾也發出一聲巨響. Orz

排定時間約兩個星期後,照完報告還要等三天. 雖然要等,但也是給一個說服自己要開刀的理由吧.

這段時間,我也有去看一家民俗療法的中醫. 他似乎搞不太懂 "後腳筋" 跟 "阿基里斯腱" 的差別. 他說 "腳明明可以動,後腳筋哪有斷啦!來兩次下次就可以走了!", 他第一次沒有折我腳底板所以我就有去第二次.

第二次我現在真的很後悔去,我一直說不能扳. 他就是說不扳你腳筋都縮在一起怎麼可以,就給我扳下去了.

幹!這次不是"繃"一聲,我聽到"趴機"一聲. 整個被拉斷的感覺,當場我痛到冷汗直流臉色發白. 而我耳邊傳來的 GBM(背景音樂) 是 - 中醫,來看病的病人和我爸一起么喝我說可以走的聲音. 旁邊的人似乎都像著了魔一樣. 在這小小的診所中,在那一瞬間,整個場面就像是傳銷說明會,大家都在說可以賺大錢,只有我跟我 GF 還是半清半醒的. 經過這次我相信,集體的活動是能催眠人做出奇怪的事情的.

之後幾天,我真的比較能走了. 但我現在相信應該是完全被拉斷,所以才不會痛的關係. Orz

(待續)

阿基里斯戰記-受傷

事情發生到現在,總算有一個確定的方向. 寫一寫,紀錄一下之前發生的事情. 以下為一個無名部落客為了紀錄自己生活的文,無興趣者可退散了!

2007年11月23日星期五(至今剛好一個月),逢甲資工系籃OB賽前一天.

出發前一晚,普通都會想多帶一套前一天就能多打一天,這次就不知怎麼搞的只帶了一套球衣褲,也許一切都是天註定. 下午跟 GF 去銀櫃唱完歌後,球興一來就開找人去逢甲打球. 不是說少一套球衣? 剛好之前愛跌倒特賣會,請小名買了一件大紅班蛙,就這樣人找齊了,球衣也有了,不打就太對不起自己了.

先說說自己身體狀況,28歲,173/72 不胖但胖在肚子,一星期打 1~2 次籃球(約兩小時),一星期會去健身房跑步(快跑 3km)或去國小跑步(快跑慢跑 5km),每天洗澡墊腳尖 100 下. 打球前一定都有熱身拉經筋,腳上也有穿跳躍A(一種護腳踝的護具). 拉拉雜雜只是想說我不是普通都沒在動,突然激烈運動才受傷的.

那天台中天氣很好,涼但不會絕對無冷到手冰腳凍的境界. 受傷前,我也已經打了 4~5 場以上,身體也沒有很冷. 不過事情還是發生了.

我捉了一個防守籃板球,一如往常我下球,腳一登準備自己把球運到三分線時. "蹦!!" 我聽到身體裡發出一聲巨響,旁邊場下的學弟也聽到了,我以為我的跳躍A尼龍繩斷了,同時右腳腳後跟好像被別場的球打到一般的感覺,但不同的是,我回頭並沒有看到球,當然也不可以有球打到我右腳,而我的跳躍A好好地在我腳上. 那什麼東西斷了?

斷了線的小木偶 - 我當下是這麼感覺. 腦中一片混亂,我只記得我對圍上來的人說 "斷了",回過神來,想到的第一件事 "幹!我怎麼把車開回新竹!",我竟還有時間搞笑.

坐在場邊,仍是不知道我的腳發生了什麼事,腳指有回應,腳踝勉強能背曲個幾度,腳跟跟小腿腹之間就是很痛. 安慰自己,可能不過就是小腿拉到而已,休息一下說不定明天就沒事了. 我還這樣走去便當街吃晚餐,走回 OB 會館.

當天晚上很難入眠,腦袋不斷迴響著 "蹦~",更別提右腳踩地完後的神經陣痛.

隔天一早,我發現真的不能在逞什麼英雄了. 我 GF 帶著我去了台中澄清醫院.

(待續)

軟體建構之道 (Code Complete) 第二版 第二十章到第二十六章心得

這幾章都在討論如何改善程式碼,我心得不太多,應該說重點太多,不知能說啥. Orz

第二十章-軟體品質面貌

使用者關心的是軟體好不好用,而不是程式碼用了哪些驚為天人的設計. (心酸貌)

每項影響軟體品質的參數是會互相抵制的,就跟你老闆要你在最短的時間,最少的人力下,做出效率最高的應用程式.

第二十一章-共同構築

兩個 RD 一起趕一個專案. 雖然書上說好處多多,但我當初被電很慘. 由其一開始沒導入 CVS ,版本的統整根本是惡夢一場.

第二十二章-開發人員測試

RD 自己測自己寫的程式. 這應該是很多 RD 每天都在做的事吧. 我通常只有在重要的子系統部份會做先行測試,先寫出測試程式,等等寫完系統就能馬上測試. 雖然有些人會覺得寫一份 Code 還嫌不夠多嗎? 但說也奇怪,寫完馬上能測還真的怪爽的. 我自己覺得先行測試好處如下:

• 撰碼前先寫測試程式,不會掉入已經熟悉功能而寫些無關痛癢的測試方法.
• 以使用這個功能的角度來測試,讓程式的介面更容易被使用(更有模組的感覺).
• 寫完可測,亂爽一把.
• 之後修改或重構功能,馬上能用測試程式驗證.

第二十三章-除錯

請利用 Debug 工具,縮小錯誤可能發生的範圍,不要用心電感應來找到錯誤.

花費了大量的時間來除錯,若可以請認命重寫程式碼比較好(尤其是在一大塊爛 Code 中找 Bug).

了解問題所在,才開始修改程式碼. 不要用 +1 不行那我 -1 看看能不能跑的烏龜心態. 這不叫 Debug ,這叫碰運氣!

第二十四章-重整

這章要自己看啊! 書上寫了很多關於需要重整程式碼的線索(比如: 不斷看到相同的程式碼片段...etc). 若確定寫完的 Code 不會再被射回自己臉上者,可跳過此章節.

第二十五章-程式碼微調策略

不要太早最開始最佳化. 你這個月房貸都快繳不出來了,你還在想要買什麼 3C 產品來提升自己的生活品味嗎.

正確的程式比快速的程式重要.

只有經過實際測試,才能得知是否真的最佳化. 沒有數據,一切都是瞎猜!

第二十六章-程式碼微調技巧

就說是微調了,我不知有啥心得啊! 超多~小重點啊!

你是哪種程式設計師?

(圖片來源: http://elielin.chu.jp/blog/bimg/061106.jpg)

原本只是 Code Complete 的一個例子,補充一下應該能補齊所有種類(以下皆轉自書中 Orz).

• 青澀的理論學家,完全盡信所有讀過的書籍.
• 經歷過無數艱苦戰役,老學院代表-"真材實料"的程式設計師.
• 年輕有自信,但卻自命不凡的電腦高手.
• 厭倦未來空想大餅的資深程式設計師,只想尋找一些有效的做法.
• 有智慧的老程式設計師.

自己補充(以下才是我想的 Orz):

• 自命不凡,說的一嘴好 Code 的偽電腦高手.
• K 完幾本快快樂樂學程式,一招半式就想闖天下的偽程式設計師.
• 緊抱舊技術,新技術退散的老程式設計師.
• 寫程式只是為了生活,來一個需求,我就寫一個功能的程式公務員.

最後自我分析:

我是一個青澀的理論學家,只信自己想信的書籍. 年輕無自信,不知未來何去何從的小螺絲釘. 厭倦不切實際天馬行空的需求,只想尋找有效率的做法. 緊抱 JAVA,C 語言退散的程式設計師. 寫程式只是為了生活,但卻有種生小孩的感覺,努力讓每個我生出去的孩子都能長得乾乾淨淨的,別人家的小孩不干我的事(請參考螢火蟲之墓). 我是一個自以為程式設計師的公務員.

歡迎補充. Orz

真的假不了?

人累真的什麼鳥扣都會寫出來,此文用來警惕自己.

剛寫了一段類似如下的 Code:

boolean isFalse = false;
if (isFalse == true);
{
  System.out.prinln("isFalse == true 才會印這行!!");
}

照理說 isFalse 應該是 false ,但我的 Console 就不爭氣地狂印.
isFalse == true 才會印這行!!
isFalse == true 才會印這行!!
isFalse == true 才會印這行!!
isFalse == true 才會印這行!!
isFalse == true 才會印這行!!
...

真的太累了! 回過神來才發現!

boolean isFalse = false;
if (isFalse == true);
{
  System.out.prinln("isFalse == true 才會印這行!!");
}

所以這段程式碼根本等於:

boolean isFalse = false;
if (isFalse == true)
{
}

System.out.prinln("isFalse == true 才會印這行!!");

幹! 根本沒想過自己會寫出這種 Bug(當初在書上看到嘴角還輕蔑地上揚)! 外加自以為 Eclipse 無敵! 這真是生命中值得去撞牆的一天!

PPY 不為人知的隱藏技 - 推倒排行榜

一直在夢想著 FunP 哪天能提供像這樣的小工具 - 自己部落格內的文章在 FunP 上被推文的排行(讓別人一進來就能知道哪些文章有人推)

就在剛剛我試出來了,但是要有個蠻囧的先決條件 - 你所有的文都要是你自貼上去的,而且你平常沒在貼別人文(可以推別人文).

以下以圖代替說明:

Step 1: 進入 FunP 工具.

Step 2: 選擇文章聯播元件按以下設定,取得程式碼.

Step 3: 將程式碼中的src=""雙引號內的字串改成"http://funp.com/tools/story.php?blog_id=哈部落的部落格ID&push".

看不懂請看 FunP 上的討論串(請看 FunP 掃地阿婆 - PPY 的精彩隱藏技說明).

最精簡版本(以下程式碼修改 blog_id 即可,上面都可以不要看了,若已經看完了,在此說聲抱歉,這篇發文到最後已經算在搞笑. 早知就直接發問就好. 囧rz)
<script language="JavaScript" src="http://funp.com/tools/story.php?blog_id=哈部落的部落格ID&push" type="text/javascript"></script>

這就是史上最囧的夢幻功能 - 推倒排行榜,供大家參考. 也許已經有別人實作過了,若回娘家請多包含.

我知道工程師最討厭用戶提需求,所以這篇文若被 FunP 工友看到,可直接略過. Orz

容易忽略的小事 - 命名

今天 K 了 The Greatest Challenge in Software Development 這篇. 裡頭包含了一些延伸閱讀,有興趣的人可以去看看.

身為一個程式工程師,每天除了看大盤指數和王建民昨晚有沒有拿下勝投外,最常幹的是應該就是替你的程式碼想名字了.

命名就像人每天都要吃飯,不吃飯人活不久,不命名我不知道你要怎麼寫程式. 有人三餐亂吃,身體吃出毛病,也許短期內身體看不出什麼異狀,但長期來看一定是有損健康的.

最常看到的爛變數命名: a1, a2
我實在不知道為什麼工作那麼久的人會寫出這種變數? 難道他知道我要接他的 Code? 還是他度濫我? 還是他寫的 Code 都經過他延腦 Obfuscate 過了?

一樣東西有不同的名字
我知道 "小叮噹" 跟 "哆啦A夢" 是同一個人. 問題是若新加入的成員不看日本漫畫怎麼辦? 若沒有人去解釋這些名字是指同樣的東西,這倒楣鬼可能要花很多時間才知道 "貝吉達" 就是 " 達爾",他們都是指一個額頭很高的賽亞人. 若他沒理解這件事就直接開始寫 Code 的話,那 "七龍珠" 這故事就可能越來越可怕了(變成同人誌 或 番外篇 吧 Orz).

剛本來想找小叮噹的圖來放,找到這張,這張和這張. 別人畫的,有興趣自點,我不敢亂放. 我只能說你亂命名就會寫出這種小叮噹. Orz

反正,我只是想說,竟然你天天都要幫程式想名字,何不就學一個好一點的命名方法呢? 萬丈高樓也是平地起,打好基礎也會有好理解的程式碼,不是嗎?

Textile

A Humane Web Text Generator. 使用更易人類閱讀的方式編寫 Web 文字.

語法快速上手: http://hobix.com/textile/quick.html#writing-in-textile
線上翻譯器: http://www.textism.com/tools/textile/

住在程式世界裡的怪獸

這篇原文實在超經典的,大家一定要連進去看啊.
一定要看啊!不看會後悔!

More Monsters of the Programming World

Part1: http://blogoscoped.com/archive/2007-12-10-n70.html
Part2: http://blogoscoped.com/archive/2007-12-12-n59.html

The Character Encoding Bug
(它的天敵是 UTF-8)
哈!超傳神啊!

The Feature-Creep Bird
(跑很快又會飛)
寫程式不變的真理就是需求一定會變啊.

The Overlong Function Snake
(專殺程序編寫員)
難道會殺客戶嗎. Orz

General Gold-Coating
(用原子彈殺蒼蠅)
再請教過我的外國同事後,我終於了解這跟黃金鎚戰士(在下面)的差別.
RD 常常做出一個小功能就沾沾自喜,或者專注在一個無關大局的小功能上.
這..我常犯. Orz

The One-Eyed Newbie
(身長200公尺)
新手不要來!汙辱我的美!我不是你的師傅,你卻偏偏纏上我!

The Distraction Dragon
(被美麗的火球包圍)
我寫程式時通常很專心. (' W  ')

The Syntax Serpent
(專吃分號)
還好我用 Eclipse 沒此困擾.

Quick Hack Bactexia
(快速繁殖 & 壽命短)
想都沒想就直接亂寫一通,讓我想起某前輩.

The Waving Security Vulnerability
(居住地: 懸疑陡峭)
都住在那麼危險的地方了,還能說安全嗎. 囧rz

Bottleneck Bird
(吃一大堆蝙蝠跟小燕子)
為何不吃掉我重新修改所需的時間啊. Orz

The Legacy Code Squid
(一堆未知的觸角)
怪不得我接的 Code 都有股章魚味.

The Magic Number And
(有時候會有劇毒)
我身體好癢啊!

The Change Request Hydra
(住在黑暗的洞穴內)
跟住在澳洲的客人有親戚關係.

Spaghetti Code Sally
(據聞已經 180 歲)
Wiki 介紹: http://en.wikipedia.org/wiki/Spaghetti_code

Lasagna Code Louis
(勉強能走幾步)
Wiki 介紹: http://en.wikipedia.org/wiki/Lasagna_code

The Golden Hammer Warrior
(是銀彈軍團的首領)
話說有一陣子,我也變身為黃金戰士. Orz

The Zombie Manager
(請餵時間給他吃)
應該是指管理階級不斷想些消耗時間卻沒生產力的點子吧. Orz

Load Lufinite Infinite Loop
(你可以進去他的房子卻可能走不出來)
真傳神. Orz

Assumption-Eating Plant
(可以長到 3 公尺高)
一直假設是神經質的行為. Orz

Dependecy Rabbits
(無聲無息就跳到你身上)
耦合度地獄. Orz

有興趣的人可以去買他的明信片喔!
http://www.cafepress.com/blogoscoped.199824097

捷運心文化運動 KUSO 創意秀 得獎名單

阿母喔..
我得獎啦..

今天接到電話還以為是電話詐騙.. Orz

不知道之後能不能在捷運上看到我的作品.. Orz
應該不太可能放用物件拉出來的四格漫畫吧.. Orz

在這 2007 年的最後一刻..
終於有個好消息了.. 囧rz

最後要感謝曾老師這一篇..
我才有機會得這個獎啦.. (T.. T ) Y

作品欣賞: 讓座不長眼
不過我 GF 說她不知笑點在哪.. Orz
看來以後的目標是畫出她笑不出來的作品.. Orz

軟體建構之道 (Code Complete) 第二版 第十七章到第十九章心得

第十七章-異常控制結構

使用保護子句簡化複雜的錯誤處理

if (checkUserName() == true)
{
  if (checkPassword() == true)
  {
    if (checkBirthday() == true)
    {
      if (checkCertificationPhoto() == true)
      {
        // lots of code.
      }
    }
  }
}

改寫為

if (checkUserName() == false)
{
  /* 可加上錯誤提示. */
  return;
}

if (checkPassword() == false)
{
  /* 可加上錯誤提示. */
  return;
}

if (checkBirthday() == false)
{
  /* 可加上錯誤提示. */
  return;
}

if (checkCertificationPhoto() == false)
{
  /* 可加上錯誤提示. */
  return;
}

/* 通過以上重重考驗才能抵達此處. */
// lots of code.

前者若要加上錯誤提示,又會產生出一堆 else 區塊. 後者則不會降低閱讀性. 不過 return 應該要小心使用就是. Orz

謹慎使用 goto

以下引述自書中:

使用 goto 會違反程式碼應該完全由上而下流動的原則.

我自己在考古別人的程式碼時,也最討厭看到跳來跳去的邏輯,總之謹慎使用會改變程式碼流程的語法.

第十八章-資料表導向法

書上先是舉了個取出每個月天數的範例,與其在程式中寫出以下程式碼:

if (month = 1)
{
  return 31;
}
else if (month = 2)
{
  return 28;
}
...
..(落落長的程式碼)..
...
else if (month = 12)
{
  return 31;
}

不如直接建立一個每月天數的陣列,也就是一個存在於記體的資料表,直接查表就不需要寫出一長串無聊的條件判斷了.

int[] daysOfMonth =
{31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
int daysOfJuly = daysOfMonth[7 - 1]; // 直接查表. 此處可以搬出成一個常式,來處理 -1 的邏輯.

看完這例子,我只覺得超簡單,這樣也能寫成一章. 書上接著舉了一個 "彈性訊息格式" 的範例,我只能說 "我錯了!!",我對這個範例一點 Sence 都沒有啊. 囧rz

有興趣的人請自己翻書來看,以下心得請不要認真看,算是自己解釋給自己看的東西,完全不知道正不正確.

系統內有 20 種資訊格式,因為每種資訊內的欄位都不一樣,書中將 "如何解讀資訊" 的動作包裝出來:
Hard cord: 類似每月取天數的例子,一種解讀資訊的方法就寫在一個 if 裡頭.
OOP: 建立一個解讀資訊的繼承樹,或是使用 Strategy Pattern 來封裝不同的解讀方式.

好戲上場. Orz
資料表:
1. 先定義出欄位會出現哪些型別(int, String...).
2. 利用 1 定義出的型別,建立每種資訊用來解讀的 meta data,系統內會有 20 個這樣的 meta data,這些 meta data 集合就是一個資料表(可以存在檔案內).
3. 建立讀取欄位型別的共用常式.
4. 系統接收到一個資訊,它就根據資訊編號去資料表找出對應的 meta data,然後透過 3 建立的常式就能解讀資訊.

好處是若又有新的資訊,我們不用更動程式碼,只需要在資料表建立新的 meta data. 程式碼變少了,因為都轉成 meta data(但我還是要寫 囧).

我承認,這章我看得超痛苦,我對含有 meta-data 這種例子的東西真的很不行. 我覺得我之後又會忘光光了. Orz

第十九章-一般性控制問題

以隱含的方式將布林式作真及假

不要寫 while (isDone == false) 而寫成 while (!isDone) .
不要寫 while ((a > b) == true) 而寫成 while (a > b).

這樣的好處是不用記太多項數,讀起來也較像是對話式的英文. 不過我忘記我在哪裡看到,最好不要在在條件判斷中使用 "!" .

while (!isDone) // 我看這句腦中是浮現 while ((!isDone) == true) , 反而更亂.
while (isDone == false) // 我很直覺就把 isDone 想成變數,它要等於 false 才會執行.

反而我覺得看個人啦,我思考方式比較像電腦,念起來順不順不重要,我只關心 isDone 是一個變數,它要等於 false 才會執行. Orz

以數線順序編寫數字運算式

(MIN <= i && i <= MAX)
(i >= MIN && MAX >= i)

哪一個看起來比較有感覺? 哪一個一看就知道 i 的範圍?

---- MIN ---- i ---- MAX ----

這樣還看不出來? 那這一個重點你可以跳過. Orz

書上有一段話我覺得很不賴,跟大家共勉之.

寧可努力找出好的解決方法並避開失敗,也不要嘗試找出最佳的解決辦法.

又找到了個偷懶的好理由了. Orz

這是一篇自嗨的塗鴉文

上圖主題為 "賣造" ..
主角為一個不知舔蜜點在哪的部落客..
反而寫了一堆舔屁眼的文章..
送給跟我有一樣感覺的部落客.. 囧rz

因為行動不便的關..
最近部落格寫更兇了..
比以前更常去逛別人的部落格..
看看人氣部落格到底是怎麼一個樣子..

太專業的文..
我寫不出來..

三不五時的 3C 產品開箱文..
我沒那麼多錢..

一天一圖的文..
沒幽默感..
沒靈感..
沒手感..

政治文..
認真了我就輸了..

星光文..
認真了人二雄就贏了..

只有自嗨文我能一篇接一篇地寫..
但我覺得只有名人的自嗨文才會有人想看..

唉..
人氣不能當飯吃..
但又希望哪天也能月領 100 美金的 Google AD 支票.. Orz
再拿這 100 美金來寫新的開箱文..
看到開箱文的人又手癢去點旁邊 Google 挑選好的廣告..
就這樣進入無限循環該有多好..

但事實總是殘忍低..
大家部落格上都擺著同樣的廣告..
彎彎的我都沒點了..
幹嘛點你的..

Web 2.0 對我來說..
還是個 M 型化結構.. Orz

久違了..
自嗨文..
真是好久沒寫了..

軟體建構之道 (Code Complete) 第二版 第十四章到第十六章心得

第十四章-組織直線碼

讓相依性明顯可見

/* 看不出相依性的例子. */
loadPlayerList();
caculatePlayerAvgHeight();
caculatePlayerAvgWeight();
...

以上程式碼,首先從檔案或資料庫載入球員名單,再算出球員的平均身高跟體重. 如果沒有先執行 loadPlayerList(),那根本沒有辦法算出平均身高跟體重. 對於閱讀的人也不是那麼容易看出相依性的關係.

/* 利用 傳入參數 和 常式命名 讓下一個倒楣的 RD 看出相依性關係. */
List thePlayerList = initPlayerList();  // 使用 init 前置命名.
caculatePlayerAvgHeight(thePlayerList);  // 一定得要有一份球員清單.
caculatePlayerAvgWeight(thePlayerList); // 一定得要有一份球員清單.
...

若真的無法使用比較好的技巧來顯示出相依性 - 最後最後再動用註解.
ex: 在 caculatePlayerAvgHeight() 前附註,使用此方法前必需先呼叫 loadPlayerList().

使用 "接近法則" 來排列陳述式

theBreakfast.getPrice();
theLunch.getPrice();
theDinner.getPrice();
theBreakfast.getCalories();
theLunch.getCalories();
theDinner.getCalories();
theBreakfast.getProtein();
theLunch.getProtein();
theDinner.getProtein();

換成

theBreakfast.getPrice();
theBreakfast.getCalories();
theBreakfast.getProtein();

theLunch.getPrice();
theLunch.getCalories();
theLunch.getProtein();

theDinner.getPrice();
theDinner.getCalories();
theDinner.getProtein();

眼睛是不是比較舒服? 把相關的陳述式歸類在一起,不確定這樣編排對不對? 問你的眼睛就知道了.

第十五章-使用條件式

case 陳述式請避免省略 break

switch(theParam)
  case 1:
    boo();
    break;
  case 2:
    foo();
    break;
...

我知道這是超基本的東西,但我就碰到過. 所有流程看都沒問題,但就是有問題,最後找出來問題所在,也想順便把前輩找出來鞭一輪. 養成寫作好習慣,才不會犯這種基本錯誤.

盡量不要在 case 陳述式中利用 break 來操作流程

switch(theParam)
  case 1:
    boo(); // 如果 theParam = 1 就會執行 boo() 跟 foo().
  case 2:
    foo(); // 如果 theParam = 2 就只會執行 foo().
    break;
  case 3:
    gotoHell(); // 如果 theParam = 3 就會執行 gotoHell().
    break;
...

其他人得花時間去了解程式的邏輯,事後修改也可能發生預期外的錯誤. 若你想下地獄,自己去就好,不要推別人下去. Orz

第十六章-控制迴圈

小心使用 Break 和 Continue

請確定你知道 Break 和 Continue 的定義,要不請不要亂用. 使用太多 Break 或 Continue 也會增加迴圈的複雜度,請謹慎用之.

Break: 結束迴圈,程式繼續執行迴圈後的第一行.
Continue: 跳過此次迴圈,程式回到迴圈下次重覆的開始處執行.

什麼還是不懂? 請去翻書,一個好的程式設計師,不懂就去搞懂.

由內而外建立迴圈

以下引述:

先從具體處著手,一次考慮一樣東西,然後採由簡入繁的方式建立迴圈.

我覺得我亂說反而會誤導人(因為我寫迴圈都由外而內建立),大家去翻書看看,我覺得在面對複雜迴圈邏輯時,這是很好的寫作及思考方式.

這三章都在描述程式碼的流程,我只針對我比較有感覺(有慘痛經驗)或之前沒注意的部份寫心得.

到底是客戶痛苦? 還是工程師痛苦?

此篇為讀完 Sharing The Customer's Pain 的心得.

看過不少的書或文章,總是教導工程師要傾聽客戶的需求.
"工程師不要在關在自己的象牙塔了!"
"軟體是寫給一般人用的!"
"工程師寫的軟體只有工程師覺得好用!"
以上是我常聽到或看到的 黑特關鍵句.
今天看完這篇,我想要替工程師辨護一下.

工程師根本碰不到客戶

很多需求都是客戶幹醮客服端 (中間幹醮流程視公司規模決定) xxx 幹醮到老闆,最後老闆在來幹工程師. 工程師面對的只是 老闆 跟 那該死的 DeadLine 而已.

已經失真的需求

(圖片來自: http://lib.verycd.com/2006/01/26/0000086858.html)

大家都看過綜藝節目,藝人排成一排猜四字成語,客戶就像那出題目的人,公司對外窗口就是第一個人,工程師這種苦命的小螺絲就是那該死的最後一個人.

客戶: 我想要 "每個月一號就產生上個月的資料報告 ".
老闆: 客戶想要 "今天以前 30 天的資料報告",這星期五給我.
工程師: ...(暗)

一開始就往南走,是不可能走到台北的. 最後的下場就是亂改硬上,要不就是假日加班沒加班費外加公司不開冷氣之砍掉重練.

死期的壓力

不知為什麼,常覺得客戶覺得每個功能都很簡單. 只要嘴砲一發,程式碼就能工工整整地射在螢幕上,然後也不用測試就能上線執行.

老闆: 那個之前不是誰誰誰做過了,直接拿來改一下看看.
工程師: 我可能要花點時間搞懂他的作法,然後...
老闆: 我相信你可以的,後天給我.
工程師: ...(信你娘親)

在如此這般 精確的時程 安排下,大部份的工程師應該都會選擇 求有再求好. 畢竟,一個能動的東西 強過 一個不會動但好用的東西,能交差就好. 很可悲的想法,但花心力弄到好用,老闆也不會加你薪,不如做個可以跑能交差,早點下班做自己想做的事,這比較實在!

客戶自己都不知道自己想要什麼

老闆: 那個功能有客戶反應不好用,想要加一些功能.
工程師: (我一定要搞懂客戶想要什麼) 那可以給我客戶陳述的需求或假想的使用畫面嗎?
老闆: 他只說不好用,你能不能自己上網 Google 一下,看看客戶可能想要什麼功能.
工程師: ...(這殺小)

(圖片來自: http://hi.baidu.com/bestkobe/blog/calendar/200701)

這真的很無言,通常被打槍機率很高,這完全是叫工程師自己挖個自己的墳墓吧! 當然這樣流程下做出來的東西先不論好不好用,連是不是打中客戶的舔蜜點都要先插三柱香拜一下. Orz

自己的感覺:
寫自己的程式是件開心的事. 寫客戶的程式是件該死的事. 搬磚頭你花多少心力就搬多少塊磚頭. 寫程式你花再多時間,只要一句 "這不是客戶要的東西",就請砍掉重練.

不負責結論:
可以動是應該的,沒有錯誤該偷笑了,不好用,如果能的話就將心比心吧!! Orz
客戶真的痛苦嗎?
工程師真的痛苦嗎?
請想想錢跑到誰口袋去了.

軟體建構之道 (Code Complete) 第二版 第十二章到第十三章心得

第十二章-主要資料型別
本章在說明使用 int, float, ... 這些資料型別的注意事項..
很多小重點..
我只紀錄一下對我寫程式比較有幫助的..
有需要自己去書店翻一下..

使用布林變數簡化複雜的測試..

if ((eatBreakfast() && eatLunch() && eatDinner()) || (hasHeadache() || hasStomachache()))
{
}

上面看完應該眼睛都花了..
你應該開始會想 "我會在需要的時候弄懂這段程式碼在做啥" ..
其實我上面例子想表達的是..
如果 三餐都有吃 或者 身體哪裡不舒服 的話再去做區塊內的事..
而不改寫成..

boolean eatMeals = ((eatBreakfast() && eatLunch() && eatDinner());
boolean isSicked = (hasHeadache() || hasStomachache());

if (eatMeals || isSicked)
{
}

這樣不就清楚多了..

避免常值即便是安全的常值..
就算你知道打籃球最多同時上場 5 個人..
程式碼中最好還是使用 具名常數 來取代 5..

private int final MAX_PLAYERS_COUNT = 5;
...
public void checkPlayerOnCourt(int inPlayerOnCourt)
{
  if (inPlayerOnCourt > MAX_PLAYERS_COUNT)
  {
    // 判技術犯規.
  }
}

另外這樣你程式中也避免掉到處都有 "5" 這個魔術數字的問題..

如果是多維陣列請考慮用比 i 和 j 更有意義的名稱..
比如 Array[i][j][k] 考慮改成 Array[長][寬][高] 之類的..
要不改成 Array[ptrX][ptrY][ptrZ] 也比較不會弄錯(但還是不夠好)..
總之轉成現實中對應的物件而不是電腦程式的術語..

第十三章-異常資料型別
本章比較著墨在 結構 和 指標 上面..
我總覺得 JAVA 的 類別 就含蓋掉 結構 的部份了..
另外寫 JAVA 也不會處理到指標.. Orz
不過我還是乖乖看完了..

使用結構簡化參數清單..
直接拿書上例子..

addEmployeeData(name, address, phone, ssn, gender, salary)

如果我們直接包裝出一個員工結構(員工包含 name, address, ...)..
那這一大串參數就可以變成..

addEmployeeData(employee) // 參數簡化成一個員工結構.

這樣做的優點有..
1. 不用去記參數的順序..
2. 之後若參數增減也不用修改常式的參數介面(當然還是要修改常式裡的程式碼)..
缺點則是..
1. 增加耦合度..
之後要使用到此常式也必須知道 員工結構 這個東西..
所以結論是..
程式設計師要自行判斷哪種情況適合 建立新的結構來簡化參數清單 ..
用到的參數數目夠多 -> 直接傳入結構
用到的參數數目少 -> 直接傳入基本資料型別的參數

使用抽象概念層級來存取指標..

node = node.next <-> account = NextAccount(account)
event = eventQueue[queueFront] <-> event = HighestPriorityEvent()

右邊的作法 將原本的程式碼抽像化成一個常式..
對我來說..
比較好閱讀..
且可以重複利用常式 而不是 到處都看到 event = eventQueue[queueFront] 這種東西..

這兩章..
我看得有點辛苦.. Orz

Google Reader 也來熱門推薦了

剛剛我突然發現我 Google Reader 右上怎麼多一塊東西..
一定是我平常上班太認真了才遲了那麼久發現..

點進去一看..

還蠻不賴的..
有多少人訂就寫多少人..
簡單明瞭..

不免俗的 Search 一下自己的部落格..

不賴..
這三個人中一定有一個是我老師.. 囧rz

無言的心情

自己好久沒寫心情文了..

GF 說最近我都在寫部落格..
但不寫些東西..
讓自己腦袋動起來..
才不會想東想西..

每天的時間都過得很慢..
不是什麼會死人的病..
但就是會難過..

寫寫寫..

讓我覺得至少有開了另一扇窗的感覺..
久違的心情文..
也是不太想寫的心情文..

推啊推啊小黃人

第一次看到 FunP 這張圖就覺得很好玩..
如果你的文章被 FunP 上的好朋友推的話就會出現一個小黃人..
我好朋友不多..
文章也很少被推..
所以我只最多看過三個小黃人..
真的很好奇..
最多會有幾個小黃人出現(身體流著工程師想追根究底的血液)..

雖然只是一張小小的圖..
但總比下面出現一行 "好友人數: 1" 來得感性一點..
如果我在我的 UI 裡藏這種東西..
應該會被贛醮到爆.. Orz
我也好想加喔..
同個 IP 都一直在 MSN 就跑出一個小綠人出來好了.. Orz

不過我第一次看到小黃人是有點會意不過來..
不知道為什麼是招手..
沒辦法直接聯想成有好友在推我文..
所以我內心的認定好友推文的 ICON 如下..

帶點黑(黃)色幽默..
這就是我每次參加比賽都不會得名的原因.. 囧rz(自己找的理由)

重點在態度

今天一早我的外國同事丟給了我兩個部落格的文章..
也都是在講述程式設計師的一些行為..
他怎麼知道我很愛看這種東西.. Orz

Are you inadequate?
如何變成一個成熟的程式設計師?

作者建議:

• 讀比你聰明的人寫的部落格.. (O) 我有看 Qing 大 最近寫的程式設計文..
• 寫你自己的部落格.. (O) 但跟程式有關的都是亂寫.. Orz
• 每天都要學新東西(任何事物).. (O) 多少都有翻書..可是技術的碰不多..
• 無時無刻都在寫程式.. (X) 抱歉我真的做不到..

反正不要安於現狀..
不害怕去嘗試新的事物..

The Developer's Worst Excuse
我只對文中這句最有興趣..

I didn't had much time, so I did everything the fastest way possible…

翻成中文在白話一點..
"Deadline 快到了!! 反正寫出來可以跑就好了!! 林北沒時間設計啦!!"

會有什麼下場..
都是老生長談了..
每個 RD 一定也碰過這種爛扣..

反正重點在態度..

你寫 Code 的態度..

決定接 Code 者的贛醮程度..

看完以上兩篇..
只覺得外國的月亮沒有比較圓..
與其怨天由人問自己為什麼不是在 Google 裡寫扣..
不如先做個對自己程式碼負責的人.. Orz

軟體建構之道 (Code Complete) 第二版 第十章到第十一章心得

第十章-使用變數的一般問題
變數有效的時間越短越好..
要使用時才宣告定義..
使用該變數的程式碼集中在一起..
原因無它..
就是增加閱讀性..
你不用擔心是不是別的地方會去修改到該變數..

跨距越短越好..
跨距就是同一個變數下次出現之間隔的行數..

int a = 0;
int b = 1;
a = a + b; // a 的跨距為 1.

其實觀念同上..
反正你就想你家冰箱會去冰箱拿飲料的就家裡那幾個人..
遭小偷我不知該如何解釋 Orz..
若你家冰箱擺在馬路上..
你想要是哪個路人幹了你家飲料就比較麻煩了..

避免變數有隱藏的意義..
比如..

int thePlayerCount; // 球員數目.

thePlayerCount 就專心至力於紀錄球員數目就好..
不要搞個..

int thePlayerCount; // 球員數目,若為-1代表籃球社倒了.

一個變數就專心做一件事就好了..
這種偷吃步..
都是爽一時..
一痛就痛到你離職換公司..
再痛到下一個倒楣 RD 身上而已..

書中一句話個人覺得很實在..

僅可能保持變數的區域性,因為區域範圍有助於智慧管理.

這章也很實用..
建議入手可先翻一翻..
小小習慣大大改善..

第十一章-變數名稱的力量
這章大至說明一些慣例..
幾個熱門的語言也有命名的表格供參考..
關於縮寫也有幾個不錯的規則(命名太長一直是我的痛處 Orz)..

命名要清楚..
不要亂加入數字..
...
(超多請自己去書店翻)

這章適合..
還沒有建立起自己命名習慣的人..
覺得 Review 自己 Code 會產生閱讀障礙的人..

變數命名這種事都說起來簡單..
有心的人就是有心..
沒心的人就還是 x1, x2, temp 照樣給你寫一堆啦..
又想到我那用 JAVA 寫 C 風格的前輩了.. Orz
不知道他現在過得好不好..
快轉行吧你..

Wii Fit 隱藏體重

女(男)生們..
若你男友(閃光,女王)買給妳(你)..
請不要太開心就中計了..
若妳(你)不想要妳(你)的體重曝光..
這篇不得不看..
沒搞懂前..
千萬不要玩用妳(你)的 Mii 玩 Wii Fit..

有些人可能不想要自己的體重曝光.. Orz
那在下面幾個地方要注意一下..
我自己上網找找不到..
所以才無聊寫這一篇..
已經有人寫的話不要鞭我..
我只是覺得可能有人會需要知道.. Orz

第一次加入 Mii 的時候

除了 BMI 也會跑出體重喔..
不要入手太嗨了..
發現旁邊的人臉上已經三條線了..

每天的年齡測驗
畫面應該同上..

Wii Fit 頻道
點入自己的 Mii 後..
就能看到體重的曲線.. Orz

 

如何不讓自己的體重曝光?

(圖片截自官網)
1. 在 Wii Fit 頻道中點選自己的 Mii ..
2. 進入後..點選後右上方有個 "個人設定" 的按鈕..
3. 進入後..點選 "第一個選項" 來設定自己的基本資料..
4. 進入後..點選 "最下面的選項" 即可設定密碼..

之後若要使用你的 Mii 進行遊戲就得輸入密碼..

進行遊戲時是都不會顯示跟體重有關的資訊的.. Orz - 請安心遊玩
反正..
謹記..
旁邊有人時不要做測驗跟觀看 Wii Fit 頻道就好..

以上..
希望造福想入手但又怕個人資訊外洩的朋友.. 囧rz

夜王

(圖片截至官網: http://www.tbs.co.jp/yaoh/chart/index-j.html)

原本對這齣日劇完全沒有興趣的..
主要原因是我覺得台灣的廣告剪的不是很好..
主角就出來一下下..
其他都是小角色抱一個女生..
然後解說該男公關是什麼類型..
一開始我還以為是 "孃王" 類型的日劇..

現在只覺得慶興自己有看..
今天撥完最後一集..
感覺真熱血..
最後一集真的很有熱血 Fu ..

遼介跟聖也把自己的副手找回來..

遼介派跟聖也派聯手..
金四郎 & 光 (那一桌全部都是歐巴桑太 Kuso 了)
夏輝 & 大河 (這兩人實在是不同型的啊)
修 & 蓮 (超級帥哥軍師..我腦中只浮現 諸葛亮 跟 周瑜 聯手的畫面..)
遼介 & 聖也
聖也最後一集真的太帥了..
我覺得後面根本感覺不出來遼介是主角啊.. Orz

歌舞妓町四天王登場..

聖也帶著光到關西成為 NO 1..

幹..
看完好想當男公關啊..
這麼有漫畫 Fu 的 日劇不知道還有沒有機會再看到啊..

補充一下..
倒數第二集 猩惠 亂入..
好久沒聽到她講 Pekoli 了.. Orz
某一集 及川奈央 也有客串演出..
及川奈央 是誰?
我也不知道.. Orz

另外..
我們家看到 修 都直說帥..
我開始懷疑我的性向了.. Orz
下一齣 女帝 剛好可以調整一下我的男性荷爾蒙分泌量.. Orz

軟體建構之道 (Code Complete) 第二版 第九章心得

第九章-虛擬碼程式設計流程
虛擬碼程式設計(PPP, Pseudocode Programming Process)..
簡單說明就像是寫一篇作文..
先訂好大綱..
在根據大綱來寫出每章節的內容..

對應到寫程式..
作文 <-> 常式
大綱 <-> 虛擬碼
每章節的內容 <-> 實作的程式碼

這樣做的好處有..
從比較高的層次切入而非一頭栽入程式碼中..
而後..
虛擬碼也能轉換成程式中的註解..

對我來說..
從比較高階的層次切入我就不用先去管要用哪些語法去實作..
虛擬碼之後就可以直接拿來當註解..
比我整個程式碼都寫完再來寫註解的那種不得不做的感覺來得好太多了..

以下則是其他我比較有印象的部份..

當虛擬碼所需要的實作程式碼行數超乎預期..
請將這些程式碼集中建立一個新的常式..

請懷疑自己的程式碼..
根據書中提供的數據..
只有大約 5% 的錯誤來自硬體,編譯器和 OS..
看來 "為何在我電腦上可以跑" 這句經典名言是最好少用.. Orz

以下這句新名詞還蠻屌的..
大鍋炒編譯: 大鍋炒 -> 來編譯 -> 修到正
程式碼東拼西湊..
混在一起 Compile 看看能不能跑..
有錯在修..
重新 Compile..
(以下重複)

還好我還沒有這種問題.. Orz
我只是在不穩的房子上面加蓋危樓而已(遠望狀)..

最後一段書裡的話自己要記住..

埋頭苦幹通常代表不完整的認知..
而且也是現在和未來必然出錯的保証..
重新設計錯誤的常式絕對值回票價..

這章建議有買的人可以先看..
實用度蠻高的..

軟體建構之道 (Code Complete) 第二版 第八章心得

今天都在解 Bug ..
所以也是低一下看一下..
反正只是寫寫心得..
非專業分享.. Orz
說不定有人看了就會去買這本書..
除了勸敗外我這樣也算對台灣軟體產業盡一份微薄的心意啊.. Orz

第八章-防禦性程式設計
之前看 Head First 系列稍微有點印象..
就你所有的常式傳入的參數你都給他檢查一遍..
不管他看起來像不像男生..
你都還是要給他檢查下去..
不過書裡頭當然不像 Head First 那麼簡單只給個大方向啦..

建立一層專門驗證的 Level(路障,防火牆)在外部與內部類別之間..
有點像 Facade 模式..
但我以前從沒想到這樣做..
沒設計就直接在 View 的層次就開始驗證了..
不好的習慣..
好 RD 不要學..

其他大部份就是編寫程式中的實際範例啦..
對我來說可能比較有感覺的就是..
接到低階例外要丟出高階例外以符合架構上的抽像概念..
若接到例外不處理也要在程式碼中說明..
這兩點我比較常用到..

喇賽完了..
看到 220+ 頁..
還有快 700 頁待看.. Orz

WiiFit開箱文&極度危險使用心得

官方網站: http://www.nintendo.co.jp/wii/rfnj/index.html
這款遊戲我已經注意很久了..
但沒想到我竟如此早入手..
還是在只有一隻腳的狀態下入手.. 囧rz
水貨商賺蠻大的..
我以 NT$ 4600 入手(原價 8800丹)..
反正先買先享受吧..

另外..
為何標題那麼聳動..
事實上目前右腳處於一個不能動的狀態..
但我又不想拍拍盒子應付了事..
就這樣試玩了.. 囧rz
事後證明..
我現在還沒辦法享受 Wii Fit 這塊遊戲..

首先不免俗是外殼照一張..
整盒包含一個平衡板 + 遊戲..
總共是 5 Kg 重..
若跟朋友交情不夠..
千萬不要請他從日本帶回來..
應該會翻臉..

使用者體重上限 136 kg..
以後任天堂可出擴充模組..
胖一點的人一腳一塊板子就可以支援到 272 kg 了.. Orz

平衡板是無線的..
吃四顆 A4 電池..
記得玩之前平衡板跟 Wii 主體要同步一下訊號..
按一下 "平衡板上的紅鈕(上圖裝電池的地方)" 跟 "Wii 主機面板上的紅鈕" 即可..

板子跟遊戲合體照一下..
我現在身體不太方便搞個疊疊樂..
我怕我東西沒疊好我自己先摔死..

進入遊戲後先建立個人資料..
輸入身高.生日..

接著要用到板子了..
幹..
這樣怎麼用..
只好..

這樣好一點了..
可是真的很可怕..
搏命演出..
一不小心很可能就會..

醫生: 你腳怎麼更嚴重了?
我: 玩 Wii Fit 又給它蹬斷了.. 囧rz

接著它會測定你腳的重心..
這倒是真的很重要..
身體很多毛病都是因為姿勢不良(重心不對)造成的..
很明顯..
我這塊板子沒有故障..
左邊吃了 66.8% 的力..
右邊吃了 33.2%
身體重心在左腳跟.. T.. T

你上板子後它會測量你的重量並計算 BMI ..
我是在標準上限左右..
預計這陣子會肥上去.. T.. T

量完以後..
你的 Mii 就會根據體重變胖變瘦喔..
我的肚子.. T.. T

中間會做個控制身體重心的的測驗..
計算你的年齡..
少隻腿的我是..
52 歲..

打擊很大..
所以這張有點手震..

以下的我就都不敢玩了..
我只玩了一個瑜珈的呼吸我就快死了.. Orz

整個 Wii Fit 分成四個種類的運動(或是遊戲)..

肌肉運動..
光看我腳就痛..

瑜珈..
我就是做左上第一個..
唉..
光這樣就已經有搏命的感覺..

有酸素運動..

網友 Derek 提到..
酸素在日文中是「氧氣」的意思，所以有酸素運動，也就是我們平常所說的「有氧運動」。

這標題就讓我想到 "極限體能王" 常說的乳酸地獄.. Orz

平衡運動..

我只玩了瑜珈..
所以其他沒玩就不要亂喇賽了..

一進去就由電腦教學..
有語音又有影片..
你在做的時候板子也會不斷地計算你的重心..
每個運動都還有排行榜.. Orz
就這方便我覺得有點像 "互動教學的軟體" 反而不太像是 "遊戲"..
雖然項目沒有很多..
但總比自己一個人邊翻書邊做好玩一點.. :)

為了我的腳..
其他我關機啦..
有個小功能就是在 Wii 頻道會多出一個 Wii Fit 的頻道..
這樣你就不用把遊戲放進主機就能得知你身體狀態的趨勢圖啦..

拉拉雜雜說了一堆..
大家可以到 "我們的 Wii 頻道" 找 "Wii Fit 紹介映像" 喔..
我覺得這段影片很清楚介紹了 Wii Fit 的功能..
若沒有 Wii 的話可點 http://wii.com/jp/movies/wii-fit-movie1/
應該是一樣的影片..
主機 + Wii Fit 一次購入吧..