開発環境のためのDocker再入門 - ひげろぐ
色々と開発環境を整理したくて3年くらい前に触ってみたきりだったDockerに再入門。 既存のVagrantで構築していた開発環境、vm.boxで指定しているイメージがダウンロードできなくなっていたり、Chefでプロビジョニングしていたところが動かなくなっていたので、直すより新しく作り直した方が早いかなと言うのがきっかけ。 前に試したときはDocker Compose的なものがなく（見つけられなかっただけかもしれないけど）、公式のコンテナも少なかったので、まだ本格的に使うには色々辛みがあるなと結論づけてそっとじしたのだった。 以下つらつらとメモ。 VagrantとDockerの使い分けについて 開発環境として定番のVagrantとの使い分けについては以下のページが簡潔でよくまとまっていて参考になる。 個人開発環境をvagrantで建てるべきか、dockerで建てるべきか 個人的には何かサーバ
TDDの基本テクニック - ひげろぐ
TDDBC 福岡2のデモより。 なおこれらのテクニックについては以下のURLが大いに参考になる。写経おすすめ。 RSpec の入門とその一歩先へ – t-wadaの日記 アサートファースト ゴールから書き始める。 プロダクトコードを実装しないでテストコードのアサーションを書き、それを実行してRedを出す。 これによってテストが失敗したときにきちんとRedになることを確認する。 仮実装 最短の実装でテストをGreenにする。 例えばFizzBuzzで「3と5以外の数字を受け取ったらその数字をそのまま返す」というテストで以下のようなアサーションを書いた場合 fizzbuzz("2").should == "2" 仮実装は以下のようになる。 def fizzbuzz(input) 2 end なんという茶番。 しかしこの仮実装によってRedからGreenになることを確認することでテストが確実に動
TDDの基本的な考え方について - ひげろぐ
今日はTDDBC 福岡2の講演を聴きながら取ったメモを転載。 TDDとは何か、なぜTDDするのか、どのようにTDDを進めていくのか。 テストは目的ではなく手段であり、真の目的は「健康」。 TDDはスキルだから誰でも習得可能。 といったことが凝縮されている。 TDDとは まず動くコードを書いてそれをきれいにしていくのがTDD。 きれいだけど動かない設計より汚くても動くコードを書いて、それを徐々にきれいにしていく。 ソフトウェア開発においては、まずコードを書いて動かしてみないと分からないことが多すぎる。 なのでコードを書き始める前に設計に力を尽くしても無駄になる部分が多い。 完璧な設計をしてからコードを書き始めようという「完璧主義の呪い」 （一方で設計しなさすぎも死ぬけど） TDDのサイクル 1. テストを書き 2. そのテストを実行して失敗させ (Red) 3. 目的のコードを書き 4. 1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
