10分
cancan gem （!= CanCam） は、ウェブアプリケーションの「認可」をつかさどるライブラリ。
重要なのは、「認証」ではなく「認可」のみを受け持っているということで、要するに権限管理だけを「関心事」として持つライブラリであるということ。したがって、認証側は、 devise でも、 warden + omniauth でも、 Railscast のように authlogic でも、自力実装でも大丈夫だということ。キレイ目でもカジュアルダウンしたときにもコーデに使える万能アイテムのようなものですかね。
当ブログにしては珍しく Rails スリ～ で試してみよう。
思いつきベースですが、
大体の方針です。しかも、半年後ぐらいには変わってる可能性があります。
それでは、今年もお世話になります。
1分
Gemnasium keeps you up to date on the gems that matter to you.
あなたが github 上に Rubygems やその他プロジェクトのリポジトリを持っていたとして、その Gemfile や gemspec を読み込んで、依存関係を把握し、記述がまずい等で最新の Rubygems にキャッチアップできないようなら教えてくれるサービス。
こんな感じ。
要するに、 bundler はすでに 1.1.rc7 が出ていて、遠からず 1.1 がリリースされるだろうから、よってこの ~> 1.0.0 という記述のままではじきに最新のものが使えなくなるよ、ということ（黄信号）、さらに、 rspec はとっくに 2.8.0 が出ているので、いまの ~> 2.3.0 という記述では最新のものが入らないよ（赤信号！）、などの情報が分かるということ。
ということで、こういった黄信号/赤信号な事態になったら通知してくれて、たとえば、他の gem は全部 ~> 2.8.0 なのに、この rack-session-dbm だけ ~> 2.3.0 って書いてあるから依存関係が破滅する、みたいな事態を早急に防げる、というわけだと理解した。合ってるのかしら……。
複雑さを増していく依存性の問題に日々立ち向かう、 Rubygems 戦士たちには便利なツールだと思われる。 travis-ci のようにバッジを張り付けることもできるようだ（プロジェクトの URL の後ろに .png をつけるだけなので便利）。
あと、インフォグラフィックとしても中々面白いような気がする。
Open source moves pretty fast. If you don’t stop and look around once in a while, you could miss it.
Using old gems is bad. And unnecessary. Gems are updated all the time.
- Bugs are fixed.
- Security holes are filled.
- New features are introduced.
It can be hard to keep up with, but it’s important for the health of your code.
from Why use Gemnasium? – Have a nice developing life!
2分
明けましておめでとうございます。ブログもぼちぼち通常営業です。
先日ぼくの（github:mlightner氏や @aereal 氏の実装を大きく参考にしたものです）Sinatra系対応パッチがマ～ジされました、次世代ページネーションエンジン kaminari ですが、昨年末にそのパッチを含む 0.13.0 がリリースされています。
早速使ってみたいところですが、時期的に、ちょうど Rails 3.2RC やら Rack 1.4 やらが出ていて、設定にややコツが要るのでそこだけメモしておきます。Padrino の例ですが、 Sinatra でも適宜読み替えてください。
1 2 | padrino g project kaminarino -d activerecord -a sqlite -b cd kaminarino |
Gemfile を編集15 16 17 | # rack のバージョンを 1.3 系に指定しないと、最新の rack 1.4.0 が入って面倒な事態になる gem 'rack', '~> 1.3.0' gem 'kaminari', '~> 0.13.0', :require => 'kaminari/sinatra' |
1 | bundle update |
1 2 3 4 | padrino g model user name:string padrino rake ar:migrate padrino g controller users get:index padrino console |
1 2 | >> 100.times { User.create!(name: SecureRandom.base64(12)) } >> exit |
app/app.rb:
1 2 3 4 5 | class Kaminarino < Padrino::Application #... register Kaminari::Helpers::SinatraHelpers #... end |
app/controllers/users.rb:
1 2 3 4 5 6 | Kaminarino.controllers :users do get :index do @users = User.page(params[:page] || 1).per(5) render :"users/index" end end |
app/views/users/index.html.haml:
1 2 3 4 5 6 7 8 9 10 11 | !!! 5
%html
%head
%title= "users page: #{@users.current_page}"
%body
%ul
- @users.each do |user|
%li
= "User ID: #{user.id} |"
=h user.name
= paginate @users |
1 | padrino start |
で、とりいそぎ paginate ヘルパーなどを移植したのですが、実は生成される URL は機械的に後ろに「?page=n」をくっつけているだけだったりして色々と申し訳ない感じなので、何というか、こう、ユーザ側で自作した方がうわなにをする
もうすぐ Rails 3.2 の正式版が出て、 rack 1.4 を考慮した依存関係になるとのことで（参考ポスト）、一緒に Padrino なんかも対応してくれるはずですので、それまではちょっと最新の rack が使えませんが待ちましょう……。
＃ 少しだけそもそも論的な話をすると、 kaminari 自身が actionpack に依存していること、そして、実は Sinatra 側のヘルパーも ActionView を利用している（移植の工数を最小限にするために……）ことが問題を難しくしている感じもありますが、ここはこう、きっといい方法があると思って考えて続けています（helpersだけでも別の gem に切り離すと綺麗なのかもなあ～とか）。
何かご意見があればお気軽に @a_matsuda さんや ぼく まで～。一応、 Sinatra 関係の改修のメンテナを立候補させていただきましたので……。
