カテゴリー: ソフトウェア

PostgreSQL を 8.3 に

Debian, ソフトウェア, , コメントを残す

バックエンドに PostgreSQL を使っているのは、自前のデータベースのほかに Trac と MediaWiki だ。バージョン 8.3 が出てから1ヵ月以上経つし、MediaWiki の 1.12.0rc1 で PostgreSQL 8.3 対応の文字が見えてきたのでそろそろ大丈夫だろうとバージョンアップしてみた。

debian の場合 pg_upgradecluster で簡単にデータの移行ができる……はずだったのだが一筋縄ではいかなかったのだった。きっと数ヵ月後には根本的に解決されていて役に立たない情報になるだろうが、記録しておく。

自前のデータベース

PostgreSQL の contrib に含まれている isn.sql[1]を利用している。この isn.sql も 8.2 と 8.3 で若干違っているようで、pg_dump したものを読み込ませてもうまくいかなかった。

しかたがないので、pg_dump したものを isn.sql 関連の定義前の部分、isn.sql による部分、その後の部分の3つに分け、前の部分を読み込ませた後、contrib の isn.sql を読み込ませ、それから後の部分を読み込ませることで、ようやくデータの移行ができた。

自前で書いていたフロントエンドは特に問題なしと思ったら、

互換性のない変更点
文字でない型 (日付型など) を自動的に text 型に変換しないようにしました。
今までは text 型入力を受けとる演算子や関数に文字でない値が渡されると、自動的に text 型にキャストしていました。 これからは text 型でないデータを渡したい場合には text 型への明示的なキャストが必要になります。
に引っかかるところが数ヵ所見つかった。演算子 ~ はテキスト型にしか使えないとのこと。暗黙のルールは使わないようにしているつもりでもうっかり使っているのものだなと思った。

Trac

データの移行はすんなりとできた。が、使ってみるとエラーが出る。上と同様、キャストに関わる問題のようだ。検索して、6416と6512の変更を加えて、うまく動くようになった。

MediaWiki

MediaWiki で使っている tsearch2 は PostgreSQL 8.2 では contrib だったのが 8.3 では本体に組み込まれた。と言っても関数名等の互換性を取るために 8.3 でも contrib の tsearch2.sql を読み込ませる必要がある。上述したのと同じように dump を分割してデータを移行した。

これで大丈夫と思ったら、記事を書き換えようとした際にエラーが出た。ts2_page_text() で tsvectorの引数の ‘default’ は存在しないというもの(すみません、メッセージを正確に記録していませんでした)。

maintenance/postgres/tables.sql の 当該関数の定義箇所を見てみると 

-- Tsearch2 2 stuff. Will fail if we don't have proper access to the tsearch2 tables
-- Note: if version 8.3 or higher, we remove the 'default' arg
とのコメントがある。1.12.0rc1 ではまだ対応されていないのだった。新しい版を見るとコメントがつけ加えられていて、patch-tsearch2funcs.sqlの存在を教えてくれた。これを適用して、問題なく動くようになった。

  1. 書籍コードの ISBN をひとつの変数型として扱うためのもの。↑

gdm でのシャットダウンの禁止

Debian, ソフトウェア, , コメントを残す

特に設定しないと gdm のグリーティング画面で、「アクション」から誰でもシャットダウンや再起動ができてしまう。これではコンソールの前を通りかかった人は誰でも実行できてしまうので困ったものだと思うのだが、GNOME の考え方なのだろう、以前からこれがデフォルトだ。

また、いったんログインすれば、メインメニュー「シャットダウン」の項目があり、一般ユーザーがシャットダウンできてしまう。意図的でなくてもメニューで「ログアウト」と隣合っているので、うっかり間違えてシャットダウンしてしまうことがある。別のユーザーがリモートからそのマシンを使っていると困ったことになる。

シャットダウンを禁止するには、GNOME 2.18 では、gdm の設定ファイル /etc/gdm/gdm.conf[1] の [deamon] セクションに 

[daemon]
HaltCommand=
RebootCommand=
と書き加えればよかった。シャットダウンと再起動用のコマンドに空を指定することで、自動的にグリーティング画面の「アクション」メニューから「シャットダウン」「再起動」の項目が消え、ログインした一般ユーザーのメインメニューからも「シャットダウン」が消えていた。

ところが、gdm 2.20 になると、グリーティング画面の「アクション」からは消えるが一般ユーザーのメインメニューには「シャットダウン」が出るようになってしまった[2]。

