依照原始 Gopher 授權方式，採用 Creative Commons 3.0 Attributions 釋出，謝謝！原始 SVG 向量格式檔（以 Inkscape 繪製）以及完稿輸出的 PNG 檔請下載本壓縮檔。

這篇是很久以前答應 hSATAC 大人說要寫的，由於一直有更有趣的事情可以做所以就拖稿拖到現在，主要講的是如何使用 Packer 來快快樂樂建 AWS EC2 AMI，將這件事情給它 infrastructure as code 這樣。

範例檔案放在 [GitHub] 這裡，這篇舉的例子，是建出一個把 Drupal 8 裝好的 AMI，先看 packer.json：

{
    "variables": {
        "drupal_version": "8.2.5"
    },
    "builders": [
        {
            "type": "amazon-ebs",
            "name": "drupal-8-ami-us-east-1",
            "ami_description": "My Drupal 8 barebone AMI ({{user `drupal_version`}}) (us-east-1)",
            "region": "us-east-1",
            "source_ami": "ami-e13739f6",
            "instance_type": "t2.micro",
            "ssh_username": "ubuntu",
            "ami_name": "drupal-8-ami-{{timestamp}}",
            "tags": {
                "Name": "drupal-8-ami-{{timestamp}}",
                "Distribution": "Ubuntu Server 16.04 LTS (HVM), SSD Volume Type",
                "Drupal": "({{user `drupal_version`}})"
            },
            "ami_block_device_mappings": [
                {
                    "device_name": "/dev/sda1",
                    "volume_size": 8,
                    "volume_type": "gp2",
                    "delete_on_termination": true
                }
            ],
            "launch_block_device_mappings": [
                {
                    "device_name": "/dev/sda1",
                    "volume_size": 8,
                    "volume_type": "gp2",
                    "delete_on_termination": true
                }
            ],
            "vpc_id": "vpc-cc9aeba9",
            "subnet_id": "subnet-940f76ae",
            "associate_public_ip_address": true,
            "security_group_ids": [
                "sg-15a50671"
            ],
            "communicator": "ssh",
            "ssh_pty": true
        },
        {
            "type": "amazon-ebs",
            "name": "drupal-8-ami-us-east-2",
            "ami_description": "My Drupal 8 barebone AMI ({{user `drupal_version`}}) (us-east-2)",
            "region": "us-east-2",
            "source_ami": "ami-d1cb91b4",
            "instance_type": "t2.micro",
            "ssh_username": "ubuntu",
            "ami_name": "drupal-8-ami-{{timestamp}}",
            "tags": {
                "Name": "drupal-8-ami-{{timestamp}}",
                "Distribution": "Ubuntu Server 16.04 LTS (HVM), SSD Volume Type",
                "Drupal": "({{user `drupal_version`}})"
            },
            "ami_block_device_mappings": [
                {
                    "device_name": "/dev/sda1",
                    "volume_size": 8,
                    "volume_type": "gp2",
                    "delete_on_termination": true
                }
            ],
            "launch_block_device_mappings": [
                {
                    "device_name": "/dev/sda1",
                    "volume_size": 8,
                    "volume_type": "gp2",
                    "delete_on_termination": true
                }
            ],
            "vpc_id": "sg-789c2d11",
            "subnet_id": "subnet-60e84409",
            "associate_public_ip_address": true,
            "security_group_ids": [
                "sg-789c2d11"
            ],
            "communicator": "ssh",
            "ssh_pty": true
        }
    ],
    "provisioners": [
        {
            "type": "file",
            "source": "./nginx/default",
            "destination": "/tmp/nginx-default"
        },
        {
            "type": "shell",
            "inline": "wget https://ftp.drupal.org/files/projects/drupal-{{user `drupal_version`}}.tar.gz -O /tmp/drupal.tar.gz"
        },
        {
            "type": "shell",
            "script": "./provision.sh"
        }
    ]
}

這份 Packer template 裡頭很多地方都可以望文生義，我就不一一逐條解說了。只講一些概念上的、可能會遇到坑的地方。

首先，一份 Packer template 分為好幾個部份，我這個例子裡，就分成了 variables, builders 以及 provisioners 三塊。

