Fred's blog

Maker 一詞近年來翻紅，有人稱「自造者」，有人稱「創客」，以代工起家的國內產業，覺得 Maker 風潮是一個維持舊有工業地位的方法和機會，更將其引伸成軟硬整合、創業模式，無一不紛紛出來插手，想佔一塊地，分一杯羹。有些媒體將 Maker 塑造成有專業技術能力的人們，彷彿與一般人有很大的鴻溝。種種因素，自然越來越多人不了解 Maker 是什麼了。 但我們認為真正的 Maker 並不是擁有厲害能力的人，而是願意動手落實的人。 為什麼我們要成立 MakerCup？ 我們想聚集純粹想動手、交流的朋友，並讓更多人參與並體驗 Maker 的世界。 事實上，Maker 的定義很簡單，凡是能打造、做東西的人，都能稱為 Maker。做菜的廚師，是個 Maker；編織衣服的人，是個 Maker；畫家，也是個 Maker。當然，寫軟體、做電子電路的人，以及各種設計師，通通都算是 Maker。無論在什麼領域，Maker 精神強調的是動手去實現、完成，去參與過程、瞭解過程，進而讓自己更有能力去打造出更多創意十足的東西。更重要的是，在這種不設限的旅程，能讓我們都具備著跨領域思考的能力。 既然過程才是最重要的，我們便開始思考怎麼樣讓更多人交流，交流技術、能力，共同發展和探討更多的知識。我們不應該只是追求一時且短暫的成果，滿足政府或代工產業想要立即成果的 KPI，更或是不應該鑽牛角尖盲目追求頂尖技能，而是讓更多人參與、動手，普遍瞭解更多不同的事物和技能。 於是， MakerCup 這個社群出現了，每週四都會舉辦一場分享交流活動或是小聚會，讓 Maker 平日下班或閒暇時，可以來走走坐坐，輕鬆喝點小飲料，或是現場做點東西： https://www.facebook.com/groups/MakerCup/ 我們希望，這個社群將如一碗太古時代的生命濃湯一般，熬煮出真正的 Maker 生命。 延續黑客松台灣的精神 還記得這一年，我們籌辦了整個年度的「 黑客松台灣（Hackathon Taiwan） 」，每個月都有 300 至 500 人的大型創作活動，讓不敢踏出來的年輕學子、上班感到無聊的人、及很少離開自己專業領域的朋友，走出來到活動上以「能力會友」。這一年的過程，讓大家的成果，從簡陋成長到真正的創意或產品，從簡單的技術到複雜的應用，從小設計到跨領域的整合。 ...

話說，Isomorphic 一直是 Node.js 開發者的夢想，期望同一套程式碼前後端都可以使用，大幅簡化程式碼和加速開發。此外，動態網頁的 SEO 問題也可以同時獲得解決，許多效能問題也可以得到改善。但是，要實現 Isomorphic 的架構，有很多的問題得先解決，會花大量時間在前期工作上，往往讓許多開發者頭痛。 儘管頭痛，仍然阻止不了大家往 Isomorphic 的世界前進，我也因此建立了一個專案「 Lantern 」，希望能讓更多人能以 Isomorphic 架構，快速建構出自己的網站服務，省去許多前期工作的時間。該專案是一個網站服務的樣板，實作了會員系統、權限管理、第三方登入、多國語系和送信機制等功能，在使用者介面上也做了一個還算美觀的介面。基本上，開發者只要 clone 下來，然後修改設定檔或改改介面、增加點功能，就可以快速完成一個屬於自己的全新網站服務。 最特別的是，「 Lantern 」整合了現今所有最新的技術和概念，包括了 Koa、React、FLUX、ES6/7+、Webpack 以及 Semantic UI，大量運用了 Generator、class 及 decorator 等最新 JavaScript 語言特性來簡化設計。所以，如果你想要接觸最新的技術，完全可以透過修改「 Lantern 」專案來學習和熟悉。 目前「 Lantern 」支援 Facebook 剛發佈的最新 React v0.14+ 和 react-router 1.0.0+，也避免使用像 redux 這類反 FLUX 原始設計的框架，讓原本熟悉 React 和 FLUX 架構的開發者，可以快速上手。也提供一些常見的 Extension，方便開發者寫出前後端通用的程式碼，大多數情況下，開發者不需思考程式碼運行在前端還是後端。 快速安裝使用 若想要使用「Lantern」，方式很簡單，先從 Github 取得程式碼： git clone git@github.com:cfsghost/lantern.git 安裝必要之 NPM 模組： npm install 使用 webpack 編譯專案（若要正式上線，可加上 -p 選項來編譯）： webpack 運行網站服務： node app.js 最後可以使用瀏覽器開啟網址，確認是否成功： http://...

