ねこ日記

プログラミング学習の記録

環境変数の復習とRailsアプリ中の環境変数

Railsアプリを作っていて「環境変数が設定されていないのでエラーになる」などの文言に出会ったことが何度か・・・。 「開発環境」「本番環境」などの言葉があるので、アプリで環境変数を扱う場合、環境=開発・ステージング・本番のどれか、というイメージを持ってしまって挙動がうまくできませんでした。 だけれどもどうやら違うぞ、環境変数についてきちんと抑えないといつまでたっても環境変数でつまづいてしまうのではと思ったので再学習しました。

そう、これは再学習。環境変数自体は一回やったはずなんだけどな・・・。

だけどアプリを絡めて環境変数をどう扱うのか整理できたので再学習してよかったです。

環境変数とは

環境

開発環境や本番環境とかの環境は別物だそうです!!(知らんがな!って思った。)

環境変数でいう環境とはOSの事を指しているそうです。

「環境」っていう言葉が厄介に思えるのはわたしだけでしょうか・・・(あんま聞かないから多分私くらい)

プロセス

プログラムを実行する単位のことを「プロセス」といいます。

例えば「rubyプログラムを実行する」とか「ブラウザを起動する」とか。 「シェルを起動する」というのは1プロセスです。

変数(シェル変数)

シェル上で作った変数を「シェル変数」といいます。 単に変数と呼ぶ方が多いのかも?なので以下変数とします。

変数は1プロセス上で有効です。 起動中のシェルで作った変数はそのシェル上で有効です。「シェルを起動する」というのは1プロセスなので、シェルを終了すると消えてしまいます。シェルを再起動したり別のシェルを立ち上げたりしても先ほどの変数は存在しません。

変数の作成と参照

$  NAME=neko     #  変数の作成。"="で代入。 =の前後にスペースは入れない。
$  echo $NAME    # echo:文字列を画面に表示。 $:変数を参照。
neko

環境変数

シェル変数は現在実行中のシェルだけで有効な変数ですが,環境変数はシェルから実行したコマンドにも引き継がれる変数です。

シェル=親
シェルから実行したコマンド=子
子からさらに実行したコマンド=孫
のように親子関係で呼びます。 親で作った変数はシェルのなかで有効で、子や孫には無効。 親で作った環境変数は子でも孫でも有効です。

環境変数の作成と参照
変数のとほぼ同じですが、代入する時にexportとつけることで環境変数となります。

$ export NAME=neko   # export:環境変数を作る
$ echo $NAME
neko

環境変数も親を終了させると消えてしまいます。 そうしないためには、環境変数を保存するファイルを作って実行するという方法があります。

Rails環境変数

Railsアプリは例えばRails serverコマンドでアプリを起動しますが、そのRails serverコマンドはシェルでたたきます。そのシェルとの関係でいうとシェルが親でRailsアプリは子にあたります。

したがって、親(シェル)で子(Railsアプリ)にも有効な環境変数を作成しRailsの中で呼び出して使っていきます。

環境変数を使う理由

大きく分けて2つ理由があります。

  1. セキュリティの問題
  2. 外部接続の問題

1.は例えばパスワードとか、API連携に必要なKeyとか。外部に知られたらやばい!っていう情報を環境変数として取り扱いソースコードからは分からないようにします。

2.はDBが代表的な物のようです。 同じソースコードを持つRailsアプリでも、例えば開発環境と本番環境(この環境は環境変数の環境とは違う・・・)では異なるDBを使用します。どのDBを利用するのか指定するためにはDBのURLが必要ですがそれを明示的にソースコードの中に書くと、コードをpullするたびに書き換えないといけないだとか、気づかなければ誤ったDBを利用することになってしまいます。

Railsアプリの環境変数の作成と参照
シェルで環境変数を作成し、Railsアプリで呼び出します。

シェルで環境変数を作成するのは上記と同様

$ export PASSWORD=neko

Railsアプリにある、その環境変数を呼び出したいファイル内で以下記述します。

