HYPO 12平方的感動

從去年底結婚後就不知道在龜什麼? 行動力降低很多,照片拍了一堆,但卻都躺在硬碟裡. 上星期終於一鼓作氣在家把去年蜜月的照片挑一挑拿去做 HYPO 了!

六千多張只能挑出36張也真夠折磨人的了,連續兩天的假日就看到我光著上身,在電腦前滿頭大汗挑照片上字的宅樣,只能說美好的事物後面一定有不為人知的黑暗面.

HYPO 12平方是採取固定時間出貨的樣子,所以就算你先做好,它還是統一某一天才會出貨給客戶,不過寄送這一部份倒是蠻快的,6/26出貨我隔一兩天就收到了.

看起來很有質感,上面是主標題,下面是副標題. 我學別人副標是打上出遊時間,這樣一看就記得是什麼時候去日本玩的.

書皮是 WF 愛的綠色, HYPO 12平方還真的蠻迷你的,大概就跟一張音樂CD差不多大張. 主標題我下的很白話,怕寫太繞舌又被人酸太煽情(我真的怕了(郭富城)).

HYPO 12平方的印刷效果很不錯(我都是原圖上傳),相較於 HYPO Ticket 和好感動,輸出表現算是好上一些. 基於裡頭36張,都是我跟 WF 的照片,沒放什麼風景照,我想也不用放上來閃人了. 如果喜歡拍風景照的人,拿 HYPO 12平方來做自己的寫身書也是很不錯的選擇.

東京賞櫻急行軍-根本是新宿街拍大集

續上篇 東京賞櫻急行軍-名副其實的目黑川櫻花.

本篇幾乎沒有景點介紹,仔細看根本就是在新宿到處亂晃亂拍而已. XD

永遠看起來那麼帥氣的木村拓哉.

身上都是早上敗家的東西,所以兩人先回飯店把東西清一清. 每天都要從新宿站走回飯店,讓我真的很懷念去年就在上野站附近的 CUBE .

TOKYO HEART - 宮崎葵 幫 Tokyo Metro 代言的一個形象活動. 只不過是搭乘的交通工具,都能e夠包裝成一種生活態度. 概念與設計真的是充斥在日本人的生活環境當中.

會拍這張也代表我們今天偷懶,直接坐東京 Metro 到新宿三丁目逛,沒辦法只能安慰自己是用錢買時間和體力啊! XD

0101 樓上的 Uniqlo ,不過又是女性專賣店,不過這分店也是小的可怕,類似台灣一般百貨公司少女專區的櫃位,佔地就如上圖所示,繞一圈就沒有了.

WF 進去巡邏一圈,我在一旁對著螢幕亂拍.

到了靖國通, WF 就殺到藥妝店去逛了,我則是到一旁的電玩店去發呆. 這次去日本,我什麼電玩的東西都沒有買,其實是很想亂買(看到貨色都那麼齊,就會很有購買的慾望),但想到回去想做的事實在太多…

相信這次去電玩店,店員應該都能在我的頭上看到天使與惡魔在打架吧…

日本的免費衛生紙都很大包,但日本人似乎不太愛拿.

戀巴的 momo 也出書了,書裡頭有穿癢眼的泳裝喔. XD

 

WF 吵著要吃東西,不過還好是水果,那就任她吃了.

我比較喜歡 misono ! 我們去的第一天他們在新宿有辦一場突襲演唱會,沒有看到實在是太可惜了. Orz 

不過應該只有我想看…

這家是謎片偶爾會出現的戰場,裡頭還有蠻多”明星”的簽名. 店內還真的蠻小的,很難想像這麼小的地方也能夠拍片. Orz

不過我啥都沒有買,就別在誤會我了. 出國當觀光客,臉皮就是比較厚一點. XD

檢視較大的地圖

新宿站東口

明明只是隔一個車站,但我總是能夠迷路. 今天走的到的地方,明天就可能走不到. XD

檢視較大的地圖

每次都會故意經過,但卻沒什麼膽量走進去…

西武百貨內的 Uniqlo 還蠻大間的,最後一晚在這邊補了不少衣服回台灣.

整個新宿東西南北口都繞過了,這還不包括路不熟多繞的路,看的出來臉已經想回家睡覺了.

新宿真的是個不夜城,上次住上野很明顯時間一晚,就只剩下一些居酒屋有在營業了. 比起營業時間長度,台灣就真的就是樂勝了(新竹不包含在內).