搭配使用 Git 進行開發工作，時常會碰到一個狀況，就是我們 fork 一個專案出來修改，但在我們在修改的同時上游有了更新，這時我們會想要把上游的更新同步下來。這是一個常見的問題，許多人不時會提出來詢問，事實上如果你去 Google ，多半能找到這樣一篇名為「 Syncing a fork 」的 Github 文件。雖然這篇文章已經把程序詳細列出來了，但還是有人看不太懂，原因是要搭配「 Configuring a remote for a fork 」這一篇文件一起看才知道來龍去脈。 簡單來說，我們要先把「上游（upstream）」的 repository 加入我們眼前正在修改的專案，然後把上游更新拉回來，最後再與我們現有程式碼合併。 首先，加入上游的 repository 並命名為「upstream」： git remote add upstream https://github.com/YOUR_USERNAME/YOUR_FORK.git 未來想要更新前，可以使用 fetch 去拉上游的更新回來： git fetch upstream 最後再把 upstream 的內容，與現有的正在修改的進行「合併」： git merge upstream/master

要講到 Fluky 這一個 Flux 框架，這要從我的一個新計畫說起。因為最近又重新興起了一波 Isomorphic App 的熱潮，許多人開始打造了自己的 Isomorphic 網站，自己也做了一個。而什麼是 Isomorphic 呢？簡單來說，就是寫一次程式，然後前後端都可以使用的機制，也是一個網站服務工程師的夢想。還記得過去自己曾實作了 frex.js 試圖達成 API 層面的 Isomorphic，現在 React 這樣的前端框架，更提供了一個打造前後端 Rendering 的 Isomorphic，使得原本在前端動態產生的畫面，可以在後端產生，更一舉解決了 SEO 的問題。 話說，搭上了這波熱潮，最近開始土炮自己的 Isomorphic App，Github 上開啟了一個「 Lantern 燈籠 」專案，希望做一個標準的專案架構，讓自己以後開發新專案時，可以不需要重新再來一遍。痛苦的是，與很多人一樣，踩到了很多地雷，在專案架構設計上，也一直有很多許要調整的地方，這也難怪，畢竟這是一個興新的開發概念。 於是從零到有的過程中，也有許多副產品，其中包括了一個新的 Flux 框架「Fluky」。很多人問我為什麼不採用當今紅遍半天邊的「redux」，原因其實很簡單，我不想脫離傳統 Flux 模式和 React 開發的概念太遠，然後同時想要用試著更精簡的方式描述這些流程。另外一點是，受到過去 X11 這世界最先進的網路圖形化視窗系統的設計所啟發，打算試著全面使用「事件」來管理資料流和程式上任何的溝通。 如果你有興趣，可以直接以 NPM 來安裝這個 Flux 框架： npm install fluky Fluky 的設計 基本上， Fluky 本身的概念很簡單，幾乎所有的行為都是透過 Fluky.dispatch() 這個 API 來進行，包括呼叫 Action、Store，然後所有的行為都可以使用 Fluky.on() 所監聽。也就是說，只需要這兩個 API，幾乎就已經足夠。對於 View 的工作而言，永遠就是呼叫 Fluky.dispatch('action.*') 和監聽 Fluky.on('store.*') 。 這樣設計有什麼好處呢？因為所有的訊息和命令傳遞，都有統一的事件機制和命名規則，理論上來說，事件...

這是個總有人一問再問的問題，到底 Node.js 這樣單執行緒（Single Thread）的設計，到底有什麼優點？為什麼總是有人說，它比傳統多執行緒的設計來得有效率？以往，一旦開始討論這個問題，總是會有人開始提到 Context Switch、Asynchronous 等機制，越講越玄也越講越複雜化。 其實我們可以用簡單的餐廳比喻，就能理解 Single Thread 加上事件驅動（Event-driven）的機制，如何與傳統設計不一樣。 場景想像 試想一個場景：一間餐廳有 100 個座位，然後來了100個客人。 處理方法 身為老闆的你，你會選擇哪種方式服務這些客人： 請100個服務生一對一服務這些客人。 請 25 個服務生，看當下狀況服務這些客人。 一般來說，傳統的多 Multi-thread 的設計就類似方法 1，而 Single-thread 且 Event-driven 的設計就是方法 2。 通常大多數情況我們會選擇方法 2，因為客人通常都是處於等待（看菜單、等上菜、吃自己）的情況，並不需要服務生貼身服務。所以即便請 100 個服務生，這些服務生大多數時間也只是等在那也佔地方，而服務生眾多也導致服務生之間的溝通和互動其實不易，更不容易交換資源，回報和協同工作難以進行。反而安排一個小型的外場班，讓裡面的人合作見機行事，會比派出 100 個各自獨立的人來得好。 併發數高的原因 併發數（concurrent request）指的是單位時間內可以處理的要求量，一般用來評估一個網路應用程式的效能。而通常在網路服務裡，併發數也相當於單一時間內能服務的連線數量。 所以，以前面餐廳外場班的模型來說，如果你有 100 個服務生，就可以服務 400 個客人。換句話說，同樣的資源，能處理的併發數（concurrent requests）也就比較高。 後記 不過如果你開的是酒店或按摩店，那可能就要請一百位服務生了。:-)

