SUMMER SONIC 2013

サマソニ2日目だけ行きました。

今年のリストバンドはリボンみたいでかわいかった

ももいろクローバーZ

MountainStageに入った瞬間入場規制が始まった。午前中に入場規制が入ったアーティストは初めて見た。レッドがジャンプするって事しか知らなかったので、ジャンプ見ようかなあと思ったけど、汗が異常に流れてきたので途中で抜けて物販でタオルとTシャツを購入。
ちょっと見たらもういいやって抜ける人も結構いたけど、入場規制で順番待ちしている人の行列を見たら、人気は半端ないなあと思いました。

未定(初回限定盤)

CAPITAL CITIES

ポップです。ダンスミュージックかつポップ。休日の昼間に部屋に流したい感じでした。

Capital Cities Ep [Analog]

THE ROYAL CONCEPT

スウェーデン出身のポップなマンドゥ・ディアオかなと思ってたら、想像以上にポップでした。なんていうか次のアルバムを聞きたい感じですね。まだ伸びしろがあるというか。次はもっとロックな感じでアルバム作って欲しいかな。

The Royal Concept

CYNDI LAUPER

ハイスタンダードがインディーズ時代にカバーしていたので、原曲をライブで聞きたくて見ました。最初から目当てのMoney Changes Everythingをやってくれたので満足。後から知ったけど、還暦みたいですね。それであの歌唱力はすげえ。

トゥルー・カラーズ

THE VENTURES

ビーチステージとベンチャーズって最強の組み合わせだと思った。ユーミンのカバーを聞きながらビールとソーセージは最高でした。毎年来て欲しい。

ベンチャーズ・プレイ・ユーミン

MUSE

SUMMER SONIC初参戦の時はヘッドライナーだったぽいですね。出世したなあ。ライブの内容はトリを務めるには十分のクオリティで、スタンドまで立ち見の満員だった。最後の花火凄かったですね。100発ぐらい打ち上げてたかも。

The 2nd Law

今年はフラっと見に行った感じだったので、そこまで疲れなかった。しかしSUMMER SONICは毎年色々な面がブラッシュアップされていて良い。帰りの電車もここ数年で増やされたし、かなりオススメのフェスになったと思う。

Instagramの写真をブログなどに貼れるようになったらしい

夏っぽい写真貼ってみた！

Git勉強会@Krayに行ってきた

KrayさんのGit勉強会に行って来ました。以下感想。

Gitはなぜ難しいのか(irohiroki)

コマンドを実行した時に.git/ 配下で何が起こっているのか？という部分にフォーカスを当てていた部分が印象に残りました。初心者向けという前提っぽかったので、最初にそれ説明しちゃうの・・・？と思っていたけど、前半で.git/配下の動きを説明しておいた方が理解しやすくなるなと感じました。これは新発見。(この時、メタプログラミングRubyを連想してしまった。タイトルに「メタプログラミング」って入っているので勘違いしていたのだけど、他言語経験者にとってはいい入門書として読める良書です。)

Gitをなんとなく使ってる人に丁度いい感じの内容でした。

まとめ： pullは恐ろしいコマンド

Gitがどう動いているかについて(f96q)

Gitのソースコードの解説。初音ミクのカツラが気になってあまり記憶に残っていない。

まとめ： GitはCで実装されてるけど、構造体使ってOOPな感じに作ってるよ！おもしろーい！リーナス！リーナス！

次回予告

次もあるらしいのでダニーさんに脅されて行くと思います。

HerokuでBambooStackからCedarStackに移行する

Herokuでずっと更新していないアプリをruby2.0に上げようとしたのだが、Gemfileに「ruby "2.0"」と書いてもpushするとbundle installでエラーが出る。調べてみると過去にHeorkuで作ったアプリはBambooStack上で動いていて、使用出来るRubyのバージョンが古いなどなどが原因だった。
なので、Ruby2.0を使えるCedarStackに移行しようと思ったのだがBambooStackからCedarStackへの移行ツールなどは用意されておらず、CedarStackにするには新しくアプリを作るしかなかった。旧アプリ→新アプリへのデータ移行作業をすればいいかと考えたのだけど、BambooStackで作ったアプリのURLは「http://appname.heroku.com/」だったものがCedarStackだと「http://appname.herokuapp.com/」で作られるらしい。独自ドメインを設定していないので、URLが変わってしまう。これでは移行できない・・・と思ったが、アプリ名さえ同じであればheroku.comもherokuapp.comと同じIPを指してくれるので問題は無し。

