EuroPythonについて

EuroPythonは，ヨーロッパで開催されるPythonカンファレンスの1つです。PythonのカンファレンスとしてはPyConが世界各地で開催されていて，例えば，ドイツ，フランス，イタリアといった国において開催されています。日本でも初のPyCon JPが8月に開催されることになっています。

EuroPythonは，そういったヨーロッパの国々の，ローカルのPyConよりも大きな規模で開催されるカンファレンスです。

筆者が参加した EuroPython 2011は6月20日?26日の6日間，イタリアのフィレンツェ で開催されました。用意された650個のチケットはすべて売り切れ，参加者数は600人以上だったようです。会場は グランドホテル メディテラネーオ というホテルでした。

なお，EuroPythonは，2年続けて同じ場所で開催するようにしていて，来年もフィレンツェで開催されることが決定しています。これは規模の大きなイベントの運営を1年毎に交代していくと，毎年同じような問題が起こり，運営のノウハウが蓄積されないことを避ける意図があるそうです。

Pythonの海外イベントの雰囲気を知ってもらい，本稿の読者がいつか参加しようと思ったときの参考になるよう，3回にわたって筆者視点でEuroPython 2011のレポートをお届けします。

travel: 旅行

本カンファレンスには，小宮さん（@tk0miya）と池さん（@rokujyouhitoma）と筆者の3人で参加してきました。残念ながら会場で日本人とは会いませんでした。筆者たちは3人一部屋で会場と同じホテルに滞在しました。筆者が本カンファレンスへ参加するのにかかった費用は次の通りです。

合計すると188,654円になります。実際のところ，現地での食事や観光もしたのでもう少しお金がかかっています。航空券や燃料サーチャージも時期によって変動するので概算の参考程度にみてください。

往路は成田-ローマ-フィレンツェとすべて空路で移動しましたが，復路はフィレンツェ-ローマを電車で移動しました。フィレンツェ-ローマ間は，飛行機で1時間，電車で1.5時間程です。筆者は，飛行機よりも電車の方が快適で，待ち時間を考慮すると，電車のほうが便利なように感じました。

EuroPython 2011

keynote: 基調講演

EuroPython 2011は，2人のPythonistaによる基調講演から始まりました。

GOOD API DESIGN: 優れたAPIデザイン

最初に講演したのはAlex Martelli氏です。

Alex Martelli氏は，Pythonソフトウェア財団（PSF）のメンバーであり，PythonクイックリファレンスやPythonクックブックの著者でもあります。現在はGoogleに所属しています。講演の中ではAPIデザインのアンチパターンとして，APIのライフサイクルも考慮しながら，なぜそれが良くないか，ならどうしたら良いのか，という考えるための土台を説明して，自身の経験の中からその方法論を説明されていました。

本講演の資料と動画はGOOD API DESIGNで公開されています。

最悪のAPIデザインのアンチパターン

最悪なのはAPIを提供していないことであり，APIの必要性が求められているにも関わらず，APIを提供しないと次のようなことが起こることが紹介されました。

• stackoverflowにスクレイピングの質問ばかり繰り返される
• スクレイピングが増えることで，システムにレンダリングの負荷が増える
• 表面的なちょっとした変更がユーザのアプリケーションを動かなくしてしまう
• 自分たちの競合に参入するきっかけを与えてしまう

プログラマの出発点はここからです。

• そうだ！ APIを提供しよう
• 使いやすくてシンプルなAPIにしよう
• ドキュメントをちゃんと書いて，更新し続けよう

デザインのないAPIは，APIではない

その次に良くないことは，何も考えずにただAPIを提供することです。それは内部の実装を変更しようとすると，次のことが起こるからです。

• 面倒になって改善しようとしなくなる
• (変更によって）既存ユーザのアプリケーションを動かないようにしてしまう
• 新旧の2つの実装を提供すると，メンテナンスの負荷が増える

この問題に立ち向かうアプローチは次の2つの視点から考えます。

• どう使いたいかを考える
  • 自分が利用者だったら何をどうしたいだろうか
  • （とは言っても）単純に利用者の立場だけで考えるわけでもない
• いまの実装を忘れる
  • 少なくとも2つ3つの実装を考えて，その中から共通項を探す
  • 何が変更されると困ったことになるか
  • APIにずっと残っている中核は何か

APIのデザインは大変ではあるものの，その見返りも大きく，機能を拡張するだけでなく，システムのコア機能を分割する優れたアーキテクチャも手に入れられると述べていました。

APIのデザイン

APIをデザインするにあたり，考え方としてAPIを階層化する方法が良いと言及されていました。

• システムの論理的なアーキテクチャの低レベルAPIを1つだけ公開する
• 低レベルAPIは使い方が分かり難くても，パフォーマンスが良くデバッグしやすいなら構わない
• その他のAPIは低レベルAPIから構成する（システムの内部処理を使わない）

APIの変遷

優れたAPIを設計してもユーザに新しいAPIへ移行してもらう必要があります。大きな変更はユーザを離反させることにつながるため，段階を踏んで移行します。

• 新旧APIが動作するリリースを1つ以上提供する
• チュートリアルとドキュメントを準備する
• 旧APIに新しい機能を追加しない

一貫性のないAPIデザインのアンチパターン

引数の順番や命名規則などが一貫性のないものになってくるときがあります。

• 人は時間と共に考え方が変わるから
• もともとの要件とは違うようになったから
• 別のメンバーが違う方法で実装したから

そんなときにデータディクショナリを作ると良いと提案されていました。それは，チーム内で共有する名前とその概念を1対1でひも付けたものです。そして，新たに何か思い付いたときに追加するように運用し，そこから名前を選択するようにします。これにより，決めることに要するオーバーヘッドを少なくするという狙いがあります。

簡単に言うと，チーム内で情報を共有することを言っているのですが，これをシステム的にやると良いと説明されていたように思います。