今出張で、サン・フランシスコに来ています。街はもうクリスマスムードで、楽しげな雰囲気がただよっています。期間限定のアイススケートのリンクが公園にできていたり、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人がいつもブリッジをしながら情報交換をしていた、という話は興味を引かれました。また、会社が傾く予兆として、そのブリッジが行われなくなったのが崩壊の始まりを予兆させたというのもおもしろかったです。少し今の忙しい状況がクリアできたら、会社のチームを巻き込んでやってみたいと思います。インフォーマルコミュニケーションをここまで鮮やかなメタファーで説明している本は初めてです。

軽く本書を紹介してきました。現役のギークの人も、マネージャになりたての人も、普段はなかなか体験できない状況にはまり込みそうな人も、多くの人の役に立つ本だと思います。 ]]> 日記 @shibukawa http://blog.shibu.jp/article/47057592.html Mon, 01 Aug 2011 03:29:35 +0900 ※写真はsphinx-users.jpから拝借しました(shibu.jpと同一サーバですが)。SphinxのユーザコミュニティであるSphinx-Users.jpで、アート・オブ・コミュニティの読書会を行いました。もちろん、フォーカス・リーディングの寺田さんもおっしゃっていますが、読書というのはただ読んで満足するだけではダメです。行動に結び付けるなり、何かしらのアウトプットに繋がらない読書は、ただ「できた気になる」だけでナンセンスです。このブログのエントリーでは、Sphinx..
※写真はsphinx-users.jpから拝借しました(shibu.jpと同一サーバですが)。

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

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

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

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

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

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

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

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

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

まずは2章を読んでミッションステートメントを定めます。2章ではミッション・ステートメントを決定するまでにいくつかのステップが設けられていますので、これに従って完成させていきます。

読み手 vs 書き手

コミュニティの種別として、ファンのグループ(興味の対象を変更することはない)と、自らアウトプットを作っていくコミュニティと2つに分かれます。Sphinxはドキュメントツールであるためややこしいのですが、Sphinxというpocooプロジェクトが作ったツールそのものに対してコードをコミットしていくためのコミュニティではなく、あくまでもユーザとして利用者視点で日本語の説明を充実させて多くの人に広めるのが目的となります。そのため、読み手のコミュニティとなります。

Asakusa.rbみたいに、パッチを書こう、というコミュニティであれば書き手となります。日本の場合は、IT系のイベントでも多くは読み手主体のコミュニティとなるでしょう。

このあたりは、重要な問題であるため、一回で決めきることはできないかもしれません。この次のコミュニティのデザインとの間で何回かイテレーションして決定せざるを得ないケースもあるでしょう。

コミュニティのデザイン

本書中では、次の3項目の質問で定義されているのがコミュニティのデザインとなります。

• ミッションは何か？
• コラボレーションを行う機会、及び領域はどこか？
• 必要なスキルは何か?

最初の「ミッションは何か？」は、読み手/書き手とリンクしています。コミュニティが目指す方向性を決定します。Sphinx-Users.jpでは、

Sphinxを活用して、ドキュメント作成をパワーアップしたい人から、 Sphinxの拡張機能をプログラミングする人まで、幅広くサポートしていく コミュニティを目指しています。

と定めました。おそらく、明文化されているかどうかに関わらず、どのコミュニティもここまではおぼろげに決定していることが多いでしょう。Sphinx-Users.jpも、昨年の設立時のトップページの文言とほぼ一致しています。

「コラボレーションを行う機会、及び領域はどこか？」は、「コミュニティに貢献したい」と思った新しいメンバーが、どのような活動を通じてコミットメントしていくか、を説明する内容になります。ついつい「コミュニティメンバーに何を与えるか？」というマネジメント視点で考えがちですが、あくまでも「コミュニティーメンバー」視点で考えます。例えば「採用事例を紹介することで、他の人の役に立つ」や、「ウェブサイトの間違いを指摘する」などです。Sphinx-Users.jpでも、いくつか候補を挙げました。

「必要なスキルは何か?」は「コラボレーションを行う機会、及び領域はどこか？」が決まってくれば自動的に決まります。ある程度、活動内容に依存して決まるところもあります。

これらの内容が決まったら、最後にミッションステートメントを書きます。本の内容にあわせて、ミッションの掘り下げを挟んでもいいでしょう。今回、ミッションステートメントは、Google Docsを使ってみんなでわいわい言いながら、各自手を加えて作っていきました。Etherpadは同一行編集をしまくるとなんか動きが怪しかったです。

