訂閱

上次更新

July 08, 2015 02:01 AM

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

Powered By

Planet

摩茲星球 | MozTW Planet

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

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

June 21, 2015

MozLinks-zh

Firefox 使用者類型研究(北美洲)

從 2012 年 10 月到 2013 年 2 月,使用者經驗研究團隊進行了史上最大的計畫:以北美洲使用者為對象,針對使用者型態進行的大規模研究調查。這不但是獨特且令人興奮的計畫,也彰顯我們優秀的團隊合作。(無論是使用者經驗團隊內,或與 Mozilla 的其他單位皆是)


一位參與者筆電上的 Firefox

研究目標

本專案的主要目標是根據他們的行為、態度、信念和動機來定義和描述使用者族群,我們將這些分類稱​為「使用者類型」(User Type),因為我們的重點放在使用者與產品及服務的互動和行為,而非行銷面向(我們也從這篇對類似研究進行後設分析的優秀論文中借用了「使用者類型」和「使用者分類學」等術語)。

除了定義使用者類型外,研究的另一個主要目標是,清楚地了解我們的使用者,他們是誰、他們如何使用我們的產品和服務。有了這些資訊,我們就可以針對人們實際使用我們的產品及服務的方式來設計產品及功能。 我們相信這些使用者類型,將幫助整個 Mozilla(不只是使用者經驗或產品團隊)做出決策、設定優先順序,為我們的產品和服務指引方向。

我們選擇從北美開始,是因為我們團隊最熟悉這個市場。因為我們團隊主要位於北美,將研究限於美國和加拿大能夠節省交通預算,減少招聘及與第三方廠商合作的費用。

由於具有地域上的限制,我們將盡量避免將此結果套用到其他地區。然而,一些小型的後續研究指出,下列部分分類的特點,仍能套用在其他文化及其他瀏覽器的使用者上。

研究方法

我們的研究分為三個部份:

  • 找尋 24 戶地理位置及人口分佈顯著不同,並使用 Firefox 為主要網頁瀏覽器的家庭,進行晤談,於此研究中,我們試圖探索受訪者在行為、動機、態度及其如何成為 Firefox 使用者的關聯性,我們在多倫多、安大略、北卡羅萊納州的夏洛特和加州洛杉磯等地區周邊完成這些家庭訪談。
  • 針對類似 Firefox 使用者母群進行簡單抽樣,受試者人數為 45 位,邀請使用者填寫線上日誌方式收集簡短縱貫研究的使用者行為資料。
  • 以 1000 人為樣本的量化研究,試圖驗證前兩項質化研究的結果。研究結果發現受試者可劃分為我們先前研究的數個特質,並透過因素分析驗證這項結果,我們還能估計每個使用者類型在母群所佔的百分比。

身在定性研究的分析迷霧中

研究結果

Firefox 使用者類型

基於以上的量化研究,我們發現絕大多數的 Firefox 使用者(約九成)或多或少都能歸類成某個類型。雖然很多人擁有多重類型的特質,但這些使用者最後都能被歸納為於某種特定類型。少數使用者所表現出的特質則介於多種特質之間。

以下是我們找出的六種使用者類型,與其主要的相關屬性,包含:

  • 一段第一人稱的敘述,描述此類使用者的動機和行為
  • 該類型佔整體 Firefox 使用者的百分比
  • 與該使用者類型相關的人口統計數據

我們要特別感謝為每種使用者類型設計出下列圖形的 Zhenshou Fang

熱衷者

我熱衷於了解與採用新科技。我也喜歡自己解決技術問題。

屬性

  • 熱衷於新科技
  • 會自行解決遇到的技術問題
  • 想要掌控自身的瀏覽體驗
  • 很可能有自訂瀏覽器
  • 對新科技有自信
  • 在裝置間同步、傳送資料與媒體
  • 絕大部分經常上網
  • 很可能曾上大學或具有學士以上學歷
  • 偏向年輕的年齡層

忙碌蜜蜂

我的生活忙碌,希望科技能用就好。對於生活中科技背後的技術細節,我不感興趣。

屬性

  • 使用科技:網路就是一種「家電」
  • 忙於生活中的各種活動,不優先把時間用於網路中
  • 對於科技背後的細節不感興趣
  • 對於技術問題感到厭煩
  • 部分資料有跨裝置互動
  • 偏向女性
  • 偏向年長

中階經理

我對於科技感到自信與習慣,特別是排除問題。科技是我日常生活的重要元素,但在採用新科技我會先小心評估。

屬性

  • 對科技感到自信且習慣,但不熱衷
  • 工作、就學與生活都與科技完整融合
  • 能有耐心地對解決自身的技術問題
  • 採納最新的工具與功能,但會先做考慮
  • 可能使用手機、可能整合資料進手機
  • 多工且自訂化
  • 教育程度較熱衷者與魔法師為低
  • 常上線

堅定用戶

就算可能已經過時,我還是會持續使用確定能用的技術。我頑強抵抗更新現有科技,因為我相信「沒壞,就別修它」

