2023/10 PyCon JP 2023 のトークネタメモ
2023トークネタメモ for 2023/10/27 PyCon JP 2023 イベント CfP
https://2023-apac.pycon.jp/

トーク申込み

トーク概要1
応募URL
タイトル
トラック
Web Programming
言語
日本語
概要（400文字まで）
OpenTelemetryは、複数のプロセス、システムをまたがってアプリケーションの処理を追跡する分散トレースの仕組みを提供するフレームワークで、今年2021年春に1.0.0 がリリースされました。分散トレースの仕組みは、イマドキの複数コンテナ構成ではないモノリシックな構成に適用することでも、トラブルシューティングやデバッグ、テストの役に立ちます。このライブラリを活用し、Webアプリおよび周辺システムの処理を追跡する方法について紹介します。
詳細（300文字以上）
現代のWebアプリは構成要素が多すぎます。JS、Serverless API、Nginx、Python、RDB、KVS、などなど...。あるリクエストで呼び出された処理全体を把握したいとき、どうやって追跡したらよいでしょうか。全ての処理にデバッグログを仕込み、そのログを集約して絞り込み、そこから処理全体を再構成して把握するのがよいでしょうか。そのような追跡（分散トレース）を、本番、開発、テスト、あらゆるシーンで簡単に行いたいところです。
このトークでは、分散トレースの仕組みを導入するメリットを、具体的な動作例を見て理解できます。
OpenTelemetryは、OpenTracingとOpenCensusが合流して生まれ、Cloud Native Computing Foundation（CNCF）配下のIncubatingプロジェクトとして活発に開発が進められています。分散トレースは複数サーバ・複数コンテナ時代になって難しくなった、通信の流れの把握や、ボトルネック把握、プロファイリングをサポートする、クラウド上で多数のシステムが協調動作する現代のソフトウェア開発の現場では重要な技術です。
備考（一般公開されない）
なし
この題材を選んだ理由やきっかけ
分散トレースはPythonとは関係ないレイヤーにあるため、私がPythonの文脈で紹介することによって、多くの人に興味を持ってもらい、導入・活用する事例が増えるきっかけとなり、翌年以降、より詳しい事例を紹介する方が現れる呼び水となると考えています。
オーディエンスが持って帰れる具体的な知識やノウハウ
分散トレースの仕組みを導入することで、どのようなメリットがあるのかを具体的な動作例を見て理解できる。
オーディエンスに求める前提知識
最近のWebアプリ開発や、そのデバッグで苦労した経験
オーディエンスのPythonレベル
中級者
発表資料の言語
日本語のみ
ネタ
2021年春にリリースされた OpenTelemetry 1.0.0 は、OpenTracingとOpenCensusが合流して生まれました。
>Cloud Native Computing Foundation（CNCF）は、Linux Foundationのプロジェクトの１つで、コンテナ技術の推進と、その進化を取り巻くテクノロジー業界の足並みを揃えるために2015年に創設された財団
>OpenTelemetryは、CNCFによるOpenTracingおよびOpenCensusプロジェクトの統合によって作られたオープンソースの可観測性フレームワーク。
このような仕組みを提供するフレームワークは以前ありました
それらのうちの2つ、OpenTracingとOpenCensusのマージが2019年春に発表され、今年2021年春にはOpenTelemetry 1.0.0 がリリースされまれました。
OpenTelemetryはアプリケーション内の情報を収集（インストルメント）するためのライブラリを提供します。
Djangoアプリおよび周辺システムの処理を収集・プロファイリングする方法について紹介

