Conference With Developers 2 を開催します
2月1日にConference With Developers 2というイベントを開催します。
昨年に引き続き今回は、
- ninjinkun http://ninjinkun.hatenablog.com/
- fladdict http://fladdict.net/blog/
- 岸川克己 http://d.hatena.ne.jp/KishikawaKatsumi/
- ishkawa http://blog.ishkawa.org/
という、iOS界で今をときめく/不動の大御所な皆様にお話しいただきます。
LTも募集中ですのでぜひご参加ください
そして老害になる
闇 Advent Calendar 2013の7日目として老害化の話をします。
ベンチャーじゃなく大企業につとめてよかったことは、さまざまな技術バックグラウンドを持つ人と仕事ができていることだ。
色々な流儀や文化の人たちと接し、ぶつかることで自分の視野がどんどん広がっていくのを感じている。
昔話をすると、学生時代、自分は主にRubyを書いていてJavaやPHPをダサいものだと考え、時にはそれを口にすることもあった。
しかしdisるための根拠などをしっかりと持っていたわけではなく、なんとなくで
最新技術=かっこいい、べんり
古い技術=ださい、めんどくさい
と考えていた
社会人になってからダサいと思っていたまともなPHPの書き方を知りそれはそれで悪くない、むしろRubyよりすぐれだところもたくさんある素晴らしい道具と知った。
逆にcoolだと思っていたnode.jsやCoffeeScriptに手を焼き、PhoneGapのような技術で作られたプロダクトに苦しめられもした。
それらをiOSネイティブに書き換えていく作業をするなかで見た目だけで敬遠していたObjective-Cの思想が大好きになったりもした。
DB設計の正しいやり方を身につけ、それまでに自分がActiveRecordのmigrationで適当につくったものがいかにひどいものだったかも知った。
経験を積めば積むほど、今まで自分がバカにしていたものがいかに優れているかがわかるようになったし、逆に今まで無条件で最高だと考えていた技術の欠点も見えてきて、新しい技術が単に新しくてcoolそうだというだけで飛びついたりすることは減ってきた。
エンジニアは気付けば新しくて楽そうなものに流れる傾向がある。
しかし、最高のまともなエンジニアになるためには新しいもの、古いもの、有名なもの、無名なものをイーブンに評価できるようになるべきでなのではないだろうか。
そう考えもあり、最近はC++をずっと勉強していて楽しい。Javaも深く知りたい。他にも知りたいことがたくさんある。
しかし、そういうことをやっているとどんどん周囲と考えが離れていくのを感じる。技術の話をしても噛み合わないことが増えてきているような気がする。
Rubyやnode.jsかじったやつが使ったこともないのにPHPやJavaを叩いてるのを見るとぶん殴りたくなる。
RDBの大した知識もないのに「MySQLはめんどうそうなので、MongoDBを使おう」などと提案されると軽蔑してしまうしそいつとは仕事したくない。
このままいくと将来こんなことを言ってしまうかもしれない
「プロダクションでnode.js使うの?いいけど何か問題が起きたとき対応できるの?nodeのソースコードすら追えないじゃ困るじゃん。C++も読めないのに偉そうなこと言うなよ」
そして老害になる
iOSの隠しフォント,ヒラギノ角ゴW1を使ったアプリが審査通った件
意識高いiOSアプリのつくり方
なんとなくRSpec使ってるやつダサい
先日、第5回若手Webエンジニア交流会でLTしてきました。
ビール飲んでピザつまみながらLTきいたりLTしたりするのカジュアルでいいですね。
というわけで、スライド公開します。
Testing Frameworkについてで、
「なんとなく、とりあえず、RSpec」みたいなのはダサいよねというお話
スライドの原稿
テストとかの話 矢口裕也 (@yayugu) 「みんなー テスト書いてる?」 みたいなの飽きたよね 今日は TDDとBDDとAgileとかの開発スタイル と テスト哲学の話を しません Testing Framework の話をします Testing Framework 大きく分けて2つ xUnit xSpec xUnit class TestInteger < UnitTest def test_add assert_equal(2, 1 + 1) end end xSpec describe Integer context 'when add 2 numbers' do it 'should return sum' do 2.should eq(1 + 1) expect(2).to eq(1 + 1) end end end ここで質問 どっちが好き? xUnit xSpec ほうほう なんで? 自分がなぜ そのテストフレームワークを 好きか 答えられる? みんなに言いたい 自分が使う ツールのことを もっと良く知ろう フレームワークは よく考えて ちゃんと選ぼう 自分の話 さいきんRubyだと minitest使ってる iOSだと SenTestingKit 何を考えて これらを選んだのか xUnit xSpec この2つを比較 ※思想とかは考えない 比較方法 機能でそれぞれ2つの パーツに分類してから比較 xUnit - test class class TestHoge, def test_hoge - assertion assert_equalとか xSpec - behavior describe, context, it - expectation should, expect (1)機能の違い (2)表記の違い (3)実装の違い (1)機能の違い assertionとexpectation →同じもの test classとbehavior →振る舞いの階層化ができるか (2)表記の違い assertionと expectationに ついてのみ比較 参考フレームワーク: Ruby - minitest - RSpec Obj-C - SenTestingKit - Kiwi Ruby minitest assert_equal(2, 1 + 1) RSpec (should) (1 + 1).should eq(2) RSpec (expect) expect(1 + 1).to eq(2) assert_equal(2, 1 + 1) (1 + 1).should eq(2) expect(1 + 1).to eq(2) Obj-C SenTestingKit STAssertEquals(2, 1 + 1); Kiwi (should) [[foo should] equal:bar]; Kiwi (expect) [[theValue(1 + 1) should] equal:theValue(2)]; STAssertEquals(2, 1 + 1) [[foo should] equal:bar]; [[theValue(1 + 1) should] equal:theValue(2)]; 表記の簡潔さ assert > should > expect (3)実装の違い assert の実装 global or test classのインスタンスに assert関数を定義 class UnitTest def assert_equal(expect, actual) if (expect == actual) puts '.' else puts('F') end end end expectation の実装 2スタイルある - should - expect should の実装 RSpec BasicObject.module_eval do def should(...) ... end end BasicObjectに shouldを追加!!! voodoo感ある Kiwi @interface NSObject (...) - (void)should; ... @end NSObjectに カテゴリとして shouldを追加!!! voodoo感ある expect の実装 RSpec ::RSpec::Matchers.module_eval do def should(...) ... end end BasicObjectオブジェクトを 汚染しないため shouldよりmagic少ない toやeqの実装は 面倒そう Kiwi #define theValue(expr) \ ({ \ ... [KWValue valueWithBytes:... }) Kiwiも 同様 実装の健全さ assert > expect > should まとめ -test class, behaviorの機能差 階層化できるか -assert, expectの機能差 なし -表記の簡潔さ assert > should > expect -実装の健全さ assert > expect > should 使うべき Testing Framework A. 階層化が不要: test class + assertion → xUnit B. 必要: 階層構造 + assertion → minitest Test::More subtest など を使うべき サンプルコード describe Integer context 'when add 2 numbers' do it 'should return sum' do assert_equal(2, 1 + 1) end end end ここに書いたのは あくまで俺の考え 「なんとなく」 ではなくちゃんと考えて Testing Framework を選んで使おう Happy testing!