気ままに気ままのエンジニアブログ

定期的に得た知見を気ままに発信中

【Rails】 Called id for nil, which would mistakenly be 8 -- if you really wanted the id of nil, use object_id Rails.root:~の解決方法

こんにちは。

昨日は、蝉の音を聴きながらそうめんを食べ、真夏を全身で感じてました。

どうもハチマキです。

はじめに

業務で発生したエラーですが、解決方法の記事を探すのに若干手こずったためメモを書いていきたいと思います。

本日の概要 : Called id for nil, which would mistakenly be 8 -- if you really wanted the id of nil, use object_id Rails.root:~の解決方法

環境

事象

featureテストを書いた際にエラーが発生
※ただこのエラーを解消する必要があるのかは別途考える必要がある(nilに対してidメソッドを呼んだときにエラーを表示するため、解消するとnilでもエラーにならなくなってしまうため。)

エラー例

Rails開発中に以下のようなメッセージが表示されることがよくあるそうです。

Called id for nil, which would mistakenly be 8 -- if you really wanted the id of nil, use object_id Rails.root:~

問題点

「whiny nil」と呼ばれるものがオンになっていた

解決方法

config/environments/test.rbファイルを開き、下記true設定されているものをfalseに変更

・修正前
config.whiny_nils = true
  
・修正後
config.whiny_nils = false

この設定がオンになっていると、アプリケーションのコードでnilに対してidメソッドを呼んだときにエラーを表示されます。

【rspec / capybara】RuntimeError: Must pass a hash containing 'with'の解決方法

こんにちは。

この暑させっかく夏好きになったのに、もはや嫌いになりそう。

どうもハチマキです。

はじめに

業務で発生したエラーのメモを書いていきます。
忘れないうちのメモメモっと。

本日の概要 : RuntimeError: Must pass a hash containing 'with'の解決方法

事象

featureテストの書いた際にエラーが発生
具体的には、fill_inメソッドを使って、フォームに値が反映されているか確認するテスト

エラー例

Failure/Error: fill_in 'hoge'

 RuntimeError:
   Must pass a hash containing 'with'

問題点

大きく2点が問題でした。

  • :withパラメーターで文字列が指定されていない
  • labelでなくテキストフィールド側のIDに合わせた値ではなかった

解決方法

テストファイル

fill_in 'hoge', with: 'test''hoge'の部分はidを、'test'の部分はvalueを記述
click_on "更新"

expect(page).to have_text("test")

viewファイル

= form_tag(~~_path, method: :'post') do
 %ul
  %li
   = label_tag :hoge
   = text_field_tag :hoge, class: 'form-control'
  %li
   = label_tag :fuga
   = text_area_tag : fuga, '', size: "40×3", placeholder: "testです"
  
  %li
   = submit_tag '更新', class: 'form-btn'

これだけ!簡単でした!
IDがわからない場合は、ブラウザの開発者ツールを使って探すとすぐ見つかると思います。

【rspec】Ambiguous match, found 2 elements matching option "hoge"の解決方法

こんにちは。

夏の台風だけはやめてくれ。日々そう願っております。

どうもハチマキです。

はじめに

業務で発生したエラーのメモを書いていきます。
忘れないうちのメモメモっと。

本日の概要 : Ambiguous match, found 2 elements matching option "hoge"の解決方法

事象

自動テスト(rspec)を追加した際にエラーが発生

エラー例

テストファイル

Failure/Error: select 'hoge'
     
 Capybara::Ambiguous:
  Ambiguous match, found 2 elements matching option "hoge"

問題点

  • bottonやselectの要素が重なっている(フィールドが1つではなく、例えば1対Nの関連だったりして、同じ名前の複数のインプットが有る場合、以下のようなエラーとなるようです。)

解決方法

firstメソッドを用いることで解決!

・修正したソースコード
select 'hoge', match: :first

もしくは、idが〇〇の要素のセレクトボックスを選択したい場合
within '#〇〇' do
 select 'hoge'
end

【勉強会振り返り】VSCodeのコマンドテクニック

こんにちは。

もっぱら冬好きな私でしたが、歳を重ねるごとに夏の素晴らしさを感じてます。

どうもハチマキです。

はじめに

先日の勉強会で普段使っているVSCodeのテクニック共有会に参加してきました。
効率化を行う良いコマンド達の知見を得たので、改めて調べてみたので多少のアウトプットをしてみます。

勉強会でのゴールは、前より効率化できることでありプラグイン拡張機能)というよりは、
コマンドを中心としたテクニックという感じでした。

では、早速行きましょう。

本日の概要 : VSCodeのコマンドテクニック

  • コマンドパレッド
  • ショートカット設定
  • 画面分割
  • Zenモード
  • ファイルの開き方
  • カーソル操作
  • テキスト編集

