概要

先週末、マンハッタンで開催された年次カンファレンスに、PyGothamからスピーカーとして招待されました。イベントから得られるものを最大化するため、参加して学んだことをメモとしてまとめました。他の人にとっても何か面白い発見や役に立つことがあればと思い、共有します。

評価・レビュー

トークの質

今年のトークは全体として、正直なところ少しがっかりしました。気に入ったものもいくつかありましたが（後述）、物足りなく感じるものが多くありました。

原因のひとつは、単純に自分がターゲット層ではなかったことです。多くの枠が機械学習のトークで占められていました。機械学習自体は面白いと思いますが、仕事で使っているわけではないので、入門的な機械学習のトークはもう十分かなという気分でした。

運営のスムーズさ

PyGothamの運営チームには称賛を送りたいです。イベントを実にスムーズに運営していました。スピーカーとして、必要な情報を必要なタイミングで得られました。見たすべてのトークで音響・映像機材は問題なく動作し、進行もすべて定刻通りでした。食事もおいしく十分な量がありましたが、やや炭水化物が多めでした。

会場

ペンシルベニアホテルはカンファレンスの会場として素晴らしいところでした。ステージは3つあり、座席も十分で、窮屈に感じたり、見たいトークに入れなかったりすることは一度もありませんでした。各部屋は近くにまとまっていてトーク間の移動も楽でしたし、参加者同士で廊下で立ち話をするスペースも十分にありました。

自分のトークの出来

「自分のトークを振り返る」（後述）をご覧ください。

お気に入りのトーク

Archiving the Internet Before it All Rots Away

スピーカー: MonadicalのNick Sweeting

Webページのアーカイブにこれほど大きなコミュニティがあり、ツールがこれほど成熟しているとは知りませんでした。Nickは、中央集権的なデータリポジトリがいかに簡単に失われてしまうかを指摘しました。これはアレクサンドリア図書館のような古代の例にも当てはまりますし、GeocitiesやTumblrのようなデジタル情報にも当てはまります。こうしたリポジトリは、一般の人々が自分自身でアーカイブし、保存するためのツールを持つことで生き残るのです。

NickはWebページをアーカイブするためのさまざまなツールを紹介し、インターネットアーカイブに取り組む団体やオンラインコミュニティを案内してくれました。ツールは想像以上に成熟しており、JavaScriptやRPCを多用してHTMLを動的に生成するシングルページアプリケーション（SPA）でさえアーカイブできるツールがいくつかあるとのことでした。身近な汎用ツールの中にも強力なアーカイブ機能が備わっているものがあります。

Nickは、JavaScript、CSS、画像を含めて単一のWebページを丸ごとダウンロードする、次のようなwgetコマンドを紹介しました：

wget \
  --no-verbose \
  --adjust-extension \
  --convert-links \
  --force-directories \
  --backup-converted \
  --span-hosts \
  --no-parent \
  -e robots=off \
  --restrict-file-names=windows \
  --timeout=60 \
  --warc-file=archive.warc \
  --page-requisites \
  --user-agent="Lalala this is chrome I promise..." \
  --load-cookies="mycookies.txt" \
  --compression=auto \
  --no-check-certificate \
  --no-hsts \
  "https://2019.pygotham.org"

その他、良かった点：

• Nickが紹介してくれたkiwixは、私にとって初めて知るプロジェクトでした。WikipediaやStack Overflowのような大規模なコンテンツサイトのオフラインコピーを提供しており、ローカルで動かすことができます。
• Nickはアーカイブ関連のリソースやコミュニティのディレクトリを管理しています。

Maintaining a Python Project When It’s Not Your Job

スピーカー: Hynek Schlawack

• トーク概要
• スライド

Hynekはattrsやstructlogといった人気のオープンソースプロジェクトをいくつかメンテナンスしており、外部からのプルリクエストをレビューする時間は限られています。彼は自動化ツールを使ってレビューにかける時間を最小限に抑え、コントリビューター自身がバグを見つけられるようにしています。これは、私のコードレビューにおける第一の原則である「退屈な部分はコンピュータに任せる」とぴったり一致していました。

Hynekは楽しくエネルギッシュなスピーカーです。彼は「こんにちは、Hynekです。あなたが知らなかったヨーロッパの友人です」というジョークから話を始めます。この一言で、これから話す内容が楽しく、時にユーモアを交えたものになるというトーンが決まります。

その他、良かった点：

