最近看了一篇熱門文章《利用 Apps Script 讓 Google 表單回覆自動產出 Google 文件》，不看不知道，看了才知道原來 Google 有推出 Apps Script 這麼神奇好用的東西，透過它可以搭配 Google 的服務實現各種「辦公自動化」。
這麼有趣的服務，令人不禁想要天馬行空的運用它，究竟我們可以拿 Apps Script 做什麼事情呢？
（本文同步發佈於 Medium。）
如前面所述，在思考 Apps Script 可以拿來做什麼時，忽然想起前一陣子研究 Jira service management 所注意到的一個功能——Customer Portal。簡單來說 Customer Portal 就是一個面向使用者的單一窗口與入口，假設今天是 IT/MIS 部門在使用 Jira service management，那麼 IT 部門就可以利用 Customer Portal 建立一個給一般員工使用的「IT 問題回報表單」。假如員工有各種 IT 問題，就填寫該表單，IT 部門則會從 Jira service management 得到員工回報的問題資訊，根據資訊開立 Ticket 並分配給工程師處理。IT 部門除了可以從 Customer Portal 得到表單提供的資訊，甚至還能夠設定當員工填寫了表單的某些選項時，就直接觸發事先準備好的自動化腳本，直接自動處理某些 IT 問題。
（Jira service management 的 Customer Portal。）
Customer Portal 這麼棒的功能，真希望 GitLab 也能擁有，但很可惜目前只能自己打造。所以就讓我們參考上面那篇文章，利用 Google 表單 + Apps Script + GitLab 試著快速搭建一個陽春版的「IT 問題回報表單」。...
（活動延期至 2021/11/24，已順利舉辦！） （非常可惜，因為 COVID-19 忽然爆發，活動已延期暫緩。看著當時寫的這篇宣傳文，真是百感交集。）
下個月 5/27、5/28 即將舉辦 DevOpsDays Taipei 2021，這次的活動場地一樣在大家熟悉的老地方「臺北文創」。由於 COVID-19 疫情的緣故，今年的講師群幾乎清一色都是國內講師，活動的規模也縮小至 1 天半，即 5/27 下午舉辦「開放空間會議」，5/28 為一整天的研討會。
（本文同步發佈於 Medium。）
活動介紹 今年是自 2017 年以來，第四次舉辦 DevOpsDays Taipei， 雖然今年活動規模縮小，但活動的豐富度依然不減。
開放空間會議 （截圖來自 FB 粉專，2019 年 Open space 的盛況。）
首先，按照慣例今年一樣會舉行大受好評的「開放空間會議」（Open Space Technology），時間會安排在 5/27 下午 13:00 ~ 16:30。
想當初 2017 年時，籌備小組一直很擔心與煩惱 Open space 到底該如何進行，擔憂會不會白白準備了場地與設備，但最後根本沒人願意額外花費一整個下午來參加一個沒有講師沒有議程的交流活動。
然而 2017 年的經驗徹底地跌破了我們的眼鏡，當年有超過一半的購票者願意在聽都沒聽過的狀態下，參加 Open space。那一年的經驗，讓籌備小組徹底地感受到 Open space 的魔力，原來人們是有辦法在很短的時間內，即產生共識、連結與認同，原來深度的經驗交流與分享可以發生的如此自然與順暢，以及原來人們並不是抗拒交流，也許只是習慣了「聽講」或者人們只是欠缺一個合適的「交流場域」。
（截圖自 FB 粉專，2017 年的 Open space 盛況。）
「開放空間會議」就是一個如此神奇、充滿魔力的「交流場域」。如果你已經確定報名參加 DevOpsDays Taipei 2021，還請千萬不要錯過 Open space。請帶著你自身的經驗、你在職場上遇到的困難與疑問、以及一個開放的心，來到 Open space 與其他人進行交流，這個下午也許你有可能會獲得超乎你想像的收穫。...
2020 年，因為爆發 COVID-19 疫情的緣故，世界各地許多的研討會都被迫中止舉辦，當時 DevOpsDays Tokyo 2020 也受到影響，被迫臨時中止。在疫情肆虐一年之後的 2021 年 4 月，DevOpsDays Tokyo 再次出發，這次以線上、線下同步進行的全新形式回到了眾人面前。（當年 DevOpsDays Taipei 2020 也同樣受到 COVID-19 疫情影響，在不斷延後舉辦與籌備事宜之後，最終也是決定中止舉辦。）
【補充】當時 DevOpsDays Tokyo 決定中止活動的事情，可以參考這篇 Blog 記錄 DevOpsDays Tokyo 2020 中止の経緯
在 DevOpsDays Taipei 2019，台灣這邊邀請了日本的 DevOpsDays 組織者（Organizer）與講師來台交流，今年則是日本的組織者邀請我們以線上的方式參加 DevOpsDays Tokyo 2021。本文就以簡短的文字紀錄 4/15、4/16 這兩天透過線上參與 DevOpsDays Tokyo 2021 的部分見聞。
（本文同步發表於 Medium。）
活動形式與大會運用的各種線上服務 （大會公告，活動將會採取線上、線下同步進行。）
DevOpsDays Tokyo 2021 採取線上、線下同步進行的形式舉辦，但由於疫情的緣故，很多講師也是採取遠距的方式進行演講。
即便是日本當地的講師，很多也是透過遠距的方式演講。有些演講會有多位講師以遠距的方式同台分享。所以有時在演講正式開始之前或結束之後，在不經意之間還可以聽見講師們在互相聊天。
如果講師是遠距演講，在線下的場地，就會將遠距的畫面投影給線下的參與者；反之，如果講師是實際來到現場分享，則會由線下將現場的講師及簡報畫面提供給遠距的參與者。
而 DevOpsDays Tokyo 2021 這次採用的遠距工具是 ZOOM。由於活動議程分為三軌同步進行，因此總共開了三個 ZOOM 會議室，參與者需要自行按照議程時間表，進入不同議程的會議室。
DevOpsDays Tokyo 2021 有英文講師，而大會很貼心的聘請了即時口譯員，因此在英文演講的時候，該議程的 ZOOM 會議室會多出一個「語言」選項。這是 ZOOM 的一項貼心功能，如此一來日本的與會者即可切換至 Japanese 聆聽口譯員翻譯的日文，反之當日文與會者在提問時，英文講師即可切換至 English 聆聽口譯員翻譯後的英文進行回覆。...
本文將說明如何透過 GitLab CI + JMeter 實現小規模的 Load testing。
（本文同步發表於 Medium。）
操作步驟 先準備一個能夠操控 Container 的 GitLab Runner，gitlab.com 的使用者可直接用官方提供的 Shared runners。
站在巨人的肩膀上，我們要借用 justb4/docker-jmeter 這個優秀的 GitHub 專案，用它作為基底。
【補充說明】justb4/docker-jmeter 的作者已經寫好一個立即可用的 Test Plan 並搭配變數和幾個 script，也有易讀易懂的文件。因此如果你只是想要立即使用 JMeter 執行小規模的 Load testing，它只需要稍微微調就可以直接在 local 環境中拿來運用。
先將此專案 import 至 GitLab。由於是公開的 GitHub 專案，所以 Import project from 我們直接選擇 Repo by URL 並填入 GitHub 的 Git repository URL 即可順利 Import。 （等待 Import 動作執行完畢。）
由於 justb4/docker-jmeter 是設計用來直接拿來使用的，因此我們要稍作微調，讓它變成適合我們放在 GitLab CI 的模樣。調整的方向有 2 個：
修改 Test Plan，讓我們可以用 Variables 動態調整更多的 Load testing 參數。 讓 Variables 可以透過 GitLab CI 的各種方式輸入，方便以各種測試參數進行 Load testing。 決定好方向之後，開始實施客製作業。首先修改 Test Plan (....
在先前的文章，艦長曾說到 GitLab CI 的一項缺點，即是我們無法輕易的在 Local 環境運行 GitLab CI，往往需要反覆修改 .gitlab-ci.yml、送出 Commit 並等待 CI Pipeline 顯示出執行結果。這冗長又反覆的過程實在是為規劃 CI Pipeline 及撰寫 CI Job 帶來困擾，也大幅拖慢針對 CI Pipeline 本身的測試與驗證速度。
然而，這項長久困擾 GitLab 使用者的困擾，似乎浮現了一線曙光！為我們帶來希望的即是名為 glci 的工具。
（本文同步發表於 Medium。）
TL;DR glci 目前還在 v0.4.3，尚未進入 v1.0，是個 2021/2/17 才開始沒多久時間的年輕工具。因此尚無法在 Local 完整的還原 GitLab CI 的所有功能與行為。
但我必須說，能在 Local 執行 .gitlab-ci.yml 中的 CI Pipeline 與 CI Job 實在是很有吸引力的一件事，希望 glci 能持續發展下去，有興趣的朋友除了試用之外，不妨也考慮考慮發揮一下開源精神為此工具貢獻己力吧！
試用記錄 以下僅記錄這次試用過程的各項操作。
根據 README 的簡短註記，glci 可透過 yarn 安裝，所以先在 mac 安裝 yarn。
# macOS 使用 Homebrew 安裝是最省力的
brew install yarn 接著用 yarn 安裝 glci...
使用者在初次踏進 GitLab CI 的世界時，通常按著官方文件一步步照做，多半不會遇到什麼問題。唯獨有一項東西有可能讓新手產生較大的疑惑，那就是該如何選擇 Executor。
目前在官方文件上已經有提供了一份 Compatibility chart 幫助使用者選擇 Executor。本文就讓艦長也針對 Executor 表達一些看法吧！
（本文同步發表於 Medium。）
GitLab Runner 與 Executor 的關係 首先，讓我們先來解釋 GitLab、GitLab Runner 與 Executor 的關係。
讓我們拆開來說明，先從 GitLab 與 GitLab Runner 的關係開始。
如上圖，我們都知道 GitLab Runner 是用來幫助我們執行 CI Job 的工人，而 GitLab 就是這些工人的老闆。老闆（GitLab）會去查看需求單（.gitlab-ci.yml）建立一張又一張有先後順序的工單（CI Pipeline），而每一位工人（Runner）則是每隔固定的時間就去詢問老闆（GitLab）現在有分配給自己的工作（CI Job）嗎？現在自己應該做哪一項工作？工人拿到工作後開始執行，並且在執行過程中將處理進度即時填寫在工單上。
到這裡為止，大部分的人都不太會有什麼問題，讓我們接著說明 GitLab Runner 與 Executor 的關係。
前面我們將 GitLab 與 GitLab Runner 比喻為老闆與工人，那麼 Executor 是什麼？是工人的工具嗎？艦長覺得與其說是「工具」，Executor 反倒更像是工人的「完成工作的方式」或「工作的環境」。
舉例來說，就像我們都曾聽過的都市傳說，據說在國外有某知名企業的工程師，偷偷將自己的程式開發工作遠距外包給印度工程師完成，藉此實現上班摸魚打混還能取得高績效表揚的神奇故事。當然偷偷把正職工作私下外包是不正確的行為，但在這個故事中，這就是這位工程師「完成工作的方式」；同理用嘴巴命令別人做事、自己苦力的土法煉鋼、善用自動化工具或高科技工具輔助、遠距連線工作⋯⋯這些都是不同的「完成工作的方式」。
按著上面的比喻，依據你選擇的 Executor 決定了 Runner 將會採用何種「方式」及在哪個「工作環境」來完成 CI Job。
因此我們可以明白，這意味著身為老闆的我們，很可能需要聘雇多位不一樣的工人。舉例來說，炒菜煮飯這種工作，我們就會安排給在廚房工作的廚師、闖入民宅開寶箱這種工作，我們就會安排給 RPG 遊戲中的勇者。根據不同的 CI Job，我們有可能需要準備設置了不同 Executor 的 Runner 來因應。...
這則一樣是從工作筆記中撈出來的舊筆記，重新整理後釋出在部落格分享。
對於「密碼管理器」觀望了很久，一直在考慮要不要使用它，最後看了這篇《為什麼今天就該開始使用密碼管理器》之後，覺得作者說的很有道理，我們應該用一套正規、有加密、有一定安全防護的「密碼管理器」來管理密碼；同時由於團隊協作的需要，難免會遇到必須共用帳號密碼的情況，故確實需要一個合適的服務來管理密碼。於是當時稍微花了一些時間比較了幾套常見的「密碼管理器」，最後在參考該文章的介紹後，選擇試用了 LessPass 與 Bitwarden 這兩套工具。
（本文同步發表於 Medium。）
LessPass LessPass 在當時號稱是一個全開源（Fully open source）的軟體，你可以自行架設服務，也可以註冊使用官方維護的雲端服務。 實際試用之後，第一時間覺得 LessPass 的運作邏輯跟一般想像中的「密碼管理」不太相同。該怎麼說呢？當下使用的感覺是 LessPass 與其說是幫我們集中儲存與管理密碼的「密碼管理器」，正確來說它更像是一個「密碼產生器」。
也就是根據你輸入的「網址」、「帳號」、「主密碼」、「密碼強度與亂數的設定值」，它會幫你產生出一組「高強度的密碼」，於是你可以使用這一組密碼去註冊其他需要登入密碼的服務。
接著當下次需要輸入密碼登入某個服務時，你只要能在 LessPass 輸入正確的「網址」、「帳號」、「主密碼」、「密碼強度與亂數的設定值」，LessPass 就會再次幫你產生出相同的「高強度密碼」，讓你可以複製貼上，順利登入服務。 （如上案例，根據「網址」、「帳號」、「主密碼」、「密碼強度與亂數的設定值」，即可產生出一組獨一無二的「高強度的密碼」。）
看到這裡，你一定會想說「這也太麻煩了，我光是記憶密碼就夠累了，現在還要記憶這麼多組變數！？」，對此 LessPass 的解決辦法即是 LessPass Database。
因此不論是 lesspass.com 提供的雲端服務，或你自行架設的 LessPass Database Server，其實最主要的功能都是用來幫你儲存各個服務的「網址」、「帳號」、「密碼強度與亂數的設定值」，方便你下次要「產生」密碼時，可以免去輸入這些欄位。也就是說 LessPass 並不是直接儲存「密碼」本身，因此我才會說它本質上更像是一個「密碼產生器」。
LessPass 有 Chrome 的擴充套件可以安裝，方便使用者可以快速使用。 目前 LessPass 在 GitHub 上的 Readme 已經沒有直接寫明如何 Self Host your LessPass Database，並且 install-lesspass.sh 這個安裝腳本也已經在這個 Commit 中將其移除了。
因此如果想要自行架設 LessPass Database，可以自己研究一下現行版本的 docker-compose.yml，嘗試用 Docker 架設。
艦長當初是參考舊版本的 Readme，並對照前述的 install-lesspass.sh 及 docker-compose.yml 來架設的。但就如前述這些資訊都已經有些過期，只能做為參考輔助，無法保證照著做還能正常架設。 續上，再提供另一項資訊給各位參考。在上述 LessPass 官方提供的 docker-compose....