Sonar 2.4: アーキテクチャ制約ルールとMaven 3のサポートSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
OracleがJava 7 と Java 8のJSRを発表
原文(投稿日：2010/11/17)へのリンク Oracleは、Java 7/8の包括的なJSRを発表した。以前からPlan Bとして知られている、いくつものフィーチャがその中にある。JavaSEとJavaEEの仕様が定義される方法は、新しい内容を直接定義するのではなく、他のJSRを参照する方法をとる。しかしよく、参照されるJSRが完成した後で、そうするのである。今回は、参照される多くのJSRは、未だ作業中、あるいはモジュール化の件もあり、現段階では、わからないものもある。 JSR 336, Java 7は、以下のものを含むことを提案している。 JSR 203, Javaの新々IO API JSR 292, JVMへの invokedynamic の導入（メソッド ハンドルではない） JSR 334,Project Coin, としても知られており、恐らく含まれるのは、 switch文での
アジャイルのまずい考え方
ここに見られる悪い態度は、他の役割や専門家が価値を持っていることを理解できず、現実に沿った形で柔軟性をもつ必要性を認識せずに、哲学的な解釈に固執することだ。極端に言うと、この態度はすべての場面のすべてのマネージャにまでこの見方をひろげると労働主義者や、新共産主義者とほとんど同じものなのだ。確かにすべての企業文化や組織階層をフラットに無限定にすべきだという考えを採用する人々は急進的である。この見方は表層的ではあるが、このような考え方をもった人が(リーダーのように)権限のある人であるとすると、この人の考えは勢いをまし、開発チームとマネージャの関係を悪化させることもありえる。プロジェクトの完結という目的が、マネジメントと労働者の階級闘争に置き換わってしまうのだ。 “マネージャでなく、チームがプロジェクトを動かしているのだ。何を済ませるかは私たちで決定する。” この考え方は、マネジメントの役割はも
Spring 2.5：Spring MVCの新機能
Web層ではSpring XMLの設定が下の層に比べて冗長になりがちで、おそらくその価値も低い傾向にあるので、わずかな量のXMLで済むというのは素晴らしいニュースです。コントローラは、view名やフォームオブジェクト名、バリデータ型など多数のプロパティを保持しますが、その目的は依存性注入よりも設定です。そうした設定を効率的に管理する方法として、bean定義の継承や、あまり頻繁に変更しないプロパティの設定回避があります。しかし、経験から申し上げると、多数のデベロッパがそうした方法をとらないので、結果として必要以上のXMLとなってしまうのです。ですから、@Controllerと@AutowiredはWeb層の設定に非常に好ましい効果を上げられるのです。 シリーズ第2弾でこの議論を引き継ぎ、Web層向けのSpring 2.5アノテーションを一通り見て回ります。こうしたアノテーションは非公式に@M
GroovyServ - 高速起動Groovy -
スクリプトの開発は、出力結果の様子を見ながら、試行錯誤的に記述を修正していくため、起動速度が重要になります。1秒はとても待っていられません。 Groovyはその機能からして、本来PerlやRuby、Pythonなどにも拮抗しうる強力なスクリプト言語ですが、GroovyServを併せて使うことで、スクリプト言語としてのGroovyの本来のパワーを最大限に引き出すことができるようになります。 起動性能ベンチマーク GroovyServを用いた場合の起動時間、具体的には以下のコマンドラインの実行に要する時間を計測してみます。 $ time groovy -e "println 'hello'" この測定方法だと、起動時間だけではなく処理時間や終了に要する時間も含みますが、それは十分に小さいと仮定しています。 Mac OS Xでの起動速度の測定結果を[グラフ1]に示します（グラフ縦軸目盛りの単位は
5つのクラウドプラットフォームを計測し比較する
原文(投稿日：2010/07/23)へのリンク BitcurrentとWebmetricsは5つの異なったクラウドプラットフォーム上でいくつかのテストを実施した。対象となったのは、Amazon、Google、Rackspace、Salesforce.com、そしてTerremarkだ。実施したのはこれらのプラットフォームの性能を計測するためのテストだ。このテストの結果のひとつから言えるのは、アプリケーションのタイプによって各プラットフォームの性能は違うということだ。 このテストの報告書の作者たちは性能テストするのために4つの種類のテストを選んだ。そして5つのクラウド上で5つのネイティブアプリケーションを実行してベンチマークをとった。 テスト 小さなオブジェクトをリクエストする – 1x1ピクセルのGIF 多くなオブジェクトをリクエストする – 2MBのイメージ CPU負荷の高いタスクを実行
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iPhone 開発環境は Android より優れているか？
JAX-RS 2.0に関する取り組みが始まった
Google App Engine、Google Closureを使ったHTML5アプリケーション開発
Spring Roo 1.1.0 リリース: OSGi，データベースリバースエンジニアリング，GWT 2.1 機能をサポート
どんなアジャイル指標が報告されるべきか？
Eclipse Virgoリリース
GoogleとSpringが協働でクラウドのJava開発を推進
Eric EvansがDDD（ドメイン駆動設計）を語る
Ramnivas Laddad氏がAspectJおよびSpring AOPでのAOP選択について語る
ストーリーポイントは複雑さや時間と関係があるか？
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
Adobe が Hadoop のための Puppet レシピをリリース
アジャイルとは何を意味するのか - 調査結果より
米国におけるAgileユーザグループ：プラクティスのコミュニティ
