PHP書いてたけどRuby書くことになって１年間でやったことてきな

久しぶりに雑談っぽい記事
よくあるようなタイトルでブログを書いてみる(実は4ヶ月前から下書きとして放置温めていた訳では・・・)
Rubyをお仕事で使い始めて(ほぼ未経験の状態から)1年以上(1年4ヶ月くらい)たったので
Rubyを使い始めて1年でやったこととかまとめてみる

Rubyをお仕事で使う以前のお話

Rubyの直前だとPHP書いてました。
FrameworkはCodeIgniterで、他にPHPのFrameworkだとZend Frameworkはお仕事で使ったことあります。
他の言語だと、C/C++,Java(少々),JavaScript,etc...

Rubyを使うことになった経緯

PHPで書いていたシステムのリプレースで闇による策略(適当)により
最終的にRuby(Ruby on Rails)でやるよ！ってなったから
(PHPは数年書いてたので個人的に新しい言語出来るのは嬉しかった)
なので下記のような感じでお仕事の内容は進んでいくのです。

1. リプレース
2. リリース
3. その後

1.リプレース

Rubyなにそれ？おいしいの？状態だったので技術書でRubyとRailsの勉強をしつつ
ここら辺の善しとされる記述方をガン見したり社内の他のRailsプロジェクトのソースを見ること数日

とりあえず１機能作ってみることになり作成してpull requestを送る
チーム内に1名経験者がいたのでその人にレビューして貰い、修正して再度レビューをして貰い・・・
等々を繰り返してRubyになれて来たあたりでもう一冊下記の技術書を購入

パーフェクトRuby (PERFECT SERIES 6)

この本はRubyに慣れて来た自分にとっては復習的な意味やそんな書き方出来るのかRubyすげーってなってとても良かった。

そんなこんなで何とかリプレース終わったんですが、
やはり経験者がレビューをしてくれるっていうのは
Ruby特有の記述方を理解する上でとてもありがたかった。

2.リリース

リリース１ヶ月前くらいに経験者の人がチームから抜け(一応サポートはしてくれるという形)、
運用したことない自分が色々やることになってしまった件。
そんなこんなでリリースした訳ですが、レスポンスがおっそ！ってなり
2週間くらいごにょごにょを行うことになり,
その2週間くらいユーザにちゃんとしたサービスを提供できていないことが申し訳なさすぎて本当に胃が痛い毎日を送ることになった。
(負荷テストをやるべきだったのですが色々な事情により・・・また何故か同じ構成なのに本番環境でのみしか起こらない現象でもあったため)

でもこの2週間くらいのごにょごにょで
だいぶRuby on Railsで構築されたサービスの運用で問題になってくる部分が理解でき
経験値はだいぶ積めた気がする。

3.その後

リリース後は機能追加とかしていく訳ですが、
機能追加という面では特に困ったことは無く(時々Rubyの罠にはまったりしましたが・・・)
機能追加の他にもレスポンスを早くする為に主にviewのレンダリングの高速化等を行いました。

• Ruby関連の技術書をいくつか読む
• はてぶとかでRuby関連の情報をチェック
• twitterでRubyの凄い人達をフォロー
• chefのrecipe書く
• capistrano deployタスク整理
• fragment cache使用
• いくつかのgemの作成
• Redis-Sentinel導入
• Rubyのversion up
• RubyKaigi2014に参加

機能追加以外には上記の様なことをやりちょうど1年たったくらいでRailsのversionを3.2から4.1へupgradeしました。

まとめてきな

そんなこんなでRubyistになった訳です。
色々な理由からはじめたRubyですが、
書き始めた段階から経験者にレビューして貰える環境だったので
その点でかなりRubyらしい書き方を覚えることが出来て習得がスムーズにいった気がします。
Ruby(Rails)を使ってみて感じたことは以下のような点です。

1.コードを短く綺麗に書ける

綺麗なコードは芸術だと思っている自分としてはこれは凄く嬉しかった。
しかも可読性が高く直感的にわかりやすい。

2.ARがすごい

これはRubyでは無くRailsの話
ActiveRecordが凄く優秀でこれのおかげで更にコードを綺麗に書ける

3.命名は凄く大事

以前は略語とかを使ってmethod名等を短くしていたのですが、
method名は可読性が高く直感的にわかりやすいものを付ける癖がつきました。
Rubyだからという訳ではなく他の言語でも気をつければいいのですが・・・

4.Gemがいっぱい

