iGoogleガジェット + 何か

Jan 24, 2011

wtnabe 11/01/22 22:37 Google Chrome 拡張の RTM のようなものが Firefox

にも欲しいなぁ
wtnabe 11/01/22 22:45 おぉ、サイドバーで開くこれがまさに Google
Chrome 拡張で開いてるやつか。なるほど。
wtnabe 11/01/22 22:47 ブックマークツールバーから外に出すのは無理なのか
wtnabe 11/01/22 23:09 結構この iGoogle ガジェットを使う方式いいな。

って思った。

cf.

iGoogle って使ってないからあまり意識したことがなかった。

freebsd-update で 6.4-RELEASE に

Jan 24, 2010

自宅サーバの FreeBSD は基本的にはお気楽実験用なんだけど、DNS cache サーバを兼ねているので事故るとまずい。そういう意味も含めて古めのものを追っかけてるんだけど、今まで使っていた 6.3 が 2010年1月いっぱいでサポートされなくなるので 6.4 に上げた。

freebsd-update

手順はこんな感じ。

freebsd-update -r RELEASE upgrade
freebsd-update -r RELEASE install
shutdown -r now
freebsd-update install

library が上がって ports 上げろって言われたので以下の作業を追加。

portupgrade -af
freebsd-update install

念のためもう一度再起動しといた。ports の full rebuild は途中で設定を何個か聞かれながらで丸半日以上掛かったかな？

そうしたら ircd-hybrid, nadoka, tiarra の起動周りがイマイチ、nadoka がうまくいったりいかなかったりしてる。もしかして nadoka が ircd より先に起きたりしてるのかもしれない。どうにか手動で順番もきっちり意識して再起動して意図した動きに。やっぱ ircd も God 管理にしなきゃダメだなぁ。

Trac が 0.11 で動かなくなった

※ 解決済み。なぜか mod_fastcgi が無効になってた。これを戻しただけで動いた。

Trac, pysvn 周りはいつもちょっとハマるので面倒で放置していたんだけど、portupgrade -af で一緒に上がってしまって案の定動かなくなった。

どうも PYTHON_EGG_CACHE が設定できていなくて cache を作るディレクトリが見つからないみたいなんだけど、

Apache + FastCGI

で動く設定が出てこない。なんか FastCgiConfig –initial-env じゃなくて PythonOption で渡すみたいなんだけど、edgewall の方にキチっと書かれてないなぁ。Python 読める人が自力で解釈してブログに書いてあるのはありがたいんだけど、0.11 が出てずいぶん経つのに情報が整理されてないのは Python 製のツールっぽくない印象。

とりあえず自宅で Trac は重要じゃないから今度考えよう。

PHP の設定って PHP で書いた方がよくない？

Jan 24, 2008

PHP の各種設定を行える場所

基本的に3つあると思う。

php.ini
.htaccess
設定用関数を利用

で、普通 PHP の入門記事とかで触れられるのは 1 か 2 のはず。でも、実はこれ間違ってたんじゃないかって思い始めた。

まぁ確かにすべての項目を 3 の方法で設定できるわけじゃないんだけど、ほとんど困らないような気がする。

今までの方法は全部ダメ

php.ini は忘れた方がいいというか単なるデフォルト

まず php.ini , これは virtual host で複数サイトを展開する際、すべて設定が同じになってしまう。今からまっさらの状態で新しく始めるならこの設定にしておくべきというのがまずだいだい決まっているので、それに従って設定してしまうというのは確かにアリ。

でもちょっとでも歴史があった場合これだけじゃ絶対うまくいかない。sjis のサイト、euc-jp のサイト、utf-8 のサイトが入り乱れていること請け合い。あるいはオープンソース開発者でいろんなコード触ってるとかいう場合なんかも一つの php.ini でまかなえるはずがない。

だからもうこの際「インストールして php.ini を編集する」っていう流れは忘れちゃっていいと思うんだ。

.htaccess はサイトごとの設定を保持できるけどそれだけじゃダメ

..htaccess じゃなくて apache の conf の方がいいとかそんなことを言うつもりなし。

