2011年12月10日

PyPyよりも5倍高速な最速のPython処理系

IMG_0844

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

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

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

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

スクリーンショット(2011-12-10 19.23.38)

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コンパイラだったり、ガーベジコレクションのアルゴリズムを選択s地ありできます。上記のベンチマークの結果は単に-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の印象

IMG_0847

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

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

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

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

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

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

posted by @shibukawa at 20:55 | Comment(180) | TrackBack(0) | 日記 はてなブックマーク - PyPyよりも5倍高速な最速のPython処理系

The fastest Python Implementation x5 faster than PyPy

IMG_0844

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 (F31), and second lines are the time to calculate. I uses CPython 2.7.2 and PyPy 1.7 and "it".

スクリーンショット(2011-12-10 19.23.38)

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

IMG_0847

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.

posted by @shibukawa at 20:15 | Comment(173) | TrackBack(0) | 日記 はてなブックマーク - The fastest Python Implementation x5 faster than PyPy

2011年11月18日

ScreenRecyclerで外でも快適デュアルディスプレイ

ScreenRecycler

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にしました。その後に、インターネット共有をかけます。

スクリーンショット(2011-11-18 17.00.57)

スクリーンショット(2011-11-18 17.12.35)

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

network

VNCでつなぐ

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

スクリーンショット(2011-11-18 17.09.54)

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

vnc

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

ultravnc

posted by @shibukawa at 18:21 | Comment(237) | TrackBack(0) | 日記 はてなブックマーク - ScreenRecyclerで外でも快適デュアルディスプレイ

2011年11月09日

ありえるえりあ大規模JavaScript開発の勉強会資料

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

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

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

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

posted by @shibukawa at 13:54 | Comment(299) | TrackBack(0) | 日記 はてなブックマーク - ありえるえりあ大規模JavaScript開発の勉強会資料

2011年08月02日

書評「Being Geek ―ギークであり続けるためのキャリア戦略」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

会社の昼休みのブリッジ

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

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

posted by @shibukawa at 00:54 | Comment(152) | TrackBack(0) | 日記 はてなブックマーク - 書評「Being Geek ―ギークであり続けるためのキャリア戦略」

2011年08月01日

アート・オブ・コミュニティ読書会をしよう!

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

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

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

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

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

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

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

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

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

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

続きを読む
posted by @shibukawa at 03:29 | Comment(127) | TrackBack(0) | 日記 はてなブックマーク - アート・オブ・コミュニティ読書会をしよう!

2011年07月08日

数独/ぷよぷよ好きな主婦のためのProject Euler入門

Sudoku
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++テンプレートメタプログラミング版などのエントリーをお待ちしています。

posted by @shibukawa at 05:54 | Comment(92) | TrackBack(0) | 日記 はてなブックマーク - 数独/ぷよぷよ好きな主婦のためのProject Euler入門

2011年07月02日

新婚旅行のクルーズツアーとNintendo 3DS

CIMG1794

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

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

DSC_0594

船の様子

続きを読む
posted by @shibukawa at 14:24 | Comment(109) | TrackBack(0) | 日記 はてなブックマーク - 新婚旅行のクルーズツアーとNintendo 3DS

TechLion #2でアート・オブ・コミュニティの紹介をしてきました。

IMG_5302

新宿の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月と言っていたような気がします。まだ参加されていない方はぜひご参加を。

posted by @shibukawa at 14:18 | Comment(168) | TrackBack(0) | 日記 はてなブックマーク - TechLion #2でアート・オブ・コミュニティの紹介をしてきました。

2011年05月21日

アート・オブ・コミュニティ出ます

今週は今の会社(DeNA)で初めての海外出張。木曜日の夜中に帰ってきて、金曜日出社して、今日は今から新婚旅行という謎の神様のいたずら的なスケジュールを楽しんでいるところですが、新婚旅行中に、かれこれ2年近く翻訳し続けてきた「アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには」がようやくみなさまの元にお届けできるはこびとなりました。

オライリーなのに、ソースコード(ボーナスページとも呼ばれる)がまったくなく、小さな文字がびっしり400ページの、翻訳者(とレビューの方々)泣かせ(しかもイギリス人っぽいジョーク満載で翻訳に苦戦・・・)なところもありますが、自分で翻訳している文章を読んでいても、ずっとワクワクしっぱなしでした。@voluntasの人とチャットしながら一緒にオライリーのUSのサイトを見ていて、目次を見ただけで一目惚れしました。発売日(2009年の8月1日だったと思う)にPDFと紙の本のセットを買い、速攻で読み始めました。当時の会社は「本を出すのは副業にあたり、副業禁止規定に反する」という感じだったのですが、「この本を出せるなら首になってもいいや」と翻訳を始めました。そうこうしているうちに、なんか本の企画がばらばらと入り始めて、いつの間にか4冊出ていましたが、一番最後のメインディッシュとして、一番最初に出したかった本を出せることになりました。翻訳権がゲットできたのは、野良翻訳を初めて半年ぐらいあとの、とちぎRuby会議です。本書の翻訳者を探していたオライリーの高さんと偶然会うことができて、今に至ります。

原著者は、登場してからあっという間にデスクトップ向けのLinuxでトップクラスの人気を占めるようになった、Ubuntu Linuxのコミュニティで活躍しているJono Bacon氏です。人が集まればフィードバックが増え、システムが良くなって、さらに人が集まるというサイクルであるため、人を集めてきちんとした成果を出し続けるということがこのようなコミュニティでは必要になりますが、それをこなしてきた作者だからこその、直球ど真ん中な内容の本です。よくあるビジネス書のような「これだけやればOKだよ」みたいなチャラいことは書いておらず、一つ一つのアドバイスは奇をてらった内容はないのですが、その分、重みのある内容となっています。ビジネス書を流行のマカロンだとすれば、アート・オブ・コミュニティは伝統のずっしり餡のつまったあんパンみたいな感じです。