屬性

  • 抗拒變化
  • 非必要下避免升級工具或技術
  • 偏好已知甚於未知
  • 在網路上花費的時間不連續
  • 可能擁有較舊的科技
  • 有限的行動裝置或智慧型手機使用率
  • 此類使用者年齡層分布較廣

長青樹

我生活中的大部分時間都不仰賴科技。對於使用科技我感到有些抗拒,因為我怕犯下無法更正的錯誤。

屬性

  • 對新工具與自訂化感到不習慣
  • 沒有網路也可能活得下去
  • 學習科技就跟職訓差不多
  • 同時使用老工具與新科技
  • 網路不是他們生活的重心
  • 在技術問題上仰賴他人
  • 教育程度較低
  • 年齡分布偏高

魔法師

我喜歡幫自己和別人撰寫程式。技術就是我的生命。

屬性

  • 軟體開發者或工程師
  • 對網路有非常準確的認知
  • 對安裝、使用與排除技術問題感到信心
  • 喜歡創造技術
  • 通常對 Firefox 感到高度滿意
  • 高度理解且熟練技術
  • 教育程度較高
  • 偏向男性

您覺得自己屬於哪一種類型呢?

原文 / Firefox User Types in North America
授權 / 創用 CC 姓名標示-相同方式分享-3.0

φ chiaoju、Irvin 翻譯 - Roger, petercpg, shadowcrow, BobChao 編輯

by Irvin Chen (noreply@blogger.com) at June 21, 2015 09:54 AM

June 17, 2015

Othree

GHCJS

最近幾天把 GHCJS 研究了一遍,一開始的需求是因為開始用 pandoc,然後想要用 JS 提供即時的預覽,因為 Pandoc 是 Haskell 寫的,所以看下來自然是看到 GHCJS 了,其實網路上以經有人成功的把 Pandoc 轉成 JS 了,叫做 markup.rocks,我後來也是基於他在 github 上公開的這些程式碼來研究。

要安裝 GHCJS 有點麻煩,以 OSX 為例,要先去下載 GHC 的 binary distribution 壓縮檔(ghc-7.8.3-x86_64-apple-darwin.tar.xz),解壓縮後,進目錄執行:

./cofigure
make install

安裝完 GHC 後要更新 cabal 這個套件管理工具:

cabal install cabal-install

然後這樣會把 cabal 裝到自己 home 目錄下面,所以還要更新一下 $PATH:

PATH=$HOME/Library/Haskell/bin:$PATH

接下來才是安裝 GHCJS:

git clone https://github.com/ghcjs/ghcjs-prim.git
git clone https://github.com/ghcjs/ghcjs.git
cabal install ./ghcjs ./ghcjs-prim

要用 GHCJS 之前,還要安裝一下環境的基本套件:

ghcjs-boot --dev

如果一切順利的話就可以開始把 Haskell 程式轉成 JS 了,不過事情當然沒這麼簡單,首先 GHCJS 的套件和 GHC 的套件在本地是分開的,要裝給 GHCJS 環境的話,要加上 --ghcjs 的選項,例如:

cabal install --ghcjs pandoc

這樣裝的套件才能夠讓 GHCJS 轉譯時使用,然後第二個問題就是上面這個指令其實裝不起來,因為 Pandoc 和 GHCJS 不相容,markup.rocks 的作者 Ozan Sener 其實有 fork 一份 Pandoc 針對這個問題作 patch,所以安裝改成下面的指令:

git clone git@github.com:osener/pandoc.git
cabal install --ghcjs ./pandoc

不過還是會有些問題,基本上就看缺什麼用 cabal 裝一下,然後有些錯誤要簡單修改一下程式碼,詳情不是很重要,因為接下來馬上有第三個問題,就是這樣裝起來後,會發現要成功的轉 markup.rocks 還是有問題,其中 reflex-dom 一直裝不起來,這個套件主要是拿來做網頁介面的,所以我把 Main.hs 內只和 pandoc 相關的抽出來,想建立一個只有 pandoc 單純一點的 Haskell 程式,然後一番努力後,終於成功了,這時同時出現兩個問題,第一個是產出的檔案超大,有 20MB 左右,markup.rocks 線上 demo 放的是有過 closure-compiler 的也還有 2.2MB,而另外一個問題,是我找不到程式可以讓我抓到輸出入的位置(嚴格來說有找到但是無法用),後來又查了些資料才發現,GHCJS 目前還沒辦法把 Haskell library 單獨轉譯然後開 API 出來,一定是一個完整的 Haskell 應用程式,然後編譯出來的 JS 就是執行這個程式,沒有外面插手的餘地,換句話說,就是所有事情都要用 Haskell 完成,然後用 GHCJS 編譯成一個獨立的 JavaScript 應用程式,GHCJS 的 Issue 194 就是在講這個問題,看起來離有結果還有些距離。

總之結論是,目前 GHCJS 還不到真的可拿來做應用的程度,最後遇到的兩個問題算是比較大的,就是輸出檔案太大和只能把整個應用程式轉譯成 JS 這兩個問題,不過事情總是要有開始,希望未來有一天這兩個問題能解決,就能夠把 Haskell 的一些工具轉到 JS 上了。

