GOTO Berlin: マイクロサービスを用いたWunderlistの再構築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が最近リリースされ、重要な変...
Datomic情報モデル
データベースは、主にデータを通して提供する力のおかげでデータベースだと言えます。他の点では、単なるストレージシステムです。通常、この力は、データの組織化 (例えば、インデックス) と、組織に影響を与えるクエリシステムの組み合わせから来ています。開発者たちは、興味深い、ますます広く使われる冗長な分散ストレージシステムを、自由に手に入れていますが、しばしばその影響力を失っています。Datomicはこれらのストレージシステム上で動き、スケイラビリティや組織化した情報の保存、そして、開発者自身の手に力を取り戻そうとしています。 構造と表現 データベースは、リレーション、列とドキュメント等、そのモデルの下部にある基本ユニットを持ちます。Datomicのユニットは、私たちがDatomと呼ぶ原子的な事実です。 Datomは以下のコンポーネントを持ちます。 Entity Attribute Value T
効果的なテストの文化を創る
自動テストの場合、シナリオ、実行、検証はすべてプログラムによってドキュメント化され自動化されます。唯一の手動のセットアップはシナリオ実行のボタンをクリックするだけです。記憶に頼る必要もありませんし、賞味期限の切れたドキュメントを頼って、シナリオを追いかけ、手動で実行する必要はないのです。 ほとんどの開発者が自動テストの価値を認めながら、その利点を享受するのに失敗しています。私は幸いなことに、利点を享受するための正しい方法を見つけることができました。 責任 テストに責任を持つことがなかったら、テストを自動化する時間はなかったでしょう。これはとても単純なことです。自分が開発を支援したシステムのサポートを担うことで、私はソフトウエアがきちんと動作することを保証するということに大きな関心を抱きました。午前5時に電話で起こされて問題を解決するのはごめんです。私は問題がその日のうちに解決するようにこつ
SOAを超えて: 動的な業務アプリケーションのための新しいエンタープライズアーキテクチャフレームワーク
ソフトウェア開発においては、多くのフレームワークや製品がその（変化に対する）適応能力を誇示しています。あるソリューションがどれほどうまく変化に適応できるかを把握しようとする前に、システムがどのように変化するか - それこそがダイナミック（動的）と言うことです - についてのしっかりした定義が必要とされます。 初期のオブジェクト指向による手法では[1]、システム分析は中立でなければならず、現実世界に置ける二種類の要求をベースにしていました。: 現実世界のエンティティ?現実世界のエンティティとその関連についての情報を収集することで、技術的・主観的な視点ではなく、オブジェクティブな視点でシステム構造の分析を開始することができる 現実世界のイベント?現実世界のエンティティが持つ状態を変化させるイベントの発生のみが、システムの振る舞いを決定する あらゆるシステム分析に対するこうしたコンテキストにおい
アジャイルのレトロスペクティブはなぜ難しいのか？
レトロスペクティブ（ふりかえり）は，チームの作業方法を見直して修正することによって，自らの作業を改善するものだ。より多くの価値をユーザに提供する手段として，アジャイルの重要な手法のひとつに数えられることも多い。しかし時には，レトロスペクティブを行うのが難しく思われることもある。変更すべき対象がチームメンバのコントロール範囲外にあると感じられたり，改善の余地がないように思われたり，適切なアクションの定義が難しく感じたられりすると，アクションの定義よりも先に不満が口をつき始める。そうなるとレトロスペクティブがつまらない，単なる時間の浪費だと感じられてしまうのだ。このような問題に対処して，より有意義なレトロスペクティブを行う方法を見つけるには，どうすればよいのだろう？ Keith McMillan氏のブログ記事 agile concept of the week: retrospective に
ビッグデータをドリルする
Hadoop関連のあらゆる技術が注目を集める現在、Hadoopのエコシステムの中から新しいプロジェクト/実装が生まれ続けているのは驚くべきことではない。Apache Drillは大規模なデータセットをインタラクティブに分析できる分散システムを開発するプロジェクトであり、GoogleのDremelから着想を得ている。Hadoop MapReduceのような既存のビッグデータバッチ処理フレームワークやS4やStormのようなストリームプロセスフレームワークの代替ではなく、大規模データのリアルタイムでインタラクティブな分析を実現する、今までなかった製品だ。 Dremelと同じようにDrillの実装は入れ子になっているツリー構造に似たデータの処理を基本にしている。Dremelでは、データは入れ子のスキーマベースデータモデルであるプロトコルバッファが基本になっている。Drillはこのデータモデルを拡
InfoQ: ErlangとYawsを使ったRESTfulサービス
以前に有名となった「Apache vs Yawsのグラフ」(source)を見て、あなたもまたYawsを使うべきだと思ったでしょうか? 一見すると、そのグラフは、Yawsに対する信じられないくらい大きなスケーラビリティの優位性があるように見えます。Apacheが4000のパラレル接続でダウンしたのに対し、Yawsは80,000を超えるスケール能力を持っています。このグラフに対する反応は大きく二極化する傾向にあります。「これらのグラフは正確な方法で行われたものではなかった」あるいは「Apacheの設定ミスに違いない」というものと、それとは反対に「ワオ！Yawsを利用する価値がある」というものです。 Yawsの比較グラフを信じるかどうかに関係なく、Yaws(サイト・英語)は動的コンテンツを提供するための確かなWebサーバーです。Claes Wikstrom氏は、Yawsを「もう一つのWebサー
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GoogleがSSL 3.0のサポートを廃止
Etsyはいかにして1日に50回ものデプロイをしているのか
Java 7 ソケット・ダイレクト・プロトコル - 一度書けば、どこでも実行できる、ある場所では驚くほどに
メンテナンス可能な自動受け入れテスト
Jepsen: PostgreSQL, Redis, MongDB および Riak の分割耐性をテストする