2009年2月13日 星期五

真是太閒了...

今天一時無聊上網看電影介紹,想說找個電影來看,習慣上,我會先看看網友討論的部分,發現一段對話如下(發話者認為網站上的影評有錯...),看了一下發言時間,也不像是刻意弄出來的:

http://bbs.atmovies.com.tw/bbs/bbs.cfm?action=view&c=102&s=59622 (原址)
我只能說,這世界上無聊(或幽默?)的人實在是不少...呵呵, 顯然很多人是太閒了~^^

BTW, 最近真是沒啥電影好看...唉...

Silverlight 的 Linux 版本釋出

昨天看到一個訊息,Silverlight的Linux版本釋出,盡點道義推一下,不過老實說,Linux我不常用,所以沒特別的感覺,如果要讓我稍為興奮一點的,我寧可看到的是手機版的Silverlight推出,不過看來還需要等一段時間,期待囉...

辛勤工作的獲利

我最近發現了一件我早該發現的事情,那就是,原來賺錢是一門專業,而不是一件自然而然就會發生的事情,這個論點和過去一些管理大師(A到A+那位)的看法大相逕庭,不過似乎挺符合台灣這邊的前幾年的現狀。

很久以前的有一陣子, 我脫離了園區工程師這個頭銜(我進入的很晚, 又脫離的很早, 所以既沒有攬到一個新貴的稱呼, 也沒分到什麼有價值的股票, 所幸前陣子的金融海嘯也沒掃到我), 當時我離開園區後(好幾年前了), 我整天研究技術處理專案,偶而寫寫書稿, 待在StarBucks, 伯朗等咖啡店, 同時也接一些課程和顧問工作, 那時候我才知道, 原來---原來---台北那麼多的人是不用上班工作的。

而且更令人詐舌的,是這些看起來沒啥工作的人(請注意,我肯定這些人不是學生、也不是業務員之類...),出手都比我大方得多....而且是很多很多,那時候我在內湖、天母看到一些穿著短褲拖鞋進入Starbucks的人,比起我看到西裝筆挺的人還要謹慎點,因為我後來發現...原來財主常常隱藏在令人不注意的外表下...(^_^)

說遠了, 回頭, 很多讀者以為寫技術書籍很賺錢, 或是從事資訊行業能夠如何如何,或是剛畢業的小朋友覺得到了科技業可以怎麼發展...但是根據我這十多個年頭的觀察,如果你的目標是想要賺錢,你的專業絕對不能只是(只有)資訊技術,你的專業應該要是『如何賺錢』...相信我,這是一門高深的學問,而資訊業中的許多人對這一門學科恐怕都是不及格的。

在我身邊從事軟體開發工作的,至今還沒有哪一個工程師(後來變成老闆的除外)讓我覺得他日子過得很優哉的(至今, 一個都沒有),無一不是加班熬夜酗咖啡,稍稍有一點點成就的,這種狀況就更加的明顯。

幾乎每一個我認識的講師、作者、專家、或是技術人員,都只能勉強算是中產階級,幾乎每個人都要為小孩子的學費和房貸傷腦筋,我沒有認識任何一個可以買豪宅的人(我猜這是我也買不起的原因),在這些人當中,當然也沒多少是對時尚、名牌、或是精品有研究的,自然也不太可能有炒股的空間,即使我想要個內線交易也從來不曾有人給我真正的明牌, 就算我真的知道了個明牌,最慘的是,我猜大多數人也沒那個本錢去炒...從某種角度來看,幾乎也可以說是典型的市井小民了...

對照台灣少部分可以不用工作,一直念書,還可以住在豪宅的幸運兒,和從來不需要考慮收入是不是不夠(可能只需要擔心太多沒地方放)的人來說,我們這些從園區出來的工程師哪是新貴,那些人才是真正的新貴,這幾年我才知道,原來,很多人可以動動嘴巴就進帳一兩億的,我拼完我這輩子大概也沒個零頭...

其實我也有不少帳戶,只是平時活動的那些帳戶的剩餘金額扣掉安全庫存量之後,大多都不會超過我每個月需要繳的支出,大概也因為這樣,所以我每個月匯款或是轉帳的唯一機會,是月初領到錢之後付給銀行、保險公司、或是繳帳單,有時候和朋友們聊起,大家都消遣自己說我們是典型的過路財神,是個幫銀行賺錢的...

