八月 9, 2016
» The newbies workflow on Mozilla Gecko project

As our recent development focus shifting from Firefox OS to Firefox, we need contribute to gecko repository directly instead of contribute to gaia repository. The most of works are still related with Javascript, the main change is the workflow and API difference.  In Gaia we works between Bugzilla and github; In gecko, we have Bugzilla and mozReview.

Once you have setup the environment, the workflow could be still based on git, and most thing are dealt automatically. Mozilla is a pretty open workplace so I can share my workflow with the world. Here are a reference about how I did for per patch/weekly/per setup/one time workflow.

Per patch workflow

When I work on a new bug, I'll checkout a new branch (on mac)

$ git checkout -b bugxxxxxxx inbound/branches/default/tip
or (on ubuntu)
$ git checkout -b bugxxxxxxx inbound/default
Usually the bug is focus on a component of gecko, such as `browser/components/customizableui`. To make .js/.jsm changes work, we don't need to rebuild gecko. But to make some C++ code or new test code works, we need to rebuild this part of source via

$ ./mach build browser/components/customizableui

Once we have some progress for the patch, we can test code via command:
$ ./mach test browser/components/customizableui/test
Once the patch is ready, commit it as normal git commit, with a structured syntax:
`Bug xxxx - description. ;r=?reviewer_bugzilla_alias`.

Then, use git mozreview command to push the commit onto bugzilla for review.
$ git mozreview push
Ooh, you also need to make sure you've followed the JS code style https://wiki.mozilla.org/DevTools/CodingStandards#Code_style and CSS code style https://wiki.mozilla.org/Firefox/CSS_Tips

You can use try chooser http://trychooser.pub.build.mozilla.org/
 to select test suites that runs automatically on the test server. Treeherder is Mozilla's test server hosted on AWS (Amazon Web Service). Push code there and everyone will have the same base to validate if your code works well on anyone's computer.

The reference try script (credit from :Gijs) for `browser/component` is

try: -b od -t none -p win32,win64,macosx64,linux,linux64,linux64-asan -u mochitest-bc,mochitest-e10s-bc,marionette,marionette-e10s

You can manipulate the script based on what you need to test.

Weekly workflow

Because build takes more time, I usually do the following command only twice a week if necessary.

We need update gecko repository regularly:

$ git remote update

Checkout a new bug and then rebuild the stack

$ ./mach build

The command will compile the whole gecko.

 Do at every Setup

You may check MDN as a start point, with Developer Guide https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide and especially the source code page
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code

I will do the setup flow everytime I got a new laptop.

1. Update git

Use the PPA from the maintainers of git on Ubuntu:
$ sudo apt-add-repository ppa:git-core/ppa
$ sudo apt-get update
$ sudo apt-get install git 
 2. Install git-cinnarbar

gecko itself managed via mercurial, we need install git-cinnarbar to help us deal with mercurial codebase via git.
Check http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install-git.html#mozreview-install-git 

$ sudo apt-get install mercurial
$ git clone https://github.com/glandium/git-cinnabar.git
 Then set git-cinnabar into system PATH

$ gedit ~/.bashrc

export PATH=$PATH:absolute_path_to/git-cinnabar

$ . ~/.bashrc
Then follow Mozilla: A git workflow for Gecko development to checkout gecko via git.

Make sure you follow the firefox build guide https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build to setup firefox build environment.

You can install style check related libraries via following command:

$ ./mach eslint --setup

You may want install mozreview which is improve the overall experience of review with Bugzilla http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install.html
$ ./mach mercurial-setup
Will clone version-control-tools into `~/.mozbuild/version-control-tools`. We need update system PATH
$ gedit ~/.bashrc
export PATH=$PATH:absolute_path_to/git-cinnabar:/path/to/.mozbuild/version-control-tools/git/commands 
$ . ~/.bashrc
$ git config --global bz.username someone@example.com
$ git config --global bz.apikey as3r123hj325hjld3
$ git config --global mozreview.nickname mynick
$ git mozreview configure
Then, run bootstrap script to install required build environment

$ ./mach bootstrap
 
Then, the most time saving advice: setup mozconfig for artifact builds if possible. 
When you only work for front-end related work (non c++), Artifact build will download compiled platform code to save you lots of build time.
Do One time
 