最終的にできあがったのがこちらです。できあがったら、ウェブサイトのトップなどに書いたり、コミュニティ運営で生かすなど、積極的に活用してください。

Sphinx-Users.jp(略称#sphinxjp)は、ドキュメンテーションツールのSphinxの普及を主眼としたコミュニティです。 日本で散らばっているSphinx関連情報を集めて、Webサイト、イベントを通じてSphinx情報を発信します。また、MLやチャットでの情報交換、勉強会の開催などを通じて、ドキュメントをパワーアップしたい人、ドキュメントや翻訳で苦労している人、Sphinxの拡張機能を開発したい開発者たちに”Fun”を提供していきます。

どいつも、順番にやれば100点の回答が出せるというものではないので、一度決めても、数ヶ月おきとかに見直しをかけたり、ブラッシュアップをする必要があります。Sphinx-Users.jpの場合は、翻訳中のArt of Communityの記述なども参考にして、一度おぼろげにやったことがあったため、今回はフィードバックも生かした2回目となっています。

風通しのよいコミュニケーションのためのツール選び

次に、3章と軽く4章、5章も絡む内容の議論を行いました。ミッションステートメント到達に向けて、メンバー同士の情報交換および、マネジメントとメンバー間のコミュニケーション手段を決定していきます。

Sphinx-Users.jpの場合は外部リソースを積極的に使うことにしました。最近流行の質問系サイトと、最近はSNSとしても有名な分散系のリポジトリサービス(Sphinx-Users.jpの場合はBitbucket)の課題トラッカーを利用した、バグ報告・要望フォームです。

また、Sphinx-Users.jpの場合は、ウェブのコンテンツのソース(Sphinx製)がすべてBitbucket上に管理されていて、ここにプッシュすればビルドされてウェブが自動更新されるようになっています。そのため、Bitbucketのforkしてpull-requestという流れも、ウェブサイトの修正方法や加筆の内容の伝達コミュニケーション手段として扱っています。このあたりは、コミュニティ内のワークフローにも関わってくる内容ですね。便利なシステムがあれば、それに対してコミュニティのワークフロー側を合わせるというのでもいいと思います。

宣伝本部長たる、ウェブサイトの構造のリファクタリング

最後に、今までの内容を踏まえて、ウェブサイトを分かりやすくしていきます。まだ見ぬ未来のメンバーが、どういう情報に触れることで自分の参加したいコミュニティを見つけていくのかをロールプレイしながらやると良いでしょう。

今までごちゃごちゃだったコミュニティ情報と技術情報を目次上でもすぱっと分けました。そして、こちらの期待するコミュニケーション手段と使われ方などを明確にしていったりしました。コミュニティの入り口を分かりやすく、ユーザグループに入る際の手順と具体的なイメージなどの情報が、正確なきちんと与えられるようにを議論しました。

本当はあと3時間ぐらいあったら、みんなでcommit＆pushしてその場で修正とかもできたかもしれません。今回は時間がなかったので実際の修正作業は家で行いました。Sphinxという素材を生かして、URLはなるべく変えないようにしました。URLが変わると、はてなブックマークなどにひも付いている貴重なフィードバックも消えてしまうのがツライところ。Wikiで運営しているコミュニティの場合は心を鬼にして切り替えていく必要があるかもしれません。勉強会として行うのであれば、午前中から行ったり、合宿してもいいと思います。

コミュニティの改善は定期的に行おう

今回は、Sphinx-Users.jp設立以来の2度目の方針決定ミーティングでありました。やはり回数を重ねていくうちに、コミュニティの立ち位置もしっかりして、何をやって何をやらないかも具体的に考えられるようになってきます。ぜひ、定期的にこのような場を設けてみてください。また、ユーザ参加型のウェブサービス類も、ユーザ目線での機会のリストアップなどは参考にできると思います。BtoCをしているサービスの方々にも、このような手法が広がるといいなと思います。

また、今回の勉強会では、2章を中心として議論を行いました。このあたりがベーシックな部分であるため重要と思いますが、もちろん、時間があれば本書の紹介していない部分を深めて議論してみてください。

アイスブレークにはナーフ

最後の最後になりますが、このようなミーティングなどでスムーズな意見が出てくるようになるには、みんなが仲良くなるようにして忌憚なく意見を言えるようになる、というのも手ですが、時間がかかりすぎてしまいます。IT系のイベントであれば良くアイスブレークというワークを行ったりしています。

このようなアイスブレークの道具としてイチオシなのがナーフです。最近はいろんな勉強会に持って行くようにしています。僕が買ったのはナーフ N-ストライク マーベリックですが、もともと、DeNAのアメリカの子会社のngmoco:)に出張に行った際に「ぜひこの文化を日本でも広めてくれ」とお土産でナーフ N-ストライク ナイトファインダー EX-3をもらったのがきっかけです。国際企業で外国と積極的に関わる部署なので、他の国の文化を理解するのは大切ですよね！DeNAの僕の部署でも、(飲み会前などに)テンションが上がったり、遊び心がMAXになると撃ち合いが行われるようになってきました。撃ってみると良くできていておもしろいので、ぜひナーフをオススメします！