Gemがいっぱいあって便利
使用するGemをGemfileに書いてbundle installすれば
簡単にGemを導入出来るのは素敵すぎる

5.testを書く文化てきなやつ

Ruby書いているならtestも一緒に書くの当たり前だよねてきな雰囲気がある気がするのですが、
testを書いていてよかったと思うことが多々あるのでtestを書く習慣が出来たのはよかった。
他の言語でもちゃんとtest書こうと思えた。
testがあるとリファクタとかRubyやRails,その他のgemのversion upも楽だった

6.開発効率があがった気がする

開発の効率はあがった気がする。
PHP書いてた時はtest書かなかったけど、
testを書いている今と比べても今の方が開発のスピードは上がったしバグも少ない気がする。

7.コミュニティが凄い

日本人(Matz)が作成した言語だからなのかも知れませんが、
コミュニティの活発さが凄く目立っている感があっていいなという印象

8.多機能すぎてググるのつらめ

複雑なことも出来るので、こんな複雑なこと出来るのかな？
っていうときにどんなワードでググればいいかわからないというのが
初期のときに多かった気がします。

9.version upを追うの大変

他の言語に比べて新しいversionが公開されるスピードが早いのと、
それを追わなければならない感が強いと感じました。
追うのは大変ですが個人的にはそれが楽しかったりします。

10.書いていて楽しい

そのままなのですが書いてて楽しい
でもこれが一番大事ですよね

他にもいっぱい感じたことがあるのですが最後の「書いていて楽しい」というのが
一番大きいですね。
参考にした技術書やサイトも後ほどまとめようかと思います。

Fluentd + Elasticsearch +Kibanaを導入したので手順をメモ

導入経緯

「serverのログ見るときに複数のserverにsshで入って見るのとかつらめ」
という理由からリアルタイムで集められたら幸せになれるのではと考え、
fluentdを使ってみようとい結論に至った訳です。

なぜfluentdにしたのか

他にもflume(良く知らない)とかあるのになぜfluentdにしたかと言うと下記の理由から

• Rubyで実装されているのでカスタマイズとかプラグイン作る場合も作りやすいかな
• gemとして提供されているのでRubyプロジェクトでは導入しやすいかな
• プラグインがいっぱいある
• RubyKaigiでそのっつさんの下記のお話を聞いていたりで使ってみたかったとかそんな感じ

Fluentd Hacking Guide at RubyKaigi 2014

リアルタイムログ解析もしてみる

Fluentdを使うならElasticserchとKibanaも導入してリアルタイムログ解析も楽しそうなので導入を決定

Fluentdのセットアップ

今回はnginxのアクセスログとRailsのアプリケーションログの中のエラーを抽出してAggregatorに集約したいと思います。
セットアップ前にちょっとfluentdについて説明
いくつかの種類のノードがあるので今回関係あるものを軽く説明

Forwarder

Aggregatorにイベントを送信するノード

Aggregator

各Forwarderから送られるイベントを集約する為のノード

セットアップ

今回はgemを使ってセットアップしますが他にもrpmパッケージからのインストール等複数の選択肢がありますので
下記を参考にしてください。
http://docs.fluentd.org/ja/categories/installation
Ruby等は既にinstallしている前提です。
Rubyのinstallは過去記事をご覧ください。

ForwarderとAggregatorで実行

$ gem install yajl-ruby --platform=ruby # gem install fluentdで正常にinstallできない場合があったので実行
$ gem install fluentd
$ fluentd --setup ~/fluent # ~/fluentdのディレクトリにfluentd用の設定ファイル等を作成する
$ fluentd -c ./fluent/fluent.conf -vv & # 設定ファイルを指定し起動
$ echo '{"json":"message"}' | fluent-cat debug.test # 動作テスト
2014-11-29 17:27:09 +0000 debug.test: {"json":"message"} # こんな感じのログが出力されるはず

Forwarderのconf設定

$ vi ~/fluent/fluent.conf
# Nginx access logの設定
<source>
  type tail # 
  path /var/log/nginx/access.log # nginxのaccess logのpath
  format nginx # fileのフォーマット
  tag nginx.access # tag名
  pos_file /var/log/fluent/nginx.access.pos # position fileを保存しておくpath
</source>

