「資料探勘」幼幼班

請訪問 iCoding Blog 主站 



儘管「資料探勘」已經被研究數十年了，到現在仍然被許多人所誤解，因此我決定整理一篇「資料探勘」的基礎簡介，希望能幫助大家對資料探勘這個領域有多一點的初步認識。過程會牽涉到一些專有名詞，已盡量附上連結，若仍無法理解還請多多包涵。如有錯誤，也歡迎不吝指正。

什麼是資料探勘

「資料探勘」是一個「嘗試從一大組資料當中找出一些特徵樣式（pattern）的過程」。

「資料探勘」結合了「資訊科學」和「統計學」等跨領知識，除了對原始資料的分析和資料的技術之外，統計模型與統計推論、結構化的後置處理、資料視覺化等技術都是資料探勘會牽涉到的領域。

「資料探勘」的英文原文是 Data Mining，源於1990年的資料庫社群，曾經成為 HNC 這間公司的註冊商標，在人工智慧和機器學習的領域中，Data Mining（資料探勘） 和 Knowledge Discovery（知識探索）經常互為同義詞。

為什麼要做資料探勘

人們希望能從一堆資料當中，萃取出一些有意義的資訊，並且把這些資訊轉換成比較容易理解的形式，以便對這些資訊再利用。而這也是「資料探勘」存在的目的與目標。

舉例來說，人們會想透過某種從地層資料當中去分析歸納出一些含礦量高的地形特徵樣式（pattern），並建出合乎真實的地底模型（model），再利用這些特徵或模型找出建造優異礦坑或油田的過程與方法。

常見的資料探勘方法

粗略來說，資料探勘可以分成底下三個步驟：

1. 資料預先處理 (pre-processing)
2. 資料探勘 (data mining)
3. 結果的評估與驗證 (results validation)

資料預先處理（Pre-processing）是一個必要的步驟，不但要確保資料的數量足夠，讓探勘的結果具有意義，也要避免資料無法在合理的時間內可以被分析完畢，此外，也必須確保資料的乾淨（data cleaning），例如過濾掉一些雜訊或錯誤的資料，以免探勘出奇怪的結果。

資料處理完之後，就可以開始探勘了：

• 異常偵測
• 用來分辨一些看起來不尋常的資料，這些東西可能會是有意義的資訊或只是單純的錯誤。
• 關聯規則的學習
• 資料當中有許多變因或是變數之間可能會有關聯性（例如天氣和銷售量的關係），這個步驟的目的專門用來找尋這種關聯性。
• 分群
• 在面對一群未知類型的資料時，把看起來相似的資料聚集成同一個組別的方法。
• 分類
• 把新發現的資料歸類到預先定好的類別當中（例如把郵件分成重要、普通、和垃圾）。
• 回歸分析
• 用來找出資料之間是否有依賴或獨立的關係。
• 結果摘要
• 提供一組最具代表性（代表原始資料或某件知識或事情）的簡化資料，並且包括視覺化以及結果報告。

由於探勘完的結果或是找到的特徵樣式（pattern）很可能有不合理的結果（例如：過度最佳化 - overfitting），所以在做完資料探勘之後需要做驗證（Result validation），以免被錯誤的結果所誤導。一般來說，我們會在探勘前把資料分成訓練組（training set）和測試組（test set），我們會把訓練組餵給探勘演算法進行探勘，再用測試組檢測從訓練組當中找到的特徵樣式是否也存在於測試組。ROC 曲線是常拿來評估驗證結果的方式。

常見的誤解

資料探勘強調的是「探勘」或是「探索未知（detecting something new）」這件事。

很多人誤以為資料探勘包括任何形式的大規模（尤其是強調巨量，例如大資料 - big data）的資料或資訊的處理過程，例如一些資料收集、擷取、放置、分析與統計分析，甚至人工智慧、機器學習、Business Intelligence、電腦輔助決策系統等，都不是資料探勘。

市面上有些暢銷書用了行銷手段，在書名前面加上 Data Mining 幾個字來提高賣點，這也是不對的。

另外，資料探勘和「應用」資料探勘技術其實是兩件事情，一個是對未知模型的探索，另一個是拿已知的模型進行應用，一個是模型創造者，一個是模型使用者，如果沒有切割十分清楚很容易被誤解。