トーク概要2
応募URL
タイトル
トラック
Web Programming
言語
日本語
概要（400文字まで）
ログを出力しましょう、とはよく言われますが、何を、どこまで、出したら良いのかはログを出す目的がないとイメージしづらいものです。とりあえず色々実装してからログを出すことを後で考えるという人も多いのではないでしょうか。とりあえずそれっぽいログ実装をして、テストや運用が始まってから情報が足りずに困った、という人も多いのが実情です。このトークでは、ログ出力が何に使われるのか、どうやって実装するとよいのか、の全体像をPython+Webの文脈で紹介します。
詳細（300文字以上）
ロギング（Logging）の話題は多くの切り口があります。それぞれの切り口、レイヤーについてログ出力関連の技術を紹介します。
ログを出そう。まずはloggingモジュールの基本設定から
処理状況を伝えるINFOログ。なにを出したら良い？
INFO、WARNING、ERROR、状況に合ったログレベルを設定しよう
複数サーバーで出力されたログを1箇所に集約しよう
参照: logstash
エラーが起きたらログを見る？エラーログは一番分かりやすい用途
エラーじゃないけど、これどういう状況？エラーがないときに効果を発揮するINFOログ
運用中の問い合わせに答えるためのトレース情報
運用開始前にも効果を発揮、想定外の操作を行うテストのログ
フロント操作、サーバー処理、DB問合せ。trace_idによるログ情報の関連付け
構造化ログによるデータ処理
参照: structlog
備考（一般公開されない）
オプション
この題材を選んだ理由やきっかけ
概要に書いたとおり。ログ出力は、実装後に困った経験がないとイメージしづらいものです。また、その経験があれば適切なログ出力ができるかというとそうでもありません。Python界隈でもログ出力に関連するツールが充実しつつあります。ログ出力の用途を知り、現在のツールを知り、その効果を把握したうえで実装前の設計時点で考慮できるようにする、そんなプログラマーが増えるとよいと思い、このトークを提案します。
オーディエンスが持って帰れる具体的な知識やノウハウ
ログ出力の用途、現在のログ関連ツールの状況、ログ出力の効果
オーディエンスに求める前提知識
ログ出力なんも分からん、という方
ログ出力とか要らんでしょ、という方
ログ出力実装してみたけど役に立ってる感じがしない方
ログはあるけど追うのが大変だと思ってる方
オーディエンスのPythonレベル
初級、中級
発表資料の言語
日本語のみ
ネタ