# Rails errorの設定
<source>
  type tail
  path RAILS_ROOT/log/rails.log # Railsのlogのpath指定
  format multiline # 複数行のログを送りたいときに指定
  format_firstline /.*[eE]rror.*/ # Errorもしくはerrorを含む行からformatNの条件を満たすログまでを送信する
  format1 /(?<error>.*[eE]rror.*)\n\n/ # 改行が連続している部分まで送信する
  tag rails.error # tag名
  pos_file /var/log/fluent/rails.error.pos # position fileを保存しておくpath
</source>

<match *.*> # この条件にmatchするtagを下記の条件でごにょごにょする
  type forward
  buffer_type memory # Fluentdの内部バッファリングにmemoryを使用
  buffer_chunk_limit 256m # チャンクのサイズ
  buffer_queue_limit 128 # チャンクキューの長さ
  flush_interval 5s # データフラッシュの間隔
  <server>
    host aggregator_host # aggregatorのIP
    port aggregator_port # aggregatorのfluentの使用portを指定
  </server>
</match>

Aggregatorのconf設定
今回はelasticsearchへの送信とlocalにlog fileとして保存を行う設定です。

$ vi ~/fluent/fluent.conf
<source>
  type forward
  port aggregator_port
</source>

# tag名がnginx.*の設定
<match nginx.*>
  type copy
  <store>
    index_name nginx
    type_name nginx
    type elasticsearch
    include_tag_key true # tag keyの設定
    tag_key @log_name # tag key名
    host localhost # elasticsearchのhost
    port 9200 # elasticsearchのport
    logstash_format true # Kibana用にlogstashフォーマットで出力するオプション
    flush_interval 3s
  </store>

  # localに保存したいので設定
  <store>
    type file
    path /var/log/fluent/nginx.access_log # 保存する際のpath
  </store>
</match>

# tag名がrails.*の設定
<match rails.*>
  type copy
  <store>
    index_name rails
    type_name rails
    type elasticsearch
    include_tag_key true
    tag_key @log_name
    host localhost
    port 9200
    logstash_format true
    logstash_prefix rails
    flush_interval 3s
  </store>

  # localに保存したいので設定
  <store>
    type file
    path /var/log/fluent/rails.access_log # 保存する際のpath
  </store>
</match>

Aggregatorでpluginのinstall

$ fluent-gem install fluent-plugin-elasticsearch
# fluent-gemのコマンドが無いって言われた場合
$ vi ~/.bashrc
+ export PATH="$HOME/.rbenv/versions/2.x.x/bin/:$PATH" # rubyのversionは環境に合わせて変更
$ source ~/.bashrc

confを更新したのでfluentを再起動します。
以上でfluentの設定は終わりー

fluent.confのformatに関して

Forwarderのconfのformatに関してですが
formatで設定された正規表現を使ってログの文字列に対してRubyのmatchを使っているイメージ
なのでRubyの正規表現の名前付きキャプチャ等を理解していると設定が楽になるかと思います。

Elasticsearchのセットアップ

今回はAggregatorのserverでelasticsearchを動作させる

$ sudo yum install curl-devel java-1.7.0-openjdk
# elasticsearchもyumでinstallする
$ sudo vi /etc/yum.repos.d/elasticsearch.repo
+ [elasticsearch-1.3]
+ name=Elasticsearch repository for 1.3.x packages
+ baseurl=http://packages.elasticsearch.org/elasticsearch/1.3/centos
+ gpgcheck=1
+ gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch
+ enabled=1
$ sudo yum install elasticsearch

Kibanaのセットアップ

kibanaもAggregatorのserverにいれる
kibanaへのアクセスはnginxを使うのでnginxも一緒に入れるよ

nginxのセットアップ

$ sudo yum install nginx
$ vi /etc/nginx/conf.d/kibana.conf
server {
    server_name localhost;

    location /kibana/ {
         root /usr/share/nginx/html;
         index index.html index.htm;
    }
}

kibanaのセットアップ

$ wget https://download.elasticsearch.org/kibana/kibana/kibana-3.1.1.tar.gz
$ tar xvzf kibana-3.1.1.tar.gz
$ mv kibana-3.1.1 /usr/share/nginx/html/kibana
$ cd /usr/share/nginx/html/kibana
$ vi config.js 
# 32行目 elasticsearch: "http://"+window.location.hostname+":9200",
# 上記をAggregatorのhost nameに変更

動作確認

設定が完了したのでAggregatorでミドルウェアを起動させる

$ sudo /etc/init.d/nginx start
$ sudo /etc/init.d/elasticsearch start

これでhttp://aggregator_host/kibanaにアクセスするとこのようにkibanaの画面が表示されるはずです。

