ericsk.net

告別微軟二年生

2013-03-02T22:52:16-08:00

這是我踏入職場的第二次滿兩年，感受卻是大不相同。一年前寫過「微軟一年間」，周年留下記錄已經變成習慣了。在即將滿兩年 (2011 年 3 月 1 日我正式成為 Microsoft 的一員) 的日子，剛好最近又要對自己的 Role Model 作一番檢視，公司的檢視方式就不在這裡多作說明，網誌上就用自己的方式來作檢視吧！

隨著 Microsoft 在這一年來不斷釋出新的產品，我的工作內容也就變得「多元」起來，不僅僅是被 promoted 之後有更大的責任，很多作法或是決定都必須要跟著「重新發想」，過去我也像「一般的讀書人」一樣，做事、做決定都瞻前顧後、害怕犯錯，而且又容易沉浸於過去的成功經驗，以致一直難以打一次漂亮的仗、或是作出一件令人振奮的成績，但更巨大的壓力讓我必須採取更積極的作法 — 勇於嘗試、面對失敗，我們雖然在寫作文時都會寫出「失敗為成功之母」，往往一腳踩進讀書人的仕途無間道之後，就沒有那麼勇敢了。寫到這裡，便很感謝我的老闆願意讓我不斷嘗試、我的同事們 (包括實習學生) 都願意支持我偶而提出的新作法，我知道我們都相信大家都是為了大家好而努力的。

那我的自我修煉呢？其實我一直提醒自己：「希望我不要有一天需要特別提醒別人『我是有技術能力』的人。」所以我還是會努力的找機會抓時間鍛鍊自己的技術能力，這一年來，除了原本工作上就會研究的 Windows 8、Windows Phone、Windows Azure、IE/HTML5 之外，同時也持續複習精進 Web 開發技術 (還有熟悉 Windows Azure) 而作了「Visual Studio 2012 女孩」、「IE10 Hackathon」、「Windows App 開發嘉年華」還有「MSDN 開發訓練營」等網站，還有 Windows Phone 上面的「我愛微笑單車 WP7/WP8 版」、以及一些還在 github 上努力與尚未公開的程式們。除了練功、真真正正熟悉這些平台以外，也是要持續地學習技術，才會在技術面前表現謙卑，因為這一切都不是那麼簡單的。

我希望多年之後我不是說出：「我以前也是寫程式的，這很簡單吧…」而是「這個我前幾天才實際動手做過一次，真的有很多眉角要注意呢！」

工作愈久，愈是覺得自己需要進步的地方還是很多，也希望目前持續會與我在 face2face、internet 上互動的朋友持續給我指教，因為你們都有我沒有學習到的專業能力！雖然不知道這個系列文會寫幾篇，但只要是領薪水的一天，我還是會持續往「稱職的員工」努力，不斷使用日劇男主角的特殊能力：樂觀、堅持、不放棄來面對工作上的每一天！

加油，艾瑞克！

不犯錯的人生

2012-09-03T18:28:47-07:00

我覺得我們從小到大受的教育就是要我們過著「不犯錯的人生」。

「人非聖賢，熟能無過」，大概每個人從小學時寫的作文就經常引用這句話，然後曉以「知錯能改，善莫大焉」的大義。但真正能做到的人應該真的很少，基本上現在的社會結構就是層層上報，報喜不報憂，好像只要跟上級講了不好的消息、不利的發展就是自己的錯或是辦事不力，所以為了保障自己的地位就用盡一切方法爭功諉過，大家拼了命地維持皇城內的和諧，好像一切不好的消息只要蓋住就自動消失一樣。

我自己碰過一個例子，在團隊合作的過程中有個環節出包了，有個夥伴很快就跳出來指責批評誰誰誰沒想清楚、誰誰誰做了一個錯誤的決定、誰誰誰沒有做好確認，結果整個團隊開始花力氣跟時間在爭論到底是誰對誰錯，每個人都不想承認自己有錯所以僵持不下。結局就是….問題沒有解決，夥伴們感情也破裂，就只是因為大家都要維持著「不犯錯的人生」。

