node.jsとは何か(3)

今日はnode.jsで採用しているCommonJSの話である。
CommonJSの説明だけだとあっという間に終わってしまうのでJavaScriptの歴史を混ぜ込んだら期せずして長くなってしまった。

さて、1995年に発表されたJavaScriptは開発当初「Mocha」と呼ばれ、次に「LiveScript」となり（実際Netscape Navigatorの2.0のアルファ版ではではこの名前だった）、最後にようやくJavaScriptになる(Navigatorの2.0B3から)という変遷をたどった。このJavaScriptという名前っていうのはJavaというコンパイル言語を補完するスクリプト言語にしたいという考えがあったからという話もあるんだけど、そのころ開発元のNetscapeはSunとの業務提携を発表しており、ちょうどそのころJavaが世に出てNetscapeブラウザ上でクールなJavaアプレットが動くんだぜなんて発表されて世間が沸いていたもんだからマーケティング上、Javaの冠をかぶせてその人気にあやからせてもらおうとNetscape側が思っていたとしても全然おかしくない。むしろそちらのほうが自然に感じる。

で、1996年にMicrosoftもJavaScript互換の言語を作るんだけど商標問題を避けるため、JavaScriptという名前を自社製品で使うことができなかったので結局JScriptという「心中お察しください」的な名前を使うことになる。

その後Netscape社はJavaScriptの地位を確固たるものにしようとしてその後ECMAという機関に標準化を依頼し、仕様が決まるのは1997年の6月のこと。結果としてECMAScriptという名前で標準化されたんだ。この4カ月後の10月にはMicrosoft陣営はInternet Explorerの4.0にてこのECMA-262 1st editionに準拠したと宣言する。ま、名前はそのまま変わらずJScriptなんだけどね。ただ、その仕様をもとにブラウザ間でのスクリプト動作の互換性が向上することとなる。

このころ大変だったのはそれを使うユーザ側。なんせJava、JavaScript、JScriptなんてあるもんだから、そりゃまあ混乱するのは目に見えていた。
本屋に行けば Java と JavaScript の本がごっちゃになってるし、採用担当の面接官もJavaScriptができるっていうのを勝手にJavaできるって勘違いするし、ただでさえバグの多い実装がバグの多いブラウザに乗っかってるせいで、セキュリティ関連の問題がぶわっと噴出するしね。だからJavaScriptを動作しないように設定していた人も多いんじゃなかろうか。このような黎明期の混乱のおかげで不幸なことに「トンデモ言語」的なイメージがJavaScriptに定着してしまうことになるんだ。

この後、1999年にIE5でActiveXとしてまず実装され、その後Mozilla系ブラウザやサファリでも実装されたXMLHttpRequestの登場がJavaScriptの転機を担う。ま、このへんからは説明もいらないと思うんだけど、そのXMLHttpRequestを利用した技術が2005年にAjaxと名づけられ、Google Mapでその技術が採用されるや否や爆発的な人気を獲得する。その後も続々とこの技術を利用するライブラリやフレームワークが開発され、現在ではWebアプリケーションを作成する上で欠かすことのできない言語となっているってわけだ。


で、話をECMAScriptのところまで戻すよ。
いわゆるJavaScriptベースと言われる言語の結構な割合が ECMA-262 3rd Edition をもとにしている。ActionScriptもその一つだ。

仕様書は下のリンクからダウンロード可能だ。
http://www.ecma-international.org/publications/standards/Ecma-262-arch.htm

この仕様書を見れば分かる通り、仕様ではいわゆる文法的なものが規定されており、さらにはクラスベースじゃなくってプロトタイプベースのオブジェクト指向言語なんだよーってこと程度しか書かれていない。この規定範囲の小ささが後になってCommonJS設立の動機の一因となるんだけどひとまず置いておこう。
それとここで ActionScriptってクラスベースじゃんよーって思った人もいるかもしれないがASでクラス使えるようになったのは2.0からだ。ちなみにその辺のActionScriptのオブジェクト指向サポートの変遷については以下の資料が詳しい。
http://www.adobe.com/livedocs/flex/3_jp/html/help.html?content=04_OO_Programming_12.html