也是謎店之一,書跟片子為主,沒有其它有的沒的商品. 再說明,本人真的不是愛逛這種店,只是台灣沒有,去日本玩有機會當然是要去逛一下. XD

若有問題想問,可留言告之,我以我看到的情況回答. XD

最後一張照片無意義…

這一篇只是要說明,我還記得我還有遊記沒寫完,請大家不要放棄我… Orz

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第八章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第七章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章是本書的最後一章,我終於 K 完這本書了,雖然頁數不多,但看原文速度真的慢很多啊!

注重效率的團隊 將之前章節強調的觀念,以套用在團隊的立場在強調一次. 成員間要多交流,大家互相學習及成長,把好的開發流程或概念帶進團隊來,整個團隊不斷往前邁進,公司對外才會更有競爭力.

無所不在的自動化 告訴我們電腦是處理重覆性工作的專家,懶惰則是好的工程師需要具備的特性之一,利用工具或自己開發程式,把需要浪費時間的工作交給電腦處理,省下來的時間再去學新的東西.

無情的測試 強調測試並不是用完即丟,或是寫完就不用去修改它的. 測試程式應該是不斷被執行,並且會隨著程式碼演化的.

代碼文檔不分家. 註解是程式設計師最好的朋友,多花一點時間到離職都可以受用無窮,大腦就應該拿去裝一些需要思考運轉的東西,而不是用來挖掘當初為何自己要這樣寫的理由. 另外,每一份印出的文件都只是當時專案的快照,並不代表其永久有效,透過使用開放編輯的方式,讓文件跟程式碼同步演化,文件才有其存在的價值.

巨大的期望 需要與客戶持續互動,才能確保專案是朝著客戶想要的方向邁進. 回饋的頻率拉得越長,其修改所需的代價也會越高.

傲慢與偏見 - 很日劇式熱血的一小章. 反正就是要激發讀者身為職人的自尊,我以我的程式碼為榮,別人看到作者是我就知道這是品質保證. 因為自尊所以更認真保證品質,品質提高別人對自己的 Credit 變高,如此便是一個良性的循環.

第七章 Pragmatic Projects

Pragmatic Teams

• 開發團隊必須重視程式碼的品質.
• 開發團隊必須察覺不論是專案內(ex:新需求)或專案外(新技術)的變化.
• 鼓勵團隊內的成員互相交流.
• 建立成員對開發團隊的認同感.
• 在一個專案中,給予每個人負責不同面向的責任,以免多個人都在做一樣的事情.
• 不要看完書就急著要求團隊開始實行,維持夠好的規範和風格即可,而不是將額外的負擔加諸在開發團隊上.

Ubiquitous Automation

• 當你發現自己不斷在重複某些步驟時,那就是該自動化的時候到了.
• 電腦本來就適合用來處理重複性的工作.

Ruthless Testing

• 透過測試能盡早發現問題.
• 發現問題後,將該問題建立成測試條件.
• 程式本身沒有問題,但給個不是使用者想要的東西,那還是有問題.
• 使用者不好上手的操作流程,也算是有問題.
• 越解耦的程式碼,若容易做模組測試.
• 測試覆蓋範圍的重點,不在於有測到所有程式碼,在於有測到所有的狀態.

It’s All Writing

• 再強的記憶力也抵不過一支筆.
• 註解說明為什麼要做這件事,動機和目的. 而程式碼本身會說明如果做這件事.
• 良好的變數/方法命名習慣,讓程式碼更容易被閱讀.
• 雖然這段程式碼你可能只會寫這麼一次,但它可能之後要被閱讀好幾百次.
• 比”沒有意義命名”還糟的是 – “讓人產生誤解的命名”.
• 利用工具或自寫程式,將文件的表現方式(ex: PDF, HTML …)從內容中獨立出來.

Great Exceptions

• 寫出來的東西不符合使用者的期待,那就是失敗.
• 藉由不斷與客戶互動(ex: 展示雛型),來確保成品是客戶所預期的.
• 試著超出使用者所預期,只要超出一些些,讓使用者覺得我們真的是想做一個很好的系統.

Pride and Prejudice

• 在自己的程式碼上署名以示負責.
• 尊重夥伴所寫的程式碼,你怎麼對他們,他們就怎麼對你.

