RailsでDBのカラム名を変更する
今回打ったコマンド
rails g migration RenameTypeToSchedule action:string
vim db/migrate/20121018151132_rename_type_to_schedule.rb
rake db:migrate
背景
"type"が予約後とはつい知らず、、にカラム名にしてしまった。
なのでカラムを変えなければ、、、
コマンド解説
マイグレーションファイルを生成
rails g migration Renameカラム名Toテーブル名 新しいカラム名と型
生成したマイグレーションファイルを編集
class RenameTypeToSchedule < ActiveRecord::Migration
def up
rename_column :schedules, :type, :action
# 呪文 :テーブル名, :旧カラム名, :新カラム名
enddef down
rename_column :schedules, :action, :type
# 呪文 :テーブル名, :新カラム名, :旧カラム名
end
end
upとdownで新旧カラムを書く位置が逆になっているのに気をつけよう
マイグレーションを更新
rake db:migrate
影響箇所
カラムを変更したら次のファイルの変更が必要になったよ
旧カラム => 新カラム
app/models/schedule.rb
app/views/schedules/_form.html.erb
app/views/schedules/index.html.erb
app/views/schedules/show.html.erb
なんかコマンドで一発変換できそうな気もするけど、あるのかな?
エラー見て手で直しちゃいました
おしまい
MatcherクラスのfindをEclipseでデバックする時の注意点
やること
MatcherクラスのfindをEclipseでデバックできないのを再現
原因を突き止めることはやってない
Let's 再現
java.util.regex.Matcherのfindメソッドをデバックします。
デバックで使用するのはEclipseのExpressionsです。
試しにこんなコードをデバックしますよ。
Matcher matcher = Pattern.compile(regex).matcher(input);int i = 0;
while (matcher.find()) {
System.out.println("ループ" + ++i + "回目です。");
}
例えば
String regex = "no[0-9]"
String input = "no0/no1/No2/no3"
としてみましょう。正規表現で一致する no0,no1,no3 なので3回ループが実行されます。
その時の出力は、次のようになります。
ループ1回目です。
ループ2回目です。
ループ3回目です。
それでは今回のテーマ、デバックをしてみます。
一回目は、期待通りに成功するパターンをやります。
variablesを見ながらステップオーバで検証
ループ1回目です。問題ない。
ループ2回目です。
ループ3回目です。
もう一度。
今度は、失敗するパターンです。
Expressionsでmatcher.find()の値を監視した状態でステップオーバで検証
一度もループに入ること無く失敗。
原因はわかりませんでしたが、デバックするときは気をつけて下さい。
git rebase がコンフリクトして困った困った。
バージョン管理にはgitを使ってます。
いつもgithubにある最新を取得する時には
git fetchってやってます。
git rebase origin/master
まぁいつかは出会うであろうコンフリクトについ最近(仕事以外の場面で)出会ったので、
その時の解決方法を書きます。
状況
今回はいつもと少しやり方が違いまして、
ブランチを切らずに職場からの変更とマイホームからの変更をやり取りを一括してmasterで行なっていたのです。
そりゃあすぐコンフリクトするわ。
まぁコンフリクト解決の練習にもなるし、仕事に影響が出るようなものではないからいいやとやっていたわけです。
(ちなみにdotfilesの管理です。)
masterに変更加えてとりゃー!
git fetch
git rebase origin/master
「しまっ!...」
それでは解決法を
コンフリクトなんて、
まぁ期待通りというやつですよ。
色々調べた結果。
コンフリクト直して、
git add .
git rebase --continue
すれば問題なく解決。
ちょろいもんですね。
ちなみに私はaddするところをコミットしてしまったりして上手く行かず、
何回かgit rebase --abort したりしてました。
公開鍵認証によるSSH接続をする
背景
今回はじめてMyマシンを購入した。
公開鍵とか秘密鍵は生涯一つで十分と教えられたので、仕事で使ってるやつをこっちに持ってきて使おうとした時にちょっとハマった話。
作業
cp [任意フォルダ]/id_rsa* $HOME/.ssh/id_rsaとid_rsa.pubが配備されていればいいのかな?
続いて接続を確認
ssh -T git@github.com
成功すると
Hi shimosuk! You've successfully authenticated, but GitHub does not provide shell access.失敗した時のはメモするの忘れた。ごめんなさい。。
失敗した?接続するには適切なパーミッションを設定する必要があるらしいですよ。確認してみてね。
chmod 600 ~/.ssh/id_rsaこのあと再び、接続を確認するとパスワードの入力を求められた。
パスワードが正しく入力できれば、上記のメッセージが表示され、git cloneとかでプロジェクトの取得も楽々。
おまけ
正直、パスフレーズは覚えていたけど、パスワードは全く覚えてなくて脇汗もんだった。
なんとか入社した時の初々しい気持ちを思い出しながら、何個か試してパスワードをヒットさせた。
成功してほんとによかった。
OmniAuthでハマったところ
参考にしていたのは Rails3レシピブック 190の技 の
第11章 ライブラリのところ
[183] OmniAuthでユーザ認証の仕組みを作る
Twitterを使ってユーザ認証をしようとした。
基本的には写経でOKでした。
ただ、omniauthの仕様の変更で幾つかハマったところが、
例えば、omniauth のバージョンが 1.0 以上の場合は
( Gemfile )と書かなければ行けなかったり、gem "omniauth"
gem "omniauth-twitter"
app/models/user.rb で、 auth["user_info"] のところが auth["info"] に変わって
( app/models/user.rb )と書かなければいけなかったり、user.name = auth["info"]["name"]
user.screen_name = auth["info"]["nickname"]
本の写経はやり方とか説明が親切で勉強になるけど、仕様変更とかでハマらないためにも提供先のソースは意識しなきゃいけないんだなと反省した。
Railsアプリで認証のための情報はバージョン管理に含めないために
OAuth認証使って Rails で、 twitter の bot を作ろうとした際に、 「 cunsumer key のあつかいどうすんだよ!」ってなった話。
明確に「これ!」という答えは無いらしく、今回は heroku を使うので以下で紹介する foreman を使う方法にしました。
それ以外の場合は下記に色々な回答があるので、参考にしてください。
http://qa.atmarkit.co.jp/q/2212
一応バージョンは関係無いと思いますが、参考までに
Rails 3.2.6
ruby 1.9.3p194 (2012-04-20 revision 35410)
どんな事するか
Railsアプリ内でに環境変数を用意します。
herokuの仕組みに
ENV['CONSUMER_KEY']とかやって値を呼び出せる仕組みがあるらしいので、それを利用します。
foreman (こんなやつ: https://github.com/ddollar/foreman )を使いますよ〜
ちなみに、 heroku の環境変数の定義のやり方は下記URLの日記に参考となるものが書いてあります。
http://d.hatena.ne.jp/akiinyo/20120522/1337674131
※ ごめんなさい。まだ自分は試してないのですが、この方は実際にアプリを動かしている実績があるので大丈夫かと、、(同僚なのでよく知ってる)。
http://akiinyo-blog.herokuapp.com/
https://github.com/akiinyo/AkiinyoBlog
やり方
それでは本題ですよ〜
まずは下記を Gemfile に追記したら bundle install を実行。
# Gemfileに記述
gem 'foreman'
続いて、 Procfile を新たに作成します。下記のような書き方で今のところ問題出て無いですが、
詳細を調べたい方は http://blog.daviddollar.org/2011/05/06/introducing-foreman.html を見て下さい
# Procfile の内容
web: bundle exec rails s
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
~更新(2012/11/23)~
下記のように書かないとHerokuで動かなかったので訂正
# Procfile の内容
web: bundle exec rails server -p $PORT
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
.env を作成します
ここに、認証に使うための公開するべきでないキーとかを環境変数として定義します。
# .envの中
CONSUMER_KEY=xxxxxxxxxxxxxxxxxxxxxx
CONSUMER_SECRET=xxxxxxxxxxxxxxxxxxxxxx
.gitignore への追加をお忘れなく
これを忘れて .env をcommitとかpushして残してしまっては意味が無いので、
# .gitignoreに追記する内容
.env
最後に、 .envで作成した環境変数を使いたいところで、 ENV['CONSUMER_KEY'] とすれば、ok!
# 任意のファイル
OAuth::Consumer.new(
ENV['CONSUMER_KEY'],
ENV['CONSUMER_SECRET'],
{site: "http://api.twitter.com"}
)
サーバを起動するときは
foreman start今までの rails s だとダメっぽいですね。
ちなみに、もし foreman を使わないと .env をと ENV['CONSUMER_KEY'] が上手く紐付かず、
OAuth::Unauthorized (401 Unauthorized)っていって怒らてたりします。
LLDecade 行ってきた感想を今更書いてみた
前回の日記でも軽く触ったけど、LLDecade行って来ました。
この時は発表する機会も多かったので(身内の中で)、面白い発表とかするにはどうしたらいいんだろう的なモチベーションだった。
メモを見返しても、面白かった発表のメモとかが多く内容についてはあまり触れてない感じ。
まぁ内容は、自分がまだまだ未熟なんで理解できないことが多くてメモしてないだけなんですけど、、、
ってことで参考になった発表など分析したことを紙じゃなくて、webの方にも箇条書きで書きだしておこう!って言うのが今のオレのモチベーション。
たくさんの色々なスタイルの発表を聞いた一日であったんだけれども、「わからないけど、面白い!勉強になる!!」っと感じた発表と「寝るな!!寝るな!!..zzz」って感じで自分との戦いを壮絶に繰り広げるタイプの発表があった。
魅力的な発表
自分が魅力的に感じた発表のタイプはこんな感じ。
発表してる本人が徐々にヒートアップしていって、すごく楽しそうに暴走している。
内容を消化し切るのは難しかったけれど、メモした内容を基に、後から「調べてみようかな!」という好奇心が沸く
話題の節目に息抜き的なスライドが入る
ずっと集中しているのは辛いけど、こういうスライドが入ると話が代わるタイミングがわかりやすいし、集中をリセットできるのでだらだらやられるよりも内容が頭に入りやすいように感じた。
ただ、面白いスライドを入れるだけでも自分は好きだけど、節目にこういうスライドが有ると、難しい話でも聴きやすく聞けて、「これは凄い!」と感動した。
自分は発表をただ面白くすることを目指して作り始めてしまうので、こういう使い方ができるようになるとカッコイイなと感じた。
デモするタイプ
アドリブ力がすごい!w
あの大舞台でハプニングを恐れずにやれちゃうところが、凄い!
インパクトが凄いので、伝えるたいことが表現出来るものなら、人の記憶に刻む最強の発表スタイルな気がした。
死闘を繰り広げた発表
まとめてると自分に当てはまることもあるし、人に伝えるって難しい。。。
声が小さい
スライドにも集中して、聞き取りにも集中して、やがて...
自分は、緊張したり発表に自信がないときにやってるなぁ、頑張って仕上げた発表をここで潰すのはもったいないので、頑張る。
スライドや声のトーンにメリハリがない
自分には、単調なスライドが羊に、声が子守唄に代わる呪いがかけられているようなので、だいぶしんどかった。
自分は普段の発表どうなんだろう。意識してなかったし、必死過ぎて余裕ないから、もしかしたら当てはまる部分があるかもしれない。
こういう視点で見たからこそのフィードバックだな。気をつけよう
フォントが見づらい
メモする気が無くなちゃうん。
事前に知識があれば、変換もスムーズに行えるんだろうけど、自分のような初心者には脳内変換する余計な作業が苦痛で、辛かった。
発表対象が明らかにプロな場合にのみ有効になるのかなぁ?少なくとも自分には辛かった。
難しすぎる
これは単純に自分の問題w
簡単な解説みたいなのしてる時間もないだろうし、スライドに埋め込むわけにもいかないだろうから、聞き手の自分が頑張らないといけないんだろうな