gdm の設定の [daemon] セクションを見ると、 AllowLogoutActions という項目が 2.20 から増えていた。これに空の値を指定する、つまり先ほどの2行に加えて 

AllowLogoutActions=
と書くことで、一般ユーザーのメインメニューから「シャットダウン」を消すことができた。

【2011年6月29日追記】 GNOME でのシャットダウンの禁止—最近の流儀 を書きました。

  1. gdm のマニュアルを見ると /etc/gdm/custom.conf という名前のようだが、Debian では古い名前 /etc/gdm/gdm.conf が使われ続けているようだ。↑
  2. ロックダウン・エディタ pessulus を使うことも考えたが、これで「ログアウトを無効にする」と「シャットダウン」も「ログアウト」も一緒にできなくなってしまう。これらを別々に設定することはできない。↑

ブラザーのレーザー複合機

ソフトウェア, コメントを残す
レーザープリンタのドラムが汚れて縦に黒線が入るようになってどうしようかなと思っていたところに Fax付電話機が故障したので、ここは複合機を買うことにした。 Postscript(互換)、Linux用のドライバが用意されているということでブラザーのレーザー複合機を購入した。

ほしい機能

Fax機能で、受信時は複合機のメモリに保持しておき(これは当然できる)、必要なときに PCからファイルとして見えると助かる[1]のだが、結局、紙に印刷するしかない。スキャナ機能ではデータをFTPでPCに送ることもできるのだから、Fax機能でも受信データを同じように送ることができてもよさそうなものだが、その機能はないらしい。

brpcfax

オンラインでマニュアルを読めばだいたいの設定はできたのだが、「PC-FAX 送信 CUPS Wrapper ドライバのインストール方法」はちょっと不親切だ。インストールまではできるが使い方がわかりにくい[2]。 そこで検索してみると英語版のInstalling a Brother Linux PC-FAX send driver into a CUPS based Linux Systemが見つかり、こちらの方がはるかにわかりやすい[3]。もっとも使用頻度の高いと思われる OpenOffice.org から直接印刷するようにFaxを送る方法が載っている。ここにかいつまんで訳すと[4]
  1. OpenOfficeの設定ユーティリティである spadmin を起動する。(注: このプログラムを探すには find / | grep spadmin )
  2. 「新しいプリンタ」ボタンをクリック
  3. 「Fax 機の設定」を選択して、「次へ」ボタンをクリック
  4. 「標準ドライバ」を選択して、「次へ」ボタンをクリック
  5. 次のコマンド行を入力[5]
    brpcfax -o fax-number=(PHONE)
    そして「次へ」ボタンをクリック
  6. Faxプリンタの名前を入力。例えば Brother fax
  7. 「完了」ボタンをクリック
OOo で作成した文書を送るには、「印刷」で上記で名づけたFaxプリンタ名を選択して「OK」すると、Fax番号を入れる小さなウィンドウが開くのでそれを入力して「OK」する。 英語版マニュアルにはこの下に Mozilla の場合の設定方法があるが、firefoxでは「PostScript/default」以外のプリンタでは印刷コマンド指定ができないようだ。
  1. Windows なら附属のソフトでできるらしい。↑
  2. さらに誤りもある。「ファクス送信を実行する」の章の最初のコマンド例「単一宛先にファクス送信する場合：」は dpkg -i brmfcfaxcups-1.0.0-1.i386.deb と書かれているが、いくらなんでもそんな訳はない。英語版を見れば brpcfax -o fax-number=0566-55-12345 psfile.ps である。↑
  3. 検索中に見つけたブログの記事も参考になる。↑
  4. 実はStarSuite 8 管理ガイドにほぼ同じ記述がある。↑
  5. StarSuite 8 管理ガイドやブログの記事によると (TMP)をつけたほうがよさそうだ。↑

MediaWikiのスタイルシート

ソフトウェア, , コメントを残す

編集の際、プレビューはするものの最後に保存するのを忘れてしまい、せっかくの編集が水泡に帰すことがしばしばある。そこでせめてプレビューのあいだは背景に色を着けて注意を促したい。

全ての外装に反映されるスタイルは MediaWiki:Common.css に書けばいいらしい。編集画面でプレビューは <div id=’wikiPreview’> となっているので、

div#wikiPreview {
background-color: #ACCAC1;
}

