1  家族や実家との情報共有やコミュニケーションに使っているWeb・ネットサービス

うちの夫婦は元々二人ともPCの前に長時間滞在していることが多いので、PC上で情報共有するようなツールは結構重宝している。 最近になって米国に住みはじめたこともあり、距離を問わないインターネット越しのサービスはありがたい。最近使っているのはこんな感じ。

Google Calendar
互いの飲み会予定や外出予定、訪問者の予定などを共有するのに重宝している。 共同編集可能なカレンダーを作れるのが便利。

1. 自分のカレンダー (私が編集可、妻が閲覧可)
2. 妻のカレンダー (妻が編集可、私が閲覧可)
3. 家のカレンダー (私と妻が閲覧・編集可)

こんな感じで数種のカレンダーを共有している。こうした予定は口頭でもやりとりするが、何日の何時だったかは聞いても結構忘れるので、後から確認できる手段があるのはなにかと楽。それと旅行イベントを入れておくとそれに向けてなんとなく盛り上がったりする。
ちなみに職場はOutlook/Exchangeなのでそちらとは全く別管理にしている。

Zenbe lists
Todoリスト、特に買い物リストを共有したくて色々と探していたが、妻が iPhone を買ったのを契機に使い始めてみる。無料のiPhone専用アプリ Zenbe Lists の方はボタン一つで同期が完了するし、WebインターフェイスはAjaxでそこそこ快適。リストの共有がURLを送りつけるだけなので認証などはちと不安だが、買い物リスト程度ならさほどリスクもあるまい。
惜しむべくはPalmのWebブラウザからまともに使えないことか。専用アプリとまでは言わないが、できればモバイルデバイス用ページを用意してほしいところだ。

ちなみに Zenbe と言うサービスは Todo List 以外にもWebメールやカレンダー、その他Webサービスとの連携機能を提供しているようだ。ちなみにRTMでも良かったんだけど、iPhoneとの連携にProアカウントが必要だったのでやめといた。

Skype
言わずと知れた無料VoIPソフト。出国前に互いの実家PCにマイクとカメラを仕掛けてアカウントの登録まで済ませ、日本にいる間に通話テストまでしてきた。
とは言えPCを立ち上げたり USB カメラを抜き差しする度に「Skype音声入力元」を設定で変更しなければならなかったりと分かりにくい部分があり、さほど積極的に使われている感じではない。それでもこちらから SkypeOut で安価に日本に電話したりするのには十分役立っている。

Youtube, Picasa Web Albums
夫婦間のファイル共有は自宅のLinux/Sambaや mt-daapd なのだが、撮った動画や画像を友達に見せたい時に、ユーザ限定公開しておいて先方で見せるというのにはこのあたりを使っている。 Picasa の方はパスワード付URLで共有できるので相手側にアカウントが必要なく、アクセス制御と言う意味では難があるものの、より手軽ではある。 世間一般に公開するものは Flickr を利用中。

del.icio.us
for:username で相手にbookmarkを送ったりもできるがその機能はあまり使っておらず、基本的には私が一方的に妻のbookmark rssを購読するだけになっている。

Amazon wishlist
時々送りつけられてくる。

IRC
最近はあまり夫婦でPRIVと言うのはしなくなったけど、隣のPCにURLを送るなんて用事には未だに役立ってる。IM代わりといったところ。

1  借りたものは・・・ - Allegro molto vivace. (2007-07-17)

私にはこういう発想が無かったのでちょっと面白い。blog などもそうだが、最近は新しいウェブサービスが出るととりあえずアカウント名確保のために登録だけするというパターンが多いので、ちょっと考えさせられた。ただ、正直そこまで気にしなくてもいいんじゃないかと思う。

フリーで使えるウェブサービス、例えば blog のサービス提供側がなにで儲けているかを考えると、元元持っているサービスへの集客やリテンション目的(例えば OCN 回線に対してのブログ人)と言うケースを除けば、大抵は広告収入だろう。その場合、広告主にアピールできるパラメータはサービス全体での「ページビュー」「サイト滞在時間」と言った通常のパラメータの他に、利用ユーザの「アカウント数」「アクティブユーザ数」などがある。