一人でできることはちっぽけです。何をするにしても、胸を張って人に見せられるような質/量のものを作り上げるには、多くの方のサポートが必要となります。また、自分の少しの力を提供するだけで、他の人がやりたい夢を実現する手伝いもできます。シュリンクしていく日本経済の中で、今までと同じような幸せを維持していくように軟着陸していくためにはどうすればいいのか?というのは良く言われることですが、コミュニティというのは一つのキーワードになるんじゃないかな、と思います。また、会社と個人の関係も大分崩れてきて、コミュニティに活動するような感じで仕事をしている人も増えてきています。21世紀の企業マネジメントとかも内包しているように思います。

本書を出すにあたっては、日本UNIXユーザ会の法林さん、日本XPユーザグループ(XPJUG)の川口さん、前川(てつ)さん、Python/Sphinxのコミュニティ仲間の清水川さん、Ubuntuの日本のローカルコミュニティ(LoCo)の小林さん、吉田 さん、水野さん、やまねさんに、ばっちりと内容の濃いレビューをしていただきました。何度も何度もチェックして丁寧に指摘をしてくれた、オライリー・ジャパンの高さん、ディベロッパーサミットの合間に質問に答えてくれたJono、朝に翻訳作業をしていても、文句を言わずに見守ってくれていた嫁にも助けていただきました。みなさん、どうもありがとうございます。

簡潔でコンパクトで読みやすい日本語となることをこころがけ、また、日本ではまだまだ需要が低いだろうと11章を無料でWebで出して本からカットするなどしたこともあり、(手間の割に)リーズナブルな価格でお届けできました。原著はクリエイティブコモンズなので、無料でダウンロードできますので、こってりなジョークを味わいたい方は原文もどうぞ。日本語はあっさり醤油味な感じです。

本と言えば「IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)」もコンスタントに売れているようです。この本を書くにあたっても、勉強会について触れました。勉強会はコミュニティの入り口です。アート・オブ・コミュニティは運営側の視点の話ですが、参加する側としてはこちらの本もどうぞ。

つまみぐい勉強法では、タイプ別勉強法として明治維新の4人の人物に例えて説明していますが、この4人のピックアップをしてくれたのが、めんたねというミルトン・エリクソンなどを嗜むコミュニティ仲間の浅生楽さんです。そのさん浅生楽が先日出された「桃の侍、金剛のパトリオット (メディアワークス文庫)」では山県有朋が出てくるのですが、僕がお願いしてピックアップしたところから想像が膨らんで、小説のきっかけになったとか。いろんなコミュニティでの刺激が巡り巡って、いろんな成果が出たりして、なんだか最近楽しいです。

have fun!

posted by @shibukawa at 12:31 | Comment(228) | TrackBack(0) | 日記 はてなブックマーク - アート・オブ・コミュニティ出ます

2011年04月21日

ソニック婚しました

DSC_0006 1

結婚しました。今までご支援くださった方々、どうもありがとうございます。最初にデートしたのが2010/4/18で結婚式を挙げたのが2011/4/17。2011年は転職(ホンダ→DeNA、オモチャ屋→主婦)&結婚と大きく生活が変わります。今後は2人の時間も大切にしなければならないため、気軽に勉強会に行ったり、本を書きまくったりできませんが、今まで仲良くしてくださった方との縁も大切にしていきたいと思いますので、今後もよろしくお願いします。

ちなみに、トップのぬいぐるみは、嫁が服を作ったオリジナルなので、売ってません。

ソニック婚

出会いのきっかけはセガのソニック・ザ・ヘッジホッグです。青いハリネズミです。正確にはソニックの音楽です。ソニック・ザ・ヘッジホッグのシリーズは、初期のメガドライブ版の音楽は、ドリカムの中村さんが担当したということで根強い人気があります。また、SONIC THE HEDGEHOG以降にメインコンポーザを務められていることが多い大谷さんのクラシックを基調としたメインテーマも重厚で好きですけど、私たちは断然、瀬上純さんのファンです。

僕がソニックシリーズを始めてプレイしたのは、ドリームキャストのソニックアドベンチャーで、次はソニック10周年記念パックのソニックアドベンチャー2。嫁はゲームキューブのソニックアドベンチャー2バトル。このシリーズはすごい強烈で、タイトルの強烈なギター、かっちょいい洋楽風の歌の入ったオープニング、ゲーム起動後のメニューでの音声ナビゲーションなど、今プレイしても10年以上前のゲームとは思えないクオリティです。2のオープニングの曲のギターに強烈にやられて、ソニック・アドベンチャー2 ヴォーカル集を二人とも購入しました。このLive & Learnの流れるラストバトルのかっちょ良さは文章じゃ書き表せないです。

2010年に、瀬上さんが何度か東京でライブをされました。そこで出会うことができました。僕が宇都宮で、嫁が浜松とどちらも餃子の町でライバルなんですが、まあそちらは重要じゃないです。どっちもおいしいです。380km。クルマで6時間ほどという遠距離でしたが、無事に今に至る、という感じです。まさにソニック様々です。ちなみに、婚約指輪の裏には「ソニック20周年」って彫ってもらいました!そんでもって、入籍日は、瀬上さんのバンド、Crush 40がライブをやる予定だった日時(4/3の18:00)だったりします。

瀬上さん