のように書いた。

第何何曜日

ことば, ソフトウェア, , 2件のコメント

日付を尋ねる場合に「何年何月何日」のようにあいだに別の語が挟まればいいのだが、「第何何曜日」というのは言いにくい[1]。次のような事情で「第何何曜日」を求める方法を検索したく、この単語でいいのだろうかと思ったが、やはり仕方ないのかこのまま書いてあるのがいくつか見つかった。ともあれ意味は通じるし、そもそも未知のところを「何」に置き換えればほぼそのまま表現できる日本語は強力だ。

さて、その事情というのは……うちの資源ゴミの収集日は「第 2, 4 月曜日」だ。うっかり忘れてしまうことがしばしばあるので、収集日 (の前日) に自分宛にメールを飛ばそうと考えた。cron では「第何何曜日」という指定はできないので、スクリプトのほうで判定する。せっかくだからメモしておく。

Y 年 m 月 d 日は、その月の第 i の w 曜日か

これは検索ですぐに見つかった。曜日は、PHP なら求める手段は用意されている。

$i = floor(($d+6)/7);
$w = date("w", strtotime($Y . $m . $d));

Y 年 m 月の第 i の w 曜日は、その月の d 日か

上の逆だから簡単だと思ったが、何度か試してみてようやく

$w1= date("w", strtotime($Y . $m . "01"));
$d = $i*7-6 + ($w+(7-$w1))%7;

とした。ここで $w1 は当該月の 1 日の曜日である。$d が当該月の最大日を越えない判定が必要かもしれないが、ゴミ収集日はたいていの場合 5 回目の曜日には設定されないので省略した。

【追記】5年半ものあいだをおいて、続きを書きました。

—

ところでこのために PHP マニュアルの日付・時刻関数を見ていたら、日の出時刻や日の入り時刻を返す関数というものまであるではないか[2]。

現代の都市生活者には日の出・日の入り時刻より、ゴミ収集日を返す関数のほうがありがたい。……と思ったら、この日の出・日の入り時刻関数は宗教上の必要から作られたらしい。別に農耕狩猟生活のためというわけではなかった。

  1. 「第何週の何曜日」というと誤解を招く。今月はたまたま 1 日 が日曜日だからいいとして、たとえば来月 (2007年5月) の「第 2 週の月曜日」は 7 日? 14日?↑
  2. 残念ながらここのサーバは PHP のバージョンが 4 なので、これらを使えない。↑

電子テキストの文字校正

ことば, ソフトウェア, , , コメントを残す

印刷を目的としない文章を、修正個所を判りやすく指示 (つまり「校正」) しながら遠くにいる人ととともに作っていくにはどうするか。メールでやりとりすることを念頭において考えていたことをまとめてここにメモしておく。

ごく短いプレーンテキスト

「2 段落めの最初の文、ふたつめの『ロボット』を『人間』に置換」という感じの、電話で口伝えするような、長たらしい指示。 ごく短い文書で校正個所が少ないときにはこれでも伝わるが、増えてくると嫌になる。

指示を受け取った側 (この文章では「著者」と呼ぶことにする) は、その指示にしたがって元の文書を書き換える。

改行が少ない文書

自然言語の単純なテキストファイルや HTML の文書など[1]。

校正の内容は、プレーンテキストなら文字種や大きさはないので、ほとんど削除・挿入のみ (置換は「削除して挿入」で表現できる) となる。

タグによる校正記号

<del> と <ins> で表現する。校正に関するコメントは著者と校正者で了解して <comm> にするとか、あるいは HTML の範囲内のタグを流用する。

ロボットは他の<del>ロボット<comm>これは「人間」のはず</comm></del><ins>人間</ins>に危害を加えてはならない．

HTML を知っている人には意味が通じやすい。しかし、人間に伝えるためのもので、実際に HTML のタグとして機能するわけではない[2]ので注意が必要である。エディタは HTML 対応のもので代用できるかもしれない。

校正の作業

校正者は対象ファイルにエディタで直接タグを書き込んでいく。置換の場合、<del> と <ins> が連続することになる。

ruby を使える環境なら Docdiff (単語あるいは文字単位の差分でとる) を利用する方法がある。docdiff.conf で 

tag_del_start           = <del>
tag_del_end             = </del>
tag_add_start           = <ins>
tag_add_end             = </ins>
tag_change_before_start = <del>
tag_change_before_end   = </del>
tag_change_after_start  = <ins>
tag_change_after_end    = </ins>
と設定しておく。

