いつも忘れるRailsコマンド ルーティングを調べる編

パスやルーティングを調べたいときのあれこれ

環境

gem "rails", "~> 5.1.5"

ルーティングを調べる

bin/rails c でコンソール立ち上げたあとに以下

> show-routes

controller名に基づくパス生成ができるか確認

# hoge_controller.rb とかだったら
> app.hoge_index_path

※ニアミスだったりするとサジェストしてくれる

docker-comporse で立ち上がっているコンテナ内をbashでみたい

docker-composeとかで立ち上がったファイルの中身を覗きたいとか、見たい場合

コマンド

docker-compose exec {{docker-composeで指定しているサービスの名前}} bash 

例

docker-compose.yml が下の場合

version: '3'
services:
  db:
    image: mysql:5.7
    volumes:
      - mysql_data:/var/lib/mysql

  web:
    build: .
    command:  bundle exec rails s -p 33333 -b '0.0.0.0'
    volumes:
      - .:/sample
    ports:
      - "3000:3000"
    depends_on:
      - db

こんな感じ

docker-compose exec web bash

swagger-codegenで生成される nodejs-serverのswagger-toolsのバージョンを変えたい

swagger-codegenって便利なんだけど、サポート言語と歩調併せている関係か部分的に最新版じゃないかったりする。なんでそれを歩調合わせたときのメモ

やりたいこと

• 最新版のswagger-toolsでお手軽モックサーバを立ち上げたい

問題

• 最新版のswagger-toolsは1.0.3、しかし生成されるのは1.0.1
• 1.0.3と1.0.1は結構UIに差がある、できれば1.0.3を使いたい

解決策

swagger-codegenにオプション的なものがないので力技で置換

例

# 前もってディレクトリを消しておく
rm -rf ./{{生成先のファイルパス}}
# swagger-codegenする
swagger-codegen generate -i {{生成元のjson}} -l nodejs-server -o {{生成先のファイルパス}}

# バージョンを差し替えたpackage.jsonをつくる
sed -e "s/\"swagger-tools\": \"0.10.1\"/\"swagger-tools\": \"0.10.3\"/"  {{生成先のファイルパス}}/package.json >  {{生成先のファイルパス}}/package_n.json
rm  {{生成先のファイルパス}}/package.json
mv  {{生成先のファイルパス}}/package_n.json  {{生成先のファイルパス}}/package.json

Railsの設定でDBのコンソールを立ち上げる

本番のRailsアプリケーションで直接MySQLで調査したい時に mysql -p -u みたいにやると長いパスワードのときにつらいのでそういうときのためのコマンド

$ bin/rails db -p

Rubyでハッシュのキーを全てローワーキャメルに変換する

すべてのキーをローワーキャメルに変換したいときってあったりなかったりするのでメモ

コード

  # hashのキーを全てlowerCamelに変換する
  # @param [Hash] hash 変換元のハッシュ
  # @return [Hash] 変換後のハッシュ
  def lower_camel_key_hash(hash)
    hash.each_with_object({}) do |(k, v), new_hash|
      lower_key = k.to_s.camelize(:lower)
      new_hash[lower_key] = v.is_a?(Hash) ? lower_camel_key_hash(v) : v
    end
  end

参考サイト

• 【Rails】Hashのkeyスネークケースから大文字とかキャメルケースにしたいとき - Qiita
• Rubyでハッシュを別の形式のハッシュに変換する方法 - give IT a try

Errorが起きた後の状態を調べるRSpecの書き方が全然見当たらないので書いた

表題の通り、Qiitaに投稿した。

RSpecでエラーが起きたあとの状態をテストするときの問題点と回避案 - Qiita

一応記事内では蛇足になりそうだったのでなんでこんなものを書いたのかの編集後記的補足。

今回実環境でやりたかったこと

サービスクラスを実装していたので、複数のテーブルのデータを1メソッドでザクッと変更する処理を書いていた。そのため、メソッドの処理が失敗してraiseしたらちゃんと他の処理もロールバックしているのかを調べたかった。

その末色々調べてみたこと

raiseすることを確認するのは以下のコードでできるのは探せば結構出てきた

# raise_error({{対象のStandardError}}) で確認可能。
expect { object.error_okiru_yatsu }.to raise_error(ZeroDivisionError)

ただこの場合には『エラーが起きる行動を実行すると、意図したエラーがあがる』というテストである

ただ個人的には

1. 例外が起きる何かを設定する
2. テストしたい行動を実行すると設定値のせいで処理が成功しない
3. 処理が成功しなかった場合に関連する値が意図しないものになっていない

とあった場合に3番目を確認したかったので、上の方法を混ぜるのは何か違う気がしていた。 そのため、記事内の処理をやるに至ったのだが、なんかコレジャナイ感をはらむ結論が出た。

なので今回はQiitaに書いてみた

今回割と微妙な内容ではあったが

• 日本語でコレに関しての情報がない
• 割と他の方法論があるのであれば知りたい
• ただはてブだと埋もれそう

などの理由からQiitaに書いてみて、突っ込まれたらそれを吸収する方法論をとりました。

まぁあんまり見られないかなと思いつつ、なんかフィードバックがあったら嬉しいなぐらいの気持ちです。

参考リンク

• RSpec でエラーを捉えらんないアレなミス - Qiita

BigQuery上でUTCのTIMESTAMPをJSTで比較する

世界基準の時間で入れようという気持ちが働いた結果、UTCでデータレイクに保存されていることがある。

ただ、集計で絞りたいときは大概日本時間なので、そういうときに書き換えるクエリ。方法論は色々あるけど直感的に書ける書き方。

前提条件

• STANDARD SQLです
  ( 補足：Google BigQueryの新機能 Standard SQLまとめ - Start Today Technologies TECH BLOG )
• 変換対象はTIMESTAMP , DATEはまた別

やり方

単純に比較したいだけなので、UTCに対し9時間加算する。

TIMESTAMP_ADD({{対象カラム}}, INTERVAL 9 HOUR)

ありがちな created_at を絞り込みたい場合は以下の感じ。

(TIMESTAMP_ADD(created_at, INTERVAL 9 HOUR) >= TIMESTAMP('2018-4-01 0:00:00') AND TIMESTAMP_ADD(created_at, INTERVAL 9 HOUR) < TIMESTAMP('2018-05-01 0:00:00'))

参考リンク

• Bigqueryの日時に関係する関数全部試してみた ①Date編 - Qiita
• BigQueryのStandardSQLで日付（date, datetime, timestamp）を変換する方法 - 寝ても覚めてもこんぴうた