June 17, 2015 04:08 PM

Irvin

MozTW Steps - 服務學習專案規劃

目前各大學都有一堂服務學習必修課程,通常是安排在大一時且零學分(不影響成績),目的是想讓同學可以付出自己的時間(通常一學期 10~15 小時),協助各項公益計畫或團體,有益於社會且從中學習。

過去兩年中,MozTW 與教育部校園自由軟體中心(OSSACC)合作,在交大與中央大學,執行了三學期的服務學習計畫,讓同學從翻譯 Mozilla 補助說明文章、推廣與說明影片、網頁開發技術文章、Firefox 套件與軟體的中文化…等等項目中選擇,運用自己的閒暇時間,對 Mozilla 專案做出些許貢獻,接觸並了解開源碼計畫的執行方式。

MozTW Step

三月時,MozTW 在台中舉辦了兩天一夜的 MozTW Steps 活動,對於各專案計畫進行未來半年期的分析語討論。對於服務學習專案,我們也進行了一些規劃。這是討論時的海報,以下將會簡要說明。

Planning - Service Learning

計畫目的

服務學習計劃的目的,主要有以下幾點:

  • 讓社群能接觸年輕一代的同學,傳達 Mozilla 理念給更多人
  • 尋找認同且持續貢獻 Mozilla 專案的成員
  • 推進 Firefox 補助說明文章翻譯完成度,協助更多使用者
  • 增加相關影片的字幕,益於推廣的理念

過去成果

我們簡要分析了一下過去的成果。共有 49 名同學參與,完成了 20 部宣傳短片字幕、38 篇 Firefox 補助說明文章、10 篇網頁開發技術文章、4 篇報導與 1 個 Firefox 套件的中文化。

過去的成果都整理於此:

近期參與對象

本年度服務學習的合作對象,包含交大資工的大一同學約 15 人;另外中央大學也由 Angelboy 號招資訊社團中有興趣的同學進行。

下學期可能的對象,除交大外,另由黯鴉在協調中原大學的老師與同學參加。

資源

在推動服務學習計劃時,我們主要有兩個資源可給予同學:

  • OSSACC 協助核發的服務證書
  • 我們可簽發英文的 Mozilla 貢獻證書

挑戰

服務學習計劃的主要挑戰有二:

如何找人

要將服務學習推廣到一個科系,首先要有該科系負責該課程的教授認可,而與教授接洽、聯繫則需要各科系的在學同學協助。

如何帶領

專案執行時,會先讓同學選定有興趣的項目,再由我們寄送「如何進行」的說明文件。同學做完後我們則需要編輯、修定、掌握成品的品質。

這方面則面臨能協助與修訂成果的人不夠多,對成果與品質的掌握度不足的問題。

持續貢獻

每學期的計畫結束後,我們尚無進行後續追蹤,無法了解參與的同學是否仍持續貢獻,也因而無法有效擴大貢獻者基礎。

解決方案

針對上述問題,我們則想到了一些解決的方法。

製作計畫網頁

在「如何找人」的問題上,透過製作「服務學習專案網頁」的方式,彙整成果,並且加上「如有興趣參與,歡迎聯繫…」的聯絡資訊。一方面如果有教授看到感興趣,即可與我們連上線;另一方面,整理出更清楚的相關資訊,也可讓想協助推動的同學,更容易提供負責教授參考。

校園大使

我們發現服務學習計劃,與 Mozilla Taiwan 公司已執行兩屆的「Firefox 校園大使(FSA)」,可以構成相輔相成的雙環。參加過服務學習的同學,我們可以推薦他們參加校園大使,更加深入 Mozilla 的文化與內涵;而歷屆的校園大使,對 Mozilla 已有充足的了解,除可成為協助新同學進行服務學習的角色,也可協助我們聯繫各科系的負責老師,找尋新的合作對象。

行動計畫

  1. 招募十位歷屆的校園大使,協助他們成為服務學習的 Mentor。
  2. 聯繫參加過服務學習的同學,推薦他們參與校園大使計畫。
  3. 尋求一至兩人的協助,製作服務學習計劃網頁。

by Irvin Chen (noreply@blogger.com) at June 17, 2015 10:51 AM

MozTW 為何要堅持社群獨立性—智財局封網法案的案例 The case of MozTW campaign against internet regulation bill

Brief for Mozillians: The slides is about an local campaign we ran, against a SOPA-like bill in last June (2013) in Taiwan. I'd like to share this experience for all, to get the idea that what can we do as a Mozillians and a Mozilla community, to dealing with these kinds of political issues for protect internet freedom.

MozTW 作為一個 Mozilla 的在地社群,維持獨立性一直是我們堅持的一件事情。

Mozilla 的社群成員多數有某種「Mozilla 如果違反 Mozilla 宣言,我們身為社群的一份子必群起反對」的原則,從各種爭議,例如先前的「首頁廣告」、「Brondon Eich 的正反爭議」中都可以看到。當然我們 MozTW 也不例外,從反對 Firefox 台灣版行為追蹤、應對 mozilla.org/zh-TW 的強制轉址上,都可以看出我們身為 Mozilla 社群,維持獨立性、堅持應有價值的意義。

