Fred's blog

搭配使用 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.*') 。 這樣設計有什麼好處呢？因為所有的訊息和命令傳遞，都有統一的事件機制和命名規則，理論上來說，事件...