有一次我也在工作上出了個包，跟我合作的同事覺得很衰被我牽連到，當然是對我氣急敗壞地指責，而且希望我發個信出來說都是我的錯，當下我並沒有爭論究竟是不是我的錯，我對同事說：「沒問題，要有人擔錯誤的責任你都可以把我放上，但我現在希望我們先把問題解決，請大家協助我修正我犯的錯，把事情做好好嗎？」我不知道我犯了錯對我造成了什麼影響，但我很肯定事情在大家的合作之下順利完成了，出的包也盡可能地止血了。

在公司裡，我總會跟我有接觸的實習生說，別人怎麼帶你我不知道，但是我的風格是很能包容、允許而且歡迎實習生犯錯的，因為人都有羞恥心，犯了錯之後一定都會有點在意，這反而能讓他下次在做同樣事情時更謹慎，同時避開前一次造成犯錯的因素，怎麼說都是好事，更何況，沒有什麼錯是不能原諒的，不願意原諒別人犯錯的人，難道這輩子都沒犯過錯嗎？

如果你會害怕因為承認錯誤、失敗而失去些什麼，那應該是因為你本來就沒有什麼價值去擁有那些東西，才會因為一時的過錯而被「處理」掉吧..

士大夫的困境

2012-07-18T08:07:50-07:00

你以為我又想講「文人相輕」這個老梗嗎？其實我想說的更多….

「士大夫」過去是指在社會上有地位、有威望的知識份子，但其實我這裡想說的只是唸過書的人。你一定覺得很奇怪，唸書不是好事嗎？從小到大多少師長告訴我們：「只要好好唸書，就會有前途，會有好日子過。」所以有辦法的，都去唸書，沒有辦法的，想辦法讓下一代去唸書，所以整個台灣社會都是士大夫 (當然我也算是唸過書、是我所謂的「士大夫」)，那這樣不是應該很好嗎？大家都很有前途，都有好日子過…

但現在的社會氣氛看起來好像不是這樣….對吧？

其實士大夫都有困境，但不知道是沒有發現，還是基於士大夫的自尊而不願意承認而已？士大夫的困境就是非常容易被控制，怎麼說呢？各位士大夫可以仔細想想從小到大，我們唸書學得最透徹的是什麼事？就是「競爭」與「優越感」 (一字以蔽之就是「鬥」)，我們學的是追求個人的成功，所以在社會上，只要權威者給士大夫好的待遇或階級，這個士大夫就會自動去擺平其它的士大夫 (或者是為了爭取而自動產生競爭意識) ，所以有了「因為我頂著 OO 學歷的光環，讀聖賢書，所學何事？」的優越感，打從心底不想與人合作追求團體的成功，怎樣都要做到「我最棒、我最屌、我最厲害」才肯罷休。但事實就是，你有 OO 學歷只能證明你唸書考試超強，其它什麼都沒證明。更何況很多時候，你真的有把在學校學到的知識發揮在你的工作上嗎？

但是士大夫有優越感，做了與別人不一樣期待的事好像就是認輸，所以苦撐在自己可能不那麼有熱情、不那麼喜歡的領域中，開始懷疑以前追求的那個美好未來到底在哪裡？

我就以自己為例，我絕對不是優秀的讀書人，我高中化學考過個位數的分數、大學被當過幾科、碩士班也沒做出很了不起研究，但作為一個士大夫，我在每個階段也都接受了困境的挑戰。大學四年想換個環境唸碩士班，被所有週遭的朋友質疑為什麼不推甄本系；碩士班要畢業時，被所有的人質疑為什麼要去 CHT 服國防役；國防役結束時，所有人都訝異為什麼我要離開 CHT；甚至我到 Microsoft 做技術傳教士，也要被許多朋友質疑為什麼不做個~~堂堂正正~~道道地地的工程師？別人的故事我不知道，但這個社會就是那麼愛幫士大夫做生涯規劃：「你一個交大資科學士、台大資工碩士為什麼不 XXX ? 為什麼要 OOO?」

亂七八糟講了一堆，其實我想說的是，高學歷、高階級都不是讓你優越的條件，只有讓你的長處被發揮了才是。

Python on Windows Azure 簡報公開

2012-06-13T12:05:24-07:00

上週受到 PyCon Taiwan 2012 的邀請講了一場 Python on Windows Azure，這是我的投影片：

