ライブラリの動作を学習するためにテストを書く - ひげろぐ
TDDのパターンに学習用テストというものがあると『テスト駆動開発入門』に載っていた。 自分が作ったものではない外部のライブラリを使い始めるときに、動作を確認するために小さなコードを書く、ということは誰でもしていることだと思うが、その動作確認のためのコードをテストとして書く。 それによりライブラリのAPIに対する理解をコードに落とし込んで残しておけるので、曖昧な理解が減りそう。 正しい理解ができていればテストはパスする。 またライブラリのバグなのか、自分の使い方が悪いのか切り分けるのにも使えそうだ。 そういう原因がよく分からない状況になってしまったらテストを追加して追い込んでいけば良い。 また副産物として、ライブラリがアップデートされたときにその影響をテストするのにも使うことができる。 試しにamazon-ecsで学習用のテストを書いてみた。 # -*- coding: utf-8 -*-
Capistranoとchef-soloを組み合わせて使う - ひげろぐ
たくさんのホストをChef設定したいけどChefサーバー立てるのめんどくさいし！ でもコマンド一発ですべてのホストが更新されて欲しいし！ というわけでこの組み合わせです。 Capistranoはインストール済みでsshのログインに必要な鍵も各ホストに配ってあるものとする。 加えてChefのクックブックなどはすでに定義済みで以下のパスにある前提で。 /home/akahige/chef-repo Chefに関してはここでは深くつっこまないので、よかったら以前書いたものをどうぞ。 chef-soloで作業環境構築の自動化 | ひげろぐ Chefを試してみた | ひげろぐ sudoの設定 chef-soloはsudo経由（root権限）で実行する必要がある。 そしてCapistranoでsudoを実行するにはパスワードなしでコマンドを実行できる必要がある。 そういう事情なのですべてのホストにてs
テストコードを書くコストに関する考察 - ひげろぐ
昨年お世話になっていた職場の仕事仲間と先月ランチする機会があった。 自分の関わっていたプロジェクトはペアプロやTDDを実践していたのだが、残念なことに自分が抜けた後はテストコードを書かなくなってしまったという。 理由を聞くと「テストコードを書くより、動くプロダクトコードをどんどん書きたい」ということだった。 これは心情的にはよくわかる。 納期のプレッシャーが強く、TDDに慣れていない状況では特にそうだ。 要は「テストを書いてる暇なんかない」と判断してしまうわけだ。 TDDの最初の躓きのひとつとして、テストコードを書く手間が増えただけのように感じられるというものがあると思う。 実際に手間は増えている。 しかし適切なテストの書き方がよくわからないため、余分な手間をかけすぎているということもあるだろう。 例えばゲッターやセッターのテストを逐一書いてしまう。 これは実際に無駄なことであるから、この
Titanium Mobileを二ヶ月くらいさわってみた感想。 - ひげろぐ
今年に入ってからほぼ毎日触ってました。でもほとんどiPhone開発しかしてない感想。 主観的なところをだらだらと書いてみましょう。 とりあえず気に入っているところイマイチと思うところを挙げてみたい。 合わせて総評など。 気に入っているところ さくさく開発できる Objective-Cとは段違いの開発効率。 冗長なメソッド名とメモリ管理の煩わしさからの解放がうれしい。 ちょっとしたモックアップ程度ならさくっと作れてしまう。 そこから開発者が作り込みに注力できる環境が見事にできあがっているのではないかと。 JavaScriptはくせもあるけどおおむね使いやすい言語。 CoffeeScriptとの組み合わせでさらにいいかんじ。 TDDできる Jasmineで気持ちよくTDD出来ている点が非常にポイント高い。 おかげでTitaniumラブですよ。 Objective-CでもTDD可能だけど、OCU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
