發表文章

目前顯示的是 2012的文章

2012 Java 認證日與會感

圖片
        其實除了我有利用 Java 開發過 Android 程式外,對於整個 Java 繁華萬千的世界,我可以說是個局外人。         這次『2012 Java 認證日』從主題很明顯是個推廣 Oracle 版本的 Java 證照行銷活動,本來應該與我毫無關聯,但收到 eDM 的當下,不小心被我瞄到這場免費活動的議程其實有『置入性教學』。真是怪哉,別人都是藉教學之名做『置入性行銷』,Oracle 則是反其道而行。

失敗專案的得與失

圖片
        前幾個月和同事在業外接下一個稍具規模的專案。承接這專案其實背負著相當高的風險,其一為此案所需要的各項專業技能我們是 完全付之闕如 ,能夠在什麼都不會的情況下接觸到這案件,完全是同事的人脈引薦所致。其二為對眼前這個合作夥伴的不熟悉,以及一些不信任因素。         當初會考慮冒此風險,原因之一是此案的極高的報酬,再來是因為上過 激勵課程 ,內心感覺要跳脫筐做冒險: 若要如何,全憑自己 。所以在工作規劃分配後,對於必須惡補的技術項目覺得有賭一賭的信心。         如果是之前的我,只敢做有把握、會做的事,當看到實力和目標有如此懸殊的差距,一定會直接拒絕。         當然,最終沒有成功完成此專案,但其實我一點都沒有難過的感受。因為這個挑戰的本來就是『 失敗是應該,成功才奇怪 』的任務,然而我從這個挑戰的過程看到自己的延展性和真正的弱點。若我承接的是個十拿九穩的案子,面對的可能就是『 成功是應該,失敗卻難過到想不開 』,而且什麼都沒學習與成長的結局。         所以接下案子後,我們當務之急就是如何將技術落差產生的風險降到最低,並且爭取最多的工作時間作為克服技術障礙的緩衝之用。         這次團隊組合的專精是在 Adobe Flash / .NET ( ASP.NET ) / MS-SQL,但客戶要的是 HTML + AJAX ( No Flash ) / Java ( JSP ) / PostgreSQL 。在最初幾次與客戶的會議討論,總算把其中一項置換為同事所宣稱熟悉的 PHP 。客戶的網站除了少部分的特色項目,大多是一般網站都該有的常見功能,而 PHP 是出了名的有很多免費既存套件可以快速架站,因此我研究幾套自由免費的 CMS ( 內容管理系統 ) ,挑選了 Joomla 做為整個專案的開發基底。         由於 Joomla 只支援 MySQL 和客戶需求不同,經過幾次強力說...

AppWorks DEMO #5 會後感

圖片
        11 / 7 日這天跟公司請了假,和同事小郭一起親臨這場半年一次的創業大拜拜。這次總共有 23 組團隊上場展示 ,好像是我參加過最多團隊的一次。經過上次太晚到場連椅子都沒得坐、資料沒得拿的教訓,這一次我早早到場順利幫同事佔到前兩排的座位。         觀賞過程中,小郭讓我體會他虛實整合的優越能力:他女朋友觀看線上網路直播,他在現場一邊透過手機用 LINE 跟女友討論交換意見,其中不乏出現許多讓人噴飯的苛薄言詞。         以簡報表現來說,整體成績和上一次相比屬伯仲之間,不過以創業主題而言,比起上次更吸引我許多,至少沒有出現那種讓我久坐不耐的情形。跟上次較為不同的,這次大部分的團隊都有準備預錄好的 DEMO 影片在簡報中播放,而減少了 live demo 的比重。         這其實是個聰明的方式減少現場現場不預期的意外,也可以先規避防錯的開發工作。不過也因此會讓人懷疑他們的產品是否真如他們宣稱與影片上所示那麼流暢?畢竟某組的影片剪接的斧鑿痕跡過深,看得出很多程式載入和操作反應的畫面被剪掉。