Building Python Applications on Windows Azure

View more presentations from Lin-Chieh Shangkuan.

如果你在註冊 Windows Azure 時在某個步驟 (填寫信用卡資料) 一直卡住不動的話，請先到 Microsoft Account 帳號總覽將您的姓名全改成英文即可。

那些年，我們一起用的 Google App Engine

2012-04-15T20:26:06-07:00

第一次覺得自己參與 OSDC.tw 這麼深 LOL

事情是這樣的，在今年的 OSDC.tw 研討會中，有一場 keynote 及一個 lightning talk 提及他們曾經來研討會聽到 Google App Engine 這個平台後的一些故事：
先是 zonble 的

以及 Toomore 的:

當然我知道他們都是開玩笑（希望不是我自我感覺良好），我也不會因為這樣就生氣還是不高興啦～只是覺得兩位都太抬舉我了，大家會想用 App Engine 應該是因為 Google 大神的服務，而不是小弟我的嘴砲（COSCUP 2008 Lightning talk + OSDC.tw 2009 + COSCUP 2009 以及數不清的 Taipei GTUG 活動）才對吧 XD 不過能被提到就是一種肯定（又在自我感覺良好了？），謝謝大家還認為我是個咖 Orz

不過我還是想說，當時我是真的誠心推薦 Google App Engine 這個平台的，並沒有收到任何營養金或是什麼好處（我同意得到現在的工作有關聯），而那時應該也蠻多人因為 App Engine 做了很多事情, 得到了很多開心才對。現在很多人要出走，應該都是因為收費機制的問題（呼籲 Google 的傳教士來回應大家的問題），那時的我從來就不知道該平台的 road map 或是收費的競爭策略，現在的收費機制完全是我始料未及的，說我推坑的話也太沉重了

至於到微軟工作，雖然我在 social media 上開了一點玩笑，但真正的原因之前已經交待過，就不特別再說什麼了。雖然成為了「廠商代表」，但是在各種資訊科技的技術上還是很希望跟大家交流切磋的

告別我的二十代

2012-03-12T09:36:04-07:00

這一天總是會來的，有道是「三十而立」，但我每天仍然感覺到如臨深淵、如履薄冰。好多事還來不及在「二十幾歲」去完成，就要跟它告別了，在問卷調查中的年齡就要改填另外一個區間了，想到我就雙腳一軟…..

我已經記不得我九歲的時光了，但是我印象中的十九歲過得不是很好，所以迷信了男生「逢九必衰」的都市傳説，於是乎那一年一心只期盼廿歲趕快到來，好像所有的不幸與不快樂都會在廿歲得到解放。不過由於廿歲時感覺運勢有好轉，所以去年迎接廿九歲時，本來打算謹慎地過每一天，但隨著工作愈來愈忙，我也忘了要在意自己廿九歲的事，只不過這次好像不會特別覺得廿九有什麼很糟的遭遇（也許是幫助我的人太多了），轉眼就來到了卅歲，對！就在沒有意識到狀況下這天就來了。

回顧二十代的這十年間，我從一個迷糊的大學生默默地就成為一個打工仔，中間歷經了很多事，每一件我都歷歷在目，不管是大二夏天的資訊營、大三對 Computer Graphics 的著迷、大四沉迷實況野球（迷到現在）及考研究所﹑碩一的好人助教、碩二的菸酒生及大兵日記、國一的 Java 深度歷險、國二的跟老板拍桌、國三的到處跑社群以及結黨（Taipei GTUG）不營私、國四的「上官老師」以及微軟一年級的洋蔥傳教士….（就算被説很老梗但我還是要説）這些都好像是昨天才發生過的事，那些好像都還是早上才見過的人吶…

在「那一夜我們説相聲」中有一個段子説，記性好的，活得特別痛苦，但想起這些事還是會會心地一笑，那就繼續痛苦吧！

三十代的人生，希望可以一改過去２９年的一事無成，做一些讓自己覺得不枉此生的事，也希望與認識五年、十年、廿年的朋友們再一起往前邁進！再見了，我的二十代人生

微軟一年間

2012-02-29T09:19:17-08:00

不知不覺就到微軟上班一年了，我終於不是菜鳥了嗎？

