Takeaways from Cory Zue's May 2023 Livecoding Session

2023-06-03

Cory Zueの2023年5月ライブコーディング配信から得た学び

友人のCory Zueがライブコーディングの配信を公開しているので、1本見てみてメモを取ることにしました。

Coryのブログはよく読んでいます。私たちはどちらもPythonの開発者ですが、彼はDjangoを専門としているのに対し、私はFlaskのような軽量なフレームワークばかり使ってきました。Djangoの経験はありませんが、Python自体には慣れています。

Djangoの話についていけなくなるのではないかと不安になってきました。
CoryがChatMessageモデルを見せてくれました。これは、オブジェクトをデータベースにどのように保存し、取得するかをフレームワークに伝えるORMオブジェクトのようです。
- ORMを触ったことがないので、すべてが初めてでした。

Coryが./manage.py makemigrations chatというコマンドを実行します。先ほど定義した2つのモデルに対応できるように、データベースマイグレーションを生成しているようです。
続けてCoryは./manage.py migrateを実行し、作成したマイグレーションを適用します。
Djangoは私が慣れているやり方よりずっと「魔法」が多いと感じました。私はこれまでデータベースのマイグレーションを手作業で作ってきたからです。
- Coryのやり方は、新しいオブジェクトを定義するたびに大量のSQLのボイラープレートを書いていた私の経験に比べればはるかに手間がかかりません。ただ、開発者とデータベースの間に多くの抽象化が挟まることにもなります。

Coryは追加したモデルを基に、管理ページのボイラープレート定義をChatGPTに作らせています。
- ChatGPTは正しく生成しましたが、Coryは自分の好みのDjangoの書き方に合わせて微調整が必要でした。

Djangoはその定義を使って、データベース上の新しいモデルを追加・編集するための管理UIを自動生成するようでした。
- これは便利です。私は普段こういうときは直接データベースをクエリしていますが、こちらの方が明らかに簡単です。

Coryはこのアプリをローカライズできるように設計しているようでした。私は15年ほどそういったことを考えたことがありません。
国際化対応文字列の構文はとてもシンプルでした。
- {% translate "Manage your chats here." %}
- 他の言語への翻訳は別の場所で用意する必要があるはずなので、どういう仕組みなのか気になります。

Djangoは不思議です。get_object_or_404を呼ぶだけで、オブジェクトが見つからない場合に関数を抜けてHTTP 404エラーを返せるようです。
- これはPythonのFlaskやGoに慣れている私にはかなり馴染みのないやり方でした。あちらでは（ハンドルされない例外がHTTP 500になる場合を除き）HTTPエラーを返す処理をもっと明示的に書く必要があります。

Coryは私が見たことのないgitのGUIを使っていました。
- git gというコマンドで起動していましたが、これはCory独自のgitエイリアスだと思います。
Coryはファイルを確認しながら、1つずつコミットに追加していました。
Coryはフォーマットが正しくないとコミットを拒否し、望ましいスタイルに自動整形するpre-commitフックを使っていました。
- これは私がずっと避けてきたやり方です。自動ツールにコードを書き換えられるのを信用できなかったからです。
- Coryのやり方では、自動ツールがコードを書き換えたあと、コミットする前に本人が変更内容を確認しています。

Coryはhtmxを使って、私が悩んでいる問題を解決しているようでした。クライアントサイドのレンダリングとサーバーサイドのレンダリングでコードが重複するのをどう避けるかという問題です。
- ウェブアプリでは、ページにコンテンツを追加したいけれどページ全体を再読み込みしたくない、という状況によく出くわします。
- ユーザーが再読み込みしたときには、動的に追加したときと同じ内容が表示されるべきです。
- 私はよく、どれも一長一短な3つの選択肢で行き詰まります。
  1. 常にクライアントサイドでレンダリングする。複雑で、ブラウザでの表示も遅くなります。
  2. 常にサーバーサイドでレンダリングする。変更を反映するには基本的にページ全体を再読み込みする必要があります。
  3. レンダリングのロジックを2回実装する。クライアントサイド用とサーバーサイド用にそれぞれ1回ずつです。
動画では一部しか見えませんでしたが、htmxを使えばCoryはHTMLをサーバーサイドで定義し、htmxの属性によって特定の要素だけを、ページ全体の再読み込みなしに、レンダリングロジックを重複させることなく再描画できているようでした。

ChatGPT APIは驚くほど簡単に使えます。
- APIはモデル名と、会話内のメッセージのリストだけで構成されています。
- 会話の状態は、APIを呼ぶたびに完全なメッセージ履歴をChatGPTに渡すことで維持します。

Djangoは重厚なフレームワークだと思っていましたが、想像以上に重厚でした。DjangoはPythonのリストや辞書、enumにまで独自のラッパーを用意しています。Djangoと素のPythonの隔たりは、Reactと素のJavaScriptの隔たりのように感じました。

Coryがやっていたことの多くはDjango固有だったため、自分の仕事に活かせる学びを見つけるのは難しかったです。たまたま動画の選択が悪かっただけかもしれません。この動画でCoryがやっていた作業は、Djangoのさまざまな要素をつなぎ合わせることが中心だったからです。

それでも、より高い抽象化レイヤーからすべてを設計していくスタックでの開発者体験を見るのは面白いものでした。