ちなみに、子会社の様子はこちら↓。最近はFinger Missileという原始的だけど、強力な武器も導入され始めているとか・・・

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

「コンピュータを使って問題を解くなんて、それってズルじゃないの？」と思われるかもしれません。もちろん、「電卓持ち込み禁止」の試験にパソコンなんて持ち込もうものなら、カンニング扱いで退場させられてしまいます。ですが、世の中には、「パソコンで解く」というルールのパズル集なんかもあります。それが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泊は船の上、残り一泊は機内泊というツアーです。地上のホテルに泊まったりとかはなしです。

船の様子

船は想像以上に大きく、プールもあればジムもあり、劇場もあればクラブもあり、レストランがレストランが8カ所、カフェが3カ所・・・かな？雑貨屋が２軒、洋服を売るお店が1軒、宝石屋までついてます。13階建て(客室は4階から)だし、全長もけっこうある(280m)ので、今いる初台のDeNAのオフィスビルの数倍でかいのが海の上を泳いでいるイメージ。エントランスからして天井が高く、立派な階段はあるし、ワシントンモニュメントっぽいものはあるし、水は流れているし・・・すごいです。客室は10階のバルコニー付きの部屋でした。いろいろコンパクトにまとまっている部屋で、なかなか使い勝手は良いです。絵も飾ってあったり、鏡が配置してあったり、広く感じる作りです。広角レンズ持って行かなかったので室内写真はいまいち撮れませんでした。すみません。

ハワイのクルーズ船は、基本的に昼間は港に停泊していて、夜は島の間を航行します。揺れを75%削減する仕組みがあるらしいのですが、ゼロではないですし、船尾の下の階の方のレストランとかは結構揺れがあったりします。それでも良く効く酔い止めはいくらでもリクエストするともらえますし、シーバンドというバンドを着けていたらほぼ問題なしでした(当方、トヨタのレンタカーを自分で運転して酔った経験があるほど乗り物酔いに弱い)。

だいたい、ハワイの旅行というと、1島か2島行く感じだと思いますが、クルーズだと大きな4島(オアフ島、マウイ島、ハワイ島、カウアイ島)を回ることができます。それぞれの地でオプションツアーが色々選べますので、ハワイを満喫できます。

船の生活

ハワイは日本語を話す店員が多く、伊豆に行ったのとあまり変わらない感じがしますが、船内は日本人も多くなく、会話は基本的に英語です。外国に行って日本人がいるとガッカリする、という人もいると思いますが、船内は外国っぽい雰囲気を120%楽しめます。ただし、日本人の船員さんも一人いて相談に乗ったりしてくれますし、レストランには必ず日本語メニューがありますので、英語が得意でなくてもなんとかなります。

船の中の生活は、まず朝起きて、朝ご飯を食べて、オプションツアーに出かけて、帰ってきて夕飯を食べて、夜のコンサートを聴きに行ったりのんびりする、といったスタイルでした。もちろん、船内でもフラ教室があったりするので、オプションツアーに行かないで船内で楽しむこともできます。

オプションツアーは子供から参加できるようなものから、シュノーケリングやスキューバ、ゴルフツアー、ヘリコプターのツアーなどさまざまあります。町中に自分でタクシーなどに出て行って、そこのアクティビティ紹介のお店に行けば、額面上は安いツアーもありますが、それぞれの所でトップクラスのものを揃えてくれているようで、サービスはとても良いです。2人ぐらいならタクシー代だけで値段がひっくり返ってしまうことも多いですが(最終日のサーフィンのツアーがいっぱいで予約が取れなかったので、自分で探しにいった経験から)。また、日本人ツアーのお客さんもいて、日本語のバスガイドツアーみたいなのもあったりします。

ソーシャルゲーム的な課金システム