從開始求學以來，我總是過著「怎樣也想不到我會如此這般」的人生，所以「怎樣也想不到我會到微軟上班」似乎好像也不是那麼不可預期的事，若從過去的經驗來看，「意想不到」的過程或結果都還不錯，所以希望這一段人生也是個不錯的旅程。

不得不說，在這個時間點加入微軟，雖然有點誇張，但我仍然覺得自己是何其榮幸在恭逢一個微軟轉型的時刻，不論從內部、外部甚至是產品來看這間公司都跟過去的印象、想像有很大的不同，一個人在職業生涯中是多難得有這樣的機會能親身見證到一個公司巨大轉變的過程？加入微軟後，除了站在軟體巨人的肩膀上觀看這整個軟體、科技產業令身為軟體人的我何等興奮之外，參與公司的化學反應就是我收穫最多的部份。

常有人會問我：「在這個時間點，推廣某某微軟技術平台不是很辛苦嗎？如果你負責的是某某大家喜愛的平台，會不會更輕鬆愉快？」

而我總是很老梗地用38度金門高樑的廣告回應：

「如果，我們一輩子都只敢挑有把握的事做，那你要怎麼知道，你的能耐會在哪？」

今天公司給我薪水 hire 我來做事，不就是希望藉由我的能力，或是發揮潛力做出貢獻嗎？困難愈多，挫折愈深，你不覺得事情做起來很過癮嗎？雖然不見得靠你一個人就能改變什麼，我要努力的部份還非常多，但比起不用努力就有好的結果要來得有成就感多了，因為那樣的話，你不知道究竟是你有努力有價值，還是只是那個品牌的價值？

過去這一年來，也有不少朋友問我：「你大學、碩士都是唸資科資工，現在不做很純的工程師（咦），會不會很『可惜』？」

這個問題我覺得也很有趣，我一直都認為，大學及碩士班的過程對於自己專業度的提升，並不是用來限制你以後只能做什麼的，人生那麼長，就算只算職業生涯也很長，不必被這四年或六年給限制了你的各種可能性，難道你畢業後出社會工作一點都沒成長嗎？當然我始終還是沒有放棄成為一個偉大工程師的夢想（我不是醬爆），你們怎麼知道我現在的經歷不是我成為偉大工程師的一部份呢？而且我相信我自己，就算再當幾年傳教士，我應該還是可以比很多所謂的「Senior Engineer」有競爭力吧（自我感覺無敵）

這一年間要感謝的微軟人、非微軟人太多了，是因為長官、同事、各位朋友們的支持我才有舞臺的，今年還是要持續努力，不管在什麼樣的技術、平台上，我們要與各位一同努力的部份還很多，大家一起加油吧！

2011 年的回顧

2011-12-30T01:28:24-08:00

2011 年換了新的工作，要做的事、要學的事都變多了，疏於照顧 blog 真是不應該，不過還是可以稍微列一下今年的大事：

1月: 國防役開始的那天（2006/10 關西當兵, 2007/01 種花報到）覺得 2011/1 好久，但也就到了

2月: 在種花的年假已經有14天，正煩惱著怎麼在1、2月且有過年的狀況下放完這14天的年假

3月: 正式加入 Microsoft，我只記得跟著吃我前代目的 farewell 吃到快中風了（他人緣太好！）。很高興弄了 IE9 Hackathon

4月: 飛到 Las Vegas 參加 MIX’11 接受 Microsoft 文化洗禮，當然也見識到 DPE 貴婦團的實力

5月: 飛到 Atlanta 參加 TechEd NorthAmerica 2011，無聊的城市，長途長途的飛行，開始習慣飛行的感覺

6月: 跟著大家一起弄開發者大會，對 Microsoft 而言，除了員工是資產之外，開發者也是重要的資產之一（所以花了很多成本在 MSDN）

7月: 大中華區開年，在成都以熊貓之姿一戰成名，感謝 Herb 的梗以及 Cathy 給的舞臺。月底又飛到丹佛參加 Microsoft Global Exchange，徹底瞭解這間公司文化，並且也瞭解了 DPE 的文化

8月: 為了 Mango SDK, marketplace 即將 launch 而做了很多有形無形的資源準備