さあ今日ようやくここでnode.jsに関連する話になるんだけど、じゃあnode.jsで採用されているV8ってどうなのか？V8のサイトを覗いてみれば分かる通り ECMA-262 3rd Edition に基づいているよって記述がある。でもその上にGoogleのオープンソースJavaScriptエンジンって記述もある。

これを分かりやすく言いかえると
JavaScriptはECMAScriptの方言である。
とするならばJavaScriptの実装（ここで言うとV8）はECMAScriptに準拠する。
ってことだね。


で、CommonJSの話。

node.js 以前にもさまざまな Server Side JavaScript の実装があったのはご存じの通り。RhinoやSpiderMonkeyのようになかなかポータブルなものからAptana Jaxerのように巨大なヤツ（というか全部入りのフレームワークだもんな）、V8でもv8-cgiっていう、V8をウェブアプリ書くのに使えるようにって試みもあった。そんな中、とあるエンジニアが乱立するServer Side JavaScriptの独自進化を憂い、サーバーサイドのJSには何が共通して必要とされるのかを考え、2009年1月末に自分の意見をブログで公開して議論の場となるメーリングリストを設けた。

これがCommonJSの始まりである。

以下がそのブログ
http://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-needs/
ちなみに著者であるKevin DangoorはPython製ウェブアプリケーションフレームワークのTurbogearsやPaver、JS界隈でいうとDojoやBespinなんかを開発してきたエンジニアで現在はJSの本丸(?)、Mozillaで働いているという経歴の持ち主だ。

で、CommonJSが解決しようとした問題領域は

  • モジュール機構がない。
  • 標準ライブラリがない。
  • ウェブサーバーやデータベースとの標準的なインターフェースがない。
  • パッケージのマネジメントシステムがない。

といったことなど。要するにブラウザ以外でJavaScriptを利用する際に問題となる領域の解決を目指しているんだよね。

で、CommonJSで策定済み、もしくは策定中の仕様の一覧は以下のページにまとめられている。
http://www.commonjs.org/specs/

このうち、node.js が準拠しているのは現在のところ Module 1.0とUnit Testing 1.0のみだ。
http://wiki.commonjs.org/wiki/Modules/1.0
http://wiki.commonjs.org/wiki/Unit_Testing/1.0

仕様を見てみれば分かる通り、その内容はごくわずか。
だからnode.jsはCommonJSに準拠して云々というくだりで何やら難しそうだなんて思う必要なんか全然ないからね。

内容の割に長くなってしまったけどnode.jsとCommonJSについての話はこれくらい。
次回はいよいよ実装の話に移っていくつもりである。

node.js とは何か (2)

昨日に引き続き、いざ！part2なのだ。

前回では node.js と v8 の結びつきまでを書いたので、今日は Non-Blocking I/O の話を。


Non-Blocking I/O という言葉からブロックしない I/O をイメージするのはたやすい。でもこれを実現しようとなるといろいろとまあ面倒くさいんだよね。

それを解決する常套手段で言うとファイルディスクリプタ（ネットワークならソケットだね）を開いてそれをselectシステムコールの監視対象に加えておき、selectを呼び出すことで監視するっていう方法がある。こうすると何が嬉しいのかファイルディスクリプタが２つある場合で考えてみよう。

まずAとBというファイルディスクリプタを監視対象とする。
selectシステムコールを呼び出し、そのどちらかが読み出し準備完了となっていないかを確認する。
もしどっちも準備できていなかったらプロセスをスリープさせる。もしくは他にできることがあるのならその処理を行う。
で、どちらかが読み出し準備完了となったら読み出し処理を開始する。

A、もしくはBのどちらが先でも大丈夫ってところがまず嬉しい。
待っている間に他のことができるってところも嬉しいよね。

で、こうすることでユーザからすれば「ブロックしていないんじゃね？」ってことになるんだ。ま、他にも方法はあるんだけど。