ENV["PASSWORD"]

設定方法

シェルで環境変数を作りますが、そのまま親を終了すると環境変数は消えてしまいます。 それだとRailsアプリを起動するためには度々環境変数を作らなければなリません。その手間を解消するために環境変数を保存するためのファイルを作り、シェルの起動やRails起動のタイミングでそのファイルを呼び出せるようにする方法があります。 シェルの起動時に呼び出せるようにしたければシェルでファイルを作り、Rails起動時に呼び出せるようにするにはRails内にファイルを作ります。そういう時にdotenvなどのrubygemを使うと簡単に効率よく管理ができます。

参考記事

http://wa3.i-3-i.info/word11027.html

シェル変数と環境変数の違いをコマンドラインで確認する

シェルの基本操作法(後編3:シェル変数と環境変数) | 日経 xTECH(クロステック)

「何が分からないのか分かる」ための分析

何が分からないのか分からない

コード書くこと自体が好きで、分かんなくても辛くない人や楽しめる人もいるらしいと聞いたことがあります。でも私は「何が分からないか分からない」時は最悪な気持ちになりやすいです。「もはや自分が何者かも分からん・・・私は、なぜ、ここにいるんだろう」とか思い始めて分からない沼にはまっていくときもあります。

しかしながらプログラミング学習をしているとこのような状況があまりに多いのでこのままではよくないなと思ったのと、Fjord Boot Campでも「このような状況の解決方法を身につけることも勉強のうちだ」とアドバイスをいただいて、試行錯誤してみました。その結果として“「何が分からないのか分からない」から辛いんだな”と少し客観視するといくばくか気持ちが穏やかになるということに気づきました。

それに加えてこれまで、Fjordの駒形さんや夫、そして様々な勉強会で教えてくださる方々が「何が分からないのか分かる」ための対応について教えてくださってきました。そのことを踏まえ、自分で見つけた解決方法をメモしておきます。

冷静な時は「何だ、こんなの当たり前じゃないか」って思うんですけど、沼にいるときには頭の中からスッポリ抜けてるので、そういうときに読み返す予定です。

前提としては日本語です

答えにたどり着く一歩手前を目指す対応です

パターン1:単語の意味が分からない

対応

  1. 意味がわからんと思う単語を列挙する
  2. 書籍、辞書、google等で調べる
  3. 図を探してみる
  4. 書き留める
  5. (自分の言葉で言い換える)

1.だけでもやると、例えば「いつもこの言葉がわからないな」と意識できる。調べる気力がなかったり調べてすぐにわからなかったとしても、単語を意識するのはとても有効な気がします。

もしくは調べたけど書きとどめられないとか、自分の言葉にまでは落とし込めないなとかも、やろうとすると認識できるので、より具体的に「“どのくらい”自分がわかっていないのか」を知る有効な手段になります。

それから、図はかなりいいです

パターン2:文の意味わからない

対応

だいたい単語の時と同じ。

  1. ブログや記事を読んでみる
  2. 書籍、辞書やグーグルで調べる
  3. 図を探してみる
  4. 書き留める
  5. (自分の言葉で言い換える)

パターン1と2で違うなと思うのは、パターン1は「概念」という物を落とし込めるかどうかっていうのがキーで、パターン2は「その概念の使い方」がわかっているかどうかというのがキーなのではないかということです。あるいは方向性やゴールと言ってもいいかもしれないです。

パターン3:やり方がわからない

ゴールや方向性がわかっていても「どうやって?」というのが分からないとたどり着くのは困難なので、やり方を知るのはもっとも重要かもしれません。しかし、ここらへんから、誤った情報を採用しないという見極めと判断が求められる気がしています。そしてそれが難しい。 したがって、正しい情報にアクセスするという点で順に列挙します。

対応

  1. 公式ドキュメント
  2. GitHubのReadmeやwiki
  3. 書籍
  4. ブログや記事・・・前提の環境や書かれた時期は必ず確認する