資料探勘的應用

前面提到「資料探勘」像是找礦脈、油田的過程，而在這過程下有許多的多輔助工具、已知特徵樣式或模型等技術因應而生，這些的資料探勘的「衍生應用」在許多領域都可以看見，例如：

• 商業：
• 客戶關係管理（利用分析結果來找出精準客群）、購物籃分析、決策系統等。
• 科學與工程：
• 生物資訊、醫學、基因、藥學、電力工程等，都是「資料探勘」的重度使用者。
• 人權組織：
• 可以透過探勘政府的資料，去探索迫害人權的政府機構或文獻的存在。
• 時空資料探勘：
• 資料探勘技術也被廣泛的應用在地理資訊系統（GIS）的研究上，這些資料量非常驚人龐大，存在著許多巨大挑戰以及潛在應用在商業的機會。
• 視覺、音樂資料分析
• 例如伴隨分析（co-occurrence analysis），可以用來區分音樂的類型。
• 監控：
• 分析防堵恐怖份子的應用也透過資料探勘歸納出來的結果作依據。
• 樣式探勘（pattern mining）
• 從資料中比對一些已知的樣式，像是所謂的「關聯規則」，可以用來幫助改善商業銷售狀況，例如買啤酒的人，80%的機會會買洋芋片。

提了這麼多相關應用，是不是有種眼花繚亂的感覺呢？
其實，這些廣大的資料探勘的相關應用正一點一滴地在改變你我的日常生活呢：）

希望這篇文章能讓您對「資料探勘」有多一點感覺。

Reference: http://en.wikipedia.org/wiki/Data_mining
Photo by Caitlin Childs, CC licensed

決定你公司名稱的五種方法

決定一個名字的因素有哪些？在 google 裡面搜尋 “naming your company” 得到的一長串列表當中，我們可以知道有一堆的因素可以決定。

當然有很多不同的策略可以幫你的公司取名字，不過你也可以簡單的從報紙上面隨便翻翻來得到其他創業的人都是怎麼取名的。

不過也不要太輕率的亂做決定，公司名稱除了會是一個辨識你個人的重要部分之外，它也會被用在行銷、媒體關係、部落格、網站甚至是印刷品上面。

這會是個很重大的決策！

下面提供了五種不同的企業命名方式可以參考看看。

真實的字 (Real words)

Yahoo、Apple、Amazon 和 Twitter 都是這種類型的命名方式，他們都是一些有意義的字，但是跟你的事業並沒有直接的關係。

採用這種方式的理由：有趣而且相當容易有記憶點。畢竟創造 Yahoo（之前叫做 Jerry’s Guide to the World Wide Web）的人不只找了一個唸起來很有趣的名字，而且他們也建立了一個獨特的廣告口號。

不採用這種方式的理由：名字可能會太抽象而且讓人有點困擾。如果這個字選的不好，那可能不會對你的事業有啥幫助，另外其實你也很難找到沒被用掉的網域。不信的話可以馬上去試試看！

拼錯的字 (Misspelled words)

你當然知道怎麼拼字！不過用些拼錯字的同音字可能會讓你的公司感覺起來很酷。想想看下面這些例子：Tumblr(Tumbler), del.icio.us (delicious), Digg (dig), flickr (flicker) 還有 Google (Googol)。

採用這種方式的理由：除了拼錯的字會特別突出外（不信問看看你的英文老師），而且這也可以幫你克服那些討厭的網域註冊問題。

不採用這種方式的理由：用拼錯的字可能會讓人覺得有點困擾，而且會讓人家在網路上比較難找到你的公司。

兩個看起來有意義的複合字 (Two syllable, compound words)

很多新創公司都朝這個方向前進，像是 Birchbox, SkillShare, Crowdtilt 還有 JackThreads，或許 Facebook 的成功也讓這個風潮有點原因？

採用這種方式的理由：似乎有無限種可能可以把兩個字湊起來表示你的事業，而且相較之下 URL 也會好找很多。

不採用這種方式的理由：感覺起來好像很難想像到這樣做會有啥壞處，不過有的時候這種方法會被玩的太過火，要確認你不會僅僅因為好玩就隨便把兩個字湊起來。