アカウント数は mixi に例を見るまでもなく、そのサービスが人気だというアピールのための数字として重要だ。広告収入が目的では無いウェブサービスでも、buy out の際などにはどれだけ使われているかと言う数字が重要だし、アカウント数は確実にその一つである。と言うことで、使わないからといってアカウント自体を削除されてしまうのは、確かにリソースの節約という面はあるにしても提供側に取っては痛し痒しだったりする可能性があるんじゃなかろうか。

なお、以上は完全に憶測だけで書いているので念のため。また個人的な好みとしては、検索結果のリンク先が無くなっているのはどんなサイトにせよガッカリ度が高い出来事なので、出来れば消さずにそのまま置いておいて欲しいと思う。

1  「5年前からWeb 2.0を見ていた」--関心空間がサイトリニューアル

関心空間は Web2.0 かどうかはともかく、SNS の先駆者のひとつだったことは確かだと思う(もうひとつの先駆者はゆびとま)。関心のあるキーワードを実際に、関心空間を起点として始まった人間関係も実際に結構あって、今も友達として付合いがあり、非常に有難い場であった。惜しむべくはキーワードを一通り登録し終わってしまったヘビーユーザに新しい視点を提供できなかったことだろうか。

さて、今回めでたく(?) SNS 機能を強化してリニューアルされた。極めて個人的には昔のおもちゃ箱みたいなスタイルも好きだった気もするが、デザイン的にはすっきりした感じになっている。どちらにしても、SNS が皆 mixi 相似のスタイルである必要は無いのだから、あくまで「関心のあるモノ」を中心にした関心空間のスタイルを貫いて頂きたいところだし、それが存在価値なんじゃなかろうかとも思う。

1  Amazon wishlist を ruby-amazon で公開

ruby-amazon を使って AWS の wishlist を公開してみる。どこかで実装を見掛けた気もするけど、過去に まんがめもランキング で使っているし、amazon/search でレスポンスを得るだけなら簡単なので 30分くらいで車輪を再発明。response を得てしまえば response.products からプロダクト情報を引っ張り出すだけ。

require 'amazon/search'

page_max = 1
request = Amazon::Search::Request.new(DEV_TOKEN, ASSOCIATES_ID, LOCALE)
request.cache = Amazon::Search::Cache.new('/tmp/amazon')

products = Array.new
(1..page_max).each do |page|
  begin
    products += request.wishlist_search(WISHLIST_TOKEN, HEAVY, page)
  rescue Amazon::Search::Request::SearchError
  end
end

各定数は適当に自分のものを入れる。wishlist は 1 page に 10 アイテムという構成らしく、全アイテムを取るには page_max を 100 等にすれば良さそう(wishlist の最大値は知らないが)。AWS のドキュメントによれば page=0 で全て取得、と成りそうなところだが、どうもうまく取得できなかった。2 ページ以上取得すると当然 2 回以上 AWS への REST Request が発生して遅くなるのでとりあえず 1 page (10 item) にしておく。

2  Blog に Wishlist を掲載

この Blog に wishlist を載せるようにした。最新アイテム 10 個のうち、ランダムに 3 つが掲載される。一応宣伝と言う意味もあるんだけど、私の Amazon Wishlist は面白そうだと思った書籍等を入れて置く場所として使っているので、用途的には del.icio.us や はてなブックマーク に近い扱い。なので del.icio.us のエントリを公開しているのと同じ感覚で公開と言うポリシーのつもり。プログラムは amazonwishlist.rb に置いときます。

1  Duplicate feeds の統合を Bloglines.com にお願いした

RSS Feed の URL が、例えば http://yoosee.net/d//index.rdf と '//' が重なっていたため、これが '/' の物と別扱いされていた。その他諸々と併せて本来 index.rdf と atom.xml の 2種類しかないはずの Feeds が 8種類も登録されていた。と言うのに昨日気付き、駄目もとで昨日、Bloglines contact にFeed を aggregate して欲しいと言うお願いを出してみた。

2  一晩経って

