海外Clojureエンジニアポジションの持ち帰り課題を晒してみる

ハイレベルには

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

という構成を取った。

戦略としては学習ができるヤツという事を示したかったので積極的に馴染みが薄い物に手を出した。

結果駄目でも何かは身につけば勝ちみたいなメンタル

table: 採用した vs 馴染み/定番

採用した 馴染み/定番

aleph/yada jetty/rign/reitit

juxt/clip integrant

cucumber/cypress/pact 普通のユニットテスト(clojure.test)

GitHub Registry あんまり触らない領域

どうなったか

好評だった

学び|感想

学習を軸に取り組んだので書く

aleph

エラーが発生するとnettyベースの詳細が急に露出して見慣れない領域に飛ばされる

yada

前職で使用されていて苦手意識があり克服したかった

(ミドルウェアモデルに対して)インターセプターモデルなのは結構だが、デフォルトのインターセプターが何をしてくれるのか良く分からなかった。自前のインターセプターともどう相互作用するのかも自明でなかった。

デフォルトのインターセプターを外して、自分で必要な物だけ指定するみたいな事をした

juxt/clip

良い

integrantに対する批判として、コンポーネントをどの用に作るか、とそのコンポーネントをシステムでどう呼ぶか、がコンプレクトしている点 (ig/init-key) がある。

{:some.ns.core/component {:foo #ig/ref :some.other.ns.core/component}...}

juxt/clipは

コンポーネントをどの用に作るか => どこぞのnsにある関数を指定する

そのコンポーネントをシステムでどう呼ぶか => 任意のkey

という感じで非常にこれで良い感をとても感じた

{:foo \`(d/create) :compoent {:foo '(clip/ref :foo)} }

本当にテクニカルでない人と開発者の溝が文法とかプログラミング言語に限られるのであれば役には立つかもしれないが、得てしてテストでカバーするべき物を考えるのも開発者なのではというバイアスがあり、個人的にはわざわざプログラミング言語でないシンタックスに翻訳するオーバーヘッドに見合うという判断にはならない

cypress/k6

cypress =>ブラウザベースのテストを現代で実行するには定番

k6 => ロードテスティング!

宣伝の通りのことに使える、期待を満たすツール

pact

サーバーを既知の状態に設定する開発用のエンドポイントが必要だったりする

--provider-states-setup-url http://localhost:8080/pact-setup/

GitHub Actions

直ぐquotaに達してしまう(private repoの場合?)

GitiHub Registry

dockerイメージの保存に使用していた

直ぐquotaに達してしまう

それでは良いお年を!