抜けている部分があるかもしれませんが
こんな感じで導入は終了です。
fluentのconfの設定をいじって各々の環境や要件に合わせたログ収集を行えば幸せになれるのではないでしょうか
fluentのその他の設定は下記を参考にしてください。

ActiveRecordでデータを更新後に任意のカラムのデータが更新されたかを知る方法

ActiveRecordで更新後に更新前の値を取得する - まっしろけっけ

以前上記のブログで紹介した内容なのですが、
カラムのデータが更新される前の値が知りたいのではなく、
カラムが更新されたかをどうかのみを知りたい場合にもっと便利なmethodがあったよ。

class User < ActiveRecord::Base
  def change_name
    # 何かしらの処理
  end
end

上記のような前回と似たようなmodelを使用して説明します。
下記のコードのような処理が行われnameが変更された場合のみ
change_nameメソッドを呼びたい

user = User.find(1)
user.name = "hoge"
user.save!

columnname_changed?を使用すると変更前の値を取得出来る

今回はnameカラムが変更されたか知りたいのでname_changed?を使用します。
下記の様にafter_updateで判定を追加してみる

class User < ActiveRecord::Base
  after_update do 
    change_name if name_changed?
  end

  private
  def change_name
    p "hoge"
  end
end

これで先ほどの様にfindからsave!まで行うとchange_nameが呼ばれhogeが出力されているかと思います
sexのみを変更してもchange_nameは呼ばれないと思います

誤解を招きそうだったので追記

user = User.find(1)
user.name = "hoge"
user.name_changed? # true
user.save!
user.name_changed? # false

上記のようになるのでafter_update等のcallbackで使用する際はchanged?で変更されたかを確認出来ますが
callback外ではsave後は判定には使用出来ませんので注意を

sidekiqを2から3にupgradeしたときにしたこと

最近rails applicationで使用しているsidekiqを2から3にupgradeしたのでその際にやったことをメモ

Gemfile更新

まずGemfileを変更します。
Capistranoでのdeployを行っているのでcapistrano-sidekiqも追加します。
※version指定はそれぞれの方針で行ってください。

- gem 'sidekiq', '~>2.0'
+ gem 'sidekiq', '~>3.0'
+ gem 'capistrano-sidekiq' # 3系から別gemに切り出された模様

実際に更新してみる。

$ cd rails_root
$ bundle update sidekiq

deploy.rbを変更

capistrano関連が別gemになったのでrequireするパスを変更する

- require 'sidekiq/capistrano'
+ require 'capistrano/sidekiq'

おまけ(generator)

基本的には上記の変更で簡単にupgrade出来ると思います。
おまけとしてv3.2.2から追加されたgeneratorの使い方を紹介

$ cs rails_root
$ rails g sidekiq:worker User # Userは作成したいworker名
      create  app/workers/user_worker.rb
      create  test/workers/user_test.rb
$ more app/workers/user_worker.rb
class UserWorker
  include Sidekiq::Worker

  def perform(*args)
    # Do something
  end
end
$ more test/workers/user_test.rb 
require_relative 'test_helper'
class UserWorkerTest < MiniTest::Unit::TestCase
    def test_example
      skip "add some examples to (or delete) #{__FILE__}"
    end
end
$ rails g sidekiq:worker HogeHoge
      create  app/workers/hoge_hoge_worker.rb
      create  test/workers/hoge_hoge_test.rb

Rspecをrequireしていればrspec用のテストファイルが作成されるみたいです。

Genymotionでunable to connect to your virtual deviceというエラーで起動しない時の対処

Genymotionは高速なAndroidのエミュレータのことです。
今回は起動時に「unable to connect to your virtual device!・・・」というエラーが発生したので
インストールから解決方法までをメモしていきます。

インストール方法

Genymotionこちらからダウンロードしてください。

ダウンロードするには登録が必要になってます。

起動

初回起動すると「You have no virtual device availabe yet.」とあるので「Yes」
その後登録したアカウントでログインをすると下記の画像のようにAndoridエミュレータのイメージ一覧が表示されるので
好きなdeviceを選択してください。(今回はXperia Zを選択)

ログインが終わると下記のようにDL済みのイメージ一覧が表示されるのでお好きなイメージを選択するとエミュレータが起動します。

エラーが発生した場合

ネットワークの初期設定によっては下記のようなエラーが発生してしまう場合があります。

その際はVirtualBoxの環境設定>ネットワークと進みます。

下記のような設定でアダプタを追加もしくは編集します。

