Photo Friday “Building”
- 2011年6月23日
- カテゴリ: イベント
- タグ: Photo Friday
iwaimの行動記録など
WordPressの各エントリーに作成者の情報を載せるための方法を探していたら、WP About Authorプラグインというプラグインがリリースされていることに気づきました。このWP About Authorプラグインを用いることで、各エントリーに作者のプロフィールをとても簡単に表示することができます。
デフォルトの設定で使うだけであれば、プラグインを有効にすれば各エントリーに作成者のプロフィールが表示されます。作成者の画像については、Gravatarが使われますので、Gravatar の使い方などの説明を読んで設定しておくと良いと思います。設定は「プラグイン」から「WP About Author」を選べばどのような場所に出すのかなどの設定を行うことができます。設定項目は大きく別けて「どのような条件で表示するのか」と「どのような形で表示するのか」の2つがあります。日本語での情報が見つからなかったので、以下に簡単に書いておきます。
どのような条件で表示するのかは「Display Settings」で設定します。以下の設定項目があります。
なんか特に説明が不要な気がします。個人のウェブサイトであれば「Display On Individual Posts / 個別の投稿に表示」だけを有効にするだけでいいような気はしますね。「Display In Search Results/ 検索結果に表示」は私が検証したときはちゃんと動いていなかった気もしますが、デフォルトのテーマなどでは試していないのでよくわかりません。個人的にはいらないので暇だったら調査するぐらいかなー。
どのような形で表示するのかは「Box Settings」で設定します。簡単な設定しかできません。「Box Background Color / ボックスの背景色」ではプロフィールを表示する領域の背景色を設定します。テーマにあわせた適当な色を指定すると良いでしょう。「Box Border / ボックスの縁取り」はプロフィールを表示する領域の縁取りを設定します。「Thick Top Border / 上部に太めの縁取り」「Thin Surrounding Border / 細めの縁取りで囲む」「No Border / 縁取りなし」の3つだけしか設定がありません。まあ、プラグインとしてはこれぐらいに留めておいた方が煩雑になりすぎないので良いのではないかと思います。多少ならばCSSを書き換えれば良いのかもしれないですね。それ以上自分好みにするならばこのプラグインをベースに手を入れるか、テーマ自体にハードコーディングしてしまうか、でしょうか。
設定画面はともかく、表示される部分に「More Posts」などとでてしまうので何とかしたいところです。Gettextizeされていないので、せっかくだからGettextizeしようかと思ったのですが、ちょっと時間を割いただけでは残念ながらできませんでした。設定画面側のコードにはGettextizeしようとする意思も感じられたにも関わらず、2011年6月8日現在の最新版のバージョン1.1では実現できていないので何かはまりどころがあるのかもしれません。時間のあるときにでもみてみようということで、とりあえず日本語化だけしておきました。単に日本語を埋め込んだだけです。必要な方は以下のURLからどうぞ。ライセンスはWP About AuthorがGNU GPL version 2なので同じライセンスになっています。
本家のものが国際化されるまでの暫定のつもりなので、わざわざどこかに置く場所を確保するのは面倒ということでDropboxに投げ込んだだけです。たぶん本家が国際化されるまではそのままですが、本家が国際化されたら削除してしまうかもしれません。
OpenStreetMap Japanが東北地方太平洋沖地震の情報を集約するためのウェブサイト「sinsai.info」を稼働しはじめました。地図/位置情報とその場所に関係する情報を集約し、災害の被害をできるだけ食い止めようという試みの一つです。
少し触ってみた経験を基に、レポートを書くときに心がけた方がよさそうなことをメモしておきます。参考になれば幸いです。
緊急時ではありますが、だからこそできるだけ落ち着いてください。
災害に関する情報は日本人だけではなく、あらゆる国籍の方が必要としています。簡単な日本語を使うことで、日本語に不慣れな人にも有意義な情報となり得ます。例えば、阪神大震災のときも、避難所案内の簡単な日本語ポスターが大変役だったという情報もあります。
救助要請のレポートの場合、レポートタイトルを「助けてください」というようなものにするのではなく「助けてください（宮城県○×市△町）」などの位置情報を入れる方が望ましいです。
外部のウェブサイトのURLをアナウンスするレポートも必要ですが、「ニュースソース」にURLが書けるからといって「説明」にURLを書かないということはやめた方がいいです。「説明」だけでURLも判るようにしてください。また、できるだけ詳しく書いた方が閲覧者にとって有意義となるでしょう。
WordPress用のプラグインMy Link Orderは、標準では並び替えることのできない「リンク」を自分の好きな順に並べることができるようになるとても有用なプラグインです。しかしながら、プラグイン自体に日本語リソースが入っていないため、そのままでは設定画面などが日本語ではなく英語になってしまいます。現在の最新版であるMy Link Order 2.9.1を対象に日本語翻訳を実施したので、その翻訳結果の反映方法をまとめておきます。
日本語翻訳の結果自体は既に開発者のfroman118さんに送付済みであり、次のリリースで同梱していただける予定になっていますので、My Link Order 2.9.1よりも後のバージョンではプラグインをインストールするだけで設定画面などが日本語で表示されることになるでしょう。このエントリは（なかなか次のバージョンがリリースされないようなので）次のバージョンがリリースされるまでの継ぎとして書いておきます。
手順は次の通り。
これだけです。とても簡単ですね。
Shibuya.tracの分散バージョン管理勉強会に参加してきた。1時間ほど遅刻で。事前に言われていた場所が判りづらい問題は住所メモって、道端にある地図をみれば問題なかった。ちゃんと地図印刷していったら迷わないんちゃうかなー。
到着したら「GitとHudsonによるきれいなリポジトリの作り方」が丁度終わるところだった。これも聞きたかったけど仕方ない。参加した人のブログエントリみていると、CIなツールいれて、1回テストしてから通ったものだけを中央のリポジトリにいれる感じかな。これだと中央リポジトリのコードはきれい（なはず）になるというやつか。今、いくつかのプロジェクトでは手元にHudson入れてpush前に一応ビルドが走るようにしているんだけども、それをもっとエレガントにした感じなんだろうなー。スライド公開を待とう。Oかもとさんの「Shibuya.trac 分散バージョン管理勉強会に参加しました。」によれば、BazaarのPQMが使えそうということなので時間あるときに調べてみよう。
Oかもとさんの話あたりで会場アンケートとって、BazaarユーザはLTスピーカーのiwataさんだけだったのかな。最近コミット権もらったプロジェクトがBazaarなので使い始めてたんだけども遅刻したから数に入ってない。まあ、使い始めたばかりだけども。
Mercurialはしばらく手を出す暇なさそうなので……。
歴史改変は、試行錯誤な手元の更新をpush前にやるとよかったりするのだろうか。分散型リポジトリでの運用のデファクトスタンダードがよくわからん。なんか適当な書籍買った方がいいんかなあ。bzr pullできなかったときにbzr mergeやったときのコミットログってどんなのがいいの？とかそういうのとかもよくわからん。分散型リポジトリで共同開発やってみるためだけのプロジェクトを作ってみるかなー。
git bisectは便利そうだとは思った。1回使ってみよう。ただ、使いどころが難しいのではないかなあ、という気がしないでもない。単体テストとかでひっかかるものだとCI入れてたら良いだけという気もしたけども……。まあ、そういうので漏れたもの、そういうのでは検出できないものがあった場合に発生時点の調査には非常に強力なんだろうな。チェックのためのコードが書ける場合は人間が見るんじゃなくて機械に任せるべきだろうしね。
Hudson勉強会は参加したい。
MantisBTで作成したユーザの情報を使ってBasic認証の実現する方法。Apache HTTP Serverのモジュールmod_auth_mysqlを使えば問題なくできた。例えばWikiなどと連携するときに便利かもしれない。検証環境は次の通り。
MantisBTをみたところ、mantis_user_tableテーブルにユーザ名とパスワードを保持しており、ユーザ名は「username」フィールド、パスワードは「password」フィールドにMD5ハッシュ値で格納するのがデフォルトのよう。だから、それをmod_auth_mysql側の設定で参照させればいいだけ。例えば次のような設定となる。
AuthMySQLEnable On
AuthMySQLSocket /var/lib/mysql/mysql.sock
AuthMySQLHost localhost
AuthMySQLUser mantis
AuthMySQLPassword mantispw
AuthMySQLDB mantisdb
AuthMySQLUserTable mantis_user_table
AuthMySQLNameField username
AuthMySQLPasswordField password
AuthMySQLPwEncryption md5
AuthMySQLNoPasswd Off
AuthGroupFile /dev/null
AuthName "Auth"
AuthType Basic
require valid-user
設定項目の詳細はhttp://modauthmysql.sourceforge.net/CONFIGUREなどを参照のこと。
とりあえずこれでできることは確認したので、後はmod_auth_mysqlというプロダクト自体の信頼性や安定性などを調査しないとダメかなー。
HTML5は執筆時点でまだ勧告されていないので、まだまだ変わる可能性はあるんだけど書いておく。昨日(いつ)「ブログも更新しないし」とか言われたので。なお、本エントリで参照しているものはHTML5 A vocabulary and associated APIs for HTML and XHTML W3C Working Draft 25 August 2009です。一応Editor’s Draft 13 January 2010がでてて、それも確認したけど、該当部分に大きな変更はなかったし。
で、本題。SGMLアプリケーションであるHTML4は、SGML宣言で「OMITTAG YES」とされていたことから、タグの省略が可能となっている。例えばhead要素の終了タグとbody要素の開始タグを省略した次のようなHTML文書は仕様に適合している。
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>自明でないと省略できません</title>
<script type="text/javascript">
<!--謎のスクリプト-->
</script>
<p>本文なのですが。</p>
</body>
</html>
で、これがどのような理由で仕様に適合しているのかは結構ややこしい。理由はsatoshiiさんによるRe: SGML の省略タグ機構に詳しい。
ここでHTML5に話を移す。HTML5では、SGMLアプリケーションだったHTML4とは異なり、SGMLアプリケーションではないという道を選んだ。このことにより、HTML5では仕様自体にタグの省略についての取り決めも盛り込むことになった。W3C Working Draft 25 August 2009では9.1.2.4 Optional tagsの箇所である。
HTML5の仕様では、HTML4よりもタグの省略に関しては結構限定されてしまっているとも言えるが、省略可能な状況をすべて列挙しているため、とても解しやすくなっている。
最近、一部で話題となっているhttp://html5.us/のHTML文書は、執筆時点では次のようになっている。
<!DOCTYPE html>
<title>html5.us</title>
<style>pre{font-family:courier,monospace;font-size:48px;margin:5% auto;text-align:center;width:50%;}</style>
<pre><code><!doctype html></code></pre>
これは、先に例示したHTML4のコードと結構似ている構造だが、これが仕様に適合しているというのは、仕様を軽く読むだけで容易に理解可能となっている。
このような仕様になった議論は全然調べてないけど、列挙してしまうというのはかなり思い切った方針だと思うし、列挙しているそれぞれの条件についても読んでみると結構考えられているように思う。すごいなあ。
エントリ「まだ進行中だけどperldocjp関連の話をまとめるよ」に対してmattnさんからいただいたコメントに答えてみる。ただし、私見。
リポジトリの話で言うと、コンテンツは見られるべき場所においてこそコンテンツなんだと思うな。
正直、《リポジトリの話で言うと》という部分とその後の部分との関連はまったく解っていない。だから、コンテンツの見せ方についてのみ、私の考えを書いてみる。
まず、Japanized Perl Resources Project (以下、JPRP)というものがどの範囲を示すのかというのは明確な定義はこれまでもなされていないような気はしている。ただ、sourceforge.jpに作成されたプロジェクトと、それに先行して作成されたPerlドキュメント日本語訳MLぐらいがJPRPなのだろうと私は考えている。
Perlドキュメント日本語訳MLが発足したのは井上さんによる2002年5月17日の[perldocjp:0001] Perlドキュメント日本語訳ML発足である。翻訳物の見せ方については、同日に菅原さんから[perldocjp:0003]で問題提起されている。その後、2002年7月20日に宮川さんが[perldocjp:0214] perldoc.jpにて、http://perldoc.jpの試験稼動がアナウンスされ、今に至るという状況である。このhttp://perldoc.jpがJPRPの一部であるか否かについては、ドメイン取得やサーバの構築、維持管理などを踏まえても、JPRPメンバーでもある宮川さんや、その後、ドメインを委譲された大沢さんら個人の力で運営されているものと考えることが妥当であろう。関係者各位にはどれだけ感謝しても足りないぐらいだと思う。
しかし、このことによりJPRPは、プロジェクトとしてはPerlユーザに対して翻訳物を提供する手段を考えることはなくなったとも言える。もちろん、複数のウェブサイトで、同じものを提供する意味は乏しいのだから当たり前といえば当たり前の結果であろう。
今回、mattnさんからの《コンテンツは見られるべき場所においてこそコンテンツなんだと思うな》というコメントは、金田さんの[perldocjp:1121]の発言を受けて私が[perldocjp:1123]にて『Japanized Perl Resources Projectとしては構わないんじゃないでしょうか。perldoc.jpの人が構うかどうかは知らないけれども。でも、それは我々Japanized Perl Resources Projectが気にするところではない。』と発言したことへのコメントであると推察する。もちろん、http://perldoc.jpから参照されなくなった状態で、CVSリポジトリに格納していくだけの作業をやってもあまり意味はないということは理解できる。しかし、金田さんによる[perldocjp:1121]では《んじゃ特に問題ないですね。perldoc.jpが置き換わった時にはCVSリポジトリの内容とperldoc.jpの内容が食い違ってくると思いますがそれは構いませんか？》と問われているときに「いや、それはダメだ。食い違うようにすべきではないのでhttp://perldoc.jp側でなんとかしろ」というような発言はできないことは推察して欲しい。そして、[perldocjp:1123]では同時に『今後、Japanized Perl Resources Projectの成果物がperldoc.jpから参照されなくなった場合にどうするのかは我々Japanized Perl Resources Projectの課題なのでしょう』と発言しているように、仮にそのような状況になった場合は何らかの対処が必要であるという認識も持っている。
ま、私としてはhttp://perldoc.jpがJPRPのCVSリポジトリを見なくなる可能性は極めて低いというようには思っているけどね。しかし、まあ、以前よりJPRPとしてできることをいくつか考えているので、年内にでも何かを見せることができるレベルまで持って行きたいと思う。こう書いてしまうことでやらざるを得なくなるというメソッド。
あと、lestrratさんにPerldocJp-Webってのを書いていただいたので、これをとりあえずローカルで動かしてみることもやってみようかなー。
当事者の一人で、まだ終わってないけどざっとまとめるよ。Japanized Perl Resources Project即ちhttp://perldocjp.sourceforge.jpのプロジェクトという意味で「perldocjp」と表現している人と、http://perldoc.jpを指して「perldocjp」、そしてまたJapanized Perl Resources Projectという意味で「perldoc.jp」と表現されてしまっているケースがあるのでMLログを読むときは要注意だ！
以下、Japanized Perl Resources ProjectはJPRPと略す。
2009年12月8日21時 (UTC+9) ぐらいまでの流れ。細かい議論が知りたい人はログをどうぞ。
まず、金田さんの立ち位置が全然理解できていない。どういう立場で発言しているのかとかが。現在のhttp://perldoc.jpを置き換えるものを作ろうというドキュメントプロジェクトの立場なのか、それとも翻訳の仕組み自体を改革しようという立場なのか。
翻訳を実施しているプロジェクトであるJPRPのリポジトリのGit化については、正直言って翻訳プロジェクトで分散型リポジトリを採用するメリットが理解できていない。マスターとなるリポジトリのメンテナンスを継続的にできるだけの体制が作れるならばもしかしたらありなのかも知れないが、これまでのJPRPの状況を考えるとpushされてきてもpullされないままになりそうな可能性は十分に高い。それならば、まだ、集中型リポジトリでコミット権を持っていただく方がプロジェクトが回るだろうと判断。
フロントエンドをWiki化する案はまだまだ議論中なのだが、スパムやいたずらを排除できるだけの仕組みがかなり難しいのではなかろうか。手動で発行されたユーザIDからのみ受け付けるという仕組みを採用するのならば、今、Wiki化する場合に享受できると主張されているメリットはなくなってしまう。ま、引き続き議論なんだろうな。
JPRPのリポジトリがCVSなことについては、今の若い人なんかはCVSなんかは使ったことがないという現状はあるのかもしれないなぁ、と想像している。Subversionの時代から使い始めたとか。そのあたりについてはいろいろ意見が欲しいなぁ。Perlドキュメント日本語訳 MLへくれるのがベストだけど、ブックマークコメントとかそういうのでもOKです。よろしくお願いします。
HTML5ではbody要素もセクションを作ります。というのをうっかり忘れてて、次のように書いてしまってた。
<body> <article> <header> <hgroup> <h1><a href="http://iwaim.beering.be/blog/">行動記録</a></h1> <h2>再開</h2> </hgroup>
これだと当然無名なセクションが作られてしまう。例えばHTML 5 Outlinerを使うと次のように表示される。
<ol><li><i>Untitled Section</i><ol><li>行動記録</li></ol></li></ol>
無名セクションを作ってしまわないためには、このようにマークアップしないとまずい。
<body> <header> <h1><a href="http://iwaim.beering.be/blog/">行動記録</a></h1> </header> <article> <header> <h2>再開</h2>
慣れるまで忘れがちなので、戒めのために記録しておく。