ここで問題点が浮上する。
selectシステムコールってファイルディスクリプタの数が増えるほど性能が劣化しちゃうんだ。
そうなるとスケーラビリティを目指す上で問題があるってことになっちゃうね。
だからlinuxではepollっていうもっと高速なものが開発された。ところがFreeBSDやOSXにはkqueue、Solarisには/dev/pollという同じような仕組みを持つものが別々に用意されてしまったんだ。あーもうめんどくさい。普通に考えればソースの中でマクロ使いながらそれぞれ分岐させて別個の処理をするしかない。それを独自にちゃんとやってるソフトウェアももちろんあるけどね。nginxもそうだし、mikioさん作の Kyoto Tycoon もそうだ。

で、このめんどくさいっていう問題を解決するため、またもっと易しいインターフェースを提供するために作られたのがlibeventだ。
libeventはコンパイルするプラットフォーム上で最適なシステムコールを選択し、プログラムには同一のインターフェースを提供してくれる。
おなじみのmemcachedでも使われているね。

さあここで話は node.js にようやく戻るよ。
libevent を使っても良かったんだろうけど、開発当時、libev という libevent と同じような機能を提供する、しかももっと高速なライブラリがあった。libevent のバージョン2系は1系に比べてかなり高速化しているんだけど当時はアルファ版がリリースされるかされないかといった時期。「高速に動作する」という理念から libev を選択するのは自然の成り行きだったんだろうね。さらにうまいことに libev 側の利点として同じ作者が開発した libeio という非同期I/Oライブラリまでが存在していた。

だから node.js ではI/Oのイベントループ制御と非同期I/Oに libev と libeio を採用することなったんだ。

ところでこの libeio ではスレッドプールが使われている。先ほどのAとBの例で言うとAの読み出し処理中にBが準備完了になった場合、Bも並行して読み出したほうが効率がいいからね。だから前回シングルスレッド云々と言っていた訳だけどこの部分においてはマルチスレッドを効率化のために限定的に利用している。でもプログラムを組むときにユーザーがスレッドを意識することはない使われ方だよ、ご心配なく。


さあ、こうして v8(JavaScript) + libev(I/O用イベント制御ライブラリ) + libeio(スレッドプールを用いた非同期I/Oライブラリ) という node.js のベースが整うこととなり、さらなる問題解決へと動き出すこととなる。


今回の説明はココまで。


なるべく易しく説明するように心がけた積もりなんだけど、やっぱり前回に比べると難しいね。まだまだ自分ももっと深く理解する余地があるんだろうと思う。ホントに隅から隅までわかっていれば易しく説明できるはずだから。
リファレンスをまとめておくね。

selectのマニュアル
selectのチュートリアル
libevのサイト
libevのベンチ。libeventの1系との比較がある。
libeventの名誉を守るため2系とlibevを比較したベンチ。その１、その２
libeioのドキュメント
PerlのEVモジュール。libevのperlラッパ
IO::AIOというperlモジュール。libeioが使われている。
Rev、rubyのlibevラッパ
pythonにだってラッパがある。
実はpythonってすごいことに標準ライブラリでepollやkqueueを使うことができる。


あとselectまわりやNon-Blocking I/Oについてはいい書籍があるんだ。
その書籍とは「UNIXネットワークプログラミング Vol.1 ネットワークAPI: ソケットとXTI」で恐らく本棚に置いてる人も多いんじゃないかな。故 W.リチャード・スティーブンス御大によるものだ。自分の知る限り、ファーストネームをイニシャルだけにしてミドルネームとラストネームを読ませる人ってこのくらいしか知らない。ま、それはいいとして、その6章が「I/O の多重化: select関数とpoll関数」、15章が「非ブロッキングI/O」となっていてまさに今回取り上げている話題そのものとなっている。

node.js とは何か

期せずして久々の更新になってしまった。ブログを書く気がなくなったとかそういうのではなくてただ単に忙しかっただけ。その間、まぁ仕事が予期せぬ方向から炎上してみたり、事故をもらって愛車が全損したり（フロントガラスが全面熱線入りなんていう変なオプションなどを諸々付けていたからお気に入りだったのに）と決して良いことばかりで忙しかったわけではないけどね！

で、今回は node.js のお話。異様な盛り上がりを見せているものの、じゃぁそれっていったい何かというと「JavaScriptを用いたNon-blocking I/O環境」という非常にシンプルなものだ。

その根底には「うまくスケールできること」と「動作が速いこと」という理念が見受けられる。

