memo: pukiwiki spam alert

http://d.hatena.ne.jp/kinneko/20061102/p1

pukiwiki で書き込みしてると

「Alert: plugin "XXX" was called over 768 times. SPAM or someting?」

とか出る場合がある。書込する当該ページでプラグインが呼ばれすぎているのが原因なので、その場合は原因となる "XXX" プラグインの部分を削除してから書きこむようにするか、上記の kinneko さんのリンクを参考にして強制的にページを削除してから、"XXX" プラグインを除いた形でページを最作成すると良い。

pgrep, pkill

http://www.freebsd.org/cgi/man.cgi?query=pgrep&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE&format=html
http://www.linux.or.jp/JM/html/procps/man1/pkill.1.html

その昔、俺が大学に入って間もないときは「名前にマッチするプロセスに対して一気にシグナルを送る」というのは意外に大変だった。当時は以下のような長ったらしいことをしていたので、今でもそうする癖がついている

ps -wef | grep i-want-to-kill-this-process | awk '{print $2}' | xargs -n 1 kill -9

しかし今やこんなことは無用だ。以下のように1コマンドで可能だ。名前にマッチするプロセスIDを探すのだってpgrep一発である。良い時代になったものだ(´ー｀; )

pkill -u mumumu i-want-to-kill-this-process

ただ、pgrep, pkill ともに環境依存ではある。Solaris, Linux, FreeBSD にあることは確認しているが、drryたんによると標準の Mac OS X には存在しないようだ。

＃どうも未だに癖が抜けないのでjournal
＃killallはどうなのって言われそうだけど、、

poss-ja support page added

http://producingoss.com/ja/ja-support.html

「オープンソースソフトウェアの育て方」のサポートページ作りたいね、と高木さんと話しつつ放置していたら、Karlから案内のメールが来た。丁度いいタイミングなので追加しておいた（一行独白

[memo] Looking up the past timeline

Twitterのタイムラインを調べて、ちょっとしたワードにマッチしたものを削除する処理が必要になった。さすがにWebインターフェイスから手動で調べるのはやってられない。

Net::Twitter楽だよね。例外処理が微妙にダサイと感じるのはPerlそのものの問題なので置いといて、と。ひっかかったのは マルチバイト文字の正規表現を書くときは、Perlの内部フォーマットである UTF-8フラグが立った状態にしないといけない、という点くらいだろうか。

俺別にPerlが嫌いなわけじゃないんだね、と改めて再認識した。



[ Update January 2nd 20:36:55 JST by m ]

例外処理がちょっとダサイ点については Try::Tiny がちょっとカッコいい！(｀ー´)
tokuhirom さめ情報ありがちょーヽ(´ー｀。)ノ

use Try::Tiny;
try {
    die "error occured!";
} catch {
    warn "caught error: $_";
}

Last day of 2009

あと数十分で2009年も終わる。この一年はどんな年だったか、ちょっとだけ書いてみる。

ざっと言えば本を出すのに協力したりだとかコード書いたりだとか仕事したりだとか、そんな一年だった。けど、自分が志向してる方向が変わっているのは間違いない。一応Web業界の動向も追い続けてはいるけれども、もっとレイヤの低い方向に近づいている感じ。

脚を洗いたいと思う一方で結局今年は「完全には」洗えなかった。自分が進もうとしている方向に迷いがあるのも事実だろう。自分が気に入った方向、居場所とはどこか。それに答えが出たとき、もっとアクティブに動ける気がする。

なんだかんだいって、今年も沢山の人にお世話になりました。来年も宜しくお願いします。

[memo] make is NOT always GNU make

http://www.freebsd.org/cgi/man.cgi?query=make&sektion=1

当たり前のことではあるが、makeコマンドで実行される make が必ず GNU Make とは限らない。FreeBSD における make は BSD make であり、GNU make は gmake コマンドである。

