Mac+rbenvでconfigure: error: something wrong with LDFLAGS=”…”とか言われた時のいち解法

今日は多摩川花火大会をやっていまして、今まさに自室の窓の外から花火が見え音が聞こえる中こんなブログ記事を書いています。ダイナマイト漁で捕獲でもされている気分です。

さて、El Capitanでrbenvを使っていて、rbenv installをしようとしたときこんなかんじのエラーが出てちょっとハマりました。

% rbenv install 2.2.3
Downloading ruby-2.2.3.tar.bz2...
 -> https://cache.ruby-lang.org/pub/ruby/2.2/ruby-2.2.3.tar.bz2
Installing ruby-2.2.3...

BUILD FAILED (OS X 10.11.6 using ruby-build 20160602-31-gf085feb)
...
checking whether LDFLAGS is valid... no
configure: error: something wrong with LDFLAGS="-L/Users/(myname)/.rbenv/versions/2.2.3/lib "
make: *** No targets specified and no makefile found.  Stop.

このエラーはいろんな状況で起こるようです。autoconfのログを見てもよくわかりませんでした。
ググってみると、やれrbenvプラグインのruby-buildが古いだの、やれ特定バージョンのrubyで起こるだの、gccを消せだの、brew doctorしろだの、手動ビルドしろだの…などなど、さまざまな原因でこの現象が起こるようですが、
僕の場合はLIBRARY_PATH環境変数に書いてあったディレクトリが実在しなかったことが原因でした。

つまり、

LIBRARY_PATH=/usr/local/lib:/usr/lib:/lib

だったのですが、僕の使用するEl Capitan機に/libというディレクトリは存在しなくて、それが結局rbenv installのエラーを引き起こしていました。
なので、環境変数から/libを除くか、/libをmkdirすると、rbenvのビルドは死ななくなりました。
エラーメッセージ自体からはそのことを直接は読み取れなかったので、ハマりました。

ご参考までに。

【灰色魔術】Rails.loggerと独自Loggerのログレベルを同じにさせたかった

お魚といえば安いものから高いものまでピンきりですが、上はどこまでいくんでしょうか。魚ですよ!値段順で調べるで見ると、マグロなどが高いのはやはり用意に想像がつくところですが、キログラム単価で見た時には特にウニやかずのこなど量が取れないものがぶっちぎってるんですね。

さて、RailsのLoggerでは、ログレベル、すなわちどのレベルのログまでがログファイルに保存されるかを指定することができます。

Rails.logger.level = :info

この辺りは既に十分いろんなわかりやすい説明があるのでそのあたりをご参照いただくとして。
Debugging Rails Applications — Ruby on Rails Guides

一方で、独自ライブラリ等でRailsと独立のロガーを持っている場合、すなわちRails.loggerと別にLoggerのインスタンスを持っていて、そいつのログレベルを設定するときには、小文字シンボル:infoや:warnでは設定できません。
Loggerクラスに定義されている定数Logger::INFOやLogger::WARNを指定する必要があります。

$logger = Logger.new(STDOUT)
$logger.level = Logger::INFO

では、Railsでアプリを書いていてなおかつそのログレベルを環境変数等で指定可能にしたいが、その際にそういった独自Loggerのログレベルも一致させたい場合はどうすれば。
ちょっと何を言っているかわかりにくいでしょうが、下記のコードのようなことです。

log_level = (ENV['LOG_LEVEL'] || :info).to_sym
Rails.logger.level = log_level.downcase
$logger = Logger.new
$logger.level = Logger.const_get(log_level.upcase)

Rails.logger.levelにつっこむシンボルを使って強引にLoggerクラスの定数をRubyのClassに実装されているconst_getを使って動的にひっぱってくる…というような方法をとっています。
黒魔術的というほどではないですが少し灰色なかんじ。

このようにすれば、Railsのloggerのログレベルと独自Loggerのログレベルを一度で同時に指定できるようになります。
例えば

% LOG_LEVEL=Debug rails c
> Rails.logger.level
:debug
> $logger.level
0
# ↑ Logger::DEBUGの値

そもそもRails.logger.levelも:infoなどのシンボルではなくLogger::DEBUG(=0)など数値で指定することもできるのですが、
その場合もこの技法を活用すればユーザ指定時(シェルから%LOG_LEVEL=WARN rails cする場合)などでは文字列で書けるので便利と言えそうです。

