訂閱

上次更新

August 30, 2015 02:00 PM

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

Powered By

Planet

摩茲星球 | MozTW Planet

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

August 28, 2015

BobChao

Use Firefox OS "lightsaber" on Flame

EN: I'll make a note as a "lightsaber quick install guide" here.

Firefox OS 新的 Add-on 等功能都在 lightsaber 上,要安裝稍微得費點勁,這邊分享一下最速達陣手法:

「不必」自己 build Gecko

EN: You don't have to build the whole gecko from mozilla-central, just use the nightly and it works. Check Updating your Flame and choose the https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/ builds.

lightsaber 上面叫你自己從 mozilla-central 重新自建 Gecko,但其實光是要嘗試新東西的話無此必要,只要更新 Flame 到 mozilla-central 的 nightly-build 就好:

https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/

如果不知道怎麼升級,請見 Updating your Flame

拿把光劍

EN: then, follow the quick setup section in the README.md of lightsaber, but be sure to remove the "GAIA_DEV_PIXELS_PER_PX=2.25" part.

接著就要把光劍裝上去,其 Readme 裡有最速捷徑

sudo npm install -g bower && sudo npm install -g gulp && sudo npm install -g apm && sudo npm install -g grunt-cli && sudo npm install -g browserify
git clone https://github.com/fxos/lightsaber
cd lightsaber
make install
make sync

我這邊故意少複製了一行,原因有三:

  1. 我在 make sync 時有跳錯誤,如果發生錯誤無論如何就上網查一下,通常都是什麼東西沒裝好。
  2. 這邊有可能會問你要裝哪種 gaia-icon,我反正是挑最新的
  3. 這份 Readme 主要寫給 Z3C 用,如果你好傻好天真地照辦那在 Flame 上就有問題了。

最後一行是真的要把 Gaia 裝上去,作為日用機,我常用的參數是這樣:

  • 要掛 Mozilla 的品牌: MOZILLA_OFFICIAL=1
  • 日用,跳過測試用 App: PRODUCTION=1
  • 跳過啟用導覽與設定: NOFTU=1
  • 開啟 adb 連線除錯: DEVICE_DEBUG=1
  • 開英文跟注音鍵盤: GAIA_KEYBOARD_LAYOUTS=en,zh-Hant-Zhuyin

如果你也要裝中文語系和設定上去,參考小帥提提供的古早資料,將語系抓下來,再以 language.json 指定一下啟用的語系即可。你的最後一行指令可能長得像這樣:

DEVICE_DEBUG=1 PRODUCTION=1 MOZILLA_OFFICIAL=1 GAIA_KEYBOARD_LAYOUTS=en,zh-Hant-Zhuyin LOCALE_BASEDIR=locales/ LOCALES_FILE=locales/l.json make reset-gaia

最後

沒有下一步了,就是這樣喵。雖然手上有 Flame 又不屬於 MoCo 的華人不多,但還是分享一下順便當自己的筆記 -- 我近兩年前寫的 build Firefox OS 筆記,現在還是很好用 :P

by Po-chiang Chao (noreply@blogger.com) at August 28, 2015 03:46 PM

August 25, 2015

MozLinks-zh

Webmaker app — 數位掃盲新方法

編案: 日前 Mozilla 正式釋出 Android 平台的 Webmaker app。為此我們於此刊載 Mozilla 基金會執行董事 Mark Surman 於四月時撰寫的文章,希望能讓大家更加了解 Webmaker app 的設計與涵義。

年初在巴塞隆納的 MWC(世界行動通信大會)上,Mozilla 啟動了 Webmaker app 的公開測試。這是一個自由且獨立運作的網路出版工具,對於 Mozilla 所致力的「提高世界各地的數位素養(digital literacy)」也是重要的一步。

Webmaker app 的想法,是源自於我們過去一年在孟加拉、印度和肯亞的研究成果。這份研究指出兩件事情:智慧型手機的新使用者面臨陡峭的學習曲線,常被侷限在諸如 Facebook 之類的基本 app,甚至不知道自己正在「上網」;與此同時,使用者仍然渴望創造在地相關的內容,並期望從中獲益。

Webmaker app 讓每個人都能夠在打開他們的第一隻智慧型手機時,就能快速發佈網站或 app,以滿足這些渴求。學生可以為同儕製作數位公布欄、教師可以製作和發佈教案、商家也可以架設網站來推廣自己的產品。

我們的想法是,讓智慧型手機用戶甫上網之際先快速上手,再協助他們與時俱進。這種「先做再說」的數位素養策略,鼓勵人們視自己為主動的創作者,而非被動的消費者。數十億人在今後幾年內都將開始捫心自問「我為何上網、我該如何使用網路」,而這種觀念將在此扮演重要角色。