去年(2013 年)六月的智財局封網事件,也是 MozTW 社群獨立行動以堅持 Mozilla 信念的代表案例。在那之後,我們真的一直沒有空把相關的前因後果整理出來。趁著這週在舊金山參加 Mozilla 基金會全員會議,跟其他人分享相關案例的機會,整理了一份投影片。歡迎各位留言或到 moztw-general 提供意見與建議。

長久一來一直礙於人力不足,其實社群還可以做的更多、還有更多事可以做的更好,歡迎有興趣協助的人一起加入

Specially honor the two contributors of the blackout codes,
最後特別要表彰一下,元兒小喵 貢獻Blackout 程式

by Irvin Chen (noreply@blogger.com) at June 17, 2015 10:51 AM

Events of Taiwan community: challenges, evolutions, and survivals in 2012

I'd just joined >MozCamp Asia 2012 in Singapore (Nov 16~18), and had a session Events of Taiwan community: challenges, evolutions, and survivals in 2012, here is the slide and my speaking draft. I hope that our experience could make some help to my beloved Mozilla worldwide community.

Irvin Chen / Volunteer / Mozilla Taiwan Community TW community liaison since Nov. 2011

MozTW Brief intro

In the beginning, I'm going to give a brief intro of Mozilla Taiwan community. Established in 2004, making contribution by maintaining product localization and & localized product sites, MozTW turned out to be a project-oriented community: including online/offline marketing campaigns, evangelism talks, localizations, and contribution in different Mozilla projects.

The challenges of MozTW: From my point of view

Before I start of the challenge part, I'm going to make a DISCLAIMER: Ideas below may or may not representing other MozTW member's idea. This is what I observed from my own contributing experience, others might not think it's a big problem, or the problem might not exist at all.

Community age problem

As time passes, if a community doesn't grow with enough younger participation, the average age of community contributors becomes older. Also you'll find out you have no that much time after graduated, and the same situation happened across all the active folks of your community. Many of the communities are formed by a herd of college students, so you can foresee such a problem in 4~5 years if the community were newly burned in your region.

Market Changes

I feel that the change of the browser market / OSS environment makes us harder to recruit these days. When we begin, there are only several browsers in the market, Firefox represents innovation and creativity, it's a little rebel and hacks culture, it's cool. At that time when a people wanted to join some internet interesting group and contribute in a non-programming field, you don't have so many OSS/software communities choices like today. This day there are other browsers which thinks to be cooler than the old fox across techies, the opportunity to contribute, with the spirit of the social action are much more.

Take events for example, 5 years before, there were not so many events for geeks like our Firefox Party in Taiwan, I think it's easier to gather hundreds of attendees and have much attention to our campaigns, but it's much harder today. Taiwan has population about 20 millions, and In this year we have more than 10 houndries attendee conferences, subjetive on OSS and web. The growth of internet and globalization OSS projects also have some effect, one can easily find events, communities, reach and contribute remotely to non-local project. I think it's make us harder on our recruition today.

The "Official Mozilla" problem

We now face challenges from new "official" player on Firefox marketing / representative, and I expect company is going to grow its new community in the marketing strategy.

Mozilla office in Taipei was established last year right after MozCamp, before that, we had discussed some of the problems we may face across core contributors of Taiwan. In this year, I have seen many things we were worried at that time, which I don't really want to see, resulting in much more challenges. Which may happened again, if Mozilla is opening new office, then we may want to avoid them.

1. You're no longer the "Mozilla representative"

MozTW was the de facto "Mozilla representative" before. After the local company opens, when people want to contact Mozilla, they'll directly contact the company, and since it's related to end-use marketing, if the information doesn't been bounced to community, which means much less co-operation opportunities and much less eyes attracted on community.

And there is a branding problem, if your community use "Mozilla-country" as your name, you may have to prepare for the naming transition, for that this is the offices' formal name. In fact, we don't really have the choice deal with this situation, this problem had been foreseen by BobChao, our previous community liaison many years ago, so we'd used MozTW and Mozilla Taiwan Community bi-branding for years. But when we actually deal with the situation today, it's still hard to come out with a good enough branding strategy, weather to promote the "Mozilla Taiwan Community" on our events? Or to use "Mozilla Community" only? Or using "MozTW" preventing distinguish to "Mozilla Taiwan", the official name of office?

As my own observing, people just couldn't understand. In fact, they don't find there is several Mozilla depart at all.

2. You're losing your volunteer while the company recruit

Once the office is open, you may find out your hardly-working community guru to be hired, and they had much less time contribute to community projects. The better they had done before, the harmful it would be. In conjunction with the age's problem of community and recruitment problem, it'll became hardest challange you'd like to deal with.