9月: 跟辦事最讓人放心的大鈞硬拼完了 TechDays Taiwan 2011，永遠不會忘記我們英勇的 Keynote 戰士們。這個月最重要的還有 Win8 初次亮相

10月: HTC 的芒果機首發，技術支援，開發商交流是免不了的一個月。

11月: MSDN 的芒果開發課程流水席，真的很開心每場都爆滿，開發人員還是對芒果很有信心的，後勢看漲啊！！

12月: 為了上半年檢討，以及下半年的計劃努力著，2012是個令人興奮的一年，開發人員跟著我一起持續燃燒熱血吧！

我的高三國文老師

2011-11-14T23:59:06-08:00

在我高中三年的歲月裡，每一年都是風格完全不同的國文老師，而我最懷念的，是我高三時的國文老師－－蕭平奕老師。

按照我模糊的記憶，我們班級在那一屆台南一中三類組之中，成績並不是前段的班級（當然是扣掉了資優班），升上高三之後，幾乎所有科任老師都與高二時相同，但是國文及英文這兩科卻換了新的老師來帶我們班，其實除了我高一因為當英文小老師以外，三年來我對英文老師的印象一直很薄弱，但是高三時的這位新的國文老師，卻能讓我永遠牢牢地記在心中。

老實說，有時候我們還蠻羨慕有些高一的班級有年輕（看起來像剛畢業）的女國文老師、女英文老師，你知道的，17, 18歲的男生腦袋就是這些有的沒的（難怪書唸不好），這位新來的國文老師，雖然並不是學生們心目中的瑪丹娜（畢竟離大學畢業應該有相當長的時間了），但我覺得老師卻有一股仙女的氣質，因為她身材高挑，走路很端莊，時常面帶微笑，我常常覺得她根本就是用飄地進到我們班的教室。

然而，雖然老師有仙女的氣質，但她並不是來讓我們輕鬆好過的，在南一中，三類組的班級因為有上生物課，所以課表上就沒有「中國文化基本教材」（一類、二類組都有），但老師來的第一天就說，她除了基本的國文課會完整地上完之外，她還會加入中國文化基本教材的內容，而且她每個禮拜都會小考！這對很多三類組的學生來說簡直是苦不堪言，畢竟自然組的學生總覺得應該是花更多時間在數學、物理、化學等科目上面（小孩子不要學），哪有聽說國文課這麼精實的？

就這樣，如精神時光屋般的國文課，進行了三個月後，歷經了一次模擬考及一次段考，我們班的國文成績大幅提升，我印象很深刻，就在第一次段考結束，國文老師來發考卷時，她居然像個小女孩般雀躍地說著：「你們知道嗎？你們是全三年級全班國文平均最高分的喲！平均八十幾（我真的忘了），比資優班還厲害！」這樣的成績，大家當然都很興奮，但我看著喜上眉梢的國文老師，我覺得她比我們還興奮，好像很有成就感似的把整班的頑石都點靈了，這種感覺讓我很振憾，從小喜歡跟老師唱反調的我（參考文章：我的高中導師），居然有愛上這位老師的感覺了！

當然不是只有我一個人愛上（雖然那時沒禁師生戀），我們是全班都愛上了國文老師，平常大家上課都死氣沉沉的，但是國文課時大家就很愛舉手問老師問題，老師在發問時，大家也都很踴躍搶答，這樣歡樂的氣氛，我才發現，雖然老師不是瑪丹娜，但她是瑪莉亞（噢～聖母瑪莉亞）啊！！！我們對國文老師的崇敬、愛慕之情，連其它科任老師都感到吃味了，老是虧我們為什麼只愛唸國文。其實仔細回想，老師那時每次來上課，她都會帶著她幫我們整理好的重點、關聯，而且會教我們怎麼記憶、活用她所提供的「武功秘笈」，我想真正讓大家國文程度提升一個檔次的，除了歡樂的氣氛，就是老師如此這般地用心吧！

我不好意思說我是老師的愛徒（應該也不是），但我還是要很不要臉地回憶地說，老師其實還蠻愛點我起來回答問題的，或許是我總能給老師一個滿意的答案（當然聖母如她，就算答錯也不會怎麼樣），又或者是我有時上課放空時都會被她抓包，這時她就會問我是在思念誰家的女孩兒，直要我拿照片給她看看（謎：老師那時就懂了沒圖沒真相的梗嗎？），我就會回答：「不聞機杼聲，惟聞女嘆息，問女何所思，問女何所憶」來閃避一切。

