タグ

frameworkと設計に関するhiro360のブックマーク (25)

  • TopHatenar+HatenarMapsのシステム構成 - kaisehのブログ

    TopHatenarとHatenarMapsのシステム構成が、バージョンアップの度に複雑化してきて、自分でも把握しづらくなってきたので、整理する意味で図を作ってみました。 図に示したように、HatenarMapsは、S2RMIを使ってTopHatenarと協調動作しています。はてなダイアリーとはてなブックマークに関するデータをクロールしているのは、TopHatenarの側です。HatenarMapsの側では、TopHatenarのService層をS2RMI経由でコールして、集計済みのはてブ情報を取得し、クラスタリング処理の後にポリゴンを計算しています。その他、HatenarMaps上でコメントビームの表示等がリクエストされる度に、TopHatenarをコールしています。よって、HatenarMaps側のDBには、基的にポリゴンデータしか入っていません。 以下、図中に出てくるフレームワー

    TopHatenar+HatenarMapsのシステム構成 - kaisehのブログ
  • 2008-07-02

    新戦略の中でオラクルが「戦略的製品」として挙げた20製品のうち、 旧BEA製品がそのままの形で残ったのは5製品。 Webアプリケーションサーバー「BEA WebLogic Server」の関連3製品と、 Java仮想マシン「BEA JRockit」、トランザクション処理モニターの「BEA Tuxedo」だ。 新名称はそれぞれ、「Oracle WebLogic Server」「Oracle WebLogic Suite」 「Oracle WebLogic Application Grid」「Oracle JRockit」「Oracle Tuxedo」である。 http://itpro.nikkeibp.co.jp/article/NEWS/20080702/309935/ ということは旧OASは無くなるってことなのかな。 OAS残留はわからないけど、WebLogicが残るのは確定みたいなので

    2008-07-02
  • Strutsは古代、JSFは近代、現代はRails - ひがやすを技術ブログ

    最近流行の古代、近代、現代パターンで、Webアプリケーションのアーキテクチャを振り返ってみたいと思います。 古代に生まれたStrutsですが、実は結構完成度が高く、WebにおけるMVCパターンは、Strutsでほぼ完成しています。ViewはJSP(Velocityもあり)とタグライブラリで決まり、ControllerもActionで決まり(StrutsそのものもControllerに分類する場合もあり)でしたが、モデルの実装方法は、決定的なものがありませんでした。 実は、モデルには、アプリケーションモデルとドメインモデルがありますが、この辺の考えも明確なものがありません。アプリケーションモデルという言葉は、あまり聞いたことがない方もいるかもしれませんが、SmalltalkのMVCは、既にそうなっているようです。 モデルをデータのみから成るドメインモデルと,アプリケーション固有の情報から成る

    Strutsは古代、JSFは近代、現代はRails - ひがやすを技術ブログ
  • 2008-06-30 - おおたに6号機blog - 続フレームワークのジレンマ

    反響どうもありがとうございます。 まとめてになっちゃうのですが、面白い議論なのでいくつかレスして引っ張ります^^; あと、ユーザーの性質による部分もあると思います。 最適なものを作りたいなら1から作るべきですし、それだと時間が足りない場合は スクラッチで作ったりしますし。スクラッチ(スクラッチ部分のテストが発生)するのがめんどくさいかつ、 最適でなくて問題ないシステムであるならばフルスペック(スクラッチがないため連携テストの必要がない)のフレームワーク もって来たりしますし。 http://d.hatena.ne.jp/shot6/20080627#c1214581000 なるほど。 私のコンテキストの問題もあるのですが、私が言っているフレームワークとはたぶんに Webフレームワーク、特にプレゼンテーション部分に特化していることが多いと思ってもらってよいです。 (自分の性質上そうなってそう

    2008-06-30 - おおたに6号機blog - 続フレームワークのジレンマ
  • フレームワークのジレンマ - おおたに6号機blog

    フレームワークを作っている人にはいつもあるひとつのジレンマがあるんじゃないでしょうか。 それは機能追加によるフレームワークの肥大化です。 ユーザさんから言われた機能・自分達のチームでこれは良い!と思って入れた機能など 理由はそれぞれですが、フレームワークが形になってからの機能追加は進む一方です。 機能が増えればそれだけ故障箇所が増えるのと一緒です。また想定しない使い方をユーザさんが してくる場合もあるでしょう。 自分もこのような機能追加は正しい・求められているんだとずっと思っていました。 今でも間違ったことだと思ってるわけではありません。 ただし、それには大きな前提があることにちょっとだけ気づいたのです。 それは、 最初に開発されたフレームワークの機能は十分に検討され、 厳選されたミニマルセットな機能以外はあってはならない。 という前提です。書いてみれば当たり前で拍子抜けされるかもしれませ

    フレームワークのジレンマ - おおたに6号機blog
  • 日米トップJ2EEアーキテクトが語るフレームワークの未来---Gavin King氏にひがやすを氏が聞く

    O/Rマッピング・ツールHibernate,JBossのフレームワークSeamの作者Gavin King氏。King氏はEJBなどJavaのコンポーネントを統合するWeb Beansを提唱し,Javaの標準化プロセスである「The Java Community Process」で標準化が行われている。金融業のシステムや商用フレームワークに採用されているDI(Dependency Injection)コンテナSeasar2の作者ひがやすを氏。ひが氏はSeasar2で,アジャイルな開発を実現するためのツール作成に取り組んでいる。日米のトップJ2EE(Java2 Enterprise Edition)フレームワーク・アーキテクトがWebアプリケーション・フレームワークの未来について語った。

    日米トップJ2EEアーキテクトが語るフレームワークの未来---Gavin King氏にひがやすを氏が聞く
  • Webアプリ連携フレームワーク - yojikのlog

    http://flowr.31tools.com/ このフレームワークは非常に興味深いです。 flowr が対象とするのは、パーマネントリンクを持つ Web アプリケーションです。一般的なブログや Wiki、Amazon のような製品情報ページの URL が一定のルールで固定化できる EC サイトなどが当てはまります flowr の最も基的な特徴は、URI の指す各リソースに対しステートマシンでその振る舞いを定義し、また個々の URI に対してメタデータを付加・制御することができるというものです。 Web アプリケーション に flowr を使って機能を追加するために必要なことは、各リソースの URL を取得する方法を用意するだけです。例えばブログの場合はブログパーツを貼り付けることで flowr との連携を行います。 最近、既存のアプリをあまり変更せずにワークフローの機能を組み込む(ワ

    Webアプリ連携フレームワーク - yojikのlog
  • 新・たけぞう瀕死の日記

    ■ [Click]ClickとUrl Rewrite Filter ClickとUrl Rewrite Filterを組み合わせて任意のURLを使う方法を試してみました。以下は/pages/ページ名というパスを/ページ名.htmにマッピングする場合の例です。<outbound-rule>を定義しておくことでページに出力されるリンクやフォームのパスを書き換えることもできます。<urlrewrite> <rule> <from>/pages/(.*)</from> <to type="forward">../$1.htm</to> </rule> <outbound-rule> <from>/(.*?)/(.*)\.htm</from> <to>%{context-path}/pages/$2</to> </outbound-rule> </urlrewrite> いろいろとハマったのですが最

  • Url Rewrite Filter その7 実は結構重くない? - monjudoh’s diary

    web.xmlの設定からUrl Rewrite Filter自体を外した時との比較で、 outbound-ruleとruleが両方記述されている場合は2,3割CPU使用率が上がってる感じ。 outbound-ruleのみの場合は両方記述されている場合とほぼ同じ、 ruleのみの場合はほとんどCPU使用率が上がらないので、 outbound-ruleを使うと重くなるということみたい。 その5で書いたけど、outbound-rule動作時には、 UrlRewriteWrappedResponseのインスタンスが生成されているはずだから、 その分重くなってるのかもしれない。

    Url Rewrite Filter その7 実は結構重くない? - monjudoh’s diary
  • Url Rewrite Filter その6 なんかキモイ現象 - monjudoh’s diary

    <rule> <condition type="parameter" name="hoge" operator="equal">HOGE</condition> <from>.*/hogehoge\?.*</from> <run class="Fugafuga" method="doSomeMethod" /> <!-- doSomeMethodにてパラメタfugaを変換して、attribute・rewrited_fugaに格納 今回は"fugafuga"が入るとする。 --> <set name="rewrited_hoge">HO</set> </rule> <rule> <condition type="attribute" name="rewrited_hoge" operator="equal">HO</condition> <from>.*</from> <to type="r

    Url Rewrite Filter その6 なんかキモイ現象 - monjudoh’s diary
  • Url Rewrite Filter その5 outbound-rule要素について - monjudoh’s diary

    外向けのURLを書き換える際のルールを記述する要素で、 HttpServletResponseのencodeURLメソッドが実行されるタイミングで、 ルールが適用されるくらいにしか把握していませんでしたが、 具体的には↓こんな感じみたいです。 下準備 UrlRewriteFilterがフィルタチェーンでたらい回されてきたHttpServletResponse等をUrlRewriteWrappedResponse*1でラップする。 ラップしたUrlRewriteWrappedResponseの方をフィルタチェーンにたらい回す ほんちゃん UrlRewriteWrappedResponseのencodeURLメソッドが呼ばれる encodefirst="false"(デフォルト)のoutbound-rule要素で定義したルールがすべて適用される UrlRewriteWrappedRespons

    Url Rewrite Filter その5 outbound-rule要素について - monjudoh’s diary
  • Url Rewrite Filter その4 run要素を使うときはjarをshared/libに置いちゃダメ - monjudoh’s diary

    Url Rewrite Filterにはrun要素というのがあって、 <rule> <from>^/world/[a-z]+/[a-z]+$</from> <run class="com.blah.web.WorldServlet" method="doGet" /> <to>/world-presentation.jsp</to> </rule> こんな感じで記述してやると、指定したクラスの指定したメソッド*1を実行できますが、 これを使う場合はUrl Rewrite Filterのjarをshared/libに置いてはダメで、 WEB-INF/lib配下に置いてwarに含めてやらないといけないよーだ。 WEB-INF/classes配下に置かれたクラスはアプリのクラスローダからじゃないとロードできないけど、 この辺に書いてあるように、アプリのクラスローダはSharedのクラスローダの子

    Url Rewrite Filter その4 run要素を使うときはjarをshared/libに置いちゃダメ - monjudoh’s diary
  • Url Rewrite Filter その3 - monjudoh’s diary

    cookieオフ時のjsessionid削除でけた。 <outbound-rule encodefirst="true"> <from>(.*);jsessionid=[0-9A-Fa-f]{32}(.*)</from> <to>$1$2</to> </outbound-rule>encodefirst="true"が重要で、ルール適用前にencodeURL()を実行するという意味らしいんだけど。 詳しいところは後で調べて書きます。 後、セッションIDの文字数が32文字決め打ちなので、動作はAPサーバに依存します。 というかTomcat用です。 Tomcatの設定でjsessionidを出さないように出来たような気がするけど、これも調べて後で書くことにします。

    Url Rewrite Filter その3 - monjudoh’s diary
  • Url Rewrite Filter その2 - monjudoh’s diary

    うぇ、outbound-ruleでの表示用URL書き換えが、JSTLのc:urlでうまく使えないっす。 どうやら、outbound-ruleの動作ってのは、response.encodeURLを実行した際に 以下のようになるようにするというものらしいです。 to要素で設定した変換後URL= response.encodeURL(from要素に合致するURL);んで、JSTLの方のソース(org.apache.taglibs.standard.tag.common.core.UrlSupport#doEndTag)を見てみますた。 // if the URL is relative, rewrite it if (!ImportSupport.isAbsoluteUrl(result)) { HttpServletResponse response = ((HttpServletRespon

    Url Rewrite Filter その2 - monjudoh’s diary
  • Url Rewrite Filter - monjudoh’s diary

    UrlRewriteFilter - Rewrite URL's in Java Web Application Servers apacheのmod_rewriteみたいなことができるServletFilter。 ちょっと前にマイコミジャーナルで存在を知り、ちょうど新旧アプリの入れ替えというURLをちょこちょこ差し替えるような用事が出来たので、 仕事で使ってみようかと思い弄ってみました。 記事を読んだ限りではものすごく有用そうでしたが、実際に触った感じではちょっと物足りないかも。 いえ、記事では http://www.example.com/diary/diary.cgi?year=2007&month=05&day=12 というURLよりも http://www.example.com/diary/2007/05/12 というURLのほうがユーザにとってもわかりやすいし このような/区

    Url Rewrite Filter - monjudoh’s diary
  • 【ハウツー】Java WebアプリでもわかりやすいURLを! - Url Rewrite Filterの使い心地 (1) わかりやすいURLの重要性 | エンタープライズ | マイコミジャーナル

    WebアプリケーションではURLのわかりやすさも重要とされている。たとえば http://www.example.com/diary/diary.cgi?year=2007&month=05&day=12 というURLよりも http://www.example.com/diary/2007/05/12 というURLのほうがユーザにとってもわかりやすいし、検索エンジンにもクロールされやすいといわれている。 Apacheでは後者のURLへのリクエストを、サーバ内で前者のURLに書き換えて処理を行うための"mod_rewrite"というモジュールが存在する。mod_rewriteを使えば既存のWebアプリケーションに大きな修正を加えずに、後者のようなアクセシビリティの高いURLを提供することができる。また、サーバ上でWebサイトのフォルダ構成を変更した場合などもmod_rewriteを使用する

  • ひがやすを blog - [etc]フレームワークの進化的開発

    フレームワークは、多くのユーザのニーズに応えられるようにするために、汎用的で、最初から多くの機能が盛り込まれるというのが一般的ではないかと思います。 でも、当にそうかなぁと私は思います。例えば、私がフレームワークを作るとします。多くのユーザのニーズを初めから把握できるでしょうか。たぶん、できないでしょう。ユーザのニーズを想像して機能を盛り込んでも実際に使われるかどうかは分かりません。それなら、ニーズを確実に把握できない機能は盛り込まないほうが良いでしょう。 ただ、このような考えはフレームワークに限っては落とし穴があります。機能の足りないフレームワークは誰にも使われない可能性があり、フィードバックがないかもしれないのです。 結局事前にどこまで機能を盛り込むかというのは、非常に難しい決断になります。そんなときに、私が使う方法は、「ユーザに使ってみたいと思わせるキラーな機能」は、事前に盛り込み

    ひがやすを blog - [etc]フレームワークの進化的開発
  • [ThinkIT] 第3回:アーキテクチャとフレームワークの定義 (1/3)

    アーキテクチャという用語は元々建築の世界で用いられてきた用語であり、「建築術」「建築様式」「構造、構成」といった意味がある。現在では建築の世界に限らず、様々な分野でこの言葉が用いられている。 例えば、「システムアーキテクチャ」という用語はC/S(クライアント/サーバ)アーキテクチャなどの複数のコンピュータからなるシステムの構造を表すときに用いられる。一方,情報デザインの分野では、「複雑なものを明らかにするために、データにおけるパターンを組織化する人」を意味するものとして,「情報アーキテクト」という言葉が用いられている。 また、ビジネス・アーキテクチャという言葉は「ビジネスにおける概念間の一貫した構造」を指すものとして(注1)、あるいは「活動要素間の相互依存性もしくは関係性のあり方」を指すものとして用いられている(注2)。 ソフトウェア工学では「ソフトウェアアーキテクチャ」を「ソフトウェア要

  • [ThinkIT] 第5回:モジュールの作成 (1/2)

    今回はフレームワークの役割と構築について前回までで紹介しきれなかった部分を解説した上で、フレームワーク全体がどう動作しているかを説明します。 「簡単に使い方を覚えられる」という条件を満たすために、データオブジェクトを使って素早く動作するようにカスタマイズしたデータアクセス層を採用しました。他のオプションも検討しましたが、広告会社の開発環境で使うには複雑過ぎるという結論に達しました。 データオブジェクトがどのようなふうに動作するのか詳しく見ていく余裕はありませんが、フレームワークで使用しているデータオブジェクトのスーパークラスをお見せします。 データベースの全テーブルには、フレームワークのデータオブジェクトスーパークラスを継承した各データオブジェクトクラスが対応します。リスト8と9を見てください。指定したデータベースのデータオブジェクトをすべて生成するスクリプトもあります。これで時間を大幅に

  • [ThinkIT] 第4回:フレームワークの役割と構築方法 〜 後編 (1/3)

    リクエストハンドラはリクエストを受け取ると、それが正しいものかチェックして要求されたモジュールに送ります。どのような振る舞いをするかは、ユーザがリクエストを送ったModuleによります。リスト5を見てください。 リスト5 <?php ⁄** * * * @author Darryl Patterson < darryl.patterson@eurorscg.com > * @copyright Euro RSCG 4D * *⁄ include_once('common/util/class-EnvironmentFactory.php'); include_once('common/util/class-ModuleFactory.php'); require_once('common/util/class-Config.php'); class Handler { var $confi