プロジェクトのリモートリポジトリで他のメンバーのプルリクがmergeされたら
他のメンバーの作業ブランチがリモートレポジトリでmasterブランチにマージされた
↓
自マシンのローカルレポジトリのmasterブランチをgit pullで同期
git checkout master
git pull
↓
（その後、自分がプルリクエストを送りたい場合）
↓
対象の作業ブランチでmerge masterする
git checkout some-branch
git merge master
↓
mergeする際にコンフリクトが発生するとそのファイルはaddされず、ステージされない
↓
コンフリクトを解決して、そのコンフリクトしていたファイルをaddしてcommit
（コンフリクトは解決しなくても、addすればコミット＋マージ自体は行えるので注意）
git add .
git commit
↓
（コミットメッセージの編集画面が表示される）
↓
コミットメッセージにコンフリクトの内容が含まれるので、必要なら残す
↓
普通にpushして、プルリクエスト等を送る
git push origin some-branch
↓
おしまい
Devise使っててNameError: wrong constant name mailersが出た時の対処
version:
rails: 4.0.3
devise: 3.2.2
config/initializers/devise.rb
#config.mailer = 'Devise::Mailer'
↓
config.mailer = 'Devise::Mailer'
「config.mailer = 'Devise::Mailer'」のコメントを外したら動くようになりました。
エラーの状況が発現したのが、自分でMailer実装した後だったんで、あたりをつけて設定書き換えたら動きました。理由はあんま深くまで追っていないので想像ですが、Devise側で暗黙に決まっていた定数が新しく追加したメーラで書き換えられたとかなのかな、と。
deviseのRemberable機能をデータベースにカラムを用意して使用する方法
deviseでは様々な機能がはじめから用意されています。それら機能はモジュール化されており開発者の用途に合わせて選択できるようになっています。
その中に「rememberable」という、所謂remember meの機能も用意されていて、その機能なのですが、少し変わった設計でして、定石通りDB上にカラムを用意してtokenを保存するという仕様にはなっていません。
具体的な仕様は、DBに保存されたencrypted_passwordというハッシュ化されたパスワードを使用して、remeber meの機能を実現しています。
参考URL：
Devise3.2.2 のデフォルト設定では、Rememberable の remember_token のカラムがないのでソースを解読してみた | EasyRamble
で、この仕様、Omniauthなんかを使ってOauthのSNS認証でユーザー機能を実装しようとすると、deviseのfriendly_tokenなんかを使ってダミーパスワードを作らないとRemember me機能が使えなくなります。
で、この問題、DeviseではオーソドックスなDB上にtokenを保存する仕様に変更できるようになっています。
その手順はいたって簡単。
remember_tokenというカラムをUsersテーブルにつくる
この情報、GithubのWikiに記載がありました。その部分だけ引用します。
have a remember_token column in your model
Omniauthable, sign out action and rememberable · plataformatec/devise Wiki · GitHub
こんだけしか記載がありません。
以上のようにremember_tokenのカラムを用意すれば、ユーザーのレコードをcreateするときにfriendly_tokenを使ってpasswordを指定する必要はありません。
Rails4なのにMassAssignに関するエラーが出た理由
症状
Rails4 + Devise + Omniauthを使って認証機能なんかを作っていたのですが、何故かMassAssignに関するエラーが出てしまい、新規ユーザーのレコードが保存できない事態に陥ってしまいました。
WARNING: Can't mass-assign protected attributes for User: name, password
Rails4ではコントローラ側のStrongParametersでユーザーレコードの更新に使用するParameterを許可するはずで、なんでだー！Model側のエラーじゃないかー！と2日くらい悩んでいたのですが、理由は簡単でした。
理由
じぶんで「protected_attributes」のgemをインストールしていたから。
対策
なので、Gemfileからprotected_attributesを削除し、アンインストール。
反省
- 今回の事態を引き起こした理由
不用意なコピペ
特に意味も確かめずにコピペしていました。これではいけない。自分のコードについて、その意図をすべて説明できるようでなければならない。
- 今後の対策
不用意なコピペをしない、参照先のコードの意図を読み取る。ソースを深く読む。
なんか日本昔ばなしとかでありそうな話だ。思慮の浅い若者が、良かれと思ってとった不用意な行動によって墓穴を掘るみたいな。
「作りたいもの」の作り方
インスパイア元：プログラミングが上達しない or 勉強が続かない人へ:とあるIT系社長のブロマガ - ブロマガ
なんだよ作りたいものとか
よくプログラミング学習についてのエントリが盛り上がる時期がある。そのなかの幾つかのブログエントリで叫ばれるのが「作りたいものの有無」についてだ。彼らの主張としては、「作りたいも」があるからこそ、そこに試行錯誤のループがあり結果的にプログラマとして成長できるのだ、という感じの主張だ。これについては、まったく同意であるのだけど、じゃあ作りたいものが無い奴はどうすりゃいいの？という疑問が当然あると思うのだけど、議論としてそんなに盛り上がってない気がする。
なので、個人的な考えとして「作りたいもの」について考えを書いていこうと思う。
作りたいものは自己表現でも自己実現でもない
「作りたいもの」という言葉にはある種の純粋さ、ひたむきさ、ものづくり、的な雰囲気や響きを感じる。でも、そういう高貴な、仰々しいものでは決して無いと思ってる。だれでも作りたいものは持てると思ってる。作るものはなんでもよくて、モノマネでもなんか作ってみれば「試行錯誤のループ」は作り出せる。
クローンを作る
個人的には、特にWebアプリは、「掲示板が作れればなんでも作れる」と思ってる。
だから、多くの人は、よくある技術書のチュートリアルで「ブログ」や「掲示板」を作ると思うが、それを作った瞬間「あれ？これでたいていのWebアプリ作れるんじゃね？」ということに気づくはずだ。FacebookやTwitterなんかのWebアプリは個人でも作れる。いわゆる「CRUD」の仕組みはそこまで複雑ではない。だからまず前提として、「作りたいもの」の有無は置いておいて、「作るのは難しくない」というものがあるとおもう。
そもそもの企画を除けばエンジニアリングとして問題になるのは、あとでも述べるが、「セキュリティ」と「高トラフィックへの対応」ぐらいだと思う。もちろん個人ではなく集団での制作になればチームとしての開発手法への理解は重要になるが、ここでは割愛する。
何がしかの独創性あるサービスの企画を思いつけば、そこからは大変ではない。大変だけど。CakePHPやSymfony、Railsなんかのフレームワークの使い方を覚えれば個人でサービスをリリースすることのハードルはさらに下がる。
つまり、ただ作るだけならそこまで難しくないんで、なんか「既存のWebサービスの真似しちゃおうぜ」と。そこで作り切れれば結構可能性が見えてくる。そこで自分の理想を実現する手段を手にする。そうすれば「試行錯誤のループ」は見えてくると思う。
あとは「セキュリティ」と「高トラフィックへの対応力」
結局、ここですよね。何がしかの、とりあえず良識ある技術書は自分が指南したサービス開発の成果物を、今すぐデプロイしろとはなかなか言わない。最大の理由は責任を取れないからだ。
自分が指南したフレームワークはたとえ執筆当時は最新版でも、その後何がしかのアップデートが行われるのが通常だ。多くの場合、そのアップデートの理由は、広範な意味でのパフォーマンス改善か、あるいはセキュリティアップデートだ。ある瞬間での最高水準の技術指南は未来の悪癖かもしれないから、執筆者は読者が技術者として健全な態度であることを期待する。
結論
何が言いたいかといえば、作るものなんて何でもいいんですよ。ものまねでいいんですよ。ブログでもTwitterでもFacebookでも、結局は「あるコンセプト」を制限とUIによる演出で実現してるだけで、テキストデータのやりとりです。例えばInstagramのクローンを作って犬画像しか投稿できない制限を実装できれば、それはもう独自のサービスと呼べます。掲示板作れればなんでも作れますよ。ただ、その時点で公開してはいけないことを自覚できていれば、あなたは善良なエンジニアですね、っていう、ホントそれだけです。
よし、ものまねでもいいから、なんかつくろう！そこが試行錯誤のループの入り口です。
関連エントリ
