作為軟體開發人員，山姆鍋也很常跟 QA 團隊說過類似這樣的話：「這個版本，在我的電腦上可以正常執行」。我們都知道開發人員的執行環境跟其他成員通常有很大的差異，所以，說這句話往往只是浪費時間，對於解決問題並沒有太多實際幫助。那有沒有方法可以讓開發以及測試人員有一致的環境來確認問題根源呢？藉由虛擬化技術以及 Vagrant 這樣的工具，現在我們有更好的方法。

作為一家認同「精實生產」理念的雲端軟體服務公司，「影化身科技」同樣擁抱「持續整合」的敏捷開發模式，為了達到持續整合的要求自然需要有持續整合系統的支持。本文山姆鍋收集一些提供雲端持續整合的服務，並提供「影化身科技」採用的方案作為參考。本文屬於 「善用雲端服務，微型企業的自強之道」系列文章之一。

雖然不是所有公司都需要專案管理系統，但「影化身科技」作為一家雲端軟體服務公司，專案管理系統的運用有其戰略上的目的。這裡的「專案管理系統」並不單指像是 Mircosoft project 這樣用來管理資源與行程的軟體，舉凡問題回報、需求追蹤也涵括在專案管理系統的範疇內。作為「敏捷開發」的擁護者，「影化身科技」採用哪種專案管理系統？本文屬於 「善用雲端服務，微型企業的自強之道」系列的文章之一。

「影化身科技」採用 Google Docs 作為雲端文件管理系統，理由除了 Google Apps for Business 已經包含這個服務外，主要還是它符合需要又不用錢。對於「影化身科技」這樣的微型企業，能有這樣免費又高品質的服務真是難得的資源。
本文屬於 「善用雲端服務，微型企業的自強之道」系列的文章之一。

文件管理系統簡單地說就是管理企業文件的建立、分享、編輯等協同工作的系統。作為雲端文件管理系統，山姆鍋認為下列特性最為重要。

之前的這篇 「使用 Amazon S3 作為 Maven 套件倉儲」文章中，山姆鍋提到使用 Amazon S3 作為套件倉儲的構想與好處，但那篇文章只適用于採用 Maven 作為建構工具的專案。山姆鍋已採用 Gradle 作為「影化身科技」的正式建構工具，所以，需要針對 Gradle 找到適合的方案。

在使用 Vert.x 作為即時網頁應用平台這篇文章，山姆鍋提到「影化身平台」利用 Vert.x 作為即時 Web 應用的服務框架，看中的是它對網路服務的執行效率。除了方便網路服務開發外，Vert.x 的模組 (module) 支援，對於寫大型網路服務來說是個很重要。

作為軟體開發人員，山姆鍋跟大多數人一樣不太喜歡寫文件，但文件 (尤其是 API 等技術文件) 其實就跟原始碼一樣需要即時的更新與維護。「影化身科技」的網站已經採用 Markdown 這種輕量級文件格式且所有內容都跟程式碼一樣進行版本控制，對於技術文件，自然希望採取相同的流程。本文說明山姆鍋選擇 AsciiDoc 作為文件格式的主要原因。

使用 Maven 或 Gradle 等軟體建構工具 (build tool) 常常會需要使用 Maven 套件倉儲 (artifacts repository) 來作為套件存放的地方。過去山姆鍋習慣使用 Nexus Repository Manager 來作為這樣的套件倉儲服務器， Artifactory 雖然沒用過，看起來也很不錯。本來不加思索打算按照習慣用 Nexus 安裝個套件倉儲，或者使用 Artifactory 看看也很新鮮，但突發奇想：可不可以使用 Amazon S3 來作為 Maven repository？有什麼問題跟限制？

在 DevOps 的發展趨勢中，將新功能儘快自動交付給使用者是其中重要的一環。但觀看相關的文章，會看到幾個好像相關但應該又有點不同概念的名詞：「持續整合 (continuous integration)」、「持續部署 (continuous deployment)」、與「持續交付 (continuous delivery)」， 到底他們之間有什麼差異？山姆鍋也來分享一下自己的想法。

不管是網站或者網頁應用 (web applications)，提供支援的語言、框架、工具等等可以說已經相當成熟，對初學者來說：最大的問題應該只是常常不知道該如何選擇哪個。但隨著行動網路裝置的普及，網頁應用開發面臨新的挑戰，像是：要求大量連線、即時雙向互動等，這些都讓傳統的應用服務器 (application server) 出現捉襟見拙的窘況。本文山姆鍋介紹 Vert.x 這個即時網頁應用框架，作為雲端應用基礎架構的一部分。