誤った情報を採用しないという観点から、なるべく1.や2.がいい。やり方を調べる中でも単語や文章レベルで調べることを繰り返すことになるとは思います。 ドキュメントやソースコードなどで解決できるのが一番だと思うけど、私は今の所それだけだと自力で解読できず・・・。何言ってるんだこの人たちは、ってよく思っています。 だけど、その中で「ここはわかる。ここまではできる」「ここがうまくいかない」等どこまで自分ができるのかあるいは全くても出ないのか知ることはかなりの前進です!!!!

パターン4:目的がわからない

私のなかで、これが分からないと道を誤りやすいなと感じたのがこれ。 目的を分かってて作業するのと分かってないままやるのではだいぶ変わります。

対応(というか確認すること)

  1. 「私は今全体の中の〜〜の部分について◯◯ということをするために作業しています」
  2. 「◯◯な状態にしたいので、〜〜を△△に変更します」
  3. 「□□と△△ではうまくいかないのですが◯◯という観点ではどちらがいいでしょうか」

とか。◯◯の部分が目的。

特に私としては、学習していることや調べていることについて、1.や2.を自分で認識するように心がけるようにしています。

「何が分からないか分かる」と答えは近い

パターン1〜4のなかで自分がどれに該当するのか。
「単語レベルではわかるけど文章としてはわからない」かもしれない。
「単語、っていうか、もう何なら読み方もわかんない」かもしれない。
「何がしたいかわかない」かもしれない。
どんな状態だったとしても分からない自分を分析していけば「何がわからないか分かる」という状態に上がっていけるはず。 そしてそれができればもう答えに辿り着いているに等しいとも言えるのではないでしょうか。

何かを学習するということ

私は結構やりたがりで社会人になってからも新しいことをバンバン初めているタイプの人間です。なので学ぶことには慣れているつもりでした。この記事に書いたことはプログラミング以外の学習にも通じると思います。 でも特に、プログラミングにおいては、重点的に意識することが自分には合っていると感じています。

RubyKaigi2018に参加しました

はじめに

Rails Girls JPの支援を受けてRubyKaigiに初めて参加してまいりました。

諸事情で今年は参加は諦めようと思っていたのですが、行けて本当によかったです。今では「諦めよう」と言っていた自分が目の前にいたら「なんで?それでいいの?後悔するよ?」って言いたいです笑

予定があって2日目のセッション後に帰宅したのですが、2日間がとても濃いもので、3日間いられないのがとても残念でした。

ともかく、関係各位のみなさま本当にありがとうございました!

またそれに加えて@emorimaさんには宿泊面でもお世話になりました。 いつもプログラミングのことも教えてくださるし、気配り具合が素晴らしくて、いろんな面で頼れるお姉さんのような存在です^ ^

感想

技術的なこと

今回参加してよかったと感じた理由の一つは、最前線の人たち同士の熱くて楽しそうな姿に触れたことです。

話してる内容が難しくて、98%くらいわからなかったのは悔しかったですが。 逆に何がわかったんだろうか。 うーん。

わからないながらも、お話ししている方や聞いている方が何かについて色々議論しているのを聞けたことは、だいぶんモチベーションが高まりました。

そしてわからないなりにメモは頑張りました。 本来は「発表の内容をメモする」というのができたらよかったんでしょうが、そこまではできなくてもいいやと思って、聞こえてくる単語を拾うようにしていました。

そうすると単語レベルでも、わかったつもりになっている事に気づいたり、複数のセッションで何度も出てくる言葉はそれだけ重要なんだなと思ったりしました。

メモしたものはDropBoxに置いてるので、おいおいまとめたり調べたり、読み返したりしていく予定です。

それから、聴きながらハッシュタグ追いかけるのは必須でした。 「要するに〇〇という事だね」とか言ってくれる人がいるのがすごくありがたかったです。

国際会議

RubyKaigiは国際会議ということで、海外からの参加者が多くいらっしゃいました。通訳用のトランシーバーが出払ったとのことなので、100人以上いらっしゃったのかな??(よく知らない)

