読み書きができる能力 (Literacy) は、ながらく教育水準をはかるバロメータとして使用されてきました。読み書きソロバンと言われてきたように、 基礎的な数学能力を表す Numeracy という言葉もあります。

これに加えて、近い将来プログラミングをする能力が人間の基本的な素養として重要になってくるのではないかと思っていましたが、同じようなことを考えている方が記事を書いていたので紹介します。

• THE RISE OF CODERACY

彼は Coderacy （コーデラシー）と名付けていますが、なかなかいい名前じゃないでしょうか。

色々考えてしまうので、考えたことをメモしておきます。

CC8800-1という巨大なクレーン車があるそうです。

国内にも何台かあるっぽい。 140mぐらいアームを伸ばせる。

これを使って放水ホースの先端をプールに取り付ける。 取り付けたらあとは使用済み核燃料が冷えるまで、数カ月間注水を続ける。

取り付けは大変そうだけど、ホース先端に錘を付けてプール内に吊るし落とせばいけそうな気がします。

Though it may be needless to say.

There must be languages or grammars hidden in the manner of developing games to have human-beings worked for various tasks.

The main reason of which I was felt in love with Merb is it uses same context for controller and view. By sharing same context, view_helpers and instance variables become simple. You just use them in controller then you can use them in view by same manner. But as you know, Rails3 doesn't.

The reason Rails3 doesn't is probably for caching. If the view has many outer variables that affects its result, the cache key tends to be very complicated. In the manner of Rails3, we can use both action caching and partial caching easily. Because the all variables used in view are clear and small.

But in these days, I am doubting the use of those caching. Now we don't use browsers that has no capability of JavaScript. In addition, Google treats Ajax pages for indexing well. Haven't you ever seen the URI that has '#!'? That's for it. So now, the most of pages can be provided as static html with dynamic JSON. They are combined by JavaScript. There's few situations that the action caching and the partial caching go well.

In conclusion, I think the context should be shared between view and controller so that we can use view helpers simply.

fltkもGLUTも気がつけばFATになっていっている気がします。

• FrameBufferにpixelsをput出来る
• 最低限のマウス、キーボードからの入力をさばける
• Windowは１個. resizeとかは不要

だいたいこのぐらいで十分なので、

• 外部ライブラリに依存しない
• OS/アーキテクチャに依存せず 32bit/64bit で動く
• 初心を忘れない鉄の意志でメンテナンスされている

GUI toolkitが欲しいです。無かったら作ろうかな。

ストレージを操作するための言語として、SQLは制約が大きすぎ、MapReduceは自由すぎるので、中間ぐらいの自由度のストレージ操作言語があると良いと思う。

GIレンダリング言語（aka GIRL）の立ち位置はそのあたりかな。

「天才エンジニア」でIT業界は変わらない

残念なことに、技術者がその技術だけで名前を上げることが出来るシステムは、世界中探してもない。つーか、世の中ってそんなものなのだ。

いまであれば、そんな事は無いと言えると思う。

ウィニー開発者に逆転無罪

金子勇さん、おめでとうございます。

技術だけで名を挙げるには、冒険家である必要があるのかもしれない。 本当に先鋭的で革新的な技術は、社会を不可逆的に大きく変更してしまうので、強い反発や抵抗もあるだろうから。

自然言語の場合はよくわからないけれど、 プログラミング言語に関しては、まず書きたいプログラムが特定の言語に依存せずにプログラムそのものとして脳内にあって、それをプログラミング言語に翻訳しながらソースコードに置き換えていっているように感じる。

多分、フローやデータ構造については、言語の力を借りずに思考できるのかもしれない。

Through my investigation for writing about the parallel computing, I found there are many "incoherences" and "inconsistencies" all over various terminologies regarding parallel computing. I guess surrounding environment is so fastly changing, the center of excellence of this research field has been moved very frequently.

Most of significant works had been done in the era of sequential computing. But for very near future, we will be going into the era of parallel computing. The terms that had been spawned in the hypothetic world would get real body and require coherent and consistent definition of themselves.

ちょっと趣向をかえて製本の話です。

分厚すぎて持ち歩きにくい技術書などを、章ごとに解体するという事はまれにあると思いますが、いつも困るのが章見出しが見開きの左側に来てる事です。

見出しが見開きの左側に来ている場合、章ごとに本を解体すると、見出しのページの裏に前の章のページがあったりして難しい事になります。 それに対して、見出しが見開きの右側に来ていれば、簡単に章ごとに分解して持ち歩く事が出来るようになります。