每個字開頭的縮寫 (Initials and acronyms)

想想比較老派的公司像是 IBM (International Business Machines), AOL (America Online) 還有 TBS (Turner Broadcast System)，

採用這種方式的理由：如果數個單詞加在一起可以精準的描述你的事業，用縮寫的方式似乎是一個很合邏輯的答案。這樣也會更容易讓你的客戶和事業夥伴記得你的名字。

不採用這種方式的理由：很無聊。而且大多數的公司都用三個字母的縮寫，不過所有三個字母縮寫的 .com 網域都被註冊走了。所以你可能要花上一大筆錢才能獲得這個網域。

假的字 (Made-up words)

Skype, Hulu, Zynga… 儘管一點意義都沒有，不過感覺起來很好玩。

採用這種方式的理由：無中生有你的品牌名稱讓你可以有很多發揮創意的空間，如果你做的好的話，一個虛擬的名字可以弄的很引人注目而且很好記。

不採用這種方式的理由：創造一個名字可能會有幾個缺點，包含了可能會導致其他人對你品牌的誤解和困擾。如果名字太虛無飄渺，那可能會很容易被人家忘記，或是根本就是完全被忽略。

Reference: 5 Trends Entrepreneurs Should Consider When Naming a Startup

Photo by Le ciel azuré, cc licensed.

你其實並不懂 JavaScript

筆者之前曾在 Ideasnow! 上面發表過這篇翻譯文章，最近重看有許多不同的感覺，再加上有些部分之前研究 jQuery 原始碼以及 JavaScript 效能的文章有看過，所以稍微編修了文章再加上了一些個人見解。

偶然在網路上看到這篇文章，覺得很有趣，必須說這篇文章有幾點我不太了解的地方，所以有稍微查了一下，想說乾脆用我自己理解的方式把它翻譯一遍。如果你也恰巧很了解 JavaScript，然後發現我理解錯誤，那請一定要糾正我:)

你其實並不懂 JavaScript

本文翻譯自：http://www.w2lessons.com/2011/04/you-dont-know-javascript.html
This article is translated from: http://www.w2lessons.com/2011/04/you-dont-know-javascript.html

過去一年多來，我發現到一個正在發生的問題，一個令人不是那麼開心的現象。我一再的看到程式設計師在履歷裡面填入他們實際上不是這麼熟悉而只是稍微接觸過的技術。而在那麼多的程式語言中，最常被用來填充在履歷上的正是 JavaScript。

你甚至沒有意識到你不了解 JavaScript

之所以會這樣，大概是因為幾乎每一個 Web 工程師或多或少都會有需要用到 JavaScript 的時候。在沒有完全了解的狀況下，最常看到的學習 JavaScript 的方法是依照需求從網路上隨便找一段 JavaScript 程式碼片段，配合一些間單的編輯之後再進行「剪下與貼上」。這麼一來，工程師從未真正的學習語言可是卻往往會有一種錯覺，自以為自己懂。在經過了一些學習的課程以及 JavaScript 工作了幾年下來之後，我發現在你真正的了解它之前，你並沒有意識到你其實並不懂 JavaScript。看起來這是個惡性循環的問題。而其實你需要的只是有個人來告訴你你並不懂 JS，並且你需要一些真正的學習來了解 JS。時常面試到一些很驕傲的把 JS 列在履歷上的人，但其實僅僅只是做過一些從網路上來的程式碼片段擷取而成的 onClick 的處理函式或是表單驗證的簡單工作。如果有用過或是有一些 JS 框架(例如 JQuery 或 Dojo )的知識的話很好，但是在沒有完全的了解實作這些框架的 JS 的情況下，其實並無法真正的熟悉了解這些 JS 框架。為了展現 JS 的各種組成原理，我把這些概念區分為基本，中等，進階三個等級：

基礎等級包含：

• 知道基本的 JS 語法，例如迴圈，if 判斷式，try/catch 等。
• 了解各式函式定義的方法以及指派的方法，包含了解匿名函式的使用。
• 了解基本的 scope 原則，包含全域 scope (window) 以及物件 scope (不包含 closures)
• 了解執行 context scope 以及 this 的使用
• 了解各種生成物件以及宣告物件的方法，包含函式本身也是物件的概念。
• 了解 JavaScript 的比較運算子的意義，例如 ‘>’，‘<', '==', '===' 
• == 與 === 可以稍微簡單解釋一下
• == 會對運算元做完物件轉換（可能是隱性）之後再來做比較
• === 則不會做物件轉換，並且必須連同 type 也要相同才會被認為是 equal 
• 物件與陣列生成方式的不同

