海外Clojureエンジニアポジションの持ち帰り課題を晒してみる
2023年は求職(@米国)をしていた年で、縁の無かったポジションのインタビューの過程で取り組んだ晒しても問題が無いと判断したClojureのプロジェクトがあったのでClojure Advent Calendar 2023の2日目の記事として晒す。
ハイレベルには
kubernetesで動く
crud api backend (Clojure)
frontend (cljs)
test
ci/cd
repl driven development
が要素として要求されていた。
アンサーとして
kubernetesで動く => minikube
api crud backend => aleph/yada/next.jdbc/honeysql
frontend => helix
test => cucumber/cypress/pact/k6
ci/cd => GitHub Actions + GitHub Registry
repl driven development => juxt/clip
という構成を取った。
戦略としては学習ができるヤツという事を示したかったので積極的に馴染みが薄い物に手を出した。
結果駄目でも何かは身につけば勝ちみたいなメンタル
採用した 馴染み/定番
aleph/yada jetty/rign/reitit
juxt/clip integrant
cucumber/cypress/pact 普通のユニットテスト(clojure.test)
GitHub Registry あんまり触らない領域
どうなったか
好評だった
学び|感想
学習を軸に取り組んだので書く
aleph
エラーが発生するとnettyベースの詳細が急に露出して見慣れない領域に飛ばされる
yada
前職で使用されていて苦手意識があり克服したかった
(ミドルウェアモデルに対して)インターセプターモデルなのは結構だが、デフォルトのインターセプターが何をしてくれるのか良く分からなかった。自前のインターセプターともどう相互作用するのかも自明でなかった。
デフォルトのインターセプターを外して、自分で必要な物だけ指定するみたいな事をした
juxt/clip
良い
integrantに対する批判として、コンポーネントをどの用に作るか、とそのコンポーネントをシステムでどう呼ぶか、がコンプレクトしている点 (ig/init-key) がある。
で皆で深いネームスペースで
(defmethod ig/init-key ::some-component [_ _]) とかやるのでシステムマップが読むの辛い感じになりがち {:some.ns.core/component {:foo #ig/ref :some.other.ns.core/component}...} juxt/clipは
コンポーネントをどの用に作るか => どこぞのnsにある関数を指定する
そのコンポーネントをシステムでどう呼ぶか => 任意のkey
という感じで非常にこれで良い感をとても感じた
{:foo `(d/create) :compoent {:foo '(clip/ref :foo)} } cucumber/bdd
テクニカルでない人間が怖がらない文法で記述されたテストデータ(をパースしたデータ)に対してテストを書く
本当にテクニカルでない人と開発者の溝が文法とかプログラミング言語に限られるのであれば役には立つかもしれないが、得てしてテストでカバーするべき物を考えるのも開発者なのではというバイアスがあり、個人的にはわざわざプログラミング言語でないシンタックスに翻訳するオーバーヘッドに見合うという判断にはならない
cypress/k6
cypress =>ブラウザベースのテストを現代で実行するには定番
k6 => ロードテスティング!
宣伝の通りのことに使える、期待を満たすツール
pact
サーバーを既知の状態に設定する開発用のエンドポイントが必要だったりする
--provider-states-setup-url http://localhost:8080/pact-setup/ GitHub Actions
直ぐquotaに達してしまう(private repoの場合?)
GitiHub Registry
dockerイメージの保存に使用していた
直ぐquotaに達してしまう
それでは良いお年を!
