はてなブックマーク

ExtJSはGPLなので困ったところに、ExtJS 2.0 からフォークしたOpenExtってのがあると。じゃあこれかなあ。 と思ったらfirefox3とchromeでDatePickerがデカくなって壊れます。パッチを当てればよいらしい。 ext-all-debug.jsの17999行目に1行追加。 el.className = "x-date-picker"; el.style.width = '10px'; //これを追加 el.innerHTML = m.join(""); ext-all.jsで、「x-date-picker」検索して、そこに同じく幅指定追加。 B.className="x-date-picker";B.style.width='10px';B.innerHTML=C.join(""); これで治った。良かった良かった。

曰く、「データ構造をこれこれこうすれば共通化できるでしょ。そうすると、この画面とこの画面とこの画面と・・・は同じデータを見る事になるんだから、分ける意味が判らない、意味がないでしょ。だから画面をひとつにしろって話でblur blur blur」 いやー、それ分けた方がいいと思います。 「えー？じゃあ、この画面とこの画面とこの画面・・・・と、何が違う？」 アクターが違う、ユースケースが違う、サブシステムからして違う、他色々考えるとあれもこれも違ってくると思う。というか、唯一違わないのがデータ構造、ただそれだけ。 そりゃ「出来る限りは」正規化というか共通化した方がいいと思うけど、データが正規化出来るという事実「だけ」を根拠にUIの正規化を正当化するのはおかしい。 稼働し始めると、ユーザーさんからどうせ「フォーカス順はこうした方が」「入力欄の並び順が」「この場合これが必須なので」とか、アクターや

Office2007に対応した（らしい）、POIの3.5-FINALが出ましたよ。これで1,048,576件まで表示できるぞ〜。 が。 毎度ですが、結構変わってます。 Region関連パッケージが変更 セルの範囲を管理する（マージとか）Region周りのパッケージが変更になりました。この変更は地味にでかい・・・。 (旧)org.apache.poi.hssf.util (新)org.apache.poi.ss.util 一応古いクラスも非推奨で残ってはいるんですが、取得するメソッドがないのでどうする事も出来ない。もうちょっと移行パスを考慮して戴きたかった所ではある。 本当はFisshplateも早く3.5対応したかったのですが、これのおかげでずっと保留でした。0.2.0からこっちにします。なので、0.1.xとは互換性がなくなっちゃいます・・・。 HSSFCell#getRitchStrin

5月31日付けで、スターロジックを去る事になりました。 理由は、スタロジの経営判断によるものです。如何なる判断なのかは、id:makotanの云う通り、経営者からのアナウンスを待つのが宜しいかと思います。 思い返せば一昨年のSeasar Con飲み会での大暴れで色んな方にご迷惑お掛けしたりして、そんなんでこの結果かと云われると忸怩たる思いですが、己の力不足を思い知った次第です。 寂しい限りですが、皆有難う＆どつかれさまでした！＞元メンバー。 スタロジ自体はこれからも継続して発展していくはずですので、変わらぬご愛顧のほどを宜しくお願い致します。 同時に、現在求職中の技術者がここに数人おりますので、ご興味御座いましたらご連絡下さい。

RIAとかゆって、結局ほとんどがC/S時代のVBとかDelphiとかで作ってたUIを再現したいって話かと思うんですよ。 もちろん中にはぐっとエンタテインメントなかっちょえーUIな要望もあるかと思いますが、RIAな開発環境を使う側のニーズの絶対数の話だと、まあそうかと思うですよ。 で、がんばったわけですよ。 が、お客様がやろうとしたオペレーション例。 とにかく検索ボタン押す 検索結果が一覧表示 欲しいデータをCtrl+Fで探そうとするも、できない 検索できないんですけどという問い合わせ 今ブラウザを使って仕事しようって人はみんな普段の生活でブラウザ使ってあれこれいじってるわけで、そうすると、欲しいデータに辿り着くための方法というのは「Ctrl+F」なんですよ。 HTMLでいいんですよ。いや、HTML「が」いいんですよ。覚える事少ないから。 しかも求められてるのって、S2の従業員サンプルとかの

もっと考えてみると、Entityに列挙をプロパティとして持つ事で受けるメリットとデメリットのバランスが悪すぎる。 Entityクラスを自動生成する方法がいくつかあるのに、それが素直に使えない。EntityクラスってくらいなのでDB上の型と合わせた方が筋ではないかいのう、などなど。 で、条件分岐などで区分を見るとかだったら、 if(HogeFlag.NOT_HOGE.getValue.equals(fuga)){ //ああだこうだ }とかやればいい訳だし、大した事ではない。 列挙のメリットは、メソッド呼び出し時の引数の型チェックが大きいと思う。だからEntityのプロパティまで律儀に列挙にするメリットはあまりないよなあ。 やっぱWebアプリの場合、需要なさそうだなあ・・・。

よく考えてみたらば、S2Daoで上手い事文字列の区分から列挙に変換してEntityクラスにマッピングしてくれるとベストではないかと。 Dtoは基本的にプレゼンテーション層依存と考えてるので、そこから独立した業務ロジックたるLogicクラスではEntityを見て色々とやるのが筋かと思うわけです。 その時の条件分岐なんかに列挙が使えれば、これは固い。 で、HTMLベースのWebアプリだとUIでは文字列で持つしかないので、Dxoでは逆に列挙から文字列へ変換して、プレゼンテーション層へ渡す。 さて出来るかな・・・。 もっと贅沢云うと、Dxoでは変換しないで、プレゼンテーション層のフレームワークで列挙→文字列変換。うーんこれは要らんかな。 なんで俺はこんなに列挙が好きなんだ？