ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

Developers Summit 2013 まとめ

devsumi2013 Ruby Scala

※本記事は自鯖Blogの転載です
※元記事は2013/02/16に書かれました

http://blog.parrot-studio.com/2013/02/devsumi2013/

今年も参加してきましたヽ(`･ω･´)ノ

「Enterprise」「Social Game」「startup」3つの世界のAction!：Developers Summit 2013


例によって大雑把なメモ書きに、自分の感想等を織り込んでます
気づいた範囲で随時Updateしていきます

今年のテーマ

  • 「共感」から「行動」へ => Action!
  • 各セッションごとに「Action!カード」を配っていた
    • 講演者のメッセージやお勧め書籍が書いてある
    • 約一名、お勧め書籍に「評伝シャア・アズナブル」とか書いている方が・・・Σ(・ω・ノ)ノ

評伝シャア・アズナブル 《赤い彗星》の軌跡 上巻 (KCピ-ス)

評伝シャア・アズナブル 《赤い彗星》の軌跡 上巻 (KCピ-ス)

14-B-1：３つの世界：エンタープライズ、ソーシャル/ゲーム、スタートアップ

  • 唯一2枠使っていたセッション
  • まさに今回のデブサミを象徴する話
  • 孫泰蔵氏の話がかなり面白かった
    • あまり知らない分野だっただけに・・・
  • エンタープライズとソーシャル（Web）に分断された世界
    • naoya氏はWebという言葉を好んで使っていた感
  • それに加えてスタートアップというムーブメント
  • 会場の7割近くが「エンタープライズ」、2〜3割がWeb、スタートアップ10名くらい？
  • 「常識を問い直す」「変化を受け入れる」「過去が通用するとは限らない」
  • 各自自己紹介
  • 三谷氏
    • システムから経営へ
  • naoya氏
    • 知ってる話だから細かくメモってないΣ(・ω・ノ)ノ
      • みんな知ってる・・・よね？
  • 泰蔵氏
    • Y!の創業者との出会い
    • 23歳でスタートアップ
    • Gほーさんの話
      • どうしてもパズドラの紹介に
  • エンタープライズの今までとこれから
  • 省力化・業務・要求仕様・PM・・・
  • 今後も存在し続ける
  • 日本のIT投資は（アメリカに比べ）圧倒的に「伸びてない」
    • 95年くらいからほぼ横ばい
  • 80年代のアメリカ＝費用対効果が悪い
  • 2000年代のアメリカ=投資も効果も大きく伸びる
  • 80年代の日本＝費用対効果が高かった
  • 2000代の日本＝投資が増えない上に効果がただ下がり
  • なぜか？
  • 80年代＝省力化・効率化がメイン
    • 日本の得意分野
    • エンジニアのレベルも高かった
      • 社会に対して専門性が高いから？
  • 2000年代＝ビジネスモデル
    • アメリカはこれが得意だが日本は苦手(´-ω-)
  • 省力化・自動化はやり尽くした？
  • バックエンド（経理・人事等）からフロント（営業・経営）へ
  • 要求されるスキルが「積み上がっている」
    • あとでQAで出てきたが、全部必要なわけではない
    • 客と「一緒に」問題を「発見」できるか？
      • 解決よりは発見が大事
  • 他の世界（＝Web/スタートアップ）との協業が必要
  • Webサービスの話
  • IT＝「ビジネスのIT化」と「ITそのもののビジネス」
    • 「エンタープライズの三文字略語はわからない」
  • Googleの台頭
  • Web2.0＝Googleのやらないこと＝コミュニティ/ソーシャル
  • その流れでのFB
  • モバイルインターネットの台頭
  • "Post PC" = PCインターネット時代の終わり
    • 接続数はすでにPC=<スマフォ
  • PC時代＝Googleの一人勝ちΣ(・ω・ノ)ノ
    • 広告というすでに存在したビジネスをインターネットで置き換えた
      • 「新しいビジネス」が生まれたわけではない
  • 大衆化
    • インターネットは「ディスカッション」から「消費」へ
    • ガラケー -> スマフォの事例で日本はアドバンテージがあったはず・・・だが・・・
  • 開発トレンドの変化
    • クラウド・アジャイル・ソーシャル・・・
    • GitHubによる協業
    • エンタープライズ寄りも含む
  • 飽和
    • すでにアプリは山ほどあり、個人がどうにかできない
  • モバイル化 / グローバル化
    • 水道もないのにネットはある国すら
  • クラウドソーシング
    • エンタープライズ側への踏み込み
  • モバイルインターネット時代の成功事例
  • "Webサービス"はフロンティアであり続ける
  • 「Webの理想」はどうなるか？
    • オープンが当たり前の一方、「クローズド」だと思う人々
    • そういう人にとってはおそらくインターネット＝SNS
  • スタートアップベンチャーの話
  • 自分の知らない分野なので一番面白かった
  • ベンチャー投資が現象/立ち上げ数も減少
    • アメリカとどんどん差が
  • ・・・というのを悲観的に見る必要はないΣ(ﾟДﾟ)ｶﾞｰﾝ
  • 「新しいムーブメント」は全くデータに出てきてない
    • 例：日経平均
    • ずっと下がっているというが、実は57％の会社で株価上向き
      • 単に選定された「旧来の企業」が下向きなだけ
  • 「誰でもスタートアップ」の時代
    • クラウド・モバイル・ソーシャル・OSS
  • 昔に比べて大幅にスタートアップコストが低下
    • naoya氏の話にあったInstagramとか典型
    • ROの立ち上げ時、お金が集まらなかったので、ギリギリのサーバ数で接近ゲー
    • ROのデータセンターに突撃するOFF（？）(lllﾟДﾟ)
  • サークルが作ったアプリがすごいダウンロード数
    • しかも日本：海外＝2：8くらいで
    • ただし、あくまで一例ではある
  • EXIT戦略の変化
    • 昔：IPO＝株式上場
    • 今：M&A
      • 2000年くらいから圧倒的にM&Aが多数
    • "巨人"がイノベーションを買う
      • 例：FBがInstagramを買う
  • もはや「マネタイズ」はナンセンス
    • M&Aでコストはペイできる
  • 業界の高度化
  • ベンチャーのカジュアル化
  • シリコンバレーの人口：300万人
    • 福岡県が500万人
  • 17000/年できて12000/年の会社がつぶれる
    • つまり、年5000社くらいずつ増えている
  • 「エコシステム」「生態系」の存在
  • 日本には（ベンチャーの）生態系がない
    • いわば砂漠であり、砂漠に水（公的資金）とか入れても無駄
  • ゆえに、アジアで生態系を作る
  • 毎週スタートアップ向けの勉強会を開催中
    • スタートアップの「スター誕生」的なイベントも
  • まだ「種から芽を」の段階で、生態系には遠い
    • 世界中いろいろなところで生態系ができつつある
  • 「作る人がいない」「アイデアがない」
  • 「バンドを組む」感覚でスタートアップ
    • この表現が一番しっくりきた
  • やりたい人で集まって、気軽に解散すればいい
  • 短時間ながらパネルディスカッション
  • 「開発＋α」か「専門性」か
    • どちらかでないと今後生き残れない
  • 「最初から英語で作る」（泰蔵氏）
    • 日本人は英語が苦手
    • "苦手だから" シンプルな言葉や絵で表現しようとする
    • 結果的にグローバル/ユニバーサル化
      • これは確かに納得...φ(･ω･｀)
    • そもそも、「まともな英語」を話している国の方が少数
    • 日本語だと暗黙の了解が生まれやすい
      • 他のコンテキストに応用が利かなくなる
  • 開発は英語ですべき（naoya氏）
    • 一方、Rubyの普及のおかげか、日本語を使う海外の人もそこそこいるらしい
  • 質問
  • どうしたらエンタープライズに人が来るのか？
    • 某社で面接した人の8割が「フィードバックが欲しい」
      • me, too.
  • Specialityがあるから他の人に対してOpenになれる（氏）
    • 自分の基盤が必要、ということ
  • Professionalism
  • "Web"サービスを作りたい（naoya氏）
  • ロボットベンチャーをやりたいので人を募集中（泰蔵氏）


14-A-3：Ruby2.0

  • 相変わらず面白い話
  • 普通に「ムカツク」とか言っちゃうあたりが相変わらず
  • 1993/02/24：「Ruby」という名前が決まった日
    • バブルで案件が弾け、暇だったから作った
  • 誰でも最初にやる"Hello World!!"
  • だがそんなに簡単ではない
    • 「文字」にはStringクラスが必要、そのためにはObjectクラスが・・・
    • 「出力」にはI/Oの処理が・・・
  • 結局半年かかった
    • 「動くもの」ができるまでのこの半年のモチベーションが壁
  • 1995/12にVer0.95として公開
    • コピーして配布する度に+0.01していた
  • 過去のRubyはだいたい盆と正月に合わせてリリース
    • 2003/08：1.8
    • 2011/10：1.9.3
  • （2.0に対する）心理的な壁
    • どんどん鈍化していくバージョン番号の伸び
  • 初めてRuby2.0に言及：RubyConf2001@フロリダ
    • ちょうど9.11が発生した頃
    • 新VM / 新GC（世代別GC） / ネイティブスレッド / 埋め込みAPI
  • つまり、「コアの置き換え」
    • 1.9のYARVによってほぼ達成
    • 世代別GCはコストが高すぎた
    • 1.9は別方式を採用
    • 2.0はさらに新方式（bitmap marking）を採用
    • 1.8まではグリーンスレッド
      • ユーザレベルスレッド
      • つまりは「見かけ上スレッドのように動く処理」
    • なので、マルチコアでもシングルコアしか生かせない
    • 1.9でネイティブスレッドへ
    • but、Rubyのほとんどはスレッドセーフではない
    • GILで大きくロックして対応
    • 同時に1つのVMしか動かない、という妥協点
    • JRubyは完全なスレッドを（JVMが）持っている
      • 「いろいろ言われるのでむかつく」Σ(・ω・ノ)ノ
  • 「現在の」Ruby2.0に言及：RubyConf2003
    • キーワード引数 / ハッシュリテラル / メソッドコンピネーション / セレクターネームスペース
  • 壁を乗り越える要因
    • 「20周年」
      • ADD：Anniversary Driven Development
    • 言及していたものがそれぞれ完成した
def countup(from to, step : 1) # stepのデフォルト値が1
  (from..to).step(step) {|i| p i}
end

countup(1, 10, step:2) # 1, 3, 5, 7, 9
  • （特にRailsで多用される）Hash引数を置き換えるもの
    • 最後のHashから値を取り出す手間から解放される
    • デフォルト値もメソッド定義の中に織り込める
    • 順序も気にしなくて良くなる
  • メソッドコンビネーション（Module#prepend）
    • いわゆる「アスペクト（志向）」
      • 元のメソッドの前後等に別な処理を差し込む手法
      • Javaで一時期話題になって、本を読んだことが
      • 例：特定メソッドが呼ばれたときにLoggingする
    • Railsで多用されている「alias method chain」
      • 元のメソッドをaliasで待避させ、メソッドを修飾する手法
    • しかし、名前が衝突したり、管理が面倒だったり、グループ化も無理
  • Lisp（CLOS）におけるメソッドコンビネーション
    • before / after / around
    • Rubyではオーバーヘッド(´-ω-)
    • moduleを適用する際、同じ名前があった場合に・・・
      • include：元のメソッドの「後」
      • prepend：元のメソッドの「前」
    • ・・・に処理を差し込む
    • メソッドの中でsuperを呼べば元の処理が呼べる
      • なお、JavaのアスペクトはClassになにも書かず、別なところに書いてフックしていた
      • Javaの場合は後から差し込めるのがメリットだが、管理はしづらい気が(´-ω-)
  • Refinements
    • Rubyでよくやる既存クラスの拡張
      • いわゆる「オープンクラス」
    • but、スコープに問題がある
    • 一箇所で動作を変えたものが全体に波及する
      • 例：math / jcodeによるInteger / Stringの拡張等
    • スコープを限定してクラスを書き換えることができる
    • ただし、「実験的実装」扱い
      • 他の処理系から（遅くなる等）文句が来たとかΣ(・ω・ノ)ノ
      • なので、Ruby2.0の必須要件ではなく、変わるかもしれないし、他の処理系で使えないかもしれない
module Hoge
  refine String do
    def piyo
      p "piyo : #{self}"
    end
  end
end

"あ".piyo #=> method missing

using Hoge
"あ".piyo #=> piyo : あ
  • 遅延評価（Enumerable#lazy）
    • Ruby1.9のEnumerableは無限を扱えない
      • そのように書けるだけで、順番に処理しているから
      • 「必要になったら値を取得」＝遅延評価ではない
(1..Infinity).map(&:to_s).select{|s| s.match(/3/) }.take(10) #=> 無限の処理でメモリを使い果たす
    • 当初はmap_lzのようなメソッド追加を検討
    • but、めんどいΣ(・ω・ノ)ノ
      • lazyを使いたいような人はlazy（怠惰）である
    • lazyというメソッドを挟むアイデアを採用
(1..Infinity).lazy.map(&:to_s).select{|s| s.match(/3/) }.take(10)
  • Ruby2.0は2013/02/24リリース予定
  • 一方でRubyという言語の限界もΣ(ﾟДﾟ)ｶﾞｰﾝ
    • 新しいことをやろうとすると、Rubyの仕様を壊さずにできない、等
  • 今後の予定


14-A-5：RubyでiOS/Androidアプリを作るMobiRuby

  • mrubyの特徴
    • CPUパワーがない環境向け
    • not POSIX、C99のみ
      • ファイルの読み込みすらないΣ(ﾟДﾟ)ｶﾞｰﾝ
    • ほとんどのライブラリがない
    • OSとかCPUに極力依存しない
    • Configurable
      • ライブラリ単位でコンパイル時の組み込みを制御できる
      • 例：Tableの保持方法をhashかlistか選べる
    • アプリへの組み込みも可能
    • マルチVM
    • グローバル整数なし
    • 2010年開発開始 -> 2012/04 OSSとして公開
      • 2011のRubyKaigiで話を聞いた
    • mrbgems
      • mruby版gem
      • 任意の機能をgithubから取り込める
    • とにかく全体にシンプルな作り
    • エコシステムもまだこれから
    • 今から開発に参加しやすい
  • mobiruby
    • （現在は）iOS向け
    • MITライセンス
    • ネイティブ（Objective-C）の機能はほぼ使える
    • Rubyの力（メタプログラミング）をモバイルにも
      • Luaは軽量だがDSLとか書きづらい
      • 逆に書けるならROのホムAIが面白いことになるが・・・
    • 当然ながら、（Objective-Cの）コード補完が効かない
      • 自力でメソッドを記述できる人向けΣ(・ω・ノ)ノ
  • 構成要素
    • コア：mruby
    • gem：mruby-cfunc
      • Cのメソッドをmrubyから好きに呼べる
    • gem：mruby-cocoa
      • Objective-Cのメソッドをmrubyからほぼ呼べる
      • Rubyで定義したクラスをObj-Cで継承とかも
      • 問題はmrubyとObj-CでGCの方式が違うこと
      • 現在ここがボトルネック
    • gem：mobiruby-common
      • iOSとAndroidの共通部分
      • "require"の実装やPOSIX要素の実装など
    • gem：mobiruby-ios
      • iOS依存の部分
  • Objective-CとRubyの対応部分を3月くらいまでに
  • AppStoreへの登録もOK
    • 非公開APIの利用はダメなのだが、ドキュメント化されてないAPIがOKかわからない
    • なので、頻繁に観測気球を上げているらしい
  • 「RubyMotionとの違いは？」
    • 「2万円払った方がいい」Σ(ﾟДﾟ)ｶﾞｰﾝ
  • メリット
    • mrubyがmatz製である
    • mrbgemsの仕組みがある
    • MITライセンス
    • コンパクト
  • デメリット
    • 不安定
    • 実装されたクラス等が少ない
    • デバッガがない
      • mruby自体、トレースを吐かずに落ちるらしい
    • コード補完が使えない
  • 作者さんはTitaniumの会社に勤務
  • 社長に「（競合になるけど）mobiruby公開していい？」
  • 社長「やってみれば？（別に競合しない）」
  • 世界に向けて「ポートフォリオ」になるものが欲しかった
    • つまり、「私は○○の作者です」と言える何か


14-A-6：ニコニコ静画（電子書籍）の作り方　〜みんながニコニコしてくれる読書体験を届けるために〜

  • Team nicobook 3代目リーダー
  • http://seiga.nicovideo.jp/book/
  • 2011/11公開
    • 最近R18対応も(*ﾉ∀ﾉ)
      • 22時をすぎると導線が出てくるらしい
      • 特にリリースを出してない
  • 開発8名
  • その他スタッフは兼務が多い
    • インフラとかデザインとか
  • 全体でも20人いないくらい
  • github:enterprize
    • ディスクイメージで納品されるのでブラックボックス
    • データバックアップがめんどいらしい
    • 運用コストが高め
    • 21$/user/month
  • リポジトリ名に「自分の嫁」の名前を使用Σ(・ω・ノ)ノ
    • そうすると愛着が湧くらしい
  • 運用ルールはシンプルに3つだけ
    • pull request前にテストを通す
    • masterへのmergeはpull requestで
      • 勝手にmergeしてpushしない
    • pull requestは本人以外の誰かが必ずチェック
  • Simple is Best
  • 複雑化すると・・・
    • 守れない
    • アクションに対して逃げ腰
    • コードが私物化される（手間が掛かるので）
  • コードレビュー
    • レビュアを固定しない
    • 得意な人が見る
    • 不安なら他の人にもお願いする
    • チェックしたらmerge
  • Jenkins
    • リリース基準：「JenkinsがGreen」のみ
    • but、これが難しい
    • いったんRedを放置するとどんどん腐っていく
  • リリース手順
    • git -> svn / tag / Wikiに手順書作成 / インフラ部隊がリリース
    • but、めんどい(´-ω-)
      • 普段gitなのでsvnのコマンドを忘れる、ドキュメントは書きたくない
  • 自動化ツール「リリース先輩」
    • ツールに人格を持たせる
    • IRCで「お願いする」
    • するとリリース手順を自動でやってくれる
    • 進捗もIRCで「しゃべる」
    • 自動化に遊びを持たせて愛着を
  • チームの約束
    • 「テストを書け」
      • 自動化、デグレ防止
      • サービスを回し続けるのに必須
      • 運用＋新規開発＜手持ちのリソースでなければならない
      • 運用リソースが増大すれば、新規開発ができず、サービスが死ぬ
      • （このあたりが社内で理解されていない？）
    • 「根性で問題を解決しない」
      • エンジニアの仕事はエンジニアリングである
      • 手で解決するのはNG、自動化せよ
    • 「何をやってもいい」
      • "許可を求めるな、謝罪せよ"
      • 勝手になんでもしていい、ということではない
      • あくまで共通の利益（Common Good）のために
      • ダメなら考える
      • ちなみに、許可を求めないけど、謝罪もしないし、勝手すぎる人はマジで困る(´-ω-)
    • 「失敗を引きずらない」
      • 反省し、考え、再発を防ぐ
  • 新しいルール「ライトスタッフであれ」
    • やっぱりパトレイバーだったΣ(・ω・ノ)ノ
    • light（軽い） / right（正しい）
      • （わりときつめの・・・おそらく会社に対するアピールが）
  • 「当たり前のことを当たり前にやる」
  • その上で＋αの付加価値を提供できるかが重要
  • 何というか・・・D社の内情がいろいろ見えたセッションだった
  • このチームは理想的だけど、それが社内的にどうかはまた別
    • 実際、「先代」はD社をやめているし、有名な人も最近離れまくり
    • 「とがった人」が片っ端から辞めている感
  • 企業の成長の中ではよくある話ではあるが・・・(´-ω-)


14-B-7：こわくない関数型言語

  • 結論：こわい(((((( ;ﾟДﾟ)))))
    • アカデミックな内容に偏っていたので、難しかった
    • そもそもラスト枠でこれはきつい・・・
    • 以下、個人的メモとして役立ちそうなところだけ
  • 「ScalaをベターJavaとして始める」
  • 「scalaz（ライブラリ？）はいらない」
    • 私はよく知らないので、おそらく知らないままでいい(´-ω-)
  • COP本と逆引きを勧めていた
    • 逆引きは私も昨年から読んでいる

Scalaスケーラブルプログラミング第2版

Scalaスケーラブルプログラミング第2版

Scala逆引きレシピ (PROGRAMMER’S RECiPE)

Scala逆引きレシピ (PROGRAMMER’S RECiPE)


15-C-3：Azureエバンジェリストが大企業マイクロソフトの中でとってきたAction!の軌跡

  • まず会社のミッションを評価されるレベルでこなす
    • 「○○さんなら仕方ない」と言われるレベルまで
  • MSの名前が邪魔だった
    • どうしてもお堅いイメージがつきまとう
  • （エバンジェリストの仕事は）潜在層とファンへのアプローチ（と考えている）
  • とはいえ、あくまで会社の評価は営業成績
  • なので、それらの仕事をこなしつつ別の活動もしている
  • 社畜が自由を勝ち取るプロセス
    • 転職・独立 -> 難しい
    • 風土改革 -> 一社員では難しい
    • 新規事業 -> 自分でやりたいことと、会社のミッションをすりあわせる
  • 「（しばらくクラウディアさんの話をするので）リア充の方はこちらを(´･ω･)っ」
  • 昨年のマイルストーン：コミケにクラウディアさん
    • ここで「リアルクラウディアさん・巫女さんVer」がチョコを配り始める
      • が、もらえなかった(´･ω･`)
  • かかった費用：800万くらい
    • グッズ（？）の売り上げがあるので、実費用はもうちょっと少ない
  • 「（権利とかにうるさいので）MSは（コミケ層には）嫌われているのでは？」
    • 実際は大好評
  • 「わかりやすい数字」を出さないと、「上」は納得してくれない
    • 日本法人だけでなく、本社も含めて
    • 「認知度が上がりました」ではわかってもらえない
  • グッズの売り上げという数字
  • アンケートで仮説を実証
    • 「コミケの参加者にIT関係が多いのではないか？」
    • 関係者3割・今後目指す人まで含めると5割近い結果に
      • もちろん、MSブースに来るような人、という補正はあるだろうけども
  • こういった情報を詳細なレポートとしてまとめる
  • 「手段と目的の逆転」
    • 「コミケに出たいが、どうやったら会社の業務と絡められるか？」
  • コミケWebカタログにAzureを採用
    • 全力で取りに行く
    • そして仕事として成功させる
    • そこから広げる「お客さんのイベントなんだし、何か出しませんか？」
  • アイデアを形にするための動き
    • 社内でボランティアスタッフを確保
      • 意外とエンタープライズとか開発系からも多かった
    • 予算調達
    • コンプライアンス
  • そして新しい動きへ
  • 大企業ならではの醍醐味
    • 例：他社との競合案件
  • Azureチームだけでは限界がある
  • しかし、「MS」として他部署と協業すればいろいろできる
  • さらにパートナー企業や別分野の客も巻き込んで提案
  • 一体となって新しいビジネスを提供する
  • Azureの話
  • だいぶ使われるようになった
    • ソーシャルゲーの媒体にて、いくつかの部門で受賞
  • ここでデモ
    • ディスクイメージ提供
    • コンテンツをエンコードして配信する仕組み
    • iOS向けのアプリ開発プラットフォーム
      • MSのサイトなのに「まずXcodeをDLします」Σ(・ω・ノ)ノ
  • ここでKDDIの「twilio」のデモ
  • WebとTELをつなぐAPI
  • 匿名通話
    • 相手に番号を知らせずにWeb経由で通話
      • WebアプリがAzure上で動いていた
    • JSでアプリが書ける
      • 通話や音楽をコントロールできる
    • サーバが停止したらTELが来るとか
    • （ファミレス等で）順番が来たらTELが来るとか
    • 商品が入荷したら（人手を介さずに）TELが来るとか
    • 事例：タクシー配車サービス等
  • ハッカソンイベントあり
    • クリプトンも参加しているが、某ミクさんは関係ないらしい


