訂閱

上次更新

April 02, 2015 12:00 AM

所有時間皆為協調世界時(UTC)。

Powered By

Planet

摩茲星球 | MozTW Planet

這邊是工作人員碎碎念的地方,您可獲得最新出爐的資訊以及最不成形的想法 :P

March 30, 2015

timdream

Service Worker and the grand re-architecture proposal of Firefox OS Gaia

TL;DR: Service Worker, a new Web API, can be used as a mean to re-engineering client-side web applications, and a departure from the single-page web application paradigm. Detail of realizing that is being experimented on Gaia and proposed. In Gaia, particularly, “hosted packaged app” is served as a new iteration of security model work to make sure Service Workers work with Gaia.

Last week, I spent an entire week, in face-to-face meetings, going through the technical plans of re-architecture Gaia apps, the web applications that powers the front-end of Firefox OS, and the management plan on resourcing and deployment. Given the there were only a few of developers in the meeting and the public promise of “the new architecture”, I think it’s make sense to do a recap on what’s being proposed and what are the challenges already foreseen.

Using Service Worker

Before dive into the re-architecture plan, we need to explain what Service Worker is. From a boarder perspective, Service Worker can be understood as simply a browser feature/Web API that allow web developers to insert a JavaScript-implemented proxy between the server content and the actual page shown. It is the latest piece of sexy Web technologies that is heavily marketed by Google. The platform engineering team of Mozilla is devoting to ship it as well.

Many things previously not possible can be done with the worker proxy. For starter, it could replace AppCache while keeping the flexibility of managing cache in the hand of the app. The “flexibility” bits is the part where it gets interesting — theologically everything not touching the DOM can be moved into the worker — effectively re-creating the server-client architecture without a real remote HTTP server.

The Gaia Re-architecture Plan

Indeed, that’s what the proponent of the re-architecture is aiming for — my colleagues, mostly whom based in Paris, proposed such architecture as the 2015 iteration/departure of “traditional” single-page web application. What’s more, the intention is to create a framework where the backend, or “server” part of the code, to be individually contained in their own worker threads, with strong interface definitions to achieve maximum reusability of these components — much like Web APIs themselves, if I understand it correctly.

It does not, however, tie to a specific front-end framework. User of the proposed framework should be free to use any of the strategy she/he feel comfortable with — the UI can be as hardcore as entirely rendered in WebGL, or simply plain HTML/CSS/jQuery.

The plan is made public on a Wiki page, where I expect there will be changes as progress being made. This post intentionally does not cover many of the features the architecture promise to unlock, in favor of fresh contents (as opposed of copy-edit) so I recommend readers to check out the page.

Technical Challenges around using Service Workers

There are two major technical challenges: one is the possible performance (memory and cold-launch time) impact to fit this multi-thread framework and it’s binding middleware in to a phone, the other is the security model changes needed to make the framework usable in Gaia.

To speak about the backend, “server” side, the one key difference between real remote servers and workers is one lives in data centers with endless power supply, and the other depend on your phone battery. Remote servers can push constructed HTML as soon as possible, but for an local web app backed by workers, it might need to wait for the worker to spin up. For that the architecture might be depend on yet another out-of-spec feature of Service Worker, a cache that the worker thread have control of. The browser should render these pre-constructed HTML without waiting for the worker to launch.

Without considering the cache feature, and considering the memory usage, we kind of get to a point where we can only say for sure on performance, once there is a implementation to measure. The other solution the architecture proposed to workaround that on low-end phones would be to “merge back” the back-end code into one single thread, although I personally suspect the risk of timing issues, as essentially doing so would require the implementation to simulate multi-threading in one single thread. We would just have to wait for the real implementation.

The security model part is really tricky. Gaia currently exists as packaged zips shipped in the phone and updates with OTA images, pinning the Gecko version it ships along with. Packaging is one piece of sad workaround since Firefox OS v1.0 — the primary reasons of doing so are (1) we want to make sure proprietary APIs does not pollute the general Web and (2) we want a trusted 3rd-party (Mozilla) to involve in security decisions for users by check and sign contents.

The current Gecko implementation of Service Worker does not work with the classic packaged apps which serve from an app: URL. Incidentally, the app: URL something we feel not webby enough so we try to get rid off. The proposal of the week is called “hosted packaged apps”, which serve packages from the real, remote Web and allow references of content in the package directly with a special path syntax. We can’t get rid of packages yet because of the reasons stated above, but serving content from HTTP should allow us to use Service Worker from the trusted contents, i.e. Gaia.