不過,我覺得我們這一票,才是最愛台灣的人,我真的覺得我們這一票人比台灣當今檯面上的任何政治人物(不管紅橙黃綠藍)對台灣更有貢獻,我當然也沒有綠卡(也根本沒機會有綠卡),自然也沒有外國籍,我始終待在這裡,我在這裡出生,在這裡工作和生活,能偶而出國玩也算是奢侈的消遣了,大部分的時候我只能配合振興台灣經濟方案在國內多一點點消費。

我身邊很多很多這樣的工程師、技術人,但是這些人都有一個特色,我在這些人眼中都看到對專業的堅持和熱情,有時候是那種有點傻勁或是雖千萬人吾往矣的魄力(偶而一不小心也會變成方向錯誤的蠻幹),這些人都稱不上是有錢,但是都很努力的生活,和工作。

很多人和我一樣,一開始入這一行只是因為興趣,工作真的很累,但是每次下班之後走在台北街頭,初春的微風拂面挺舒服,我覺得我對得起我自己、對的起我的家人、對得起國家社會。我覺得我的工作對這個世界有一點點幫助,對客戶有一點點幫助,辛苦所得也讓我可以負擔的起照顧好我的家庭。

對我來說,有些時候這樣就已經很足夠了。多的,就當作上天的賞賜了...

有一回,我在捷運上,看到一個我很久沒看到的場景,擁擠的捷運上博愛座已經滿了,一個孕婦帶著小孩走了進來,同時間又一個行動不變的老人走入,趁著捷運還沒啟動的那一兩秒,很多乘客都『爭先恐後』的把一般的座位讓了出來(因為需求量大),有時候覺得,行善也是會傳染的..

我想講的是,有機會或有能力,請多幫助一些身邊需要幫助的人,其實台灣很多人都需要幫忙,只是不好意思開口,很多人其實也熱於幫忙,只是有時候沒那個氣氛,連行善也會不好意思...

2009年2月7日 星期六

從Silverlight開發架構看到的一些感慨

最近在撰寫Silverlight的文稿(書稿和雜誌稿)、範例、和一些課程教材的時候,看到Web開發技術的發展回頭對比台灣的開發環境實在有一些感慨。

先講第一個,話說從頭,有一陣子我介紹了ASP.NET上的MVC,MVC這個架構是個好的Pattern,可以幫助開發人員達成建構出有架構、便於更新維護、便於抽換的應用程式,問題是這是(只是)一個規範、一個樣式,所謂的規範就表示,你應該遵循藉以得到一些好處,但是有趣的是,規範這個東西在台灣不見得一定會被遵循,老實說我本來以為在全世界都是這樣,但是根據我的觀察,在台灣這個狀況比較明顯,反觀我在台灣以外的一些合作夥伴和團隊,對於 "規範" 這個事情的嚴謹度和遵守(你也可以說是死板),超過了我的想像和期待。

我舉幾個簡單的例子:
1.估時程:我常常看到,為了爭取到某一個案子,在時程評估的時候,就已經放棄架構了,我們給了客戶一個若要遵循架構就根本不可能達成的預計完成時間。
2.當進度落後:當進度落後的時候更慘,本來SA,SD花時間想好的架構,可以因為進度理由一夕之間失效,更有趣的是,這個架構可能是先前花了兩三個月決定的,但是Developer+PM可以在一天內推翻。
3.當客戶要求不合理:一樣的狀況, 有時候客戶會有一些超越常態或是超越技術可能性的要求,為了成案,往往PM答應的莫名其妙,而怪的是,最後還是可以做得出來,天知道這後面隱藏了哪些可怕的東西。

