Keisei Kinjo (JC) on Keisei Kinjo (JC)'s Blog

X-GhostのインフラをAzureからCloud PF Type Aへ移行した話

Thu, 23 Jul 2026 00:42:11 +0000

会社のtech blogに記事を書きました

太陽隊2025-2026賽季回顧

Wed, 29 Apr 2026 05:41:01 +0000

we all can feel proud of what this team did, not only over the course of the entire season, but tonight as well

季後賽第一輪4:0被強大的雷霆橫掃，之後主教練Jordan Ott說道。

整個系列賽有過幾分鐘的領先可整體上沒有任何還手之力。即便是這樣本賽季還是遠遠超出了包括我在內多數人的預期。受到傷病困擾三巨頭同時在場的比賽不會超過30場，馬威，艾倫連續不能出戰。即使在這樣的情況下，賽季中無明星幹掉湖人，雙殺灰狼，絕殺雷霆，附加賽第一場惜敗拓荒者後，第二場對勇士強勢追回來都讓人眼前一亮。對太陽球迷的我來說是一個充滿驚喜沒有遺憾的賽季。特別是在經歷過去年那樣一個絕望的賽季之後。整理了下心情剛好在等飛機的時候有時間回顧本賽季的同時給教練和各個球員打個分。球員按照薪資排序，除去已經被交易或者上場時間過短的球員。

Jordan Ott: S

第一年當主教練，經驗不足能把這副天賦明顯就欠缺的牌打著麼好多半要歸功於Ott. 從騎士隊帶來的需要大量跑動wheel offense戰術，進攻明顯變得流暢，空間開闊三分機會多，少有硬解。他也不墨守成規，能用的鋒線只有兩個年輕人Fleming和Dunn，而且兩個人的三分過於不穩定，例行賽後期開啟了我從我見過的DBook, Jalen, Goodwin/Royce, Collin, Ighodaro/Williams四後衛一中鋒的極端陣容。相信每一個球員，最後時刻往往能出奇制勝帶走比賽。與此同時Grayson, Royce, Collin都打出了生涯年。

球隊文化不是一年內養成的，冠軍球隊也不是單靠堆疊球星加老牌明星教練就能實現的。Ott正在幫太陽對建立新的球隊文化。這是前面三個失敗的賽季都沒有過的。

Devin Booker: C

可能是因為沒有了KD的防守牽制力，也沒有3年前攻受平衡的陣容加持。carry全場的能力下降了不少，特別是在面對鋒線強大的球隊的時候很容易就被封死。賽季的三分命中率33%在後衛裡面算很低。期待下個賽季能夠找回狀態。

Jalen Green: B

如果沒有Jalen的爆發可能已經倒在了跟勇士的那一場附加賽。但賽季初期缺陣太長跟球隊的體系有點不兼容，跟在火箭的時期一樣組織跟傳控能力太差勁，防守也基本是漏勺。作為第二得分點太差，如果能像幾年前路威或者JC一樣作為第六人發揮一點神經刀屬性還行。做為核心還差的太遠，這也是火箭隊去年為什麼要把他當作交易的籌碼。

Dillon Brooks: S

Dillon一向以防守強硬性格更強硬出名，不是這個賽季我都不知道他的單打可以這麼強，有一段時間沒有DBook跟Jalen就是靠Dillon帶隊贏了西部強隊多次。跟DBook一樣帶個髮帶，如果不是投籃姿勢太醜甚至有點難以分辨。不僅如此他還給太陽帶來的精神屬性，整體的防守積極性。比如贏球後的賽后採訪學狼叫就能看出整個團隊氣氛很不錯。

Grayson Allen: B

兩年前有一段時間是聯盟最強神射手三分投出46% 去年開始增肌後也沒有下降多少。這個賽季下降到35%但產量來到生涯新高，在場就很穩，但缺席場次太多了。

Royce O’Neale: A

可以說沒有Royce的精準投彈式的邊線球，很多比賽在根本就拖不到最後，絕殺的幾場也幾乎都是靠他的發球。除了三分沒有Allen穩定啞火之外無可挑剔。

Mark Williams: B

以年齡來說算不錯是太陽自不躺平的Ayton之後最好的中鋒，可經常會被對面更加強悍的中鋒爆前板。同樣的問題是傷病太多，季后賽如果能出戰贏雷霆一到兩場應該還是可以的。

如果關乎到體驗，我還是選擇自己來

Sun, 01 Mar 2026 07:46:12 +0000

前段時間跟老婆聊起來，我出生於鄉下所以第一次去星巴克，居酒屋，義大利菜都是在18歲以後到了上海之後才體驗到的。她覺得不可思議，因為對她出生與首爾，這些事物早已司空見慣成了生活的一部分，甚至也回憶不起來第一次去到底是什麼時候。

一般來說體驗過一次之後就會因為邊際效應的遞減，完全沒有了第一次的新鮮感，另外經歷越多年齡越大對新鮮事物的感度也會下降。如果說人生是由體驗加總而成的，無疑去上海的上大學對我自己來說極大豐富了人生的體驗。可以說是鄉下人的精神勝利法，但這確實是出生在上海或者其它大城市的人所無法體會到的。

隨著AI或者LLM的出現體驗有被替代的趨勢，AI本質上來說是用自己的現有的認知水平來快速變現換取產出，可是提高自己的認知水平還是得花時間學習（學習本身也是體驗的一部分），AI可以加速最開始catch up的速度，但作為碳基生命的我們體驗目前看來只能自己來獲得不能簡單地複製粘貼。讓我想起了去年在Platform Engineering Kaigi 2025聽到的一個演講。

認知負荷理論で挑むPlatform Engineering：サイボウズにおけるKubernetesプラットフォームの拡大に向けて by @zoetro

「認知負荷」也就是「Cognitive」，中文應該譯作「認知負擔」或者「認知成本」。這個演講強調的是減少認知負擔的過程的真正目的是--達成更深層次的學習。並且認知負擔也是有分類的

課題內在的負擔：比如難用的UI
課題外在的負擔：比如學語法這個過程很難
學習理解的負擔：運用學會的語法來解決問題的時候的負擔

一蹴而就得到的答案雖然能削減掉所有的認知負擔，但相反會失去真正的理解。關於課題內在和外在的負擔確實應該要削減，但對於學習理解的負擔反而應該增多。套用到AI上就是，用AI來減掉課題內在和課題外在的負擔，學習理解要自己花時間去體驗。

被運作了幾百年的資本主義機器給裹挾了的我們很容易理解並相信下面這條邏輯鏈：提高生產力 → 給公司帶來利益 → 有利於自己的績效考核 → 金錢報酬/職涯發展

這套邏輯經過了時間驗證在多數情況下都最能擬合現實。迫於生活壓力或者攀比心裡開始向現實妥協，傾向於用唯一的標準來衡量事物，比如金錢，比如生產力。

但如果體驗與學習這個過程本身對我來說很有趣，那我還是選擇自己來，不想“外包”給優秀的AI

日本打工人的稅務陷阱

Sat, 27 Dec 2025 05:03:08 +0000

高投票率的老年人使用多數人暴力拖累社保，絕望的冰河世代要面對工資還沒有漲上去就要縮水，政府以公司這個中介瘋狂抽取中產階層，年輕人低薪加民粹。日本的未來看起來並不樂觀。

首先聲明我完全無意否認稅跟社保的重要性。到了年末算了一下稅金又重新學了點稅務相關的知識，想以一個打工人的身份來總結一下日本複雜的稅制以及對打工人來說有限的節稅方法。

先擺上數字比較容易理解。一個住在東京都中野區的普通上班族A，拿著略高於平均水平的年收入 500萬yen，無撫養，沒有車，工資的50%用於租房以外的消費。

舉個例子

那麼A在2025年這個要交的稅是 39.03% 這還是在實行減稅並假定A不喝酒不抽煙不開車的情況下，如果沒有還會高出很多。

這裡的 39.03% 是怎麼算出來的呢，拆開看看。需要繳的稅大概有以下幾種，太多的話比較複雜，只寫了比較常見的。

厚生年金
健康保險
雇用保險
所得稅
復興稅
住民稅
消費稅

從社會保險（年金跟保險跟健康保險）開始算起比較容易理解，因為社會保險是用收入來計算的，稅是用所得（從收入扣掉必要的經費）來計算的。

厚生年金

稅率是18.30%
月收入是416,666屬於410,000那一檔
按照自己出一半，公司出一半的原則那麼一年的厚生年金是 410,000 * 0.183 * 0.5 * 12 = 450,180

健康保險

根據協會稅率會不同，以［ITS］関東ITソフトウェア健康保険組合為例，稅率是9.50%
按照自己出一半，公司出一半的原則: 5,000,000 * 0.095 * 0.5 = 237,500

雇用保險

稅率0.60%
5,000,000 * 0.006 = 30,000

所得稅

給與所得控除: 5,000,000 * 0.2 + 440,000 = 1,440,000
- 可以理解為打工人的經費，只不過這個經費是被釘死的
基礎控除: 680,000
- 需要通過「合計所得金額」來算出。所得是 5,000,000 - 1,440,000 = 3,560,000
社會保險控除: 450,180 + 237,500 = 687,680
所得稅
- 課稅部分: 5,000,000 - 1,440,000 - 680,000 - 687,680 = 2,192,320
- 稅率 10%外加97,500的控除
- 所得稅 2,192,320 * 0.1 - 97,500 = 121,732

復興稅

所得稅的2.1%: 121,732 * 0.021 = 2,556

住民稅

基礎控除縮水為: 430,000
其餘不變
住民稅
- 課稅部分: 5,000,000 - 1,440,000 - 430,000 - 687,680 = 2,442,320
- 稅率: 10%上下，這裡以10%計算
- 住民稅: 2,442,320 * 0.1 = 244,232

上面全部扣完，A還剩下5,000,000 - 450,180 - 237,500 - 30,000 - 121,732 - 2,556 - 244,232 = 3,913,800 還需要計算消費稅

GKEでrollout restartする際に起きる503エラーを解消した

Wed, 12 Nov 2025 08:33:24 +0000

前日、GKEでdeploymentに対してrollout restartを実行すると、10s前後の503エラーが発生する事象に気づいた。呼び出し側でエラー処理が実装されているため大きな問題ではなかったが、オンプレのクラスタでは同じ事象が発生しないため、原因を調査した。

環境

GKE: 1.34.1-gke.1829001
Networking: Gateway API

再現

以下のスクリプトを実行させながら、kubectl rollout restart deployment/your-appを実行する。

START=$(date +%s.%N)
while true; do
 curl -s https://your-app.example.com/
 END=$(date +%s.%N)
 ELAPSED=$(echo "$END - $START" | bc)
 echo -e "\nElapsed time: ${ELAPSED}s"
 sleep 0.1
done

rollout restartをするタイミングで、10s前後、503系のエラーが起きることを確認できる。

Elapsed time: 21.341049000s
OK
Elapsed time: 21.530590000s
OK
Elapsed time: 21.730951000s
upstream connect error or disconnect/reset before headers. reset reason: remote connection failure, transport failure reason: delayed connect error: Connection refused
Elapsed time: 21.938160000s
upstream connect error or disconnect/reset before headers. reset reason: remote connection failure, transport failure reason: delayed connect error: Connection refused
Elapsed time: 22.135801000s
upstream connect error or disconnect/reset before headers. reset reason: connection timeout
Elapsed time: 26.838277000s
upstream connect error or disconnect/reset before headers. reset reason: connection timeout
Elapsed time: 31.532648000s
OK
Elapsed time: 31.740313000s

`503 upstream connect error or disconnect/reset before headers`

処理中のリクエストがあるにもかかわらず、backend serviceが削除されるとこのエラーが発生する。 preStop hookを追加することで解消できた。

英文在日本Tech Conference的用武之地

Sun, 28 Sep 2025 04:27:31 +0000

因為中二病或是僅僅因為不好學，高中的時候英文不及格是家常便飯。大學後也被順理成章地分到級別最低的一檔英文班，曾被英文老師嘲諷「你們能坐在這裡，數學成績應該都不錯」。

10年前來日本留學後才猛然發現：英文不好學術研究就難以順利進行，參加國際學會也必須使用英文發表，另外想跟來自其他國家的留學生交流也只能講英文。因此我不得不在學日文的同時被動提高自己的英文水平。很多人說學日文後因為片假名的緣故英文會倒退，但從我的經驗來看自學日文反而讓我理解了學習語言的通用方法，即「記住最低限度的語法與單詞，在試錯中收集反饋，用反饋來理解下一步應該要學什麼」。完全沒有想到，在這個過程中當年不拿手的英文成了我的興趣之一，到今天為止每個禮拜都去同一間咖啡店參加英語會話並且已經持續了6年。

近幾年因為工作的緣故，經常有機會參加日本的Tech Conference，主辦方一般都會邀請世界級別的名人或著大佬來進行最開始的Keynote演講。但問題是參加的日本程序員多半不會英文或是不敢講英文，從 Google Cloud Certification 最開始只支持英文和日文（現在應該也是，懶得查了）就能看出日本程序員整體的水平。所以主辦方基本都會貼心地為參加者準備好同聲傳譯，每個座位都配備有接收器和耳機。根據我最近參加的三個不同的Conference的經驗，會英文的優勢其實不在於不需要戴那個同聲傳譯耳機，而是在結束後的「懇親会」可以跟演講嘉賓一對一聊天幾十分鐘，請教問題並交換聯繫方式，屢試不爽（n=3）。因為基本上英文不好又害羞的日本程序員不會跟你競爭。如果是在國際性的Conference，類似這樣的機會恐怕很難得，演講者多半沒有時間跟你一對一聊那麼久。

英文這個工具，總會在意想不到的地方派上用場。就像著名程序員原子能說的那樣，英語才是最好的計算機語言。

There are always people who think for you

Sat, 20 Sep 2025 05:28:59 +0000

所有忘記在元宇宙墳頭上香的阿貓阿狗們在AI時代又打滿雞血復活了。

「你不用這個AI新工具你就會跟不上時代然後被AI取代」

「學習新知識沒用因為AI學的比你更快」

「競爭對手已經開發出AI賦能的新功能了我們不抓緊就會被淘汰」

「你寫的CLI工具沒毛用我們應該讓開發者跟AI直接用自然語言交互」

「這個AI工具在歧視中國跟中國用戶」

從職場，推特，YouTube不斷受到這種論調的轟炸。互聯網泡沫時期我還沒有記事，身處於AI泡沫之中多少能想像當時的情境。

其實也不一定要身處於泡沫時期，衰退蕭條時期也是一樣，從十幾年前開始我所居住的日本地鐵裡比較常見的脫毛廣告喜歡用的一種利用恐懼或著從眾心理的營銷手段。諸如

「你不開始脫毛你就沒有機會接觸到優秀的異性」

「脫毛能變美」

「別人20歲都開始脫毛了就你沒有」

云云，他們的用語更加巧妙沒有我講的那麼直接。主要針對女性，最近可能市場飽和了，男性脫毛也多了起來。一開始我以為沒人會相信這種拙劣的廣告，但能持續這麼多年自然是有利可圖，你情我願。

甚至不一定要是脫毛無良廣告，日本的部分年輕人收入跑不過通脹生活越來越緊張，甚至買大米都要精打細算。房間裡的大象明明是吸年輕人血去填老人窟窿的這個無法持續的社保系統，本質原因是政府短視，決策失誤還有人口減少的趨勢無法避免。而多數人卻相信是外國勞動者帶來的問題，國家給外國人發錢搶佔了他們的資源。甚至讓某橘色政黨在7月的參議院選舉中投機成功。

總有人代替你思考，他們創造需求，製造焦慮，劃分敵我。科技飛速發展，但人類從「烏合之眾」出版的19世紀末開始（或著更早）並沒有進步。消費了過多的快餐信息，多巴胺分泌次數暴增，系統二已經開始退化。如何才能獨善其身？

我自己的炒股錯覺

Mon, 28 Jul 2025 12:59:31 +0000

東京飛往上海的飛機晚點至少2個小時。在候機的同時回看之前寫的一篇博文叫打工人炒股的錯覺，當時的我自信地得出了結論：「股黃金期貨外匯加密貨幣一律不碰」一年三個月後來看我自己也沒有履行這個結論，中間還是經不住誘惑投資了幾隻個股，甚至在4月川普宣布解放日關稅清單的時候出於恐懼賣掉了一部分持有很久的ETF。