One thing to note about this mix is that a signed package means it is offline by default by it’s own right, and it’s updates must be signed as well. The Service Worker spec will be violated a bit in order to make them work well — it’s a detail currently being work out.

Technical Challenges on the proposed implementation

As already mentioned on the paragraph on Service Worker challenges, one worker might introduce performance issue, let along many workers. With each worker threads, it would imply memory usage as well. For that the proposal is for the framework to control the start up and shut down threads (i.e. part of the app) as necessary. But again, we will have to wait for the implementation and evaluate it.

The proposed framework asks for restriction of Web API access to “back-end” only, to decouple UI with the front-end as far as possible. However, having little Web APIs available in the worker threads will be a problem. The framework proposes to workaround it with a message routing bus and send the calls back to the UI thread, and asking Gecko to implement APIs to workers from time to time.

As an abstraction to platform worker threads and attempt to abstract platform/component changes, the architecture deserves special attention on classic abstraction problems: abstraction eventually leaks, and abstraction always comes with overhead, whether is runtime performance overhead, or human costs on learning the abstraction or debugging. I am not the expert; Joel is.

Technical Challenges on enabling Gaia

Arguably, Gaia is one of the topmost complex web projects in the industry. We inherit a strong Mozilla tradition on continuous integration. The architecture proposal call for a strong separation between front-end application codebase and the back-end application codebase — includes separate integration between two when build for different form factors. The integration plan, itself, is something worthy to rethink along to meet such requirement.

With hosted packaged apps, the architecture proposal unlocks the possibility to deploy Gaia from the Web, instead of always ships with the OTA image. How to match Gaia/Gecko version all the way to every Nightly builds is something to figure out too.

Conclusion

Given everything is in flux and the immense amount of work (as outlined above), it’s hard to achieve any of the end goals without prioritizing the internals and land/deploy them separately. From last week, it’s already concluded parts of security model changes will be blocking Service Worker usage in signed package — we’ll would need to identify the part and resolve it first. It’s also important to make sure the implementation does not suffer any performance issue before deploy the code and start the major work of revamping every app. We should be able to figure out a scaled-back version of the work and realizing that first.

If we could plan and manage the work properly, I remain optimistic on the technical outcome of the architecture proposal. I trust my colleagues, particularly whom make the architecture proposal, to make reasonable technical judgements. It’s been years since the introduction of single-page web application — it’s indeed worthy to rethink what’s possible if we depart from it.

The key here is trying not to do all the things at once, strength what working and amend what’s not, along the process of making the proposal into a usable implementation.

Edit: This post have since been modified to fix some of the grammar errors.

by timdream at March 30, 2015 10:39 PM

Othree

ECMAScript 6 Final Draft Approved

剛剛看到說 ECMAScript 2015(ES6) 定稿了,最後一版草稿是 RC4(還沒 release),接下來會是 ECMA 認證流程的樣子,不過繼續下一版的討論也不會中斷,順便要說一下他們最後 approve 的地方是在 H.R. Giger 博物館的酒吧,超酷的,這是畫異形那位大師的博物館。

March 30, 2015 10:34 AM

March 28, 2015

Othree

For the Entire Web

這陣子有兩件事情引起我的一些注意,覺得值得寫下,兩件事情我覺得其實是根本上是同一件事情,先來看一下第一件事情,就是 Daniel Yoder 寫了篇文章 React Is A Terrible Idea,這篇文章在 React 當紅的時間出現,自然引起很多人的不滿,隨便在 Google 上搜尋就可以找到一堆回應,我自己對於 React 其實是沒特別感覺,沒有喜歡也沒有覺得它做錯什麼,真的要說的話大概還有點覺得它方向正確,我是認為 React 和 Angular 的 directive 都在把 component 的觀念引入前端工程師的視野之中,而這對於 Web Component 的發展應該會是有正面影響的。

再回到 Terriable Idea 這篇文章,作者對 React 的評論我其實不完全認同,最後面有提到用 Web Component 而不要用 React,這部分我覺得是作者誤會了 React 的角色,不過有些地方有人說 React 明明就可以和 Web Component 合作,還附上 ng-conf 的演講影片,我到覺得他們也完全沒搞清楚作者的重點在哪裡;提到 Flipboard 的 react-canvas 那部分算是我認為最能表現出作者想要講什麼的,作者想說的重點是現在的網路環境有限制、有問題,但是遇到時不要用一些旁門左道的方法來處理,因為這些問題終究會被解決,而問題被解決時,你之前所花的時間和資源就等於是完全浪費掉,與其要浪費在走旁門左道,還不如把這些時間和資源用在從正確的地方解決這個問題,而最後受惠的不只是自己,還有所有網際網路的開發者、使用者,這是從一個很高等生命體的角度來看事情,就如同這篇文章的標題:「For the Entire Web」,要你犧牲自己的部分利益去成就整體網際網路的利益,當然這是有些理想化,很多商業公司可能要短時間就有產品出來,不太可能所有的開發在遇到問題時都停下來等瀏覽器或是標準齊備,但是對於不少的大型企業,我就覺得他們確實應該要好好正確的回饋網路環境來解決這些問題,像是文中提到 Facebook,還有接下來要說的 Google,不過他說 Facebook 是為了和 Google 競爭才開發 React 之類的論點我就不予評論了,太多臆測~