次の日、ふと自分の Feed を Bloglines で見てみたら subscribers が減っていて、確認してみると Feed は確かに 2 つに減っている。けどこれでは統合と言うより削除ではないのか…。しかし一方で、Blog へのアクセスログ内に User-Agent として表示される数値は統合された後の数字らしく、きちんと増えている。これはどっちが正しいのだろう。spam box に落ちていた bloglines からの返事には「対処したから確認してね」とあったが、その結果の不具合だと思うのでもう一度事情を説明する。
ちなみに一緒に頼んでいた favicons.ico 画像の更新も 1 business day 内にやってくれたらしい。対応速度は素晴らしい。

3  追記 - 更に一晩

ちゃんと subscribers の数字も直った。お願いしたことは完全にやってくれてる。素晴らしい。
ただこれ、私がその Feed owner であると言う確認を特にした感じでもないので、人の Feed に勝手に口出しできちゃう様な気もしないでもない。まぁそんなことをやる意味は無いとは思うけど。

1  はてなへの住所登録の義務化撤回について

結局、全面的に撤回することで落着いたようだ。

はてなの運営っていまいち不明瞭なところがあって、小さい規模の頃ならば近藤さんのバランス感覚とセンスだけで回していけたんだろうけど、これくらい大きくなったんだから外部から見て透明度を増すためにも運営方針を明確化するいい機会になった、と言う意味では住所登録自体は失敗だったけどはてな的には必ずしもマイナスではないと思う。結果的に、はてなにとっても本意だろうし、恐らくはてな自身は元々ユーザのためを思ってアクションを起こしているんだと思うので。

それにしても小倉弁護士の煽り記事 はわざとなのかなぁ... そもそも今回のはてなのやり方では虚偽登録を全く防げないから、個人情報を抱えるリスクだけが増えて小倉弁護士の言う訴訟リスクへの対応にはならないと思うんだけど。

2  個人情報とインターネット

ところで個人情報を集中的に代理運用するような仕事が出てきてもおかしくないような気もするけど、そう言うのはあまりベンチャーとかが出来るような仕事でも無い気がする。心情的に、だけど。かと言って大手がやるとしたら競合関係とか鬱陶しそうだし、コンソーシアムとか合弁企業とか作って、ある程度共通で使える TypeKey のような仕組みを提供出来ないものかね。

1  専有サーバから機能分散へ

友達のところに置かせて貰っていたサーバを引き上げることになった都合上、色々とやり方を画策している。とりあえずは一部を自宅、一部をさくら、DNS は基本的に Domain Registry が Free で Name Server を提供してくれているのでそちらにやらせてしまうのが良さそう。さくらでも引き受けてくれるようなんだが、いまいち融通が効かない。

しかしある程度回線の太い環境に 1 台置いて一元的に DNS から Web, Mail, DB, その他を使うのに比べたら割り振りを考えるのが面倒だな。

2  さくらのレンタルサーバでの mod_rewrite

どうやらさくらのレンタルサーバでは mod_rewrite は使えないらしい。さくらのレンタルサーバ非公式FAQ にもそう明言されている。使えるようにならないのか機能要望のリクエストを投げておく。tdiary のような xxx.html → cgi で動的生成 と言う受け渡しには ErrorDocument 404 を喋らせて、cgi 側で REQUEST_URI 環境変数を拾ってなんとかする方法で対処は出来そうだが、少し鬱陶しい。

1  Apache 1.3.33 に上げた

某所の apache を 1.3.31 → 1.3.33 にアップグレードしたのだが、よくよく CHANGES_1.3 を見てみると、1.3.32 のところに

Fix a bunch of cases where the return code of the regex compiler was not checked properly. This affects mod_usertrack and core. PR 28128.

つまり、以前は正規表現になっていない書き方、例えば *\.html でも大丈夫だったのが、1.3.33 からはちゃんと .*\.html と、* や ? のような「直前の文字 n 回にマッチ」と言った記号には、その「直前の文字」が必要になったと言うこと。正規表現に正しく対応しただけとは言え、こんな利用者に影響が出るような事はせめてリリース分の中にいれて欲しいんだが... 某所では不具合出ちゃったよ。

1  はてなへの住所登録に関するパブリックコメントの募集について

