Team Work ...

當我們不同在一起, 是不是還能Team Work?

很多人問我, 為什麼會在這裡, 我那三大理由的第二點一定是最噁心芭樂的 -- "因為你們".

我喜歡和你們一起工作, 因為相處夠久, 都知道各自的優缺點, 也彼此信任(雖然我是那個最不可以被信任的人 ... >_< ... 都是我害了大家), 可以各自發揮所長又互補所短.
這種感覺真的很好, 真正的各司所職、堅守崗位、互相合作、有默契的Team Work(不是沒有分工的喔).

但現實總是殘酷, 面對組織不斷改變, 面對越來越無力的生存環境, 老戰友們一一先行告退 ...
來來去去本人之常情, 留下來的人也不少, 我們能否多吸收或取得些什麼呢?


用最後一份力(如果你還有), 為自己多吸收多取得 ...
用最後一份力(如果你真的還有), 和志同道合的戰友並肩作戰(要確定那是你志同道合的) ...


當有一天我們不同在一起的時候, 或許我們仍能維持Team Work的默契, 一起接案子或者討論事情.

當然啦 ... "林美如"得一定要約在一起的啦 ... ^_^


from 白目屋頭號要犯

20060525歡送Joe同樂會

唉, 認識的人裡面, 走的人比留下來的多 ... 唉

Joe這傢伙, 也是元老之一, 沒想到那麼低調的閃 ... 怎麼可以放過他呢, 依照慣例, 當然要用力給他慶祝.

這天, 我們相約忠孝商圈的"野火燒不盡"燒肉店, 拼命吃ㄚ ...

小的我當然義不容辭再度充當小小攝影師, 偷拍偷拍啦 (希望我走的時候, 也有人來拍我啦)



所有的照片在這裡喔 ...
http://www.flickr.com/photos/saunier/tags/20060525%E6%AD%A1%E9%80%81joe%E5%90%8C%E6%A8%82%E6%9C%83/

來喔來喔 ... 來"林美如"喔

話說這天為了慶祝.. ㄟ, 是歡送郁凱小妹妹轉換新職與提前慶祝新居落成, 我們三人特約金色三麥品酒.

輝哥果然是輝哥, 毫不客氣的點了一堆吃的和各1000cc的大麥與黑麥啤酒, Ho... 我覺得好像是在慶祝他20年後升官的樣子 ... ^_^

說真的, 5月真的是轉職潮, 尤其對我們這年紀的人來說, 要考慮的事情變的好多, 念頭變多了, 也相對變的不快樂了 ... 但這就是人生阿 ...

祝福郁凱 ... 鵬程萬里~~~
祝福輝哥 ... 不要等20年, 來個5年升官發財吧~~~

美麗的女主角側面


好可怕的酒鬼


一人乾掉1000cc ??? 好厲害阿

我的腮腺在"發言"

今天中午難得吃到雞排飯, 吃到一半, 右耳下方卻開始腫起來, 甚至連右邊臉頰都腫了.
雖然自己開玩笑說: "幸好我的臉很圓, 應該看不出來", 但心裡還是很在意到底是扁桃腺還是腮腺發炎.

Google真的是我的好朋友, 三兩下就得到最可信賴的消息, 加上有豐富醫學知識的毛爺(趁機狗腿一下)協助, 應該可確定是腮腺炎.

晚上趕快跑去看醫生, 醫生說 ... 是腮腺炎, 要我多注意, 可能是病毒或是腮腺堵塞引起的.
如果這兩天吃東西的時候會腫起來, 那就要轉診去照腮腺影像 ... 好口怕阿~~~ >_<

我可愛的腮腺阿 ... 我可愛的圓臉阿 ... 給我乖一點(>_<)

可愛的嘟嘴觀音和白目豬

這兩件樹脂黏土捏麵人都是宜蘭縣"薪傳"的作品.


