Re: 如果想要免費實習,就去參加 Open Source 活動吧

揭露:Gasolin 是我同部門的同事,我們在同一個 Project

Gasolin 發表了一篇「如果想免費實習,就去參與 Open Source 活動吧」的文章,結果在某第三地意外引發了檢視邏輯的討論。從文章的起頭,我想這篇文章的發想,是從目前的就業環境來為畢業生就業的 bootstrap 問題提出一個答案。我自己的經驗就不用再度長篇大論了:我在第一份工作前所累積的實力都是在學校工讀的專案與 Open Source 社群專案中累積的,在這之中累積的溝通、合作、工程、規畫實力我還真的想不到哪裡能有同樣強度的機會。

至於這適不適合所有人呢?我也不敢說,至少不敢說的跟 BobChao 或是 Gasolin 那樣肯定。就如人與所有團體的關係一樣,所謂正確的位置或是發揮的空間都是要自己爭取的,也沒有某個型態的組織模式可以跟你保證你一定找的到自己的位置與空間。

談到組織模式,就不免又要提一些 Open Source 專案與活動治理。某個場合才跟另一個強哥 Legist 聊到一個與我原本信念相反的現象:大部分的 Open Source 軟體專案的治理,最終不是落入慈愛的獨裁者(benevolent dictator)的 BDOL 決策模式(例如 Linus Torvalds 之於 Linux Kernel),不然就是由某公司直接掌握方向(例如 Canonical 之於 Ubuntu)。社群最後也常常演化出慈愛的獨裁者。當然人們都會說 Open Source Licensing 直接從法律的層次保障了你「不爽就 fork,開新專案」的權力,但實質上這個權力在大型專案能有效實行的機會渺茫,就跟台灣的公民投票法一樣 XD

岔開了,內文與標題不符 … 總之我想說的是,如果這是 Open Source 活動組織與治理不可避免的走向,在其中的我們要如何確定我們給畢業生的 offering 一定是比起「企業免費實習」還要好的機會(例如,如果參與 Ubuntu 的開發很明確的只是為了某天要拿到 Canonical 的工作,那跟免費實習有什麼不一樣)?前述的確定,能否從組織結構與治理上保障?如果找的到這兩個問題的答案,大家就可以毫不猶豫的認證蓋章 Gasolin 的文章,我們對就業市場的衝擊也是對台灣社會很大的貢獻。

PS. 澄清一下,Canonical 公司與 Ubuntu 專案不必然是前述的樣子,請大家把這兩個字換成 X 公司與 x 專案 … 如有冒犯敬請見諒,畢竟我不能用另一組公司和專案的組合 😛

Opera 改用 WebKit 與 Chromium

如題,本日最大消息,Twitter 與 Blogsphere(如果你還覺得這個「地方」存在的話,笑)都爆炸了,如同當年 Google 宣布 Chrome 時的反應一樣。Twitter 可以看搜尋以及 Mozilla CTO Brendan Eich 的訊息。

在 Mozilla 工作,看到的反應比較多是負面的,像是在擔心 monoculture/diversity,尤其是 Mobile Web 的部份。例如,Mozilla 的 layout 魔術師 roc 在「And Then There Were Three」就說(節譯):

Opera 對 Web 標準的影響會大幅的降低,尤其是當他們和 Apple 與 Google 有不同想法的時候。佈局引擎的多元性又更加降低,尤其是 Mobile Web 的部份 … Mozilla 會更難推廣網路標準,相較於「coding for Webkit」… 網路標準會失去他的重要性,標準制定的過程會被 WebKit 這個開源專案的內部決定與政治取代。WebKit 的程式錯誤會反過來變成標準 … 無法分辨佈局引擎的行為是程式錯誤還是設計。

最近一年倒是多少有跟別人聊到類似的假設:「假如 WebKit 變成 de-facto web standard 會怎樣」這樣的問題,尤其是之前跟 Kenny 大大MozTW Labs 的路口討論。不管是好是壞,我們離那個假設又更近一步了。

台北當然是春節休假。Mountain View 剛開始上班,不知道公司會不會發什麼聲明出來。

CSS Classes State Machine Puzzle

It is quite nature to code CSS classes as “states” in a web applications. Say if you have three <div class="view">s within the <body> tag, you can easily toggle the class of the body to show/hide the views, with one-off CSS animations as view-to-view transitions, right? Wrong.

It turns out, it works with two states even with transition/animation, but not so much if there are three states. For two states like A & B, there is only one possible route to get into each state, A→B for B, and B→A for A. However, if there are three states, A would have routes B→A and C→A, and so on. It’s basically n*(n-1) for n states.

How do you specify two different CSS animations for the two routes? This doesn’t sounds like a common question, but I have personally encountered twice in different projects, and I bet sooner or later this would happen to everyone as we moved from DOM animation to CSS and rely more and more on browser to run the animation smoothly.

One way to look at it would be that this is a design flaw of the CSS language. There should be some pseudo-class like :was() to specify what exact route to match against. However, inventing a pseudo-class just for the animation property doesn’t sound like a great idea.

The other way, and a more practical approach is to look for solution with what we have right now. Inevitably, to distinguish route B→A and route C→A, one should introduce immediate states, making the routes B→A’→A and C→A”→A. Yet, this further complicate things if one would like the scripting part stay as a clean finite-state machine: First, the transition of A’→A will depend on animationend event, which couples the CSS code with Javascript code. Second, and the bummer that makes the solution incomplete, is that the animationend event will never fire if the state changes again during the A’ or A” state, which make it necessary to handling the changing in Javascript code again ourselves. Good luck on codify all the A’→B, A”→C, A’→C, … transitions.

Now you know how hard it is to write a mobile OS window manager with Javascript + CSS. There might be some obvious answers I overlooked, if you would like to give your solutions, feel free to comment here or post it on your own blog.