一度全てを撤回してパブリックコメント募集という形にするらしい。紆余曲折したけど、この辺の出し方はまぁ悪くないかなと思う。ただこの 3案って、どう考えても 2 に落着いて終わりと言うか作為的なものを感じるなぁ。特に 2 と 3 の間があってもよさそうなのにそうしていないのは、少なくとも「ある程度の顧客の個人情報は集めておきたい」と言う意図が感じられる気がする。勘繰りすぎかなぁ。とは言え 1 を押し通されるよりは良かったと思うので、そこは評価したい。

2  TSUTAYA online はてな

しかしこのタイミングで TUTAYA との提携 とかの顧客情報が絡みそうな新しいビジネスが出てくるのは正直どうよ。はてなが儲けるのは良いことだと思うし、商売なんだから全てを正直に公開してやれとも思わないけど、やるならあまり勘繰られないようなやり方でやった方がいいんじゃないだろうか。特にはてなみたいに「信用がなくなったらユーザ離れておしまい」になりそうなビジネスの場合。

1  「サーバ」に対する誤った認識

ビジネスでサーバを扱う人間の端くれとして、内容に何の異論もない。それでも個人的には「自宅でサーバ立てるのは楽しいよ」とだけ言っておきたい。自宅にせよなんにせよ、自分で root 持ってインターネットに繋がってるサーバを自由にいじりつつ管理するのは確かに大変だけどその分の楽しみというのもあるから。

ただ、立てるだけだと三日坊主になる(そうして放置されるのがもっとも質が悪い)ので、自分の情報生活インフラなり友達やコミュニティ向けのサービスを自サーバ運用する。サービスダウンが自分や周りにクリティカルな不利益になるので、頑張って運用せざるを得なくなる。運用やトラブルから学ぶ事は非常に多いので、情報処理技術者として勉強したいならばもってこいだと思う。

一方で「サーバを立てる事」をあまり気軽に考えている人には、サーバ運用にはこのレベルの苦労はあるんだよ、と言うことは認識して貰った方がいい。また、メールや DNS のように他者との連携を必要とするサービスは最低限セカンダリを置く。知り合いで持ち合いをしたり、DNS や SMTP だけ、どこかに委託する手もある。その程度の見定めも出来ないうちはあまり手を出さない方がいいというのも正直なところかも。

2  自分の意見のまとめ

サーバを構築・運用する事自体が趣味・実益で、ちゃんと手間・時間・お金などのコストをかけてやれるなら自宅サーバの自由度と経験値向上効果は良いもの。
単に独自ドメインを使いたいとか凝った CGI を動かしたいとか安上がりに済ませたいとか言うのが目的なら、今なら安いホスティングサービスも沢山あるし、そっちの方がトータルの時間や手間や金は安いはず。

特に中小企業などでビジネスユースの場合は片手間にせず、素直にホスティングサービス使ってください。管理に熟練していたとしても、データセンタレベルの設備じゃないと達成できないサービスレベルというのも現実問題としてあります。

3  余談そのいち

もう昔話なんだろうけど、昔はこうやって自宅に OCNエコノミー引いたり大学の回線使ったりして自サーバ建てて運用しながら成長した人も少なくなかったわけで、トラブって迷惑かけて詳しい人がコメントしてくれたりとか、ありがたいもんでしたね。周囲環境が全然違うので「脆弱性即地獄送り」な今では通用しない理屈かも知れないけどね。

4  余談そのに

恒常的にインターネットに直接晒されるサーバを立てるなら、個人的には Debian がお勧め。理由はセキュリティアップデートがある程度早く出るし、かつほぼ自動で更新することができるから。人間、面倒なことは長続きしないもんです。もちろんそうした仕組みがある別の OS / Distribution でもいいですけど、「最初の手間」より「日常の手間」が軽いことを基準に選んだ方がいいです。

5  余談そのさん

このサーバも実は友達の家に置かせて貰い、warm hand が必要なこと以外は全てリモートから自前で管理・運用しているものです。何か新しい技術を見つけたときに、さっと入れて実サービスとして試せる環境は物凄く役に立ってます。一応別所にほぼ同一環境のテストベンチサーバを持っていて、外に出す前にはそこで軽い試験はしたりしてますけどね。
近々その友達の家からサーバを引き上げないといけないことになったので、持って行き先を検討中と言う昨今であります。