UML 教學分享

圖片
        前陣子我開始在公司內嘗試導入 UML 做為內部所有設計文件的溝通標準。過去,敝公司的前任架構師有他習慣的系統架構表達方式,定義了許多幾何形狀與色碼標準。         雖然其細緻程度也能相當詳盡地表達系統的異動,但總不是個業界標準的方式。         一直以來,我的理念就是讓工程師( 包括我自己 ) 在一家公司所學到的技能與知識,是到了下一個環境也能夠再運用的 ,而不是學到的知識僅僅只能適用於當下的工作環境,一旦轉換了工作環境就全部變成廢物,這樣不但無法真正累積實力,而且真的非常浪費寶貴的生命。         終於有機會讓這局面有了轉機,我開始重新導入設計文件的標準,開始要求工作同仁放下過去學到的一切,全部重新改以業界標準 UML 來表達一切的設計。

【預先構築】開課經驗與心得

圖片
        當一個系統成長的越來大時,不是只求功能可以用、程式可以動而已,還要考慮到『可維護性』、『可變動性』以應付隨機改變的商業競爭環境。 然而系統越大,往往包袱越多、越難以變動、不可預期的風險越大 ,這就是目前公司最頭大的問題。         最近我們單位在公司內肩負起提升程式開發人員做『設計』的素質,希望大家真的能從『程序員』變身為名副其實的『程式設計師』。然而想要從開幾場 seminar 就改善這件事未免太異想天開,談 如何做設計這件事情,本身有太多經驗的累積和眉角,決不是照著固定章程 SOP 就可以達到,甚至有同事譏為「不傳之秘」 。         就如同我過去的文章曾經表述,設計不分好壞,只有合適和不合適兩種,合適的設計就是能『因地制宜』的設計, 所以做任何設計之前,認清楚當下所處的環境才是最重要的根本!

哪裡有「好公司、好工作」?

圖片
        相信大部分的人對於目前的工作、公司的文化,內心有很多的不滿與抱怨,我也是。         去年年底,我曾經因為對職位工作內容的失望,對人事糾葛內耗的無力,而跟公司請辭。被慰留時,我還 寫了一封信 給慰留我的高層主管。         當時認為自己在工作崗位上已經『 學不到我想學的東西 』、『 推動不了我想貢獻的改變 』,專業沒有成長,工作因為公司的氣氛而沒有成就感。那時的我,實在找不出自己想在公司內做什麼,只有 面對一堆『不想做』的事情 。         我很感激公司高層願意幫忙排除掉那些『不想做的項目』,但在當時那個階段,仍未找到『想去做的項目』。過去我一直認為當工作內找不到讓自己有企圖心的項目,就是該轉換環境尋求其他發展的時刻,所以在食之無味、棄之可惜的情況下,一邊騎驢找馬,探訪其它出路。         然而就在今年初一場課程的突破,我發現到: 一切與我有關 。         我們不妨回頭再想想,為何大部分的人都在抱怨自己的工作和公司呢?至少就我周圍接觸的人統計來,這個比例應該接近百分百( SHIT,這是吸引力法則嗎? )。         我們可以推導出原因的真相,可能是因為: 世界上沒有百分百合意的工作: 也許我所嚮往的其他公司,裡面其實也有一堆抱怨不滿的員工伺機逃出,所以才會走到哪都遇到對工作不滿的人。 會抱怨不滿的人到哪裡都還是會繼續抱怨與不滿: 牛牽到北京還是牛,心態不正確的人到哪裡都是不對的。         根據第一點,既然世界上沒有百分百合意的工作,那換工作根本無法解決問題,只是從一個火坑跳到另一個火坑。 地獄反正有十八層,大家可以輪流玩看看,反正人生就是一票到底,不玩白不玩 ,但不論怎麼玩,終究無法解決問題。         根據第二點,問題出在自己,卻妄想用外在環境來改變現況,根本是緣木求魚, 換工...

