Hazelcast 2.0 リリース，オフヒープ・ストレージと分散バックアップを装備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が最近リリースされ、重要な変...
JavaをRESTful設計に合わせる
Javaがこれまで長年にわたってソフトウェア開発の世界に肯定的な影響を与えてきたこと、すなわちJavaとJVMが多くの開発者とアプリケーションに対する主要な、汎用的ソリューションであり続けることを誰も否定することはできない。 CORBA, Java EE, SOA, REST あるいは Web サービスがあるが、Javaはこれらすべてをサポートすることができる。JavaとRESTが広く普及していることを考えれば、この2つを合体する、標準をベースにしたアプローチが現れるのは、単に時間の問題だった。そしてそれが JAX-RSであり、EE6で導入された。多くのJAX-RS実装があり、その中には、 Jersey（参照実装）や RESTeasyがあり、広く使われている。 長年にわたり、JAX-RSについて批判があるが、特にそれがRESTfulな設計を奨励しているのかどうかについてである。これらの問題
スクラムの先へ進む
アジャイル初心者の多くは、スクラムでアジャイルをはじめる。スクラムには明確な指針、ルール、プラクティスがあり、チームにアジャイルを導入するのに役に立つ。ところがスクラムもまた組織の中でさまざまな問題に直面し、多くの会社にとって成功を難しくする一因になっている。スクラムをやってきた人たちは自問する。どうすればよいのだろう？ スクラムだけで十分なのだろうか？ Jimmy Bogard氏は、なぜスクラムをやめたのか、なぜ彼のチームはスクラムで成功した後、そのコアプラクティスをいくつかやめることでパフォーマンスを改善できたのかについて、次のように説明する。 イテレーションはpullベースのアプローチほど効率的ではない。 タイムボックスで仕事をすること、割り当てて空きを埋めることには、何かしら心理的影響があります。明確なタイムボックスのイテレーションをやめて、できる限り早く納品することにのみ注力する
DRY原則の利用: コードの重複と密結合の間
原文(投稿日：2012/05/25)へのリンク DRYは重複とそれに伴うメンテナンスの問題を軽減するものだが、誤用すると密結合を生み、可読性を損うおそれがある。教訓：ソフトウェア開発原則は、ほかの原則やパターン、プラクティスを考慮して適用しなくてはならない。 DRYは Don’t Repeat Yourself の略語であり、Andy Hunt氏とDave Thomas氏が書籍「The Pragmatic Programmer: From Journeyman to Master」（邦訳：「達人プログラマー―システム開発の職人から名匠への道」）で最初に言及したソフトウェア開発原則だ。その原則はこう述べている。 知識のあらゆる部分はそのシステムにおいて単一で、曖昧さのない、信頼できる表現でなくてはならない。 ここでHunt氏は重複による負の影響と、それゆえにDRYを利用することの重要性を強調
GAE開発の落とし穴
Googleが提供しているクラウド環境「Google App Engine」（以下GAE）、個人で利用している人、既に開発として使用している人、これから開発に使う人、色々かと思います。我々も開発プロジェクトとしてGAEを使うこととなり、全く経験のなかった環境やツールに戸惑いながらも開発を進めています。進めていくなかで様々な困難や今までのWEBアプリ開発と違った作法に苦悩いたしました、その苦悩の数々をここに書き記せればと思います。 開発はGAE/Jで行いましたので、これからの内容はGAE/Jの場合のお話とさせていただきます。 今回はGAEが掲げるメリットとともにプロジェクト進行時にハマった点、問題と感じた点を書いていきたいと思います。この記事が出るころには解決している部分も多々あるかもしれません。単に我々の経験・知識が不足しているだけかも知れませんが、同じようにこれからGAEに取り組む方がい
Java 7と8についてAdam Messinger氏が語る
原文(投稿日：2011/08/01)へのリンク 先週のJava 7のリリースを受けて、InfoQはOracleでFusion Middlewareグループで開発部門のバイスプレジデントを務めるAdam Messinger氏に今回のリリースとJava 8についての同社の計画について詳しい話を聞いた。 InfoQ: OracleのJavaに対する"全体的"な計画がどのようなものか教えてくれますか。 OracleはIBMのような大企業から個人開発者までの他のグループも巻き込んでJavaの開発を続けていきます。JCPのようなAPIや使用が開発される団体やOracleがスポンサーになっているGlassFishやOpenJDK、参画しているEclipseのようなプロジェクトにも関わっていきます。私たちの最優先事項はすべての開発者のために時代とともにJavaの生産性、信頼性、技術を進化させ続けることです
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文での
FlexおよびJavaアプリケーション構築のためのテクノロジー
Flash Playerは、ブラウザー内のFlash Platformで作成されたアプリケーションのためのクライアントランタイムです。これらのアプリケーションは、ブラウザーベースのアプリケーションの利点である、あらゆる場所からのアクセス、容易な開発（インストールが不要）、簡単なアップデート、すべてのオペレーティングシステムおよびブラウザーでの一貫性といった特長をすべて備えています。一方で、ブラウザーベースのアプリケーションの制限として、オフラインでのアクセスができないこと、ブラウザーのセキュリティサンドボックスの制約により、ブラウザーウィンドウ外部のユーザーのコンピューターとのやりとりができないことといった欠点を持ちます。 ブラウザー内とブラウザー外の両方のアプリケーションの利点を取り入れるためにアドビが開発したのが、Adobe AIRです。これは様々なオペレーティングシステムで動作するラ
InfoQ: Google App EngineにJettyを採用
原文(投稿日：2009/8/5)へのリンク Google App Engineが当初使っていたウェブサーバ/サーブレットコンテナはApache Tomcatだった。しかし最終的にJettyへと変更された。開発コミュニティではこの決定により、なぜ変えたのか、Tomcatでなにか問題があったのか、と多くの人が問いを投げかけた。InfoQはJettyの開発元企業であるWebtideのチームにインタビューをする機会を得て、今回の決定の事情について詳細を聞いた。 InfoQ：GoogleがTomcatや他の選択肢でなくJettyをApp Engineに選んだのはなぜでしょうか。 GoogleがJettyを選んだ理由と思われる特質はサイズと柔軟性です。クラウドではサイズが重要です。Jettyのインスタンスを（Googleがしているように）数万動かすとすると、各サーバが1MB小さければ全体で数十GBのメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google：マネージャはやはり重要な存在である
Ruby から Java へのシフトで大統領選を乗り切った Twitter
jQueryをサポートしたApache Wicket 6がリリース
一生懸命働いていますか？
Spring SocialはJavaにソーシャル接続を提供する
Heroku上でPlay!の公開ベータがリリース
Eclipse Jubula: 機能テストの自動実行ツール
InfoQ: 複合Web APIのPlayを評価
Java ラムダ式のシンタックスの第一バージョンが議論に火をつける
アップグレードと異なるプログラミングパラダイムのためのHadoop再設計
David Pollak氏 lift と Scala を語る