• 知らなかったツールをいくつか知ることができました：
  • isort: Pythonのimport文をソートしてくれます。
    • 私はPython3のボイラープレートプロジェクトに追加しました。
    • このツールの欠点は、「自動で修正する」（ビルドチェックで求めている動作ではない）か「役に立たない失敗メッセージを出す」の2つのモードしかないことです（欠点）。
  • Black: Pythonコードの空白をフォーマットします。
    • 面白いツールですが、私が愛用しているyapfと比べて、特に大きな利点があるようには思えませんでした。
  • tox: 異なる仮想環境でPythonのテストスクリプトを実行します。
    • 5年ほど前にtoxを使った覚えがありますが、当時は単体テストで振る舞いをモックするために使っていました。今のプロジェクトはまったく別物のように見えるので、mockが標準ライブラリに入った後に方向転換したのか、単に私が勘違いしているのかよくわかりません。
    • いずれにせよ、なかなか便利そうです。複数のPython環境で動かすプロジェクトはまだ作っていませんが、引き出しに入れておくと良さそうです。
• Hynekのプルリクエストのチェックリストやコントリビューター向けドキュメントの例も気に入りました。
• トークの内容を公開のテキストアウトラインとして作成している人を見たのは初めてでしたが、Hynekのものはとても役に立ちました。

Make You An Async For Great Good!

スピーカー: NexmoのMark Smith

Markは、並行処理コードを書くためのPythonライブラリであるPythonのasyncioモジュールを紹介しました。彼は、mysyncioという簡易版を自作することで、このライブラリの仕組みを理解したのだと説明しました。

Markがこれほど少ないコードでasyncioの機能の多くを再実装してみせたことに感心しました。彼の実装では、本物のasyncioモジュールが持つ重要な機能、特にスレッドセーフ性や例外処理は省略されていましたが、asyncioの中核的な機能は実現していました。並行プログラミングはしばしば直感的に理解するのが難しいものですが、Markの「魔法を解いた」バージョンのライブラリを見たことで、asyncioがより理解しやすくなりました。

自分のトークを振り返る

スピーカー: Michael Lynch（筆者）

• スライド

自分のトークについては良い感触でした。準備の度合い（5〜7回の通し練習）にも満足していますが、カンファレンス直前の週まで先延ばしにせず、もっと早くリハーサルを始めておけばよかったと思いました。

PyTexasでのトークの後、改善点としてメモしていたのは「もっとゆっくり話すこと」と「ノートPCを下向きに見すぎないこと」でした。PyGothamでは、ゆっくり話すことを意識しすぎたせいか、トーンが平板になり、自分の話に飽きているかのように聞こえてしまいました。最初の5〜10分を過ぎると改善しますが、今後のトークでは、話す内容に感情を込めることを意識したいと思います。

一番の失敗は、画面をミラーリングするのではなく、Google スライドの「発表者ビュー」で投影してしまったことでした。画面上のタイマーがペース配分に役立つと思ったのですが、自分のスライドが見られなくなることを失念していました。内容は十分に覚えていたので、発表者ビューの小さなサムネイルだけでもほとんどのスライドは話せましたが、何度か観客に背を向けてスクリーンの文字を読まなければならない場面がありました。

• うまくいったこと

  • 発表する内容に自信を持って臨めた。
  • 話すスピードを落とし、聴衆に意識を向け続けることができた。

• 改善が必要なこと

  • 「発表者ビュー」ではなく、ノートPCの画面をミラーリングすることを忘れない。
  • ゆっくり話すことと平板なトーンで話すことは別。カンファレンスに登壇できることを嬉しく思っているのだから、その熱意をもっとトークで表現すべき。
  • 内容自体がやや堅苦しく感じられる。もう少し軽やかさやジョークが必要だ。
  • 準備が慌ただしくならないよう、もっと早くリハーサルを始める。

かかった費用

PyTexas参加時にかけた約1,200ドルと比べてみてください！すべてのカンファレンス主催者が、車や電車で行ける距離で開催し、近くに泊めてくれる友人がいることを確認してくれれば、とても助かるのですが。

時間的には、準備に5〜10時間かけました。PyTexasのスライドがすでにあったので今回の準備はかなり楽でしたが、前回の反省を踏まえてプレゼンには少し手を加えました。

その他の雑感

「どう改善できるか？」

これまでのカンファレンスでは、トークが良かったと声をかけてくれた人に、ただお礼を言うだけでした。今年は「ありがとうございます！改善できそうな点はありますか？」と聞いてみました。皆さん少し驚いた様子でしたが、たいてい一瞬考えてから何か提案をしてくれました。

カンファレンスではフィードバックが得られにくいのが残念なところです。誰でも人前で話すスキルやスライドの分かりやすさは改善できますが、スピーカーは、何がうまくいっていて何がそうでないのかというデータがあまりありません。私自身、トークを見ていると「それは簡単に直せるのにもったいないな」と思うことがよくあります。でも、頼まれてもいないのにアドバイスをしに行くのは失礼ですし、特に相手がそもそも緊張しているような内容であればなおさらです。