有時候這種互動的感覺就好像我在學校的媽一樣，高三下學期，我想要透過推薦甄試來進入大學唸書，在過了筆試的關卡之後，我到處跪求老師們幫我寫推薦信，唯獨我的國文老師，在我還沒去找她時，她就已經幫我寫好一份（雖然她寫成交大資工，但我一定要說我第一志願是交大資科）了，我非常感動老師對我這麼好，而且還笑著對我說要加油喔！那時的我應該是整個人都呆愣住了，而且也太ㄍ一ㄣ了，應該要立刻給老師一個大擁抱才對！現在想想，就算是當場跪下作 (worship) 的動作都不誇張。

高中畢業後，我就遠離南部北上唸書，這一離開南部到現在轉眼就過了十一年半了，我居然都沒有再回學校看過老師（因為都寒暑假才返鄉），而現在老師應該也早就退休了（吧），也不知道要如何讓老師知道我的這般心意，只能在這裡把思念的心情記錄下來，

我一直努力沒讓國文程度低落，雖然高中畢業後只有兩次預官考試（一次是大四考、一次是碩二考的）有國文測驗，兩次我都是87.5分（很巧，都剛好錯5題），應該是還算合格吧！雖然年紀大了，忘的東西也變多了，我還記得老師點我起來問了一些問題，而我回答了「三金遊水」、「垂死病中驚坐起，暗風吹雨入寒窗」、「春夜宴桃李園序」、「….」而且我還記得《六國論》蘇家三父子都有寫喔

最後，我只想說：「謝謝妳，國文老師」

P.S. 老師如果還記得我，她記得我的模樣應該是這樣（右一）的吧：

Modernizr 源碼剖析（上）

2011-06-26T20:16:10-07:00

讀 Modernizr 的原始碼除了瞭解它做了什麼事之外，更可以學習到不少 JavaScript 與 DOM scripting 的技巧。

Modernizr 是一個 JavaScript 函式庫，它主要會做兩件事：

偵測瀏覽器對於（廣義的） HTML5 各種規格支援的程度，並且在 <html> 標籤中加入適當的 class 來表現偵測後的結果。舉例來說，若是瀏覽器不支援在 CSS 中使用 border-radius 的語法，那 <html> 標籤中就會有一個 no-borderradius 的 class；而若是支援 CSS 漸層的語法，則會有一個 cssgradients class。
這樣的好處是，網頁開發者可以使用 CSS 來因應各種支援的狀況，像是這段範例程式碼：
```
.box {
   border-bottom: 1px solid #666;
   border-right: 1px solid #777;
}
.boxshadow div.box {
   border: none;
   -webkit-box-shadow: #666 1px 1px 1px;
      -moz-box-shadow: #666 1px 1px 1px;
           box-shadow: #666 1px 1px 1px;
}
```
若瀏覽器尚未支援 CSS 中的 box-shadow 語法，則 Modernizr 會在 <html> 中加入 no-boxshadow 的 class，則整個頁面並不會套用到下方的 CSS rule；反之則下方的 CSS rule 就會生效（因為 <html> 標籤中加入了 boxshadow 的 class。

提供函式或屬性來測試或表示某個 HTML5 的規格是否已經在該瀏覽器下被支援。比方說我要使用 JavaScript 動態插入一個聲音檔案，想要使用 HTML5 的 <audio> 標籤來做，則可以利用 Modernizr 的屬性來測試支援的程度：

/* 測試瀏覽器是否已經支援 <audio> 標籤 */
if (Modernizr.audio) {
  var audio = new Audio();
  audio.src = Modernizr.audio.ogg ? 'music.ogg' : 
              Modernizr.audio.mp3 ? 'music.mp3' : 'music.wav';
  audio.play();
} else {
  /* 使 用 polyfill 來做 fallback, 參考：https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills */
}

由此可知使用 Modernizr 可以省下很多自行偵測瀏覽器能力的程式碼（相信專業的吧）。