因為我對外都自稱一個 Geek，所以時常有人問我，Geek 是什麼？一直以來，「技客（Geek）」個名詞讓許多人感到陌生，甚至對這詞彙一知半解的人，都以為 Geek 與普通宅宅無異，更甚至是覺得這只是另一種宅宅的說法。的確，Geek 某些地方與普通宅宅很相近，指的是醉心於特定專業或領域的人，但這些人擁有絕佳才能，只是為了鑽研知識或研究新事物可以幾乎荒廢其他事，廢寢忘食對他們來說只是小意思，甚至可以犧牲人際關係等一般正常社會交際行為。由此可以看出 Geek 對於自有興趣的事物，將會多努力去鑽研。 不可否認，「技客（Geek）」這個詞在早期帶有貶意，但在現今社會中，人們交流的手段和方法已經透過科技有很大的改變，Geek 可以透過網路或各種新方法，找到能分享交流的同好朋友。透過網路串連，他們不再只是群體中被傳統主流排除在外的人，反而搖身一變，變成強力促使世界進步的主要群體。如今，大家眼中的 Geek ，代表著才能與努力，更代表能「動手完成任務」的傑出人們。開玩笑的說，專心致志（宅宅）加上真正動手實做的能力，就是「技客（Geek）」。 想要成為一個 Geek 嗎？只要你符合這樣的條件，無論你原本是個技術 Hacker、Maker 還是個設計師，更甚至是任何領域的人，都可以稱自己是一個 Geek，甚至可以以此為榮！也許，你也有自己沒發現，但是能堪稱 Geek 的一面也說不定！ 後記 為了讓更多 Geek 能聚集在一起交流，共同迸出創新的火花，我們 Hackathon Taiwan 開始了一個新計畫 GeekBar I/O，將嘗試透過各種活動和方式，讓 Geek 們共同發光發熱！歡迎大家共襄盛舉！

自從 Node.js 0.12 版和 io.js 之後，大量的開發者開始了各自的 ECMAScript 6 大冒險，許多人對 Generator 的使用仍跌跌撞撞，對於這種看似「同步（Synchronous）」的「異步（Asynchronous）」機制，有許多人腦袋遲遲無法轉過來。雖然在小弟的書（參閱連結： 新書報到！Node.js 模組參考手冊！ ）已經有清楚的說明 Generator 使用方法，但就許多讀者回函來看，對於 JavaScript 越是熟悉的人，越無法直觀理解 Generator 的思維，甚至是老是抓不准使用的時機點。 尤其是過去我們已經有 Promise、async、Q 和 bluebird 等處理非同步程式流程的模組和工具，很多人就是覺得沒有使用 Generator 的必要。不過，如果你會使用 co 模組，你會突然發現若是將過去的流程機制與 Generator 相搭配，程式開發將變得更為流暢。 若想要安裝 co 模組，可以直接以 NPM 下載： npm install co 本文接下來會說明一些 co 的基本使用，破除一些 Generator 難以使用的地方，讓開發者們更容易開始 Generator 的旅程。 讓原生 Generator 更好用 這是很多人不喜歡使用 Generator 的主因，以往為了使用 Generator，我們還要先建立一個 Generator 的函數，然後不時的去處理 Generator 所返回的資訊，一遍又一遍進入 Generator 之中。因此，無論 Generator 再好用，這些麻煩的動作也完全抵銷他的優勢，大多數人還不如回到舊的流程控制方法，以免徒增自己的麻煩。 而如果使用 co，可以直接將 Generator 函數當作「立即函數使用」，其餘的部份我們可以不需要擔心： var co = require('co'); co(function *() {     console.log('Inside'); }) 再也不用煩惱 yield！ 以前光是 Promise，就已經讓很多人詬病，覺得每次使用 Promise 都要花許多時間對函數進行包裝，而 Generator 也有類似的問題，若是要使用 yield，更是一件大工程。於是，co ...

 『是不是要很厲害才能參加黑客松呢？』這是一個永遠都會有人問的問題。 事實上，黑客松從一開始的出發點，就是三五好友聚在一起進行研究及開發的活動，帶有很純粹的動機。參加這樣的活動，你不必真的很厲害到極點，而最重要的是動手和夥伴合作，過程中可以順便認識朋友與他人交流，讓投入的過程中更加豐富有趣。 從這樣的角度來看，『黑客松式的學習』是不是有可能的呢？如今看來是肯定的，5/23 於台北剛結束的 NodeSchool 聚會就是一場黑客松式學習活動，吸引了近兩百位參加者，共同參與了這場具有黑客精神的學習活動！ 順帶一提，這此使用的場地，也是 黑客松台灣（Hackathon Taiwan） 每個月辦活動的主場地，無論如何，也記得來報名下次 6/13 - 6/14 （六、日）的黑客松活動！ 什麼是 NodeSchool？ NodeSchool 是一個線上學校，目標是運用線上工作坊課程，讓所有人都可以在這學到各種技術。而恰逢 NodeSchool International Day 國際日活動，全球各地都紛紛各自舉行一場 NodeSchool 盛會，因此身在台灣的我們也理所當然響應了這樣的活動。  這個活動的形式相當特別，沒有講師在台上講課，而是採用線上工作坊教材與題目的形式，讓參加者在自己的電腦上挑戰通關。NodeScool 擁有許多工作坊教材，從基礎課程到進階的選修課程都有，除了 JavaScript、Node.js 之外，也有 ES6、WebGL、Three.js、Functional Programing 和 React.js 等課程。詳細的課程資訊，可以參考 NodeSchool 官方網站 。 由於每一份教材都是經過設計，而且每一個主題和關卡都擁有提示和說明，參加者在一題題解答的過程中，可以靠自己慢慢學會一門技術。如果真的遭遇到了自己難以突破的困難，可以跟左右鄰居討論研究，若真的也沒有辦法了，可以找在現場自願的指導員（Mentor）幫忙排解問題。 黑客松式的學習活動 回想起過去從小到大，我們的學習模式，總是有個老師在台上教學，枯燥而乏味，而為了保證教學進度，不免伴隨著填鴨式的教學方法。這樣的模式我們早就習慣，雖不見得喜歡，但也無可奈何，逐漸的，我們的思考和學習，慢慢僵化了。 具有一定寫程式經驗的人都知道，...

