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は新たな悪い評判にさらされている。 InfoQで報じた通り、ここ数週間、ブラウザ上のJavaは深刻な脆弱性に苦しめられてきた。組織も個人もさまざまな方法でこの問題に対処している。多くがブラウザのJavaを無効にした。Appleは最新バージョンのOS Xでは独自バージョンのJavaの提供をやめたが、今年の1月に2度も、OS X上の現在のバージョンのJavaウェブプラグインを事実上ブロックしている。 現在のセキュリティに関するトラブルはOracleがAskツールバーをJavaインストーラに組み込んでいることにも飛び火している。Javaのインストーラにツールバーが組み込まれるのは、2005年にSunがGoogleツールバーをインストーラに組み込んだのが最初だ。3年後、SunはMicrosoftと取引をしてMSNツールバーを組み込み、2008年には
図1.シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード(”製品コード”と”テストコード”)です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか?その質
従って、この記事のタイトルにある質問に対して、かんばんが常識かどうかの答えは、「ノー!」です。しかし、常識は経験則の例であり、わたしは、かんばんが製品開発の数多くの挑戦を解決するための経験則に基づくアプローチだと信じています。経験則とは何か、経験則が正しいアプローチだと私に気づかせた第一の原因、そして、かんばんシステムを設計するために経験則をどのように使えるかについて、この記事の残りの部分でさらに調べましょう。 経験則 Merriam Websterオンライン辞書によると、「経験則」(heuristic)の意味は、次の通りです。: "実験的、特に、試行錯誤する方法によって、学習、発見、または、問題解決の手助けとして関係したり、役に立ったりすること。また、パフォーマンスを向上させるために(フィードバックの評価として)、自己学習技術を利用する、調査のための問題解決技術に関係していること。 1つ
ツール 個人的には Vim を好むようだが、Henneke 氏がこのプロジェクトで使用したツールについて以下のように述べてくれた。 「Eclipse内で検索するのは、びっくりするほど遅く煩わしいものです。」 「Xcodeのオーガナイザでドキュメントを検索するのは、腹立たしいほど遅いです。」彼は後に検索を速くする方法を発見した。 「Eclipse(および Androidプラグインの logcat 統合機能)のタグによるログの絞り込みはとても役に立ちます。」 「双方のIDEとも、コード補完機能は、本当に素晴らしいものです。」 「Xcodeのインターフェイス・ビルダは使い物になりません」 「Xcodeのインスツルメント機能は、プロファイリング、計測、デバッグに極めて有効です。」 「Androidエミュレータは完全なる時間の無駄です。その遅さときたら、ほとんど冗談のような代物です。私の開発サイクル
競争力を維持するために企業は,組織内部でイノベーションを行う方法を探している。その最初のステップは,新たな製品やサービスについて考え,アイデアを議論し,概念を生み出すための時間を確保することかも知れない。そのためのアプローチには,”フルタイム"の専任チームの設置,イノベーションのための十分な時間の確保,あるいは短時間かつ集中的なイノベーションワークショップの編成など,さまざまなものが考えられる。 Jeff Gothelf氏は自身のブログに,組織内部のイノベーションチームについての記事を書いた。技術革新に専念するチームの構築が重要な理由について,氏は次のように説明している。 効率のよいチームを構成するというのは,リーンチームの成功において,人を雇うのと同じくらい重要なことです。多くの企業は,製品開発組織における個々の分野を,サービスプロバイダ - 内部的なエージェンシ(事業機関)として考えて
アジャイル初心者の多くは、スクラムでアジャイルをはじめる。スクラムには明確な指針、ルール、プラクティスがあり、チームにアジャイルを導入するのに役に立つ。ところがスクラムもまた組織の中でさまざまな問題に直面し、多くの会社にとって成功を難しくする一因になっている。スクラムをやってきた人たちは自問する。どうすればよいのだろう? スクラムだけで十分なのだろうか? Jimmy Bogard氏は、なぜスクラムをやめたのか、なぜ彼のチームはスクラムで成功した後、そのコアプラクティスをいくつかやめることでパフォーマンスを改善できたのかについて、次のように説明する。 イテレーションはpullベースのアプローチほど効率的ではない。 タイムボックスで仕事をすること、割り当てて空きを埋めることには、何かしら心理的影響があります。明確なタイムボックスのイテレーションをやめて、できる限り早く納品することにのみ注力する
原文(投稿日:2011/12/28)へのリンク 企業がソーシャルメディアを使って製品や企業自体の評判を調べる傾向が顕著になっている。これに伴い、単語と定量的メトリクスを使い、文書に含まれる感情を分析するという独特の課題が現れている。 Subramanian Kartik氏とEMCのGreenplumチームはブログ記事をMapReduceとPythonのNatural Language Toolkitを使い、EMC GreenplumデータベースのSQL分析と組み合わせてスパースベクトルとK-平均法アルゴリズムを用いて分析するという研究プロジェクトを行った。 Subramanianは昨年のNoSQL Now 2011カンファレンスでこの研究について発表した。InfoQはこのプロジェクトと背後にあるアーキテクチャについてSubramanianに詳しい話を聞いた。 InfoQ:Greenplum
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
ほとんどの人が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。 これは
原文(投稿日:2009/09/16)へのリンク すべてのアーキテクトが知っておくべき97のこと (InfoQの記事)に続いて、「97のこと」シリーズの続編はすべてのプログラマが知っておくべき97のこと、だ。これらはwikiに集められて、誰でも貢献できるしコメントも受け付けている。 このwikiには既に(この記事を書いた時点で) 88 のエントリが集まっていて読まれている。例えば、 コードだけが真実を知っている by Peter Sommerlad氏 スピードは命取り by Uncle Bob氏 API設計の黄金律 by Michael Feathers氏 自分のIDEを知る by Heinz Kabutz 人々のためにテストを書くWrite Tests for People by Gerard Meszaros氏 InfoQは「すべてのプログラマが知っているべき97のこと」の編集者であるK
Ola Bini氏(リンク)は、JRuby (リンク)開発の中心人物であり、Practical JRuby on Rails Projects(リンク)の著者である。その彼が、Ioke(リンク)というJVMの上で動く新しい言語を開発している。Iokeの型を重視し、非常に動的でプロトタイプベースのオブジェクト指向言語が目指すところは、素晴らしいぐらい小さい正規構文を持つLispやRubyを使用したときに得られる同等の力を開発者に授けることである。 Ola氏は、以下にIokeの本質(リンク)に関する説明をしている。 Iokeは、強力な型付け言語であり、動的、プロトタイプベースのオブジェクト指向言語です。それは同図像であり、数種類のマクロがビルトインされています。Iokeに最も影響を与えた言語は、Io(リンク)、Smalltalk(リンク)、Self(リンク)、Ruby(リンク) そしてLisp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く