ハウツー本を読むだけじゃ、逆に遠回りになってしまう？
青木氏も「数学や哲学といった基礎学問で得られる力は，良い設計に役立つ」と同意する。「昔，人工知能が流行ったとき，会社で数学や認知科学の本を読んでいても，誰もとがめなかった。そういう本を会社で読むのが許される職場は，今となっては貴重になってしまった。現場で読まれるのはいわゆるハウツー本ばかり。それが悪いとは言わないが，近道しようとして，逆に遠回りになってしまっているのではないか」と指摘する。
ITProにのっていたこの記事、すごいいいことを言っていますよね。
ITpro Expoってイベントで、Smalltalkで有名な青木さんの発言ですが、、
現代人って新書とかハウツー本とか、薄くて軽くてすぐ実践できるノウハウ本には手を出すけど、名著とか厚い専門書は読まないですよね。軽い本を大量に読むのも、厚い専門書を読むのも、金銭的なコストはそんなに変わらないだろうけど。
できれば、こういう数学、論理学、哲学、、、、みたいなことは学生のうちにエッセンスを吸収しておくべきだけど、、誰が教えられるだろう？とか思ってしまう。
こういうことが本当は大事なんだろうけどね。
フロントローディング、ソフトウェア開発の自動化
僕たちは今、どんどんソフトウェア開発の自動化の方向へすすんでいるような気がする。
様々な技術によって、製造するソースコードの量を減らす方向（自動化）へ進んでいるということだ。
everpearceさんのブログにトラバります。
製造工程でのミスを少なくするために設計工程で作りこみをするという、製造業の「フロントローディング」の考え方は、ソフトウェア現場でもリアルタイムで起こっていますね。
現実的なレベルとしては、UMLのモデルなんかを使って、設計の可視化をして設計をちゃんとやろうという機運が高まっていると言う感じでしょうか？
自動化には、まだまだ程遠いですが、良い方向に向かっていることを認識しています。
おそらく設計段階の可視化をしようというのは一通りできた後に、しばらくするとSoftware Factoriesみたいな技術が徐々に徐々に浸透してくるのではないかと思います。
最近、社内のミーティングで↑の技術の紹介がありました。
現状を見ると、すべてを自動化することはできなくても、モデルとか言われる単位で設計を行い、ソースコードは自動生成。後は細部を補うって感じになっていましたね。
さらには、現在は、プログラマが楽するための自動生成技術ですけど、将来的には非プログラマがコーディングレスでソフトウェア開発を行う日が来るんでしょうね。
出版業界も進化してるんですね
JavaとErlangを統合する
Erlang is an agitator to traditional enterprise development because it excels so well at concurrency, uptimes of five nines or more, and "hot deployment" of code. But there are valid reasons for why someone may not want to dive in head first. How many CIOs want to lose their investments in Java? Who wants to leave behind all the great libraries produced by the Java community?
最近、次の言語として注目を集めているErlangですが、、、、この記事の筆者が言うとおり、エンタープライズ向けに現在構築されているJavaの資産を捨てて、みんながErlangに流れるかっていうとそうではないですよね。
たぶん、比較的軽量なシステムを構築していてる人たちは、移行が早くできるかもしれないけど。重厚長大なシステムを作ってる人たちはそうでないような。
こういう場合、考えられるのは
とか？
記事では、(1)のパターンです。Jinterfaceとかいうのを使ってうまく連携させている模様。
Jinterfaceの使い方については檜山正幸さんの日記が詳しいようです。
Erlangのプロセス間ではメッセージ通信が容易に行えますが、JInterfaceライブラリを使うと、ErlangプロセスとJavaプログラムとのあいだでもメッセージ通信ができます。予備知識である分散Erlangから説明し、JInterfaceを紹介します。ちょっと長いので、前後編に分けて、今回の前編ではErlang側の話をします。
