CloudBeesがJenkinsエンタープライズ版をリリース
原文(投稿日：2011/12/20)へのリンク CloudBees が Jenkins Enterpriseをアナウンスした。これはオープンソースの継続的統合(CI)サーバーの有償版で、大規模にJenkinsをインストールしている会社がターゲットである。 このエンタープライズ版は以下のことに焦点を当てている。 技術サポートを毎日24時間世界的規模で提供する Long Time Support (LTS)バージョンは、3ヶ月（オープンソース版におけるコミュニティサポート）から12ヶ月（エンタープライズ版）に拡張される 大規模にJenkinsをインストールしている会社に役立つ、プロプライエタリなJenkinsプラグインを追加する CloudBeesの社員である Koshuke Kawaguchi氏は、分裂前にはオリジナルのHudsonの開発を率いていた。更にCloudBeesの数人の社員がJe
Jenkins，Hudson，そして Eclipse
原文(投稿日：2011/05/11)へのリンク Hudson を Eclipse 財団に移行する 先日の提案に伴って，これが Jenkins と Hudson の再統合につながるのではないか，さらにはコードライセンスの EPL への変更があり得るのではないか，などの憶測が生まれている。 今回の移行に関する発表にまったく関与できなかった Jenkins コミュニティからは，憤怒の声が多数 (コメントスレッドに見られるように) 上がっている。さらに，移行を承認する企業がいくつかある一方で， まだ CloudBees がその中に含まれていないのだ。 Eclipse 財団に移行するという案は，実は プロジェクトが分裂する 以前にもあった。しかし，プロセスがあまりにも重い，という理由で，その時は拒否されている。Jenkins が常に迅速かつ反復的な手法で開発されているのに対して，Oracle と S
組み込みシステムのアジャイル
アジャイルが「隔たりを越えて」ソフトウェア開発業界の主流に入っていくにつれて、一見したところアジャイルは適合しないかもしれないと思われるソフトウェアプロジェクトにさらに多くのタイプが現れている。現実には、これはアジャイルとプロジェクトが本当に合わないというよりも、これらのプロジェクトを支援するために専門家によって書かれたアドバイスを見つけることが難しいためであろう。 そのような分野の1つは、ハードウェアと組み込みシステムのソフトウェア開発のものだと言う人もいる。Mark Levison氏が、時間をかけて、組み込みソフトウェア開発プロジェクトにアジャイルを適用する人々の経験に関する情報について役に立つ参照先(リンク)を集めている。 組み込みソフトウェアプロジェクトにアジャイルを適用することは、相当ユニークな難題を示しているように思えるかもしれない。例えば、 対応するハードウェアをすぐに入手で
プロダクトオーナーパターン
プロダクトオーナーの役割は、多くのオンライン・フォーラムやブログで定期的に議論されている。この役割の持つ課題と、そこに含まれるさまざまな責任は、議論やアドバイスが生み出される原因になってきた。 最近、プロダクトオーナーという役割と、アジャイルプロジェクトの中でプロダクトオーナーが確実にやるべき重要な活動について、いくつか議論がなされた。 Mary Poppendiek氏は、「プロダクトオーナー問題」について記述し、次のように述べている。 構築するのにふさわしいものを発見するのは、優れたプロダクトを作る上で最も重要なステップです。そこで間違えると、出来上がるものが100%無駄になってしまいます。何を作るべきかということに関する決定を１人のプロダクトオーナーに委譲してしまうと、開発チームが行うべき最も重要な仕事を、本当にすぐれた決定を行うスキルや知識のない人にアウトソーシングすることになります
仮想パネル：ソフトウェアアーキテクチャの文書化について
原文(投稿日：2009/08/10)へのリンク ソフトウェアアーキテクチャの文書化というのは、企業のアプリケーション開発プロセスにおいて重要である。プロジェクトにおけるアーキテクチャの文書化のニーズを理解する上で重要なことは、アーキテクチャの文書化がプロジェクトのライフサイクルにおいてどんな役割を果たすのか理解することだ。プロジェクトにおいて、アーキテクチャドキュメントを作成する根本的な理由は、コミュニケーションと分析と記録のためである（例えば、ある決定をドキュメントに記録しておくと、時間が経過しても失われることはない）。プロジェクトで作成するアーキテクチャドキュメントの量と種類は、そのプロジェクトで作成するプロダクトのコミュニケーションおよび分析のニーズを反映したものにするべきである。 アーキテクチャドキュメントは、プロジェクトからマネジメントへ、アーキテクトや主任設計者から開発者へ、プ
InfoQ: HTTPSコネクションの最初の数ミリ秒
ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは
InfoQ: あなたがやっているのはテスティングかチェッキングか？
原文(投稿日：2009/12/08)へのリンク ソフトウェアテスティングとは、ステークホルダにテスト中の製品やサービスの品質に関する情報を提供するために実施する、経験的調査のことだ。しかし、この定義では、テスティングとチェッキングの微妙な違いを生む「知恵」については語られていない。Michael Bolton氏は、これら2つの違いと、その違いがある理由について語った。 Michael氏によると、 チェッキング（チェックすること）とは、すでにある信念を確認するという動機から実施するものです。チェッキングは確認、検証、妥当性確認というプロセスになります。すでにそれが正しいと信じているときに、チェッキングによってその信念を確認します。コードを変更してもこれまで同じようにすべて動作することを確かめたいときに、私たちはチェックします。 テスティング（テストすること）とは、新しい情報を見つけるという動
メンテナンス可能な自動受け入れテスト
原文(投稿日：2009/12/07)へのリンク 自動テストはすぐに辻褄が合わなくなってしまい、メンテナンスするのが大変だ。従って企業もテストを自動化したがらない、とDale Emery氏は言う。氏は、最近公開したペーパーにテスト自動化に関わる共通の問題を回避するための実践的な方法を記している。これは、典型的な自動化コードから始めて、より強力でメンテナンスしやすいコードに育てていく方法だ。 氏のペーパーの根底にある発想は、テスト自動化はソフトウエア開発だ、ということだ。この発想はシンプルでとても現実化しやすい。Dale Emery氏はこの発想をElisabeth Hendrickson氏から教え込まれた。 ほとんどのソフトウエアにとってメンテナンスは、初期開発以上にコストがかかるものだ。しかも、そのコストはコードの生存期間全般にわたる。テスト自動化の分野では、レコード/プレイバックスクリプト
.NET 版 Cucumber について，Aslak Hellesøy 氏へのインタビュー
原文(投稿日：2009/11/12)へのリンク Cucumber が先日 .NET をサポートしたことについて，InfoQ は作者である Aslak Hellesøy 氏にインタビューを行った。Cucumber はビヘイビア駆動開発 (Behavior Driven Development，BDD) のための受入テスト (acceptance testing) ツールである。Agile 2009 の時，InfoQ の Mark Levison が 機能テストツールワークショップ のレポートとして，Matt Wynne，Richard Lawrence 両氏による Cucumber の .NETソリューション開発開始について伝えたことがある。これが後に Cuke4Nuke という名称になった。 InfoQ: Cucumber について簡単に説明してください。 Aslak: Cucumber
激論: Prototype vs. jQuery
クライアントサイドにおけるウェブ開発の場面で Ajax が当たり前のように用いられるようになり、「どの JavaScript/Ajax フレームワークが最高か」という問いかけをよく耳にするようになった。Glenn Vanderburg 氏が記事の中で Prototype(参考記事リンク) と jQuery (参考記事)を比較すると、業界のエキスパートである Douglas Crockford 氏と Dion Almaer 氏からさまざまなレスポンスが返ってきた。 Glenn Vanderburg 氏は自身がプロとして JavaScript をつかった経験から語り始め、彼がどういう事情で両方のフレームワークをつかって作業するに至ったかを説明する(リンク)。 Rails をつかった開発を経験した多くのプログラマと同じく、わたしは JavaScript ライブラリである Prototype(リン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: 良いテストの品質とは何か?
Kanban and Scrum - Making the Most of Both
プロダクトオーナはスクラムマスタを兼任できるか
レガシープロジェクトでテストの自動化を始める
Facebookはどのようにコードを出荷しているか
DiggとRedditがNoSQL陣営に入る
アジャイルを導入するパイロットプロジェクトの選び方
テストを分類する
RESTfulなJSON Webサービスのベストプラクティス
Atom Publishing Protocolは出来損ないか？