それに関連して感じたことは2つあります。 1つは @igaiga555さんがおっしゃっていたことと全く同じこと。

もう一つは「自分の世界狭いな」ってことです。 逆にいうと「もっと知らないことを知りたいし、もっと多くの人と出会いたい」と思いました。 なぜだかわからないですがプログラミング以外のことももっとやりたいとも感じました。 高校卒業して大学入学する時に思っていたような「もっと自由に、もっと楽しく、もっと自分に素直に、なんでもやってみたい!」っていう気持ちが湧きました。不思議な力が働いている!

f:id:neko314:20180605000405j:plain
世界各地からいらしてました!沖縄の密度が濃いのも発見でした

コミュニティ

以前「Rubyコミュニティーは温かい」と聞いたことがありました。 (私はまだRubyしかわからないですが、言語によって雰囲気にも傾向があるみたいです。)

実際、当日は国や地域によらず"Ruby Committer/Rubyist"というのが一つのコミュニティーというか、「全員が仲間!」っていう雰囲気を感じました。

様々な瞬間にとてもフラットな場だと感じました。 具体的には「初心者だし、話もわかならいし、・・・あ、あのスピーカーの人、話しかけてもいいのかな」みたいな、技術的なことを理由に遠慮することは不要だと思いました。

※もちろん、みなさん素晴らしい方々で心から尊敬しています!お話しするのも畏れ多いです。その割には遠慮が足りてないかもしれませんが、本当に尊敬しています!

関連して、私が初めて@a_matsudaさんのお話を聞いたRails Girls Tokyo,8thの場で「今日からみなさんはコミュニティーの一員です」っておっしゃっていたのを想起しました。

あの時はよくわからなかったんですよね、コミュニティーってなんだろうっていうこととか。 でも「あの人もすごい、この人もすごい、でも自分は・・・」みたいなのは一切要らなくて「私もここの一員なんだと思っていいんだ」っていうのをRubyKaigiで感じました。それが、すごく嬉しかったです。

そう思って日頃を振り返ると、@emorimaさんが誘ってくださったのをきっかけに何度かasakusa.rbに参加しているけど、みなさん気さくで親切にしてくださるので、感謝増し増しです。(とはいえ流石に私が行っていいのかは毎回迷ってはいますw)

そして何よりRails Girlsを通してお世話になっている方々に、今までよりも一層感謝の気持ちが湧いています。 みなさん優しすぎませんか、って言いたいくらいです。名前をあげると切りがないくらいたくさんの方に、この1年弱でありえないくらいお世話になっています。

本当に本当に本当にありがとうございます!

別問題として:懇親的な場でどんどん話しかけるのはやっぱり緊張する(どうやったらグイグイ行けるんすかね)

これからの目標

  • 今の私にとっての「できないことをできるようになること」を積み重ねる(人とは比べない)

  • お世話になりっぱなしではなく自分にやれることを見つけて実行する

  • 日本酒のことも語れるようになる!

  • 英語やるぞ!

果たして来年の私は・・・・!?

最後になりましたが、RubyKaigiを準備運営してくださった皆様に感謝いたします。ありがとうございました!

サーバーでRailsアプリを動かすための手順

今まで一応デプロイはHerokuでしたことはありました。 いよいよもっとちゃんと根本的にデプロイを理解することになり、初めてやる作業が多かったのでまとめておきます。

環境

[サーバー]
さくらのVPS Debian9

この前サーバーレンタルしたばっかりでMacSSH接続したぞ、くらいの感じ。

アプリをサーバーに持ってくる

イメージ

f:id:neko314:20180603110726j:plain

ローカル⇆Github
GitHub⇆サーバー
それぞれの間をうまく繋いぐように順番に操作していけばいい。

ローカル)⇆Github

これは特になんと言うこともない通常のあれ。

GitHub⇆サーバー

ここが初めてだったので、ちょっと操作に時間がかかりました。ゆっくり冷静にやればできたので、次からはもう少しスムーズにやれたらなと思います。

