はてなブックマーク

はじめに こんにちは、majimaccho です。 読者の皆さんは最近、DI（Dependency Injection：依存の注入）してますでしょうか。 DI は素晴らしい仕組みである一方で全く DI しない Ruby on Rails のようなフレームワークが支配的な時代もありました。 それでも DI は今でも有用な考え方として残っている中で、DI にどう向き合っていけばいいのでしょうか。自分なりに考えをまとめるために調べてみたので、同じような疑問を持っている方に参考になれば幸いです。 TL;DR 単純にコード量が増加することに加え、DI の仕組み自体が複雑さを内包しているので開発生産性が低くなることがあります。そのため、DI は言語によっては局所的かつ限定的に利用する方が良い場合があります。 いくつかの工夫によって DI が持つメリットを享受しつつ、不要な複雑さを排除して、シンプルかつ

これまで、型駆動設計を実践することが何を意味するのか、簡潔でシンプルな説明を見つけるのに苦労してきました。誰かに「どうやってこのアプローチを思いついたのですか？」と尋ねられることが多いのですが、満足のいく答えを出せないことがよくあります。そのアイデアが突然のひらめきで浮かんだわけではなく、正しいアプローチを空から引っ張り出す必要がない、反復的な設計プロセスがあると分かってはいるのですが、そのプロセスを他の人にうまく伝えることができていませんでした。 しかし、およそ1ヶ月前、JSON を静的型付け言語で、そして動的型付け言語にパースしたときに経験した違いについてTwitter上で振り返っていた時、ついに私が探していたものを見つけました。そして、そのスローガンはたった3つの英単語で表せます。 Parse, don’t validate (バリデーションせずパースせよ) 型駆動設計のエッセンス

tbls はいいぞ 🦍 筆者は tbls の大ファンであり、特に Viewpoints 機能が他のツールとは一線を画していると思っています。今回はその良さをお伝えできればと思います。 TL;DR tbls は実際のスキーマから DB のドキュメントを生成するツール ER 図が巨大化しても、tbls の Viewpoint ごとに分割することで DB の全体像が理解可能になる Viewpoint の粒度に困ったら一旦トランザクションと集計の単位に設定する 個別のテーブルと Viewpoint は相互に参照できる CI に組み込むことでドキュメンテーション忘れを防げる なんのために DB のドキュメンテーションを行うか DB のドキュメンテーションはそれなりにコストがかかるため、おざなりにされることも少なくありません。 しかし、下記のようなケースを考えるとドキュメンテーションは必須であると言