關於「我沒有時間」這檔子事…

圖片
        「 沒有時間 」在我看來, 是人生陷入絕境的一種警訊 。因為在我們有限的生命裡, 能夠創造無限可能的唯一籌碼,就是「 時間 」 !         學習、成長進化、思考方向、執行與創造新的機會,這些都需要我們投入時間。 一旦當你開始說「我沒有時間」,這就是某個惡性循環的開端,而且很難翻身 。         我曾經在「 兒童關懷協會 」的義工活動說,在我看來,世界上最可怕、最絕望的行業,就是「 計程車司機 」。因為他們 不是領定薪 ,而是「做多少、拿多少」,想賺錢就沒有懶可偷。而 這個工作最可怕的地方在於:即使沒生意可做,時間也不是他們的,因為他們還是得不斷地花時間開著空車像是孤魂野鬼在路上繞圈圈,尋找乘客。         有客人載時,他的時間只能專心開車,沒有客人時,他還是只能專心開車( 除非他決定今天生意不做了 )。幾乎沒有別的行業吃時間吃的這麼兇狠的。         不信的話,大家搭計程車可以跟司機聊聊他開了幾年車?我得到的答案幾乎都是八年十年以上的, 一旦陷入這個行業,幾乎就是做到退休! 這個行業竟然遠比其他行業穩定,決不是因為這是某個幸福產業,而是他們全部都陷入無法跳脫的惡性循環 (註) 。         最近,我周圍的朋友一個個跟我反應: 工作忙到昏天暗地,工作時間從早到晚,沒有喘息 。 朋友A: 是某公司行銷企劃,因為工作繁忙又是責任制,幾乎天天早九晚十一,一天工作常常超過 14、15小時,有時連周休一日都休不到,沒空顧女朋友,天天吵架。 朋友B: 在某大建設集團工作,公司內鬥嚴重,只要休假或是沒有配合加班,立刻成為被攻擊放箭的目標。搞得他就算事情做完,還是得跟大家一起加班,以防患同事放箭。 朋友C: 某公務機關業務承辦人員,早八晚八,回家還得應付家庭需求,苦惱沒有自己的時間。         在我的觀念: 時間比財富還重要 ( 一寸光陰一寸金,寸金難買寸光陰 )。     ...

世上沒有完美的設計,只有合適的設計

圖片
        由於我在公司所處的團隊的工作內容,有部分是在 review 公司內其他團隊的 HLD ( High-Level Design - 高階設計 ) ,並給予本身專業上的建議,最近我發現,這樣的職掌讓我面臨了許多矛盾與衝突。         原因是: 每個設計其實都有他本身的道理。         除非找來的工程師是個沒經驗的初學者,犯了很多沒 sense 的錯誤,不然稍有年資的工程師所做的設計多半有他站得住腳的考量。那個考量很可能是「 成本與風險 」,也可能是「 架構和彈性 」,也可以是「 效能和穩固 」,更可以是「 商業價值和使用者經驗 」。以上任何一個顧慮你都不能說他錯,但是大家抓住的利基點都不同,互不退讓之下,事情往往難以敲板定案。

AppWork DEMO #4 會後感

圖片
        昨天剛好是我請休的日子,衝著 AppWork 這麼衝著我面子,安排在我休假期間舉辦這個 DEMO 活動,毫不猶豫地把休假的空閒時光奉獻給會場( 真是往臉上貼金,就只是狗屎運好罷了 )。         第一次尋找台大醫院的國際會議室,足足讓我吃了十五分鐘的苦頭,在醫院裡面迷路了好陣子,不過一切都是值得的。         半年前的 DEMO #3 我是透過網路看實況錄影版本 的,由於可以不斷反覆倒帶觀看,所以可以比較 詳細地寫下對每個團隊的想法 ,今年去現場,又沒拿到現場發送的團隊介紹手冊,也沒做筆記,只能從簡單地概觀印象說說這次參與後的感想。