Webmaker app 自由且開源,提供超過 20 種語言支援。使用者可以透過手機簡訊、Facebook、WhatsApp…等工具傳送網址,以分享創作成果。Webmaker 中建立的內容,可以在任何手機瀏覽器上打開。目前提供 Android、Firefox OS 和當代手機瀏覽器的版本,更完整的平台將在今年稍晚釋出。

另有一個讓 Webmaker app 更為完善的要素,就是 Mozilla 廣泛且面對面的教學計劃。我們的創作者、輔導者與教育者志工網絡,正在全球超過 80 個國家中運作。這些配備有 app 及其他工具的志工,為協助人們了解網路的運作原理、創造與其日常生活習習相關的內容,已在學校、圖書館和其他公共場所,舉辦了許許多多的非正式工作坊。僅僅去年一年,Mozilla 志工們就在 450 個城市中舉辦了 2,513 場工作坊!

此一數位素養運動,是我們與合作夥伴共同推展而出。Mozilla 和那些對開放網路、在地內容及賦權用戶,與我們一樣感到熱情、且深具影響力的非政府組織、行動電話營運商、和其他全球性組織聯手合作,以確保我們的數位素養計劃能幫助到最需要的人。

當數十億位首次接觸網路的用戶上網時,他們會發現一個可以打造、型塑並每天使用,以改善自身、業務和教育的平台。這是一個具有雄心壯志的目標,但 Mozilla 已經準備好了。想要參加、或更家了解我們的數位素養行動,請到 webmaker.org/localweb

原文 / Webmaker App Takes Fresh Approach to Digital Literacy | The Mozilla Blog
作者 / Mark Surman
授權 / 創用 CC 姓名標示-相同方式分享-3.0

φ Nini Hsu、楊椀婷 翻譯 - Irvin 編輯

by Irvin Chen (noreply@blogger.com) at August 25, 2015 04:15 PM

August 20, 2015

Othree

React 入門

京都嵐山

其實這篇想寫一陣子了,不過拖太久本來想放掉,是後來又看到 TonyQ 在說他的經驗,就覺得還是寫一下,搞不好可以幫到人(?),然後其實我對 React 沒深入研究,目前也只寫過一次,也沒做到複雜的 App,所以這篇純粹是我的觀察啦。

先講結論,寫過目前一般 Web App 的人,要來寫 React 大概都要一些撞牆期吧,我的狀況是要寫 React + Flux 架構的 Web App,但是一開始對 Flux 的介紹沒認真看,在一知半解的狀態下就開始做了,結果就一直出現些靈異現象,大部分是覺得應該要更新畫面了但是沒有,追到後來大概就兩個原因:

  • 亂用 props 和 state,總之就是 React 只會在 state 變化的時候更新畫面,props 變化的時候不會(其實設計上是 immutable 的),而用 props 的時機基本上是父層 component 要設定資料給子 component 的時候才會用,至於父層收到不同的資料給子 component 時,同樣是改 props,為什麼畫面就會更新了,事實上是因為父層 component 更新的時候,才有機會改動到子 component 的 prop,而因為有重新 render,子 component 的內容也會一起更新,也才更新了畫面。

  • 想要只更新子 component,這個問題就是沒把 flux 的設計弄清楚,Flux 的 store 其實有點代表所有的資料的意思,而不管是什麼動作,都要把整包的 store 資料更新回去,根 component 會綁事件在 store 的更新事件上,發現 store 資料有更新就開始重新 render component,然後跟著它的子 component 就會因為 prop 更新而跟著更新。

當然 store 是可以有多個的,重點在於每次更新都要整個 store 的資料重新給根 component,不能從 store 裡面某一層開始送,然後想要只更新某個子 component,這樣結果就很容易發生靈異事件,當然 React 可以不用 Flux 架構,不過我覺得那條路走起來更困難,所以還是乖乖使用 Flux 架構,其實我後來做的結構很簡單,action 就只是一個事件,store 就是 POJSO 而已,沒用到一些市面上的 Flux framework。

最後一點要提的就是每次都整包 store 更新,可能就會有人想到效能問題,當然 React 本身效能不錯,不過資料量要是超大,可能還是會有出現狀況,我想這也是為什麼 Facebook 要發展 Immutable.js 的原因,其實我仔細瞭解後,發現 Immutable 配合 Flux 架構真的是超適合的,而且他在大量資料更新的時候,可以保持蠻不錯的效能,因為只有 reference 的變化,而不是真的重新產生整包資料,沒變化的資料都是本來就已經在記憶體裡面的,整體的資源消耗少很多。