雖然 Modernizr 已經幫網頁開發者做了很多事情，不過認真看一下它到底做了哪些事情也是很重要的學習，除了瞭解如何搞定瀏覽器的 feature detect 之外，也可以學習一些 JavaScript 的寫作技巧，以下就以幾個分類來剖析 Modernizr。

定義 API 介面

Modernizr 函式庫提供一個 Modernizr 物件來進行操作（如同上述的範例），而在 Modernizr 的原始碼裡，它是這樣做的：

window.Modernizr = (function( window, document, undefined ) {
  var ...,
  Modernizr = {},

  ...

  return Modernizr;
})(this, this.document);

用一個 anonymous function 產生一個命名空間（namespace）是很常見的技巧，這個 function 最後傳回在裡面宣告的 Modernizr 物件（因為有使用 var 宣告，所以是 local variable），然後將它 assign 到 window.Modernizr 下，這樣在其它的 JavaScript 程式碼中就可以直接使用 window.Modernizr 或是 Modernizr （定義在 window 下的變數可以省略 window）來存取它。

另外，將 window, document 以及 undefined 當作引數（arguments）傳進去的作法也出現在很多函式庫之中，除了可以減少 scope 檢查的時間，也可以避免這些保留字事前被亂改掉了。而這個立即被執行的 function，呼叫時傳入的參數（parameters）是 this 以及 this.document，this 就是這段程式碼被執行時的 context，在瀏覽器預設的狀況下，若是沒有被 function 包住的話，則 this 就相當於 window。至於為什麼不直接帶入 window 以及 window.document，只是為了保持彈性，也許這個函式庫會被應用於其它非瀏覽器的執行環境，那時候 global object 就不一定是 window 了。

如何偵測 CSS 樣式支援

在 Modernizr 中，一開始會建立一個 <modernizr> 的 DOM 物件，然後就利用這個物件下的 style 屬性來測試各種 CSS 2.1/3 樣式的支援程度，初始化的程式碼如下：

    mod = 'modernizr',
    modElem = document.createElement(mod),
    mStyle = modElem.style,

對瀏覽器而言，只要使用 DOM API 來產生一個 DOM 物件，不管瀏覽器是否認得這個標籤，都可以對它使用 CSS 來設定樣式（所以要讓傳統瀏覽器認識 HTML5 的新標籤，這就是一個解決方法），所以就可以拿它的 style 屬性來試試瀏覽器的能耐。而在做完所有的偵測之後，也要加上一段清空的程式碼避免耗費多餘的記憶體（或是 memory leak）：

setCss(''); // 將 mStyle.cssText 整個清空
modElem = inputElem = null;

舉例來說，若要偵測瀏覽器是否支援在 CSS 中使用 hsl/hsla 來表示色彩，那它的檢查流程會是：

先塞一個使用 hsl/hsla 的色彩表示法到 mStyle.cssText 下，例如：mStyle.cssText = 'background-color:hsla(120,40%,100%,.5)';
再檢查 mStyle.backgroundColor 的值，是否含有 hsla 的字串，若瀏覽器不支援的話，在上述直接覆寫 cssText 的動作就會沒有作用，所以 backgroundColor 的值也不會有 hsla 的字串囉。（不過，事實上有些瀏覽器會將 hsla 的表示法轉成 rgba，所以同時也要檢查是否有 rgba 的字串）

這一段的原始碼是這樣寫的：

tests['hsla'] = function() {
    // Same as rgba(), in fact, browsers re-map hsla() to rgba() internally,
    //   except IE9 who retains it as hsla

    setCss('background-color:hsla(120,40%,100%,.5)');

    return contains(mStyle.backgroundColor, 'rgba') || contains(mStyle.backgroundColor, 'hsla');
    };

而如果是有瀏覽器前置詞的 CSS 樣式屬性（如：-webkit-box-shadow），則很簡單會去測試 mStyle 下是否有 boxShadow、WebkitBoxShadow、MozBoxShadow、OBoxShadow、msBoxShadow 或是 KhtmlBoxShadow 屬性，值得注意的是，在 style 屬性下的 DOM 前置詞，只有 IE 的前置詞全是小寫字串。

這段程式碼拆成了幾個 functions 來做，它的流程大致是這樣的：

testPropsAll('boxShadow');

