Seasar3がやってくる - ひがやすを技術ブログ
Seasar2は、機能を枯れさせることに徹し、機能追加は行わないと宣言してから、二年以上たちます。 で、Seasar2が冒険しないことによって、適切な大きさの問題は生まれなくなり、開発者が離れ、Seasar関連プロダクトが生まれなくなり、Seasarユーザも離れていく。使われないSeasarからさらに開発者が離れていく。 こういうスパイラルが発生するかもしれないことについては、どう考えますか？ このような声もありました。「機能を枯れさせることに徹する」というのは、かなりの冒険でしたが、今のところ、うまく行っていると思っています。 「RubyやSeasar2、OpenPNEが“定番”に、Linux Foundationが活用動向調査」という記事も出てましたね。 http://itpro.nikkeibp.co.jp/article/NEWS/20100527/348514/ しかし、二年の間
アクティブレコードパターンの本当の意味 - ひがやすを技術ブログ
アクティブレコード 1行に対応 ドメインロジックを実装している 最近はDBよりの所にドメインロジックを書くのは廃れている RailsのActiveRecord、S2JDBCとか データマッパー ドメイン設計したクラス群とERモデルのマッピング Hibernate、DjangoのORマッパー オブジェクト指向により忠実 PofEAAをみると、アクティブレコードは、「テーブルの行をオブジェクトでラップしたもの」で、データマッパーは、「データベースとオブジェクトを独立して設計しそれらを結びつけるもの」と書いているので、アクティブレコードパターンは勘違いされやすいかも。 アクティブレコードの定義を原文から持ってくると次のようになります。 An object that wraps a row in a database table or view, encapsulates the database
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
僕がRubyをやめたわけ - ひがやすを blog
私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。 liftを開発した人へのインタビューなんだけど、ちょっとひ
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
2007-10-25 - ひがやすを blog
っていうか、Hibernateにも昔からcriteriaあるよね？ http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#querycriteria List cats = sess.createCriteria(Cat.class) .add( Restrictions.like("name", "Fritz%") ) .add( Restrictions.between("weight", minWeight, maxWeight) ) .list(); 流れるようなインターフェースとメソッドチェーンは違うものだよヨシオリ。ぱっとみは似ているかもしれないけど。 流れるようなインターフェースでは、ソースコードを書いている人が、中断することなく流れるようにコーディングできなければいけない。 HibernateのCrit
ひがやすを blog - 2007-09-24 - 「なぜお前らは「好きだからコードを書く」はできるのに「好きだからメンテナンスする」ができないのか?
本当の問題は「スーツ + 頭のカタイおやじ VS. 無垢な技術者」という話だろうか。なんで、スーツの人や、頭のカタイおやじや、無垢な技術者がいるのか、その前提条件を問わなくちゃいけないんじゃないのか。その前提条件に、自分がどんな一手を打てるのかを考えて、世界を変えていこうよ。ていうか、世界を変えていたじゃない。 なんか、高井さんが勘違いしているみたいだから、書いておくけど、俺は、「だから世の中が悪い」とかいうつもりはありません。この構図は、過去何度も繰り返されている事実だから、まず私たち技術者は、その事実をきちんと認識しなければならない。 昨日は書かなかったけど、実は、「弱い技術者」というのは、「頭の固いおやじ予備軍」でもだったりする。 実際良く見かけるんだけど「最新の技術についていくのは疲れた」「なにかスーパーなデファクトが現れてそれで統一されて欲しい」「考えるのめんどくさいから標準で統
2007-08-29 - ひがやすを blog
バブルになってはじけて、そこで生き残ったものからがスタートなんだ、という見方をする人間にとっては燃えろ燃えろ！弾けろ弾けろ！というカンジです 煽るほうは、そういう風に思うのかもしれませんが、なんかすっげー納得できないのは、おいらだけ? だってバブルがはじけて生き残るのはほんの一握りですよ。自分たちが原因で、失敗するならあきらめもつきますが、バブルを起こして運がよければもうけられるみたいに思っている人に散々利用されて失敗するのは、納得がいかないですね。過剰に評価されれば、それだけ失敗する案件も増えてくる。 煽られてそのプロダクトを採用して、火を噴いたプロジェクトも悲惨ですよ。 どんなプロダクトも言語も正当に評価されることが重要で、無駄に煽る必要はない。バブルを起こそうとしている人のやりたい放題にさせないように、常に冷静に考え、警告を発しなければならない。そう思います。 良い悪いは置いておくと
ひがやすを blog - [Seasar]Service を使う際の方針
6/29 19:00から21:00 wakhokの12FでSeasar2のmini eventを行います。協賛は、日本Javaユーザグループです。 場所はこちら。 http://www.wakhok.ac.jp/tyo-sat/map.html 場所を貸していただくwakhokのみなさまありがとうございます。 うわさのtugboat.GTDが登場します。 http://tugboat-gtd.sandbox.seasar.org/index.html ぜひ、screenshotやデモをお試しください。 イベントの内容はこちら。 Seasar2の実装事例 - tugboat.GTDの紹介 tugboat.GTDの紹介/デモ version 0.8 Preview: tugboat.GTD + RESTful WEB Services. Super Agile Web Development
ひがやすを blog - [DI]DIって本当に必要?
http://www.commonsmedia.jp/cm/JavaAndSolarisCampaign blogでNetBeansやJavaEEについて書いて、トラックバックしたら先着100名にAmazonギフト券3000円分をプレゼントするそうです。id:nowokayさんのためのような企画です。 id:taediumさんもid:da-yoshiさんもぜひどうぞ。ただし、Seasar固有のことはできれば避けてねということです。 DIって本当に必要?たまにそう思うときがあります。DIによって開発は本当に楽になったのか。 DIのメリットでよく語られることとして、インターフェースと実装を分離し、機能の利用者側はインターフェースを通じて機能を利用することで、実装に直接依存しなくなり、後で実装を変更しても影響を受けなくなるということがあります。 実際後から、実装クラスを変更するということはめった
2007-02-07
デブサミ-VisualBasic, Delphiから10分でJava+Flex2にポーティング http://d.hatena.ne.jp/higayasuo/20070118#1169099987 携帯用のコンテンツを開発するときに､ドコモ、AU、ソフトバンク用にテンプレートは異なるけど､サーバサイドのロジックはいっしょということもあるでしょう。そんなニーズに応えるのが､1ページ複数テンプレート機能です。 例えば､HogePage.javaがあった場合に､hoge_i.html, hoge_a.html, hoge_s.htmlの3つのテンプレートを用意しておきます。HogePage.javaに次のようなdoメソッドがあった場合､次にどのページに遷移するのでしょうか。 public Class doAction() { return Hoge2Page.class; }hoge_i.ht
レイヤとモデル
アプリケーションをレイヤ分割した場合、 プレゼンテーション層 -> ビジネスロジック層 -> データアクセス層 のように分けるのが一般的ではないかと思います。 ここで、矢印は、依存関係を表しています。例えば、プレゼンテーション層は、ビジネスロジック層に依存していて、ビジネスロジック層は、データアクセス層に依存しています。 矢印の向いていないほうには依存していません。例えば、ビジネスロジック層は、プレゼンテーション層に依存していません。 誤解が多いんじゃないかと思うのは、レイヤとモデルを混同することです。一番多く見られるのは、ビジネスロジック層とドメインモデルの混同です。 モデルは、各層を流れていくデータ(+ ロジック)であり、どの層にも依存しません。逆に層はモデルに依存することになります。 モデルは、プレゼンテーションモデルとドメインモデルに分かれます。本当は、ERモデルもあるのですが、こ
ひがやすを blog - [Seasar]なぜSuper Agileなのか
デブサミ-VisualBasic, Delphiから10分でJava+Flex2にポーティング http://d.hatena.ne.jp/higayasuo/20070118#1169099987 この前のJavaナイトセミナーでSeasar2がなぜSuper Agileなのかをしゃべりました。その資料が公開されています。 http://www.iajapan.org/bukai/java/event/2007/0124/JNS_02.pdf 資料だけだと十分に伝わらないと思いますが､興味のある方はご覧ください。強い型付けの言語が好きなんだけど､最近のJavaってLLにめちゃめちゃ遅れをとっているよねー、Javaってだめなのかなーって思っている人向けです(笑)。 何人かの方に感想を書いていただきました。ありがとうございます。m(_ _)m http://d.hatena.ne.jp/to
2007-01-29
デブサミ-VisualBasic, Delphiから10分でJava+Flex2にポーティング http://d.hatena.ne.jp/higayasuo/20070118#1169099987 Flex2では、モデルとUIコンポーネントと間の自動バインディングがサポートされています。自動バインディングとは､モデルの値が更新されたら自動的にUIコンポーネントの表示が更新されたり､UIコンポーネントに入力している値が変わったら､自動的にモデルの値を更新する機能です。 デフォルトではバインディングは単方向です。基本的には､モデルの変更をUIコンポーネントが検知するだけ。例えば､次のようなMXMLがあったとします。 <?xml version="1.0" encoding="utf-8"?> <![CDATA[ [Bindable] private var hoge:String; ]]>
2007-01-31
デブサミ-VisualBasic, Delphiから10分でJava+Flex2にポーティング http://d.hatena.ne.jp/higayasuo/20070118#1169099987 今やってる案件がチューニングのフェーズに入っていて､Gridのチューニングをやってるんだけど､どれくらいまでチューニングできるかなぁ。 teeda-html-exampleのgridManyXY.htmlの3000件を処理するのに私のノートで60秒かかるので､それを10秒以内にするのが目標。 最初は､データ量を減らすために、HTMLに直書きしているstyleをCSSを使うようにしてみます。CSSをUIComponent(実際はRenderer)から動的に書かなきゃいけないんでそんなに簡単じゃないんだけど､やってみますか。 http://d.hatena.ne.jp/higayasuo/2007
規約ベースのフレームワークのほうが覚えることが増える? - ひがやすを技術ブログ
設定の記述量を減らす→規約ベースになる→覚えないといけないことが増える（ように見える）、という図式ですね。ただ、規約がないF/Wでは設定を記述するための書式を覚えないといけないので実は覚えないといけないことの量は大して違いはないのかもしれませんが、設定はIDEやプラグインなどによって補完可能だけれども規約は補完されにくいため、結局は規約ベースのF/Wの方が覚えないといけないことが多くなるという気はしています。 よく規約を覚えるのが大変と言う意見を見ますが､規約は､規約ベースのフレームワークを使う使わないに関わらず(ほとんどの場合)必要です。一人で開発していれば別ですが､複数の人数で開発している以上､規約を守って開発する必要があると思います。 各プロジェクトごとに、規約を考えて､それをいちいちソースコードや設定ファイルに書くのは､大変なので､あらかじめ妥当だと思われる規約をフレームワーク側で
JPAの問題点 - ひがやすを blog
JPAには非常に期待している人も多いでしょう。私もその一人です。実際にプロジェクトで使ってみて、見えてきた問題点を書いてみます。JPAの実装としては､Hibernate3.2を使っています。 学習コストが高い。 JPAの全機能のうち､プロジェクトで使うものに絞り込んで教育すると、3日程度で教えることができるのですが､そこそこ使えるようになるには､2〜4週間かかります。これは、Hibernate in Actionにも書いているのでそういうものなんでしょう。 トラブルシューティングが難しい。 多くのプロジェクトで実際にハマルのはこれでしょう。うちのプロジェクトでは､Hibernate職人である小林さんがいるにもかかわらずいろいろ苦労しました。Hibernate職人のいないプロジェクトで使うのは厳しいのではないかと思います。 SQLの扱いが貧弱。 JPQLは、SQLのかなり貧弱なサブセットなの
2006-11-11
Seasar2.4.1をリリースしました。 2.4.0からの変更点は次の通りです。 S2Dao1.0.x系と組み合わせられるようにDatabaseMetaDataUtil#getColumnMap()を修正しました。 ダウンロードはこちらからどうぞ． http://s2container.seasar.org/ja/ Maven2からのご利用はこちらを参照ください． http://www.seasar.org/wiki/index.php?Maven2RepoRemote Seasar2.4の開発は､去年の今ぐらいからやっているので､ほぼ1年間開発に費やしたことになります。これは、Seasar2の歴史(3年弱の短い歴史ですが)の中で、最も開発に時間がかかったバージョンです。 2.4は当初、EJB3,JPA,JSFを使うためのAll in Oneプラットフォームの土台として開発を開始しました
ひがやすを blog - [Seasar]ページ駆動開発とテーブル駆動開発
Seasar2.3の時代は､Goyaと言われる開発手法がありました。Goyaのアーキテクチャは､JavaEEの基本にのっとったレイヤモデルアーキテクチャです。詳しくはこの辺。 http://d.hatena.ne.jp/higayasuo/20050817#1124260949 http://d.hatena.ne.jp/higayasuo/20050818#1124338844 役割分担がきちんとされているきれいなアーキテクチャだと思うのですが、CRUD(Create Read Update Delete)しかないような単純な画面でもそこそこクラスが必要で重い感じがするのも事実です。 過去のDIではインターフェース中心の設計が強く推奨されていたため､レイヤモデルアーキテクチャは重く感じられても非常にDIにフィットしていました。 しかし、Javaでさらに生産性を高めるためには､レイヤモデル
![ひがやすを blog - [Seasar]ページ駆動開発とテーブル駆動開発](https://cdn-ak-scissors.b.st-hatena.com/image/square/fc296ca94e94eeb09dd04bb7e8dab6adbb5ecbd5/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126970898857%2F17680117126970931595%2F1550550017)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