其中，在 variables 裡我們可以宣告接下來會用到的變數，在我這個例子裡，我把想裝的 Drupal 版本寫在這裡，之後很多地方都可以用 {{user `drupal_version`}} 來引用。

然後看到 builders 這塊，我分別想在 AWS 兩個美東 region 建立需要的 AMI。這裡有個小 tricky 的地方，就是如果我們不特別寫 name 這個屬性的話，Packer 是不會允許我們建立多個同一 type 的 images 的（這裡就是指 amazon-ebs），如果我們需要在複數個 AWS region 建立 AMI，就要特別寫明 name。

還有要注意的一個概念是，Packer template 裡面寫的各種屬性，是在「建立 image 當下」使用的，AMI 建完後，要怎麼使用是你家的事，Packer 並不負責這塊。所以呢，為了 Packer 方便作業（在這裡是透過 SSH 連進一台為了做 AMI 而臨時開出的 EC2 instance），像是 vpc_id, subnet_id, associate_public_ip_address, security_group_ids 這些設定，是 Packer 呼叫 AWS API 開一台 EC2 instance 時使用的，特別是 security_group_ids，注意這些設定要能夠保證 Packer 可以 SSH 登進去機器，不然就等著 timeout 執行失敗。

provisioners 這裡我們可以用很多方式來對 AMI 做 provisioning，Packer 官方提供了很多常見的 provisioners，除了基本的丟 file、跑 shell script 以外，還有一些很潮很夯或不潮不夯但有用的自動組態工具像是 Ansible, Chef, Puppet。搭配這些自動組態工具就有更多花樣可以玩，可能也比 shell script 更好處理一些更需要彈性的東西。

最後提一個小技巧，就是如果我們跑 packer build packer.json 時遇到問題，那麼用 packer build -debug packer.json 進除錯模式，Packer 會把它為了這次 building 動態產生的 SSH key 寫在檔案系統裡，讓您可以手動 SSH 進去這台機器，方便診斷問題所在。

先從 [Rust is more than safety] 這篇開始，作者認為到目前為止，Rust 在行銷上並沒有打到「我能為用戶解決什麼問題？」的痛點，光只在語言設計的層面上兜圈子，特別是「安全」這點，然後有了這些回應：

• [graydon2 | Rust is mostly safety]: 作者認為以一個系統語言來說，Rust 不但追求「安全」還特別致力於滿足 concurrent 下的「安全」，就是 Rust 的最大賣點。
• [Safety is Rust’s Fireflower]: 作者認為 Rust 主打的「安全」，就是讓涉足系統程式設計的用戶，終於有一個在這方面做得比過去同質產品更好的選擇可用，如同瑪莉歐裡的金花一樣。
• [Fire Mario, not Fire Flowers]: 原作者被各方吐嘈後寫的回應。引用前面瑪莉歐的譬喻，認為 Rust 的行銷應在是聚焦在「吃了 Rust 這朵『安全』金花，會讓你成為火球瑪莉歐」，而不光是「Rust 是一朵有『安全』功效的金花」。
• [Fire Flowers and Marios: Marketing Rust – Medium]: 各打五十大板的吐嘈。我覺得這篇前面有點像來亂的，但是後面寫得還頗有道理，對於技術的行銷來說很中肯。
• [Rust is Software’s Salvation – Redox – Your Next(Gen) OS]: Redox 這個採用 Rust 寫的 OS 專案也來參戰，作者寫出從早期因為 Rust 的幾項特性 (safety, concurrency, performance, documentation) 而開始接觸這語言，算是忠實愛用者，但是覺得 Rust 當前的問題之一就是「太少東西是以 Rust 寫成的」，從這點引申論述 C 語言為何至今還是受到相對多數的用戶採用、C 語言的問題、軟體的品質問題、Rust 或許就是這個問題的救贖。

2016 年回顧：