Linux, Mac OS X においては、make は GNU make と見て差し支えない。Mac OS X での BSD make は bsdmake である。くれぐれも GNU脳にならないように＞自分

Solaris とかだとどうなるんだろうね。

----

※GNU脳になってしまっていてよくひっかかる別のコマンドとしては、tar コマンドや cp コマンドが挙げられる。特に後者は Mac OS X の cp に -a オプションがないことに驚愕した苦い思い出がある。

[memo] bit shift operator

C言語のビットシフト演算子は、左オペレータの幅以上の値を右オペレータに指定した場合、その動作は未定義である。これは規格で定義された動作である。以下、JIS X 3010 2003 (ISO/IEC 9899) P48 より引用する。

6.5.7 ビット単位のシフト演算子
   シフト式：
       加減式
           シフト式 << 加減式
           シフト式 >> 加減式
制約　各オペランドは，整数型をもたなければならない。
意味規則　整数拡張を各オペランドに適用する。結果の型は，左オペランドを拡張した後の
型とする。右オペランドの値が負であるか，又は拡張した左オペランドの幅以上の場合，
その動作は，未定義とする。

----

このことから、ビットパターンを出力する以下のコードは c の値によって動作するか否かが決まる。型によってオペレーターの幅は異なるため、頭の隅にいれておく必要があろう。間違っても俺のように何も考えずに100ビットとかシフトさせようとしないでください(´ー｀; )

#include <stdio.h>

int main(int argc, char *argv[])
{
   unsigned long long a = 65535; // long long は一般に64bitの幅を持つ
   int c;
   for (c = 63; c >= 0;c--) {    // c を 64にすると途端に動作しなくなる
       printf("%d", (int)((a >> c) & 1));
   }
   printf("\n");
   return 0;
}

[memo] 3 notations of [lat|long]itude

http://en.wikipedia.org/wiki/Longitude

Each degree of longitude is sub-divided into 60 minutes, each of which divided into 60 seconds. A longitude is thus specified in sexagesimal notation as 23° 27′ 30" E. For higher precision, the seconds are specified with a decimal fraction. An alternative representation uses degrees and minutes, where parts of a minute are expressed in decimal notation with a fraction, thus: 23° 27.500′ E. Degrees may also be expressed as a decimal fraction: 23.45833° E. For calculations, the angular measure may be converted to radians, so longitude may also be expressed in this manner as a signed fraction of π (pi), or an unsigned fraction of 2π.

----

ジオコーディングしているとはじめは緯度経度の記法が3つあるのに戸惑ったりするが、基本的には「度・分・秒」や「度・分」の表記ではなくて、「度」の値のみを小数点付きで表す表記（上記で言えば 23.45833°E)を使うようだ。データとして扱いやすいというのがその理由だろう。俺もこの3つのうちどれを採用するかといわれたら、表示上の理由がない限りはこれを選ぶ。strtod すればdoubleにできるし、ね。

分と秒は60進法なので、他の記法からこの記法への変換も簡単だ。分、秒をそれぞれ60及び3600で割って度の値に足せばよい。

undefined reference(3)

もうこのネタやめにしたいんだけど、一応メモしておく。なんでクラス名忘れるかね。これはひどいとしか言いようがない。原因がわかるまでにかかった時間は2分くらい。

---- test.h ----
#ifndef __TEST_H__
#define __TEST_H__

class A {
public:
    static void hoge();
};

#endif  // end of __TEST_H__

---- test.cpp ----

#include "test.h"

void hoge() {
    return;
}

---- main.cpp ----

#include "test.h"

int main(int argc, char* argv[])
{
    A::hoge();
    return 0;
} 

以下の実行結果は最早おなじみである。

$ g++ main.cpp test.cpp
/tmp/ccSUS3Oq.o: In function `main':
main.cpp:(.text+0x12): undefined reference to `A::hoge()'
collect2: ld はステータス 1 で終了しました

