[Hack] Kaku – music player for next generation

kaku_radius

每年都要花點時間做自己的 Open Source Project,而今年意外的有一個很好的題目可以來發揮 xDDD,所以就利用一些下班的時間把 Kaku 的整個雛型打造出來了!Kaku 是一個音樂播放器可以讓你自由地聽各個網路平台上面的音樂(目前支援的平台有 YouTube、Vimeo 還有 SoundCloud),算是一個各平台整台的小作品。

(先點連結看看再說:http://kaku.rocks

而在開發這個程式的時候也發生許多有趣的問題,所以想把我還記得的部分寫下來做個記錄 xD。

Node Webkit(NW.js) 起手式

因為我一開始的目標就是希望這個程式是各個作業系統的使用者都可以使用的,因此桌上型應用程式勢必是我的首選,又因為在實際寫 Kaku 之前,我有幫 Atraci 寫過一些相關的程式碼,所以對於如何操作 Node Webkit 提供的 API 有一點點研究,所以就選用 Node Webkit 當作我開發的基底。(我只是前端工程師阿阿阿)

說到 Node Webkit,他有個有趣的設計就是他提供不同的 JavaScript Context,因此你的應用程式雖然是用前端的技術打造的,但是因為可以跨用到 Node Context,所以就可以混用許多現有的 npm module 當做後端來處理資料,所以在我的設計下,在這個程式裡面就有這兩類不同的資料夾,讓程式可以很明確的切分他們的職責。

搞定開發環境

因為有過幾次合作開發 Open Source Project 的經驗,所以如果你要讓你的專案吸引其他開發者的注意力的話,那你一定要把開發環境搞定或是簡化到一個指令複製貼上就可以跑起來,要不然光是一開始就讓別人有很強烈的挫折感,那你的專案也不用期望會有多少人來幫忙開發了 xDD。

又因為 Kaku 是我想要來嘗試練習 React 的一個專案,裡面用到很多 jsx 的語法所以需要 precompile 的動作,而且又因為要把整個程式包裝成 Node Webkit 的應用程式,也需要另外做 build 的動作,因此我就用 gulp 當做我 building tool 的基底來把這些操作都包裝起來,讓開發者只要按一兩個 gulp 指令就可以了!

現在想想,一開始就把這件事情做好所帶來的效益真的很高,也真的有一些人上了一些 patch !

開心寫程式…嗎?

以前在 Mozilla 的時候,我們 app 的程式是架構在 require.js 之上以 AMD 的模式開發,所以時間久了我也漸漸的習慣了這種寫程式的方式,所以一開始的 Kaku 也是以這種方式寫的(對,之後被我全砍了)。但是時間久了我發現我漸漸的被他的東西綁住,整個 repo 開始要加入他專屬的設定檔去設定東西,最慘的就是寫測試的時候還要特別去設定一些東西才可以讓 AMD 的程式碼順利的跑在 require.js 上面。然後我記得最麻煩的是前端用的 require.js 和後端用的 require.js 無法混用,我還要特別抓一份存在 node_module (WTF),然後它對於 ES6 的支援度不知道為什麼有很多問題,所以到後面有很多東西不是沒有測試,而是我不知道要怎麼讓他成功的跑在測試環境上面所以才沒有寫,囧!

這些其實不是壓倒我的最後一根稻草,壓倒我的是 3rd-party library 對 AMD 的支援有一些問題,不知道是那些作者在寫 UMD 寫太爛還是怎樣,有時候那些判斷的順序寫錯就無法用,囧!!所以那個時候為了讓很多 3rd-party library 可以使用,還特別 fork 並改了好多個專案,雖然大多都是 quickfix 不過也是很麻煩呀!

之後,因為強者我前同事 @rickychien (Mozilla 已經變前公司了你不知道嗎 xDDD) 在這段期間內一直和我在討論引入 webpack 的事情,所以就在某兩天想說長痛不如短痛,一次改了一百多個檔案把之前 AMD 的東西全部拿掉然後把測試還有開發環境一次全部用壞之後,就成功的把程式碼全部轉過去了 xDDD(完全錯誤示範,請不要學!!)

這邊真的要慶幸之前是用 AMD 的模式寫程式,才可以把各個模組切的這麼乾淨,然後通通改用 Common js 的方式載入,然後透過 webpack 來做打包的動作,整個世界美好!

Test + CI + Documentations +++

雖然是 Open Source Project,還是要用高規格來寫程式,該有的 CI、測試、文件都沒有少(有很多還沒寫完就是了…),這些東西真的都是在你要改程式的時候才特別有感!還記得以前不知道在哪個文章上看到幾句話關於工程師最討厭做的事情(以下為大概):

  1. 寫文件
  2. 寫註解
  3. 寫測試
  4. 別人不寫文件
  5. 別人不寫註解
  6. 別人不寫測試

為了不要變成那個讓別人討厭的人,所以只好默默的把這些東西都補齊了 xDD,這些真的很重要呀!

從 NW.js 到 Electron

其實說實在的原本 NodeWebkit(NW.js) 用的好好的,只是想要嘗試一下 Github 特製的 Electron ,所以就一口氣換過去了 xDDD ,說真的之所以會想要轉換過去是覬覦他自動更新的功能,能夠讓應用程式自動更新真的很棒呀,不過研究後才發現他原生只有支援 Mac OS ,Windows 的則是要另外把他包進來,而 Linux 就什麼都沒有了 xDD,而且最麻煩的是要有提供一個 endpoint 讓他去存取得知最新版本,然後當使用者需要更新的時候才會再去相對應的載點下載。

其實想一想整個流程也是很合理啦,不過因為我不想要有伺服器來存這些東西,維護也有成本,所以我的東西都是放在 GitHub Releases 裡,因此就自己利用 GitHub API 自己簡單實做一個各平台都可以用的自動更新程式放在 Kaku 裡,讓他每次被啟動後會去判斷是否需要更新,如果使用者確認要更新後,會再把使用者導到下載程式的地方,完成半自動更新的流程(使用者唯一要多做一步的就是要自己解壓縮檔案然後覆蓋舊的程式這樣)。

說實在的 Electron 本身並沒有帶來太大的好處,一來是整合相關的 gulp 工具不多,二來是因為他的 global shortcut 的設計和 nw.js 的不一樣,需要多處理程式得到 focus 還有失去 focus 的事情(雖然也是好事啦),三來是我的程式沒有複雜到要用到很多特殊功能,所以花了很多不必要的時間 xD。不過用了就用了,有 GitHub 帶著社群開發也可以讓 Electron 更長久,持續觀注!

善用工具、改善工具

Kaku 有使用了很多社群開發的工具,盡量把主要的時間留在開發主要的商業邏輯,或是整合這些工具讓自己可以用得更順手。也因為這樣子,中間發現了一些工具的問題,這個時候要做的第一件事情就是先找找看有沒有其他更好的工具,如果沒有的話,我就會試著去 fork 那個專案然後修有問題的地方,最後再上 PR 給原作者。先不論那個 PR 會不會被接受,但至少在這個過程中,我也試著推動了輪子,試著讓這些東西變得更好,省下別人的時間。如果最後沒被 merge,笑笑也就過了是吧?

行銷!

通常程式設計師都不太會注重這一塊,但是我覺得對於 Open Source Project 來說,這一塊相當重要。這邊想講的不是說要砸多少錢買廣告幹嘛的(拜託,這是 Open Source Project 耶),而是要有一個基本的門面,至少簡單做個網頁加點程式相關的圖片嘛!不得不說在這個資訊暴炸時代,如果資訊本身不夠吸引別人,即使你改變了這個世界幾百次,也不會有任何人注意到的。

沒有人注意到這個專案,就不會有人使用你的程式,就不會有開發者加入和你開發新東西,你就會開始覺得這些東西做了不知道要幹嘛只能自 High,久了也就失去動力繼續下去了。不過至少,你可以去一些開發者論壇以技術的角度切入並和大家分享你做了這些東西,除了彼此技術的成長之外,無形當中也是一種行銷不是嗎?

所以,我就請設計師朋友幫我做了 Logo,也自己簡單的做了一個網頁展示這個程式,雖然沒有多專業但也比什麼都沒有好多了!再適時加上一點點 Social buttons ,如果有人想要分享的話自然就會分享,這樣也就夠啦!

最後最後最後

如果你沒用過 Kaku 的話,請立馬去官網下載,有什麼意見或想法都很歡迎留言給我,敬請期待下一篇文章 😛