瀬上さんは元々、高校・大学とバンドをされていて、「ゲーム会社なら音楽を仕事にできるぞ」とセガに入社された方です。プログラミングの世界でもたまに話題になることですが、仕事と趣味のバランス感覚は人によってさまざまです。「仕事でやるとつまらなくなるから趣味に留めておいた方がいいよ」的なことを言う人もいます。その中でも僕は瀬上さんの生き方が一番好きです。限られた人生の中で最大限世の中に貢献するには、趣味と仕事の両輪を回して全力で回し続けるのが一番だと思います。好きな音楽を仕事にして、仕事の中でバンドを作って、CDまで出しちゃう。ロック系の雑誌で高評価を獲得するなど、仕事と趣味がコラボレーションして、アウトプットも一流。あこがれるよね!そもそも、仕事にしただけで飽きちゃうような趣味は一生モノの趣味じゃないと思うし、仕事としても趣味としてもずっと続けられる活動をしていきたいです。僕にとってはそれがたまたまコンピュータだったというだけの話。僕が最近出している本に「目標はセガの瀬上さん」と一言書いていますけど、こういう気持ちを込めています。

瀬上さんのお話はセガのクリエーターズインタビュー(前編, 後編)で見られますよ。The Best of Crush40TRUE BLUETRUE COLORSThe Worksはマストバイですよ!

僕の好きな曲はWhat I'm Made of, I am...あたりです。嫁はI am...とKnight of the Wind。ただ、残念なことに、ドライブ中に瀬上さんの曲がかかると、二人とも聴き入って会話がなくなってしまうのです。

そろそろ、3DSで新作が出るよという発表も大分前にあったし、据え置き機の新作の話もちらほら聞こえてくるし、瀬上さんが音楽ディレクターとして関わったソニックアドベンチャーの20周年記念サントラソニックアドベンチャー2の20周年記念サントラも出るようですし、今年も色々楽しみです。

お寺の結婚式

結婚式はお寺で挙げました。「ニセ教会で誓うよりはいいよね」と考えて、渋川家の菩提寺のお寺で行いました。共通の知り合いもいないし、「披露宴に100人呼んでも話す時間ないし、別にパーティーすればいいよね?」と、家族だけで式を行い、近所の写真館で二人と家族の写真を撮り、その後はアルポルトでお食事会でした。準備期間はすごく短く、お寺との打ち合わせは2週間前w。出張してくれる貸衣装屋さんに裏赤の白無垢のレンタルをお願いしたぐらいで不安になるぐらい準備がラクでした。また、式中はymotongpoo氏に写真を撮ってもらいました。感謝です。

DSC01945

今までの過ちを悔い改め、仏様の前で誓うという式のスタイル。お経をみんなで読んだりもするんですよ。くばられたのは、字が読めない人向けに絵が描いてある経文。なかなか趣があります。最後には終の棲家のお墓でお参り。住職さんのここ20年ぐらいのお仕事の中で、結婚式をお寺で開催したのはわずか3組ぐらいとのことでしたけど、とても良かったと思います。

DSC02014

あまりネットにも情報はないですが、お寺での結婚式にご興味のある方はメールやTwitterで質問ください。

ということで、結婚報告に見せかけた瀬上さんの宣伝でした。秋に延期されたライブ、みんな行こうね。

posted by @shibukawa at 00:05 | Comment(64) | TrackBack(0) | 日記 はてなブックマーク - ソニック婚しました

2011年03月21日

勉強会の火を守ろう(オフライン編)

Candle
by Peter Zoon under CC-BY

直接震災の影響を受けていない地域の人向け&2011/03時点の状況に基づいて書いています

3月11日に、記録に残る中でも最大規模の地震が発生しました。今このときも、自衛隊、消防、警察の方々が被災地での救援活動を続けていますし、東京電力の社員の方々も決死の覚悟で原子力発電所と向き合っています。海外からも多くの応援が来ています。既に10日目となっていますが、少しでも多くの方の生存が確認されるのをただ祈るのみです。Pythonハッカソン仲間の魚拓の人こと、握力王新沼大樹さんはTwitterの書き込みを見る限り、地震と津波の被害から逃れられたようですが、今は夜盗と闘っているっぽい・・・199Xの世紀末を生き抜いて欲しいです。

東京は直接の地震による影響は宮城、福島、茨城、千葉に比べたら軽微でしたが、発電所の停止の影響で交通網に影響がありました。また、ガソリンの供給が追いつかないなど様々な問題が発生しつつあります。特に計画停電の影響で電車が動かないことで、今までできていた活動がしにくくなっています。この事態は当面続く模様です。

僕は、どちらかというと勉強会を主催する側にいることが多かったりしますが、「計画停電で電車が止まってしまうから、帰れない人も出てしまうし、しばらくや辞めておこうかな」「閉店が早くなって、平日に買い物ができない人もいるから、土日は空けてあげないと大変かな」と思ってしまいがちです。ですが、直接の被害を免れた人達のできることはというと、我慢生活をすることではなく、経済活動を活発に行って、税収や企業の収益の落ち込みを少しでも減らし、災害地域の復興に回るお金を少しでも増やすことです。勉強会に行ってスキルを付けて仕事の中で生かして収益を上げる/転職するなどする。周りの人と一緒に本を書く。そして収入を増やして税金を払う。まあ、勉強会に出ている人はいつも通りですよね。また、少しでも仲間の顔を見て話すことが精神の安定にも繋がります。

ただ、現在の社会のボトルネックは電気とガソリンなので、なるべくここに負荷をかけない範囲で、という但し書きがつきますが(制約理論とかザ・ゴール参照)。それを踏まえたガイドラインを作ってみました。もしご意見・質問等あれば、ここのコメント欄でも、メールでもお知らせください。

東京の休日ならオフライン勉強会はやっても大丈夫(※現時点)

ピークというか、発電能力の制限を超えて、計画停電をしている時間帯でなければ、電気を無理に節約する必要はありません。むしろ電気は溜められないので、「昼間のピークのために、夜のコンビニの営業を止めよう」というのは完全にナンセンスですからね。ここは誤解しないように。まだ、自動車工場などが稼働していないという事情はありますが、例えそれらの工場が稼働したとしても、土日であれば企業の大口の電力受給社が止まっているため、余裕があります。実際、現在でも、土日には計画停電が行われてません。