這次五月的 Hackathon Taiwan ， 因為原本的講師沒空，所以我就來救援了一場 QML 工作坊，這堂課以活動的倒數計時器為開頭，討論怎麼使用 QML 進行超酷炫科幻 UI 的設計，是一堂初學入門課程。 有鑑於過去聽到不少人反應，要使用 QML 必須與 C/C++ 打交道，門檻相當高，於是，這個工作坊的目標，就是讓學員可以在純 QML 的環境下，以 QML 來開發自己的 UI 界面。即便是不熟悉程式語言的人，都可以輕易使用 QML 做出絢麗的 UI。 活動簡報 後記 這次 QML 工作坊事後反應還算不錯，甚至有人以 QML 來開發黑客松活動的作品，未來如果有機會可以再次開課。:-)

 在 Facebook 看到很多人都在整理自己的程式筆記，我也整理關於 JavaScript 語言常被誤解部份的筆記，然後分享出來供各位同好參考。 講實話，從 1995 年開始的 JavaScript，直到前幾年，都讓我恨的牙癢癢，甚至覺得他是個垃圾，因為當時的他太沒有規範，效能極差。直到近年來才逐步改善，我也才慢慢擺脫對他的排斥及恨意。 但就算已經有標準規範，JavaScript 語言對很多人來說依然很頭痛，除了其 Asynchronous 非同步的機制外，更要面對其極為動態（Dynamic）的特性，而從 OOP 的角度來看，其 classless 的設計更讓人不知所措（ES6 之後開始支援 Class），與傳統的 OOP 相去甚遠。所以，JavaScript 處處與其他語言完全不一樣的概念及思維，讓很多人在裡面處處誤解。 所以若是想學習 JavaScript 深入的概念，最好的方式就是放下其他語言的既有概念，直接了解 JavaScript 的核心機制，雖然會讓人手足無措，但卻是最好的手段。否則，很容易練就或死背很多怪招，寫出難以除錯或過於複雜的程式碼，當然，更嚴重的是誤導他人。 要深入或精通 JavaScript，務必了解並思考其執行程式時發生什麼事，每一行程式碼當下被執行時的狀態，遠遠比程式碼排列來得重要。只要掌握每一行程式碼的『執 行當下』，所有 JavaScript 的疑難雜症，都能迎刃而解。關於這一點，有興趣閱讀硬梆梆定義文件的，可以參考 ECMA-626 的『10.3 Execution Contexts』一節。（參考網址： http://www.ecma-international.org/ecma-262/5.1/#sec-10.3 ） 關於 this 關鍵字的機制 很多人會搞糊塗 this 關鍵字，就因為他是一個會被 Execution Contexts 大量影響的東西。JavaScript 在 Function 或 Context 被執行時，才會依當下情況去決定 this 為何。這代表，使用 this 時在哪一個 function 或地方不重要，而是當進入這個使用 this 的 context 時（如：Function 被執行時）才會決定 this 是什麼，this 是什麼只跟你如...

經過幾個月努力，新書『 Node.js 模組參考手冊 』終於誕生。這本新書與前一本『不一樣的 Node.js』稍稍不同，主要訴求不是初學者入門，而是參考用書，無論是新手還是已經很熟練 Node.js 的專家好手，都可以拿來參考，還希望各界多多支持！ 有鑑於 Node.js 發展迅速，其應用已經不只是被侷限在 Web 之上，甚至適合各種不同的領域與場景。所以，許多的功能及模組被大量開發出來，從網路應用、桌面應用甚至到嵌入式應用都可以使用 Node.js 來開發。 可以應用在各種場景，代表就會有不少人面對 Node.js 數不清的模組時，總是不知道該怎麼辦，除了很難抉擇之外，更是有很多超出原本常識的模組存在。有些時候，更是需要將許多模組拼湊起來，才能完成一個特殊的功能。 然而，大量的應用範例，也需要花大量時間才能一一摸索，若不是有人事先整理好，對於大多數人來說，無疑是永遠無緣觸碰。因此，這本書為此而生，希望透過大量整理各種應用範例，以減少 Node.js 開發者摸索的時間，加速學習或研究的速度，更甚至縮短產品開發的週期。 如果你是初學者，你可以從中找到一些基本模組的完整範例參考，或是學習模組選擇的方法。如果你已經是很熟悉 Node.js 開發的專家，你可以從本書看到許多使用 Node.js 所開發的特異功能的應用範例，如：Bittorrent、SSH Server、演算法、加密、文件格式、多媒體支援等。此外，本書也將提及 C/C++ 原生模組和 V8 JavaScript 引擎的原理和範例，還有各種資料庫、Message Queue（訊息佇列）等常用的完整使用範例，當然也有今年最新的 io.js 相關內容。 雖然說本書名為模組參考手冊，但整本書卻是以應用範例為導向，並非完全是一個個模組的介紹，有很多是多個模組整合而成的範例，許多部份都是網路上連原文文件都缺少的資訊或文獻，可以說是花大量時間和經驗的結晶。 我只能說，希望讀者們會喜歡！希望能幫上大家工作開發上的忙！請大家多多支持！ 後記 前一本『不一樣的 Node.js』，因為一些模組更新太快，所以有些章節已經有些老舊，如果你是前一本書的讀者，可以和新書『 Node.js 模組參考手冊 』做比對參考，因為裡面有雷同的章節，可以使用新書的方法來取代舊書老舊的部份。 至於舊書翻版，我們已...

