株式会社ビジネスバンク主催のrubyイベントに参加した。
rubyの生みの親、まつもとゆきひろさんの講演が聞けたので、忘れないようにここにメモする。
技術の未来を考えるとき、2つの可能性がある。
1つは過去から現在へ続いてきた技術の流れがそのまま続いていくこと。
もう1つは、革新的な変化が起こり、新しい技術が使われるようになること。
後者の例は、量子コンピュータや、汎用人工知能が考えられるが、予測ができず、たまにしか起きない。
そこで前者の、現在の流れが続いた場合を考えてみる。
Webアプリでクライアントサイドの比重が高まる。
Webアプリを作る際に、クライアントサイドに多くの仕事をさせる流れがある。
- シングルページアプリケーション
- Web API
クライアントのJavaScriptでほとんどの仕事をさせ、サーバサイドはWeb APIでJSONを返すだけにする。
これはサーバサイドでページの整形までやり、クライアントではブラウザがレンダリングするだけという設計とは異なるアプローチである。
マイクロサービス的であるとも言える。
Isomorphic（アイソモルフィック）
これもWebの話。サーバサイドとクライアントサイドで同じ言語を使う。
一番分かりやすいのが、クライアントでJavaScriptを使い、サーバサイドもNodeを使って書くこと。
Rubyでもやろうとすればできる。Opalというruby処理系があって、Rubyでクライアントサイドを書き、JavaScriptに変換して使える。
rubyの速度の問題
rubyは確かに遅いが、事業アプリのボトルネックはネットワークかDBがほとんどであり、プログラミング言語が問題になることはまずない。DBならクエリの書き方が悪いとかである。
※自分の感想
確かに、事業システムの性能問題は、トランザクションデータが大きくなることによって発生することが多い。自分の現在保守している顧客管理システムもそうだ。
事業システムのデータ量増大の問題は、マーチン・ファウラーが『アーキテクチャ・パターン』の前書きで書いていて、読んだ事がある。
しかし、自分が巨大なシステムでrubyを使う事を不安視してしまう理由は、性能ではない。rubyは静的型チェックが効かない。コンパイル時のチェックがないのが不安だ。
今思うと、質疑応答の時間が長く取ってあったから、質問してみても良かった。
マルチコア、クラウドベース
これはそのまんまの話。
rubyの得意分野
プロトタイプを作ったり、試行錯誤するフェーズが一番得意。
何を作るか分かっていて、ウォーターフォールで作っていくような場面ではなく、作ってみて動作を確認し、またちょっといじってみるといった場面が一番向いている。
昔はrubyで最初作ってみて、本格的に作るとなったら別の言語でというやり方が多かったが、今は性能の進歩で、プロダクションもそのままrubyで作って問題ない事が多くなっている。
その他
mrubyを作った時には、もっと組み込みシステムで使えるメモリが増えると見込んでいたが、そんなに増えなかった。それで、rubyを載せてもらえる状態にならなかった。
感想
視野が広い人だな、と思った。
自分は日頃Webアプリを作っていて、本当にそこしか知らない。
組み込みとか、CPUとか何も知らないでやっている。
しかし、そういうマシン側にも目を配っていて、話としてはあまり出なかったけど、ちゃんと知っている感じだった。
コンピュータが人に仕えるべきで、人がなるべく楽をできるように考えてrubyを作っているそうで、元々プログラミング言語というのがそういうものだから、その通りにやっているという事なのだが、本人の口から聞くと、ちょっと感動する。
お腹が途中で空いてしまって、軽食のピザをかなり僕が食べてしまった。
テーブルで相席になった方、ごめんなさい。
