文章來源： 寫給年輕的，老闆（三） (轉貼本文僅為好文欣賞並供自我留存，無任何商業利益)
專業經理人的習慣：「尋找邊界」；老闆的習慣：「打破邊界」。
親愛的M,
首先要恭喜你拿到了第一筆投資，你的事業得以繼續發展，我們也覺得很幸運能夠投資這樣專業的團隊，參與到你們的創業過程中。今天白天聊的都是財務數字，晚上吃飯我們就閒聊些有關創業方面的話題吧。我們看過的創業者很多，或許可以給你一些其他方面的建議。
你從大企業離開，出來自行創業也有一年左右的時間了。如何？幫別人打工以及自己當老闆，感覺兩者最大差別在哪？哈哈，以前在大公司裡真安逸對吧？福利好，上下班雖然不一定準時但是假日休閒生活還是有的，拿個大企業的名片出去還是人人尊敬的。
大企業裡的員工，特別是像你一樣的高階管理者，往往會有一種錯覺，覺得自己是菁英中的菁英。的確，大學畢業生爭先到知名企業工作，因此能進入任職的都是精英。但是這些菁英在工作上無往不利，卻是受到了企業品牌的庇蔭，很多人卻錯以為是自己的能力很強。
舉個簡單的例子，我相信你的創業公司在過去一年內，在招募人才上遇到了極大的困難。小公司，前途未卜，給不起好薪水，你能招到什麼好人才？還不就是幾個大學畢業生將就著用，大部分時候是你們幾個創業的夥伴一個人抵兩三人自己動手做？
而當你在大企業工作的時候，你的部門要招募好人才是相對容易的。寫幾張申請表給人事部門，每天就有上百封履歷表送上來讓你挑。而管理這樣精英的團隊以至於你覺得管理真是個輕鬆如意的工作，那可真是很大的錯覺了。
因此，身為一個投資者，我們對於從大企業離職創業的人，感到既愛又怕。一方面我們相信能進入大企業的都是精英，在裡面擔任到高管的更是精英中的菁英，一方面我們又很懷疑，這些人過去在大企業做事情這麼順手，有多少百分比是出自他真正的實力。
朋友告訴我一個故事，一個知名電子商務企業的副總裁被公司開除。因為他自認這間公司能創業成功有很大一部份歸因於他，認為自己是因「功高震主」所以遭此下場。他誓言雪恥，於是自行創辦了一家新的電子商務公司，並宣稱再也不要為別人打工。
故事的結局是這間初創公司虧損連連最後倒閉，這位朋友重新回到職場，在一家二流的網際網路公司擔任專業經理人。我並不想去深究背後是不是有什麼恩怨情仇，只是覺得：「他好像沒有他自己想得這麼厲害」。所以，正確的評價自己的能力是挺重要的事情。
說到能力，我個人特別感覺很多大企業高管的能力，集中在玩弄辦公室政治上面。這種能力要拿來創業公司，那還真是省省吧。此外，除了能力還有習慣與心態。事實上，高階專業經理人具有高度的「尋找邊界」的習慣，而這種習慣恰恰是自己創業當老闆所不需要的。
「這件事情不歸我們部門負責」；「明年度只要能達成 20%增長就已經領先業界」；「這事我們做不了，因為ABCD的困難無法解決」；「同業都是這麼做的，我們不這麼做會有問題」；「上次不是說好這麼做嗎？為什麼又改？」
這就是專業經理人的習慣：尋找安定，尋找明確，尋找依靠，尋找慣例，想著如果別人這麼做自己跟著應該沒問題－這就是「尋找邊界」的習慣。在越大的公司待越久做到越高階的職務，這習慣就越牢固。然而，這卻不是老闆的習慣，老闆的習慣是－「打破邊界」。
「這件事情你們兩個部門都有責任」；「明年度為何只能增長 20%？為何不是200%？」；「這事我們一定要做，ABCD的困難如何解決？」；「為什麼同業都是這麼做我們就得跟著這麼做？」；「誰告訴你上次的決定是不能更改的？你不知道商業環境是動態的嗎？」
你明白這兩種思維邏輯的差異了嗎？專業經理人習慣用城牆把自己圍起來，而成功的創業者／老闆，習慣把城牆打破往外衝，去探索更多的機會跟可能性。企業是在不斷否定過去的自己而成長的，如果這種否定停止了，這間企業創新與突破困局的可能性就很小了。
哈哈，你想起來自己擔任高管的時候如何與老闆相互拉鋸了吧。沒錯，這就是思維的不同，你現在自己當老闆了，應該更能體會這種不同。我們希望你時刻提醒自己，不要讓過去當專業經理人的習慣影響了你創業。你一定要敢想，敢突破，這間公司才有希望。
從這個角度看，或許剛畢業的學生創業，更沒有思維習慣的包袱。他們還沒有在企業裡歷練，還沒養成壞習慣，更敢於突破。然而，學生創業缺少了專業能力，卻也是投資人所不樂見。總之，要能有專業歷練同時不被專業經理人的思維習慣所限制，確實不容易。
沒有能夠保證創業成功的方法，我常說：「運氣是創業成功的必要條件」。每一個成功創業的故事都是不可複製的，說明了他們都具有絕大的偶發性。然而，「打破邊界」的思維習慣能讓你接近成功一些。在此讓我們舉杯，先預祝你們創業成功，乾杯。
（文： 【嘉丰資本】投資合夥人黃紹麟)
2011年5月9日 星期一
好文：寫給年輕的，經理（二）
文章來源： 給年輕的，經理（二） (轉貼本文僅為好文欣賞並供自我留存，無任何商業利益)
管理者最重要的工作不是管別人，而是管自己。
親愛的M,
今天是你升職當部門經理的第一天，你的主管王總監希望我可以跟你簡單的聊一聊，給你一些意見。我已經很久沒有當部門經理，但是到現在還記得第一次有機會當部門經理的時候，我回家問家人的第一個問題是：「媽，部門經理的工作是什麼？」
請別笑得太大聲，哈哈。
其實，工作越久越會發現，主管對自己的影響真的是很大。當我面臨在工作上的問題時，浮現在腦海裡的第一個聲音往往是：「我以前的主管是怎麼處理的？」當然，公司會提供初級的主管培訓，但是這種培訓其實遠不及你的直屬主管對你的影響深遠。
現在帶領一個五六人的部門，你有機會開始常常問自己，以前帶領你的經理，他是怎麼做的？哪些地方讓你覺得他很不錯？哪些地方很討厭？而你可能還沒想過，你現在帶領的部屬以後會拿你當榜樣，你打算留下一個什麼樣的榜樣給他？
管理本身不是件容易的事，我曾經聽過「管理是最讓人挫折的事」這種說法。你可以試著去網路書店，以「如何當主管」為關鍵詞找看看，很多這方面的書。這些書教你的方法，我稱之為「術」，這些當然重要，不過書上很少教你「道」，而「道」才是一切的核心。
「道」，指的是，你是否真正看透了工作的本質，乃至於人生的本質。只有真正看透了這些，你的管理工作才會揮灑自如，所有的「術」信手拈來，不急不徐，部門有績效而部屬與你相處愉快。因為，管理者最重要的工作不是管別人，而是管自己。
管自己？什麼意思？我最常拿來考初級主管的一個問題，就是：「如果你的部門裡面有一個你，你打算怎麼管理他／她？」曾經有個以火爆脾氣聞名的初級主管想了半天，說「如果我的部門裡出現了像我一樣的人，我不知道怎麼管理他」。
說到底，其實就是不知道怎麼管自己。
很妙的是，老天爺通常會安排這樣的部下在你的部門裡出現，考你。你早晚要遇到你自己，因為那就是你的人生課題。一個人會莫名其妙的不喜歡另一個人，通常是因為在他身上發現了自己的缺點。如果你對你的部屬感到不滿意，想一想是不是你自己的問題。
還記得自己當了部門經理沒多久，老是抱怨著自己的部屬能力不行。其實，這種抱怨在初級主管中普遍存在。大部分初級主管都是因為專業能力受肯定所以才晉升，部屬能力不如你乃理所當然，不需抱怨。換個角度想，招聘一個專業能力跟你一樣強的人來當部屬，你敢不敢？
嘖嘖，看你笑得尷尬，我知道你不敢。這不怪你，因為大部分人都不敢（不敢又抱怨，嘖）。事實上，主管與部屬間的關係不是領導，而是配合。部屬發揮專業，而你的工作轉而變成溝通。你們的工作關係是平等的，各自扮演好該扮演的角色而已，你一定要看透這點。
我們對初階主管的考評已非純粹專業能力，而是偏向溝通能力。我們不要你把隊員的槍搶過來自己射擊，而是要你把作戰命令聽懂，化成小隊隊形讓隊員就定位發揮火力。你現在是隊長，請從神槍手的位置上退下來，請去找另一個神槍手來，請把小隊其他人也訓練成神槍手。
此外，跨部門溝通也變成你的工作重心。要謹記，你的溝通不可以讓部門間產生對立情緒，甚至如果你發現了這種對立情緒時還需要主動去消除。你不可以關起門來在部門成員間去說另一個部門的不是，如果你真的不滿，你應該直接跟那個部門的主管溝通。
溝通是不可以帶著情緒的，帶著情緒的溝通一定不是好的溝通。
切記不要發脾氣不要跟別人吵架，特別是當你認為自己很專業而從這樣的基礎出發去跟別人爭執時。工作以來我跟人吵架的次數很多，每一次發脾氣的結果總是後悔。倒不是說爭執容易得罪人（雖然實際上也是），而是覺得自己當時面貌怎麼如此猙獰，我不喜歡那樣的自己。
此外，正常情況下你不會在一家公司待上一輩子。幾年以後通常你會發現一旦離開了那個地方，當時的爭執好像一點也不重要了。人生的路很長，該展現你專業堅持的地方要展現，但絕對不要因為一間你最多待上三年五年的公司而對人發脾氣，太不值得了。
初級主管最容易遇到的問題還有一個：來自中央的命令與第一線的戰況有差異。有時候我們會很疑惑，有時候會很擔憂，有時候憤憤不平，認為公司正在往錯誤的方向上前進。我們以公司的存亡為己任，我們覺得老闆昏庸無能，我們想挽救。
站在你的專業角度，這個時候能做的事情是：忠實的反應第一線戰況，謹慎的做出建議。建議能否被採納，除了看你的溝通能力外，最終是看老闆的命。別笑，在我的工作生涯中有兩個總結：第一，企業要成功，主要看老闆的命；第二，運氣是創業成功的必要條件。
永遠要了解一件事情：出資的老闆他的風險比你大得多，如果錢不是他出的而是他找人投資的，那他也是冒著信用破產的風險，所以他理論上比你更在意這間公司的死活。你現在還只是個初級主管，不用分擔太多老闆的煩惱，等你變成高階主管時，想跑還跑不掉的。
所以，好好享受你剛得到的初級主管生涯，放輕鬆，放輕鬆。讓你的同事感覺到你升官前跟升官後相比一樣沒有官架子，著重在把工作完成而非大權在握就隨意支使，要了解到你在這間公司最多待上三五年所以所有人都是你的朋友，這樣你就成功了。祝福你啦。
（文： 【嘉丰資本】投資合夥人黃紹麟)
管理者最重要的工作不是管別人，而是管自己。
親愛的M,
今天是你升職當部門經理的第一天，你的主管王總監希望我可以跟你簡單的聊一聊，給你一些意見。我已經很久沒有當部門經理，但是到現在還記得第一次有機會當部門經理的時候，我回家問家人的第一個問題是：「媽，部門經理的工作是什麼？」
請別笑得太大聲，哈哈。
其實，工作越久越會發現，主管對自己的影響真的是很大。當我面臨在工作上的問題時，浮現在腦海裡的第一個聲音往往是：「我以前的主管是怎麼處理的？」當然，公司會提供初級的主管培訓，但是這種培訓其實遠不及你的直屬主管對你的影響深遠。
現在帶領一個五六人的部門，你有機會開始常常問自己，以前帶領你的經理，他是怎麼做的？哪些地方讓你覺得他很不錯？哪些地方很討厭？而你可能還沒想過，你現在帶領的部屬以後會拿你當榜樣，你打算留下一個什麼樣的榜樣給他？
管理本身不是件容易的事，我曾經聽過「管理是最讓人挫折的事」這種說法。你可以試著去網路書店，以「如何當主管」為關鍵詞找看看，很多這方面的書。這些書教你的方法，我稱之為「術」，這些當然重要，不過書上很少教你「道」，而「道」才是一切的核心。
「道」，指的是，你是否真正看透了工作的本質，乃至於人生的本質。只有真正看透了這些，你的管理工作才會揮灑自如，所有的「術」信手拈來，不急不徐，部門有績效而部屬與你相處愉快。因為，管理者最重要的工作不是管別人，而是管自己。
管自己？什麼意思？我最常拿來考初級主管的一個問題，就是：「如果你的部門裡面有一個你，你打算怎麼管理他／她？」曾經有個以火爆脾氣聞名的初級主管想了半天，說「如果我的部門裡出現了像我一樣的人，我不知道怎麼管理他」。
說到底，其實就是不知道怎麼管自己。
很妙的是，老天爺通常會安排這樣的部下在你的部門裡出現，考你。你早晚要遇到你自己，因為那就是你的人生課題。一個人會莫名其妙的不喜歡另一個人，通常是因為在他身上發現了自己的缺點。如果你對你的部屬感到不滿意，想一想是不是你自己的問題。
還記得自己當了部門經理沒多久，老是抱怨著自己的部屬能力不行。其實，這種抱怨在初級主管中普遍存在。大部分初級主管都是因為專業能力受肯定所以才晉升，部屬能力不如你乃理所當然，不需抱怨。換個角度想，招聘一個專業能力跟你一樣強的人來當部屬，你敢不敢？
嘖嘖，看你笑得尷尬，我知道你不敢。這不怪你，因為大部分人都不敢（不敢又抱怨，嘖）。事實上，主管與部屬間的關係不是領導，而是配合。部屬發揮專業，而你的工作轉而變成溝通。你們的工作關係是平等的，各自扮演好該扮演的角色而已，你一定要看透這點。
我們對初階主管的考評已非純粹專業能力，而是偏向溝通能力。我們不要你把隊員的槍搶過來自己射擊，而是要你把作戰命令聽懂，化成小隊隊形讓隊員就定位發揮火力。你現在是隊長，請從神槍手的位置上退下來，請去找另一個神槍手來，請把小隊其他人也訓練成神槍手。
此外，跨部門溝通也變成你的工作重心。要謹記，你的溝通不可以讓部門間產生對立情緒，甚至如果你發現了這種對立情緒時還需要主動去消除。你不可以關起門來在部門成員間去說另一個部門的不是，如果你真的不滿，你應該直接跟那個部門的主管溝通。
溝通是不可以帶著情緒的，帶著情緒的溝通一定不是好的溝通。
切記不要發脾氣不要跟別人吵架，特別是當你認為自己很專業而從這樣的基礎出發去跟別人爭執時。工作以來我跟人吵架的次數很多，每一次發脾氣的結果總是後悔。倒不是說爭執容易得罪人（雖然實際上也是），而是覺得自己當時面貌怎麼如此猙獰，我不喜歡那樣的自己。
此外，正常情況下你不會在一家公司待上一輩子。幾年以後通常你會發現一旦離開了那個地方，當時的爭執好像一點也不重要了。人生的路很長，該展現你專業堅持的地方要展現，但絕對不要因為一間你最多待上三年五年的公司而對人發脾氣，太不值得了。
初級主管最容易遇到的問題還有一個：來自中央的命令與第一線的戰況有差異。有時候我們會很疑惑，有時候會很擔憂，有時候憤憤不平，認為公司正在往錯誤的方向上前進。我們以公司的存亡為己任，我們覺得老闆昏庸無能，我們想挽救。
站在你的專業角度，這個時候能做的事情是：忠實的反應第一線戰況，謹慎的做出建議。建議能否被採納，除了看你的溝通能力外，最終是看老闆的命。別笑，在我的工作生涯中有兩個總結：第一，企業要成功，主要看老闆的命；第二，運氣是創業成功的必要條件。
永遠要了解一件事情：出資的老闆他的風險比你大得多，如果錢不是他出的而是他找人投資的，那他也是冒著信用破產的風險，所以他理論上比你更在意這間公司的死活。你現在還只是個初級主管，不用分擔太多老闆的煩惱，等你變成高階主管時，想跑還跑不掉的。
所以，好好享受你剛得到的初級主管生涯，放輕鬆，放輕鬆。讓你的同事感覺到你升官前跟升官後相比一樣沒有官架子，著重在把工作完成而非大權在握就隨意支使，要了解到你在這間公司最多待上三五年所以所有人都是你的朋友，這樣你就成功了。祝福你啦。
（文： 【嘉丰資本】投資合夥人黃紹麟)
好文：寫給年輕的，自己（一）
文章來源： 寫給年輕的，自己（一） (轉貼本文僅為好文欣賞並供自我留存，無任何商業利益)
你拒絕一個工作機會的原因，只能是一個：「那不是我」；而你接受一個工作也同樣的只能有一個原因：「那是我」。
親愛的M,
你父親希望你來找我聊聊，對你在未來的工作選擇上做些指導。這個任務讓我有點惶恐，畢竟每個人的人生道路與選擇都是不同的，沒有誰能替誰做決定。或許，我就簡單的說說自己，以及談談做決定的時候，應該掌握哪些原則吧。
1994年的時候，我還是大學三年級學生。在考大學時只知道選擇跟「電子」與「機械」有關的科系，不小心考上電機系。除了發現原來電子跟機械根本是兩種不同學問外，還拋棄學業把時間花在鑽研電腦，三年後卻告訴自己「我不要當工程師」，並幻想當廣告影片導演。
這真是一個糊塗年輕人對於自己未來的胡亂決定。然而，儘管還是不知道未來在哪，大學三年級時我對人生路途的感覺突然變得清晰起來。當時我在一個本子上寫下幾個對自己的看法，這些看法在我沒有意識到的情況下，完全出現在後來12年的工作生涯中：
- 我要當先知，要走在全世界的最前面，要把所看到的告訴世人。
- 我要過著到處演講與寫作的生活，那樣的生活一定很棒。
- 我不會很有錢，但是會一直有人出錢給我玩最新的科技。
- 我覺得自己不適合當領導者，但很適合當領導者的左右手或幕僚。
- 我要當技術人員與行銷人員之間的橋梁，因為我兩者皆懂。
在後來的工作中我一直都能走在時代的尖端，從網際網路到3G一直到 Web 2.0 ，我在從事這些創新領域的工作時，基本上都還沒什麼人做。我也很滿意自己經常有機會去演講，每周都有一篇文章發表並堅持 10多年。曾經有讀者來信說，我的文章啟蒙並影響了一代人。
你能如此清晰的寫下對自己的看法以及對未來的想像嗎？要能清楚說明你「是」什麼，如果沒法說清，那至少要能說明你「不是」什麼，這或許容易得多。不，不要一下子就跳到說自己想做什麼或不想做甚麼工作。你一定要先弄清楚，「自己」是什麼，而非「工作」是什麼。
在你真正弄清楚你自己內心深處的意思之前，你腦袋裡的聲音很多是家長以及社會給你的聲音，那些聲音並不是真正的你。我常看到很多孩子屈從父母的安排選擇了自己不喜歡念的學校或科系，而選擇的理由不外乎那些熱門科系將來容易賺錢有成就。
而實際的情況是，你要做自己喜歡的事情才會有成就。這一點，絕大部分的人都沒弄明白。這裡的喜歡，是必須喜歡到狂熱的程度才行。如果只是偶一為之，「好像還蠻有興趣的」，恐怕是不夠的。例如，我在自己的網站上曾經寫下過這樣的兩句話：
- 我要不斷的寫，直到我寫不動為止；寫作是我的終生事業。
- 當我站上演講台的時候，我是無敵的。
「了解你自己」，這句古希臘的哲人所說的話，正是你在做任何選擇的唯一關鍵。一個不瞭解自己的人，做不出正確的選擇。你一定要發掘自己的內心深處，找出那個能讓你小宇宙完全爆發的事情出來。你喜歡，你就做得好，你做得好，你就容易有成就。
辦公室裡有同事喜歡唱歌，曾參加過全國歌唱比賽並在地區拿到排名。我問他，你來上班幹甚麼？怎不去當歌手？是什麼事把你困住了？他說了很多理由，說要進演藝圈有種種困難。然而，他最終告訴我他弄明白了，他其實沒那麼愛。如果真的熱愛，那些困難全部不成理由。
真正熱愛唱歌的人，我想你看過的。Michael Jackson ，一個站上舞台就呈現無敵狀態的人，演藝事業是他的生命，是他的終生事業。哦我忘了，他不是你們這個年代的人熟悉的偶像。不過無妨，我會建議你去看最近一部有關他的電影，「This is it. 」。
大部分的人在看這部電影的時候，都會因為看到MJ對演藝事業的堅持而肅然起敬。然而，大部分人認為那是「他」（一個巨星）而不是「我」。然而這絕對是錯誤的。事實上每個人都有自己熱愛的事，在這些事情上面都能成為巨星，關鍵是找到自己的天命了沒。
台北淡水有個賣鹽水雞的小攤販，顧客總是大排長龍。老闆每次把鹽水雞跟調料混合放在鐵盒子後，就兩手抓著盒子使勁搖晃，務求充分混合調料。我曾看他搖那個盒子看到傻了，態度無比慎重，運用全身力氣，恭敬交付顧客。。。那是他全力以赴的一包鹽水雞。
大排長龍的顧客說明了人們多麼喜愛他的全力以赴，在那個小攤子上這個老闆是無敵的。這種在各個角落裡發光發熱的人很多，不論事情大小。大陸的相聲演員郭德綱，在成名前曾經經歷過台下只有幾個聽眾的表演。是什麼事情讓他能耐得住這種寂寞？除了熱情，沒有別的。
在社會上，有名以及有錢都被認為是一種成就。這當然是好事，但是這兩件事情被認知的次序有點顛倒。實際情況是，名與利都是你把自己熱愛的事情做好了之後的副產品，因此，有錢與有名乃是不可避免的，他們是結果，不是目的。
尋找自己，是一個終生的課題。那是老天爺給你的天命，你必須傾聽自己內心的聲音才能找出答案。你拒絕一個工作機會的原因，只能是一個：「那不是我」；而你接受一個工作也同樣的只能有一個原因：「那是我」。其他的事情，都是很次要的考量了。
你能試著按照我前面舉的例子，寫下一些對你自己的看法嗎？例如：什麼是你的終生事業，你在做什麼的時候會像上癮一樣不可自拔，進入無敵狀態（哈哈，這可不是網路遊戲），你想成為什麼人，而你覺得那樣子一定很棒。希望做這些練習，對你做決定的時候有幫助。 （文： 【嘉丰資本】投資合夥人黃紹麟)
你拒絕一個工作機會的原因，只能是一個：「那不是我」；而你接受一個工作也同樣的只能有一個原因：「那是我」。
親愛的M,
你父親希望你來找我聊聊，對你在未來的工作選擇上做些指導。這個任務讓我有點惶恐，畢竟每個人的人生道路與選擇都是不同的，沒有誰能替誰做決定。或許，我就簡單的說說自己，以及談談做決定的時候，應該掌握哪些原則吧。
1994年的時候，我還是大學三年級學生。在考大學時只知道選擇跟「電子」與「機械」有關的科系，不小心考上電機系。除了發現原來電子跟機械根本是兩種不同學問外，還拋棄學業把時間花在鑽研電腦，三年後卻告訴自己「我不要當工程師」，並幻想當廣告影片導演。
這真是一個糊塗年輕人對於自己未來的胡亂決定。然而，儘管還是不知道未來在哪，大學三年級時我對人生路途的感覺突然變得清晰起來。當時我在一個本子上寫下幾個對自己的看法，這些看法在我沒有意識到的情況下，完全出現在後來12年的工作生涯中：
- 我要當先知，要走在全世界的最前面，要把所看到的告訴世人。
- 我要過著到處演講與寫作的生活，那樣的生活一定很棒。
- 我不會很有錢，但是會一直有人出錢給我玩最新的科技。
- 我覺得自己不適合當領導者，但很適合當領導者的左右手或幕僚。
- 我要當技術人員與行銷人員之間的橋梁，因為我兩者皆懂。
在後來的工作中我一直都能走在時代的尖端，從網際網路到3G一直到 Web 2.0 ，我在從事這些創新領域的工作時，基本上都還沒什麼人做。我也很滿意自己經常有機會去演講，每周都有一篇文章發表並堅持 10多年。曾經有讀者來信說，我的文章啟蒙並影響了一代人。
你能如此清晰的寫下對自己的看法以及對未來的想像嗎？要能清楚說明你「是」什麼，如果沒法說清，那至少要能說明你「不是」什麼，這或許容易得多。不，不要一下子就跳到說自己想做什麼或不想做甚麼工作。你一定要先弄清楚，「自己」是什麼，而非「工作」是什麼。
在你真正弄清楚你自己內心深處的意思之前，你腦袋裡的聲音很多是家長以及社會給你的聲音，那些聲音並不是真正的你。我常看到很多孩子屈從父母的安排選擇了自己不喜歡念的學校或科系，而選擇的理由不外乎那些熱門科系將來容易賺錢有成就。
而實際的情況是，你要做自己喜歡的事情才會有成就。這一點，絕大部分的人都沒弄明白。這裡的喜歡，是必須喜歡到狂熱的程度才行。如果只是偶一為之，「好像還蠻有興趣的」，恐怕是不夠的。例如，我在自己的網站上曾經寫下過這樣的兩句話：
- 我要不斷的寫，直到我寫不動為止；寫作是我的終生事業。
- 當我站上演講台的時候，我是無敵的。
「了解你自己」，這句古希臘的哲人所說的話，正是你在做任何選擇的唯一關鍵。一個不瞭解自己的人，做不出正確的選擇。你一定要發掘自己的內心深處，找出那個能讓你小宇宙完全爆發的事情出來。你喜歡，你就做得好，你做得好，你就容易有成就。
辦公室裡有同事喜歡唱歌，曾參加過全國歌唱比賽並在地區拿到排名。我問他，你來上班幹甚麼？怎不去當歌手？是什麼事把你困住了？他說了很多理由，說要進演藝圈有種種困難。然而，他最終告訴我他弄明白了，他其實沒那麼愛。如果真的熱愛，那些困難全部不成理由。
真正熱愛唱歌的人，我想你看過的。Michael Jackson ，一個站上舞台就呈現無敵狀態的人，演藝事業是他的生命，是他的終生事業。哦我忘了，他不是你們這個年代的人熟悉的偶像。不過無妨，我會建議你去看最近一部有關他的電影，「This is it. 」。
大部分的人在看這部電影的時候，都會因為看到MJ對演藝事業的堅持而肅然起敬。然而，大部分人認為那是「他」（一個巨星）而不是「我」。然而這絕對是錯誤的。事實上每個人都有自己熱愛的事，在這些事情上面都能成為巨星，關鍵是找到自己的天命了沒。
台北淡水有個賣鹽水雞的小攤販，顧客總是大排長龍。老闆每次把鹽水雞跟調料混合放在鐵盒子後，就兩手抓著盒子使勁搖晃，務求充分混合調料。我曾看他搖那個盒子看到傻了，態度無比慎重，運用全身力氣，恭敬交付顧客。。。那是他全力以赴的一包鹽水雞。
大排長龍的顧客說明了人們多麼喜愛他的全力以赴，在那個小攤子上這個老闆是無敵的。這種在各個角落裡發光發熱的人很多，不論事情大小。大陸的相聲演員郭德綱，在成名前曾經經歷過台下只有幾個聽眾的表演。是什麼事情讓他能耐得住這種寂寞？除了熱情，沒有別的。
在社會上，有名以及有錢都被認為是一種成就。這當然是好事，但是這兩件事情被認知的次序有點顛倒。實際情況是，名與利都是你把自己熱愛的事情做好了之後的副產品，因此，有錢與有名乃是不可避免的，他們是結果，不是目的。
尋找自己，是一個終生的課題。那是老天爺給你的天命，你必須傾聽自己內心的聲音才能找出答案。你拒絕一個工作機會的原因，只能是一個：「那不是我」；而你接受一個工作也同樣的只能有一個原因：「那是我」。其他的事情，都是很次要的考量了。
你能試著按照我前面舉的例子，寫下一些對你自己的看法嗎？例如：什麼是你的終生事業，你在做什麼的時候會像上癮一樣不可自拔，進入無敵狀態（哈哈，這可不是網路遊戲），你想成為什麼人，而你覺得那樣子一定很棒。希望做這些練習，對你做決定的時候有幫助。 （文： 【嘉丰資本】投資合夥人黃紹麟)
2011年3月19日 星期六
2010年9月23日 星期四
幫助思考的好工具－心智圖法～XMind工具軟體
近日被要求要針對一份執行計畫作較細化的列示，之前已想辦法用Project配合Excel提供作業規劃了，要再細化？！嗯~~我想，對於主管，恐怕得用別的方式展示計畫，目標是易於在第一眼就表達相關作業的規劃緣由與關係。突然想到之前曾稍稍碰過的Mind manager tool，因為之前根本沒好好思考過它，更別提能夠體會其價值；試著下載XMind這套工具，它還有臺灣代理，相關資源與參考資料整理得似乎不錯，花了不到1hr邊使用邊畫出我的第一個心智圖，漸漸體會它對思考、釐清相關想發、思維方面有其妙的助益，看來是值得我花點心思study。
1970年代，英國人東尼‧博贊 (Tony Buzan) 為了提昇思考能力，想出了一種利用圖形來輔助思考的方法，他提出的這個輔助工具就是『心智圖』。
比起單純的使用文字，利用圖形輔助思考有時更加直覺。心智圖可以利用不同顏色的線條及各式各樣的圖案加深整體印象。也有人說，因為心智圖是一種圖像，我們要辨識心智圖時會用到平常較少使用的右腦，等於是在平常使用的左腦之外再加上右腦的輔助，所以對於記憶有莫大的幫助。
找到一些網上先進們文章、網站：
以 XMind 心智圖整理重點並匯至 Word 運用 、█大麋鹿走地圖█▇▅▂ 、克明大大的鮮思維－採購了 XMind Pro (2年三組授權) 心智圖軟件 。
1970年代，英國人東尼‧博贊 (Tony Buzan) 為了提昇思考能力，想出了一種利用圖形來輔助思考的方法，他提出的這個輔助工具就是『心智圖』。
比起單純的使用文字，利用圖形輔助思考有時更加直覺。心智圖可以利用不同顏色的線條及各式各樣的圖案加深整體印象。也有人說，因為心智圖是一種圖像，我們要辨識心智圖時會用到平常較少使用的右腦，等於是在平常使用的左腦之外再加上右腦的輔助，所以對於記憶有莫大的幫助。
找到一些網上先進們文章、網站：
以 XMind 心智圖整理重點並匯至 Word 運用 、█大麋鹿走地圖█▇▅▂ 、克明大大的鮮思維－採購了 XMind Pro (2年三組授權) 心智圖軟件 。
2010年9月12日 星期日
可快速Note所見文章、網誌
新建了我的 tumblr http://dayder.tumblr.com/
話說~~ Blogger為何沒有這功能，配合在 IE上新加按鈕~超讚
(以下內容原文參 http://ifrs-1.blogspot.com/2010/07/tumblr.html )
Tumblr是什麼呢？嗯！是很懶的部落格專門用來隨時筆記使用的～
首先，當然是先進Tumblr，註冊，然後自定一個URL；接著，這網站會要求你先貼個什麼東西<--這個「什麼東西」就是先上傳你的大頭貼啦～
進Appearance去上傳吧！但是你當然不用呆呆的就真的上傳自己的照片，網民當久了，應該知道上傳什麼東東比較恰當吧！ @@
接著，進到Goodies，看到一個叫Share on Tumblr的Icon，不用客氣，就直接用滑鼠按著那個按鈕，拖到瀏覽器上面隨便一個顯眼的地方，接著，大功告成！
到任一個blog，你只要看了喜歡，就可以在法律規定的範圍內將那段文字或圖片或影片選取後，去點剛才前面提到的，你已拖到瀏覽器上方的Share on Tumblr，然後，你還可以加個註解或感想之類的，接著，這些你選取的內容自己就會到你的Tumblr區塊了！
話說~~ Blogger為何沒有這功能，配合在 IE上新加按鈕~超讚
(以下內容原文參 http://ifrs-1.blogspot.com/2010/07/tumblr.html )
Tumblr是什麼呢？嗯！是很懶的部落格專門用來隨時筆記使用的～
首先，當然是先進Tumblr，註冊，然後自定一個URL；接著，這網站會要求你先貼個什麼東西<--這個「什麼東西」就是先上傳你的大頭貼啦～
進Appearance去上傳吧！但是你當然不用呆呆的就真的上傳自己的照片，網民當久了，應該知道上傳什麼東東比較恰當吧！ @@
接著，進到Goodies，看到一個叫Share on Tumblr的Icon，不用客氣，就直接用滑鼠按著那個按鈕，拖到瀏覽器上面隨便一個顯眼的地方，接著，大功告成！
到任一個blog，你只要看了喜歡，就可以在法律規定的範圍內將那段文字或圖片或影片選取後，去點剛才前面提到的，你已拖到瀏覽器上方的Share on Tumblr，然後，你還可以加個註解或感想之類的，接著，這些你選取的內容自己就會到你的Tumblr區塊了！
2010年8月18日 星期三
PowerPoint Template
做報告都少不了PowerPoint這套簡報軟體，雖然它本身有內建一些簡報的背景範本，但樣式不多，很容易與其他同學或同事用到一樣的ppt簡報背景，找了幾個不錯的PowerPoint 背景免費下載站：
1. http://office.microsoft.com/en-us/templates/CT101172721033.aspx
2. http://www.brainybetty.com/
3. http://www.presentationhelper.co.uk/free_powerpoint_template.htm
4. http://www.presentationpoint.com/powerpoint-templates/index.htm
5. http://inzones.com/free-templates.htm
6. http://www.indezine.com/powerpoint/templates/freetemplates.html
7. http://www.presentersresource.com/
8. http://jc-schools.net/tutorials/PPT-games/
9. http://www.mastertemplates.com/powerpoint-templates.htm
10. http://www.ebibleteacher.com/backgrnd.html
11. http://www.templateswise.com/
12. http://www.freeppttemplates.com/
1. http://office.microsoft.com/en-us/templates/CT101172721033.aspx
2. http://www.brainybetty.com/
3. http://www.presentationhelper.co.uk/free_powerpoint_template.htm
4. http://www.presentationpoint.com/powerpoint-templates/index.htm
5. http://inzones.com/free-templates.htm
6. http://www.indezine.com/powerpoint/templates/freetemplates.html
7. http://www.presentersresource.com/
8. http://jc-schools.net/tutorials/PPT-games/
9. http://www.mastertemplates.com/powerpoint-templates.htm
10. http://www.ebibleteacher.com/backgrnd.html
11. http://www.templateswise.com/
12. http://www.freeppttemplates.com/
2010年7月29日 星期四
CANON 對焦系統
對焦sensor是兩兩成對 也就說兩個senser組成一個對焦單元
sensor排列方式有水平 有垂直排列
水平排列的sensor 對物體是垂直線最敏感 對物體是水平線會無法對焦
同理 垂直排列的sensor 對物體是水平線最敏感 對物體是垂直線會無法對焦
十字型就是有兩對(4個) sensor 分別是水平排列及垂直排列 所以不管物體是水平線 或垂直線都會有相對應的對焦sensor可以感應對焦 對焦成功機率相對提高
對焦精度不同於以上的概念 canon 對於對焦精度區分成兩種
一種是一般精度 另一種是高精度
一般精度 :只要主體影像落在景深內就算對焦完成
高精度:需要落在1/3 景深內才算對焦成功
所以高精準度的那一對sensor 與一般精準度的sensor不一樣 ,需要更多的光線才能發揮作用, 這需鏡頭支援, 也就是需要大光圈的鏡頭, 需要F2.8以上(含),例如 24-70mm F2.8,135mm F2.0 ,50mm F1.4 , 85mm F1.2
一般精準度sensor 對焦時對光量需求沒有那麼高 所以F5.6以上的鏡頭都可以對焦,幾乎所有原廠鏡頭都包含
如果最大光圈是 F8的鏡頭會發生什麼事 ? 有可能無法自動對焦 這種情形只好改為手動對焦 以上報告
註:對焦時鏡頭光圈都是全開的 直到按下快門時才會縮到設定的光圈
強者解說請參考
那我的20D~~~看來都是一字的吧(淚)~~
sensor排列方式有水平 有垂直排列
水平排列的sensor 對物體是垂直線最敏感 對物體是水平線會無法對焦
同理 垂直排列的sensor 對物體是水平線最敏感 對物體是垂直線會無法對焦
十字型就是有兩對(4個) sensor 分別是水平排列及垂直排列 所以不管物體是水平線 或垂直線都會有相對應的對焦sensor可以感應對焦 對焦成功機率相對提高
對焦精度不同於以上的概念 canon 對於對焦精度區分成兩種
一種是一般精度 另一種是高精度
一般精度 :只要主體影像落在景深內就算對焦完成
高精度:需要落在1/3 景深內才算對焦成功
所以高精準度的那一對sensor 與一般精準度的sensor不一樣 ,需要更多的光線才能發揮作用, 這需鏡頭支援, 也就是需要大光圈的鏡頭, 需要F2.8以上(含),例如 24-70mm F2.8,135mm F2.0 ,50mm F1.4 , 85mm F1.2
一般精準度sensor 對焦時對光量需求沒有那麼高 所以F5.6以上的鏡頭都可以對焦,幾乎所有原廠鏡頭都包含
如果最大光圈是 F8的鏡頭會發生什麼事 ? 有可能無法自動對焦 這種情形只好改為手動對焦 以上報告
註:對焦時鏡頭光圈都是全開的 直到按下快門時才會縮到設定的光圈
強者解說請參考
那我的20D~~~看來都是一字的吧(淚)~~
2010年7月16日 星期五
我在盯者你~ YN-468閃燈
跟Allen兄商借神燈580EX，自此終於了解：好鏡可以緩緩，閃燈不能不敗的道理。
近來M01火紅的永諾YN閃燈，參考文章：
[分享]超平(便宜)燈 永諾YN-460
閃光指數直逼原廠神燈--超值外閃 永諾YN-460 II
[開箱]便宜手動閃燈 永諾YN-460 II
永諾Yongnuo YN467 PK 原廠神燈Canon 550EX
YN-468 永諾閃燈開箱
嗯～$2950連三位小朋友都不用的價錢，可以弄一之回來玩玩了。
永諾閃燈比較如下：
好用、取代檔案總管免費、免安裝工具：MDIE
免費好用又不用安裝~ 想不到為何不裝來用用~~~
原文請參 http://playpcesor.blogspot.com/2007/06/mdie.html
下載網址 http://www.badongo.com/file/8273387
試了一下，馬上幫我舒緩工具列爆炸的情況，
原本每每都得維持開啟 4~5個以上的檔案總管數量。
右鍵拖曳可直接上層、下層目錄，可上一頁、下一頁~~有驚豔到！
(這些M$都沒想到？)
原文請參 http://playpcesor.blogspot.com/2007/06/mdie.html
下載網址 http://www.badongo.com/file/8273387
試了一下，馬上幫我舒緩工具列爆炸的情況，
原本每每都得維持開啟 4~5個以上的檔案總管數量。
右鍵拖曳可直接上層、下層目錄，可上一頁、下一頁~~有驚豔到！
(這些M$都沒想到？)
2010年7月15日 星期四
調校SQL效能
好久沒搞SQL資料庫了，這篇文章蠻受用，為免消失，轉載於此。
(原文轉載自 http://www.wretch.cc/blog/hcu16b/10264132 )
有些程式員在撰寫前端的應用程式時，會透過各種 OOP 語言將存取資料庫的 SQL 陳述式串接起來，卻忽略了 SQL 語法的效能問題。版工曾聽過某半導體大廠的新進程式員，所兜出來的一段 PL/SQL 跑了好幾分鐘還跑不完；想當然爾，即使他前端的 AJAX 用得再漂亮，程式效能頂多也只是差強人意而已。以下是版工整理出的一些簡單心得，讓長年鑽究 ASP.NET / JSP / AJAX 等前端應用程式，卻無暇研究 SQL 語法的程式員，避免踩到一些 SQL 的效能地雷。
1、資料庫設計與規劃
‧ Primary Key 欄位的長度儘量小，能用 small integer 就不要用 integer。例如員工資料表，若能用員工編號當主鍵，就不要用身分證字號。
‧ 一般欄位亦同。若該資料表要存放的資料不會超過 3 萬筆，用 small integer 即可，不必用 integer。
‧ 文字資料欄位若長度固定，如：身分證字號，就不要用 varchar 或 nvarchar，應該用 char 或 nchar。
‧ 文字資料欄位若長度不固定，如：地址，則應該用 varchar 或 nvarchar。除了可節省儲存空間外，存取磁碟時也會較有效率。
‧ 設計欄位時，若其值可有可無，最好也給一個預設值，並設成「不允許 NULL」(一般欄位預設為「允許 NULL」)。因為 SQL Server 在存放和查詢有 NULL 的資料表時，會花費額外的運算動作 [2]。
‧ 若一個資料表的欄位過多，應垂直切割成兩個以上的資料表，並用同名的 Primary Key 一對多連結起來，如：Northwind 的 Orders、Order Details 資料表。以避免在存取資料時，以叢集索引掃描時會載入過多的資料，或修改資料時造成互相鎖定或鎖定過久。
------------------------------
2、適當地建立索引
‧ 記得自行幫 Foreign Key 欄位建立索引，即使是很少被 JOIN 的資料表亦然。
‧ 替常被查詢或排序的欄位建立索引，如：常被當作 WHERE 子句條件的欄位。
‧ 用來建立索引的欄位，長度不宜過長，不要用超過 20 個位元組的欄位，如：地址。
‧ 不要替內容重複性高的欄位建立索引，如：性別；反之，若重複性低的欄位則適合建立索引，如：姓名。
‧ 不要替使用率低的欄位建立索引。
‧ 不宜替過多欄位建立索引，否則反而會影響到新增、修改、刪除的效能，尤其是以線上交易 (OLTP) 為主的網站資料庫。
‧ 若資料表存放的資料很少，就不必刻意建立索引。否則可能資料庫沿著索引樹狀結構去搜尋索引中的資料，反而比掃描整個資料表還慢。
‧ 若查詢時符合條件的資料很多，則透過「非叢集索引」搜尋的效能，可能反而不如整個資料表逐筆掃描。
‧ 建立「叢集索引」的欄位選擇至為重要，會影響到整個索引結構的效能。要用來建立「叢集索引」的欄位，務必選擇「整數」型別 (鍵值會較小)、唯一、不可為 NULL。
------------------------------
3、適當地使用索引
‧ 有些書籍會提到，使用 LIKE、% 做模糊查詢時，即使您已替某個欄位建立索引 (如下方例子的 CustomerID)，但以常數字元開頭才會使用到索引，若以萬用字元 (%) 開頭則不會使用索引，如下所示：
USE Northwind;
GO
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'; --使用索引
SELECT * FROM Orders WHERE CustomerID LIKE '%D'; --不使用索引
執行完成後按 Ctrl+L，可檢閱如下圖的「執行計畫」。
圖 1 可看出「查詢最佳化程式」有使用到索引做搜尋
圖 2 在此的叢集索引掃描，並未直接使用索引，效能上幾乎只等於掃描整個資料表
但經版工反覆測試，這種語法是否會使用到索引，抑或會逐筆掃描，並非絕對的。仍要看所下的查詢關鍵字，以及欄位內儲存的資料內容而定。但對於儲存資料筆數龐大的資料表，最好還是少用 LIKE 做模糊查詢。
‧ 以下的運算子會造成「負向查詢」，常會讓「查詢最佳化程式」無法有效地使用索引，最好能用其他運算子和語法改寫 (經版工測試，並非有負向運算子，就絕對無法使用索引)：
NOT 、 != 、 <> 、 !> 、 !< 、 NOT EXISTS 、 NOT IN 、 NOT LIKE
‧ 避免讓 WHERE 子句中的欄位，去做字串串接或數字運算，否則可能導致「查詢最佳化程式」無法直接使用索引，而改採叢集索引掃描 (經版工測試並非絕對)。
‧ 資料表中的資料，會依照「叢集索引」欄位的順序存放，因此當您下 BETWEEN、GROUP BY、ORDER BY 時若有包含「叢集索引」欄位，由於資料已在資料表中排序好，因此可提升查詢速度。
‧ 若使用「複合索引」，要注意索引順序上的第一個欄位，才適合當作過濾條件。
------------------------------
4、避免在 WHERE 子句中對欄位使用函數
對欄位使用函數，也等於對欄位做運算或串接的動作，一樣可能會讓「查詢最佳化程式」無法有效地使用索引。但真正對效能影響最重大的，是當您的資料表內若有 10 萬筆資料，則在查詢時就需要呼叫函數 10 萬次，這點才是真正的效能殺手。程式員應注意，在系統開發初期可能感覺不出差異，但當系統上線且資料持續累積後，這些語法細節所造成的效能問題就會逐步浮現。
SELECT * FROM Orders WHERE DATEPART(yyyy, OrderDate) = 1996 AND DATEPART(mm, OrderDate)=7
可改成
SELECT * FROM Orders WHERE OrderDate BETWEEN '19960701' AND '19960731'
SELECT * FROM Orders WHERE SUBSTRING(CustomerID, 1, 1) = 'D'
可改成
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'
注意當您在下 UPDATE、DELETE 陳述式時，若有採用 WHERE 子句，也應符合上述原則。
------------------------------
5、AND 與 OR 的使用
在 AND 運算中，「只要有一個」條件有用到索引 (如下方的 CustomerID)，即可大幅提升查詢速度，如下圖 3 所示：
SELECT * FROM Orders WHERE CustomerID='VINET' AND Freight=32.3800 --使用索引，會出現下圖 3 的畫面
SELECT * FROM Orders WHERE Freight=32.3800 --不使用索引，會出現上圖 2 的畫面
圖 3
但在 OR 運算中，則要「所有的」條件都有可用的索引，才能使用索引來提升查詢速度。因此 OR 運算子的使用必須特別小心。
若您將上方 AND 的範例，邏輯運算子改成 OR 的話，如下所示：
SELECT * FROM Orders WHERE CustomerID='VINET' OR Freight=32.3800
由於無法有效地使用索引，也會出現圖 2 的畫面。
在使用 OR 運算子時，只要有一個條件 (欄位) 沒有可用的索引，則其他所有的條件 (欄位) 都有索引也沒用，只能如圖 2 般，把整個資料表或整個叢集索引都掃描過，以逐筆比對是否有符合條件的資料。
據網路上文件的說法 [1]，上述的 OR 運算陳述式，我們還可用 UNION 聯集適當地改善，如下：
SELECT * FROM Orders WHERE CustomerID='VINET'
UNION
SELECT * FROM Orders WHERE Freight=32.3800
此時您再按 Ctrl+L 檢閱「執行計畫」，會發現上半段的查詢會使用索引，但下半段仍用叢集索引掃描，對效能不無小補。
------------------------------
6、適當地使用子查詢
相較於「子查詢 (Subquery)」，若能用 JOIN 完成的查詢，一般會比較建議使用後者。原因除了 JOIN 的語法較容易理解外，在多數的情況下，JOIN 的效能也會比子查詢較佳；但這並非絕對，也有的情況可能剛好相反。
我們知道子查詢可分為「獨立子查詢」和「關聯子查詢」兩種，前者指子查詢的內容可單獨執行，後者則無法單獨執行，亦即外層查詢的「每一次」查詢動作都需要引用內層查詢的資料，或內層查詢的「每一次」查詢動作都需要參考外層查詢的資料。
以下我們看一個比較極端的例子 [2]。若我們希望所有查詢出來的資料，都能另外給一個自動編號，版工我在之前的文章「用 SQL Server 2005 新增的 ROW_NUMBER 函數撰寫 GridView 分頁」中有介紹過，可用 SQL Server 2005 中新增的 ROW_NUMBER 函數輕易地達成，且 ROW_NUMBER 函數還能再加上「分群 (PARTITION BY)」等功能，而且執行效能極佳。
圖 4 將 Orders 資料表的 830 筆資料都撈出來，並在右側給一組自動編號
現在我們要如上圖 4 般，將 Northwind 中 Orders 資料表的 830 筆資料都撈出來，並自動給一組編號，若用 ROW_NUMBER 函數的寫法如下所示，而且效能極佳，只要 2 ms (毫秒)，亦即千分之二秒。
SET STATISTICS TIME ON
SELECT OrderID, ROW_NUMBER() OVER(ORDER BY OrderID) AS 編號
FROM dbo.Orders
但如果是在舊版的 SQL Server 2000 中，我們可能得用以下的「子查詢」寫法：
SET STATISTICS TIME ON
SELECT OrderID,
(SELECT COUNT(*) FROM dbo.Orders AS 內圈
WHERE 內圈.OrderID <= 外圈.OrderID) AS 編號
FROM dbo.Orders AS 外圈
ORDER BY 編號
但這種舊寫法，會像先前所提到的，外層查詢的「每一次」查詢動作都需要引用內層查詢的資料。以上方例子而言，外層查詢的每一筆資料，都要等內層查詢「掃描整個資料表」並作比對和計數，因此 830 筆資料每一筆都要重複掃描整個資料表 830 次，所耗用的時間也因此爆增至 170 ms。
若您用相同的寫法，去查詢 AdventureWorks 資料庫中，有 31,465 筆資料的 Sales.SalesOrderHeader 資料表，用 ROW_NUMBER 函數要 677 ms，還不到 1 秒鐘；但用子查詢的話，居然要高達 225,735 ms，將近快 4 分鐘的時間。
雖然這是較極端的範例，但由此可知子查詢的撰寫，在使用上不可不慎，尤其是「關聯子查詢」。程式員在程式開發初期、資料量還很少時感受不到此種 SQL 語法的重大陷阱；但等到系統上線幾個月或一兩年後，可能就會有反應遲緩的現象。
------------------------------
7、其他查詢技巧
‧ DISTINCT、ORDER BY 語法，會讓資料庫做額外的計算。此外聯集的使用，若沒有要剔除重複資料的需求，使用 UNION ALL 會比 UNION 更佳，因為後者會加入類似 DISTINCT 的演算法。
‧ 在 SQL Server 2005 版本中，存取資料庫物件時，最好明確指定該物件的「結構描述 (Schema)」，也就是使用兩節式名稱。否則若呼叫者的預設 Schema 不是 dbo，則 SQL Server 在執行時，會先尋找該使用者預設 Schema 所搭配的物件，找不到的話才會轉而使用預設的 dbo，會多耗費尋找的時間。例如若要執行一個叫做 dbo.mySP1 的 Stored Procedure，應使用以下的兩節式名稱：
EXEC dbo.mySP1
------------------------------
8、儘可能用 Stored Procedure 取代前端應用程式直接存取資料表
Stored Procedure 除了經過事先編譯、效能較好以外，亦可節省 SQL 陳述式傳遞的頻寬，也方便商業邏輯的重複使用。再搭配自訂函數和 View 的使用，將來若要修改資料表結構、重新切割或反正規化時亦較方便。
------------------------------
9、儘可能在資料來源層，就先過濾資料
使用 SELECT 語法時，儘量避免傳回所有的資料至前端而不設定 WHERE 等過濾條件。雖然 ASP.NET 中 SqlDataSource、ObjectDataSource 控制項的 FilterExpression 可再做篩選，GridView 控制項的 SortExpression 可再做排序，但會多消耗掉資料庫的系統資源、Web server 的記憶體和網路頻寬。最好還是在資料庫和資料來源層，就先用 SQL 條件式篩選出所要的資料。
------------------------------
結論：
本文的觀念，不管是寫 SQL statement、Stored Procedure、自訂函數或 View 皆然。本文只是挑出程式員較容易犯的 SQL 語法效能問題，以期能在短時間瀏覽過本文後，在寫 ADO.NET 程式時能修正以往隨興的 SQL 撰寫習慣。文中提到的幾點，只不過是 SQL 語法效能議題的入門篇。後續有時間的話，版工會再補充在本帖的回應留言，或另開新主題。
(原文轉載自 http://www.wretch.cc/blog/hcu16b/10264132 )
有些程式員在撰寫前端的應用程式時，會透過各種 OOP 語言將存取資料庫的 SQL 陳述式串接起來，卻忽略了 SQL 語法的效能問題。版工曾聽過某半導體大廠的新進程式員，所兜出來的一段 PL/SQL 跑了好幾分鐘還跑不完；想當然爾，即使他前端的 AJAX 用得再漂亮，程式效能頂多也只是差強人意而已。以下是版工整理出的一些簡單心得，讓長年鑽究 ASP.NET / JSP / AJAX 等前端應用程式，卻無暇研究 SQL 語法的程式員，避免踩到一些 SQL 的效能地雷。
1、資料庫設計與規劃
‧ Primary Key 欄位的長度儘量小，能用 small integer 就不要用 integer。例如員工資料表，若能用員工編號當主鍵，就不要用身分證字號。
‧ 一般欄位亦同。若該資料表要存放的資料不會超過 3 萬筆，用 small integer 即可，不必用 integer。
‧ 文字資料欄位若長度固定，如：身分證字號，就不要用 varchar 或 nvarchar，應該用 char 或 nchar。
‧ 文字資料欄位若長度不固定，如：地址，則應該用 varchar 或 nvarchar。除了可節省儲存空間外，存取磁碟時也會較有效率。
‧ 設計欄位時，若其值可有可無，最好也給一個預設值，並設成「不允許 NULL」(一般欄位預設為「允許 NULL」)。因為 SQL Server 在存放和查詢有 NULL 的資料表時，會花費額外的運算動作 [2]。
‧ 若一個資料表的欄位過多，應垂直切割成兩個以上的資料表，並用同名的 Primary Key 一對多連結起來，如：Northwind 的 Orders、Order Details 資料表。以避免在存取資料時，以叢集索引掃描時會載入過多的資料，或修改資料時造成互相鎖定或鎖定過久。
------------------------------
2、適當地建立索引
‧ 記得自行幫 Foreign Key 欄位建立索引，即使是很少被 JOIN 的資料表亦然。
‧ 替常被查詢或排序的欄位建立索引，如：常被當作 WHERE 子句條件的欄位。
‧ 用來建立索引的欄位，長度不宜過長，不要用超過 20 個位元組的欄位，如：地址。
‧ 不要替內容重複性高的欄位建立索引，如：性別；反之，若重複性低的欄位則適合建立索引，如：姓名。
‧ 不要替使用率低的欄位建立索引。
‧ 不宜替過多欄位建立索引，否則反而會影響到新增、修改、刪除的效能，尤其是以線上交易 (OLTP) 為主的網站資料庫。
‧ 若資料表存放的資料很少，就不必刻意建立索引。否則可能資料庫沿著索引樹狀結構去搜尋索引中的資料，反而比掃描整個資料表還慢。
‧ 若查詢時符合條件的資料很多，則透過「非叢集索引」搜尋的效能，可能反而不如整個資料表逐筆掃描。
‧ 建立「叢集索引」的欄位選擇至為重要，會影響到整個索引結構的效能。要用來建立「叢集索引」的欄位，務必選擇「整數」型別 (鍵值會較小)、唯一、不可為 NULL。
------------------------------
3、適當地使用索引
‧ 有些書籍會提到，使用 LIKE、% 做模糊查詢時，即使您已替某個欄位建立索引 (如下方例子的 CustomerID)，但以常數字元開頭才會使用到索引，若以萬用字元 (%) 開頭則不會使用索引，如下所示：
USE Northwind;
GO
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'; --使用索引
SELECT * FROM Orders WHERE CustomerID LIKE '%D'; --不使用索引
執行完成後按 Ctrl+L，可檢閱如下圖的「執行計畫」。
圖 1 可看出「查詢最佳化程式」有使用到索引做搜尋
圖 2 在此的叢集索引掃描，並未直接使用索引，效能上幾乎只等於掃描整個資料表
但經版工反覆測試，這種語法是否會使用到索引，抑或會逐筆掃描，並非絕對的。仍要看所下的查詢關鍵字，以及欄位內儲存的資料內容而定。但對於儲存資料筆數龐大的資料表，最好還是少用 LIKE 做模糊查詢。
‧ 以下的運算子會造成「負向查詢」，常會讓「查詢最佳化程式」無法有效地使用索引，最好能用其他運算子和語法改寫 (經版工測試，並非有負向運算子，就絕對無法使用索引)：
NOT 、 != 、 <> 、 !> 、 !< 、 NOT EXISTS 、 NOT IN 、 NOT LIKE
‧ 避免讓 WHERE 子句中的欄位，去做字串串接或數字運算，否則可能導致「查詢最佳化程式」無法直接使用索引，而改採叢集索引掃描 (經版工測試並非絕對)。
‧ 資料表中的資料，會依照「叢集索引」欄位的順序存放，因此當您下 BETWEEN、GROUP BY、ORDER BY 時若有包含「叢集索引」欄位，由於資料已在資料表中排序好，因此可提升查詢速度。
‧ 若使用「複合索引」，要注意索引順序上的第一個欄位，才適合當作過濾條件。
------------------------------
4、避免在 WHERE 子句中對欄位使用函數
對欄位使用函數，也等於對欄位做運算或串接的動作，一樣可能會讓「查詢最佳化程式」無法有效地使用索引。但真正對效能影響最重大的，是當您的資料表內若有 10 萬筆資料，則在查詢時就需要呼叫函數 10 萬次，這點才是真正的效能殺手。程式員應注意，在系統開發初期可能感覺不出差異，但當系統上線且資料持續累積後，這些語法細節所造成的效能問題就會逐步浮現。
SELECT * FROM Orders WHERE DATEPART(yyyy, OrderDate) = 1996 AND DATEPART(mm, OrderDate)=7
可改成
SELECT * FROM Orders WHERE OrderDate BETWEEN '19960701' AND '19960731'
SELECT * FROM Orders WHERE SUBSTRING(CustomerID, 1, 1) = 'D'
可改成
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'
注意當您在下 UPDATE、DELETE 陳述式時，若有採用 WHERE 子句，也應符合上述原則。
------------------------------
5、AND 與 OR 的使用
在 AND 運算中，「只要有一個」條件有用到索引 (如下方的 CustomerID)，即可大幅提升查詢速度，如下圖 3 所示：
SELECT * FROM Orders WHERE CustomerID='VINET' AND Freight=32.3800 --使用索引，會出現下圖 3 的畫面
SELECT * FROM Orders WHERE Freight=32.3800 --不使用索引，會出現上圖 2 的畫面
圖 3
但在 OR 運算中，則要「所有的」條件都有可用的索引，才能使用索引來提升查詢速度。因此 OR 運算子的使用必須特別小心。
若您將上方 AND 的範例，邏輯運算子改成 OR 的話，如下所示：
SELECT * FROM Orders WHERE CustomerID='VINET' OR Freight=32.3800
由於無法有效地使用索引，也會出現圖 2 的畫面。
在使用 OR 運算子時，只要有一個條件 (欄位) 沒有可用的索引，則其他所有的條件 (欄位) 都有索引也沒用，只能如圖 2 般，把整個資料表或整個叢集索引都掃描過，以逐筆比對是否有符合條件的資料。
據網路上文件的說法 [1]，上述的 OR 運算陳述式，我們還可用 UNION 聯集適當地改善，如下：
SELECT * FROM Orders WHERE CustomerID='VINET'
UNION
SELECT * FROM Orders WHERE Freight=32.3800
此時您再按 Ctrl+L 檢閱「執行計畫」，會發現上半段的查詢會使用索引，但下半段仍用叢集索引掃描，對效能不無小補。
------------------------------
6、適當地使用子查詢
相較於「子查詢 (Subquery)」，若能用 JOIN 完成的查詢，一般會比較建議使用後者。原因除了 JOIN 的語法較容易理解外，在多數的情況下，JOIN 的效能也會比子查詢較佳；但這並非絕對，也有的情況可能剛好相反。
我們知道子查詢可分為「獨立子查詢」和「關聯子查詢」兩種，前者指子查詢的內容可單獨執行，後者則無法單獨執行，亦即外層查詢的「每一次」查詢動作都需要引用內層查詢的資料，或內層查詢的「每一次」查詢動作都需要參考外層查詢的資料。
以下我們看一個比較極端的例子 [2]。若我們希望所有查詢出來的資料，都能另外給一個自動編號，版工我在之前的文章「用 SQL Server 2005 新增的 ROW_NUMBER 函數撰寫 GridView 分頁」中有介紹過，可用 SQL Server 2005 中新增的 ROW_NUMBER 函數輕易地達成，且 ROW_NUMBER 函數還能再加上「分群 (PARTITION BY)」等功能，而且執行效能極佳。
圖 4 將 Orders 資料表的 830 筆資料都撈出來，並在右側給一組自動編號
現在我們要如上圖 4 般，將 Northwind 中 Orders 資料表的 830 筆資料都撈出來，並自動給一組編號，若用 ROW_NUMBER 函數的寫法如下所示，而且效能極佳，只要 2 ms (毫秒)，亦即千分之二秒。
SET STATISTICS TIME ON
SELECT OrderID, ROW_NUMBER() OVER(ORDER BY OrderID) AS 編號
FROM dbo.Orders
但如果是在舊版的 SQL Server 2000 中，我們可能得用以下的「子查詢」寫法：
SET STATISTICS TIME ON
SELECT OrderID,
(SELECT COUNT(*) FROM dbo.Orders AS 內圈
WHERE 內圈.OrderID <= 外圈.OrderID) AS 編號
FROM dbo.Orders AS 外圈
ORDER BY 編號
但這種舊寫法，會像先前所提到的，外層查詢的「每一次」查詢動作都需要引用內層查詢的資料。以上方例子而言，外層查詢的每一筆資料，都要等內層查詢「掃描整個資料表」並作比對和計數，因此 830 筆資料每一筆都要重複掃描整個資料表 830 次，所耗用的時間也因此爆增至 170 ms。
若您用相同的寫法，去查詢 AdventureWorks 資料庫中，有 31,465 筆資料的 Sales.SalesOrderHeader 資料表，用 ROW_NUMBER 函數要 677 ms，還不到 1 秒鐘；但用子查詢的話，居然要高達 225,735 ms，將近快 4 分鐘的時間。
雖然這是較極端的範例，但由此可知子查詢的撰寫，在使用上不可不慎，尤其是「關聯子查詢」。程式員在程式開發初期、資料量還很少時感受不到此種 SQL 語法的重大陷阱；但等到系統上線幾個月或一兩年後，可能就會有反應遲緩的現象。
------------------------------
7、其他查詢技巧
‧ DISTINCT、ORDER BY 語法，會讓資料庫做額外的計算。此外聯集的使用，若沒有要剔除重複資料的需求，使用 UNION ALL 會比 UNION 更佳，因為後者會加入類似 DISTINCT 的演算法。
‧ 在 SQL Server 2005 版本中，存取資料庫物件時，最好明確指定該物件的「結構描述 (Schema)」，也就是使用兩節式名稱。否則若呼叫者的預設 Schema 不是 dbo，則 SQL Server 在執行時，會先尋找該使用者預設 Schema 所搭配的物件，找不到的話才會轉而使用預設的 dbo，會多耗費尋找的時間。例如若要執行一個叫做 dbo.mySP1 的 Stored Procedure，應使用以下的兩節式名稱：
EXEC dbo.mySP1
------------------------------
8、儘可能用 Stored Procedure 取代前端應用程式直接存取資料表
Stored Procedure 除了經過事先編譯、效能較好以外，亦可節省 SQL 陳述式傳遞的頻寬，也方便商業邏輯的重複使用。再搭配自訂函數和 View 的使用，將來若要修改資料表結構、重新切割或反正規化時亦較方便。
------------------------------
9、儘可能在資料來源層，就先過濾資料
使用 SELECT 語法時，儘量避免傳回所有的資料至前端而不設定 WHERE 等過濾條件。雖然 ASP.NET 中 SqlDataSource、ObjectDataSource 控制項的 FilterExpression 可再做篩選，GridView 控制項的 SortExpression 可再做排序，但會多消耗掉資料庫的系統資源、Web server 的記憶體和網路頻寬。最好還是在資料庫和資料來源層，就先用 SQL 條件式篩選出所要的資料。
------------------------------
結論：
本文的觀念，不管是寫 SQL statement、Stored Procedure、自訂函數或 View 皆然。本文只是挑出程式員較容易犯的 SQL 語法效能問題，以期能在短時間瀏覽過本文後，在寫 ADO.NET 程式時能修正以往隨興的 SQL 撰寫習慣。文中提到的幾點，只不過是 SQL 語法效能議題的入門篇。後續有時間的話，版工會再補充在本帖的回應留言，或另開新主題。
2010年7月6日 星期二
2010年5月11日 星期二
最佳化 Visual Studio 2008 執行速度
(感謝Allen分享)
●關閉起始頁
工具 -> 選項 環境 -> 啟動，改變 啟動時 的屬性為 顯示空白環境
●關閉歡迎畫面
在 Microsoft Visual Studio 2008 的捷徑上按滑鼠右鍵，選 內容
在 目標 的最後，加上參數 /nosplash
●關閉動畫
工具 -> 選項 -> 環境，把 動畫環境工具 取消
●關閉追蹤修訂
工具 -> 選項 -> 文字編輯器 追蹤修訂 取消
●關閉 ToolboxPopulate
工具 -> 選項 -> Windows Form 設計 -> 工具箱，把 Auto ToolboxPopulate 設定為 False
將專案建置的元件自動加入工具箱的功能關閉
剛剛按照網頁上的說明，將設定一一改變，果真啟動 Visual Studio 2008 快了許多！
●關閉起始頁
工具 -> 選項 環境 -> 啟動，改變 啟動時 的屬性為 顯示空白環境
●關閉歡迎畫面
在 Microsoft Visual Studio 2008 的捷徑上按滑鼠右鍵，選 內容
在 目標 的最後，加上參數 /nosplash
●關閉動畫
工具 -> 選項 -> 環境，把 動畫環境工具 取消
●關閉追蹤修訂
工具 -> 選項 -> 文字編輯器 追蹤修訂 取消
●關閉 ToolboxPopulate
工具 -> 選項 -> Windows Form 設計 -> 工具箱，把 Auto ToolboxPopulate 設定為 False
將專案建置的元件自動加入工具箱的功能關閉
剛剛按照網頁上的說明，將設定一一改變，果真啟動 Visual Studio 2008 快了許多！
VM 參考資料
感謝Tyler 2月分享：
這裡簡單找了一些vm的資料供大家參考目前VM主機是安裝VMware Server 1.0(free)
最新版是2.0(free)，且支援64bit guest os
有一種說法是Microsft Hyper-V的效能比VMWare Server好，不曉得真實性如何
而且灌Windows Server 2008是免不了的
另外市面上效能最佳的vm應該是VMware ESX，但對週邊的支援差，現在也有免費精簡版叫VMware ESXi 它比較特別的是不需安裝作業系統，因此guest os非常的原生(所謂的半虛擬化)，所以效能會很好
VMWare Server 2.0
https://www.vmware.com/products/server/overview.html
Microsoft Hyper-V Server
http://www.microsoft.com/hyper-v-server/en/us/default.aspx
VMware ESXi導入
http://applepig.idv.tw/archives/919
效能比較(2007年的資料)
http://blog.nonestyle.net/2007/03/vmware-virtual-pc-parallels-virtualbox.html
VMware ESX/ESXi/Server效能比較
http://www.vixual.net/blog/archives/543
虛擬機之家
http://www.xuniji.com/
2010年3月1日 星期一
錄音好物 - OLYMPUS WS-500M
幾年前MP3正夯時，曾因需要錄音並能當MP3隨身聽買了1G的產品，但錄音效果實在差強人意，而且一年前它也早壽終正寢。
近日因為上課需要錄音，上網survey了一下錄音筆，竟發現有人談到～見 懇請大大推薦錄音筆 一文，另外，[開箱] OLYMPUS WS-500M 也值得一讀，搭配下載韌體更新，可直接錄製MP3。
沒想到這好物只能從美國代購取得，從沒天頂的拍賣場花了 $3050大洋還直奔五股自取(還迷路繞到泰山去了...)；
今天上課錄製的心得是~好得不得了啊，上了9小時的課，用掉1顆AAA (4號)電池，還不錯哩，音樂MP3聽起來的效果也很讚，有SRS也可以設BASS，按鍵配置蠻順手的，不用看書明書也能馬上上手，還有SLOW、FAST語言學習功能，都是很實用的功能，唯一可以挑剔的，應該就是美感的問題了，塑膠味頗重，果然是美國老粗的style（跟SONY日本美型派的真差得遠），但對我而言，無損對它的讚賞。
近日因為上課需要錄音，上網survey了一下錄音筆，竟發現有人談到～見 懇請大大推薦錄音筆 一文，另外，[開箱] OLYMPUS WS-500M 也值得一讀，搭配下載韌體更新，可直接錄製MP3。
沒想到這好物只能從美國代購取得，從沒天頂的拍賣場花了 $3050大洋還直奔五股自取(還迷路繞到泰山去了...)；今天上課錄製的心得是~好得不得了啊，上了9小時的課，用掉1顆AAA (4號)電池，還不錯哩，音樂MP3聽起來的效果也很讚，有SRS也可以設BASS，按鍵配置蠻順手的，不用看書明書也能馬上上手，還有SLOW、FAST語言學習功能，都是很實用的功能，唯一可以挑剔的，應該就是美感的問題了，塑膠味頗重，果然是美國老粗的style（跟SONY日本美型派的真差得遠），但對我而言，無損對它的讚賞。
2010年1月11日 星期一
2010年1月4日 星期一
2009年12月19日 星期六
CANON EOS 20D 參數與 DPP 最適調整
蒐集網上分享~
對 EOS 20D機身參數：
對比 -2
銳利度+2
飽和度+1
色調 +0
只拍RAW檔
進DPP調整
DPP3.7.2設定
+RAW影像調整
---暗部調整(1) --> 是-1吧~!!
---銳利度(4)
+進階調整
---亮域雜訊抑制(0) --> 4
色差雜訊抑制 -> 5
這組設定測試過後最耐看
色階自然,銳利度OK.
有調整飽和度所以顏色上會比較討喜.
其他的部分都最接近現場感覺.
測試後發現DPP轉出的JPG(直出、或先TIFF再PhotoCap4轉JPG)整個雪花一片...
研究後發現是"亮域雜訊抑制"的問題 (參 [測試]canon 機身與後製消除雜訊分析 一文)，
後來，改設定
亮域雜訊抑制 -> 4
色差雜訊抑制 -> 5
轉出的JPG終於是適合人看得了~~
對 EOS 20D機身參數：
對比 -2
銳利度+2
飽和度+1
色調 +0
只拍RAW檔
進DPP調整
DPP3.7.2設定
+RAW影像調整
---暗部調整(1) --> 是-1吧~!!
---銳利度(4)
+進階調整
---亮域雜訊抑制(0) --> 4
色差雜訊抑制 -> 5
這組設定測試過後最耐看
色階自然,銳利度OK.
有調整飽和度所以顏色上會比較討喜.
其他的部分都最接近現場感覺.
測試後發現DPP轉出的JPG(直出、或先TIFF再PhotoCap4轉JPG)整個雪花一片...
研究後發現是"亮域雜訊抑制"的問題 (參 [測試]canon 機身與後製消除雜訊分析 一文)，
後來，改設定
亮域雜訊抑制 -> 4
色差雜訊抑制 -> 5
轉出的JPG終於是適合人看得了~~
2009年12月7日 星期一
無線解決方案 - WDS survey (醞釀實作!)
有在用無線AP的一定都常為訊號不穩、熱當~這類問題所苦，近來適逢家裡網路幾乎掛點的狀況，為何用"幾乎"~!因為開個IE竟然要30秒~首頁是google傳統頁ㄟ~~越想越不對，烏龜重置然後爛SMC AP也power down了，狀況一樣沒改善，原以為SMC爛只影響無線的狀況，沒想到用有線連的PC也一樣，重點是，我的wow也沒法玩了~~這簡直是太嚴重了，看來該下定決心換掉它了。
----------------------------------- 分隔 ----------------------------------------
survey解法，有一款 Ruckus 覆蓋王 似乎不錯，但價格不斐，要 $3xxx ，而且我的狀況是樓中樓，也怕它只是距離遠但穿透性無法合我所用；繼續爬文後，發現另一個 solution - Wireless Distribution System(WDS) ，嗯~這似乎能解決我的問題，而且也能保留往後擴充~
這二篇文章：
----------------------------------- 分隔 ----------------------------------------
survey解法，有一款 Ruckus 覆蓋王 似乎不錯，但價格不斐，要 $3xxx ，而且我的狀況是樓中樓，也怕它只是距離遠但穿透性無法合我所用；繼續爬文後，發現另一個 solution - Wireless Distribution System(WDS) ，嗯~這似乎能解決我的問題，而且也能保留往後擴充~
這二篇文章：
可以好好參考，搭 SparkLAN 速連通訊 WRTR-142 802.11g 無線路由器 $888，加購一根10 dBi天線Y購也只要$690搞定，
看來甚至我不必急者買2臺AP，先買一台+天線，或許連WDS都不必了，等試過再報告了。
另外的選擇： 上網3件事DIR-600實測 (上網+下載+Skype) ，看來D-Link可以考慮。
華碩ASUS WL-520GU 似乎也不錯，配合 華碩WL-520gu刷tomato問題請教 這篇改機。
華碩ASUS WL-520GU 似乎也不錯，配合 華碩WL-520gu刷tomato問題請教 這篇改機。
訂閱：
文章 (Atom)