PHP at Yahoo!を読む - Sooey
PHP at Yahoo!を読む イタリアで開催されたPHPDay 2007にてYahoo! EuropeのFederico Feroldi氏が行なった「PHP at Yahoo!」のプレゼン資料が、氏のブログで公開されました。 Yahoo!が社内でどのようにPHPを使用しているのかということはこれまでにもRasmus Lerdorf氏のプレゼンなどで明らかにされてきましたので、「PHPのビルド時にはモジュールはほとんど組み込まない」とか「ビジネスロジックをエクステンションとして実装する」といったことは皆さんご存知だと思います。今回も前半はそんな感じの内容ですが、途中で実装よりの具体的な話題になってきたと思ったら、Yahoo!が利用しているテンプレートエンジン r3がオープンソース化したと書かれていてビックリ。しかもsymfonyのビュー層にも組み込んで使っているとか。 他にもDrupal
【ハウツー】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を使用する
たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～内部設計【AOPの適用】～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト AOPの適用は、自分でも何となくやってしまっているところがあり、設計手法として改めて考えてみると、説明が難しいところがあります。 今回は、自分なりの考えをまとめてみます。 AOPをどこに適用すれば良いのか？ 「AOPとは何か？」って聞かれたら答えやすいのですが、「AOPをどこに適用すれば良いのか？」と聞かれると、答えるのが難しいですね・・・。 自分で設計していても、感覚的に決めてしまっているように思います。 AOPの例として、トランザクションやロギング処理が良く取り上げられるますが、それらはシステム全体としては、どのように位置づけられるのでしょうか？ システムとして、ユーザに適用する機能（core concern）とAOPで実現する機能（crosscutting concern）は、縦横のような関連を持
![たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～内部設計【AOPの適用】～](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
【ハウツー】クラス構造がまる見えに! UDocでJavaをダイナミックに分析する (1) Ja...
UML、なかでもクラス図はクラスの関係を把握するうえで欠かせないダイアグラムだ。できれば既存のAPIはクラス図を見て簡単に全容を把握しておきたい。その際に全自動でクラス図を作成できると大変便利だろう。そこで紹介したいのがUDocだ。こうした用途にぴったりのアプリケーションである。 UDocはJava クラスをUMLライクのダイアグラムによって視覚化するGUIアプリケーションだ。Javadoc、Javaバイナリファイル、Javaソースコードなどから動的に UMLライクのダイアグラムを生成できる。生成されるダイアグラムそのものを動的に編集することも可能なので、グリグリといぢりながらクラス関係を解析できるすぐれものだ。動作にはJDK 5.0かそれ以上のバージョンが必要。本稿執筆時点の最新版は12日(米国時間)に公開された1.005であり、GNU GENERAL PUBLIC LICENSE Ve
Teeda Extension featuring Goya 〜アーキテクチャ【Pegeの継承】〜 - 現場のためのソフトウェア開発プロセス - たかのり日記
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 今回は、Pageクラスの継承についてです。 Pageの継承 現在のTeedaのバージョン（3/18現在 Ver.1.0.6）では、各画面のPageクラスは、基底となる独自のPageクラスを継承するようにしておくと便利です。 多くのWebアプリケーションでは、以下のようにしておくと良いと思います。 AbstractBasePage アプリケーション全体の基底クラス AbstractSubAppPage サブアプリケーションの基底クラス SubAppXxxPage 個々のPageクラス 上記の継承関係にした場合、バリデーションには注意する必要があります。 親クラスのバリデーションは継承されません。小クラスで明示的に指定する必要があります。 #バリデーションの継承を行えるようにするのは、現在Teedaコミッタ
10のアプリケーションロールパターン ― ＠IT
インタラクションデザインパターン（2） アプリケーションロールデザイン、 基礎の10パターン ソシオメディア 上野 学 2007/3/19 前回の「80年代のAppleに学ぶUIの部品化とガイドライン」では、インタラクションデザインの作業にパターンを活用することの有用性について説明しましたが、今回からは、実際にどのようなデザインパターンがあるのかを考えていきたいと思います。 私はこれまでの連載（ユーザビリティのヒント、Webアプリケーションのユーザーインターフェイス）を通して、インタラクションやユーザーインターフェイスのデザインはプログラムが出来上がってしまってから最後に付け加えるというものではなく、システムの基本的な品質を決定する重要な要素として設計の初期段階から考えなければならないものであると主張してきました。なぜなら、そのシステムが提供しようとしている機能を、画面の見た目や操作の流れ
たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～外部設計～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 工程の位置づけ システムがユーザに提供するものを定義します。 システムの振る舞いとして、ユーザレビューを行うもの 内部設計以降の工程でプロジェクトメンバが増えることを前提として、インプットとして決定しておくべきもの という観点で、標準（？）のGoyaでは含まれていませんが、DB設計もこの工程に含めています。 成果物 業務機能一覧 業務ごとに、システムの役割の概要を書く。 画面遷移図 業務フローから、画面遷移図を書き起こす。 UIスケッチ 画面の構成を決定する。入力／表示項目、ボタン／リンクのみを記述し、デザインにはこだわらないように注意する。 業務フローに沿って、ウォークスルーを実施。漏れ／不要／修正箇所を洗い出す。 画面項目説明 項目の仕様として、説明／初期値／バリデーションルールなどを記述します。D
![たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～外部設計～](https://cdn-ak-scissors.b.st-hatena.com/image/square/25e7558323c09b52d06cb979120703dc35339b82/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F6435988827677137249%2F11696248318753705804%2F1369152372)
たかのり日記 - [Seasar2][Teeda]Teeda Extension featuring Goya ～要件定義～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 普段使用されている手法で問題ありませんが、Teeda Extensionの強み／弱みを知らないと、後で苦労することになると思いますので、ここでは、その点について紹介したいと思います。 また、一般の要件定義レベルよりは、後工程でのリスクを軽減するためにも、実装に近いレベルで書きたいと思います。 ※2007/02/11時点 Teeda Extensionの特徴 JSF拡張 JSFの仕様をベースに、JSFの使いづらい点を拡張したフレームワーク。 ページ駆動開発 HTML画面を起点に開発を実施する。画面とそれに関連するデータや処理を、1対1で開発するスタイルを採用しており、画面と画面遷移のアンマッチを解消している。 HTMLテンプレート Viewのテンプレートを標準的なHTMLだけで記述することが可能。これまで
たかのり日記 Teeda Extension featuring Goya ～アーキテクチャ【レイヤー構成】～
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 今回はアーキテクチャについてです。 レイヤー構成について、3パターンほど私が考える案を紹介します。 各コンポーネントの役割については、別途説明したいと思います。 Full Pattern 特徴 大規模アプリケーション向け。 コンポーネントを最も細分化したパターン。画面とロジックを分担して共同開発したり、フロー制御や他システム連携が多かったりするシステムに向く。 Serivceがトランザクション境界となる。 レイヤー構成 プレゼンテーション層 Action、Page、Dto サービス層 Service、Dxo ドメイン層 Logic、Dao、Entity Middle Pattern 特徴 中規模アプリケーション向け。 画面ロジックとドメインロジックを2つのレイヤーに集約させたパターン。大抵のシステムは、
Teeda Extension featuring Goya 〜アーキテクチャ【コンポーネント】〜 - 現場のためのソフトウェア開発プロセス - たかのり日記
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 今回は、各コンポーネントの役割についてです。 Action 役割 プレゼンテーションロジック。画面項目の表示／非表示切替や、ボタンを押下したときの処理などを記述する。 インプット 操作シナリオ 作成単位 画面単位 命名ルール 画面名+Action（例:EmpListAction） Teedaのルール上、ボタンに付けたid（do〜）がメソッド名となります。 初期化メソッドは、initialize/prerenderとなる。前者は、画面が表示される最初の1回だけ呼び出され、後者は、画面表示の度（バリデーションエラー時やポストバック時など）に呼び出されます。 Page 役割 プレゼンテーションモデル。Actionと分離しない場合は、プレゼンテーションロジックも兼ねることになる。画面項目と1対1のプロパティを持
「ソフトウェアの仕様書は料理のレシピに似ている」へのフィードバックをいくつか集めてみた
一年近く前に書いた「ソフトウェアの仕様書は料理のレシピに似ている」というエントリー。今になってもトラックバックやコメントが送られて来るのは、実際に日本のIT業界に働く人たちの間にも「今のやりかたはおかしい」という疑問や不満があるという証拠だろう。 そこで今日は、シオレットの引用機能のテストも兼ねて、よせられたフィードバックを新しい順にいくつか紹介してみる（それも、昨日になってやっとシオレットが動き始めたSafariブラウザーを使っての投稿だ^^）。 まして、優秀でないエンジニアがコードを書かずして、仕様書を作ることが出来ようか？ソフトウェア開発はウォーターフォールでは上手くいきません。 【さくねこの”チラシうら”にっきより引用】 別会社のSEが設計して、それを請け負った会社のPGが実装する。こんなやり方でまともなプログラムが作れたらある意味凄い。物凄いオーバーヘッド作業をこなして作るわけだ
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：梅田サロン中止のお詫び、およびアーキテクチャ変更についての技術詳細レポート
先週末に予定されていたJTPA企画の梅田さん主催オンラインサロンですが、会場に多くの人が集まるにつれてLingrが重くなってしまうという事態に陥ってしまい、まるでイベントの体をなさないまま時間が過ぎてしまい、あえなく中止となってしまいました。 当イベントを楽しみにしていた皆様、そして梅田さんはじめJTPAスタッフの方々には、本当に申し訳なかったと思います。ここに改めてお詫び申し上げます。 Macworld 2007のときには180人を収容して何の問題もなく快適に使えていたので、「1000人はわからないけど、200人ぐらいなら大丈夫だろう」とたかをくくっていたのが間違いでした。 今回はその反省も含めて、内部で検証した技術情報をすべて公開し、どのような問題に直面し、どのように解決にあたっているのかをお伝えすることで、特に技術者の皆さんに役立つフィードバックにしたいと思います。 ■今回のアーキテ
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：Lingr and Comet - 技術解説編
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
ひがやすを 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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html
eBayのアーキテクチャ - 設計と実装の狭間で。
スカイプの技術的な仕組みについて教えてください。…
バックナンバー – おくvillage
Technologies for UI
IBM Developer