跟很多人一樣我在金錢的利益誘惑與來自社交媒體的噪音輸入之下，並沒有經受住誘惑。甚至在抄底日股成功了兩次之後，開始覺得自己能跑贏標普500，然後開始每天花時間刷新各種證券APP有模有樣地分析圖表，可回頭看看作為玩家參與到這場需要一點點門檻的合法大型賭博，並不開心也完全談不上樂趣，但卻付出了不少時間。

真的有必要那麼貪婪跟著急嗎？錯過了行情無所謂天塌不下來，通勤地鐵或者旅行的飛機遲延一點無所謂不在乎那幾個小時，讓自己因為這些小事變得焦躁不安很不划算。

自宅Kubernetesクラスタをk3sからkubeadmに乗り換えた

Wed, 28 May 2025 10:04:13 +0000

2023年年末にk3sを使ってRaspberry Pi 4と10年位前に買った超古いノートPCで自宅Kubernetesクラスタに構築した。構築はめっちゃくちゃ楽だった（数分間で終わる）が、k8s標準のものではなく、addonsや新しいOSSを試す際に謎のバグが多発してdebugも大変だったので、改めてkubeadmを使って構築することにした。クラスタが崩壊したときの復旧を楽にするために、手順を残しておく。もし検索エンジや生成AIの参考リンクなどでこのページにたどり着いた方がいたら、何かの参考になれば嬉しい。

手順

container runtime (containerd)をインストール
kubeadm, kubelet, kubectlをインストール
kubeadm initでcontroller planeを構築
kubeadm joinでnodeをクラスタに追加

当たり前のことだが、container runtimeとkubeadm, kubelet, kubectlはcontroller planeとworker nodeの両方にインストールする必要がある。

環境

Raspberry Pi 4

CPU: Cortex-A72, aarch64, 4 cores
Memory: 8GiB
OS: Debian GNU/Linux 12 (bookworm)

Mini PC

CPU: Intel(R) N97, x86_64, 4 cores
Memory: 8GiB
OS: Ubuntu 24.04.2 LTS

古いノートPC

CPU: Intel(R) Pentium(R) 3805U @ 1.90GHz, 2 cores
Memory: 8GiB
OS: Ubuntu 22.04.5 LTS

Raspberry Piをcontrol planeにして、残り2台をworkerにする。

container runtime (containerd)をインストール

他のcontainer runtimeでも良いが、無難にcontainerdを使うことにする。今後はCRI-Oで遊んでみるかもしれないが、Docker Engineはたぶん使わない。

用極簡主義來健身

Sun, 11 May 2025 10:05:35 +0000

諸如健身，學習英語之類的活動，速成基本無效，需要長期堅持才能看到成果。但包括我在內多數人很容易半途而廢。經過數次失敗於總結教訓後，這次健身我持續了半年，每個禮拜去4到5次，健康狀況跟身材都有了明顯改善。我發現對抗半途而廢，「極簡主義」很實用。

我們要承認你我中的大多數人是沒有意志力的。所以走增強意志力的路線雖不能說完全不可能但難度不小，更理想的方法應該是不用強大的意志力也能長期堅持。這時候極簡主義中的一個思想就很有用：儘量「不做選擇」或者說「只做簡單的選擇」。

先來想一下去健身需要做的選擇

去什麼健身房
喝不喝蛋白粉
氧氣水需要嗎
需要帶什麼衣服去健身
什麼時候去健身
如何選擇器械，需不需要教練
…

沒去之前看到這些選擇就覺得望而卻步了，即便是堅持了一段時間之後也會覺得麻煩慢慢就放棄了。仔細想想很多選擇其實是不用做的，除非想追求極致，但那是堅持下來之後的另一個階段這裡就不做討論了。

健身房選擇

在我看來就一條原則離家或者公司近，所有追加option都不要。那種又是全球連鎖，又提供最新器械的都沒用，最終去的只會是同一間。

蛋白粉選擇

蛋白粉對於增肌來說肯定有幫助，但是從選擇開始，到購買，儲存，沖泡，洗杯子，晾乾。一次還好，每次去健身房後都要做這一整套動作就太過於麻煩了。而且不認真洗那個杯子真的會很臭。所以很簡單，不喝，或者稍微增加日常飲食的優質蛋白質攝入，偶爾去便利店或超市買散裝的就足夠了。

氧氣水選擇

氧氣水有種智商稅的感覺，我也懶得去查證了，沒那閒工夫喝。即使有用付出的成本也過高。

服裝選擇

為了防止受傷基礎的護具是必須的，但服裝其實沒那麼講究，緊身之外問題都不大。健身專用的服裝買來也會忘記帶，而且除去健身之外也毫無用處。

健身時間選擇

什麼時候去其實無所謂，但儘量做到甩手就能去，或者減少去之前需要做的準備工作，時間固定的話比較能容易形成習慣。另外快步走到健身房就是有氧運動，當作熱身也行。這能有效縮短去健身房的時間，每次的時間縮短了堅持下去也就更容易。

器械，菜單，教練的選擇

教練其實也不需要，網上的教程都說的很好只是沒辦法給你第一時間的反饋，習慣之後基本就能理解教程中所說的注意事項。菜單也越簡單越好，大多數部位練到了就行，訂製菜單AI很在行。

另外要儘量縮短健身時間，工作日擠出一兩個小時難度很大，但30-40分鐘應該還是可以的。比如最開始儘量不做自由重量只選擇機械式器材就行。自由重量雖然效果好，但找啞鈴片，放啞鈴片，收啞鈴片很麻煩也費時間，再者對於新手來說容易受傷。還有就是發現前面有人在用就立馬換項目，找其它可以代替的器械，功能類似的器械很多不用糾結於每次完全一模一樣，有的大哥大姐一上去二三十分鐘不下來，等他們練完太花時間。

總結

去離家最近的健身房，不喝蛋白粉氧氣水，基礎護具就行，縮短健身時間。即便意志力不強也比較容易能長期堅持，其實跟二八原理類似用20%的努力來取得80%的健身成果。切記不要想著用數字量化一切，今天比昨天好或者跟昨天一樣就足夠了。又不是考試也不是KPI考核，最關鍵的是能夠長期堅持，時間到了自然會看到效果。而且如果哪一天突然對健身或者運動本身產生興趣了再倒回去考慮之前被略過的細節就行。相信有了經驗之後會有完全不一樣的視角。

好像類似的方法運用到英文學習也是一樣的，有機會可以講講。

Phoenix Suns

Sat, 10 May 2025 00:00:00 +0000

從2005年開始看NBA，跟大多數人一樣最開始因為姚明的緣故自然而然成為了火箭球迷，姚明退役之後就基本沒有太關注最多也只是在季後賽偶爾看看新聞或者閒著沒事才會看比賽。

後來哈登來到了火箭之後火箭魂復燃，中間CP3又加入火箭。但不巧跟強盛的宇宙勇同處於一個時代，即便2018年完全搞了一套反勇士的豪華陣容，但CP3受傷以及火箭史詩一般的拉稀命中率導致G7失利。2019年捲土重來又幾乎以同樣的方式再次倒在勇士面前。當時邊寫論文邊看比賽，氣到想把電腦砸爛並發誓再也不看NBA。

但打臉總是很快到來，2021年CP3來到太陽，疫期間週末沒事做就開始關注這一支已經落寞很久的年輕球隊。這次還拉上了老婆（當時的女朋友）一起看比賽，兩人同時成為了太陽的球迷。本以為這支球隊距離奪冠的距離還很遠，但竟然還馬上就看到了希望，只是後來跟火箭時期的劇本很類似

21年 CP3, Booker, Ayton, Mikal, Crowder 總決賽失利，但陣容均衡充滿活力
22年首發Crowder換成Johnson，例行賽第一然後倒在西區半決賽，還跟獨行俠上演的了另一場拉稀的G7，也就是The Game，現在聽到Dinwiddie這個名字我還是會頭皮發麻
23年 Mikal, Johnson換成KD，依然倒在西區半決賽，但跟後來的冠軍金塊打得有來有回，並且在太陽主場看到了Booker的爆發
24年梭哈式交易CP3被換成Beal, 制服組丟掉未來追求現在。陣容完全被克制第一輪被灰狼橫掃，而且當時的Ant還沒有進化為完全體
25年賽季初西部第一讓人看到希望，但經歷換中鋒KD受傷以及更衣室的一系列問題之後連play-in都沒的打

這5個賽季多半的比賽我都看了，最絕望的甚至還不是輸球，Beal手握霸王條款而且在菲尼克斯已經置業同意被交易的可能性很低，所以薪資空間的問題完全得不到解決。另一方面因為前兩年的賭博式交易選秀權早就被全被丟出去了，馬上宣布重建也不可能。看了出局後CEO的採訪，竟是場面話看不到一點對籃球的熱愛。現在比較現實的解法是就是交易KD跟Booker，特別是把Booker交易到季後賽因為貧攻剛剛輸給勇士的火箭。這樣對於當下的太陽，火箭以及Booker個人來說都是不錯的選擇。但夏天會發生什麼，沒人知道。

希望一切如願吧🚀

Meta Blog

Sun, 27 Apr 2025 00:00:00 +0000

還沒有寫把博客遷移到這裡的原因，那就在地鐵裡開始動筆寫一篇博客的博客 Meta Blog

曾經用過的博客服務

QQ空間
新浪博客
Lofter
Qiita
Zenn

最開始接觸到博客服務是QQ空間，那時候Blog這個詞才剛剛被翻譯為博客或者部落格，已經忘了是2006年還是2007年。第一次擁有「個人網站」可以簡單的上傳文字和照片，小學生的我自然是很新奇。

開始寫真正意義上的博客是2009年上高中之前。在BBS認識的朋友很多人都有自己的博客於是跟風開了新浪博客，文字很幼稚但一直堅持寫到了大學一年級入學之後，還因為新浪博客認識了至今從未謀面的同濟大學的學姊。

大二之後把新浪博客遷移到了网易的Lofter因為UI看起來比其他的服務好看，當時幾乎所有的課都逃掉就算去了也是坐在最後一排，埋頭於自己的興趣（日語，吉他，長跑）。有時間就用文字紀錄下了自己的一些感想，幾乎兩個禮拜左右就能寫一篇。從最開始到大學畢業前關停，只有一位讀者，我也是他博客的唯一一位讀者，可以說是這一位讀者陪伴著我學會了吉他跟日語。

再次接觸到博客已經過了5, 6年，工作後想把自己的一些嘗試跟想法分享給他人，就開始在Qiita（差不多等價於中國的CSDN）跟Zenn上寫一些技術相關的文章。這也是第一次嘗試用日文寫博客，沒有想像中難跟Master時期寫的報告差不多，因為技術文章的用詞相對單一表達也不複雜。

平台帶來了便利（比如SEO），但相反也有諸多的限制，某些國家甚至還有言論審查。但無可厚非，就像在註冊帳號的時候沒人閱讀的超長協議書裡面寫的那樣，免費使用別人的服務的時候就默認自己已經成為了別人的商品。

所以去年年初開始最終決定self-hosting了現在的這個博客，並且同時關停了其它博客帳號。做的事情很簡單，把Markdown文件傳到GitHub, 然後通過static site generator hugo生成網頁之後部署到Vercel上。我更需要一個相對自由，好玩， 能夠自我滿足的博客。不需要複雜的社交功能，不需要頻繁地查看或者回信，想看的人自然會看，想用什麼語言寫就用什麼語言，沒有KPI不想寫就完全不用寫，任何人都可以看。

一個牽強的比方：就像是爵士樂一樣。

生成AI時代のSRE【サポーターズCoLab】に登壇した

Fri, 11 Apr 2025 00:00:00 +0000

4月3日、生成AI時代のSRE【サポーターズCoLab】に登壇しました。

資料を公開します。

髮小

Mon, 07 Apr 2025 00:00:00 +0000

在社交媒體上，除了少數面基過的之外，網友大家最多也就是點讚之交，然後從隻言片語中構建著對彼此虛擬的印象。自然而然地就會傾向於臉譜化或者符號化對方的形象，比如左派右派、女權男權、身分認同、小粉紅、網右、精日。然而現實中人是更加複雜，多元跟矛盾的。觀點相近不是成為朋友的必要條件，當面對具體的人的時候去談論宏大而又空洞的主義意義並不大，我也是最近兩年，特別是30歲之後才理解的。

小學在英文補習班上認識的朋友（髮小）前段時間來日本旅遊，在我家住了一個禮拜。帶著第一次來的他上山下海看櫻花，走在東京街頭說著所有人都聽不懂的方言，有種時空錯亂的感覺。看到他的拍照、取景找點的水平遠遠超過我這種門外漢，讓我想起了2017年。

那年他剛剛畢業，因為對學校裡學專業課程相關的工作完全提不起興趣，更想從事cosplay攝影，當時急需要一筆錢去某大城市參加培訓班。但苦於沒有錢，剛剛交換留學回來的我想都沒多想就把剛剛從上海市拿到的留學獎學金大半借給了他。酒桌一別，我也沒有想到因為疫情等諸多因素，時隔7年才再次見面。現在他雖然沒有完全靠攝影為生，但週末業餘時間能接到項目賺點外快的實力還是有的。

晚上在我家客廳聊天。他說他堅決要買，房租房太難受了，一刻也等不了，旅行回去馬上就看房。我就跟他講現在經濟不好不適合上槓桿，最恐怖的是並不知道什麼時候是底，更別談觸底反彈。而且你們公司都裁員兩波了，謹慎點好。但他沒有要聽勸的意思，很篤定地相信這次下跌已經基本見底，再不買就又要錯過了。

他還說他堅決不會去東南亞，印度，香港，台灣等地，因為據說那邊歧視中國人而且很危險。我就跟他講，有機會還是要實地體驗一些才知道，就像你這次來日本一樣，不要妄下結論。國內簡體中文能接受到的訊息很受限並且被審查。當然第二句話沒有說的那麼明顯。

一起玩的幾天也跟著他領略到了小紅書的威力，按照小紅書的攻略走到的地方都擠滿了像是完成打卡任務的中國年輕遊客，熙熙攘攘。我為了跟他一起完成他搜索的攻略，平均每天走接近3萬步。只能跟他說第一次來心情完全可以理解，但沒必要把自己搞那麼累。小紅書上說的「必去比打卡地」是別人的想法，沒必要跟著他人的喜好去匆忙地對答案。去真正感興趣的一部分就行了，我們可以悠閒地去咖啡店或者酒吧。但他拿出了那一句難以反駁的標準答案「來都來了」

沒有試圖完全說服他，因為我知道完全不可能，也沒有必要。

但以後如果他遇到切身的困難，我想我還是會像以前一樣拉他一把。跟2017年一樣。

旅途中遇到的人們

Mon, 27 Jan 2025 00:00:00 +0000

在DeepSeek的威力之下，大即是正義模式正在崩潰瓦解，比起粗暴的資本堆疊也許這才是科學技術的進步。

看完新聞發完感慨之後，時隔多年我在農曆春節前夕登上了返回故鄉的飛機。其實已經準備好了電子書，所以就算是6, 7個小時的飛機也沒有那麼難熬。飛行途中跟鄰座的年輕人自然而然地攀談了起來。「去年大學畢業。旅遊簽證去東京參加修士入學考試。朋友們都已經開始工作或者入學。因為考試完全沒心情觀光旅行。沒有直達航班在陌生的城市轉機」所有的要素跟當年的我出奇地相似，讓我想起了因為考學的壓力大到蕁麻疹發作的2017年年初。

一個人的旅途中，總會遇到很多有意思的人和事，特別是在臥鋪列車或著青年旅館。

2007年剛上中學，在去廈門的列車上跟火車上下鋪的惠州大哥（沒記錯的話他叫希希）馬上就混熟了，之後跟他也剛剛認識的幾個大姐姐打狼人殺。具體內容早就忘記了只記得因爲我穿着一件黃白體恤於是他給我取了綽號叫大馬哈魚。這是我人生中第一次交到外地的朋友。

2012年上大學在去上海的臥鋪列車上遇到一個去浙江打工的大叔說鷹潭車站的雞腿好吃，要給自己老婆帶一個。聽聞我也感興趣之後深夜到鷹潭之後把我叫醒問我要不要買。那時候的臥鋪火車車站之間停的時間足夠跟站在月臺上的小販們買東西。遇到另一個大叔是來自紹興的生意人跟我強調了好多次有學歷才能掙大錢。

