HTML5 Word Cloud to lost access to Facebook News Feed on April 30th, 2015

Since v2.x SDK, Facebook require apps to go through Login Review process if the app need to access to News Feed. I tried to submit HTML5 Word Cloud two times but repetitively I got the same response:

read_stream – Unapproved

The read_stream permission is only approved for apps that let people use Facebook on platforms where Facebook is not already available.
If you’re building an app on Android and iOS, for example, you won’t be approved for this permission. Web, Desktop and TV apps will also not be granted this permission.

With v1.0 SDK to be turn off on April 30th, 2015, that means the app will lost it’s ability to access people’s News Feed on that date.

HTML5 Word Cloud is a Web technology demonstration, it uses JavaScript/DOM to render user input in a tag cloud, all within the browser. No user data is collected because user data never leaves the browser. It’s all written in the privacy statement, and the code base is open sourced.

If you think this app deserves access to News Feed and you happen to know someone who could help, please point them to this post. Thank you.


Facebook 將於 2015 年 4 月 30 日停止提供動態時報內容給 HTML5 文字雲

v2.x SDK 要求 Facebook 應用程式經過登入權限審核才能使用動態時報內容。我試著升級 HTML5 文字雲從 v1.0 SDK 到 v2.x 並申請審核兩次,但是兩次的審核都被拒絕。因 v1.0 SDK 將於 2015 年 4 月 30 日關閉,屆時文字雲將無法再提供產生 Facebook 動態時報的服務。

HTML5 文字雲是一個 Web 技術示範,它使用瀏覽器處理內容,提供另一種不同的呈現。使用者的資料不會離開他的電腦。這些都完整的解釋在隱私權保護聲明,程式碼也可供檢視

若您認為 HTML5 文字雲值得繼續取得動態時報內容,且您知道有人可以幫忙的話,請將這篇文章傳給他們。感謝。

Tim’s Dream for the Web

Even before I get myself this username (timdream) and polluted the search result, search result of that term will give you a link to on LogicError, appropriated titled “Tim’s Dream for the Web”. That “Tim” was Sir Tim Berners-Lee, and he imagines the Web to be the powerful means for collaboration between not only people, but machines.

Weaving the Web, credit: W3C.

Weaving the Web, credit: W3C.

Collaboration between people has been closer than ever because of the Web. It have already grew closer thanks to the technologies set branded as “HTML5”, and the technologies will only grew stronger, hopefully beyond the catchphrase. As of the machines, a form of Semantic Web is indeed slowly emerging, but not in the ideal open, collaborative way and in a more top-down, proprietary approach, limited to the centralized design in which many are asked to interface with few proprietary platforms who encapsulates all data.

It’s a good thing for people to start enjoying what it is possible when the data is linked — yet, having them linked in a more open way while safeguarding our privacy remain the work to be done. This week we saw the 20th anniversary of W3C, and the HTML5 spec reaches Recommendation status — the events themselves are testimony of the rough history of the Web. I remain cautiously optimistic on this one — the organizations rally on this front is largely intact, and people will, eventually more aware of the danger when as they enjoy the convenience of the technologies.


The LogicError page was in my bookmark since a long time ago, like Firefox 0.8-ish, but not until now I realized LogicError is in fact an Aaron Swartz project. The footnote itself, with the name, kind of say something.

Constructor Function:JavaScript 設計模式的返璞歸真

JavaScript 是個瘋狂的語言,語言本身非常隨便自由,從不試圖引導程式設計師遵守特定的模式。我參與的 Gaia Project 無論是商業需求或是架構上也是很瘋狂的;試圖用 Web 湊出一個手機介面以及功能,但同時間新需求又來的又快又急。在一開始的幾年,我們一直沒有機會慢下腳步,想想每個人喜歡用的 module pattern、singleton pattern 等等是不是符合未來的需求。但最近一年以來,幾位同事終於慢慢的意識到,使用 JavaScript 一開始發明時提供的 constructor function pattern,才是最安全,符合最多 use case 的作法。以下整理我認為的幾個關鍵的優點,供各位參考:

優點 1:沒有封裝(encapsulation)