嘟嘴觀音是Jay不知道哪一次回宜蘭時幫我買的, 很可愛, 本來想貢供奉在客廳酒櫃, 但因模樣有趣, 似乎不適合我媽每天對著做"早課"(唸經), 現在和我的一堆雜物一起"供奉"在我書桌上 ... 真是委屈了 >_<


白目豬的誕生則具有"指標性"與"深遠的意義" ... 話說前陣子我開始以豬的身分自居, 想要低調過日子, 卻被公司那位布萊恩(Brian)先生發現了我的真實身分, 還有我和高層密不可分的秘密關係 ...

既然如此, 我只好將家世給抖出來 -- 我家是開白目屋的, 所以當然只有我能夠白目不諱的想說什麼就說什麼, 在會議上亂槍打協特, 最後榮升白目屋聯盟首席代表, 旗下還跑來一個我根本不認識的白目廖 ...

布萊恩(Brian)先生為了恭賀我榮升, 特地獻上一隻白目豬, 因此有"白目屋裡養了一隻白目豬"的美言 ...


感謝大家 ... 感恩阿 !!!


(PS. 什麼跟什麼阿 ... 我又在胡言亂語了)

読み物小舖 -- Pratical JAVA - 實踐16 : 認識Exception Control Flow機制

Exception Control Flow, 這是SCJP必考的東西.

Exception是JAVA語言一個強大且實用的特性, 但也給JAVA增加了複雜性.
大多數的工程師只知道Exception要去catch, 但是接著要做什麼就不知道了.
其實要抓哪些Exception來做處理, 或者如何正確的使用Exception, 前題都是必須要充分了解Exception.

這一個topic, 主要是讓大家複習JAVA Exception的機制與運作原理.

Exception的行為類似goto述句(但JAVA內並沒有提供goto述句, 卻有把goto當作關鍵字並束之高閣).
一旦某個Exception發生, control flow立刻轉移到下面三者之一:
1. catch block
2. finally block
3. calling method(呼叫端)
這是Exceptino所表現的goto行為, 了解這個是很重要的, SCJP必考.

當程式在try區段內拋出異常, 會發生怎樣的事情呢?
1. 如果同時存在catch block與finally block, control flow將會先轉移到catch block, 再轉移到finally block.
2. 如果沒有catch block, control flow會轉移到finally block.

Exception內另一個很重要的觀念, 不能對Exception視而不見. 但這取決於看待問題的角度. 將於實踐17討論之.
但是如果對Exception導致的事情懵懵懂懂, 會導致程式行為錯誤, 而且難以擴展和維護.

在專案內, 我想, 除了定義哪些Exception要被處理之外, 另外也要制定LOG的機制, 這樣才不會老是發生那種catch之後什麼都不做, 結果debug到昏倒的情形.

読み物小舖 -- 中天綜合台 週日晚間 影響100 Google 李開復專訪(筆記)

WOW ... 今天是Google全球副總裁 李開復的專訪 ...

以下是我的筆記, 說真的, 一家公司會成功必然會有道理, 人也是一樣的.

1. Google的使命 : Google不以Search Engine為使命, 他們真正的使命是 "整合全球資訊, 變成使用者想要尋找資料時的門戶" , 因此和資訊整合有關的技術與方法, 都是他們要做的.

2. 他們內部不分 "想的人" 與 "做的人" . 創新的人往往就是真正做事的人, 因此可以3,5人成一個團隊, 然後在幾個月內把做出的東西放到Internet上讓廣大的用戶使用, 給予評價. 因為用戶的利益與聲音才是最直接與準確的. 若某樣技術或服務頗獲好評, 就可以包裝成產品.
員工可以花20%的時間做自己想做的事情, 或者參與別人的計畫, 但要秉持透明平等的觀念(每個計畫都是平等的), 不鼓勵互相競爭.
-->競爭會帶來進步, 但同樣也會帶來猜忌與小團體, 甚至導致更嚴重的負面傷害.

