2回目のRails Girls,More!
2017年12月17日（日） 時間は前回同様13:00〜18:00 場所も前回同様で
株式会社ケーシーエスキャロット｜ソフトウェア企画・開発 でした。2回目だったので迷わず行けました！
自作アプリは保留
ちょっと前まで「とにかくまず自分のアプリを作りたい！」というのを最大の目標にしていましたが、行き詰まっている状況が続いていました。
いくつかの勉強会でいただいた学びや得た情報から、（これは私の自己分析にすぎませんが）原因は以下の点だと思っています。
設計がないまま思いつきで作ろうとしている
おおよそのイメージはあるけど、作ってみながら「いや、もっとこんなのもあった方がいい」「これはこう動いた方がいいけどこっちはいらないかも」と行き当たりばったりの作業を繰り返していました。そして「あれ？このページは何をする為に作ったんだっけ」などのようにわけがわからなくなっていました。コードの構成が支離滅裂になって、やればやるほど絡まる
これも根本的に設計の問題かもしれません。１つ機能を加えたいと思うたびに、調べて、そこのコードをなんとか書いて、次にやりたいことについてはまた調べてまた書いて・・・のループをしていると、１つ前に書いたコードがなぜこんな風に書いてあるのか自分でもわからなくなっていっていました。それに例えば後から後からコントローラーを増やしてはルーティングを書き換えてどうなっているのが正しいのか不明・・・という具合にだんだん交通渋滞気味に。
「書き直したい」という思いが湧くけれど、書き直すスキルがない。 という状態になっていました。
今回のRails Girls, More!で学んだこと
そんなこんなで今回は、自作アプリではなくRails Tutorialを進め、わからない部分をコーチに教えていただこうと思いながら参加しました。
やったのは検証の部分の途中、６−２−３「長さの検証」から６−２の終わりまででした。
Ruby on Rails チュートリアル：実例を使って Rails を学ぼう
主に教えていただいたのはvalidationの考え方。あとは途中でてきた「正規表現」でした。
テストについては奥が深いので今は「こう書くのかふむふむ」程度にするというアドバイスもいただきました。（やり始めると沼にはまって抜け出せない、と他の人にも言われました笑）
①validation（検証）とは DBへ保存するデータを規制するもの
”DBにデータを送る”のはなんでもかんでもいいわけではなく、「郵便番号ならこういう形式」「ここは数字のはず」などの設定をする。
②破壊的メソッド
”「… downcase!」に書き換えてみよう”という演習が出てきて、”なんだこれは！”と思ったので質問。
予想「強調してるとか？？」（心の声）
回答「これはデータを書き換えるものだよ」
今回の場合
before_save { self.email = email.downcase }
これはメールアドレスをdowncase（小文字）にするだけ。
before_save { email.downcase! }
こちらだとメールアドレスを小文字にしたものに置き換える。
メールアドレスの一意性検証の中で出てきたけれど、メールアドレスにまつわることがちょっと難しすぎてあんまり理解できてない。
③正規表現のポイント
正規表現を自分で０から何もみずに書くのはとても難しいけれど、書いてあるものをみた時におおよそ「こういうことが書いてある」ということを把握できるようになっておくようにとのことでした。
/ :正規表現の開始を示す
[ ]+ :[]の中の文字のいずれか少なくとも1文字以上繰り返す
\A:文字列の先頭
あとは括弧が塊になっているということ。 とりあえずこれだけでも覚えておいてみようと思います。
とにかく回数をこなす方向で
「わからないことが多すぎて進めるのに時間がかかる」という悩みに対していただいたアドバイスとして「今はわからなくてもいつかわかる思うからとにかくどんどんやる」というようなことを教えていただきました。
実際、その後だいぶサクサク進めていて、そっちの方が楽しなって感じているし、自分にあっていると思います。
わからないことを潰しながらではないとスキルが上がらないとなんとなく思い込んでいたのですが、必ずしもそういう訳でもないなと感じます。 とはいえ、「今押さえておくべきこと」もあるはずなので、時と場合によって「これだけはわかろう」「ここは解決させたい」というのを自分の中で意識して勉強を続けたいと思っています。
🎅🎅🎅🎅🎅🎅
今年最後の、そしてクリスマス前のRails Girlsだったので、ケーキを作ってくださっていました！！ 綺麗で美味しくておしゃれで素敵なブッシュドノエルでした〜❤️感謝〜❤️