對很多人來說，黑客松（Hackathon）是一個可怕的詞彙，它神秘且陌生，似乎是只有軟體工程師能參與的活動。事實上，黑客松的本意只是希望大家可以齊聚一堂，跳出原本的生活圈，和其他人完成或創造一些與平常不一樣的東西。 打造一個平民化的黑客松一直是 Hackathon Taiwan 的目標，除了每月都舉辦推廣之外，為了讓活動更親民，還特意引入各種初學手把手的工作坊課程，以減少眾人對黑客松的恐懼，課程內容涵括了網站、軟體、硬體、設計、藝術領域，從 Arduino、Node.js、QML、前端、雲端服務、科技藝術一直到 3D 印表機等整合課程都有。為了讓更多人能學習更多更深入的技術，也陸續開設了不同類型的進階工作坊。無論是已經很厲害的人，還是沒有太多經驗的學生，都可以前來活動，找到自己覺得最舒服的位置，學習發自內心的動手去完成一件事。 這活動的最終目的，是希望見到大家以能力會友，撞出火花，讓大家找到能互補的團隊成員，成就未來有潛力的團隊，實現更多具有影響力的創新。如我們一直所說，這是一個如太古般的生命濃湯，孕育著人才與新創火花。來黑客松能做出什麼成果，或許很難說，但你一定會得到很多的朋友與經驗！ 我們期待終有一天，當某個成功的新創公司被問到：『當初創辦人們是如何認識？』，他們會回答：『在 Hackathon 活動』。 精彩回顧影片 還不知道黑客松在做些什麼嗎？看看我們三月份兩天一夜活動的精彩回顧吧！ 下次活動訊息 4/11-4/12 （六、日）兩天一夜的黑客松活動也開放報名了！完全免費！名額有限，快來報名吧！ 議程頁面 ▶  https://hackathon.tw/agenda/agenda.html 報名頁面 ▶  http://www.accupass.com/go/hackathon06 社群訊息 此外，如果你有興趣，可以加入 Hackathon Taiwan 的 Facebook 粉絲團，關注最新動態！ https://www.facebook.com/HackathonTaiwan

自從 Node.js v0.11 版之後，內建的 V8 引擎被更新了，於是 JavaScript 引擎的原生 API 大幅度改變，導致很多以 C/C++ 所撰寫的原生模組紛紛出現相容性問題。影響範圍包括了前陣子發佈的 Node.js v0.12 以及 io.js 1.0+，因為都使用了新版的 V8 JavaScript Engine，而有同樣的問題。 其實這樣的問題已經不是新鮮事，自從 Node.js v0.8 到 v0.10 就開始有些許不相容的問題，只是到了 v0.12 和 io.js 之後，出現了更多狀況。因此 Node.js 圈子內的知名開發者 Rod Vagg  建立了 NAN 專案，用來解決這樣 Native API 不相容的問題。 NAN 全名為 Native Abstractions for Node.js，目標是設計一系列通用 API 供 Native Add-on 開發者所使用，讓開發者可以使用這通用的 API，一次性開發出支援 v0.8、v0.10、v0.12 和 io.js 1.0+ 的原生模組，不必再為 V8 原生 API 相容性所苦。 若想要使用 NAN，可以直接以 NPM 下載： $ npm install nan 然後在 binding.gyp 中加入 include_dirs 的屬性設定，讓 Node.js 或 io.js 引入 NAN 模組： 'include_dirs': [     "<!(node -e \"require('nan')\")" ] 經過這樣的設定配置後，我們就可以在 C/C++ 程式裡面引入 NAN 的標頭檔，開始使用 NAN 的 API： #include <nan.h> NAN_METHOD(Hello) {     NanScope();     NanReturnUndefined();     // 或是這樣寫 NanReturnValue(Undefined()); } 上面的程式碼，代換成舊的版本（v0.8、v0.10），就等同於： Handle<Value> Hello(const Arguments& args) {...

