概要 本記事は、スクラムを管理するアプリケーションをクリーンアーキテクチャの考え方で実装し、WebからもCLIからも動かせるようにしたという実践を紹介するものです。学習のための個人開発で作成したサンプルアプリケーションの設計と実装を適宜紹介することで、クリーンアーキテクチャに対する理解を深めることが目的です。 モチベーション なぜ現代の開発現場で定着しているクリーンアーキテクチャのアプリを手元で実装してみようと思ったかというと、私自身Webエンジニアとして働く中で、クリーンアーキテクチャの実践例は入出力をWebに限定したものばかりだったからです。 しかし、「詳細に依存せず抽象に依存すること」と唱えるクリーンアーキテクチャにとって、Webはただの詳細です。そこで、入力元、出力先を問わないアプリケーションはどのような書き味になるのか、自分で確かめてみたくなりました。 例えば、「ドメイン層は独立

Next.js v13 への移行でやったことまとめ 準備 基礎となる記事に目を通した -> https://zenn.dev/link/comments/eefa4975aaedaf マイグレーションガイドを見て一つずつ対応しようかなと思ったけど、記事が長いのでnext devで動かして出てきたエラーを潰していく方法にした。とりあえずビルドできるようになったら、見落としやより良いやり方があるか確認するために読む。 ページコンポーネントに対して pages にあるファイルを app ディレクトリに移動させる 規約 通りに page と layout にコンポーネントを分割する getServerSideProps の処理をasync function getData() に変更する コンポーネントを async 関数にする props ではなくコンポーネントの中でgetData()の返り値を

最近、個人の技術ブログをリニューアルしました（パンダのプログラミングブログ）。 リニューアルの際に、念願だった OG 画像の自動生成を実装してみたところ、意外と簡単にできたのでその方法を紹介します。 OGP画像とは何か OGP 画像の OGPとは Open Graph Protocol の略語で、ある URL のページをリッチなコンテンツで紹介できるというものです。 サイトのタイトルやページのコンテンツをイメージさせる画像などを meta タグを使って HTML に埋め込みページの内容を表現できます。 Twitter や Slack、Line で URL を貼り付けると URL とは別に表示される物がこれにあたります。サイトのページが増えるとページ一つ一つに OGP 画像を用意することは手間がかかります。そこでこの記事では、OGP 画像を自動生成する方法を紹介します。 OGP 画像の作成方

ER図を作成する schemaspy を使う。Dockerを立ち上げ、ローカルで以下のコマンドを実行する。 ホスト名、DB名、ユーザー名、パスワードは自分のものを設定する $ docker run -v "$PWD/schema:/output" --net="host" schemaspy/schemaspy:6.1.0 -t pgsql -host localhost:5432 -db database_name -u user -p -debug コマンドを実行する コマンドを実行すると以下のようなログが出力される。 $ docker run -v "$PWD/schema:/output" --net="host" schemaspy/schemaspy:6.1.0 -t pgsql -host db.abcdefg.supabase.co:5432 -db dbname -u u

Compiler API で yaml から型を自動生成する この記事は TypeScript Compiler API を実際に使って TypeScript の型を自動生成する方法を紹介しています。 記事内では Google Analytics のイベントの型の自動生成にトライしています。 題材として GA を選んだのは、以前 Next.js に Google Analytics（GA） を導入する方法を紹介した記事でGA のイベントで使う型を yaml から自動生成するのはどうか と書いていたからです。 正直なところ、GA のイベントに馴染みのない方もいらっしゃると思うので、最初はもっと一般的な例にしようかなとも考えました。 しかし、一般的なことを例に挙げると「ふーん、便利だね」という感想で終わってしまい、業務で自分が使うようなイメージが湧かないかもしれないと考えました。 そこで、あえ

記事の概要と動機 Takepepeさんの「AtomicDesign 境界線のひき方」という記事を読んでいて、はたと気づいた。「限定的コンポーネントを横断的なものに移行する」という箇所は、SOLID原則のISPとそのリファクタリングの話だ。ISP（Interface Segregation Principle）とはインターフェース分離原則である。 コンポーネントは、はじめは限定的コンテキストで実装するべきでしょう。共通利用される頃合いに、リファクタリングすれば十分です。その際に忘れてはならないことが「抽象化」です。 この記事は、Takepepeさんの記事中の以下の一文に対して、インターフェースという観点から解説を加えた返歌、つまりアンサーソングである。 コンポーネントのインターフェース フロントエンドのコンポーネントのインターフェースとは、単純化するとPropsの型である。 type Art