というわけで、b-mobile U300の期限がきたので、購入しておいたb-mobile Fairに変更。SIMを差し替えて開通の電話をかけて、設定のアカウント部分を変更するだけと楽なもの。

速度は流石の快適さ。後は、どれ位持つか。4ヶ月上限とはいわないけど、2ヶ月くらいもってくれれば上々。

基本は「〜」したら「〜」する、といった「タスク」。

「Deliciousでブックマーク」したら「Evernoteに投稿」する、「Instagramで写真を投稿」したら「Wordpress.comで投稿を作成し公開」するなどといったことが可能。

下手な連携ツールやRSS経由でするよりも細かな調整がきくので有り難い。認証もOpenIDやAPI経由で使えるものは、できるだけそっちで認証してくれているようだ。

といいつつ、Evernoteが不整合になって、バックアップとってなおしていたら容量オーバーしたので、しばらく利用停止。

まず入力口としては4つ。デスクトップからはブラウザ拡張とInstapaper。iPod touchからはFastEverとReeder。ブラウザ拡張は適当に見ているページを放りこむ用で、Instapaperはメモしておいて後から☆をつけることで、選別をかけている。FastEverはその場でのメモ入力用で、ReederはRSSを読んでいて何かあればメモ、程度の連携。

FastEver
カテゴリ: 仕事効率化
価格: ￥170

Reeder
カテゴリ: ニュース
価格: ￥250

入力は全部Inboxにあつめて、デスクトップで定期的に整理。

まだ出力が甘いけれども、ひとまずはこんなところで。

課題としては、ソーシャルブックマーク系が丸々外れてしまっているので何とかしたいところ。Deliciousとの連携はなんだか面倒そうなので、どうしたものか。

まずは、パッケージをバイナリでインストール。久しぶりなのでports以外でパッケージをいれるためにはどうすればいいか、Handbookを探してしまった。

# pkg_add -r lighttpd
# pkg_add -r php5

/usr/local/etc/lightttpd を編集。

modules.confでfastcgiを有効に。ついでに、ロードバランサとしてpound経由にしたので、extforwardモジュールを使いロードバランサを指定してログに元のIPアドレスが出るようにしておく。

##
## FastCGI (mod_fastcgi)
##
include "conf.d/fastcgi.conf"
include "conf.d/extforward.conf"

server.modules += ( "mod_extforward" )
extforward.forwarder = (
    "192.168.xxx.xxx" => "trust"
)

fastcgi.server = ( ".php" =>
                   ( "php-local" =>
                     (
                       "socket" => socket_dir + "/php-fastcgi-1.socket",
                       "bin-path" => "/usr/local/bin/php-cgi",
                       "broken-scriptfilename" => "enable",
                        "min-procs" => 2,
                        "max-procs" => 5,
                        "bin-environment" => (
                                "PHP_FCGI_CHILDREN"     => "1",
                                "PHP_FCGI_MAX_REQUESTS" => "5",
                        )
                     )
                   )
)

lighttpdの起動でエラーが出たので、IPv6を無効化。

# service lighttpd start
Starting lighttpd.
2011-11-27 10:19:00: (network.c.203) socket failed: Protocol not supported
/usr/local/etc/rc.d/lighttpd: WARNING: failed to start lighttpd

server.use-ipv6 = "disable"

favicon.icoが表示できないので、conf.d/mime.confに指定を追加

  ".ico"          =>      "image/x-icon",

コンテンツは以前実験したPukiwikiをコピーして、無事稼動。

3年間ほど確保したけど、具体的にはどう使ってやるかな。

久しぶりにGANDIにアクセスしたので、個人情報の更新やwhois情報の修正もすませておく。

そこで、まずは母艦と直接同期させようとしてMac側のiCloudを切ると、ローカルのiCalデータが全部消えた。マスターそっちなのか…orz

仕方が無いので再度iCloudと同期して、iCalの「書き出し」でバックアップ。

iPod touch側のiCloudを切ると、データを残すかどうかの選択肢が出た。残してみたら、Mac側のと重複して、全部データがダブった。

解消方法。全部Mac側のカレンダーを削除して、iPhoneも消して同期。それから再度バックアップからMacに登録しなおして同期。ふう。

どうしても重複した場合は、一応iCal Dupe Deleterというツールや、AppleScriptでの対処もあるらしい。

最初にまっ白いカレンダーを見た時は、嫌な汗が出てしまった。

正式にやりたい時は、(多分)次のようにしましょう。

1. iCloudと同期したまま、iCalでデータをバックアップする。丸ごとだと設定もろとも残るので、個別カレンダーごとに保存。
2. MacとiCloudとの同期を外す。
3. iPod touchとiCloudとの同期を外す。データは削除。
4. バックアップからMacに再登録。
5. iPod touchを同期して反映。

何故かiCalはバックアップから復活するごとにiCloudをONにするらしい。非常に嫌な挙動だ。

1. ブラウザプラグインの出来が悪い

はっきりいってこれがほとんど全て。どう出来が悪いのかを見ていくと

1-1. Firefoxでは登録後に小ウィンドウが消えない。一々C-wで消す必要があり面倒。

1-2. タグの補完が無い。出るとしても妙な候補しかでなくなった。

1-3. 推奨タグがほとんど出ない。他人のタグもわからない

