nbdev:探索的プログラミングをPythonで実現する開発環境(3/4)

１．nbdev:探索的プログラミングをPythonで実現する開発環境(3/4)まとめ

・Jupyter Notebookは「探索的」部分では優れているが「プログラミング」の部分では優位性がない
・既存の素晴らしいツールを活用しつつ、必要に応じて独自のツールを構築してnbdevを実現
・notebookの優れた特性によりマージコンフリクトの解決やテストケースの作成／実行が容易

２．Jupyter Notebookに欠けている事

以下、www.fast.aiより「nbdev: use Jupyter Notebooks for everything」の意訳です。元記事は2019年12月2日、Jeremy Howardさんによる投稿です。アイキャッチ画像のクレジットは(Photo by Simon English on Unsplash)。3日で訳そうと思っていたのですが少し時間が足りずに1日延ばしました。

Jupyter Notebookに欠けているものは何でしょうか？
Jupyter Notebookは、「探索的プログラミング」の「探索的」の部分では優れていますが、「プログラミング」の部分ではそれほど優れていません。例えば、次のようなことを実際に行う手段が提供されていません。

・Jupyter以外の環境で実行可能な再利用可能なモジュールを作成
・ハイパーリンクされた検索可能なドキュメントの作成
・テストコード(継続的インテグレーションによる自動化を含む)
・コードのナビゲーション
・バージョン管理

このため、一般的には、それぞれの開発段階に最も適したツールを使うために、大きな手間をかけながらツールを切り替える必要があります。

	長所	短所
IDE/Editor	・最終的な配布可能モジュールの生成・ドキュメント検索機能・構文の強調表示および型チェック	・非対話型なので、探索的行動に向いてない・動的言語の不完全なサポート・ドキュメントはテキストのみ・インタラクティブな文書化やサンプルを使って説明する機能がない
REPL/shell	小規模なインタラクティブな探索に最適	配布可能なモジュールの作成を含む、他の全ては不得意
従来のnotebooks	・コード、リッチテキスト、画像を組み合わせ可能・インタラクティブに探索した事を記録することにより、具体的事例を通して説明可能・正確なコードナビゲーションと動的言語の自動補完	REPLと同じ

この問題を処理する最善の方法は、既存の素晴らしいツールを可能な限り活用しつつ、必要に応じて独自のツールを構築することであると判断しました。

例えば、プルリクエストの処理と差分の表示には、ReviewNBという優れたツールが既にあります。ReviewNBでグラフィカルなdiffを見ると、単なるテキストデータのdiffが今までどれほど情報不足であったのかパッと見て理解できます。

例えば、コミットにより画像がぼやけてしまった場合はどうでしょう？または、ラベルがないグラフをアップデートしてしまってませんか？視覚的な違いがあるとき、あなたは本当に何が起こっているか知る事ができます。

ReviewNBの視覚的な差分、表形式の出力の変更を表示しています

多くのマージコンフリクト(merge conflicts:gitで同じファイルを複数人が同時に編集してしまった際に起こるエラー)はnbdevを使うと回避できます。なぜなら、そもそもこれらの競合を引き起こすメタデータの多くを除去するようにgithookを設定するからです。

gitからプルするときにマージコンフリクトが発生した場合、nbdev_fix_mergeを実行するだけです。このコマンドを使用すると、nbdevは、出力に矛盾がある場合にセル出力を使用して出力します。

セル入力にコンフリクトがある場合、両方のセルがコンフリクトマーカーとともに最終的なノートブックに含まれるため、Jupyterで簡単に見つけて直接修正できます。

nbdevがマージコンフリクトをセルを使って表示している例

モジュール式の再利用可能なコードは、標準のPythonモジュールを作成するだけでnbdevによって自動作成されます。nbdevは、コードセル内に「#export」などの特別なコメントがあるかをチェックします。これは、セルをPythonモジュールにエクスポートする必要がある事を示します。

各notebookは、notebookの先頭にある特別なコメントを使用して、特定のpythonモジュールに関連付けられています。

文書による解説ページ(Jekyllを使用しているため、GitHub Pagesが利用できます)は、notebookと特別なコメントから自動的に構築されます。Sphinxなどの既存のアプローチでは必要な機能がすべて提供されていなかったため、独自のドキュメントシステムを作成しました。

vim、Emacs、vscodeなど、ほとんどのエディターとIDEには素晴らしいコードナビゲーション機能が既に組み込まれています。また、ボーナスとして、GitHubはWebインターフェイスでコードナビゲーションを直接サポートします。(ベータ版です。現時点ではfastaiなどの選ばれたプロジェクトのみです！)

そのため、nbdevがエクスポートするコードは、これらのシステムのいずれかで直接ナビゲートおよび編集できるようにし、更に、編集内容をnotebookと自動的に同期できるようにしています。

私達はテスト用に、独自のシンプルなライブラリとコマンドラインツールを作成しました。テストは、探索および開発(およびドキュメント化)プロセスの一部としてnotebookに直接書き込む事が出来、テスト用コマンドラインツールは全notebookにパラレルにテストを実行できます。

notebookの自然に状態を保持するステートフル性は、単体テストと統合テストの両方を開発するための本当に素晴らしい方法であることがわかりました。

テストケースを作成するために特別な構文を学習する必要はありません。Pythonの通常のコレクション操作とループ構造を使用するだけです。従って、学ぶべき新しい概念ははるかに少ないです。

これらのテストは、通常の継続的インテグレーションツールでも実行でき、発生するテストエラーの原因に関する明確な情報を提供します。デフォルトのnbdevテンプレートには、継続的インテグレーション及びその他の機能のためのGitHubアクションとの統合が含まれます。(他のプラットフォームのプルリクエストを歓迎します。)