許多人認為沒有封裝,曝露實作細節是一個缺點,但我認為不做任何封裝的益處比壞處更多。直覺上大家會認為 JavaScript 元件需要封裝,是因為大家習慣使用黑盒子式的 library (例如 jQuery)。jQuery 作為一個灑到外面給大眾使用的函式庫,隱藏細節來保留未來升級的空間是有必要的。但在自己或是協作專案中,藉由封裝來防禦這樣的「使用者」是沒有必要的——大不了就是開一張票給同事請他改掉。若有試著閱讀過 jQuery 程式碼和 build system 的朋友,也會發現,jQuery 專案本身各 function 在它內部的 scope 也是攤平,獨立測試的。與其用封裝作防禦,不如用完整的測試來定義 public method 的行為;這就要談下一個優點。

優點 2:可測試性

Test-Driven Development 似乎非常流行,但我們得承認不是所有的元件都有清晰的需求與憑空定義的 interface,可以先開完會、冥想一下,然後寫完測試,凍結測試再開工。元件的形狀與介面勢必是個隨著需求或是撰寫過程發現的 edge case 而演化出來的。在 Gaia 開發的歷史一開始是不要求單元測試(unit test)的;許多使用封裝模式設計的元件隨著需求慢慢的長大,長到最後發現無法切出可測試的獨立單元。如果使用 constructor function,就可以保證永遠找的到可測試的單元:「單元」可以是掛在 prototype 上的一個方法,也可以直接測試一個 instance。我個人的習慣是測試 instance,原因如下。

優點 3:各 instance 與 prototype 預設是分離的

Gaia 開發的歷史,遭遇的另一個問題是,許多元件都被設計成在環境中只會被使用一次。這樣的元件,勢必沒有可供單元測試項目獨立使用的 instance。當時最後使用的醜陋解法是確定測試時會改變的 state property,在每個測試的 teardown() 將它重設,但更絕望的是有些元件的 state 根本就封裝在自己的 scope 內,這就完全沒救而且嚴重的傷害的我們的測試涵蓋率。分析哪個 property 是 state 也一個手動而且容易出錯的過程。若當初使用 constructor function,每個 instance 就可以是用完即丟的測試單元,另外,console.log(instance) (或是 JSON.stringify(instance))可以直接印出 instance 上面的所有被設定的 property,跟它的 prototype 上的 property 或是 method 完全切開。

但在這邊要注意的是每個 instance 不會真的用完即丟,尤其是和 DOM API 有互動的元件。我們最後定義了一組通用的 method 名稱,要求元件都要有 stop() method 讓 instance 把自己從 DOM 上分離下來。

優點 4:「天然的感覺」

懂 JavaScript 的 prototype inheritance 老實說就跟日文的五段動詞一樣,大家學的時候都知道好像要學到那邊才算學會了什麼,但是在那之前總是卡一堆人(苦笑)。Prototype inheritance(或是簡單的,constructor 與 instance 的關係)在學習曲線上的問題是看起來沒有實際的例子可以參考,object 內部的繼承關聯也沒有被 JavaScript Engine 暴露出來。但這件事情在 ECMAScript 5 之後已經有了改善;我們現在有 Object.create()Object.getPrototypeOf(),還有原本就有的 constructor 屬性與 instanceof 運算子。要找實際的例子就更令人例外了:其實大家每天使用的 DOM API 都只是某個 constructor 的 instance,本身沒有 method,執行的時候其實是執行它的 prototype 上的 method;不相信的話,打開 console 看看 Object.getPrototypeOf(navigator) 是回傳哪個 object,或是 navigator.constructornavigator.constructor.prototype 是什麼。

(玩完之後你會發現 Object.getPrototypeOf(navigator)navigator.constructor.prototype 都會指到一個名為 NavigatorPrototype 的 object,navigator.constructor 會是一個 constructor function。不過執行它不會得到新的 navigator object 而是會 throw。你也不能 new window.constructor() 或是 new Window() 得到另一個 window object。)

總之,無論元件們最後是要從相依性來層層呼叫 new 建立出來,還是偽裝成 DOM API 掛在 window 或是 navigator 底下,實際運作的 object 都應該是 instance 而不是 object dict,因為你所仰賴的 DOM API 就是這樣實作的。從這裡出發也更容易看出與操作 this 關鍵字所指向的 object,進而寫出乾淨的程式碼(例如實作 EventListener interface)。這是我所謂「天然的感覺」。

結語

以上大略是我們選擇 constructor function 建構元件的理由。當然,沒有任何技術分享或是 framework 是適用所有專案的,請保持求真的精神,尋找您自己的真理。


P.S. 圖片跟這篇文章真的沒有關係。