1. 硬著頭皮、厚著臉皮，報名碼天狗週刊的策展人，逼鞭策自己看 Erlang, Elixir 的東西。在這種大家都還沒凝聚出死板的操作定義、最佳實踐、把生態圈風氣變得人云亦云、按表操課、造神拜神的時候，很多東西可以隨心所欲地摸索，我覺得就是最好的時候。
2. 悟出「購物車」這種系統，其實可以採取簿記原理設計。
3. 在工作中採用 Scrumban 方法，以及實踐心目中的「真．DevOps」工作文化，覺得學到很多、成長很多。也比較快樂。
4. 「用戶想的與你不一樣」，其實沒有倒站，卻在用戶的感受下（所謂的 UX）認定我們就是倒站， 雖然覺得冤枉，但是習得這樣的教訓並改進相關的 UI 後，覺得如果自己是用戶，這樣的改良用起來也會比較爽。也是一次寶貴的經驗。
5. 從「月薪嬌妻」中警惕自己對於「責任」與「義務」的區別，不能因為因循苟且而麻木、失去判斷力。追求婚姻的品質，這是根本。

想做兩個應用：

• 鄰居的二手菸偵測器
• 依空間亮度、時段的芳香噴霧機啟動開關

之前其實我對 Arduino 抱著一種鄙夷的態度，認為男子漢既然要做這種單晶片應用，就該直接去用單晶片，這樣才硬派。

但是直到最近想做上列的兩個應用，光是製作一塊電路板，就讓平時已經忙得不可開交的我卻步。而 Arduino 這種把介面（無論是指軟體或硬體）、控制語言的基礎先弄得具體而微的快速原型製作工具，其實幫人省下了不少時間。

而且做出來的東西，就算不是量產等級的，但也不只是不中用的「玩具」，而是確確實實能派上用場的成品。

就是這樣，我對 Arduino 的觀感開始轉為覺得它可親可愛。

一開始接著要寫這第二篇的時候，我的腦袋又陷入了之前寫學位論文時的窠臼，或者說是心魔，心想要有一套論述、理論，來支持我最後想帶出來的結論，於是愈寫愈覺得處處碰壁，深怕哪邊沒防禦好、又要被吐嘈。

唉，網路何時變得這麼可怕？（掩面嚇哭）

不過這系列廢文就只是「雜論」罷了，我真的給自己太多壓力了。且其實資訊架構有其適合的人事時地物（不過也存在著因循苟且、習慣成自然的那種「沒有架構的架構」啊…），並沒有絕對的是非好壞。所以我只要照我的腦子想到哪、就記到哪、歸納到哪，這樣就好了吧？

巴哈洽特

因為 Chat 被起了個渾名叫「洽特」，所以我就自己把巴哈姆特 BBS 的 Chat 看板戲稱為「巴哈洽特」。

在很久很久以前，巴哈姆特 BBS 還算百花齊放的時候，Chat 只是一個「不分類雜談區」，但是現在 Chat 可能是巴哈姆特 BBS 之所以還維持資訊流量的、一枝獨秀的看板。在我忘記鳥窩 BBS 密碼、且鳥窩關站後，Chat 就是我溫度最接近的同溫層了。

為什麼要特別講這個呢？是因為我覺得巴哈姆特的「主題串接模式」很難用，又或者說目前這些還活著的 Telnet BBS 站的同質功能都很難用，在訊息量大的 Chat 尤其常讓我覺得心煩意亂，追某主題的新文章，得一直在「一般文章列表」、「主題串接模式」間切換。

但是這當中的含金量、哏量又每每讓我覺得心滿意足。

Twitter 在訊息列表整個攤平 (flatten) 這點上有些相似。Twitter 把資訊單位化簡到「某個人，在某個時間，講了什麼話」的「訊息」，然後在「時間軸」上鋪排開來，這樣的資訊架構。要追個前後文，來來回回點個好幾層是常有的事。

不太一樣的地方是，Twitter 通常是我先看到我 follow 的帳號用戶發的推文，或這些帳號轉他人的推文，但是 BBS 比較沒有這樣的 filter bubble 效應。

現在很多 Web 式的論壇系統，也稱自己為 BBS，但在討論串 (threaded) 呈現這方面，做得更直觀、好用些，甚至還有 semi-threaded 與 full-threaded 的結構。

我當然是希望我的「這個 BBS」能夠把討論串的呈現弄得更好爬文。而我設想的結構甚至不是樹狀，而是圖 (Graph)。