kaminariのlink_to_next_pageにtwitter bootstrapのiconを挿入する方法

kaminariのlink_to_next_pageに文字列でなくtwitter bootstrapのiconや画像等を埋め込みたいときがあると思います。
helper methodを使用して書けることがわかったのでメモ。

controllerはREADME通り。

class PostsController < ApplicationController
  def index
    @posts = current_user.posts.page(params[:page]).per(4)
    respond_to do |format|
      format.html
      format.json { render json: @posts }
    end
  end
end

helper methodを定義します。

module PostsHelper
  def next_icon
    content_tag("i", nil, class: "icon-chevron-right")
  end
end

viewはこんな感じです。

<%= link_to_next_page @posts, next_icon %>

kaminariは素晴らしいgemですね。
勉強になります。

Rails3レシピブック 190の技

railsのcontrollerでfindメソッドをDRYに書く

railsのcontrollerの中で各action毎に同様のfindメソッドを呼びたいときがよくあります。
そんなときは以下のようにDRYに書くことができます。

before

class PostsController < ApplicationController
  def show
    @post = current_user.posts.find(params[:id])
  end

  def edit
    @post = current_user.posts.find(params[:id])
  end

  def update
    @post = current_user.posts.find(params[:id])
    @post.update_attributes(params[:post])
  end

  def destroy
    @post = current_user.posts.find(params[:id])
    @post.destroy
  end
end

after

class PostsController < ApplicationController
  before_filter :set_post, :only => [:show, :edit, :update, :destroy]

  def show
  end

  def edit
  end

  def update
    @post.update_attributes(params[:post])
  end

  def destroy
    @post.destroy
  end

  private

  def set_post
    @post = current_user.posts.find(params[:id])
  end
end

勉強になります。

初めてのRuby

rubyでif条件式がtureになる条件

ややこしいタイトルですね。
rubyを書いていて、すごく基本的なところでハマってしまったのでメモ。

結論から言うと、rubyでif条件式がtureになる条件は以下の通りです。

 ①falseでない
 ②nilでない

つまり、0や空文字列、空配列は真となります。

if Member.find_by_id(current_user.id)
  print 'いるよ！'
else
  print 'いないよ！'
end

はMemberにcurrent_userが存在しないときnilが返るため"偽"となりますが、

if Member.where(:id => current_user.id)
  print 'いるよ！'
else
  print 'いないよ！'
end

はMemberにcurrent_userが存在しないとき[]（空配列）が返り、"真"となります。

基本だけど、気をつけた方が良さそうです。
曖昧なままで理解した気になる自分の脳を破壊したいです。

明解!Ruby―奥深いRubyの文化を身に付けるテクニック

Google Maps for iPhone がアップデートされたようです

Google Maps for iPhoneがアップデートされたようです。
レストランやカフェなど13種類のカテゴリから近くの店舗を検索できるようになり、
より検索性に優れたデザインになりました。

早速、明日から使ってみることにしましょう。
楽しみです。

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

2013年3月に読みたい本

最近、サービス開発の方ばかりに時間を使っていて本を読む時間がめっきり減ってしまっている。
今は開発に集中すべき時期なのでそれはそれでいいような気もするが、教養を深めたりよいコンテンツに触れておかないと、よいサービスは作れないとも思っている。
なので、なんとかなんとかやりくりして本を読む時間をつくっていきたい。

ひとまず3月に読みたい本を列挙しておくことにしよう。

文章の書き方

文章の書き方 (岩波新書)

物語消費論改

物語消費論改 (アスキー新書)

ゲーム的リアリズムの誕生　動物化するポストモダン２

ゲーム的リアリズムの誕生　動物化するポストモダン２: 2 (講談社現代新書)

明解!Ruby―奥深いRubyの文化を身に付けるテクニック

明解!Ruby―奥深いRubyの文化を身に付けるテクニック

楽々ERDレッスン

楽々ERDレッスン (CodeZine BOOKS)