August 20, 2015 04:38 PM

August 17, 2015

Othree

fetch is the new XHR

這次 COSCUP 講的是新的 Web API: fetch,其實這個東西要用只要看 HTML5 Rocks 那篇文章就好了,只是我在使用和做 fetch-er 的時候發覺很多的細節和問題(投影片裡面的 facts),有一些不跟最新進度也不知道狀況是怎樣,連 Stack Overflow 上也沒有,可能有人遇到但是不知道,所以就和我的 fetch-er 專案一起投稿。

和 fetch-er 專案一起投稿的另一個考量是,在 COSCUP 和 OSDC 分享這麼多次,年初我突然才發現我的講題和 Open Source 的關連度實在太低(嚴格說來我在那時才認真意識到 open source 和社群的差異),只有 2013 的 COSCUP 是講我在 Vim Plugin 開發上的歷程,其他有一場有介紹到 underscore,之外就大部分是在介紹 Web 的新東西,所以認真的覺得今年要投和 Open Source 相關的東西,而不是只是 Web 相關的而已。

August 17, 2015 10:28 AM

August 07, 2015

Othree

My First Patch to Firefox

zh download dialog

OSX 自從升級到 10.10 之後,繁體中文版 Firefox 就冒出了一個 bug,一堆使用到作業系統原生的視窗,像是下載圖片,開啟檔案等等的,都會變成簡體中文介面,這個問題在 Bugzilla 上的編號是 1089363,畫面看起來就像上面的圖一樣,這個問題的狀況,推測是 OSX 本來在這種系統對話框,會使用使用者現在設定的系統 locale,但是 10.10 改成應用程式正在運作的 locale,然後 Firefox 本來會用 locale AB_CD 中的 AB 段而已,所以 zh_TWzh_CN 就都會變成 zh,然後 OSX 的 zh 又會變成簡體中文,結果就變成這樣了。

其實這個 bug 的解法, Steven Michaud 很早就提出了,就是把本來 locale 的 resource 目錄的名稱改成 zh_TW,大概 diff 如下:

 AB_CD = $(MOZ_UI_LOCALE)

-AB := $(firstword $(subst -, ,$(AB_CD)))
+ifeq (zh-TW,$(AB_CD))
+LPROJ_ROOT := $(subst -,_,$(AB_CD))
+else
+LPROJ_ROOT := $(firstword $(subst -, ,$(AB_CD)))
+endif
+LPROJ := Contents/Resources/$(LPROJ_ROOT).lproj

其實不會很難,不過因為 Firefox 的程式碼變動很快,連 build script 也常常變動,那個 patch 檔出來的時候已經不能用了,然後又沒人處理就這樣一直拖下去,前陣子 Moztw 那邊又被提出來一次,剛好我為了弄 WebIDL 相關應用的時候有 build 過 Firefox,想說應該可以處理看看,就接下來嘗試了,build 本身蠻簡單的,就照著網路上的文件就好,比較難的是要 build 成特定語系的,找很久才在 Moztw 討論區找到答案,要在 .mozconfig 裡面加上:

ac_add_options --with-l10n-base=/d/lang
ac_add_options --enable-ui-locale=zh-TW

其中第一行設定的路徑要指定到你指定的位置,而且要絕對路徑,然後在該目錄 clone 翻譯的 repository 下來,可以在 l10n-central 那邊找自己的語系,以 zh-TW 來說:

cd /d/lang
git clone http://hg.mozilla.org/l10n-central/zh-TW/

然後這樣就可以 build 中文版了,build 完執行就看到精美的黃底紅字 XML 解析錯誤視窗。

Firefox Missing String

還好我有點經驗,知道 Firefox 的介面是 XUL 寫的,然後字串是用 XML entity 方式存在,所以很快就想倒是翻譯問題,於是上去找了 l10n dashboard 看看繁體中文的狀況,看的是 fx_central 這棵樹下的字串:

Firefox l10n stat

可以看到目前有缺哪些字串,因為字串還沒穩定所以也還不會有翻譯,所以就需要手動進去把這些 entity 的定義補上,內容隨便填,然後重新 build 一次,結果就修好了!

nightly zh_TW download dialog

