Hadoopとの連携を実現したCOBOL→富士通、売り方間違ってる！

ここのプレスリリース


世界初！ Hadoopとの連携を実現したCOBOL「NetCOBOL V10.5」を販売開始
並列分散処理により、バッチ処理時間を従来の約18分の1に短縮
http://pr.fujitsu.com/jp/news/2012/12/5-1.html


あ～なんで、胡散臭いビッグデータに絡めちゃうんだろうなあ・・・
単純に、
「夜間バッチが早くなりますよ！」
「夜間バッチのマシンがリプレースできますよ」
だけで、インパクトあるし、売りやすいだろうに・・・

それによって、夜間バッチの人員削減や、集中化ができれば大きな意義がある。
そっちによる経費削減とかのほうが、
ビッグデータとかいう海のモノとも山のものともつかない物を
売るのより、売りやすいはず・・・

プログラミングの自動化と設計の再利用、どっちが効率的？

設計さえしてくれれば、プログラミングは自動的に行うという
ようなツールがある。
CakePHPのbakeなども、その一種と考えられるか・・・

---

しかし、これらのモノの注意点がある。

「設計さえしてくれれば」

の点。実は、設計工程に時間がかかるのだ。

とくに、プログラミングの自動生成において、bakeのように、

DBからモデルを作り、
そのモデルから、コントローラー、ビュー（画面）を作成していく

ものに関しては、DBと画面が一致していれば簡単に作れるが、
RDBの場合、正規化するので、必ずしもそのような構造にはならない。
（テーブルは正規化して分割され、それを結合してコントローラーができ、
　画面につながる）

---

むしろ、画面設計のときにHTMLで作成して、ボタンをクリックすると
遷移するようにして、画面をHTMLベースで完成させてしまい、
それをプログラミングで再利用できるようにしたほうが良い。

つまり、設計の再利用。

現在のフレームワークは、こちらのほうもできるようになっている
（Cakeだと、bakeを使えば上述の方法になるが、使わないで、
　画面から作っていってもかまわない。Zendもそう）

この場合、モデルの部分は、サーバー側で作っておいて、コントローラー
で画面に出力するか、ajaxとしてREST形式で送るかを判断することになる。

---

設計ができればというのは、設計まで待ってしまう。
そういう意味では設計の再利用のほうが効率的に見えなくもないが、
どうなんだろう・・・

サンダーバードの勝手に絵文字変換！

おお、勝手に絵文字に変換していたのか、Thunderbird!

以下のメールを、

自分の宛先に送り、さんだーばーどでみると、

となる。

:-)を、絵文字に勝手に変換してくれているのね。