今後、トークの後に声をかけてもらったときは、お礼を言うだけでなく、どうすればもっと良くなるかを聞くことも忘れないようにしようと思います。もし私のトークをご覧になった方がいれば、ぜひ改善点を教えてください。

カンファレンスはアイデアが生まれる場所

カンファレンスは創造的な思考を刺激してくれます。会場に座るまでいつも忘れているのですが、参加するたびに必ずそうなります。カンファレンスでなければ決して思いつかなかったようなアイデアが浮かびます。

時々、トーク中に自分の思考がさまようからなのか、あるいはスピーカーが思考プロセスを丁寧に説明してくれることで、普段とは違う発想が引き出されるからなのか、理由はよくわかりません。ただ、どのカンファレンスに参加しても、自分のビジネスや今後取り組みたいプロジェクトについて良いアイデアを持ち帰ることができます。

暗号通貨を盗む話をトークにすべきだ

そうでなければ思いつかなかったアイデアの例として、PyGothamで「How I Stole Your Siacoin」をカンファレンストークにすべきだと気づいたことがあります。面白いストーリーで、Pythonを使っていますし、レーベンシュタイン距離や公開鍵暗号といったトピックを楽しく説明できます。これまでカンファレンストークにしようとは考えもしませんでしたが、一度思いつくと、とても当然のアイデアに思えました。

何も求めない方がいいのかもしれない

今年前半のPyTexasの後、新しいプロジェクトを探していたことに気づき、会場には大勢のテックワーカーがいるのだから、ビジネスの課題について話しかけてほしいと頼んでおけばよかったと思いました。誰でも、マネージドサービスに任せたいと思っている業務はあるはずです。（願わくば）自分が有能な開発者であることを示せたはずなので、何か作ってほしいと頼んでもらえたかもしれません。

PyGothamでは、トークの最後に、仕事で「こんなマネージドサービスがあればいいのに」と感じていることがあれば声をかけてください、と呼びかけました。結果は、何もありませんでした。

最悪でも「MailChimpが欲しい、ただし無料で無制限で」みたいなひどいアイデアくらいは出てくるだろうと思っていましたが、まったく何もなしでした。なので、この戦略にはあまり価値がないのかもしれません。今後は、この場を使ってWhat Got Doneの新規ユーザーを集めるために使ってみようかと思います。

CFPのレビューは勉強になる

スピーカーがカンファレンスに応募する際には、「CFP（Call for Proposals）」を記入します。なぜ自分がそのカンファレンスで話すべきなのか、そしてイベントのスケジュール表で参加者を惹きつけるための紹介文をどう書くかを、数段落で説明するものです。

PyGothamは、参加者がすべてのCFPを見て投票できるという、これまで経験した中で初めてのカンファレンスでした。自分でもいくつかCFPを書いたことはありますが、他の人のCFPを読んだことはなかったので、どのトークが採択されるかについて（程度は不明ですが）投票権を持つ立場として経験できたのは、とても勉強になりました。

学んだこと：

• CFPのレビューは本当に疲れます。
  • 確か300件ほど応募があったと思います。3〜4回に分けて読みましたが、エネルギーの残り具合によって、あるものにはより寛容に、あるものにはそうでなく、といったムラがあったはずです。
• 自分の興味と参加者全体の興味のバランスを取るのは難しいものです。
  • 例えば、私自身は機械学習のトークにそれほど興味はありませんが、他の人は興味があることはわかっています。そういうトークに賛成票を入れるべきか、反対すべきか。
• CFPで気取った態度はマイナスにしかなりません。
  • 応募者の中には、CFPを記入すること自体が自分にはふさわしくないかのように振る舞う人もいました。「あなたのトークは何についてですか？」という質問の後に、「参加者はあなたのトークから何を得られますか？」といった質問が続くのですが、後者に対して「上記参照」や「これは最初の質問と意味のある違いはない」といった手抜きの回答をしている人を何人も見かけました。
  • 100件のCFPをレビューして、そのうち90%を落とさなければならない状況では、そうした横柄なものから落とすのが最も簡単です。

年3回のカンファレンス登壇はちょうどいい目標

年初に、2019年に3つのカンファレンスで登壇するという目標を立てました。PyGothamでその目標が達成されました：

1. NERD Summit 2019
2. PyTexas 2019（参加記）
3. PyGotham 2019

振り返ってみると、年3回というのは今でも良い目標だと感じています。1回ごとに1〜2週間は疲れて動けなくなりますが、良いアイデアをもらえたり、そうでなければ出会わなかったであろうツールやテクニックに触れられたりもします。