2013年從上海回程的列車上，遇到個大姐用中日雙語跟女兒講話。聽聞我在自學日語並且我們又是同鄉，馬上就開始講述她的傳奇人生，從沒有考上高中到去上海打工，到賭場輸掉30萬，到跟日企高管結婚，到日本婆婆不喜歡她，到她的女兒不想學日文，到她女兒用昂貴的化妝品給狗化妝。列車上的30個小時完全不足以讓我消化這巨大的信息量。

2014年還是在臥鋪列車上遇到了隔壁大學的同鄉學長，他家境優渥熱衷於做慈善。跟我講述了他組織的各種募捐活動以及自己對佛學的研究。

2015年西安青旅，跟老闆峰哥聊了起來，他說他嚮往自由，喜歡跟形形色色的人聊天，大學畢業後就離開家鄉在西安大理等地輾轉一直在開青旅。還遇到了一位退休後在世界各地旅行的天津阿姨，聽了她在世界各地旅遊的見聞，得知她的下一步計畫竟然是是去南極。她在爲此進行一系列的準備。

2016年在伊勢神宮青旅跟一個瑞士人還有日本的一家三口玩UNO，這個瑞士人僅僅學習日文幾個月卻流利到誇張學了三年的我自愧不如，甚至還跟我講比起外來語「オレンジ」來說他覺得「橙色(だいだいいろ)」這種說法更美。

2017年在上海住青旅，跟老闆白哥聊了起來，他大學畢業沒有就業一人隻身騎行了大半個中國，最後在上海徐匯區開了青旅以近乎難以維持的價格爲來上海求職的年輕人提供住宿。

雖然他們中的大多數我再也沒有見過，跟他們的小小交集，旅途也變得更有意思。就像「回憶愛瑪儂」的故事情節一樣，如果把時間拉長到無限長，「一瞬間」跟人類所能認知的「永遠」也並沒有區別。

KEDAを導入してAWS SQSキューとHTTPリクエストベースのスケーリングを実現する

Thu, 23 Jan 2025 00:00:00 +0000

会社のtech blogに記事を書きました

KEDAを導入してAWS SQSキューとHTTPリクエストベースのスケーリングを実現する

Argo CDとArgo Workflowsにおける認証・認可の設定

Mon, 16 Dec 2024 00:00:00 +0000

背景

仕事ではArgoCDでGitOpsを行っており、Argo Workflowsでバッチ処理を実行するエンジンとして利用しています。

運用初期は利用者が多くなかったため、Argo CDのSSOはGitHub Team (グループ管理)とArgo CDに付随されているDexを使用していました。また、認可設定はシンプルに保ち、Basic Built-in Rolesを利用して、クラスタ管理者にrole:admin、利用者にrole:readonly権限を付与していました。一方、Argo WorkflowsではSSOを設定せず、デフォルトのAuth Modeであるserverを使っていたため、認証が通れば誰でもバッチのログを閲覧できる状態でした。

しかし、プラットフォームの成長に伴い、機密性の高いログが増える見込みとなり、現在の運用は対応が難しくなってきました。

そこで、先日最小権限の原則（Principle of Least Privilege、必要最小限の権限のみを付与する運用方針）に従い、Argo CDとArgo Workflowsの権限設定を見直しました。本記事では、公式ドキュメントに記載されていない落とし穴や、実践してみて明らかになったArgo CDとArgo Workflows権限のポイントについて解説します。 Argo CDやWorkflows権限設定の権限設定を進める際の参考になれば幸いです。

Argo CD

先述の通り、今回の構成ではGitHub Teamでグループを管理し、OpenID Connect ProviderとしてDexを利用しています。この構成における認証・認可のフローは、GitHub Teams → Dex → Argo CD Applicationとなります。

Argo CDでは、グループごとにnamespaceのアクセス権限を設定することで、必要最小限の権限のみを付与できます。ただし、Argo CDのドキュメントRBAC Configurationの記載によると、namespaceごとに設定する場合、事前にApplication in Any Namespacesを有効化する必要があります。

デフォルトでは、Argo CDのApplicationはargocd namespaceに作成されるため、Applicationリソースを各namespaceに分割して配置する必要があります。この設定は比較的簡単な一方で、ApplicationSetのtemplateにおいてnamespaceがサポートされていないため、この方法を採用するのは現実的ではありませんでした。すでにApplicationSetによって複数のnamespaceにアプリケーションをデプロイしているため、ApplicationSetの廃止は容易ではありません。

その解決策として、namespaceごとにAppProjectを作成し、論理的なグループ化を行いました。AppProjectは、Argo CDにおいてアプリケーションをグループ化し、リソースやアクセス制限を設定するためのリソースです。以下は、その例です。

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
 name: samples
 namespace: argocd
spec:
 destinations:
 - namespace: samples
 server: "https://kubernetes.default.svc"
 sourceRepos:
 - "https://github.com/org/repo.git"

このAppProjectに対応する権限は、Dex設定用のConfigMapに定義します。

EKSにおけるNamespaceごとにCloudWatchとEC2のコスト按分方法

Wed, 04 Sep 2024 00:00:00 +0000

会社のtech blogに記事を書きました

GKEでArgo WorkflowsにWorkflow Archiveを導入する

Tue, 09 Jul 2024 00:00:00 +0000

副業先のtech blogに記事を書きました

blue/green戦略によるKubernetesクラスタ更新時にIstioの対応方法

Fri, 05 Jul 2024 00:00:00 +0000

会社のtech blogに記事を書きました

ややこしいノートアプリを捨てよう！15行のMakefileとGitで自分のノートを管理する

Sun, 23 Jun 2024 00:00:00 +0000

なぜ

最近のFancyなノートアプリが複雑になりすぎて個人利用には不要な機能が溢れています。その上、自分が書いたノートなのにローカルに保存されないため、サービス障害やインシデントが起きるとを閲覧できないリスクが高いです。

そのため、MakefileとGitだけで自分用簡易ノートを作りました。

詳細

この15行のMakefileがすべてです。↓

.PHONY: pull note journal

pull:
	git checkout master && git pull origin master

today=`date +%Y%m%d`
year=`date +%Y`
journal_path=./journal/${year}/${today}.md
name=newname

note: pull
	@mkdir -p notes && echo "# ${name}" >> notes/${today}_${name}.md && code notes/${today}_${name}.md

journal: pull
	@mkdir -p "./journal/${year}"; if [ ! -f ${journal_path} ]; then echo "# ${today}" >> ${journal_path}; fi; code ${journal_path}

ややこしいことはやっておらず、directory journal/とnotes/にmarkdownファイルを作ってvscodeで開いているだけです。

journal/
- 日記を保存するディレクトリ
- 年別に分けるためにjournal/配下に更にサブディレクトリYYYY/を生成するように実装している
- make journalを実行するとjournal/YYYY/YYYYMMDD.mdが生成される
- 日付などは自動生成されるので自ら記入する必要なし
note/
- その他のノードを保存するディレクトリ
- こちらは年別にわけてない
- make note name="hogehoge"を実行するとnotes/YYYMMDD_hogehoge.mdが生成される

Markdownはコードブロックや画像挿入の機能が備えているため、ほとんど個人のユースケースに対応できます。また、ノードアプリの画像やURLを挿入する際に使う「Markdown方言」を覚える必要もなくなります。

検索に関しては、自分が普段使い慣れているIDEの検索機能を利用すればいいので、ほとんどのノードアプリより優れていると思います。

ノートをGitHubのprivate repositoryに上げておくと、GitHubにログインできれば他の端末からでも閲覧・編集できます。モバイルから編集しづらいという問題はもちろんありますが、そもそも外にいる際にスマホをいじる時間を減らして周りの景色を楽しんだほうがいいでしょう。

最後に

シンプルなノードアプリを自作しましょう！ノートアプリを選んでカスタマイズする時間・お金があるのであれば、自分の趣味などに充てたほうがよいのではないでしょうか。

また、GitHub PagesとMarkdownで自作個人ナレッジマネジメントツールに興味のある方は筆者が2年前に書いたこの記事も併せて読んでみてください。

ご参考になれば幸いです。

香港

Mon, 06 May 2024 00:00:00 +0000

今天凌晨抵達東京，補覺到下午1點才起來本來想打開電腦做副業卻發現身體上的疲勞雖然恢復了但完全不想工作。趁着記憶還新鮮，寫一寫這幾天的直觀感受。

旅行本身

去香港之前幫朋友買東西的時候，想了想覺得名煙，名酒，手錶，奢侈品都挺無聊的。為了這些東西去打工有點蠢。物慾在得到滿足的一瞬間就會帶來空虛，之後就需要更大更強烈的刺激來填補。

而旅行帶來的體驗卻完全不一樣，跟家人，朋友，或者自己一個人，從計劃到實行到中間因爲天氣等不可抗因素而必須做出的改變與妥協，在陌生的地方體驗幾天完全不用的生活方式，過後也能從回憶中得到滿足。

幾個小貼士

在東京的話可以考慮在新宿外貨両替のインターバンク換港幣（或者其他外幣也一樣），沒有隱藏費用甚至可以比肩香港重慶大廈的匯率。但需要注意不要走錯地方，隔壁有一家沒有牌子的店匯率看上去好一點點但是會收8%的手續費。我因爲大意走錯被坑過一次
習慣了日本大車站便利的coin lockers之後會發現要在香港找個存行李的地方太難，而且價格也很貴，在中環三個箱子存了4個小時就花了260HKD
我乘坐紅眼航班沒有問題，但是女朋友顯然體力不支，下次能選的話還是不要安排那麼緊張的行程，至少去的時候可以選擇白天的航班
乘坐叮叮車（Tramways）的體驗很不錯，能近距離體驗港島的街景，甚至還能包車開Party
跟當地人交流雖然中文也沒有問題但是因爲我不會廣東話，用英文交流更加順暢
香港對寵物挺友好公共場合沒有太多限制，或者也有可能是能養寵物的人本身就很少，不用特別限制

5年之後

乘坐Tramways路過銅鑼灣，中環，金鐘等熟悉地名和街景讓我想起了2019年的那些熬夜的凌晨，連續幾天透過媒體看着前線用雨傘自製的燃燒瓶對抗裝甲車和水跑車的年輕學生們。5年後的現在雞蛋不僅沒有戰勝城牆，而且城牆還被加高加固而且更加密不透風。一邊是賣房子準備跑路的英國加拿大的香港人，一邊是覺得自己靠着低稅收跟相對較低的房價撿了便宜的“新香港人”。

禮拜天中環HSBC樓下拿着微薄薪資的菲律賓女傭們席地而坐，年輕的女孩們在跳舞，唱卡拉OK，邊喝大瓶可樂邊打牌，買賣看起來像是從內地進來的衣物飾品。幾個肥頭大耳的保安保衛着寫字樓的“國界”。顯然她們好像並不屬於港府所喜歡的“新香港人”。而在那種環境下卻依然能夠保持樂觀與積極我很佩服。

說到我自己，2018年3月宣佈廢除任期的那條新聞讓我打消回中國的念頭，2019年的反送中則是讓我堅定了從法律上脫離中國的決心。但由於跟父母溝通不是很順暢很多時候又是我先斬後奏，趁着這次旅行的機會，在酒店跟快5年沒見的父母深夜促膝長談。互相坦誠地交換了意見，父親說出了下面一句話

“我們可能接收不到沒有被管控過的信息，但是能夠理解你的決定。就像是從東德逃到西德，從北朝鮮逃到韓國，當年從內地逃到香港一樣。改變的只是時代背景，人們在做的事情沒有改變”

達成了此次旅行的目的，剛剛好目的地是5年後的香港

自作PCからUbuntu22.04開発環境構築してみた

Sat, 20 Apr 2024 00:00:00 +0000

アップルをはじめとして、最近スペックがそこそこ良いPCがわけわからないくらい高くなり、誰でも使える個人用のコンピュータというPersnal Computerの趣旨と乖離しています。独断と偏見ですが、せっかく数十万円でPCを購入したのにもかかわらず、

パーツ交換不可なので、数年後は電子ゴミになり、自然環境に優しくない
不要なソフトウェア・サービスが多い（たとえば、2022年なのに、バージョン管理非対応のクラウドサービスiCloudが大きなシェアを占めているっていう皮肉）
なんとかStoreの通知がうるさい。利用するのにアカウント（個人情報）が必要
プライバシー侵害問題
…

https://www.theguardian.com/world/2021/oct/15/apple-plan-scan-child-abuse-images-tears-heart-of-privacy

別にゲーマーではないですが、数十万払ったのに自由が奪われる感じがどうしても気に入らないので、自作PCからLinuxの開発環境を構築することにしました。

ハードウェア

秋葉原まで行く元気がなかったので、すべてのパーツはAmazonやメルカリから購入することにしました。また、PCパーツの価格変動が激しいのでkeepaのメール通知機能を活用すると簡単に低価格でお気に入りのパーツ狙えます。 https://keepa.com/

最終的に以下のパーツを買いました。

	Model	Price
Motherboard	ASUS Intel B560M-A	¥10,563
CPU	Intel Core i5 10400	¥18,943
GPU	ASUS GTX 1650-4G DUAL	¥21,500
Power	玄人志向 KRPW-BK 80PLUS Bronze 750W	¥5,535
Memory	KLEVV DDR4 2666 PC4-21300 8GB*2	¥7,002
Storage	Crucial SSD 500GB MX500	¥5,980
CPU Cooler	CPUクーラー虎徹 Mark II	¥3,400
Case	SAMA JAX-03W (second hand)	¥4,480
LAN cable		¥945
Total		¥78,348

あくまで筆者の例ですが、他のパーツに替えても全然問題がありません。パーツ間の互換性と電源容量だけ気をつけてください

打工人炒股的錯覺

Fri, 19 Apr 2024 13:00:00 +0000

趁着今天全球股市暴跌，來簡單聊聊打工人炒股的錯覺，以及我的策略。

打開推特好多人都在用中文聊炒股炒幣買房。最近跟公司同事去聚餐只要聊到炒股炒幣炒FX（拉槓桿炒外匯）或者買房，幾乎所有人都滔滔不絕，長篇大論發表觀點。而一個簡單的事實是，長期來看經濟大餅越確實是在做越大，但短期的股市漲跌取決於市場對於經濟的預期（不是實際情況，只是預期）。牛市之下，大家都能輕鬆靠著炒股短期賺到錢，但牛市永遠不可能長久，短期投資個股或對於大多數打工人來說不見得是個好的策略。

炒股好像會給我們打工人一種錯覺，會讓我們覺得我們有那麼一瞬間我們從勞方變成了資方，有機會不依靠勞動僅僅靠著決策就能在短期內賺進鈔票。不可否認確實也有人是這樣成功的，但跟書店琳琅滿目的成功學書籍一樣完全不具有任何普遍性和可再現性。而且投資跟投機其實本質上並無差別，都是某種形式上的賭博，靠著承擔一定的風險來獲利。再者，炒股炒幣花費時間精力，最終的營收不僅反應在最後的數字上，還需要考慮到時間成本，精力成本，甚至是心理成本。算上這些看不到的無形成本，炒股的收益率估計也就不剩多少了。

但是，作為打工人能不炒股嗎？

顯然完全不炒股也不可取，就連長年通縮的日本也進入了通脹時代，不炒股就只能等著資產縮水。另外，日本政府從幾年前開始學習英國的ISA推出了名為NISA的投資稅收減免政策，其實意思就是說按照現在的少子高齡化進展，以後養老金很大可能會不夠用，所以政府也想鼓勵民眾加入資本市場的遊戲。

我個人的觀點是，我們首先需要承認並考慮清楚我們的現狀

我們多數打工人是凡人不夠聰明
沒有一手信息源
運氣不可能一直好
分析公司財報大多數情況是浪費時間

基於以上現實，用免稅額度長期定投風險相對較低的S&P500等優質ETF就完全足夠了，個股黃金期貨外匯加密貨幣一律不碰，甚至不買房（跟A Random Walk Down Wall Street書中的觀點類似）。把炒股看K線的時間用來多陪伴家人，或者打球，看書，寫碼，練琴等興趣愛好，甚至是刷推特都可能更加有意義。

