Python で複数のバージョンをサポートするのがしんどい
すでに Python 3.1 もリリースされ、また 2.7 のリリースも近いというのに、世の中ではいまだ Python 2.3 や 2.4 が現役で使われている。
たとえば、サーバ用 OS としてよく使われる CentOS 5 では、Python のバージョンは 2.4 である。
またレンタルサーバの xrea.com では、2.3 と 2.4 が半々ぐらい。2.5 はインストールすらされてない。
そんなわけで、Python のライブラリをリリースするなら、下は 2.3 や 2.4 から、上は 3.1 までサポートするのが望ましい。だけど、それをしようとすると Python はかなりめんどくさい。
たとえばデコレータやジェネレータ式やset()が導入されたのは 2.4 からなので、2.3 をサポートしようとすると使えない。
## デコレータやジェネレータ式は 2.4 以降 @classmethod def f(cls, *args): print ", ".join(str(x) for x in args) ## 2.3 をサポートするにはこう書く必要がある def f(cls, *args): print ", ".join([str(x) for x in args]) f = classmethod(f)
また try/except と try/finally が同じインデントで書けるようになったのは 2.5 から。あと条件演算子も 2.5 からだから、2.4 をサポートしたければ使えない。
## 2.5 では try/except/finally が同じインデントで書ける f = open('file.txt') try: s = f.read() except Exception, ex: logging.error(ex.message) finally: f.close() ## でも 2.4 をサポートしたければ、ネストしないといけない f = open('file.txt') try: try: s = f.read() except Exception, ex: logging.error(ex.message) finally: f.close()
Python はバージョンアップごとに少しずつ改善されていっているのはわかるんだけど、なんというか、構文レベルの変更があるので複数のバージョンをサポートするのがしんどい。exceptとfinallyが同じレベルで書けるようになったのが 2.5 からとか、はぁ？とか思うんだよね。こういう基本的なところはもっと初期からサポートしておいてほしい。
ほかにも Exception クラスが new-style になったのが 2.6 からとか、今までなってなかったのかよ！と思う。new-style class の導入自体はもっと古くからされてるんだから、そんな変更は 2.3 や 2.4 のころで済ませといてほしい。2.6 で動かしたらテストがエラーになりまくって焦ったわ。
このへんは、まだ PHP や Ruby のほうがましだよね。Ruby の構文は 1.6 から特に大きな変更はないからサポートは楽だ (今さら 1.6 をサポートする必要はないけど)。条件演算子は昔から使えるし、begin/rescue/ensure はいつでも同じレベルで書けるし、クラス定義が new-style に変更されるなんてこともない。
人によって感じ方は違うだろうけど、Ruby は言語のコンセプトが最初からしっかりしている (ように思う) から、構文レベルの変更とか Object クラスの仕組みが変わるとかなくて、変わるのはライブラリのほうだけだから複数バージョンのサポートは別に難しくない。でも Python のように object レベルでの変更とか構文レベルの変更がちょくちょくあって、かつ古いバージョンも広く使われていたりすると、複数バージョンのサポートはかなりしんどい。
特に Python 2.x と 3.x の両サポートは泣きそう。構文レベルで互換性がないから、えらいトリッキーな書き方をしないといけない。かといって、2.x と 3.x とでソースを分けるのもメンテナンスが超めんどくさい。Ruby 1.8 と 1.9 の両サポートが簡単なのに比べると、どうしても、ね。
いつまで Python の古いバージョンをサポートしなきゃいけないのだろうか。少なくとも CentOS 5 はあと数年は現役で使われるだろうから、その間は 2.4 のサポートは必要だろう。また Google App Engine は 2.5.2 だから、App Engine ユーザは Python 3 への移行なんて当分できそうにない。Google がとっとと 3 に移行してくれないと、Python 3 が主力になることはないように思う。残念ながら。
そんなわけで、どなたか Snow Leopard で 2.4 や 2.5 をコンパイルする方法を教えてください。いろいろぐぐっても、さっぱり解決できへん。
VCS において Git が革新的な点
はっきりいって、Git の CUI は使いづらくてわかりにくい。サブコマンド名やオプションが開発者目線で決められており、ユーザからどう見えるかという視点が欠けている。その点、Subversion はよく考えられて洗練されていたし、それを受け継いだ Mercurial も使いやすい。Linus は Subversion をこき下ろす前に Git のコマンド体系を整理すべき。
ただ、Mercurial などと比べて Git が革新的にすごい点がひとつある。それは、バージョン管理システムに Garbage Collection (GC) の概念を持ち込んだことだ。みんなあまり注目してないと思うけど、こいつはほんとうに kool な機能だ。
GC はもちろんプログラミング言語の分野での概念だけど、そのプログラミング言語の世界では、GC が一般的に使えるようになることでプログラミングスタイルが大きく変わった。それまでならメモリ管理を気にして、確保したメモリ領域を何度も使い回すスタイルだったけど、GC が普及してからは、メモリ管理を気にせず一時的なオブジェクトをじゃんじゃん生成することが当たり前になった。この、一時オブジェクトの生成を気にしないというスタイルのおかげで、プログラムを書くのがずいぶん楽になった。
Git にも同じことがいえる。Git は、使われなくなったコミットを掃除してくれる GC 機能があるので、一時的なコミットを気軽にじゃんじゃん作成できる。コードを変更したらとりあえずコミットしておく。気に入らなければ reset する。reset すると、どこからも参照されないようなコミットができちゃうけど、Git なら GC があるから気にしなくていい。
これが Mercurial だとそうもいかない。先に断っておくと、Mercurial のリポジトリは非常に洗練されており、Git の素朴な仕組みと比べると開発者のセンスが段違いに光ってる (つまり Mercurial の作者は Linus より頭いい、多分)。ただ、Mercurial のリポジトリは追記型アーキテクチャなので、使いもしないコミットをじゃんじゃん作成してあとからなかったことにするという使い方や、今までのコミットを付け替える rebase のような機能にはうまくフィットしない。
Git と Mercurial のどちらがアーキテクチャとして優れているかは、結論のでない問題だと思う。かたやファイルをまるごと圧縮して差分すらとらない*1という、素朴であるがゆえに新機能を追加しやすいアーキテクチャ、かたやスクリプト言語で実装されているのに非常に高速に動作するという洗練された、しかしそれゆえに想定外の使い方には弱いアーキテクチャ。どっちのほうがすごいかは、ワシのようなものが口を出すのもはばかれる。ほんとうにどっちもすごいと思う。
ただ、Git が GC を装備していてそれが実に画期的なことであるというのは、もっと知られていいはず。ワシは Git の CUI がすごい嫌いで、GitX がなければ Git なんか使ってないんだけど、でも VCS のリポジトリに GC の概念を持ち込んだ Git の功績は末代まで讃えられるべきだと思う。
*1:packしなければ。
「分散 VCS」という名前はよくない
Git は RCS っぽい
lifeLOG + REPOsitory: 平等分散リポジトリの見せる夢
ワシもそう思う。Subversion のときはリポジトリを作って http.conf に記述して Apache 起動して…みたいな作業が必要だったけど*1、Git や Mercurial はそういう手間が全然いらない。バージョン管理をしたいと思った瞬間にすぐできちゃう手軽さが、まさしく RCS を彷彿とさせる。分散 VCS 万歳。
あーでも、「分散」VCS という名前はよくないと思う。Git や Mercurial は、リポジトリが「分散」しているわけじゃなくて、単体で完結したリポジトリが相互に連携できるというだけだから、「Distributed」とは違うんじゃないかなあ。少なくともワシは最初のころ、Git は P2P 的な仕組みを持っていて、コミットするとそれが複数のリポジトリに分散されて保存されるのだと勘違いしてた。勘違いを生み出す名前よくない。
ワシ的には、Subversion のほうがよっぽど「分散」的だと思うんだよね。Git や Mercurial と違い、Subversion はリモートリポジトリのすべてをローカルにコピーする必要はない。自分が作業するのに必要な部分だけを取ってこれて、自分が必要としないものはリモートに置いたまま。リポジトリをまるごと clone しなきゃいけない Git や Mercurial と比べると、こっちのほうが Distributed な感じがしない？
リポジトリをまるごと clone しなきゃいけないアーキテクチャは、下請け構造のプロジェクトには使いづらいと思うんだけど、どうですかね。末端の下請けプログラマには自分の作業範囲に関係するソースだけを与え、全体のソースは渡したくない、という要求はごく普通にあると思うんですけど。
他にも、ゲーム開発なら画像データや音楽データやムービーデータをバージョン管理したいと思うけど、それらを全員が自分のローカルマシンに保存しなきゃいけないというのは、どう考えても無駄です。
だから、Git も Mercurial もまだまだ改革できる余地はあると思う。
「我々の間にはチームプレイなどという都合のよい言い訳は存在せん。あるとすればスタンドプレーから生じるチームワークだけだ」
http://www.magi-01.jp/sac/1st/words_aramaki.htm
Git や Mercurial は、まず互いに独立した Stand Alone なリポジトリがあって、それらが必要に応じて連携するというだけだから、まさに『スタンドプレーから生じるチームワーク』そのものだと思う。「分散 VCS」という呼称はやめて「SAC VCS」と呼ぶのはどうか。
*1:必須ではないけど必要ではあった
Google が CPU 開発に乗り出す可能性
なんの裏付けもない、まったくの個人的な妄想だけど、Google はそう遠くない未来に、CPU 開発に乗り出すという予想をしてみる。いやいや汎用品を使うからこその Google なんだと言われるだろうけど、それなりに根拠はある。
- Google にとっては、CPU の単体性能よりも電力あたりの性能 (もっといえばデータセンターあたりの全体性能) のほうが重要。たとえば、性能は Intel CPU の半分しかないけど消費電力が 1/10 であるような CPU を 10 個使えば、(単純計算だけど) 同じ消費電力で 5 倍の性能が手に入る。
- オープンソースにより、バイナリ互換性の重要性が下がってる。特にサーバサイドなら Windows が動かなくて構わないので、x86 である必要性が少ない。
- 言語やコンパイラや VM を作れるエンジニアが自社にたくさんいる。Chrome は JIT を搭載しているし、オールスターなみの面子による Go 言語のニュースも記憶に新しい。CPU が変わってもうまくやれそう。
- 今は元 Sun のエンジニアが数多く流出している。SPARC や Niagara の設計をやっていたエンジニアや、あるいは Java VM を作ってた人が Google に入る可能性は十分高い。
- すでにイーサネットスイッチは自社開発しているらしいし、ルータも自社で開発中と言われている。必要とあらば CPU を開発したっておかしくない。
- 既存の CPU が、Google が必要としている命令を備えてない可能性がある。たとえば「検索アルゴリズム向けの命令」があると検索が非常に高速化できることがわかったとすると、独自 CPU を開発する動機になる。
- Google が購入する CPU の数は非常に多く、しかも今後も増え続けることが予想される。Intel に払っている金額もものすごいはずなので、ここを削減する方法は考えているはず。
- 『Google が CPU 開発に乗り出した』というニュースや噂がでれば、Intel の株価に影響が出るのは避けられない。ということは、そういう話を示唆するだけで、Google は Intel との価格交渉を有利に勧められる。つまり、開発に本気じゃなくても、ブラフだけでも Google には有利な材料になる。
- Apple が独自 CPU に走った。iPhone と iPad の市場規模でも独自 CPU の開発コストがペイするなら、Google の規模でも十分ペイする可能性は高い。
問題は、どこまで本気で乗り出すか、という点かなと思ってる。あと特許も。
・・・と思っていたら、こんなニュースが。
この記事によると、Intelは既存のCPUを新たなものに作り直すために、今年の第2四半期の終わりごろに研究者たちに対して48コアのCPUを実験的に出荷する予定だそうです。
48コアモデルのCPUは主に学術機関などに対して送付される予定となっており、Intelの研究所に勤務するSean Koehl氏によると、このCPUは研究プロジェクトの一環であるため、商用に展開できない可能性があるものの、採用されている機能に関しては、将来登場するであろう新たなCPUにも搭載されるだろうと述べています。
なお、このCPUが開発された背景や動作速度ですが、自動車やサーバーまで、あらゆるデバイスにおける計算速度を高めるために、1つのCPUにさらに多くのコアを導入する研究の一環で開発されたもので、動作クロック数については、1.66GHzないし1.83GHzで動作する新型Atomプロセッサと同等になるとのこと。
ついにIntelが「48コアのCPU」をサンプル出荷へ、最小消費電力は25ワット - GIGAZINE
性能が低いけど極めて低消費電力なコアを多数集めたもの・・・まさに Google 向けじゃん。値段次第では Google が大口のお客さんになるかもね。
より詳しい記事はこちら。
米Intelは2日(現地時間)、Intel Architecture(IA)ベースのコアを48個集積した研究用のプロセッサ「シングルチップ・クラウド・コンピューター(SCC)」を開発した。
今回の試作では、P54C(Pentium)ベースのコア48個を、2Dメッシュのネットワークで構築した。2つのコアを1つの“タイル”としてみなし、2つのL2キャッシュと共通のメッセージバッファ/ルータを持つ。そして4つの“タイル”を1つの“島”として扱い、各々の島の電力や動作クロックをコントロールできる。さらに、この“島”を6つ組み合わせることで、48コアを実現した。
タイル間は、独自の高速ネットワークで構築され、256GB/secの転送速度と、低レイテンシで接続されるのが特徴とされる。Intelでは、クラウドデータセンターに非常に似たマルチプロセッサの構成を、この1チップで実現できるようになったため、SCCと名付けたという。
Intel、48コアのIAプロセッサを開発 - PC Watch
App Engine で DI を使うメリットはない？
DIの主なメリットは、テストのしやすさと宣言的トランザクションだと思いますが、AppEngineではモックなしで簡単にテストができ、Bigtableの仕様的に宣言的トランザクションはほとんど使えないので、AppEngineでDIを使うメリットは余りないんじゃないかと思います。単に複雑になるだけ。
これが、Slim3でDIをはずした理由です。
2009-11-15 - yvsu pron. yas
うーん、どうだろ。DI のメリットって、システムを疎結合にできることだと思うんだけど。疎結合にできるから、たとえばテストがしやすくなったりするわけで。疎結合にできるメリットは App Engine でもうれしいと思うけど、違うのかな。なんか他の意図があるような気もする。
それより、『単に複雑になるだけ』という言葉が気になる。やはり Java 屋さんにとっても、DI コンテナを使うのは複雑さが増すという認識なんですかね。『DI は簡単だ』という人もいれば『複雑だ』という人もいて、どちらも都合のいいときに都合のいい主張をしているだけのように見える。
あと『AppEngine』が正しいのか、それとも『App Engine』が正しいのか、非常に気になるんですけど、実際どっちが正しいんでしょうか。2ch のスレが『AppEngine』と『App Engine』とで分かれてて混乱するわ。
Mac OS X でUSBメモリのアンマウントをコマンドラインから行う
$ sudo diskutil umount /Volumes/NO\ NAME Password: Volume NO NAME on disk1s1 unmounted
Google App Engine で Java を使うと起動時間が数秒もかかるらしい
上記3つの対策を施し、詳細は省略しますが約50回の起動で、最小3693ms、最大14303ms、平均6884msとなりました。対策前（平均8895ms）と比較すると2000ms程度の改善です
GAE/J、起動時間（spin up時間）短縮の試行錯誤 : CB NANASHI管理人ブログ
これ、まじなのか。『平均6884ms』って、つまり起動に6.8秒もかかるってことだよね。
Google App Engine で Java を使うと、起動するのに平均で約7秒、最大で14秒もかかるのか。これはひどい。
この上でさらに JRuby + Rails を動かしてる人たちはすごいな。尊敬はするけど、真似しようという気にはならない。
ところで実際にサイトにアクセスしてみたが、数秒も待たされることは全然なくて、さくさく表示された。比較的アクセスがあるサイトなら、起動時間はあまり考えなくてもいいということかな。
