memo-space

あーこれおもしろそう。ブラウザを自動で動かすweb application自動テストツール。

Selenium

Selenium ver.0.5 勝手にまとめサイト

斜め後ろの人間として色々調べる。色々わかったけどまとめてる暇ねー！

とりあえず2種類の現象がおこっている。全角マイナスについてはUnicodeのマッピングの問題なのでEUCJP-winで回避できそう。

でも"Ω"とかそのたもろもろ、他にもマズいのがある。これは http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txtのA(Ambiguous)を半角とみなしているからだと思う。

http://www.unicode.org/reports/tr11/によると、East Asian legacy character encodingsではAは全角、non East Asianでは半角とすることを推奨しているらしい。

む。早くもツッコまれてるけど見なかったことにして書こう。

最近マインドマップというのが流行しているらしい。僕はマインドマップについては1冊も本などを読んだことが無いので詳しくはないが、書店にいくとその盛り上がりっぷりに驚く。

あれはさすがに加熱しすぎだろうと思うんだけど、マインドマップ自体は嫌いではない。パっと見で良いなと思ったところは、枝に沿って文字を書き込むところ(そうとも限らないんだろうけど)。そうではなくて丸とか四角の中に文字を書き込んでそれを枝で繋げるようなものだったら、あんまり良い印象を受けなかったと思う。単に書きづらいからだ。。

僕はフロチャートが嫌いだ。あれが本当にダメだと思うところは、条件分岐の菱形だ。文字が書きづらいったらありゃしない。フロチャートを書くという目的以外で菱形の中の文章を書いたことのある人なんてそういないと思う。まあ僕が定規を使っても真っ直ぐ線が引けないほど人一倍不器用なせいもあるんだけど。

マインドマップについてもう少し書くと、僕は二十年間ほどずっとノートは罫線に沿って使ってきた。マインドマップが僕にもたらしたインパクトは罫線からの開放だ。マインドマップという言葉が無ければ、ノートにあんなもん書いてたら恥かしくて人に見せられない。

まあ逆にいえばその程度のインパクトだということだけれども。きちんと本を読めばぐんぐん頭がよくなるのかもしれませんが。

まだ続くつもり。

今年を振り返るわけじゃないが、最近僕の心に響いた言葉。

きしださんのフィジカルの話はおもしろかったしもっと流行ってほしい言葉だ。

平鍋さんのEoM = EoT + EoCも刺激的だった。

ここでひとつ、僕も最近心の中で大切にしているひとつの言葉を紹介したい。それは「記法」だ。Rubyのまつもとさんの「名前重要」をパクらせてもらえば「記法重要」ということだ。ここでいう記法とは、ソースコードのことでもあり、UMLやマインドマップのようなもののことでもある。

しかしこのことをこの時間から説明する根性はなくなりつつある。また機会を見て続きを書きたい。

しかし楽譜ってすごいな。楽譜の歴史はよく知らないけど、表現する為の記法として何百年も使われているなんて。

数カ月前、眼科で右目が白内障だと診断された。そのころからボヤけている感じはあったが今はもっと見えなくなっている気がする。元々視力は良く今でもおそらく左目は1.0以上あるので普段の生活には支障はないのだが。近くの細かいものに対して右目は全く形を認識できないので、焦点を合わせることができない。ちょっと前まで右目でファインダーを覗いてピントを合わせていたのが信じられないなぁ。

自分がアトピー性皮膚炎だと知った時も思ったが、人一倍自分の体に無頓着な人間にとってはなんともやっかいな話だ。逆に言えば自分を大切にしないことに対してバチがあたったのかもしれない。

というわけで、今の右目の状況をgimpで再現してみました。

こうなるはずが posted from フォト蔵

こうなってるんです posted from フォト蔵

中国で見かけたアバウトな英語(@nifty Daily Portal Z)

英語もコレかよ!!懐が深いというか。さすがは富士エアーの国。

東京でのPHP勉強会の時にS2Daoの話を聞いて、あのSQLの中にパラメータ埋め込んだりif文埋め込めるのはいいなぁと思った。Daoはともかくアレだけでもやりたい。

あれはいわばSQLのテンプレートだ、ということはSmartyでもいいじゃん。(と考えた人は過去にもいたと思う)。つまり、

phpファイル
  $smarty->assign('user_id', $_GET['user_id']);
  $sql = $smarty->fetch("user_sql.tpl");
  $res = pg_query($conn, $sql);
  ...

user_sql.tpl
  SELECT * FROM user_table WHERE user_id = {$user_id|sqlq}

という感じだ。SQLのリテラルのクォートは修正子プラグインでも作ってやればよいだろう。

でもせっかくこれが出来るのなら、いちいちfetch()してからpg_query()するよりもSmartyクラスを継承して、

  $smarty = new SmartyDB;
  ...
  $smarty->assign('user_id', $_GET['user_id']);
  $smarty->query('user_sql.tpl');