可能有人會說,有沒有這些資源的投入應該差距也不大吧,最近就剛好有另外一件事情可以佐證,Dart for the Entire Web 這篇 Dart 官方的公告說到,Dart VM 將不會進入到 Chrome 裡面,也就是說要在瀏覽器上跑 Dart,將還是只有轉成 JavaScript 這個選項,這件事其實是蠻大的一件事,上一個在網頁裡面跑的另外一種語言是微軟的 VBScript,最大的問題不在於好不好寫,而是在於他被單一企業把持,不過後來結果大家也都知道,所以當 Google 推出 Dart 而且說以後 Chrome 會可以直接跑 Dart 的時候,我想大部分人都是都不看好的,甚至部分人是覺得 Google 怎麼為做微軟做過的蠢事。而剛好在這個官方公告出來後幾天內,Brendan Eich 在 Hacker News 上回應一串討論回應的蠻激動的,這串本來是在說 ECMAScript 新版本有很多東西根本是從 Dart 來的,Brendan Eich 則是反駁說很多東西在 Dart 出來前就已經在討論有 Proposal 了,然後到後來寫了一篇幾乎都在抱怨 Dart,還提到 V8 team reset 的事情,從這邊看起來,似乎是因為新的 V8 team 不打算作 Dart VM 進去,才有了 Dart 那篇公告;而 Brendan Eich 抱怨的重點,其實就是前面那段提到的,Google 花了超多人力資源去搞 Dart,而不是來幫忙改進既有的 ECMAScript,而這確實有實際的影響,他舉了一個例子,就是大數(bignums)的支援,Dart 有支援,在 ES 這邊目前有一點可能性會在 ES7(2016) 中出來,但這東西其實從 2010 就已經開始有討論了,如果有人來將這些討論規格化,並實做起來,那大數應該在現在的 ES6(2015) 就有了。

最後再回到 Terriable Idea 這篇文章,我雖然不完全認同他對 React 的看法,但是我認為他的重點沒錯,如果他拿 Dart 出來講可能就不會引出這麼多砲火吧(可是可能也比較沒人注意),其實 react-canvas 我覺得也是很有趣的實驗,不過做成正式產品上線就是另外一回事了,最大的問題,他完全放棄了親和力的問題,而 Flipboard 這種內容為主的產品性質是不該放棄親和力的。

March 28, 2015 05:25 AM

March 27, 2015

MozLinks-zh

新版 Firefox 設定頁網味十足

另外一個很棒的 Firefox 改變就要來了!

到目前為止,「Firefox 偏好設定」的長相一直是一堆累贅的視窗組成,幾乎沒可能在其中找到想要的設定。這是典型的軟體問題:隨著程式增加新功能,相關的設定直接加進原本的介面,讓已經很複雜的設定介面隨之膨脹,變得更加複雜。


這個亂七八糟的東西,就是現在的 Firefox 偏好設定介面

終於,新的契機來了!

Firefox UX 團隊興奮地向大家宣佈,全新的美麗設定頁面,已經成為 Nightly 版本的預設值,很快就會在釋出版中出現了。在這個新設計中,有一致的視覺元素、精進的資訊架構,所有的東西都在內頁中呈現,不需另開視窗。


新的 Firefox 設定頁

為什麼把設定放在內頁中,不另開視窗很重要呢?

  1. 跨裝置的一致性:使用內頁呈現,讓我們不再需要仰賴裝置繪製獨立的對話框與視窗。這對平板與手機來說格外重要,因為要在上面很難進行視窗管理。今後,Firefox 行動版的使用者在使用桌面版時,就會看到熟悉的介面,反之亦然。

  2. 跨系統的一致性:Windows、OSX 與 Linux 處理新視窗與對話框的方式都不一樣,這表示在不同的作業系統上,設定頁的使用體驗也不同。在 Firefox 內繪製設定頁,我們可以讓不同系統呈現一致的視覺體驗。

  3. 與網路的一致性:某方面來說,瀏覽器就是網路的門戶。如果表現得跟充滿對話框的傳統應用程式一樣,就太落伍了。用網頁做設定頁的優點,讓使用者不需在現有分頁之外另開視窗,而破壞體驗。

  4. 可擴充性:不被小小的浮動視窗限制,意謂我們可以創造更豐富的客製化體驗。附加元件管理員已在先前轉換成內容頁面,讓我們得以實驗更豐富的使用體驗。同樣的,請期待偏好設定畫面上更多的創新設計應用吧!

