グラフを手軽に共有できるツールを作ってみました

 
Graphiddleという、Web上のリソースをベースにD3.js + jQueryなグラフを手軽に共有できるサービスを作ってみました。

これは何?

 オープンデータやクラウド型のオフィスソフトのデータを手軽にグラフ化して共有すること、そしてグラフを手軽に使いまわすこと、その二つを目標としたWEBアプリです

 例えばオープンデータプラットフォームで公開されている福井県鯖江市の男女年齢別の人口統計をベースに五才ごとにまとめたグラフ
がこんな感じです。元になったデータはここに公開されていますが、このサイトには他にも同様のデータが公開されているのでフォーク用のページでURLを切り替えれば別の町で同じようなことができます。
 データ自体も男女別で2014年から2010年の分まであるので、コードをいじれば動的に切り替えたり人口ピラミッドを作ったりと色々なことができるわけです。
 
 

コードの書き方

 変数としてグラフを描画するsvgを表すd3.jsのオブジェクトである「svg」、dom要素としてのsvgを操作するためのjQueryオブジェクトである「$svg」、web上のリソースをパースした結果である「data」の三つの変数が設定されているので、それを元にゴリゴリと書いていけばグラフの完成です。
 なお現在のところ、一度保存したらグラフの編集はできません。フォークのみです。ログイン系めんどいのです…

ToDO

 まずはソースコードの公開を目標としています。それとログイン回りの実装。デザイン面も手を抜きすぎですのでなんとかしたいです

 

一人で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割程度

ワラワラフォトの種明かし

 Baidu.jp不自然言語処理コンテストの表彰式が終わったので、ワラワラフォトの種明かしをします。
 実はワラワラフォトでやっているのは、「w」と「twitpic」をTwitterの日本語検索に投げているだけなのです。

言葉にならない気持ちを言葉にする

 Baiduの言う不自然言語を自分が使うシチュエーションはどういう時か? というところから考えて見ますと、単純に言葉だけではつたわらない空気や感覚、ニュアンスといったものをテキストベースであるウェブ上で伝えようとする時です。つまり不自然言語は言語にできないものの言語化なので、うまく使えば言葉にできないものをインデックス化し、検索できる、ということです。
 例えば、よく使われる不自然言語と適当な対象を絞り込むキーワードを組み合わせ日本語検索になげれば感情があふれている「何か」を検索できます。

顔文字を試して見る

 そこで、最初は顔文字に注目しました。顔文字というのはパターン化しやすくて大部分は「(^^)」というように「()」ではさまれたパーツがあります。しかも感情表記としてはある程度パターン化されていますので、単純に顔文字で分類すればそれだけで感情に基づいた分類になります
 ならば「( )」あたりで検索するとおもしろい結果が出てくるかなー? と思ったのですが、簡単に試したところで「出てこない」どころかForbiddonだったので断念しました。
 ちみなに、後で調べたところGoogle Buzzでは顔文字を検索クエリとするとエラー再試行の無限ループに突入します(^^;)

じゃあ草を生やそう

 次に試したのが「草をはやす」という習慣です。「これはひどいw」という感じで、ネタがあれば「w」をつける習慣は広くあるわけです。これと組み合わせれば…と思ったところ、見事に成功しました。

 つまり、日本語検索に限れば、wと何か適当な対象を絞るだけで簡単にネタっぽいものが手に入るわけです。
 今回はとりあえず簡単にtwipicだけでやりましたが、色々と応用が効きそうなので、もうちょっと本格的にサービス化してみてもいいかも? とか考えていますw
 

 
 

ぼんやり見ているだけで旬なネタ画像が降ってくる…かも?

 ワラワラフォト、というサービスを公開しました。
 ただぼんやりと見ているだけで、旬でステキなネタ画像やかわいいぬこが降ってくる…かもしれません。


 
 また、画像をネタにつぶやいて友人と楽しい時間を共有することもできます。
  虫眼鏡のアイコンやサムネイル画像をクリックしてみてください

 暑い中のひと時の癒しに、また気分転換、ストレス解消などにどうぞご利用ください。

これはなに?

 Baidu.jp不自然言語処理コンテストの応募作品です。内容は表彰式まで秘密ですが、とある方法でTwitterに流れているネタ画像を収集しています。

 もちろん、JavaScriptだけで作りました。

 単にタイル状なりスクロールするリストで展開してもつまらないので、元々ソーシャルストリーム用に考えていたUIと組み合わせました。
 現状はまだ簡単なものですが、画像に付随する呟きの内容を分析して似たようなことを呟かれている画像は近くに固まるようになっていて、だいたいの話題の傾向が見えるようになっています。
 本来は一時間に数千件の単位で流れてくるものを見やすくするためのUIなので、ややオーバースペックなのですが、そこそこの効果は出ているようです

 

災害ネットの応用

 インターフェースとしての災害ネットは応用が可能です。
 位置表現を含む情報さえあれば、災害に限らず多様な分野で文字通りのマッピングができます。また、整理されていない情報であればあるほど効果的です。
 問題は、そういう情報が流れているところが少ないことなのですが。

開発のきっかけ

 元々は、大崎で行われたマッシュアップキャラバンの帰りに落雷によって電車が止まり、大回りする羽目になったのがきっかけです。
 
「こういう時、携帯から位置情報つきで書き込める掲示板があったら便利じゃない」。

 実際には携帯ウェブサイトの作成が難しいとか、PythonXMLパーサーが使いにくくて予定していたGoogleAPPEngineの使用を断念したりと紆余曲折があってこういう形になってしまいましたが、なるべく早くに何とかしたいです。

災害ネットの仕組み

 こんな仕組みになっています。

  1. Yahooトピックスからはキーワードで、Livedoor天気情報からはRSSで提供される情報を収集
  2. タイトルを一つの文字列にする
  3. LocoSticker 位置表現特定APIで解析。
  4. タイトルの位置表現を元に、位置表現単位で分類
  5. ページのヘッダに「生」のスクリプトとして書き込む(汗)
  6. そうでないものは普通にリスト表記

 単純なのですが、位置情報単位で分配しているので視覚的にはかなり見やすくなっていると思います。