ヤマレコは本日で5周年です！
2005年10月30日から数えて5年。趣味で続けたにしてはそれなりの規模のサイトにまで成長できたと思います。最初は誰もいない状態から、いまは月に20万人近くの方にアクセスいただくサイトに成長しました。使っていただいている皆さんに感謝するとともに、自分の自己満足のためにヤマレコのこれまでと今後について記事を残してみます。
ヤマレコのこれまで
カモレコの誕生
ヤマレコは、山岳会カモの会に所属していた私が、会報を作る編集局に参加したことから始まっています。
当時は、みんなの感想や写真をいちいちメールで問い合わせて集めたあと、Wordのファイルを地道に作って、プリンタで大量印刷したものを手で綴じていく、という人海戦術で会報を作っていました。
当時の編集局のメンバーと話をしていたときに「PDFか何かの形で、会報を自動で作れる仕組みがあるといいんだけど」というザックリとした雑談をしていたときに、じゃあやってみるか、と作ってみたのが始まりです。
カモの会の会員向けページのデザイン（現在）
ヤマレコ開設（2005年10月30日）
カモの会の中でもある程度システムが使われるようになったので、同じような仕組みを外でも作ればいいんじゃ？と勝手に判断して作り始めたのがヤマレコです。カモの会のシステムは自作のperlプログラムだったのですが、利用者の登録とかそのあたりが全然できていなくて、自分でそこから作る知識もなかったので、xoopsというphpベースのCMSのプログラムを使い、ヤマレコ専用のモジュールを作ってシステム化することにしました。
最初のころは、だーれも来ない閑散としたものでしたが、単に趣味としてやっていたので、システムを作ることだけに注力して作り続けようとしていました。
当時、システム更新履歴に「皆さんに使ってもらえるその日まで、地道に頑張ります。」という覚悟を書いたのをよく覚えています。
当初のデザインはこんな感じでした。
ライバル登場（2006年夏ごろ？）
細々とやっていた中で、少しずつ利用者がつき始めていたのですが、某山日記共有サイトが立ち上がったのがこのあたりの時期です。ヤマレコより後にできたサイトだったのですが、広報が上手かったこともあり当時見つけたころにはすでにヤマレコを大きく抜き去っていました。このとき広報活動の重要さを思い知りました。
これが自分の闘争心に火をつけたようで、少なくとも機能では負けないように機能強化を行いつつ、かつお金を払って広告を打ったり、Yahooのカテゴリに登録したり、SEO的なチューニングをするような広報活動も開始しました。
Yahoo! Web APIコンテスト受賞（2007年6月20日）
ヤマレコのシステムとしては一般の人向けではないニッチな機能だし、どうせ分かってもらえないんだろうと思っていたので、受賞できるとは意外でした。まだサイトが残っているようです。
http://api-contest.yahoo.co.jp/
ほか2007年ごろの活動
Yahooさんの地図APIの登場（2006年12月14日）もあって、地図系の機能強化を地道にやっていた時期です。
- yamareco.com取得（2007年1月27日）
- 標高グラフ機能（2007年3月9日）
- クリックによるルート入力（2007年3月31日）
- 山データ（2007年4月5日）
- マイページのグラフ集計（2007年5月9日）
- 日記機能の追加（2007年7月9日）
- 最近の訪問者機能の追加（2007年7月15日）
- 1/25000地形図への対応（2007年8月11日）
- 写真の一括アップロード（2007年9月25日）
- ルートを外部ブログに貼れるブログパーツ（2007年11月10日）
デザインはあまり代わり映えしませんが・・・
2008年ごろの活動
年末年始に時間が取れることもあり、年が変わるところでそれなりに時間がかかる機能を提供しています。ほかの機能は日常的に機能を付け足したりするようなかたちで作っていました。全ルート地図は、利用者ごとに大量のルートを短時間で表示する必要があったため、技術的に苦労した機能の1つです。
ただ、2008年はモチベーションが下がっていたこともあり、数ヶ月間何もしないような時期もありました。
- 地図印刷サイト「地図プリ」開設（2008年1月1日）
- コミュニティ（2008年5月10日）
- スライドショー（2008年6月24日）
- 全ルート地図（2008年10月31日）
デザインも試行錯誤していました。
2009年ごろの活動
2009年は大きな機能として、「山行計画」「ガイド記事」の機能を作りました。みんなにお気に入りの山を紹介してもらう「ガイド記事」はもっと上手く回るかなと思ったのですが、作った後に機能を改善していなかったことや、そもそも記録とガイド記事の使い分けの指針を出せなかったこともあり、あまり使われない機能になってしまいました。
- 山行計画（2009年1月26日）
- ガイド記事（2009年6月14日）
- 携帯サイト（2009年8月11日）
「また山に行きたくなる」というコンセプトをつくり、バナーをtomoeさんに作り直してもらいました。サイトのデザインは最近のタブ型のものに落ち着きました。
2010年の活動
記録・計画・日記の3つの大きな機能ができたところで、次は「行きたい山を探す」機能が抜けていることに気がつき、山を自動的に紹介してくれる山コンシェルの機能を作りました。
歩いた時期、距離や標高差から自動的におすすめの山を選ぶのですが、選び方はもっともっと改善できると思っています。優先度としてなかなか着手できていませんが・・・。
また、みんなでコンテンツを作っていけるWiki的な機能を作って欲しいとの要望が沢山あったのですが、単にWikiを作っても一部の人しか登録してくれないだろうという課題がありました。何とかして普段の活動の流れでWikiのコンテンツを入れてくれる仕組みを作りたいという意図で、記録の標高グラフや地図と連動したWikiとして「地名Wiki」の機能をリリースしました。
今のところ上手くいったので、さらに色々な機能に強化して行きたいです。
Google Earth連携の機能も作るのが比較的簡単な割に、インパクトが大きくて標高差も直感的にわかるので非常に好評でした。
- 山コンシェル＆プレミアムプラン（2010年1月16日）
- GoogleEarth連携（2010年8月10日）
- 地名Wiki（2010年9月6日）
ほかにもブログパーツやブックレビュー、お気に入りや拍手機能にソーシャルニュースやヤマレコグッズなど色々作って企画して成功・失敗してきましたが、キリがないのでこの辺にしておきます。
今後のヤマレコ
これまで掲げてきた「また山に行きたくなる」というコンセプトは継続し、人と人がつながる場としてのサイトにしていきます。
行きたい山を探して、行きたい山の情報を収集し、装備の準備・計画書を作り、実際に山に行って、感動を記録に残す。その記録を見てまた山に行きたくなる、という登山全体のサイクルを自然に回していけるようにサポートしていくのがヤマレコの目的であり、ここは変わることはありません。
現時点では、情報収集・計画書・山の情報を探すところの一部のサポートのみであり、まだまだ改善の余地があります。たとえば、計画書の提出先も一部の警察署のみとなっており、全国の警察と連携したシステムにはできていません。カモの会向けに作っているような、計画書をほかの人にチェックしてもらったり、下山したら「下山したよ」と報告できるような仕組みも必要だと思います。
利用者の裾野を広げることにも目を向けて行きたいです。
現状、「記録を残そう」と思ってくれるのは、主にある程度山を行っている人であり、ヤマレコの利用者も山が始めてという人は少数派のようです。
今後はより裾野を広げて、登山が初めての人でも山に行った感動を残し・共有できることで、2回目・3回目の登山に進んでいって頂ける仕組みを作って行きたいです。
また、初めての登山をする人に対して、熟練者の皆さんの力を借りて情報を提供したり、ガイドや山岳会の紹介をしたり、登山の裾野を広げられる基盤を作って行きたいと思います。
熟練者の方向けにも改善が必要です。逆に山に行き過ぎていて記録を残す気にもならないというのもあると思います。記録の入力を自動化したり、普段の活動のちょっとした延長で記録を残せるようにすることで、記録を残しやすくしながら、一方で記録を残したくなるような仕組みを作っていく必要があると考えています。
また様々な登山スタイルがある中で、クライミングにはクライミング向けの、トレランにはトレラン向けの表示であったりコンテンツの登録ができるように、ある程度の登録や表示のカスタマイズも必要かなと思っています。全てをカバーした仕組みにするのは難しいですが、今後も課題の1つとして取り組んで行きたいです。
趣味でやっていることを理由に、寄り道したり、立ち止まったり少し迷ってしまうこともあると思いますが、上記の考え方を軸にしてがんばっていきますので、今後ともよろしくお願いします！
HDD容量増強の顛末
ちょうど1か月前に、メインサーバのHDDを増強したのですが、その際のメモを残すのを忘れてました。
概要
古いハードディスクにあるOSが入ってるシステムの領域はそのまま残し、ヤマレコが入ってるデータ領域を新しいHDDに移します。
古いHDDはRAID1構成になってましたが、新HDDはもっと増やせるように、RAID5構成にしました。
手順1：旧HDDx1に新HDDx1でRAID構成にしてコピー
新HDDの追加
まず、サーバに新HDD(1TB)x2を刺してしまいます。
起動して、認識されているデバイスを確認します。
# fdisk -l
sdc, sddとして認識されていました。
パーティションを切ります。
# fdisk /dev/sdc # fdisk /dev/sdd
旧HDDと同じ構成にして、type=fd(Linux RAID)で領域を作ります。
今回は、sdc3, sdd3を追加領域として使います。（sdc1,sdc2は未使用）
次に、新HDDをフォーマットします。
# mke2fs -j /dev/sdc3 # mke2fs -j /dev/sdd3
RAIDの組み直し
旧HDDのRAIDは、ソフトウェアRAIDで構成していて、/dev/md2として認識されています。
まず、デバイスを外すために片方のHDDを止めます。
疑似的にFail状態にしないと外せないみたいです。
# mdadm --fail /dev/md2 /dev/sda3 # mdadm --remove /dev/md2 /dev/sda3
そして、新HDD#3をRAIDに追加します。
# mdadm /dev/md2 -a /dev/sdd3
これで、自動的にコピーされます。１日ぐらい待ちました。
コピー中のステータスは
# cat /proc/mdstat
で確認できます。
手順2：新HDDx2でRAID構成に、旧HDDx2もRAID構成に
新HDD(sdd)をRAID1(/dev/md2)から外し、旧HDDx2(sdb,sda)の構成に戻します。
# mdadm --fail /dev/md2 /dev/sdd3 # mdadm --remove /dev/md2 /dev/sdd3 # mdadm /dev/md2 -a /dev/sda3
新HDD#3(sdd)と#4(sdc)で新たにRAID5(/dev/md3)を組みます。
# mdadm --create /dev/md3 level=5 --raid-devices=2 /dev/sdd3 missing # mdadm --detail --scan
ここで表示された、/dev/md3の行をmdadm.confに追加します。
# vi /etc/mdadm.conf ARRAY /dev/md3 level=raid5 num-devices=2 UUID=1044cb0d:e611b637:ba2e68b8:4fbc99cd
追加できたら、新HDD#4をRAIDに追加します。
# mdadm /dev/md3 -a /dev/sdc3
これで、またコピーが終わるまで、1日ぐらい待ちます。
手順3：新HDDの容量を増やす
新HDD側のRAID容量は、RAID1(/dev/md2)を引き継いでいるので、500GBのままになっています。
コマンドを打って、RAIDの容量をHDDの最大容量(1TB)まで増やします。
# mdadm /dev/md3 --grow --size=max
ファイルシステムとして、拡張したものを認識させます。
(# e2fsck -f /dev/md3) ※このコマンドが必要なことがあるらしいですが、今回はやってません。 # resize2fs /dev/md3
最後に、不要になったファイルを消して完了です。
HDD利用率94%が、41%まで減少しました。
作業後のステータス
# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] [raid0]
md3 : active raid5 sdc3[1] sdd3[0]
974559040 blocks level 5, 64k chunk, algorithm 2 [2/2] [UU]
md2 : active raid1 sdb3[0] sda3[1]
486183040 blocks [2/2] [UU]
unused devices: <none>
おまけ
作業途中、RAID構成を切り替えた瞬間に電源が落ちて、反応がなくなりました。その後、電源を入れ直しても反応しない／少しするとまた落ちるの繰り返しになったので、電源を交換しました。
すると、電源は入ったのですが、grubプロンプトになって起動しません。
grub >
仕方がないので、起動用のコマンドを手打ち
> root (hd0,2) > cat /boot/grub/grub.conf
この内容に従ってコマンドを打ってみると、起動しました！！
起動後、GRUBを入れ直します。
# grub-install end_request: I/O error, dev fd0. sector 0
と出るので、/boot/grub/device.map 内の
(fd0) /dev/fd0
を削除して
# grub-install --no-floppy /dev/md2
でインストール。
起動するようになったが、途中でswaponでFAILEDが出るようになってしまいました。起動後に/dev/md1(swap領域)のRAIDを再構築したらFAILEDがなくなって問題解決。
電源のON/OFFが何度もあったので、負荷がかかってたんでしょうか。突然落ちた時にはかなり焦りました。
ご意見箱の設置
Cookpadというサイトでは、ユーザからの意見をいつでも簡単に入力できるために、ご意見を送るフォームをサイトの右側に準備しているという話を前に聞いていました。ヤマレコでも、簡単にご意見を伺うような機能が必要だろうと思い、同じような機能を準備しました。
Xoopsのブロックからのメール送信
同じ機能をXoopsで実現するには、Xoopsのブロックの中にご意見箱用のFormを用意する必要があります。しかし、Xoops Cube Legacy対応の問い合わせモジュールを２つほど使ってみましたが、どれもブロック化してフォームを送ることができません。
仕方がないので、ページとして表示されるときのソースコードを読みながら、ページ表示時のFormと同じ内容でカスタムブロック内のFormが作れるように書き直しました。
ほか
明日から仕事だ・・・。今日は疲れたので、明日に備えて早めに寝ます。
ユーザに対して「自分の行きたそうな記録」を見せたい（３）
今日はユーザーインタフェースの部分と、高速化のためのデータベースの見直しをしてました。
機能の名前
昨日も書きましたが、ユーザーにお勧めの記録を選ぶ機能なので「コンシェルジュ検索」という機能の名前にしようと思います。
絞り込み機能
絞り込みの機能を追加してみました。
- ジャンル
- エリア
- 季節（何月から何月まで）
- レコ君が選ぶユーザーの記録と、その関連する記録を選択した時期から選びます。
- 季節を選ばない場合は、今の日付の前後1ヶ月にしました。
まだ性能面でオーバーヘッドが多いので、もう少し手をいれます。
ユーザに対して「自分の行きたそうな記録」を見せたい（２）
前回、ユーザが自分の行きたいと思う記録が分かるように、標高差と距離の２次元のブロックを作って記録を提示する機能を考えました。今日も引き続き検討してました。
理想形はボタンを押すだけ
そもそも使う人の立場からすると、自分がどんな記録を探したいのかを考えことすら面倒です。例えば「お勧めの記録を表示」みたいなボタンを１発押すだけで、自分が行きたいと思う山や記録を見せてくれるのがベストでしょう。記録を検索するためにキーボードを打つのも面倒だし、クリックもしたくない。そもそも知らない山を見つける場合、キーワードも思いつかないので打つことすらできないわけだし。
ということで、ボタンを押すだけで行きたい山を探して表示することを目標にします。
記録の分類軸を２次元から３次元に
前回の日記では、歩いた距離と高度差の２次元で記録を分類しようとしてみました。しかし標高差を使って判断しているところが問題で、0mから登って500mに行くハイキングの記録と、2000mから2500mに行くピークハントの記録が同じブロックに配置されていました。
そこで、もう１軸「最高点の標高」という軸を追加しました。これで、標高が高い場所を歩く場合と、低い場所を歩く場合の２種類の記録が、違うブロックに分類できるはずです。
ベースにする記録の選び方
ボタン１発で自分の行きたい記録を探すには、過去にヤマレコに登録した自分の記録をベースに探すことになると思います。まずは過去２年ぐらいの間で、自分が実際に行った記録をPickupして、その記録に傾向が近い記録を提示することにしました。あまり記録が古いと、その記録の後にユーザーの山の趣向が変わっていたり、スキルアップしていたりして参考にならなくなるはずですし。
また、「来週」とか「今週末」に行く山を決めるために記録を探すシーンを想定すると、直近の季節の記録しか探したくないはずです。例えば今の時期だったら、１２月〜２月ぐらいの記録から適切な記録を提示してもらいたいと考えるかなと。
上記２点より、
- 過去２年のうちに行った
- 現在の前後１ヶ月の範囲の季節で
- 自分の行った山の記録
の中から、ベースにする記録をランダムに選ぶことにしました。
上記の条件に当てはまる記録が存在しない場合はどうすればいいのか？は後日考えます。なんか色々やり方がある気がしますし。例えば、お気に入りに登録した記録とか、別の時期の山から推測とか、ハイキング固定で探してしまうとか、友人の記録とか。
関係しない山行記録の除外方法（フィルタのかけ方）
内容が近い記録を全て一覧にしてもいいのですが、ベースにする記録と同じ山の記録は表示しなくてもいい場合も多いかなぁと思います。例えば、高尾山の記録をベースにしてしまうと、他も高尾山の記録ばかりになってしまいます。これでは新しい山を探せないので、検索機能の魅力が半減してしまいます。そこで、今回は「ベースにした記録」が関連付けられている山と同じ山に関連付けられている記録は、検索結果の一覧から除外するようにフィルタをかけることにしました。
また「ベースにした記録」と同じ季節の記録を選び、違う季節の記録は除外することにしました。
これ以外にも、オプションとして一覧表示させる記録から「ジャンル」や「エリア」に対してフィルタをかけて（絞り込んで）、意図と異なる記録を見なくてもいいようにします。
一覧表示の件数
あとからフィルタ定義や絞り込み機能を追加することも考えられますし、そもそも一覧表示できる件数にはばらつきが必ず発生します。このばらつきを吸収できるように、まずは10件〜100件ぐらいの間でページを分割せずに一覧表示できるようにしてみます。
隣接ブロックの見つけ方
１ページの最大表示件数は３０〜５０件程度として考えたとき、１ブロック内には最大でも100件程度の記録しかなく、この中でさらにエリアやジャンルを絞り込んでいくと、１つのブロック内の記録だけでは足りなくなってきます。このような場合には、隣接するブロックにも範囲を広げて検索する機能が必要です。
例えば、
- ベースとする記録を決める
- ベースとする記録が所属するブロックを特定する
- ブロック内の記録を表示
- 該当ブロックの周囲にあるブロック群を取得する
（⇒ １つ前の手順に戻る）
というような手順を踏みます。
隣接ブロック群はリスト管理して、同じブロック内の記録を何度も表示しないように注意します。
ほか、どんな拡張を考えるか
- 記録だけじゃなくて山もお勧めを提示して欲しい。
- 記録を登録していないときにも、適切な記録を提示できるようにしてほしい。
- そのためには、ユーザの好みが分かるようなデータの収集手段が必要になる。例えば、お気に入りの登録記録とか、過去に見た記録とか。
ユーザに対して「自分の行きたそうな記録」を見せたい（１）
今のヤマレコは検索の機能が貧弱で、キーワードの検索やデータベースの各項目の検索しかできません。今後の機能追加として、自分に合った記録を適切に提示してくれるような機能が欲しいと思って色々検討してます。
結果的にシステムから見ると、記録の検索機能になるので
- 検索するときに何をInputするか
- どの記録をどういう順番に並べて表示するか
の２点を考える必要があります。
検索するときに何をInputするか
ユーザがラクをするには、明示的に示さないような仕組みが要ります。例えば、過去の記録の傾向とか、プロフィールとか。
でも、過去の記録のうち、どの記録を中心にするのか、とか、ユーザがプロフィールを正確に入れてくれていない場合もある、とか、ラクをする代わりに精度が下がってしまう問題があります。
そこで、少し面倒になりますが、探したい記録に関する情報を少しはユーザ側が提示する前提で考えます。まずは、自分の行った記録を選んで、この記録に近い記録を探す、みたいな機能ができればいいかなぁと。
どの記録をどういう順番に並べて表示するか
ある記録に近い記録（この記録を書いたなら、この記録は近いはず、みたいな）を提示するには、記録と記録の関係を調べて、１次元のリストに並べる必要があります。
その一方で、パラメータは
- 季節
- 日数
- ジャンル
- 歩いた時間（コースタイム）
- 歩いた距離
- 高度差
- 最高点の標高
- エリア
- パーティのメンバー数
- 利用した装備
などなど、挙げだしたらキリがないです。どこから検索されるかもわからない状態で、何次元もあるパラメータの中から何をどう優先的に表示させるのか、まともに考えるとできそうな気がしません。
仕方がないので、まずはパラメータを絞り込んで２次元で作って、どのぐらい精度が高いのかを見てみることにしました。今回は
- 歩いた距離
- 高度差
の２次元のグラフ上で記録を整理して、記録間の近さを座標上の距離で判断しようと考えました。
課題１：高度差の取り方
高度差と言っても、高度差の取り方にもいろいろあります。最高点と最低点の高度差を取ると、縦走している場合とピークハントの差がでないのである程度デコボコしていることも分かるように高度差を取ります。
細かく取ろうとして、GPSログの各座標ごとに登りと下りの加算をしていく方法を採用すると、細かい登りと下りも加算されてしまい、GPSログの採取ポイント数が多いと高度差が大きくて、採取ポイント数が少ないと高度差が小さいという結果になってしまいます。
そこで、上記の２つの間を取るようにしました。例えば高度差が１００ｍ以上着いたときだけ、加算するようにするとGPSのポイント数にも左右されにくく、ある程度デコボコしていることも表現できるはずです。
また、登りと下りの片方が長い場合は、標高差が大きい方を取ることにしました。
課題２：近い記録を見つけるときの性能
各記録を距離と高度差の２次元座標軸にちりばめた時、例えばある記録A（もしくは、座標上のある特定の点）から近い記録を正確に探そうとすると、その記録A以外の数万もの記録について、記録Aとの距離を計算して、近いものを表示することになります。
しかし、検索をするときはブラウザのボタンをクリックしてから表示するまでのせいぜい数秒、実際はネットワークの遅延やブラウザの処理時間もあるので数100ms程度の時間で終わらせないと、体感速度としてやってられません。
まともに数万件の記録間の距離を毎回計算していると、どう考えても表示までには間に合いません。夜間のバッチ処理等で毎回記録間の距離を計算してもいいのですが、記録数が多くなってくるとバッチ処理の負荷も馬鹿になりません。
今回はその対策として、２次元の空間をある程度ブロック分けして、検索するときは、そのブロックの中にある記録を並べるようなやりかたにしようと思います。
課題３：ブロックの切り方
では、ブロック分けをするとして、どうブロック分けをすればいいのでしょうか。縦軸に標高差、横軸に歩いた距離を取ったとき、標高差が低く距離が短い場所に記録が偏って、泊数が多くなるような距離が長いものは記録が少ないような分布になるはずです。
ブロックを住所のような感じで、あらかじめ縦と横の座標を区切ってしまうと記録の数が増えてくると偏ってる領域のブロック内の記録数が多くなってしまって関連性の高い記録を表示するというもともとの目的が達成できなくなってしまいます。
そこで、例えば、１つのブロックには記録が２００件しか入らないように、今回は動的にブロックを分けるようなやり方を採用しました。最初は１つの大きなブロックだけ定義しておいて、ブロック内の記録が２００件を超えたら、ブロックを縦横４分割してブロック内に記録を追加して、２００件を超えたブロックをまた４分割するようなやり方にしました。
検索をどうやるか
２次元空間上のあるブロック分けした中は、ランダムなり何なりで記録を並べて、ブロック内ではいい記録が見当たらなかったときは、その隣のブロックを探していくような並べ方が必要なんですが、どの隣を次に表示するのかが難しいです。ここは検討中。
試作で確認
どの程度正確に表示されるのか、まずは試作で確認してみました。
- 今のヤマレコの記録を２次元空間にならべて、どういう分布になっているのか
- ブロック分けをしてみて、同じブロックに入っている記録が近い記録になっているのか
とりあえず２点確認してみました。
確認１：今のヤマレコの記録分布
縦軸に標高差(0〜4000m）、横軸に距離(0〜40km）のグラフを作ってみました。
予想通り、標高と距離が短い記録に偏ってました。
確認２：同一ブロックが近い記録になっているか
結論としては、ダメでした。特に標高差を使って判断しているところが、0mから登って500mに行くハイキングの記録と、2000mから2500mに行くピークハントの記録が同じブロックに配置されていました。
今日の結論
やはり２次元では精度に限界があるので、もう少しパラメータを増やして多次元にしていこうと思います。あまり増やしすぎるとブロック分けが難しくなっていくので、何のパラメータで多次元にするのか、色々検討してみます。
おまけ
考えたことややったことの記録をブログに残すのは重要なんですが、誰向けに残してるのかよくわからない内容になってしまいました。後から自分が見るかというと見ないし、他の人も見てないだろうしなぁ。まぁ、自分の頭の整理に時間を割いたと思えばいいのかな・・・。
MA5向けの応募作品
去年Mashup Awards 4で、Cycle-Ringが
Yahoo賞とゴーガ賞をダブル受賞したことをいいことに、
今年もこっそり作ってみました。
PlusTrack
いろんなWebサービスのコンテンツにトラックログを関連付けて
地図上でライフログを確認できるようにするサービスです。
詳しくは
PlusTrackの紹介ページ↓をご覧ください。
本当は、いろんなWebサービスをマッシュアップしたかったんだけど
時間の都合上、現時点ではTwitterとフォト蔵だけ対応してます。
今後、どんどん対応サービスを追加していきます！
相変わらずニッチな感じで、爆発的には人気は出ないだろうけど、
コツコツ作っていきます。
将来的には、iPhoneとかAndroid端末があれば
写真もメモもGPSも、ログを同時に取れる気がするんだけどなー。