Become committer
https://www.mozilla.org/en-US/about/governance/policies/commit/
 
Create Bugzilla API key
https://bugzilla.mozilla.org/userprefs.cgi?tab=apikey
Manage ssh
https://login.mozilla.com/ssh_keys_index

十二月 15, 2014
» 移民效應,是自幹一套還是拿別人的 Open Source 來用?

Marissa Mayer 與起死回生的雅虎 一文中,可以看到雅虎工程師對自家 CEO 的讚美。其中一點提到雅虎內部有很多系統設計是與外界完全不一樣的,直到新 CEO 上任才放下使用多年的YUI而擁抱其他Open Source團隊維護的專案。

從樂觀的角度看:因為當初Yahoo工程師夠強(Douglas Crockford),覺得自己做的東西比別家的好,所以乾脆自己做。有這種「愛自幹」的精神,所以才會做出很多跟其他地方不一樣的東西,這是feature。從反面看則是因為長期跟人家用的工具不一樣,所以沒辦法直接使用別人做的Open source工具,這也是bug。

以前的Yahoo「不擁抱其他Open Source團隊維護的專案」嗎?Yahoo當然某種程度是支持Open Source的公司。就我所知,Yahoo是間很早開始支援 Hadoop 開源專案的公司。Yahoo使用 Hadoop,也延攬 Hadoop 開發者進公司,所以「不擁抱其他Open Source團隊維護的專案」這個論點也許是存在的。

我們來看看 Google。類似於 YUI,Google 自己也有一套 Closure Library,多數 Google 的產品都建構於其上,雖然開源,但外面專案會使用它的也少之又少。
而 Android 呢,AOSP專案裡也有不少只能在 Android 工具鏈中使用的工具,但從以前基於 Eclipse 的 Android 開發工具到最近釋出的Android Studio 1.0是基於 IntelliJ 的開發工具,部分的Google似乎較接受擁抱其他Open Source團隊維護的專案。


在寫下這兩段話的同時,我比較這兩家公司擁抱其他Open Source團隊維護的專案的原因,竟發現兩者改變的相同點在於「併購」。當Google併購Android,就接受了Android團隊與他們提出的開發工具。當Yahoo開始大採購,許多新創團隊進入Yahoo大家庭的同時,也帶進各團隊使用的「其他Open Source團隊維護的專案」。也就是說,當新移民團隊進入這個團體時,帶來了改變。

比起大公司而言,新移民團隊在被併購前的資源有限,使用其他Open Source團隊維護的專案是很自然的事。團隊被併購後若需使用併購方的技術重新打造產品,將是相當痛苦的事情。因此在Yahoo大採購後許多原有規矩被改寫,恐怕背後也有這些新團隊帶來的影響。

用社會學可能可以解釋為什麼是團隊而不是個人?因為改變一直是困難的事。原有的團隊在過去磨合/開發的過程中已經凝聚出了一些共識。移民到新團體的過程中,新移民團隊需要參與和適應團體的一些運作方式,而團體則需接納和適應新移民團隊的一些習俗。


回來想想 Mozilla 也做了很多 Open Source 專案,但整套工具常常僅供自己相關的專案使用。
從自身找原因,自家工具的開源專案原本就是為了滿足自己的需求。當外部出現對這套工具的需求時,由於公司人力資源調配,優先要滿足的還是自身專案時程的需求。
當用到的Open Source專案在公司裡就有人可以諮詢,當然比去找其他Open Source團隊維護的專案來地可靠(?)。許多專案在這樣的思維下就使用自己寫的工具,當意識到的那天,已經回不去了。

若想避免現在的feature變成未來的bug,在決定自幹專案工具前,先想一想(或search一下),也許結果會不一樣。


三月 19, 2014
» FoxBox and SummerOfCode14

FoxBox is the project that intent to provide a battery included Firefox OS build environment.


The goal of foxbox is to try any approach that make new user can do as less as possible to start the FirefoxOS development

Our first take is use vagrant with virtualbox to make major platform users can try FirefoxOS dev in VM.


It will be great to setup the current version of foxbox in your desktop environment
http://github.com/gasolin/foxbox

And record obstacles you encountered here https://github.com/gasolin/foxbox/issues?state=open.
There are some issues (but not the limit) that might be worth to do in the future version of foxbox.