アダプター
  IPv4アドレス:192.168.56.1
  IPv4ネットマスク:255.255.255.0

DHCPサーバ
サーバを有効化にチェック
  サーバー アドレス(R):192.168.56.100
  サーバー マスク(M):255.255.255.0
  アドレス下限(L):192.168.56.101
  アドレス上限(U):192.168.56.254

その後VirtualBox マネージャーで対象のイメージを選択し設定(黄色の歯車マーク)を選択>ネットワークと進みます。

下記のように設定を変更します。
(上記でアダプタを追加ではなく編集した場合は既に設定されている可能性があります)

ネットワークアダプターを有効化にチェック
  割当(A):ホストオンリーアダプター
  名前(N):先ほど追加or編集したアダプタを選択

上記の手順で変更して再度Genymotionでイメージを選択すれば正常に起動するはずです。

Rails3から4へUpgradeしたお話

今回はお仕事で開発をしているweb applicationで使用しているRuby on Railsのversionを
3.2から4.1へUpgradeしたお話です。
その際の進め方や遭遇した問題をメモてきにまとめておきます。

Rails3のコードをRails4のコードにconvertする

今回はRubyKaigiでお話を聞いてきたsynvertというgemを使用しました。
デフォルトのsnippetsをそのまま使用するとskip_filterがskip_actionに変換され(正確にはskip_action_callback)エラーが発生する等細かいバグがあるのでforkしてごにょごにょして使用しました。

$ gem install synvert
$ synvert -l # snippetの一覧が表示される
$ synvert -r rails/upgrade_3_2_to_4_0 # rails 3.2から4.0へのコードの変換
$ synvert -r rails/upgrade_4_0_to_4_1 # rails 4.0から4.1へのコードの変換

synvertはこちらでweb toolも公開してます。

Gemfileを更新する

次はGemfileを変更します。

- gem 'rails', '3.2.19'
+ gem 'rails', '4.1.6'

- gem 'strong_parameters' # 事前に導入していた為削除(Rails4からはRailsに含まれています)

とりあえずrailsのversionを変更

$ bundle update rails

使用しているgemの依存関係でエラーが出たので
逐一使用している各gemのversionを適切なものを使用するように書き換えました。

config関連の修正

# config/application.rb
- require "active_resource/railtie" # active_resourceはgemに切り出されました。gemも使用していないので削除

- config.paths["config/routes"] << Rails.root.join("config/routes/hoge.rb")
+ config.paths["config/routes.rb"] << Rails.root.join("config/routes/hoge.rb")

# config/environments/*.rb
- config.active_record.auto_explain_threshold_in_seconds = 0.5

セッション flash の互換性維持の為

# config/initializers/cookies_serializer.rb
- Rails.application.config.action_dispatch.cookies_serializer = :json
+ Rails.application.config.action_dispatch.cookies_serializer = :marshal

matchを使用する場合は明示的に記述する必要がある為

# config/routes.rb
- match "hoge" => "hoge#index"
+ match "hoge" => "hoge#index", via: [:get, :post]

staging環境をproductionと一緒の設定で動作させる為

# config/secrets.yml
+ staging
+   secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

secret_key_baseの生成方法

$ rake secret
=> "secret_key_base"

envの設定

$ vi ~/.bashrc
+ export SECRET_KEY_BASE="上記で生成したsecret_key_base"

model関連の修正

ActiveRecord Relation周りの変更対応(shift,pop等一部のmethodがない)

# rails 3.2
users = User.limit(10)
users.pop

# rails 4.1
users = User.limit(10)
users.pop
# NoMethodError: undefined method `pop'

# rails4.1でrails3.2と同じ挙動にする場合
users = User.limit(10).to_a
users.pop

conditionsがdeprecatedになった為

+ has_many :posts, conditions: '`id` <= 100000'
- has_many :posts, -> { where('`id` <= 100000') }

minimumのオプション修正(オプションでjoinsとか渡せなくなった？)

- Post.minimum('rank', {joins: :user, group: :user.id})
+ Post.joins(:user).group(:user_id).minimum('rank')

slow queryに注意

ActiveRecordにて自動で生成されるqueryで数カ所slow queryが発生していた為
修正が必要になりました。

sweeperの削除

sweeperがrails-observersというgemに切り出された為にsweeperを削除
fragment cacheのキーにupdated_atを含んで更新されたら別cacheを使用するように変更(なんで最初からupdated_atを使わなかったのか・・・orz)
rails-observersを使用してもいいと思います

