渋日記@shibu.jp

今出張で、サン・フランシスコに来ています。街はもうクリスマスムードで、楽しげな雰囲気がただよっています。期間限定のアイススケートのリンクが公園にできていたり、ngmoco:)のオフィスの入っているビルにもイルミネーションが飾られていたりします。

PyPy advent calendar に参加しています。@aodagからバトンを受け取りました。今日のこのネタはアドベントカレンダーの記事です。

PyPyはご存知でしょうか？その怪しげな(Pythonらしくイヤラシい)名前にもかかわらず、なんだかよく分からないパフォーマンスを叩き出しているPython処理系です。1.6でもすでにCPythonよりも早かったのですが、1.7ではさらに改善されています。

ですが、このPyPyよりも速いPythonの処理系が存在します。次のスクリーンショットはフィボナッチ数列を計算するベンチマークプログラムの結果です。それぞれの組みの最初の行が計算結果(F₃₁)で、2行目が経過時間です。このベンチマークでは、比較対象としてCPython 2.7.2とPyPy 1.7を使っています。

PyPyはCPythonよりも8.6倍ほど高速であることが分かりますが、「それ」はPyPyよりも5倍ほど高速でした。オリジナルのCPythonと比べると、実に40倍の速度です。にわかには信じがたい結果です。

この秘密のPythonはPyPyに含まれています。Restricted Pythonというもので、略してRPythonと呼ばれます。Zopeには同じ名前のPython環境がありますが、これとは異なります。ベンチマークのコードを以下に貼り付けます。このブログではsmippleを利用しました。Ianさんありがとう！

だけど、そんなインタプリタ存在しないよ

ですが、RPythonインタプリタなどというものはどこを探してもありません。RPythonというのは、Pythonのサブセットの仕様名です。すべてのRPythonのプログラムはPythonやPyPy上で実行させることもできます。PyPyでは、もう一つ、translate.pyというツールを提供しています。このブログのキモはこのプログラムです。translate.pyについて紹介します。

RPythonってなに？

RPythonはPyPyのために作られたサブセットです。PyPyがPythonで書かれている、という話を聞いたことがある人もいるでしょう。ですが、PyPyのとんでもない速度はGuidoが開発しているCPython上で達成された結果ではありません。Pythonで書かれたPyPyのインタプリタのソースコードはtranslate.pyを使ってC言語やLLVM、CLR(.net)、Javaといったバックエンドのソースコードに変換されます。RPythonは軽量言語的な柔軟性を捨てる代わりに、速度を獲得した言語といえます。例えるなら乙女座のシャカですね。RPythonの結果はまさに天舞宝輪です。

py2exeなどのように、このネイティブコードやJavaや.netなどのプログラムを生成できるというところに興味があったので、アドベントカレンダーのネタ作りのためにちょっと触って見ました。

RPythonでコードを書くにはどうするの？

つぎのコードは、すべてのプログラマーにとって馴染みの深いコードサンプルのHello Worldです。

• target関数は、エントリーポイントを定義する特別な関数。
• __name__を使ったブロックはRPythonでは実行されないため、他のPythonインタプリタと互換性を維持するのに使える。
• エントリーポイントの関数は整数を返す必要がある。

つぎのコマンドを実行して、スタバにでも行ってコーヒーを飲んでいると、凄まじく効率の良いバイナリのプログラムが生成されます。

僕はまだ詳しくは調べていませんが、RPythonには速度に関するオプションがたくさんあります。Just-In-Timeコンパイラだったり、ガーベジコレクションのアルゴリズムを選択ｓ地ありできます。上記のベンチマークの結果は単に-O2をつけただけで簡単に実行したものです。また、上記のコマンドラインではCPythonを使っていますが、PyPyを使うと、ちょっと時間の節約ができます。

RPythonプログラミングはエクストリーム・プログラミング

この「エクストリーム」は「エクストリーム・アイロン」的な意味ですお察しください。ほとんどのPythonのコードはそのままでは変換できないでしょう。なんだかC++でコードを書いているかのような気分になりますし、多くの落とし穴があります。ここでは解決方法がわかっているものに限定していくつか紹介します。

