概要 DockerCon 2016 のキーノートで、新しい Docker 1.12 の機能に関する説明がありました。また、その発表に合わせるように blog への投稿 “Docker 1.12: Now with Built-in Orchestration!” もありました。例によって日本語訳を作成しましたので、内容把握の参考程度にどうぞ。 図版は省略しました。原文をおたどりください。なお、自分の整理用に以前のバージョンの比較用画像を作りましたので、こちらも参考程度にどうぞ。 Docker 1.12: ついにオーケストレーションを組み込み！ ３年前、Docker は難解な Linux カーネル技術をコンテナ化（containerization）と呼ぶシンプルで誰もが利用しやすいものにしました。今日、私たちはコンテナのオーケストレーションも同じ様にします。 単一ホスト上にコンテナを個々にデ

牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ

こんにちは。商品本部デジタルマーケティング室の 作野 浩之 です。 先日、AWS Summit Tokyo の Developers Conference で発表した「タウンワークにおけるサーバーレスアーキテクチャデザイン」の詳細について、お話しようと思います。 実施した施策について リクルートジョブズはタウンワーク、フロム・エーナビ、とらばーゆ、はたらいく、リクナビ派遣など複数のメディアを取り扱うのですが、今回はタウンワークにおいて、以下のような施策を実施しました。 つまり、サイト内のユーザーの行動に応じて、ユーザーの嗜好を元にダイナミックに検索結果を変更するという施策です。 最終的に出来上がったシステム構成 結論からいうと、このようなシステム構成でもって、リアルタイムな予測を用いた検索システムを構築しています。 詳細については以下で触れていきます。 システムを作る上で最も考慮したポイン

2016年になってもアジャイルはテストをしないとか、計画を立てないとか、1日10回デプロイするための技法といった誤解が広まっているのは残念すぎる。 まず、ITのビジネス価値を最大化するという視点が必要なはず。事業の売上や費用を改善するためにシステムを活用するのであって、システムを作ること自体は目的にならない。 事業を取り巻く環境は変化が速いので、ITもそれに合わせて変えていく必要がある。1年後にシステムが完成したら事業環境が変化していて役に立たないかもしれない。投資が無駄になるリスクを抑えるために、数週間で軌道修正を繰り返す。 だから、事業環境の変化にITを対応させるためにアジャイルが必要、という話の流れになるはず。システムを作るためにアジャイルが必要とはならない。事業上の必要性からアジャイルを選択する。 ここまできて初めて、ITのビジネス価値を最大化するためにスプリントや自動デプロイとい