まず「うまくスケールできること（多量のアクセスを捌けること）」を解決するにあたり、まずはスレッドモデルか、イベントループかという問題があった。そこで author たる ryan は一つの決断をする。

「イベントループ」

node.js が生まれたのは 2009 年に入ってから。ちょうどそのころ C10k 問題がクローズアップされていてね、いろいろなベンチが公開されていたわけなんだけどウェブサーバの apache vs nginx といった構図のベンチもその中の一つにあったんだ。

この apache vs nginx のベンチが何を意味するのかと言えば先ほどのスレッド対イベントループ。apache はご存じのとおりスレッド、対して nginx はイベントループ。で、その性能の差は使用メモリ量などに端的に表れていたんだ。スレッドモデルの場合ね、実行スタックをコピーする必要があるからスレッドが増えるほどメモリ使用率が上昇する。対してイベントループモデルは１プロセスのままだからメモリはそれほど食わない。この点ではイベントループが有利っていうコンテクストだ。

ただね、イベントループモデルにも弱点がある。それはコードのどこかでブロックする処理が発生するとプロセス全体がストップしちゃう、つまりイベントループ自体の処理もストップしてしまい、パフォーマンスに大きく影響してしまうってことなんだ。

ryan はこの、イベントループにおけるブロックをなくそうと考えた。それが node.js のそもそもの始まりってわけ。

このブロックしてしまう処理というのはI/Oに端的に表れていて、たとえばCPUのL1キャッシュだと3サイクル、L2で14、RAMだと250で済むんだけど、それがDISKになると41,000,000サイクルかかって、ネットワークならさらに240,000,000サイクルもかかってしまうんだ。これがどのくらいすごいのかというと、サイクルをメートル換算してみるとわかりやすい。RAMでも250メートルでまだ目の届く範囲なんだけど、DISKになった瞬間、地球一周分、ネットワークだとさらに地球6周分！！！このコストの比はやっぱりトンデモナイんだよね。

で、ちょっと話はズレるんだけど、イベントループを利用したモデルっていうのは今までも他の言語で既に実装されていて、例えばPythonでいうとTwisted、RubyではEventMachine、PerlではColoのAnyEventなんかもある。ただそれらの実装ではNon-BlockingのI/Oを強制したりはしていないがために、スレッドで書かれた同様の処理をするプログラムよりも遅い場合があるんだよね。

だから Non-Blocking I/O の使用を強制してしまうことでさらなる高速化を図ろう、それが node.js なんだ。

この node.js の js に決まったというのはもともと JavaScript がシングルスレッドモデルでイベントループという仕組みを持っていたからで、だからもし JavaScript がスレッドモデルを採用していたとしたら node.js ではなくて node.el になっていたとしても不思議じゃなかった。
このJSの採用というのは大きな副次的効果を生み出すことになる。ウェブアプリに関わっていた人たちって大抵は多かれ少なかれJSを使っていたからね、新規の学習コストが非常に低い。つまりウェブアプリ開発者なら誰でも使えるような言語だってこと。
さらに具合のいいことにすでに Google V8 という、JavaのHotSpotにも携わっていた Lars Bak が生み出した高性能のJavaScriptバインディングがすでにあった。非常に嬉しいことにV8はC++環境に組み込みやすいという利点さえある。「動作が速いこと」という理念の一つにはこの V8 の影響力ももちろん欠かせない。

こうした結果として V8+Non-Blocking I/O が node.js として産声をあげることとなる。



唐突だけど、続きはまた明日なのだ。
車乗らないとついつい飲みに行っちゃうんだよね。飲んだら乗るな、乗らないなら飲め、みたいな。だから飲んでしまい眠くって先が書けないのである。

続き書きました。

OSS開発の国際化について

本当はいろいろ書きたいことがあるのだけれど、書けるレベルにまで自分をなかなか引き上げられない。といってこのまま書かないのも何なので、今日はOSSを巡る国際情勢についてちょっぴりだけ書く。

今のOSS界隈の動きは実は自分が経験した中でも凄まじいことになっているのだ。
中でもすげーと思っているのはコミッタ、コントリビュータの国際化だ。もうね、名前からしてこれどう読むんだろうって人が増えている。10年くらい前までは欧米の人たち中心だったOSS界、今や完全にボーダーレス化しているんだよね。
露出が高まっているなと感じるのは中南米、ロシア・東欧、インドなんかの人。

