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

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

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

一直以來，山姆鍋使用 Eclipse IDE 都很習慣預設的白色背景，但最近寫程式開始覺得白色背景似乎 "太亮" 了。看過別人使用暗色系主題，山姆鍋我也來更換一下吧。

「影化身平台」的設計目標之一是高可用性 (high availability)，而為了達到這個目的，基本上就表示系統的所有元件都要有冗余 (redundancy) 容錯 (fault-tolerancy) 的特性，以避免成為單一失敗點 (SPOF)。「高可用性」是個很大的課題，本文山姆鍋只先針對資料本身的可用性來說明「影化身平台」採取的解決方案以及使用的理由。

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

雖著雲端服務越來越成熟，相關的服務供應商也逐漸增加，對於微型企業來說，代表有更多的機會可以降低成本並提高競爭力。「影化身科技」主要專注在 Java 平台的應用服務，對於某些應用，尤其是 Web 應用，可以利用現有的 PaaS 供應商來免除初期投入成本以及服務器維運的負擔。本文收集幾個適合用來部署 Java 應用的 PaaS 供應商，作為未來部署時的參考。本文是「運用雲端服務建構企業基礎建設」系列文章之一。

對於在 Java 平台上，部署過後台服務器的人來說，讓 Java 程式以 Windows/Linux 服務 (daemon) 形式執行，是一個常見的問題，這裡的以 “服務方式” 是指該程式會隨系統啓動而自動執行，甚至更好的話，該程式如果異常結束會被重新執行。過去，山姆鍋跟多數的人一樣，選擇 Java Service Wrapper，不過自從它在 3.2.3 版本以後改了授權，雖然仍可以繼續使用 3.2.3 版本，但相信很多人也跟我一樣想尋找其他替代方案。

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

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