15-B-5：SQLアンチパターン - 開発者を待ち受ける25の落とし穴

SQLアンチパターン

SQLアンチパターン

  • アンチパターンとは「問題を解決するつもりが、裏目に出る技法」
  • 4つのセクションと25のアンチパターン
    • 論理設計 / 物理設計 / クエリ / アプリケーション
    • No.25は書き下ろし
  • 構成
    • 「名前」
      • この本の最大のポイントはパターンに名前がついたこと
      • あえてカタカナのままにする
      • 会話で目立つし、中二っぽいΣ(・ω・ノ)ノ
      • 「私が中二なので仕方ない（ﾄﾞﾔｧ」
      • 必殺技のようでｶｺ（・∀・）ｲｲ!!
    • 「目的」
      • 何を解決しようとしたのか
    • 「アンチパターン」
      • やってもうたこと
    • 「アンチパターンの見つけ方」
      • こういう発言が出てきたらまずいという「匂い」
    • 「アンチパターンを使っていい場合」
      • この本のフェアな部分
      • コンテキストによって何が最適かは違う
    • 「解決策」
  • 「他人の失敗を学び、自分の失敗を回避する」
  • 「データの問題はプログラムのバグよりはるかにでかい」
  • 細かいことはいいから買えщ(ﾟДﾟщ)

最終日はもういくつか話を聞く予定だったのですが、
体調的な限界であきらめました(´-ω-)