話說 如果你之前就有參加過我們的 Hackathon 活動，就會對從第一屆黑客松就有的倒數計時器有所記憶。這是我們特別為 Hackathon 活動所開發的倒數計時器，其著漂亮粒子特效，讓許多人印象深刻，尤其是投影在夜晚的牆壁和玻璃上，伴隨著台北 101 和夜空為背景，可說是非常炫麗又有氣氛。 但經歷過了四次活動，這個計時器也該功成身退了，隨著活動人數成長，活動內容及場地規劃，舊的計時器已經慢慢不敷使用，除了一身漂亮的動畫外，沒有太多的功能。而且，縱使有著一個看起來炫酷的特效，對工作人員和很多參加者來說，也慢慢膩了。 於是，我們又提起筆開始設計一個全新的倒數計時器系統，想設計一個更具科技、科幻感及現代感的介面，除此之外，更希望可以在未來可以引入更多的功能和互動機制，如導引、會場資訊查詢、甚至是直播等。就這樣，一個新的計時器誕生，並在 3/7 - 3/8 第五次的黑客松活動被使用。 因為我們期望這個計時器，不只是用來倒數計時，未來能變成一個多用途的活動系統，所以在設計上有更多的規劃及保留。也採用更多色塊來進行設計，讓畫面上有更多可利用的空間。 互動功能 在這次活動中，我們觀察到了一個現象，那就是對正在專心進行創作及 Hack 的人，手上的工作雖樂趣無窮，但對於旁觀者來說，卻是無聊透頂，這讓黑客松（Hackathon）活動的現場，時不時會呈現一種沈悶的氛圍。此外，參加者的工作效率往往呈現著週期性，或是專心時間總有一個極限，適當的放鬆和中斷也是常見的情況。但是如果放鬆或中斷手上工作時，沒別的事可以舒展身心，這會感到相當無聊了，於是會看到有些人會選擇用吃東西來打發中間的時間。 其實，來黑客松除了動手做之外，人際關係經營及交流也是很重要的一環，但別人正在專心工作時，你不便打攪，尤其是當同隊的人都正在專注做事實，你剛好想要換個氣的時候，更不可能去煩自己的隊友。不過，雖然你的周圍可能沒人可以跟你互動，但你可以去找同樣想換氣的人產生互動，畢竟全場人這麼多，跟你處於同一個狀態的人總是有不少。 那麼，如何找到人可以跟自己互動或交流呢？ 這次活動，我們建立了 IRC Channel ，讓參加者可以上來 IRC 聊天室來說說話。所以，如果你有興趣，除了活動時間之外，平時也可以加入我們的 IR...

每個月舉辦的台灣黑客松（Hackathon Taiwan），第四屆活動順利落幕！感謝大家的支持！無論你碰上什麼樣的隊友，有沒有完成作品，下次都歡迎再來！ 曾幾何時，許多人對黑客松活動已經感到麻痺，似乎就是一群躲在暗處的宅宅工程師聚集起來自我感覺良好的場合，不然就是許多新創團隊前來展示產品的地方。往往沒有機緣巧合參與的人，總是深怕自己能力不足而無法參與，也有人覺得來這裡看別人發表產品，相當無趣。人們逐漸忘了黑客松的原本出發點，也忘了捲起袖子動手的熱情，更忘了與人交流並相互扶持學習的愉悅。 事實上，一個在大家心目中理想的黑客松，不外乎就是有得玩、有得學、有得做、有得交流，最後，能上台展示自我並取得成就感。這樣的氛圍，不同於補習班，也不同於一般制式學校，因為沒有成績壓力、沒有世俗壓力、更沒有人干預你，這更像是一個大學校園，參與者就在這樣的環境中自由發展，盡情做自己覺得有趣的事。 也許是教育體制的問題，也許是歷史文化所致，我們從小就沒有太多自由發展的機會，這讓不少人很晚才找到了自己的興趣。而進入社會後，缺少發自內心驅動的職場生活，讓更多人被生活所困，只能被世界及國內潮流被動的推著往前。我們有多久，沒有因學習新事物而開心？我們有多久，沒有因為與同伴們完成共同目標而感到興奮？那些再簡單不過的樂事，變成是種奢望。 這也是為什麼，我們發起了這樣的黑客松活動，試圖喚起人們的童趣以及熱情，讓人們在這找回自我學習的熱誠，以及團隊合作的心情，更重要的是，能夠學習如何貢獻並展現自己。在我們的活動中，無論結果的作品如何，這些種種對一個好的人才來說，都是不可或缺的要素。因為我們認為，台灣的人才素質普遍不錯，只是尚未有好的方法展示出來，並引出其真正價值而已。 共同持續參與，並逐漸改變這個社會氛圍，在這我們看見了人才們發光，也看見這片土地的希望。如果你問我說台灣黑客松每屆的活動能留下什麼？我會說，別的黑客松我不知道，但我知道我們的活動，讓人們帶回去的是提升後的自己與改變產業、社會的動力。 也許你沒發現，但經歷過這一切後，你已經不一樣了。 後記 不同於普通的活動，籌劃黑客松更為累人，除了要照顧的是兩天一夜的會眾，還要規劃各類課程與營造氛圍，更不能為了財務壓力下與中心思想背道而馳，複雜程度完全不可同日而語。 可愛的是，我們的參與者都是發自內心的願意主動參與，...

