なまがきの味

これまでGoogle Readerの共有アイテムは、twitterfeedでtwitterにポストしていたんですが、Reader上でメモを入れてもツイートに反映されないので、ちょっとそっけないなぁ、という感じでした。

そこで @hiro45jp がブログで紹介していたReader2Twitterに変更してみました。

設定は簡単で以下の手順であればすぐ登録ができます。

1. Reader2Twitterにアクセスして、OAuthでtwitterと接続
2. 上の画像が出るので「Google Reader Number ID」を登録。
   これは自分のGoogle Readerの共有アイテムの公開ページのURIの一部で、最後のスラッシュに続く連続した数字です。ちなみに私の場合は http://www.google.co.jp/reader/shared/0038XXXXXXX33?hl=ja となっているので（Xは伏せてます）、この文字列の中の「038XXXXXXX33」を Google Reader Number ID にペーストします。
3. bit.lyのIDとAPI keyを入力
4. 好みに応じてツイートのフォーマットをテンプレートから設定
5. 最後のラジオボタンは「Only Sync Share with Note」を選択。
   最初は「Sync All Share」を選択していたが、これだとメモ付きの共有アイテムが2回ツイートされてしまった。

以上で設定は終わり。

みなさんも、Google Readerで知った、ちょっとしたおすすめ情報をtwitterでつぶやいて共有しませんか。

ブログをCORESERVERへ引っ越したらWordPressの管理画面に入れなくなってしまった。ログイン画面は表示されるけどIDとパスワードを入れてサブミットすると「このページにアクセスするための十分なアクセス権がありません」と返ってくる。最初はパーミッションの問題かと思って調べてみたけど、とくにおかしな設定はない。

グーグル先生に問い合わせてみたら、どうも引っ越しに伴いWordPressのテーブルプリフィックスを変更したことが原因だったようだ。

WordPress のテーブルプレフィクスを変更する時の注意点 | バシャログ

テーブルプリフィックスの変更はwp-config.phpを修正して、MySQL内のテーブル名を変更すればOKと思っていたけど、実はテーブル名の情報は「wp_options」テーブルの中の「option_name」カラム、「wp_usermeta」テーブルの中の「meta_key」カラムにも入っていたらしい。そこに旧テーブル名でアクセス権に関する情報が入っていたため、上記エラーが出ていたようだ。

うちの環境では上記以外にもプラグインが作った（と思われる）データが「wp_usermeta」テーブルの「meta_key」カラムに入っていたので、あわせて新しいテーブルプリフィックスに変更しておいた。これでやっとブログが更新できるようになった次第である。

自宅のサーバー、Mac mini 2005が不調。もともとのスペック不足もありリプレイスも考えたが、金もないし世話するのも面倒くさくなり、レンタルサーバーを借りることにした。ドメイン管理はバリュードメインなので、安いしコアサーバーでいいや。ということで引越しの覚書を書いておく。

引越し元の作業

1. 引越し元から引越し先へWPのファイルをアップロード
   必要に応じてwp-config.phpの内容を変更
2. WPのDBをダンプしてコアサーバーへアップロード
   mysqldump –u ユーザー名 –p old_wordpress_db > dump.sql
   データの中に引越し元のURIが絶対パスで書かれている事があるので、テキストエディタで開いて、引越し先のURIになじむ様に置換をしてからアップロードする

引越し先の作業

1. コアサーバーの管理画面でMySQLのDBを作成
2. dump.sqlを新たに作ったDBへインポート
   mysql –u ユーザー名 –p new_wordpress_db < dump.sql

各種設定作業

1. バリュードメインの管理画面でDNSレコードを更新
   DNSに登録してあるIPアドレスを引越し元から引越し先のIPに変更
2. コアサーバーの管理画面で引越し先サーバーにドメイン名を登録
   DNSの更新が反映されないとこれができない。時間が解決するのを待つのみ、私の場合は小1時間。