老媽的底片機

Canon EOS 33 + Tokina AT-X Pro 28-80mm 1:2.8 + 過期的 iso 400 底片

當事人要捉照片請至 Picasa 相本:

2009/6/23 底片機

跟老媽借了好久,終於把36張給按完了. 但不知道是底片過期的關係,洗出來的效果有點年代久遠的感覺.

按底片感觸最深的就是,拍完會不自己對著那不存在的 LCD 準備預覽. 在洗出來之前,完全不知道自己拍了什麼拍的怎麼樣,有種再拆復活節彩蛋的驚喜感.

覺得自己處於資訊發達的數位年代,反而很容易對週遭事物麻木. 每天要吸收和製造的資訊都太多了,數位雖然帶來了生活上的便利,卻也讓原本應該感動的事物變的那麼理所當然…

初探 git 版本控制系統

git 跟 CVS 和 SVN 一樣,可以是有中央儲存庫(repository)的主從架構(ex: 連線至 github).

git 也可以是分散式的版本控制,每個人都是自己的儲存庫. 這代表每個人對於同一個專案,都可以有一個自己版本.

在分散式的架構下,本機就是儲存庫. 這代表就算沒有中央儲存庫, Git 也可以直接在本地端使用. 坐火車|坐飛機時 commit 到本地端儲存庫,等到有網路時再 push 到中央儲存庫即可.

git 不會像 CVS 和 SVN 一樣,每個資料夾下都會產生額外的資料夾.

git 觀察檔案內容而非檔案名稱. 在不同版本間,只要檔案內容一樣就只會有一個實體. 如此能節省空間及提升效率.

延伸閱讀:

• Git 原始碼管理
• Getting Started with Git and GitHub on Windows
• 使用Git與Github管理軟體開發專案
• Git 版本控制系統 (1)
• Git 版本控制系統(2) 開 branch 分支和操作遠端 repo.
• Git Cheat Sheet
• 基本 VIM 操作指令

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第七章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第六章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章重點放在開始寫碼之前應該有的準備工作 - 收集需求,解決臭蟲,確認可行性,製訂規格 和 開發流程.

需求之坑 在於使用者很可能自己都不知道自己的需求為何的情況下,其實很多需求是在回饋的過程中,不斷地被挖掘出來的. 個人的經驗通常是,通過層層的關卡後,我做出來的東西,通常變的不會是終端使用者所想的功能,以至於後續會不斷上演砍掉重練的情況發生.

解決不可解的謎題 和之前提過的”靠巧合編碼”一樣,都是要求程式設計師要真正了解問題,把發生問題的原因解決,而不是掩飾表面或後續衍生的問題.

直到準備好 要求在寫碼之前要先規劃藍圖,房子不會邊蓋邊想要改幾層,但寫程式時常會被要求這要搞,但無腦之開寫的下場,辛運一點就是可運行但很難維護的程式碼,最衰的就是寫到一半才發現根本此路不通準備黑掉…

規範陷阱 相對於不規劃就編碼,它位於光譜的另外一端(凡事太過或是不及都不會是好事 XD),嚐試著一次完成所有的規格是件不可能的事,再加上客戶不斷增加或變化的需求,規格與實作往往會漸行漸遠. 做人腦筋不要太死板,規格也是一樣,且戰且走,邊做邊改,最後才不會拿到一本根本過時的兩千頁規格書.

圓圈與箭頭 要程式設計師對於各種開發方式採取開放的態度. 個人覺得這可以套用在各種地方,不排斥學習新知,好的學起來,不好的也了解壞在哪裡. 井底之蛙,以管窺天. 海納百川,有容乃大.

第七章 Before the Project

The Requirements Pit

• 將會變動的部份從需求中分離出來.
• 找出客戶為何需要此需求的原因,如此當你實作時才會更貼近其需求.
• 實際到使用者工作環境,觀察使用者會採取的行為操作.
• 利用工具紀錄新增的需求,好讓自己能夠知道目前到底增加了多少需求,以求通盤了解整體狀況.
• 從專案開始,就維護一份詞彙表,用來讓客戶,程式設計師以及其它人對照參考,確定彼此指的是同一個東西,而這份表格也能應用於使用者介面以及程式變數名稱上.
• 將文件放上內部網頁上,可供參與者觀看或編輯. 而非印出一份沒人會看也辦法即時更新的文件.

