タグ

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

  • 【資料公開】カイゼンの基本

    みなさんこんにちは。@ryuzeeです。 2016年9月16日に行われたDevelopers Summit 関西で表題のテーマで登壇してきましたので資料を公開します。 カイゼンについては1日のトレーニングコース(バリューストリームマップ作成含む)を[@haradakiro](https://twitter.com/haradakiro)と提供していますのでご興味のある方は[ご連絡](https://www.ryuzee.com/contact.php)ください。

    【資料公開】カイゼンの基本
  • Dashingで簡単にダッシュボードを作る方法

    全国1億2000万人のImmutable Infrastructure好きの皆様こんばんは。 去年あたりに色々な場所で紹介されたりして知っている人が多いと思うのですが、簡単に自分用にダッシュボードを作れるDashingが結構使いやすいので改めて紹介しておきます。APIを用意しているミドルウェアやシステムであれば簡単にデータを引っ張ってきてゴニョゴニョできます。 Dashingとはhttp://shopify.github.io/dashing/で公開されているSinatraベースで作られたダッシュボード作成用のフレームワーク。 非常に見た目の良いダッシュボードが作れます。デモは、こちらで公開されています。 ウィジェット型のアーキテクチャーのため、色々なダッシュボード用のパーツを独立して作成し、自由に配置することができること、データを自動で更新できること等も特徴です。 インストールDashi

    Dashingで簡単にダッシュボードを作る方法
  • テストエンジニアの面接の際にするとよい20の質問

    みなさんこんにちは。@ryuzeeです。 DZoneという海外のサイトで “The 20 Best Software Tester Interview Questions” (テストエンジニアの採用面接の際にすると良い20個の質問)がまとまっていたので紹介します。 ここにあがっている質問を必ずすべきかという話ではありませんし、完全な網羅性があるわけでもありません(カバレッジの話やブラックボックス・ホワイトボックスの話のような基礎的な質問も入っていないです)。 一方で、ある程度の規模になった組織においては、採用面接の質を向上させるために自分たちの組織で共通の質問集のようなものを用意しておくのはベストプラクティスの1つと言えます。 もちろん一度作ったらそれで終わりではなく、新しい質問を追加したり、いろいろな候補者から期待と違う回答があった場合には質問自体を見直すといったことも必要になってきます

    テストエンジニアの面接の際にするとよい20の質問
  • 【資料公開】The Basics of DevOps

    2015年11月21日に楽天さんで行われたRakuten Technology Conferenceで「The Basics of DevOps」というテーマで話をしてきましたので、資料を公開します。 なお、楽天さんなので資料は英語です(ただし中学レベルの英語なので問題ないと思います!!)。 DevOpsというとすぐツールの話をしちゃう人が多いのですが、僕の考えるDevOpsはツールの話だけではありません。 何度も言っていますが、DevOpsの土台になるのはCultureだと思っています。 こちらからもスライドにアクセスできます。

    【資料公開】The Basics of DevOps
    shoma
    shoma 2015/11/23
  • 技術的負債にどのように取り組むか

    みなさんこんにちは。@ryuzeeです。 定期的にSlideshareをウロウロして良い資料がないかを探しているのですが、技術的負債に関する分かりやすい資料があったのでご紹介します。 技術的負債とは、現在の進捗のために、将来のキャパシティ(ソフトウェアの開発能力)を犠牲にすることであるもうちょっと具体的に言えば、技術的負債とは、ソフトウェアの内部的な問題(見つかっているか見つかっていないかは関係はない)、要求の明確化の欠如、ダメな設計、ビジネスの要求に適していない設計、自動化できるはずの箇所の手動処理などを指す**利子の支払いは時間のムダである。**例えば欠陥を直すのに時間を取られる、要求が明確になった後に再度作りなおす、複雑なコードを理解するために余計な時間を取られる、などなど技術的負債の悲惨なサイクルがあるテストを書く時間がない、リファクタリングする時間がない、設計レビューする時間がな

    技術的負債にどのように取り組むか
    shoma
    shoma 2012/04/25
  • 大きなリリースの際にチェックすべき34のこと

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

    大きなリリースの際にチェックすべき34のこと
    shoma
    shoma 2012/02/03
  • 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のアンチパターンとベストプラクティス
  • 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)する方法
    shoma
    shoma 2011/02/21
    phpunit 経由なので --log-junit すれば Jenkins様 にお願いできそう
  • 1