タグ

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

  • 開発をより良くしたい人が読んでおくべき10冊

    アジャイルな開発の導入支援の現場や色々な勉強会でよく「どんなを読んだら良いですか」と聞かれたりします。 何のためにを読んで勉強するかは人それぞれですし、自分のおかれたコンテキストでどのが役にたつかは分からないですが、以下にあげたは個人的に強くオススメできるです。人に聞くのも大事だし自分で試行錯誤するのも大事だけど、を読んで体系的に学んだり先人の知恵を学ぶことは続けたほうが良い。 プロダクティブ・プログラマ -プログラマのための生産性向上術どうやったら自分自身の生産性を高くすることができるのか。PCの使いこなしから始まり、自動化やバージョン管理等にも触れている プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)著者/訳者:Neal Ford、島田 浩二 (監訳)、夏目 大出版社:オライリージャパン発売日:2009-04-27単行

    開発をより良くしたい人が読んでおくべき10冊
    hidehish
    hidehish 2012/03/12
    見てる:
  • 大きなリリースの際にチェックすべき34のこと

    以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ

    大きなリリースの際にチェックすべき34のこと
    hidehish
    hidehish 2012/02/14
    見てる:
  • 【資料公開】チケット管理システム大決戦 第二弾

    みなさんこんにちは。@ryuzeeです。 2011年6月30日にShibuya.tracの第12回勉強会として、チケット管理システム大決戦第二弾を実施しました。 僕はモデレータ役として登壇させていただきました。普段講演者として発表する機会は多いのですが、モデレータは初体験でしたので段取りが悪かった点もあるかと思いますがご容赦ください。 以下に当日利用した資料を公開します。 手前味噌ですが、このレベルの内容が揃った資料はなかなか無いと思いますし、資料的価値もあると思いますので、参加された方もそうでない方も是非ご覧ください。 質問等がある場合は#shibutraタグをつけてつぶやいて頂ければと思います。(また各資料の左端に作成者のIDを記載しておきました) ご登壇頂いた池田さん、中村さん、山さん、大貫さん、関さん、藤原さん、原田さん、かぬさん、ご参加頂いた皆さん、事前準備に奔走してくださった

    【資料公開】チケット管理システム大決戦 第二弾
    hidehish
    hidehish 2011/07/04
    見てる:
  • Agile Scrumと組織(資料公開)

    著作 SCRUM BOOT CAMP THE BOOK 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎 出版社:翔泳社( 2013-02-13 ) 定価:¥ 2,520 スクラム初心者に向けて基的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者/訳者:渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社:インプレス( 2014-09-19 ) 定価:¥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説

    Agile Scrumと組織(資料公開)
    hidehish
    hidehish 2011/06/11
    見てる:
  • スクラムにおけるイベントと出席者

    みなさんこんにちは。@ryuzeeです。 スクラムにおけるイベントはスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブの4つがあります(スプリント自体もイベントですが他のイベントの入れ物なので除外しました)。 また責任としてはプロダクトオーナー、スクラムマスター、開発者、そしてそれ以外のステークホルダーに分けられます。 誰がどのイベントに出席するべきなのかについて、マトリクス化された資料が存在しなかったので、作成してみました。なお、イベントではありませんが、プロダクトバックログリファインメントを参考までに入れました 以下補足です。 プロダクトオーナーのデイリースクラムへの出席出席しません。 デイリースクラムでやるべきことは開発者がスプリントゴールを達成できそうか確認し、必要なら再計画のきっかけにすることです。 開発者がスプリントゴールの達成にリスクが

    スクラムにおけるイベントと出席者
    hidehish
    hidehish 2011/05/12
    見てる:
  • PHPUnitのアンチパターンとベストプラクティス

    みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたらPHPUnitのアンチパターン・ベストプラクティスに関する素晴らしいスライドを見つけたので内容を抜粋で紹介します。 1. テストの中で何もテストしていない class FooTest extends PHPUnit_Framework_TestCase { public function testSomething() { $foo = new Foo; $foo->doSomething(new Bar); } } こういうテスト。どこにもアサーションがなくて何もチェックしていません。 $foo->doSomethingの戻り値を検証しないならなんの意味もありません。 純粋にTDDをしていれば、テストコード作成→テスト実行でRed→プロダクションコード作成→テスト実行でGreenなのでこういうテストは登場しませ

    PHPUnitのアンチパターンとベストプラクティス
    hidehish
    hidehish 2011/05/07
    見てる:
  • より良いテスト駆動開発を行うためのチートシートの紹介

    みなさんこんにちは。@ryuzeeです。 planetgeek.chというサイトでUrs Enzler氏がTDDのチートシートを公開していたのでご紹介します。 Clean Code and Clean TDD Cheat Sheets (PDFファイルでダウンロード可能です) 以下で、チートシート内の一部を意訳にてご紹介しましょう。 Unit Test Smellsテストが何もテストしていない一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない テストに過度なテスト準備が必要とされるテストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが当にテストしたいのが何なのか?ということを分かりにくくする。 大きすぎるテスト有用だが大きすぎるテスト。たぶんテストが1つではなく複数の機能をチェックしているか、テストが1つ以上のことをやろう

    より良いテスト駆動開発を行うためのチートシートの紹介
    hidehish
    hidehish 2011/04/24
    見てる:
  • 「塹壕よりScrumとXP」その後とテスト自動化順序の決め方

    みなさんこんにちは。@ryuzeeです。 「塹壕よりScrumとXP」はHenrik Kniberg氏が書いた無料書籍で、日語を含めて13ヶ国語で読まれている最も有名なスクラムとXPに関する導入事例の1つです。 日語訳はInfoQの以下のページからダウンロード可能です。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches そのHenrik氏が、Agile Israele 2011で行ったキーノートが、非常に良いものなのでご紹介します。 資料は氏のサイトからダウンロードできます。 このスライドでは、Henrik氏がもし記事を書いた2006年に戻ったら今度は違うやり方をするであろう項目について説明しています。 項目は以下の15個です。 キューを制限するチーフプロダクトオーナーのロールを設けるバックログの項目はユーザースト

    「塹壕よりScrumとXP」その後とテスト自動化順序の決め方
    hidehish
    hidehish 2011/04/13
    見てる:
  • テスト自動化に関するスライドの紹介

    みなさんこんにちは。@ryuzeeです。 SlideShareでテスト自動化に関する良いスライドをみつけたのでご紹介します。 Agile Toolkit http://www.slideshare.net/nverdo/agile-toolkit-mo-conf 参考になる部分は以下の3スライドでしょう。順に説明していきます。 手動テストのコストプロジェクトの初期は以下のような状況です。 テストする項目は少ない手動でテストを完了するのも簡単まだプロダクションでもないし、問題があって影響を受けるのは限定された人だけしかし時間がたつにつれて 手動でのテストにはとても多くの時間がかかるようになる製品が出荷されてしまうと、バグによってとても多くの人が影響を受けることになってしまうという状況に変わっていきます。 右のグラフは手動でテストを行った場合のテスト時間の推移を示していますが、見て分かる通り、

    テスト自動化に関するスライドの紹介
    hidehish
    hidehish 2011/04/05
    見てる:
  • BehatとSeleniumを組み合わせ受け入れテストを自動化する

    みなさんこんにちは。@ryuzeeです。 Behatは良さそうなので引き続き検証しています。 今回は、BehatとSeleniumを組み合わせて、受け入れテスト型のテストを自動化してみたので、その方法について説明しましょう。 なお、前回の記事を読まれていない場合はまずそちらを参照してください。 PHPでBDD(Behavior Driven Development)する方法 Seleniumの課題僕が関わっている案件では受入テストを自動化しているケースももちろんあって、その際はPHPUnitとSeleniumを組み合わせています。 このテストには以下のような課題があります。 画面の操作をするphpコードが大量にあって、ソースを見ただけでは何をしているのか分かりにくいSeleniumは操作に画面の要素名利用するため、例えばサイトのデザインを大幅に変えたりすると、テストの中身も大幅に書き換えな

    BehatとSeleniumを組み合わせ受け入れテストを自動化する
    hidehish
    hidehish 2011/02/12
    見てる:
  • PHPでBDD(Behavior Driven Development)する方法

    みなさんこんにちは。@ryuzeeです。 RubyであればRSpecやCucumberとか使って、むしろBDDしているケースの方が多いようですが、PHPでやっている事例はあまり聞きません。 とりあえずPHPでもBDDできることは確認できたので、その方法をご紹介します。 ※実戦投入にはもうちょっと検証は必要かもしれません。 BDDとは?BDDとはビヘイビア駆動開発(Behavior Driven Development)でテスト駆動開発から派生したものです。 テスト駆動開発とドメイン駆動設計を統合したようなイメージになります。 対象における「振る舞い」や「制約条件」の検証のために、自然言語的な記述でテストコードを記述します。 スペックファーストで仕様を作ってから実装するという流れになります(コードを書く前に振る舞いを決める)。 ということで、以下ではPHPでBDDを行う方法について解説してい

    PHPでBDD(Behavior Driven Development)する方法
    hidehish
    hidehish 2011/02/11
    見てる:
  • 【資料公開】DevLOVE Test Dayでお話しました

    Ryutaro YOSHIBA / Agile Coach, CTO at Attractor Inc. 翻訳者/ Scrum Alliance認定スクラムトレーナー(CST) / 認定チームコーチ(CTC) /書籍→『SCRUM BOOT CAMP THE BOOK』『プロダクトマネージャーのしごと』『エンジニアリングマネージャーのしごと』『チームトポロジー』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』『Effective DevOps』他 ご相談はお気軽に!!

    【資料公開】DevLOVE Test Dayでお話しました
    hidehish
    hidehish 2011/01/28
    見てる:
  • CakePHPアプリをHudsonで継続的インテグレーションする方法

    この記事はCakePHP1.2系またら1.3系を対象としており、CakePHP2.0系では別のアプローチになります。 不思議なことにCakePHPアプリの開発でHudson使って継続的インテグレーションしている事例をほとんど見たことがないんだけど、個人的にはPHPアプリだって全部HudsonでCIすべきと思っているのでやってみた。 (ちなみに最近までphpUnderControlでCIしていた) 概略 CakePHPアプリでCIやろうとして問題になるのは、 CakePHPでのテストライブラリがSimpleTestでありJUnit互換のテスト結果を出力できないこと さらにSimpleTestでは一応XMLでの結果出力ができるのに、CakePHPreporterにcake_xml_reporterとかが無くて、html出力かテキスト出力しかできない という2点にあるので、この2点をクリアする

    CakePHPアプリをHudsonで継続的インテグレーションする方法
    hidehish
    hidehish 2010/10/23
    見てる:
  • テスト自動化について5分で分かるまとめ

    みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの1つであるこのプラクティスのみで1冊のが書けるくらい奥が深い基的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保

    テスト自動化について5分で分かるまとめ
    hidehish
    hidehish 2010/08/29
  • ドキュメントレビューをする際の10のポイント | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 重厚長大なドキュメントは、動かなかったり嘘が書いてあったり現実と異なっていたり、その上肝心なこと書いてなかったりということで辛いことが多いのが現状です。 今回とある筋からドキュメントをレビューする際のポイントを教えて欲しい、という依頼を受けたので書いてみます。 なお、個人的には、ドキュメントレビューよりソースレビューの方が重要だと思っています。 とはいえドキュメントレビューで肝心なのは、 ドキュメントレビューをするなら、その投資に見合う何を得るのか?を決めておく必要がある当にそのドキュメントは必要か?をよく考える(会社のルールだから!というのは理由にはなっていない)だと思います。 レビューのポイント1. 体裁をレビューするのではなく、中身をレビューするひどい現場だと、文書のインデントやフォントのサイズ、誤字脱字ばかりを重箱の隅をつつくようにチェッ

    ドキュメントレビューをする際の10のポイント | Ryuzee.com
    hidehish
    hidehish 2010/08/07
  • 【資料公開】アジャイルな開発プロセスを導入するために考えなければならないこと

    Ryutaro YOSHIBA / Agile Coach, CTO at Attractor Inc. 翻訳者/ Scrum Alliance認定スクラムトレーナー(CST) / 認定チームコーチ(CTC) /書籍→『SCRUM BOOT CAMP THE BOOK』『プロダクトマネージャーのしごと』『エンジニアリングマネージャーのしごと』『チームトポロジー』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』『Effective DevOps』他 ご相談はお気軽に!!

    【資料公開】アジャイルな開発プロセスを導入するために考えなければならないこと
    hidehish
    hidehish 2010/03/21
  • 1