Solving Impossible Puzzles

• 跳脫既有的框架來思考問題.
• 遇到難題時,不要明知不可為而為之. 反之,列出所有可能的原因,然後一一去驗證,直到找到真正的問題來源為止.
• 靜下心來思考,哪些是真正的問題? 哪些只是衍生或是使人誤解的問題?

Not Until You’re Ready

• 準備好了再開始寫程式碼! 坐下來啥都沒想,邊寫邊想,那只能叫做敲鍵盤而已.
• 分辨你只是 想拖台錢 還是 真的覺得還沒準備好 的方法: 找出需求中你認為最困難的部份,開始寫一些 Prototype 的程式碼,若你發現你寫的很順,甚至開始覺得這樣下去只是浪費時間,那代表你已經準備好實作這個需求了.
• 正式編碼前先撰寫 Prototype ,就像大軍出動前會先派斥候去偵查敵方實力一樣.

The Specification Trap

• 不用想一次就補捉出系統的所有細節.
• 長篇大論讓人很好入睡.
• 取代先定規格再編碼的方式,讓 編碼 和 規格 同時進行. 這種開發流程鼓勵我們不斷從實作中得到回饋,然後將其轉換成最適合的規格. 編碼跟規格是同步在進化的,規格不在是一灘死水.
• 有經驗的程式設計師,在編碼時腦中應該會浮現最適合當前情況的設計抉擇.
• 在沒有考慮技術層面下,很容易定出沒有辦法實作出來的規格.

Circles and Arrows

• 對於各種開發流程,不要太過拘泥於形式.
• 客戶喜歡看到實際的產品,而非文件及圖表.
• 對各種開發流程採取開放的態度,學習並融合其優點,不斷改進自己的開發流程.

從地獄歸來的 ipod nano4 開箱文

話說前兩天,我把壞掉的 ipod nano2 丟進青草湖裡,突然有個中年大叔拿著一台金色的 ipod 浮了起來.

大叔: 這台是你掉的 ipod 嗎?

我: 這不是我的…

然後大叔又沉下去,過了兩分鐘他又拿了一台銀色的 ipod 回來.

大叔: 這台是你掉的 ipod 嗎?

我: (看了一下機身發現耳機孔會整個掉下來) 這台是我的.

大叔: 你很誠實,所以我決定送你一台最新的 ipod nano4 黑.

以上故事,純屬虛構…

這台 ipod 是 WF 給我的驚喜,背負著被我誤會又在亂買包包衣服的屈辱(!?),辛苦地在各大網路商場訪價後的成果.

ipod nano4 8g + 保護貼 + 矽膠套 + 耳機收納套 + USB 轉接插頭 = 4700 元整

上一下 PTT 訪了一下鄉民二手價也是落在這個範圍,二手價買到全新機不得讓我心生佩服. 但我的 ipod 是紙盒包裝而不是官網看到的塑膠盒,很怕她是買到山寨機,不過機身序號能上網申請 Apple ID 應該是正版的吧? 山寨有那麼強大?

終於…

我也有一台不盲不聾的健康 ipod 了,雖然拿到前心裡一直覺得 WF 不用花這額外的錢,但拿到手後我似乎是異常的興奮.

上班之後,我只有送家人東西,然後看到他們用得很爽,我才會有開心的感覺. 自己買給自己的東西,入手後都還是一張死魚臉. –.. -

背後原本可以有雷射刻印服務,但 WF 考慮到之後脫手問題,就選擇不搞這套了. 我只能說這想法整個專業啊,連之後的事情都幫我想好好了,但也很怕他連賣場都幫我弄好了...

這代跟三代相比,有加了簡單的感應功能,翻轉機身會影響到介面的顯示方式或切換功能. 比較有趣的就是你可以搖一下 ipod ,它就會隨機切換到下一首歌. 不過這動作要夠大,小小的它不會有反應,上星期 LH 的島居24小時特輯中,島居也有搖過她的 ipod ,不小心手滑真的會整台飛出去啊.

我很喜歡這個搖晃換歌的功能,但旁邊的人應該不太喜歡這個功能. 我個人覺得這功能會間接讓使用者發動具物理傷害的招式. 果然! ipod 會讓聽音樂不在只是聽音樂! (逃)

從今天開始我終於能替每首歌評分啦! XD

當然最後要謝謝 WF ,這篇文跟圖就是回報您最好的方式啦!