1.サーバーからGitHubリポジトリにアクセスするための認証を行う

SSH鍵認証を使う。ここではサーバーがクライエント、GitHubがリモート。

やり方としては、

  1. SSH接続の鍵認証についてssh接続を鍵認証で行う←このページのうち「クライアントにキーペアを登録」までをやる。

  2. GitHubのヘルプページ: Managing deploy keys | GitHub Developer GuideリポジトリのDeployKeyを登録する。1.で作った公開鍵(~~.pubって言う名前のファイル)の中身をコピペする。

  3. クライエントにリポジトリをcloneする。2.まで終えた後初回接続時に確認の画面が出る時、それはよしなに対処する。参照: SSHサーバのRSA fingerprintの確認方法 | server-memo.net

2. Railsアプリのあれこれを整える

異なる環境(Macとサーバー)でアプリケーションを動かすためにはcloneしただけではダメみたい。って知ってたけど、実際やってみる「なるほど、そう言うことか」と思いました。

  • gemをbundle installする

リポジトリをcloneすると言うことはGemfileもあると言うことだけれど、Gemfileがあるだけではgemがないままなので、インストールしないといけません。

この時に何かとエラーが出てたんですが、エラーメッセージに必要なgemや参照すると良いページが示されていたので、エラーとはいえそんなに苦しくはなかったです。

  • db:migrateする

データーベースも同じように新しい環境にファイルを置いただけでは実際のテーブルがまだない状態なので、rails db:migrateも実行します。

その後rails cなどでUsers.countなど簡単な操作を実行してみて問題ないことを確認〜( ・∇・)

上記まで終わったらrails serverも動くでしょ〜と思ったら、なんとエラーが出ました。