然後就開始想辦法生 patch 檔案了,中間也有用過 hg mq,最後都固定改好,commit 後用 hg export . > fix.patch,總之改好我就丟上 bugzilla 了,結果第一個 patch 只改到一個檔案,實際上應該有五個檔案要改,而且才隔一天,Makefile 就被別人改過了,只好重新找位置修改,重新生 patch,到最後一個 review 過,build 也過的 patch 中間還發生了不少事情,包括 Makefile 被別人又改動一次,用 AB or LPROJ 的命名問題,字串的變化造成假翻譯又要增加,還有 build 工具 mach 被人改壞,和推上去之後有 build 失敗的狀況等等,非常的一波三折。

其中 build 失敗是 b2g 的 build 失敗,原因是我有地方改錯,不過要測試也是要重新設定,參考的是 Building the Firefox OS Simulator 這份文件,把 .mozconfig 改成:

. "$topsrcdir/b2g/config/mozconfigs/common"

mk_add_options MOZ_OBJDIR=../build
mk_add_options MOZ_MAKE_FLAGS="-j9 -s"

ac_add_options --enable-application=b2g
ac_add_options --disable-libjpeg-turbo

重新 build 看能不能過。

改完產生的 patch 檔上傳到 bugzilla 時,要勾選 Content Type 是 patch,然後 review flag 設定成 ?,選一個 reviewer,通常會有 mentor 來跟你說選誰好,我的情形是 timdream 在幫忙,接著就等 reviewer review,他 review 過的話, review flag 就會變成 +,然後就會收到一封「Congratulations on having your first patch approved」的信件,說了一些後續可以做的事情,接著要做的就是讓 patch 真的進去 repository,可以在票的 keyword 加上 checkin-needed,就會有機器人自己來把你的 patch check in 進 mozilla-inbound 這個 repository,然後丟上機器人自動編譯和測試,例如這個我 B2G build 失敗的例子,都過了就會進 mozilla-central,之後才照順序進 mozilla-aurora、mozilla-beta、mozilla-release,現在進去 mozilla-central 的大概要等 Firefox 42 才會上線了,應該是和 OSX 10.11 同時吧。

August 07, 2015 01:06 AM

August 03, 2015

Othree

Electron 入門

electron

前陣子花了些時間用 Electron 寫了個桌面應用程式,覺得有些資訊應該記錄一下,其實我覺得 Electron 的文件弄得超爛的,非常沒有 Github 的水準,Github 當初能夠起來,我認為一個很大的原因就是文件做的很好,而且在頁面上都會提供相對應操作的說明文件,不只讓網站的易用性提昇很多,連帶的也推廣了 Git 的使用,算是相輔相成起來的,不過 Electron 剛推出的時候,我就覺得,這是有文件嗎?甚至讓我有個印像是,我們雖然推出 Electron 但是沒很想讓你們用,所以文件隨便寫寫。

為什麼這樣說,拿現在最新版 0.3.0 來說,其實這應該只是自動產生的文件,整頁的第一篇文章是 Application distribution,這真的沒有哪裡搞錯嗎?而且這份文件還很爛,有關鍵的地方沒說,之後會講。總之,要開始寫 Electron App 應該要看的是 Quick Start 才對,這份文件用了一個很簡單的範例讓你開始可以跑 Electron App,只要會寫網頁,從這邊就可以開始做 Electron App,但是一個應用程式哪有這麼單純,只靠 Web 端的技術一定是有不足的,例如我要做的程式就需要讀取 key 去登入 SSH 然後做事情,這登入 SSH 然後做事的部分用的是 node 的 code,不能跑在瀏覽器環境,在 Electron 的架構下,瀏覽器環境稱為 renderer,而另外一邊用來起始 renderer process 的則稱為 main process,要登入 SSH 的 code 就要寫在 main process 這邊,那兩邊要怎麼溝通呢?Electron 提供了 IPC 模組來用。

IPC 模組應該是稱為 Inter Process Communication 吧,我覺得這在 Electron App 開發當中應該是超重要的一部份,結果在 Quick Start 那篇文章中竟然沒有範例介紹,只有簡單的一句話說如果兩邊要溝通要用這個(或是另外一個 remote 模組),而且點過去也只有 API 文件,沒有範例,後來出的 remote 模組的文件才有範例說明,總之這樣弄來弄去還是有解決兩邊的溝通問題,所以下一個遇到的,就是我要怎麼讓使用者選檔案了。

因為 Electron 是跨平台的,我的程式設計是用 private key 去登入遠端的機器做事情,Linux 或 OSX 都可以假設 key 的位置,但是 Windows 不行,所以我就要提供可以讓使用者選檔案的功能,這部分文件也是沒有好好的連結,你看完 Quick Start,看一遍文件目錄,其實都看不出來到底要怎麼做到這件事,事實上它被稱為 dialog,這不把整份 API 文件翻文真的不知道是放在這名字下面。

