TECH EXPERT体験レビューDay17｜テックエキスパートやっぱスパルタだわ

テックエキスパート体験レビュー17日目です。今日は「テックエキスパートなかなかスパルタだわ」と思った事があったのでお伝えできればと思います。

カリキュラムに突如追加お題が入ってきた

テックエキスパートがスパルタだなと思ったのは、何の前触れもなく突如カリキュラムに追加でお題が課された事です。

そのお題というのは簡易なWEBサービスをあと4日で作れというもの。

前提条件を言っておくと、テックエキスパートのカリキュラムでは1日最低8時間前後くらいのカリキュラムが組まれていて、みんな必死にヒーヒー言いながら日々カリキュラムをこなしています。

そんな中突如、自分でWEBサービスを作れと。それも4日で。カリキュラムは据え置きで遅れてはならない。

こんなお題が降ってきました。幸いにも私は少し早めにカリキュラムをこなしているのでそこまでダメージは大きくないですが、進捗が遅れている方の場合、相当な時間を確保しなければこのお題をクリアすることはできないと思われます。

もちろん、お題の内容自体に関しては意味のあることでしょうし、文句はないのですが遅れをとっている方に対する配慮がないなあとつくづく思ってしまいます。

カリキュラム遅れると転職保証の対象から外れるので注意が必要

私が常々「進捗が〜」と言っている１つの理由がコレです。テックエキスパートでは、10週間の期間中にいくつか期限が決められていて、その決められた期限までにカリキュラムを終えられていない場合は「転職保証の対象外」となってしまいます。

しかもその期限というのが結構厳しく、現在の進捗だけで見ると全体の半分くらいの方しかその期限の進捗に乗れていないという状況です。（ちなみに与えられている目標進捗通りに進めると間に合いません。笑）

これってどうなんでしょうか、、。

まあ実際多くの方が巻き返して、期限に間に合わせるのだと思いますが、この突然のお題といい、転職保証の期限といい結構精神的に追い詰められる人もいるのではないかなあと実感しています。

常々、転職成功率98%みたいなことを言っていますがそれって実際に入校した人を母数にするとどれくらいの数値になるんだろう。数字マジックかなと勘ぐってしまいます。

備忘録コーナー

それではここからは備忘録コーナーとなります。

includesってなんだっけ？

railsの中で例えば「Post.all」みたいな感じでデータを取ってくる際に「Post.all.includes(:user)」みたいな形で書く時があります。

これはN +1問題を解決するためにincludesメソッドを使っているのです。

N + 1問題に関しては別の記事で解説しているので割愛しますが、簡単に言うとSQL（データベースの司令）がめっっちゃ効率悪いことをしている状況ということです。

で、そんな時にincludes(:対象のモデル)を入れると効率よくデータを取ってきてくれるというワケ。

これを使うのは「1対多」の関係になっている時なので、そういった場合にはN +1問題に気をつけつつ、解消したければincludesを入れていくと言う感じ。

部分テンプレートの使い方

railsではrenderメソッドを使ってビューに部分テンプレートを適用することが可能ですが、ちょい応用みたいなのが出てきたので備忘録。

通常
render partial :テンプレ名

ローカル変数使う時
render partial :テンプレ名, locals: {使う変数名:　元の名前}

で、これに加えてcollectionというのがあります。collectionを入れると部分テンプレをeachメソッドの代わりに使うことができます。（厳密に言うとコレクションが複数の場合、１個ずつ表示する）

ちょっとこちらの記事から引用させていただきますが、要するに以下のように使うことができるのです。

<% @users.each do |user| %>
  <ul class="lists">
    <li class="list">#{user.name}</li>
  </ul>
<% end %>


上記は以下に書き換え可能

views/yyy.html.erb
<ul class="lists">
  <%= render partial: "user", collection: @users %>
</ul>

 

hamlの時のrenderの省略形

ちなみにこのrenderですが、hamlで記載する場合は大幅に省略して記載することが可能です。

<%= render partial: "user", collection: @users %>

がhamlだと

=render @users

もはや原型を留めていないのですが、このように書くことができるので覚えておくと良さそうです。

if文を三項演算子でめちゃくちゃ簡単に書く！

Rubyなどで下記のようにif文を使った条件分岐の式がありますが、これを三項演算子を使ってとってもスマートにかけるそうです。

通常のやつ
if 条件
　式１
else
　式２
end

三項演算子

条件 ? 式１ : 式２

name== true? redirect_to root : exit

すみませんめちゃくちゃ適当なので合ってないかもなのですが、とりあえず「？」が成立する時、その右のアクションを行い、それがfalseの時は一番右の行動を行うというイメージです。

参考記事；https://qiita.com/lasershow/items/160c854e4256ba596ec5

 

Railsでテストが出来るRspecジェム

railsでテストをする場合はRspecというGemを使うのが便利です。通常通りgemファイルに追記してbundle installすれば使えるようになります。

テストコードはこんな感じ
describe "setumei" do
 it "ここで検証したいことを書く" do
   expect( 1 -1 ).to eq 2
 end
end

ポイントはこの「1-1」の部分でここが条件になり、 eq２を期待するといった感じです。なのでこのテストコードだと「１＋１は２だよね？」ってことを検証しています。

eqの部分をマッチャという

ちょっと笑ってしまいそうなのですが、上記の「eq」に当たる部分をマッチャといいます。このマッチャはeq以外にも色々とあり、それによって様々なテストができます。

例えば「includeでエラーコード○○含まれてるよね？」みたいにしたり「validでバリデーションされてるよね？」みたいなことができます

例えばerrorsメソッドであれば、バリデーションにより保存ができない時に「なぜできないのか？」ということまで出力が可能です。

be_validマッチャではexpectの引数にしたインスタンスが全てのバリデーションをクリアする場合にokとなるマッチャです。

factory_botというGEMでインスタンスの生成をボット化

ここまで紹介してきたテストコードを実施する際にはインスタンスを生成して検証する必要がある場合が多いのですが、その時にいちいちインスタンスを生成するのは面倒です。

user = User.new(nickname: "aaa", email: "aaaaaaaaaaa", password: "aaa", password_confirmation: "aa")

これを毎回作るの面倒！

そこで活躍するのがfactory_botです。これを使うことで検証したい部分以外のインスタンスを自動生成できます。で、このfactoru_botを使うにはbuildメソッドとcreateメソッドを使います。

user= build(:user)みたいな感じでインスタンスを生成できる

※ここの「user」はファクトリーボット内で定義したユーザーの意

この２つ基本的な機能は同じで、インスタンスを生成します。しかしbuildメソッドではDBにデータが保存されません。

一方でcreateメソッドならDBに保存までできます。なのでダブりチェックとかをしたい場合はcreateで作ってからbuildで次のインスタンスを作るのがいいのでは？と思っています。

エラーメッセージ取り出したい時、複数ある場合は配列でとる

例えば「○文字以上ならパスさせない」みたいな検証をする際ですが、この場合エラーメッセージは複数あるので配列に保存されています。

そのためそのような検証をする際には少し工夫が必要です。

user = build(:user, nickname: "aaa")
      user.valid?
      expect(user.errors[:nickname][0]).to include("is too long")

テストコードを書く際の原則

テストコードを書く時には以下のことを意識する