そのため、土日の勉強会であれば、まったく問題ありません。山の手線沿線であれば、今のところ計画停電の範囲外であるため、飲み屋もやっているでしょう。勉強会・懇親会とセットで開催できます。一人暮らしなら、個人個人で家に籠もって照明を付けたりするぐらいなら、複数人でまとまって電気を使う方が省エネというものです。

ただし、電車の本数がかなり減っています。終電ギリギリを狙って・・・というのはあまりしない方がいいでしょう。懇親会は余裕をもってお開きにすると良いと思います。また、夏が近づくにつれて東京の土日も停電が行われる可能性も大です。状況に応じて判断してください。

東京の平日はちょっと気を付けよう

電車の状況が刻一刻と変わっている状態ですので、参加する方は自己責任できちんと路線の状況を把握してください。鉄道会社には優先的に電力を供給するというニュースも見た気がしますが、まだ折り返し運転をしているところもあると思いますし、普段通りではありません。会社も在宅勤務を推奨するところが今後は増えるでしょう。「会社に行けないのに勉強会に行っちゃう」はさすがにまずいと思うので(社会人として)、慎重に判断するようにしてください。電車は相変わらず前日にならないと状況が分からないのかな?そういう意味で、ドタキャン率も上がるでしょう。仕方ないです。こういう時ですから。有料の会場を使う場合も、いつもよりも多めのマージンをとって集めて、余った分は懇親会 or 次の勉強会で使う、といったことが必要でしょう。

地方の場合

僕も6年半以上栃木で暮らしていましたが、地方の場合は、電気以外にも、ガソリンというもう一つのボトルネックが切実に関わってきます。ガソリンがなければ会社に出社することもままなりません。数日中には解消する見込みとのことですが、平日にしろ休日にしろ、足が確保できるまではちょっと我慢した方がいいと思います。このエントリーの後編として、もう一本エントリーを書く予定ですので、そちらを参照してもらえるといいかな、と思います。

いっそのこと合宿も

今後、夏が近づくにつれて、電力の需給バランスはさらに悪化してくるでしょう。その時は地方に勉強会合宿をするといいと思います。僕も何度もしたことがありますが、とても良いです。東京電力の圏内は停電があるので、それ以外の地域に。僕も松本や志賀高原で合宿したことがあります。スキーシーズン以外の時期のスキー場とかは狙い目です。

また、今後復興が進んできたら、今回の震災の被害の大きかった地域にも行きたいと思っています。今後、長きにわたって復興が行われていきますが、時間がたって忘れさられてしまう、というのが一番復興を遅らせます。勉強会や合宿などで現地に赴くことで、長く心にとどめておくことが大切かな、と思います。

引っ越しにも勉強会戦略を

ちょうど、今は年度末です。僕の周りでも、ぼちぼち引っ越し先をさがそう、という人が増えてきています。震災の日の電車の運休を受けて、「なるべく会社のそばに」という意識で動いている方も多いと思いますが、もし選択肢が複数あるのであれば、勉強会仲間が集まっているエリア、というのも考慮に入れるのをオススメします。かくいう僕が1月に引っ越しをしたのは、悪(Pythonista)の巣窟と言われる、駒込です。夜チャットをしていて「今からファミレスでハッカソンしようか」みたいなこともできます。Rubyistなら都営新宿線でしょうか?非常時を勘案しても、そうでなくても、近くに友達がいることは良いことです。

次はオンライン勉強会について

本当はオンライン勉強会のことだけを書こうと思ったのですが、色々考えているうちに「あれ?土日であればオフライン勉強会も東京ならできるじゃん」ということに気づいたため、2本に分けて、まずオフラインの勉強会についてのみ書きました。次のエントリーでは、オンラインの勉強会について紹介しようと思います。

posted by @shibukawa at 09:20 | Comment(163) | TrackBack(0) | 日記 はてなブックマーク - 勉強会の火を守ろう(オフライン編)

2011年03月10日

先輩から、新人に手渡して欲しいと思って書いた本

IMG_7352.JPG
by Andrew Butts under CC-BY

僕も一筆書かせていただきましたが、新卒準備カレンダー 2011春が非常に盛り上がっています。「IT業界はこんなことが良くない」と、あげつらって、自分があたかも分かっている人間のように振る舞うのは簡単ですし、手っ取り早く優越感を得られるでしょう。日本はどうも評論家気質な人が多い気がして、リスクを冒して渦中の栗をまっさきに拾いに行く人はあんまり多くない気がしていましたが、それでも、今回のように「業界を元気にしよう」「新しく入ってきてくれる人にも、業界を楽しんで欲しい」と思う人が多くいることは心強く感じます。ITでこけたら、もうどうしようもないもんね。内需だけでやっていける国ではないし、今まで強いと言われてきた自動車も情報産業の力を借りないと、設計も何もできない状態ですし、金融系だってそう。IT業界を守る我々こそ、日本の最後の砦、という意識を持っています。

さてさて、アドベントカレンダーでは宣伝くさくなってしまうのを避けるために書きませんでしたけど、自分が書いたIT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書) について紹介しようと思います。この本は、 @nomicoxさんと二人で、編集の野口さんのマンションに通い詰めて、みんなであーでもない、こーでもないと構成を考えて、本にした内容の倍以上の文章を書いて(削って)、まとめあげて書いた本です。本のコンセプトは、「やさしい先輩から、後輩へのアドバイス」「ながくお役に立てる本を」です。

資格とかを並べたとしても、すぐに変わったりするし(1種をとった瞬間に、制度が変わってなくなった世代)、そもそも資格で仕事してないですし、IT業界といっても、分析屋さんから、DB屋さん、インフラエンジニア、プログラマーと多岐に渡っているので、例え仕事が変わっても、変わらず役に立つ「自分で自分を伸ばす力」にフォーカスしています。筆者としては、「先輩が、後輩に最初の一冊として手渡す本」になり、自立して、成果を出せる社会人になるための手助けができれば、と思っています。そういう意味では、発売されたは昨年の5月ですが、本当のスタートは、この3月4月だと思っています。もし本書を読んで「教えたいな」と思ったら、この本を後輩に手渡してくれると、とてもうれしいです。

