2012年12月15日 星期六

2012 Java 認證日與會感


        其實除了我有利用 Java 開發過 Android 程式外,對於整個 Java 繁華萬千的世界,我可以說是個局外人。

        這次『2012 Java 認證日』從主題很明顯是個推廣 Oracle 版本的 Java 證照行銷活動,本來應該與我毫無關聯,但收到 eDM 的當下,不小心被我瞄到這場免費活動的議程其實有『置入性教學』。真是怪哉,別人都是藉教學之名做『置入性行銷』,Oracle 則是反其道而行。

2012年11月11日 星期日

AppWorks DEMO #5 會後感

        11 / 7 日這天跟公司請了假,和同事小郭一起親臨這場半年一次的創業大拜拜。這次總共有 23 組團隊上場展示,好像是我參加過最多團隊的一次。經過上次太晚到場連椅子都沒得坐、資料沒得拿的教訓,這一次我早早到場順利幫同事佔到前兩排的座位。

        觀賞過程中,小郭讓我體會他虛實整合的優越能力:他女朋友觀看線上網路直播,他在現場一邊透過手機用 LINE 跟女友討論交換意見,其中不乏出現許多讓人噴飯的苛薄言詞。

        以簡報表現來說,整體成績和上一次相比屬伯仲之間,不過以創業主題而言,比起上次更吸引我許多,至少沒有出現那種讓我久坐不耐的情形。跟上次較為不同的,這次大部分的團隊都有準備預錄好的 DEMO 影片在簡報中播放,而減少了 live demo 的比重。

        這其實是個聰明的方式減少現場現場不預期的意外,也可以先規避防錯的開發工作。不過也因此會讓人懷疑他們的產品是否真如他們宣稱與影片上所示那麼流暢?畢竟某組的影片剪接的斧鑿痕跡過深,看得出很多程式載入和操作反應的畫面被剪掉。

2012年10月7日 星期日