It's true that the problem will naturally begin to exist as the time pass, whether the offices open or not. Community always lose core contributors as they graduate from school and if they are not luckily enough to find the job which can have enough leisure time to contribute, but I was hoping it may be difference when it comes to Mozilla. It's seems that it's my too idealistic wishes when our community contributors joined the local office.

3. You'll see competing campaign/sites/community appear

While the local company doing end-user promotions, as time passed, many events/campaigns rolled out one by one. You'll begin to see the competing projects to what your community were doing unavoidable.

Campaign

From online campaigns such as facebook pages to offline events such as workshops and speeches, I'm frustrated for that with the full time employees, engineers and budget supplement, their campaign seems eventually more successful than what communities did. <- their campaign would be probably more successful than what communities did. ??

We used to translate news from Mozilla and Mozillian's blogs to a Trad. Chinese Mozilla Links, since it's a community volunteer project, we could not control the effectiveness but quality. Nowadays, when local office can publish the "latest" news in synchronize with Mozilla Press blog, that's the efficiency we can never achieve ever. How could our campaign compete with the company's similar one, for that you can only exchange your sleeping time while they're working on a daily basis? It turned to be no choice but to give up translating and spreading the news, also on many campaigns which local office may be interested in, and choose what they're not.

Websites

Second is about websites. After the local company opened their site, your community portal are no longer the second Mozilla sites anymore. Users will see 1) localized mozilla.org, 2) local office's mozilla.com.country and 3) community's site. All 3 different sites are shared with similar contents and same propose - to spreading information about Mozilla, and the same action - to provide Firefox download. If one user could found that there are more than one site exist, he'll be frustrated with them no doubt. I think most of the users don't really figure out there are.

Even further, one day you may surprisingly found that mozilla.org been redirected to local office's website, instead of the normal localized mozilla.org in your language. It has not happened on zh-TW yet, and I'll never eager to see it happened. Why bother to do so when l10n contributors are taking good care of mozilla.org, when it comes to One Mozilla conception?

Anything more to expect? Has your community ever built a forum? What if you found that one similar section appear at local official site? What would the originnal forum users thought? That's the best negative message from "One Mozilla" that we could convinced our users regionally.

Community

With the local company's some kinds of campaign begin, you may expect the other "more official" community begin to exist, while they started recruit volunteer/students. The worse thing is that you're still facing the recruit problem we mentioned before, and you may have to keep thinking "how to recruit new contributors on community's projects, from our already recruited local office's contributors." How weird is it.

It turns to be the original community are not the only Mozilla community anymore, although it was, it's not, maybe for some employees POV.

How about from the One-Mozilla POV?, the overall community is growing while your formal community weakening on behavior of above problems. It's true that our own community may not include all of the Mozillians in our region, and an alternative communities may have been running more systematically with the direct instructions from local company, and the overall perceptions of Mozilla and Firefox to audience may increasingly. But for me, the problems are more emotional than rationally.

I couldn't questioned my believed methods to making Mozilla stronger. For the love of my community of which I begin to contributed, for the different expectation from Mozilla manifesto I believed in - "the trust of our transparent community-based processes, and the way we use to build communities that support the Manifesto's principles. To saw a community been weakening from above problems, I found that I couldn't be as proud to mention the openness and our community approach as I was before.

The evolutions and survivals of MozTW

Next is the quick review of evolution and survival of MozTW this year

Offline events of 2012

In 2012, we had several offline events, such as a co-hosting Firefox-Ubuntu party in April, and Webmaker Pop-up party running joinly with local Mozilla office.

We kept running weekly MozTW Lab Cafe and Gathering routined meetings continuously, for community members to gather and share with each other. It seems more people are attending regularly this year.

The campaign of browser pairs game

And about online events, besides regularly updating of the our portal site, our main brick-and-click campaign this year is "Browser Pairs Game" as mentioned in the earlier session by the author WM and littlebtc. We promoted Firefox for Android, the responsive design of our community sites our mascot Foxmosa and HTML5 all in one single joyful game campaign, not forgot to mention how happy to see the audience react, when they found the unique design of the game. I could not forget to thanks for the Firefox Mobile marketing team on supporting the campaign.

And We're planning to keep running the campaign, also roll-out more games to promoting the mascot and the delight of HTML5, and have more fun this year.

The l10n challenges

Due to the challenges I'd mention above, I believed we have to avoid doing things which the local office began to work on, that is, we have to decreasing the translation of blog article and building l10n product sites, divert our attention to other fields. One of the approach we tried is the video subtitle translation with Amara. After finish several short videos such as "A Different Kinds of Browser", "The Mozilla Story" and "Looking Ahead", we challenged to hosting a 2-day workshop translating "Code Rush".

With the total attendance of about 20 contributors, and several days of over-night working on adjusting the subtitles, and with the gracefully supporting from Tara Hernandez with her video clip, the screening of <Code Rush> at local cinema with hundreds of attendees on Soft Freedom Day turned out to be the most success events of this year.

From passive to active recruit, try to target the different audience

