#ginzarails 「プログラマがコードを書きながら考えること 」by jnchitoさんの観察ログ
はじめに
2019/8/29にDeNAさんにて開催された銀座Rails#12で、jnchitoさんのライブコーディング（動画）を観る機会があった。まずは雑に出す。
当日の様子はこちらのハッシュタグでどうぞ
ライブコーディングが始まる前に思い浮かべたこと
- どこから始めるか？
- どんな出力にするか？
- ツールは何を使うのか？
- 伊藤さんならもちろんテストから？
- もしかして簡易ツールだとテストは書かない？
パッと見ポイントだなと思ったこと
- 使い慣れた技術を選定している
- Rails
- Heroku (w/ Scheduler)
- Mechanize gem
→（後からわかるが）Mechanize gemはそうでもなかったらしい。
観察スタート（心の声を添えて）
序盤
- 対象のサイトをよく観察してみる
- 単純なターゲットを決める（ユニークキーをみつける）
新プランの判断は既存との差分で決める
名前に迷う（ある）
名前をつけるときにちゃんとスペルをチェックしている
リポジトリを作成したら、まずは基本動作をチェックしてイニシャルコミットする（ある）
モデルを考える
- Rubymineを利用して作成する（便利！）
- 最初にすっとインデックスも貼っている
- migrateもRubyMine上からやっている
- 最初にバリデーションもさっと設定
- コミットもRubymine上で実施。
- 英語のまま
中盤
まずモデルからメソッドをはやしていく
- やっぱりテストから作成している。
- 簡単なテストをパスさせるところから
Gemをどこに追記してくか、いつも悩む（ある）
- Mechanize導入して、最初に簡単な動作確認をする（重要）
何度もリクエストを飛ばさないようにするためのgem（スクレイピング時の配慮大事）
テストライブラリはどちらも使えるようにしておくと便利らしい
- Minitest & RSpec
まずさっと試す→さっとリファクタ
DOMチェックはChrome Dev toolのconsoleでさっと試す
- console上で使えるメソッドにも色々便利なものがある
Rubyの使い方についてはかなりサクサクでてくる（当たり前だけど）
正規表現の適用までもかなりスムーズ
RubyMine上でgit diffも確認できる（diffの確認はやっているがいつもターミナルだなぁ）
アプローチとして、アーキテクチャ上の一連の処理に対して簡単なものをまず作る
- インクリメンタルに実装を進めていく。
RubyMine上のターミナル画面を小さいまま使ってる（意外だがそうならざるを得ない？）
自分とやっている手順は近いがRubyMine上ですべて完結しているところが凄い（ウィンドウの切り替えがないところが良い）
RubyMine上だとテストランもわんぽちでいける
終盤：運用へ向けて
- Rakeタスクを作成
- Heroku Schedulerを設定
まとめ
- 手慣れているツール使いのスムーズさが半端ない（Ruby、RSpec、RubyMine）
- 自分の中でここまで習熟しているものはないのでは、というくらいスムーズだった。
- 自分の中であいまいなことは一次情報を調べる（英語、初めて/たまに触るツール）
- この過程を経て手慣れたツールに昇華されていくのだと思う。
2019/9/8追記
伊藤さんが発表に使われた資料と動画がBOOTHで販売開始されました。リンクはこちら↓