というわけでまずDBのバックアップ。

bundle exec heroku db:pull sqlite://db/production.sqlite3 --app appname

ここで自分の環境ではエラーが出た。このエントリーを書いている時点ではRuby1.9.3以降でsqlite形式にデータを変換する時にバグがあるらしく、Ruby1.9.2以前のバージンでエクスポートしなくてはならない。(Macで開発している場合は「brew install apple-gcc42」でRuby1.9.2をコンパイルできるようになります。)

そして現在使っているHerokuドメイン"appname"をブラウザから別名にリネーム*1し、今まで使っていた"appname"でアプリを再作成します。

heroku create appname --stack cedar # アプリ削除からこのコマンド実行までに"appname"を取られたら作れなくなるので急いで作る

そしてバックアップしたDBを新アプリにインポート。

bundle exec appname db:push sqlite://db/production.sqlite3 --app appname

これでアクセスしてみて動作確認がとれれば旧アプリは削除してしまってOK。

ちょっと面倒ですね。ブラウザからクリックひとつでStackを移行できるツールがあったらいいのに。

*1:コマンドでもできます

RubyHiroba 2013年に行ってきた

RubyHieroba2013に行って来ました。
相変わらず意識のRubyistばかりでいい刺激になって良かった。
今回特に興味を持ったのはTwilioですかね。いじってみたい。まだ何を作るかは思いつかないけど、色々と使い道がありそう。
ずっとLTのブースにいたんですが、そろそろ自分もLTぐらいはやった方がいいかなと思った。まずはネタを考えないとだけど。

入門Chef Solo補足メモ

入門Chef Solo - Infrastructure as Code

そろそろChefでも覚えるかって時に伊藤直也さんが「入門Chef solo」を出版されたので購入しました。
Chefを覚えようとして最初の段階でハマッて諦める人が多いみたいですね。僕はいきなり本書を読みながら進めていったので殆ど止まること無く覚えられましたが、Chefのマニュアルを見た印象では確かにいきなり詳細過ぎる解説を見せられても分かりにくいかなー、と感じました。たったの890円だし、Chefをこれから覚えたい人は買って損は無いと思います。

補足

knife-soloの最新版インストール時の解説で、git cloneしてrake installと書かれていましたが、自分の環境ではjsonが入らずにエラーになりました。gem update --systemを実行し、gem installでオプションの--preをつければ0.3.0が入ります。

$ gem update --system
$ gem install knife-solo --pre

knife solo init実行時にuninitialized constant KnifeSolo::Pathname (NameError)が発生しました。knife-soloのインストール先のknife-solo.rbでrequire 'pathname'を追記して下さい。例えばrbenvを使っている環境なら以下のファイルになります。

# require 'pathname' を追加
~/.rbenv/versions/2.0.0-p0/lib/ruby/gems/2.0.0/gems/knife-solo-0.3.0.pre3/lib/knife-solo.rb

RSpecでshouldからexpectへ移行する時に困ったこと

RSpecのExpectationsでshouldが非推奨となり、expectが推奨になったわけですが、expectで書くかと思った時に困ることがあった。例えば、

subject { User.new }
its(:login_id) { should be_nil }

のようなコードを書きたくてもshouldが無いと書けないのでは？と思ってたわけです。
これが書けないってなるとまだshouldで様子見かと判断していたのですが、
実はこのケースについてはconfigでshouldをdisabledにしてもサポートされていました。
ちょっと安心。shouldを使える場所はshouldを使い続けて、書かざるを得ない部分だけexpectを使えばもしshould継続！って展開になっても対応は最小限で済むはず。
しかし、shouldが使えないとなるとコードをパッと見て「expectを使っているところは更新処理」だと判断しにくくなる点が不満ではあるなぁ。