然後,Electron 的 renderer process 端雖然和瀏覽器環境幾乎一樣,不過還是有些差異,一部份是 Chrome 引擎的問題,例如最近的 fetch,在 renderer process 會受到 CORS 限制,但是 XHR 不會,這是因為 fetch 還沒有檢查 Chrome 的 safety flag,所以如果要用 fetch API 接 ES6 Promise 的話,就要用 Github 的 polyfill,自己把檢查的程式碼拿掉,另外一個類似的問題是,如果要在 renderer process 中,引入第三方的 library,有兩種用法,一個是用新出現的 require 來引入 npm module,或是像一般網頁一樣,直接用 <script> 標籤引入 js 檔案,但是就會發生一個問題,因為 jQuery 會判斷現在的環境,然後來決定要不要 expose $ 變數到 global scope 下,剛好,Electron 的環境下,雖然是要當成瀏覽器環境,但是又多了 require 可以用,結果就是被誤判成在 Node 環境,想當成一般網頁環境用 jQuery 就會找不到 $,結果也是要自己去修改檢查部分的程式碼。

最後,把程式功能弄得差不多了,要打包給其他人時,發現竟然無從下手,本文開頭提到的 Application distribution 這份文件說的很簡單,就是把某個目錄換掉就好了,可是真的到了這一步才意識到,是換掉哪裡的目錄?結果只好上網找別人弄好的打包工具,這邊我用的是 electron-packager,研究一下才發現,原來是要抓 Github 上 release 那的檔案下來處理,整個過程其實還蠻不愉快的,因為根本不是難懂,而是文件作不好造成一堆時間浪費啊。

August 03, 2015 01:27 PM

July 28, 2015

Irvin

TW Mozillians @ 香港開源年會 HKOSCon 2015

In the end of June, totally 7 Taiwan Mozillians (5 reps, 2 core contributors) flew to Hong Kong to host a Mozilla booth at HKOSCon 2015 (Hong Kong Open Source Conference). The following are 2 blog posts from Yao Wei and Ernest.

Mozilla Links 正體中文版: Showing off Firefox in HKOSCon 2015
Participating HKOSC 2015 — Medium

日前, ErnestBobChaoOrinRJ魏藥Peter 等共七位 MozTW 成員,一同前往香港開源年會,並擺設 Mozilla 攤位。關於活動的情形,歡迎閱讀以上魏藥及 Ernest 的直擊文章。

Here I will add some of my own experience & observation.
以下紀錄一些我個人的經驗與觀察。

Booth 攤位

MozTW Mozillians #FoxYeah @ HKOSCon2015
(TW Mozillians with Sammy Fung, Bob & Ernest is not in this photo)
(台灣成員與香港的 Sammy,Bob 與 Ernest 不在這張照片中)

Create big banners from FoxYeah stickers to demostrate, is indeed good try on our booth. We can take chance to sharing ideas with people on those topics of banner (security, customize...), and ask people to choose their favorite one to take photo, has really positive feedback.

將 FoxYeah 標語製作成大扛棒在攤位上展示,並讓人拿著最喜歡的標語拍照,是一個準備簡單,卻非常有笑點的小活動。不但容易吸引目光,也成為與參觀者的交流話題。