関数の中で他の関数を定義

関数定義をネストさせることはできません

多重継承

RPythonは多重継承をサポートしていません。メソッドのコードの共有をしたい場合には、_mixin_フラグを2つ目以降のクラスに付ける必要があります。super()関数を使うこともできません。ただし、多重継承をすることができないため、親クラス群をC3アルゴリズムで直列化することはないので、それほど重要ではありません。

公式サポートされているモジュールが少ない

公式には、os, math, time群だけがサポートされているようです。せめてreを・・・

@propertyデコレータ

プロパティというすばらしい機能を使うことができません。

メタプログラミング

__dict__プロパティにアクセスすることができないため、dir()関数が使えません。もしRPython用のテスティングフレームワークを作るのであれば、古のCppUnitのようにテストメソッドを1つずつ手で登録していくようなコードになる気がします。

関数の引数が、特定のデータ型にバインドされる

通常のPythonでは、変数が型情報を持つことはありません。そのため、C++のテンプレートのように、ジェネリックなアルゴリズムを記述することもできます。しかし、RPythonの変数は型情報を持ち、最初に割り当てられた時にバインディングが生成されます。これには関数の引数も含まれます。

RPythonの印象

なんだか難しいなぁ、と感じました。

最初に、「これが正規表現をサポートしたら、ちょっとした小さなツール開発で使えるかな、と考えました。そのため、pure Pythonで実装されていて、reと互換性を持つrxpyの移植に挑戦しました。しかし、凄まじく難しくて、うまく完成まで持っていくことができませんでした。上記の落とし穴も、この移植中に見つけたものになります。また、RPythonの最も厳しい点は、ビルド時にリソースを大量に消費するというものです。上記のHello Worldのビルドでも1.5分ぐらいかかりましたし、もしPyPyのような巨大なプロダクトをビルドするときは、メモリは4GB以上ないとダメ、だとか。

また、それほど詳しいドキュメントもありませんし、だれかがRPythonの仕様を保証してくれているわけでもありません。そのため、試行錯誤を繰り返して触っていく必要があります。しかし、将来的には、RPythonのアノテーションの仕組みをもっと詳しく知って、RPythonでのプログラミングを支援してくれる便利なライブラリが増えてきたりすると、もっと開発しやすくなるでしょう。

僕は兎にも角にも、このスピードのすごさを目の当たりにしてしまったため、少しずつでもRPythonを触って、RPythonでできることをどんどん広げていきたいと考えています。

PyPyアドベントカレンダーは、つぎは@yanolabさんの番です。

なお、このエントリーでちょっと言葉が難しいなあ、と感じられた方は、とても評判のよい、エキスパートPythonプログラミングという本をおすすめしております。とうか訳しました。よろしくね！

Now I stay San Francisco for business trip. The city become Christmas season and very happy atmosphere. Special ice-skating rink is appeared in the park and the office building that ngmoco:) is in has many illuminations.

I joined PyPy-ja advent calendar . Yesterday @aodag wrote the entry. Today is my turn.

Do you know PyPy? It is a very impressive Python implementation. Its speed become faster and faster. 1.6 was already faster than CPython but 1.7 improved too.

But there is the fastest Python implementation that is faster than PyPy. Following result of the benchmark program that calculates Fibonacci number. Each first lines are the result of the calculation (F₃₁), and second lines are the time to calculate. I uses CPython 2.7.2 and PyPy 1.7 and "it".

PyPy runs 8.6 times faster than CPython. But "that" implementation runs 5 times faster than PyPy. It is more than 40 times faster than original CPython. Do you believe the result?

That secret of that Python is included in PyPy. Its name is RPython, shorten form of "Restricted Python". Zope has same name Python environment, but it is different one. The code of benchmark is following. This entry uses smipple. Thank you for Ian Lewis! He is super cool Python programmer.

But the interpreter doesn't exist actually.

