デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
Benchmarking High Performance I/O with SSD for Cassandra on AWS
by Adrian Cockcroft Today AWS has launched a new Solid State Disk (SSD) based instance that addresses the need for high performance I/O, and we have run a few initial benchmarks to see how it shapes up. With this announcement AWS makes it easy to provision extremely high I/O capacity with consistently low latency. AWS has been competitive in instance memory capacity for a long time and is leading
心折れないためのカルドセプト - 妄想科學倶樂部
カルドセプトは決して簡単なゲームではないし、1回のプレイに時間がかかるゲームでもあるので、どうしても挫折者が出ることは避けられない。しかし熱心なファンの一人としてはプレイヤーがどんどん増えて欲しいので、できる限り挫折を避けられるようにサポートしたい。 あくまで基礎的な話で、必ずしもこの指針に従わねばならぬようなものではない。が、基礎を知らずして応用に走って強くなれるものでもない。 挫折の原因 最初に挫折の原因を考えてみると、恐らく大きく分けて次の3つだろう。 全然勝てない 長い時間かけて戦ったのに負けて脱力 カード集めがしんどい 1と2はブックの調整やプレイ技術の問題になる。まずはそれを解決しよう。 敗因 負けた時のパターンというのは大体 ずっとリードされたまま終わる 後半に逆転される 育てた領地を落とされる 高い通行料を取られる のいずれかだろう。 1は全体にブックの動きが悪く、とりわけ
プログラマが欲しい仕様書とは
3. ソフトウェア工学とは • ソフトウェアの開発・運用・保守に ついて体系化、分析、研究する分野 • 高度で安全なソフトウェアを短期間 で設計するための研究を行う
Club DB2 でゲスト講師をしました - ミックのブログ
昨日 7/13 に渋谷マークウェストで Club DB2 のゲスト講師としてお話をさせていただきました。RDB の設計における物理と論理のせめぎあい（トレードオフ）というテーマで、前回以上に自由に喋らせていただきました。いつもながら運営の寛大な方針に感謝しています。ご参加いただいた皆様、お疲れ様でした。 講演では説明が足りなかった部分、また質問をいただいたことで改めて自分でも考えてみたことを、少しここで補足しておこうと思います。 ぐるぐる系が悪いケース まず、前提としてぐるぐる系が猛威を振るうのはバッチです。オンラインでは、そもそもループ回数が少ないので大きな問題にはなりません。講演でも、最初にこのことを明示して話を進めるべきでした。前提をはしょったせいで混乱を招いたかもしれません。 ぐるぐる系を並列させるのはどうか ループそのものは直列だとしても、ループ自身をジョブレベルで並列させれば、
実践！データベースリファクタリングツール
2. 開発中のデータベース スキーマの変更 正直避けられない 開発中 出来ればデータを消さずにスキーマを変更したい 運用中 絶対にデータを消さずにスキーマ変更する -> 楽はしたいがデータが消えるのは困る 3. データベース スキーマ変更管理の課題 情報の一元化 マスタの情報と差分情報がバラバラになって一元管理されずにズレが生じる場合がある データの消失の防止 特に運用中は必須 管理の容易さ 複数 DBMS への対応 4. データベース変更管理ツール ( データ準備型 ) 初期データを用意して、スキーマ変更の度にスキーマを作り直して初期データをロードし直す ツール S2JDBC-Gen 、 Jiemamy 利点 管理するのは最終的なスキーマ情報だけで良い 毎回スキーマを作り直すのでどんな変更でも対応できる 欠点 用意したデータを使うので開発者ごとに違うデータを使ったりするのは難しい データ
訳：ELB：評価方法のベストプラクティス - aws memo
Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services http://aws.amazon.com/articles/1636185810492479 ＝＝＝＝ 概要 ELBを最もよく評価するには、ELBのアーキテクチャを理解する必要がある。本稿は、AWS ELBの機能と独特なアーキテクチャについて述べる。ベストプラクティスを提供することで、ELBをテスト・評価する際に一般的な落とし穴(pitfall)から避けられるようになる。このホワイトペーパーが対象としている読者は、ELBの経験が少ないが、過去にH/W,S/Wのロードバランサを使ったことがあるような開発者である。 ELBの概要 ELBは、複数のEC2インスタンスへ、自動的にトラフィックを分散する。単
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
