先日、月間オブラブ創刊号が発行されました!
2011年、オブジェクト倶楽部はオブラブへと名前を変え、メルマガを月刊にし、記事をブログへと、大きく形を変えましたが、今後ともよろしくお願いします!
また、初春オブラブミニミニイベント「ペアプロワークショップ」もまだ席に余裕があるようなので、是非是非ご参加ください!
オブラブ: http://objectclub.jp/
オブログ: http://oblog.objectclub.jp/
2011/01/13
2011/01/04
書き初め
うちの事業部の毎年恒例の書き初め。今年の一字は「笑」にしました。
今年一年、笑って終われるように、自分のやれることを精一杯やっていきたいという思いで、この字にしました。
また、htkymtks_ugの活動を通して、世界にほんの少しの笑い(と失笑)を届けられればと考えています。
これは別に冗談ではなく、プログラムを書いてお金をもらっている以上、技術的卓越を追求したいと思うもの。そのためには壊していいオモチャはいつも手元に置いておかなければなりません。その一つが、htkymtks_ugで使っているいくつかのツールです。なので、ユーザ会の半分は本気と書いてマジでできているのです。(もう半分はちくわです)
気づけば今年で29になります。20台最後の一年に相応しい一年にしたいものです。
今年一年、笑って終われるように、自分のやれることを精一杯やっていきたいという思いで、この字にしました。
また、htkymtks_ugの活動を通して、世界にほんの少しの笑い(と失笑)を届けられればと考えています。
これは別に冗談ではなく、プログラムを書いてお金をもらっている以上、技術的卓越を追求したいと思うもの。そのためには壊していいオモチャはいつも手元に置いておかなければなりません。その一つが、htkymtks_ugで使っているいくつかのツールです。なので、ユーザ会の半分は本気と書いてマジでできているのです。(もう半分はちくわです)
気づけば今年で29になります。20台最後の一年に相応しい一年にしたいものです。
2011/01/01
2010/12/06
RSpecにおけるdescribe/contextとTDD(未完)
タイトルはいまいちですが、今の私のWeb日記力ではこれが限界。
この記事は、オチも結論もありません。私(と@ursm)がRSpecでテスト駆動開発をする上で感じている違和感をとりあえず読める形にしただけです。
まずは次の2つのテストを見てください。
次に、Railsのコントローラのテストを考えてみましょう。
しかし、ある程度開発が進んでくると、今度は既存の機能にコンテキストが追加されるようになってきます。(例えば、最初はロールが「教員」「学生」だけだったのが、途中で「ゲスト」が増えるなど)そうすると、今度はdescribe単位ではなく、context単位でテストを追加したくなります。しかし、それまでのテストはすべてdescribeを上位に書いているので、急にcontextを上位にするわけにもいきません。(モヤモヤ)
最初に書いたように、これに明確な答えがあるわけではありませんし、「こうしたほうがいいのかもしれない」という程度の意見もありません。ただ、今こういうモヤモヤがあって、もしかしたら数ヶ月後、数年後になんらかの答えを見つけられたなら、それが私達の成長の証であることを再確認できるようにここに残しておきます。
===ここから追記===
2010/12/17 Arrayの例でcontextとdescribeが同じ順番になってしまっていたのを修正しました。
この記事は、オチも結論もありません。私(と@ursm)がRSpecでテスト駆動開発をする上で感じている違和感をとりあえず読める形にしただけです。
まずは次の2つのテストを見てください。
describe Array do
describe '#empty?' do
context 'just initialized' do
subject { Array.new }
it { should be_empty }
end
end
end
describe Array do
subject { @array }
context 'just initialized' do
before do
@array = Array.new
end
describe '#empty?' do
it { should be_empty }
end
end
end
テストしている内容(itの中)はどちらも同じです。両者で違うのは(ほぼ)describeとcontextの順番だけです。次に、Railsのコントローラのテストを考えてみましょう。
describe 'HogeController' do
describe 'GET index' do
context 'login as Teacher' do
...
end
context 'login as Student' do
...
end
end
end
これも同じように、describeとcontextを逆転させると次のようにも書けます。
describe 'HogeController' do
context 'login as Teacher' do
describe 'GET index' do
...
end
end
context 'login as Student' do
describe 'GET index' do
...
end
end
end
ただ、少なくとも普段は下のような書きかたはしません。それは、これから作るのがメソッド(アクション)であり、そのメソッドを検証する観点としてコンテキストがあるからです。しかし、ある程度開発が進んでくると、今度は既存の機能にコンテキストが追加されるようになってきます。(例えば、最初はロールが「教員」「学生」だけだったのが、途中で「ゲスト」が増えるなど)そうすると、今度はdescribe単位ではなく、context単位でテストを追加したくなります。しかし、それまでのテストはすべてdescribeを上位に書いているので、急にcontextを上位にするわけにもいきません。(モヤモヤ)
最初に書いたように、これに明確な答えがあるわけではありませんし、「こうしたほうがいいのかもしれない」という程度の意見もありません。ただ、今こういうモヤモヤがあって、もしかしたら数ヶ月後、数年後になんらかの答えを見つけられたなら、それが私達の成長の証であることを再確認できるようにここに残しておきます。
===ここから追記===
2010/12/17 Arrayの例でcontextとdescribeが同じ順番になってしまっていたのを修正しました。
2010/11/09
読了「JavaScript: The Good Parts」「Release It! 」
「JavaScript: The Good Parts」は4章の「関数」と付録は必読な感じでした。
大体の場合、何らかのフレームワークを使うはずなので、この本で書かれていることが必要になる場面はそんなに多くないように思います。とはいえ、私のようなJavaScriptアレルギー患者には、よくイライラするところがしっかり説明(弁解)されているので、アレルギー治療にはよく効きそうです。
「Release It!」はよい本ですね。
非常に実践的なノウハウがつまっていて、しかもそれは大規模システムを開発・運用しないとわからないような事ばかりでした。
私の普段の仕事で使えるかというと、ちょっとオーバースペックかなと思いますが、ソフトウェアをリリースして運用することに対しての心構えと、問題が発生したときのアタリの付け方などは非常に参考になりました。
大体の場合、何らかのフレームワークを使うはずなので、この本で書かれていることが必要になる場面はそんなに多くないように思います。とはいえ、私のようなJavaScriptアレルギー患者には、よくイライラするところがしっかり説明(弁解)されているので、アレルギー治療にはよく効きそうです。
「Release It!」はよい本ですね。
非常に実践的なノウハウがつまっていて、しかもそれは大規模システムを開発・運用しないとわからないような事ばかりでした。
私の普段の仕事で使えるかというと、ちょっとオーバースペックかなと思いますが、ソフトウェアをリリースして運用することに対しての心構えと、問題が発生したときのアタリの付け方などは非常に参考になりました。
2010/10/21
DNSをVALUE-DOMAINからZerigoにしました
Zerigoはipv6対応のVPS+DNSサービスです。
VPSとDNSは別のサービスになっているようで、それぞれ独立して使えます。
ZerigoのDNSサービスが優れているポイントとしては、以下のようなものがあります。
VALUE-DOMAINからの移行は次のようにやりました。
VPSとDNSは別のサービスになっているようで、それぞれ独立して使えます。
ZerigoのDNSサービスが優れているポイントとしては、以下のようなものがあります。
- IPv6対応
- REST API
- TTLが1分〜
- AAAA、SRVレコードに対応
VALUE-DOMAINからの移行は次のようにやりました。
- VALUE-DOMAINに登録しているレコードの情報を全部Zerigoに移す
- VALUE-DOMAINの「ネームサーバー変更」で「他社提供/自前のネームサーバー」を選択する
- ネームサーバとして「(a..e).ns.zerigo.net」を設定する(Zerigoの「nameservers」で確認できます)
- dig #{domain} NS をたまにやりながら待つ(Zerigoの「Tools」でも代用できます)
2010/10/12
社内勉強会「60分一本勝負」を始めました
※この記事は、10/04に書きたかった記事です。
空前の勉強会ブームも少し落ち着いてきたように見える中、社内勉強会「60分一本勝負」を始めました。
この勉強会のルールは2つだけです。
こんなゆるい勉強会が成り立つのか不安になってしまうような感じです。
とはいえ、興味はあるけど1人だと手を出しにくいようなテーマもあるわけで、そんなときに仲間とチュートリアルの写経でもできたら心強いと思いませんか?
そんなゆるゆる勉強会の初戦の相手は、node.jsでした。
都合のよいことに、勉強会の数日前にたまたま@ursmによるnode.jsを試してみたが公開されましたので、これを写経することにしました。
しかし、なんと当日にnpmのリポジトリが落ちるというアクシデントが。
おかげで全員が写経を終えることができませんでしたが、その変わりにnodeがパッケージを探索する仕組みがわかったりして、ほんの少しだけお得な勉強会だった気もします。
社内で勉強会をやろうとしても、準備が大変だったり、みんなの時間が合わなかったりして出来ないでいる方は、こんなスタイルで始めてみては如何でしょうか。
60分一本勝負初戦の結果
|ESM|npmの乱入により無効試合|node.js|
空前の勉強会ブームも少し落ち着いてきたように見える中、社内勉強会「60分一本勝負」を始めました。
この勉強会のルールは2つだけです。
- 制限時間は60分
- 勉強会のために資料は作りません
こんなゆるい勉強会が成り立つのか不安になってしまうような感じです。
とはいえ、興味はあるけど1人だと手を出しにくいようなテーマもあるわけで、そんなときに仲間とチュートリアルの写経でもできたら心強いと思いませんか?
そんなゆるゆる勉強会の初戦の相手は、node.jsでした。
都合のよいことに、勉強会の数日前にたまたま@ursmによるnode.jsを試してみたが公開されましたので、これを写経することにしました。
しかし、なんと当日にnpmのリポジトリが落ちるというアクシデントが。
おかげで全員が写経を終えることができませんでしたが、その変わりにnodeがパッケージを探索する仕組みがわかったりして、ほんの少しだけお得な勉強会だった気もします。
社内で勉強会をやろうとしても、準備が大変だったり、みんなの時間が合わなかったりして出来ないでいる方は、こんなスタイルで始めてみては如何でしょうか。
60分一本勝負初戦の結果
|ESM|npmの乱入により無効試合|node.js|
登録:
投稿 (Atom)