1-4. スペース入りのタグがつけられるようになって、「,」で区切ればマルチタグになるよう変更されたが、日本語に非対応。一々フォーカスを外して確定を待つか、スペース二つ挟んで選択画面から”Separate”を選ばないと1つのタグにされてしまう

1-5. タグの確定が遅い。待ってから登録しないとタグ無しとされてしまう。大分ハマりました。

1-7. 登録キャンセルしようとしても登録されていることがある。タグの通信が原因? よって無駄な登録が増える。

1-8. ブラウザプラグインのボタンで自分のhomeにとぶと、ブックマークの一覧ではなく全体のスタック一覧に飛ばされるようになった。一々メニューを出してリンクを辿らねばならず面倒。

かと言って今更他を試すのも面倒なわけで(Diigoはあまり良くなかった)。はてさてどうするか。

自作サーバの自主運用で有名だったはてなが、さくらのクラウドでの業務委託に切り替えたとの事。安価に入手できる、用途にあわせつつ適応で組める、といった自作のメリットがクラウドで享受できるようになってきたからなのだろう。サーバ機器のおもりをするにしても、昨今は節電もあれば人件費も相対的に高くなるし、結局のところ運用費用がかかるということだ。

個人ではどうかと言うと、私は以下の点をクリアできれば自宅サーバをクラウドに移しても良いと考えている。なお、価格優位性とか保守体制とか会社の信頼度とか安定度とか、あたりまえの話は省略。

まずは可用性ということで「データが引き揚げられること」。データをベンダロックインされるのではなく、適当な単位で手元にバックアップしておきたい。Amazonなど世界各国で分散すれば1箇所落ちても大丈夫、などというのもあるが、古い人間なのでデータは手元に届くようにしておきたいし、手元が壊れてもリモートがあるという状態にしておきたい。

つぎにいささか職業病的だが「機密性が約款で担保されていること」。元々通信事業者には縛りがかかっているが、クラウドサービスの場合どこまで適用されるのかがいまいちわかりにくい。そのため、オペレータが中身を覗けません、安いからといってマーケティングに利用されません、という保証が欲しい。その分、いざとなったら約款の壁でデータが取りだせませんよとなってもＯＫ。そのための可用性条項だ。

最後に、できれば身元確認を取るサービスであること。クラウドによるサービスの利点は支払いさえあればすぐに取れるような利便性にあることは承知しているが、住所を同定する必要があるISPサービスとの連携、あるいはクレジットカードでも良いので身元や信用の確認を行った上で利用可能なサービスである方が、Pinboardのように◯◯な方々避けとしては望ましい。

実際に移すとしたら、まずはウェブとDNSまわりで様子見して、最後にやっとメールサーバという事になるだろう。IPv6が自宅までなかなかきちんと届かないので、クラウドで試せるならば色々やってはみたい。Vyatta等も気になる。

そして、ここまで書いてやっと気がついたが、どっちみち家庭内でファイルサーバとか動かすと大して消費電力がかわないのではないだろうか。せいぜいISPを移動しやすくなる程度? …まあ気にしない気にしない。

IPv4が枯渇した今、IPv4を極力延命しつつも嫌でも徐々にIPv6を使わなければならない時期にきている…はずである。というのも一般のレベルでは当然そうあってしかるべきだが、枯渇も延命も移行も実感が無いからだ。

通信網の対応状況としては、通信におけるラスト1マイルの問題のように、ISPと家庭内機器(CPE)の対応がまだまだ取れていない。NTT-NGNでは徐々に対応していくのだろうけれど、フレッツ・ネクスト(NGN利用)のみでフレッツISDN/フレッツ光はまた別。ソフトバンクは6rd方式を推進している一方で、事前に大量のIPv4を確保し、最近はiPhoneにもプライベートIPを割り振り、やりくりしようとしている様子が噂レベルで聴こえてくる。ISPによる差こそあれ、一応進んでいると見ていいだろう。

目を機材やソフトウェアに向けると、おおよそ対応していることに「なっている」が、もちろん旧来の機器では対応していないものも多いし、「IPv6対応は上位グレードだけ」という機器がある時期もあった。小規模のソフトウェアでは、よほど意図していない限りIPv4に依存しているものも多いだろう。だが、このあたりは徐々に必要であれば改善されていくと考えている。

一方、専門家の間でもまだIPv6について実用にならないという勢力があり、そういうのを見ているとUnicodeの状況を思い出す。かつては実装の品質差も激しかったし、規格自体も色々と言われていた(そして今も言われている)。けれども、最終的には規格は不具合を補われ、ソフトウェアはOSが担保して標準的な手法を使えばそれなりに対応するようになり、ユーザがそれほど不自由無い形で使えている。L10N(地域化)ではなく、I18N(国際化)が主となった。

きっと、IPv6もそうやって、実用してはじめてわかる不便なところを修正しつつ、進んでいくのだろう。技術者として、せめてその様子の概観くらいは目を向け続けておきたいものだ。

余談に注目。昔から空き領域を半ば実用的な意味を込めて、0xdeadbeef等の意味があるっぽく読める文字列で埋められるような事はあった。

IPv6でもそれは同じで、16進数が数ケタあれば十分綴れる。ましてそれが組織名の略称ならば。

というわけで、A10 NetworkがA10::A10とか、ciscoがC15C0:D06:F00Dとか、FaceBookがFACE:B00Cとかしはじめるわけですね。今は違うのもあるようですが。

IとかOが苦しいですが、1と0でまあ良いのかと。Gを6と読ませるよりは余程自然です。