トーク概要3
応募URL
タイトル
Pythonログ出力AtoZ: 初心者でも安心の基本と実践テクニック
ボツタイトル
お手軽ログ出力！JSON構造化も、コンテキスト情報も！
トラック
言語
日本語
概要（400文字まで）
ログを出力しましょう、とはよく言われますが、Pythonでログ出力する際にはなにを使って出したら良いでしょうか。printや標準ライブラリのloggingでしょうか。PyPIには、もっと使いやすいライブラリがいくつも提供されています。ロギングは文脈によって求められる始めやすさや保守しやすさなどの機能性が変わってきますが、クラウド時代のログ出力では、JSONによる構造化ログや呼び出し元のコンテキストを含めた出力が必要とされます。このトークでは、こういった機能を提供するstructlogを使い、実際のプロジェクトでの利用例を紹介します。
詳細（300文字以上）
使いやすいラッパーライブラリは気軽に使い始められるメリットがあり、1ファイルのスクリプトや、ちょっとログを出力したいシーンでは大変重宝します。しかし、コードが複雑になり複数ファイルに分かれた場合や、標準ライブラリやフレームワークのログ出力も合わせて扱うには、始めやすさよりも、追跡しやすいログを簡単なコードで手軽に出せることが大事になってきます。
例えば、ログフォーマットを全体でJSON構造化ログに統一すれば機械的に扱えるようになります。あるいは、呼び出し元のコンテキスト情報をフレームワークのログ出力に含められれば、トラブル時の調査にかかる労力が大幅に削減されます。
予定しているアジェンダは以下の通りです。
ログ出力のユースケースとケースに合わせた使いやすいロギングライブラリの紹介（5分）
クラウド時代のPython+Webにおけるログ出力に求められるもの（5分）
クラウド時代にお勧めのロギングライブラリstructlogについて（5分）
structlogのセットアップ方法（軽く）（3分）
structlogが提供する構造化ログ出力（3分）
structlogのコンテキスト情報出力とその便利な使い方（3分）
まとめと質疑応答（5分）
備考（一般公開されない）
1. Python 初心者にとって自らの知見を広げる内容か
はい。プログラミング初心者であれば、ログの重要性をまだ認識していないと思います。また、Python初心者はPython標準のloggingを使いこなすのが難しい可能性が高く、そのために苦労していると思います。ログ出力をケースに合わせて行う方法は有用だと思います。
2. Python が社会で活用されている具体的なイメージを描けるか
はい。ちょっとしたスクリプトからクラウドで動作するサービスまで色々なところでPythonが使われていることがユースケース紹介からイメージできます。また、ロギングによって現実の問題に対応する方法があることが、Pythonを実社会で運用可能であることを示し、具体的にどのように問題に対処するのかイメージできるます。
3. 内容に独自性・新規性はあるか
ロギング（ログ出力）自体は新しいものではありませんが、実際のWebシステム、サービスでログ出力するための手法と、structlogを実際に使ったケースはあまり共有されていません。また、複数サービスをまたいでstructlog間でコンテキストを共有する方法は世界中で見てもあまり共有されていないと思います。
4. トークの発表が明確にイメージできるほど構成は詳細に書かれているか
はい。アジェンダを記載しました。
5. コミュニティの国際交流に寄与するか
structlogの作者Hynek は、PyCon JP 2015のキーノートスピーカーです。あれから8年が経過し、当時の発表を覚えている人はほとんど居ないと思いますが、私がstructlogを使い始めてこうやって発表しようと思い立ったことは当時のPyCon JP 2015でのキーノートや、同年の数週間前にEuroPythonでHynekと知り合ったことと無関係ではありません。今回のトークは時間が限られているためその点について触れられるかは分かりませんが、可能であれば、PyCon JP イベントや海外PyCon参加が今回のトークの起点にあることを伝えたいと思います。
6. Python を使う「楽しさ・熱意」をアピールできるか
トークのコンテキストが技術的な内容に集中すると思うため、楽しさや熱意は含められないかもしれません。Hynekがstructlogを8年以上保守し続けている熱意は前述の2015年当時の話題と合わせて伝えられればと思います。また、例年通り、楽しくトークしたいと思います。
7. 聴衆が具体的に持ち帰ることができる知識や技術の利用方法・工夫があるか
今回のトークのコンテキストは技術的な内容に集中するため、トーク内容やトーク資料がそのまま持ち帰ることのできる知識、技術、工夫となります。
この題材を選んだ理由やきっかけ
プログラマーであれば誰しも「プログラム実行中に何が起きているか分からない」という問題に遭遇すると思います。そんな時役立つのがロギングですが、やり方が分からなかったり、設定方法が難しかったりと最初のハードルが高いものです。最近はPythonにもログ出力に関連するツールが充実しつつありますが、全てのユースケースに合うツールがあるわけではありません。そこで、ログ出力に求められるユースケースとそれに合った現在のツールを紹介し、それらの組合せを知ることで、最初のハードルを越えるだけでなく、現実的にありえるより複雑なケースにも耐えられる様になると思います。トラブルシューティングにかける時間を削減し、より生産的な活動に集中できるプログラマーが増えるとよいと思い、このトークを提案します。
オーディエンスが持って帰れる具体的な知識やノウハウ
ログ出力の用途、現在のログ関連ツールの状況、ログ出力の効果
structlogの具体的な使い方
オーディエンスに求める前提知識
ログ出力なんも分からん、という方
ログ出力実装してみたけど役に立ってる感じがしない方
ログはあるけど追うのが大変だと思ってる方
クラウド時代のWebアプリ開発や、そのデバッグで苦労した経験
オーディエンスのPythonレベル
初級、中級
発表資料の言語
日本語のみ
ネタ


