在套用第三方API時，像是從Facebook撈資料、從Google撈資料、從Twitter撈資料，在驗證身份的流程中，通常第三方會要求你去登記、並設定一個redirect的網址。

以我的經驗來說，Facebook跟Google在這方面是比較友善的，網址可以設定為localhost，在本機開發與測試很方便。

但是像Yahoo跟Microsoft就比較嚴格：他們不接受localhost

這時候該怎麼辦呢？

我找到的solution是這個：

Ngrok

安裝與使用非常容易，我Ubuntu下載完之後，只輸入兩行指令

$ unzip /path/to/ngrok.zip

$ ./ngrok 80

就得到一個公開網址了。

Tunnel Status online
Version 1.3/1.3
Forwarding http://3a4bfceb.ngrok.com -> 127.0.0.1:80
Forwarding https://3a4bfceb.ngrok.com -> 127.0.0.1:80
Web Interface http://127.0.0.1:4040
# Conn 0
Avg Conn Time 0.00ms

他會將送到http://3a4bfceb.ngrok.com（每個人會有一個隨機網址）的request全部轉送到本機的server，實在非常方便。

（Photo via Ngrok）

許多網站實作會員系統時，會開發「用facebook登入」功能，或是註冊過程中套入facebook資料、減少使用者註冊的麻煩。

開發人員通常會覺得，至少拿得到email，對吧？

其實不然。就算使用者同意授權還是可能拿不到。

Facebook API有針對email欄位寫下這段：

This person’s primary email address listed on their profile. This field will not be returned if no valid email address is available.

所以，跟臉書拿資料時，不要用email欄位來判斷是否從facebook拿到資料了，用id欄位。也不要直接用email欄位去判斷使用者是否註冊過。

真的硬要寫入email有一個solution：臉書就算不給你email，若是有回傳username就將email存[username]@facebook.com、
連username都沒有就存[id]@facebook.com

臉書會將收到的信轉寄給使用者信箱。
注意：不是存進臉書收件匣，是轉寄到使用者的主要信箱。臉書政策改過。

http://www.theverge.com/2014/2/24/5443454/facebook-retires-its-email-service

注意：經我測試，有username就不能寄信到[id]@facebook.com，會失敗。

根據國外開發者的回報，他們的會員大約有0.1% – 2%有這個情形。

大家都以為至少能從臉書拿到email，這導致了一個國際級常見bug吧。

臉書工程師的解釋如下：

There are a number of circumstances in which you may think a user should have an email address returned but they will not. For privacy and security reasons it is not possible to elaborate on the precise reason any specific user’s email address will not be returned so please do not ask.

Some possible reasons:
No Email address on account
No confirmed email address on account
No verified email address on account
User entered a security checkpoint which required them to reconfirm their email address and they have not yet done so
Users’s email address is unreachable

可以參見以下文章的討論：

http://stackoverflow.com/questions/9347104/register-with-facebook-sometimes-doesnt-provide-email

最近分析Codeigniter框架的原始碼，開始思考一件事情：

一個框架的各個元件，是否應該要盡量能夠獨立於框架之外？

有人認為，框架的元件本來就附屬於框架之下，不需要也不應該獨立於框架之外使用。

我個人認為，只要是類別就應該盡量降低相依性，這樣重用性、擴充性、可讀性才高。

開始討論這個問題之前，我想先引用某位PHP programmer的一段話：

「所有框架都很爛！」（They All suck!）

http://www.phpclasses.org/blog/post/226-4-Reasons-Why-All-PHP-Frameworks-Suck.html

主要理由如下：

• 同樣的code非必要地不斷重複執行
• 需要太多相依的類別
• 非必要的複雜解法
• 重複做了伺服器提供的功能

他點出了框架的幾個缺陷。

我認為期待各元件能彼此獨立很好、不期待各元件能彼此獨立也沒錯。這似乎是一個個人喜好的問題，而沒有對錯之分。

下面是我認為正方以及反方的論點。

為什麼框架的元件應該可以搬出框架之外使用？

我認為，如果框架底下的元件相依性很低，那麼當開發者只喜歡其中幾個功能、而不喜歡整個框架的時候，便可以把元件搬到外面，另外拼裝或是手刻一個自用的framework。

若是框架能夠做到這樣，則上述PHP programmer的四項批評便幾乎不再是問題。

反之，像CI這種core功能嚴重相依的框架，則只能選擇全盤接受、或是不使用CI。

另外，也可以理解為某個功能在PHP的世界被創造過，你不應該重新創造、也不應該創造不能被重新使用的類別。這不正是物件導向程式設計的一個重點嗎？

為什麼框架的元件不應該搬出框架之外使用？

框架本身就代表了底下的眾多「元件」，以及某一種「使用這些元件的方式」。

以CI來說，許多元件使用了全域函數去讀取類別(load_class函數)、讀取config值(config_item函數)、記錄log訊息(log_message函數)、計算執行時間(benchmark類別)，等等。

CI的元件本來就預設在CI之下使用，所以這樣設計確實很方便。否則為了能讓元件搬出去使用，要加上一大堆dependency injection技法、一堆地方要寫得比較general、彈性，也是麻煩。

話說如此，某些程度還是能同時兼顧所有優點的。例如Laravel的Eloquent ORM，在框架之內很優秀，搬出去用依然出色。

關於我對CI架構的批評，可參考：

http://howtomakeaturn.github.io/ci/common.html

http://howtomakeaturn.github.io/ci/output.html

(Photo via Akira ASKR, CC licensed)

利用Codeigniter工作半年了，最近想深入了解CI框架的底層運作。

找了朋友一起，打算把整份source code讀過一遍，並且加上我們的一些解釋與批評。

http://howtomakeaturn.github.io/ci/menu

寫了幾份review之後，慢慢理解了一些對CI的批評是從何而來。
我目前看到最討厭的部份是core/common.php定義了大量的全域函數。
最可怕的是定義了load_class函數來負責載入絕大部分的類別。
這直接導致：
1、無法在建構式傳入參數
2、呼叫載入的類別要寫$URI =& load_class(‘URI’, ‘core’)，真的很醜
3、所有相關類別因此都嚴重相依，無法把元件獨立出去在CI之外使用

另外，我還發現部份類別並沒有專注在「一個任務上」。

例如Output類別裡面有計算benchmark相關的code，違反了single responsibility principle，增加了維護與理解的難度。

也因此，整體說來，source code並不好讀。

目前只review了一小部份，還會繼續下去。

想收集更多意見並且與大家討論，希望有興趣研究codeigniter原始碼的朋友，一起加入我們：）

https://github.com/howtomakeaturn/Analyze-Codeigniter

(Photo via ecstaticist, CC licensed)