But you can't use RPython interpreter. RPython is the specification for the subset of Python. All RPython program can run on Python and PyPy. One more thing, PyPy provides the tool translate.py. This is a secret of this blog entry. I will introduce translate.py.

What is RPython?

RPython is created for PyPy. As you heard, PyPy is written in Python. But its super exciting benchmark result isn't achieved on Guido's CPython. PyPy interpreter source code is converted by translate.py into C or LLVM or CLR(.net), Java source code. RPython can gain unbelievable speed instead of any flexibility of lightweight language.

I am interested in the feature that it can translate into native or Java or .net execution like py2exe. So I tried it for PyPy-ja advent calendar.

How to program in RPython?

Following code sample is a sample that familiar with all programers - Hello World.

• The target function is the special function it makes decision the entry point.
• __name__ block is not executed. It is useful to keep compatibility with other Python interpreters.
• The entry point function must return integer.

After typing these command and going to Starbucks and drinking coffee, you get super fast native binary program.

I don't research the detail, but it supports many options to improve the speed, like Just-In-Time compiling and Garbage-Collection. Above result of benchmarking was generated by simple option(just -O2). Above sample uses CPython, but if you use pypy, you can save your time.

Programming in RPython is an eXtreme Programming.

This "eXtreme" is a same meaning of eXtreme Ironing. Almost all Python code can't be accepted as is. I felt as if I programming in C++. There many pit falls. I will show the some of them.

Function in other functions

You can't nested function definition:

Multiple inheritance