もうさ、これだけ多くのOSSプロジェクトが乱立しているとそれに寄与できる人材の増加って追いついて行かないんじゃないかって危惧した（なんて上から目線な！）時もあったんだけど、どうやらそんな心配なんてこういった開発者の多国籍化によって杞憂に終わったようだ。ま、そんな中で日本はどうなのよっていう憂慮は残る。国際化だグローバルマーケットだって言う話はもうみんな耳にタコができるくらい聞いている訳だけど、それは何も日本の中だけじゃなくって世界中の国々で叫ばれている話なんだ。景気のいい話を聞けるのなんてほんのわずかな国だけであって、それ以外の大部分の国では日本と同様に景気が悪くって、だから身軽なITを使って何とかしようってそっこらじゅうでみんな必死に考えているってわけ。で、その一端がOSSという世界にも表れているんだろうなって思ってる。

悲しいことにその、一番競争に晒されている業界の中でいささかあぐらをかいているように見えてしまうのが日本なんだよね。
Ruby 以外ではあまりコミッタやパッチ投げたりしている日本人見かけないもん。
もちろんいることはいるってことはわかってる、ただ絶対数があまりにも少ないんじゃないかってこと。日本独自でユーザコミュニティ作って裾野を広げていくっていうことは確かに重要なこと。でもフィードバックが少ないっていうのはあまりにも切ない。

これは全く持って私見なんだけど、会社がもし抱えている開発部隊の技術力を上げたい場合に手っ取り早いのはOSSの開発に少しでも加わってもらうってことだ。もちろん「ウチの会社の商材オープンソース化します」って誰もソース読みたがらないようなものの開発じゃなくて既にきっちり開発コミュニティが形成されているようなところのね。例えば Ruby とか。

OSSの開発から得られるもののスゴさを理解している経営層なんてホント悲しいことにほとんどいないんだろうけど、実はめちゃめちゃ莫大なんだ。わずかな時間で気付いたものだけでも

  • ソースの読解能力
  • 影響範囲の特定能力
  • テストを常識と捉えられる能力
  • スゴいと思える先輩
  • コンセンサスを得るための説得能力
  • ビューティフルコード！

などなど。４番目の先輩ってなんだそれって感じだけど、ある技術者が会社の中でしか開発していなくてその人がスゴいと思えるような人材が社内にいない場合、会社からいなくなってしまう可能性が高まるから重要だよね。

こうして OSS 開発に従事してもらうことでそのコミュニティにとっても会社にとっても Win-Win という関係が出来上がる。経営層には将来を見据えて是非一考願いたいものだ。

日本のIT系ニュースサイトの憂鬱

日本のIT系ニュースサイトをほぼ見なくなってもう半年になる。
検索エンジンで検索したときに引っかかったのを参照するくらいしかしなくなった。

で、見ないって決めたのは日本のIT系ニュースサイトって要するに

  • アメリカ発の記事の翻訳
  • 日本企業のプレスリリース情報

くらいしかないんじゃないか？とある時ふと疑問に思ったからだ。

それならアメリカ発のものについてはソース記事そのまま読んだほうが早いし、日本企業のプレスリリースなんて自分には必要のないものがほとんどだ（大抵は興味をひかないエンプラ系ばっかり）。だからRSSリーダの類から日本のIT系ニュースサイトのものを全て取っ払い、見えないようにした。

最初は何気に不安だったんだけど、今ではその存在すらほとんど忘れている程度なのでやっぱり必要なかったんだろう。その代わりといってはなんだけど、こっちのメディアが注目しないようなアメリカのスタートアップの動きを今までより注視するようにしている。あとインドも（英語で読める記事があるからね）。

と、まるで日本のIT系ニュースサイトをディスってるみたいに映るかもしれないがそうではなくってしょうがないことなんだ。なぜなら日本のIT業界は動きの速いアメリカに比べれば流れのない沼のようなもの。だからこっちのメディアはたとえ面白くないものであってもプレスリリースに群がるしかない。翻訳記事を書いて紙面（画面？）を埋めるしかない。
それでも日本のIT系ニュースサイトに他国のメディアにはない素晴らしい特徴がある。それは技術系の連載記事だ。あのレベルのまとまった記事を英語で探そうっていったって実はそうそう簡単には見当たらないのだ。