船内は無料でも楽しめるようになっています。レストランの半分ぐらいは無料です。無料でもかなり豪華なビュッフェ(ビュッフェで有名な伊豆長岡＆那須のサンバレー並かそれ以上)があったり、ロブスターもたまに出てくるようなレストランがあったりします。ちょっとした飲み物類(ソーダ、お酒類)は有料です。また、$10〜$25/人の追加で入れるスペシャルなレストランもあります。入場料だけで、メインディッシュを複数頼まなければそれ以上はお金はかからないです。すごいパフォーマンスの鉄板焼きとかは有料です。無料で遊べるけど、「おにぎりを買うには100モバコイン必要です」というmobageと同じ感じです。ちょっとフィルタかかりすぎだけど↓ここも無料。ピアノの生演奏も聴けます。

それ以外の小ネタなど

ハワイのクルーズツアーに限ったネタ(他のは知らない)としてはこんなのがあります。もし行かれる方は参考にどうぞ。

• フォーマルを用意とあるけど、それほど厳密ではない。ネクタイまでは不要。穴あきのジーパンとかサンダルとか短パンじゃなければ入れるよ、というレストランがあるぐらい。
• ホワイトナイトというイベントがあるので、白い服を持って行くとよいです。
• 最終日に船内の売店で半額セールがあります。
• オプションツアー以外に、無料のシャトルバスが港に来ていて、近所のモールなどに連れて行ってくれる。買い物やお土産は結構しやすいです。
• 出航するときは、ぜひデッキに上がって景色を楽しむと良いと思います。巨大な船がぐいぐい進んでいく様は圧巻です。また、360度海が見える景色の中での夕日がとてもすばらしいです。
• 新婚旅行、誕生日、○○記念日などがあれば、それを伝えておくと、ケーキ(バタークリームを使っていて甘い)をくれて祝ってくれます。

最終日には、映画の撮影などにも使われたという、カウアイ島の絶壁に船を寄せてくれます。大迫力です。

特に、シャトルバスの買い物が良いです。地元のゲームセンターにいったり、地元のスーパーに行ったり・・・もとより観光地よりも現地のスーパーに行くのが好きなタイプなので。「あー、アメリカは今こういうのが子供に流行っているのかぁ」とか色々勉強になります。ちなみにこれが、「ポモドーロテクニック入門」でキュウリと一緒に会話していたアーティチョークです。アーティチョークって日本で知られてないから、翻訳するときはキャベツあたりにした方がいいかな、とかも考えましたが、最終的にはそのまま訳しました。

こちらがゲームセンターで撮った写真。将来美人になりそうな金髪レディがこれを見て「ドーモ！ドーモ！」と興奮しておりました。すっかり日本の顔です。

こちらがモールでゲッツしたソニックグッズの数々。Tシャツは売ってなかった！

初めてのクルーズツアーでしたが、自分のホームとなる部屋にずっと滞在していられるため、荷物とかお土産の面倒を見るのが楽ですし、ホーム自体が移動して色々連れて行ってくれるので、とても気楽にすごす事ができました。とても良かったです。もし夏の一番混むシーズンを外して休みが取れるなら、また行きたいと思います。アジアを回るクルーズツアーもあるみたいですし。クルーズツアーの大半はリピート客、というのが分かった気がします。船員さんのサービスもとても良いです。部屋に帰ると、いろんなタオルの動物がお出迎えしてくれます。ちなみに、このタオルの動物作り講座もありました。

今回の隠れた名脇役

ちなみに表題でも触れているニンテンドー3DSですが、3D写真を撮るのに大活躍でした！まだまだ画質はちょっとしょっぱいし、液晶を明るくするとバッテリーの持ちが悪いというのはありますが、伝説のデジカメQV-10みたいな感じで、また新しいガジェットが登場！という感じですね。暇なときにゲームもできる(1万5000円相当)、3Dのデジカメ(1万円)と考えればそんなに高くない気がする！

3Dで撮った写真はMPO形式(JPEGを2枚繋げただけの単純なフォーマット)で保存されます。また、2Dで撮った写真も一緒に保存されます。3dporch.comなど、3D写真をアップできるウェブサービスもぼちぼち出てきています。エンジニア同士の会でも裸眼の3Dを見ると「おおっ！」となるし、ガジェットとして購入するのをお勧めします。ゲームはそのうち出るだろうし。何枚かアップした画像はこちらから見られます。

3D写真を撮るときは、わざと手前にちょっと障害物が入るようにして立体感を演出するのがポイントですね。ぜひ、僕と会う方は、事前に言ってもらえれば3DSを持って行って写真をお見せしますよ！3DSのディスプレイで見る3D写真はチープながら臨場感あります。

ちなみに、3DSは7月31日までならエキサイトバイクが無料でもらえます！(おっさんホイホイ)。「欲しいソフトが出たら買おう」という人もぱっと買ってしまってもいいと思います。