ブックマークはもういらない!? 再検索を最適化するサービス「X-History」を開発しました

再検索を最適化するための、「思い出す」ことに特化した履歴検索サービスX-Historyを開発しました。ブラウザの拡張から閲覧履歴を取得し、自分が閲覧したウェブページのなかから検索を掛けることが出来るサービスです。現在はまだβ版と言った所であり、試しに使っていただけるユーザーさんを募集しています。

X-Historyは思い出すことにフォーカスした検索サービスです。そしてその特徴として、大きく3つの特徴を持ったサービスです。

各ユーザー毎にパーソナライズされた検索エンジンを提供する

1つは、各ユーザー毎にパーソナライズされた検索エンジンを提供する点です。ユーザーが訪れたことのあるサイトのみにフォーカスすることにより、もう一度同じページを見つけたいときにノイズの入らない検索結果を返すことができます。一度見たことのあるサイトをgoogleなどの他の検索エンジンで探そうとすると、不要な情報が混じることが多く探すのが時間がかかってしまったり、結局見つからない場合が多いです。

検索結果をスクリーンキャプチャと共に表示する

2つめは、検索結果をスクリーンキャプチャと共に表示する点です。もう一度ページを見つけたいと思ったときに、タイトルや文章、URLだけで果たして正確に求めるページに訪れることが出来るでしょうか？検索結果に表示されるリンクをクリックしてページを実際に目で確認して回るということをしてはいませんか？X-Historyは検索結果をウェブページのスクリーンキャプチャとともに表示するので、あなたが何となく抱いている目的のページを思い出すことを容易にします。文字だけから目的のページを思い出すことは難しいですが、そのページのデザインや雰囲気から思い出すことはより容易なものです。

自分にとってのページの重要度を自動で判定する

最後にいまだ発展途中の特徴ですが、自分にとってのページの重要度を自動で判定することです。X-Historyはあなたのページ上の滞在時間から、あなたにとってのそのページの重要度を算出します。現時点では滞在時間のみを判定に使用していますが、将来的には、あなたのページ上でのアクションをもとに、自動で重要度を判定することも考えています。これにより、ブックマークする必要性を無くしたいと考えています。ブックマークの管理は案外大変なものです。重要そうだからとブックマークしておいても結局２度と触らなかったり、ブックマークした気がしたサイトがブックマークされていなかったり。果てはブックマークが増えすぎてもはやブックマークから目的のサイトにたどり着けなかったり。将来的には、あなたにとって重要なサイトはすべてあなたの代わりにX-Historyが自動で覚えておくようになるでしょう。

これは、昨年12月に行なわれたStartup Weekend Sendaiにおいて優勝したときに企画したものです。 @n0bisukeと友人Tと僕の3人のチームx-historyが企画したサービスになります。卒論などのためにあまり時間を割けず、開発に時間がかかってしまいましたが、ようやくβ版とはいえ形にすることができました。いろいろとお力添えいただいた皆さんには感謝しております。今後のとりあえずの所としては、いろんな人に使ってもらいながらフィードバックを得つつサービスの価値検証および、ブラッシュアップをして行ければ良いなと思っております。

開発して行く中で色々と失敗したなと思ったこともあってそれも書こうかと思っていたのですが、ボリュームが多くなってしまいそうなのでまた後でまとめようかなと思います。

X-Historyをつかって、みなさんの再検索の体験を改善してみてください。

X-History

Sidekiqのワーカープロセスが増殖してメモリを食い殺す

現在開発を進めていたアプリで、スクレイピングをするためにワーカーに処理を投げるということを行なっていました。その際にSidekiqを使用していたのですが、Sidekiqのワーカープロセスが増殖してサーバーのメモリを食い殺す。という自体が起きてしまい、エラーが頻発するようになってしまったのでその原因を探ってみました。

当初の段階で怪しいと思ったのはSidekiqのconfig/initializers/sidekiq.rbで設定ファイルに不備があるかconfig/unicorn/production.rbでUnicornの起動時にRedisとコネクション結ばせている設定がおかしいかの部分ではないかと見込みを付けてみました。

元の設定はこんな感じ

config/initializers/sidekiq.rb

  Sidekiq.configure_server do |config|
    config.redis = { url: ENV['REDIS_URL'], namespace: "sidekiq_#{Rails.env}" }
  end

  Sidekiq.configure_client do |config|
      config.redis = { url: ENV['REDIS_URL'], namespace: "sidekiq_#{Rails.env}" }
  end

config/unicorn/production.rb

*
*
*

after_fork do |server, worker|
  Signal.trap 'TERM' do
    puts 'Unicorn worker intercepting TERM and doing nothing. Wait for master to send QUIT'
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection

  # When in Unicorn, this block needs to go in unicorn's `after_fork` callback:
  Sidekiq.configure_client do |config|
    config.redis = { :url => ENV["REDIS_URL"] , :namespace => "sidekiq_#{Rails.env}"}
  end
end

んで、調査を進めて行った所あまり、参考に出来そうな記事を見つけられず。MRIのバグやら,Sidekiqのメモリリークだなんやらという話がでてくる。解決出来なそうで不安になる。

Sidekiq not deallocating memory after workers have finished

Memory leak?

これも問題は問題だが、今回の状況とはちょっと異なる気がする。よくわからなくなって来たのでSidekiqのソースコードを読み始める。

途中、可愛いメソッド見つけてなごんだ。こんなメソッドも動くんだー。

とふと気がついて、Capistranoでのデプロイ時になんかおかしいことが起こってるのではないかと主行ったって調べた所、見事Sidekiqのpidファイルを見つけられずにプロセスを終了させずに新たにプロセスを生成していたことを発見。

バグは、capistranoのsidekiqのpidを指定する部分でフルパスを渡していたせいでした。

config/deploy/production.rb

set :sidekiq_pid, "#{current_path}/tmp/pids/sidekiq.pid"

変更後

config/deploy/production.rb

set :sidekiq_pid, "tmp/pids/sidekiq.pid"

これで、しっかりとSidekiqの再起動時にプロセスがkillされるようになったはずなのでメモリを異常にくうことは無くなったはず。Capistranoがkillできなかった場合に止まってくれなかったこと、それに気付かなかったこと。そしてpidファイルのパス指定が賢くなかったことが重なった悲劇でした。ずっと悩んでいたのですがようやく解決。

にしてもSidekiqのメソッド可愛いですね。