Elementaryアップデートの試行錯誤

Thu, 28 Mar 2024 00:00:00 +0000

副業先のtech blogに記事を書きました

NodeにTaintsがついている場合、Datadog DaemonSetにTolerationsを忘れないでね！

Mon, 15 Jan 2024 00:00:00 +0000

マネージド型k8sのDaemonSet

EKSなどのKubernetesマネージドサービスは、DaemonSetを介してNodeにkube-proxy, ebs csi, cniなどのPodを適切に配置してくれます。

k8sドキュメントに記載している自動的に追加されるTolerations以外で、ワイルドカードのTolerationsもデフォルトで入っています。

tolerations: 
- operator: Exists

EKS管轄外のDaemonSet

しかし、DatadogなどEKS外でデプロイされたDaemonSet Podsを入れる際に、TaintsがついているNodeにPodがスケジューリングされないため、注意が必要です。解決方法としては、ドキュメントに書かれているように

https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#taints-and-tolerations

You can add your own tolerations to the Pods of a DaemonSet as well, by defining these in the Pod template of the DaemonSet.

DaemonSetのPodテンプレートにtolerationsを定義することです。

tolerations: 
- operator: Exists

また、このようなワイルドカードのTolerationsを追加するのは便利かもしれないですが、（EKSの場合）Fargateにスケジューリングされてしまうので、Affinityもちゃんと書きましょう

affinity: 
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: eks.amazonaws.com/compute-type
 operator: NotIn 
 values:
 - fargat

余談ですが、同じくDaemonSet介してデプロイされるfluent bitでは、不必要なTolerationsによるバグが過去起きていました。

https://github.com/aws-samples/amazon-cloudwatch-container-insights/issues/61

Helmを使用せずにKustomizeでAirbyteをKubernetes上に構築する

Tue, 19 Dec 2023 00:00:00 +0000

会社のtech blogに記事を書きました

潤日進階: 如何DIY歸化日籍🇯🇵

Wed, 29 Nov 2023 00:00:00 +0000

本文可以轉載，但請附上這個博客的URL

寫這篇文章的理由

用日文谷歌搜索「日本国籍帰化」結果多半是行政書士們用於營業推廣的文章，可能因為利益相關，多數不是很詳細整理的也不是很系統，另外信息也相對較陳舊沒有一直更新。本文的目的是詳細描述DIY歸化日籍的整個過程，為後來人提供方便。花幾十萬日圓找行政書士也可以節約不少時間，但中國方面的資料依然還是需要自己獲取，大家可以看完這篇文章之後再權衡一下。

記得當時我DIY日本留學的時候也是在知乎（當年的知乎）上查到一個叫蘇菲的前輩寫的文章，然後自己將文中的內容付諸實踐，最後沒有經過語言學校大學畢業後直接旅遊簽證考試然後入學修士。因爲我是小鎮做題家而且家庭條件也完全談不上好，那篇文章可以說是改變了我的人生軌跡。現在我想做的是把我微不足道的經驗分享給想要知道的人。

前提

本文主要針對於來自中國且已經持有長期簽證在日本留學或者工作並且想要歸化的朋友。如果人還在中國的話，建議首先參考有名的潤學項目的其他文章再來閱讀此文
本文只談方法論，關於要不要「潤」以及日本適不適合潤等話題本文不做討論
本文內容全部基於筆者自身2022-23年（或者更早）的經驗，可能會過時或者跟你的情況有所偏差，如果有事實性錯誤歡迎提出issue, PR
也歡迎其他形式的PR
歸化所需要的材料因人而異，作爲補充整理到了cases裏，請對比閱讀

歸化的條件

日本的國籍法第五條是這樣寫的，

居住条件（国籍法第５条１項１号）引き続き５年以上日本に住所を有すること

能力条件（国籍法第５条１項２号）２０歳以上で本国法によって行為能力を有すること

素行条件（国籍法第５条１項３号）素行が善良であること

生計条件（国籍法第５条１項４号）自己又は生計を一にする配偶者その他の親族の資産又は技能によって生計を営むことができること

重国籍防止条件（国籍法第５条１項５号）国籍を有せず、又は日本の国籍の取得によってその国籍を失うべきこと。

不法団体条件（国籍法第５条１項６号）日本国憲法又はその下に成立した政府を暴力で破壊することを企て、若しくは主張し、又はこれを企て、若しくは主張する政党その他の団体を結成し、若しくはこれに加入したことがないこと

挑選出其中的一部分稍微詳細說明一下。以下都是慣例沒有明文規定，或者說從官方的資料查不到相應的內容，但在申請的過程中可以瞭解到。

首先關於「居住條件」，說的是5年但按照一般經驗上來講，我申請過程中瞭解到其中的至少3年必須要工作並且正常納稅，也就是單單來日本留學念了5年書並不能申請。另外這個「引き続き」的定義也值得注意，跟申請用住類似，一年之內離開日本超過150天或者單次超過90天過去的話通常會從0開始計算。也就是有大半年或者有過長時間離開日本的經歷會被判定為將來不想在日本長居。

關於「素行條件」，就是說你不能偷稅漏稅（包括保險年金）或者過去有案底。。只要自己遵守規則準時繳納了稅金跟社保完全不是問題，如果就職於正規的公司的話每個月稅跟社保都會直接從工資扣除因此完全不需要擔心。過去就算有過輕微的交通事故，在申請的時候詳細說明情況問題應該也不大。

「生計條件」就是說你得有個穩定的工作能養活你自己跟你的家人，沒有硬性規定收入多少而且我個人覺得不是很嚴格。

「重国籍防止条件」這點就更好理解了，日本也不承認雙重國籍也就是說取得日籍之後必須放棄原來的國籍，這對持有中國國籍的人來說應該沒有任何影響，因為中國也不承認雙重國籍。準確來說在中國如果你不是鐮刀應該不可能擁有多本護照。

下面介紹幾個在申請過程中我所瞭解到的隱藏條件。

日語水平法律沒有明確要求但至少要有小學低年級水平，面談的時候即便你有N1證書也還是會測試你的日語能力
如果你剛剛跳槽在新公司未滿一年，通常不會讓你申請，在他們看來頻繁換工作意味着不穩定。在一家公司至少買一年後才能夠申請
如果有同居人（這裏指的是還沒有結婚的男女朋友），同居人的身份證明跟納稅的材料也需要提交

時間線

下面整理一下歸化的時間線

（滿足上述條件之前半年）第一次面談
（滿足條件之前兩個月）第二次面談
（滿足條件的當月）第三次面談
（滿足條件的當月）提交申請
（申請三個月後）法務局面試
（面試三個月後）法務局來電
（兩週後）歸化結果通知
（一週後）放棄中國國籍拿到歸化相關的證明書
（一週後）辦理戶籍相關的手續

整個過程前後接近1年半，需要有點耐心。還有就是上述時間線是我綜合幾個朋友的平均結果，樣本數很少應該會有不小的偏差，僅供參考。歸化的通過率很高，走完這個漫長的過程基本上就成功了。換句話來說只要法務局讓你提交申請，成功率就已經在90%以上了。數據來自日本政府官方的統計

乍看很難，如果把歸化看作一個項目，分階段完成的話其實難度也不大。整個過程中你還會發現日本各個行政部門之間儘管做事方式落後缺少互相交流且效率低下，但卻都很很認真能把整件事情事無鉅細地全部辦完，還挺有意思的，扯太遠了，回到主題。

需要打交道的實體

歸化涉及到的材料很多，並且日本跟中國的材料都需要。並且如果有配偶小孩，或者有工資以外的收入則需要的材料會更多。獲取這些材料需要跟以下實體打交道。

中國
- 中國戶籍所在地的公證處
- 在老家的父母
- 中國駐日大使館領事部
日本
- 法務局
- 区・市役所
- 警察局
- 年金事務所
- 就職的公司
- 大學

整個過程至少需要去6次法務局，2次中國大使館領事部，2次居住地的区・市役所，1次中國國內的公證處。別的因人而異，具體需要什麼材料以及如何獲取會在後面的詳細步驟中說明。請行政書士可以減少你去法務局的次數，有沒有價值這裏不做判斷。

自作プロキシサーバで海外のサービスを利用しよう

Tue, 17 Oct 2023 00:00:00 +0000

本記事に書かれていることを実践する際は自己責任でお願いします。不都合などが生じた場合、責任を負いかねます。

背景

日本のインターネット環境は比較的自由ですが、海外のサービスを利用際には大人の諸事情によってサイトがリダイレクトされて利用できない場合があります。制限されるのはあまり気持ちよく感じないのとWeb閲覧時自分のプライバシーを保護するため、先日自作プロキシサーバを自作しました。

本記事では主にHowに焦点を当てて紹介します。関連技術のWhatとWhyについては深く言及しないので、公式ドキュメントまたは他の解説記事をご参照ください。

雑なアーキテクチャ図

利用技術・サービス

AWS Lightsail
- 仮想プライベートサーバ
- 3ヶ月無料
- $3.5/月
ムームードメイン
- 3000~4000円/年（申請するドメインによる）
gost
- OSS
- Webサービスを装うために使う
Cloudflare
- gostを使うのに必要
- 無料プランで十分
SwitchyOmega
- OSS
- クライアント側の設定

あくまでも一例で最適解ではないです。

事前準備

VPS（仮想プライベートサーバ）を契約

今回は、AWSが提供しているLightsailという軽量仮想プライベートサーバのサービスを利用しますが、EC2やHerokuなど他のサービスを利用する場合もまったく問題ありません。リージョンは日本以外（例えばUS）に設定しておきます。AWSのCLIを利用する場合、AWS IAMなどを設定する必要がありますが、今回は基本的にいじらなくても良いです。 Lightsailでサーバを立ち上げたら、AWS CloudShellからサーバにアクセスできます。ローカルに慣れている方はキーをダウンロードして、sshでアクセスしても構いません。

念のため、

curl ipinfo.io

を実行して、設定しているリージョンの住所と一致しているか確認します。また、HTTPSを利用するため、Networking -> IPv4 FirewallからHTTPSを追加しておきます。

GCS composeで32以上のオブジェクトをまとめる方法

Thu, 17 Aug 2023 00:00:00 +0000

先日の記事にてパーティション化されたCSVオブジェクトをCloudSQLにimportする方法を紹介しました。

SDKを利用して32より多いオブジェクトをまとめる場合、GCPのコミュニティのチュートリアルのコードをそのまま使っていました。（2023.8.10にアーカイブされ済み）

https://github.com/GoogleCloudPlatform/community/blob/master/archived/cloud-storage-infinite-compose/index.md

文章最後に書いてあるように

This code is offered for demonstration purposes only, and should not be considered production-ready. Applying it to your production workloads is up to you!

コードはデモ用途のため、そのまま本番環境で使うのはで推奨しないです。先日この文を見逃して自分の環境にデプロイし、平常運転1ヶ月後、パーティション化されたCSVオブジェクトの数が増えたらバグが出ました。

事象

起きていた事象は、composeによって作られた中間オブジェクトが消されず残り続け、最終的に数TBのとてつもなく大きいオブジェクトが作成されてしまいました。一つのオブジェクトは5TiBまでというGCSの上限を超えてしまうため、処理が失敗しました。

どこがバグ

問題は関数compose_and_cleanupから呼び出している関数delete_objects_concurrentにあります。オブジェクトをまとめた後、毎回中間オブジェクトを削除していますが、そのdelete処理自体が非同期処理ですべての処理が終了するのを待たずに次のblob.composeの実行が始まります。

The delete_objects_concurrent function is very simple, using fire-and-forget delete tasks in an executor. A more robust implementation might check the futures from the submitted tasks.

チュートリアルの中にちゃんと書いてあります。（もっとロバスト性のある実装は、submit済みのタスクのfuturesをチェックするとのこと）

まとめようとするオブジェクトの数が少ない場合はほとんど問題がないですが、1000オブジェクトあたりを超えるとdeleteがcompose処理より遅くなるため、next_chunkが永遠に存在しているままwhileループから脱出できない状態になります。

delete処理自体は特に制限ないようですが、数百のオブジェクトを削除する場合時間かかるとドキュメントに記載されています。

https://cloud.google.com/storage/docs/deleting-objects#delete-objects-in-bulk

解決方法

最初に試したことは、記事に書いてあるようにsubmit済みのタスクのfuturesをwait処理でチェックします。つまりすべてのdelete処理が終わるまでに、compose処理を行いません。（python並行処理の詳細は公式ドキュメントまたは他の記事をご覧ください）

from concurrent.futures import ALL_COMPLETED, ThreadPoolExecutor, wait

def delete_objects_concurrent(blobs, executor, client) -> None:
 """Delete Cloud Storage objects concurrently.
 Args:
 blobs (List[storage.Blob]): The objects to delete.
 executor (Executor): An executor to schedule the deletions in.
 client (storage.Client): Cloud Storage client to use.
 """
 futures = []
 for blob in blobs:
 logger.info("Deleting slice {}".format(blob.name))
 futures.append(executor.submit(blob.delete, client=client))
 wait(futures, return_when=ALL_COMPLETED)
 logger.info(f"Deleted {len(blobs)} objects")

しかし大量なオブジェクトを1つずつ削除していること自体は変わらないので、試してみたら処理が途中でtimeoutになりました。 batchを利用して削除処理をバッチにまとめる方法もありますが、ロジックをシンプルにしたいので、他の方法を考えました。

パーティション化されたCSVファイルをCloudSQLにimportする方法

Wed, 16 Aug 2023 00:00:00 +0000

問題

パーティション化されたCSVファイルをCloudSQLにimportする場面は時々あると思います。残念ながらCloudSQLはBigQueryのようにwildcardsによるimportを対応していません。需要はあるようですが↓

https://issuetracker.google.com/issues/132058570?pli=1

ファイルごとにimportするとオーバーヘッドが毎回発生するため、速度的に実用性があまりないと思います。一方、importはオペレーションの1種なので、並列処理はできません。

https://cloud.google.com/sql/docs/troubleshooting#import-export

HTTP Error 409: Operation failed because another operation was already in progress. There is already a pending operation for your instance. Only one operation is allowed at a time. Try your request after the current operation is complete.

なので、ファイルを結合してimportするのはより現実的な解決策だと思います。

`gsutil compose`

gsutil composeを利用すると、GCSにある複数のファイルを結合できます。 cliのみならず、SDK(google.cloud.storage.Blob.compose)も同じ機能が提供されています。

https://cloud.google.com/storage/docs/composing-objects#create-composite-client-libraries

https://cloud.google.com/storage/docs/gsutil/commands/compose

ただし、結合できるファイルは最大32個という制約があります。

There is a limit (currently 32) to the number of components that can be composed in a single operation.

AirflowからDataformにdata_interval_endなどのcontext変数を渡す方法

Wed, 24 May 2023 00:00:00 +0000

先日GCPのDataformがGAリリースされました。せっかくなので、まずAirflowにある既存ワークフローの一部をDataformで書き換えようと思いました。

AirflowからDataformをトリッガーする

ドキュメントを調べると、AirflowからDataformをトリッガーするoperatorはすでに存在しています。 https://cloud.google.com/dataform/docs/schedule-executions-composer#create_an_airflow_dag_that_schedules_workflow_invocations

簡単にまとめると

DataformCreateCompilationResultOperator: sqlxをsqlにコンパイルする
DataformCreateWorkflowInvocationOperator: sqlを実行する

しかし、どのようにAirflowからDataformへ変数を渡すかについてはドキュメントに記載されていません。

Dataformに変数を渡す

まず、Dataformの設定ファイルdataform.jsonに変数varsを追加しておきましょう。

{
 "defaultSchema": "dataform",
 "assertionSchema": "dataform_assertions",
 "warehouse": "bigquery",
 "defaultDatabase": "project-stg",
 "defaultLocation": "asia-northeast1",
 "vars": {
 "bq_suffix": "_stg",
 "execution_date": "2023-05-24"
 }
}

DataformCreateCompilationResultOperatorのソースを調べてみたところ、compilation_resultという引数があることを発見しました。

https://github.com/apache/airflow/blob/739e6b5d775412f987a3ff5fb71c51fbb7051a89/airflow/providers/google/cloud/operators/dataform.py#LL73C29-L73C46

compilation_resultの中身を確認するため、APIの詳細を調べました。 https://cloud.google.com/dataform/reference/rest/v1beta1/CodeCompilationConfig

