Not rated yet. You must be logged in to rate this. video.
1, Recorded on 2010/04/23 kazunori_279 on USTREAM. Conference
Not rated yet. You must be logged in to rate this. video.
Slim3 に Scenic3 と PirkaEngineを使う方法 - やさしいデスマーチ
ここの所、随分とAppEngineへの関心が高まってきているようです。Slim3の周辺も活発になってきている事もあり、Scenic3に注目していただく方もチラホラと出てきました。注目されるということは非常にモチベーションが高まります。 今回は前回に予告した通り、Scenic3にPirkaEngineを組み合わせる方法の紹介です。Slim3はGAE上で動作するフルスタックのMVCフレームワークですが、その大部分の機能はModelに相当するDatastore周りです。View層はJSPに幾つかのヘルパが用意されており、Controller部分はシンプルな１コントローラクラス＝１URLのパターンになっています。この組み合わせでも、十分に機能するのですが、JSPを使いたくない場合や１クラスに複数のアクションメソッドを記述したいスタイルとは相性が悪くなります。後者についてはScenic3が解決する領
Java開発者の読むDjangoの設計思想 - やさしいデスマーチ
Djangoのサイトには「Djangoの設計思想」というドキュメントがあります。どんなフレームワークでもそうですが、設計思想を理解し、その流れをつかむ事で正しい利用への最短ルートです。もし、自分の思想にあわないならば問題です。可能であれば、そのフレームワークの検討を取り止めるべきでしょう。それが出来ないならば利用している時にはそのフレームワークの思想で思考することが求められます。 Djangoの設計思想は、緩く結合し、必要最低限のコードで、だが隠蔽せずに明示するという事です。DjangoではMVT（モデル／ビュー／テンプレート）と呼ばれるMVCに近い構造をとります。それらの３つのレイヤーはお互いに疎な関係を持ち、モデルとテンプレートはデフォルトの実装以外を容易に採用できるようになっています。また、ほどよく規約を適用し必要なコード量は少なくなっていまが、なんでもかんでも裏側で処理せずに、なに
JMockitは理想的なモックフレームワーク - かとじゅんの技術日誌
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
AppEngine/Jのspin-upを劇的に改善する方法 - ひがやすを技術ブログ
AppEngineは、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入しています。 そのため、アプリケーションを起動(spin-up)する時間がとても重要になってきます。このspin-upの時間はpython(webapp)で60cpu_ms以下。(cpu_msはcpuが使う仮想的な時間ですがmsと同じ感じで捉えてもらってもとりあえずは大丈夫です)JavaのServletだと600cpu_msくらいです。PythonでもDjangoような大きなフレームワークだと1000cpu_msくらい(アプリによる)かかりますが、許容範囲内。JavaだとSlim3で1300cpu_ms、Springだと早くて7000cpu_msという感じで、Slim3がギリギリ許容範囲内でしょうか。ほんとうは、1000
Google App EngineでWebサービスを作ってみての ”実際のところ”
先日、Amazonの価格をチェックしてメールでお知らせするWebサービス「マケプレ・フラグ」を公開してみた。 このWebサービスは、sinatra on GAE/JRuby という構成で作ってあるのだけど、実は4、5日程度でひととおりの機能が動作するくらいになっていた。 別にGAEバンザイと言いたい訳ではなくて、本題はここから。 GAEって制限が多くあるので、これを回避するのが結構大変。さらに「マケプレ・フラグ」は価格情報を得るためにAmazonのProduct Advertising APIを使っていて、実はこちらにも制限がある。 GAEは30秒以内にレスポンスを返さなくてはいけない 利用者が商品検索して30秒も待ってくれる訳はないので、それは問題にならない(というより30秒も待たせるならGAEに関係なく設計を見直すでしょ)。 問題は、cronで実行するようなバッチ処理も同様の制限がある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PirkaEngine
http://japan.internet.com/column/developer/20080603/26.html