Scala + Wicket にあう ORM を探す - イトウ アスカ blog
面白みがないので JPA はとりあえずおいときます。Doma がお気に入りなので、Doma が念頭にあったりします。それを踏まえて Scala + Wicket にあう ORM を探しています。文中でいう「エンティティ」とはレコードと紐づくクラスのことです。 Squeryl Wicket で利用するなら直列化に関する仕組みがしっかりできていないといけません。Squeryl その点でポロポロ問題がでました。以前もとりあげましたが、まず、エンティティに定義している serialVersionUID がなぜか永続化対象になってしまいます。これはバグでしょう。それから、エンティティのフィールドにカスタム型（ユーザ定義型）が使えるのですが、そのカスタム型が必ず継承しなければならないクラスが Serializable ではないのでカスタム型を使用したエンティティは直列化できなくなってしまいます。 結論
ウォーターフォールはアジャイルよりも難しい - イトウ アスカ blog
きっと同じような記事を書く人がたくさんいるんだろうなぁと思いつつ。 アジャイルはウォーターフォールよりも難しい | 日経 xTECH（クロステック） ↑こちらの記事に触発されて、私がウォーターフォールやりながらアジャイルでやりてぇと思ったときの経験を書いてみる。 難しさ（1）落ちない水。隠れた溯上用水路 ウォーターフォールとは、滝のことです。各プロセスが手戻りすることなく、次々にこなされている様が、また、ガントチャートなどで書き表わした場合の様がその滝のように見えますね。 さて、このプロセスって、ちゃんと予定通りこなすことってできるんでしょうか？ まず無理でしょう。なぜなら、見積り工期の根拠が乏しいからです。ふたを開けてみたら「思ったより時間がかかった」という経験を持っている方は少なくないでしょう。 また、やってみたら「この仕様じゃダメじゃね？」となったこともあるか思います。と言いますか、
Wicket でこんな風にプロジェクトをすすめました - イトウ アスカ blog
ちょっとした成功体験を紹介します。 どんなプロジェクトだったか オフコン系の社内業務支援システムをWebベースに作り変えるプロジェクトでした。まだ全部終わってませんので過去形でいうのは適当ではありませんが。 コンポーネントの登録を省力化した とにかくこの手のシステムは1画面あたりの項目数が多い。なので、コンポーネントの生成と登録をちんたら手組しているとラチがあきません。そこで私がとった方法は、Excelシートに項目名とコンポーネントの種類、Wicket ID、必須か否かや値の範囲などの簡単なバリデーション情報を書いて、それを POI で読み込んでソースを生成することでした。 はじめはコンポーネントの種類はまさしくクラス名で指定していたのですが、何度かバージョンアップを繰り替えして今では和名で指定しています。実際のクラス名とは別区XMLファイルで結びつけています。たとえば「テキストフィールド
バリデータを書くことに違和感を感じた - イトウ アスカ blog
Cubby にしろ、JSF にしろ Struts にしろ、バリデータにはたと違和感を感じました。 オブジェクト指向なんだから、どんな値が OK な値なのかはオブジェクト自身が知っていなきゃいけないんじゃないのかな？ 車オブジェクト自身が、搭乗定員を知らないのはおかしくないですか？ いやいや、搭乗定員 5 名でも、その気になれば 6 人乗れるよ。それを取り締まるのは法律であって、バリデータは法律なんだって話もありますが。 でも、「1 リットルの器」オブジェクトに 2 リットル入るのは明らかにおかしい。外野がなんと言おうと入らないものは入らない。 特に POJO が流行った今、「物」を表した「オブジェクト」は、ほとんどが単なる構造体。 なんか、違和感を感じるんですよねぇ。
内作フレームワークが持つリスクを考慮すべきですよ＞某大手 SIer さん - イトウ アスカ blog
大手（ばかりではないでしょうが）SIer さんがたまにやる、どこにも公開していない内作フレームワーク（今回は、Java の Web アプリケーション用のものを念頭におきます）でプロジェクトをすすめるのはこういうリスクがあるんですけど、考慮してますか？ っていう話です。 わざわざ書くってことは、考慮してない現場をまのあたりにしてるからなわけですが。 名の知れているフレームワークと言うとまずは Struts ですね。名が知れていないものでも、容易に情報が得られるフレームワークはたくさんあります。また、プロの編集者がちゃんと編集・校正して、しっかりと製本されたそれらの参考書も手にはいります。 いっぽう、内作のフレームワークについて、それを使わされる下請けさんなどの立場で見るとどうでしょうか。 プロジェクトが始まるまで、下手すれば名前すら聞いたことがない。 プロジェクトが始まっても、なぜか実行環境
重厚なフレームワークを使うとプログラムを均質化できると思うのは妄想 - イトウ アスカ blog
特に大規模プロジェクトの場合、プログラマのレベルの違いによるプログラムの質の差をなくそうとして重厚なフレームワークが用いられることがあります。 ほんとうにそう思ってるならソースコードレビューのひとつもしてみなさいって、お偉いさん。 そんなんで均質化なんてできやしないですよ、イマドキ。COBOL じゃあるまいし。 Java を例にすれば、文字列を等号で比較しちゃったり、プリミティブ型のラッパー・クラスを new で作っちゃったり（valueOf 使えよって話。というか Autoboxig すら知らないって何？）、せっかく BigDecimal で取り回してんのにプリミティブ型に変換してから計算しちゃったりと、構造的な作りよりも、もっと基本的な部分にレベル差がでることのほうがずっと多いですよ。 ベテランはイカした基底クラスを作ってさくっと画面量産とかできちゃって、ビギナーはなかなかそうはいかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
