Takeaways from Cory Zue's May 2023 Livecoding Session

Michael Lynch

Cory Zueの2023年5月ライブコーディングセッションから得た学び

原文は Michael Lynch により に公開されました。 このブログを購読する

友人のCory Zueがライブコーディングのセッションを公開しているので、一つ視聴してメモを残すことにした。

自分のバックグラウンドとCoryのバックグラウンド

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

開発環境

タイムスタンプ 0:10

  • OS: Ubuntu
    • CoryはOS X派だと思っていた。
  • ブラウザ: Firefox
  • IDE: PyCharm(たぶん)
    • PyCharmは使ったことがなく、普段はVS Codeを使っている。

モデル

タイムスタンプ 2:53

  • Django関連で置いていかれそうで不安になってきた。
  • Coryが示したChatMessageモデルは、オブジェクトをデータベースにどう保存し、どう取得するかをフレームワークに伝えるORMオブジェクトのようだ。
    • ORMを触ったことがないので、すべてが初めての内容だった。

マイグレーション

タイムスタンプ 3:35

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

管理画面の作成

タイムスタンプ 3:50

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

タイムスタンプ 5:49

  • Djangoはこの定義を使って、新しいモデルをデータベース上で追加・編集するための管理UIを自動生成するようだ。
    • これは便利だ。自分が同じことをするならデータベースに直接クエリを投げることになるが、こちらの方が確実に楽だ。

翻訳

タイムスタンプ 10:05

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

Djangoの制御フロー

タイムスタンプ 14:52

  • Djangoは不思議だ。get_object_or_404を呼ぶだけで、オブジェクトが見つからなければ関数を抜けてHTTP 404エラーを返すようだ。
    • PythonのFlaskやGoでは、HTTPエラーを返すときは(ハンドルされない例外がHTTP 500になる場合を除き)もっと明示的に書く必要があるので、この挙動は自分にとってかなり馴染みがない。

git GUI

タイムスタンプ 25:08

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

クライアントサイドとサーバーサイドのレンダリング間でコードを共有する

タイムスタンプ 29:06

  • Coryはhtmxを使って、自分が悩んできた問題――クライアントサイドレンダリングとサーバーサイドレンダリングの間でコードの重複をどう避けるか――を解決できているようだ。

    • Webアプリでは、ページにコンテンツを追加したいが、ページ全体をリロードしたくないという状況によく遭遇する。
    • ユーザーがリロードしたときには、動的に追加したときと同じコンテンツが表示されるべきだ。
    • 自分はよく、次の三つのどれも微妙な選択肢の間で立ち往生する。
      1. 常にクライアントサイドでレンダリングする。複雑で、ブラウザでの描画も遅くなる。
      2. 常にサーバーサイドでレンダリングする。変更を表示するには基本的にページ全体をリロードする必要がある。
      3. レンダリングロジックを二重に実装する。一度はクライアントサイド用に、もう一度はサーバーサイド用に。
  • 動画では細部まで見えないが、htmxを使うとCoryはHTMLをサーバーサイドで定義しつつ、htmxの属性によって特定の要素だけをフルリロードなしで再描画でき、レンダリングロジックを書き直す必要もなくなるようだ。

ChatGPT API

タイムスタンプ 36:48

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

まとめ

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

Coryがやっていたことの多くがDjango固有だったため、そこから得た学びを自分の仕事に応用するのは難しかった。たまたま選んだ動画が運悪く、今回の作業がDjangoのさまざまな要素を組み合わせる内容が中心だったからかもしれない。

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

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。

コメント