本篇主要分享在 TRON (波場) 部署智能合約 (Smart Contract) 並與之交互的經驗分享。
為讓初學者快速瞭解與跟著操作，所有的環境都在本機 (自建私鏈) 完成，操作完成後，也可以方便快速地刪除，回到本機乾淨的環境。
軟體工程領域 (軟體架構) 的 “Legacy system” 層級之分。
這篇文章會分享我如何利用容器 (Container) 來依據產品或專案，分門別類的管理並隔離各種程式語言開發環境及其版本。
為了解決各種疑難雜症，我很常需要在各式各樣的開發環境來回切換，諸如 Python、Go、PHP、Node、Java 等，若再加上版本號，如 Python 2 / 3、Node 8 / 12、Java 1.8 / 11，則組合方式更為多元且複雜。這不僅容易弄亂生產環境，有時還會彼此發生衝突。
過去我會採用系統預載的版本，例如 Ubuntu 18.04 預設為 Python 2.7，然後再加上 Version Control 工具 (如 pyenv) 來新增 Python 3 環境，再用 virtualenv 來隔離模組。但到了容器化 (Containerization)時代，我們可以有更整潔的解決辦法。
時常不知道或忘了某個命名慣例的名稱嗎？這裡條列了常見的程式命名慣例、命名規則 (Naming convention)，以讓軟體工程開發時，有參照原則及共同語言。
VS Code (Visual Studio Code) 對技術的細緻，或許才是拉大與其他競品距離的主要原因。
本篇是 TGONext 架構組 - Ant 組在 2020-03-27 第二次聚會的內容整理。這些經驗與能力決定了你的價值。
第一篇是 軟體技術架構如何正確與商業需求快速對齊：談 MAU 換算至 RPS，SLA 回推至 SLI。
此次聚會是雜談，關於 Migration, 架構演進, Queue。
(按圖放大, click for enlarge)
軟體技術架構應該要如何正確與商業需求對齊？很多人有不同的想法，而依據我多年的經驗，不外乎就是質及量。
質與量有很多檢測依據可以評斷軟體技術架構是否符合商業需求，而因為時間與篇幅有限，這裡我先提出兩個最基本的對齊方式。
質在商業需求就是SLA(Service-Level Agreement, 服務等級協議)，即公司提供給客戶的服務品質保證。量在商業需求就是MAU(Monthly Activited Users, 月活躍客戶)，即公司商業希望達成的每月活躍客戶數。有些人可能會用DAU(Daily Active Users，日活躍用戶)。
『Scalability! But at what COST?』 是 2015 年談及 Scalability (可擴展性) 的 Papers，但值得回味。
AWS Firecracker 的 Papers 值得推薦給對 Linux Virtualization 及 Container 入門有興趣的人閱讀。
Linux containers 及 virtualizations 差別
可看出 Firecracker 為了 security 及 compatibility 的權衡，選擇採用 virtualization 而不是 container 的原因。