◎ 本文轉載自 Blog.XDite.net。

目前一些主流的語言都有提供所謂的套件管理機制，像是 Perl 的 CPAN，Ruby 的 gem，Node.js 的 npm 等等。而它們都屬於集中式的管理，可以讓開發者上傳自己所開發的套件。

當然 PHP 也是有套件管理機制，那就是 PEAR (PHP Extension and Application Repository)。只是 PEAR 官方為了套件的品質，所以在審查機制上非常嚴格；這也使得開發者很難把自己的成果，藉由官方提供的管道來分享給其他人。

雖然後來陸續有一些高手實作了某些方案，想要解決這個問題，但可惜都不了了之。

註：相關的資訊可以參考 c9s 在 OSDC 的介紹：OSDC.TW 2012 - The ecosystems of PHP and Perl。

◎ 本文轉載自 Blog.XDite.net。

第 4 件事：架設一套 issue tracking system

你用什麼工具來管理軟體專案的進度呢？我曾經一度認為使用 issue tracking 管理專案進度，是一件天經地義的事。大家都是這麼做的，所以這個題目沒什麼好談的。後來，我才發現這個印象大錯特錯…

◎ 本文轉載自 Blog.XDite.net。

第 3 件事：制定 Art／RD 都遵守的開發 convention

在傳統的開發過程中，作法多半都是：規劃 => UI／畫面設計 => 程式設計。

其實若專案規劃階段結束的早（也就是實作類似最低可行產品的概念），並非需要等待 UI／畫面設計完工，才可以進行到「套版」（程式設計）的階段。

一直以來，我都認為「套版」是一個非常不好的說法，造成了偏差的印象。因為一個網站實際上是「一整套」的「軟體」，並非是「畫面」設計的出來，程式就配合寫的出來。雙方必須都要是可以執行實作的部分才行。

◎ 本文轉載自 Blog.XDite.net。

第 2 件事：application deployable from day 1

在進入開發階段後，我會做的第一件事：make application deployable

也就是：專案開始第一天，就必須要有個 production 直接可運行（可以鎖密碼，當作測試 server）才行。（我在 Rails 101 這本書最後一章，加入 capistano 與裝機為必練技能，就是這個緣故。）

◎ 本文轉載自 網站製作學習誌。

之前分享了初探 RequireJS 一文後，對 RequireJS 已經有一定的瞭解，但後來實際應用到 Backbone.js 程式上時，發現了一些要特別注意的事項。

以下便是我在整合兩者時的筆記。

一直以來，我們都習慣使用 script 這個 HTML 標籤來載入 JavaScript 檔案。這種方式有兩種缺點：

• 無法在 JavaScript 程式中直接管理相依性，必須在 HTML 中處理。

• 雖然目前新式瀏覽器已經能夠以非同步的方式來載入 js 檔案，但是舊型瀏覽器還是會有阻塞 (blocking) 問題。

終於 CommonJS 提出了 AMD 這個 API 規範，用以讓我們的 JavaScript 程式可以模組化，並同時解決 js 檔案載入時的阻塞問題。

目前已經有許多實作 AMD 規範的 JavaScript Library 了，而 RequireJS 則是目前討論最多，應用最廣的其中一個實作。

以下是我在研究 RequireJS 時的筆記，若有謬誤還請大家指正。

◎ 本文轉載自 Blog.XDite.net。

借用新創網站這樣開發才夠快這篇格式，希望不要介意。我主要是想闡述以前在 T 客邦的經驗方法。

T 客邦在一年半裡面，就從台灣 Alexa 400 名以外，衝進台灣 Alexa 100 名內。這一年半時間技術團隊開發出了四個大網站，數十個子網站，和背後一群深厚的基礎建設 (HA, backup, PV stat, advertising system…etc.)。T17 實際開發的工時在 2.5 個月以內。

我是一個軟體工程師，過去六年我都在開發網站。在新創公司裡，速度節省時間、時間就是金錢、金錢就可以再去請更多工程師讓整個開發速度更快。學校並沒有教很多「軟體工程」的方法，或是怎樣才算是一個好的 Programmer。這些東西在台灣業界其實不存在的，大家都是邊做邊摸，從經驗中學習。我從書籍上和網路上學了很多能讓團隊更有效率的做事方法，因為我相信我在新創團隊裡我必須先這樣，用業界公認覺得快，且快得有道理的方式。底下是幾點可以和大家分享的。

◎ 本文轉載自 Blog.XDite.net。