アド・アストラ　―スキピオとハンニバル― 1

アド・アストラ　―スキピオとハンニバル― 1 (ヤングジャンプコミックスDIGITAL)

1ページ１ページ、能動的に読み進めるとしよう。

Gitで複数のcommitを一つにまとめる方法

複数人で開発をしているとよくこんなことがあると思います。

pull requestー！
↓
師匠「ここ修正してくださーい！」
↓
修正は完了したけど、どうリポジトリに反映すれば…？
修正した後のコミットが増えちゃうの嫌だし、一つにまとめたいなぁ。
ブランチを消して再pushもしたくないし…

そんなときは以下のように操作します。
まず修正したいブランチに移動します。

$ git checkout branch_name

指摘された点を修正し、コミットします。

$ git commit -m "Fix hoge!"

ここで直前のコミットを2つ前のコミットにリベースします。
（←同一ブランチ内でのリベースもできるのね！）
オプション-i を指定します。
これはinteractiveモードで、各コミットに対して操作を指定するためのオプションです。
i 以降で編集対象を指定します。HEADは最新のコミットを表していて、^^ は最新のコミットから2つ前までのコミットを編集することを表しています。
HEAD^^ の部分は HEAD~2 とも書けます。

$ git rebase -i HEAD^^ 

するとvimが立ち上がります。

pick 5c30631 Delete unused gemfile
pick 7f01e5e Fix hoge!

# Rebase 8bdb124..7f01e5e onto 8bdb124
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

目的に応じてコマンドを指定します。
今回は直前のpickを指定したコミットに統合し、コミットメッセージは破棄したいのでfixupを指定します。

pick 5c30631 Delete unused gemfile
f 7f01e5e Fix hoge!

# Rebase 8bdb124..7f01e5e onto 8bdb124
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

保存すると複数のコミットを一つにまとめるためのリベースが完了します。

あとは、リモートリポジトリにpushしてあげるとコミットが一つにまとまった状態で反映されます。

git rebase -i が使えるようになるとgitの幅が広がった感があります。

Gitによるバージョン管理

Git初心者が複数人で開発するために覚えるべきコマンド（前編）

最近、知人と３人でWebサービスを開発しているのですが、
その中でGitとBitbucketを使用してソースコード管理を行っています。

その際に、よく使用しているGitのコマンドを自分のためにメモしておきます。

まず、ブランチを作成します。
作成した新しいブランチへの切り替えを同時に行うには git checkout コマンドに -b オプションをつけて実行します。

$ git checkout -b branch_name

このコマンドは下記と同じ意味です。

$ git branch branch_name
$ git checkout branch_name

ファイルの編集が完了したら、編集したファイルをインデックスに登録します。
この際、-A や -u オプションを安易につけてはいけません。
Issueに関係のないファイルを push してしまい、先輩エンジニアの方に何度も注意されてしまいました...
まずは diff コマンドで修正点を確認し、自分の意図する変更があったファイルのみを add します。

$ git diff
$ git add file_path

ファイルをaddできたら、その結果を確認します。

$ git status

add されたファイルの変更箇所を確認したい場合は、

$ git diff --cached

で確認できます。

add されたファイルが正しいことを確認したら、ファイルをコミットします。

$ git commit -m "Commit messages"

コミットログ や diff は前回紹介した tig コマンドでも確認することができます。

$ tig

さて、いよいよリモートリポジトリへ push します。

$ git push origin branch_name

push できたら pull request を送って、チームのエンジニアにレビューしてもらい master に merge しましょう。

add や commit を行う前に何度も確認を行っていて一見とても面倒ですが、コミットメッセージと関係のないファイルを push して、しかもそれを複数人が行った日には、このコードいつ何のために編集したの？わけわかめ〜 な状態になってしまうことは想像できますね...
「ソースコードはみんなのもの」
という意識で慎重に作業するよう心がけましょう。（←自戒）

Gitポケットリファレンス