CodeCompilationConfig内にvarsという変数を指定できるようです。

{
 "defaultDatabase": string,
 "defaultSchema": string,
 "defaultLocation": string,
 "assertionSchema": string,
 "vars": {
 string: string,
 ...
 },
 "databaseSuffix": string,
 "schemaSuffix": string,
 "tablePrefix": string
}

BigQueryのsuffixをcode_compilation_configのvarsへ渡してみたら問題なく実行できました。ちなみに、Dataform側からはdataform.projectConfig.vars.bq_suffixで変数を呼び出せます。

DataformCreateCompilationResultOperator(
 task_id="create_compilation_result",
 project_id=PROJECT_ID,
 region=REGION,
 repository_id=REPOSITORY_ID,
 compilation_result={
 "git_commitish": GIT_COMMITISH,
 "code_compilation_config": {
 "vars": {
 "bq_suffix": "_stg",
 }
 },
 },
)

Dataformにcontext変数を渡す

増分処理する際によくdata_interval_endなどのcontext変数を利用して当日の差分だけ取り入れます。しかし、DataformCreateCompilationResultOperatorではtemplate_fieldsが実装されていないため、直接{{ data_interval_end }}のようなjinjaテンプレートを渡すことはできません。

TaskFlowでDataformCreateCompilationResultOperatorをラッピングすれば前述の問題を解決できます。data_interval_endはcontextから取得します。ポイントとしてはDataformCreateCompilationResultOperatorを返す際にexecute()を呼び出す必要があります。

from airflow.decorators import task

@task()
def create_compilation_result(**context):
 execute_date = (
 context["data_interval_end"].in_timezone("Asia/Tokyo").strftime("%Y-%m-%d")
 )
 return DataformCreateCompilationResultOperator(
 task_id="create_compilation_result",
 project_id=PROJECT_ID,
 region=REGION,
 repository_id=REPOSITORY_ID,
 compilation_result={
 "git_commitish": GIT_COMMITISH,
 "code_compilation_config": {
 "vars": {
 "execute_date": execute_date,
 "bq_suffix": Variable.get("bq_suffix"),
 }
 },
 },
 ).execute(context=context)

最終的なDAGは以下のようになります。

Apache Airflowのコミッターになった話

Thu, 11 May 2023 00:00:00 +0000

Google Providersのバグを見つけた

先日DAGを開発中にGoogle Providers (apache-airflow-providers-google==8.9.0)のCloudDataTransferServiceJobStatusSensorを使用したところ、 project_idはオプション引数であるにも関わらず、省略するとエラーが発生するというバグに遭遇しました。