未看先回:是的,下一步就是在設定頁上增加搜尋功能。為了能讓你精確的召喚出想要的那個選項,而無須「學習」我們的介面,這是一定要的啦!

在此特別感謝資深視覺設計師 Michael Maslaney,它是變色龍專案的先鋒,制定此次改版的風格指南。另外感謝密西根州立大學的學生 Owen Carpenter、Joe Chan、Jon Rietveld 與 Devan Sayles,他們在 2012 年 5 月提出了獲獎內頁偏好設定設計初版

原文 / Firefox’s Redesigned Preferences Feel More like the Web | Mozilla UX
作者 / Jennifer Morrow
授權 / 創用 CC 姓名標示-相同方式分享-3.0
刊載日期 / 2014/5/23

φ Mika 翻譯 - Irvin 編輯

by Irvin Chen (noreply@blogger.com) at March 27, 2015 01:02 PM

March 20, 2015

MozLinks-zh

究竟…結果出爐了

數百萬人參與了「我們想要的網路」投票活動(一張票,一世情;感謝支持!),表達你們認為網路的未來最重要的是什麼事。

結果已經出爐…排在首位的是隱私保護—對我們而言這特別重要。事實上,這是我們的核心價值之一。

我們不只相信你擁有在線上保有隱私的權利,同時我們還捍衛它、並持續不斷在 Firefox 上打造創新的功能,幫助你保有線上生活的控制權。

關於 Firefox 如何保護你的隱私,立刻了解更多

原文 / The results are in
授權 / 創用 CC 姓名標示-相同方式分享-3.0
刊載日期 / 2014/7/17

φ Yingui Chen 翻譯 - Wildsky、Irvin 編輯

by Irvin Chen (noreply@blogger.com) at March 20, 2015 12:00 AM

March 17, 2015

MozLinks-zh

(大概是) 好事一椿… Metro 介面 Firefox 開發再度延宕

編按:本文刊載於 2014 年 3 月的 The Mozilla Magazine 中。MozLinks 正體中文版目前人力不足,積稿如山,在此誠徵有志成員加入編輯團隊

為 Window 8 作業系統特別開發的 Metro 介面 Mozilla Firefox,正式釋出的機會看起來微乎其微。Firefox 副總裁在 Mozilla Future Releases 部落格的一篇文章中說明原因。

Firefox 副總裁 Johnathan Nightingale 日前表示,已要求工程師和發行經理暫緩釋出 1.0 版的 Metro 介面 Firefox,因為「釋出可能會是個錯誤」。根據副總裁的說法,Firefox Metro 釋出預覽版僅有約 1000 個活躍測試者,但全球每日都有數百萬個活躍用戶使用 Firefox 的其他開發測試版本。這個現象讓 Mozilla 重新考量 Windows 8 與 8.1 的 Metro 介面版 Firefox 是否真有廣大的需求。

IE 作為 Windows 的預設瀏覽器,和 Google Chrome 一樣具備 Metro 模式。然而,在單一作業系統中同時推行兩種不同的使用介面,也引發各界爭議,據傳微軟已計畫在明年度的某個時刻,將開發主力轉移至「Windows 9」上。(編按:目前已公佈新版 Windows 將會是「Windows 10」,跳過「9」)

Mozilla 表示,雖然 Metro 介面版需求鮮少,但一旦正式釋出,還是得盡力修補錯誤及其他問題。由於用戶這麼少,我能想見為何繼續開發將會是吃力不討好的事情。無怪乎開發團隊決定終止,並著重在改進桌面版與 Android 版的 Firefox 上。

Google Chrome 的 Metro 模式則具有不同的目的:讓民眾熟悉 Chrome OS 以網路為核心的介面(雖然沒有網路的情況下也能使用)。這麼一來,民眾就能在購買 Chromebook 前先一探究竟。Google 透過 Windows 8 宣傳 Chromebook 使用體驗,所以即便需求量少,開發 Metro 介面還是有利於 Google。

Mozilla 的情況則不同,我賭 Metro 介面版的用戶會超少,而且除非 Mozilla 持續除錯、改善瀏覽器,不然難保還會招來一堆批評。趕緊對外說明 Mozilla 不感興趣的原因,然後塊陶是個更好的抉擇,Firefox 的副總裁就如此進行了。