`rescue in block (2 levels) in require': There was an error while trying to load the gem 'uglifier'. (Bundler::GemRequireError)

bundle installはできてるし、何がダメなのかわからなかったのでこのメッセージをそのままググってみました。 そうしたらたくさんの検索結果が出てきたので、みなさんよく出くわす模様。

そのなかで参考にした記事: There was an error while trying to load the gem 'uglifier'. rails でこんなこと言われたら

その後なんとかrails serverが起動しました٩( 'ω' )و

次はNginxとPumaを使ってアプリが動かせるように設定をしていきます。また記事に残したいと思います!

テストの方針について

たくさんいろんな人にいろんなアドバイスをいただいています。

「なんのテストをするか」が最初の難関だったのですが、少し見えてきた気がしています。

RSpecで何をテストしたらいいのか決めてない時、とりあえずわたしが書いてるもの。 - Qiita

@akiko_pusuさんまじでいっつもお世話になってていろんなことを解説してくださいます。テストのことも「書いてみるね」って、こうして記事にしてくださいました。 超謙虚な方なんですど、ほんとなんでもわかりやすく教えてくれるし絵も上手だしワーママとしてお忙しい中でいつもきめ細かく接してくださる方。尊敬!@akiko_pusuさん、好きです!(突然の告白)

【初心者向け】テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?) - Qiita

@akiko_pusuさんの記事のコメントにある通りですが、@jnchito がテストをどう組み立てておられるのかっていう記事を書いてくださいました。(私のために書いてもらったと思ってて、一方的にすごく喜んでいますw)

自分の中にうまく消化できない疑問がこんがらがっていて、「テストコードを書く」という段階にたどり着くまでの道のりの長さにくじけそうになっていました。

まだ現在でもテストを書くのは全然できません。書くのはすっごく遅くて、なんならテスト以外のことも不十分だったりして、どこから手をつけたらいいかもわからずふてくされて魂が抜けちゃいそうな時が結構あります。

だけど、「テストはとっても大事だ」ってみなさんおっしゃいますし、「テスト書けないって言ってたらどこにも採用してもらえないよぉ〜」っていう言葉(愛の鞭)とか周囲の現役エンジニアさんにもらってるんで、時々はふてくされながらも、乗り越えて習得したいです!

Rails Girls Tokyo 9thでスタッフをしました

5/18-19に開催さたRails Girls Tokyo 9thにスタッフとして参加しました。

スタッフをやらせてもらえて、本当にありがとうございました。

Rails Girls Tokyo 9thについて

オーガナイザーの@usamimiemiさんがどんな思いで開催したのかなどブログに書いておられます。

tararico.hatenablog.com

スタッフとして参加して

前日まで

  • 経緯

オーガナイザーの@usamimiemiさんと@emorimaさんから声をかけていただきました。 確かいつかのRail Girls Tokyo, More!の場だった気がします。

  • 準備

会場の確保、食事の手配、人員の調整など事前に必要な様々なことはオーガナイザーさんが全てやってくださいました!

  • 名札

今回の初めての試みとして名札を新しく作りました。Rails Girls Kampalaの名札が素晴らしいので「こんな感じにしてみよう」っていうことで。

どう仕上げるかなど、作成はスタッフが担当しました〜。

具体的にはPhotoshop使いの@hinagimakiさんが印刷までやってくださいました!皆様から好評でした!さすが・・・!

  • 予習

ここまで書いて明らかなように私は大して仕事をしていなかったので、前回スタッフをしていた方が書かれたグラレコを見て当日のイメトレをしていました!(イメトレ大事!)

当日

スタッフとしてやったのは会場設営、受付など。 またGirls経験者ということでLTをさせていただきました。

インストールデイの私の大役としてインスタ風パネルを仕上げるというお仕事がありました。 「絶対負けられない戦いが・・・ここにある!」って感じでした。無事に成功してよかったです! 素敵なフレームを作っていただけてありがとうございました。無駄にならなくて本当に肩の荷がおりました。

f:id:neko314:20180527212243j:plain
記念撮影〜

ワークショップ中はお部屋の片隅にいたので、ワイワイとしている各テーブルを愛おしい気持ちと羨ましい気持ちとで見つめていました。(楽しそうだったので私もどれかのテーブルに入りたかったですw)

f:id:neko314:20180524224027j:plain
アプリ作成中の様子

感想

私は前回はgirlsの一人として参加して、今回初めて運営する側としてRails Girlsに関わりました。

運営側になってみて「前回参加した時の”楽しかった”っていう気持ちはこんなにもいろんな人の準備と思いと工夫と労力があって、いただけたものだったんだ」って心から思いました。本当に改めて、いつも支えてくださる皆様に感謝いたします。

今回の参加者の皆様からも「楽しかった」「参加してよかった」というお声があがっていて、スタッフとしてとても嬉しかったです!

私自身も、プログラミングスキルをもっと高めたり、人とのつながりを大事にして行こうと改めて思いました。

このRails GIrls Tokyo 9thと、Rails Girls、 Rails Girls Tokyoに関わった全ての皆様に、心よりの感謝を。 そしてこれからも皆様よろしくお願いいたします。

f:id:neko314:20180527210952p:plain

皆様のブログなど

参加してくださった@kasumi8ponさんの感想。 kasumi8pon.hateblo.jp

コーチの@komagataさんの感想。

docs.komagata.org

@katorieさんのコーチLTのスライド。 speakerdeck.com

自動テストの考え方

苦戦しているけれど、テストの書き方の基本が少しずつわかってきたので、まとめ。

そういえば、ブログを書いたり日報を書いたりするのがとても下手だと自分で思います。

読み返した時に自分が何に詰まっていたのか、それがどんな原因で、どう対応したら解決したかっていうのを意識してまとめて行きたいと思います。

戦いの記録

初回

  • 詰まっていたこと: バリデーションしかかける自信がない
  • 書いたテスト:modelのテスト(バリデーションだけ)
  • もらった助言:「”自分で書いたメソッド"のテストを書こう」

2回目

  • 詰まっていたこと:「自分で書いたメソッド」がどれかわからない。gemやrails自体の機能との区別がつかない。
  • 書いたテスト:gemとか全く絡めてないメソッドのテスト
  • もらった助言:「gemの機能を使って書き加えたテストも”自分で書いたメソッド”だよ」

3回目

3回目でこのテストならオッケー( ・∇・)いただきました。

初歩の初歩のテストコードでめちゃくちゃ苦戦して1週間使いました。辛かったです。

でも、オッケー頂いた時は、ただただ嬉しくで涙が・・・(● ˃̶͈̀ロ˂̶͈́)੭ꠥ⁾⁾

modelのメソッドのテストを書く(ユニットテスト

基本的なことなので、このブログをいつか読み返している私は、ここに書くことなんてもう分かってて当然でしょって思ってて欲しい。

メソッドが何をしているのか

”自分で書いたメソッドに該当するのが悲しいことにomniauthを使ったメソッドで、正直usageとかomniauthを使いこなしている人たちのコードをみて写して書いたみたいなところがあったので、「果たしてこれはどうテストしたらいいんだろう」というのを考えるもの大変でした。

こんなメソッド。

def self.from_omniauth(auth, singend_in_recource = nil)
    where(provider: auth.provider, uid: auth.uid).first_or_create do |user|
      user.email = auth.info.email || User.create_unique_email
      user.password = Devise.friendly_token[0, 20]
      user.name = auth.info.name
      user.avatar_file_name = auth.info.image
      user
    end
  end

このメソッドでやりたいこと。

where(provider: auth.provider, uid: auth.uid).firstの部分。 providerauth.provider(このアプリではTwitterのみ)でuidauth.uidの情報を持っている最初のユーザーを探す。

or_create do |user|は、該当するユーザーがいなかったらユーザーを新規登録する。

user.email = auth.info.email || User.create_unique_email  
    user.password = Devise.friendly_token[0, 20]
    user.name = auth.info.name
    user.avatar_file_name = auth.info.image
    user

ユーザーの登録情報はemailpasswordnameavatarで、provider(=Twitter)のアカウント情報を使うよ。

登録したユーザーを返して終わり。

というのがこのメソッドである。(テスト書かなかったらわからなかった)

やりたいことをテストする

where(provider: auth.provider, uid: auth.uid).firstの部分。 providerauth.provider(このアプリの場合はTwitterのみ)でuidauth.uidの情報を持っている最初のユーザーを探す。

テストに書くこと。 *「過去にTwitter認証を使って登録している」という状態なので、テストではすでに登録したユーザーのデータを作成。

before do
    user = User.create(
    name: "TestUser",
    email: "testuser@example.com",
    provider: "twitter",
    password: "testpassword"
  )
 end
  • providerauth.provider(このアプリの場合はTwitterのみ)でuidauth.uidの情報を持っている最初のユーザーを探す」をコードにする。
it "authenticate an user" do
    user = User.where(provider: "twitter").first
    expect(user.name).to eq ("TestUser")
end

or_create do |user|は、該当するユーザーがいなかったらユーザーを新規登録する。

  • 「ユーザーの登録情報はemailpasswordnameavatarで、provider(=Twitter)のアカウント情報を使う」をコードにする。
 it "create an user through Twitter's API" do
              user = User.create(
                name: "OtherUser",
                provider: "twitter",
                password: "otherpassword"
                )
              expect(user.email).to be_empty
            end
Twitter認証の場合、アカウント情報にeメールアドレスがないっていう問題があるので、そこは別のメソッドとテストで書いています。

初めてテストっぽいテストを書いてみて

今回はfjord Boot Campの課題だったので、メソッドが先にあって、それを追う形でテストを書きました。 ですがテスト駆動型だとテストを先に書いて、やりたいことを明確にしてからメソッドにしていくんだなという感覚が少しは分かってきた気がします。

しかしまだこれはちょっとしたユニットテストに過ぎないし、もっと美しい書き方があるそうなので、もっともっと努力をしていきたいです。

テストを書くのは大変そうですが、テストを通してアプリ全体の設計やコードを美しくするというマインドも高めて行けたらなって思います。