| Russel 的个人资料-= 訓練登陸火星 =-照片日志列表 |  工具  帮助 |
|
2月4日 [R.I.P]聖嚴法師辭世... 到現在我還沒辦法接受，一個讓人溫暖的長者就這麼離開了。 他是聖嚴法師，法鼓山的創辦人。 我跟他其實沒有什麼接觸，要說有，我很喜歡他那溫暖的笑容和充滿智者風範的言論，一個八十歲的高僧，從來沒有被人稱做「上人」或「無上師」之類的虛名，反而是很積極的，正向的，帶給台灣這充滿衝突的小島一點點溫暖。法鼓山沒有金碧輝煌的建築物，更沒有自己的電視台，他們默默的將佛教帶入人們的生活裡。 甚至關心宅宅族的生活。  即使是重病纏身，他仍然保持一貫的慈悲，他堅持不換腎，辭世後，聖嚴法師立下的遺囑中表示，辭世之後不發訃聞、不傳供、不築墓、不立塔、不立碑、不豎像，不揀舍利子，並以火化植葬方式，實現生前推廣的禮儀環保...
總是有人把他跟某個後山之王搞混了，但我並不在意，他的辭世是台灣最大的損失，我想從此以後，台灣再也沒有令人景仰的佛教人物了。 再見，聖嚴法師。 1月5日 [CSI] Dear Mac... 雖然早就知道Peyton就要離開CSI:NY的熟女團隊，但是看到Mac在讀那封Dear John Letter的時候，還是有種不捨的感覺...
我很喜歡她的英國腔，據說紐約迷並不喜歡這套。不過至少他不是掛掉（算編劇有良心，讓Mac不會在喪偶之後又要再承受一次這種痛苦，編到最後變成賭神也不太好看）。
4x04的片尾，Mac蹺班到他兼職的小店去當Bass手，主唱的歌超好聽：
看Mac和Stella那閃亮亮的眼神...暫且稱呼那個眼神叫做「夥伴」的眼神吧！
Mac加油吧！聽說第五季編劇會「補償」你的（大雷），明天還是要繼續伸張正義喔！
（謎之音：吵架也要記得女朋友的名字嘿！）
另外，為什麼宅男亞當可以賺到那麼正的女朋友？
12月8日 [DP]給自己找麻煩的實錄 軟體開發到一定程度之後，就會發現原本的寫法總有些很怪的瑕疵，之所以稱為「瑕疵」，原因不外乎「程式可以跑，但是可讀性很差」，最後程式就會黏著在很奇怪的地方，最後的結果就是程式更動變得困難不易維護，臭蟲發生的機率也大大的提高。 最近在寫一支程式，其實是從別人那裡接手的...看得出來這個程式開發得很快，不過也拜他所賜，也讓我玩了一些東西。 第一個階段的程式大概是這樣的感覺： 大概描述一下好了：這兩個物件，另外再去呼叫了Web Service來取得資料，因此基本上這兩個物件裡的兩個Operation做的事情是一樣的，但是分佈在不同的物件裡。試想一種情況：如果這兩個Operation回傳的值不同了，或者名稱改變了，參數調整了，甚至消失了，那維護人員第一件事就是打開整個專案，並且搜尋整個專案，把原本的Method改成新的名稱、參數，甚至重新處理。 這不是個很建康的方法，其實整個方法描述下來有很多地方可以改善。因此當我接手這個系統的維護時，我第一件事情，就是檢討這個Model是不是有值得修改的地方。 因此我改了另一個方式來處理，這個方式，會用到幾個不錯的觀念： 我把所有的WebService Method用另一個物件包了起來，並且叫做Web Service Adapter，所有的物件如果要去呼叫Web Service，一律透過這個Adapter去呼叫。 這個方法的優點是，把分散的各地的Web Service Method收歛在自己可以控制的範圍內（就是那個Adapter物件），但仍有一個問題：Adapter物件也可能會產生變數調整、物件改名等問題。 這個問題很難解決，但先聖先賢們發展一個理論，叫OCP（Open-Close Principle），大概的基礎就是保持物件內的彈性，並且不會因為修改Method產生困擾。保持彈性的方法有很多，基本上大原則就是不要修改方法，而以多型或者覆載的方式來處理，如此一來就能保持物件之間的彈性，維護時也只要針對物件去維護，乾淨又整齊。 把物件抽出來之後，更好的優點就是：如果Web Service回傳的值是需要另外處理的，也可以在Adapter物件裡統一處理，這個優點真是令我感動，這樣一來，去使用這些Method的物件可以更專注在自身所需要的資料，而不用再另外去分心這些資料是不是物件所需的資料。 再來就是程式內部的處理了，在第二階段的處理上，我加上了一個偷吃步的方法：Try-Catch。這個方法讓我碰了一個釘子，因為Try-Catch雖然可以讓程式更乾淨，因為我只要是錯誤的訊息，可以一律拋出一個Exception，那呼叫的物件只要用Catch包上之後，就可以統一來處理不正確的訊息，但是產生了兩個問題： 一、Try-Catch會降低整體的效能，我看過一個很傳神的說法，Try-Catch就彷彿是奔馳的高鐵上那支緊急暫停拉把，加上去之後就像是拉下緊急暫停拉把... 二、有可能會低估了原本丟出來的Exception的緊要程度，當然啦！如果是針對每一個Exception來做處理，那又另當別論了。 （很可惜我沒有留下這個階段的程式，其實我很愛這個階段的程式碼，乾淨到只要專注正常的流程，只是效能的關係不得不放棄，這讓我惆悵了好一陣子。） 第三階段的修改，就是把Try-Catch全部拿掉，雖然說回到第一階段，但是在Adapter物件上，我補上implement IDisposable。 這個動件使得我每次去呼叫Web Service可以有一個統一去Dispose Object & Reference的地方，這個東西在增進效能上無關痛癢，但是在資源的使用上幫助就很大。以.Net Framework來說，去Dispose Web Service算是幫大家一個大忙（請原諒有點無能的http.sys以及IIS） 當程式寫完交出去，我大概花了將近一個月的時間，感覺是很長久，實際上後半段（約三個星期）都是進行這部份的調效。會有這種想法其實跟大學時留下的習慣有關：我習慣把程式寫得很短，用各種方式來處理程式，並比較其中的優缺點，唸研究所之後，買了一本「聖經」，叫「物件導向設計模式」，這本書根本就是把我打得暈頭轉向的一本書，但是隨著工作經驗的不斷累積，書裡的程式竟然慢慢的開始對我微笑... 所以我把書放在公司裡，免得嚇到我了... 12月4日 [故事]我聽來的故事 - 3 這波「棄工潮」不少人有意無意的被刷了下來，有人是無端被刷到，有人是公司惡整，當然也有一些所謂「共體 我一個朋友跟我說了一個故事： 他小時候被丟到鳳山一間叫「正中」的學校唸書，那間學校不少名人都去唸過，但更多的是出來之後變名人的案例，當他唸了兩個月之後，發生了很多不愉快的事情，於是他就決定要離開這間學校，過一些比較像他想過的生活。 他要休學的時候，他的長官跟他說「勸你還是別吧！有很多人從我們這個退學之後，下場都很糟...」他的長官馬上列了十幾個很不好的例子，而且大多都是他聽說過的例子... 其實，如果是我，就會想「媽的這間學校就光收這種傲骨學生....-_-」 他退學的決定下了之後，他也沒多想什麼，結束鳳山短暫的生活返回台北。 十年後，同樣的事情再度發生，他的工作不順利，明顯產生瓶頸，於是他寄了信給總經理，告訴他離職的原因以及預定的時間。 總經理花了大把大把的時間，證明離開現在的工作並沒有比較好，當時他因為這個工作還去看了身心科的醫生，總經理竟用心踩在這隻痛腳上，直言如果有這方面的問題，其他公司「未必願意收留」。 於是他很快的就離開現在的公司，並且在景氣還不能成為藉口前，找到了更好的發展空間，他不用再看身心科，不用刻意控制脾氣，不用在意客戶的臉色，更重要的是，他打開了另一扇窗，讓更多的光線照亮他的前程。 我老闆說：「如果這件事是值得做的，就要勇敢去做」，我老闆是這句話的實踐家，而我朋友是這句話的證明。希望大家一切都安好，在這波浪潮中逆勢成長。 PS:最近工作有點忙，也沒什麼心情貼新的文章，未來會有一系列關於平台發展的文章，以及Design Pattern的研究心得，敬請期待啦～ 11月13日 不大不小的事 - 8 這個單元已經變成半年報了...主要也是因為最近沒什麼空寫新的東西，但是有些不記錄不行的東西... 一、王永慶：  這大概是我今年聽到最讓我震驚的一件事情了。 我不認識王董，但是和台塑集團有一點淵源：在我唸高中的時候，我們全家幾乎是靠台塑集團在照顧，台塑集團對員工的照顧只能用無微不至來形容：我們家四處有台塑集團的保健、保養、書刊產品，甚至買Matiz都能打折。 雖然他最後在油品這個東西上面讓自己有點下不了台（大煉油場，以及看不到的七折油價），但是我還是很感念他的幫忙。 開放民眾悼念時，我和熊特地去林口向他致意... 聽說有人哭著進去，相信我，這一定是真情流露。 二、11/7 又到了一年一度的11/7了。 還沒當兵前，不懂當兵究竟有什麼了不起的，但是這件事情真的可以影響人很久很久。對我來說更是格外的特別：可以說讓我體驗的所謂「如果再一次會不會有所不同」這句話。 老實說，再一次，真的會不一樣，但是，如果可以，最好一次就做到好。 剛梯Ａ同協們，希望你們一切都好。 三、H! 何瑞修回來了。  好吧！我承認，上面不是何瑞修。AXN播完CSI:NY之後，接下來繼續播流氓CSI系列，老實說，看邁阿密系列只有一種「紐約實驗室是講道理的」的感覺，好啦～H真的很性格，但是要別的流氓來照顧你的小孩...這.... 四、強者我同學： 篩啊要辦個人展了，這件事滿讓我羨慕的，主要是因為一個人的研究成果能夠真正展示出來，這件事在我的工作領域裡面並不多見：至少我知道，沒有幾個人是真的會去鑑賞程式設計師寫的程式.... 在同學的婚禮上遇到了篩啊，他拿著相機在五桌的同學桌裡拍來拍去的，當然也免不了互相聊上幾句。問起她現在「會不會怕我」這個話題，其實我還覺得有點挖苦我的感覺。但是他的回答讓我覺得挺有趣的：「現在你比較有笑容」。 以前我究竟是用什麼臉在唸大學啊！？ BTW，大家有空可以去看看他的展覽。 五、ＣＰＢＬ： 中信鯨解散了。 雖然斷斷續續看了幾年的球，但是今年的黑米事件再次影響了中華職棒，沒想到米迪亞從籃球吃到棒球來，並不是帶來喜訊，反而是讓黑勢力更加深入職業比賽當中。 最後台灣又剩下四隊職業球隊了......唉..... 10月16日 [神棍]把這兩個人綁起來!! 我們家的人知道，我現在只要看到股市和油價，就會把這兩個人抓出來罵，一個是謝金河，一個是忘記名字的女教授。 謝金河不用說，這傢伙現在還是不時的會在年代新聞台出現，在選前不斷的在喊台股萬點的人，他也有份不用說，甚至還喊出「台股兩萬點不希奇」的神經論點。其實台股在三月時，就已經看到最高點的反轉訊號，要上九千八點點已經是很誇張了，沒想到謝金河還是在新聞和節目上鼓吹進場。最近看台股的一日行情，真是愈看就愈火（雖然我沒有進場，不過只要看到國安基金進場就有氣...）。 把他綁起來！台股兩萬點的時候再放他出來。 其實台股有一個方法可以簡單上萬點，就是把加權值調整一下就可以了...（被打飛） 第二個人，是一個女教授，在油價破一百四的時候，出來接受電話採訪：「油價上兩百元，冬天就要來臨了，油的使用量會增加，會到兩百元我一點也不意外吶～～」 他媽的，就在她接受完採訪後，油價上了一百四十五，然後就反轉，跌破一百四。然後一路下來，今天的西德州原油也接近七十元，杜拜和布蘭特更別說，早就已經在七十元以下了。 把這個女教授綁起來，油價破兩百元的時候再放他出來。 親愛的教授，你沒有出來說話會死嗎...今天下午我終於找到這位兩百元教授了，他是淡江大學經濟系教授廖惠珠。 我把她的『預言』整理一下： 5/1:廖惠珠認為以國際局勢來看，七月前油價調降機率低。(蘋果) 6/28:淡江大學經濟系教授廖惠珠認為，油價預估會在暑假漲到一百七十美元，關鍵是若美國需求未減緩，美元持續走貶，油價攀升機會就高。(蘋果) 7/21:淡江大學經濟系主任廖惠珠表示，原油長期基本面還是供不應求，明年可能會站上每桶兩百美元的新高！(台視新聞) 7/21:淡江大學經濟系主任廖惠珠表示，雖然短期內油價有略微下滑跡象，但未來面臨颶風威脅、寒冬需求增加及美國用油減量成效等不確定性因素仍然存在，加上中國、印度用油量持續上升，基本面仍供不應求，未來油價持續上漲機會大，甚至明年有可能上看每桶二百美元。(蘋果) 7/22:淡江大學經濟系主任廖惠珠最近才到土耳其參加「國際能源經濟學會」，廖惠珠表示，與會的學者認為，明年國際油價應該會在每桶一百到兩百美元之間(中廣新聞網) 10/16:淡江大學經濟系主任廖惠珠認為，以全球原油開採成本來看，落到七十美元已算合理。 (蘋果) 最近有很多消息，說台股會多低多低，油價會多低多低，我只能說，最好的時候還沒來，但是最壞的時間已經過去了。台灣人應該要高興，因為南韓之前的好大喜功，已經給他們產生不良的結果了！這個故事給我們的反思是，牛皮人人會吹，但是最後都會有考驗的。 所以，不要聽那些神棍在那裡胡扯東胡扯西，這些人光會落井下石或錦上添花，沒什麼鳥用。 10月7日 [C#]處理一連串if/elseif的理想做法最近在整理一支程式，發現有一段這種程式： 1: if(i==1) 2: .....3: else if(i == 2) 4: ....5: else if (i == 3) 6: ....7: else if (i == 4) 8: ....9: else if (i == 5) 10: .... 11: .... 12: ....13: else if (i == 200000) 14: ....15: else 16: Console.WriteLine("This loop works die almost!!"); 也許這個數字有點誇張，但是比較常見的是四到五個，甚至接近十個，放進資料庫裡覺得太少，用If/elseif來做又很長的的程式碼。
也許有人會換成用Switch case來做，效能好一點，但是還是一長串，Like this:
1: switch (strErrorCode) 2: {3: case "10": 4: return "Ten"; 5: case "11": 6: return "Eleven"; 7: case "12": 8: return "Twelve"; 9: case "14": 10: return "拾肆"; 11: case "15": 12: return "拾伍"; 13: case "16": 14: return "拾陸"; 15: case "17": 16: return "拾柒"; 17: case "62": 18: return "很多的Case"; 19: case "31": 20: return "放進資料庫又太多"; 21: case "52": 22: return "放在程式裡也太多"; 23: case "60": 24: return "更重要的是"; 25: case "70": 26: return "維護上也很麻煩"; 27: default: 28: return "有時候還會忘記Default!"; 29: } 處理這方面的問題，我們先從學理的角度來研究這個問題：資料量多大時，放進資料庫會比較適合。一般來說，資料庫在搜尋資料時，並不是透過小學生的循序搜尋法來找資料（即上例Case1），而是透過其他的演算法來處理：也許是二分，也許是內插，但無論如何，搜尋的成本都沒有想像中的高，因此，把if/else或者switch/case的資料放進資料庫，增加的成本要怎麼估算？就是這些資料究竟有沒有由DBMS管理的需求？像上面的Case1以及Case2，其實都沒有進資料庫管理的必要。如果資料值得透過DBMS來管理小型資料的話，我們先假設資料庫是利用比較簡易的二分搜尋法來找資料，假設我們的if/else已經大於8筆(2的3次方)，其實是可以進資料庫做管理，因為在Worse case下，在三到四次以內就能找到所需的資料(log(base 2)8 = 3 log(base 2) 16 = 4)，但如果透過if/else來做處理，Worse case的成本是8，算起來是相當值得的。
但是，如果我們不考慮使用資料庫，但也不想用if/else的處理方法？我有個建議，就是抽出來用Collection。
做法其實很簡單，就是將那一個很大的判斷式，用另一個物件來處理，該物件裡再用Collection來管理資料，最後再利用method來取得資料。
原本if/else的部份先改成：
1: protected string errorMessageHandle(string strErrorCode) 2: {3: errorMessageHandler errorHandler = new errorMessageHandler(); 4: return errorHandler.getErrorMessage(strErrorCode); 5: }然後再撰寫errorMessageHandler的部份如下： 1: public class errorMessageHandler 2: {3: private System.Collections.Hashtable hashTable; 4: public errorMessageHandler() 5: {6: hashTable = new System.Collections.Hashtable(); 7: }8: public string getErrorMessage(string key) 9: {10: string rtnVal = string.Empty; 11: createHashTable();12: try 13: { 14: rtnVal = hashTable[key].ToString(); 15: }16: finally 17: { 18: hashTable.Clear(); 19: }20: return rtnVal; 21: }22: private void createHashTable() 23: { 24: hashTable.Clear();25: hashTable.Add("10", "OXOXOXOXOXOXOXOX"); 26: hashTable.Add("11", "OXOXOXOXOXOXOXOX!!"); 27: hashTable.Add("12", "OXOXOXOXOXOXOXOX!!"); 28: hashTable.Add("14", "OXOXOXOXOXOXOXOX!!"); 29: hashTable.Add("15", "OXOXOXOXOXOXOXOX!!"); 30: hashTable.Add("16", "OXOXOXOXOXOXOXOX!!"); 31: hashTable.Add("17", "OXOXOXOXOXOXOXOX!!"); 32: hashTable.Add("18", "OXOXOXOXOXOXOXOX!!"); 33: hashTable.Add("19", "OXOXOXOXOXOXOXOX!!"); 34: hashTable.Add("62", "OXOXOXOXOXOXOXOX!!"); 35: hashTable.Add("31", "OXOXOXOXOXOXOXOX!!"); 36: hashTable.Add("52", "OXOXOXOXOXOXOXOX!!"); 37: hashTable.Add("60", "OXOXOXOXOXOXOXOX!!"); 38: hashTable.Add("70", "OXOXOXOXOXOXOXOX!!"); 39: } 40: } 程式碼比if/else來處理是變大了很多，但是這程式的優點在於：在增加判斷式上的便利性及彈性增加了：其實createHashTable的部份可以可以改成讀檔來處理，如果訊息有修改時是可以不做到不用重新編譯程式。如果是使用Java來處理，可以利用相對應的Collection來處理（應該是用HashSet之類的）。
何時使用呢？這個可能需要仔細評估一下：因為HashTable可能會占用很大部位的記憶體（尤其當HashTable相當巨大時），其實如果有恰當的記憶體管理或是Design pattern（例如用singleton來實作），對於記憶體的占用就會比較輕。總之呢，只要用到Collection，記憶體的管理就是要列入考量。 10月3日 [故事]我聽來的故事 - 2 最近從同學那裡聽說，一個苦情的學妹結束了上海的出差之後，就要換工作了，新的工作是到廠商那裡去上班，以我的說法，就是從乙方變身為甲方，從悲情的奴役角色一下變成了主人！ 其實這種變化是健康又有益身心的，但是幸運的話這種變化其實也挺難得的，也可以這麼說：她這種變化等於是停止了飄泊的Coding歲月，人生的旅程可以在某個岸邊得以休息... 下面這個例子就沒那麼幸運了。 我一個長輩，正在幫Ｋ公司履行一份對Ｔ單位維護合約，甲方的承辦人Ｌ，是一個大概二十幾歲的年輕小伙子，原本以為年齡相仿應該還好溝通，沒想到他承辦人這個角色做得非常好，不但屢屢使用相當強勢的態度來要求乙方進行不合理的工作內容，而且口氣相當的不客氣。據說這位承辦人一年之間氣走了十幾個程式設計師，更可惡的是，他還將乙方的工作成果當成自己的工作成果，回報給他的上級，讓上級誤以為這個成果是由他完成的！這種近乎瓢竊的行為他也不在乎。 喔對了，他的身份也不是正式職員，也是Ｔ單位的約聘人員。 隔年年初，該單位和Ｌ談換約，他也把Ｋ公司的上級找來，雙方談了許久，達成了一個協議：Ｔ單位不知道為什麼，決定要更換承辦人，那原本的承辦人呢？Ｔ單位以續約做為條件，希望Ｋ公司收下Ｌ，但工作地點仍在Ｔ單位的辦公室，不過Ｌ的角色由原本的承辦人變成維運人員。 這下可嚇壞了在Ｔ單位呼風喚雨的Ｌ，但以他的身份並沒辦法要求些什麼，也只能照辦了。 一夕之間，Ｌ的身份由契約的甲方承辦人變成了乙方維運人員，不但如此，他的長官還由原本的Ｔ單位頭頭變成了我的長輩。Ｌ盡可能的習慣這種改變，但仍無法改變自己的態度。 「你們Ｋ公司之前如何如何如何...」 「我們Ｔ單位如何如何如何...」 新的承辦人上任之後，對Ｌ仍然是畢恭畢敬，但日子久了，當承辦人的角色慢慢暖起來之後，仍不希望他是以前承辦人自居。而Ｌ雖然只是角色改變，工作內容並沒有什麼太大的變化，但自己深覺被「降格」之後，沒多久也萌生辭意，黯然離開現職。 離開前還發生一件事，在做工作交接時，長輩對Ｌ不太合作的態度感到非常不耐，當Ｌ在那裡指天畫地的說著「你們Ｋ公司之前如何如何」時，長輩突然丟出一句。 「那你現在是在質疑我的管理方式嗎？」 相信我，這句話無論是在軍中，或著在職場，這話都是很有力的一句話... 真的，風水輪流轉，什麼時候甲乙方立場會倒轉過來，沒有人知道... 10月1日 [Visual Studio]從起始專案看VS的發展 從Visual Studio的code initial就可以看出微軟對這個新版本的編輯器及核心有什麼大的延革。
來看看進入.Net年代時的Visual Studio.Net有什麼特別的。
1: using System; 2: 3: namespace Test 4: {5: /// <summary> 6: /// Summary description for Class1. 7: /// </summary> 8: class Class1 9: {10: /// <summary> 11: /// The main entry point for the application. 12: /// </summary> 13: [STAThread]14: static void Main(string[] args) 15: {16: // 17: // TODO: Add code to start application here 18: // 19: } 20: } 21: } Yes，沒什麼特別的，using裡只有引入一個很普通的System而已，如果要用什麼東西，程式設計師必需一個一個把他using進來，這個版本的.Net其實最主要的變化在於翻天覆地的變化，也可以說是一個新的里程碑吧！
進入Visual studio 2005之後呢？
1: using System; 2: using System.Collections.Generic; 3: using System.Text; 4: 5: namespace MyTest 6: {7: class Program 8: {9: static void Main(string[] args) 10: { 11: } 12: } 13: } 從using段看得出來，這個版本最大的進展就是在泛型...其實也不知道是Java抄微軟，還是微軟抄Java，同時期的Java 5也推出了泛型，但是東西不太一樣，定義的物件類型也略有不同，但是這個東西在效能的表現上（尤其在平台有支援的情況下）表現極佳。
比較令人在意的就是微軟直接把System.Text引入進來。在System.Text底下，其實還有一個東西在System.Text底下的一個namespace，就是RegularExpression，這個namespace也許對程式設計師來說是比較常用的，但在System.Text這個namespace底下究竟有什麼class呢？在2003底下，只有Encoder及Decoder，在2005下呢，也是有Encoder及Decoder，再加上一些Exception及Fallback的機制...我只能猜測這些東西也許平台在使用某些功能時，會使用到encoding及decoding，因此不得不將這個東西引入進來，但是應該是可以花點時間研究一下這個namespace底下究竟有什麼特別的東西及功能。
進入Visual Studio 2008：
1: using System; 2: using System.Collections.Generic; 3: using System.Linq; 4: using System.Text; 5: 6: namespace LinqTest 7: {8: class Program 9: {10: static void Main(string[] args) 11: { 12: } 13: } 14: } 係地，又是Linq，微軟果然是拼了老命想把這個東西推行出來，從各項證據顯示，Linq將很有可能是未來兩三年的微軟新寵兒，我很想拿這個東西跟NHibernate比較看看效能上的差異，不過不提效能的差異，光是編輯器的支援，我想NHibernate就輸了一大截了吧！
從這種小小的地方，就能看出微軟對自家產品的看法以及應該著焦的地方，如果是微軟的Programmer應該可以從這些地方看出未來應該努力的方向吧！ 9月30日 [MS]不再自己玩自己的IE 8 微軟從有IE開始，就一直走著自己的路，就算真的有正式的規格，微軟仗著他財大業大，竟也可以視若無睹，但現在不知道是不是因為Google的Chrome以及Firefox已經威脅到IE的市占率，還是微軟真的開始苦開發者所苦，IE竟然反過來大量的支援W3C以及CSS的標準！這可嚇死像我這種吃過微軟苦頭的設計師：什麼？我不用再判斷使用者的瀏覽器，再去決定要跑什麼Java script了嗎？ 別的不提，光是Acid2的測試，就可以看出IE真的很盡心盡力的在和這個世界接軌，甚至可以發現，IE對現行的HTML 4的支援度，比Firefox或Chrome都還要高（微軟是宣稱80%左右），未來的HTML5草案，IE8(甚至IE7)都已經開始去支援了。    以上三張圖由左至右分別為IE8、Firefox 3.0、Chrome，其實Chrome的Acid測試基本上是Pass的，但是應該是Pass*才對，因為當做瀏覽器的resize時，笑臉人的頭蓋骨就會飛飛飛飛飛飛起來了。 除了支援性上的進步以外，在效能上也有長足的進步，在Javascript引擎的部份做了很大部份的修改：其實說IE對自家產品最佳化也不為過，微軟開始正式Web Application的發展性無可限量時，對自家的瀏覽器投入了極大心力在進行開發以及行銷，無論在安全性、效能、使用者界面及操作的友善性都比IE7提升不少，甚至對開發者來說，以往最缺乏的開發者工具都內建了，而且比其他競爭者的工具更好，更方便。 但IE8卻有一個非常令人垢病，但卻又令人又愛又恨的功能：不提IE6，就針對IE7和Firefox來談，以前操作瀏覽器頁籤時，如果有某個頁籤Crash掉，則整個瀏覽器都會因此被迫重開，IE8提出了一個新的方法，叫做「Loosely-coupled Internet Explorer」...如果對Pattern有點了解，Loose coupled就是低度耦合，換句話說就算使用者開了兩萬個頁籤，其中一個頁籤掛了，也不會影響到其他一萬九千九百九十九個頁籤，很讚對不對，錯！每個頁籤都是同不同的Thread在操作，意思就是說，每個頁籤都各別使用一個執行緒的資源，我曾經試著去看資源管理員...Firefox開十個占用大概200MB的資源（我也不知道為什麼），而IE只開了三個，資源就已經快要破百。當然啦，我並沒有去深入研究IE8他在資源占用上和其他瀏覽器究竟有什麼不同，罷特，如果IE吃資源是用這種方法吃....我並不會對這功能感到高興。 如果還有人對IE的印象是停留在IE6那個殘破，只是為了應付而做出來的瀏覽器的話，那可真的是大大的落伍了，事實上，我在操作IE7以及Firefox2或Firefox3上，其實得到的滿意度基本上已經都得到相當高的評價：喔拜託，還在說用IE中毒？不知道是誰手賤去Click不該點的連結，就算瀏覽器已經好心提醒了，還不是硬要點？IE8長足的進步，不但讓使用者有更好的使用經驗，以及與其他應用程式更接近的操作方式，對於更常使用瀏覽器的開發者，IE8提供了更強大的使用者工具（嗯，也許比Firebug更強大喔！），這種進步，除了刺激Mozilla以及Google提供更好更方便的軟體以外，其實得利的一方，還是使用者，如果Windows通知要升級到IE8，相信我，你有很多很多的理由告訴自己：「來裝個IE8吧！」 反正還是能移除的...科科。 9月27日 [ASP.Net]Code behind將死？ Code Behind技術一直都是.Net時期微軟在網頁技術中最大的應用，但隨著網頁架構的演進，以及對安全性考量的要求愈來愈高的情況下，Code behind是否完全符合所謂MVC架構(Model/View/Controller)的討論事實上是時有所聞。 除此之外，Code behind這個技術代表著微軟所推出的網頁技術從原始的頁面與程式放在同一頁，轉變成為源碼與頁面設計分開。這種設計的優點在於，以往頁面設計以及商業或邏輯流程設計必需綁在一起的情況得以改善，程式設計人員與網頁設計人員將不需要針對同一個頁面做修改，而可以各別做操作。 但是Code behind這種東西，他的架構其實還是有討論的空間，尤其在物件導向技術愈來愈純熟的情況下，MVC的架構也愈來愈完整。然後Java就推出了Struts來實作MVC架構。 老實說，我覺得Struts非常神奇，但我不太會用。  如果有寫過Struts，他的設計方式真的把Model和Controller拆得非常乾淨，在Controller裡沒有Model，而Model裡又與Controller的操作鬆散的連結，基本上就是由Controller來決定頁面的生成。這有什麼好處？除了符合所謂MVC的架構之外，也有所謂保護原始碼的機制在裡面，其實外界並不知道實際的頁面長像，只能看到副檔名為action的元件操作。 Code behind不能進行MVC的架構設計嗎？可以，基本上這種架構只要經過適當的架構設計（如商業邏輯及頁面邏輯的分層）就可以完成，其實裡面最難的就是如何將Controller和Model做適當的切分，一個沒有太多實作經驗的程式設計師其實很難運用物件導向的操作原理來實作，更別提所謂MVC架構，甚至N-Tier的程式架構了。 去年微軟推出了一個新的Framework，叫MVC Framework，也許可以這麼說：LINQ是.Net framework版圖裡最重要的一塊拼圖，這塊拼圖將主宰未來.Net framework發展的走向。 不不！Code behind還會在，就像要直接在ASPX的頁面寫程式也是可以，但是這種架構是否會慢慢的被視作不入流的應用？沒人知道，但是從幾場微軟所舉辦的研討會，甚至Tech ED，LINQ都是不斷被提到的新技術，微軟甚至將它與SQL Server做非常緊密的結合。即使我們都知道Hibernate在Java的場子裡表現雖然不俗，但是卻有相當令人垢病的效能及設定問題，但微軟還是將LINQ用力的推展開來。而MVC架構有什麼問題呢？設定以及難以跨越的進入門檻，尤其是在Model的部份和Linq做結合之後，效能上的表現會不會讓強調大量運用的客戶卻步？ 我們拭目以待。 9月15日 [科普]週末的NGC & Disco very 上個星期最大條的事，不是誰又講錯什麼話，也不是誰的錢又從口袋裡露出來，更不是那個四處打轉的颱風，而是可能創造微黑洞，讓上帝還沒決定什麼時候要摧毀地球前，一群 總之呢，我是抱著「就算被吸進黑洞，我也不要被吸得不明不白」的心情在看NGC的大型強子對撞器的特輯。 為什麼會叫「大型」呢？顧名思義之前有一個比較小型的。不過這台花了近二十年才建起來的大怪物，其實並不是只是要看兩個質子對撞，其實這是包含了很多比較小的計畫。而NGC這次主要是拍攝ATLAS（超環面儀器）及CMS（緊湊渺子線圈）的建置過程。  上面這張圖，大概就是LHC這個計劃的全貌。 老實說看完之後，我挺擔心的，雖然那是一群全世界最聰明的人在幹的大事業，但是建置的過程和我參與的專案都差不多：所有事情即便在上線之後都還是無法控制。會不會產生黑洞？或著像迷霧驚魂般，連結到其他異世界去？ 嗯，結論就是，NGC也不知道，也就是說，就算我被吸到黑洞裡，我還是不明不白的被吸進去。 另外的一件大事，就是九一一攻擊事件滿七週年，所以這兩個頻道又瘋狂的在播放九一一的特輯，雖然兩個頻道都著眼於攻擊事件本身的始末，以及過程（如聯航175以及聯航93）。這幾個特輯都製作得相當精采，但是也很令人心酸，尤其是聯航93的經過，更是令人佩服。 沒看到嗎？那...等明年吧...:D 9月12日 [Music]不合兩兄弟. 有一天，我學弟問我，不合兩兄弟是誰。他們就是知名的英國搖滾團體：Oasis的主唱Liam Gallagher及吉他手Noel Gallagher。 樂壇裡不知道傳多久這兩個兄弟不合的情況了！Oasis也多次因為這種傳言而傳說Oasis就要解散了，不過事實證明，他們不但愈吵唱片賣得愈好，而且愈吵愈紅。  開始聽他們的音樂，是從一九九五年開始的Morning Glory?，那時候還不是專輯，是一張合輯吧！九五年那時候聽到Oasis的"Don't look back in anger"驚為天人，雖然那是一首有點吵的歌，不過真的非常好聽，小時候也沒注意歌詞裡究竟唱些什麼，只覺得...Wow!This is really what i call the music..後來還是賣了這張CD，甚至還有一種很鍾情英倫搖滾，覺得稱他們為Beetles之後最成功的英國搖滾樂團真的並不為過（Blur？Good,但我跟他們不熟喔...XD） 不管怎麼說，Oasis還在，不管之後的Coldplay、Keane的表現如何搶眼，都沒辦法強過我對Oasis音樂的那種喜愛。  說句題外話，最近很流行「鈴鼓手」，Oasis的鈴鼓手是誰呢？不是別人，就是主唱Liam，有圖為證...XD Oasis的音樂，幾乎可以說沒有攻擊性，大多的歌都挺正面的，不過樂團的性格就相當的火爆...這其實可以說是一般音樂人的通性吧！總是唱著我的未來不是夢，但是私底下的卻挺火爆的，最近有個新聞，就是不合兩兄弟在加拿大演唱時，有個神經病突然衝上台來攻擊Noel，不過Liam馬上把那神經病丟下台去痛扁一頓。 希望Noel沒事才好。 總之呢，Oasis又出新專輯了，本人是抱著既期待又怕又傷害的心情在等這個專輯...至少也等了兩年左右，希望有好的專輯才好啊。 Don't Look back in anger Live Don't look back in anger (抒情慢板) 8月15日 [.Net]初探Data Service 昨天參加了微軟老大哥所辦的Seminar，雖說是一整天的會程，但是兩場所討論的東西大不相同。 先說說早上的議程：Sql Server 2008程式...超長的，反正就是微軟找個時間宣傳新上市的SQL Server 2008。其中多了很多對Programmer很好的新服務，有一些耳熟能詳的東西，像Linq、WPF、Sliverlight...之類的，不過有一個好東西，卻很少被提到，這東西叫Data Service。 以往程式設計師在寫Ajax的時候，常會寫處理後端資料的頁面（或元件..Whatever），藉由Javascript來存取這些頁面，無論是利用Get或Post的方法，來完成一些不用換頁的存取動作。在Ajax漸漸被微軟重視之後(其實也是Sliverlight也有這方面的需求)，微軟發展了一個新的專案，叫Astoria，這東西就是後來的Data Service。 這個專案提供了Programmer一個方便存取資料的方法，透過URL的方式，向後端資料庫存取資料，無論是增、刪、改、查都可以處理。提供的資料格式，除了一般的XML之外，還提供了現在很紅的JSON(JavaScript Object Notation) ，這個服務可以說大大減少了程式師的工作負擔，可以把一部份的工作交給這個服務來完成.... 只要你夠相信它的話。 其實這東西可以說是Web service的另一種型態，如果換個角度來想，這個服務可以讓專案更容易切分成N-Tier，Programmer可以把Data Layer留在Data Service層中，使用者的程式透過Data Service取得資料。簡單的說，前端的Programmer不需要知道後端資料的細節，後端的Programmer也不需要前端資料的取用方式，以往令人頭疼的ODBC、JDBC都可以把他丟到垃圾桶...他們不再是取用資料的唯一方法了。 只要你夠相信它的話。 其實這東西比Web Service更強大，但也意味著它更危險：只要是透過URL取得資料，就有資料曝露在外的安全性考量，我不確定微軟在這方面是否有其他的考量，不過有一點是必然的：只要是放在Web Service上的資料，某方面來說就是要有「這東西遟早會曝光」的準備，安全性永遠都是便利性的反項，就像效能也是便利的反項一樣，程式設計師只能在中間取得平衡。 從Ajax全力支援、Linq到Data Service，看得出來微軟在這方面的巧思愈來愈多，找個時間來弄一個全套的2008來玩看看，也許會有什麼意外的收獲。 8月12日 [Movie]從"時空線索"一片看佛家的生死觀 這篇真的是胡言亂語了。 最近電視台在播放很好看的「時空線索」，說有一個很有趣的Team找到了一個透視過去時空，甚至穿越時空的方法，雖說成功的阻止了暴行，但也可以說一切都沒有變化...這是怎麼一回事？ 我們先從電影的開頭開始說起：丹佐華盛頓在調查一宗遊艇爆炸案時，發現此案與另一件凶殺案有關，而丹佐華盛頓不願看著凶殺案再度發生，決定利用各種方法找出凶嫌，甚至阻止爆炸案的發生。 好，說完了，那這跟佛家生死觀有什麼關係。 在片中有一個所謂「平行線宇宙理論」，意思就是說我們生活在一條時間線上，有過去，現在和未來，但如果更動了其中的一個參數，是有可能改變整條時間線的，也就是改變參數的過去將流向另一個未來，並與現在平行。以前我在上數學課時，我的數學老師強調平行線的交點是在「無限遠」的地方，這個「無限遠」的地方，其實就可以印證在這個平行線宇宙理論裡。 因此，佛教裡的禪宗常會利用這種宇宙觀，說明過去、現在和未來其實是變化莫測的，現在我和過去我也許有關連，但是未來我會因為現在我的種種想法和念頭，創造出許許多多的可能，而這些過去我都是存在的。而當下的這個時候，每個我都在生活著，換句話說，如果我們有機會坐上時光機，這些我都還在上班、上課，過著日常生活中。  什麼意思呢？就是一個念頭，產生了一個不同的世界，也就會產生一個不同的結果。丹佐華盛頓透過時光穿梭的方式回到過去，雖說是改變了未來，但是一些事件卻不曾改變，因為他們都真實存在，雖說無法解釋，但總是會有機會證明他是合理存在的。 所以佛家強調「當下」的重要性，當下決定未來的走向，未來也印證了當下的決定，如果站在未來看現在的選擇，是會有無限多種的可能性，所以「我」是不重要的，因為將「我」放在宇宙時間線上，只能決定一個「點」的空間...其他太宗教性的教諱就不多提了。  其實可以想像我們過的每一秒都在一個電視螢幕中播放著，然後有成千上萬個螢幕都在放送著我們的人生，不過如果其中有一格想不開做了不同的決定，那這一格就放送著不同的生活，以及不同的未來...也許你們不相信，這個想法是我國小六年級時，在放學路途中的一個幻想... 結論就是：人常常會有一些想法和念頭，去牽動一個行為和動作，雖說是微小不切實際的行為，但對未來的影響力是很巨大的（See!又和渾沌理論牽上關係了），因此不要執著於「現在」想要幹什麼，應該著眼於「未來」會成為什麼？ 這篇對於時空線索的說明更加的詳細，可以參考看看。 和這部片同時上映的「關鍵下一秒」有更出色的時間流的實體化表現，可以放在一起看看...雖然我覺得這部的結構很失敗.. 記得以前有人說「人不能活在if if的過去」，基本上我是贊同的，但是如果站在未來看現在，如果能預先知道這些if所帶來的後果，那可真是個了不起的能力啊！ 8月7日 [法克]這個單位每年都跟我們說"我們快倒了"...... 當我看到這個新聞時，實在止不住自己憤怒的情緒...
這個單位，每年調升投保人的保險費就算了，都已經換政府兩個月了，才發現原來乙方的董事長是自己老闆手下的行政院長。那就算了，沒想到還在推責任！一下子是法律的問題，一下子是東元的問題，好像全世界的問題都不是他們的問題，全部都是法律的問題，要不就是乙方的問題，是乙方沒告訴我你們董事長的哥哥當行政院長了，是法律規定要利益迴避的，我們是甲方，偉大、正義、代表人民的甲方？ 啊？出問題了，那....就把紙卡拿出來用吧！順便通知重新發標吧！什麼？一定要用健保IC卡的人？關我屁事！ 所以，在健保局裡的十幾個人，以及東元的一個人，就可以決定還沒拿到健保IC卡八十萬，甚至十百八十萬人的權益。是誰給你們這種權利的？ 好事是，終於在壓力之下，健保局做出「比較正確」的選擇，暫時接手東元的製卡作業，並且盡快發包找新的廠商來處理，不過，只要待過公家機關就知道，除非新的廠商將東元製卡的程序整套買回來，要不然就算再發包，東元還是會得標，原因很簡單，東元花了那麼多的成本在製卡機器上，光成本就贏很多廠商了，如果東元真的迴避，那很簡單，要嘛就是買東元的製程，要嘛就是未來有新的健保卡產生（幸運的是Java card應該是另外一個廠商做的產品，東元不可能自己包啦！），聰明的廠商該怎麼因應呢？ 從健保IC卡這件事，再次凸顯健保局這個單位管理之爛，該單位法務之懶散，還有公家機關那種不願負責任，行盡推諉之能事，看他們那個發言人說那篇屁話，我差點把手中的便當丟出去...接下來就看監察院怎麼查這筆帳，如果有問題...真想看看健保局要怎麼推。 [電影]誰會看Mamma mia? "One guess: a lot of the women who saw Sex and the City, plus kids who loved High School Musical, plus some gay guys, And, a big plus, most of those who saw the original musical, which by now grossed over $2 million -- more than any movie has ever earned in theaters."  這不是我說的，是時代雜誌的專文，在介紹Mamna mia!這部片。上個星期，時代的電影介紹，專文在介紹近期的幾部電影：Indiana Jones、Iron man、Hellboy、Sex and the City，以及這部Mamma mia，他們有個共通的特點：熟(geriatric actors)。 Mamma mia!是怎麼樣一部戲呢？其實看看預告片大概也看得出來，不過再看看演員陣容：Meryl Streep, 59, Pierce Brosnan, 55, Stellan Skarsgard, 57, Colin Firth, 47...有夠熟的一部片，但這部片在英國甫上映，就拿下英國電影榜的冠軍！這部片無論是卡司陣容，音樂（別說你不知道ABBA），還有電影內容都相當令人矚目。雖然時代雜誌有點酸溜溜的在說這部片如何如何，但整體來說還是給予不錯的評價，也預期這部片應該會賣得不錯...其實也是想當然爾啦，台灣好像除了吉屋出租（Rent）這部沒有賣得很好，其他幾個音樂劇的電影如Chicago、Dreamgirls、Hairspray都還賣得不錯。 目前看起來，只要時代有介紹的電影都還滿不錯的，我想應該值得推荐給大家進戲院去看看。只是看之前，也許你要想一想，你是時代所猜的那些人之間的那一種呢.... 8月5日 [故事]我聽來的故事 - 1 我有一個朋友，最近剛從第三世界回來，渾身是傷。但是他沒有休息很久，就趕往下一個城市工作了。 我一直以為在第三世界，除了盛產石油外就是一望無際的沙漠，沒想到他跟我形容的也是這樣。 「去那裡當工程師真的是整死人了。」 當然，他也不是自願去那裡工作了，現在流行駐點派駐，沒想到連第三世界也如此，裡面不但工程師是派駐的，連管理的人也是派駐的，駐點人員、約聘人員都比正式員工還多。不過令人覺得奇怪的是，管理人員的氣焰比技術人員高也就算了，非正式員工的管理人員氣焰也比正式員工的氣焰還高！當你進入他們辦公室裡，聲音愈大聲的，那個人一定是管理人員，而且是約聘的，而他在教訓的人，一定是來自另一間公司的派駐人員。 「（尖叫）我不是跟你說！那～份～文～件～十～點～前～要～給～我！」暫且稱他為恐龍大姐吧！恐龍大姐帶著藍牙耳機，在工程師工作區裡踱來踱去。我朋友說，他帶著睡眼看著他，很懷疑自己是不看錯了？因為現在時間是十二點五十分，已經關了燈大家正在休息。而全辦公室的人都被她一個人打擾了！ 「（尖叫）我不管你什麼路途遙遠！一九九九專線本來就不是這樣弄的～你現在就給我送來！」恐龍大姐持續尖叫中，從十二點五十分一路尖叫到一點十五分，沒有任何人敢阻止她。 我朋友嘆了口氣，「每個人都是去工作的，幹嘛把氣氛搞成這樣，更何況他還不是正式員工，只是坐位在他們之間罷了」，他很慶幸他不在恐龍大姐手下做事，不過據說他的管理人員一度表示想把他的管理人員換成恐龍大姐，讓他悶了好一陣子。 不過，好事是他已經離開現在工作的地點了！不用再聽到那種會令人腦神經衰弱的尖叫聲了。據他形容，那種聲音就像一千根針掉在玻璃上，不斷刮著然後發出刺耳的尖銳聲響..... 8月1日 [.Net]微軟，這到底是複雜，還是簡單呢？ 最近被指派了一個新的任務，負責維護一個簡單的Windows Service。 仔細想想，這好像是我寫.Net以來的第一支Service，以往都是以Application(甚至是Web)為主，拿到了這程式，雖然是簡單的專案，不過仍是令我興高采烈不已。 打開專案以後，我有點傻掉了：整個專案裡有兩個不同的Class，一個是Service，一個是ServiceInstall，Service顧名思義就是主要的服務，那...ServiceInstall呢？難不成還要去寫一個安裝的程式？ 沒關係，我自己開一個Service的Project看看，不開還好，一開真的看到自己的渺小... 還真的沒有Install...難道微軟背棄我們了嗎？我耐住性子，編寫了一個簡單的小程式測試Service。 1 namespace myService 2 { 3 public partial class Service1 : ServiceBase 4 { 5 public Service1() 6 { 7 InitializeComponent(); 8 } 9 10 protected override void OnStart(string[] args) 11 { 12 EventLog.WriteEntry("My simple service started."); 13 } 14 15 protected override void OnStop() 16 { 17 // TODO: Add code here to perform any tear-down necessary to stop your service. 18 } 19 } 20 } 這程式的意思是在Service啟動時，會在事件檢視器裡寫入一行「My Simple service started」，寫完compile結束後...好像什麼事都沒發生，我天真的以為他就會出現在服務裡了...結果當然是沒有。 拜大神之後，找到，原來是要用installUtil.exe這支公用程式將程式安裝進去，OK啊，來測試看看。
哩係得共啥米小朋友...反正就是沒有寫進去就是了，少了一個RunInstallerAttribute的東西。 好啦～這時候也只能摸索了。先把那個專案打開，然後再看看程式結構。果然是有一個RunInstaller的東西，把這個Keyword丟到Google後，找到一線光明。 經過了千辛萬苦，我終於把Service安裝進服務裡了，只覺得一陣莫名其妙：難不成這個Service是可以安裝在Linux裡面？這樣到底是簡單還是複雜？以一個開發環境來說，這麼做只是讓初次接觸的開發者摸不著頭緒，這些可以簡化為三步驟Step by step簡單處理的"Windows 專屬服務開發"，卻弄得有夠多事。 好吧！至少我找到答案了。 |
|
|
