Go to Qiita Advent Calendar 2024 Top
LoginSignup
17
37

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@kugyu10(kugyu10)

Ruby on Rails チュートリアル集中講座1日目メモ

Posted at

日本語版Rails Tutorialhttps://railstutorial.jp/
を運営しているYassLabさんが講師！
たった５日間であの長いRails Tutorialを完走する集中講座に参加しています。
https://coedo-dev.doorkeeper.jp/events/72968

５日間参加予定です。
どうせメモたくさんとるので、Qiitaで公開していこうと思います。

#第１章 ゼロからデプロイまで 〜hello, AWS & heroku!

寝坊しましたorz

（開発環境を整えるまでの辛みって熟練者でも避けて通れないと思うんだけど、
そこをどういうマインドで楽しんでいってるのか、を学びたかった。）

heroku確認

heroku version

これで、herokuコマンド無いよって怒られたら
heroku CLIをインストールする必要がある。

AWSのCloud9でherokuインストール

ぼくが一周目したときはCloud9がAWSになる前だったので
ちょっと細かいところが変わってました。

nvm install node
nvm use --delete-prefix v9.3.0
npm install -g cli-engine-command@8.0.0
npm install -g heroku-cli

詳細はこちら(https://qiita.com/beplocks661/items/8d840b6efcdcd14009bf)

一番最初のbundle install

withoutオプションをつけておくと、二度目からは自動的にproductionなしでやってくれる

bundle install --without production

#第２章 Toyアプリケーション〜黒魔術scaffold

scaffold わりと上級者向け。

Railsの全体像をざっくり解説する章
なんとなくの理解でいいよって前提。

（本当になんとなくしか分からない・・・・っ！！）

作るもの

Userモデル

カラム名 型（って言い方正しいのか？）
id integer
name String
email String

あとupdate日時とかもある。

scaffoldで作るコマンド

rails generate scaffold User name:string email:string

Micropostモデル

カラム名 型（って言い方正しいのか？）
id integer
content text
user_id integer

コマンド

rails generate scaffold Micropost content:text user_id:integer

rails db:migrate

冪等（べきとう）性「何回叩いても大丈夫！」
何も考えずにDDL作っちゃうとそうはならないよね。
rails dbけっこう偉い。

###resources
routesに書くアレ。
いい感じ（REST）にURL→Controllerの紐付けしてくれるやつ

##URLで /users 叩いたときの流れ

  • まずroutes見に行く
  • resourcesで紐付いているuser_controller#indexアクションにいく
  • @user ← User.all
  • default_render
    • アクションとかメソッド読んだときに、なにも書いてない時にやること・返すこと。
      Javaと違ってこういう省略がRubyには多い
  • app/views/users/index.html.erb(だったか？）をrenderする
  • ブラウザで見れる！！！！

##アソシエーションを用意
has_manyとかbelongs_toとかをmodelに書くとすっごい便利。

has_many:microposts

User.first.microposts って書き方ができるようになる

belongs_to:user

Micropost.first.user って書き方ができるようになる。

アソシエーションで嬉しいことの１つに
こういう処理をすごく簡単に書けるようになること。

Micropost.last.user.microposts.first

とかいう、あるいみ循環的なことを書けるようになる？
（一応、rails consoleで試したら動いた。）
「最後にツイートしたユーザーの、初めてのツイート」
を拾ってこれる。便利かも。SQLじゃこんなに直感的に書けない。

Modelは単数形でキャピタルだよ！

User
とか

あとはだいたい複数形だよ！

/users
users_controller#index
とか

#第2.5章 質疑応答〜まったくRailsは最高だぜ！

###Railsの開発曲線のお話

  • 今日一番パッションを感じたお話。
  • Ruby on Railsは学習コストがかかる。そのぶん、精鋭だけを集めたチームの開発速度すごい！
  • Railsがそもそも向いてないものもたくさんある。でもスタートアップならたぶん最速。
  • Rails最高だぜ！って愛情が伝わる。こういうのすごいモチベになる。

###Q：SQLの知識は必要か？

  • yesかnoかでいったらyes
  • ActionRecordで普段は意識する必要はない

###Q：scaffoldは現場でも使うか？

  • 使った方が早いときは使う

###Q：精鋭のRailsチームに入るには？

  • まず、なんで彼らは精鋭にこだわるのか？ってお話。
    • 低いレベルの人が入ると、高いレベルの人が教えないといけない
    • つまり、チーム全体が低いレベルにあわせないといけない
  • なので、精鋭Railsチーム作ってる企業は 絶対に 採用ラインは下げない。
  • なので、自分がそのラインにあがっていく必要がある。
  • 「技術を知らないこと」自体は減点にならないよ、ってお話。
  • 「未知の何か、不確実なもの、新しいフレームワークに出会った時、どういう態度にでて、どういう行動をするか？」の方がずっとずっと大事だし、採用者は見たい。
    • どういう反応でも良い。どういう反応するタイプなのか？
    • たかが1時間の面接やレビューじゃ見きれない部分
    • なので、 みんなが見えるところ（Github Qiita）で、それ（未知なものに対してどういう行動をとるか）をやることが大事。

↑の話は、今自分に一番必要なところと感じた。

###OSS Gate

  • OSSは敷居が高いのでOSS初心者向けのイベントやってるよーってコミュニティ

###RESTfulの話

#第3章 ほぼ静的なページの作成〜みんな大好きTestのお話

###良く打つコマンドは短くしよう、というお話
.bash_profile いじってAiles別名登録しておく

bu bundle update
bi bundle install

g git
l log

（これ、エイリアスが被って困ることないのかな？）

VFS Connection が駄目と怒られる

AWSが調子悪いっぽい
→「R」からダッシュボード、インスタンス再起動→なおった

（なんかトラブル解消のスピードがめっちゃくちゃ早い）

#Branchの話

masterはバグあるのは望ましくない。テストが終わっている安全なブランチであるべき。
featureブランチで新しい機能をつくる。
テスト終わってからマスターに入れる。

「Git flow」という考え方。

#tmuxのエラー
rails t した時になんかエラーでたやつ。
Terminalに色をつけるためのもの。

sudo yam install tmux

で解決できるはず。

##よくあるテストはコンピューターでやってもらおう
テストコードの考え方。早いし楽。

aboutを作って
Red → Greenになるのをデモ。

##yeild
普通の変数と違って、その中身はあとから定義するよ、って関数。
先にapplication.erbを読んで
後から個別のviews/static_pages/help.html.erbとか見てる。
help.html.erbにyeildの中身を書いている
（書いてなかったら空文字""が返る？）

#いつ先にテスト書く？

  • バグを見つけた時。将来同じバグを書いちゃうかも。リファクタリング。
  • セキュリティ的に重要なコードを書く時は先にテスト書く。認証関係のテストとか。

#先に書かない時

  • ころころ仕様が変わるとき。変わりそうなとき。
    • 何度もテストコードを書き直すハメになりそうな時は書かない。ある程度固まってから。
    • UI、UX設計が不十分なとき。
  • 本当にこの機能が必要か分からないとき。

Slenium

主にブラウザ互換を確認するためのもの。
すでにそのサービスはビジネス的にうまくいっていて、
（もっとユーザーを増やすために）IE11いけるか？Chromeいけるか？を確認するもの。

rails testはもっと機能のテスト

Viewテストの必要性

pintarest
Gumroad

みたいに、デザインで勝負する。デザイン面で競合より優位に立つこと狙っている
サービスであれば、Viewのテストも重要。

Osushiの例。

どこまでテスト書くのが割に合うライン？

どこまでテストを書くのかお客様と合意をとりたいので、
どこまで書いた方がお得なのか測りたい、みたいな背景。

そもそも前提が良くない、という身も蓋もないご意見。
本当は「テストコード書いた方が御社ビジネス的にいいですかね？」と
相談できる関係じゃないと、長期的にはまずいよ。

バグゼロを担保しない、準委任契約がオススメ。

3.5章 懇親会の雑談

メモってないので、印象に残った話だけ

###Rails Tutorialは実はherokuのhobbyプランだよ
静的なやつに飛ばしているだけだから。
13000人くらいのアクティブユーザーをそれでさばけるらしい。

##例えばredmine１つ導入するのでも反対にあうような息苦しい会社なら？

  • 提案する人が、今までのやり方と新しいやり方とで
    「これだけ違いますよ」という数字を出そう。
  • 測り方が多少雑でも、1.X倍とか大きく効率化できるのなら無視できない。
  • 要は、「提案者がただやりたいだけ、やってみたら大して変わらなかった」と区別できる判断材料を与えることが大事
  • 本当に数字出たのにつまらない政治で反対されたなら、上司にちくりますよ、と脅していい（笑）

ここらへんは経営者らしい、現実的な視点だと思った。
ついついぼくらSIerは硬直した組織で疲弊してて、文句を愚痴るだけになりがち。
解決のために誰を巻き込むか？ってのは、ベンチャーでも考えなきゃいけないことだし。

RSpec勉強すべき？

（そりゃ出来たほうがいいけど）できるかどうかはさほど重要ではなく、
出来ないものに出会った時、どう対応するか力を磨く・見せる方がずっと大事。

Elixirの話とかPythonの話とか

生のPythonは遅いので、機械学習用のいろんなライブラリがCで書かれている。
Rubyはエンジニアファーストで設計された言語。
書いてて楽しいと感じるエンジニアがやはり多く、
ErlangをRuby風に書きたい→Elixir とかそういう試みが多いんだとか。

17
37
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
17
37

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?