問題は CLI でスクリプトを起こしたときに .htaccess は役に立たないってこと。だからいちばんいいのは、

..htaccess などに

php_value auto_prepend_file CONFIG_FILE

と書いておいて設定は PHP で書く方法なんじゃないか、というのがこの記事の趣旨。

だいたい、.htaccess で設定を書くと PHP 独自定義の bool値も定数も存在しないので読みにくくなってしまう。

php_value error_reporting 2047

とか書かれててもすぐに意味が分からないし、php_flag なのか php_value なのかも気にしなきゃいけない。面倒くさいし、この部分、マニュアルもそんなに丁寧に書かれていない。

やってみよう

php.ini だと

mbstring.language          = Japanese
mbstring.internal_encoding = utf-8
mbstring.http_input        = pass
mbstring.http_output       = utf-8
mbstring.detect_order      = auto

これを .htaccess で書くと

php_value mbstring.language Japanese
php_value mbstring.internal_encoding utf-8
php_value mbstring.http_input pass
php_value mbstring.http_output utf-8
php_value mbstring.detect_order auto

これを PHP で書くと

<?php
// mb_http_input(); // 違う機能です

mb_language( 'Japanese' ); // ※ mbstring.language と同じ意味ではありません！
mb_internal_encoding( 'utf-8' ); // 自動変換の機能に対しては有効ではありません
mb_http_output( 'utf-8' );
mb_detect_order( 'auto' );

ただし上に書いたように注意事項もある。

PHP の中ですべての設定を書けるわけではない
PHP の中で行った設定が期待通りに働かない場合もある

特に 2 の方は一見うまく動いているように見えるので注意が必要。例えば

mbstring.internal_encoding()

を PHP の中で設定するときは

mbstring.encoding_translation off

とセットでないといけない。encoding_translation は PHP のコードを読み込む前に動く（でないと透過的な変換として機能しない）ので、php.ini あるいは .htaccess の段階で internal_encoding が決まっていないと正しく動作しない。逆に、この機能を使いたい場合は

mbstring.encoding_translation
mbstring.internal_encoding

は PHP の外でセットしておかないとダメ。最近では UTF-8 をそのまま使うことが多くなっているはずで、その際は自動変換の機能はなくても問題ないけど、そうでない場合は注意が必要。

PHP で設定を書かなくてもいいのは実はメリットじゃなかったのかも

今回なんでこんなことを思ったかっていうと、さっきも書いたけど

CLI で起動したとき .htaccess は生きてこない

ということに今さら気づいたから。しかし上の auto_prepend_file なら CLI でも以下の方法で設定を読み込むことができる。

php -d auto_prepend_file=CONFIG_FILE

CLI を活かせると、例えば大量の PHP のファイルの動作チェックの自動化とかできちゃう。もっとも、イマドキのアプリなら普通はフレームワーク使ってるし、フレームワークのテストに従ってるかもしれないし、ユニットテストがバッチリ動いててチェックも楽ちんなので全然関係ないかもしれない。

でもそうじゃない環境もある。絶対にある。そのとき、せめてこの方法が使えれば人の目と手でチェックするだけよりも確実に効率は上がる。上がるんだよ。

上の方法で

error_reporting( E_ALL );
ini_set( 'log_errors', true );
ini_set( 'error_log', '/path/to/error.log' );

とかしておいて

for i in `find /path/to/app -name '*.php'`;
do
  cd dirname $i;
  php -d auto_prepend_file=CONFIG_FILE $i;
done

とか回すとドバーっとエラーがログに吐かれる。いちいちブラウザで開いて回らなくてもよい。

まぁ CLI の場合は当然 HTTP 周りのパラメータがセットされないわけだけど、それも CLI での検証時だけ適当に補完するように CONFIG_FILE を書いてやればとりあえず騙せるのではなかろうか。

PHP スクリプトで変更できない設定を CLI 環境下で反映する

