テストエンジニアの面接の際にするとよい20の質問
みなさんこんにちは。@ryuzeeです。 DZoneという海外のサイトで “The 20 Best Software Tester Interview Questions” (テストエンジニアの採用面接の際にすると良い20個の質問)がまとまっていたので紹介します。 ここにあがっている質問を必ずすべきかという話ではありませんし、完全な網羅性があるわけでもありません(カバレッジの話やブラックボックス・ホワイトボックスの話のような基礎的な質問も入っていないです)。 一方で、ある程度の規模になった組織においては、採用面接の質を向上させるために自分たちの組織で共通の質問集のようなものを用意しておくのはベストプラクティスの1つと言えます。 もちろん一度作ったらそれで終わりではなく、新しい質問を追加したり、いろいろな候補者から期待と違う回答があった場合には質問自体を見直すといったことも必要になってきます
発売のお知らせ：アジャイルコーチの道具箱 - 見える化の実例集
こんにちは。@ryuzeeです。 既にご存知の方も多いと思いますが、昨日4月13日に新刊の「アジャイルコーチの道具箱 - 見える化の実例集」(Jimmy Janlén著、原田騎郎・吉羽龍太郎・川口恭伸・高江洲睦・佐藤竜也訳)が発売になりましたのでお知らせです。なお、こちらの書籍はLeanpubでの電子書籍(PDF)形式のみでの販売です。 本書の内容と特徴は以下のとおりです。 本書は、仕事の見える化を進める際に役立つ方法を図と説明つきで96パターン紹介する書籍です。全体で124ページで、各パターンを1ページあたり1つずつ紹介しています。通読するというよりはパラパラと見ながら気になるパターンを探すとよいと思います「見えないものは改善できない」というのがカンバンなどの見える化に共通する基本的な考えです。そして見えるようにした後の課題として、どうやってもっと分かりやすくするか、どうやって毎日維持す
物理カンバンの写真10枚（＋勝手レビュー）
みなさんこんにちは。@ryuzeeです。 他の会社やチームで使っているカンバンを見れる機会はそう多くはないのではないでしょうか？ そこでFlickrでCreative Commonsライセンスで投稿されているカンバンの写真のうち、役立ちそうなものを10枚紹介します。 それぞれ写真に対して、写真から読み取れる良い点や改善点をコメントとしてつけましたので、自分のカンバンを改善する役にもたつと思います。 その1https://www.flickr.com/photos/drewm/369319379/こんなにたくさんの項目が貼られると制御しきれないので、タイムボックス等を導入して、定期的にクリアするレーンは線で区切った方が良い付箋が反り返っている。正しい剥がし方をしていないかも付箋の色の違いに意味をつけるその2https://www.flickr.com/photos/dinomite/3219
【我流】プレゼンテーション資料の作り方
全国100万人のブリよりワラサ好きのみなさんこんにちは。先日強いチームの作り方を公開したのですが、何人かの知り合いからこういうスライドの作り方教えてほしい、というリクエストを受けたので以下にダンプしておきます。 参考書籍以下にあげる本は一度読んでおいて損はないです。プレゼンテーションZenは、ピアソンが技術書の取り扱いやめてしまい絶版かと思ったけど第二版が出て何より。 ガー・レイノルズ シンプルプレゼンプレゼンテーションZEN 第2版プレゼンテーションZENデザインこれらの本の中でも出てきますが、「プレゼンテーション」と「ドキュメント」は明確に分けた方がいい。 よく会社で経営方針とか数字とかをパワーポイントで作って配りますが、単にデータや説明を見せるならそれこそワードでやった方が読みやすいしコンパクトです。 トヨタがA3用紙1枚でまとめる(最近そうでもないらしいですが)と聞きますが、それと
マイクロサービスに関する資料のまとめ
世の中マイクロサービス・マイクロサービスうるさいのでちょっとこれ読んでおけという資料をまとめておきます。 はっきり言ってマイクロサービス化しようとすると、組織構造の話、エンジニアの責務の話など技術的な課題以外の領域にもいろんなチャレンジがあるので、普通のプロジェクトでも苦労する組織が取り組むとか、設計だけして開発を委託しているけどDB一極化がやばいので取り組むとかは止めておいた方がよいと思います。 概念Twelve Factor Appマイクロサービスの話ではないが、モダンなアプリケーションを作りたければ開発チーム全員に叩き込んでおくべき内容MicroservicesMartin Fowlerによるマイクロサービスの解説。2014年5月に公開Martin Fowlerのブログは翻訳が可能で、日本語訳を公開してくれている人がいる。こちら単純に言えば、「マイクロサービスとは単一のアプリケーショ
アジャイルトピックカード
Jimmy Janlé氏が書かれた“Agile Topics card deck”という記事が面白かったのでご紹介。 端的にいえば、アジャイルに関連するものをカード化して現場で活用してみるという内容です。 議論やアイデア出しのときに絵の入ったカードを使うというのは開発に限らず一般的なテクニックです。人はそれぞれ知識や思考方法に差があったり、議論の内容ややり方を自分の居心地のよい場所に収束させてしまう傾向にあるためマンネリ化しやすかったりもしますが、ちょっとしたツールのサポートがあればそれを多少防ぐこともできます。 たとえば、智慧カード、ブレスター、アイデアトランプなんかはその分野のものになります。 自分も過去にAgile Buffet Cardというのを作ってみました。こういうのがあると新しいアイデアが浮かんだりもしますし、見ているだけでも楽しいと思います。 以下参考和訳です。詳細は“Ag
vagrant-lxc用のCentOS Boxを自作する方法
前回の内容(vagrant-lxcで軽量仮想環境を手に入れる)の続きです。 VagrantではあらかじめBoxと呼ばれる仮想マシンの雛形を用意しておいて、起動時にそれを複製して環境を用意します。したがってLXCとVagrantを組み合わせた場合でも当然のことながらBoxが必要となります。前回の記事ではBoxは公開されているものを使いましたが、今回はBoxを自分で作成する方法を説明します。なお、Boxの作成方法はvagrant-lxcの配布物に含まれているubuntuなどのBox作成のスクリプトをかなり参考にしています。 事前準備：LXCでCentOSを利用できるようにするvagrant-lxcで利用するBoxの作成では、LXCで先に元となるOSの環境を作成できるようにする必要があります(なのでLXCを母艦にインストールしてください。必然的に環境はUbuntu系のディストリビューションに限ら
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 (+Amazon EC2)
著作 SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人 永瀬美穂 吉羽龍太郎 出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる
ChefのCookbookのベストプラクティス
OpsCode社のシニアコンサルタントであるJulianさんがChefConf2013で話された内容が参考になるので、簡単に紹介します。 スライドはこちらに公開されています。 また動画はこちらです。 ここで出てこない話として僕がやるべきだと思うことは「テストを書くこと」です。 test-kitchenとserverspecの組み合わせがおすすめです。 ばかでかいレポジトリをつくらないいろいろなものをまぜこぜにしない たくさんのレポジトリに分割するのを怖がらない (opscodeも昨年opscode/cookbooksの巨大構成から、opscode-cookbooks/個別cookbookに構成を変えています) 個々のCookbookの連携はBerkshelf使えば大丈夫 全員が共用するような会社用Cookbookをつくらない関係ないプロジェクトのものが含まれると見通しが悪くなる 大きすぎる
5分で分かった気になるDevOps
最近あっちゃこっちゃでDevOpsという単語を聞きますが、概念的な言葉でスコープが広いので簡単に整理しておくことにします。 これで5分くらいで分かった気になるかもしれません。 2009年にFlickrの人が発表した概念 http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 概念なので、実装は個々の現場によって異なる。アジャイル開発とアジャイル開発方法論の関係のようなもの。 従来型の考え方による利害対立 Devは多くの機能を早く届けなければならない すばやい変化 Opsは安定した運用を行いトラブルを起こさないようにしなければならない 変化を避けたい それじゃビジネスに勝てない DevOpsとはDevとOpsが協力しながら、ビジネスのために継続的に成果を出す、もしくは変化に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】The Basics of DevOps
TracをXML_RPC経由で操作する(基本編) | Ryuzee.com