剛講到MVC和所謂的規範,可能很多人對我說的 "規範" 的定義不清楚,舉個ASP.NET開發人員應該要知道的例子,有幾個我所謂的規範簡單的具體例子就是:
1.ASP.NET頁面(.aspx和.aspx.cs 或.aspx.vb)當中,不得有ConnectionString or SQL指令。(你應該寫在一個表(不管是資料表或是對照表)當中,以便於後續維護。(但是,誰敢說自己的.vb或.cs中沒有SQL指令碼?我看是一堆吧...)
2.ASP.NET程式碼當中不該有商業邏輯,只能有處理UI的Code, 也就是說,你應該要有一個Business object。
3.超過100行的Method或Sub, Function 應該再切割。

類似像上面這樣的說習慣也好, 說規範也行,是不應該被打破的,但是,有多少因為時程關係而破壞規範的例子? 多的慘不忍睹。

在連續幾次課程中我被問到MVC之後,我的回答開始變成:如果你(或你的開發人員),無法嚴守上面這幾個規範,那就不應該去想ASP.NET MVC,因為這(MVC)不符合你的需求。

MVC是一個保持(證)系統架構清晰、具有延展性、可抽換性的開發架構,以降低維護成本提高重用性,但是如果你的Code是上面這樣的寫法,那完全不可能接受MVC的規範。

好,回來談Silverlight, 上課時,我很清楚的跟學員介紹了Silverlight RIA抓取後端資料庫的方式,大致上如下:
1.撰寫一個Business Object(包含Data Access Class)來抓取資料庫中的資訊,例如請假資料...(這邊應當是 AP層)
2.利用WCF或WebService撰寫一個Service,來調用剛才寫的Business Object,這是Service層。
3.在Silverlight應用程式當中,調用遠端的Web Service來存取並顯示資料。(這邊是展示層)

曾經有幾個學員問到說,怎麼會這麼麻煩呢?

我為什麼不能像以前寫Windows應用程式和Web應用程式時一樣,用一個SqlDataSource或是"直接"撈DB中的資料呢?

當我聽到這個問題之後大為震驚,這表示
1.原來以前大家都是在處理展示層的UI上,直接抓取後端資料?
2.原來過去大家很少撰寫Business Object或是Service,都是透過ADO.NET直搗狂龍式的取得DB中的內容?
(不過, 我欣賞學員願意問的求知慾, 只有這樣才能持續成長, 比起在心裡覺得怪怪的但總是沒問出問題的學員, 他們會進步得較快)

如果是這樣,那怎麼同樣的學員會問MVC的問題呢? 這沒道理啊, MVC的概念根本不是這樣啊? 原來,學員提到準備要導入MVC開發架構,但是他心裡其實對MVC還沒個底,並不知道改成MVC之後,比起他現在的開發方式額外要撰寫很多、很多很多的Class...

真的是 "變得" 比較麻煩嗎?還是其實是過去為了一時的便利, "省去了" 太多太多 本來其實應該要做的工作呢?

我的一個前輩告訴我,先前他對Design Pattren概念雖然很清楚,但是總是覺得彆扭,和台灣的架構師們討論起來也覺得沒那麼自然,似乎很難應用。

後來有一次,他參與國外的一個開發團隊,發現在這個團隊當中,有著來自世界各國的優秀成員,在當中討論系統architecture的時候,在會議中,每個人討論起開發架構,其中Design pattrene觀念似乎是理所當然的,像喝水一樣,很多的爭辯只會到某人提出應該要用某種Pattern來解決為止,不會有任何其他的疑問,架構和規範像聖經一樣牢不可破。

我並沒有說(我也沒資格說)怎樣一定比較好,坦白說我以前寫的一些範例也並不敢說全然依照上面的規範,只是回頭想想覺得有點感慨,當我們在討論RIA或是Silverlight的時候,好像一直講的都是你的程式可以怎樣炫、可以怎樣讓人感覺不同、有怎樣的使用者體驗...但是卻忽略了開發架構是一切的根本,為何我要建議學員考慮把一些ASP.NET的應用程式改以 Silverlight來開發,原因不是炫、是這樣的開發架構才較為合理。

Silverlight有清楚的展示層、服務層、AP層、DB層的觀念, 除了展示層之外的東西,都應該是與UI無關的,和過去ASP.NET開發人員習慣(但不應該)把所有東西綁成一坨混在一起是不一樣的。

我還是這麼說,應該把技術應用在適當的場合,技術本身有延續性,很多新技術的出現,都是因為要解決過去的一些問題,UI只是其中之一,除了UI之外,開發架構是一個開發Team的核心競爭力,否則我們的開發團隊很可能只能持續的從勞力苦工中獲取很低很低很低的毛利,很類似台灣的代工製造業現在面對的問題,開發團隊中沒有一些累積出可重用的元件其實是一件很可怕的事情...

從團隊到個人也是,過去的經驗的累積(包含知識、專案、成品、元件),會是開發人員與其他開發人員不同之處,我知道每一個開發人員現在其實都很累,面對專案、面對一些其他有的沒的,但是如果可以,還是建議大家,多花一點時間在架構上,對於開發人員來說,這應該是只有好處的。