undefined reference(2)

前のエントリで書き忘れていたので追記しておく。メソッドの実装忘れも俺的にはよくある。たとえば以下のようなコードである。宣言して満足しちゃった、的なアレである。

--- test.cpp ---

#include <iostream>

class A {

public:
   //    default constructor.
   //    not implemented.
   A();

   void helloworld()
   {
       std::cout << "Hello World!" << std::endl;
   }
};

int main(int argc, char *argv[])
{
    A a;
    a.helloworld();
}

上記をコンパイルすると、下記のようになる。実装がないので、リンカから見えない。以下の結果は当然の帰結である。

$ g++ test.cpp
/tmp/ccIVHTVA.o: In function `main':
a.cpp:(.text+0x74): undefined reference to `A::A()'
collect2: ld はステータス 1 で終了しました

C++ namespace -> undefined reference to 'main'

C++ の namespace は重要なキーワードであるが、うっかり main 関数のようなグローバルな関数をそれで囲んでしまうと大変なことになる。マングリングによってラベルが変化し、自分が意図した通りにリンカから見えなくなるからである。

namespace はスコープを変えるんだというごく当たり前のことがことがわかっていればこんなことは多分普通やらないんだと思います。多分。ただ、そういう理屈もわかっていない初心者とか、以下のような多段 namespace のマクロを全ファイルに適用するのが癖になっている人とかは要注意である。

--- test.h ---

#ifndef __TEST_H__

#define __MUMUMU_NAMESPACE_NAME__ mumumu
#define __AHO_NAMESPACE_NAME__ aho