最後的最後,願各位的另一半,心裡頭都住了一個手拿金色__(請各位自己印出後自己填字)的大叔.

天堂掉到地獄的 ipod nano2 另一種型式的開箱文

先說在最前面,我這篇沒有要搞笑的意思,更不是因為沒有梗寫部落格才出此下策的…

話說我之前的文有題到,我手邊有一台已經白屏的 ipod nano 2代(偽 shuffle),網上爬到的招式都用過了:

1. Reset .
2. 轉為硬碟模式後,格式化,透過 itune 重新安裝.
3. 放電後重新充電.

除了方法二讓我短暫看到使用者介面外,大半的時間都是白屏狀態. 上網修不包含運費是要一千多元,這價錢我已經寧願多貼一點錢買 ipod nano3 二手機了. 買面板回來自己修,但若修不好也是等於多花那面板錢.

只到上週 OB 賽才發現 H 學長有參與這款面板的設計,就跟學長凹了幾塊面板回來,心想真的是天助我也!

剛剛準備照著網路上的分解圖準備開修中,此時嘴角還是上揚貌. 雖然沒修過,但我臉上的表情告訴著各位 – Yes! We Can!

他上下分別各有四個螺絲,前面三個都很順利,但第四個一方面太小一方面鎖很緊,不得不跑去 NOVA 買了一支小十字起回來,但殘念螺絲已經被我鎖花,只好硬著頭皮直接跳到下一步 - 將板子從機殼中推出…

我現在相信工業設計一定有它的道理在,沒拆掉的螺絲剛好就卡死耳機接頭的部份,在我推出板子的同時,接頭就這樣硬生生的斷了.

這間接說明了一個可怕的事實,就算我把螢幕修好,這也將是一台沒有聲音的 ipod …

此時我也無心再戰,旁邊拍攝的人也笑到合不攏嘴,她說她一小時內竟然能看到一個人的人生百態,可見我心情落差之大…

另外驗證 H 學長所說的,網路上的白屏現象應該都不是他們家出的貨.

從明天開始就要回復用 PSP 聽歌的日子了! 看著桌上的屍體,我只能說痛過才知有多痛,下次不管怎樣還是交給專業的來好了…

程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第六章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第五章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章主要強調的重點是 – 程式設計師是否真的了解自己在寫什麼. 而 程式黑手 與 程式設計師 的最大差別我想也在於此 - 是否有在用腦在寫程式碼,還是不管三七二十一拼出一個會動的東西而已.

靠巧合編碼 最好的解釋情境 – 修一個關於迴圈的 Bug ,只是不斷地去調整迴圈 index 的範圍,而不是找出錯誤的真正原因. 如果在寫程式時有這樣的心態,那你就是在靠巧合在編碼.

演算法的速度 使用 O() 表示法,在編碼(或 檢視程式碼片段)的過程中就能大概知道其效率,提早察覺效能上可能會遇到的瓶頸.

重構 鼓勵程式設計師週期性地檢視過去的程式碼,昨日的程式碼不見得符合現今的需要. 不斷地透過重構來整理程式碼,而不是在歪斜的骨架上搭建新的疊層屋.

易測試的代碼 在於寫程式之前就已經準備好測試的程式碼,如此所寫的程式碼不自覺就會以好測試為目標來下筆. 理想中,程式碼的大功能會被切分成小功能(這樣比較好分別測試). 另外,測試程式是重構最好的朋友,重構完是否搞砸了原有的功能? 問問測試程式是最快的方法.

邪惡的嚮導 也就是靠 IDE 工具生成出來的程式碼. 如同靠巧合編碼,是否真的了解程式碼,是 程式黑手 與 程式設計師 的最大的差異之處. 就算只是想當個程式黑手過日子,我相信多了解程式碼還是能節省許多解 Bug 的時間,好讓你回家看老婆抱小孩就是.

第六章 While You Are Coding

Programming by Coincidence

• 清楚自己要做什麼再下去做,不要只是盲目地寫程式碼.
• 倚賴可靠的結果,而不是”假設它應該是…”,遇上 假設 請實際去驗證它.
• 不要讓 過去的程式碼 限制了 當下的程式碼! 過時了那就重構它!

Algorithm Speed