中階等級包含：

• 了解 timer 的使用，以及使用的時機以及使用的方式，比如用來當做非同步執行的方法。
• 譯者之前寫過一篇文章有稍微提到使用 timer 來達到非同步執行的一些技巧
• 深度了解 callback 以及 function 的使用，例如透過 call 以及 apply 兩個 function 函式來改變 context 以及 function 參數傳遞。
• 了解 JSON 表示法以及eval函式。
• 了解 closures，包含對於效率的影響，以及如何透過 (function(){}()) 達成 private變數。
• 了解 AJAX 以及 物件字串化。

進階等級包含：

• 了解  ‘arguments’ 以及如何利用 ‘arguments’ 以及 ‘arguments.length’ 達成function overloading。以及利用 arguments.callee 產生遞迴呼叫。特別要注意的是 arguments.callee 可能會有點問題因為 ECMAScript 5 Strict Mode 並沒有支援 callee。不過 jQuery以 及 Dojo 都有用到就是了。
• 進階的 closures 應用，例如 self-memorizing functions，currying，以及 partially applied functions。
• Function 與 html prototyping(prototype chain)，並且知道如何 reuse 既有的 JS Objects 與函式 (例如array)
• 物件型別，以 及 instanceof 與 typeof 的使用
• Regular expression
• with 敘述式，以及為什麼不應該用 with
• 最難的在於把所有這些串接在一起組成乾淨的強大的快速的好維護並且跨瀏覽器的程式碼

最後這一點尤其重要，並且也最難做到。在JS允許非常自由寬鬆的寫法的狀況下，你的code很容易就會變成一團混亂的無法維護的 ”spaghetti code” (譯註：大概是說你的code邏輯扭扭曲曲而且互相糾纏的意思)。一旦你真正的去學習JS，並且能夠結構化它並且把他們組合成一大型的 Web Application，那你就真的精通 JS 了。而這需要數年的練習，以及可能需要從『錯』中學習，並無法僅僅從書上學到。我自己本身每天使用 JavaScript 好幾個小時已經好幾年了，並且持續的找到一些更好的方法來結構化我的 code。貿然的直接去看一個 JS framework 是很危險的，因為 jQuery code 有點慢慢傾向難以維護的態勢 (譯者：最近有在研究 jQuery 原始碼，的確是很容易在裡面迷失，而且架構稍微不好懂，但至於是不是難以維護就見仁見智)。Dojo 則是提供了些支援透過他的 Class 與 Package 來幫忙結構化 JavaScript 程式碼。

在 Node.js 之後，JavaScript 已經從前端滲透到後端了，所以我決定把web相關的知識從以上的需求區隔開來。就是在 Web (也就是 DOM 與 IE) 這一塊給了 JS 一個不好的名聲，並且嚇到所有的Programmer。儘管如此。如果你正在學習 Web 方面的 JavaScript，身為一個好的開發者，有一些其他的事情你必須知道：

• 有效率的新增，移除，改變 DOM nodes。包含透過一些工具(例如，document fragments)來盡可能減少瀏覽器的 re-flows。
• 這一點在譯者之前的提升 JavaScript 的效能一文中有稍微提到。
• 以跨瀏覽器的方式去存取DOM元件的資訊。最後是透過一些既有的 jQuery/Dojo 框架。很重要的是必須了解來自 CSS 或是 style tag 或是運算過後的屬性之中的差異性。
• 跨瀏覽器的事件處理，繫結，反繫結，事件傳遞 (bubbling)，以及如何達到想要的 callback context。一樣，這些最後是透過既有的 framework 來做，但是開發者還是必須瞭解背後的原理。
• 譯者認為 event bubbling 是ㄧ個很重要的觀念，尤其如果一開始就很習慣使用 jQuery (或其他 framework) 在做 event binding 的時候很容易就忽略掉這一塊，但如果對 event bubbling 不了解的話很容易在 DOM element 有重疊的時候會出現一些自己無法預期，或是明明原本做得到，但卻因為不了解特性而繞路的做法。
• 擴充物件屬性 (expando) 與屬性設定 (attribute setting) 的差異，包含效能的差異以及既有同名屬性的差異。
• expando 的效率遠勝於 attribute setting ( 尤其在 IE 上)
• 用來抽取 DOM node 的 regular expression
• 其實譯者自己也對 regular expression 不熟 (慚愧)
• 有效的瀏覽器功能偵測以及適當的防錯機制