書籍の内容紹介

1章: つまみ食い勉強法とは何か?

ゆるめのタイトルですが、言っていることはそんなに優しくはなくて、「とにかく、ジャンルが変わってもなんでもいいから、勉強だけは続けよう」という内容です。同じ事をとことん突き詰めることができる人であれば、この本なぞ読まずに、自分で力を伸ばしていけるでしょうけど、何せ様々な所で変動が起きて、いつ自分の仕事の仕方ががらっと変わるか分からないのがIT業界の面白いところです。いろいろと、興味の赴くまま(興味があれば、集中力が続くから、短期でも成果がでる)に、広げていきましょう、という内容です。

2章: 守りの勉強法

あまり書かれてこなかった、仕事の仕方、報告の仕方などです。あまり仕事の中でも、面と向かって説明することが少ない内容ではないかと思います。どちらかというと、仕事でミスして、お説教の中で・・・ということの方が多いんじゃないでしょうか?勉強という意味では、仕事の実践の中で学ぶことは多いです。また、転職して分かったのですが、転職するにも、与えられた仕事にどれだけ一生懸命取り組んできたか、ということが問われます。その仕事を続けるにも、転職するにも、手を抜いてもいいことはなんにもないのです。

3章: 攻めの勉強法

自発的に自分を広げていくための方法を色々紹介しています。読書などのインプット、手を動かすアウトプットの両方が大事ですよ、といった内容が書かれています。ある意味、この章が一番のキモですね。

4章: 勉強法座談会

ちょっと休憩的な内容ということで、僕の尊敬するエンジニアの方々をお呼びして、技術評論社の会議室で行った座談会の内容です。本当に濃い内容で、2時間ぐらいの予定が、気づけば倍以上、話し続けていました。先輩方の業界に対する展望や学びの姿勢は、自分のモデリング対象としてとても参考になると思います。また、若手でない方も、昔話のところでニヤニヤ楽しんでもらえると思います。

5章: 勉強会に行こう

IT業界では、1980年代ぐらいから開催され続けてきて、業界全体を進化させる原動力となってきたのが、この勉強会です。ここ数年間はビジネス書系でも「勉強会」という言葉が聞かれるようになってきましたが、ただ参加するだけではだめですよ、とか、そのようなことが書かれています。一人の勉強と、複数人での学びとの両輪が大切です。

6章: 勉強を思考タイプ別に攻略!

ビジネス書を読んでも、役に立つ本と、役に立たない本があります。それは本自体の問題ではなく、本の著者と読者のそれぞれのスタイルの差が原因です。エジソンみたいに育てられたら、みんな発明王になれるかというと、そうではありません。中にはコツコツ型の、二宮金次郎タイプもいるでしょう。本人の特性に合わない勉強法は、無駄ですし、自信の喪失に繋がるとすれば害ですらあります。この章では、幕末から明治に活躍した人に例えて、それぞれの勉強法を紹介しています。

ちなみに、一昨年前の企画時には、大河ドラマが坂本龍馬になることは知らなかったので、大河ドラマと一緒になったのは偶然です。

7章: 家庭を持っている人の勉強の仕方

この本の一番の特徴的な部分です。もちろん、正解はないのですが、多くの人に聞いて統計的に「みんなこんな風に時間を作っている」ということを紹介しています。ちなみに、僕も今度結婚する嫁には「この章読んでおいて」と渡してあります。「プログラマーはこういう人間だから」というのを紹介する資料としても是非。

posted by @shibukawa at 02:21 | Comment(127) | TrackBack(0) | 日記 はてなブックマーク - 先輩から、新人に手渡して欲しいと思って書いた本

2011年02月28日

ホンダを辞めて、DeNAに転職しました


by kennymatic under CC-BY

昨年の12月末で本田技術研究所を退職し、1月付けでDeNAに転職しました。ホンダが嫌いでやめたわけではなく、自分のキャリアプランや夢と合わなかったのと、DeNAであれば自分の力をもっと生かせるんじゃないか、と思ったからです。。

ホンダを辞めた理由

3年ぐらい前から、「定年まではここにはいないで転職しよう」と思っていました。元々ホンダに入ったのは、カタチのないソフトウェアではなく、カタチのある製品に乗るソフトウェアを書きたかったからです。エンジン制御とか面白そうですよね?実際に配属されたのは、社内SEの部署でした。最初の希望とは違ってはいましたが、SIerとは違い、お金や見積もり、競合といった殺伐としたことをあまりしないで、目の前にいる自動車の設計者と話をして、相手が喜んでくれる仕様を考えてシステムを作るのは楽しい体験でした。

ですが、社内で自分で手を動かしてシステムを作るよりは、外部に外注することが多くなったり、一緒に仕事している人が派遣から請負になって、システム開発がやりにくくなったりという環境の変化がありました。また年齢が上になってくると、自分で手を動かすこともできなくなりそうだったのも「今のうちに辞めないと、ソフトウェアの技術者として周回遅れになりそうだな」と危機感を持ったきっかけです。

決定的だったのが、本を書くことができない、ということでした。3年前に、ウェブマガジンの連載の依頼が来て相談したのですが、「本を書いたり、連載することは副業禁止規定に反するのでNo」ということでした。その後、いろんな会社の友人に就業規則を見せてもらったりしましたが、B2Cの会社の中でもホンダが一番厳しかったです。大手のテレビ局でも、「業務で知り得た内容は許可を取ること」「そうでない内容は自由」という感じだったり、ベンチャーであれば「積極的にどうぞ!」という感じでした。当時のマネージャが、総務と交渉してくれて「雑誌の記事なら社名を出さなければOK」と話をつけてくれて、とても感謝していますが、「日本のIT業界を元気にしたい!」と思っていた僕には、この規則は足かせになりました。本田労組も「余暇をゆっくりするために、十分に余裕のある給与を」というスタンスであったため、「副業を許可する」という方向ではありませんでした。

