就職先が決まりました
この度プログラマとしての就職先が決まりましたー！🎉
今までの経緯を簡単に記録しておきます✍️
これからIT業界へキャリアチェンジする方にとって少しでも励みになれば幸いです😊😊
目次
１．建設・不動産の仕事を退職
元々建設・不動産の仕事をしていました。
IT業界の若い人にとっては噂に聞くだけの世界かもしれませんが、電卓やFAXや書類の郵送が当たり前の世界🙂
パソコンが苦手な社員も沢山います。
彼らのメインの仕事は別にあって、パソコンを覚えることはあまり優先順位高くないのです。（ただし CAD 使える人はわりといます）
でもやっぱり人手不足が加速する中、 excel でも DB でも使って業務を正確に迅速に行えるようになっていかないと、手間がかかって残業も多いし、せっかく面白い仕事なのに大変でもったいないなと思いました。
そこで、IT技術を身につけて不動産業のメインの仕事以外の手間をできるだけ減らしたいと思い、IT業界へのキャリアチェンジを決めました！
２．プログラミングスクールで学習することにした
ITのことを知らずにいきなりIT企業に転職するのは不安がありました。
未経験でも求人はありますが、「誰でもできる」「パソコンが苦手でもOK」「未経験率○％以上」なんてちょっと信じられないというか、その程度の仕事しかさせてもらえなさそうだし、都合良く使い潰されそうだな〜と思いました笑
というのも自分が採用側だったら、新卒でもないのに何も知らない人が来たらめちゃくちゃ困る🤔
というわけで、まずはちゃんと勉強したいと思い、フィヨルドブートキャンプに参加することにしました。
フィヨルドは信頼のおける友人に教えてもらったうえで自分でもよく考えて選びました。
今でもこの選択は間違ってなかったなと思います！🙂
ただし誰にでもフィヨルドを推すわけではないのでそれは次に書きます💡
３．フィヨルドブートキャンプに参加
フィヨルドブートキャンプに参加しました。世田谷区にオフィスがあり、近くの人はオフィスで勉強するも良し、遠方の人は自宅でリモートで勉強するも良し、というスクールです。
私は関東圏内とはいえかなり遠いので、ずっとリモートで参加していました👩💻
以下、フィヨルドブートキャンプのいいところと注意点です👀
3-1. いいところ
プログラミング以外のことも広く学べる
これはフィヨルドブートキャンプに決めた一番の理由です。他のプログラミングスクールには Ruby と Ruby on Rails を勉強して終わり、という感じのがありましたが、ITの仕事するなら絶対それだけじゃ足りないと思いますｗｗ
フィヨルドはメインの Ruby 以外に Linux や HTML, Git, SQL など一通り触れることができるので、これはかなりありがたいと思いました🙏
リモートでもわからないところは聞ける
リモートで近くにメンターがいなくても、掲示板やSlackでわからないところを質問できます。
メンター以外にも他のユーザーが回答してくれたりします。
初心者であることに理解のあるスクールなので、どんなに初歩的な質問でも回答がいただけます。
何がわからないかわからない状態でも、考えていることや現状を伝えれば「こうしてみたらどうなりますか」「ここはどうなってますか」などヒントをいただけるので、ちょっとずつでも進むことができます。
課題が困難
良くも悪くも課題が難しいです！笑
課題にはいくつか条件が提示され、それを全て満たすものを作って提出します。
初心者なので、条件の意味がわからない、どこから手を付ければ良いのかわからないことが往々にしてあります。
スクールと謳っていますが丁寧に手順を示されるわけではないので、自分で調べて解決していく以外に課題をクリアする方法はないと思います。
でも仕事っていつもそうだよね〜と思いながら進めるのがいいです😂
既にやり方がわかっていたらラッキー。
そういう意味ではITの仕事に就く前にこういう経験できるのは良かったなと思います。
学習の経緯が成果として残る
フィヨルドでは、学習したことを日報をまとめたりブログを書くことになっています。
他の人の日報やブログを見ることができますが、かなり性格が出ます笑
日報、ブログに時間をかけてしっかりまとめておくと、後で自分が助かります。
どの参考書よりも自分にとってわかりやすい記事が残ります。
文章を書くのはちょっと面倒ですが、手を抜かなくて良かったなと思う点です。
就職先の斡旋
フィヨルドブートキャンプでは就職先を斡旋してくれます。
私は結果的にそこに至る前に自分で就職先を決めてしまいましたが、業界未経験者にとって斡旋はかなり嬉しいことです😆
変にブラック企業にあたる確率も低いのでは？と思います。何をブラックと思うかは人によって少し違うので、ゼロとは言いきれませんが。
3-2. 注意点
課題が困難
良くも悪くも課題が難しいです。
自分で調べて考えて時間をかけても、どうしてもわからないことってあります💦
そんな時に近くに聞ける人がいるとすごく良いと思います！というか、いないと無理かも笑
オフィスに行けばメンターがいますが、リモートだとこのへん結構困ります。
私は地域コミュニティにかなり助けられました！
わからないことは「私の現状の能力でこれ以上調べても理解できない」と結論が出るまで調べる。気になれば一人でも勉強会に参加する。わからないところはわかるまで質問する。
かなりエネルギーのいることですが、幸い地域のエンジニアの方々と知り合うことができ、貴重なお時間をいただきながら学習を進めることができました。本当に本当に感謝です🙇♀️
質問するのが結構難しい
リモートで何がわからないかわからない状態だと、質問も難しいです。
よくわからず的外れな質問をしてしまうと、いただく回答も当然解決には繋がらないです。
でも周りの皆様は本気で考えて回答してくださるので、質問できず進まないよりは質問して何かヒントを得られるほうがいいのかなと思います。
とはいえ質問者・回答者共に根気のいるやりとりになり、これが結構疲れてしまいますｗ
３．就職活動
私は斡旋先企業のこともよく知らないので、とりあえずプログラマとしてどこかに就職して経験を積んで、それから折を見て不動産業界に手を出していこうかなと考えていました。長い道のりですが笑
ところが縁あって不動産業界のITソリューションをやっている企業に無事11月に入社することが決まりました！
いきなり不動産系の仕事できるとは思っていなかったので本当にありがたいです✨
前職を退職してから約1年2ヶ月です。長かった〜！
４．思ったこと
これまでの経緯で思ったことをまとめます。
やりがいを感じるポイントは人それぞれ
エンジニアの仕事の魅力のひとつとしてよく言われる在宅ワークやリモートワークなど、私も最初はいいな〜と思っていました。
通勤時間もないし、そのぶん家のこともできるし、女性のキャリア的にはめちゃくちゃ魅力的なのはわかります。
一方で私は顧客やチームメンバーと直接顔を合わせて話す時間が好きで、直接お礼言われたりすることで達成感を感じて仕事が楽しいと思ってきたので、在宅ワークはちょっと孤独感じそうだなと思っていました。
特に不動産業界のIT領域を担っていきたいと考えると、顧客と会わない選択肢は無いなと思いました。
人と会うのが苦手な人もいれば、人と会うからこそ楽しいと思う人もいるので、自分のやりがいをよく考えて、会社の魅力的な制度が自分にとって本当に必要かどうか考えると、選択肢の幅が広がると思いました💡
女性エンジニアという言葉
IT業界は女性比率が低いらしいのですが、建設・不動産業も女性は少なかったです。
もっと言うと工学部は女性が少ないです。
なのになぜかIT業界に片足を踏み入れた途端、「女性エンジニア」「女性の働き方」「RailsGirls」など、女性であることにフォーカスをあてた言葉を目にすることが圧倒的に増えました👀
最初はなぜ女性というだけで集まるのかよくわからなかったのですが、それだけIT業界の女性進出が進んでいる気がします。これはすごいこと！
昔「全国土木系女子の会」という年1回のイベントで黒部ダムの見学に行ったことがありますが、全国規模のわりに小型バス1台で収まってしまいました😂
工事現場に行くと男性用トイレしか無いところもあるので、生理中とか本気で現場に行きたくなかったりします。
ゼネコンだと女性というだけで就職を断られることもあります。まあ確かに力仕事なうえに危険で責任も重い仕事なので、一応理解できますが…笑
こんなふうに、女性だから仕方ないって思っていたこと今まで沢山あったのですが、もしかしたら仕方なくなかったのかも？と思えるようになってきました🤔🤔
IT業界だけでなく世の中どんどん誰でも働きやすい雰囲気になっていってほしいです。
老若男女、適材適所です。
５．これからのこと
11月入社でしばらくの研修期間を経て、実務に入っていくことになります。
フィヨルドでは Ruby を学んだのですが、就職先で扱う言語は Ruby ではないので、また1から言語を学ぶことになります。
このブログは引き続き学習記録をちまちまと書いていくかもしれませんのでよろしくお願いします😎
初めての Rails 学びメモ
最近はずっと rails の勉強をしています！
最初はrails が自動で作ってくれる沢山のファイルをどう触っていいのかわからなかったのですが、ようやくある程度自分で考えて編集できるようになってきました🎉
細々と学んだことがあるので、自分の記録としてブログに書いておきます💪
rails 慣れてる方にとっては読むほどのことではないと思いますが、本当に初めて触る方にとって何かヒントになればと思います😊
１．Ruby on Rails 概要
わからないところをわかるようになるには、調べてそこに書いてあることが解読できないと意味ないです。
なのでなんとなくわかってきた概念を自分なりにまとめました。
もちろん一概には言えなかったり言葉足らずなところがあるのは重々承知なので、揚げ足取りは受け付けません😙
とりあえずこういうことをイメージしたら一歩進めたよって話です。
２．どこでつまづいているかわからないとき
書いたコードがなぜかブラウザに反映されなかったり、POSTしたパラメータがなぜか表示されなかったり、「なぜか表示されない」系はブラウザにエラー文すら出てこないです…。
そのため、どこのコードを直せば良いのか見当もつかない時がありました😭😭
ブラウザの表示ばかりに気を取られて、裏で起きていることを見落としていた初心者っぷりです。
こういう時は、以下のところをチェックしたら解決できることが多かったです✨
- コンソール（railsサーバのログ）
エラー文やPOSTしたパラメータの中身が書かれています。
場合によっては解決方法まで教えてくれているので、よく読んだほうが良いです笑 - chrome の「検証」や「ページのソースを表示」
erb などで書いたコードが思い通りのHTMLになっているか確認できます。
私は form の action （POST先のURL）を確認することが多いです。
３．rails console の使い方（使い道）
POSTがうまくいかないときなど、色々調べていると「rails console で確認する」みたいなことが書いてありますが、「それのやり方がわからないんだよーーー！💀」状態でした。
$ rails cでコンソールモードになるのは知っていても、具体的に何を入力して何を見れば良いのかわからない。
今でもちゃんと使えているとは思えないのですが、最低限知りたいことを知るツールとしては使えるようになりました！
例えば User という名前のモデルがあるとしたら、User.newって入力すると User が一人生まれます。
これだけでは当然名前やメールアドレスなど必要な情報は全部 nil ですが…笑
でもDBの User テーブルが持っているカラムを見ることはできます。
これを見て「あれ、provider なんてカラムあったっけ？」なんて考えるヒントになったりします👀
普通なら自分で作ってるはずなんですけど笑
私みたいな初心者はいろんなところからコピペしてくるので、いつの間にか状況が把握しきれなくなりますよね〜👻
ちなみにこれをやってしまうと、今まで正常だったはずのビューで「name が nil です」ってエラーが出たりするので、カラムを確認できたらUser.last.destroyなどのコマンドで削除するのをおすすめします🤭
カラムを確認したいだけならUser.lastのほうが楽です。最後に作成した User のレコードを表示してくれます。
ただし User が既に1人以上いる場合に限ります！
このモデル名.newとかモデル名.lastとかの書き方は ActiveRecord と呼びます。
なのでActiveRecordで調べると他の書き方も知ることができます！
４．ビューの form とコントローラー
私がよくわからなかったのは、ビューで投稿フォームを作ったのに submit ボタン押しても POST されてないみたいだなということが多かったです。
例えばコメントフォームを作って投稿したいとき、なぜかコメントが保存されなかったら、Comment コントローラーを確認します。
new と create の違い、edit と update の違いをあまり気にせずなんとなくやっていたので、全然うまくいきませんでした笑
| アクション | コードが動くタイミング |
|---|---|
| new | 投稿ページを表示する時 |
| create | new のページで submit ボタンを押した時 |
| edit | 更新ページを表示する時 |
| update | edit のページで submit ボタンを押した時 |
submit ボタンを押す前はいくら create アクションの中身にコードを書いても動きません。
なのでビューに渡したいインスタンス変数などがあれば new の中に書きます！
「なんか edit メソッド何も書いてないけど動いてるし、このまま edit には触れずに update に色々詰め込も〜」なんて適当なこと考えていたからつまづきました😂笑
性格ですね、たぶん全然ここでつまづかない人もいっぱいいると思います。
５．ストロングパラメータ
ストロングパラメータは単語だけ難しそうですがそんなに難しくなかったです。
コントローラの下のほうによくあるこういう private メソッドです。
これは、悪意を持って変な情報を POST されないように rails が POST を受け付ける内容を制限しています。
キャプチャの例だと、 titleは受け付けてくれますがurlは拒否されます。
拒否されるとサーバ起動しているコンソールにunpermitted parameterと表示されます💪
他にも細々と注意点はありますが、ざっくりとしたのは以上です🎉
rails で RSpec を使ってみる
前の記事に引き続き、今度は rails のモデルに対して RSpec を使ってみます！
スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)の真ん中くらいから始めていきます。
目次
- １．Rails プロジェクトの作成
- ２．rspec-rails のインストール
- ３．rspec 用ファイルの作成
- ４．Blog モデルの作成
- ５．Blogのバリデーションを設定する
- ５．スペックファイルの編集
- ６．エラーメッセージのテスト
- ７．Entry モデルの作成
- ８．モデル間の関連のテスト
１．Rails プロジェクトの作成
myblogという名前のアプリケーションを作りたいので、以下の流れで進めます。
rails プロジェクトの新規作成なので細かいところは割愛します！
$ mkdir myblog$ cd myblog$ rails new
２．rspec-rails のインストール
rspec-rails という gem をインストールします。
RSpec公式サイトに最新のバージョンが載っているので確認します！2019年7月20日時点では3.8です。
Gemfile のgroup :development, :test内に rspec-rails を指定します。
42行目を追記しています。
ちなみに、デフォルトで書かれているchromedriver-helperはサポート終了しているそうで、このままにしておくと後で警告されます。
ここでついでに別の gem に変えておきます。
59行目を削除、60行目を追加です🙃🙂
webdriversという gem に変更です。
最後にbundle installを実行です！
３．rspec 用ファイルの作成
$ rails generate rspec:installを実行すると、rspec用のファイルが作成されます。
４．Blog モデルの作成
テスト対象のモデルがないと進まないので、とりあえず通常どおりBlogモデルを作成します。
$ rails g model Blog name:stringrails db:migrate
ターミナルの画面はこんな感じになっています👀
５．Blogのバリデーションを設定する
Blogモデルの何をテストするかというところですが、ブログの名前を入力必須項目にして、バリデーションが正しく設定されているかをテストします！
Blogモデル（blog.rb）に以下の1行を追加します。
validates :name, presence: true
５．スペックファイルの編集
スペックファイルにテストコードを書いていきます。
blog_spec.rbを以下のように書きます✍️
これを実行すると failure になります。
新規ブログを作っただけでは名前がないのでバリデーションエラーになって当然ですね💀
実行コマンドは丁寧にパスを指定しましたが、今はrspecだけでも大丈夫です！
多分パスを指定しない場合はスペックファイルを全部実行するのではないかと思います。
なお、スペックファイルの5行目を以下のようにしてブログの name が空でない場合、テストがパスします。
@blog = Blog.new(name: "BLOGNAME")
６．エラーメッセージのテスト
バリデーションエラーのメッセージに関するテストにはいろいろな方法があるみたいです。
今回はエラーメッセージにcan't be blankが含まれているかテストします👀
先程のスペックファイルの9~13行目を追記します。
@blog.valid?は、ここでバリデーションを検証することでエラーメッセージにエラーの値が格納されるとのことです。
参考サイト：Rspecでモデルのvalidateをテストするときの注意
これでテストは通ります🎉🎉
７．Entry モデルの作成
Blogモデルと同様に Entry モデルを作成します。
$ rails g model Entry title:string body:text posted_on:date$ rails db:migrate
８．モデル間の関連のテスト
今度は Blog モデルと Entry モデルの関連をテストします。
モデル間の関連は以下のとおりです。
- Blog has_many Entry
- Entry belongs_to Blog
本来はモデルファイルに関連を定義するのですが、先にテストから作成します！
先に Failure になるはずのことを行うことで、スペックファイルとモデルファイルが正しくリンクできていることを確認できます。
元サイトのテストコードで使われているhave_at_leastメソッドは今は使えないみたいなので、別の方法をとります💦
8-1. shoulda-matchers をインストール
Gemfile のgroup :testに shoulda-matchers を追記し、bundle installで gem をインストールします。
次に、/spec/rails_helper.rbに以下の1文を追加します。
require 'shoulda/matchers'
8行目のところです😙
同様に/spec/rails_helper.rbの最後に以下を追加します。
Shoulda::Matchers.configure do |config| config.integrate do |with| with.test_framework :rspec with.library :active_record with.library :active_model with.library :action_controller with.library :rails end end
これで shoulda-matchers の設定完了です！
8-2. テストコードを書く
blog_spec.rb と entry_spec.rb をそれぞれ以下のように書きます。
8-3. テストを実行する（失敗する）
$ rspec spec/modelsで2つまとめてテストを実行しますが、アソシエーションの設定をしていないので当然失敗します🤨
8-4. アソシエーションを設定する
blog.rbにhas_many :entriesを追加entry.rbにbelongs_to :blogを追加- entry のマイグレーションファイルに
t.references :blog, foreign_key: trueを追加 $ rails db:migrate
これでモデルの関連付けができると思います🎉
もし最後にうまくいかなかったら、DBを一旦リセットすると良いと思います！
$ rails db:drop$ rails db:create$ rails db:migrate
8-5. テストを実行する（成功）
最後にテストを再度実行して、成功していることを確認します！🎊
ruby で RSpec を使ってみる
最近ずっと rails の勉強をしているので学んだことをまとめているのですが、沢山学んだことがあって記事を書くのが難しいので公開までもうちょっと時間かかりそうです💦
全然ブログ更新していないので、今日は RSpec について勉強しました！
１．RSpec
RSpec というのは、プログラムの振る舞い(behaviour)を記述するためのドメイン特化言語(DomainSpecific Language:DSL)を提供するフレームワークだそうです。
簡単に言うとプログラムのテストを作るための言語ですね！
私が RSpec の基本的なことを学んだ記事。めちゃくちゃ参考になりました！💪
- 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」
- 使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」
- 使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」
- 使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」
２．テストの書き方
一番簡単なテストは以下の構文で書けます。
describe '計算' do it '1 + 1 は 2 になること' do expect(1 + 1).to eq 2 end end
いきなり複雑な書き方の解説は大変なので、テストで使う構文や機能を紹介します！
describe：テストのグループ化を宣言。it：テストを example という単位にまとめる。it do ... end：この中の expectation がすべてパスすれば、その example はパスしたことになる。expect(X).to eq Y：「XがYに等しくなる」という expectation 。context：テストのグループ化を宣言。条件を分けるときに使うことが多い。before do ... end：example の実行前に毎回呼ばれる。let(:foo) { ... }： { ... } の中の値が foo として参照できる。subject { X }： expectationをis_expected.to eq 'Y'という形で書ける。shared_examples 'foo' do ... end：再利用したいexampleを定義する。it_behaves_like 'foo'：定義したexampleを呼び出す。shared_context 'foo' do ... end：再利用したい context を定義する。include_context 'foo'：定義した context を呼び出す。pending：テストに保留マークをつける。ただし中断するのではなく、そのまま実行を続ける。 テストが失敗すればpendingとしてマークされる。 ただし、テストがパスした場合は pending にならないことによりテストが失敗する。skip：はそこから先は実行せずにテストを pending としてマークする。xit：it を xit に変更するとその example は実行されず、pending 扱いになる。
また、RSpecのマッチャには以下のようなものがあります。
| マッチャ | 意味 |
|---|---|
| to | 「～であること」を期待する |
| not_to / to_not | 「～ではないこと」を期待する |
| eq | 期待値と実際の値が「等しい」かどうかを検証する |
| be | 等号・不等号と組み合わせて、値の大小を検証する |
| be_truthy / be_falsey | その仕様にあわせて戻り値の真偽を検証する |
| be true / be false | true もしくは false であることを厳密に検証する |
| include | 「配列に～が含まれていること」を検証する |
| raise_error | 「エラーが起きること」を検証する |
| be_within(Y).of(X) | 「数値 X がプラスマイナス Y の範囲内に収まっていること」を検証する |
３．実際に書いてみる
スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)というサイトに、実際に手を動かして書ける解説があるので、やってみます！
ここから先の内容は上記のサイトに沿って進めた体験記なので、学習される方はそちらのサイトで学習してみてください〜！
所々違うやり方をしているので、つまずいた方にとって私のブログが何かの参考になればと思います笑
3-1. インストール
まず練習用に適当なディレクトリを作ってみます。私はrspec-practiceという名前のディレクトリにします！
rspecという gem を使うので、rails を使っていれば Gemfile に gem の名前を書いてインストールすれば良いのですが、適当に作ったディレクトリにはそのままでは gem をインストールすることができません。
ディレクトリ内で以下のコマンドを実行します！
$ bundle init
これによりディレクトリ内にGemfileというファイルが作成されます✨
この Gemfile に以下の1文を追記して保存します。
gem "rspec"
キャプチャの8行目です💡
保存したら以下のコマンドを実行すればOKです😊😊
$ bundle install --path vendor/bundle
念のためインストールできたか確認します。
rspec -vコマンドで RSpec のバージョンが表示されればインストール成功です🎉
ちなみにこれ以降も元サイトでコマンドがspecとされているところが、私の環境ではrspecで動きました。
多分バージョンの違いだと思うのですが、specで先に進めない方はrspecに置き換えて試してみてください👀
3-2. スペックファイルの用意
先程作ったディレクトリ内に、array_spec.rbというファイルを作成します。
RSpec では_spec.rbで終わるファイルがテスト用のファイルとして認識されるようです。
ここにテストコードを書いていきます！これをスペックファイルと呼びます。
スペックファイルの中身は以下のとおりにします。
（元サイトのとおりにやるとshouldが古いと言われるのでexpectに書き換えています）
テストが通るか予想してみると、最初に空の配列を定義しているので、2つの example は通りそうですね🙂
3-3. RSpec の実行
ターミナルで以下のコマンドを実行することで、書いたテストを実行することができます！
rspec array_spec.rb
2つの example がパスして、テストが成功しています✨✨
3-4. テストに失敗してみる
あえてテストに失敗して、どんな実行結果になるか見てみます。
array_spec.rbに以下のコードを追記します。
3つめの example ということになりますね💡
配列の要素を3つ作成し、それぞれの要素に空のハッシュを入れます。
配列の最初の要素だけにcat: "Nuko"を代入したつもりでテストを書いたら、実際は全ての要素にcat: "Nuko"が代入されていたという失敗例です😎
3つめの example が失敗しているので、赤でF(Failures)と示されています。
エラーの読み方はそんなに難しくないですね。そのままなので割愛します！
3-5. documentation 形式フォーマットでの実行
documantation 形式とは、RSpec の実行結果を仕様書風に出力するものです。
RSpec 実行時に–format documentation (-fd)というオプションをつけることでdocumantation 形式に出力できます。
先程のテストコードで試してみます！
ちょっと親切になったような…？
3-6. テスト成功にする
先程のテストをパスさせるには、以下の1行を書き換えます。
- @array = Array.new(3, Hash.new) # 間違い + @array = Array.new(3){ Hash.new } # 正解
3-7. spec ファイルの文字列に日本語を使う
describe や it に渡す文字列は日本語を使うこともできます。
文法的に違和感があったりするので、あえて日本語を使う必要はないと思いますが…笑
Omniauth
前回の devise でユーザ認証に続き、本日は omniauth（オムニオース）という gem を追加して、rails アプリに Facebook や Twitter などの SNS アカウントでログインできるようにします！
今回は Github アカウントによる認証をやっていきます。
※ devise と組み合わせて使うので、devise が完了している前提で進めていきます。
目次
１．OAuth
omniauthは、OAuth2（OAuth の version2）という規格を使っています。
OAuth2の仕組みについては、以下の記事がとても参考になりました！✨✨
２．omniauthで Github 認証
2-1. インストール
omniauth を使うには、以下の gem をインストールします💡
例によって Gemfile に以下のように gem 名を書きます。
gem 'omniauth' gem 'omniauth-github'
今回は Github ですが、 omniauth-twitterやomniauth-facebookなどもあります😊
Gemfile が書けたらターミナルでbundle installです！
2-2. registrations_controller 作成
registrations_controller を作成し、deviseのコントローラを継承します。
コンソールで以下のコマンドを実行します！
$ rails g controller users::registrations
そうするといくつかファイルが作成されます。
その中にcontoroller/registrations_controller.rbというファイルがあるので、以下のように書きます。
class Users::RegistrationsController < Devise::RegistrationsController def build_resource(hash={}) hash[:uid] = User.create_unique_string super end end
2-3. models/user.rb 修正
app/models/user.rbのdevise:のところに1行追加します。
キャプチャの6行目です🙂
:omniauthable, omniauth_providers: %i(github)
また、同じファイルに以下のようにメソッドを追加します。
def self.create_unique_string SecureRandom.uuid end def self.dummy_email(auth) "#{auth.uid}-#{auth.provider}@example.com" end def self.find_for_github_oauth(auth, signed_in_resource=nil) user = User.find_by(provider: auth.provider, uid: auth.uid) unless user user = User.new(provider: auth.provider, uid: auth.uid, name: auth.info.name, email: User.dummy_email(auth), password: Devise.friendly_token[0, 20] ) end user.skip_confirmation! user.save user end
2-4. routes.rb 修正
routes.rbのdevise_forに以下をように修正します！
devise_for :users, controllers: { registrations: "users/registrations", omniauth_callbacks: "users/omniauth_callbacks" }
2-5. devise.rb 修正
config/initializers/devise.rbの Oumiauth のところに以下の1行を書きます。
ちなみにENV['文字列']の文字列は環境変数であり、自分で名前をつけることができます💡
config.omniauth :github, ENV["GITHUB_ID"], ENV["GITHUB_SECRET"], scope: 'user,public_repo'
2-6. Github操作
Github の Developer Settings で、OAuth application を新規作成します✈️
ここで rails アプリと関連づけます。
Application name：アプリケーション名-developmentHomepage URL：http://localhost:3000/Authorization callback URL：http://localhost:3000/users/auth/github/callback
すると Client ID と Client Secret というコードが発行されます👀
2-7. envファイル作成
アプリケーションディレクトリ直下に.envファイルを作成し、以下のように書きます。
GITHUB_ID=Githubに出てきたClient ID GITHUB_SECRET=Githubに出てきたClient Secret
これは公開してはいけないので、忘れずに.gitignoreに.envを追加します🤖
Gemfile に dotenv-railsという gem を追加して、bundle installします。
これは.envファイルに書いた環境変数を有効にする gem です😎
2-8. migrationファイル追記
devise に関する migration ファイルのcreate_table :users do |t|以下の内容に追記します。
2-9. view修正
必要に応じてviewを修正します。
私の場合はあまり色々書きませんでした🌝
devise 使ったときに自動で_links.html.erbに以下のプログラムが書かれていたので、それを使います。
ログイン画面はこうなります！
2-10. books_controller 修正
books_controllerにも1行追加します。
before_filter :authenticate_user!
これでログインしているかどうかを判別し、コントローラへのアクセスを制御します。
2-11. omniauth_callbacks_controller の作成
app/controllers/users/omniauth_callbacks_controller.rbを新規作成します。
中身は以下のとおりです。
class Users::OmniauthCallbacksController < Devise::OmniauthCallbacksController def github @user = User.find_for_github_oauth(request.env["omniauth.auth"], current_user) if @user.persisted? sign_in_and_redirect @user, :event => :authentication set_flash_message(:notice, :success, :kind => "Github") if is_navigational_format? else session["devise.github_data"] = request.env["omniauth.auth"] redirect_to new_user_registration_url end end end
2-12. i18nについて
omniaith 関連の i18n については devise-i18n の gem に含まれているので、特別何もしなくても勝手に多言語化してくれました〜！
以上です！
はじめての devise でユーザ認証（試行錯誤記録）
本日は Rails のアプリにユーザ認証機能を付けます！
devise という gem を使います。
先に断っておきますが、試行錯誤を重ねたため、この記事の流れはちぐはぐかもしれません…😇
初めてdevise使った人のメモ程度に読んでいただけますと幸いです！
目次
１．ユーザ認証
ユーザ認証というのは、コンピュータにアクセスしようとするユーザが、アクセスを許可された本人かどうかを確認することです。
身の回りの例では、パスワードを使ったログイン機能や、ICカードや指紋を使った認証です🗝
２．devise を使ってみる
devise は rails のアプリでよく使われるユーザ認証プラグインです。
早速使ってみます！
2-1. deviseインストール
まず自分の rails アプリの Gemfile に以下の1行を追加します。
gem 'devise'
そしてコンソールでbundle installを実行し、deviseをインストールします。
2-2. 初期セットアップ
続いて、deviseの機能を rails アプリで使えるようにしていきます。
コンソールで以下の順番で4つ実行します💪
rails g devise:install #全体のインストール rails g devise user #ユーザーモデルを作成 rails db:migrate #userテーブルを作成 rails g devise:views #ビューの作成
全体のインストールの時、コンソール上にセットアップ方法が出てきます。
ここに書いてあるとおり進めていきます。
まずconfig/environments/development.rbに以下の1行を追加します💡
config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }
わたしの場合、コメントアウトで devise の設定であることをメモしておきました。
次にconfig/routes.rbを確認します。
2行目のdevise_forという行が自動で追加されています🌝
この時点で rails サーバを起動して routes を見てみると、以下のようになっています（抜粋）。
routes の見方はhttp://localhost:3000/rails/info/routesに接続です🚗
この一覧はコンソールでrails routesを実行しても見ることができます。
config/routes.rbに以下の1行を追加します。
root to: "コントローラ名#ビュー名"
ここには各々rootパスに設定したいものを設定するそうです。
rootということなので、多分/にアクセスした時の設定ですね😎
トップページにあたるところだと思います。
私はRailsの教科書で作ったbooks_appを使っているので、私の場合コントローラ名はbooks、ビュー名はindexになります。
books_contoroller.rbというファイルがあるので、ひとまず先に進めるはず！👼👼
参考記事：Railsの教科書
2-3. カスタマイズ
ここからは自分でカスタマイズしていきます🎈
ログイン状態の確認
devise には、ページに飛んできた人がログイン状態かどうかを判定し、ログイン状態ならコンテンツを表示、ログイン状態でなければログインページに飛ぶという動作をするためのヘルパーが定義されています😊
/app/controllers/application_controller.rbに以下の1行を書きます。
before_action :authenticate_user!
続いて/app/views/layouts/application.html.erbに以下を追加します。
<% if user_signed_in? %>
<p><%= link_to "ログアウト", destroy_user_session_path, method: :delete %></p>
<% end %>
ここでlocalhost:3000にアクセスすると、以下の画面になりました！
英語ですが、とりあえずログイン画面ができているようです。
メール認証
サインアップするユーザは、まず仮登録として登録メールアドレスにメールを送り、返信によって本登録とします。
/app/models/user.rbに:confirmableを追加することで、各種認証時の確認作業が定義できるようになります😐
5行目の最後のやつです👏
ここから試行錯誤していてかなり不安のある内容ですが、migrationファイルを作成します。
多分一度はうまくいかないので、次わかるようになったらちゃんと書きます😢
とりあえずやってみたこと。
rails g migration add_confirmable_to_devise
migrationファイルには以下のように書きます。
/db/migrate/yyyymmddxxxxxx_add_confirmable_to_devise.rbという名前のファイルです。
沢山書いてありますが、コピペしたい方は以下のサイトを見てください😊😊
How To: Add :confirmable to Users · plataformatec/devise Wiki · GitHub
今回は7行目と18行目のコメントアウトを取り除きます。
書けたらコンソールでrails db:migrateです！
ちなみに私は色々試行錯誤しているうちに devise に関する migration ファイルが2つできてしまってエラーが発生しました。
どちらか消すとうまくいきました！笑
その際、migrationファイルのConfirmableに関する部分にコメントアウトがあれば外します。
migrationファイルを含むdbディレクトリ以下のファイルを修正した場合、コンソールでrails db:resetをしないと反映されないです🤨
または db:dropとdb:createとdb:migrateを順番に実行します！
SMTPサーバの設定
メール送信の設定ができたら、SMTPサーバの設定をします。
letter-openerとletter-opener_webという gem を使ってみます！
Gemfile のgroup :developmentの中に以下の2文を追加し、bundle installを実行します。
gem 'letter_opener' gem 'letter_opener_web'
/config/routes.rbに以下を追加します。
if Rails.env.development? mount LetterOpenerWeb::Engine, at: "/letter_opener" end
10〜12行目のところですね👀
/config/environments/development.rbには以下を追加します。
config.action_mailer.delivery_method = :letter_opener_web
キャプチャの64行目です！
これでlocalhost:3000/letter_openerにアクセスするとrailsアプリから送信したメールが確認できるようになるはずです。多分。
サインアップ
railsサーバを起動して、サインアップ画面に行きます。
まだ日本語に対応していないので、英語のまま進めます。
（いじってる間にいつの間にかリンク増えてるのはすみません）
サインアウト
好きなところにサインアウト用のリンクを書きます。
私はとりあえず全部のページからサインアウトできるようにしました笑
３．i18nで多言語化
多言語化します！
devise-i18nという gem を使います。
※ devise-i18n-views という gem は上記の gem に統合されたので使いません！！
Gemfileに以下の1文を追加し、bundle installします。
gem 'devise-i18n'
これだけでロケールファイルがインストールされたことになるので、手動で yml ファイルを生成する必要はありません🙂便利〜！
インストールされたロケールファイルの中身は以下のリンクから確認できます。
あとはviewファイルのほうでちまちまとi18nに対応するようにt('.sign_in')など書いていくだけです。
自分で書かなくてもいい方法がありそうでよくわからなかったので、もしご存知の方は教えてください〜😊
はじめてのdeviseについては以上です。
ちぐはぐな情報ですみません…次使うときはもっと整理できるよう善処します！💪
ページング処理（kaminari）
本日は kaminari を使ってページング処理をやります！
目次
１．ページング処理
ページング処理というのは、見たほうが早いと思うのでキャプチャを載せます💡
このように、全部表示すると多すぎてしまう情報をページという単位で分けることです。
使用するメモリも少なくなり、ユーザにとっても見やすいようにするものです👏
２．kaminari
ページング処理をするために、 kaminari というものを使います⚡️
まず、RailsアプリのGemfileに以下の1行を入れます。
gem 'kaminari'
次に、Comtroller のページング処理を有効にしたいところを以下のように書きます。
def index
@books = Book.page(params[:page]).per(5)
end
これは、indexページに現れる@booksにページング処理を施しています📖
.per(5)で、5件で1ページにしています🙂
デフォルトは25みたいです💡
最後に、ビューファイル（ERB）の表示させたいところに以下の1文を入れます。
<%= paginate @books %>
これだけでとりあえずページング処理完了です！簡単！🎉
kaminariに関する多言語化（i18nのja.yml）は以下のとおりです。
ja:
views:
pagination:
first: "最初"
last: "最後"
previous: "前"
next: "次"
truncate: "..."
以上です🌝