[2023-03-09, 02:31:24 UTC] {taskinstance.py:1774} ERROR - Task failed with exception
Traceback (most recent call last):
 File "/home/airflow/.local/lib/python3.8/site-packages/airflow/sensors/base.py", line 236, in execute
 while not self.poke(context):
 File "/home/airflow/.local/lib/python3.8/site-packages/airflow/providers/google/cloud/sensors/cloud_storage_transfer_service.py", line 91, in poke
 operations = hook.list_transfer_operations(
 File "/home/airflow/.local/lib/python3.8/site-packages/airflow/providers/google/cloud/hooks/cloud_storage_transfer_service.py", line 380, in list_transfer_operations
 request_filter = self._inject_project_id(request_filter, FILTER, FILTER_PROJECT_ID)
 File "/home/airflow/.local/lib/python3.8/site-packages/airflow/providers/google/cloud/hooks/cloud_storage_transfer_service.py", line 459, in _inject_project_id
 raise AirflowException(
airflow.exceptions.AirflowException: The project id must be passed either as `project_id` key in `filter` parameter or as project_id extra in Google Cloud connection definition. Both are not set!

修正自体はそれほど困難に見えなかったため、Airflowにissueを報告するよりも、自分で直接修正に取り組むことにしました。

Contributor手順を読んで環境構築する

むやみにコーディングするより、まずCONTRIBUTINGを読んだほうが良いと思い、下記のドキュメンを見つけました。

https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst けっこう長いので、前半をさらさらと読んでContribution Workflowを参照しながら、ローカルの開発環境を問題なく構築しました。躓きそうなところ基本的にドキュメントにまとめてもらっています。

開発

https://github.com/apache/airflow/pull/30035/files#diff-2118fb849310fd85b9768e6732ab2dfa60ed75c751b5b9d0e176bcd1f950b6bbR75-R109

まず他のところを真似してproject_idを指定しない場合の単体テスクを書きます。何も実装していないので、もちろんテストはコケます。その後、CloudDataTransferServiceJobStatusSensorの実装を下記のようにproject_idを明示的に指定しない場合、hook.project_idから取得できるように変更します。

- request_filter={"project_id": self.project_id, "job_names": [self.job_name]}
+ request_filter={"project_id": self.project_id or hook.project_id, "job_names": [self.job_name]}

これで終わり！PRを投げてPRを待ちます。一週間もかからずApache Software Foundationメンバーの方からApproveをもらいました。

受け入れテスト

2週間後「apache-airflow-providers-google 8.12.0rc1をリリースされたので、リリースのテストをお願いします」の連絡がissueから来ました。

https://github.com/apache/airflow/issues/30427

8.12.0rc1をインストールし実際にCloudDataTransferServiceJobStatusSensorの動作を検証してみたら特に問題なかったので、うまく動いたよと返信しました。

Slack BoltとCloud Functionsでデータ基盤アクセス承認システムを開発

Thu, 20 Apr 2023 00:00:00 +0000

会社のTech Blogに記事を書きました

Slack BoltとCloud Functionsでデータ基盤アクセス承認システムを開発

Airflowの単体テストを書きましょう

Thu, 06 Apr 2023 00:00:00 +0000

データ基盤は下流の分析・可視化・モデリングの「基盤」となるので、品質の担保は言うまでもなく重要ですね。品質を確保するには、ワークフローの監視・検証、ワークフローのテスト、そして加工用クエリのテストがいずれも欠かせません。この記事では、ワークフロー（Airflow）の単体テスト方法について紹介します。また、ワークフローの監視・検証に関しては、過去の記事も合わせてご覧いただけると幸いです。

ワークフローの監視

ワークフローの検証

DAGの単体テスト

まずは、DAGの単体テストについて説明します。厳密に言えば、DAGの実行ではなく、DAGが正確に構築されたかどうかのテストを行います。

https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html#unit-tests

Airflowの公式ベストプラクティスでは簡潔に紹介されていますが、具体例を挙げてさらに詳しく説明しましょう。

importのテスト

importが正常にできることを確認する（importが失敗するとWeb UIからも確認できるが、単体テストする時点で確認するともっと便利）
import時間を制限する。（冗長なDAGがあると解析するのに時間がかかるので、import時間を制限することで、事前に冗長なDAGを発見できる）
最低でも1つのタスクが含まれていることを確認する。

import unittest
from datetime import timedelta

from airflow.models import DagBag


class TestImportDags(unittest.TestCase):
 IMPORT_TIMEOUT = 120

 @classmethod
 def setUpClass(cls) -> None:
 cls.dagbag = DagBag()
 cls.stats = cls.dagbag.dagbag_stats

 def test_import_dags(self):
 self.assertFalse(
 len(self.dagbag.import_errors),
 f"DAG import failures. Errors: {self.dagbag.import_errors}",
 )

 def test_import_dags_time(self):
 duration = sum((o.duration for o in self.stats), timedelta()).total_seconds()
 self.assertLess(duration, self.IMPORT_TIMEOUT)

 def test_dags_have_at_least_one_task(self):
 for key, dag in self.dagbag.dags.items():
 self.assertTrue(dag, f"DAG {key} not exsit")
 self.assertGreater(len(dag.tasks), 0, f"DAG {key} hasn't any tasks")

DAGの設定

DAGタイムアウト設定が必ず行われていることを確認する
失敗時のアラート通知用のcallback関数が必ず行われていることを確認する
DAGにタグが付与されていることを確認する（タグはDAGの分類や検索に役立つ）
catchupを無効になっているかを確認する（場合によって有効でも構わない）

class TestDagsSetting(unittest.TestCase):
 @classmethod
 def setUpClass(cls) -> None:
 cls.dagbag = DagBag()

 def test_dag_has_necessary_setting(self):
 for key, dag in self.dagbag.dags.items():
 self.assertIsNotNone(dag.dagrun_timeout, f"DAG {key} hasn't dagrun timeout")
 self.assertIsNotNone(
 dag.on_failure_callback, f"DAG {key} hasn't on_failure_callback"
 )
 self.assertIsNotNone(dag.tags, f"DAG {key} hasn't tags")
 self.assertFalse(dag.catchup, f"catchup of DAG {key} was not False")

これらのテストを通すことで、DAGの基本的な構成が適切であることが確認でき、DAGの運用上の問題を未然に防ぐことができます。

AirflowからAirbyteをトリッガーする際にハマるポイント

Mon, 06 Mar 2023 00:00:00 +0000

https://docs.airbyte.com/operator-guides/using-the-airflow-airbyte-operator/

AirflowからAirbyte Operatorを利用するための設定について、Airbyte公式の記事は既にわかりやすくまとめています。実際に試してみて、少しハマったところがあったので、その知見を共有したいと思います。

1. Airflowを`2.3.0`以上にアップグレードする必要がある

apache-airflow-providers-airbyte[http]を利用するのにAirflowを2.3.0以上に上げないといけません。(apache-airflow-providers-airbyte[http]をdocker-composer.ymlの_PIP_ADDITIONAL_REQUIREMENTSに追加することも忘れずに) Cloud Composerなどを利用している場合、GUIからアップグレード可能です。

https://airflow.apache.org/docs/apache-airflow-providers-airbyte/stable/index.html

version: '3'
x-airflow-common:
 &airflow-common
 image: apache/airflow:2.3.4-python3.8
 environment:
 &airflow-common-env
 PYTHONPATH: /opt/airflow/dags
 AIRFLOW__CORE__EXECUTOR: CeleryExecutor
 AIRFLOW__CORE__SQL_ALCHEMY_CONN: postgresql+psycopg2://airflow:password@postgres/airflow
 AIRFLOW__CELERY__RESULT_BACKEND: db+postgresql://airflow:password@postgres/airflow
 AIRFLOW__CELERY__BROKER_URL: redis://:@redis:6379/0
 AIRFLOW__API__AUTH_BACKEND: 'airflow.api.auth.backend.basic_auth'
 # 追加
 _PIP_ADDITIONAL_REQUIREMENTS: apache-airflow-providers-airbyte[http]==3.2.0

2. Airflowの古いバージョンから`2.3.4`上げるとdocker-composeがバグる

airflow 2.2.xでは問題なく環境構築できていましたが、イメージをapache/airflow:2.3.4-python3.8に変更してdocker compose up airflow-initを実行したら怒られます。

You are running pip as root. Please use 'airflow' user to run pip!

Airflowの古いdocker-composer.ymlのバグのようなので、 https://github.com/apache/airflow/pull/23517/files

services -> airflow-init -> environmentに_PIP_ADDITIONAL_REQUIREMENTS: ''を追加すれば解決できます。

Cloud Composerでmax_active_tasks_per_dagのデフォルト値が機能していない問題

Wed, 08 Feb 2023 00:00:00 +0000

問題

先日Cloud Composerの環境を↓にバージョンアップしました。

Cloud Composer 2.0.32
Airflow 2.2.5

core.max_active_tasks_per_dagという一つのDAG内同時に処理できるタスクの上限を設定するパラメータがデフォルト値16のままになっているのにも関わらず、実行するタスクの上限が明らかに16を超えています。

https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#max-active-tasks-per-dag

ローカルにあるAirflow 2.2.5環境では何の異常もなく、ComposerのAirflow Configurationを確認したところ、なぜかcore.dag_concurrencyが100に設定されています。

[core]
dags_folder = /home/airflow/gcs/dags
plugins_folder = /home/airflow/gcs/plugins
executor = CeleryExecutor
dags_are_paused_at_creation = True
load_examples = False
donot_pickle = True
dagbag_import_timeout = 300
default_task_retries = 2
killed_task_cleanup_time = 3570
parallelism = 0
non_pooled_task_slot_count = 100000
dag_concurrency = 100
....

core.dag_concurrencyの役割はcore.max_active_tasks_per_dagと同じく、一つのDAG内同時に処理できるタスクの上限を設定しています。Airflow 2.2.0からはすでにDeprecatedになったはずなのに、なぜか残り続いています。

https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#dag-concurrency-deprecated

試み

手動で削除しようと思ったですけど、バージョンを上げたのでCloud Composer -> AIRFLOW CONFIGURATION OVERRIDESにcore.dag_concurrencyというパラメータすら存在しませんでした。

Cloud SQLにある大量なテーブルをBigQueryに入れる話

Thu, 02 Feb 2023 00:00:00 +0000

経緯

昨年度から大規模なデータ分析基盤の構築に携わっています。最近Cloud SQLにある6つのDBの数百個のテーブルを日次洗い替えでBigQueryにあるデータ基盤に入れるタスクを取り組んでいます。 Cloud SQLとBigQuery両方ともGCPのサービスのため、federated queriesを利用すると簡単にできそうに見えますが、

https://cloud.google.com/bigquery/docs/federated-queries-intro

実際に行ってみると、以下の3つの課題を気づきました。

BigQuery側でスキーマ情報を含めたテーブルを一々作成するのは現実的ではない
プロダクトの進化とともにテーブル・カラムが頻繁に作成・変更されるため、BigQuery側でも対応しないといけない
Cloud SQLにあるテーブルの定義をそのまま取ってきてもBigQueryではMySQLとPostgreSQLの一部の型が対応されていない

https://cloud.google.com/bigquery/docs/tables#sql_1

少し苦労していましたが、幸い解決方法を見つけました。今後躓く方もいるかもしれないので、知見を共有したいと思います。

BigQuery側でスキーマ情報を含めたテーブルを一々作成するのは現実的ではない

BigQueryはクエリの結果によってテーブルを作成できるので、事前にテーブルを作っておく必要がありません。 https://cloud.google.com/bigquery/docs/tables#sql_1

大量なテーブルを一々作成するのは現実的ではない課題の解決法としてはDBのメタ情報（descriptionを含めて）をそのまま生かしてテーブル作成用クエリを生成し、テーブルを作成します。

例えばPostgreSQLの場合、まずはテーブルのメタ情報

SELECT 
 schemaname, 
 relname AS table_name, 
 obj_description(relid) AS description
FROM pg_catalog.pg_statio_all_tables
WHERE schemaname = '{YOUR_SCHEMA}'

とカラムのメタ情報を取得します。

SELECT
 c.table_schema,
 c.table_name,
 c.column_name,
 c.data_type,
 pgd.description
FROM pg_catalog.pg_statio_all_tables AS st
INNER JOIN pg_catalog.pg_description pgd on (
 pgd.objoid = st.relid
)
RIGHT JOIN information_schema.columns c ON (
 pgd.objsubid = c.ordinal_position and
 c.table_schema = st.schemaname and
 c.table_name = st.relname
)
WHERE c.table_schema = '{YOUR_SCHEMA}';

上記のメタ情報をfor文で回してテーブル作成用のクエリテンプレートの$columns $pg_schema $table_nameに入れたら、テーブル作成用のクエリが生成されます。Airflowとかで定期的にクエリを実行すれば問題解決です。

M1 MacでDocker DesktopからRancher Desktopに移行

Thu, 19 Jan 2023 00:00:00 +0000

https://www.docker.com/pricing/october-2022-pricing-change-faq/

The list price of the Docker Business subscription will go up by $3, to $24 per user per month

2022年10月のお知らせですが、Docker Desktop Business subscriptionがなんと8倍値上げ！！コスト面の理由でRancher Desktopに移行することになりました

移行する際に、Rancher Desktopの2つバグを見つけました。これから躓く人もいると思うので、一旦バグ内容と解決法を共有します。

バグ1：volumesをマウントする際に`chown`から`permission denied`エラーが出る

https://github.com/rancher-sandbox/rancher-desktop/issues/1209

issue自体はまだ解決されていない(2023年1月)ですが、 ~/Library/Application\ Support/rancher-desktop/lima/_config/override.yamlに下記の設定を追加すれば回避できます。

mountType: 9p
mounts:
 - location: "~"
 9p:
 securityModel: mapped-xattr
 cache: "mmap"

バグ2：M1 MacはMonterey 12.4以上に上げないと、割り当てられるメモリは最大3GBになる

Rancher DesktopのGUIからメモリを32GBに設定したにもかかわらず、

docker infoで確認すると、CPUは設定通りですが、メモリは2.9GiBしか割り当てられていませんでした。

 Architecture: aarch64
 CPUs: 6
 Total Memory: 2.909GiB
 Name: lima-rancher-desktop

https://github.com/rancher-sandbox/rancher-desktop/issues/2855

dbtでBigQuery上に構築したデータ基盤のメタデータ管理

Sun, 11 Dec 2022 00:00:00 +0000

データ基盤におけるETL/ELT開発のT(Transform)を担うツールdbtは最近注目を浴びています。dbtでデータモデリングする方法既に多く紹介されたので、この記事では手を動かしながらdbtでBigQuery上に構築したデータ基盤のメタデータを管理する方法を紹介します。

環境構築

dbt公式はHomebrewを推していますが、ローカル環境が汚染されるのをなるべく避けたいので、Dockerで環境構築します。 dbtのプロジェクトとプロファイルの設定ファイルを用意しておかないと、公式のドキュメントそのまま実行したらコケます。しかし設定ファイルの生成は環境を構築する必要があるので無限ループになっています。

https://docs.getdbt.com/docs/get-started/docker-install

そのため、公式のサンプルプロジェクトをforkし、事前にローカル環境で生成した設定ファイルを追加しました。

https://github.com/jckinjo/dbt-metadata-management

`profiles.yml`を編集

{YOUR_DATASET_NAME}と{YOUR_PROJECT_ID}を置き換えます。複数のデータセットのメタデータも作成可能ですが、一旦任意のデータセット名を指定する必要があります。dbtの問題点でもありますが、後ほど説明します。

Dockerイメージをプル

docker pull ghcr.io/dbt-labs/dbt-bigquery:1.2.0

コンテナを立ち上げる

git clone https://github.com/jckinjo/dbt-metadata-management
cd dbt-metadata-management

`gcloud`認証

認証済みの場合、このステップは不要です。

gcloud auth login --no-launch-browser
gcloud auth application-default login --no-launch-browser

コンテナを立ち上げる

docker run --rm \
 --network=host \
 --platform linux/amd64 \
 --mount type=bind,source=`PWD`,target=/usr/app \
 --mount type=bind,source=`PWD`/profiles.yml,target=/root/.dbt/profiles.yml \
 --mount type=bind,source=$HOME/.config/gcloud/application_default_credentials.json,target=/root/.config/gcloud/application_default_credentials.json \
 ghcr.io/dbt-labs/dbt-bigquery:1.2.0 \
 ls

データモデルのリストが表示されたら、環境構築が無事終了です。

ドキュメントを生成する

`docs generate`

以下のコマンドを実行すれば、models/配下のクエリとメタデータ（yamlファイル）を参照して、target/配下にメタデータのドキュメントが生成されます。

docker run --rm \
 --network=host \
 --platform linux/amd64 \
 --mount type=bind,source=`PWD`,target=/usr/app \
 --mount type=bind,source=`PWD`/profiles.yml,target=/root/.dbt/profiles.yml \
 --mount type=bind,source=$HOME/.config/gcloud/application_default_credentials.json,target=/root/.config/gcloud/application_default_credentials.json \
 ghcr.io/dbt-labs/dbt-bigquery:1.2.0 \
 docs generate

さらにdbt docs serveを実行すると、localhostからメタデータのドキュメントを確認できます↓。schema dbt_testとdbt_test_2はBigQueryのデータセットに該当します。

PythonデコレータのSyntactic Sugarなぜ便利かを理解した

Wed, 23 Nov 2022 00:00:00 +0000

Pythonデコレータを利用する場合、@decoratorというSyntactic Sugarを関数やメソッドの先頭に付けるのが一般的ですが、なぜ便利なのかいまいち理解できていないので、調べてみました。

デコレータの詳細は公式ドキュメントあるいは他の方がすでに紹介されているので、本記事では割愛します。ちなみにおすすめの記事はこちらです。

https://rednafi.github.io/digressions/python/2020/05/13/python-decorators

まず適当に文字列の両側に<b>を追加してくれる簡単なデコレータを書きましょう。num_bは片方に追加する<b>の数を表しており、デフォルトは1となっています。

from functools import partial, wraps


class Emphasis:
 def __init__(self) -> None:
 pass

 def add_b(self, func=None, num_b=1):
 if func is None:
 return partial(self.add_b, num_b=num_b)

 @wraps(func)
 def wrap(*args, **kwargs):
 ret = func(*args, **kwargs)
 return "<b>" * num_b + ret + "<b>" * num_b

 return wrap

デコレータ引数なし・関数引数なしの場合

最初は一番簡単なパターンで見ていきましょう。デコレータep.add_b(hello)の返り値は関数なので、一回コール()すればSyntactic Sugarと同じことができるので、むしろSyntactic Sugarを使わないほうがわかりすそうですね。

ep = Emphasis()


def hello():
 return "Hello, There"


@ep.add_b
def hello_with_sugar():
 return "Hello, There"


print(ep.add_b(hello)())
print(hello_with_sugar())

<b>Hello, There<b>
<b>Hello, There<b>

デコレータ引数あり・関数引数ありの場合

しかしデコレータと関数両方引数がある場合はep.add_b(num_b=2)(hello)("Taro")を書かないといけません。言葉で説明すると、hello関数を引数としてデコレータep.add_b(num_b=2)に入れて返された関数に引数"taro"を渡してコールするという意味です。書けなくはないですが、ややこしくなるので、Syntactic Sugarのほうが断然簡単ですね

ep = Emphasis()


def hello(name):
 return f"Hello, {name}"


@ep.add_b(num_b=2)
def hello_with_sugar(name):
 return f"Hello, {name}"


print(ep.add_b(num_b=2)(hello)("Taro"))
print(hello_with_sugar("Taro"))

<b><b>Hello, Taro<b><b>
<b><b>Hello, Taro<b><b>

おわりに

Syntactic Sugarのおかげで、デコレータと関数両方引数がある場合でも簡単にデコレータを使えるようになりました。ただ個人的にデコレータを初めて触る方はまずあえてSyntactic Sugarを使わず試してみたら、デコレータの理解が捗るのではないかと思います。ご参考になれば幸いです。

アラートを出す際にAirflowのContextから誤ったtask idが取得されてしまうバグの対処法

Mon, 21 Nov 2022 00:00:00 +0000

先日投稿した記事はAirflow DAGのon_failure_callbackとdagrun_timeoutを組み合わせることでDAGの遅延を監視する方法を紹介しました。

Contextから誤ったtask idが取得されてしまう

contextからdag_runの情報を取得してチャットツールやメールにアラートを出すのは一般的です。Slackにアラートを出す際の例ですが、dag_id, run_id, task_id, reason, log_urlを取得して、webhookでSlackの特定なチャンネルに投稿し、log_urlをクリックするだけですぐローカルあるいはクラウド環境（例えばCloud Composer）で失敗したtaskのログを確認できるので、アラート解消の効率化に繋がります。

ソースは以下となります。

from slack_sdk.webhook import WebhookClient
from airflow.models import Variable
from textwrap import dedent


def notify_error(workflow: str, context: dict) -> None:
 webhook = WebhookClient(Variable.get("slack_webhook_access_token"))
 log_url = context.get("task_instance").log_url

 message = dedent(
 f"""
 :x: Task has failed.
	*Workflow*: {workflow}
	*DAG*: {context.get('task_instance').dag_id}
	*Run ID* {context.get('dag_run').run_id}
	*Task*: {context.get('task_instance').task_id}
	*Reason*: {context.get('reason')}
	<{log_url}| *Log URL*>
	"""
 )

 webhook.send(
 text="alert",
 blocks=[
 {
 "type": "section",
 "text": {"type": "mrkdwn", "text": message},
 }
 ],
 )

しかし、数回検証してみた結果、実行が失敗したタスクtask_idではなく、誤ったtask_idが取得されてしまう事象がしばしば発生します。Airflowの既知バグで、現時点（2022.11.21）はまだ修正されていないです。

データ基盤におけるGoogleグループ・IAMによるアクセス制御

Fri, 18 Nov 2022 00:00:00 +0000

会社のTech Blogに記事を書きました

Airflowのon_failure_callbackとdagrun_timeoutを組み合わせることでDAGの遅延を監視する

Thu, 17 Nov 2022 00:00:00 +0000

https://buildersbox.corp-sansan.com/entry/2022/08/18/110000

この記事では新しくDAGを作成してデータの転送処理が遅れているかを監視する方法が紹介されました。監視と実行用のDAGを分離することでスッキリにはなりますが、DAGが増えることによって管理の手間が生じます（特にDAGが大量にある場合）。

https://stackoverflow.com/questions/69312630/airflow-triggering-the-on-failure-callback-when-the-dagrun-timeout-is-exceed

を参考にして DAGの引数on_failure_callbackとdagrun_timeoutを組み合わせることでDAGの遅延を監視する方法を試してみました。

from datetime import datetime, timedelta

from airflow import DAG
from airflow.models import TaskInstance
from airflow.operators.bash import BashOperator


def _on_dag_run_fail(context):
 print("***DAG failed!! do something***")
 print(f"The DAG failed because: {context['reason']}")
 print(context)

default_args = {
 "owner": "mi_empresa"
}

with DAG(
 dag_id="failure_callback_example",
 start_date=datetime(2021, 9, 7),
 schedule_interval=None,
 default_args=default_args,
 catchup=False,
 on_failure_callback=_on_dag_run_fail,
 dagrun_timeout=timedelta(seconds=45),
) as dag:

 delayed = BashOperator(
 task_id="delayed",
 bash_command='echo "waiting..";sleep 60; echo "Done!!"',
 )
 will_fail = BashOperator(
 task_id="will_fail",
 bash_command="exit 1"
 )
delayed >> will_fail

実行時間が45秒超えると、_on_dag_run_failが実行され失敗したDAGのコンテキスト情報がプリントされます。誰かの役に立つかもしれないので、試しながら気づいた2つのポイントを共有します

1. `on_failure_callback`と`dagrun_timeout`をdefault_argsに入れちゃったら動作しない

default_argsはDAG作成時に実行されるため、DAGのメタデータを入れるのが一般的
with DAG(...)に記載されている引数はDAG実行時に反映されるため、on_failure_callbackとdagrun_timeoutに入れないといけない

2. `context.get('reason')`を利用すると、エラーの種類を判断可能

task_failure タスク実行失敗によるエラー
timed_out　遅延によるエラー

なので、エラーによって異なる処理する場面では活用できそうですね。

Telegramで多言語ニュースチャットボットを作った話

Thu, 03 Nov 2022 00:00:00 +0000

先日多言語Webニュースアプリを作りました。通勤電車で当日のニュースをチェックしながら、外国語を勉強できるので、まあまあ使いやすかったです。

実はこのWebを開発する1年ほど前に、一度Telegram botで多言語ニュースチャットボットを開発していました。今日はそれについて紹介したいと思います。

https://github.com/jckinjo/multitrue-bot

事前準備

Telegram bot

Telegramは日本ではあまり人気がないですが、Telegramのアカウントを作るだけでAPIキーを取得できるので、ざくっとボット作りたい場合は使い勝手がけっこういいです。また、良さげのSDKもあります↓。そういう意味ではSlackも同じですが、Telegramは感覚的にLineに近いので手軽さで勝っていると思います。

https://github.com/python-telegram-bot/python-telegram-bot/tree/master/examples

ニュースの取得

ニュースの取得方法は先日開発したWebアプリと同じくNewsAPI利用して取得しています。なぜNewsAPIを採用したかについては半年前の記事で詳細を説明したので、割愛します。

実装

https://core.telegram.org/ に参照してボットの初期設定が完了したら、実装に入ります。フローは以下となります。

/startでニュースボットを起動
国・地域を選ぶ
ニュースのジャンルを選ぶ
終了あるいは2.に戻る

全体フロー

SDKが提供してくれた下記3つのhandlerを利用しています。

ConversationHandler: 先ほど設計したフローに基づいてhandlerを定義する。
CommandHandler: コマンドによって発火される。今回は「入り口 (entry point)」として使う　
CallbackQueryHandler: 他のhandlerの返り値によって発火される

def main():
 updater = Updater(
 token=json.load(open(KEY_PATH / "keys.json", "r"))["telegram_key"],
 use_context=True,
 )

 dispatcher = updater.dispatcher
 country_pattern = "^us|jp|cn|tw|kr|gb$"
 headlines_pattern = "^us|jp|cn|tw|kr|gb business|entertainment|general|health|science|sports|technology|$"

 conv_handler = ConversationHandler(
 entry_points=[CommandHandler("start", start)],
 states={
 "CATEGORY": [CallbackQueryHandler(select_category, pattern=country_pattern)],
 "HEADLINES": [CallbackQueryHandler(get_news, pattern=headlines_pattern)],
 "START OVER OR NOT": [
 CallbackQueryHandler(start_over, pattern="^start over$"),
 CallbackQueryHandler(end, pattern="^end$"),
 ],
 },
 fallbacks=[CommandHandler("start", start)],
 )

 dispatcher.add_handler(conv_handler)

 updater.start_polling()
 updater.idle()

メニュー

続いてはcallback関数を見ていきましょう。start関数はwelcomeメッセージをユーザに送って、ユーザに国・地域を選んでもらいます。その後、select_category関数でニュースのジャンルを選んでもらいます。

引数contextとupdate

context.user_data: ボットを利用してユーザの情報を取得する
context.bot: ボット自体を操作する（今回はメッセージを送るだけ）のに使う
update: メッセージを更新するのに使う

def start(update, context):
 user = update.message.from_user
 logger.info("User {} started the conversation.".format(user))
 for i, v in vars(user).items():
 context.user_data[i] = v

 welcome_message = (
 "Hello, {}\n"
 "This is JC News bot🗞️🤖\n\n"
 "You can get Top News Headlines for a Country and a Category from here. \n\n".format(user.first_name)
 )
 print(context)
 keyborad = [
 [
 InlineKeyboardButton("🇺🇸", callback_data="us"),
 InlineKeyboardButton("🇯🇵", callback_data="jp"),
 InlineKeyboardButton("🇹🇼", callback_data="tw"),
 ],
 [
 InlineKeyboardButton("🇰🇷", callback_data="kr"),
 InlineKeyboardButton("🇬🇧", callback_data="gb"),
 InlineKeyboardButton("🇨🇳", callback_data="cn"),
 ],
 ]

 reply_markup = InlineKeyboardMarkup(keyborad)
 context.bot.send_message(chat_id=update.effective_chat.id, text=welcome_message)
 update.message.reply_text("Please Choose a Country🤖", reply_markup=reply_markup)

 return "CATEGORY"
 
def select_category(update, context):
 logger.info("User data from context {}".format(context.user_data))
 logger.info("Chat data from context {}".format(context.chat_data))
 logger.info("Bot data from context {}".format(context.bot_data))

 query = update.callback_query
 query.answer()
 country = query.data
 keyborad = [
 [
 InlineKeyboardButton("👩🏼‍💻Technology", callback_data=country + " technology"),
 InlineKeyboardButton("🧑‍💼Business", callback_data=country + " business"),
 ],
 [
 InlineKeyboardButton("👨🏻‍🎤Entertainment", callback_data=country + " entertainment"),
 InlineKeyboardButton("👩🏻‍⚕️Health", callback_data=country + " health"),
 ],
 [
 InlineKeyboardButton("👨🏿‍🔬Science", callback_data=country + " science"),
 InlineKeyboardButton("🏋🏼‍♂️Sports", callback_data=country + " sports"),
 ],
 [InlineKeyboardButton("🌎General", callback_data=country + " general")],
 ]
 reply_markup = InlineKeyboardMarkup(keyborad)
 query.edit_message_text(text="Please Choose a Category🤖", reply_markup=reply_markup)

 return "HEADLINES"

ニュースを取得

最後は最もコアとなるニュースを取得するロジックです。countryとcategoryによってNewAPIから最新ホットラインニュースを取得しフォーマットした後、ユーザにメッセージを送ります。具体的な詳細は説明しませんが、NewsAPICollectorというクラスでNewAPIをラッピングしています。

GitHub Issueだけで自分のルーティングを管理し、そして草を生やす

Wed, 02 Nov 2022 00:00:00 +0000

先日シェルスクリプトで個人ナレッジマネジメントツールを作った話しを投稿して、予想以上に需要がありました。

ルーティングをGitHub Posterに生成

似たような発想でルーティング管理アプリを使わずに、GitHubのcontributionsのように自分のルーティング（例えば読書、ランニング、LeetCode、外国語の勉強）を管理できると面白くない？と思いながら、GitHub上で検索したらyihong0618さんが開発したGitHubPosterを発見しました。

https://github.com/yihong0618/GitHubPoster

GitHub Isssue、Duolingo、Twitter、Kindleなど20個以上のAPIで履歴を取得し、GitHub svg poster（aka. 皆さんが大好きなGitHubの草）を生成します。

実際使ってみよう

ローダーは20個以上あり、とりあえずissueで今年年始以来の読書ルーティングの草を生やしてみました。

Issueを書く

issueフォーマットは↓に従う必要でがあります。

{整数}

{内容}

今年は1月から、日課をこなした日に当該Issueに↓のコメント追加していました。

2

「データ指向アプリケーションデザイン」

環境構築

pip install -U 'github_poster[all]'

実行

GitHubをトークンを取得し、下記コマンドを実行するだけです。

github_poster issue --issue_number ${issue_number} --repo_name ${repo_name} --token ${github_token}

また、オプション

--special-color1
--special-color2
---stand-with-ukraine

などによって色を指定することも可能です。（ウクライナをサポートする配色もあるようですね）

結果

最終的に生成されたGitHub Poster（.svgファイル）はこんな感じです。単位はtimes（回数）になっているが、hours（時間）が正しいです。

確認してみると、今年今まで336時間読書していて、週の真ん中あまり本を読んでいないと気づきました。

使った感想

余計なモバイルアプリを使わずに、ルーティング管理できるのはミニマムリスト的には最高
生成されたファイルは.svgなので、自分のサイトや他のところに取り入れるのも簡単そう
新しいローダーの開発に貢献してみたい

Airflowで構築したワークフローを検証する

Tue, 01 Nov 2022 00:00:00 +0000

データ基盤の監視

データ基盤は下流の分析・可視化・モデリングの「基盤」となるので、監視は言うまでもなく品質を担保するため重要な存在です。データ基盤監視の考え方についてこの2つの記事が紹介しています。 https://tech-blog.monotaro.com/entry/2021/08/24/100000 https://buildersbox.corp-sansan.com/entry/2022/08/18/110000 同じくSQLによるデータ基盤を監視しており、最も大きな違いは自作ツールかAirflowで検証することだけです。本文はAirflowで構築したワークフローの検証についてもう少し紹介したいと思います。

まず、Data Pipelines Pocket Referenceではデータ基盤検証の原則が紹介されました。

Validate Early, Validate Often

要はできるだけ早く、できるだけ頻繁に検証するとのことです。ELTあるいはETL処理においては、Extract, Load, Transformそれぞれのステップが終了した直後に監視するのは最も理想的だと思います。

Transformはデータセットのコンテキストを把握しておかないと検証できないため、データセットごとに対応していく必要があります。ExtractとLoadはnon-contextで汎用的な検証ができるため、データ基盤構築の序盤からやっておいた方が安心だと思います。

Extractの検証

ストレージサービス（例えばGCS）をデータレイクにする場合、データソースからデータレイクにデータがちゃんとレプリケートされたかを検証するためにAirflowのairflow.providers.google.cloud.sensors.gcsを利用すると簡単にできます。

https://airflow.apache.org/docs/apache-airflow-providers-google/stable/_api/airflow/providers/google/cloud/sensors/gcs/index.html

一つのファイルをチェックする場合はほとんどないと思うので、GCSObjectExistenceSensorよりGCSObjectsWithPrefixExistenceSensorの方がもっと実用的でしょう。下記のタスクをExtractと次の処理の間に挟むと、障害の早期発見が期待できます。なお、Extract時点で既に障害が起きている場合はほとんどデータソース側の処理が失敗しているので、アプリケーション側と連携して作業する必要があります。

check_extract = GCSObjectsWithPrefixExistenceSensor(
 task_id="check_extract",
 bucket="{YOUR_BUCKET}",
 prefix="{YOUR_PREFIX}",
)

Loadの検証

ELTとETL処理、Loadするタイミングは異なりますが、検証の方法（データがデータウェアハウスあるいはデータマートにロードされたか）は同じです。よく使われているデータウェアハウスサービスBigQueryだと、Airflowのairflow.contrib.operators.bigquery_check_operator.BigQueryCheckOperatorを利用できます。

https://airflow.apache.org/docs/apache-airflow/1.10.10/_api/airflow/contrib/operators/bigquery_check_operator/index.html#airflow.contrib.operators.bigquery_check_operator.BigQueryCheckOperator

下記のタスクをLoad処理の後ろに追加すれば良いです。

check_load = BigQueryCheckOperator(
 task_id="check_load",
 sql={YOUR_SQL},
 use_legacy_sql=False,
 params={
	"bq_suffix": Variable.get("bq_suffix"),
	"dataset": setting.bq.dataset,
	"table": setting.bq.table_name,
 },
 location="asia-northeast1",
)

SQLは検証用のクエリとなっており、BigQueryのメタデータテーブルがよく用いられます。例えばこの記事が紹介されたクエリでテーブルが空になっているかを確認できます。

SELECT
 total_rows
FROM
 ${dataset_id}.INFORMATION_SCHEMA.PARTITIONS
WHERE
 table_name = '${table_name}'
ORDER BY
 last_modified_time DESC
LIMIT 1;

GCPについて簡単に説明しましたが、AWSとAzureも似たようなことはできるはずです。皆さんのワークフロー設計にご参考になれば幸いです。

自作PythonラッパーでGoogleグループのメンバーシップをより便利に管理する

Sun, 02 Oct 2022 00:00:00 +0000

Googleグループのメンバーシップを管理する方法

Googleグループを管理するのは

Workspaceのadmin SDKを利用する

https://developers.google.com/admin-sdk/directory/v1/guides/manage-groups

CLI gcloudを利用する

https://cloud.google.com/sdk/gcloud/reference/identity/groups/memberships

Cloud Identity APIを叩く

https://cloud.google.com/identity/docs/how-to/setup

3つの方法があります CLI gcloudはCloud Identity APIを叩いているので、方法2と方法3は実質同じです。

方法1との違いはなんでしょう？ドキュメント読んで実際に試したところ、大きな違いは

WorkspaceはGCPで作ったサービスアカウントをメンバーとして追加できない（それはそう）
gcloudあるいはCloud Identity APIだと有効期限付きでメンバー追加することが可能

Googleグループによってセンシティブな情報のアクセス制御する際に、有効期限付きでメンバー追加する機能を利用すると、セキュリティを担保できるので、使い勝手がかなり良いと思います。

シェルスクリプトを書いてGoogleグループ管理を自動化する場合であれば、ローカル環境やリモート環境（EC2やCloud Runなどを含めて）問わず、gcloudは断然便利です。下記のコマンドで一発aliceさんを1時間有効期限付きでグループgroup_name@email.comに追加できます。

gcloud identity groups memberships add --group-email="group_name@email.com" --member-email="alice@email.com" --expiration='1h'

一方、アプリケーションなどに組み込みたい場合は、Cloud Identity APIを叩くことになります。現時点（2022.10.1）Cloud IdentityはBigqueyなどのサービスのような公式SDKが存在しなく、APIのドキュメントも若干わかりづらいので、この度より便利にアプリケーションからGoogleグループを管理するために、Pythonラッパーを作ってみました。簡単に修正すれば他言語でも利用できる（はず）です。

Pythonラッパー

認証　

Cloud Identity APIを叩くのに、言うまでもなく認証が必要です。キーによる認証は公式のドキュメントにあるため、コピペすればOKです。

https://cloud.google.com/identity/docs/how-to/setup

アプリケーションをCloud Runなどにデプロイしている場合、キーを使わずにサービスアカウントとして認証する方法もあります。

from httplib2 import Http

from oauth2client.client import GoogleCredentials
from googleapiclient.discovery import build


def create_service():
 credentials = GoogleCredentials.get_application_default()

 service_name = "cloudidentity"
 api_version = "v1"
 return build(
 service_name,
 api_version,
 http=credentials.authorize(Http()),
 cache_discovery=False,
 )

Group IDとMembership ID

実際にメンバーシップを取得するAPIを叩いてみたらわかると思います。memberships_idとgroup_idによってメンバーシップのnameが決められます。後ほどグループからメンバーを削除する際に、ここのnameが必須です。

AirflowのBigQueryInsertJobOperatorのオプションについて

Tue, 30 Aug 2022 00:00:00 +0000

先日「AirflowでGCS外部パーティションテーブルをBigQueryに取り込む方法」についての記事を書きましたが、BigQueryInsertJobOperatorにフォーマットのオプションを追加する際に、実際の挙動は公式ドキュメントの記述と若干違うので、追記しておきます。

なぜ気づいたのか

外部テーブルを取り組む際に、閉じるカッコが見つからないというエラーが出て、

Error detected while parsing row starting at position: 4204. Error: Missing close double quote (") character.

調査してみた結果、改行記号が含まれているのが原因のようでした。stack overflowによるとallowQuotedNewlinesといったCSVのオプションを追加すると解決できるらしいです。

https://stackoverflow.com/questions/65782572/how-to-avoid-missing-close-double-quote-character-error-in-google-bigquer

https://qiita.com/sawanoboly/items/410b3346518e569da581

ただし、configurationにcsvOptionsを追加しても解決されず（同じエラーが出た）、困っていました。

configuration={
 "load": {
	"destinationTable": {
	 "projectId": PROJECT_ID,
	 "datasetId": DATASET_NAME,
	 "tableId": TABLE,
	},
	"sourceUris": ["gs://my-bucket/biostats/*.csv"],
	"autodetect": True,
	"sourceFormat": "CSV",
	"hivePartitioningOptions": {
	 "mode": "AUTO",
	 "sourceUriPrefix": "gs://my-bucket/biostats/",
	},
	"csvOptions": {
	 "allowQuotedNewlines": True
	 },
 }
},

解決法

CLI bq loadを利用す際にどうなっているかを確認したら、どうやらcsvOptionsを明示的に書く必要がなく--allow_quoted_newlinesだけ追加すとでうまくいきました。AirflowのBigQueryInsertJobOperatorで同じことをすると、問題なくloadできました。

configuration={
 "load": {
	"destinationTable": {
	 "projectId": PROJECT_ID,
	 "datasetId": DATASET_NAME,
	 "tableId": TABLE,
	},
	"sourceUris": ["gs://my-bucket/biostats/*.csv"],
	"autodetect": True,
	"sourceFormat": "CSV",
	"hivePartitioningOptions": {
	 "mode": "AUTO",
	 "sourceUriPrefix": "gs://my-bucket/biostats/",
	},
	# csvOptionsの記述は不要 
	"allowQuotedNewlines": True
 }
},

Cloud ComposerのDAGでデータ基盤の転送パイプラインを監視

Thu, 18 Aug 2022 00:00:00 +0000

会社のTech Blogに記事を書きました

AirflowでGCS外部パーティションテーブルをBigQueryに取り込む方法

Thu, 21 Jul 2022 00:00:00 +0000

GCS外部パーティションテーブルをBigQueryに取り込む

BigQueryでデータレイクを構築する際に、GCS、Google Drive Data、Bigtableから外部テーブルを取り組む場面は少なくないと思います。下記のような外部テーブルがパーティションで分けられている場合(Hive partitioned dataと呼ばれている)は少しややこしくなりますが、

gs://myBucket/myTable/dt=2019-10-31/lang=en/foo
gs://myBucket/myTable/dt=2018-10-31/lang=fr/bar

公式ドキュメントは取り組み方をわかりやすくまとめてくれています。bqというcliでコマンド2行で解決できます。

https://cloud.google.com/bigquery/docs/hive-partitioned-queries-gcs#partition_schema_detection_modes

テーブル定義を作成

bq mkdef \
 --autodetect \
 --source_format=CSV \
 --hive_partitioning_mode=AUTO \
 --hive_partitioning_source_uri_prefix=gs://your-bucket/your-table/ \
 "gs://you-bucket/you-table/*.csv" > /tmp/MyTableDefFile

テーブルを作成

bq mk --external_table_definition=/tmp/MyTableDefFile \
 my_dataset.my_table

Airflowで取り込むとどうなる？

まず、簡単に背景を補足すると現在筆者が構築しているデータ基盤はCloud Composer (Airflow)でワークフローを管理しており、AirflowでGCSから外部テーブルを取り込むといった需要があります。パーティションではない普通のテーブルであれば、BigQueryCreateExternalTableOperator利用すると一発で解決できます。しかし、パーティションのある場合はAirflowから事前用意された関数がなく（2022年7月時点）、他の方法を考えないといけないです。

GCP公式ドキュメントもConosole, bq, API, Java 4つの方法しか書いておらず、PythonのSDKはまだ実装されていないようです。 https://cloud.google.com/bigquery/docs/hive-partitioned-queries-gcs#creating_an_external_table_for_hive_partitioned_data

`BigQueryInsertJobOperator`を利用

いろいろ調査した結果、筆者と同じことに困っている人がいたようです。

https://github.com/apache/airflow/issues/13626

その下に

Have you tried to use BigQueryInsertJobOperator? for example, see: #13598

「BigQueryInsertJobOperatorを使ってみたらどう？」というコメントがありました。さらにリンク先のPR（なぜかクローズされた）に行くと、BigQueryInsertJobOperatorの例をまとめてもらっています。どうやら専用のSDKがない場合BigQueryInsertJobOperatorを使うのは普通らしいです。引数もやや雑で、そのままBigQueryのREST APIに叩くのと近い感じです。

https://airflow.apache.org/docs/apache-airflow-providers-google/stable/_api/airflow/providers/google/cloud/operators/bigquery/index.html#airflow.providers.google.cloud.operators.bigquery.BigQueryInsertJobOperator

https://github.com/apache/airflow/pull/13598/files

しかしながら、上記のPRは外部パーティションテーブルを取り組む例がなかったため、BigQuery APIのドキュメントを調べて、hivePartitioningOptionsというオプションを見つけました。これを追加すると、もしかしてうまくいくのではないかと思い、早速検証してみました。

https://cloud.google.com/bigquery/docs/reference/rest/v2/tables#hivepartitioningoptions

データを用意

https://people.math.sc.edu/Burkardt/datasets/csv/csv.html から適当にcsvファイルをダウロードします。

git switch, git restore, git grep, git blameを使ってみよう

Sun, 10 Jul 2022 00:00:00 +0000

https://git-scm.com/

毎日息を吸うようにgitを使っているけど、gitのドキュメント見たことないなと思って実際に読んでみました。あまり使われていないが、便利そうなgitコマンドを見つけたので、共有します。

git switch
git restore
git grep
git blame
git log -p <filename>
git commit --amend --no-edit

`git switch`

ブランチを切り替えるコマンドです。git checkoutでできるのに、なぜわざわざgit switchを使うのかって思っていましたが、この記事を読んで意図を理解しました。

https://www.banterly.net/2021/07/31/new-in-git-switch-and-restore/

簡単に説明するとgit checkoutは

git checkout <branch_name> ブランチ・コミットを切り替える
git checkout -- <file_name> ファイルの変更を廃棄する（直近のcommitに戻す）

2つの機能を持っているので、少し紛らわしいですね。数年前初めてgitを勉強した頃、けっこうハマっていた記憶があります。 version 2.23にブランチ・コミットを切り替える機能のみ持っている機能git switchがリリースされました。

# git checkout your_branchと同じ
git switch your_branch

ただ、新しくブランチを切る際のオプションは-bではなく、-cになっています。

# git checkout -b your_branchと同じ
git switch -c new_branch

`git restore`

git restoreは、ファイルの変更を廃棄して、直近のcommitに戻すというgit checkoutの残り半分の機能を持っています。

# git checkout -- file.txtと同じ
git restore -- file.txt

git checkoutをやめてgit switchとgit restoreを使ったほうがわかりやすいと思います。特に初心者の方はぜひ試してみてください。

Cloud FunctionsにおけるSlack APIの3秒レスポンス問題の対処法

Sun, 12 Jun 2022 00:00:00 +0000

Slack APIはUXのため著名な3秒レスポンスルールを設けています。初期設定のようなものではなく、自ら伸ばすことはできません。（厳しい）

https://api.slack.com/interactivity/slash-commands

If you need to respond outside of the 3 second window provided by the request responses above, you still have plenty of options for keeping the workflow alive.

Slack Appsを開発したことのある人にとって最初は少し戸惑うでしょうか。（筆者はそうでした。）最近はCloud Functionsとslack boltで社内の承認アプリを開発していて、試行錯誤した経験を共有したいと思います。

経緯

実装する予定のアプリの最初のステップとして、ショートカットでCloud Functionsを発火させてmodalを開きます。slack boltのドキュメントを読んで、以下の実装をおこないました。

https://slack.dev/bolt-python/concepts

（一部のコード）

@app.shortcut("/hogehoge")
def open_application_modal(ack, body: dict, client: WebClient):
 ack()

 result = process()
 client.views_open(
 trigger_id=body["trigger_id"],
 view={
 "type": "modal",
 # View identifier
 "callback_id": "application_form_view",
 "title": {"type": "plain_text", "text": "APP Title"},
 "submit": {"type": "plain_text", "text": "Submit"},
 "blocks": create_blocks(result),
 },
 )

# ....

しかし、最初ショートカットをクリックしてmodalが出てこないが、数回試してみたら出てくるという謎な事象が起きていました。modal出てからのステップ（申請フォーマットの提出、Google APIを叩く処理）は正常に動作します。

Cloud Functionsのログを調べてみたら、expired_trigger_idが出ているので、トリガーの有効期限が切れて、3秒レスポンスルールを違反しているようです。

Cloud Functions 2nd Genにおけるsecret keyの管理

Wed, 01 Jun 2022 00:00:00 +0000

GCPのFaaS(Functions-as-a-Service)Cloud Functionsは最近第二世代がリリースされ、（まだbeta期間中ですが）インフラ周りがけっこう強化されました。Cloud StorageとBigQueryにある大規模データを処理するために、HTTPトリガーのアップタイムが60分までに、イベントトリガーも10分まで伸びました。

https://cloud.google.com/functions/docs/2nd-gen/overview

筆者はこの数週間ちょうどCloud Functionsを利用して承認システムを開発しています。Cloud Functions 2nd Genにおけるsecret keyの管理について少し困っていたので、調べたものを共有します。

何が問題か

secret keyなどを明文でCloud Functionsの環境変数に保存するは流石に危ないので、他の方法が必要です。

we recommend that you review the best practices for secret management. Note that there is no Cloud Functions-specific integration with Cloud KMS.

Cloud Functions公式ドキュメントによると、secret keyを管理するベストプラクティスはSecret Managementを利用することです。また、Cloud Functions特有のCloud KMSは存在しません。

https://cloud.google.com/functions/docs/configuring/env-var#managing_secrets

1st genの場合はデプロイする際に-set-secretsというオプションでSecret Management上保存しているキーを追加すれば良いですが、2nd genで同じようなことをやると、-set-secretsはまだ実装されていない（2022年5月）ので、怒られます。

ERROR: (gcloud.beta.functions.deploy) --set-secrets is not yet supported in Cloud Functions V2.

Cloud KMSを使う

Secret Managementはまだ存在しない時代（と言っても3年前）に書かれた記事を読んで、参考になりました。

考え方としては、

Cloud KMSで認証情報(文字列)を暗号化する

暗号化した認証情報をCloud Functionsの環境変数に登録する

Cloud Functionsの関数内で暗号化された環境変数を復号化する

https://www.apps-gcp.com/kms-with-functions/

TerraformでCloud Storageのバケット名を変更する際の罠

Fri, 27 May 2022 00:00:00 +0000

最近よくデータ基盤構築の仕事をしているため、TerraformでGCPをいじったりしています。今回はCloud Storageのバケット名を変更する際に罠にはまりやすいところを紹介します。もちろん、Cloud Storageだけでなく、他のサービスやAWSなどにも活用できそうな箇所があるではないかと思います。

環境

Terraform v1.1.2
on darwin_arm64
provider registry.terraform.io/hashicorp/google v4.15.0

他の環境は正しく動作するかは未検証です。

経緯

下記のバケットを作って検証環境に反映した後、PRを出しました。

resource "google_storage_bucket" "my_bucket" {
 name = "my-bucket"
 storage_class = var.gcs_storage_class.coldline
 project = var.project_id
 location = var.gcs_location
 force_destroy = false
 uniform_bucket_level_access = true

 retention_policy {
 is_locked = true
 retention_period = 30
 }



 lifecycle_rule {
 condition {
 age = 30
 }
 action {
 type = "Delete"
 }
 }
}

チームメンバーのレビュー受けて、バケット名はmy-bucketよりmy-bucket-hogeの方が良いと言われたので、my-bucketをmy-bucket-hoge変更しterraform applyしたらエラーになりました。もちろんのことですが、最初はforce_destroy = falseに設定していて、バケット内オブジェクトが入っているので、強制変更はできません。

force_destroy - (Optional, Default: false) When deleting a bucket, this boolean option will delete all contained objects. If you try to delete a bucket that contains objects, Terraform will fail that run.

解決方法を二つ見つけました。

データ基盤におけるGitHub Actionsを使ったTerraformとCloud ComposerのCI/CD

Mon, 16 May 2022 00:00:00 +0000

会社のTech Blogに記事を書きました

データ基盤におけるGitHub Actionsを使ったTerraformとCloud ComposerのCI/CD

ワードクラウドを自作ニュースアプリに追加してみた

Sat, 14 May 2022 00:00:00 +0000

はじめに

この間Node.jsで多言語Webニュースアプリ作ってみました

https://www.multitrue.news

ニュースのタイトルと概要だけではつまらないので、単語の出現頻度によって直近一週間のニュースからワードクラウド作って、一目で世の中の出来事を確認できたら面白そうじゃないかと思いながら、ワードクラウドをニュースアプリに追加してみました。

詳細

ソースはこちらから確認できます。

https://github.com/jckinjo/multitrue

下準備

日本語と中国語などは英語と異なり、単語と単語の間スペースがないので、形態素解析が必要です。簡略化するために、今回は英語のワードクラウドのみを作ることにしました。人称代名詞や助動詞のようなStop Wordsをワードクラウドに出しても意味がないので、NLTKの英語Stop Words辞書を利用します。

https://gist.github.com/sebleier/554280

また、単語の出現頻度を集計するヘルプ関数を作成します。いい感じライブラリもありますが、できるだけdependencyを減らしたいので、自分で実装することにしました。ただ、全ての単語を最終的に大文字に変換します。

src/utils/countWordsFrequency.js

const stopwords = require('./stopwords-en.json');

// English stopwords via https://gist.github.com/sebleier/554280
const countWordsFrequency = (sentences) => {
 const result = {};

 // remove punctuation and split by space
 const terms = sentences.toLowerCase().match(/[a-zA-Z]+/g);

 terms.forEach((e) => {
 if (!stopwords.stopwords.includes(e)) {
 const name = e.toUpperCase();
 if (result[name]) {
 result[name] += 1;
 } else {
 result[name] = 1;
 }
 }
 });
 return Object.entries(result)
 .map(([key, value]) => ({
 name: key,
 value,
 }))
 .sort((a, b) => b.value - a.value);
};

module.exports = countWordsFrequency;

ニュース記事の単語出現頻度を計算

続いて、英語ニュースを収集するcontrollerに単語頻度を計算するロジックを組み込みます。今回利用しているNewsAPIはニュースの本文を取得できないため、タイトルと概要から単語出現頻度を計算し、ニュース・メタ情報と一緒にレスポンスに追加します。（収集期間のview-config.jsonから日単位で設定できます）今考えるとやはり単語出現頻度の計算とニュースの取得を分けたほうが良いかもしれません。

src/controllers/viewsController.js

exports.getHeadlinesUS = catchAsync(async (req, res) => {
 const news = await News.find({ category: 'general', country: 'us' })
 .sort('-publishedAt')
 .limit(viewConfig.limit);

 const articlesTitleDesc = await News.find({
 category: 'general',
 country: 'us',
 publishedAt: {
 $gt:
 Date.now() - viewConfig.wordscloud.dateRangeDay * 24 * 60 * 60 * 1000,
 },
 }).select('title description');
 const wordsFrequency = calcWordFrequncyInArticles(articlesTitleDesc);
 res.status(200).render('index', {
 countryMeta: {
 flag: '🇺🇸',
 title: 'Top Stories',
 code: 'us',
 },
 news,
 wordsFrequency,
 });
});

計算結果をフロントに渡す

echarts-wordcloudというライブラリでワードクラウドを描きます。 https://github.com/ecomfe/echarts-wordcloud

Herokuにデプロイする際のTips

Wed, 04 May 2022 00:00:00 +0000

2022年11月28日をもってHerokuフリープランが終了しました

https://blog.heroku.com/new-low-cost-plans

個人開発する際にコスト面と手軽さを考えるとAWSにデプロイするのはあまりふさわしくないでしょう。Herokuだともっと手軽くデプロイできるし無料枠もあるので、個人で開発したおもちゃをデプロイするのはちょうどいい感じだと思います。この間筆者が開発した多言語WebニュースアプリもHerokuにデプロイしています。

本記事では、Herokuにデプロイする際のTipsをいくつかを紹介したいと思います。少しでもお役に立てれば幸いです。

Tip 1: GitHub Actionsで自動デプロイ

https://devcenter.heroku.com/articles/git

コマンドラインでいちいち打つのは面倒くさいので、自動デプロイしたほうが断然便利ですね。もちろんHerokuのGUIからも自動デプロイできますが、せっかくソースコードもGitHubで管理しているので、GitHub Actions を使ったほう便利だと思います。

heroku-deployというアクションを利用すると、Herokuのメールアドレスとheroku_api_keyさえわかれば、GitHub Actionsから自動デプロイできます。ちなみに、heroku_api_keyはこちらから取得できます。 GitHub Actionsの設定についてですが、他の記事を見たかぎりon: [push, pull_request]に設定している方もいました。本番にデプロイするという意味合いもあるので、個人的にはrelease（リリース作成するたびに、パイプラインが発火される）に設定したほうがいいではないかと思います。ミスってpushしちゃったのも防げます。

on:
 release:
 types: published

name: Deploy to PROD

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v2
 - uses: akhileshns/heroku-deploy@v3.12.12
 with:
 heroku_api_key: ${{secrets.HEROKU_API_KEY}}
 heroku_app_name: 'your_app_name'
 heroku_email: ${{secrets.HEROKU_EMAIL}}

Tip 2: 無料枠を使いこなす

現時点(2022年5月)Herokuのプランはこうなっています。

Creating a Personal Knowledge Management Tool with Just a 15-Line Shell Script

Tue, 03 May 2022 00:00:00 +0000

Introduction

When reading books or articles, you may want to systematically manage the notes you’ve written. Currently, there are many excellent knowledge management tools available.

Confluence
Notion
HackMD
Boost Note

There are countless tools when you also include mind mapping tools. I am a minimalist and has the following preferences:

Manage personal notes like code on Github
View notes in a mind map format from the web
Use a free tool instead of a subscription-based service

Thererfore, I came up with the idea of creating a custom personal knowledge management tool. As a result, I only used a 15-line shell script, GitHub Actions, and the Markdown mind map conversion tool Markmap to create it.

M1 Mac (macOS Monterey 12.2.1)でpyenv/Python開発環境構築

Fri, 22 Apr 2022 00:00:00 +0000

はじめに

先日M1のMBPを入手したので、早速Pythonの開発環境を構築しました。 Intel Macと比べて大きく違うので、昔メモったIntel Macの環境構築手順が使えなくなり、新しく環境構築の記事を書こうと思いました。少しでもお役に立てれば幸いです。

この記事では

Homebrewは使わないで！（動くけど難易度高い） pyenvは使わないで！（動かない=2021年2月時点）

と記述していましたが、おそらく2021年2月時点ではHomebrewやpyenvなどはまだM1 Macに対応していない（？）と考えられます。現在(2022年4月)では、少し設定は必要ですが、問題なく動作できるようになりました。

Homebrew

まずはHomebrewをインストールします

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)

M1 MacではHomebrewによってインストールされたパッケージは/usr/local/bin/hogeではなく、/opt/homebrew/bin/hoge保存されるので、brewをインストールした後は環境変数を設定する必要があります。

以下を.bashrcか.zshrcに追加して、ターミナルを再起動すると、brew installは問題なく動作します。

export PATH=/opt/homebrew/bin:$PATH
export PATH=/opt/homebrew/sbin:$PATH

fishユーザはこれを実行してください。

set PATH /opt/homebrew/bin /opt/homebrew/sbin $PATH

pyenv

pyenvとvirtualenvをインストールします

brew install pyenv
brew install pyenv-virtualenv

ここまでは問題ないはずです。

続いてバージョンしてPythonをインストールします。たとえば Python 3.8.12

pyenv install 3.8.12

しかし、うまくいきません

pyenv install 3.8.12
python-build: use openssl@1.1 from homebrew
python-build: use readline from homebrew
Installing Python-3.8.12...
python-build: use readline from homebrew
python-build: use zlib from xcode sdk

BUILD FAILED (OS X 12.2.1 using python-build 20180424)

Inspect or clean up the working tree at /var/folders/f1/3g092d_11zl8xnf67bp0n79r0000gp/T/python-build.20220318172446.23811
Results logged to /var/folders/f1/3g092d_11zl8xnf67bp0n79r0000gp/T/python-build.20220318172446.23811.log

Last 10 log lines:
checking for --with-cxx-main=<compiler>... no
checking for clang++... no
configure:

 By default, distutils will build C++ extension modules with "clang++".
 If this is not intended, then set CXX on the configure command line.
 
checking for the platform triplet based on compiler characteristics... darwin
configure: error: internal configure error for the platform triplet, please file a bug report
make: *** No targets specified and no makefile found. Stop.

いろいろ調べた結果、 https://issueantenna.com/repo/pyenv/pyenv/issues/2284

Web開発ど素人がNode.jsで多言語Webニュースアプリ作ってみた

Mon, 18 Apr 2022 00:00:00 +0000

目的

筆者自身はトリリンガル（自称）のため、簡単に日本語、英語、中国語などの複数の言語のホットニュースを読めるサービスががあると便利だなとずっと思っていました。「Google Newsで良くない？」って言われそうなところですが、Google Newsはやや使いづらいと感じました。

例えば、

言語を切り替えるのに「言語地域→候補から選ぶ→更新」3回クリックする必要がある
本当にヘッドライトしか閲覧したくないのに、「おすすめ」や「ピックアップ」などがうるさい
モバイルのweb版が見づらい・アプリをダウンロードしたくない
芸能ニュースにまったく興味がないため、ニュースの表示をカスタマイズしたい

また、やってみないと（何かを残さないと）学んだ技術をすぐ忘れるのはもったいないのも考えて、多言語ニュースWebアプリを自作するという発想に至りました。

使った技術

バックエンド
- NodeJS
- Express
フロントエンド
- インタラクションがほぼないため、フレームワークは使っておらず、DOMをいじっただけ
- CSSはStart Bootstrapの無料テンプレートを使用
DB
- MongoDB
インフラ
- Heroku

コスト

毎月7ドルだけです！！（Heroku Hobbyの料金）

成果物

https://www.multitrue.news

https://github.com/jckinjo/multitrue

それでは、詳細を解説していきます。

下準備

ニュースはどこから収集するか

最初はニュース収集するかについてけっこう時間を費やしました。ニュース関連のAPIがかなり多いですが、

ある程度の無料枠がある
多言語のニュースが簡単に取れる
使いやすさ

3つの観点から考えて、NewsAPIとNews dataの2つのAPIに絞りました。ただ、後々News dataは言語を指定しても他の言語のニュースが混ざっていることがあると気づいたので（例えば、言語を日本語と指定したにも関わらず、日本関連の英語ニュースが出てくる）、NewsAPI一択となりました。ちなみに、こちらの記事はNewAPIについて詳しく説明しています。また、RSSなど他の人が作ったニュースAPIを使わないという方法もあるようですが、今回は試していなかったです。