PHP のマニュアルで変更の可否が PHP_INI_SYSTEM と PHP_INI_PERDIR になっているものは php のスクリプトからは変更できない。ini_set() とか使ってもダメ。.htaccess を使えない CLI の場合はこうなると php.ini をいじるしかないけど、システム全体に影響する php.ini をいじりたくない場合は

php -c PATH

でそのときだけの php.ini を指定することができる。

というわけで

また一つ PHP ならではの機能がメリットでなくなったことを感じたのでした。（代わりに auto_prepend_file という PHP ならではの機能を使ってるんだけど。）

というかやっぱさ。今さらだけど php.ini や .htaccess でしかいじれない設定があるのってすっげーおかしくね？ CLI だと

php -c PATH

で ini ファイルを都度指定できるけど、mod_php とかだと ini を切り替える方法ないよね？なんでこんな変な方針なんだろう。譲って言語の外で設定できることはよしとしよう。それが便利な場合もあるさ、というか実際便利だと思っていたこともある。でも言語の中で変更できないっておかしいよなぁ。

cron ジョブに複雑な条件を与えやすくする

Jan 24, 2007

つーことで『cron, crontab, and more』でちまちま悩んでいましたが、思いついたのはまた Ruby ですが以下のものです。やってることは簡単で、要は

複雑な条件はお気に入りの言語で記述する

ってことです。そのために

条件の名前と実行するプログラムを与えるだけのスクリプトを用意
条件の名前はそのまま（この場合は Ruby の）実行するメソッド名に該当する
cron には（例えば）以下のように書く

complex-cron -c RULE 'program'

という方法にしてみました。以下のスクリプトでは RULE は省略可能で、その場合は `default' を指定したものとみなしています。

※ 比較的最近の Web アプリでよくあるプラグインと基本的には同じアイディア、だと思ってます。

呼び出すメソッド（つまり判定条件）に引き数を与えることはできません。一瞬悩みましたが必要ないだろうと思いますし、引き数を与えられるようにすると実行時のパラメータの与え方が複雑になります。

実行するスクリプト

（例えばcomplex-cron て名前にしておく）

#! /usr/bin/env ruby

require 'optparse'
Version = '0.1'

class ComplexCron
  def initialize
    @condfile     = '/etc/defaults/cronconds'
    @condname     = nil
    @cond_default = 'default'
    @debug        = false

    accept_options()
    @cmd = ARGV.shift
    exam_options()
    exec_indeed()
  end

  def exam_options
    if ( @cmd.nil? )
      raise 'Nothing to do.'
    end

    if ( !File.exist?( @condfile ) )
      raise "File #{@condfile} does not exist."
    else
      load( @condfile, false )
      if ( @condname.nil? )
        @condname = @cond_default
      elsif ( !ComplexCronConds.instance_methods().include?( @condname ) )
        raise "Rule #{@condname} is not defined."
      end
    end
  end

  def exec_indeed
    if ( ComplexCronConds.instance_method( @condname ) )
      if ( @debug )
        puts @cmd
      else
        exec @cmd
      end
    end
  end

  def accept_options
    opt = OptionParser.new()
    opt.on( '-f CONDFILE' ) { |file|
      @condfile = file
    }
    opt.on( '-c CONDNAME' ) { |method|
      @condname = method
    }
    opt.on( '-n', 'dry run' ) { |v|
      @debug = true
    }
    opt.parse!( ARGV )
  end
end # of class ComplexCron

ComplexCron.new()

設定ファイルとは名ばかりの Ruby スクリプト

例えば /etc/defaults/cronconds とかいう名前で置いておく。場所はシステムに応じて適当に決めて。

# -*- ruby -*-

module ComplexCronConds
  def default
    return false
  end
end

この中に上で RULE と書いた名前に該当するメソッドを定義していきます。内容はどうぞご自由に。ただしあくまで「条件」をメソッドとして書くので、必ず true か false を返してください。default はあった方がいいかなと思って定義してあるんですけど、実際どう使うのかはあんまりイメージできてません。

これでまぁ、第3水曜だのシステムの負荷の様子だの、Ruby で判別可能な条件はなんでも書けるようになったわけです。あとは必要に迫られたときに考えればいいんじゃないかと。