Note that you require a desktop with INTEL VT-x/AMD-V hardware virtualization support(Windows8 or Mac already enabled it), at least 4GB RAM and about 10~40GB disk space(for gaia or full B2G development).


FoxBox has been approved by the Google Summer of Code administrator http://wiki.mozilla.org/Community:SummerOfCode14 , so its perfect time to step up, try FoxBox, fix issues that every others will encounter, save everybody's time and start make your own Firefox OS phone.

If you'd like to contribute FoxBox for SummerOfCode14. We expect you could find out the interesting topic you want to contribute or any other way that can better achieve FoxBox's goal.
 

一月 13, 2014
» template.js

From Template library from Messages app now available in shared/js

Rick Waldron post the new template.js library that works originally for gaia/cummunication apps. Now it's widely adopted for other apps such as settings.

The template.js library is pretty small and stable for general use. just copy it and put in your library to use it.

The syntax is no magic, just inject an single id tag into main html file. And the 'template' is just the commented code. It allows general parameters replacement and prevent innerHTML pollution.

Here's the post from Rick:


Using the Template library is simple:

1. Add <script src="shared/js/template.js"></script> to your index.html

2. Create your template as a comment node inside of any type of element,
place in index.html:

  <span id="emphasis-template">
  <!-- <${tag}>${value}</${tag}> -->
  </span>

  <span id="greeting-template">
  <!-- Hello ${name}! -->
  </span>

3. In your JavaScript code, initialize an instance of this template:

  // Template will accept either an id string or a node!
  var emphasis = new Template('emphasis-template');
  var greeting = new Template(document.getElementById('greeting-template'));


4. Generate a safe markup string with specified values by calling the `interpolate` method of the template object:

  greeting.interpolate({
    name: 'World'
  });

  // Hello World!

Simple partial nesting is supported, just tell `interpolate` which properties are "safe":

  var name = emphasis.interpolate({
    tag: 'b',
    value: 'World'
  });

  // we know that the value of 'name' has already been escaped :)
  greeting.interpolate({ name: name }, { safe: ['name'] });

  // Hello <b>World</b>!


Markup strings produced by Template are innerHTML safe (unless explicitly
marked otherwise, as shown above):

  greeting.interpolate({
    name: '<script>alert("hi!")' + '</script>'
  });

  // &lt;script&gt;alert(&quot;hi!&quot;)&lt;/script&gt;


Template instances disallow modification of the template string once the
object is initialized, but the toString() method will return the raw
template as a string:

  greeting.toString();

  // Hello ${name}!

  emphasis.toString();

  // <${tag}>${value}</${tag}>



It's important to remember that Template and WebComponent are not at odds
with each other and exist to serve to different purposes; read more here:
https://bugzilla.mozilla.org/show_bug.cgi?id=908950#c6

九月 30, 2013
» 開放徽章(OpenBadges)的遊戲化經驗

 第一個中文世界的開放徽章

「徽章」讓原本難以量化的能力,透過徽章的形式具現化。

我一直很留意遊戲化(Gamification)的應用。當越來多多事情變得可以測量之後,很自然的會想在生活中引入遊戲機制,以提高活動的參與度或樂趣。

最常見的遊戲化(Gamification)應用是 PBS(Point, Badge, Scoreboard)- 積分、徽章、排行榜。這些遊戲化元素在許多遊戲和社交網站中都會出現,如 KhanAcademyCodeAcademy 等近年湧現的線上學習網站。在站內學習時,每完成一道題目,就可以取得一定的分數;完成了一個學習單元?恭喜!你獲得了一個線上的徽章,可以把聯結展示給你的朋友或潛在僱主看。

但目前的遊戲化(Gamification)應用有個問題:我已在這平台/遊戲上投入了那麼多時間、精力,(可能還有金錢),一旦不用這平台/遊戲之後,那些我的豐功偉業都不見了。於是使用者/玩家會傾向停留在剛開始選擇的平台中,並減少嘗試其他家服務的意願。於是「Lock in」、大者恆大的現象就出現了。

也因此 Apple、Google 都仿效 XBox 推出自己的 Game Center,提供積分、徽章(成就)、玩家配對等功能,讓在同一個平台上的玩家更方便嘗試不同遊戲,並且保留遊戲的進度,期望能綁住使用者/玩家。