//
//  namespace macro
//
#define __HOGE_NAMESPACE_START__ \
    namespace __MUMUMU_NAMESPACE_NAME__ { \
        namespace __AHO_NAMESPACE_NAME__ {
#define __HOGE_NAMESPACE_END__ } }

#endif // end of __TEST_H__

--- test.cpp ---

#include "test.h"

__HOGE_NAMESPACE_START__

int main(int argc, char *argv[]) {
    return 0;
}

__HOGE_NAMESPACE_END__

上記の test.cpp をコンパイルすると、以下のようになる。

$ g++ test.cpp
/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o: In function `_start':
/build/buildd/glibc-2.9/csu/../sysdeps/i386/elf/start.S:115: undefined reference 
to `main'
collect2: ld はステータス 1 で終了しました

test.cpp を コンパイルし、main の text セクションのみをダンプすると以下のようになる。namespace の情報がラベルに付加されていることがわかる。

$ g++ -c test.cpp
$ objdump -x test.o | grep main
00000000 g     F .text  0000000a _ZN6mumumu3aho4mainEiPPc

[memo] cygwin

http://www.cygwin.com

久々に cygwin を触ったのだが、なんか日本語入力したいなと思ったり、ターミナルをUTF-8で扱いたいなと思ったりなど、いろんなことを考えてちょっと調べた。以下は自分用のメモである。

• cygwin には nkf が入っていないので、ダウンロードしてきてコンパイルする必要がある。これに伴い、gcc と make は必須になるので留意すること
• cygwin のターミナルをUTF-8で扱いたい場合は、cygwin1.dll の replacementを作っている人がいるので参考にすること。ここには .inputrc も入っているので、参考にすること
• subversion, git, python, ruby, screen は必ず入れること
• ターミナルからの日本語入力は、デフォルトで alt + 全角/半角 しか受け付けないので留意すること
  

C++ memo

以下のようなことはどのようなC++本にも書いてある。スルー推奨。
意識したとき（再認識したとき）に書き留めるのは「個人的に」重要なので書いておく。

----

• クラスメンバとしてポインタを定義する場合は、コピーコンストラクタと operator= に注意
• クラスメンバとしてポインタを定義する場合は、これらを暗黙のうちに定義させると、コピー元 が消えた際に、コピー先のポインタメンバの実体も消えてしまう。必ず意識し、定義すること
• コンストラクタとデストラクタは比較的注意がいくが、この二つは見落とされがちである

----

• （ポインタではない）実体として定義されたメンバは、そのメンバが含まれたクラスのコンストラクタが呼ばれるたびに初期化され、破棄される際に消える
• 実体として定義すると、そのクラスのインスタンスのサイズが大きくなる。通常、クラスには他のオブジェクトもメンバとして含められるので、ポインタよりサイズが大きいから。
  
• 実体として定義されたメンバは、そのメンバが含まれたクラスのインスタンスが生存している間存在する。よって、メンバ関数からその参照を返しても構わないが、そのインスタンスの生存期間は参照を使う側が意識する必要が出てくる

[memo] LGPL License option added to Qt

http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt

商売的にも、プライベート的にも非常に歓迎すべきことである(1行独白

[memo] Ethna Dynamic Form API implementation

超個人的なメモでつ(*´〜｀)

Ethna は フォーム定義を以下のように固定で書くので、フォーム定義が動的に決まる場合にどこにそれを定義するコードを書けば良いかわからない、という問題が存在する。

 var $form = array(
     'sample' => array(
         'type' => VAR_TYPE_INT,
         'name' => 'サンプル',
     ),
 );

現在は、prepare() に書いたり、Ethna_ActionForm の子クラスのコンストラクタに書いたりするしかないのであるが、現在の安定版では DBアクセス等のロジックを Ethna_ActionForm のコンストラクタに書くことができない。なぜなら、Ethna_Backend や Ethna_Session 等の、必要なオブジェクトが初期化されていないからである。

----

現状のtrunkでは、Ethna_ActionForm 初期化後に、DBアクセスのロジックが書けるように既に改造済みだったりする。なので、あとは動的にフォームを定義するフックを書くだけである。

実は、動的にフォームを決めるタイミングは以下のふたつがある。こいつらを一緒のフックにするわけにはいかないので、おそらく setD(ynamic)FormDef_[pre|post]Helper とかを定義するのだろう。なんかわかりやすいAPIの名前はないものか。

• Ethna_ActionClass にアクセスする前に、Ethna_ActionForm を初期化した直後
• View と連携するためのフォームヘルパを使うとき、Ethna_ActionForm を初期化した直後
  

jqModal: Minimalist Modaling with jQuery

http://dev.iceburg.net/jquery/jqModal/

jqModal は、いわゆる(モーダル)ダイアログをクロスブラウザで実現するための jquery plugin である。様々なフックを持ち、CSSによる見た目の改造も容易。かつAjaxにも対応していたりとかして、普通に使い勝手が良いのでメモしておく。

ただ、IE6 には以下の特別な考慮が必要だ。正直 IE6 死ねばいいのに、と思う。

• jqModal.css にある特別な位置決めエミュレートコードを書いてやらないと動かない
• IE6 には、SELECT 要素に z-index が定義されていないという割と有名な問題がある。ダイアログの下に SELECT 要素が万が一ある場合は、$('select').hide() 等で隠す必要がある。

あとは、ドキュメントと、デモにある豊富なコードを参考にすれば問題なく動いた。

Storing Hierarchical Data in a Database

http://www.sitepoint.com/article/hierarchical-data-database/2/

ツリーデータを2次元の表で表現する方法はそれなりにあるが、親や子の繋がりを1クエリで取得できるという意味で、上記の「Modified Preorder Tree Traversal」は特に優れている。データを更新する際にはクエリの数が増えるものの、親子関係の取得の際には、それを補って余りある利点がある。

具体的な紹介は、3年前のふじもとさんのエントリに譲る。ここでは、その内容に補足する形で、1点だけメモを記しておく。

----

このアルゴリズムは、親子関係を一気に取得する縦の演算には非常に強力だが、同じ階層にあるノードを一気に取得しようと思うと弱い。つまり、横の演算をしようと思うと、親の数が等しいものをいちいち全ノードについて計算しなければならなくなる。

よって、別に親の数を格納したカラムを持つのが一番良いのだろうと思う。親の数は以下のクエリで全く問題なく計算できるので、それをUPDATE時またはINSERT時に格納してしまえばいい。

SELECT COUNT(*) FROM tree_table WHERE lid < xx AND rid > xx;


[memo] How to get Database Metadata by PHP

普段データベースのメタデータを取得する機会なぞあまりない。だが、ORMを弄るときは別だ。ユーザがそうしたものを全部プログラムに書いてくれれば不要なのだが、今時の怠惰なプログラマはそれらを自動生成または補完することを求めるからである。

ということで、ちょっと Creole と adodb の場合を調べたのでメモしておく。test というテーブルのメタデータを取得する流れを記してある。尚、エラー処理は省略してある。

----

1. adodb の場合

require_once 'adodb/adodb.inc.php';

$dsn = 'mysql://foo:bar@localhost/test';
$conn = NewADOConnection($dsn);

//  get ADOFieldObject
//  A field object is a class instance with (name, type, max_length) defined.
//  @see http://phplens.com/adodb/reference.functions.metacolumns.html
$columns = $conn->MetaColumns('test');
foreach ($columns as $column) {
   var_dump($column->name);
   var_dump($column->type);
   var_dump($column->max_length);
}

2. Creole の場合

require_once 'creole/Creole.php';

//   first get DatabaseInfo object.
$dsn = 'mysql://foo:bar@localhost/test';
$conn = Creole::getConnection($dsn);
$info = $conn->getDatabaseInfo();

$test_info = $info->getTable('test');     //  TableInfo object.
$test_columns = $test_info->getColumns(); //  ColumnInfo object.

//  finally get as you like.
//  @see http://creole.phpdb.org/docs/api/creole.metadata/ColumnInfo.html
foreach ($test_columns as $column) {
   var_dump($column->getName());
   var_dump($column->getNativeType());
}

SQL QUOTED IDENTIFIER

SQLのキーワード を含んだ識別子は、ANSI/ISO SQL規格によれば ダブルクォートで括ることになっているようだ（※）。ただ、その扱いは RDBMS によって様々である。これは ORM 等で、SQLを自動生成するプログラムを書く人にとっては割と問題になる。なぜなら、ユーザが識別子として何を書いてくるかわからないからである。

そのまとめとしては、PEAR::MDB2 での扱いが非常にわかりやすかったりするのだが、私が触れている主なRDBMS上での扱いを以下にメモしておく。基本的にダブルクォートが可搬性が高いわけだが、そのデフォルトは異なったりするので、やはり RDBMS を見てクォートする文字を変えるライブラリが存在している。

----

・MySQL - http://dev.mysql.com/doc/refman/5.1/ja/identifiers.html
デフォルトは「`」を使う。目立つわけだが、そんなエンジンでも ANSI SQLモードは用意されている

・SQLite - http://sqlite.org/lang_keywords.html
[] も区切り文字として許されている。Access や SQL Server への互換性のためのものだが、これも目立つ。

・Microsoft SQL Server - http://support.microsoft.com/kb/156501/ja
設定すれば強制クォートしてくれるモードが用意されている。

・PostgreSQL - http://www.postgresql.jp/document/current/html/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

え、Oracle がないって？ 俺普段触らないのでどなたか補足よろしく(´ー｀; )

----

※ ダブルクォートで括らねばならないとされる根拠は、ANSI/ISO SQL規格にある。SQL 92 で言えば、5.2 <token> and <separator> にある。そこでは、識別子 (regular identifier body) は SQL のキーワードであってはならない (shall not) とされている。delimited identifier(ダブルクォートで括られた識別子）についてはこの規定はない。ただ、その comparion rule は複雑過ぎたので読むのを止めた、、(´ー｀; )