至於程式碼就留給有興趣的開發者們傷腦筋吧。不論 Mozilla 未來會不會因為用戶增長而改變心意,至少目前看來,較合邏輯的結論是— Metro 介面的 Firefox 不會釋出了啦。

你同意 Mozilla 任務應當著重在可接觸到較多用戶的產品上嗎?

原文 / Mozilla Firefox for Windows 8 "Metro" gets delayed again; Probably for good - The Mozilla Magazine
作者 / A.I. Sajib
授權 / 創用 CC 姓名標示-相同方式分享-3.0

φ Cheng Yi Liu 翻譯 - Irvin 編輯

by Irvin Chen (noreply@blogger.com) at March 17, 2015 05:19 PM

February 14, 2015

Othree

CSP

CSP

Communicating Sequential Processes,簡稱 CSP,和 Content Security Policy 不一樣,是用來處理非同步執行序之間溝通的一個數學模型,我最早是在 Addy Osmani 的 JavaScript Application Architecture On The Road To 2015 這篇文章裡面看到的,花了蠻多時間試著去瞭解,最近終於覺得懂一點皮毛可以紀錄一下了。

CSP 其實不是新東西,是 C. A. R. Hoare 在 1978 年就發表的論文(PDF),1985 還出了整本書來介紹,而且全文 PDF 都有在網路上,可是這本書實在太理論了,看了一點點就看不下去,只好找其它資源,發現還真的蠻少的,但是確有找到一些近幾年的實做,像是 Go 的 routine 間用 channel 溝通,或是 Clojure 的 core.async,當然 Addy Osmani 那篇也有提到 JavaScript 的部分。

根據我目前淺薄的理解,CSP 就是用 channel 的非同步溝通機制,channel 怎麼用呢,顧名思義,就是一個傳遞訊息用的頻道,不過我覺得用管線可以更精確的描述它,而且這是一個單向的管線,一邊只能傳訊息進去,一邊只能拿訊息出來,可以達成非同步的溝通最主要在於拿訊息這邊,當你在其中一個 process 中說你要跟某個 channel 拿一個訊息出來時,如果那個 channel 裡面沒有東西,則這邊的 process 就會停下來等到那個 channel 有訊息出現,這個等待的機制不同語言有各自的方法實做。

先來看看 Go 的範例吧,因為實在是比 JavaScript 的直覺多了:

package main
import "fmt"

func main() {
    messages := make(chan string, 1)

    messages <- "ping"

    msg := <-messages
    fmt.Println(msg)
}

這段程式碼是基於 Go by Example 說明 channel 的範例,程式碼很好理解,messages := make(chan string, 1)這行用 make 產生一個 channel 指派給 messages 這個變數,messages <- "ping" 表示把 "ping" 這個字串丟進去 message 這個 channel 裡面,然後 msg := <-messages 表示從 message channel 裡面抓訊息出來,丟到 msg 這個變數,:= 是指派同時宣告變數的運算子,<- 則是用來描述操作中訊息傳遞方向用的運算子,當它是箭頭就很好理解,在 Go 裡面稱為 receive operator

在第一個例子當中,因為是先送資料進去 channel 才拿出來,所以還不太有感覺,接下來看第二個例子,一樣是 Go by Example 的,這段是 Channel Synchronization 的範例:

package main

import "fmt"
import "time"

func worker(done chan bool) {
    fmt.Print("working...")
    time.Sleep(time.Second)
    fmt.Println("done")

    done <- true
}

func main() {

    done := make(chan bool, 1)
    go worker(done)

    <-done
}

這個範例稍微複雜一點,done := make(chan bool, 1) 先產生一個 done channel,然後用 go worker(done) 產生一個 concurrent routine,跑的是 worker 這個 function,內容在 main 的上面,基本上就是 sleep 一下然後傳訊息回 done channel,然後 main 最後的 <-done 就是從 done channel 拿訊息出來,先不管平行出去的 routine,通常的程式跑到這行結束,整個程式就結束關閉了,不過,就是這個不過,正常情況下,有 <-channel 的話,該 routine 程式執行到這邊就會暫停下來,直到有從 channel 裡面拿到訊息才會繼續跑下去(或是裡面已經有訊息,直接拿到就繼續往下)。

Go 的 channel 還有一些細節可以參考 Golang channels tutorial 這篇文章,其實就是一個可以跨 routine 的傳遞資料的管道,資料可以一直傳,沒有限制數量,不過還有一些相關的細節,像是 sync channel,還有 channel 的 buffer 等等。