• 對於 O() 表示法有所了解,並了解自己寫的程式碼其 O() 值.
• 如果真的看不出來,可以直接調整 input 將結果做成圖表,利用圖表看出大概的效能.
• 根據實際情況選擇適當的作法即可,不需要總是使用最完美的作法.
• 確認是瓶頸後再去優化它,而不要掉進過早優化的陷阱中.

Refactoring

• 與其說寫程式是在蓋房子,更不如說是在規劃你家花園,花草會爛所以你要加肥料,也許你覺得看膩了你又會買新的花回來種. 這裡要強調的是,需求及環境是不斷隨時間而變遷的,不符時宜的程式碼就可以重構之.
• 當你發現 1)重複的程式碼片段 2)正交性很差的設計 3)過時的資訊 4)效能差 的情況,這代表你該重構你所看到的問題了.
• 重構和增加新功能不要同時進行.
• 重構前先準備好對應的測試程式,這樣你能馬上知道你有沒有搞砸任何東西.
• 把重構拆成多個小步驟,每完成一個步驟就檢查一次,而不是一次重構完再來檢查.

Code That’s Easy to Test

• 若欲測試的模組有關聯到別的模組,那先從關聯模組開始測試.
• 測試程式能向別人展示如何使用你寫的程式.
• 測試程式能在你做了任何的變動後,快速告訴你是否改爛了哪些原本正常的功能.

Evil Wizards

• 了解利用工具自動產生出來的程式碼.

逢甲資工系籃 OB 賽

這是一篇流水帳碎碎唸文,完全是以不經大腦思考是否可以寫出來的文.

今年的 OB 賽真的是一波三折,場地感覺一直被學校耍著完,乖乖地照著規則玩,卻眼睜睜地看著不知從哪殺出的程咬金把場地給借走. 明明就是一個月才能借前的場地,但體育館就是能發出一個半月後的場地租借公告,明明就是詭異到不行的狀況,還是只能得到千篇一律的官方答案,只能說那場地應該是某人做時光機提早去借的吧!

投票時間公投了三次,隨著次數的增加,被裝笑的感覺大概是O(n^2),而回應的熱情大概是O(log n). 不管怎樣,在學弟的努力之下,我們總算借到6/6的場地,而我也馬上公告這個好消息!

不過場地好借應該是有它的原因在的,小猴子學弟馬上告知那天是端午補假,而隔週就是逢甲畢業典禮,再來就是期末考了. 我完全無視此補假,根據我的演算法告訴我,最後的結果應該不是硬打就是不用打了. 直到最後兩週前,大家才陸陸續續發現6/6其實並不帶有六六大順的意思.

版上瀰漫著一股不出聲要不就是要上班不能打的詭譎氣息,其實我個人比較喜歡不能打就直說,因為這本來就不是能強迫的東西,反正大家都認識那麼久了,我想應該沒有什麼心不心結的問題了,能夠參與就已經是一種緣份了.

以前還在學校的時候,雖然我不是什麼流氓還是丐幫幫主,但遇到這種打擊球隊士氣的狀況時,不知哪來的勇氣還蠻敢直接幹醮的(上研究所神經崩壞時還幹醮過八哥學弟一次). 隨著年齡增長不知道是冷血了還是冷靜了,說好聽是不強求做人圓滑,說難聽就是冷眼旁觀心不在此,辦活動情緒沒放那麼多了,但我還是比較喜歡那種罵是為了對方好為了球隊好的感覺.

扯遠了,反正在跟杉本請示過的狀況下,統計出來能參加的 OB (包含穿短褲的曉君經理)為18人. 再次強調主動告知不能來,比不聲不響不好意思說話來的有情有義的多.

當天到了球場,看到許久不見的 OB 們,心中的澎湃就不是能用我這爛文筆來形容了.

說真的辦事不發牢騷為的也只是讓大家一年有兩次可以出來聚聚的正當理由. 說很多次了,就算跟屆數差很多的球員不熟,就當做是自己同屆的同學會也不是很棒. 不過我真的有這種想法,是在紅褲學弟離開了我們之後 - 世事無常所以我更不能因為奇蒙子肚爛而隨便放棄這些緣份.

離開學校很久了,雖說出發前又 review 了一次所有學弟的照片名字,但到了現場還是只會認臉而已,這點真的就是要跟學弟們說聲抱歉了!

