読者です 読者をやめる 読者になる 読者になる

一人でwebサービスをリリースして二年間でやったこと

 Study Mailを個人で開発し、リリースして二年が経ちました。その間にやっていたことをまとめておきます。

やったこと

  1. SESの導入
  2. API投入前処理
  3. 出会い系対策
  4. エリア機能・コミュニティ機能追加
  5. サーバーの移転
  6. 既読処理の変更
  7. 対応サービスの拡大
    1. github
    2. peatix
    3. doorkeeper
  8. IT系以外への利用への対策
  9. キーワードの誤爆防止対策

SESの導入

 Study Mailはメールで勉強会のお知らせを配信するサービスなのですが、配信機構は最初はGoogle APPSのメールサーバーに投げてBCCに突っこんだアドレスに配信させる、という非常にプリミティブなものでした。
 しかしすぐにGmailでの不達が頻発したためこれをやめ、Amazon Simple Email Service(SES)に変更しまして解消しました。

API投入前処理

 キーワード抽出はYahooの重要度抽出APIとタイトルの正規表現マッチの二系統なのですが、APIの方が一時「セキュリティ」という単語に過剰反応するようになったため、「セキュリティの都合で」みたいな文章を消してから投入するようにしたのが始まりです。現在ではこの他にも「Facebookグループ」みたいなよくありがちで誤爆しやすい文章を消したり、関連勉強会と称して大量にキーワードをちりばめたり、略歴が混じって誤爆するようなケースに対応したりなどに使っています。
 リストに入れた正規表現パターンを順番に適用するだけの単純な仕組みですが、後でこれがかなり汎用的なアルゴリズム*1だと気が付いたのは収穫でした。

出会い系対策

 なぜかあまり知られていないのですがほとんどのイベント告知系サイトでは出会い系の告知が大量に投稿されています。数量としてはこちらの方が圧倒的に多く、IT系の勉強会とは桁が一つ違います。
 元々キーワードの設定はこれに対抗する面もあったのですがそれでもすり抜けてくるものがあるため、出会い系でよく使われるキーワードをNG指定してフィルタリングしています。
 ただ、この副産物としてリリースパーティの類も落としてしまっているのが現状の問題点です。
 

エリア・コミュニティ機能追加

 これはログを見ていて気が付いた需要への対応です。こういうことがあると、作っていてよかったと思いますね。

サーバーの移転

 最初はdotcloudを利用していたのですが、無料枠で独自ドメインを使ったケースを狙い打ちした料金設定をしてきたためさくらのVPSに引っ越しました。この時を機会にGitをデプロイツール兼用として導入。gitoliteをサーバー側に置いてそこにプッシュするという形でデプロイする形にしました。 サーバーの再起動やライブラリの導入にフックスクリプトを使って必要な作業を完全に自動化。ローカルのリボジトリ自体もDropboxで単純バックアップする二重体制になっています。

既読処理の変更

 最初は単純に最後にチェックした日付より前のを読むという単純なものだったのですが、日付順にならんでいないものがあり取りこぼしが発生したため現在は既読リストを保存する方式に変更しました。

対応サービスの拡大

 当初の対応サービスに加えてpeatix、doorkeeperに対応、またQiitaさんのハッカソンをきっかけにgithubのIDによるログインに対応しています。
 特にpeatixはRSSの挙動が特殊で、なぜか編集すると内部的に別エントリーとして保存しかつそれを保存前のエントリーと一緒にRSSに放流する上にID自体は通常の連番で各エントリーごとに違うというなかなかロックな仕様になっていて、短縮URLのみ不変であると気が付くまでが大変でした。それでも公開フラグの変更は編集扱いにならないので、未だに事前に登録して決まった時間に公開するケースは取りこぼしが発生しています。
 

IT系以外への利用への対応

 当初の想定では、利用者は私の周囲2クリックくらいにいる勉強会方面の濃い人を想定していました。ここでいう濃い人というのは例えば数年に亘ってそれなりの数の勉強会に出ていて運営側で参加する方が圧倒的に多いとか、そういうレベルです。もちろん、このレベルの人は自分なりに開催情報の入手ルートは確立しています。それでも取りこぼしがあって足りないのです。
 そういう極めて限られたユーザーを想定することで開発の難易度を下げている面があったのですが、意外にもIT勉強会以外のイベントの情報収集に使っていただけるケースが増えてきていてうまく行かないところが出てきたので、簡単なルールエンジンを導入してフィルタリングしています。

キーワードの誤爆防止対策

 SpringとかPlay、of(Open Framework)、GOのように一般的な単語とかぶる名前、アプリのようにそもそも一般的なケースなど前処理レベルでは対処しきれない誤爆に対してやはりルールエンジンを導入して対応しています。
 これを含めて前述三つのフィルタ系統のルールはログを見ながら大体週に数回くらいの頻度で改善しています。

今後とか雑感とか

 サービスは作っただけではまだスタートで、改良しつづけることが大事とはよく言われますが、実際にやると磨き上げて改善していくのはとても楽しいです。細かいところを含めれば改良すべき点は無数にあり、そこ潰していくのはプチプチに近い快感です。 
 ただ、まだ大きな改修ネタはあることと、Chefのように単純なルールベースでは対処できない物があること、そして何よりも勉強会自体が増えていて*2ハッカソンなどもほぼ毎週おこなわれるようになったことから今後は細かいネタの改良の頻度を下げてもうちょっと大きい改修ネタの方に労力を使いたいと考えています。

*1:バックトラック無しのオートマトン正規表現やファイヤーウォール等のルールエンジンに使われているそうです

*2:二年で3割程度