Thomas #FoxYeah @ HKOSCon2015
(We even got a "Gandi love Firefox" big thumb up from Gandi.net's Asia COO Thomas)
(我們甚至獲得了 Gandi 的 Asia COO Thomas 的「Gandi Love Firefox」認證)

Hong Kong local mozillians were basically all workers for HKOSCon, so we had to self-help on organize booth. Carry those Firefox OS devices and Firefox souvenir were not easy - the stickers are so-heavy. We had to separate them to everyone to carry in luggage when flight. Printer big stickers and make slogan banner on sight is good idea.

香港當地的 Mozillians 都是 HKOSCon 的主辦成員,我們只好自力救濟。要把這麼多展示品(包含近十台 Firefox OS 裝置、與各類 Firefox 紀念品)從台灣帶到香港,的確是蠻麻煩的一件事,貼紙卡片又重又多,要讓大家平均分攤裝行李箱托運。印貼紙跟買瓦楞版當場製作,又快效果又好。

We also got 21 filled contribute forms at the booth. Hope that we can get some more contributors at Hong Kong. (BTW, on our contribute form, we had various contributed area for people to choose their prefer, and most of people select multiple area. We should improve our [online form](http://mozilla.org/contribute) to accepting multiple choices too.)

本次攤位上,我們亦收集到 21 名有意貢獻者的聯絡方式。希望未來在香港能有更多 Mozilla 貢獻者。

Webmaker Workshop 工作坊

Webmaker Workshop @HKOSCon2015

Host a Webmaker workshop is one of my main topic in HKOSCon. But the lecture room is under "speak" mode, and not too easy for workshop that it's hard to see how attendees' status. Fortunately that my content is half exercise and half lecture intro.

主講 Webmaker 工作坊,是這次參與 HKOSCon 的主要任務。可惜的是,雖然參加者大多都有攜帶電腦,但是演講形式的座位安排,不太好掌握台下參加者的參與狀況,還是不太適合工作坊。幸好我準備的內容是實作與演講兼具。

This is also my first time to connecting Keynote, iPad (remote control and viewing keynote speaker note), Firefox, iPhone (share internet to mac), Reflector 2 (receive Chrome Cast mirrow from Mi2S), and Mi2S Android phone all together on stage. Perhaps the environment is too complicated thus my Mac hang for twice and it tooks me 5 mins to reboot when in 2/3 of workshop. Too bad that it cost me too much time and I cannot play last video in slide. I'll need to simplified the environment next time.

這也是我第一次同時使用 Keynote、iPad(連動 Keynote 看講者備忘)、Firefox、iPhone(分享網路給 Mac,再作熱點給 iPad 與 Android 手機)、Reflector 2(用於接收 Chrome Cast Mirrow 展示 Android 手機的 Webmaker App)與一台小米 2S Android 手機等六項裝置與軟體,在進行到約 2/3 時,遭遇到電腦當機了兩次,浪費了約五分鐘,讓最後一片短片來不及播放。環境太複雜,下次最好還是精簡一點,避免再次發生。

Here is my workshop slide,
以下是這次的投影片:


Webmaker + Workshop @HKOSCon 2015

Accommodation 住宿

Our accommodation "Royal Park Hotel" is really really valuable! Locating in central Shatin, 10 mins walk from train station all inside mall (cool and easy for luggage!), half hour metro to downtown, 1 hour Airport bus directly to hotel door. The best is price, 4 star hotel with large room (twice as large as hotel room in Kowloon) equipment with bathtub, the price only about 130 USD per 4pax room per night. (Almost same price to 2pax room.)

這次我們的住宿「帝都酒店」真的非常超值!極力推薦給四人以上一起到香港的朋友。地點位於沙田市中心,沙田車站約只要走十分鐘,全程都是室內商場(又涼又好拉行李)。搭地鐵不用半小時就能進到九龍,且 A41 機場巴士一小時直達飯店門口。最棒的是,四星級飯店,兩間四人房共定七晚,稅前一晚不到一千港幣(跟兩人房價格差不多),而且房間是九龍飯店的兩倍大以上(甚至有浴缸!)

by Irvin Chen (noreply@blogger.com) at July 28, 2015 01:41 PM

July 17, 2015

MozLinks-zh

Showing off Firefox in HKOSCon 2015

編按:MozTW 共七位成員於 6/26~27 參與 HKOSCon 2015 香港開源年會,並在現場設置 Mozilla 攤位,本文為 Yao Wei 的第一手報導。我們也將於 8/15~16 於中研院舉辦的 COSCUP 2015 擺攤,並展出與香港年會中相近的內容,歡迎大家前來參觀。

MozTW team @ HKOSCon2015 #FoxYeah

HKOSCon is an annual open source conference in Hong Kong, similar to COSCUP in Taiwan. This year it took place in HKSTP (Hong Kong Science and Technology Park). Our booth was in a glass corridor connecting the food court and the conference building. It was a brilliant idea to set up booths in the corridor, where people working in the science park may walk through it for lunch.

MozTW booth @HKOSCon2015
MozTW booth @HKOSCon2015

In our booth, we promoted Firefox, and Mozilla in general — an organization focus on freedom of choice, open standards and privacy. To accomplish this, we have a physical version of the #FoxYeah campaign which began right before HKOSCon. We have boards printed with reasons of using Firefox, and asked people to pick one they like most and take a picture with it. However, attendees tend to be shy in front of cameras; we had very few people who are willing to take a picture other than staffs.

Also, we showed off Firefox OS, one of the major projects in Mozilla. We let visitors know the potential of web technology by using our devices. Especially, as the mobile market is overly saturated, some people ask us what else Firefox OS can be applied into. We reply with the FxOS-powered UHD TV which just hit the market, and the ongoing Web of Things experiments from Mozilla Japan.

The booths along with us featured some interesting projects:

Sammy Fung, the organizer of the conference, had a lightning talk session talking about the history of open source conference in Hong Kong, and we believe the renaissance of open source movements in this place has just begun.

You can see more photos from the tag on Flickr.

Author / Yao Wei
License / CC BY-SA-3.0 TW

by Irvin Chen (noreply@blogger.com) at July 17, 2015 12:29 PM

July 03, 2015

Othree

webappsec

Safety first.

這幾天才注意到 W3C 的 Web Application Security Working Group,簡稱為 webappsec,專門負責安全相關的規範制訂,是 2011 年就成立的,算是很後知後覺吧,其實現在很多已經很廣為人知的 Web 安全機制都是出自他們之手,像是 CORSCSP,然後他們現在也很跟的上潮流,把標準的制訂也移到 Github 上了,其實會發現這個 Github repo 是因為最近在看 fetch 的 spec,裡面多了蠻多內容,而且有不少引用到其它新標準的地方,然後看這看著就看到 webappsec 這邊,順便就看了一下,有幾個新草稿好像還蠻有趣的,想說可以介紹一下,不過這些東西大部分都還不能用就是了。

第一個是 Secure Contexts,這個新東西目的很簡單,就是判斷現在的連線狀況是否安全,以前的話,前端只能看是不是使用 https protocol 連線,不過 Secure Context 有比較多的判斷流程,例如用 SSL 就不會被當成是安全的,要 TLS 才會被認為是安全,如果不是 TLS 連線則還會判斷連到哪裡,看看白名單黑名單之類的機制。

第二個是 Credential Management,主要是為了因應現在瀏覽器很多都有記下使用者填的表單資料,包括登入的表單,而這等於是把使用者某個網站的帳號密碼都記錄下來,不過其實瀏覽器要做這些功能也是會遇到很多問題,像是他要怎麼判斷現在的表單是登入表單,哪些欄位是帳號密碼,或是網站用不一樣的機制,例如 XHR 來登入,這樣瀏覽器如果無法知道是什麼機制,就無法替這些特殊機制的網站的使用者提供方便的功能,所以 webappsec 就提出 Credential Management 這個功能讓網站開發者可以透過設計好的介面來告訴瀏覽器他們的網站是怎樣登入的,然後可以儲存帳號密碼在瀏覽器端,之後提供 API 給 JavaScript 呼叫出來送到 Server 端驗證,不過說是呼叫出來,其實 JavaScript 也看不到密碼明碼,而只能直接送出 login 的 request:

navigator.credentials.get({ "password": true }).then(
  function(credential) {
    if (!credential) {
      // The user either doesn't have credentials for this site, or
      // refused to share them. Insert some code here to show a basic
      // login form (or, ideally, do nothing, since this API should
      // really be progressive enhancement on top of an existing form).
      return;
    }
    if (credential.type == "password") {
      credential.send("https://example.com/loginEndpoint")
        .then(function (response) {
          // Notify the user that signin succeeded! Do amazing, signed-in things!
        });
    } else {
      // See the Federated Sign-in example
    }
  }
);

這是從 spec 內複製出來的 sample code,一個重點是,JavaScript 程式碼其實碰不到你的密碼,只能直接把 credential send 出去,其它也還支援像是 Facebook 那種第三方登入的設計,以及把 credential 存進 store 等等機制。

第三個是 Subresource Integrity

<script src="https://analytics-r-us.example.com/v1.0/include.js"
        integrity="sha256-Rj/9XDU7F6pNSX8yBddiCIIS+XKDTtdq0//No0MH0AE="
        crossorigin="anonymous"></script>

這是個看範例馬上就能理解幹什麼用的,就是對網頁要用到的其它 resource 檔案包括:js、css 等加上驗證檔案正確性的 hash,為的是避免有第三方的檔案內容被惡意攻擊者修改過。

第四個是 Upgrade Insecure Requests,這是唯一目前已經可以用的,為的是解決 mixed content 的問題,也就是有的網站可能最近才改為 HTTPS 連線,但是網站內部用到的一些內容還是寫死 URL 用 HTTP,這時候瀏覽器就會跳出說網頁內容可能不安全,然而,這些使用 HTTP 的檔案其實可能用 HTTPS 連線也找的到,像是 Flickr、TED 等都有支援 HTTPS 連線,而 Upgrade 就是跟瀏覽器說如果這些內容找得到 HTTPS 的就用 HTTPS 的,而不是指看寫死的 URL,目前 Chrome 43 已經開始支援了,有個線上 demo 可以看,設定方法可以透過 CSP header 加上 upgrade-insecure-requests 或是寫到 meta 標籤裡面(demo 用的)

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

其實這個標準我一開始以為是類似 HSTS,是對現在開的網址本身做判斷是不是有 HTTPS 可供選擇,有的話就改用 HTTPS 連線,仔細看之後才發現是用來處理 mixed content ,可是又看一看發現也有一部份比較新的草稿有講到這個功能,目前討論的版本是用 header:

HTTPS: 1

很簡潔不過還沒瀏覽器支援就是了。

July 03, 2015 03:13 PM

June 23, 2015

timdream

前端開發領域的終結(與重生)

數年前 awoo 給了一篇重要的演講,試圖定義網路前端開發這個領域的獨立的職能,還有其作為基石,不可或缺的角色。從那邊出發,想要寫一下這幾年的觀察與心得。

先大膽的下標:網路前端開發(Web front-end development)即將終結。

就如當年的演講所定義的一樣,網路前端開發一都是跨領域的拉扯與協調。專業的能力必須同時展現在使用者體驗(UX)、專案管理(Project Management)、產品管理(Product Management),以及為了產品選擇最適合的技術的軟體工程(Software Engineering)能力,還有為了產品開發特殊技術的電腦科學(Computer Science)能力。有些團隊的前端開發還會兼視覺設計(Visual Design)。講到這裡,大家有沒有發現其實這邊已經把一個 client application 團隊的所有職能列完了(笑)?前端最大的危機,或是最大的潛能,就是可以成為以下所列的任一職務之一,或是被這些職能吸收:

  • 視覺設計師(Visual Designer)
  • 使用者體驗設計師(User Experience Designer)
  • 產品經理(Product Manager)
  • 專案經理(Project Manager)
  • 軟體工程師(Software Engineer)
  • 電腦科學家(Computer Scientist)

為何要說網路前端開發即將終結呢?首先的問題是專案的大型化與專業化;大部分的網站已經不是單純的資訊載體了,而是堅實的線上服務。一個優秀的線上服務需要專業的分工去設計與實作最好的呈現以及產品規劃,一人或許能兼任多個職能,但是必須要在這多個職能上都足夠優秀。另外一個觀察是市場現實:Web 或是 Mobile Web 還是很重要,但是它一個產品/服務中只會是其中一種呈現,而不會是唯一的呈現。這樣的產品會仰賴堅實的軟體工程規劃去細緻的拆分前後端的功能與實作,而瀏覽器所顯示的「網頁」會越來越像另一個跟 iOS/Android app 並立的 client-side software。這就呼應到最後一點了:在 Web is the Platform 的遠景之下,瀏覽器再也不只是呈現你最獨特又漂亮的版面的佈局引擎,而是和 Windows/OS X/iOS/Android 一樣的應用程式平台與虛擬機。瀏覽器的廠商們也在朝向這個未來努力,累積這個平台提供給應用程式的功能。

我預期前端開發在工程面向的職能會越來越像一般應用程式開發的軟體工程,只是用不同的技術組合,例如寫 iOS 要懂 Swift 跟 AutoLayout,但寫 Web 要知道 JavaScript 跟 CSS。像是這樣的對應會越來越明顯,對軟體工程專業的要求也會越來越高。Web 作為一個獨特的平台,並不代表他的技術組合必須永遠是獨特的。即便是不同的語言(JavaScript),軟體工程模式還是可以交換且通用的經驗。重新發明其他平台累積過的輪子,或是一年換一個 ecosystem 最熱門的工具,並不是真正的經驗累積。更何況技術組合也確實在聚合中:WebAssembly 會開始讓 Web 成為支援多個語言的開發平台,也會有更多的技術被移植到 Web 上,藉由 <canvas> 繞過 DOM,而且實用化(還記得 Flipboard 怎麼在 Web 實作 60fps 效能的版面嗎?)。

我希望這樣的終結是這個領域的轉機。「前端開發(Web front-end development)」的工程面專業化成為「軟體工程(Software Engineering)」的過程是漸進的,只要有正確的心態,一定能和整個領域一起轉換。若有足夠的基礎知識,還可以進一步精進電腦科學的技術。即便不把自己的角色定位為軟體工程師,若有正確的機會,前述的其他職能也不會難以觸及。這是一個在職涯過程中一定會面對的選擇。

畢竟如果不羽化的話,就無法飛行了。


註:之前 UX Mag 也有文章立論「網頁設計(Web Design)」即將終結,而他們的職能會被視覺設計以及使用者體驗設計給吸收。這個狀況對前端開發來說也是相似的。

by timdream at June 23, 2015 12:55 AM