ENECHANGEの白坂です。
ENECHANGE は PyCon APAC 2023に今回もシルバースポンサーとして協賛しました!
今回PyCon APAC 2023にオフラインで参加してきたので、会場の様子や参加して学んだことをレポートします。
そもそもPyConって何?
PyCon APACは、プログラミング言語「Python」を中心としたボランティアによる非営利の年次カンファレンスです。このカンファレンスの目的は、Pythonプログラミング言語とその周辺技術を探求し、議論・実践できる場を提供することです。運営チームは、アジア太平洋地域における国または地域が主体となり、現在では、シンガポール、マレーシア、インドネシア、フィリピン、タイ、韓国、香港、ベトナム、日本、台湾、インド、バングラデシュが毎年交代して開催され、2023年は日本のメンバーが主体となり運営します。そして、日本での開催は2013年以来の10年ぶりとなります。 PyCon JP は、Python ユーザが集まり、Python や Python を使ったソフトウェアについて情報交換、交流をするためのカンファレンスです。 PyCon JP の開催を通じて、Python の使い手が一堂に集まり、Python にまつわる様々な分野の知識や情報を交換し、新たな友達やコミュニティとのつながり、仕事やビジネスチャンスを増やせる場所とすることが目標です。(PyCon APAC 2023 より引用)
つまりPythonの情報交換のためのカンファレンスです。
PyCon APAC 2023について
今回のPyConは1日目と2日目にカンファレンスが開催され、
3日目はスプリントの日となりました。
カンファレンスでは、Keynoteやセッション、LTなどが行われます。
また、スポンサーブースがあったり、書籍購入ができたりします。
スプリントでは、テーマを決めてチーム開発や意見交換をすることができます。
pyconjp.blogspot.com
日程
カンファレンス: 2023年10月27日(金)〜2023年10月28日(土)
スプリント: 2023年10月29日(日)
会場
カンファレンス: TOC有明コンベンションホール
スプリント: HENNGE株式会社
2023-apac.pycon.jp
スポンサーブースの様子
PyConを楽しむ方法の一つがスポンサーブース巡りだと思っています!
スポンサーブースは、PyConのスポンサーになった企業の一部が出せるブースです。
PyConのスポンサープランによって、ブースを出せるかどうか決まります。
弊社ENECHANGEも今回ブースを出すことができました。
スポンサーブースでは会社紹介やプロダクト紹介が行われます。
どのブースも様々な工夫がされていて、エンジニアが楽しめるクイズができたり、PyCon限定のノベルティを置いていたりします。
私は、スポンサーインタビューの動画を事前に見てブース巡りを当日楽しみにしていました(笑)
そして、カンファレンス初日の入場開始直後にブースを巡ったので、たくさんのノベルティをいただくことができました。
どれも大変素敵なものばかりでした!
セッションの様子
カンファレンスでは、最初にOpeningとKeynoteが行われ、その後に5つの会場でそれぞれ15〜30分のセッションがあります。
今回はPyCon JPではなくAPACだったので、英語のセッションが例年より多めでした。
どの会場も当日ライブ配信をしていたので、参加者でなくてもオンラインで視聴することができました。
また、会場にいても見逃してしまったセッションを後から視聴することができました。
会場設営からライブ配信まで、、、PyConスタッフの皆さん、本当にありがとうございます。
セッションを今からでも視聴されたい方は、PyCon JPのYoutubeで確認することができます!
印象に残ったセッション
Django ORM道場:クエリの基本を押さえ,より良い型を身に付けよう
ORMによって実行されるSQLを毎回ちゃんと確認して、理想のSQLからORMを組むようにしようという内容でした。
セッションの中で、ORMから発行されるSQLを予測しようというクイズがあったのですが、悉く外れました...。
私は今まで、ORMを書いても、発行されるSQLを何となく予測するだけで終わっていたので、今後はSQLの確認をちゃんとしようと思います。
また、レビュー依頼する際にも、SQL出力を添えるといいよとのことでした。
最近ちょうど、アプリケーション側からDBの負荷を改善するタスクをしたのですが、
SQLを実際に確認することの大事さを痛感しました。
DjangoRestFrameworkのリファクタリング、レガシーなコードの寿命を延ばすために
DjangoRestFrameworkのリファクタリングで実際にあった課題や取り組まれたことについてのお話でした。
DjangoRestFrameworkの技術的負債について、あるあるばかりでかなり共感しました。
また、スピーカーの方のお話が面白くて笑わずにはいられないセッションでした。
普段からテストをちゃんと書こう、リファクタリングしていく際にテストがなければまずテストを書こうとのことでした。
また、巨大化したAPIViewをService層に切り分けていったという話や、テストにsubTestを導入したという話が大変勉強になりました。
特にsubtestの導入はすぐにしたいと思いました。
DjangoRestFrameworkのテストでは、下記のようなテストの書き方をすると、
もしテストが落ちるようになりステータスコードが4XXのようなレスポンスになった場合、
一行目のassert文で処理が落ちてしまい、二行目以降のassert文は通過しません。
そのため、テストが落ちる原因を調査する際、大きい処理だとデバッグが大変です。
class SampleTest(APITestCace): def test_ok(self): res = self.clinet.post(self.url, data=self.data) self.assertEqual(res.status_code, 201) self.assertEqual(レスポンスの確認) self.assertEqual(データベースの更新確認) self.assertEqual(その他の確認)
ですが、subTestを使うと下記のようにそれぞれのsubTest毎に処理が走るので複数のassert文が実行されます。
そのため、どこで処理が失敗しているのか、原因を切り分けやすくなります。
class SampleTest(APITestCace): def test_ok(self): res = self.clinet.post(self.url, data=self.data) with self.subTest("レスポンスの確認") self.assertEqual(res.status_code, 201) self.assertEqual(レスポンスの確認) with self.subTest("データベースの更新確認") self.assertEqual(データベースの更新確認) with self.subTest("その他の確認") self.assertEqual(その他の確認)
Introduction to Structural Pattern Matching
slides.takanory.net
Python3.10からの新機能である構造的パターンマッチングのお話でした。
そもそも、構造化パターンマッチングで使われる match
や case
はclassなどと違ってソフトキーワードであるとのことでした。
つまり、既存のコードにmatchやcaseが変数名として存在していても問題ないようです。
セッションでは、具体的な使い方を例文を用いて丁寧に説明されていて、確かにif文よりもいいかもしれないと思いました。
用途によって使い分けることでコードの可読性を高めることができそうです。
弊社プロダクトも3.10へのアップデートを検討したいと思います。
まとめ
あっという間の二日間でした!
また、社外のエンジニアの方とお話ができて刺激をもらえました。
来年もPyConに参加したいと思います。