はずみって怖い

artonさんと宇野るいもさんの本を買おうと本屋に行ったら、つい、買い込みすぎました。大散財大会。

Javascriptの本をやたら買い込んでるのは、Webのクライアントサイドに対する理解が相変わらずさっぱりさんだから。まあ、大体どういうことができるのか概念は理解してるつもりだけど頭の中で手法まで落ちてません。ここは深入りするとすぐに「IEではこうですが、Firefoxではこうです」といういきなり実装というか、BKな世界になっちゃうんですがそこには行きたくない気がしてます。そういうのはなんか例えばPrototyle.jsが吸ってくれてその後だけ触りたいというか(笑)。仕事でそこまでつっこむ気はないし。

逆に言えば、ひとつJavaEEのプロジェクトに(インフラだけど)じゃぼんと入ったこととRailsをちょっと勉強したことで、サーバサイド側でできることは見えた感じがあります。見えたというのは、DB設計と画面数がCRUDごとにあれば何がどのぐらいの労力でやれるのかというのが感覚として持てたということです。もちろん、細かいことで行き詰まることはいろいろあるんでしょうし難しい機能、簡単な機能いろいろだと思いますが、そういうのは設計が悪いか、そもそも業務がおかしいのかですよね、大抵は(笑)。

それはやっぱりRailsの影響が大きくて、「要は、Railsが機械的にやっていることを現実と摺り合わせてどうやるのよってことなんだよね？」ってことですよね。それぐらいRailsの設計は素晴らしいし、Railsがやってることを見れば「Webアプリの本質」が見えるってことだと思います。

で、業務がすごく単純で、DB設計が素晴らしい場合にはRailsでscaffold作ったところまでで本質が終わりで、後はバリデーションとか認証とかデータの関連とか些末で、かつ大変なところをちまちまやりましょう・・・というところで残るのは画面です。ここでどれだけのことが出来るのかが、イマイチ実感としてわかってないんですよね。今、私の興味はそこです。

もう一つ言えば、上の前提には「DB設計が素晴らしい」という条件もあるわけで、DBもやってみたいです。これまでの仕事で、DBサーバを作ったり、動かなくなったのをひっぱたいたり、耐障害設計や回復設計をやったり、メモリ周りのチューニングをやったりというのは一通りできるようになっています。でも、私、インデックス張ったことありません(笑)。DB設計と、あと、SQLは今後の課題です。SQLはどこまでつっこんでいくべきか悩みどころです。