2006-07-04 (火)
■ スタイルシートについてお勉強
最近、スタイルシートについて勉強し始めた。 基本的な書き方くらいは知っているが、 テーブルを使ったレイアウトから脱却するために、 そこそこ使いこなせるようにしておこう、と思ったわけだ。
そして、結果として、どつぼにはまっている…。もうやだ (T_T)
ブラウザによってスタイルシートの解釈が異なる部分がある、 というのを聞いてはいたが、ここまで違うとは思わなかった。 Internet Explorer と Mozilla Firefox でプレビューしてみると、 はみだしたり、変なところにワープしたりで、 全然同じレイアウトになってくれない。
結局、試行錯誤しながら少しずつ直しているが、 世の中の Web デザイナーさんは、 こんな気の狂いそうな作業をしているんだろうか…？
2006-07-08 (土)
■ 幅固定のサイドバー
個人的な好みとして、ウェブページのレイアウトは、 左側に幅固定のサイドバーがあるのが好きだったりする。 スタイルシートについてのノウハウが、 それなりに身に付いてきたと思うので、 tDiary のデフォルトテーマのサイドバーを 幅固定に改造してみることにした。
…あっさりできた。簡単すぎ。 一応書いておくと、 スタイルシートを以下のような感じで書き換えればＯＫ。
div.main {
margin-left: 158px;
}
div.sidebar {
……
width: 150px;
……
}
しかし、サイドバーが上から下まで突き抜けているのが、 どうも気に食わない。 そもそも、色使いがもう少しクールな感じであって欲しい。 どこかで気に入ったデザインのテーマを探してきて、改造してみようか？
2006-07-09 (日)
■ ネガティブマージンを用いた幅固定のサイドバー
昨日 の続き。 今度は、ネガティブマージンのテクニックを使って、 default テーマのサイドバーを幅固定にしてみる。 まず、tDiary の設定メニューから、 ヘッダとフッタを以下のように設定する。
- ヘッダ
ヘッダの内容 <div class="main">
- フッタ
</div> <div class="sidebar"> サイドバーの内容 </div>
このとき生成される html は、以下のような構造になる。
<body> ヘッダの内容 <div class="main"> メインコンテンツ </div> <div class="sidebar"> サイドバーの内容 </div> <div class="footer"> フッタの内容 </div> </body>
次に、スタイルシートを以下のように書き換える。
div.day {
margin-left: 168px;
……
}
div.main {
width: 100%;
float: right;
margin-left: -160px;
}
div.sidebar {
width: 152px;
float: right;
background-color: #eef;
color: #000;
padding: 2px 2px 100% 2px;
border-style: solid;
border-color: #aaf;
border-width: 2px 2px 2px 0px;
}
div.footer {
width: 100%;
clear: right;
……
}
以上の変更で、サイドバーを幅固定にすることができた。
なんとなく要領がつかめたので、 この次は自分好みの tDiary テーマを改造して、 今のスタイルシートと差し替えることにしよう。
2006-07-14 (金)
■ 自作の tDiary テーマ
ここ数日、tDiary のテーマを少しずついじっていた。 まだ気になる部分はあるが、 とりあえずの体裁は整ったと思うので、 今までの default テーマと差し替えてみた。
artnouveau-blue というテーマの雰囲気が良かったので、 最初はそれをベースに作業し始めたのだが、 どうもスタイルシートの記述が、 default のテーマと比べてみると不十分っぽい。 結局、default のテーマをベースに作業をやり直した。
大体の手順としては、
- サイドバーが固定幅になるよう修正
- artnouveau-blue の配色や画像ファイルを借りてくる
- レイアウトを微調整
- 色を微調整
という感じか。 シンプルすぎる気もするが、 そのうちに写真とか画像を貼りつけることもあるだろうし、 まぁこんなものだろう。
2006-07-15 (土)
■ 長いディレクトリ名や URL を折り返す
tDiary の自作テーマ の不具合に気が付いた。 ブラウザの横幅を少しずつ狭めていくと、 あるところで突然、サイドバーが下に追いやられてしまう。 調べてみると、 表の中に書かれているディレクトリ名が、 折り返されずにつっかい棒のようになっていた。 これが原因のようだ。
そこで、以前 pre タグに対して行ったワードラップの設定を、 table タグにも追加してみた。 すると今度は、他の部分がつっかい棒になる。 要するに、ディレクトリ名とか URL のような英数字の羅列は、 折り返されないのが標準の設定らしい。
こうやって pre だの table だのといったタグに、 １つ１つ折り返しの設定をしていくのが面倒になってきたので、 以下のように、本文全体に対して折り返しの設定をしてみた。
body {
……
white-space: -moz-pre-wrap; /* Mozilla */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
white-space: pre-wrap; /* CSS3 */
line-break: strict; /* IE 5.5+ */
word-break: break-all;
word-wrap: break-word;
}
ところがこれだと、IE では上手くいくが、 Firefox で表示が激しく崩れてしまう。 ならば、IE 用の設定だけを body タグに書けばいいのでは？ と思い、以下のようにしてみた。
body {
……
line-break: strict; /* IE 5.5+ */
word-break: break-all;
word-wrap: break-word;
}
pre {
……
white-space: -moz-pre-wrap; /* Mozilla */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
white-space: pre-wrap; /* CSS3 */
}
これでＯＫ。 英単語がワードラップされなくなってしまうが、 レイアウトはだいぶ崩れにくくなった。
2006-07-16 (日)
■ 長いディレクトリ名や URL を折り返す (2)
Firefox で URL が折り返されないというのは、結構有名な話らしい。 検索してみたところ、 url_breaker という拡張をインストールすれば一応解決することが分かった。
ただし、できることなら、こういう使用者側の解決法でなく、 ページ作成者側でなんとかしたいところだ。 そういう解決策がないのかと探してみたところ、 こんなページを見つけた。
要するに、url_breaker を、Firefox の拡張としてでなく、 通常の JavaScript として使おうというもの。 さっそく、以下の手順で tDiary に組み込んでみた。
1. outsider reflex のページから、 url_breaker_plus.user.js をダウンロード。
2. url_breaker_plus.user.js を以下のように修正。
(function () {
if(navigator.appName == 'Netscape'){
……
}
})();
3. tDiary をインストールしたディレクトリの下に js ディレクトリを作成し、 そこに url_breaker_plus.user.js をコピー。
4. skel/footer.rhtml の </head> の直前か、 もしくはフッタの設定の最後の部分に、 以下の html を追加。
<script type="text/javascript" src="js/url_breaker_plus.user.js"></script>
やってみたところ、ほぼ期待通りに動作するが、 なぜか table の中身に対しては効果がなく中途半端な結果になる。 オリジナルの url_breaker の方で修正に取り掛かっているみたいなので、 しばらく保留かな？
2006-07-17 (月)
■ Convert_Cache 導入による高速化
キャッシュを利用して PukiWiki を高速化する、 Convert_Cache のバージョン 1.0.0 が出ていたので、 いい機会だと思い、手元の環境に導入してみた。 実運用はもう少し試してからにするつもりだが、 作業記録を こちら に書いておく。
途中でハマったのは、 デフォルトで type = all のモードに設定されているということ。 導入方法の説明に書かれていないので、最初見落としていたが、 type = body のモードで利用するためには、 convert_cache.ini.php というファイルの設定を変更する必要があった。
■ 昨日のカウンターがゼロになる
という現象が起きている気がしていたのだが、 http://pukiwiki.sourceforge.jp/dev/?BugTrack2%2F141 を見て原因と対処法が分かったので、 さっそく counter.inc.php を修正してみた。 しばらく様子を見てみる。
■ contentsx.inc.php の rewritemap.inc.php 対応パッチ
contentsx.inc.php と lsx.inc.php というプラグインを 最新バージョンにアップデートしたところ、 rewritemap.inc.php プラグイン が効かなくなってしまった。 contentsx.inc.php と lsx.inc.php の両方に、 make_link() という新しい関数が増えており、 それが原因のようだ。
ところが、よくよく見てみると、 lsx.inc.php の方の make_link() は、 定義はされているものの使われていないっぽい。 ということで、contentsx.inc.php にだけ以下のようなパッチをあてた。
--- plugin.orig/contentsx.inc.php 2006-07-03 04:02:00.000000000 +0900
+++ plugin/contentsx.inc.php 2006-07-17 19:42:28.000000000 +0900
@@ -246,7 +246,11 @@
$url = $anchor;
$title = '';
} else {
- $url = $script . '?' . rawurlencode($page). $anchor;
+ if (exist_plugin('rewritemap')) {
+ $url = plugin_rewritemap_url($page) . $anchor;
+ } else {
+ $url = $script . '?' . rawurlencode($page). $anchor;
+ }
$title = htmlspecialchars($page);
}
$text = htmlspecialchars($alias);
これで、正常動作するようになった。
2006-07-20 (木)
■ Convert_Cache へのプラグインの登録
自分が使っているプラグインで、 登録が必要そうなプラグインがいくつかあったので、 :config/Convert_Cache に以下の設定を追加した。
*plugin |ls2_1 |1_dir | #ls2_1([$page [,...]]) | |lsx |0_dir | #lsx([prefix=$page][,...]) |
最初、ここに contentsx.inc.php も登録しようと思ったが、 恐らくその必要はないだろうと判断した。
というのも、 自分の場合、#contentsx(page=〜) のようなページを指定した使い方は しておらず、#contentsx とだけ記述して使っている。
このような使い方に限定した場合、 見出しが変わる、というか #contentsx の出力結果が変わるのは、 そのページを書き換えた時しかありえない。 逆に、見出しを書き換えたような時には、 Convert_Cache のキャッシュも必ず更新される。 だから、特に設定などしなくても、不整合は生じないだろうというわけだ。
そもそも設定の仕方とか意味をあまり理解できていない、というのもあるが、 上の設定だけを追加して試してみたところ、 問題なく動作しているようだ。
2006-07-22 (土)
■ Convert_Cache 導入時の contentsx.inc.php のキャッシュ
Convert_Cache の作成するページキャッシュを覗いてみたところ、 contentsx.inc.php が出力する目次そのものも書き込まれていた。 で、先日書いたように、 Convert_Cache がキャッシュを更新するのと、 contentsx.inc.php がキャッシュを更新するのは、 同じタイミングで行われると思ってよい。 ということは、もしかすると contentsx.inc.php の設定は、 常に cache=off で良いのでは？
試してみたところ、cache=on でも cache=off でも問題なく動く。 ただ、オプションを設定しても、結局ページ更新時にしか意味が無いので、 はっきり言ってどちらでも良いのかもしれない。 でも、厳密に考えるとどちらにすべきなんだろう？ ちょっと調べてみるか。
2006-07-23 (日)
■ Convert_Cache 導入時の contentsx.inc.php のキャッシュ (2)
昨日の件 について詳しく調べてみた。
まず Convert_Cache の動作について調べたこと。
- ページキャッシュには、目次の html も丸ごと保存されている。
- ページを更新すると、そのページや関連するページ（親ページなど？）のキャッシュは一旦削除される。
- ページにアクセスがあった時に、キャッシュが無ければ新たに作成される。
次に、contentsx.inc.php の動作について調べたこと。
- 目次更新のチェックは、ページ更新時には行っておらず、目次を表示する際にタイムスタンプを毎回チェックすることで行っている。
- wiki ディレクトリのファイルの方が、目次のキャッシュのファイルより新しければ、目次のキャッシュを更新する。
以上のことから、Convert_Cache と contentsx.inc.php を併用する場合、 キャッシュの更新は以下のような流れで行われると考えればよい。
- ページ更新時
- wiki ディレクトリのファイルの更新
- ページのキャッシュの削除
- ページ更新後、最初にアクセスがあった時
- テキストから html への変換
- （その途中で）目次のキャッシュの更新
- ページのキャッシュの更新
これだけだと、contentsx.inc.php はページ更新直後にしか呼ばれず、 cache=on に設定しても cache=off に設定しても大差なさそうに見える。 そこで、 lsx.inc.php が絡む以下のような状況を考えてみる。
- 子ページ …… #contentsx で目次を表示
- 親ページ …… #lsx(contents=(〜)) で子ページの目次を表示
各ページの更新時には、 目次の作成に関して以下のような処理が行われる。
| cache=off の場合 | cache=on の場合 | |
| 子ページ更新時 | 目次作成 | cache/〜.contentsx を更新して目次作成 |
| 親ページ更新時 | 子ページ全体を読んで目次作成 | 子ページの cache/〜.contentsx を利用して目次作成 |
この表から分かるように、cache=on だと、 cache/〜.contentsx を作成する分の手間とディスク容量が必要になるが、 lsx.inc.php が目次を表示する際の負荷を軽減できることになる。
ということで、親ページを頻繁に更新する場合や、 一部のページでページキャッシュを無効にする場合を考えると、 contentsx.inc.php の設定を cache=on にしておいても無駄ではないかな、 というところだろう。
2006-07-24 (月)
■ RSS を index.rdf という名前で配信
前から気になっていたのでやってみた。 変更箇所は以下の３点。
- .htaccess に以下の設定を追加
RewriteEngine On RewriteRule ^index\.rdf$ index.php?plugin=rss&ver=1.0 [L]
- lib/html.php の $_LINK['rss10'] の設定を以下のように変更。ただし $script_directory_index = 'index.php'; と設定してあることが前提。
$_LINK['rss10'] = $script . 'index.rdf';
- skin/pukiwiki.skin.php の <link rel="alternate"... /> の行を以下のように変更
<link rel="alternate" type="application/rss+xml" title="RSS" href="<?php echo $link['rss10'] ?>" />
作業中に気付いたが、 ツールバーの RSS アイコンのリンク先は RSS 1.0 なのに、 link rel="alternate"... のタグでは RSS 0.91 を指定しているのか。 変なの。
2006-07-25 (火)
■ 玄箱/HG を購入
Amazon.co.jp で 玄箱/HG が安かったので、購入してしまった。 税込み \15,089 で送料無料で \1,500 円分還元なので、 他の店と比べてもかなり安いと思う。 あと、玄箱に入れるために、 WD3200JB という 320GB のハードディスクも別の店で購入した。 \10,550 ＋ 送料 \420 なり。
実は、玄箱はこれが２台目だったりする。 でも、今まではデータをいろいろと保存してあって、 下手にいじることができなかったので、 これでようやくいろいろと試すことが出来る。
しかし、前回、環境構築したときのメモはあるんだが、 試行錯誤の過程がそのまま書いてあって、 なんだかよく分からないんだよな。 これもきちんと Wiki にまとめ直すか。
2006-07-26 (水)
■ now? の変換を無効にする
玄箱のインストール作業記録を PukiWiki 上で書いていたところ、 文章中にこんな表示が突如現れた。
Do you want to upgrade glibc 2006-07-26 (水) 22:06:58 [Y/n]
なんだこれは？ こんな日付を書いた覚えはないぞ？ FormattingRules のページを読んでみると、 PukiWiki 1.3 時代のなごりで、 now? と書くと更新時の日時に変換されるようになっているらしい。 なんて迷惑な…。
こんな機能ははっきり言って邪魔なので、 rules.ini.php の $str_rules にある以下の行をコメントアウトした。
'now\?' => format_date(UTIME), 'date\?' => get_date($date_format), 'time\?' => get_date($time_format),
これで安心して英文が書ける。
2006-07-27 (木)
■ Convert_Cache 導入時の &_now; 表記
昨日の作業中に気が付いたが、 now? と書いて変換された部分の日時が、リロードしても変わらない。 そうか、こういうのも Convert_Cache に登録してやらないといけないのかも。
調べてみると、now? はページ更新時の日時に置換されるので、 毎回表示が変わるはず、というのは勘違いだった。 しかし、&_now; と書くとページ表示時の日時に置換されるらしいので、 試してみたが、案の定、リロードしても同じ日時が表示される。 :config/Convert_Cache ページに、
|_now |0_every | &_now |
のように設定してみたが、やはりダメ。 そもそも Convert_Cache のソースを見ると、 ＆で始まるプラグイン用の設定をここに書いても意味が無いっぽい。 どうもこれは、設定次第でどうにかなる問題ではなさそうだ。
でも、どうせこんな表記は今後使いそうにないし、 そういう毎回出力が変わるようなことをやりたければ、 JavaScript でも使えばいいのだろう。
2006-07-28 (金)
■ タグクラウドを表示させる
カテゴリ別のページへのリンクをサイドバーに並べようと思ったが、 せっかくなので、 最近よく見かけるタグクラウドの形式で表示させることにした。 行った手順は以下の通り。
- SmallStyle さんの category プラグインを利用した タグクラウド 表示プラグイン のページから category_to_tagcloud.txt をダウンロードし、category_to_tagcloud.rb にリネームして misc/plugin ディレクトリにコピー。
- html_category.rb というプラグインを使っているので、それに対応させるために、category_to_tagcloud.rb を少し書き換え。
- RubyでTagCloud (tagcloud-ruby) に載っているコードを tagcloud.rb として保存し、tDiary の index.rb と同じディレクトリにコピー。
- tDiary のプラグイン選択で category.rb と category_to_tagcloud.rb を追加。
- tDiary のヘッダ、フッタの設定を利用して、サイドバーの箇所などに以下のような html を追加。
<h5>カテゴリ</h5> <%=tag_list%>
これでタグクラウドが表示できた。
2006-07-29 (土)
■ 玄箱に Debian をインストール
とりあえず、これまでに行った作業を Wiki の方にまとめた。
しかし、ここまでの作業をやってみて思ったが、 Genbako kernel collection さんが配布している、 sarge 化＆カーネル 2.6 化した Debian 化キットのおかげで、 インストール作業は昔に比べて本当に楽になった。 ありがたいことだ。
2006-07-30 (日)
■ 玄箱のセキュリティ対策
Wiki に以下の作業記録を追加した。
今のところ、パッケージをアップデートしましょうとか、 TELNET はやめて SSH を使いましょう、くらいのことしか書いていないが、 何か書くのを忘れている気がするので、 思い出した時にまた内容を追加することにしよう。
■ Windows 2000 インストール時の BigDrive 対応
SP+メーカー のバージョン 0.63.0 が先日リリースされたが、 バージョンアップ内容の中に、なにげにすごい機能が１つある。
Windows 2000 の[高度な設定]の[Windows 2000インストール直後からBigDrive(137GB超えのHDD)に 対応する]を[BigDrive(137GB超えのHDD)に対応する]へ名称変更し、機能としては、 インストール時点でのBigDriveに対応できるようになった
今まではほぼ不可能とされていたことなので、 この機能にはちょっと感動した。 Windows 2000 は Service Pack 4 まであてた CD を作ってあるが、 CD を作り直そうかと思うくらいの機能だ。
ただ、冷静に考えてみると、 この機能が必要となる状況はあまりないかもしれない。 というのも、バックアップやデフラグの手間を考えて、 システム用のパーティションは 10GB くらいで作って、 データ用の大容量パーティションを別に作るようにしているからだ。
でも、Windows 2000 のこういう妙な制限が回避できるようになったのは、 本当にすばらしいことだと思う。
2006-07-31 (月)
■ 玄箱の時計の精度を改善する
玄箱の時計はかなり不正確で、下手すると１日に10分くらいずれたりする。 こんなにも不正確なのは、以下の２つが原因らしい。
- クロックの周波数が設計値から約 0.75% ずれている
- カーネルで変な補正処理をしていて、起動するごとにクロックの周波数が変動する
これを直すためには adjtimex というコマンドを使うのだが、 以前のメモを見ながらその作業をしようとして、ふと手が止まった。 そういえば、 Genbako kernel collection さんが配布しているカーネルは、 この件に関する修正パッチが適用されていたような気が。 ということで、起動時のログを見て確認。
kuro-box:~# dmesg | grep "decrementer frequency" decrementer frequency = 32.522240 MHz
やっぱりそうだ。周波数が 32.522240 MHz に固定されている。 それなら別に adjtimex コマンドを使わなくても、 時計は十分に正確になっているのでは？ そう思い、１時間で時計がどのくらいずれるか計測してみた。
kuro-box:~# ntpdate -b ntp1.jst.mfeed.ad.jp; sleep 3600; ntpdate -b ntp1.jst.mfeed.ad.jp 31 Jul 21:48:38 ntpdate[981]: step time server 210.173.160.27 offset -0.019737 sec 31 Jul 22:48:39 ntpdate[995]: step time server 210.173.160.27 offset 0.057847 sec
１時間で 0.057847 秒のズレということは、24 時間でのズレは 1.4 秒くらい。 カーネルの入れ替え をするだけで時計がこんなに正確になるのか。すごいな。
