InfoQ: グラフデータベース、NOSQL、Neo4j
VoldemortやTokyo Cabinetといったキー/バリューシステムにおけるモデリングの最小単位はキー/バリューペアになる。そして、BigTableやそのクローンでは可変数の属性をもつタプルに、CouchDBやMongoDBといったドキュメントデータベースではドキュメントになる。これに対しグラフデータベースでは、データセット全体をひとつの巨大な高密度ネットワーク構造としてモデル化する。 ここではNOSQLデータベースにおける2つの興味深いポイント、スケーラビリティと複雑さについて詳しく説明する。 1. スケーラビリティ CAP: ACID 対 BASE 従来のデータベースシステムのほとんどは、トランザクションに基づいてデータの完全性を保証する。トランザクションを使うことで、データ管理のあらゆる状況において、データの一貫性を確保している。こうしたトランザクションの性質は、ACID（A
InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
自己組織型チームを組織化する
原文(投稿日：2010/04/17)へのリンク Rashina Hoda 氏は、アジャイルの研究者で、 New Zealand、 WellingtonのVictoria University で博士を目指しており、米国 Louisiana State Universityから学士を取得している。 氏は、 New Zealand と Indiaで３年余り、企業ベースの博士号の研究の一部として、アジャイルのチームを調査してきた。彼女の研究成果は、世界中で出版されたり、発表されており、彼女は、Agile2008, Agile2009, そして XP2009 で発表した。 最近、５月に南アフリカの Cape Townで開催されるInternational Conference on Software Engineering (ICSE2010) に彼女の論文が受理された。世界中から３８０の応募があ
JSR 310 JavaのDate/Time API
原文(投稿日：2010/03/17)へのリンク JSR 310 Date/Time APIのリーダである、Stephen Colebourne氏は、Java言語に提案中の追加と変更に対する Early Draft Review を最近公表した。InfoQは、 QCon Londonで氏に会って、プロジェクトについて更に聴いた。 InfoQ:なぜ新しい Date/ Time APIが必要なのですか？現行のAPIの何が悪いのですか？ Stephen: 現在のAPI (java.util.Date と java.util.Calendar) の主な問題は、それらがミュータブルなことです。言い換えると、次のコードを考えてください： public class Employee { private final Date startDate; public Employee(Date date) { s
アジャイルと"ユーザ中心設計"の調和
原文(投稿日：2010/03/17)へのリンク UX のスペシャリストである Anthony Colfelt 氏はアジャイルについて，それが単独では不完全なものであることを論証するとともに，ユーザ中心設計のアジャイルへの統合の可能性とあるべき姿に関して，詳細かつ興味深い検証を行っている。 ビジネス の要件定義支援という課題の解決手段として，果たしてアジャイルが適当であるのかどうか。Colfelt 氏の メッセージ はそれに疑問を呈するものだ。 アジャイルそれ自体は，状況の変化に柔軟に対応する手段として有効なものです。しかしアジャイルが，より大きな課題である「ビジネス自体が要件を定義できない」ということの解決手段として考案されたものであるか，という点には疑問が残ります。確かにアジャイルによって，開発チームがこの課題に対応するのは容易になります。しかしそれで問題が解決するわけではなく，ほとんど
アジャイルコミュニティは、理性を欠いているか？
原文(投稿日：2010/03/15)へのリンク The pmiagile Yahoo! グループ は、２つのコミュニティが一緒になる場所である。このグループの投稿者は、幅広く、様々な経歴を持った人たちである。最近のスレッドでは、project management body of knowledge (PMBOK)に書かれているような、従来型のプロジェクト管理に、アジャイルのプラクティスを適用できるかどうかを議論したものである。（このリポータは、長い引用を、あらかじめ謝っているが、これは、言い換えることが難しい、情熱的なトピックである）。 Michael James氏がPMBOKから引用: １シーズンに１回ぐらい、私は、PMBOKは、アジャイルのアプローチと矛盾しない、と信じる気になる。もしそれが真実なら、いいことだが。（再投稿して）PMBOKガイド４版からのいくつかの引用は、「プロジェク
コメントを書くべきか書かざるべきか
原文(投稿日：2010/03/03)へのリンク 開発者ならだれもが、自分のコードに最低一行はコメントを書いているはずだ。コメントをたくさん書いて、コードをもっとわかりやすくしようとする人もいる。この記事では、コードにコメントを書くときに使われるプラクティスを集めてみた。 Seattle Area Alt.Net グループのメンバらが、コードにコメントを書く必要性やプラクティスについて議論した。Kelly Leahy氏は、一目瞭然のわずかなコメントが散りばめられているようなコードが好みだ。コメントは「コードを変更したときに取り残されてしまうことが多く」、「不正確なノイズをシステムに取り込んでしまうだけ」だと考えているためだ。 （コメントを書くということは）多くの人にとって個人的なことですが、私はコメントをかなりスリムにするよう気を配っています。というのも、コードを変更したときに、コメントが取
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java ラムダ式のシンタックスの第一バージョンが議論に火をつける
コード品質管理ツール Sonarが設計とアーキテクチャのメトリクスを提供
How to Audit an Agile Team
Scooter Framework; JavaにCRUDとシンプルさを提供
Google App Engine アプリケーション用の便利な小物たち
Toyota がウォーターフォールを使っている？
主流としてのアジャイル
アジャイル ドキュメンテーション：その明確さは？
一時的なコードと継続的に使うコード、そしてその間にあるすべてのコード
EclipseのGitプラグイン、EGitがリリース
チームの最適な構造
ソフトウェアアプリケーションのセキュリティリスク TOP 10
InfoQ: 分散バージョン管理システムの詳細なガイド