這次的文章主題是「網路安全概述」。不過，其中除了講了一些網路層的東西，中間還帶到軟體、IoT、甚至印表機和 CPU 漏洞等等。

有人問說，為什麼不講應用？

因為「應用工具」的資源已經很多了。
個人覺得，基礎知識反而比較少人去鑽研。用了工具，卻不懂背後的原理，豈不是很奇怪？
若光用了工具，卻不了解原理，要怎麼知道如何防禦別人用這種工具打你？

這次的文章，由於有一大部分都是我「原本已經知道大略，但缺乏細節的了解」的知識，所以，大部分寫文章的時候，都是一邊看 paper、參考資料等等，一邊寫。

我分享一下是如何去吸收這些知識的：

• Hacker News，很多消息會先在那邊出現，但不一定有細節
• arxiv
• 社群，例如 若渴計畫 或是 Many Hats Club

「催文機」

由於這次參賽，是以團隊的身份來報名。這次報了 20 個人，且我本身記憶力頗差，一定會忘記發文或寫文章。如果失敗了，代表說我會有 19 個人的壓力（冤魂？）壓在我身上。

而且，一定也有人有這種困擾，我不希望任何人都會遇到這麼慘的狀況。

研究

首先我們必須先分析這個問題。

問題的根源是：有可能會忘記發文

所以，如果有人會忘記發文，那我們就應該想辦法通知他。我們有用 slack 當溝通工具，所以可以用 slack incoming webhook 來搭配爬蟲！

當然，由於問題是「會忘記發文」，所以最直接解決問題的方法，就是直接把大家的帳密都拿來，幫大家代發之類的。
但是這樣就沒有「團體參賽」的意義啦。

第一份工作是跟爬蟲相關的，所以我猜，這應該不會花太久吧？

實作

我快速的看了一下，因為只要抓團體的發文狀況，所以有兩種方式：

1. Hardcode 所有團隊隊員的主題，然後進去那個主題，用迴圈的方式看所有文章，並統計數量
2. 從「團隊成果」去看

第一種方法是Howard 的做法，這種方法會比較慢（因為 iThome 的伺服器不快）
第二種做法是從團隊首頁去看，這樣會比較快，因為一頁是 10 篇文章，只要爬兩三頁就可以完成統計

由於這次是用 AWS Lambda 去實作，所以執行時間會影響價格等等，而且爬蟲主要的目標，從上到下，依序是：

1. 把東西正確的抓回來
2. 使用的頻寬小
3. 執行速度快

顧及以上三種條件，所以採用第二種做法。

找出「規則」

快速翻過團隊的首頁，會發現每一個「主題」的連結都長得這樣：

https://ithelp.ithome.com.tw/users/20107159/ironman/1325
https://ithelp.ithome.com.tw/users/:userID /ironman/:topicID

（這是 Howard 的）

這網址看起來有兩個地方會變動：

1. userID
2. topicID

Howard 剛辦帳號，不可能有 1325 個主題。往下看，會發現 topicID 是有順序的，所以我猜測：itHome 的資料庫中，可能有一張叫 鐵人主題 的表，其 ID 格式是有順序的數字，這張表和 使用者 呈 1:m 的關係。（因為把 topicID 改成別的就會觸發 404）。

我們從這裡可以得知：topicID 可以當作「識別鐵人主題」的唯一條件。

AWS Lambda & Amazon Linux 地雷

所以憑直覺寫了一支程式，然後上傳去 Lambda。
這程式根本不會跑啊！

後來思考了一下，錯誤訊息大概是在抱怨「依賴包編譯環境與現在執行環境不同」。原本覺得 Lambda 根本壞了，但是後來想想：

1. 我的執行環境是 macOS
2. lambda 上面是 Amazon Linux
3. requests 或 lxml 其中一個有用到 C++ 函式庫，需要編譯

綜合以上幾點，這錯誤很合理。

我後來找到這篇文章，介紹如何使用 Docker 建立一個 Amazon Linux 的容器並拿來打包要跑在 Lambda 的程式碼。

Slack 的問題

解決 Lambda 的問題之後，發現：
Bot 沒有辦法正確的標記 Slack 用戶

而且更慘，某些人是可以正常地被標記，有些人是直接標不到（會顯示成黑色的字樣）。

經過一段時間之後，我找到 Slack 的公告：

原來是因為 Slack 開始不支持讓程式用 ID 來標記人（因為會撞 ID/ID 可以亂改等等），而只能用 UID 來標記。所以我就只好用 Slack API 找出每個有參賽的人的 UID，改過去之後，終於可以成功的標記人啦！

程式碼

Bot 如果運作正常，看起來會像這樣。

這個「催文機」的程式碼，放在 Github 上面。