從以上的各點看來，JavaScript 除了 alert(myVal 以及 myBtn.onclick=… 之外還有非常多東西。在你的 copy/paste 的來源之外還有許多跟 JavaScript 相關的東西可以學習，而你必須透過閱讀以及練習來成為一個真正的 JavaScript programmer。有兩本很棒的書包含了以上所提到的你必須知道的JavaScript，一本是 Douglas Crockford 大師的著作：The Good Parts，另一本是jQuery作者  John Resign 的著作：Secrets of the JavaScript Ninja (譯者個人很推這本)。必須說由於每個人都有一個瀏覽器，JavaScript 大概是一個最容易可以取得(使用)的一個語言。建立一個簡單的 HTML 頁面，並且開始測試以上所提到的概念吧！至於履歷上的列表，我會說如果你已經瞭解基本等級的知識並且正往中階等級學習，那你就有資格把 JavaScript 列在你的履歷表上。一旦你開始開發你自己的 JavaScript 函式而不是只是 copy/paste，那麼你大概可以宣稱你懂 JavaScript。不過在那之前，請停止說你懂 JavaScript。

如果我有漏掉任何一個關於 JavaScript 的面向，請回覆讓我知道。並且請分享你的經驗關於任何你遇過宣稱懂得 JS 或是任何語言的人。

請注意到我並不是一個前端開發者，我其實是一個後端的開發者，並且也是 full-stack 開發者。現今，每一個後端開發者都需要學習 JavaScript，而這也正是我這篇文章想要鼓吹的事情。我並沒有想要顯示我似乎很厲害，因為我很難說我知道關於 JS 的任何一件事情。我想要的只是更多的人可以了解 JavaScript 是一個巨大並且強大的語言。

(Image source: http://ejohn.org/blog/javascript-performance-stack/)

PHP：一個亂七八糟的爛設計 - (III)

續前

上ㄧ篇陳述了對於 PHP 的立場。( 原本 PHP 這篇文章的 priority 比較低，但因為有讀者留言問有沒有續集，因此特地把 priority 先拉高 :) )

本篇文章翻譯自：PHP: a fractal of bad design

不要告訴我這些事情

我太常爭論 PHP 了，以至於我常常得到一些固定論點的反駁。而這些反駁大部分都是刻意用來想要終止對話用的。所以拜託，請不要再把這些論點丟給我，拜託 :(

• 不要告訴我好的程式設計師不管用什麼語言都可以寫出好的程式碼。這無法代表什麼。一個好的工匠也可以用石頭來敲釘子，但是有多少工匠會拿石頭來敲釘子？挑選好的工具也是一個好的程式設計師應該具備的技能。
  
  
• 不要告訴我記得一個程式語言的上千種例外狀況是一個程式設計師該做的事，我承認在任何系統上，這件事情都是對的，因為電腦很笨。但是這不代表一個程式語言的例外狀況可以無上限般的可笑。PHP 充斥着例外狀況，以至於花在語言本身的時間比寫出你要的程式的時間還多，這樣是不對的！
  
  
• 別告訴我 C 語言不就是這樣，那就去寫 C 吧。
  
  
• 不要告訴我是因為我把奇怪的東西放在一起而搞爛的。如果有兩個功能存在，一定有一天這兩個功能會被某個人放在一起。
  
  
• 不要告訴我 Facebook 跟 Wikipedia 的 backend 也是 PHP。他們也可以用其他狗屁語言寫，只要他們有夠聰明的人可以解決那些問題。
  
  
• 總之，不要告訴我任何事情。如果這個列表無法傷害你心中 PHP 的地位，那再也不會有任何事情可以。所以不要跟我爭了，把時間拿去寫一個超酷的網站，並再破紀錄的時間裡面完成，儘管證明我是錯的吧 :)
  

我愛 Python，如果你願意的話，我可以無止盡地告訴你我多愛 Python。但我並不是說 Python 是完美的，但 Python 的好處遠勝過它不好的地方。因此我認為 Python 是最適合採用在我目前想做的事情上。

PHP 系列文章：

PHP：一個亂七八糟的爛設計 - (I)

PHP：一個亂七八糟的爛設計 - (II)

python logging 做得好，維護沒煩惱

請訪問 iCoding Blog 主站 

跟 print 大法說再見

每次在寫程式的時候，我們一定會把程式運行中的訊息記錄下來。在 Python 中，我們很順手地，就會做下面這件事:

    print( "The program meets error %d" % error_code )

比如說，當我們遇到讓我們害怕的bug, 慌張的程師設計師一定會用 print 大法，開始到處印內部的變數。 當你開心地找出問題以後，你一定會很無力地看到不少無用的訊息噴出來....

懶惰的天性使然，一定會等到上線再來整理這些一團亂。

另外，程式中有許多有意義的指標，可以讓我們知道程式運行的狀態，你不會希望它們只是被  print 到螢幕上而已，資訊一定要好好地保存好，甚至是很專業地把log 傳送到 splunk 這種log 分析系統裡，程式才可以被清楚地掌握與管理。

說了這麼多，就是要你除了Business Logic 之外，程式裡面不要有無義意的 print。

請開始用 logging 模組

我們現在就開始用使用python logging 來印出資訊。

首先，用簡單一點的寫法，在你的程式的開頭，可以寫這段code.

import logging

logging.basicConfig(level=logging.DEBUG)

logger = logging.getLogger( __name__ )

這樣就好，沒有別的事情了。

然後，在你的程式中，依照你的需要，你可以寫出如下的 code

logger.debug( "enter the XXX function" )
logger.debug(" user exists 10000 ")

從此以後，你需要做的事就是把資訊，依照 debug, info, warning, error, critical 這些分類來把資訊印出來，像是前面的例子，你只要把第二行的 logging.basicConfig(level=logging.DEBUG) 中的 level 換成別的level: logging.basicConfig(level=logging.INFO)。這樣子的話，程式中為了除錯所加的 debug 訊息就不會再出現了。


不過，上面講的簡略的做法，只是讓你了解logging該怎麼使用，並且只是把 logger.debug 當做可依情況關閉的 print 來用而已，我們需要如下更有彈性的寫法。

這個寫法的原則很重要，請都用下面所說的想法來設計 logging 相關的程式:

1. 每個 module, class, 都用自已的logger, 當你寫的code, 是一個被人使用的module, 請不要去做多餘的設定。
2. logger 的名字為了要能方便找出問題，所以不要亂取，通常都是以 module 或是 class 的名稱來命名。
3. logging 的設定，由整個應用程式的main 函式來決定, 比如說決定該把log 寫到檔案或是將log 傳送到syslogd .我們目前是為了簡單好用才以 logging.basicConfig 當作例子。更實際的例子會用 logging.config.fileConfig. 

所以，當你寫一個 Utility 型式的程式的時候，你只要記好下面這三行code. 其它都不要多想。

import logging

logger = logging.getLogger( __name__ )

logger.debug( "XXX" )

 logging.basicConfig

講完了 Utility 該注意的事情了。你免不了要寫程式進入點。在這裡就是設定logger的地方, 但是python 的logger 由於很有彈性，所以有點複雜。看完了Python logging 的 Reference 以後，我們可要寫像下面落落長的設定才可以把log 寫到 standard error 

恩，要先弄懂 formater, handler。能先弄懂是很好，但若是第一時間弄不懂，你可以把那些設定換成 logging.basicConfig(level=logging.DEBUG) , 就像更前面的例子一樣。若是你想把log 導到檔案中的話，那就只要做一點修改: logging.basicConfig(filename='/tmp/logs', level=logging.DEBUG), 加上 filename 這個 argument就好。 記好 basicConfig 這個捷徑，logging 更快樂~

logging.config.fileConfig

為了更有彈性，更完整的功能，logging module 提供了 ini 檔的格式的設定檔。

有的時候我在想，連logging這件事情都要寫一個config 檔案，就覺得程式設計師好辛苦啊~ 不過苦歸苦，生活還是要過.....

在這裡不講logging 的config 檔怎麼寫，就只講 logging.config.fileConfig 這個function 該怎麼用。

這個function call 做的事還是設定logger, 所以它該出現的地方，跟 logging.basicConfig該出現的地方是一樣的。

不過，在 python 2.6 後，這個 function call 多了一個參數，叫做disable_existing_loggers，使用上，請把它設定成False, 但python 為了向後相容2.5版以前的python，把它的預設值設成了 True. 

如果照它的預設值 disable_existing_loggers=True 來執行的話，在這個function call 之前所get出來的logger,  如果沒有在 config file裡面設定過的話，就會被disable。也就是說，極容易發生你的 module 寫的log 都寫到空氣裡了。

所以，請這樣子用 fileConfig:

    logging.config.fileConfig('log_config_file", disable_existing_loggers=False)

如此，你才有機會看到各個 module 所寫出來的log。

最後

logging 有點複雜，但請熟悉一下這篇文章整理的做法，這樣才能在短時間寫出好維護的好Code!! 當然，還有很多不同的Style 來設定 logger, 如果有不同的Style, 也可以一起討論!

然後，幫強者我同學 Scott 廣告一下他的手機APP (真是不搭) http://blog.walkthisway.tw/post/27802609152/taiwan-host-bnb

人比人氣死人的開信率

晉明帝才幾歲時，坐在父親元帝膝上，有人從長安來，元帝問他洛陽那裡的消息，聽後流下了眼淚。明帝問父親因為什麼哭泣，元帝把晉朝東渡長江的意思詳細告訴了他，於是問他：「你認為長安比起太陽來哪一個遠？」明帝回答說：「太陽遠。沒聽說有人從太陽那邊來，顯然可知太陽遠。」元帝對他的回答感到驚異。第二天元帝召集許多臣僚舉行宴會，告訴他們上面這些意思，再次重新問明帝。明帝竟回答說：「太陽近。」元帝變了臉色，說：「你為什麼不同於昨天說的話呢？」明帝回答說：「抬頭只見太陽，不見長安。」《世說新語·夙惠》

常有朋友在問我開信率高低的問題，想要知道一般開信率大約是多少 ? 有人說開信率大約在 10% 左右就不容易了，也有人說至少要有20%以上吧 ? 那到底多少 %才算合理呢 ?

真正的問題在於開信率本來就不該和別人比

如果你知道影響開信率的原因，你就知道和別人比開信率真是一點也不理智，讓我來為大家介紹以下幾點會影響開信率的因素：

名單的取得方式

如果是透過買來的，有絕大部份是無效的名單，就算是有效的，也不一定喜歡你的產品或服務，想當然的開信率就會比較低。但如果是會員自行提供的，他本來就對你的產品或服務有興趣也有信任感，所以開信率就會比較高。

名單取得的時間

你說名單都是會員自行提供的，那取得的時間也有差，如果你的名單是半年內收集來的，開信率就會比較高，但如果是累積一、二年以上，其實已經有很多的名單已經失效了，所以開信率就會低很多。

寄進去收件匣

當然啦，如果你的電子報跑到會員的垃圾郵件，那看都看不到，更別說開信了。

電子報的主旨及"第一段"內容

當你好不容易把電子報寄到會員的收件匣中，卻淹沒在滿滿的電子郵件裡，該如何脫引而出呢? 當然第一眼看到的就是主旨，所以主旨寫的好很重要。而現在很多收信軟體、手機、平板電腦都有提供郵件預覽的功能，所以除了主旨以外，你也可以加強"第一段"的內容。

寄送的時間

你的會員通常是早上開信呢? 還是中午開信? 還是晚上開信? 到底是平常日開信比較多? 還是假日開信比較多? 不同的客群都有不同的習慣，說寄信也要看時辰真是一點也不為過。

這樣大家明白了吧，當比較的基準點不同時，開信率是很難和別人比較的，如果你真的要比就是和自己比，然後根據以上各點再來作調整，慢慢提高自己的開信率，進而提高自己的 RPE 囉。

(Photo via marcelleitner bilderleben.at, CC License)