很多人知道如何實作網站功能。但是卻不知道如何將網站成功的完工，並且如期上線。往往明明專案開始之初有不少的工期，有不錯結果的卻很少。上線前後總是一團慌亂。

其實「上線」這件事情完全是可以被掌控的。這當中有不少眉角，只是多半被疏於控制，導致風險橫生。

線上移轉 (Live Migration)

在系統管理的工作中，若發生可預知的硬體問題時，往往需要停機方可進行修復，相對地服務也必須停止運作。如果是透過虛擬技術來建置服務環境時，即可以減少因硬體維修所造成的停機時間 (service down time)。

◎ 本文轉載自 Blog.XDite.net。

我在網站程式上線前需要準備的事（四）提到了為了順利進行專案，一個好的專案管理系統絕對是必備的。

專案管理系統背後運作的邏輯何在，就是這篇文章主要的重點。

What is issue tracking (project management) system?

Issue Tracking system，顧名思義就是紀錄、追蹤問題的系統。BugZilla、Trac、Redmine、JIRA、lighthoustapp、Basecamp…等等這幾套軟體，都是知名的 Issue Tracking system。

◎ 本文轉載自 Blog.XDite.net。

關於 Github 被入侵這件事，目前在國外開發圈傳的沸沸揚揚。看來中文圈還沒有消息，我來報導一下到底發生了什麼事好了。順便宣導一下開發 Rails 程式碼需要注意的其中一個觀念..

到底發生了什麼事

Rails 的 master 被某個 hacker 塞上這一段 commit。以證明 Github 是可以被入侵的。

前言

前言

前言

本文將實作如何建立 Lagg 虛擬網路介面，並採用 LACP 方式，讓 FreeNAS 主機啟用網路卡頻寬合併功能 (Link Aggregation)，也就是 IEEE 802.3ad (Link Aggregation Control Protocol, LACP)，同時也將設定 FreeNAS 主機網路卡啟用 Jumbo Frame 功能，以便在 FreeNAS 主機進行大檔案（例如影音檔）傳輸時，能減少主機運算負載並加快傳輸時間，且於相關功能設定完畢後進行成員網卡故障及 Jumbo Frame 大封包測試。

您曾經用 Ruby on Rails 開發網站，但在國內找不到可以用的主機空間嗎？或者您是新創公司，但初期還沒有足夠的資金投資伺服器的硬體設備嗎？又或是沒有專職的 MIS 幫您管理伺服器？讓我們來看看 Heroku 吧！

簡介

自從 Heroku 出現之後，筆者挺羨慕 Rails 的開發者有這麼酷的服務可以使用。不過就在不久前 Heroku 也開始支援 Python 了，便趁著空閒玩了一下。大體而言只要熟悉平常使用的 Python 相關工具，像是 virtualenv、pip 以及 git，整個部署流程就很簡單。

本文將說明如何透過幾個簡單的步驟，把 Django 部署到 Heroku，手腳快的話十分鐘之內便可以看到網站在 Heroku 上運作了。

前言

相信許多人都有開發 PHP 的相關經驗，豐富的資源及其便利性皆為不可忽視的優點，程式本身撰寫起來也相對容易，相較之下環境建置及部署反而成為許多開發者的困擾。PHP Fog 透過 PaaS 的方式減輕了開發者在這方面的負擔，透過幾個簡單的步驟便將開發時所需的環境及資料庫設定完成，並且提供許多 Framework 可直接選用，讓開發者能更專注於程式開發。以下將透過 PHP Fog 平台簡易實做 PHP 程式開發。

Fossil 簡介

對於程式設計師而言，日常工作中最常使用的工具，可能會是編輯器，或專為某種程式語言所設計的整合開發環境；而對負責大型軟體開發工作的軟體團隊成員來說，版本控制系統則是另一套相當重要的軟體工具。如果沒有版本控制系統，大型軟體的開發團隊成員將難以有效控制軟體版本，並可能導致程式臭蟲增加。

目前在 UNIX/Linux 系統之中，已經存在許多成熟的版本控制系統，例如較為知名的 Git、Subversion 或 CVS 等等。若以架設方式加以細分，則有分散式與 Client-Server 二種不同的系統分類。除了這些系統以外，網路上還可以找到許多其他各具特色的版本控制系統。雖然這些系統的知名度較低，但如果仔細檢視其優點與特色，仍然可以找到一些頗為出色的版本控制系統。本文所要介紹的 Fossil，便是一套採用分散式處理方式的版本控制系統。