sunaot

入り方の手順は、
- ヒカリエにたどり着く
- 11F で入館受付
- 21F で SeminarRoom の部屋へ
の順になります。

* ヒカリエの場所 (地上駅直結だと 2F、地下鉄直結だと B3 へ着きます)
http://www.hikarie.jp/access/index.html

* 入館受付

sunaot

基礎知識

• 結合性
• 凝集性
• 直交性と DRY

読み物系

• 実装に名前をつけるのでなく意図に名前をつける
• 条件分岐とのつきあい方

sunaot

require 'test/unit'

class Test < Test::Unit::TestCase
  def test_resolv_error
    force_resolv_error do
      # do something
    end
  end

  private

sunaot

select 
  'a dake' as type
, id
, ckey 
from 
  table_a a 
where not exists
  (select 1 from table_b b where a.id <=> b.id and a.ckey <=> b.ckey)
union all
select 

sunaot

	soft	mixed	hard
HEAD	o	o	o
index	-	o	o
working tree	-	-	o

• index は git add して登録されたインデックス
• working tree は add される前の展開されてるファイル

sunaot

setup を DRY にしたい

# こんな支援モジュールを書く
use strict;
use warnings;

{
 package Foo::Bar;

sunaot

条件分岐とのつきあい方

プログラムが複雑になる一番の理由は条件分岐 (if 文など) です。

条件分岐がなければ、一本道で読み下していけばいいのでバグが入り込む余地は大変少なくなります。

ということで、

• 条件分岐を書かなくていいように書く
• 条件分岐を書くなら、わかりやすく局所化して書く

sunaot

select
  c.id
from
  user u
  join
  recipient r
    on (u.id = r.user_id)
  join
 conversation c

sunaot

• スローテスト問題
  • なぜスロー？
    • DB アクセス、GUI からのテスト、etc
  • 対策は？
    • 並列実行
    • GC 止めたら速くなったYO!
    • setup に時間のかかるリソースを prefork するように
  • ほんとにそれ対策になってるの？
    • CI 管理者が今あるテストを前提に高速化をする話と明日書くコードが遅い話は混ぜちゃダメ
• 明日書くコードは生まれながらに高速に書けばいい

sunaot

例外設計の話。

こんな指針がいいのかなー 2013 夏 ver.

例外の目的とは？

• 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」
  • via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html

.NET の「例外のデザインのガイドライン」にもこう書いてある。