なのでググった時にそういう、ニュース系サイトの連載記事が引っかかった時には嬉々としてクリックしている。

なんで海外メディアには技術系の連載記事が少ないのか。それはメディア側にとっては連載記事ってうまみがないからではないだろうか。ああいいう連載記事って各々が

  • 特定層向け（プログラマ、アーキテクト、インフラ屋、経営層など）
  • 連載後半になるに従ってインプレッションが減っていく（ディアゴスティーニ効果？）

という辛さがまずあって、さらに連載記事の読者層はロイヤリティが高い。んっとここでいうロイヤリティってブランドロイヤリティみたいな意味で、要するにそのページを見る人は広告には目もくれずその「記事の内容」を見に来るので、結果的にそこに貼られている広告は全くもってポチられないってこと。でもこの、読者にポチってもらうというのはメディア側としての重要な収入源。

このへんが日本のIT系ニュースサイトが抱えるジレンマではないだろうか。
収益源は広告だからバンバン読者に広告をクリックしてほしい。でも広告だけだと飽きられるから読者の読みたくなる記事を載せたい。載せて購読者が増えたはいいけど広告をクリックしてくれない。みたいな。

そういったサイトはまだまだ影響力があるのだから VC とタッグを組んでスタートアップに投資し、そこでメディアの強みを活かしてPRを行い、結果としてその中から強力な会社が次々と生まれるようになったりすると面白くなるだろうにな、とふと思う。

微積がようやくわかってきた。

何を隠そう、数学はこのブログ随一の非モテコンテンツ。
もうこの数学って単語見た瞬間にブラウザの戻るボタン押されたりタブ閉じたりされているんじゃないかって思ってる。

まー、でもここはそういうブログなのだ。

半年くらい前に始めた微積、実はもう３周目くらいに突入している。
１周目はホント辛くってさ、何もかもがほぼ忘却の彼方だったので予備知識はほとんどない状態だったんだ。もうね、高校生の頃に習ったような公式類を忘れているもんだからその歩みは匍匐前進レベル。ブックオフで高校生向けの参考書を買ってきて、あーそうだっけなぁと思いつつ復習してようやく元の微積の本に戻るということを繰り返していた。だから１周目は全体を俯瞰するだけと思っていたのに想定外に時間がかかりまくった。で、２周目にようやく突入して今度は練習問題を解くということを中心に。今の３周目は証明と応用に重心を置いて読んでいる感じ。
で、今その３周目と並行してやっているのが線形代数と微分方程式、そして数値計算。微積で鍛えられたおかげで徐々に数学の本を読むのが前ほど辛くなくなってきているのを実感している。むしろ楽しい。これをやり終えて初めて自分の知りたかった分野のスタートラインに立てそう。
その分野とはマシンラーニングの分野。
Excelにはソルバーっていう機能があってそれを使うと魔法のように最適化問題を解けたりしてそれはそれでものすごいんだけど、そこから一歩踏み込んで機械学習がなんなのか、自然言語処理ってどんなんだろうってある時知りたくなったんだ。ただ、コテコテの文系だった自分にとってその壁はあまりにも高く大きく、絶対あんなのわからないって思ってた。でもイメージだけ把握して「あー機械学習ね、リコメンデーションで使われているヤツね」なんて知った口をきくような人間にはなりたくない。
だからどこまでレベルを下げてもいいから一から学んで行こうって思った。
手始めにやったのは機械学習の基礎知識には何が必要なのかというところの調査。結果、グラフ理論、確率・統計、数値解析、数理計画法が基礎になっているようだったのでそこからちょっと入門してみたんだけど、そのレベルでは数理計画法なんかが全くちんぷんかんぷんで歯が立たなかった。なのでさらにそれらの基礎となる微分積分、線形数学、離散数学まで降りて行ってようやくスタート可能になった。ようやく分からないことがなんなのか分かるレベルにまでこれたんだよね。
この機械学習を学ぶっていうのは自分にとって一大プロジェクト。なんせ到達点までおそらく１年以上かかるから。プログラミング言語なら１ヶ月もあればそれなりに扱えるようになるけれどこの数学ってヤツはそうはいかない。ただ、せっかく好きになったことだから着実にその歩みを進めて行くつもりだ。RAWR!!!!!