続きを読む
posted by @shibukawa at 08:36 | Comment(223) | TrackBack(0) | 日記 はてなブックマーク - ホンダを辞めて、DeNAに転職しました

2011年02月20日

Pythonが1位になるXデー

一緒にエキスパートPythonプログラミングを翻訳した稲田さんが、こんなことをつぶやかれていました。 Screen shot 2011-02-20 at 7.52.00

この直後に「あまり数だけ見ても、言語ごとに粒度が違うのでそれほど意味はないだろう」と言われてもいたりするので、特にそこまでこだわっての発言ではないのですが、でもいざ「PYthonのパッケージ数がPerlを逆転した!」となると、きっとslashdot.orgあたりで一瞬だけ祭りになったり、言語ランキングがどうのとか騒がれることになると思われるので、その祭りに備えて、いつごろ逆転しそうかを軽く計算してみました。

日時PyPICPAN
2/11314819255
2/81326619299
2/201339219376

この3週間を見ても、PythonのPyPIの登録数の方が伸びが大きいですね。この3週間だけ見ても、Pythonの方は1日に10件ほど登録があります。最初の1週間のPythonの伸びはすさまじく、このペースでいくと、1年半で逆転しそうです。後半の区間はそれほど多くなく、このペースのままであれば4年ぐらいですね。archive.orgによれば、2007年末で3200、エキスパートPythonプログラミングの出版時(2010/5/28)前後でPyPIは10000を超えたので、実質的なペースはこれらの間ぐらいになりそうです。まぁ、線形ではなく、「9ヶ月で1.3倍」みたいな感じの伸びであれば、もっと早くに数がひっくりかえるかもしれませんが・・・

Pythonがさらに伸びる余地があるとすれば、PythonではPyPIからダウンロードしてインストールするという、cpanコマンドみたいなものはまだ標準じゃないんですよね。追加インストールするライブラリ(setuptools, distribute, pip, buildoutのeggのレシピ)を使うと、cpanコマンドみたいなことは実現できますが、Python 3.3でdistutilsのバージョンがあがって、標準で提供されるようになれば、さらなる伸びが期待されるんじゃないかと思います。厳密に見比べたわけではありませんが、Ubuntuのパッケージを見ると、結構PyPIで見つからないようなものも結構登録されている感じがします。まぁ、Perlもそうなんでしょうけど。

ということで、将来slashdot.orgで祭りになって、「これを予測しているニホンジンがいた!」とリンクされてもいいようにブログに書いてみました。個人的には3年ぐらいで逆転かなー、と思っているのですが、みなさんはどう予想されますか?

posted by @shibukawa at 08:21 | Comment(155) | TrackBack(0) | 日記 はてなブックマーク - Pythonが1位になるXデー

2011年02月11日

ポモドーロテクニックでモニタリング力アップ

ポモドーロたいまー

妹と二人で翻訳した、アジャイルな時間管理術 ポモドーロテクニック入門 が本屋に並び初めてはや2ヶ月ぐらい。最初一ヶ月はずっとアマゾンが品切れ状態で、「在庫が復活したらブログを書こう」と思いつつ、引っ越し、転職などなど、色々盛りだくさんでなかなかブログ更新が止まっていましたが、雪が降って風邪も引いて、Jonoからメールの返信も来ないので久しぶりにブログを書くことにしました。翻訳者として、みなさんよりも一足先に使い始めた効果などを紹介します。

ちなみに、最大で14位まで順位が上がっていたみたい。見てみたかった。

ポモドーロテクニックの効果は集中力だけじゃない

ポモドーロテクニックを初めてすぐに実感する効果が、集中力のアップです。Twitterで「ポモドーロテクニック入門買いました!」という人を地道にリストしてみましたが、みなさん、感想で実感してくれているみたいです。でも、実践してみると違う効果が見えてきます。自分の今の集中力やがんばり具合がモニタリングできるようになってきます。

例えば、翻訳をする場合。「この分量なら3ポモドーロぐらいかなぁ」と結構な精度での見積もりができるようになってきます。そうなると、逆に自分が疲れてきて効率が悪くなった時に、「いつもの1.5倍の時間がかかる」みたいな判断ができるようになってきます。そうすると「今のこのペースで仕事しても1時間余計にかかるから、早めに寝て明日の朝やった方が時間の節約になる」などと定量的に判断できるようなります。

休憩時間はタイマーで強制してもいいのですが、慣れてきたら「おしっ!」という気持ちになるのを自分で待つ方が良いです。(時間の目安でタイマーを動かしているのは悪くないです)。多分、最初は3分でもスイッチが入ります。でも、1日も後半になって、ポモドーロ数が2桁を記録し始めてくると、徐々に休憩時間が延びてきます。「ちょっと近くのコンビニまで歩いて行ってみよう」とか、戦略的に大きめの休憩を入れてみたり、「今日は作業効率が悪くなってきたから明日にしよう」とか、休憩時間で自分の調子が分かってきます。

「自分の様子が分かる」というのは一番大事なことです。PDCAを回すにしても、何を改善するにしても、自分が分かるのが最初の第一歩です。今まではなんとなく、だったのが時間や数字で見えてきます。仕事がたくさんあって忙しくて忙しくて、家に帰るのも午前・・・みたいな状況だったとしても、自分の効率の悪い時間帯を減らし、ボトルネックを減らしていけば、効率を上げていけるはずです。本の訳者の言葉では、GTDとの組み合わせを紹介しましたが、究極的には制約理論(TOC)と組み合わせて行くのがいいかな、と思っています。自分のアウトプットを極大化するには、です。