// 切到 testPropsAll 的函式定義
// domPrefixes = 'Webkit Moz O ms Khtml'.split(' ')
function testPropsAll( prop, prefixed ) {

    var ucProp  = prop.charAt(0).toUpperCase() + prop.substr(1),
        props   = (prop + ' ' + domPrefixes.join(ucProp + ' ') + ucProp).split(' ');

    return testProps(props, prefixed);
}

// 再到 testProps 的函式定義
function testProps( props, prefixed ) {
    for ( var i in props ) {
        if ( mStyle[ props[i] ] !== undefined ) {
            return prefixed == 'pfx' ? props[i] : true;
        }
    }
    return false;
}

要檢查一個 CSS 樣式屬性時，直接呼叫 testPropsAll 函式來取得瀏覽器是否支援（最後會得到 true 或 false），而 testPropsAll 函式中會將前置詞拼湊之後，以陣列的形式傳遞至 testProps 函式來檢查，所以在 testProps 函式中就直接以一個 for-each-loop 看看這些屬性（如：WebkitBoxShadow）是否在 mStyle 中有被定義（以 !== undefined 做檢查，以免遇到 falsy value 的問題）。

而 prefixed 引數則是為了 Modernizr.prefiexed 這個 API 所準備的，這部份稍候再做介紹。

偵測 HTML5 標籤能力

HTML5 新增了不少標籤的定義，但是要如何「確切」地知道瀏覽器是不是支援某個標籤呢？以 <canvas> 為例，如果直接使用 document.createElement('canvas'); 來測試，瀏覽器並不會反應出是否有真正支援 canvas 的繪圖能力，所以必須針對標籤的特性再做一些測試，像是：

var elem = document.createElement('canvas');
    return !!(elem.getContext && elem.getContext('2d'));

就可以測試建立出來的 <canvas> 物件是否真的有 getContext 方法可以操作。比較特殊的測試還有：

<video> 的支援測試，Modernizr 作了兩件事：

檢查是不是有 canPlayType 方法
檢查編碼器的支援能力（ogg, h264, webm）

完整的程式碼如下：

    tests['video'] = function() {
        var elem = document.createElement('video'),
            bool = false;
            
        // IE9 Running on Windows Server SKU can cause an exception to be thrown, bug #224
        try {
            if ( bool = !!elem.canPlayType ) {
                bool      = new Boolean(bool);
                bool.ogg  = elem.canPlayType('video/ogg; codecs="theora"');

                // Workaround required for IE9, which doesn't report video support without audio codec specified.
                //   bug 599718 @ msft connect
                var h264 = 'video/mp4; codecs="avc1.42E01E';
                bool.h264 = elem.canPlayType(h264 + '"') || elem.canPlayType(h264 + ', mp4a.40.2"');

                bool.webm = elem.canPlayType('video/webm; codecs="vp8, vorbis"');
            }
            
        } catch(e) { }
        
        return bool;
    };

值得注意的是，這個測試的回傳值是一個 Boolean 物件，為什麼不直接使用 true 或 false 這樣的 literal 呢？因為它可以借用這個物件來放入 ogg、h264 以及 webm 的屬性，這樣單純在使用 Modernizr.video 作為是否支援 <video> 標籤的真值判斷，同時又可以再使用 Modernizr.video.h264 來判斷是否支援 h.264 編碼過的影片。

而類似的 <audio> 也有類似的作法。

SVG 的支援，程式碼很簡單：
```
// ns = {'svg': 'http://www.w3.org/2000/svg'}
return !!document.createElementNS && !!document.createElementNS(ns.svg, 'svg').createSVGRect;
```
除了用 createElementNS 來產生 <svg> 標籤之外，也檢查產生出來的物件是否有 createSVGRect 的方法。

而瀏覽器是否支援 inline SVG 的部份也有點 tricky，簡單地說就是直接塞一個空的 <svg /> 到文件中，然後看看瀏覽器會不會將它展開成標準格式的 SVG：
```
var div = document.createElement('div');
div.innerHTML = '<svg/>';
return (div.firstChild && div.firstChild.namespaceURI) == ns.svg;
```

（下集將介紹 Modernizr 所提供的 API，以及它程式碼寫作的技巧）