最後に今まで微積を学ぶ上で参考にした本を紹介してみる。
1.「微かに分かる微分積分」

微かに分かる微分積分

微かに分かる微分積分

もう右も左もわからなかった自分にとっての救世主的存在。この本を読めば誰でも微分の計算をできるようになるはず。
2.「やさしく学べる微分積分」
やさしく学べる微分積分

やさしく学べる微分積分

重要な点がコンパクトにまとまっており、重積分までをカバーしている。ちなみに挿絵に使われているのは著者の娘さんが書いたアリさんだ。
3.「理系なら知っておきたい数学の基本ノート[微分積分編]」
一冊でわかる 理系なら知っておきたい数学の基本ノート [微分積分編]

一冊でわかる 理系なら知っておきたい数学の基本ノート [微分積分編]

タイトルから受ける「ま、買って積んでおいてもいいか」という印象とは裏腹にすごくいい本。わかりやすさとカバー範囲がハンパない。この本を買ってわからないところを他の本で補強していくという進め方で間違いないんじゃないかって思うくらい。
4.「微分・積分30講」
微分・積分30講 (数学30講シリーズ)

微分・積分30講 (数学30講シリーズ)

とりあえず文章が多かったので買ってみた本（笑）でもね、内容は十分高度で理解するのに結構時間がかかった。
5.「やさしい微積分」
やさしい微積分 (ちくま学芸文庫)

やさしい微積分 (ちくま学芸文庫)

どうすればこれを「やさしい」と呼べてしまうのか理解に苦しむくらい難しいのだ。文庫本サイズなのでカフェで読んだりしているけど未だに読破できていない。
6.「概念を大切にする微積分」
概念を大切にする微積分―1変数

概念を大切にする微積分―1変数

練習問題と応用例の量がものすごい。微積を修了した人にもチラ見程度でいいので手にとって欲しい。アメリカの学生はこういう応用たっぷりなテキストを使うことで数学をツールとして使えるようになっていくというのがわかるから！

IT系企業のWebサイトに多く見られるサイト作りにおける失敗例

IT系企業のWebサイトに魅力を全然感じないのはなぜか？本来であればこの分野に長けていて不思議はないハズなのに、もうあたり一面死屍累々といった感じなのである。そういったサイトにありがちなパターンは本文に抽象的なキーワードが散りばめられ、何を言っているのかわからないこと。中でも程度を表すものについては注意する必要があったりする。

最
ベスト
高
長
低
安
全
強
圧倒的
先進的
卓越した
短
大
小
迅速
上
豊
明

ここにリストアップされている文字、あるいは単語が入っていると途端に文章がボヤけてしまい、読み手はたちまちにして白昼夢へトリップだ。トイレに席を立つだけでもそんなサイトを見たことを忘れてしまうだろう。例えば、ということでよくありがちな文章をひとつ部分的にピックアップしてみよう。

「〜技術力で高品質、かつ最適なソリューションを提案します。」

もうね、これだけでもかなり傲慢な文章だ。作り手のためだけのこんな文章がトップページに混じっているのを見ただけでホントうんざりする。

誰も好き好んで低い品質のものを買いたいって思わないよね。
最適なソリューション？？え？最適ってどうやって分かるの？
それとも・・・これって見積もり金額が高い言い訳？

ではそんな高品質で最適なソリューションを提供してくれる企業サイトの採用ページを見てみよう。

「未経験者可、あなたのやる気を応援します」

・・・バカにしてんの？


と、惨憺たる状況なのだ。



なんでこんなことになっているのか？