最近使っているタイマー

iPhoneアプリの一覧はウェブサイトにまとめていますが、色々使い比べてみて、Peakを最終的に使っています。なかなか計画通りに行かなかったり、1日に14ポモドーロ目とかになってくると、なかなか5分休憩じゃスタートできないので、柔軟にスタートできるのが便利です。

Peak - Etienne Segonzac

Screen shot 2011-02-11 at 13.25.14

会社PCも最近Macになっているのですが、PCで作業するときは、Pomodoriと、My Little Pomorodoの両方を一緒に使っています。Pomodoriは終わったときに「今何をやったか」が記録でき、しかもそのデータが貯まっていくため、仕事の振り返りをするのに便利です。ただ、タイマーの動きが素っ気ないので、タイマーが終わっても気づかないのが難点(仕事では音鳴らしまくるとあれかな、とミュートしてます)。その点、My Little Pomodoroの、ドック内でもタイマーを表示してくれたり、終わったらピョンピョンジャンプしてくれるのが良いです。

Screen shot 2011-02-11 at 14.08.07

ぜひぜひ、みなさん、日常生活に取り入れてください。

posted by @shibukawa at 14:15 | Comment(56) | TrackBack(0) | 日記 はてなブックマーク - ポモドーロテクニックでモニタリング力アップ

2011年01月03日

Pythonで5分で便利なことをするレシピ

あけましておめでとうございます。本当は、色々書きたいネタはあるのですが、5分で便利なネタを、ということなので参戦します。

py2exeのお話。Pythonでは、標準でビルドしたり、アーカイブを作ったり、とても便利というか、自分で書くのが面倒な処理をやってくれる、distutilsという便利ライブラリが付いてきます。昔からやっている人は、python setup.py installと呪文のように唱えた経験があるのではないでしょうか?そう、あれです。今時で「easy_installしかやったことないよ!」という方もいると思いますが、このeasy_installもdistutilsの拡張として作られているはずです。

同じようなdistutils拡張に、py2exeというものがあります。これは、PythonをWindowsのexeファイルにしてくれます。実際にネイティブコードになるわけではなく、簡単なローダ+スクリプトファイル(.pyo)&PythonインタプリタのDLLという形式なので(自己解凍のcabファイルと同じ仕組み。プログラム領域より後ろにくっついたデータを処理するようなミニプログラムが先頭についているだけだと思われる)、パフォーマンスが劇的に上がったりはしないのですが、業務でプログラムを配布するには便利です。Visual Basic(6.0以前)的な使い方ができます。

py2exeを実行するには、python setup.py py2exeとコマンドを叩かなければならないのですが、メンテナンスを他の人にお願いするのに呪文を覚えてもらうのはなぁ、とお困りの方もいるかもしれません。そこで、setup.pyとは別に、create_win32.pyというスクリプトを書きましょう。

import sys
sys.argv.append("py2exe")
import setup

これで、「Windowsでこのスクリプトをダブルクリックすれば実行ファイルができるから」と紹介できるはずです。あ、今検証せずに(Windowsマシンが手元にない)、空で書いてますが、これで行けるはず(似たようなことはやった経験あり)。

5分っていいですね。アマゾンで在庫切れ3週目に突入したポモドーロテクニック入門では、25分作業、5分休憩というサイクルで作業を進めます。2-3ポモドーロやって気分転換でもしようかな、というタイミングで自分のノウハウを外だしするのは、自分にも、周りの人にもプラスですよね。

posted by @shibukawa at 09:01 | Comment(219) | TrackBack(0) | 日記 はてなブックマーク - Pythonで5分で便利なことをするレシピ

2010年12月17日

検索エンジン改造して遊ぼう!

Clothing Manufacturer
by efilpera under CC BY-NC-SA

tk0miyaさんから、Python Web フレームワークアドベントカレンダーのパスが回ってきました。ちなみに当方、現在、The Art of Communityの翻訳直しが佳境なのと、本田技術研究所を辞めて転職することにしたのと、それに伴って引っ越しの準備やらで首がまったく回っていません。Pythonのアドベントカレンダーは、なぜか遅れるとバリカンという殺伐した話になっていて、恐怖で禿げそうです。あ、退職の話は年末に落ち着いたら書くかも。

今回のネタは、僕がユーザグループの会長をやっている、Sphinxのお話にしようと思います。Sphinxに関しては、@r_rudiさんが実用系の話を既に書いてくださっていますので、僕はハック方面で話をします。ちょうど冬休みですし、Pythonを使った入門 自然言語処理の本が最近出たり、前にも集合知プログラミングという面白い本が出ていたりして、空前の検索エンジン自作ブームが訪れようとしているのかもしれないけど、やっぱり自分でゼロから作るのはなぁ・・・という人向けのエントリーです。はい。読者少なそうですね。気にせずに進んで行きましょう。

Sphinxの検索の仕組み

続きを読む
posted by @shibukawa at 01:10 | Comment(142) | TrackBack(0) | 日記 はてなブックマーク - 検索エンジン改造して遊ぼう!

2010年09月03日

shibu.jpをSphinxでリニューアル

Screen shot 2010-09-03 at 7.26.05

shibu.jpのリニューアルを行いました。デザイン上は変わっていませんけどね。ようやく、出した本の情報を載せて、「僕の書いた本のタイトルはshibu.jpを見てください」と言えるようになりました。

このブログも、http://www.shibu.jpも、http://www.oswd.org/にあったテンプレートを利用させてもらっています。ブログの方も、このテンプレートのcssや画像を全部アップして、これに合うように、HTMLの構造やら、idやらclassやらを手で合わせていきました。結構手間かかった記憶があります。