這個現象對遊戲或作業系統平台商而言也許是好事,但是如果把目標改成線上學習網站的話...我是希望可以在更專門的網站學習不同的技能啦。
而且最好是不管線上或學習實際課程後,我都可以得到徽章/證書,這樣我可以把我收集到的成就展示給我的朋友或潛在僱主看。

第一個中文世界的開放徽章


Mozilla 嘗試在推動的 OpenBadges(開放徽章)標準就是一個解決線上/線下,不同網站之間徽章/成就流通,鼓勵使用者多多嘗試的方案。

前幾週在我講授的 COSCUP 課程 上,發出了第一個(?我想應該是吧)中文世界的開放徽章


發放的流程是這樣的:

1. 學員聽完第一個小時課程,並已實際Lab操作一陣子,符合取得徽章的資格
2. 提供學員印出的徽章兌換券,上面的內容如下


徽章兌換券

3. 學員直接使用智慧型手機掃描條碼,或前往 http://badg.us/ 網站輸入兌換碼。
4. 學員登入後可取得徽章

 
http://bit.ly/15rbii1

5. 取得的徽章可以直接分享給他的朋友或潛在僱主看,或導出到 徽章背包 (http://backpack.openbadges.org/) 中備份。所有符合 OpenBadges 標準的徽章都可以備份到 徽章背包 中。學員可以結合其他網站上取得徽章,將這些徽章整理成一個個收藏(Collection),有系統地分享給他的朋友或潛在僱主看。

透過這樣的方式,即使是實體的課程,也可以在線上留下印記!學員除了學到課程知識,也得到了一個可以永久保存的紀念章。

除了讓使用者願意多方嘗試之外,同時也讓一般人擁有發放徽章/證書的能力。從初步的使用經驗來看,開放徽章還有很多的可能性值得探索。

八月 9, 2013
» 貢獻開源專案?從怪獸(Mozilla)與超人蓋亞(Gaia)開始吧



上週在 Coscup 2013 演講的投影片,介紹為何要參與 Open Source專案,基本 Firefox OS架構,和 web 技術人如何運用自己的能力來參與 Gaia 專案開發。


Steps to contribute to firefox os (gaia) 

為這次演講花一個晚上做了一個簡單的 hack demo,在撥打電話時,馬總統會報出正在播的數字。



感謝馬總統跨刀演出。

聲音來自 Open Source 的 Bumbler to speech 專案。

六月 30, 2013
» 幫 Bugzilla 換個新佈景

新的 Bugzilla 樣式

在來 Mozilla 之前我用得比較多的是 RedmineTrac 等問題追蹤系統,到了 Mozilla 之後才比較常接觸 Bugzilla

目前大部份 Mozilla 的開源軟體都使用 Bugzilla 來追蹤 issues。所有開發者間針對 issues 的討論、審查、版本間的同步,各種開發相關的資訊都圍繞著這個系統進行,所以要貢獻 Mozilla 相關軟體開發專案,Bugzilla 是必定造訪的中轉站。

Bugzilla 是貨真價實源自上個世紀的古董網站。Wikipedia 的資料寫著,第一版 Bugzilla 發表於 1998 年,使用 Tcl 語言撰寫。Bugzilla 2.0 則改使用 Perl 語言撰寫。原因是比起 Tcl,當時 Perl 語言更普遍,改成使用 Perl 語言可以吸引更多自願協助改進的開發者。

這麼老牌的開源軟體當然有很多歷史遺留問題,我們先來看目前版本的模樣



一般預設的 Bugzilla 樣式


咳咳...只能說,過去的審美觀跟現在已經不太一樣了。

還好,Bugzilla 的開發者有意識到這個問題,登入帳號後,點選畫面右上角的 preference(設定) ,把 Bugzilla's general appearance (skin) 改成 'Mozilla',選擇 Submit Changes(儲存)後,就可以看到新版界面。


調整設定

新的界面與 Mozilla 官方網站 風格一致,界面新潮許多。

新版界面




對於每天使用的工具,做得更好看一點,真的可以增加使用的樂趣哩。

註:RedmineTrac 剛好都發表於 2006 年,就像 git 與 mercurial 都剛好發表於 2005 年一樣巧。

biggo.com.tw

A Django site.