綜合以上的兩個範例,可以歸納出來,要支援 CSP 有兩個必要條件,第一個是可以做得出 channel 物件的機制,可以放資料進去,可以拿資料出來,是先進先出機制,這部分其實不是問題,問題是第二個條件,程式碼要能跑一跑停下來等訊息然後又繼續跑下去,這可不是用 while (1) 可以處理的狀況,用 recursive function call 效能也不太好,以前的 JavaScript 是無法良好的達成第二個條件的,直到 ES6 的 async function 出現。

ES6 async function 之前有文章介紹過,這邊就不再說明,不過總之就是執行到 yield 後,這個 function call 就會先停下來,把值傳出,直到下次再次執行該 function 才會繼續往下執行,這樣停下來的機制,正好可以利用來作為 CSP 等訊息的機制,不過利用 yield 的話有一個限制,就是一定要在 async function 裡面才可以利用 channel,不像 Go 由於是建在語言裡面的,main thread 也可以跟 channel 溝通。

雖然說可以利用 async function 可以做出 CSP 的架構出來,不過要只用 async function 來寫出像 Go 那樣簡短的程式碼實在是很困難,中間還有很多機制需要補起來,所以就開始有 library 實做,目前最有名的是 js-csp,Facebook 最近的 React.js Conf 其中一場議程介紹 CSP 時也是用 js-csp 做範例,錄影在這,作為入門 CSP 我覺得是蠻不錯的一場演講:

js-csp 裡面其實做了很多事情,目前看起來像是參考 Go 來設計,例如這樣的 Go 程式碼

package main
import "fmt"
import "time"

type Ball struct{ hits int }

func player(name string, table chan *Ball) {
    for {
        ball := <-table
        ball.hits++
        fmt.Println(name, ball.hits)
        time.Sleep(100 * time.Millisecond)
        table <- ball
    }
}

func main() {
    table := make(chan *Ball)
    go player("ping", table)
    go player("pong", table)

    table <- new(Ball) // game on; toss the ball
    time.Sleep(1 * time.Second)
    <-table // game over; grab the ball
}

改成用 js-csp 寫的話就變成:

function* player(name, table) {
  while (true) {
    var ball = yield csp.take(table);
    if (ball === csp.CLOSED) {
      console.log(name + ": table's gone");
      return;
    }
    ball.hits += 1;
    console.log(name + " " + ball.hits);
    yield csp.timeout(100);
    yield csp.put(table, ball);
  }
}

csp.go(function* () {
  var table = csp.chan();

  csp.go(player, ["ping", table]);
  csp.go(player, ["pong", table]);

  yield csp.put(table, {hits: 0});
  yield csp.timeout(1000);
  table.close();
});

csp.chan 產生 channel,用 yield csp.take 代替從 channel 取訊息,用 yield csp.put 代替送訊息到 channel,然後最重要的是用 csp.go 來代替從 Go 裡面用 go 產生 routine 的操作,然後不說可能沒人注意到,js-csp 把 routine(process)、ticker 等比較底層的基礎建設都做起來了,也就是如此才能讓程式碼和 Go 的看起來這麼接近。

js-csp 基本上就是仿照 Go 的的語法來設計,只是常常需要 yield,語法還是不如 Go 來的簡潔,至於何種情境比較適合使用 CSP 呢,以 channel 的特性來說,目前看起來是常常會發生的 event 比較適合,像是常常被拿出來講的 mousemove 事件,另外就是有要分 thread 做平行運算的話也不錯,不過目前看起來是無法接上 WebWorker,主要是因為 postMessage 無法傳遞物件 instance 過去,而是會複製一份;另外因為 channel 可以關起來,所以要用來實做 Promise 也不是不行,不過就沒什麼必要如此搞就是。

講到做事件的處理,應該會有人注意到實做上的細節問題,就是要怎麼讓多個 process 去讀取同一個 channel 呢,一般而言,channel 的訊息是只能讀取一次的,就是說雖然你可以多個 process 等同一個 channel 的訊息,但是只會有一個 process 會真的拿到新的訊息,而實務上,一個事件綁了多個 handler 的情形非常常見,照 channel 的機制,應該是不能用下去的,不然就要自己管裡 handler,又多繞了一圈,事實上,CSP 模型是有一些運算可以用的,像要處理多個 handler 的問題,就可以用 mult,可以把一個 channel 轉成一對多,其它還有多對一的 share resource、Clojure 的 onto 等等,應該是想的到的情形都已經有數學模型或是不同語言的實做可以處理了,不過 js-csp 在這部分還在開發中,像是 mult 就還在 beta 階段,其實還不太能真的用,作者有說現在的介面可能會改,也因此還沒寫到文件裡面。

