www.naney.org をホスティングしているサーバが重いと思ったら、同じサーバ上のあるユーザの CGI プログラムが5プロセス無限ループしてるっぽい……。 load average 20前後。
あおりを受けて、nDiki が大変なことになっている。
nDiki は SpeedyCGI を使っているのだが、バックエンドの speedy_backend が捌ききれず、フロントエンドの speedy が大量に待ちに入ってしまっている。
MaxBackends を調整しても駄目(下手にバックエンドプロセス数を増やしても、結局処理が追いつかない)。
ということで急遽対策。
load average が高い時には、はてなブックマーク上の検索結果を表示させるために行なっているはてなブックマークへのアクセスを休止するように変更。 24時間に設定してあるキャッシュの有効期限が切れていても、高負荷の時にはアクセスにいかないようにする。
これで DiKicker の処理時間を短縮。相手側サーバへの負担も軽減。
おかげ様でここ最近 nDiki の RSS へのアクセス数が増えてきている。 ありがたい事である。
しかしながら DiKicker の RSS レスポンスは、あまり賢くなく毎回データベースから最新記事情報を抽出して生成しているため、それほど処理が速くない。
なのでアクセス頻度を高くしている RSS リーダがどこかで同時に起動しているとちょっとしんどい。 特にここ最近 Google Desktop からのアクセス数が増えている感じ。
さすがに今日はサーバの負荷が高く処理が追いつかなくてどうしようもないので、一時的に Google Desktop を拒否することに。
.htaccess に設定を追加。
BrowserMatch "Google Desktop" denybrowser deny from env=denybrowser
近日中に、RSS 処理を改善してすぐに解除する予定。
効果があるかどうかは不明だが、Crawl-delay: に対応するというクローラ (Slurp、msnbot) 向け設定を追加。
User-agent: Slurp Crawl-delay: 20 User-agent: msnbot Crawl-delay: 20
アクセス数としては Googlebot と Slurp がダントツ。 しかし Google は無下にする訳にもいかないしなぁ。
2006年3月1日にリリースされた RSS リーダ フレッシュリーダー(Fresh Reader)を昨日 Debian GNU/Linux sid 環境へインストールして試用を開始してみた。
ノート PC 上で動いている Apache2 にインストール。PHP が必要なので、libapache2-mod-suphp をインストールしておく。
apt-get install libapache2-mod-suphp
他のプライベートな Web サイトと分離するために、バーチャルホストを1つ作ってそこへインストールすることにする。 libapache2-mod-suphp を使って、自分のユーザ権限で db に書き込むように設定。 また自分だけが使えるようにアクセス制限しておくことにする。
/etc/apache2/sites-available/freshreader を作成:
<VirtualHost *> ServerAdmin naney@naney.org ServerName freshreader SuexecUserGroup naney naney DocumentRoot /var/www/freshreader <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/freshreader> Options Indexes FollowSymLinks MultiViews ExecCGI AllowOverride All Order deny,allow Deny from all Allow from 127.0.0.0/255.0.0.0 ::1/128 </Directory> ErrorLog /var/log/apache2/error.log LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature On </VirtualHost>
で、次にバーチャルホストを有効にする。
#mkdir /var/www/freshreader #chown naney.naney /var/www/freshreader #a2ensite freshreader #emacs /etc/hosts # 127.0.0.1 に freshreader を追加 #/etc/init.d/apache2 reload
続けてフレッシュリーダーをインストール。 基本的にはアーカイブを展開するのみ。
$cd /var/www/freshreader $tar zxvfp ~/sffr10lin.tar.gz $chmod 700 db
で Web ブラウザから
http://freshreader/freshreader/index.html
にアクセスする。これで基本的なインストール終了。
それから1時間に1回自動巡回するようにしておく。 今回は自分のユーザアカウント (naney) でインストールしてあるので、自分の crontab 設定に追加する。 自分の場合は、1時間に1回 run-parts されるディレクトリがあるので、そこに
#!/bin/sh /usr/bin/php5 -f /var/www/freshreader/freshreader/crawler.php
というファイルを作成しておく。
あとはマニュアルの通りWeb ブラウザでユーザを作成したり、巡回先を登録したりしていく。
現在のところ Web 巡回は
と用途ごとに分散してしまっている。
集約したかったのだが、なかなかこれというのが無かった。
と望んでいる機能が入っている。
早速 Bloglines から登録一覧を OPML でエクスポートして、インポート。
動作も軽快だしいい感じだ。 「一度に表示する未読記事の数」が設定できるのが非常に気にいった。
未読記事を表示したらそのページ(タブ)を閉じる前に全部目を通さなければならない(でないと、読んでいないものも既読になってしまう)。 Bloglines だと前回見てからの未読が1度に全部表示されるので、間隔をあけてしまった時に辛い。 この点でフレッシュリーダーは便利。
現在「無制限」「約100件」「約1000件」が選べるが、ここは自由に数値で指定できるとなお嬉しい(50件づつぐらいにきざみたい)。
Web 巡回は、基本的にこれに集約しようかな。
ということでブロガーライセンス(自身でブログ/ホームページを運営されている方向けの優待ライセンス: 無料)を申請。
社内での情報共有を目的に社内 Blog を立ち上げた。次のステップは以下だ。
読んでもらえなければ Blog を書くメリットがあまりなくなってしまうので、これは重要だ。 逆に良さがわかってくれば、自分も書こうという人が自然ど増えてくるはず。
まわりを見た感じだと、普段から RSS リーダを使っているというという人はほとんどいないようなので、まずは RSS リーダを普及させる必要がありそうだ。
うちのオフィスでの推奨 RSS リーダの条件としては
あたりかなと。むろん個人で気にいったのがあればそれにこしたことはないのだが、ここでは初めての人に薦められるものをということで。
まずは Google Desktop を試してみる (Windows をメインに使っていなかったため、今までインストールしたことがなかった)。
ウェブ クリップで RSS/Atom フィードを読むことができる。
感蝕は「まあまあ」。 他の機能も含めて使っている場合はいいかもしれないが、巡回用の RSS リーダとして使うにはそれほど良いというほどでもないな。
フィードの表示順がちょっとわかりにくいのと、フィードの URI を誤認するのがマイナスポイント。
会社で
「テーマ別に社内 Blog を分けるべきか?」
という質問をもらった。
私の意見としては、ほとんどの場合分けるべきではないと思う。
Blog 分けてそれぞれをきちんと更新していくのは、結構な手間と時間がかかるものだ。
たいがいの場合 Blog のカテゴリ機能やタギング機能を使うことで十分整理でき、その方が効果的に運用できると思う。
普段仕事では
の2つを使っている。
先日メールを Gmail にしたことで、母艦が無くてもメールの読み書きができるようになったので、これを機にサブの Windows デスクトップ PC だけで仕事ができるかチャレンジしてみた。
使用したソフトを書き出してみた。
Linux | Windows | ポータブル | |
Web ブラウザ | Firefox (Iceweasel) | Firefox | o |
メール | Mew / Gmail | Gmail | o |
Firefox + tweetbar | Firefox ( + tweetbar) | o | |
IME | SKK、uim | SKKIME | x |
キーバインディング | XKeymacs | ? | |
Skype | Skype | Skype | o |
パスワード管理 | テキストファイル | KeePass | o |
社内 Wiki 読み書き | Firefox | Firefox | o |
Excel データ読み書き | (していない) | Excel | x |
Word データ読み書き | Mew + wvHtml (/ OOo) | Word | x |
PDF 閲覧 | Adobe Reader | Adobe Reader | x |
メモ | howm | Google ノートブック | o |
RSS リーダ | フレッシュリーダー |
「ポータブル」は USB メモリにソフトウェアが入れらる、あるいはオンラインサービスとして任意の Windows BOX で使えるならば o 。
ちょっとしたメモ書きを Windows 上でして後で母艦で参照するのに、Google ノートブックを使い始めることにした。 テキストファイルに書いて USB メモリに入れてコピーするよりはずっと楽。
ネットサービス系で使った/使いたいと思ったアカウントは今日のところは以下。
はてな・Twitter は母艦の Firefox にパスワードを暗記させていて覚えていないので、頭に入れておくか KeePass に入れておく必要あり。
午前中は何とかいけたが、Web ブラウザ上の Gmail でメールを書き始めたら急にストレスを感じるようになった。
これらの点は多分 Firefox 拡張機能や、Greasemonkey スクリプトで多分ある程度解消できるのだと思う。要環境整備。
普段使っている RSS リーダが使えないと昼休みに巡回ができなくて淋しいが、こちらはその分他のことに時間が回せて結果的には悪くないかも。
今後順次環境を整備すれば、ライトな作業なら Windows BOX だけで済ませられるようになるかなぁ。
昨日会社で借りたので読んでみた。 エンジニア★流星群@Tech総研連載開始当時にはちょろっと読んでいたんだけれど、RSS リーダーで全文読めなかったのでその後読んでいなかった(肝心の画像がブロックされている)。
「理系の人々」というのは言い過ぎで「コンピュータ系の人々」という内容だけれど、それだけに直球でくる。 面白いけれど1人じゃ面白くない。 皆で読んでネタとして盛り上るための本だなあ。 そういう意味ではやはり Web 上にあることに価値があるのかも。
ツボにはまったのは「理系の分類」。 そう理学系と工学系はちょっと違う(ちなみに自分理工学部の中の理学)。 それぞれ、ちょっとした価値観の違いとプライドがある(はず)。
[ 読書ノート ]
一昨日、橋本大也氏の情報考学の記事「10月1日開催 Evernoteデベロッパーズミーティング@デジタルハリウッド大学大学院 秋葉原メインキャンパス」で、Evernoteの日本初のデベロッパーズミーティングが開催されることを知った。 会場が秋葉原で会社帰りに寄れるし、Evernote を利用している中で API についてもちょっと興味を持ち始めていたので、いい機会だと参加申し込み。 Evernote 遍歴を整理してみたり。
で、本日退勤後参加してきた。まだ若い企業であること・日本法人「エバーノート株式会社」も今年設立されたばかりであることなどもあってか、即席的だけれどフレンドリーな雰囲気のある、皆でこれから盛り上げていきましょう的な良い雰囲気の会であった。 Evernote 好き度ちょっとアップ。
以下ノート。
開会のメッセージ。
「Integrating with Evernote」
英語による発表。中島健氏が適宜通訳。
Evernoteサイトメモリー自体は思うところがあってまだ導入してみていなかったんだけれど、話を聞くことでサイトオーナーにもメリットがあることは感じられた。
OAuth も対応しているんだ。 また API を使えば Linux 版クライアントを作れる人は作れるんだな。
途中で Twitter ハッシュタグ指定が。 この時点で #EvernoteJP よりも多く Tweet れている #Evernote を推奨とのこと。
ENML については以前ドキュメントを読んだことがあるので流して聞く。
Android はやはり intent が強力だね。 今後新しい intent 対応があるとのこと。楽しみ。 個人的にははやくオフライン閲覧ができるようになってくれると嬉しい(すこし前のアップデートで準備段階としてキャッシュ機能が入ったのでもうすぐらしいんだけれど)。
デベロッパーズミーティングということで、ぜひ開発者の声をということで今朝プレゼンテーションを頼まれたとのこと。
初代 MacBook Air 用ディプレイ接続のアダプタを忘れたが、会場参加者にもっている人が貸してくれて無事プレゼンテーション。やはり Mac 率高い。
開発している iPhone RSS リーダに求められた「ニュース保存」に対応するために
と対応していった。Evernote の API 対応は1〜2日程度+テスト。工数少なく機能実装できたとのこと。メール送信によるノート新規追加を連携としているものが多いが、API 利用することでノート表示などもサポートできるという利点があるなど。
「Evernoteなう」
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。