test修正

上記の作業が一通り終了した段階でtestを走らせて落ちている部分を修正していきました。
testはrspec3を使用しています。

一部gemで問題発生

Upgrade作業を開始した当初はcomposite_primary_keysの最新版がRails4.1.6に対応しておらず
一部でエラーが発生していました。
しかし、commit履歴を見ると4.1.6対応は行われているもののreleaseがされていないといことで下記のようにGemfileを変更してみました。

- gem 'composite_primary_keys', '7.0.10'
+ gem 'composite_primary_keys', git: 'https://github.com/composite-primary-keys/composite_primary_keys', branch: 'ar_4.1.x'

その後bundle installでrails serverを立ち上げようするとcomposite_primary_keysでエラーが発生してしまったので、
composite_primary_keysをforkしてerror箇所を修正しpull requestを送りGemfileで指定しているrepositorieを自分のrepositorieに変更して動作確認を行いエラーが発生しないことを確認しました。
(Rails4.1.6へのUpgradeリリース前にpull requestがmergeされcomposite_primary_keysの7.0.11もリリースされたのでGemfileを変更し7.0.11を使用するように変更しました)

そもそもcomposite_primary_keysを使用する設計が・・・

動作検証

testが全て通っても心配なので動作検証はちゃんと行いました。
cache周りとmodel周りでバグがそれぞれ一件あったので修正

感想

上記のような手順でUpgrade作業を進めて無事にリリース出来ました。
実際には上記の手順の内Rails3.2で対応しておいても問題にならない部分はRails3.2で対応してリリースしておき、
Rails4への移行の際には最小限の作業ですむように事前に準備しておきました。

今回も感じたのはtestがしっかりしていると実際に動作検証した際の不具合も少なくて済み
安心感がありました。

以下の記事が特に参考にさせて貰った記事です

• Rails 4 へのアップグレード時に遭遇した問題 - クックパッド開発者ブログ
• Rails4へのアップデート時に引っかかったポイントいくつか - Qiita

nagareboshiっていうgemをつくったよ

nagareboshiというgemを作成して公開したのでお知らせてきな

なにをする為のものか

googleのpubsubhubbubを使う為のもの

pubsubhubbub is 何？

こことかに詳細は書いてありますが、
作成したwebページをgoogleにインデックスさせるには今までsitemap.xmlにURLを記述し、
google botがsitemap.xmlの内容を不定期に読みにきてインデックスされるのが一般的でした。

この場合インデックスされるまでに時間がかかったり、
その他諸々問題がありましたがpubsubhubbubを使用すると、
こちらから「新しいページ作成したからインデックスに追加して！」というのをpushできる仕組み

pubsubhubbubは気象庁のページの図が分かりやすいかと(気象庁の場合xmlの配信に使っているみたいですね)

使い方

shiro16/nagareboshi · GitHubこちらのREADMEでも記述してますが簡単に説明

1.initialize

Nagareboshi.configure do |config|
  config.send = true # sendをtrueにすると実際にPOSTでデータが送られます。
  config.send = Rails.env.production? # Railsの場合はこのような記述で本番環境でのみ送信されるので安全です。
end

2.URLをインデックスさせる

Nagareboshi::Sender.publish("http://example.com/") # http://example.com/をインデックスさせてみる

※ HTTP status 204が返ってくるみたいです

3.複数のURLをまとめてインデックスさせる

urls = ["http://example.com/", "http://example.com/1"]
Nagareboshi::Sender.publish(urls)

※この方法はこちらのページで下記のような記述があるので同じキーで複数データを投げているのですがgoogle先生がいい感じにしてくれるのかが謎なので心配な方は2の方法を使った方がいいかもです。

hub.url equal to the feed URL of the feed that has been updated. This field may be repeated to indicate multiple feeds that have been updated

こちらに関してはもう少し調査します。

4.デバッグ等

configureでどちらかを設定すればデバッグ等もしやすいかと思います。

Nagareboshi.configure do |config|
  config.host = "localhost" # requestをlocalhostに送る
  config.send = false # 実際にrequestを送らない設定
end

その他

• 今回gemを作ろうと思ったきっかけがここのmethod名の実装をしてみたかっただけだとかそうじゃないとかいう噂
• subscribe用のmethodも今後updateで対応していきたい
• google先生が公開しているgemも実はあります。igrigorik/PubSubHubbub · GitHub
• はじめて予約投稿機能を使ってみた