賽程採正方型四角對戰,一隊比三場. 每一場學長大概都會派我上個1.5~2節左右,不知道是不是最近的減肥計劃的關係,體重是沒減到但體力倒是比上一次 OB 好很多,不會跑個兩趟就在後場開雞排店了. 不過還是殘念,三場下來一分未得,我的身高體重速度才全場的威脅性實在是小的可憐,不過我該做該跑該擋的都還是多少有做到,不用為我哭泣~

可憐的 WF 因為加班無法到場,所以我就更可憐的,至截稿前尚無看到我打球的照片. 這不得不又要幹醮了,現在人手一台相機,網路又一堆免費圖床,但賽後的照片數量跟那個還只有台北林克的時代差不多,不知道大家是不愛拍照,還是只是喜歡拍了存在自己的硬碟. 說真的,時間一去不復返,世事又無常,能有幾張自己以前打球的照片,以後能給自己的小孩看,這不是人生一大樂事嗎?

再次宣導: 多拍! 多分享!

賽後又很後臉皮的要幫大家拍合照,其實以前在人少的時候,這算是輕鬆又一定會做的例行公事. 不過自從人越來越多後,畢業越來越久之後,反而這股氣就有點散掉了. 不知,不喜歡那種打完球了喔? 沒事了喔? 那我先走的感覺! 大家聚在這個球場,不應該只是追求自己在場上的數據表現的,不是嗎?

附帶一提,我身上穿的是 OB 送給新郎的球衣, Size 是我做夢都沒想過的 2XL ,剛拿到的時候我想說這件我應該只有掛在牆上或放在身上的份吧! 上一次 OB 我有試套,根本是小孩子套爸爸衣服,小亮哥穿 Hip Pop 衣服的搞笑風格. 沒想到我這次穿,竟然剛剛好…剛剛好…剛剛好… (震驚)

晚上還是例行的 OB 餐,不過一堆 OB 不能來,除了失望之外也沒什麼力氣多道德勸說什麼,因為團體本來就是很微妙的東西,扣除掉每個人真的不能來的理由外,大家想要追求的東西也不盡相同,也還是只能說能來就是緣份,若扯到有沒有心對我們這種團康性質的活動就太沉重了,反正我一切隨緣就好…

場地是阿文海產店,場地很大相對的別的客人也不少,在酒醉的情況下還要擔心遇上不開心的事,實在是很吃力,有請 188 跟 Wade 多幫忙注意有沒有比較封閉的場地,那就不用擔心其他有的沒有的事情.

不知道是不是我們上面的學長太團結,反而覺得之後的 OB 就不太好跳出來管事, WF 說要學會放手,所以我這次沒等到所有的學弟走才走. 想想也的確如此,之後每一屆的隊長若都擔起自己的責任,那麼 OB 賽才會走得更長遠更久吧,這樣的風氣也比較健康. 不過我個人是認為,歷任隊長先從能把自己那屆找齊的這步做起,若連聯絡方式都沒有那實在過不去對吧. :D

很慘的事,在呂大師誘惑我 WF 的情況下,本人正在處理換系統無鏡可用的狀況. 50 在海產店還真的是退無可退的狀態,真的不知道我出發前是用什麼腦袋去決定這件事的. 還好有博偉學長的隨身機,要不然錯過這一群瘋子的爆笑場面那就實在不是用可惜能夠形容的.

 

上圖是我喝完迷濛的眼神,而 WF 正在對面買雞排,上班以後的 OB 餐好像沒有一次是吃飽的,原來住逢甲跟住旅館真的是對食慾有差. 那天我其實還蠻想逛逢甲夜市的,但不知道為什麼就一下子回校友會館吃鹹酥雞看電視了.

最後,這是我大二時只有65公斤的樣子,我常常引用這張照片,以前沒有也沒錢買數位相機,拍照也通常是風景笆樂照. 一捲底片36張照片,當時應該很少球隊會狂亂按打球的照片吧. 還有上面的半袖,好像移交給我弟了,我現在穿完全是一個撐爆它的狀態.

最後的最後,這篇文也許無心中會讓人看了覺得不爽(這我不知道),不過我沒有對誰誰誰不爽的意思,這只是一篇單純的心情感想文. 呼應前文,把想法說出來總是比什麼都不跟大家說,來的健康不是嗎! 更何況我對於這個家族只有滿滿的感謝而已. :-)

果然用以前寫 BBS 心情文的無腦寫法,寫出來的字比較多. XD