テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
開発におけるDocker導入のメリット - Qiita
DockerのPros/Consとか今更感ある。他の仮想化技術との比較記事はよく目にするが、開発にどのようなメリット・デメリットがあるのかあまり周知されていないようなので自分なりの感想を書いておく。 Pros 同一性 複数人で開発する際に、環境の差が生まれない。 カプセル化 アプリケーション込みの環境をコンテナというカプセルに隠蔽することができる。 コンテナという単位に対するテストが可能に。 コンテナを捨てる・再生成するのが容易。 ポータビリティ（一貫性とも） 開発に使ったコンテナをCIでテストできる。 CIでテストしたコンテナをサーバーにデプロイできる。 デプロイしたコンテナをスケールできる。 Prosで防げる消耗 おれの環境では動いた。 はい。 複数の開発者で同一の環境で開発できるので防げる。 ローカルで通ったテストがCIでコケる。 開発と同一の環境でテストできるので防げる。 bund
失敗するプロジェクトと成功するプロジェクト
多様なプロジェクトの進め方がありますが、進め方を問わず、「成功するプロジェクト」に共通する要件は何なのでしょうか。 以下に最も重要だと思う2点を紹介します。 うまくいくプロジェクトの要件 コミュニケーションがプラットフォーム化しているプロジェクト 弊社、Cuonでの経験則になりますが、成功するプロジェクトは「コミュニケーションがプラットフォームとして成立しているプロジェクト」といえるのではないでしょうか。 『もしドラ』のヒットで日本でも一般的に有名になったピーター・ドラッカー氏は、かつてこう言いました。 コミュニケーションで一番大切なことは、相手が口にしていない言葉を、聞き分ける力である。 この言葉には、「相手が全てのことを口にしているわけではない、もしくは全て言葉で表せるものではない」という意味が含まれていると思います。 プロジェクトを進める過程で、プロジェクトマネジャーに大事なことは、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンタープライズアジャイルからアジャイル企業へ