ちょっとつまずいたのはsshでログインする時、コアサーバーにクライアントを登録しておかないとログインできないこと（これも反映されるまで時間がかかる）。

ログインできても今度はlsやcdすら使えない。Google先生に訊いてみたら、デフォルトは機能制限がついたrbashとか言うshellになっているらしい。そこで.bashrcに以下を書いてルートに置けば、bashが使える。

if test $BASH == “/bin/rbash”
then
/bin/bash
fi

まあ少なくともMac miniよりは快適になった。プロバイダに払っていた固定IPのオプション料金は800円はなくなるし、障害が出ても中の人が対応してくれるし、この機能とレスポンスで200円/月（1年契約の場合）なら全然OKですよ。

プライベートで使っているFlickrのアカウントをプロアカウントにアップグレードした。目的は現在iPhotoで管理している写真のフルバックアップと友人や親との写真の共有である。（ちなみにアップグレードしたのは去年の12月、$1=91.6円換算だった）

iPhotoのライブラリーはTimeMachineでもバックアップを取っているが、物理的に離れた場所でのバックアップも欲しかった。またiPhotoにはFlickrと同期を取る機能がついているので、ワンクリックでFlickrへアップロードできるのも楽チンで良い。

私の場合、iPhotoでは写真を月次でイベントに分割して管理している（2010年01月など）。ただし特別な出来事、例えば旅行や子供の行事など、については独立したイベントを作って月次イベントと並列で管理している。これらをイベント単位でFlickrにアップロードして、iPhotoのイベント=Flickrのセットとなるよう同期することにした。

管理している、と書くと聞こえはいいが単にイベントに分割して適当なタグを付けて、気が向いたらマイレートを付けて後は放置、と言うのが実態である。せっかくの機会なのでFlickrへアップロードする前に、不要な写真の整理とレーティング、タグの見直し程度はやっておきたい。夜な夜な作業をして、やっと2004年まで整理してアップロードしたところだ。

その作業の中で、iPhotoとFlickrの同期について幾つか気付いたので以下メモ書き。

• iPhotoのイベントを同期指定しても、稀にイベント内の写真全てがアップロードされない時がある。その場合はアップロードされなかった写真を選択して、同期アルバムにドロップする。
• Flickr上で写真を削除してもiPhotoのライブラリーには影響が無い。同期アルバム内の写真が空となり、空になったアルバムは削除するかどうか尋ねてくる。
• Flickrのセットは写真を500枚までしか内包できない。501枚以上写真があるiPhotoイベントは分割してからアップロードするのが吉。
  どうもFlickrのAPIの仕様かも。少なくともセットの制限ではない。（Thx, @tsukimiya）
• 同期設定済みのiPhotoイベントに変更が発生すると即座に変更部分の同期が開始されるので、一度Flickrへアップロードしたら意識的に同期する必要はない。
• 但しiPhotoイベント名を変更してもFlickrのセット名は変更されない。
• 複数のiPhotoイベントを同時にアップロードし始めると、アップロードが終わった順にFlickrのセットが配置される。時系列で並べたいときはFlickr上で並べ変える必要がある。

それにしても昔の写真を集中的に見ていると、子どもたちの飛躍的な成長に改めて驚かされる。「本当におおきくなったねぇ」とカミさんとシミジミ見入ってしまい、作業がなかなか進まない。もちろん自分とカミさんのゆっくりとした老化には目をつぶってますが。

本当に写真は1つの財産だなぁと改めて思った次第である。

久しぶりにWordPressのテーマギャラリーをさまよっていたら、シンプルでクリーンなPlainscapeというテーマを発見。全体の幅を調整したり、文字サイズや記事の間隔などをちょこっといじって使わせてもらっている。

ずっとシングルカラムの自作テーマを使っていたので、最近はプラグインとかトンとご無沙汰なので、面白そうなものがあったらインストールしてみよう。