コマンドパレッド

  • Ctrl + Shift + P
    • コマンドパレットを開く(各種アクションが全てこのコマンドから検索・実行が可能になる)

ショートカット設定

  • Ctrl + Shift + P
    • 「keyboard Shortcuts」を検索しショートカットキーを自由に設定可能

f:id:hachimaki37:20200810105226p:plain

画面分割

  • Ctrl + Shift + P(コマンドパレッド)でSplit Editor Right
    • キーボードだけで右分割に画面が分割される
  • option + ファイルクリック
    • 右分割に画面が分割される

Zen モード

  • cmd + k, z
    • 全画面のモードになる

ファイルの開き方

  • cmd + p
    • 開きたいファイルを検索することが可能
  • cmd + shift + e
    • エクスプローラーとエディタのフォーカスを移動する(フォーカスが当たっている状態で、キー入力するとヒットしたファイルがハイライトされる)
  • cmd + k, e
    • 開いているエクスプローラーにフォーカスされ、ファイルクリックすると参照できる
  • cmd + shift + f
    • 検索画面へのショートキー(ディレクトリ内等の検索条件を絞りたいときは、...から条件を絞ることが可能)

カーソル操作

  • option + →←
    • 左右の単語へ移動
  • ctrl + g
    • 指定行にカーソル移動
  • cmd + option + ↑↓
    • マルチカーソルを上下に追加

テキスト編集

  • cmd + d
    • 同じ単語を一括編集できる (そのまま連続でcmd + dを実行すると、同じ単語が複数選択される)
  • option ↑↓
    • 行の移動
  • Ctrl + Shift + L
    • 同じ単語を全選択する

まとめ

作業効率を上げていくためには、微々たることを少しづつ効率化していく必要があるなと感じました。
まずはVSCodeを自分色にカスタマイズしていくことから初めていきます。

undefined method `/' for nil:NilClassエラーの解決方法

こんにちは。

最近雨振りすぎで、モチベーションが持ってかれますが、力尽くで高めてます。

どうもハチマキです。

はじめに

今回は業務で発生したエラーのメモを書いていきます。
※undefined methodエラーは、「未定義」が原因で発生するエラーとなります。今回のエラー解決方法はあくまで数ある原因の中の一つのソリューションです。

本日の概要 : undefined method `/' for nil:NilClassエラーの解決方法

事象

プロダクトコードを書き終わり、いざ自動テスト(rspec)を追加した際にエラーが発生

エラー例

$ bundle exec rspec~~~
Failure/Error: without_tax = with_tax / 1.1
     