io.js 不做任何設定下，預設支援了一些 ECMAScript 6 的語法，其中包括一系列的 Collection 支援，這讓 JavaScript 在資料操作上多了一些方便之處。本文將討論到的 Set 物件，就是其中一個 Collection 類別。 簡單來說，Set 是一個類似 Array 的物件型態，可以用於處理有序的資料，而且內建迭代器（Iterator：在某些應用上同樣功能也會稱之游標 Cursor），讓開發者可以很容易對資料進行一筆筆的處理。 基本操作 基本的 Set 物件使用很簡單，如下所示： // 建立一個新的 Set var items = new Set(); // 依序加入資料 items.add('Fred'); items.add('Stacy'); items.add('Wesley'); items.add('Rance'); items.add('Kevin'); items.add('Alex'); // 依序印出 Set 物件內的所有資料 for (var item of items) {     console.log(item); } 比較特別的是，如果要依序印出 Set 物件內的所有資料，需要使用『of』這個關鍵字。原因是 Set 物件本身是一個 Generator 實作所致，如果我們想要一次把 Generator 內的工作跑完，需要運用 for-loop 加上 of 關鍵字來達成。 註：關於 Generator 與 of 關鍵字，日後有空再撰文說明其細節。總之，只要記得必須使用 of 關鍵字才能一一讀取 Set 物件內的資料，就像 Array 的 for-loop 加上 in 關鍵字。 刪除資料 刪除特定資料可以使用 remove() 方法來達成，如下所示： items.remove('Wesley'); 若是要清空資料，可以使用 clear() 方法： items.clear(); 檢查資料是否存在 我們可以直接利用 has() 方法檢查特定資料是否存在： items.has('Rance'); 迭代器（Iterator）的使用 Set 的迭代器是圍繞著 Generato...