最後想要記錄一下 Clojure 所提出的 transducer,transducer 的目的是讓 reduce 的操作可以用 compose 來組合,什麼是 reduce 操作呢,其實包括像 map、filter 都可以算是,但是這些操作以前是無法用 function composition 來做組合的,直到有了 transducer,又加上 transducer 把處理資料的型別也 decouple 出去了,所以 channel message 也可以利用。有兩篇文章可以參考,第一篇文章是 CSP and transducers in JavaScript,這篇講得非常清楚,他是從無到有把 transducer 建構起來,我是第二次認真看這篇文章才理解的,另外一篇文章是 Transducers.js: A JavaScript Library for Transformation of Data,是 Transducer.js 的作者寫的,從不太一樣的角度來看 Transducer 這個設計,有機會再來分享詳細一點。

這篇文章其實也不算是介紹或教學 CSP on JavaScript,比較是記錄一些我花時間想辦法理解的問題,包括為什麼現在才有人用 JavaScript 實做 CSP,實際上怎麼實做,目前適用的地方,還有整理了對 transducer 的理解,如果單純是想理解 CSP,除了前面提到的文章之外,還有幾篇文章可以參考 ES6 Generators Deliver Go Style ConcurrencyTaming the Asynchronous Beast with CSP Channels in JavaScript

February 14, 2015 07:26 AM

January 31, 2015

Othree

在盲人之前的親和力

不少人還會直接把網站的親和力(無障礙)問題和盲人朋友直接連在一起,覺得應該來解除迷思一下,盲人朋友確實是最直接會想到的,各種有身心障礙人士的族群當中,盲人朋友使用電腦上網的難度也是最高的,不過在你把眼睛矇起來體驗盲人如何操作電腦之前,有不少事情是可以先做的,隨便把腦袋裡馬上想的到的列了一下:

首先是網頁的文字內容易讀性,易讀性有分兩個面向,第一個面向大家比較清楚,就是文字排版、字形挑選、顏色對比等等視覺上的易讀程度,這部分做的好的話除了對老花眼、近視或是弱視的朋友有幫助外,一般人也會受惠;另一個面向則是文字內容好不好理解的程度,如果網站上的文字說明太難懂,那就應該要用更好理解的文字來重新講一遍,或是加上圖表輔助,或是乾脆減少資訊量,通常自己看的懂,不代表別人看的懂,所以如果是重要的說明(尤其是政府網站一些流程、辦理辦法之類的),建議都要找人看過,最簡單的是找家中長輩,因為網路上理解力較低的族群中,長輩們佔不少。

第二個是操作介面好不好操作,通常是 Web App 才有這需求,一樣有不同的面向,第一個是你的操作介面應該設計的容易理解,讓人看了也不會疑惑應該點哪裡,其中一個很重要的原則是不要破壞使用者的習慣,第二個面向是有些人可能無法好好的控制滑鼠(要模擬這個比模擬盲人的情境還要難),點擊不精確,所以永遠要保留鍵盤操作的選項,如果是使用原生的輸入元件來做操作介面的話,沒有亂做什麼奇怪的事情應該是都可以用鍵盤來控制,但是如果要自己設計一個嶄新的控制元件,那記得要好好利用 WAI-ARIA 來讓鍵盤可以順利的控制,像是 Google 的 Gmail 就有完整的鍵盤操作支援,這個應該是這篇文章當中做起來最辛苦的一項吧。

第三個是表單行為,要把表單作的好填,本身是一門很大的學問,不過在深入的思考設計表單的 usability 之前,有一些很基本的功能是應該具備的,其中特別想說的是錯誤訊息的處理,使用者送出表單後,如果後端的檢查沒過被打回來,應該要伴隨著能幫助使用者更新資料的錯誤訊息,並且正確的顯示在正確的位置,不然使用者不知道發生什麼事情,除了告訴使用者哪裡有錯之外,更進一步是讓使用者能把輸入資料改好,例如帳號名稱有格式限制的話,就要明確的說明有哪些限制,另外表單檢查不通過之後,記得也不要把使用者剛剛填的資料清空(實做這點還需要特別記得安全性問題)。

