依存するパッケージは厳選しよう

japan.zdnet.com

JS界隈が大騒ぎになった事件だけど、こういった事件自体は完全に防ぐことは不可能だと思う。

今回は依存ライブラリが削除されるだけで済んだけど、 npm install するだけで ~/.ssh ディレクトリを zip にしてどこかに送信するような悪質な攻撃であれば、単にCIが止まるどころでなく、世界中のエンジニアの秘密鍵がばらまかれてあちこちのサーバーにssh可能な事態になったわけで、そんな悪質な攻撃を bugfix なマイクロバージョンアップとして公開される事もありえたわけだ。

第三者のパッケージに依存するということは、それだけのリスクを背負い込むということだ。だが、逆に外部のライブラリに依存しないようにすると、生産性が落ちてしまう。 なので、コードを読む、信頼できるメンテナの公開しているパッケージを選ぶなどといった方法で、リスクとメリットのバランスを取って行かないといけない。

信頼できるパッケージを選ぶ手段の一つとして、既に信頼を集めている人やプロジェクトが信頼しているものを信頼するという方法がある。例えば Babel を使うことを選択した場合、 Babel が依存してる全部のパッケージも信頼して自分のマシンにインストールするということを選んだ訳で、なら自分のプロジェクトでも同じパッケージに依存するというのは合理的な選択のはずだ。

さて、今回の問題で驚いたのは、大混乱を招いた left-pad が、ある程度の技術があるプログラマが見たら一目でクソコードだと判断するような代物だったことだ。

  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

渡された文字列 str に、 ch で指定されたパディング文字を左に追加することで、指定された長さの文字列にする(右寄せする)コードなのだが、「文字列の左側に1文字ずつ追加する」コードがクソなのは多くの言語で共通の認識だろう。実際、事件の後、パフォーマンスを改善するプルリクエストが4件も立て続けに来ている。 https://github.com/azer/left-pad/pulls

問題は、たった17行のコードに、こんなに明らかな問題があるのに、事件が起こるまで誰にも気づかれずに、 Babel を始めとした大量のプロジェクトで利用されていたことだ。 僕は JSer じゃないので憶測だが、この開発者がJS界で超有名人で信頼されていたというよりも、「Babelも使ってるし」といった感じでどんどん依存が広まっていったのでは無いだろうか? Babel の中の人はそこまで考えて依存するライブラリを選んでいただろうか。(Babelよりも先に left-pad に依存していた有名プロジェクトがあったらごめんなさい)

外部のパッケージに依存することには大きなリスクが有ることを認識した上で、それでも利用することで得られるメリットが上回っているか、良く考えよう。

特に多くの人に利用されるOSSプロジェクトでは、そのメリット・デメリットがそのプロジェクトだけでなくコミュニティ全体に「◯◯が使ってるからウチも使おう」という基準で広まることまで考えて、より厳選しよう。

できれば依存するライブラリのコードを読んで、他人におすすめできるコードかどうか確かめ、そうでないならより良い別のライブラリを探すなり、プルリクエストを出すなりしよう。

あわせて読みたい: postd.cc

GAE が Python 3 に対応しました

今日、 GAE が Ruby と node.js をサポートするという発表がありましたが、実際のところ、今まであった Managed VM が GAE flexible environment と名前を変えたようです。

そして GAE flexible environment の公式イメージとして、 Ruby, node.js などに加えて、 Python 2.7, 3.4 もあります。 つまり、「GAE が node.js に対応した」と同じレベルで「GAE が Python 3 に対応」しました。 「Ruby や node.js に対応したのに Python 3 対応しないのかよ!」ということはありません。

とはいえ、昔からあるGAE (GAE standard environment) では、Python 2.7, Java, PHP, Go のサポートだけで、 GAE の大きな魅力だった無料枠が使えるのもこれらの言語だけです。

無料枠が提供できた理由は、インスタンスをゼロまでスケールダウンできる(リクエストが来てからインスタンスを立ち上げられる)からなので、今後 flexible environment の起動速度が改善されたらまた状況は変わるかもしれません。

最近出たPython本2冊紹介

1冊めは入門書。結城さんの Tweet を見て知った。 www.amazon.co.jp