指定されたLOG_LEVELの文字列自体が正しくない(例えば%LOG_LEVEL=DEBUUUG rails cなどと書いてしまった)場合も、const_getが例外を吐いてくれるというチェック機構が自動で働くことになるので、直接数値を指定可能にする(で数値の範囲を独自でチェックするロジックを書く)よりもラクで安全という面もあるかもしれません。

ログの収集や活用・分析などなど(fluentdとか)についてはまた備忘録がてらにまとめたいところもありますが、またの機会に。

Railsログ中の”Rendered xxxx.html.erb”を静かにさせたかった

お魚の可食部の重量に占める割合というのは、もちろん種類によって変わってくるのですが、しらすなどではもちろん100%、一方でスズキなどでは40%程度と低いようです。ただしらすは稚魚ですので、成魚と比べるのは厳しい判定かも。
さて、Rails(Rack)がGETリクエストひとつに対して吐いてくれるアクセスログは、下記のような雰囲気になります。
このうち、xxxx.html.erbをレンダリングしたよ!という情報は特に本番ではあまり必要でないことが(自分の状況では)多いので、これを静かにしてしまいたくなりました。

[2016-08-02T15:58:51](pid: 23067) INFO  -- Started GET "/" for 127.0.0.1 at 2016-08-02 15:58:51 +0900
[2016-08-02T15:58:51](pid: 23067) INFO  -- Processing by HomeController#index as HTML
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered home/_user_objects.html.erb (5.9ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered home/index.html.erb within layouts/application (11.4ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered application/_navbar.html.erb (173.5ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered application/_image_box.html.erb (0.3ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered application/_image_box.html.erb (1.2ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered application/_image_box.html.erb (0.9ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered application/_image_box.html.erb (0.8ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered application/_image_box.html.erb (1.0ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered application/_header.html.erb (175.5ms)
[2016-08-02T15:58:52](pid: 23067) INFO  --   Rendered application/_footer.html.erb (0.5ms)
[2016-08-02T15:58:52](pid: 23067) INFO  -- Completed 200 OK in 650ms (Views: 52.1ms | ActiveRecord: 10.0ms)

コチョナナバ: railsの部分テンプレートのログ出力を出さなくする
Hide rendering of partials from rails logs – Stack Overflow
このあたりを参考にして、

# config/environments/production.rb
MyApplication::Application.configure do
  ...
  # Not to show logs like Rendered xxxx.html.erb
  config.action_view.logger = nil
  ...
end

のように設定すると、このrenderingのログだけがいいかんじに静かになってくれます。

[2016-08-03T16:44:20](pid: 5973) INFO  -- Started GET "/" for 127.0.0.1 at 2016-08-03 16:44:20 +0900
[2016-08-03T16:44:20](pid: 5973) INFO  -- Processing by HomeController#index as HTML
[2016-08-03T16:44:21](pid: 5973) INFO  -- Completed 200 OK in 724ms (Views: 53.9ms | ActiveRecord: 9.4ms)

大変Informativeでよろしい。
以上、最初から最後まで完全に備忘録でした。

resque_specはGemfileのtest groupにのみ入れましょうねという雑なお話

季節は夏となりましたが気温の上下が激しく、体温調節が狂って風邪をひきやすそうな気候の今日このごろです。
普通、お魚は変温動物なので体温は周辺水温とほぼ全く同じ(代謝に伴うごく僅かな上昇程度)なのですが、サメの場合は5℃から15℃ほども高いのだそうです。マグロなどの高速で泳ぐ回遊魚にも同様の傾向が見られるのだそうです。そしてマグロの場合は、冷凍保存の質に影響するため比較的シビアな温度計測が求められるとのこと。
さて、Ruby on Rails (にかぎらずRuby)でのジョブキューイングにResqueを使っている際にハマったしょうもない出来事について、忘れないようにメモ。
結論から言うと、Gemfileではresque_specは:test groupだけに入れるようにしましょう、でないとジョブがキューに投入されないですよというだけの雑なお話です。

# Gemfile: Good
group :test do
  gem 'resque_spec'
end

ちゃんと、test環境のみでresque_specをアクティベートするように書きましょう。

# Gemfile: Bad!!!!!!
group :development, :test do
  gem 'resque_spec'
end
# or
gem 'resque_spec'
おこったこと

例えば上記の悪例のように、うっかり:developmentと:testにresque_specを書いてしまった場合。

Development環境(RAILS_ENV=development)でローカルPC上でresqueを走らせてジョブキューイングを実際に試そうとしています。
下記のようにちゃんとResqueを起動し、キューを監視してくれているというのに、

% QUEUE=default bundle exec rake resque:work
 ** [12:00:30 2016-06-07] 25304: Starting worker xxxx:25304:default
 ** [12:00:30 2016-06-07] 25304: Registered signals
 ** [12:00:30 2016-06-07] 25304: Running before_first_fork hooks
 ** [12:00:30 2016-06-07] 25304: Checking default
 ** [12:00:30 2016-06-07] 25304: Sleeping for 5.0 seconds
 ...

例えばコンソールからジョブをつっこんでも、

% rails c
> Resque.enqueue(HardWorker)

resqueサイドのほうが全く反応してくれず、queueingされていない様子…。
redisをのぞいても何かが入っている様子はない。
Resque.infoを見ても何も処理された様子がない。

というような事態になります。
なりました。
2時間ぐらい無駄にしました。つらい。

Gemを入れるとき、あまり深く考えずにdevelopmentとtest両方に入れちゃうことは皆さんままあるようなので(自分も含め)、全般的に少し注意したほうがいいポイントになりそうです。

ちなみに

じゃあ同じ論理で、rspecはテストに使うんだしrspecもtestの中だけに書いてあればいいよね!と思ったらそれも落とし穴だったりします。
rspec-rails は Gemfile で development グループにも入れてあげよう – blog.sorah

参考

Resqueのソース読んだり(結果的にはresque_specを見るべきであったので完全な無駄手間…)、めっちゃググったりしてやっと見つけたのがこちらのStackOverflow
redis – Rails development environment Resque.enqueue does not create jobs – Stack Overflow

resque_specのREADMEにも実はちゃんと書いてあるのですが、そもそもresque_specの不適切な設定が原因だと気づけなかったので、あとになって気づいた次第。あらためて、そもそも入れる時にちゃんと気をつけろという話。
leshill/resque_spec: RSpec matcher for Resque

やられたぜ!

公開Google CalendarからRuby+Google APIでイベントを取得

いよいよ5月も終わり季節は夏にという時期で、お魚的には鮎や鯵などが旬を迎えるという頃合いになっています。今の時期に魚や野菜を食べて夏バテに備えたいものです。

さて、Google Calendarからイベントを自動で取ってきたいということがあったので、Rubyでやってみました。

(Calendarにかぎらず)Google各種サービスのAPIは公式のGemが公開されており、これを使うのが最も簡単です。
Ruby Quickstart | Google Calendar API | Google Developers
Class: Google::Apis::CalendarV3::Calendar — Documentation for google/google-api-ruby-client (master)

さらに、各ブログなどで既にGoogle Calendar API (v3)を使う方法についてはよくまとまっています。
RubyでGoogleカレンダーの情報を引き抜いてみる – 鶏頭のプログラム
rubyにてgoogleカレンダーの情報を取得する – Qiita

この辺りの情報は、基本的に自分の(非公開な)カレンダーを取ってくるものですが、今回僕がやりたいことは、「他人が公開カレンダーのイベントの情報を持ってくる」ことで、
例えば僕個人の予定でなく人力アジャイルイベントカレンダー powered by 名古屋アジャイル勉強会にあるイベントをAPI経由で取ってくる、というようなことをやろうとしています。

上記の参考資料はいずれも、自分のカレンダーにアクセスするためのもので、そのためにOAuthなどのプロセスが必要となっていますが、公開されているカレンダーのイベントを取得するのはもう少しシンプルです。

ということで、ここからはその方法。

Continue reading

PoltergeistのURL Blacklisting/Whitelistingを活用してAjaxスクレイピングを速くする

よくお魚の「脂ののりが良い」といいますが、実際例えば体脂肪率という形で計測するとどうなるのでしょうか。実はそれを測定するためにフィッシュアナライザ™という製品があり、人間用の体脂肪率計と同じ仕組みで非侵襲的な計測が可能なんだそうです。アジなどでは10%とかいうオーダーの数字とのことで、意外とスリム。

さて、Rubyを使ってWebスクレイピングをするときは、個人的にはNokogiriをよく使っています。
通常はNet::HTTPでとってきたHTMLをそのままNokogiriにぶち込めばOKなのですが、非同期での描画を行うAjaxのサイトの解析はそのままではできません。
そこで、PhantomJSのRubyフロントエンドであるPoltergeistをドライバとしてCapybaraを組み合わせると、深く考えることなく静的ページと同じ感覚で解析ができてしまいます。要は、見えないところでまるっとブラウザを動かしてしまって、DOMから仮想的なHTMLを生成させちゃってNokogiriにぶち込む…というようなアプローチです。

require 'nokogiri'
require 'capybara'
require 'capybara/poltergeist'

def wait_for_ajax(session)
  # https://robots.thoughtbot.com/automatically-wait-for-ajax-with-capybara
  Timeout.timeout(Capybara.default_wait_time) do
    return if session.evaluate_script('jQuery.active').blank?
    loop until session.evaluate_script('jQuery.active').zero?
  end
end

def access(url)
  Capybara.register_driver(:poltergeist) do |app|
    Capybara::Poltergeist::Driver.new(app, {
      js_errors: false  #JSに問題があったとき例外を吐かせない。スクレイピングの際は常にfalseがいいです。
    })
  end
  s = Capybara::Session.new(:poltergeist)
  s.visit(url)
  wait_for_ajax(s)
  s
end

def get_html(url)
  s = access(url)
  html = s.html
  s.reset!
  s.driver.quit
  html
end

#あとは普通にNokogiriにぶっこんでゴリゴリやってくだけ!
page = Nokogiri::HTML.parse(get_html(url))
page.css('body')

ちなみに、Capybara::Sessionのインスタンス(accessメソッドの戻り値)に対して、ちょうどfeature specで書くようなマッチャを使ってページに対する操作ができるので、例えば「ここをクリックすると出てくる情報を解析したい」という作業も簡単にできます。

s = access(url)
s.click('Submit')
s.find('.text')  #findを呼ぶとマッチする要素が現れるまで再描画を(デフォルトで2秒間)待ってくれます。
s.html #これをNokogiriにぶち込めばOK

後ろでブラウザがまるごと動いていることの弊害と言ってはあれですが、スクレイピングにあたっては必要ではない情報も非同期でゴリゴリ取ってくることになり、負荷や時間などが増大します。
ということで、そういった必要でない情報は取ってこないようにして少しでも時間と相手サーバの負荷を低減する方法について。

Continue reading

Sidekiq::Schedulerで動的にタスクをぶち込む

お魚の中でもメバルやタチウオなどは夜行性のものとして有名で、特にタチウオなどは昼間沖の深めにいて夜には岸辺の浅いところにくるなど、かなり規則的なパターンで活動するのだそうです。

さて、rubyで野良アプリ書くときバッチ処理エンジンにはSidekiqを好んで使っています。
Sidekiqには日次処理などを簡単に行うため(*1)にSidekiq::Schedulerという拡張gemがあり(*2)、任意の定義済みワーカを例えばcronライクに繰り返し実行することができます。
基本的には各ワーカの実行条件やパラメータをYAMLの形で全て静的に記述し起動時に読み込むというスタイルなのですが、時には動的にワーカをスケジュールに突っ込みたいことがあります。

Sidekiq::Schedulerはもちろんそれもサポートしています。
ただmoove-it/sidekiq-schedulerの説明がいまいちだったので、備忘録も兼ねてまとめました(*3)。

Continue reading

【翻訳】自動テストをすべき5つの理由

最近まで知らなかったのですが、さかな検定(通称ととけん)という検定試験があり、すでに6回実施されているのだそうです。ご推察の通り、さかなクンさんが一枚噛んでいらっしゃるようです。

さて、さいきん仕事でテストを全く書かないチームにジョインしたのですが、やはりこのままではつらい未来しか見えないため、なんとかテストを書くチームに変えていこうとテストをバリバリ書く先輩と一緒に活動を始めつつあります。

ところがいざテストを書くモチベーションを話そうとしてみると、19歳でTDDに出会い初配属部署も「テストは呼吸であり」「テストは義務教育であり」「テスト書けて初めて法の下の平等と基本的人権が主張できる」環境で過ごしてきた今になって言葉に集めるのも骨が折れそうだったので、ちょうど見つけた短めでわかりやすい英語記事を紹介することにしました。
今回はそれを和訳したものを紹介します。

この度翻訳した記事はこちら。
5 advantages of automated testing vs. manual testing.

Continue reading

2015年現地参戦したJリーグスタジアム

日本の自治体(市区町村)は全部で1936あるようですが(*1)、名前に「魚」の文字が入っている自治体数は意外にも4つと少なく、そのうち3つが新潟糸魚川市・魚沼市・南魚沼市、1つが富山県魚津市と、北越に集中しています。魚へんの漢字(*2)を地名に含む自治体に広げても、鯖江市や鰺ヶ沢町などを加えて、東北と北越の9自治体のみでした。

さて、数年前からJリーグを見るようになりまして、今年は地元のレノファ山口FCがJ3リーグ参入を果たしたのをきっかけにいよいよ本格的に観るようになりました。
生観戦の魅力は計り知れないものがあり、またスタジアムそのものも興味の対象だったりするため、今年足を運んだスタジアムについてざっくりとまとめてみました。
(ゴール裏の開放されない試合を除き)全てゴール裏、いわゆるコアサポとして観戦しています。

soccer

Continue reading

嫁の顔忘れてもTimecop.returnは忘れないでねという話

夜釣りでは初心者向けの狙い目といえばアナゴなんだそうです。岸壁で釣れちゃうんだとか。ウナギはお高いのでアナゴで一杯、とかあるんだろうか。
さて、Rubyでいろいろ開発していて時間(時刻・期間…)が絡むテストをするときTimecopが便利で広く使われます。
travisjeffery/timecop – GitHub

# 現在時刻を変える
> Timecop.travel(Date.parse('1998/12/1'))
=> 1998-12-01 00:00:00 +0900
> Date.today
=> Tue, 01 Dec 1998
 
# 時間の進行を止める
> Timecop.freeze(Time.parse('1998/12/1 0:00:00'))
=> 1998-12-01 00:00:00 +0900
> sleep(10)
> Time.now
=> 1998-12-01 00:00:00 +0900  # it's still 0:00:00
 
# 時間の進行を早める
> Timecop.travel(Time.parse('1998/12/1 0:00:00'))
> Timecop.scale(3600)
> sleep(2)
> Time.now
=> 1998-12-01 02:00:19 +0900  # it took 2 hours although only slept for 2 seconds

便利ですね。
時間をいじくるので、

  • タイムゾーン周りをミスってないか
  • DBMSのタイムスタンプやredisのexpireのようにruby処理系の時間を使わないものでは効かない

こんなかんじで注意が必要なのは当然なのですが、一番しんどいのはTimecopで変えた時間を戻し忘れたときの挙動不審なかんじでしょうか。
テストでTimecopを使う場合、このテのミスをするとたいてい別のテストケースに影響しますね。順序依存で効いてくるし煽りを食ったテストケース自体は何も悪く無いことがほとんどなので、心神耗弱状態になります。

  • なぜかCapybaraのCookieが取れなくなっている
  • redisではうまくいくのにredis_mockでテストすると想定外の挙動になる
  • Timeoutが狂う

こんなことで時間をムダにするのはあほらしいので、Timecop.returnを呼ぶのは絶対に忘れないようにしましょう。

> Timecop.travel(Time.parse('1998/12/1 0:00:00'))
> Timecop.return
> Date.today
=> Sun, 20 Dec 2015

「忘れないでね」「気をつけてね」はものごとの解決策としては最悪な思考停止なので、
Rails/RSpecをお使いなら、spec/spec_helper.rbにて

config.after(:each) do
  Timecop.return
end

なる設定をしておくべきです。
また、別の安全策として、Timecopのsafe_modeといい、Timecopを使うときはblockを与えることを強制し、block末尾でreturnが自動で行われるようにする仕組みがあります。
blockを渡さずに呼ぶと例外が飛ぶので、すぐに気づきます。

> Timecop.safe_mode = true
> Timecop.travel(Time.parse('1998/12/1 0:00:00'))
Timecop::SafeModeException: Safe mode is enabled, only calls passing a block are allowed.
...
> Timecop.travel(Time.parse('1998/12/1 0:00:00')) do
>   Date.today
> end
=> Tue, 01 Dec 1998
> Date.today
=> Sun, 20 Dec 2015

Rails/RSpecのみで使うなら、spec_helperのafterでケアするのがシンプルにして安全十分かと。
テスト以外でも使うなら、safe_modeにするようinitializerなどで設定しておくほうが安全そうです。

全部Githubに書いてあるんですけども、1ヶ月近くこれにハマってしまった自分が本当にあほらしかったので忘れないように…。