INTP型のブログ

苦味があるな?

最近の気になる技術

Rust

Solanaを触る過程で使い始めたんですけど、書き心地なかなか良いです。

 

それを支えるのはやはりrust-analyzerではあるので、これがなかったら無理ゲーな言語だなとは思います。

 

並列系の処理はパワフルだし、Result型によるエラーハンドリングの容易さ、非同期も書きやすいしいいトコ尽くし!!

 

…と言いたいところですが、堅牢さ故にjsonを扱うだけでもコード量が増えがちで、この辺はjavascriptpythonを書くときのあの軽い感じが恋しくなったりもします。

 

enumとstructが入れ子になっているような型を扱うときなんかはいちいちif letやmatchを書かなくちゃいけない点も重めです。enumきれいに書くには便利なんですけど、それを解いていく作業は重労働だなぁとか思います。

 

とはいえcrateの仕組みやドキュメントの充実具合、(この型の中身なんだろう?)ですぐさまそれを参照できるようになっている点。typescriptで色々実装するときに比べると諸々良いなとはやはり思います。

 

Deno

 

denoは少しだけ触ったんですけど、nodeを使うよりもシンプルにtypescriptなプロジェクトを書くことができる点が良かったです。node_modulesとかいうキモいディレクトリがないのもいいです。

 

とはいえnpm資産がでかすぎるので、色々考えるとnodeを使うことにはなっちゃうのですが……。

 

npmに対応したとは言えやっぱりそれは一部で、ブロックチェーン周りのsdkなんかはもれなく無理。悲しいですが、個人ブログを作るとかでもない限りは触ることないかもなーと思います。

 

(時間があればAI使った量産サイトにもう一度挑戦したくて、そのときはDeno使いたいなぁと思いますけど、優先度的には低いです)

 

テストコード関連

 

Rust使うようになってUnit Testを簡単にかけるようになった + 実務で単体テスト結合テスト、総合テストを手作業でやるようになって(せめてコードでやりてぇ…)という気持ちが強くなり、テストコード関連の知識が欲しくなったりしました。

 

現状はノリで単体テストコード書いたりしてますが、どうやるのがベストかいまいちピンときません。

 

そもそもテスト設計の部分がよくわかってないので当然と言えば当然な気もします。

 

今のところは関数単位で固定の引数を入れて期待値通りの結果になるのかぐらいです。

 

結合テストはフロントも交えることになるわけで、そうなるとJest?なるものを使うことになりそうなのですが、ちょっとこの辺分からず。いったんは放置状態です。

 

今は比較的手が空いてる時期なので、テスト関連はちゃんと学びたいなぁという気持ちがあります。

 

SRE

 

最近Google Cloudを個人的に使うようになって「クソ便利やんけ!」となったのですが、とはいえ良い使い方がわからず何とも言えない気持ちになってました。

 

とりあえずCloud Run使って「めっちゃ安くAPIサーバー動かせるやん^^」とニコニコしてたぐらいです。

 

SREはサイトリライアビリティエンジニアリングのことで、あまり良くわかってないですが運用においてモニタリングが大事->だからそれをいい感じでやる方法をまとめました。みたいな話っぽいです、知らんけど

 

もともとGoogle Cloudで面白そうな機能ないかなと探していて、オペレーションスイートなるものがあるらしいことを知り、SREという概念があるらしいということを知った感じでした。

 

大抵こういうのは大規模サービスでの話だとは思うのですが、グラフをいい感じに並べてニヤニヤするのが趣味なので、モニタリングをいい感じにやる技術らしいSREは最近気になる技術の一つです。

 

---

 

web系エンジニアになってから1年半がたち、コーディングで困ることは少なくなってきましたが、構成で困ることが多くなってきました。

 

アビトラBot開発を通じて

 

(最初の成果物はひとまず完成させるところを目的地にするからどうしてもしょぼくなりがち。それはそれで良いムーブだと思うけど、そこから改修するときに構成が下手だとコストが掛かりすぎる)

 

みたいな悩みがありました。

 

ディレクトリ構成とかは正直そこまでの問題ではないと思っていて、どちらかというと機能単位で切り分けをしなかった結果、どこを消したら動かなくなるのかがわからなくなり、その影響調査でストレスがたまるし時間もかかる。みたいなのが問題に感じました。(あとは切り分けが下手で修正箇所が割と多いみたいなことになったり)

 

責務の分散はコーディングにおけるキーワードだなと思うし、ということは根拠も大事だよねと思うわけです。ノリでなんとなく大丈夫なラインを見極めることもできなくもないですが、失敗することも当然ありますし、そうすると手戻りが出て無駄が多い。

 

テストコードやモニタリングで根拠を用意した上で改修をするならノリでやるより確実だし早い。そういう意味でテストコード関連とSREは気になる技術です。きれいに書きやすい言語も影響範囲が読みやすいので改修が楽です。

 

責務の分散はいかに関数単位に切り分けていくか大事かなと、関数型プログラミングにおいてはそう思うので、最近はとりあえず機能単位で関数に切り出せオラオラという感じになってました。迷ったら関数にしておくイメージ。

 

やっていて思うのですが、自分はやはり経験しないと理解できない愚者タイプなので、愚直に色々やってみて「これいいな」「これだめだ」を経験しながら改善するのが早いのかなとか思ったりしました。どちらにせよ試す概念や知識がないので学習も必要なのですが

 

そんな感じの話でした、おわり。