元ファイルを別に保存しておき、対象ファイルは校正後の形に書き換える。 

docdiff --format=user example.txt.orig example.txt
で校正記号入りテキストを作成する[3]。コメントには対応していないので、その後エディタで開いて書き込む。

著者の作業

校正記号入りテキストを受け取った著者は、エディタで <del> のタグで囲まれた部分 (もし校正者の指摘を受け入れられなければ <del> ではなく <ins> で囲まれた部分) や <comm> で囲まれた部分を削除する。さらに <ins> タグを (囲んでいる内容は残して) 削除する。

HTML 文書

HTML 文書の場合、上記の <del> や <ins> のタグを使う方法では校正記号が目立たない。また、タグ自体の校正をするときに特に混乱する。たとえば 

<ul>
  <li>ロボットは他の人間に危害を加えてはならない．</li>
<del></ol><comm>閉じタグが間違っています</comm></del><ins></ul></ins>
となってしまう。そもそも上記の方法で用いたタグは人間のためのもので、著者と校正者で了解できていれば何でもよく、<del> や <ins> でなければならないわけではない。

それを一般化した 真鵺道 Manued というものがある。もちろん HTML 以外のプレーンテキストにも使える。規則は少ないのですぐに覚えられる。たとえば上の例は 

<ul>
  <li>ロボットは他の人間に危害を加えてはならない．</li>
【</ol>／</ul>＃閉じタグが間違っています】
のように書くことができる[4]。

真鵺道 Manued の最大の特長は機械処理が可能という点である。Emacs (系) には manued.el がある。しかし残念ながらほかのエディタの対応は見かけない。

校正の作業

対象ファイルにエディタで校正記号を書き込んでいく。Emacs で manued.el を使えば楽である。

校正ファイルの先頭に、アプリケーション (Emacs の manued.el のみなのか) に対する修正記号定義コマンドと、人間に対する注意書 (著者と校正者がしっかり了解していればなくてもいい) を付ける。

defparentheses  [ ]
defdelete       /
defswap         |
defcomment      ;
defescape       ~
deforder        newer-last
defversion      0.9.5
校正記号は次のとおりです。
[α/β]          αをβに変更する
[/α]            αを挿入する (変更の特殊形)
[α/]            αを削除する (変更の特殊形)
[α|γ|β]       αγβをβγαに並べ換える
[α||β]         αβをβαに並べ換える(並べ換えの特殊形)
[;コメント]    校正に関するコメント

ruby を使える環境なら、Docdiff (単語あるいは文字単位の差分でとる) を利用する方法がある。

元ファイルを保存しておき、 

docdiff --format=manued example.txt.orig example.txt
とする。

真鵺道 Manued 自体は上述の定義コマンドで修正記号を変更できる。しかし Docdiff は真鵺道のデフォルトの修正記号 (上記のもの) に固定されていて自由に変更できない。また Docdiff はコメントには対応していないので、後でエディタで書き込んでいく。

著者の作業

もし著者が Emacs で manued.el を使えるなら、受け取った校正記号入りテキストで、個々の校正記号についてオリジナルか修正指示のどちらを選択するかを簡単な操作でできるし、校正記号を含まない元の文書または修正された文書の全体を取り出すことも簡単にできる。

もしそれを使えない場合は、前述のタグ表現の場合と同じように、いちいち校正個所を直していく。

改行を多く含む文書

もちろん適宜改行されているテキストに対しても上記の方法は適用できる。 そのほかに diff を使うことができる。元ファイルを保存しておき、 

diff -u example.txt.orig example.txt
とする。ディレクトリごとまとめて扱うこともできる。 プログラムのソースコードなどに向いている。よく改行されている HTML 文書や TeX の文書に使うこともできる。

校正コメントは使えない。

著者は diff ファイルを受け取ったら、patch で元ファイルに反映させることができる。

書き換えてしまう

ここまで「変更個所および変更内容をわかるように指示する」ことに留意して、ファイルを直接書き換えてしまう (オリジナルを残さずに) ことは考えなかった。

だんだん「校正」から逸れてきたが、履歴がきちんと残るのなら直接書き換えてしまうということも考えられる。メールでのやりとりではないが Wiki という手もある。しかし短い単なるテキストを扱うには大袈裟すぎる。それに校正段階では一般に公開しないのが普通で、そのためには認証のしくみをつけて、いちいちログインしてもらうようにしなければならない。いわゆる一般人にはそれだけでも敬遠される。

