Conference With Developers 2 を開催します

2月1日にConference With Developers 2というイベントを開催します。


昨年に引き続き今回は、

という、iOS界で今をときめく/不動の大御所な皆様にお話しいただきます。


LTも募集中ですのでぜひご参加ください


http://confwd2.peatix.com

そして老害になる

闇 Advent Calendar 2013の7日目として老害化の話をします。



ベンチャーじゃなく大企業につとめてよかったことは、さまざまな技術バックグラウンドを持つ人と仕事ができていることだ。


色々な流儀や文化の人たちと接し、ぶつかることで自分の視野がどんどん広がっていくのを感じている。


昔話をすると、学生時代、自分は主にRubyを書いていてJavaPHPをダサいものだと考え、時にはそれを口にすることもあった。
しかしdisるための根拠などをしっかりと持っていたわけではなく、なんとなくで
最新技術=かっこいい、べんり
古い技術=ださい、めんどくさい
と考えていた


社会人になってからダサいと思っていたまともなPHPの書き方を知りそれはそれで悪くない、むしろRubyよりすぐれだところもたくさんある素晴らしい道具と知った。


逆にcoolだと思っていたnode.jsやCoffeeScriptに手を焼き、PhoneGapのような技術で作られたプロダクトに苦しめられもした。
それらをiOSネイティブに書き換えていく作業をするなかで見た目だけで敬遠していたObjective-Cの思想が大好きになったりもした。


DB設計の正しいやり方を身につけ、それまでに自分がActiveRecordのmigrationで適当につくったものがいかにひどいものだったかも知った。


経験を積めば積むほど、今まで自分がバカにしていたものがいかに優れているかがわかるようになったし、逆に今まで無条件で最高だと考えていた技術の欠点も見えてきて、新しい技術が単に新しくてcoolそうだというだけで飛びついたりすることは減ってきた。


エンジニアは気付けば新しくて楽そうなものに流れる傾向がある。
しかし、最高のまともなエンジニアになるためには新しいもの、古いもの、有名なもの、無名なものをイーブンに評価できるようになるべきでなのではないだろうか。


そう考えもあり、最近はC++をずっと勉強していて楽しい。Javaも深く知りたい。他にも知りたいことがたくさんある。


しかし、そういうことをやっているとどんどん周囲と考えが離れていくのを感じる。技術の話をしても噛み合わないことが増えてきているような気がする。


Rubyやnode.jsかじったやつが使ったこともないのにPHPJavaを叩いてるのを見るとぶん殴りたくなる。
RDBの大した知識もないのに「MySQLはめんどうそうなので、MongoDBを使おう」などと提案されると軽蔑してしまうしそいつとは仕事したくない。


このままいくと将来こんなことを言ってしまうかもしれない
「プロダクションでnode.js使うの?いいけど何か問題が起きたとき対応できるの?nodeのソースコードすら追えないじゃ困るじゃん。C++も読めないのに偉そうなこと言うなよ」


そして老害になる

iOSの隠しフォント,ヒラギノ角ゴW1を使ったアプリが審査通った件

Animetick for iOS 1.2が審査に通り、リリースされました
このアプリでは隠しフォントっぽいヒラギノ角ゴW1を使用しています。


.HiraKakuInterface-W1, .HiraKakuInterface-W2というフォントは
iOSの標準API(UIFont#fontNamesForFamilyName:)では取得できないため
Private APIにあたり、Appleの審査で落とされる可能性が指摘されていました

注意

私がセーフだったからと言ってあなたのアプリもセーフとなる保証は全くない

意識高いiOSアプリのつくり方

基本編

1. Objective-Cで書く

Obj-C使いたくないが諦める

結局Obj-C使うのが一番楽であることに気づくのだ

2. Xcodeを使う

VimとかEmacsとかAppCodeで書きたいが諦める

結局Xcode使うのが一番楽であることに気づくのだ

設計編

3. 仕様とUIをしっかり設計してから実装する

きちんと設計しないとあとから大量の手戻りが発生して泣きたくなる。

  • 技術的に可能なことをやろうとしているのか
  • 基本的な画面設計
    • メインのビュー部分
    • ナビゲーション方法(TabBarなのかNavigationBarなのかNavigationDrawerなのか)

くらいは最低限調査・設計しておく

4. フレームワーク的ライブラリを使わない
  • UIKitは既に十分にフレームワークになっており、新たな思想を持ち込む必要はない
  • Reactive Cocoaを使うのはUIKitのMVCをよくよく理解してからでも遅くない
  • BlocksKitはbad parts. 古典的delegateを使用したほうが見通しもメモリ管理も良くなるケースのほうが多い
5. なるべくWebViewは使わないようにする
  • デバッグが難しくなる
  • Obj-Cとのブリッジ部分がバグの温床になりやすい
  • 使う場合はデータのやりとりは最小限に

クラス設計編

6. ViewControllerには最低限の責任しか持たせない。ModelとカスタムViewを積極的につくる

こんなViewControllerはクソの山だ!

  • 1000行超えてる
  • JSONをパースしている
  • JSONをパースしただけの生dictionaryを直接読み取り・操作している
  • subViewの見た目(colorとかframeとか)を操作している
  • 別のviewControllerと密結合してdisappearなときにも仕事をしている

続き:あとでかく

引っ越した #tqhouse

卓球ハウスというシェアハウスを作って引越しました。


最近引きこもりが加速して外出するのもダルくなりました。


家でイベントを開けば外出しなくてもいいことに気づいたのでイベントできるようにリビングが広めの一軒家を借りました。


さっそく、今週末は「ミルキィハッカソン」をやります。


ミルキィホームズを見ながらハックするナイスイベントになる予定です。


こういうひどいイベントどんどんやって行きたい

なんとなく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!