最後一個是文件結構,正確的使用 HTML 標籤,還可以輔以 WAI-ARIA 的 role 屬性,這已經是講到爛的項目了,當然 single page application 算是特殊情形,不過只要你做的頁面還是接近傳統網頁有文字內容,有主要內容的話,把網頁的文件結構弄好還是有兩大好處的:一、SEO 的部分已經好了一大半了;二、所有輔具都可以根據你的文件結構快速的帶領使用者在文件中穿梭,不用多做什麼奇怪的導盲機制。要把這塊做好算是四點當中最簡單的,只要正確的依照語意使用 HTML 標籤,不夠的再看看 WAI-ARIA 有沒有可用的 role,不要亂用標籤,然後用檢視原始碼的功能看看好不好看,如果你能開始從 HTML 原始碼中感受到美感甚至有完美的感覺出來,相信你就在正確的方向上了。

其實以上四點都有一個特色,就是把這些地方做好,不只是身心障礙人士會受惠,文字易讀性就不用說了,操控介面如果支援鍵盤,有些正常人操作起來會更得心應手,表單的訊息也是不論是怎樣的使用者都很需要,而文件結構也是,弄得好的話,大家都好找到資料,站長應該也開心。所以其實在你想要為了提升親和力而去實際模擬身心障礙人士使用電腦的情境之前,是有很多東西是可以先做的,

相信還是有人會有興趣盲人朋友怎麼操控電腦的,曾經 HappyDesigner 有邀請有聲書協會的朋友來介紹,不過已經有點久了,我去年初剛好有機會在 Moztw Lab 遇到 Fancy 示範,當時有簡單的錄下來,有興趣的朋友可以看一下:

至於要怎麼體驗盲人怎麼操作呢?如果你是用 OSX 的話,系統有內建 Voice Over,品質很好,可以直接使用,Windows 有好幾套商業軟體,至於免費的比較有名的是 NVDA,這套也是開源軟體,一開始可能需要先當明眼人練習操作,另外它講的話一開始可能會聽不太懂,聲音合成引擎和商業軟體比起來有差,多聽幾次慢慢就聽的出來再講什麼了。

January 31, 2015 10:58 AM

January 30, 2015

MozLinks-zh

Firefox for Android 的兩個新功能

我們很高興的在此公佈兩個超棒的 Android 版 Firefox 新功能:

  1. 家,甜美又能任意裝潢的家
    以您喜歡的方式安排您的首頁。新增最愛的面板到您的首頁,選擇您預設的面板、或隱藏不需要的。

  2. 快速分享按鈕
    現在您只需要輕輕的按一下分享按鈕,就可以透過您最愛的社交應用程式,快速又容易的分享網頁。(編按:而且 Firefox 還會記住你最愛使用的服務,並放到選單的最上方!)

請確保您已擁有最新版的 Firefox Android 版,或現在就立即下載。這樣,您就能享受一切最新的功能!

原文 / Two new features for Firefox for Android
授權 / 創用 CC 姓名標示-相同方式分享-3.0

φ 歐西里斯 翻譯 - Irvin 編輯

by Irvin Chen (noreply@blogger.com) at January 30, 2015 05:46 PM

January 26, 2015

orinx

準備啟程至峇里島參加 CUAsia

先簡單的介紹一下 CUAsia 是什麼吧,他的全名叫做 Coworking Unconference Asia。顧名思義就是亞洲區共用工作空間的 Unconference 。大概會有 100~200 個來自各地的空間維護者,來討論關於共用工作空間的一些經營方向、理念及案例。

這次去主要是希望能夠取經,學習看看其他亞洲國家是怎麼做共用空間管理、規劃、行銷等。也許有些東西能夠來幫助我們的 摩茲工寮 成長;同時也希望能夠在第二天搶到 Unconference topic 的名額,來分享我們 摩茲工寮 是怎麼做分散式的 Keyholder 管理制度、以及我們怎麼透過空間推廣我們所熱愛的 Mozilla 精神 及開源文化。

先把這次主要想要取經的內容先列表寫下來,歡迎大家多給點意見。我在回台灣後,會找間在 摩茲工寮 辦一場簡單的心得分享。如果你有特別期待某個方向的內容,歡迎在我的部落格直接回應討論。我會在 CUAsia 的時候會特別關注這些議題的,不過我去聽/討論的東西主要還是會以能幫助 摩茲工寮 為主

  • 吸取別人的失敗經驗,哪些場地、設備、活動以及行銷方式是不合宜的?成長到最後大家各走出怎樣的路?
  • 當空間成長的速度過快(人數、甚至是場地),該有怎樣的應變措施去確保品質?
  • 怎麼樣讓共用工作空間可以「自己養活自己」,別人是怎麼做的?大家是運用了怎樣的 Business Model 在盈利、非營利的共用空間中
  • 以一個共用空間來說,跟其他公司、政府等單位合作的生態是什麼?
  • 更多… 我有思考到我會再更新上來 :P

by Orin Chen at January 26, 2015 04:04 PM