Javaで軽快に使える「軽量フレームワーク」特集一覧CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
Wicketで始めるオブジェクト指向ウェブ開発 記事一覧 | gihyo.jp
第6回Twitterタイムラインで見るWicketのオブジェクト指向プログラミング（後編） 矢野勉（やのつとむ） 2009-12-11
mobylet（モビレット） | 携帯Webアプリケーションを開発するためのJavaオープンソースフレームワーク
「mobylet（モビレット）」は携帯向けWebアプリケーション構築のために特化した、 強力なJavaオープンソースフレームワークです。 「mobylet」を導入することで得られる機能には、次のようなものがあります。 3キャリアの絵文字の表示/入力/変換に対応 3キャリアの絵文字入りメール/添付メール/デコメールの送信に対応 ブラウザサイズに合わせて画像を動的にリサイズ表示 アクセスした端末のUID/GUID/端末プロファイル情報などを取得可能 非常に簡単なGPS/GoogleMapインターフェースを提供 携帯端末のキャリア・機種毎に異なるブラウザ仕様への対応は非常に手間のかかる作業です。 開発者は、PC向けWebアプリケーションのクロスブラウザ対応以上に困ることも多いでしょう。 mobyletは、そんな携帯独自の開発を容易にする機能を提供し、 効率的な携帯向けWebアプリケーションの構築
Sc2009autumn 次世代Daoフレームワーク Doma
- The document discusses Domain-Oriented Mapping (DOM), which is a framework that maps objects to relational databases using domain models. - It describes how Doma can be used to define domain models (entities) and generate SQL from those models to perform data access operations like inserts and selects. - Benefits of using domain models include type safety, avoiding null checks, and reusability o
2009-09-13
T2プロジェクトとして2コマ頂き、登壇させていただきました。 T2のいま・そしてこれから 私のセッションでは、T2の概要と現在考えられるWebアプリが変わるだろうという新技術について話しました。特にHTML5(正確にはそのランタイム)が本格的に使われだすと大分変わるんじゃないかと期待しています。 T2はWebフレームワークの部類では大分変わった存在なのかもしれません。色々なリクエストをまとめて上手に扱えるという点だけに絞ったのがT2なので、そこらへんが他とは大分違うんじゃないかとおもいます。T2はフルスタックフレームワークのようにプレゼンテーション層からDao層までトータルで面倒みてくれるというわけではないです。がしかし、Dao層などは他にもよいフレームワークが色々あるし好みもあるのでそちらは各開発で適切なものを選ぶのがいいとおもいます。また、今後EclipseプラグインViliでフルスタ
リッチなWebアプリケーション構築用Javaフレームワーク「IT Mill Toolkit」:phpspot開発日誌
IT Mill - IT Mill Toolkit リッチなWebアプリケーション構築用Javaフレームワーク「IT Mill Toolkit」 次のような特徴があるそうです。 ・多数のリッチＵＩコンポーネント ・充実したドキュメント ・テスティングのオートメート ・オープンソース ・extend with GWT サンプルアプリケーションもなかなかリッチです Javaという点がPHPerには残念ですが、Javaもお使いの方は試してみるとよいかも。 関連エントリ リッチで使いやすいＵＩを作成するためのjQueryライブラリ＆サンプル集 ブラウザ上で動く12のリッチテキストエディター jQueryでリッチなグリッドを実装「jqGrid」 ソート、ページング機能等リッチなテーブルを実装するのに便利な「Sigma Grid」
TopHatenar＋HatenarMapsのシステム構成 - kaisehのブログ
TopHatenarとHatenarMapsのシステム構成が、バージョンアップの度に複雑化してきて、自分でも把握しづらくなってきたので、整理する意味で図を作ってみました。 図に示したように、HatenarMapsは、S2RMIを使ってTopHatenarと協調動作しています。はてなダイアリーとはてなブックマークに関するデータをクロールしているのは、TopHatenarの側です。HatenarMapsの側では、TopHatenarのService層をS2RMI経由でコールして、集計済みのはてブ情報を取得し、クラスタリング処理の後にポリゴンを計算しています。その他、HatenarMaps上でコメントビームの表示等がリクエストされる度に、TopHatenarをコールしています。よって、HatenarMaps側のDBには、基本的にポリゴンデータしか入っていません。 以下、図中に出てくるフレームワー
Javaクライアントフレームワーク、条件はこれ - あなたは何を選ぶ? | エンタープライズ | マイコミジャーナル
TheServerSide.com: your java Community discussing server side development TheServerSide.comにChester Chen氏がChoosing a web client frameworkという興味深い投稿をおこなっている。会社で新しいプロジェクトを開始することになり、これを機に新しいクライアントサイドのWebアプリケーションフレームワークを探しているという。提示されている条件は次のとおり。 開発環境: LinuxとWindowsが混在、Java、EJB 2/3 デプロイ環境: Linux、新しいプロジェクトはUI目的でGlassfishを使用、既存のプロジェクトはWebLogic Server 10.3を使用 新しいフレームワークの学習曲線が緩やかであること すでに十分成熟したものであること Ajaxサ
Javaフレームワークの比較検討資料公開 - 矢野勉のはてな日記
Java仕事で各種フレームワークを比較検討したので、比較用に作った参考資料を公開します。ちなみに現在私は、ドワンゴさんの社内システム開発をお手伝いしてまして、その一環で調べたものです。会社資料じゃなく、私の資料ということでブログで公開してよい、むしろしとけ、とのことなので公開しときます。 今回の案件向けにアプリケーションを画面層コンテナ層データアクセス層に分けて、それぞれフレームワークを選ぶのが目的です。コンテナ層はDIコンテナのうちいずれか、データアクセス層はO/Rマッパーを選ぶことになります。 太枠の範囲が選定対象です。よく本に出てくる杓子定規な階層図とは変えてあります。 次のものを比較検討しました。画面層SAStrutsApache Wicket（ほかにもTeedaとかClick Frameworkとかももともとは候補にあったが、調査が追いつかないので二つに絞った）コンテナSeasa
ドリコムブログは Java で動いています - onkはギリギリ霊長類
さっきラーメン食いに行ったときに話題にしたら興味深く聞いて貰えたので調子に乗って書いちゃえ。 とりあえず id:rokujyouhitoma はスイーツを食べ過ぎだと思います。一晩にパフェ 3 つも頼むヤツは初めて見た。 さて，まずコレが意外に知られていなくてよくビックリされるんですが，ドリコムブログの基本部分は Java で，Struts，Hibernate で動いてます。DB は PostgreSQL。 で，ブログの HTML 生成部分は以下のような感じ。 1. Web サーバがリクエストを受け取り，URL を組み立て直して AP サーバにリダイレクトフォワード 静的ファイルはそのまま Web サーバが返し，動的ファイルは AP サーバに投げます。このとき，400 行程度の RewriteRule を通して mod_rewrite で URL を組み立て直しています。 サブドメイン化し
DIを意識させたらキャズムは超えられない - ひがやすを技術ブログ
Java でも比較的先進的な考えを持つフレームワークがたくさんあります。そして、先進的なフレームワークは作者でさえ、流行っている、たくさん利用されていると錯覚する場合があります。利用者となるプロジェクトには大抵、新しいことが好きな先進的な人がいて、アーキテクチャを決めてしまいます。そういう人はよくネットなどで情報を発信します。また先進的であれば、記事や書籍でこぞって取り上げられ（もちろん中の人の努力もあります）、流行ってるように見えてしまいます。実際には出来れば新しいことには手をつけたくない人のほうが圧倒的に多いにも関わらず。 どこかの掲示板で、DIは疎結合のためにあるとか、そのためにインターフェースと実装を分離するんだとか、再コンパイルせずに、設定ファイルの変更のみで実装を変更できるんだとか、書いている人を見て、懐かしく思いました。 こんないいもの(たとえばDI)を理解できないのは、理解
2008-07-14
GTDの元祖である、David Allenさんのロングインタビュー。 これはフォトリですまさずにじっくり再度読むべきだと思ったのでメモる。 続きを読む 通常の小規模なアプリでさえだらだらと@RequestParamを書くことはない．つまり使わない． http://d.hatena.ne.jp/shin/20080714/p1 @RequestParamが何故必要なのか、それは非常に簡単です。 フレームワーク外で自動生成による制約をある程度期待しているからです。 つまりT2の上でフレームワーク作る人が強制しやすいようにするためです。 続きを読む ことにした。 続きを読む へー。Javaが1位だけど、緩やかに右肩下がりなのには納得。 しかしJavaも2004年、2005年あたりにガクンと下がっているのはなんなんだろう？もしやEJB？ そこPythonがあがってるのは何か関係あるのかも。 元はこ
2008-07-10
Stripesにかなり似てるんですが、結構良い感じのActionベースのフレームワーク。 AjaxianではアノテーションベースなWebフレームワークという紹介でしたがそうでもないかも。 レスポンスとしてどういうものを返すかをResolutionというクラスで表現しているのですが これはかなりStripesに似てる。T2もその辺はStripesのシンプルっぽさを真似て Navigationを作っているので似たような感じです。 サンプルのコードはこんな感じのようです。 続きを読む Googleの出す新フォーマットらしい。 Javaのチュートリアルはここ。 http://code.google.com/apis/protocolbuffers/docs/javatutorial.html これを見るとSOAっていってるもののほとんどがSOAじゃないってことになるけど・・・・ http://bu
ベストプラクティスとしてのサンプルについて -「ユーザさん/開発者にとって」シリーズその3- - おおたに6号機blog
シリーズ3回目はまたもサンプルです。 ただし今回はサンプルはサンプルでもショウケースとしてのサンプルではありません。 ベストプラクティスとしてのサンプルです。 前回はミクロな視点で各機能のディティールを紹介するショウケースの意義について 書きました。今回はマクロな視点であるベストプラクティスとしてのサンプルの意義について書きます。 ベストプラクティスとは何でしょうか？ それは言葉を変えれば勝ちパターンといえます。 このような方針でこんな全体像であればアプリケーションを構築するのが成功するんだという メッセージを伝えるのがベストプラクティスです。 細かい機能が知りたいのであればショウケースを見るべきです。 製品が提供するサンプルアプリケーションには、このベストプラクティスを伝える 意味合いがあるものがなければいけないと思っています。 言い方を変えれば、成功疑似体験を伝えるべきといえます。 （
2008-07-03
フレームワークのジレンマ 続フレームワークのジレンマ TO DOではなく、NOT TO DOの定義のほうが大事 競合フレームワークと比べたら負けだと思っている つらつらとフレームワークのジレンマシリーズを書いてみましたが、思ってるだけ・考えてるだけでは 何も起こらないので実践して検証してみる。 まずはリリースプラン。どうせなら楽しくやりたいので、わかりやすく覚えやすいコードネームをつけてみた。 確定じゃないけど、晒してみる。 ver : コードネーム 0.2 : Menu : 1.0へ向けての機能の洗い出し。これ以上大きく機能は増やさない。増やす場合は、1.0以降の機能追加として配置。 0.2.3.5 : 機能のブラッシュアップ。Testの追加とJavaDocの追記。 0.2.3.6 : サブプロジェクトの分離。必要のないサブプロジェクトは削除。 0.2.3.7 : いまんところ未定 0.
Strutsは古代、JSFは近代、現代はRails - ひがやすを技術ブログ
最近流行の古代、近代、現代パターンで、Webアプリケーションのアーキテクチャを振り返ってみたいと思います。 古代に生まれたStrutsですが、実は結構完成度が高く、WebにおけるMVCパターンは、Strutsでほぼ完成しています。ViewはJSP(Velocityもあり)とタグライブラリで決まり、ControllerもActionで決まり(StrutsそのものもControllerに分類する場合もあり)でしたが、モデルの実装方法は、決定的なものがありませんでした。 実は、モデルには、アプリケーションモデルとドメインモデルがありますが、この辺の考えも明確なものがありません。アプリケーションモデルという言葉は、あまり聞いたことがない方もいるかもしれませんが、SmalltalkのMVCは、既にそうなっているようです。 モデルをデータのみから成るドメインモデルと，アプリケーション固有の情報から成る
2008-06-30 - おおたに6号機blog - 続フレームワークのジレンマ
反響どうもありがとうございます。 まとめてになっちゃうのですが、面白い議論なのでいくつかレスして引っ張ります＾＾； あと、ユーザーの性質による部分もあると思います。 最適なものを作りたいなら１から作るべきですし、それだと時間が足りない場合は スクラッチで作ったりしますし。スクラッチ（スクラッチ部分のテストが発生）するのがめんどくさいかつ、 最適でなくて問題ないシステムであるならばフルスペック（スクラッチがないため連携テストの必要がない）のフレームワーク もって来たりしますし。 http://d.hatena.ne.jp/shot6/20080627#c1214581000 なるほど。 私のコンテキストの問題もあるのですが、私が言っているフレームワークとはたぶんに Webフレームワーク、特にプレゼンテーション部分に特化していることが多いと思ってもらってよいです。 （自分の性質上そうなってそう
フレームワークのジレンマ - おおたに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アプリケーション・フレームワークの未来について語った。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースApache Tuscanyで楽しむSOA一覧