それは一つにはウェブサイトという存在をとことん軽視しているからだ。
もうひとつにはPRということに対して全く無知で、まさかそれが自分の会社で必要になっているだなんて想像もしていないから。
もちろん、BtoBであればウェブサイト経由で仕事が入ってきたことなんか一度もないし、その必要もないのでウェブサイトなんかどうでもいいんだよね。そういったサイトの中には社長のブログや Twitter がリンクされていて、そこまではいいんだけど肝心の内容がどうしようもないものだったり（行った見た食っただけという内容の薄さに加えて愚痴が挟まれているのとか）、あげくの果てには新入社員にサイト作りを全部任せているようなものさえあるなどとヒドさ満点、このように効果的なPRを行えるはずの場所が全くもって残念なことになっているのがIT系企業サイトには結構多い。

そんな残念なサイトをどうにかする方法はないのだろうか？もちろんウェブ担当者（これまたいるかいないかといえばそもそもいない方が多いのだろうけど）がいてサイト運営に問題意識を持つ、というのが大前提なんだけど・・・。

ヒントの一つは美容を扱うサイトにあると思っている。
美は人によって基準は様々でものすごく抽象的だ。だからもし化粧品会社のようなサイトで「私たちの優れた技術で作り上げた高品質の基礎化粧品により、あなたの肌に最適なソリューションをお届けします。」という文章がただ書いてあるだけだったとしたら売上は伸びるどころか減少してもおかしくない。

ということで彼らの手法を理解すべくいくつかピックアップ（するまでもないことだと思うけど）

資生堂
http://www.shiseido.co.jp/

ノエビアや
http://www.noevir.co.jp/

ファンケルなんかも
http://www.fancl.co.jp/

ちょっと見てもらえればわかるとおり、ビジュアルの持つ力は絶大だ。美容業界のサイトにおいて言葉を裏付けるものとはやはりビジュアルなんだよね。

ではIT企業のサイトにおいて言葉を裏付けるべきものとは何だろうか？
それはやはり実績だと思う。確かにいくつか導入実績が載っているようなサイトもあるけれどただ箇条書きで企業名が載せられているだけとか・・・。導入している会社数が数百以上なら数字だけでもいいんだろうけど、少ないなら少ないなりに定期的に追加される Testimonial の形でカバーしようよ。現在の顧客の喜びを未来の顧客へ伝える努力をしていかないと伸びないってば。

次にIT企業が行うPRの好例を挙げてみる。登場するのは37signals。
また37signalsかよと思うかもしれないがそうなのである。なぜならあの会社は実は Tech Company という側面のほかに、優れたPR手法を持つ会社としての印象が強いからだ。

彼らのベースにあるPR戦略はまず「他の会社と違っていることを前面に出しまくる」ということに尽きる。
彼らが出している書籍ではどんなことが述べられているだろうか？
他の会社がやっているようなことは述べられていないし、むしろエポックメイキングな話題ばかりだよね。週４日勤務だとか。
彼らの製品はどうか？技術的に敵わない？いやそんなことはないハズだ、ちょっとした時間があれば同じようなものは作れるよね。むしろ競合製品より圧倒的に低機能でさえあるのだけれど彼らはかなりの数を売り上げている。低機能であるという、他社ならウリにしないところを逆にウリにしてね。
さらには Ruby on Rails。自分が一番すごいなと思うのは実は開発者である DHH のイケメンっぷりだ。こればっかりは何をもってしても敵わない。Jason Friedの顔は知らなくてもDHHの顔を覚えている人って多いんじゃなかろうか。技術的にすぐれた点を押し出す他社に対してなんと37signalsはイケメンで対抗なのだ！
他に特筆すべきこととしては彼らのやっていることからPRの臭いがほぼしないってこと。これもかなり難しいことなんだよね。


ん・・・と、なんだかネタに近い雰囲気になりつつあるので、日本でPRのうまいトコを挙げてみる。

自分的にスゲーと思っているのはnanapiを運営しているロケットスタート。
nanapiはもうちょっとでリリースしてから一年というところだ。でも、たったこの一年で急成長しているサイトだ。ここではそのすごい点を書かないけど、見れば見るほどうまくできているなーとただただ尊敬するばかり。今月リリースしたnanapiワークスでさらに今後その知名度はあがり、利用者数も増えていくだろう。

すげーすげーと感心するばかりじゃなく、自分も何か考えないとね。


最後に、資生堂のCMで一番お気に入りのを。


※すみません、ロケットスタートさんをロケットスタジオと誤記していました。お知らせありがとうございます！