應該蠻多人會直接點下很明顯的「以 XX 的身份繼續」亮藍色按鈕，因為這樣才能繼續使用這個應用程式，不過，當按下「以 XX 的身份繼續」後，就表示應用程式可以從 Facebook 取得你所同意的資料，以這個例子，Vonvon 應用程式能取得你的姓名、大頭貼照、年齡、性別跟你所公開的資訊，另外還包括在 Facebook 中上傳以及被標註的照片、電子郵件。
到 Vonvon 的網站會看到有許多各式各樣的應用程式，為什麼 VonVon 要開發這些所謂有趣的應用程式？這應該可以從 VonVon 關於頁面 https://tw.vonvon.me/about 得知是做分析資料販售的，至於是不是會把可以識別出個人（也就是知道是你是誰）的資料售出？在他們的隱私權政策的第 5 點有提到是不會 “Otherwise, we will never sell or disclose user data to a third party in a personally identifiable way.“，當然，這也希望 Vonvon 能夠守信用 XDD，只不過在這次 Facebook 與 Cambridge Analytica 的事件後，使用這類型的應用程式能更再思考幾秒，真的要把你的資料授權給第三方使用嗎？ 繼續閱讀 “你我正在被追蹤？”→
Laravel Logo 圖片來源：https://github.com/laravel/art/blob/master/laravel-l-slant.png Drupal Logo 圖片來源：https://www.drupal.org/about/media-kit/logos
在爬文章的時候看到一則是討論 Drupal 8 與 Laravel－Drupal Vs. Laravel，看到當天晚上就把一些想法發表回應到文章下面，可是作者遲遲還沒有允許張貼，這幾天一樣跑去看那篇文章看，還是沒被公開發佈，就先把回應寫在自己的部落格上。（現在，作者已經公布了）
以下是我回應給作者的內容（有改了一些拼字、文法錯誤…）
Berfore starting to build and develop Drupal sites for over 1 year, I use Laravel framework. I think in some website types, eg. media and content, Drupal is more suitable. Because, in Drupal 7/8, the ImageStyle is powerful, it can process different image size for different device screens. Especially, in Drupal 8, the cache system allows to control the cache of page easily and flexible.
In the beginning of developing Drupal 7, I cannot accept and realize the configurations are in database. Although, the features module can help export the configs into code. Sometimes, when deploying into production or stage site, the exported features may break or encounter the different tid. In Laravel, all configs are in code. When deploying, developers only pull the branch and set the config values into environment variables.
Sometimes, I hate to take much time to work on the customized displays or modifying forms in Drupal, since in Laravel or others development, I only need to change HTML or blade. In Drupal, I should implement hook functions to alter rener array or Form API.
BTW, I prefer Drupal 8, due to OO design, new config management, service container, plugins system, event listener, routing and so on. They provides more structural ways to maintain and develop.
最近時常想到 The Effective Engineer 裡面有一章提到的－Validate Your Ideas Early and Often（隨便翻：儘早、經常的驗證想法），介紹的第一個例子是曾經有一家可能被視為 Google 搜尋引擎競爭者的公司 Cuil，當時宣稱有超過 12 億的網頁被索引，是 Google 的 3 倍多，Cuil 也是花了幾年的時間在開發爬蟲、索引，因為當時（約 2008 年）沒有普遍的雲端主機服務像 AWS，所以也自己利用硬體資源建立幾千台的伺服器 infrastructure。但是他們在發表之後遭受許多知名媒體的批評，像是 PC Magazine 用了 “buggy”, “slow”, “pathetic” 的字來形容，在上線的時候，Cuil 的服務遇到了多次當機，最後，Cuil 失敗了。
之前的工作，其中有一個專案是開發管理志工的系統，自己花了很多力氣在系統開發，默默地寫了實作程式、測試程式、建立自動化的腳本，把開發流程跟 CI 結合，完成後，老闆才發現需要修改與實作的功能不是他們想要的。回想那段時間，當每週開會，老闆問到專案進度，只是告訴老闆完成了哪些部分，或正在開發、快完成了，到接近預計時間，才把自己認為完成的成果給老闆或同事看，在那個時候，才發現在實做出來的功能或做法，跟其他人原本認爲的完全不一樣。過一陣子回想起來，在每週開會的時候，要向老闆 demo 開發的功能，來確認實作的功能是不是走在正確的軌道上，也能夠讓老闆對完成後的系統有更清楚的了解。