今回のshibu.jpの方の改修は、ファイル一式をコピーして、Sphinxの新テーマを作ります。Sphinx-Users.jpにある、Sphinxのテーマの作成や、デフォルトのテーマなどを参考にしながら、layout.htmlを作っていきます。おおよその構造はlayout.htmlが定義してくれているので、それにあわせて、サイドバーとか特定の要素をそちらのブロックにコピペして、コンテンツが入る位置に決まったタグを配して・・・みたいな作業です。こっちの方が簡単。

今回の既存のテンプレートを使ったテーマ作成作業はsphinx-users.jpのコンテンツにしたいし、Pythonハッカソンのハンズオンとしてもやってみたいですね。見た目の良いウェブサイトが簡単にできますし、Sphinxであれば、コンテンツの追加も軽々。タグなしプレーンテキストだから、バージョン管理との相性はHTMLよりも上ですしね。shibu.jpのコンテンツはbitbucket上にも保管しています。テーマとか見てみたい方はどうぞ。

見るべきは、layout.htmlですね。40行目からのサイドバーブロックのマクロの中に、今まで使っていたガジェット類(画像表示、ブログ最新エントリー、アクセスカウンタ)のHTMLやらJSをコピーして入れ込んだのと、218〜250行目のbodyタグ内。とくにこの2箇所は、ダウンロードしたテンプレートが指定したclassやidをきちんと使うようにHTMLの構造を直していきます。Google Chromeの”Inspect Element"や、FirebugなどでHTMLの構造を比べながら直していきます。あと、Sphinxはオプションで左右のどちらでもサイドバーが出せるようになっていますが、デザインの都合上で、出す方のみを残しておきます。

HTMLオーサリングツールとしてのSphinx。いかがでしょうか?そろそろWEB+DBプレスあたりから取材が来てもおかしくないころ。

posted by @shibukawa at 07:58 | Comment(81) | TrackBack(0) | 日記 はてなブックマーク - shibu.jpをSphinxでリニューアル

2010年08月28日

新しいKindleの日本語フォントは読みやすい

IMG_0303

新しいKindleが届きました!WiFiモデルのKindleです。発表直後に予約したら、発売日に合わせて発送してくれたのかな?今度のKindleの目玉は、日本語フォント。ということで、さっそく日本語を表示させてみたいと思います。あ、ちなみに、実家の無線LANの調子がいまいちなせいか、まだネットにはつながってません。たぶん、ウェブの閲覧はまだまだ厳しそうです。そっちの用途ならiPadの方がいいです。

日本語を表示するには日本語コンテンツを作る必要があります。Amazonでは、WordやHTMLなどをAZW形式に変換してくれるサービスがあるので、これを利用して作りたいと思います。選んだのは、昔自分で翻訳した、EUnitユーザガイドにします。

Screen shot 2010-08-27 at 15.24.02

これをコピペして、Wordに貼り付けました。Amazonでは下記の形式からの変換をサポートしています。まぁ、データ交換フォーマットとしてはWordが確実かな、と思ったのでこれで。2003形式(.doc)で保存しました。Erlang、JUnitなどがスペルミスで赤線が引かれているのはご愛敬。

Screen shot 2010-08-28 at 7.28.38
  • Microsoft Word (.doc)
  • Rich Text Format (.rtf)
  • HTML (.htm, .html) 画像も一緒にzipでOKなはず。
  • Text (.txt) documents
  • Mobi book
  • Word 2007(.docx) (実験的サポート)
  • PDF(初代Kindle向け。2世代目以降は直接読める。実験的サポート)

で、次に、@free.kindle.comのアドレスに貼り付けて送信します。各デバイスごとにアドレスが一つ割り振られているので、自分用のアドレスに送ります。しばらくすると、送信元のアドレスに、変換後のファイルへのリンクが載っているので、そこからダウンロードして、USBで繋いだKindleのdocumentsフォルダにコピーします。

Screen shot 2010-08-28 at 8.10.02

さっそく見てみましょう。iPhoneのカメラで撮ったので、いまいちみにくいかも。すみません。うまく伝わるといいのですが、かなり読みやすいです。

IMG_0304

もちろん、PDFと違って、フォントのスケーリングができます。間隔の調整とかもできます。これはでかくした時の例

IMG_0308

これが一番小さい文字の例。現物でみても、十分読めます。あと2周りぐらい小さくてもいいぐらい。でもまぁ、新聞のフォントも大きい時代なので、小さくてもいいという人はそんなにいないのかな?

IMG_0309

Text to Speechは残念ながら、日本語の部分は読んでくれませんでした。日本語を学習する外国人には売れないかも。もちろん、英語を勉強する日本人には最高のデバイスであることは間違いないですし、おまけ機能はおまけとして、まず読書にフォーカスする、そして、その部分で最高の体験を安い値段で提供するというKindleのコンセプトは個人的には大好きです。iPadも持っているし、KindleもGlobal Wirelessになった2、DXに続き3代目ですが(2は母親に譲って、英語の小説読書用に活用されてる)、このKindleは良いです。

昨日見せた人にも、好評で「小説は全部これで読みたい」という人もいました。片手で軽々持てるので、ちょっと混んでいる電車でも問題なし。あ、ちょっと筐体は先代のKindleよりは華奢な感じはします。今までのKindle持っている人ですら「買い換えたい」と言う人が何人もいて、このKindleの進化の方向性は正しいと思います。スペック上は地味だけどね。見ると欲しくなる魔力。電子ペーパーの紙っぽさ(コントラスト的に)も向上しました。まだ真っ白なコピー用紙とはいかないですが、わらばん紙から、古紙使っているコピー用紙レベルに進歩。書き換えはまだまだ速読に耐えうる速度ではないけれど、安くてそこそこ良いデバイスであれば欠点は急速に改善されるものなので、そこは心配してません。プラズマvs液晶みたいなもんですよね。

posted by @shibukawa at 08:30 | Comment(125) | TrackBack(0) | 日記 はてなブックマーク - 新しいKindleの日本語フォントは読みやすい