みたいなほうがよさそうだ。ついでにクエリ結果をそのままSmarty変数にassignするメソッドがあっても良い。

  $smarty->assign('user_id', $_GET['user_id']);
  $smarty->assign_allresult('user_tbl', 'user_sql.tpl');
  $smarty->display('user_view.tpl);  /* そのまま display しちゃう */

もっと言うなら、ついでにクエリの結果をキャッシュできたりしないかな。

ssh が終了時に固まって(ハングして)しまう。

最近コレを連発していた。入力もリダイレクトしてやればいいのか。

空行（改行のみの行）はヒストリに保存されないので、空行を.psql_historyファイル内のセパレータにしてやることにした。

バックスラッシュコマンドも適当に解決。まずまず使えそうだ。

psql_addhistory_051016.patch

psqlのヒストリ機能が使いづらい。ずっと前から思っていた。僕はわりとSQLに改行をいれて打つことが多い。

ishida=# SELECT *
ishida-#   FROM pg_class
ishida-#  WHERE relname = 'tbl1';

でも、psqlのヒストリ機能は行単位なので、これを実行した後にCtrl-Pを押すと、"WHERE relname = 'tbl1';"の一行だけが出てくる。3行全部出てきてくれた方がうれしいんだけど。

で、ちょろっといじってみた。つーか適当なパッチのつもりがだんだん色々な問題が発生してきてどうしたものか。バックスラッシュコマンドはどうしようかなぁ。まあでも使える感じ。

あと、一旦psqlを終了しちゃうと、前回の履歴(.psql_historyファイルに保存されたもの）はやっぱり行単位でしか履歴を呼びだせない。うーん。改行をエスケープして保存して、read_history()を使わずに自分でファイルを読みながらadd_history()していけばできなくはないなぁ。

psql_addhistory_051015.patch

調べてみるとどうやら、alter table drop columnで削除されたカラムがあるとコケる模様。この時 pg_attribute は、

ishida=# create table t1 (i1 int, i2 int);
CREATE TABLE
ishida=# alter table t1 drop column i2;
ALTER TABLE
ishida=#  select attname, attisdropped from pg_attribute
 where attnum > 0 and attrelid = 
(select oid from pg_class where relname = 't1');
           attname            | attisdropped 
------------------------------+--------------
 i1                           | f
 ........pg.dropped.2........ | t
(2 rows)

こんな感じでゴミが残ってる状態になってるんだけど、その attname を拾ってしまっているようだ 。

これはもう全力でバグレポートを書きにいったら、既知の現象だったらしい。一週間前に報告されたのカヨ。

error copying dropped columns

COBOLはプログラミングを学ぶのに適した言語だそうです。 以前、どこぞでも話たけど、COBOLの入門サイト。

ひよこグミ

僕なんかは、大ざっぱにいうと BASIC -> C-> Java みたいなわりとマトモな言語遍歴を経ているわけですが、ここでは まずCOBOL、次にPython というかなりかわった順番で言語を修得していく過程が描かれています。

メモメモ。しかしどういう仕組みになってるのか全然わかんないよー。

CREATE TEMP SEQUENCE sl_table_seq;
SELECT 'set add table ( set id = 1, origin = 1, id = ' ||
       nextval('sl_table_seq') ||
       ',\n   fully qualified name = ' ||
       quote_literal(n.nspname || '.' || r.relname) ||
       ', comment = ' ||
       quote_literal(COALESCE(d.description, '')) ||
       ')'
  FROM pg_class r
       LEFT JOIN pg_description d ON (r.oid = d.objoid)
     , pg_namespace n
 WHERE r.relnamespace = n.oid
   AND r.relkind = 'r'
   AND n.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast');
DROP SEQUENCE sl_table_seq;

メモ。だいだいこんなもんだろ。

SELECT n.nspname
     , r.relname
  FROM pg_class r
     , pg_namespace n
 WHERE r.relnamespace = n.oid
   AND r.relkind = 'r'
   AND n.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
   AND NOT EXISTS
      (SELECT * FROM pg_constraint c
              WHERE c.conrelid = r.oid
                AND c.contype = 'p')

ちょいと前の話しですが、8.0.4がリリースされてますね。

http://blog.postgresql.jp/58 7.3.11、7.4.9、8.0.4リリース(JPUG広報担当blog)

修正内容には、あの「PostgreSQL徹底入門〜8対応〜」の著者としても有名なYoshiyuki Asabaさんのお名前もありますね(こっそり宣伝)。

     * Fix CHAR() to properly pad spaces to the specified length when
       using a multiple-byte character set (Yoshiyuki Asaba)
       In prior releases, the padding of CHAR() was incorrect because it
       only padded to the specified number of bytes without considering
       how many characters were stored.

これのことかな。 [pgsql-patches] character type value is not padded with spaces。

あ、このバグ見たことある。っていうか俺が放り投げてたやつじゃん。 [pgsql-jp: 34751] Re: charのlength について。へぇー。そんなところに問題があったんだ。てっきり bpcharin あたりがおかしいのかと思ってた。

勢いでこんなものを作ってみました。

http://www.mono-space.net/ys/wiki.cgi

HTML Slidy http://www.w3.org/Talks/Tools/Slidy/ は、HTMLでプレゼンっぽいものを作るツールです。で、これとYukiWikiを合体させてみました。

めんみって北海道限定だったの！？

http://unlimi.net/archives/50318587.html

http://ex13.2ch.net/test/read.cgi/gline/1128380614/

http://d.hatena.ne.jp/a_ogawa/

PostgreSQLによくパッチをポストしているa_ogawaさんのはてなダイアリー。凄すぎ。

なんつーか。自分ももっとがんばらなきゃダメだな。

一冊じゃ足りなかったそうです（違

こういう風にフォト蔵を使ってみるテスト。