io.js 最大的特色，就是採用了最新的 V8 ，而且直接支援了 ECMAScript 6 的語法和特性，其中一項就是文字範本（Template Literals）的支援。這代表我們可以很容易在字串中代入其他的變數內容，就像一般的 Shell Script 一般，不必再像從前的方式，使用串接字串的方式達成。 如果想要使用這樣的文字範本（Template Literals），可以直接使用 ${} 來代入其他變數，然後以『`』字元將字串包起來，然後就可以將指定的變數內容代入到字串中： var name = 'Fred'; var stringTemplate = `Hi, I am ${name}!`; console.log(stringTemplate); 接著，如果你使用 io.js 來執行，就可以得到下列結果： Hi, I am Fred!

人才培育與還原、體現並轉化人才原始價值是我們的目標，這也是目前台灣產業界應該要努力的方向，所以我們希望組織 Hackathon 活動來達成這樣人才拓撲的願景。 我們認為，黑客松的精神與文化需要被好好培養，也需要藉由持續且長久經營才會有意義，其體現的結果不只是聚在一起這樣簡單，而是動嘴、動手還要動腦的交流。因此，在大夥努力之下，Hackathon Taiwan 今年的黑客松計畫已確定，從這個月底開始，將每個月最少舉辦一次黑客松活動，年底前達成千人黑客松！（握拳） 希望藉由黑客文化中親自動手的精神，將不同領域的人才收集起來，並長期持續提供創作氛圍，使參與者相互間產生巨大的化學反應，使創新的可能性有脈絡可循。也期待能將許多具有潛力但不得其門而入的人們，引導進入到這樣熱血的世界，累積更多經驗值。 這樣的目標並不容易達成，自去年幾次的黑客松活動開始，從慘兮兮的幾個人，一直到現在的百人活動，各方面缺失逐漸補強完備，這途中經歷過許多困難，夥伴們也自掏了不少腰包，好不容易才得以存活並開始快速成長。感謝一些企業們的長期關注與投資，以及貴人大力相助，使我們陸續找到可以支撐整個計畫的資源、場地與合作機會，相信今年會是起飛的一年！ 今年才剛開始，我們仍有很多事要做，也需要更多的資源與贊助，以及工作人員，畢竟，每個月都要籌劃一場數百人、至上千人齊聚一堂『微創業』的黑客松活動，實屬不易。所以，如果您願意支持並協助我們，請務必與我們聯絡！ 我們也歡迎學生或各種單位與我們合作舉辦活動，相互連結，共享成果。如果你想在學校推廣黑客松，也歡迎加入我們的團隊，或與我們一同籌劃。 期許，我們從這個土地上出發，立足在這個現今世界的核心位置上，能使信念綿延拓撲到全亞洲，甚至是全世界，讓此地變成人才們的朝聖之地。:-) 更多資訊，歡迎參考 Hackathon Taiwan 的官方網站： http://hackathon.tw/

Koa 採用了 Generator 來控制非同步流程，所以在採用 Koa 的程式碼上，我們會看到很多 yield 關鍵字的出現。某程度來說，Generator 讓程式碼變得乾淨許多，也平坦許多，比較少出現太複雜的 Callback 高山。這對 JavaScript 來說是件不錯的事，只是，對很多開發者來說，需要點時間熟悉其概念。 總而言之，所有 yield 的關鍵字，一定只會出現在 Generator 當中，而一個 Generator 長得會是一個以『*』符號開頭的函數模樣： function *() {     // 工作流程 } 所以若是你仔細觀察，就會發現 Koa 的路由處理，採用的不是 callback 來處理客戶端要求，而是 Generator： router.get('/test', function *() {     // 處理客戶端要求的工作 }); 其實不久前，舊文『 如何於 KOA 實作長輪詢（LONG-POLLING）機制 』已提及怎麼來掌控 Koa 的流程，雖然只是簡單提及，但已經大略展示其使用方法。簡單來說，你可以當作這個 Generator 結束後，與客戶端的連線就會結束，所以我們如果要處理非同步的工作，也必須避免和阻止這個 Generator 執行完。 使用 yield 控制 Generator 的流程 為了阻止 Generator 一下就跑完，我們會使用 yield 方法來暫停 Generator 的執行，並等待一個需要花時間的非同步工作完成。如果你對舊文的內容有印象就會知道，想要使用 yield 在 Koa 中去呼叫一個非同步機制，就需要設計一個特別的函數，其函數有一個 callback，當這個 callback 被呼叫時，代表工作完成。 如下面範例就是想要執行一個非同步函數 setTimeout()，並等待其執行完成。在這範例中，我們加上了 console.log() 印出 START 和 END 字串，便於觀察其行為： router.get('/test', function *() {     console.log('START');     // 暫停 Generator 並等待工作完成     y...

io.js 的到來以及即將釋出的 Node.js v0.12，意味著我們不能再忽視 ECMAScript 6 的存在，更代表著 Koa Web Framework 開始要正式進入到市場了（如果你對 Koa 有興趣，可以參考『 舊文 』的簡報內容，有說明完整的開發方法，也有說明 Generator 的使用方法）。Koa 大量運用到 ECMAScript 6 新的 Generator 支援，簡化了非同步的機制，更減少了 Callback 的使用場景。 平心而論，Generator 的機制對許多 JavaScript 開發者確是一個不小的門檻，與舊有的習慣格格不入，需要一點時間學習及熟悉。如果你還不熟悉其機制的細節，不如先學習一些習慣的使用，這是一個比較快能上手的方式。所以，我們可以試著來實作 Long-polling（長輪詢）機制，理解如何運用 Generator 在 Koa 中進行非同步的實作。 若開發 Web 應用涉及了即時的需求，不免碰到 Long-polling（長輪詢）的機制， Long-polling（長輪詢）簡單來說，就是讓伺服器可以即時通知客戶端有資料要進行傳送，常被用在聊天室、即時通知訊息等應用，如 Facebook 的訊息通知機制，就是採用這樣的方式。 Long-polling（長輪詢）的運行原理，就是讓客戶端向伺服器要求新的資料，但取得資料後雙方都不中止連線，等到伺服器有資料要通知客戶端時才將連線中斷，而客戶端就知道有新資料要接收，重新建立一次連線以取得新資料，然後又再次保持連線不中斷，等待下次通知。 暸解了原理，我們就可以開始實作伺服器的部分。首先，假設我們現在有一個事件發送器，每次有資料更新，就會觸發一次事件。如下範例，是每秒鐘更新一次資料： // 建立一個事件發送器 var dispatcher = new events.EventEmitter(); var num = 0; setInterval(function() {     // 將 num 加一，更新資料     num++;     // 通知所有客戶端資料有更新     dispatcher.emit('update'); }, 1000); 如果是 Express，若要實...

如果你有關注這兩個月 Node.js 的發展，就會發現一些大變動，尤其在最近半路殺出了一個名為 io.js 的 Application Framework，其來勢洶洶朝著 Node.js 而來。於是，很多人看糊塗了，開始搞不清楚兩者的關係，甚至以為他是一個全新的技術。事實上，一切緣由皆由 Node.js 而起，這是起圈內的八卦事件，當然，我們也可以將其看作是社群對把持開放原始碼專案的商業團體，進行的抗議行動。 io.js 的官方網站： https://iojs.org 由於 Node.js 的發展日益興旺，掌握著 Node.js 的發展進度就代表掌握著利益，所以 Joyent 開始掌控著 Node.js 的開發進度。縱使 Node.js 有著開放原始碼社群，也有著許多貢獻者，但新版本的釋出一直受到 Joyent 的掌控，最讓社群不滿的是 v0.10 版之後，已經快兩年沒有發佈新的穩定版本。這意味著，無論社群絞盡腦汁去協助開發 Node.js，成果永遠無法面市，也意味著大家所期待的 ECMAScript 6，遲遲無法在 Node.js 上被支援。 終於，社群等不下去了，在 2014 年底發起新的計劃 io.js ，試圖 fork 原本的 Node.js 專案，目標是如果 Joyent 遲遲不發佈 v0.12 版的 Node.js，就打算自己動手。這個 io.js 的新專案，緊鑼密鼓的展開，吸引了許多開發者的關注及加入，不到兩個月的時間，在 2015 年 1 月中推出了 io.js v1.0.0 的版本，並且打算加緊步調，讓開發與發布週期更為密集。 其實，我們可以將 io.js 的 v1.0 版視為 Node.js v0.12 版，它們本質上是一樣的東西，所以 io.js 也可以支援 NPM，有著一樣的使用方式、API 和架構設計，更相容於 Node.js v0.11 及未來的 v0.12。這代表，原本以 Node.js 所開發的應用程式，理論上都可以正常以 io.js 執行。 至於未來 io.js 是否會將 Node.js 取代呢？我們拭目以待。