ActionView::Template::Error:
  undefined method `/' for nil:NilClass
 ・
 ・
 (省略)

ん〜今回触れてないのにエラーでたなぁ。。なんでや。

問題点

端的に言うと、「浮動小数点問題」というやつでした。
以前定義したtaxの計算式に正しいデータ型を定義していなかったことが原因。

解決方法

この問題を解決するためには、いくつかの方法があるみたいですが、先輩エンジニアの方に相談したところRuby標準のBigDecimalクラスを使った計算方法で解決に至りました。

▽修正したソースコード

without_tax = BigDecimal(with_tax) / 1.1

BigDecimalとは??
"浮動小数点数演算ライブラリです。任意の精度で 10 進表現された浮動小数点数を扱えます。"とのこと。

参考資料

library bigdecimal (Ruby 2.7.0 リファレンスマニュアル)
[Ruby]消費税計算にはBigDecimalを使いましょう - Qiita

                                            • -

完全に一人では解決できませんでした。。
日々勉強です。

以上、ハチマキでした。

Ruby技術者認定試験 Silver合格に必要なことを振り返る

こんにちは。

この時期の寝癖は、鳥の巣みたいになります。
小学生の時には、特定の人から焼きそばとあだ名を付けられたことを思い出しました。

どうもハチマキです。

はじめに

直近の目標にしていた「Ruby技術者認定試験 Silver」に先日無事合格しました。

心配性な私は試験対策に5つの学習法を試しました。
そこで感じた「合格するために必要なこと」「試験で重要なこと」の2点に絞り、書いていこうと思います。

ちなみに私の点数は82点(100点満中 75点が合格)でした。点数はボチボチですね・・
f:id:hachimaki37:20200630155443p:plain

では、早速行きましょう。

本日の概要 : Ruby技術者認定試験 Silver合格に必要なことを振り返る

  • 合格するために必要なことは?
    • 教材選び
    • 出題パターンに慣れる
    • 締め切り効果を使う
  • 試験で重要なことは?
    • 問題の見直しを最低3回は行うべし
  • 下記ご参考までに
    • Ruby技術者認定試験とは
    • 自身のスペック
    • 準備期間
    • 学習教材
  • まとめ
  • 参考資料

合格するために必要なことは?

1つ目:教材選び

様々な教材がありますが、結局合格するためにはどの教材をやるべきなのかについてです。
5つ試した結論は、[改訂2版]Ruby技術者認定試験合格教本(Silver/Gold対応)です。

この書籍の「模擬試験」と「※1 出題されやすい領域やよく出るタイプの問題」を十分に理解していれば、合格できると思いました。

理由は、大多数の問題(60%程度)はこちらの「模擬試験」がそのまま出題されるか、似たような問題が出題されました。
いわゆるこの「模擬試験」を理解(なぜが説明できる)できれば、6割程度は点数が取れるということです。

合格へのポイントは、残りの15%以上(合格ライン75%)の点数を取るために、何を行うかです。
他の記事でもよく出ている「※1 出題されやすい領域やよく出るタイプの問題」をこの書籍で念入りに学習、理解を深められれば合格にグンと近ずくように感じました。

※1

  • 文字列、配列やハッシュの操作
  • 2進数、8進数、10進数、16進数
  • 配列やハッシュのエイリアスメソッド
  • 破壊的/非破壊的メソッド →試験で3問程度出題されました
  • Fileのopenメソッドモード(r, r+, w, w+, a, a+)→試験で2,3問程度出題されました

※下記私が行なった学習を、合格を目的に独断と偏見で勝手に総評しました(ご参考程度に)

学習教材 [改訂2版]Ruby技術者認定試験合格教本(Silver/Gold対応) RUBY技術者認定試験 公式ガイド 公式模擬問題集PDF RubyExamination(REx) ミニツク
総評 ×
模擬試験実施回数 3回 3回 4回 30回 3回
  • 記号説明
    • ◎ 必ずやるべきです
    • ◯ やったほうが合格ラインに近づく
    • △ 時間があればやっても良いのでは
    • ×  やる必要はない

2つ目:出題パターンに慣れる

若干矛盾しますが、臨機応変に問題を解けるように設問パターンに慣れて置くことも重要に感じました。
単純な話、75%以上が合格ラインですので50問中38点とれば合格です。いわゆる最低12問は間違っても合格です。

試験では、ひねってくる問題や少々考える問題が見受けられたため、ある程度出題パターンに慣れ、回答できる状態を作って置くことが重要かと思いました。
そのためにお世話になった教材は、RubyExamination(REx)です。結果的に通勤時間などを活用し、30回くらいやってました笑

この教材の良いところは、隙間時間に取り組める点と出題パターンの量をこなせる点です。また、試験でも似たような問題はあったように感じます。
無料かつWeb回答で、解説もわかりやすいため、問題をこなし理解を深めていく上では良い教材のように感じました。

3つ目:締め切り効果を使う

これは試験を受けると決めたら、試験予約をすぐにしてしまいましょうという話です。

いつ試験をやるのかを決めておくと、学習の集中力がグンと上がります。
また、試験日を決めず学習していると、結局学習をやめてしまったり半年後に試験を受けるなどといったことが起きます。それをこの締め切り効果を使うことで事前に防ぐことができます。

心配性な私は、受けると決めた2ヶ月ほど前から試験日程を予約しました。笑

試験で重要なことは?

問題の見直しを最低3回は行うべし

個人的にはこれが重要かと思いました。
理由は、試験スタートから冷静な回答ができていない可能性が高く、初歩的なミスをしていることが多々あるためです(これは僕に限った話かも知れません・・)

試験は1時間半、一通り回答し終えてもまだ1時間程度は時間がありました。ですので、時間を気にする必要はありません。

結果的に3度、いや4度ほど徐々に確認設問を減らしながら見直しをしました(破壊的メソッドやFileクラスなど10問程度は修正しました)

見直しが終わり、残り15分程度になったところで、自己採点を実施。
11問程度不安な箇所がありましたが、逆に38問は自身があったので合格ラインに到達してると思い、試験終了を迎えました。

基本的には考える問題より、暗記問題が多く出題されるため、回答自体はサクサクと進むと思います。残りの時間をうまく活用し、点数を取れるように見直したことがよかったと振り返ると思いました。

下記ご参考までに

Ruby技術者認定試験について

公式サイトです。https://www.ruby.or.jp/ja/certification/examination/

自身のスペック

  • 文系/未経験からエンジニアになり半年

準備期間

  • 2ヶ月弱
  • 平日:通勤時間、お昼休みをメインに一日あたり約1時間〜1時間半
  • 土日:正直あまりやってません・・(やっても30分とかでした)

基本的な学習時間は、上記の形で進めておりました。
学習合計時間は、45時間前後〜65時間前後でしょうか。

まとめ

一番始めに取り組んだ模擬試験(RUBY技術者認定試験 公式ガイド)では100問中27点でした笑
その点数をみたときは、すでに絶望してました。そこから少しづつ学習を初めて、結果的に全ての教材で9割ほど点数が取れるまでになりました。
結局9割を取るためには、問題を解き続けて、わからないところをインプットし続ける。この繰り返しにつきました。

私は2ヶ月弱の準備期間を設けましたが、適切な学習、学習時間をしっかり確保できれば、1ヶ月前後で合格できる試験かと思います。
とか言ってますが、合格通知までヒヤヒヤで合格できて本当にホットしました・・

私自身、スキルも経験もまだまだなので、気を緩めず引き続き目標を立てて頑張りたいと思います。

参考資料

下記先人の方々が書かれた記事を学習スタート時から参考にさせて頂きました。

                                            • -

同じ教訓の方のソリューションになれば幸いです!
以上、ハチマキでした。

書籍"リーダブルコード" 第4部のまとめ

こんにちは。

土曜日の早朝から洗濯物を干すことで僕の休暇が始まります。

どうもハチマキです。

はじめに

業務で課題と感じる部分を解決するため、かの有名な「リーダブルコード」を読みました。
アウトプットとして、今回は最終部の第4部のまとめを書いていきます。

※4部では効果的で読みやすいテストの書き方、特定用途のデータ構文の設計と実装の検討について書かれております。

では、早速行きましょう。

本日の概要 : リーダブルコード第4部のまとめ

  • こんな方におすすめ(書籍"リーダブルコード"第1部まとめをご覧ください)
  • 第4部 選抜テーマ
    • テストの読みやすさ
    • 「分 / 時間カウンタ」を設計・実装する
    • 解説
  • 一言

第4部 選抜テーマ

テストの読みやすさ

鍵となる考え
  • 他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする
    • 大切ではない詳細はユーザから隠し、大切な詳細は目立つようにする
  • コードを完全にテストする最も単純な入力値の組み合わせを選択しなければいけない
  • テストには最もキレイで単純な値を選ぶ
    • 完璧な入力値を1つ作るのではなく、小さなテストを複数作る方が、簡単で、効果的で読みやすい
まとめ
  • みんながテストを追加しやすくなるように、テストコードも読みやすさが大切
  • 本物のコードをテストしやすく設計すれば、コードの設計が全体的に改善できる
  • 新しいテストの追加や修正を簡単にすることが大切
  • 具体的に
    • テストのトップレベルはできるだけ簡潔にする
    • テストが失敗したらバグや修正がしやすいようなエラーメッセージを表示する
    • テストに有効な最も単純な入力値を使う
    • テスト関数に説明的な名前をつけて、何をテストしているのかを明らかにする

「分 / 時間カウンタ」を設計・実装する

まとめ
  • 素朴な解決から始める(課題を抽出する)
  • 設計を試みる
  • 複数の下位問題に分割し、問題解決方法を考える(最終的にMinuteHourCounterになるまでの手順)
    • ConveryorQueue 最大長のあるキュー。シフト可能で合計ちを保持する
    • TrailingBucketCounter 時間経過に伴ってConveryorQueueを移動する。また、一つの時間帯のカウントを任意の制度で保持する
    • MinuteHourCounter 2つのTrailingBucketCounterを保持する。1つは1分間のカウントで、もう1つは1時間のカウント

解説

自然に読みやすいコードを書けるようになるための3つのステップ
  • 実際にやる
    • これから書くコードは読みやすいコードで書いてみる
    • 仲間に読んでもらったりしながら自分で「気付ける」ようになる
  • 当たり前にする
    • 一時の頑張りだけでは読みやすいコードにはならないため、続けることが大事
    • 誰かが読みにくいコードを書いていたら指摘してみる
  • コードで伝える
    • 自分が手伝って、新しい仲間も読みやすいコードを書くことが当たり前になるようにする
    • 自分たちが書いているソフトウェアを用いて、どうすれば読みやすいコードになるのかを伝えていく

一言

リーダブルコードを通して、コードを読みやすくするためのテクニックはインプットできた。
次はアウトプットしまくって、当たり前に読みやすいコードを書けるようになるために、まずはステップ1の「実際にやる」を実践して行こうと思う。
そして、最終的には自ら伝えられるように、成長していきたいと思います。

                                            • -

これでリーダブルコードのまとめは終了です。
次は何読もうかなぁ。おすすめ書籍ありましたらぜひコメントで教えていただけると嬉しいです!

以上、ハチマキでした。