1  はてなからの訂正アナウンス

はてなから住所収集に関しての一部訂正とお詫びのメールが届いていた。住所登録期限の一ヶ月延長とプライバシーポリシーの再見直し、と言う形にするらしい。「キャンペーン」などの言葉を使った事への謝罪もあり、ユーザの批判に対する企業の対応アナウンスとしては概ね良好だと思う。しかし、はてなが訴訟時の法的責任を回避するにはユーザの実名・現住所を収集することが必須なのかの説明スタンスには特に変更無し。

これが本当だとしたら、無料掲示板も日記のコメントも書いて貰うときに住所氏名を要求することが必要になりかねないと思うのだが、まぁそんなことはありえない。他の自由に利用できるWebサービスでも住所を求められた事は、物品の発送や課金が絡む場合を除いて殆んど記憶に無い。相談したという弁護士にそう言われて鵜呑みにしたのかしらん。

はてなの規模やトラブル頻度から生じる問題はあるだろうし、実際には法的責任云々よりもトラブル時にお互いの身元を抑えておきたいというはてな側の都合の方が大きいのかも知れない。まぁどっちにしてもユーザにとっては関係無いし微妙だね。
その手のリスクがあったとしても、10万件以上の個人情報なんてサービス上必須でなければ怖くて扱いたくないと思うんだけどなぁ。これが漏洩したらはてなは即死でしょ?

ともあれ私はたいしたサービス使ってないし、住所は入れずにアカウント停止を見守る方針で。

1  高木浩光＠はてな利用規約違反中

はてなにある高木浩光氏の日記が

私はこれまではてなに虚偽の誕生日と郵便番号を登録していました。
心の整理がつくまで、この日記の公開を停止します。

となっていて、何だと思ったらはてなが登録者情報に関する方針を変更したらしい。メールボックスを探してみたら、アカウントを持っている私のところにも「はてな住所登録、正しい情報登録キャンペーン」とか言うメールが来ていた。キャンペーン、とか言う割に義務化なのが微妙だが。

2  はてな登録情報の住所追加、正しい情報登録のお願いについて

住所登録のお願いアナウンスが出ていて、要約すると

• 郵便番号と生年月日の他に、新しく「住所」を登録するように変更
• 住所が登録されていない場合、2005年1月1日以降、アカウントが停止される
• 登録された住所から無作為抽出で150名に葉書を出し、実住所かの確認をする

と言うことになるらしい。個人情報保護関連法案も施行されるし、下手に(推定)16万件もの個人情報を集めると自分の首を締めると思うんだが。アカウント停止を含めて強制登録にする辺り、よほど利用者のトラブルが多かったのか、それともお上に何かごねられたのだろうか。はてなにはその手の前歴があるし。まぁ現実に問題を起こすような人間が今回わざわざ本当の住所を登録することなど無いだろうし、どのみち性別や生年月日は必要がないだろう。これに併せて「はてな利用規約改定について」と言うアナウンスも出ている。

私自身ははてな日記の友達にコメントを付けるため程度にしかはてなを使っていないのだが、逆にその程度のことのために住所まで登録するのはなんとなく嫌な気分なので、さてどうしたものか。

3  はてなダイアリー日記 - はてなへの住所登録の背景について

今回の話の背景として、こんなコメントが日記に出ていた。

違法な日記の作者を特定できないようにしておくことが、ユーザーによる違法行為を教唆・幇助したとして、あるいは違法行為を犯した張本人として、法的責任を追及されるおそれがあることが分かりました。

いわゆる プロバイダ責任法 絡み? 所謂、自由登録のサービスで完全な顧客情報を揃えるのは不可能だと思うんだが、「個人を特定する情報を収集する努力はしてたけど不十分で特定できなかった場合」の責任はどうなるんだっけ。努力していた事実があれば良い? 問題が起きてからログを調べてアクセス元プロバイダに情報開示させるんじゃ駄目なんだろうか。