Rails の Helper メソッドを rails console から試したい時
$ rails console [1] pry(main)> ActionController::Base.helpers.number_to_currency(300)
number_to_currency が定義されているのは ActionView::Helpers::NumberHelper だけど、module だから include しているところを指定してやらなきゃいけない。
久しぶりに仕事ではないコードを書いた
horesa.se に使われている horesase-boys の本文データを更新するための horesase-body というものをつくって1年間放置していたのだけれど、久しぶりに horesase-boys を更新したくなって立ち上げて、動かなくなっていたので修正をした。
Kaminari を使った
まず、画像を1000枚以上いっぺんに取得していたのだけれど、サーバに負荷かけそうだなぁと前々から不安だったので、 Kaminari を使うように変更した。
Kaminari は仕事のコードで使用していて、こういうコードを書けば良いというのがわかっていたのですごく簡単に変更できた。
以前は、触れたことがない(少ない)新しいものだったので、使うのに抵抗があっていれてなかったけど、今ではその抵抗感が信じられないくらいだ。本当に簡単。
こういう風に「食わず嫌い」的に使ってないけど使えば超簡単 みたいなものは結構多そうだなぁ。
そうそう、仕事のおかげでこういう気持ちになることが多くて、最近やっと RailsCasts を少しずつやってみるようになった。仕事で関わっているチームはどんどん良いチームになっていく感じがあって、すごく良い刺激を沢山うけるので、仕事のために使えそうなコードを覚えるのが楽しいと思える。そういう状態で Rails の勉強ができてとても幸せだ。
Rails4 にした
それからバージョンが古いのが気になったので Rails4 にアップデートしてみた。
はじめての Rails アップデート。
bundle update した
Gemfile 変更したあとに bundle install しかしたことなくって、その前に bundle update しないと関連Gemのバージョンを合わせられないっていうのにたどり着くのも時間かかった。bundle update がやってくれること初めてわかったかもしれない。
strong_parameter の対応をした
rails server したら attr_accessible で落ちていたので、該当行を消したら動いた。アッサリ！
3.2 -> 4.0 はそんなに update が大変じゃないらしいし、horesase-body は小さいから直すとこも少ない！
params[:horesases] を each して直でパラメータを設定して save してて、strong_parameter 使ってなくても保存できて大丈夫かな…と思った。each して一個ずつ取り出して save してるとこはどういう書き方が適切なんだろうなぁ。（そもそももっと簡単な書き方ありそう）
DEPLECATION WARNING がいっぱい
rake build したら DEPLECATION WARNING が3つくらい出た。
機能的には動いてたので、rails server の時にも出ていた config.whiny_nils だけ対応して終わった。
気になる
Rails4.0 を rails new した時に生成されるものと、Rails3.2 から 4.0 にアップデートした状態のものでは、config 配下の設定値や Gemfile の中身が全然違う気がする。update の時はここは直さなきゃいけない っていうのを掴むには、やっぱり 4.0 での変更点をチェックしなきゃいけないのかなあ。rails new で生成されるファイル見比べるのは骨だしな……
EPISODE #400 What's New in Rails 4 のASCII CAST の日本語(旗から飛べる) 見て確認しよ。
…と思ったらなんかまさにこれっていうのあったー！！
EPISODE #415 Upgrading to Rails 4
- 研修の時に聞いた「Rails は scaffold をしてみると書き方の違いがわかる」っていうのはなるほどだった。前にも聞いたことある気がする。
今日はこれで終わり
警告残したままで終わったけど、「こうやって一個ずつ解消していくんだなぁ」っていうのを少し実感できてよかった。
イミテーションワールド #prfm
http://www.adventar.org/calendars/126 の7日目です！
断腸の思いで決めました。どちらを書くかほんとうに悩んだ！！
こうして好きになっていった
PerfumeにハマってYouTubeで動画漁りをしてしばらくした頃、聴いたことがない曲の動画がたくさん入っているリストを見つけました。Perfume初期のライブ映像っぽくて、ヤスタカサウンドと完成された無機質な声が好きだった私は 生歌ってあんまり興味ないなー と思いながら聴いていました。そこで私は大好きなこの曲に出会ったのです！！
その名も カウンターアトラクション！！
カウンターアトラクション!?
どこか暗い曲が好きなんですよ！ 明るい短調、イントロでの転調、衝撃の暗い歌詞、寂れたメリーゴーランド感！ 私のど真ん中ソングでした。
意味
http://en.wiktionary.org/wiki/counterattraction
counterattraction (plural counterattractions)
Something that vies for the attention of a person or thing in competition with something else; a rival for preference.
ションションメドレー
最初は実はイミテーションワールドって気にならない曲だったのです。Aメロがかけ出しアイドルソングっぽい印象をうけて、そういうのがあまり好きではなかったから。でもリストを何周かするうちに気付いたわけです。カウンターアトラクションの前にイミテーションワールドがないとしっくりこないと！ これはどういうことなの!?
カウンターアトラクションはイントロで転調しているのですが、これってもしかしてイミテーションワールドとのつなぎなの？ もしかしたら偶然そうなっただけかもしれないし、メドレー用にアレンジしたのかもしれない。どちらにせよこのなめらかさは素晴らしいものだと思いました！
それからイミテーションワールドとカウンターアトラクションをセットで聴くようになって、イミテーションワールドも私の中で遊園地に通ずる世界観を確立していって、Aメロへの苦手意識が薄れていって、サビに入るときにウオーーってなるようになったわけです！
イミテーションワールド！
よく聴くようになってから歌詞も調べました。これも暗い感じするじゃーん！ 好物じゃーん！ 素敵じゃーん！
サビに入った直後の「あー イミテーションワールド」の部分は少し物悲しい感じのメロディになっていて、ここがグッときます。いや、それよりもサビに入る直前！「ファ ♭シ ♭レ」 ってあれがヤバいです！ これがもうグッと来るヤバい！！
余談
Perfumeメドレー入りのDVD
2007年に出ていたDVDが高騰したものがAmazonにあったのだけど新品あるなら新品がほしくて、3万円とかで悩んでいたのでありました。中古でも1万5千円とかするしな…
YouTubeで良いっちゃ良いんだけど、YouTubeのはいつ無くなっても不思議じゃない不安感があって、ほんとにほしいものはハードで手元においておけるのが幸せと感じるのでした。
Perfume動画漁りをはじめたキッカケ
アルバム GAME を持っているので、マカロニ聴いたことあったはずなんだけど全然覚えてなかった。
チョコレイト・ディスコが好きじゃなくてこのアルバムあまりきかなかったからかなぁ。
あと、本来ドツボといえる曲以外は映像から好きになることが多くて、マカロニも多分そうだったんだろうなー。CDで聴いただけだと退屈していたように思う。聴いて映像が思い浮かぶようになって自分の中に世界観ができてはじめて好きになるもの、あります。
Chrome で console の拡大縮小をするショートカット
偶然見つけたので書いておきます！
| 拡大 | 縮小 | |
|---|---|---|
| 画面 | ⌘+ | ⌘- |
| console | ⌘^ | ⌘- |
- 縮小のショートカットキーが同じなので、最初に拡大のショートカットキーを押すことでモードを切り替えます。
みつけた時は画面拡大とconsole縮小の組み合わせで固定されてしまって画面はどんどん拡大されるし console はどんどんちっちゃくなっていくし焦った…（バグ？）
クックパッドの開発コンテスト24に参加した(初動編) #24contest
去年は楽しそうだなと思って眺めているだけだったから、今年は参加しようと思ったのでした。
今日は私が参加しようと思ったところから、チームを組むところまでのことを書きます。書くぜ。
0. 参加すると決める
いろいろなきっかけがあって、自分に対して「参加しなければ不幸になる」と思いこむ呪いをかけてしまったので、今年は参加しなければならなかったのだった。デッド・オア・参加 みたいな心理状態だったので参加を選ぶしかなかった。モチベーションからネガティブスタートだったので考えこむことが多かった。
1. 成功を定義する
必ず成功するためにはハードルを下げてかからねばならぬ！ めいっぱい下げるのだ！ ハイハイで跨げるくらいに！
成功の定義するときの決まりをつくった
他者を意識しない成功にする
そもそも勝負事がものすごく苦手だ。ライバル視されるのもするのも苦手。他人が関わる悔しい気持ちは嫌いだし憎いし消すために色々したくなる。なので勝負を回避したくて、それには他者を回避するのが一番手っ取り早い。だからコンテストの性質がある目標はダメ。競うとかダメ。自分が中心じゃないとダメ。
技術と遠い成功にする
できること少ないので！！
成功を定義した
ゆるく楽しくやる
時間と比較のプレッシャーが苦手で、ハッカソンはそのどちらもあるから苦手意識が強いのだと思う。成功体験と思うには絶対的に楽しくなければいけない、楽しいにはゆるくなければいけない、だからゆるく楽しく！
2. メンバーを決める
最終的には一人でも参加しようとは思っていたけれど、成功に辿り着けない感じがするので、できるだけ一人では参加したくなかった。
一人で参加したくない
一人で参加すると考えた時に、成功するイメージがまったくもてなかった。技術的な自信の無さが大きく、デジタルで叶えたい夢も持っていないので、いざテーマが発表された時に動けるイメージがまったくない。イメージの結果がゼロなら良いんだけどマイナス方向に振りきれていて、夕方の薄暗い時間に、電気をつけない部屋の中で、一人で陰鬱として泣きながらひっそりと諦める様子まで頭に思い浮かんでいた……(暗)
マイナスのイメージはまったく払拭できなくて、それだと本番も間違いなく引きずられる。なので、一人では参加したくなかった。
仲間をあつめたい
もともとチーム開発への興味が強いのと、一人で参加したくないのとで、仲間を集めることにした。
チームというものへの興味
私が仕事で開発をする時、何よりも重要なのはチームだと思っている。なぜならば私は一人では開発できないから。
チームっていうのはおもしろくて。人が一人欠けたり増えたりするだけで、空気が変わる。人が同じでもとりまく環境が違えばまた変わる。なのでどこへ行っても毎回新しい。メンバーの隠れた役割がみつかるとおもしろい。チームにあわせて自分の形が変わるのもおもしろい。自分が入ったことによってチームが変化するのもおもしろい。よくわかんないけどすべてがうまくいくように、ハマるタイミングがあるとすごく楽しい。
単純に人に興味があって好きなのかもしれない。
仲間がいればきっとできる
私ひとりじゃマイナスだけど仲間がいれば成功イメージができる
- ちゃんと作品として形にできそう
- ハッカソンっていうのは時間が限られていて、だいたい今できることしかできない
- 自分だけだとできることが少ないけれど、知識が違う人と一緒にやれば表現できる範囲が増えそう
- ゴール前に諦めずに最後まで頑張れそう
- 一緒に考えたりできるから、多少の停滞があっても停止してしまうことはなさそう
- ゴールできなくてもチームでやったっていう成果が残るから頑張れそう
「いっしょにやらないか」
もひゃ氏 と みぃお氏 に声をかけた。
みぃお（@ayako119）
GGJでおせわになったときになんかすごかったけど私はあまり力になれなくて、今度何かやるときはプログラマとして一緒に って思ってその時が来たのだったーー
もひゃ（@onjiro_mohyahya）
もひゃのスキルは全然知らないんだけど、もひゃが感動したことをきくと感動が伝染して感動するので共感値が(私から一方的に)高い感じで、今度何か感動しそうなことを一緒に って思ってその時が来たのだったーー
おいしいものをつくって食べさせてくれる ※重要
「けっしてがんばらない」
あとに糧になろうが何だろうが、いま失敗したくないし成長とかチャレンジより精神安定をはかりたい。
期待したり競ったりがんばったりっていうのを念頭におくのはそれだけで私はつらくて失敗に近い感覚になる。
完成したら嬉しいし目指すのもいいんだけどけっしてがんばりたくない。ゆるく楽しくできる範囲でやりたい。
そう言ったらふたりは うんうん、いい、いい って言ってくれたから一緒にやることにしたのだった。
それから、ゆるく楽しくするために「普通の生活の中にハッカソンを入れる」を目標にした。
食事はおいしいものを食べて。夜は寝る余裕があるくらいのもの作りたいね、みたいな。
「当日は時間ないからコンビニ弁当とRedBullかｎ「アカン！(かぶせ気味) もひゃにおいしいもの作ってもらうんや！」
初動編おわり
回避するとき全力で
こうして最初のことをふりかえってみると、私にとって、自分から「いっしょにやらないか」って言うのは必要なことだったのだと気づく。自分でやると決めて、どうやったら自分の中での成功に達成できるか考えて、そのために動くということ。私はコードで成功に近づける自信がないから、コード以外のアプローチで成功に近づく必要があったのだったーー。
結構な逃げ道であった。
書いたことと実際におこったことで違うこと
この記事の中では、参加決意するときに成功定義を意識しているけれど、実際には少しずつ心のなかに固まっていったもので、「成功」という単語で意識したのはコンテスト終了後だった。メンバー決めの章でだいぶ暗い気持ちが出ているけれど、それは成功定義が固まっていなくてハードルが高いままだったからこその不安だったのだーーー。
次回予告
気が向いたときに準備編みたいなの書こうかなー。
とちぎRuby会議05に行って殻殻でお話してきた #toruby
2次会の殻殻で関さんと池澤さんとおはなししたことをまとめました。
※教えてもらったことと私の解釈が混ざっています！
「今日気になったのあった？」ってきかれて
仕様言語を使うメリットがいまいちわからなくて「Cucumberと一緒なのでは…?」って言ったら
(池澤さんと関さんが t_wadaさんのトークの simple と easy について話していた流れで)
あれはEasyだよ悪いEasy。
だって「ログインできること」って書いてあったとして、そのアプリケーションのログインってなんなの？ TwitterとFacebook、Amazonでそれぞれログインしててできることに違いがあると思わない？
Amazonはログインしてなくてもログインしている様に振舞っていて、右上にはログイン情報が出てるしカートもそのまま使える。決済の時だけログインを求められる。「ログインしている」の状態ってぜんぜん違うでしょ。
Cucumberで「ログインできること」って書くとじゃあそれはなんなんだよってなるし、なまじ書ける分書いた気になるし（以下 Cucumber dis）
すごい！！ ほとんど意識したことなかったけど確かに Twitter のログインってほんとにログインしてないと有効じゃない感じするしAmazonって決済の時なんでいちいちサインイン求められるんだろうって思ってた！！
（Cucumber disってたイメージあるけど私が仕様言語と雑な比較したせいかもしれない）
仕様言語を使うと仕様の検証ができる？
「仕様言語とXUnitでの検証が対になってるのが良いんですかね…?」「まあそうかもね」
みたいな話をしていて、その時点で私は仕様言語で書いたものは動かして検証しなければならないから結局XUnitで書くのと変わらないと思っていたんだけど、仕様言語で書いたものは検証じゃなくて「そのようにつくること」っていうまさに仕様書であるのでした。
仕様言語で書かれた仕様は厳密で、それがあるだけでコードの書き方とかできるものが違ってくる。そこに意味がある。XUnitは検証項目を書いても本体を実装しないと動かないし、動くものがないと細かい検証も書けないけど、仕様言語だと本体の結果である「RESULT」っていうものがあるから動かなくても事後条件が書ける。つまり仕様書を書いているのと同じー！（仕様書だってさんざんきいてたのにやっと理解した）
仕様言語で仕様を書こうとすると曖昧な部分を追求して考えなければいけなくなるから、書くこと自体に意味がある。つまりそれ自体が検証プロセスとなるなのだなぁと思った。（そういえばXUnitの検証ってコードの検証であって仕様の検証じゃなかった）
仕様の役割とテストの役割
「仕様言語で書くのは事前条件と事後条件だけ、実装するのはここだけ」
最初に仕様と検証とは対であるべきものなのかなと思っていたけれど、以前せきさんにテストの話をきいたときに、モデルテストを必要としていなかったのでその差が気になりました。でも私がイメージしていた対であるっていうのが間違いでした。（と最終的に自分が感じた）
実装は仕様を見て書いてるんだからそれを信頼すればいい、テストで見るべきなのはそれらが組み合わさってどうなっているかということ。ソフトウェアとしての振舞をテストするべき。モデルの試験では品質は上がらない いやあがるのかもしれないけれど「でも意味ないじゃん、そういうふうに書いてるんだし」っていうのをきいてなるほどと思った！
例えば複雑な計算が必要でテストがないと不安なロジックがあったらテストを書くのは妥当かも。
でもそれが不変で切り離せているロジックなら、テストを残す意味は無いかもしれないなぁ。
あと、API的に使われているものであればテストがあるのは良い気がしました。
例えば何かのgemでバグが発生していて一個のメソッドを修正したいとき、だれの環境でも動かせて結果が確認できるようなもの…あっ！ 使う人の環境が絡む仕様書はテストコードで書いた方が良い気がする！ 大発見だ…!! 私すごい…
仕様はどこに書くのか
モデルテストの話をしていて、この前はじめてモデルの試験を追加したのを思い出しました。
「誰が見てもこのメソッドの意味がわかるように」という観点で追加して、テスト書いて動かした段階でバグ検出できたのだけれど、それを仕様書として残すのはどうなんだろう？ 例えばコメントで書くのがいいのか、ドキュメント化するのが良いのか、仕様書ってどう残すのが良いんだろう？
仕様ってどこに残すのが良いんでしょうか
「それは…プロジェクトによるんじゃない？ 誰も読まなかったら意味ないし」
(ﾟдﾟ)!!!
これは衝撃でした！ 書けば読むものと思ったけど、よく考えたら私テストとかほとんど読まない。（よくない）
「一番だめなのは『書いてあるじゃん』っていうやつ」(グサッ)
「それって『言ったじゃん』と同じ？」
「いやそれはそこでレスポンスが発生してるからちょっと違う」(レスポンスじゃなかった気がする…カタカナ語…インセンティブ？)
どこに書いたら仕様を読まれるんだろう
せきさんのチームは仕様書とか仕様に関してコメント書いたら、実際に使う人(仕様書の読み手)に向けて音読してっていうの。だから、読み手がいるものはその場でチェックされるし、読み手がいない仕様書は書かない（書けない）というの、おもしろい！
「将来の自分に向けてコメント書くって言うじゃん」
「…いるの？」(将来の自分!!)
ぬまたさんのチームで仕事をしていた時に、みんなに影響ある(使ってほしい)ロジックを書いたら朝会のあとでシェアするというのをやっていたなーと思い出しました。仕様を共有するっていうのはやっぱりそれなりに工夫が必要なんだなー。読まないしなー（よくない）
おわり
新幹線つらかったけどまた来たくなりました。とちぎ！
（この記事は Cafe Roimu からお送りしました。クロワッサンサンドめちゃうま）
vimで自在にファイルを移動したい
たくさんのファイルをvimを開いて移動したい
$ vi *.txt
って開いたとき
:n
ってすると次のファイルに行ける。C-o で戻ることもできる。
※追記※
C-o は前のカーソル位置に戻るけど:nで開いてたファイルに戻れなくなっちゃう！
:N →前のファイル :n →次のファイル
これでもとのファイルに戻るし、また次のファイルに行ける！
Rails で model とか view にヒョイヒョイ飛んでいきたい
任意の場所で :R ってすると一番それっぽいところに飛ばしてくれる
Bundle 'tpope/vim-rails'
:BundleInstall
例えば controller ファイルの new action にカーソルを合わせて :R ってすると、対応する view のファイルを表示してくれる。view にいると対応する controller に飛ばしてくれる。
あと、= render ’form’ とかあるとき
挿入モードでもコマンドモードでもない状態(なんていうの？)で
form にカーソルあわせて gf すると飛んでくれる。便利！
