Diary?

(21:34)

別に知りたい人もいないだろうけど、昨日アップした動画の編集には Avidemux というソフトウェアを使った。こいつは「単に動画を切り貼りしたりフィルタをかけたりエンコーディングするためにだけ設計された」というだけあって、非常に機能が絞られている分使いやすい。

他のソフトウェアもいくつか見てみたけど、どれも余計な機能が付いていたので今回は見送った。ソフトウェアにおいては「学習コスト」「パフォーマンス」などといった理由でまったくもって大が小を兼ねないからなー。

(23:49)

実に様々な事情により、 Struts ベースの環境を一人で構築して主に画面まわりの内部仕様を詰めて実装という作業をしている。それで実に久しぶりに生 Struts を（仕事では初めて）使っているのだけど、やっぱ Struts は悪評が聞かれるのも頷けるなーと改めて思う。

もっとも今俺がフレームワークを設計するとしたら、とある部分で Struts を模したものになる可能性はゼロではないとも思うんだよな。とりあえず Struts の良いところと聞かれてパッと思いつくのは、基本的にビューのまわりがコアなのでそっから後ろは全部俺ワールドでもいいということだ。これが他のフルスタックになってるフレームワークだと、すべてにおいてそのフレームワークの流儀に合わせにゃならん（同じ Apache の連中のプロジェクトでいうと OFBiz）。

実際のところあんまりフレームワークがでかくなると学習コストがかかる他に、環境の構築などただでさえタルくて泥臭い作業がさらにタルくなりがちという今の時代には致命的な欠点があり、ちと酷い例だと別に画面まで含めなくても良いロジック部分のテストをしたいだけなのにバックエンドだけを起動する方法が存在しなくてアプリケーション全体をフルで立ち上げないといけない、あるいは適当なモックでデータを返せばいいフロントの動作確認でバックを切り離せないなど大変な状態に陥るリスクが付きまとうわけだ。ここがどうにもならないのとどうにか出来るのとでは桁違いだし、どうにか出来易さというのももちろん重要。

なのでカスタマイズをゴリゴリかけて独自フレームワークにすることを前提とすれば、まあそこまで発想は悪くないかなと思ってきた（その設計及び実装についてはまた別の話）。事実仕事で使った独自フレームワークって結構 Struts ベースだったりするしな（巨大な追加部分のせいで Struts が埋もれてはいるが）。