タグ

ブックマーク / www.ryuzee.com (9)

  • 【資料公開】強いチームの作り方 | Ryuzee.com

    2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。

    【資料公開】強いチームの作り方 | Ryuzee.com
    maangie
    maangie 2015/11/11
  • AWSを使ってスライドを公開するデモアプリを作ってみた話 | Ryuzee.com

    なんか色々思いついたのでデモアプリを作ってみました。実際に動作しているデモは https://slide.meguro.ryuzee.com/ にあります。 ソースは以下に置いてあります。あくまでサンプルの延長線上なのでValidationが緩かったり、あぶない実装があったりするかもしれませんのでその点はご了承ください。なお、動かすためには、最低でもAmazon S3とAmazon SQSが必要です。サーバについては自身の端末でVagrantを使って動作させることもできます。 ソース:https://github.com/ryuzee/open-slideshare開発環境(VagrantやChefのクックブックなど一式):https://github.com/ryuzee/open-slideshare-environmentアーキテクチャーAWSを使う前提になっていて、以下のようなアー

    AWSを使ってスライドを公開するデモアプリを作ってみた話 | Ryuzee.com
    maangie
    maangie 2014/12/28
  • [Agile]インセプションデッキ日本語版 | Ryuzee.com

    インセプションデッキって何?って人はThe Agile Samuraiを読むと良い。 The Agile Samuraiの日語版は@kakutaniさんや@nawotoさんが頑張ってらっしゃるので、期待して待っていよう。 簡単にいうと、インセプションデッキは10個の質問から構成されていて、プロジェクトを始めるにあたって、その質問に答えることによって、プロジェクトの全体像やこれからの方向性等を明らかにしてくれるツールだ。(逆に答えられないとするとその時点で結構ヤバイということでもある)。そしてプロジェクト期間中は見えるところに貼っておき、何か変更があれば随時更新していく。 詳細はの著者であるジョナサンのサイトのThe Agile Inception Deckを見て欲しい。 公開されているインセプションデッキのテンプレートを日語化してみた。 以下からダウンロードできる。ライセンスはC

  • [Scrum]Scrumではコードレビューをどうやっているか? | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 よく一緒に議論したり大学行ってワークショップをしたりしている原田さんが、スクラムでのコードレビューについて書かれましたので、僕も過去数年コーチとして色々な現場に行った際のことや、自分で受託開発をスクラムでやった際のことを踏まえてスクラムにおけるコードレビューのやり方を書いてみます。 レビューのやり方早期から頻繁に僕自身は小規模で頻度の高いインクリメンタルなレビューを好んでいます。 かつて大きなSIerにいてウォーターフォール型の開発をしていた際に、パートナーさんから出てきたソースコードを見ると、コピーペーストの嵐だったり、変数名がデタラメすぎたり、インデントがぐちゃぐちゃだったり(以下思いつく全ての「えーーー」を適当に想像してください)して、かつ工程の後半にレビューしていたので、直すに直せないというような悲惨なことも経験しました。 (注)ウォーター

    [Scrum]Scrumではコードレビューをどうやっているか? | Ryuzee.com
  • vagrant-lxcで軽量仮想環境を手に入れる

    Vagrantは標準ではVirtualBoxを仮想環境として利用しますが、とにかく遅いのが難点です。 Test-Kitchenを使ってChefのCookbookのテストをしたり、これらを継続的インテグレーションしようとしたときにこの遅さはたまりません。いくつか手段はあってお金持ちの皆様であれば、大富豪アプローチということで、仮想マシンを動かす母艦にXeon E5-2697 v2を積んだ高性能マシンを使ったりもできるのですが、普通に考えれば、VirtualBoxよりも軽量な仮想環境を使うのが有力なアプローチです。 今回はLXCを使って軽量な仮想環境を手に入れる方法を紹介します。 LXCのインストールLXC自体の説明はこの辺とかこの辺を参照ください。 インストール対象の母艦はUbuntu 12.04 LTSです。 sudo apt-get install lxc sudoの設定変更sudoのバ

    vagrant-lxcで軽量仮想環境を手に入れる
  • 【資料公開】ワンクリックデプロイ勉強会

    2011年12月20日に品川の日マイクロソフト社をお借りして、ワンクリックデプロイ勉強会を開催しました。 当初内輪でやろうと思っていたのですが多くの方にご参加いただきありがとうございました。 また、もろもろセッティング頂いた@katzchangと日マイクロソフトの長沢さんありがとうございました。 以下にセッション資料を公開します。 例によって短文での感想を。 セッション開始前にちゃんとRed Bullを飲んでおいたので元気だった最初の会場へのヒアリングで既にワンクリックデプロイをしている人がいるか調査したところいなかった。まぁWebサービス系でやっているところは増えては来ているもののまだ定着フェーズではなさそうな感じユニットテストやJenkinsはかなりの現場で使われている個人的な今日の名言は、「障害発生時に1日でリリースできるなら、普段のリリースも1日にできるはずだ」というやつ。物

    【資料公開】ワンクリックデプロイ勉強会
  • 【書評】手動デプロイからの卒業指南書「継続的デリバリー」

    継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化著者/訳者:David Farley、Jez Humble、和智 右桂、高木 正弘出版社:KADOKAWA/アスキー・メディアワークス発売日:2012-03-14大型:544ページISBN-13:9784048707879ASIN:4048707876 レビューに参加させていただいた縁でアスキー・メディアワークス社様より献いただきました。和智さん、高木さんの黄金コンビによる翻訳です。 デプロイ自動化に関する話を網羅的に扱ったはこれがはじめてでしょう。 上級技術者向けと書かれているように内容は結構ハイレベルで、構成管理、CI、テスト戦略についての前提知識が求められるように思いますが、アジャイルプロジェクトの中で日々改善を繰り返している人たちにとっては理解しやすいのではないかと思います。 デプ

    【書評】手動デプロイからの卒業指南書「継続的デリバリー」
  • 5分で分かるデプロイ自動化への道

    12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値(接続先データベース情報など)が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、番環境用などに分けて定義し、容易に切り替え可能にする番環境に配置する際に、アプリケーションの各所を書き換えなけれ

    5分で分かるデプロイ自動化への道
    maangie
    maangie 2012/07/11
  • ウォーターフォールの方が楽ですか?

    (顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市

    ウォーターフォールの方が楽ですか?
  • 1