In the past, most of the core contributors of MozTW are recruited from workshops and events such as school tour. But it costs to prepare the event and contents, and it's hard if we don't have someone at desired schools to help. Also the opportunity of arranging the speech at schools are more difficult these years. Consider the costs to recruit of each contributors, it seems not a good way for us to perform.

We do have a contribute page on our website, but it's not working well, not many people join us with that page (I can't even remember any), it's obviously we need to be more active on recruit.

We tried recruit new contributors at several offline events, we prepared a questionnaire with the option to choose from website, l10n, arts, campaign planning and programming, trying to target the different contribution field of portential contributors. Then we could point the appropriately project for them to begin. It's kinds of offline version of "What can I do for Mozilla".

We had not focused on programming before, this year we began to recruit students to try the good first bug, with the help from Thomasy, (whom is Mozilla rep) and Kenny (The web specification guru), and we had several success cases on that.

Another trial I performed last month is set a booth on an Donjinji event (which named comikon at many country, the spare-time comic-er exhibition), displaying illustrates of Foxmosa and Browser Pairs game, try to recruit voluntary illustrators, I indeed got many attendees sign-up for more information, but not getting active contributors yet. But just like recruit programming students at OSS conference, I think to target the specific audience is one of the possible solution to decrease the difficult of recruition.

The 2012 of MozTW and me

We may faced many challenges and decisions made to try hard on evolution, at least, we survive and I'm standing here to share our experience with all of you. It may be a hard year for me to try, and to explore to be a competent community liaison, but it seems we still alived good, maybe we're doing better than I wonder?

What I dream of…

When I reading the Mozilla Manifesto, and when I watching "the different kinds of browser",
I dreaming a community that full of people toward the same goal:
working together to growing the web to a better place,
to bringing the awareness of important things we value high,
and to helping users browsing happily, social with their friends and to realizing their dreams online.
and I know, in the mean time, we're also growing ourselves.

I dreaming that while I give up my sleep time, translating the latest news of Mozilla,
some other contributors are working at the other side of the planets Earth,
Whom I have not met, but I can see them on IRC, on mailing list,
and I can hear them arguing for some most important decisions we had to make,
according to our core values, and to our users' best.

I dreaming that I can be sure when I was tired,
community will still exist for long,
my friends will still happily contributing to the projects,
and I know the cooperation will be our strongest support for now and ever.

I can dreaming that when I leave,
the Internet will be a more friendly place, and the world must be better,
even though we only improve it once a small bit...
That I can proudly to said I was in the project, and I'm the lifetime Mozillian.

For all the dreams of mine, giving my sleeping time and my life,
keep think and try to find the solutions, of all the problems and challenges above,
try every hard to keep community exists, alive and growing,
then maybe I can be here next year once more time,
and to share our successful experience with all you my friends here.

Thanks

by Irvin Chen (noreply@blogger.com) at June 17, 2015 07:11 AM

June 15, 2015

MozLinks-zh

摩茲動手做(四)幫 Firefox OS 修 Bug 的第一步

摩茲動手做系列許久不見,第四集終於來了(三年了!)。本文的作者是交大資工的 Yu Wen Pwu 同學。Yu Wen Pwu 本學期以「幫 Firefox OS 修 Bug」,作為他的大一服務學習課程內容。短短幾個月的時間,已經送了 6 個 Patch,也有三個 Merge 了!