3. 員工對工作、公司有熱情, 自然就會小心呵護. 可能也是這樣的原因, 讓Google一直沒發生內部洩密的案例.

4. Google不做邪惡的事情(Don't be evil). 這是全公司信守的價值觀.
-->開宗明義, 簡明扼要.

5. 資訊因分享而有價值. 過去利用握有資訊或綁架資訊而獲利的人, 終將被淘汰.

6. Google不做Content.

7. Google要在台灣成立的 "台灣工程研究所", 與世界其他研究所一樣, 標榜新的創意、最好的人才、核心的技術等.
他們要有熱情、有想法、有執行力的員工, 而非只是空想.
在挑選人才的來源上, 主要分成: 學校、海外歸國人士、轉職. 因為學校的學生很有熱情, 程式的底子也不錯; 他們也希望給海外歸國人士多一些選擇的機會; 至於已有工作機會的轉職者, 比例上會少一些.


所以, 想要投履歷去Google的人 ... 可以考慮把履歷改的更漂亮喔 !!!

Effective Java Ch7.

Chapter 7. General Programming

主要討論JAVA語言的基本要素與具體細節.


條款29: 將區域變數的作用域(scope)最小化

說真的, 看到這翻譯出來的標題, 我的感覺是:"翻的真硬" ...

這標題內含的道理, 大家都知道, 就是"在變數第一次被使用的時候才宣告", 不過真的要說出優缺點是什麼, 好像卻又沒辦法說的那麼頭頭是道、大家點頭稱讚.

將區域變數作用域(scope)最小化的最有效技巧是在變數第一次被使用時才宣告它.
如果你在變數被使用之前就先宣告, 只會造成混亂, 造成程式碼閱讀者的分心. 而一旦真正到了變數要被使用的時候, 閱讀者已經不再記得變數的型別與初始值.
如果程式經過演化而變數不再被使用, 程式員也可能因為變數的宣告遠離其第一次被使用點而忘記刪掉它們.
如果一個變數意外的在"它被希望使用"的區段之前或之後被使用, 有可能導致災難發生.


其實現在的Tool越來越好用, 追查變數的來龍去脈已經很容易. 但畢竟程式碼是人寫的, 從人性的角度看來, 也的確是這樣.
更重要的是 ... 一個變數意外的在"它被希望使用"的區段之前或之後被使用, 有可能導致災難發生. 有哪個工程師沒有花時間在Debug這樣的問題? 一定很多經驗吧 ... ^_^



這篇文章很有趣的地方, 是以這個標題為主, 比較了for與while的差別.

如果迴圈變數的內容在迴圈結束之後不再有用, 那麼請儘量選用for而捨棄while迴圈.

Iterator i = c.iterator();
while (i.hasNext()) {
doSomething(i.next());
}

Iterator i2 = c.iterator();
while (i.hasNext()) { //BUG
doSomething(i2.next());
}

有"剪貼"錯誤.
如果使用for迴圈, 犯下類似"剪貼"錯誤的可能性比較小, 因為你不需要在兩個迴圈中使用不同的變數名稱.
兩個迴圈完全獨立, 因此重複使用迴圈變數名稱, 不會帶來傷害. 事實上, 這是很流行的寫法.
for迴圈的寫法比while迴圈少一行, 有利於整個函式被塞入編輯視窗中, 增強可讀性.


好啦, 我犯過這種剪貼錯誤啦, 因為有時候真的很懶 ... 但是作者說的是對的, 重複使用迴圈變數名稱, 不會帶來傷害.
不過那個什麼"for迴圈的寫法比while迴圈少一行", 我簡直笑翻了 ... 是是是, 作者您說的是.

最後說到一個很重要的觀念 : "將區域變數的作用域(scope)最小化"的最後一個手法是令函式小而集中, 這不就與一般OOAD的精神一致?


^_^