システムはWikipediaと同じMediawikiベース。2008年9月開始でおよそ3年半近く運営。項目数が1200強ページある割に、「議論」(ノート)の活用があまり無いことから、少人数で各個に編集していると推察される。凄いなあ。

と、思いつつ夏用にログホラのデータを収集する昨今であった。

そういえば、今でこそWikipediaのおかげでWikiとの略称があったが、当初は”Wiki-Wiki”から取ったオリジナルにそって、一部ではWikiWikiWebとよんでいた気がする。現在はOEDにも”Wiki”の名前で登録されたようだし、すっかりオリジナルからも離れたし、Wikiで良いのだろう。

公式サイトからは辿れなかったのだけれども、どこかにまとまった表は無いものだろうか。

しかし、Reederとの連携が良いのでInstapaperには戻りたくない。

そこで、Instapaperで記録→DeliciousとReadabilityに反映、と流れを整理した。

Instapaper→Deliciousはタイトルをとりこぼすことが多いのが難点だが、まあReadability連携のほうで普段すればなんとかなる。

なお、事ここに至り、タグは完全に捨ててます。

ifttt.comは次のように設定してある。

1. Instapaper(RSS)が更新されたら、DeliciousReadabilityに登録。これはTweetAtokなどInstapaperしか対応していないクライアントがあるため。
2. Readabilityでfavoriteがついたら、Deliciousに登録。本当は全部放りこみたいのだけれど、現状fav以外に選択肢無し。
3. Deliciousに登録されたら、Evernoteの専用ノートブックに放りこむ。

TwitterのFavもDeliciousに流れるようにしてあるので、これでどこに集めようが基本的にDelicious経由でEvernoteにURLが集まる仕組み。Readabilityがimportもサポートしていてくれるなら、Deliciousの流れを逆にしてReadabilityに集めるところなんだけど。難しい。

なお、Readabilityのfavは、家のMac版のReederで毎日夜にちまちまと処理している。

というわけで、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にするらしい。非常に嫌な挙動だ。