幫 Firefox 修 Bug 不分年齡與經驗,歡迎大家一起來挑戰各式各樣的 Good First Bug。(歡迎大專院校老師們一同來推動,以貢獻自由軟體作為服務學習課程,請聯繫教育部自由軟體推廣中心


Firefox OS 所有的 bug 都是在 Bugzilla@Mozilla 平台上管理的。因此,第一步當然是先到 Bugzilla 認領一個您想修的 bug (建議從簡單的 good first bug 開始)。或者,您也可以在 Bugzilla 上建立一個新的 bug。

接下來,有一些前置作業要完成。請先在 GitHub 上 fork 它所屬的 repository,例如 Firefox OS 的前端 Gaia:mozilla-b2g/gaia。接著請回到您的本地端,執行以下指令:

$  git clone https://github.com/username/gaia.git
$ git remote add upstream https://github.com/mozilla-b2g/gaia.git
$ # check if you have added 'mozilla-b2g/gaia' as 'upstream'
$ git remote -v

每次開始修 bug 之前,請記得從 upstream 抓取更新,使您的本地端 repository 保持在最新狀態。請執行以下指令:

$  git remote update
$ # do not use 'git merge upstream/master'
$ # use the following command instead
$ git rebase upstream/master

然後就可以開始修 bug 囉。為了維持簡潔明瞭的 commit log,您應該將所有變更提交為單一一個 commit。您可以參考以下指令:

$  git add filename
$ # your commit message should be in the following form
$ # Bug id - Description of your patch r=reviewer
$ git commit -m 'your commit message'
$ git push origin master

再次提醒您,如果您提交了超過一個 commit,請務必將其合併為單一一個 commit。您可以參考以下指令:

$  # show the commit history
$ git log
$ # n: the number of commits you want to squash
$ # please replace 'n' with any positive integer
$ git rebase -i HEAD~n
$ # into interactive mode
$ # step i. replace 'pick' with 'squash' except for the first line
$ # step ii. modify commit messages
$ git log
$ # now you should see n commits combined into a single commit

最後,請至 Mozilla 的 GitHub repository 提出 pull request。同樣地,pull request 的標題必需符合 "Bug id - Description of your patch r=reviewer" 的形式。這時系統應該會自動為您在 Bugzilla 上新增一個 attachment,其檔案名稱即為該 pull request 的網址。請在 attachment 上指定 review flag 給相關負責人。

負責人檢查過您提交的程式碼後,請到 Bugzilla 為該 bug 新增一個 keyword "checkin-needed",讓系統自動處理您的 pull request。現在就只要等候您的 pull request 被 merge,然後再前往 Bugzilla 將該 bug 的 status 變更為 RESOLVED FIXED,就完成囉。

如何測試 Firefox OS?

Firefox OS 的架構分為:Gonk > Gecko > Gaia。Gonk 是系統核心,以 Linux Kernel 為基礎。而 Gaia 則是 Firefox OS 的前端,完全採用 HTML、CSS、JavaScript 等網頁程式語言來撰寫。要測試 Firefox OS 最簡單的方法是直接在 Firefox 瀏覽器上模擬。您只要開啟 Firefox,點選右上角的開啟選單 > 開發者 > WebIDE,選擇一個 Runtime (若選單中未出現 Firefox OS,則需先安裝一個 Firefox OS 模擬器),就可以直接執行 Firefox OS 囉。

原文 / 網頁設計微筆記: 12.5 參與 Mozilla Firefox OS 開發的流程
作者 / Yu Wen Pwu
授權 / 創用 CC 姓名標示-非商業性-相同方式分享 4.0 國際 授權條款授權

by Irvin Chen (noreply@blogger.com) at June 15, 2015 01:17 PM

May 18, 2015

Othree

TypeScript, AtScript, ES Decorator

AtScript

前陣子花了些時間研究了 TypeScript 和一些相關的發展,包括了 Google Angular Team 的 AtScript 和推進 ES 標準的部分,會開始感興趣深入研究主要是因為 Angular 2 說改用 TypeScript 寫,好奇為什麼會有這樣的發展才下去搜尋資料的,這篇文章算是記錄用的,不過其實離寫好已經一陣子了,因為剛好遇到 Modern Web Conf,想說拿這題目去分享,就讓文章晚點上線了,後來投影片還有補充些內容,這篇文章就沒再更新了,所以兩邊會有些差異就是~

ECMAScript 標準一直以來都是動態型別的,雖然資料有不同的型別,但是變數本身是沒限制型別的,而在 ECMAScript 發展的過程中,靜態型別第一次出現是在已經被廢棄的 ECMAScript 4 裡,網路上還可以找到一些資料,可以看看當時設計的語法,和現在常看到的 :type 的寫法很接近,後來這個設計也在 ActionScript 3 中被使用,微軟現在的 TypeScript 也是用這種寫法。那加入靜態型別的特性會有什麼好處呢,我認為有兩個主要的優點,第一個是可以讓程式碼更可靠,減少一些 bug 發生的機會,對於大型專案來說,多了這個限制的差距是蠻大的,另外一個優點則是 JS Engine 更好最佳化,以前也有提過現在的 V8 引擎就已經會判斷變數的型別會不會有變化來做最佳化了。

或許是因為微軟對於大型專案開發的關注比較多吧,他們於 2012 年推出了 TypeScript,為 JavaScript 加入了靜態型別,用的語法很簡潔:

var i:int;
var message:string;

另外還提供了當時沒有的 class 和之前提過的定義檔等東西,TypeScript 一開始是基於 ECMAScript 5 設計的,不過在 ECMAScript 6 差不多定案後,微軟也開始著手把 ES5 based 改成 ES6 based,像是 class 就會改用 ES6 原生的,而 TypeScript 所提供的靜態型別檢查功能其實是靜態分析而已,也就是只有在把 .ts 檔案編譯成 .js 檔案時會做檢查,而由於 JavaScript 還沒有 type 的特性,所以這些型別的資訊其實在編譯過後都會被拿掉。目前除了 AngularJS 2 改用 TypeScript 之外,還有像 Asana 和 Mozilla 的 Shumway 都是用 TypeScript。

Google Angular Team 似乎對此還不夠滿足,因此他們開始發展 AtScript,在 TypeScript 上再加入 annotation 的功能,名稱的 At 代表的是 @ 這個符號,因為這個符號是很多語言寫 annotation 用的符號,自然 AtScript 也是用這個符號來標記 Annotation:

@Component({selector: 'foo'})
class MyComponent {
  @Inject()
  constructor(server:Server) {}
}

Annotation 簡單翻起來也是註解,不過他和 comment 不一樣,不是給人看,而是要給 compiler 和 JS engine 看的,而且實際上也會影響程式的一些運作,annotation 應該是一種完全沒有也不影響程式執行的 metadata,不過細分下去應該可以分為兩類,第一種是 Java 的 annotation,以 metadata 為主,像是物件的角色、物件間關係等,另外一種則是 decorator annotation,可以讓函數加上各種不同特性,其實就是 decorator pattern 的簡易語法,看到一些範例當中,最讓我覺得厲害的就是 memorize 了吧,如果程式引擎支援,加上一行 memorize 的 annotation 就可以讓那個函數自動有 memorize 特性,如果使用不支援此特性的引擎來執行程式,函數的輸出也不會有錯,就是沒有 memorize 的效果,效率會比較差,Python 中就有 lru_cache 這個 decorator 可以做到這樣的效果(Python 的 decorator 語法是提供 syntax sugar,不過寫法和其它語言的 annotation 很像):

@lru_cache(maxsize=None)
def fib(n):
    if n < 2:
        return n
    return fib(n-1) + fib(n-2)

AtScript 一個很重要的原則是這些附加的資訊,都要在 runtime 可以使用,所以就不像 TypeScript 那樣只是把不支援的東西拿掉而已,像上面費氏數列的程式碼如果改用 AtScript 寫會變成:

@lru_cache()
function fib(n) {
  if (n < 2) { return n; }
  return fib(n - 1) + fib(n - 2);
}

然後用 AtScript compiler 編譯過後會多上一段程式碼做類似下面的事情:

fib.annotations = [
  new lru_cache(),
];

這個 annotations 屬性在 runtime 時就是可以取用的資訊,目前 AtScript 的 annotation 就是比較偏重於 metadata 而不是 decorator,所以這些資料並不會直接讓函數有不同特性,而 AtScript 另外一個新東西 introspection 也是和 runtime 有關,是 TypeScript 所沒有的 runtime 時的型別檢查,JavaScript 要怎樣做執行階段的型別檢查呢?沒錯,基本上就是土法煉鋼,不過 AtScript 是引入一個 rtts(run time type assertion) 的 library 來做這件事,目前主要也是用 Angular Team 維護的 assert.js,本來的 fib 再改寫一下:

function fib(n:number):number {
    if (n < 2) { return n; }
    return fib(n - 1) + fib(n - 2);
}

然後編譯過後大概會變成:

function fib(n) {
  assert.argumentTypes(n, number);
  if (n < 2) {
    return assert.returnType((n), number);
  }
  return assert.returnType((fib(n - 1) + fib(n - 2)), number);
}

可以看到不管是在函數開頭還是要回傳之前,都會多了用 assert.js 做型別檢查的程式碼,當然,多做的這些型別檢查是會造成效能影響的,所以 AtScript 把 runtime 的型別檢查分成兩個階段,開發階段和成品階段,成品階段,要上線的時候,就輸出不包含型別檢查的 js 程式碼,這樣就不會影響效能。AtScript 其實目前沒有自己的編譯器,而是使用 Google 的 Traceur,Traceur 基本上是個 ES6 to ES5 compiler,不過實際上他還多一些非 ES6 標準的語法支援,包括了前面提到的 Type、Annotation,不過使用時要加些參數:

traceur --annotations true --type-assertions --types true fib.ats --out fib.js

ng-europe 研討會,就有一場關於 AtScript 的演講:

裡面除了基本的介紹,為什麼會發展 AtScript 之外,還有很重要的未來發展,Angular Team 是有打算把 Type、Annotation 等等特性推回 ECMAScript 未來的標準之中的。在 ECMAScript 標準的發展上,其實早在之前就有一些變數型別相關的功能在討論,包括了 typeguard,不過都沒有進到目前的 ECMAScript 6(2015),目前 AtScript 和 TypeScript 兩者正在逐漸互相同步,也有共同合作,而且 AtScript 還沒有嚴謹的 spec 文件,所以會看到官方發佈說 AngularJS 2 用 TypeScript 開發,而不是用 AtScript,目前看到 TC39 討論裡面,除了 type 之外,幫其它新東西提出 proposal 的,很令人意外,竟然是 Yehuda Katz,可以看到去年四月的會議記錄就有他提出 decorator 特性的討論,另外 TypeScript 的 Issue 1557 是關於在 TypeScript 中加入 AtScript 的 annotation 支援,Yehuda Katz 也有提到他正在整理相關資料,幾週後會在 TC39 會議提出,在他的 github 帳號上也可以找到相關的資訊,我個人對 Yehuda Katz 評價很高,不過實在是想不太到為什麼會是他跑出來推動這部分的發展,不過總之 Yehuda Katz 打算提出的是比現在 metadata 為主更進一步的 annotation,也就是包含像 Python decorator 特性的 annotation,如果真的順利成案,其實也不知道是好是壞,好的是一些程式碼可以更簡潔,壞的是 JavaScript 語法越來越多,入門要學的東西也變多很多。

May 18, 2015 10:24 AM

May 16, 2015

Othree

TypeScript 過去、現在、未來

今年 Modern Web Conf 的投影片喔,其實整份演講最重要的點就是 type 看來就是會進入 ECMAScript 了。

May 16, 2015 07:03 AM