【採用】
トーク概要4
応募URL
タイトル
トラック
Web Programming
言語
日本語
概要（400文字まで）
Django ORMはSQLの知識がなくてもある程度のデータベース操作ができる便利な技術ですが、その知識だけでDB操作をしていると、気がつかないうちにとても効率の悪い実装をしてしまいます。Web開発からプログラミングを始めた人はWebフレームワークを使ってしばらくしてからDBに関心を持つようになる、何ならDBのことはあまり考えたくない、という方も多いのではないでしょうか。このDjango ORM道場では、そんな「Django ORMあるある」を正し、本来やりたかったはずの処理を効率良く行うことができるよう、基本の型を紹介します。
詳細（300文字以上）
本トークでは、Djangoに内蔵されているDjango ORMによるデータ取得操作を扱っていきます。ほかのプログラミング言語や、ほかのWebフレームワークでは詳細は異なりますが、基本的な考え方は広く使えるはずです。
スポーツであれば鏡を見ながらトレーニングしたり、動画を撮って自分の動きやフォームを見ながら練習します。ソフトウェア開発も同じで、プログラムの実行結果を最後まで確認せずにコードを書くことはほとんどありません。ORMクエリの場合、「期待する値が取れたか」に注目してしまいがちですが、「ORMクエリが発行するSQL文」をよく観察する必要があります。試合の結果（実行結果や処理速度）だけ見るのではなく、そこに至る過程としてのフォーム（SQL文）を観察して磨いていくことが大事です。
本トークでは、道場主（コンサルタント）の立場から、「ORM利用の3つの基本」を押さえ、混乱してしまったDjango ORMコードをスッキリさせる方法を紹介します。アジェンダは以下の通りです
自己紹介と、このトークの背景（3分）
このORM、どんなSQLを実行しているの？（3分）
基本1：実行しているSQLをいつも確認しよう（5分）
基本2：意図しないタイミングでのSQL発行を避けよう（7分）
基本3：理想のSQLからORMを組もう（7分）
まとめと質疑応答（5分）
備考（一般公開されない）
本トークの内容は、Web+DB Vol 133（2023年2月発行）の私の寄稿記事を元にしています。このため、伝えるべき内容は完成されていますが、トーク用に再構成する予定です。
1. Python 初心者にとって自らの知見を広げる内容か
分かりません
2. Python が社会で活用されている具体的なイメージを描けるか
分かりません
3. 内容に独自性・新規性はあるか
おそらく。
4. トークの発表が明確にイメージできるほど構成は詳細に書かれているか
はい。アジェンダを記載しました。
5. コミュニティの国際交流に寄与するか
分かりません
6. Python を使う「楽しさ・熱意」をアピールできるか
おそらく、はい。道場主の視点で話す予定です
7. 聴衆が具体的に持ち帰ることができる知識や技術の利用方法・工夫があるか
はい。とてもあります。
この題材を選んだ理由やきっかけ
本トークの内容は、開発現場で実際にあったコードレビューで出会い、レビュー指摘によって問題を解決した際の内容です。熟練者であれば「あーあるある」と言えるようなことでも、経験が無ければ勘所を掴むまでかなりの試行錯誤が必要になります。その問題に対して私の2020年のトーク（Django + SQLAlchemy: シンプルWay）では異なるアプローチで対処しました。今回は、熟練者の視点をDjango ORM道場の道場主（あるいはコンサルタント）に置き換えて、Djangoの中で完結させます。このトークが、多くのDjango利用者のあるある問題を解決するきっかけになればと思います。
オーディエンスが持って帰れる具体的な知識やノウハウ
1. Django ORMクエリが発行するSQL文を観察する技術
2. 意図しないタイミングでのSQL発行を避ける方法
3. 理想のSQLからORMを組む方法
4. Django ORMコードを整理し、効率的にするための具体的な手法
5. 経験豊富な開発者の視点で問題を理解し、解決するための思考方法
オーディエンスに求める前提知識
Pythonの基本的な知識
Django（またはWebフレームワーク）におけるORMの基本的な理解
最近のWebアプリ開発や、そのデバッグで苦労した経験
SQLのごくごく基礎的な知識（SELECTとJOIN）
データベースの基本的な概念と操作についての理解
オーディエンスのPythonレベル
初級、中級
発表資料の言語
日本語のみ
ネタ

Most related
  • Created a year ago by Takayuki Shimizukawa
  • Updated 10 months ago
  • Views: 60
  • Page rank: 12.2