cvs, subversion などと適切なブラウザの組み合わせも、変更点がわかるので「校正」と言えなくもない。しかしこれもプログラマやそれと同じ程度にコンピュータに興味を持って向かい合える人以外にはなかなか受け入れてもらえないだろう。

朱を入れる

OpenOffice.org Writer, MS Word, PDF などの文書に「朱」を入れる。それぞれのデータを扱えるソフトを著者と校正者がそれぞれ所有していて、その「コメント機能」の類を使えることが前提となる。商用ソフトが必須となったり Linux では揃えられなかったりと障壁が大きい。

文字種や大きさ、レイアウトなどの校正は、ここで言う文字校正の範囲を越える。文字校正だけなら、テキストに変換して上記の方法を適用することも考えられる。

最後の手段は、紙にプリントして朱を入れる。もはや「電子テキスト」からも逸脱する。ついでなのでここにメモしておくが、「印刷校正記号 JIS Z 8208:2007」は 2007-01-20 改正になっている。これは有料となっているが、日本工業標準調査会のサイトで、JIS規格番号「Z8208」で検索すれば閲覧できる。

  1. HTML の地の文で適当に改行を入れると、たいてい微妙に空白がはいってレンダリングされる。英語などでは改行は単語間空白という取り扱いで問題ないのだが、日本語では格好悪いので 1段落のあいだ改行を入れないことが多い。pTeX はこのへんをうまくやってくれるので気にせず適当な文字数で改行をいれたほうがいい (エラーの際に行番号が表示されるので場所を特定しやすい)。↑
  2. 全体を <pre> で囲むだけでもブラウザでそれなりに見えるかもしれない。↑
  3. Docdiff には –format=html というオプションもある。変更点を HTML で美しく表示できるようにするものである。しかしその表示のためにたくさんのタグなどがはいるので、著者が校正結果を抽出するのにやや手間がかかる。↑
  4. defparentheses を【 】、defdelete を／、defcommentを＃と設定している場合。↑

subversion

ソフトウェア, , コメントを残す
ようやく CVSからsubversionに移行した。自分一人の環境だし、滅多にコードも書かないので何のために?というところだが、まあいろいろとファイルの管理などを。出遅れた分あちこちに情報があるので割とスムーズに移行できそうだ。 しかしいくつかの不満はある(使い手が慣れていないからかもしれないが)。ひとつは、パーミッションが保存されないこと。CVSでは作業スペースでパーミッションを変更しておいた状態で update しても(内容はupdateされても)パーミッションが変わることはなかった。subversionでは、いったんファイルを消してから新たに作ったかのように、元のパーミッション(その時点の umaskにしたがって)になってしまう。group の変更も元に戻ってしまう。webページのように、webサーバから見えるようにしてチェックしつつ作業をしている場面では面倒くさい。tarを使うときのようにパーミッションなどが保存されるといいのだが。 もうひとつの問題は日本語の文字化け。CVSより格段によくなっているけれども。 まず、ここの環境では /etc/environment で LANG=ja_JP.EUC-JP となっているしその中の自分の環境でも LANG=ja_JP.EUC-JP としている。普段使いのエディタ Emacs も (set-default-coding-systems ‘euc-japan) だ。そこで /var/lib/trac/(リポジトリ)/conf/trac.ini で 
  [trac]
  default_charset = euc-jp
とした。 ファイルの中身がeuc-jpなら何の問題もないのだが、だんだんutf-8のものも出てきた。するとTracで閲覧するときに化けてしまう。これは TracJaの説明にもあるように、
Subversion リポジトリに格納しているファイルのエンコードが、ファイルごとに違う場合、 Subversion 側で各ファイルの svn:mime-types 属性にcharset を正しく設定することで解消します (trac-0.8.2 以降):
で解決した。phpだからといって mime-typeを application/phpとするのはやりすぎで、閲覧することを考えると text/* にしておくのが吉。text/x-php としてみた。text/plain がもっとも無難だとは思うが。 Emacsでは[[psvn.elを使う。編集中に差分を見たいとき = (差分)とすると、euc-jpのバッファにutf-8を表示しようとして文字化けしてしまう。E (Ediff)だと化けずに表示できるので、こちらで見ることにしよう。