資訊透明其實是門好生意

圖片
        前一陣子,同事感嘆這個世界越來越平,失去了「 資訊不對等 」的優勢,在現今資訊發達的社會上,越來越難獲利。我聽了不置可否,卻想起前陣子在健身房聽到在我旁邊那台跑步機上,一位不知名的女士在講的電話內容。         那位女士好像是汽車拿去送修,原本她認為應該只是個小毛病,結果車廠打電話回她,說她這個壞那個也壞,東扯西扯最後報了個價: 五萬塊 。嚇得那女士花容失色。         顯然這個金額太過嚇人,那位女士開始推說身上現金不夠,想先領車,改天再修。可想而知, 修車廠那可能輕易放棄入口的肥羊? 接下來,雙方冗長的攻防戰展開,車廠看來要求女士回家拿錢,女士推說家住得太遠...,又提款卡在老公身上等說詞,車廠又「體貼地」為了這位尊貴的客戶延長營業時間,願意等你捧著現金來等到天長地久...。修車搞得像是綁架一樣。         電話掛上後,女士在跑步機上自言自語:「 怎麼會這麼貴?怎麼可能這麼貴? 」

設計的通則?

圖片
        自從上一篇『 為失敗所作的設計 』貼出後,我收到一些同事的 feedback,首先要先對覺得被影射到的同事致歉並且解釋清楚: 關於 留後路 這件事,事實上 只是當時提出的眾多考量「其中之一」而已 , 他當時也有從「可延展性」以及其他諸多方面去思考而給出那樣的意見 。 另外「 只把資料庫單純當作資料倉儲 」這樣的想法則是 來自另一位不同的同事 ,並非出自同一人。 為了 讓文章聚焦,避免模糊焦點 ,我將 來自不同人物的意見合併在一個代表人物上 ,並且因為 當時對於「預留退路」這件事情特別有感觸 ,所以在撰文時將其他無關該主題的意見 通通割捨掉 ,實際上是「 斷章取義、以偏概全,與事實不符 」。         簡而言之, 這個網誌是為了記錄針對 IT 領域,個人對一些議題當下所激發的想法 , 並非為了留為呈堂證供,留作法庭審判用途 ,所以對引論中心思想無關的情境事實和前因後果,會 過於簡略帶過或變造 ,以便撰文時可以流暢表達最重要的想法。         前天跟同事喝咖啡,針對我上一篇文章,又聊到有關『 設計與開發的通則 』這個話題( 真的很感謝有這麼優秀的同事們,不斷激發我回顧和重新審視一些觀念和想法,讓我一直在不斷的碰撞中找到成長的方向 )。我們的工作之一,除了上一篇提到的內容外,還有提出「Development Guideline」。

為失敗所作的設計?

圖片
        由於目前在任職的公司內,我所屬的單位算是掌管公司技術方向的單位,有部分的工作內容就像是 技術總監 那樣( Tech Director ),必須對公司內的專案所採用的技術提供審閱和建議,也需要指導設計方向與使用的開發樣式。         我們這個單位的目的,說起來就是要根據本身的豐富經驗來『 洞悉未來、未雨稠繆 』,避免工作團隊因為想法太過直接,而不小心掉入『 犧牲執行效能,設計欠缺彈性 』的錯誤。簡而言之, 這樣的 角色似乎需要 想太多 ,然而這件事本來就有許多困難與矛盾在,甚至很多時候,我們這個單位內都無法達成共識。         最近就有這麼一個案例,我和另一個同事合作評估一個新專案的開發策略,這個專案原本所使用的資料庫產品是價格昂貴的 商業 用資料庫 ,我主張盡可能善用該產品所提供的所有功能來達成這個專案所需,然而另一位同事的想法卻與我迥異。