最終的にどうしたかというと、こちらのリポジトリを利用させていただきました。 にわかSEの独り言 CentOS 5.8 x64でmroongaを設定 レポジトリはこちらの「wing」を。 にわかSEの独り言 RHEL6互換OS用 wingリポジトリ を公開 それで、「mysql55-mroonga」をインストールすればOK。 一緒にMySQL5.5（wingレポジトリに含まれる）もインストールされます。 わーい。
Tumblr Queueの最新ページへのリンクを生成するGreasemonkeyを更新しました。
ただのメモです。
It is called before the Application’s launch function is executed so gives a hook point to run any code before your Viewport is created.Viewportがインスタンス化する前に呼ばれます。
A template method like init, but called after the viewport is created. This is called after the launch method of Application is executed.Viewportがインスタンス化された後に呼ばれます。
Optional callback to execute after the class is created, the execution scope of which (this) will be the newly created class itself.Ext.defineの第3引数。そのクラスが生成されたあとに実行されるコールバック関数。「created」ってのはインスタンス化ではなくてファイルが読み込まれたとき…と言うような気がする（後述の実行順参照）
RapidSSL社のSSL証明書を更新した作業のまとめメモ。 SSL証明書 RapidSSL 2600円 ワイルドカード 18000円 (RapidSSL Strategic Partner) 新規申し込みおよび、サーバへの設定についてはこちらを。 【メモ】 SSLをインストールする（トラウマを乗り越えた話） | mutter 手順におけるファイル名は上記エントリを引き継いでいます。
毎朝6時過ぎに、前日はてなブックマークでブックマークしたエントリを集めたエントリを自動投稿しているのですけど、最近それが2重に投稿されて行っていることに気付きました。なんでなのかな…と思って投稿された内容を確認してみると、どうも現在は使っていないテンプレートで記事が投稿されている様子。えっ、なにそれ怖い。 一瞬、なんらかの非現実的なエネルギーによって過去のプログラムが未来に蘇り、開発された当時の、今はもう世相に合わなくなってしまっている設定に基づいて、自らの存在を現代社会に誇示しようとしているのか…なんていう妄想が浮かびましたが（BIOSHOCKみたいなの）、もちろんそんなことはなくて、さくらVPSのリニューアルで引っ越した時の旧サーバ（現在解約処理中）がまだ稼働していてcronが動いていたため…でした。えっ、なにそれ怖い。 DNSが切り替わってるんだし悪さは出来ないだろう（旧サーバ内で完結するだろう）と思っていたんですが、考えてみたらブログへの自動投稿はXML-RPCを利用していて、XML-RPCのエンドポイントはhttp://からのフルパスで指定しているのですよね。つまり、Webサービスパスワードが同じである限り旧サーバのcronから現サーバへの投稿は可能。えっ、なにそれ怖い。 IPアドレスで指定しているような設定（DB操作など）は現サーバには繋がらなくなっているので問題ないのですけど…見落としていました。油断してた。cronのチェックをするよりもサーバ自体を止めた方が確実なので、そのように。それにしても不思議なのは、サーバの引っ越しを行ったのは4月中旬で、異常が確認できるのは5/20以降。その間は特に何も問題はなかったんですよね…なにがあったんだろう。突然何か閃くものがあったとか。人為的にスイッチを入れられたとか。えっ、なにそれ怖い。
かなりBasicな話なのですけど、設定ミスでアクセス出来ない事例が生じてたのでメモとして。Apacheの設定で「wwwあり」と「wwwなし」を統一するには、VirtualHostを使うと楽です。
ServerName www.example.com
Redirect permanent / http://example.com/
ServerName example.com
Redirect permanent / http://www.example.com/
ServerName www.nplll.com
Redirect permanent / https://nplll.com
ServerName www.nplll.com
Redirect permanent / https://nplll.com/
15時くらいにサーバの1つが突然繋がらなくなり、何かやっちまったのか（例えばデータベースへの過剰なアクセスとか）と思ってサーバを再起動してみたのだけど全然ダメでおろおろしていたら、しれっとこんな告知が出てました。
メンテナンス・障害情報・機能追加｜さくらインターネット公式サポートサイト
平素よりさくらインターネットをご利用いただき、誠にありがとうござ います。 本日、ご提供サービスにおきまして、以下の通り障害が発生いたしました。 ご利用中のお客様には大変ご迷惑をおかけしておりますことを深くお詫び 申し上げます。
影響範囲 : さくらのVPS 1Gプランの一部 IPアドレスが下記の範囲のお客様 219.94.245.15 ～ 219.94.245.134 障害内容 : サーバに接続できなくなる障害が発生しました。 障害によりVPSの意図しない再起動が発生しました。ああうん、ドンピシャだよさくらさん。 いままでここまでビシッとターゲットになったことが無かったのでちょっと驚きました。発生したのが15時20分で復旧したのが18時05分。何が原因か解らないけど（機材の故障かなぁ）さすがに3時間とめられるのはきついなー。まぁ、障害発生は仕方ないか。ただせめてメールでお知らせくらいして欲しいなーと思いました。障害情報をRSSで読むといっても、それを読むRSSリーダーが今障害が起きているサーバに載っていたので。 とりあえず、データに何の問題も無くて良かったです。やれやれ。
開発者である平林幹雄さんによると「TokyoTyrant」はキャッシュサーバではないと。
ああ、確かに。Tokyo Tyrantも似たようなコンセプトなのだが、TTはキャッシュサーバではない。キャッシュサーバには、一定時間が経過したら消えるレコードを格納することで空間使用量を一定に保つという「expiration」機能が求められるのだが、TTはそれを自身では実装していない。つまり、TTは「キャッシュ」というよりも「簡易ストレージ」といった位置づけの製品だと言える。
調べてみたらPEAR::Cache_Liteが思った以上に頼りないことが解ったのでキャッシュ機構の入れ替えを検討。 【メモ】PEAR::Cache_Liteの生存期間について誤解してたこと（追記あり） | mutter いろいろ考えたのだけど、個人プロジェクトなんだし好奇心優先って事でKyotoCabinetとそれを扱うKyotoTycoonを入れて、PECL::Memcachedを利用して接続してみることにしました。PHP側については、OpenPEARの方に「Net_KyotoTycoon」と言うライブラリもアップされているのですが、まぁ今は良いかなと言うことで。 Net_KyotoTycoon \ パッケージ \ Openpear KyotoTycoon の PHP 版を作った – Heavens hell と言うわけで、以下インストール。
