Ruby, Railsの最新版(2016/06/02時点)を動かしてみた
Ruby2.3.1, Rails5.0.0.rc1を手元のMacにインストールして動かしてみた。といっても、rails newしたものをrails sしただけで特段変わったことはしていない。
気付いたところといえば、Railsのホーム画面が旧来のお馴染みのものから、Rails公式サイトのようなデザインに変わっていてちょっと感動した。それ以外では、デフォルトのWebサーバがWebrickからPumaに変わっていた。
色々いじってみよう。
コマンドメモ
cd ~/.rbenv/plugins/ruby-build git pull rbenv install 2.3.1 gem update --system
mkdir myblog cd myblog bundle init # gem 'rails', '5.0.0.rc1'を追記 bundle install --path vendor/bundle -j4 bundle exec rails new . bin/rails s
2015年のふりかえり
年が変わってしまいましたが、簡潔に2015年の振り返りをしたいと思います。
Keep
勉強会で発表した
地元の勉強会で、Gitを会社に導入した結果、OSSに貢献できるようになった話をした。
勉強会に参加するだけの人という受動的な状態から
発表する人という能動的な状態に変えることが出来た。
「発表します」と、一歩を踏み出さなければ実現しなかったので
小さな勇気を出してよかったと思える出来事だった。
発表する人になったことで、色々な良い変化が起こったので
今後も継続して発表していこうと思う。
Problem
脳のブレーキを壊し切れなかった
とある挑戦をしていたが、色々な事が重なって一旦離れてしまい
本当に自分にできるのだろうかと思い悩み、なかなか再開に踏みきれなかった。
継続的に成果を出すために、時間を決めてやることにした。
今まで以上に時間の使い方を考える一年になりそうだ。
Try
継続的に成果を出す
Problemの件、週1で成果を出せるような予定を組むことにした。
子どもがまだ小さく、まとまった時間を確保しずらいので
タスクをなるべく小さな単位(30分、1、2時間程度)に分解し
スキマ時間でも実行できるような態勢を整えようと思う。
HerokuアプリをCedar-14 Stackへ移行
嫁用のちょっとしたWebアプリが移行対象だったので
公式のガイドに沿って、特に詰まることなく10分程度で移行出来ました。
以下、備忘録です。
移行対象かの確認
下記コマンドで確認。移行対象のcedar-10だったので、移行作業決定
heroku stack
本番環境移行前の事前動作確認
下記コマンドで本番環境とは別の動作検証環境を構築
※最後のcedar-14-appの部分は自分用に変更すること
heroku create --remote heroku-cedar-14 --stack cedar-14 cedar-14-app git push heroku-cedar-14 master
動作検証環境で問題ないことを確認。
本番環境移行
下記コマンドで本番環境を移行。
gitのリモートに登録されているheroku環境が複数登録されている場合、
どれをcedar-14にするか不明と警告が出たので、
動作検証環境のリモートを削除してから移行した。
git remote remove heroku-cedar-14 heroku stack:set cedar-14 git commit --allow-empty -m "Upgrading to Cedar-14" git push heroku master
本番環境で問題ないことを確認。
最後に動作検証環境を削除して、作業完了。
久しぶりの更新。からの決意
約5ヶ月ぶりの更新で、ブログのタイトルをようやく変更しました。 日本語に訳すと、"脳のブレーキを壊す"です。
これは、憧れ(?)の人のブログで読んだ、ずっと印象に残っている言葉です。
私は普段から色々と考えすぎる質なので、心の中で思っていてもなかなか行動に移すことが出来ずにいました。
そんな中、最近仕事で出会った方に
”楽しければいいじゃん。やりたいことやればいいじゃん。”
という発想で、まず行動に移し、成功される姿をまざまざと見せつけられてきました。
なかなか行動に移せない私からすると、ちょっとしたカルチャーショックです。
そこで、憧れるだけでは何も始まらないので、私もまず行動してみることにしました。
具体的な行動について、現時点で言及することは避けますが
結果はどうあれ、今回の行動が私の”脳のブレーキを壊す”体験となり、ひいては妻や子どもの将来にも良い影響を与えてくれることを信じて邁進します。
PostgreSQLの場合、Railsのmigrationで追加するカラムの順番を制御するのは難しい
はじめに
簡単に出来るだろうと高をくくっていたら、データベースがPostgreSQLの場合、そうでもなかったというお話です。
動作環境
# rake aboutより一部抜粋 Rails version 4.1.6 Database adapter postgresql
テーブル構造
以下のようなテーブルで、titleとtypeの間に、descriptionカラムを追加する想定です。
class CreateBooks < ActiveRecord::Migration def change create_table :books do |t| t.string :title # ↓この間にdescriptionを追加したい t.integer :type # ↑ t.timestamps end end end
調査開始
RailsAPI
まずはRailsAPIでadd_columnを検索してみます。 オプションの詳細は別ページに記載されているようなので、そこを見てみましたが、それっぽいオプションが見当たりません・・。 あら、もしかして出来ない?・・いや、そんなことはないだろうと、今度はググってみます。
ググる
Qiitaの記事がヒット。ズバリのものを発見。いつもありがとうございます。 どうやらafterオプションを指定してあげれば出来る模様です。
早速、以下のようなマイグレーションファイルを作成し、rake db:migrate
で実行!
カラムの順番を確認してみると・・あらら、一番最後に追加されているではありませんか・・。
Railsのバージョンが違う?データベースがMySQLだから?と疑問に思いつつもさらにググってみます。
# rails g migration AddDescriptionToBooks description:text # titleの後ろに追加したいので、after: :titleを指定 class AddDescriptionToBooks < ActiveRecord::Migration def change add_column :books, :description, :text, after: :title end end
さらにググる
今度はstackoverflowの記事がヒット。むむっ、PostgreSQLでは無効なオプションの様子。 Answerの記事を辿っていくと、PostgreSQLのWikiに到達しました。
MySQLでは簡単に出来ますが、PostgreSQLの場合、かなり面倒な手順を踏まないと出来ない模様です・・。 Wiki曰く、列の順番を変更するには、以下の3通りの方法があるとのこと。
- テーブル再作成
- 列を追加し、データを移動
- ビューを使用した違いの隠ぺい
それぞれの概略はこうです。
- テーブル再作成
- 求めているカラムの順番で、新しいテーブル(仮にnew_books)を作成
- new_booksにbooksのデータをinsert
- booksをdrop
- new_booksをbooksにリネーム
- ビューの参照先やインデックスを再作成
- 列を追加し、データを移動
- booksにdescriptionを追加
- booksにnew_typeを追加
- booksにnew_created_atを追加
- booksにnew_updated_atを追加
- booksのtypeを削除
- booksのcreated_atを削除
- booksのupdated_atを削除
- booksのnew_typeをtypeにリネーム
- booksのnew_created_atをcreated_atにリネーム
- booksのnew_updated_atをupdated_atにリネーム
- ビューの参照先やインデックスを再作成
- ビューを使用した違いの隠ぺい
- booksにdescriptionを追加
- booksをnew_booksにリネーム
- 古いテーブルと同じ名前のビュー(books)を作成
- 列の更新・挿入・削除を扱うルールを追加
Railsで実現するには?
ということで、add_columnメソッドでは実現できないため 代替手段として、SQLを直接実行する方法を模索します。
Rails GuidのActive Record Migrationsを読んでみると、 3.9 Using reversibleの記載を発見しました。 reversibleメソッド、upメソッドやdownメソッドを利用して、直接SQLを記載すればできそうです。
ただし、今回はそこまでカラムの順番にこだわっている訳ではなく 労力に見合うほどのリターンが返ってくるわけではないと判断したため、結局、単純に最後のカラムに追加することにしました。 よって、具体的な方法については割愛します。
まとめ
データベースがMySQLの場合は、add_columnメソッドにafterオプションを指定すれば、追加するカラムの順番を制御できます。
しかし、PostgreSQLの場合はそうはいかず、直接SQLを実行する等して、自前で頑張る必要があります。
ブログ始めました
アウトプットの場として、主にIT関連の技術について書いていこうと思います。