RPython can't use multiple inheritance. If you want to share the methods, you must set _mixin_ flag into secondary classes. And you can't use super() function. But it is not important any more (because it doesn't use C3 algorithm to create sequence of parent classes).

Official supported modules are limited.

In official document, only os, math, time modules are supported.

@property decorator

It can't support nicer syntax - property.

Meta-Programming

We can't access to __dict__ property. It means dir() function is not supported. If you want to write testing framework, you must add each test methods by hand like older style CppUnit.

Function's parameters are binded specific data type

Variables in Python don't have type information. So you can write generic algorithm like C++'s template. But in RPython, variables have type information and they are binded when first assignment. It includes parameters of function.

My impression of RPython

I felt it is difficult.

At first, if it supports regular expression, I will be able to use it for small tool developing. So I tried to port rxpy (pure Python regular expression it has compatibility with re module). But it is super extreme hard task for me (and I couldn't finish). Above pit falls were found when porting rxpy. And the worst point of RPython is it takes much resources. Compiling above simple took about 1.5 minuits. And I heard building PyPy needs more than 4GB memory.

There is only a little instruction. And no one guarantees the specification of RPython. So we have to try and error to use RPython. But if I can understand annotation system better than now and more useful modules they support RPython programming are released, it will be more useful environment.

But I was moved to the performance. So I want to try RPython little by little to expand the capability of RPython. At first I will read the source code of existing programming languages they are implemented in RPython.

Next person who write PyPy-ja advent calendar is @yanolab.

Mac OS Xには、「古いPCをデュアルディスプレイにする」というコンセプトのScreenRecyclerというソフトがあります。有料ですが。毎回設定の仕方(というか、ScreenRecyclerという名前自体)忘れるので、備忘録がわりにブログで紹介します。

ScreenRecyclerは以前は32ビットモードでしか動かなかったけど、今はどうなんだろう？今のウェブサイトには注意書きがないね。まぁMacは32ビットモードにしても64ビットアプリは動くのであまり困らないですよね。

PCを2台用意

Macが親です。今回はDellのマシンが子供です。VNCはパケットを大量に流すので、ルータ経由などにするとアレゲかもしれないのでLANケーブルでMacとDellを直結しました。まずはネットワークの設定です。まず、MacのLANをローカル設定(固定IP)にします。192.168.1.2にしました。その後に、インターネット共有をかけます。

次はDellのマシンを設定しました。DellのマシンはMacとだけつなげます。Macが192.168.1.2なのでこれをゲートウェイにします。自分はこれ以外のIPにします。192.268.1.3にしました。これで完了です。

VNCでつなぐ

次に、ScreenRecyclerをインストールして起動します。設定でScan RateとかCompression Rateを上げまくると快適になります。

次に、WindowsからVNCで繋ぎます。192.168.1.2:6900に接続します。スクリーンショットはTightVNCですが、UltraVNCでも使えています。

これで快適デュアルディスプレイ生活が手に入ります。みなさんも勉強会にPCを2台持って行きたくなるはずです。MacBook Pro 15とDellのStudio 15の2台を持って熱海の坂を登るのはツライですが！

資料アップロードしました！大規模JavaScriptだけど、エンタープライズではない話ですが、お話をさせて頂きました。こちらが完成版でした。発表時はPCがうまくスリープから復帰してくれなくて、再起動→リカバリしたPPTでプレゼンしたので、2ページ目の大事なこと(後者)が説明できなくて、呪い殺されてしまった人がいないか心配で夜も寝れない日々であります。

ngCore周りで大規模JavaScriptコードを支える仕組みというのは、だいたいこんな感じかな、と思います。

• ソーシャルゲームは非同期で友達とプレイしあうゲームで、アーキテクチャは普通のウェブアプリケーションとほぼ一緒
• ファイルをまとめる(ビルド/ベイク)仕組みは重要
• ファイルアクセス時にビルドするのはコマンド叩かなくていいから良いよ
• オブジェクト指向サポートがあるとうれしい(classキーワードのある言語を使ったことある人は)
• ファイル＝名前空間の仕組みがあるのでモジュール分割が容易
• 階層型のシーン管理と、メッセージのディスパッチの仕組みが忍者ロワイヤルのアーキテクチャのポイント
• 共通ライブラリ
• 今後はデータ駆動をもっと推進していくよ
• 国をまたがって同時開発(git, git-flow/Skypeなどを活用)
• ドキュメントはSphinx(CommonJSドメインも作ったよ！)
• テストはJasmine

DeNA楽しいよ。つい働き過ぎちゃって遅くならないようにいつも気をつけています。

アート・オブ・コミュニティ ―でお世話になったオライリー・ジャパンの高さんから、Being Geek ―ギークであり続けるためのキャリア戦略の献本をいただきました。ありがとうございます。とても興味深い本でした。何度も転職を続け、エンジニアとしても、マネージャとしても、ネットスケープのようなベンチャーから大手まで、いろいろな仕事を経て活躍をしてきたMichael Loppの体験による深い話が満載でした。この本を読んでみて思ったのは、いろんな切り口から何度も読めるな、というものです。

ギークの立場から〜上司とキャリア戦略をハックする

まずはタイトル通り、ギークの立場で読んでみました。ギークの定義については本書でも語られていますが、本書では、ギークとマネージャの2元論で説明されているため、「現場の仕事をしていて、それを愛している人」と一般化してみることができると思います。ギークの場合には＋アルファで対象がコンピュータということもあり、スキルが上がれば定義を理解してルールを元に予測の範囲内で仕事をこなすことができます。他の職種と比べると、「自分の手のひらで世界を作っている」感覚が好きな人が多いという印象があります。木材などの素材に向き合っている伝統工芸の職人などに近いかなと。そのため、人材派遣業の人や、企画書を作って回していくような仕事の方が本書を読む場合にはそのあたりを勘案して読む必要があるでしょう。

そのようなギーク向けに書かれているのは、「システムとしての会社」です。ギークはどうしても出世のための仕事や会議などを軽く見がちですが、上司、キャリアパスなどの背後にある考えやシステム、ルールを見える化することで、どうすれば効率良く良いスコアを稼げるのか、というギークの得意な土俵に持ってこようというアドバイス群です。ギークとしてどんなに高いスキルを持っていても、仕事をしてお金を稼いで日々のドクターペッパー代を稼ぐには、人と接することは必須です。

転職のための面談や上司とのコミュニケーション、プレゼンテーションの仕方など、幅広い項目について、コンパクトにまとまっています。僕も転職をしたり、いろいろプレゼンしたりしていますが、試行錯誤してきた内容のポイントがいろいろ書かれていて、もうちょっと早く出てくれれば・・・と思いました。

マネージャの立場から〜人材採用と人の動かし方

タイトルだけ読むと、ギークの立場を貫き通すための本のように思えますが、ギークと相対するマネージャの立場で読んでも色々参考になることがいろいろと書かれています。中途の採用の面接をしても、会社に来てくれるその日に心変わりしてしまって来るのを辞めてしまった人がいたエピソードなど、こちらもさまざまな体験談を元にしっかりと書かれています。「無能な上司の対処法」などは、逆の立場で見ると「無能な上司と言われないためのアドバイス」ともなるし、最初のXP祭りの牛尾剛さんのプレゼン(アジャイル原理教を滅ぼすために、通し番号のクラス名を強要したりしてダメージを与えようという逆説的な内容)を思い出します。

今の会社の今のチームは、入社して7ヶ月の僕が最古参でも、かなり大きなチームに育っていたりします。このような活発で人材の流入が大きな会社であれば、マネージャという肩書きがなくても本書で書かれた話は訳に立つと思います。また、面接の仕方なども逐一教えてもらえはしないだろうし、この本を読みながらイメージトレーニングすると良さそうです。

沈みゆく船の船員の立場から〜潰れそうな会社でのサバイバル

最後は、幸いにして僕はまだ体験したことのない事象のお話です。前代未聞の前例がないことが起きたりすると、冷静な判断ができなくなってパニックとなります。特に、安定志向の日本の会社は大混乱でしょう。会社が傾いていく様子を生々しく語ってくれる人もなかなかいないのですが(ゼロではないですが)、本書を読んでおくことで、少しでも気分を落ち着けることができます。その結果、その、大変な状況であっても、今後に繋がる冷静な判断を下せるようになるでしょう。潰れそうな会社に止まるメリットなども書かれており、多角的に判断するための視点を与えてくれる本だと思います。

それ以外にハッとしたこと。

最初に説明した通り、この本は原著者の経験に基づくさまざまなエピソードから構成されています。

報奨に金銭を使うのは最後の手段(P133)

これはアート・オブ・コミュニティにも書かれている内容の裏返しです。お金を払わなくても、貢献したいという意志を持って働いてくれる人はいます。「嫌な仕事だけど、お金のために仕方がない」というメンタリティになりがちですが、お金を払わなくても楽しんで貢献したくなってしまう仕事で、さらに「お金までもらえちゃう」というのが最高の職場です。「最後の手段」とまでハッキリ書かれるとキ気持ちいいですね。

会社の昼休みのブリッジ

ネットスケープ社を支えてきていた4人がいつもブリッジをしながら情報交換をしていた、という話は興味を引かれました。また、会社が傾く予兆として、そのブリッジが行われなくなったのが崩壊の始まりを予兆させたというのもおもしろかったです。少し今の忙しい状況がクリアできたら、会社のチームを巻き込んでやってみたいと思います。インフォーマルコミュニケーションをここまで鮮やかなメタファーで説明している本は初めてです。

軽く本書を紹介してきました。現役のギークの人も、マネージャになりたての人も、普段はなかなか体験できない状況にはまり込みそうな人も、多くの人の役に立つ本だと思います。

※写真はsphinx-users.jpから拝借しました(shibu.jpと同一サーバですが)。

SphinxのユーザコミュニティであるSphinx-Users.jpで、アート・オブ・コミュニティの読書会を行いました。

もちろん、フォーカス・リーディングの寺田さんもおっしゃっていますが、読書というのはただ読んで満足するだけではダメです。行動に結び付けるなり、何かしらのアウトプットに繋がらない読書は、ただ「できた気になる」だけでナンセンスです。

このブログのエントリーでは、Sphinx-Users.jpの勉強会を振り返りつつ、コミュニティ運営に本書の内容を生かすための第一歩の踏み出し方を紹介します。

深く本書を理解し、コミュニティに生かすには？

ただ読むだけではなく、実際に自分達が所属しているコミュニティを取り上げて、具体的に議論しながら進めて行きましょう。もちろん、運営はしていないけど参加だけしているコミュニティや、運営も所属もしていない外部のコミュニティを取り上げ、脳内実験してみながら「もっとここはこうしたい」という提言をまとめていく勉強会もできるとは思いますが、さらに深く理解していくためには、

• 自分が運営側として参加できるコミュニティを題材にする
• 実際に、コミュニティの方針、ウェブサイトのコンテンツを操作できるメンバーを揃える

という2項目を揃えて、同じゴールを共有する参加者間で具体的に議論をして深めていく方法がベストだと思います。

この会では、Sphinx-Users.jp自身のミッション・ステートメントを作り上げ、コミュニケーション手段を整理して、ウェブサイトの構成の見直しまで行いました。本書の内容に照らすと、2章の内容が6割で、3〜6章までが4割といった配分です。当日の議事録はこちらです。

ミッション・ステートメント

by The Consortium under CC BY-SA

プログラミングというのは、ゲームとかソフトを作るためだけのものではありません。パズルを解くためにも使うことができます。

「コンピュータを使って問題を解くなんて、それってズルじゃないの？」と思われるかもしれません。もちろん、「電卓持ち込み禁止」の試験にパソコンなんて持ち込もうものなら、カンニング扱いで退場させられてしまいます。ですが、世の中には、「パソコンで解く」というルールのパズル集なんかもあります。それがProject Euler(プロジェクト・オイラー)です。このサイトは英語ですが、日本語訳を掲載してくれているサイトもあります。

数学とか算数がよく分からなかったので好きではない、という人もいると思います。ですが、脳トレブーム以前から、数独(ニコリ用語。パズラー用語はナンバープレース(もしくはナンプレ))はブームでした。ぷよぷよや、テトリスなどの落ちものパズルにはまったことがある方も多いでしょう。そのような方々は、プログラミングで楽しめる素養があります。

公式を覚える必要はありません！

1, 2, 3, 4...と並んだ数列があったとします。さて、1000までの数を全部足したらいくつになるでしょうか？

数学を覚えている方は、(1 + 1000) × 1000 ÷ 2という公式を思い出して、答えを導き出すかもしれませんが、パソコンを使う場合は、数式を覚える必要はありません。

それでは道具を用意しましょう。インストールする必要はありません。インターネットを見るブラウザ上でプログラムが書ける、パイソン・ウェブ・コンソールというサイトを開いてみましょう。

開けましたか？それでは、左側の欄に下のようなプログラムを打ち込んで見ましょう。コピーしてもいいですよ？

sum = 0

for i in range(1, 1001):
    ​sum = sum + i
    
print sum

入力できたら、Runと書かれたボタンを押してみてください。右側に数字が出てきましたね？これが答えです。

このプログラムは、「1000までの数を足す」という問題文をそのまま行います。パソコンは繰り返しが得意です。学校のテストでこの問題が出たとしたら、人間がこの戦法でやると、足し算を間違えたり、時間がかかったりして試験の成績は悪くなるでしょう。ですが、パソコンを使う場合にはこれでもいいのです。

sumというのは、足し算結果を入れる箱です。最初は何も足していないので、ゼロを入れておきます。=記号は代入を表します。右の数値を左に入れます。"←"みたいなイメージです。

"for i in range(1, 1001)" というのは決まった書き方です。これを見ると、コンピュータは一段下がった部分のプログラムを1から1001の一つ手前の数値(つまり1000)まで、1000回繰り返します。現在のループ回数は"i"という箱に入ります。最初の繰り返しでは数字の1が、2回目は2が入るというわけです。

繰り返される中では何が行われているのでしょうか？

ここで使っているのは、最初に使った代入の=記号です。sumとiの合計値を、再びsumに代入しています。最初の繰り返しでは、iが1なのでsumは0から1になります。2回目の繰り返しでは、1から3となります。

最後に結果を右側の画面に出します。printという言葉を書くと、結果を右側に出すことができます。何度も書くことができるため、計算結果を確認しながら出すこともできます。試しに、繰り返しの中で、途中結果を出してみましょう。

# Script text here

sum = 0

for i in range(11):
    ​sum = sum + i
    print "i =", i, "sum =", sum

Runボタンを押してみてください。ね？すごいでしょう？

ifという文を使うと、「3で割り切れる数の合計」を求めることができます。%という記号は、割り算の余りを表します。ifの後ろの式が合っている場合に、ifの中に入ります。「if i % 3 == 0」は、「iを3で割った余りがゼロの場合」となります。つまり、3で割り切れる場合にのみ、ifの中の足し算が行われます。これで、3で割り切れる数の合計を求めることができます。

# Script text here

sum = 0

for i in range(1001):
    if i % 3 == 0:
        ​sum = sum + i
        print "i =", i, "sum =", sum
    
print sum

3で割り切れる数を求めて紙にメモしましょう。それから上のプログラムの3を5に書き換えて実行してみましょう。もう一工夫加えると、「3か5で割り切れる数の合計」を求めることができます。これがプロジェクト・オイラーの第一問目です。なんだか解けそうな気がしてきませんか？工夫次第では、難しい問題を解くことができます。数独を解くプログラムの作り方が書かれた本もあります。

数独では、縦横、枠の中に1から9の数字を並べます。同時に1つしか使えないという制約があります。プログラミングでは、if、for、変数(箱)、足し算や割り算などの演算子といった道具を並べて答えを出します。1つしか使えないという制約はありませんが、上記のforの説明のように、書き方のルールがいくつか決まっていたりします。書き方のルールにさえ従えば、自由に道具を並べて答えを出していけば良いのです。

もちろん、少ない計算量で結果を出せる戦法もあります。プロの仕事となると、このような品質が求められることもあります。ゲームをプレイするなら、絵がたくさん表示される方がプレイヤーはうれしいでしょう。短い時間で計算が終われば、そのぶん、たくさん絵を出すことができます。試しに、アマゾンで「アルゴリズムとデータ構造」と検索してみてください。なんだか似たような本がいっぱい出てきますよね？早いプログラムを作るためにはこのような知識も必要となってきます。

プログラムのパズルとしては、「コード・ゴルフ」というものもあります。これは実際のゴルフと同じく、なるべく少ない文字数で結果を出すプログラムを書く競技です。さすがにホールインワンはできないと思いますが、これも頭を使うパズルです。

※勢いだけで書き始めたエントリーです。Ocaml版、Erlang/OTP版、C++テンプレートメタプログラミング版などのエントリーをお待ちしています。

最近あんまりブログを書いていなくて、「つまみぐい勉強法でアウトプットしろと言ってたじゃないか！」とお叱りをされる方もいらっしゃるかもしれませんが、昨年からの5冊に引き続き、また他の本の翻訳だったり書き下ろしをしているのでブログの時間がなかなか取れないのです。アウトプットは継続中ですよ！

報告が遅れましたが、新婚旅行はハワイに行ってきました。一番の目的はクルーズ旅行がしたかった、というのがあり飛行機でハワイに行き、7泊は船の上、残り一泊は機内泊というツアーです。地上のホテルに泊まったりとかはなしです。

船の様子

新宿のNaked Loftで開催されたTech Lion #2でアート・オブ・コミュニティの紹介をしました。その後はサイン会もしました。当日お買い上げいただいた皆様、誠にありがとうございます。

スライドはこちらにアップしました。PDFにしてみたらファイルサイズがなぜか200MBを超えてしまってSlideshareにアップできなかったので、SkyDriveのPowerPointアップロード機能を試してみました。

アート・オブ・コミュニティの最初の読者として

この本は、Python業界の裏人事部長と呼ばれる、@voluntas(実は同い年)と一緒に、夜中にチャットしながらオライリーの英語サイトの新刊情報を覗いていて「あ、これおもしろそうだな」と思ったのが翻訳のきっかけです。このあたりはこちらのエントリーにも少し書いています。

この本の翻訳中は常にワクワクしながら読むことができました。長期間に亘る翻訳作業でしたが、最後には「もう終わってしまうのかー、残念」という気分になりました。

本書はそのまま額面通りテクニックを利用しようとすると、いろいろ障害があります。プレゼン資料でも紹介していますが、地元の仲間でちょっと集まって読書会をするようなレベル1の人から、世界をまたがるようなコミュニティを運営するレベル99の人向けまで、さまざまなアドバイスが満載です。自分の身の丈に合わせて読み替える必要はありますし、自分でそのアドバイスの方向性に合うアクションを考える必要も出てくるでしょう。

例えば、一番「これって今は不要な気がする」と言われがちなBuzzの説明のところであっても、イベントの開催の告知、イベント運営の協力者募集やら、発表者募集(CFP)など、多くの人の注目を集めたいということはたまにあります。あそこまで念入りに準備して、ティザーサイトみたいな仕掛けを作らずとも、ベースとなるサイトを作って、URLをTwitterで紹介してRTしてもらったり、ブログに貼るバナーを作って宣伝してもらったり、ということは普通に行います。Buzzというのを明確に意識する必要があるのはレベル50以上ぐらいだと思いますが、そうでない人もそのベクトルの活動は必ず行っています。

「使い方はあなた次第！」というクルマが日本ではあまり売れないのと同様、手段をどんどん考えて活用していける人は多くはないかもしれませんが、複数人でコミュニティを運営する際のベースの知識として読み込んでスタートラインを合わせるのが良いと思います。

ちなみに、この本はコミュニティを運営する側の人たちのための本です。参加したい人には「つまみぐい勉強法」がオススメです。ですが、何かを勉強したり、何かを好きになったら、一緒にその技術を高めたり、広めるための仲間とコミュニティを作ったりということは良くあります。勉強会カレンダーでみかける勉強会の多くはそうやって作られたものだと思います。今後ふとしたきっかけで日本を変えようと立ち上がりたくなったときのために、あらかじめ行動の仕方を学ぶのは良いと思います。

既にコミュニティを運営していて、何か(忙しい人など)がボトルネックになって活動がスムーズに流れていないな、と感じている人は速攻アマゾンでクリック！

組織論としてのアート・オブ・コミュニティ

アート・オブ・コミュニティのもう一つの読み方には、組織論として読む方法があります。アート・オブ・コミュニティで語られる組織は実に魅力的です。みんなで同じ目的を共有し、それに向かって一緒にがんばる。同じ志の人が集まりやすいように土台を作っておく。コミュニケーションがスムーズに流れるようにして、一緒にお祭り騒ぎをしつつ周りを巻き込む。完全実績主義。

マネージャ、グループリーダーなどの肩書きの方は、この本に目を通してみると組織の足りない部分と、どうやってそれを良くしていけばよいのか、というヒントを得ることができるでしょう。

会社も転職が当たり前になり、コミュニティ活動を通じて知り合った人が、「あれ？お久しぶりですね」と会社に転職してきて久しぶりの再会をしたりする昨今です。企業も帰属するという考え方の時代は変わり、企業もコミュニティらしくなってきています。プロジェクトXみたいな状況になった時点で優秀な人(よくオファーを受ける人)からいなくなって組織が骨抜きになるということもありえる話です。21世紀の企業の方法論とコミュニティの方法論が一緒だとしてもおかしくないです。

一番大事なこと

当日の発表では、一番最後の一番重要な部分を紹介することができませんでした。ぜひ、楽しい職場で働いてみたい人はDeNAとかに転職するというのもいいかもしれないですよ？気になる方は yoshiki@shibu.jp までお知らせください。ヒミツは厳守しますよ！

Tech Lionは今後も開催されます

Tech Lionは今後も定期的に開催されるようです。なかなか濃い話がもりだくさんでした。次回は9月と言っていたような気がします。まだ参加されていない方はぜひご参加を。