プログラミング自体が初めてという人向けの入門書なので真面目に読む気は無いんだけど、応援のために買ってみた。

中身をかいつまんで読んでみたんだけど、例えばよくある間違いのコードを表示されるエラーメッセージまでセットで紹介していたりして、周りに聞ける人が居ない入門者がこの本を読みながら勉強するときに困ることを極力減らそうという親切さが伝わってきた。

入門書を読む機会が無いのでおすすめ本を聞かれても答えられなかったんだけど、これからはこの本をおすすめしようと思う。

2冊めは「入門書の次に読む本」(ただし、この場合の入門書はプログラミング非初心者向けの入門書だと思う)

www.amazon.co.jp

中上級者向けの本も最近増えて嬉しい限りだけど、この本は Effective Python よりは広く、 パーフェクト Python よりは狭い。 たとえば PHPC# 書いてた人が Python を始めるときに、Python オンラインドキュメントのチュートリアルを読んだあとにこの本を読めばいい感じのバランスになると思う。

miniconda3 が遅かった件

このブログで何度か紹介している TechEmpower FrameworkBenchmarks では、フレームワークごとにテストを Travis で回している。 Python をビルドするときには速度重視で make profile-opt でビルドしたいのだが、ビルド時間が長くなり、 Python 2 と 3 の両方をビルドすると Travisインスタンスタイムアウトして fail してしまう。

毎回同じ Python をビルドするのが無駄すぎるので、高速な Python をバイナリ配布して欲しい。最近はインテルPython が話題だが、多分まだ一般利用は無理だし、(高速化した)数学系のライブラリをバンドルしてるので Web 系にはちと向かない。

数学系のバンドルをした Python ディストリの一つとして Anaconda があり、その軽量版として miniconda があるので、それが高速なインタプリタを使ってるのではないかと期待して pybench してみた。

しかし、 pyenv で profile-opt なしでビルドした Python 3.5.1 が average: 2967ms の環境で miniconda は average: 3293ms と、かなり遅かった。 使っている GCC がかなり古いせいかな。

    Python:
       Implementation: CPython
       Executable:     /home/inada-n/local/miniconda3/bin/python
       Version:        3.5.1
       Compiler:       GCC 4.4.7 20120313 (Red Hat 4.4.7-1)
       Bits:           64bit
       Build:          Dec  7 2015 11:16:01 (#default)
       Unicode:        UCS4

ところで、 Mac の Homebrew では bottle でバイナリ配布ができているので、 PGO が使える Mac では profile-opt をデフォルトで指定してやれば、みんなが時間をかけて自前ビルドしなくても少し高速な Python を利用できるようになるはずだ。今度時間があるときに試していけそうなら pull request してみたい。

判りやすいやり方が1つは必要だ -- その1つだけなら最高だね

はじめてのにき(2016-03-10) を見て。

Python の Zen の一つ "There should be one - and preferably only one - obvious way to do it." はよく誤解される。

これはもちろん PerlTMTOWTDI 「やり方は1つじゃない」に対するものなのだけど、反対の「やり方は1つが良い」という意味では決して無い。 現実的なプログラミング言語でそんなアホな目標を持ってはいない。訳すなら「判りやすいやり方が1つは必要だ -- その1つだけなら最高だね」で、 preferably~ の部分は補助的なものだ。

例えば conditional expresson x if cond else y は、普通の if/else 文と一時変数を使えば良いので、新しいやり方だ。でも、これがない時代は、一部のエキスパートが cond and x or y というイディオムを使ってしまっていた。このイディオムは知らない人にはトリッキーで読みにくい。

最近だと、 Python 3.6 で "{foo} and {bar}".format(foo=foo, bar=bar)f"{foo} and {bar}" と書けるというのも、変数が多い時に読みにくい、format の引数に **locals() を使うという良くないトリックを使う誘惑が大きいなどといったことを理由にとうとう受け入れられた。

つまりこのZenは、新しいやり方を追加するのは今までのやり方よりも明らかに読みやすく判りやすいなどのメリットがあるときで、ちょっとタイプ数を減らすとか好みの書き方だということではやり方を増やさないということだ。

このブログに乗せているコードは引用を除き CC0 1.0 で提供します。