テストです。
アンドロイドから投稿テスト！
返信
作成者アーカイブ: bit07
PHPの “0″ という文字列の真偽
if (“0″) {
echo “真”;
} else {
echo “偽”;
}
これは「偽」と表示される。
PHP5 の参照渡し。
超基本。
普通に。
$a = 'Test'; $b = $a; $a = 'Change'; echo "b: $b"; // b: Test
参照渡し。
$a = 'Test'; $b = &$a; $a = 'Change'; echo "b: $b"; // b: Change
function 内の include
test1.php
function foo() {
global $color;
$fruit = 'SUIKA';
include 'test2.php';
echo "A $color $fruit\n";
}
for ($i=0; $i<100; $i++) {
foo();
echo memory_get_usage() . "\n\n";
}
test2.php
$color = 'green'; $fruit = 'apple';
test1.php を実行したとき、メモリが増加する。
メモリ増加の原因は、ダブルクォーテーション内の変数展開であった。関数内のincludeはメモリを増やさない事がわかった。
CoreServer で PHP CGIモード（セーフモード：オフ）
セーフモードの回避策で、
AddHandler application/x-httpd-phpcgi .php
とするのだが、CGI版のPHPを動かすということである。
しかし、CGIのPHPでも問題がある。
HTTPのレスポンスヘッダーが常に Content-Type: text/html としてしまう。
CGIのPHPでFireFoxを使って管理画面が崩れてしまうのは、このせいである。
この回避策として、load-styles.phpのみをモジュール版に戻すという手段もあるが、他の手段としてphp.ini を各ディレクトリに設置するということをする。記述は下記の通り。
cgi.nph = 1
default_mimetype =default_charset =
しかし、次の条件の時はまだ足らない、
- セーフモード：オフでないとならない場合。かつ、
- レスポンスヘッダーがPHPで設定したContent-Typeでならないとき。かつ
- レスポンスヘッダーがStatus:304でならないとき。
このとき、なにが足らないかというとStatusが常に200となってしまう。
一応回避策はあって、
- 先頭行に、#!/usr/local/bin/php -q とする。
- アクセス権を755とする。
- .htaaccess で
などで該当ファイルを
AddHandler cgi-script .php とする。
でも、この方法は面倒だなぁ。
trac インストール
ここで流れを把握
http://d.hatena.ne.jp/re_guzy/20071002/p1
python 2.5インストール
http://blog.wiredeffect.com/archives/1198
python 本店
http://www.python.org/download/releases/2.6.4/
python 日本語
http://www.python.jp/Zope/download/pythoncore
trac日本語
http://www.i-act.co.jp/project/products/products.html
Mysql-Python
http://blog.srengine.com/2008/02/python-mysql-python.html
参考
さくらでtrac
http://weekbuild.sakura.ne.jp/trac/wiki/TracDoc/SakuraInternet
フロントページの表示
フロントページの表示
- 最新の投稿
- 固定ページ (以下を選択)
- フロントページ:
- 投稿ページ:
とあるが、まず、「最新の投稿」は読んだまま。
問題の固定ページを選んだ場合は、「フロントページ」「投稿ページ」は同じページは指定できない。
違うページを指定した場合、「フロントページ」はトップページを表示する。内容はPAGEで入力したコンテンツ。「投稿ページ」はPAGEで入力したコンテンツは無視される。投稿で入力した最新の記事たちが表示される。テンプレートはhome.phpを優先的に使用する。なければ、index.php。page.phpは使用されない。
WordPress TinyMCE Advanced 3.2.7
photo credit: m.eckelberg
CoreServer で Subversion が突然使えなくなった。
なにやら、本日突然、CoreServerに設置してあるSVNが使用できなくなった。
expected format ’3′ of repository found format ’5′
というエラーが出る。なぜだ〜？昨日まではでなかったのに。
まあ、原因究明ができなかったが、対処はできた。
エラーの内容は、formatつまり、バージョンが違うことらしい。
CoreServerは標準で、1.2のsvnが入ってる。そこに、ユーザーホームに1.6をインストールし、使用している。突然、1.6の使用が断たれたようだ。
.bashrc に svnへのパスを記述すれば良いとあちらこちらに書いてあるが、もちろん、そうなっている。以前から変更もしていない。
アクセスは「svn+ssh」を用いていて、sshがsvnserveを稼働させるようにしてある。
そこで、authorized_keyに
command=”/path/to/svnserve -t” シェルアクセスとは別の公開鍵の記述
を追加し、ホームディレクトリに設置してあるsvnserve 1.6 で稼働することを明示した。
クライアントはMacOSXである。クライアント側の.bashrcに $SVN_SSH 環境変数を下記のようにセットした
export SVN_SSH=”ssh -i /path/to/svn_rsa”
svn_rsa はssh-keygenで作成した秘密鍵のファイルである。シェルのアクセスと同じ鍵にすると、シェルアクセスがsvnserveを稼働させてしまいコントロールできなくなる。なので、別の鍵のセットを作成する必要があった。
あと、確実に秘密鍵を参照しにいくように、~/user_name/.ssh/configというファイルを作成し、そこに下記のように記述した。
IdentitiesOnly yes
この記述がないと、ssh-agentがサーバーに対し、１つの鍵を保持し、それを使いまわすようだ。シェルとsvnserveで鍵を使い分けができなくなり、不便な状態が続いてしまう。
これで、シェルによる、svnserveへのアクセスは可能になった。しかし、svnXというアプリケーションはこれでもformatのエラーをはく。.bashrcを認識しない模様。
そこで、~./subversion/configの[tunnel]のセクションに下記のように追加した。
ssh = $SVN_SSH ssh -i /path/to/svn_rsa -q
これで、svnXも使える様になった。最後の-qは「Killed by signal 15.」の非表示のための対処である。
Firefox 3.6
Firefox 3.6 リリースされましたね。
とにかく、速いです。
私の使っているマシンは Mac G4 しかもシングル 1.25MHz CPU です。
それでも（だから）3.5に比べ劇的な速度アップを体感できます。
JavaScriptの処理が改善された恩恵です。