UML 教學分享


        前陣子我開始在公司內嘗試導入 UML 做為內部所有設計文件的溝通標準。過去,敝公司的前任架構師有他習慣的系統架構表達方式,定義了許多幾何形狀與色碼標準。

        雖然其細緻程度也能相當詳盡地表達系統的異動,但總不是個業界標準的方式。

        一直以來,我的理念就是讓工程師(包括我自己在一家公司所學到的技能與知識,是到了下一個環境也能夠再運用的,而不是學到的知識僅僅只能適用於當下的工作環境,一旦轉換了工作環境就全部變成廢物,這樣不但無法真正累積實力,而且真的非常浪費寶貴的生命。

        終於有機會讓這局面有了轉機,我開始重新導入設計文件的標準,開始要求工作同仁放下過去學到的一切,全部重新改以業界標準 UML 來表達一切的設計。

2012年8月27日 星期一

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

        當一個系統成長的越來大時,不是只求功能可以用、程式可以動而已,還要考慮到『可維護性』、『可變動性』以應付隨機改變的商業競爭環境。然而系統越大,往往包袱越多、越難以變動、不可預期的風險越大,這就是目前公司最頭大的問題。

        最近我們單位在公司內肩負起提升程式開發人員做『設計』的素質,希望大家真的能從『程序員』變身為名副其實的『程式設計師』。然而想要從開幾場 seminar 就改善這件事未免太異想天開,談如何做設計這件事情,本身有太多經驗的累積和眉角,決不是照著固定章程 SOP 就可以達到,甚至有同事譏為「不傳之秘」

        就如同我過去的文章曾經表述,設計不分好壞,只有合適和不合適兩種,合適的設計就是能『因地制宜』的設計,所以做任何設計之前,認清楚當下所處的環境才是最重要的根本!

2012年6月13日 星期三

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

        由於我在公司所處的團隊的工作內容,有部分是在 review 公司內其他團隊的 HLD ( High-Level Design - 高階設計 ) ,並給予本身專業上的建議,最近我發現,這樣的職掌讓我面臨了許多矛盾與衝突。

        原因是:每個設計其實都有他本身的道理。

        除非找來的工程師是個沒經驗的初學者,犯了很多沒 sense 的錯誤,不然稍有年資的工程師所做的設計多半有他站得住腳的考量。那個考量很可能是「成本與風險」,也可能是「架構和彈性」,也可以是「效能和穩固」,更可以是「商業價值和使用者經驗」。以上任何一個顧慮你都不能說他錯,但是大家抓住的利基點都不同,互不退讓之下,事情往往難以敲板定案。

2012年4月6日 星期五

AppWork DEMO #4 會後感

        昨天剛好是我請休的日子,衝著 AppWork 這麼衝著我面子,安排在我休假期間舉辦這個 DEMO 活動,毫不猶豫地把休假的空閒時光奉獻給會場(真是往臉上貼金,就只是狗屎運好罷了)。

        第一次尋找台大醫院的國際會議室,足足讓我吃了十五分鐘的苦頭,在醫院裡面迷路了好陣子,不過一切都是值得的。



        半年前的 DEMO #3 我是透過網路看實況錄影版本的,由於可以不斷反覆倒帶觀看,所以可以比較詳細地寫下對每個團隊的想法,今年去現場,又沒拿到現場發送的團隊介紹手冊,也沒做筆記,只能從簡單地概觀印象說說這次參與後的感想。

2012年3月6日 星期二

資訊透明其實是門好生意

        前一陣子,同事感嘆這個世界越來越平,失去了「資訊不對等」的優勢,在現今資訊發達的社會上,越來越難獲利。我聽了不置可否,卻想起前陣子在健身房聽到在我旁邊那台跑步機上,一位不知名的女士在講的電話內容。

        那位女士好像是汽車拿去送修,原本她認為應該只是個小毛病,結果車廠打電話回她,說她這個壞那個也壞,東扯西扯最後報了個價:五萬塊。嚇得那女士花容失色。

        顯然這個金額太過嚇人,那位女士開始推說身上現金不夠,想先領車,改天再修。可想而知,修車廠那可能輕易放棄入口的肥羊?接下來,雙方冗長的攻防戰展開,車廠看來要求女士回家拿錢,女士推說家住得太遠...,又提款卡在老公身上等說詞,車廠又「體貼地」為了這位尊貴的客戶延長營業時間,願意等你捧著現金來等到天長地久...。修車搞得像是綁架一樣。

        電話掛上後,女士在跑步機上自言自語:「怎麼會這麼貴?怎麼可能這麼貴?

2012年2月1日 星期三

設計的通則?


        自從上一篇『為失敗所作的設計』貼出後,我收到一些同事的 feedback,首先要先對覺得被影射到的同事致歉並且解釋清楚:

  1. 關於留後路這件事,事實上只是當時提出的眾多考量「其中之一」而已他當時也有從「可延展性」以及其他諸多方面去思考而給出那樣的意見
  2. 另外「只把資料庫單純當作資料倉儲」這樣的想法則是來自另一位不同的同事,並非出自同一人。
  3. 為了讓文章聚焦,避免模糊焦點,我將來自不同人物的意見合併在一個代表人物上,並且因為當時對於「預留退路」這件事情特別有感觸,所以在撰文時將其他無關該主題的意見通通割捨掉,實際上是「斷章取義、以偏概全,與事實不符」。
        簡而言之,這個網誌是為了記錄針對 IT 領域,個人對一些議題當下所激發的想法並非為了留為呈堂證供,留作法庭審判用途,所以對引論中心思想無關的情境事實和前因後果,會過於簡略帶過或變造,以便撰文時可以流暢表達最重要的想法。

        前天跟同事喝咖啡,針對我上一篇文章,又聊到有關『設計與開發的通則』這個話題(真的很感謝有這麼優秀的同事們,不斷激發我回顧和重新審視一些觀念和想法,讓我一直在不斷的碰撞中找到成長的方向)。我們的工作之一,除了上一篇提到的內容外,還有提出「Development Guideline」。

2012年1月27日 星期五

為失敗所作的設計?

        由於目前在任職的公司內,我所屬的單位算是掌管公司技術方向的單位,有部分的工作內容就像是技術總監那樣(Tech Director),必須對公司內的專案所採用的技術提供審閱和建議,也需要指導設計方向與使用的開發樣式。

        我們這個單位的目的,說起來就是要根據本身的豐富經驗來『洞悉未來、未雨稠繆』,避免工作團隊因為想法太過直接,而不小心掉入『犧牲執行效能,設計欠缺彈性』的錯誤。簡而言之,這樣的角色似乎需要想太多,然而這件事本來就有許多困難與矛盾在,甚至很多時候,我們這個單位內都無法達成共識。

        最近就有這麼一個案例,我和另一個同事合作評估一個新專案的開發策略,這個專案原本所使用的資料庫產品是價格昂貴的商業用資料庫,我主張盡可能善用該產品所提供的所有功能來達成這個專案所需,然而另一位同事的想法卻與我迥異。

Google+ Badge