Blosxom メモ

2009/08/30 tags: 2008, 2009, Blosxom, Programming, このサイトについて, 変なサイトの作り方, 試して合点

すぐに忘れるのでちょっとメモ。

補足：
Blosxom上でのシステム開発?をクローズしたので、この投稿は基本的には更新されることはありません。

すくしょ

以下の文章は、「Blosxomをカスタマイズする」ではありません。
勿論フレーバーとそれに伴うプラグインの出力レベルでの改修は数多く行なっていますが。
かいつまんで言えば、「WebサービスのRSSフィードをBlosxomの投稿ログとする」改修です。発想の発端は、「Blosxomがあったではないか。」になります。
当時利用していたレンタルサーバでMySQLを利用できなかったのも別のファクターとしてありますが。

以下、今更ながらですが、自分でも何を書いてるのか、分からない部分が多々あります。
しかしながら今回、「残タスク(Blosxom編)」「(Blosxom関連の)コーディング関連メモ」を統合して、「Blosxom メモ」とリファインさせてみて思ったのは、「プラットフォームが変わっても(= BlosxomからWordPressに乗り換えた)、やってる事変わんねーな」でした。

機能図みたいな何か
PHPでXMLの取り込み
XPathの取り扱い
レスポンスタイム
cron
ホスティングサービス固有の処理
エラーハンドリング
PEARのHTML template for PHP
閑話休題 #1
push_if_firstの修正
SIMILE Timelineについて
cron間隔の変更
開発環境の変遷
SIMILE Timelineについて 2nd try
Blosxomのログの日付について
閑話休題 #2
未来日記
XML/RSS→Yahoo Pipes→JavaScript
SIMILE Widgets | Runway
訪問者情報の表示
フローの情報をストックにするための実装…案倒れ
フローの情報をストックにするか?
トモダチ情報の取り込み
トモダチ情報の取り込みの誤報
サーバ移行に関して
一旦close?
第1.5フェーズ以降
第1フェーズのclose 2009/02
対応中案件(～2009/01)
未対応案件
完了案件
廃案・妄想レベル

機能図みたいな何か

きのうず

自分にとっては自明の理なので忘れていた。
これを書いているのは、”SIMILE Timelineについて 2nd try”の後だったりする。

上図で言えば、灰色の部分、および、”other process”をPHPで実装している。これらは任意起動、またはcronによる起動。
文章で書けば、simplexml_load_fileで各Webサービス(Tumblr・delicious・hatena::bookmark・Last.fm等)のRSS・XMLを取得して、BlosxomのログをHTML_Template_ITを用いて出力、みたいになる。
なので、Blosxom本体には表示部分を除き手を加えていない。つまり、BlosxomのプラグインによるユーザからのURLリクエストによるリアルタイムのデータ取得を行っている訳では無い。
勿論、図みたいに簡単には行かない部分があるし、他に実装している部分があるが、極論すると図みたいになる。
以下は、主には実装時に経験した色々な事を書いている。

多少補足。
“copy & modify date”は、ファイルの日付を意図的に変更する事で、Blosxomのログとしての日付の整合性を図る処理。
“other process”は、SIMILE Timeline用のJSONを作成したり、その他、モロモロの処理を行っている。
“FTP”は、自分の場合、Webブラウザからログの投稿を行うWikieditishを使わず、ローカルでファイルを書いてFTPしている。

PHPでXMLの取り込み

[Tumblr][PHP]自サイトにTumblrフォトギャラリーを設置 : boreal-kiss.comを参考に。
これを単純化してみる。

$xml = simplexml_load_file("http://hoge.com/RSS");
foreach ($xml->posts->post as $post) {
  $permalink = $post['url'];
}

当然ながら simplexml_load_fileに与えるURLは、各Webサービスにより違うし、サービスによっては別途APIを用意している場合がある。
また、$xmlの中身も(完全には)統一されていないので、中身のデータ取得はケースバイケースになる。
自分の場合、ブラウザで上記のURLを実行した結果を見ながらコーディングした。
…のだが、Firefoxの場合、モノによっては生のXMLが表示されないので、わざわざソースを見て、という…
例えば$xmlをvar_dumpするのは実に良い事だと思うが、object(SimpleXMLElement) がやたら表示されて見辛い。
何かもっと便利な方法があると思うが。
余談だが、PHPの関数によっては明示的に型変換しないと、PHPから怒られる。

XPathの取り扱い

まず、下記のパターンは何とかなった。

：
<dc:date>2008-11-25T01:05:01+09:00</dc:date>
<dc:subject>Book</dc:subject>
<dc:creator>cerberos</dc:creator>
：

これは、理屈は良く分からないのだが下記のコーディング。

$dc = $post->children('http://purl.org/dc/elements/1.1/');
$date = (String)$dc->date;

対して、Google Readerの共有アイテムに関してはできていない。
…と言うかGoogle ReaderのXML、ごちゃごちゃし過ぎ。

<id gr:original-id="http://japanese.engadget.com/...">

XMLの属性がXPathになってると言うのか。

レスポンスタイム

処理によっては、結構重いモノがある。
道義的にどうよと思わなくは無い、tumblrのタグを全て取得する処理みたいな。

Fatal error: Maximum execution time of 30 seconds exceeded in .....

という場合、これはホスティングの会社と要相談になりそうだが、set_time_limit を使って以下略。

cron

各RSS|XMLから最新の情報を取得しているこれらの処理は、ユーザからのリクエストベースで動いているのではなく、cronを利用している。
現時点においては、各サイト(tumblrはpostの種類単位)の最新情報の取得は4時間毎、Tumblrの全タグ情報の取得は月曜5時に起動している。
下記は、これらのcrontab。

0 */4 * * * /usr/local/bin/php /foo/var/hoge.php proc=normal
0 5 * * 1 /usr/local/bin/php /foo/var/hoge.php proc=all_tags

これらcronが起動した後、メールが来る。
これを送信させないか否かはケースバイケースだが、メーラでフィルタかけておけば良いかとも思う。

0 */2 * * * ... hoge.php proc=normal >/dev/null 2>&1
 is
0 */2 * * * ... hoge.php proc=normal 1> /dev/null 2> /dev/null

また、臨時にWebからも実行できるようにしている。
例えば、http://foo.com/hoge.php?proc=normal というURLリクエストに対して、下記の処理を行う。

$strtmp = $argv[1];
if (strlen($strtmp) == 0) {
  $arg_proc = $_GET['proc'];
} else {
  $arrtmp = explode('=', $strtmp);
  $arg_proc = $arrtmp[1];
}

cronからの実行時のコマンドライン引数の取得、無茶苦茶ではあります。
これを業務でやったら…と言うか、何もやってないのが問題で…銃殺モノですが。

ホスティングサービス固有の処理

今時MySQLがコミで使えないというお茶目なKAGOYAであるが、CGI・PHPご利用マニュアル – KAGOYA Internet Routingにおける「PHPをCGI版で動作させる方法」の設定をしなければならない。
suEXECと言うらしいが。
このため、自宅の開発環境であるXAMPPとパスの設定・拡張子が違う。
XAMPPを何とかすれば何とかなるかもしれないけど、最初に起動するスクリプト、上記cronの例で言えば、hoge.phpはKAGOYAの設定に従う。
その上で実際に処理をする部分は include_once で読み込ませる事で、自宅とWebとの間で最小限の修正で動くようにしておいた。

エラーハンドリング

やべぇ、組み込んでない…
こういう時、Javaみたいに try…catch…finally があれば…
一番エラーが起こり易いのは、simplexml_load_file であろうかと。
エラーハンドリングとは別に、tumblrの全タグ情報の取得で、タイミングによっては記事が全く無い状態になっている。
別ディレクトリで記事を作って、正常修了後に公開ディレクトリにコピーする、という方法に変える必要もある。

および、何かが起こるとしたら、KAGOYAのPHP仕様の変更、各WebサービスのAPI変更があるかと。

まぁ、何かあったら考えようかと。

補足。

あるじゃぁねぇかよぉ。
[ThinkIT] 第6回：企業システムにおけるPHP5の可能性 (1/2)

これはPHP5のtry～catch構文にfinally節がなく、…
この点は世界中のPHP開発者が問題視していますので、近日中にPHP開発コミュニティによってfinally節がサポートされることを期待できます。

なので、finallyが無いのは面倒なので、今は対応しないと思う。

PEARのHTML template for PHP

簡単な使い方は、PEAR マニュアル HTML_Template_IT 導入あたり。
ところが。

Webブラウザを前提とした関数(HTML_Template_IT::show())しかないので、自分みたいにテキストファイルへの吐き出しはどうすれば? で途方に暮れる。
一瞬UNIXのシェルでパイプみたいなコトができたら、と考えたが、無理っぽい気がした。
ならば、関数…と言うかメソッドというか…を作れば良いのではないかと。
まず、下がオリジナル。

function show($block = '__global__')
{
    print $this->get($block);
} // end func show

だそうだ。
これを下記にオーバーライドした。
近頃、Javaのクラス周りで悩んでいるのが意外と役に立ったかも。

require_once "HTML/Template/IT.php";

class HTML_Template_IT_ex extends HTML_Template_IT {
  function show($filename, $block = '__global__') {
    $fp_out = fopen($filename, 'w');
    fwrite($fp_out, $this->get($block));
    fclose($fp_out);
  }
}

なので、インスタンス化するのはHTML_Template_IT_exになる。

$tpl = new HTML_Template_IT_ex("./foo");
$tpl->loadTemplatefile("var.tpl.html", true, true);
 :
RSS読み込みとテンプレを埋めるデータ作成
 :
$tpl->show($FILE);

引数増やしてオーバーロードっぽくもなってるが。
ただ…まだ本番リリースしていないので何ともだが。

閑話休題 #1

のーと

ところで、このノート、世界堂でしか売ってるのを見た事がない。
A4リングノートなのだが、罫線が横長。
ネットには情報が無かったが、ナカバヤシの「丸写しノート　横長サイズノートで黒板を丸写しできる!!」とのこと。
確かに、普通のリングノートは、左側ページを書いていると、リングが邪魔になるが、このノートにはそれが無い。
また、縦長だと、上下でどうしても時系列を意識してしまうが、これは横長なのであまり意識しない。

…と、結構気に入ってるのだが、世界堂でしか扱っていないのが難点。
売り切れたり販売終了になったらどうしようかと思う。
「そうだ、POPLSで作ればいいんだ」
と思ったが、綴じがリングは扱ってないみたいで。
個人的には、綴じは無線綴じよりもリングの方が扱い易いと思っている。
よくある方眼のリングノートで代替できるかと言われても、ちょっと違うかなと。

ペンは相変わらずHI-TEC-C。
これには今まで通りの紺を使っているが、近頃発売されたらしい「和らぎカラー」の「うすずみ」が結構いいカンジ。

さて本題。
プログラミング|コーディングというのは最終手段であり、そこに至るまでの「前準備」というのが存在する
…場合がある。

今回も最初のうちは下調べだけのいきなりコーディングで済んだが、ある程度カタチが整ってきて、その上で何等かの機能を追加・修正しようとすると、現在動いている状態とのすり合わせが必要になる。
そのためには、いきなりコーディングを行うのではなく、色々と思考を廻らせ、コトの進め方を把握しておく必要がある。
その辺は、趣味のコーディングよりは、生業の方がシビアになるが。

こう書くと臥薪嘗胆の世界みたいに思えるが、こちらに限って言うならば、単純に面白い。
色々とあれやこれやと考えを廻らせるのは、ある意味至福の時間ではある。
…くどいが、こちらに限って。

上記イメージは、現在(2008年クリスマス前後)各種別毎に別々に出力されているTumbrを一つにまとめるにはどうしたら良いか? ならばtumblrのタグも一緒にした方が良いか、そう言えばせっかくだからタグクラウドしたいなぁ、一から実装するにはどう考えれば? みたいなコトをわらわらと書き出してみたトコロ。

push_if_firstの修正

Blosxomのプラグインにpush_if_firstがある。
1番目のログの下に任意の何かを表示するプラグインで、入れてはいたが有用な使い道が無かった。オリジナルのソースではAdSenseを表示しているみたいだが。
個人的な要望としては3件。

include_fileプラグインの変数を使いたい。
プラグインのヒアドキュメントの部分とはいえ、毎回プラグインを書き換えるのが怖いので、別ファイル化したいな、と。
任意の位置に表示させたい。
何となく…強いて言うならば、1番目のログの下はしっくり来ないので…
候補のファイルからどれか一つを選んで表示させたい。
いつも同じだと面白くないので。例えば、ランダムに表示させることもできるが、ページを変える度に表示が変わるのも鬱陶しいので、日毎で変更しようかと。その日表示するファイルがあればそれを表示して、無ければデフォルトの表示を行なう、みたいな。

まず一つ目は、自分のPerlへの理解度が低いため実装できず断念。

 :
use vars qw($data $is_first);
 :
$data = <<"_DATA_";
ここに表示させたい文字列を書くよ
_DATA_
 :
$is_first = 0;
 :
sub story {
  if ($data and $is_first) {
    $is_first = 0;
    $data = '';
    return 0;
  } elsif (!$data and !$is_first) {
    return 0;
  } else {
    $is_first = 1;
    return 1;
  }
}
 :

というのがオリジナルのソース。
御免なさい。
何となく分かる様な気がするけど、何となくなのでどう修正すれば? で途方に暮れる。Perlは苦手ですともええ。くそっ、Perl姉さんの壁は高い、高過ぎるぞ…
Blosxom の動作の概要 : torus solutions!によれば、storyサブに関しては「ページを作る際、各エントリーごとに呼び出されるサブルーチンです。」とあるので、だとしたらもしかしたら、ログを表示する度に変数値が保存されたままstoryサブが動くのだろうかと$dateにカウンタを表示させてみる。

use vars qw($data $is_first $count);
 :
$count = 0;
 :
sub story {
  $data = $count + 1;
  return 1;
}
 :

なるほど、想像通り。
となると、あまり綺麗では無いけどこういうカンジか。(3件目の直下に表示)

sub story {
  $is_first = $is_first + 1;
  if ($is_first == 3) {
    open(FH, "./hoge/push_if_first");
    while ($data_wk = <FH>) {
      $data .= $data_wk;
    }
    close FH;
    return 1;
  } else {
    $data = '';
    return 0;
  }
}

オンコーディングで「3」とか、ファイル名書いたりするも嫌なのだが、これは後日、bskのconfig.cgiに反映予定。但し来年本気出すレベル。
次に、3番目の要望を満たすための修正を行った。

sub story {
  $is_first = $is_first + 1;
  if ($is_first == 3) {
    my @date = localtime(time);
    my $filename = sprintf("./hoge/push_if_first.%02d", $date[3]);
    if (-e $filename) {
    } else {
      $filename = "./hoge/push_if_first.00";
    }
    open(FH, $filename);
    while ($data_wk = <FH>) {
        $data .= $data_wk;
    }
    close FH;
    return 1;
  } else {
    $data = '';
    return 0;
  }
}

まぁねぇ…Perl遣いが書くともっとシンプルになるだろうけど…
で、デフォルトに何を表示するのかだが、ちょっと考えている事があって、それは今後の対応。

SIMILE Timelineについて

SIMILE Timelineというのがあり、面白そうなので使ってみた。
のだが…断念。

理由は、Blosxomとの相性の問題。
例えば、このカテゴリは/limited/memo/カテゴリ(現在カテゴリは廃止)になる訳で、一方、このウィジェットの仕様として表示データをこのJavaScriptと同じディレクトリに置かなければならない仕様になっている。(絶対ディレクトリ指定ができない)
なので、このブログをトップディレクトリで見ると問題は無いが、カテゴリで見ると柄は表示されても中身が表示されていない、という状況。
ならばと、各ディレクトリに配置したのだが上手く行ってない。
もしくはとソースを見て絶対ディレクトリ指定に…見る気にもなれねぇorz…という状況。

これを上記push_if_firstのデフォルトのデータとして表示しようとしていたのだが残念ながら。
と言うか先週少し使っていたのだが、不具合が見付かった状態。
それと、もしかしたらIEでは表示されていなかったかもしれない。これはこれで問題だが。

後味は悪いがこれにて一件落着相成りで「無かった事にしよう」…だったのだが、偶然UnHubというサービスを知り、これのHome(デフォルトで表示されるサイト)にしようかと思った。更にこれを突き詰めて、このサイト自体のスタートアップページに良いんじゃないかと思い始めている最中。
なので、このブログ自体をhttp://www.duelist.org/morry/blosxom/みたいにして、http://www.duelist.org/morry/は、コードの参考にした…ありがとうございました…ベース奏者としての演奏歴・Timeline版みたいにシンプルなページになるかと。
ただ、ちょっとリスクがでかいと言うか、もうちょっと煮詰めないといけないかなぁと思っている。
その一方で、Timeline用のイメージアイコンをグレーをベースに作ってみたりしてはいるが。

尚、Timelineに表示するためのデータは、ここにアップされているログを総舐めして(ログ数自体多くないので可能な技と言うか)、各ログの1行目を読んでタイトル取得、ファイル更新日付の取得、等を行い、HTML templateを経由してJSONを出力している。別にXMLでも問題無いと思う。

cron間隔の変更

今までは日中に個人的なWebを触っていても、さほど影響の無い環境だったが、現在(2009年春先)はそもそも外に繋がってない環境下にいる。
例外的に個人持ちのPDAでGoogle Readerの目ぼしい記事にスターを付けて自宅で各サイトに登録する、というのが可能な程度。
なので今まで2時間毎だったcron間隔を4時間毎にしてもさほど影響は無いだろうと。

ところでどうでも良いのだが、push_if_firstのデフォルトの表示に利用しようとしたSIMILE Timeline用のJSONもcronで生成している。現状未利用なので、生成のみだが。
これの生成タイミングだが、cronを編集する時に各WebサービスのRSS取得をそのままコピペして、JSONデータ生成のスクリプトを起動するように修正した。
…実行結果を見ると、最新更新時間が合っていなかった。それもその筈で、同じタイミングで、一方ではRSS取得、一方ではJSONデータ作成を実行していた事になるので、整合性が取れる訳が無い。
なのでJSON生成は、RSS取得の5分後に実行している。JP1のジョブ管理みたいに、RSS取得が正常終了したらJSON生成、みたいにできなくもないだろうけど、そういう仕組みを実装するのも面倒なので。

開発環境の変遷

直近十数年の血と汗と涙の記録か?

約12年前：Apache & Perl on Linux…FreeBSDかも?
自宅に内向きのLANを設置。まだISDNの頃。この上でPerlで書かれたBBSを試したり、HNSを試したり。
約10年前：Apache & ActivePerl on Microsoft® Windows®
「へぇ、WindowsでApacheとか動くんだ」という衝撃があった。
前述と同じ様なコトをやっていたと思うが、shebangを書き換えなければならないので、ちょっと面倒だなと。
約8年前?：Apache & Perl on Cygwin
遅かった気がする…
約5年前?：レンタルサーバ or Apache & PHP on Windows
一時期、直接レンタルサーバにテスト用ディレクトリを作成して色々と。
PHPを触り始めた理由は、shebangが無い、妙なコーディング上のクセが無い、Perlの場合みたいな「お約束の呪文」を入れる必要が無い、みたいなのが理由。
現在：XAMPP on Windows
良い世の中になったと思う。

以上はサーバ側の環境であるが、クライアント側は実は一貫してテキストエディタであった。
どうなんだろ。今後、オブジェクティブなプログラミングを行うに際しては、もう少し便利な環境の方が良いんじゃないかと思う。
サーバ側PerlやPHPで、通常はエディタで書いて実行時、ブレークポイント・ステップ実行ができるならば、それはそれで便利かもしれない。これ、Eclipseでできそうな気がするが、手間ばっかりかかって、みたいな気がして試していない。
と、思うオレもトシだ。

SIMILE Timelineについて 2nd try

IEで動かなかった原因はJSONの記述エラー。

{'dateTimeFormat': 'iso8601',
'events' : [
{
  'start':'1992-04-01',
  'end':'1992-06-30',
  'title':'Asagaya',
  'description':'boot camp'
},{
 :
},{
  'start':'2009-03-29 19:00:01',
  'icon':'http://www.duelist.org/morry/img/circle-green.png',
  'title':'コーディング関連メモ',
  'description':'すぐに忘れるのでちょっとメモ。',
  'link':'index/limited/memo/programming.htm'
},
]
}

下から3行目にカンマがあったので。たったこれだけで?と思うが。
Firefoxでは無視されたが、IEでは厳格に処理されたため。
何故この様な事態になったかと言うと、コーディングミスと言うか、テンプレートの記述ミスと言うか…

ちなみに、最初の記述は期間を表し、下の記述はピンポイントのイベントを表す。

SIMILE TimelineのJavascriptコーディングは、下記…で動いているみたいなので…良く分からんが…

 :
<script
    src="http://static.simile.mit.edu/timeline/api-2.3.0/timeline-api.js?bundle=true"
    type="text/javascript"></script>
</head>
<body onload="onLoad();" onresize="onResize();">
 :
<div id="my-timeline" style="height:300px;">
Timeline©SIMILE comes here...
</div>
<script type="text/javascript">
//<![CDATA[
//document.getElementById('my-timeline').style.height = '500px';
window.onresize = onResize;
var tl;
function onLoad() {
  var eventSource = new Timeline.DefaultEventSource();
  var theme = Timeline.ClassicTheme.create();
  var bandInfos = [
    Timeline.createBandInfo({
      eventSource:    eventSource,
      width:          "90%",
      intervalUnit:   Timeline.DateTime.MONTH,
      intervalPixels: 90,
      timeZone:       +9,
      theme:          theme
    }),
    Timeline.createBandInfo({
      overview:       true,
      showEventText:  false,
      eventSource:    eventSource,
      width:          "10%",
      intervalUnit:   Timeline.DateTime.YEAR,
      intervalPixels: 40,
      timeZone:       +9,
      theme:          theme
    })
  ];
  bandInfos[1].syncWith = 0;
  bandInfos[1].highlight = true;
  var tl = Timeline.create(document.getElementById("my-timeline"), bandInfos);
  Timeline.loadJSON(
    "http://www.duelist.org/morry/push_if_first.json", function(json, url) {
    eventSource.loadJSON(json, url);
  });
}
var resizeTimerID = null;
function onResize() {
  if (resizeTimerID == null) {
    resizeTimerID = window.setTimeout(function() {
      resizeTimerID = null;
      tl.layout();
    }, 500);
  }
}
//]]>
</script>

気のせいか、Timeline.loadJSONで指定しているJSONのURLをダメ元で絶対指定のURLにしたのだが、動いている。
何かねぇ…これを使ってる色々なヒトのサイトのソース見たのだが、書き方もバラバラで、そもそもの script src で指定されているURLもマチマチで、みたいなカンジなので、何が正しいのか良く分からん。
取り敢えず本家のドキュメントや例題見てゴチャゴチャと。

実際の稼動はindex.tmlあたり。
ホント、良く分からん…

Blosxomのログの日付について

極論すれば、自分とBlosxomとの付き合いは、Blosxomの日付処理との闘い、とも言えなくは無い。
何も考えないと、ログがそのOS上のファイルとしての日付をBlosomでの日付として認識しているため、ファイル日付でorder byされるBlosxomでは、後日、ログの修正を行った場合、あまりよろしくない。
他のブログツールは良く知らないが、はてなダイアリーの場合は任意に日付を指定、Tumblrの場合はログを書き込んだ時点(デフォルト)、もしくは任意に日付を指定できる。

これを回避するには、Blosxomプラグインでentries_index・entries_cache・entries_kacheで、(おそらくは)ログを新規作成した日付をキャッシュとして一元管理するのが一般的だと思う。
これらの場合、キャッシュを無くした場合や、滅多にある事ではないが、移転する場合に甚だ都合が悪いんじゃないかと思う。
…改めて上記プラグインを見たのだが、entries_cache・entries_kacheは各ログに日付を持たせキャッシュを作成する仕様だった。

自分の場合、当初から上記のプラグインは使わず、別プログラムでログを単なるOS上のファイルとして日付を強制的に更新する方法を採用している。なので、キャッシュまでは作成していない。
問題は何処に基点となるファイル日付を持たせるか? であるが、これには変遷がある。また、レンタルサーバの仕様に関わる問題もあった。

まず、基点となるファイル日付に関して。

ファイル名そのものに持たせる
ex. d20090504001.txt、Blosxom_20090504_134121.txt
htmlのコメントとして持たせる
ex.
metaタグ…なのか? 取り敢えず表に出ないので良しとしているが…として持たせる
ex. meta-date: 2009/05/04 13:41:21

当初---いわゆる"unlimited text works" (= 1st.)の頃---は1.の前者のパターンだけだった。
例で言うと、そのログ(= ファイル)の日付を2009/05/04 hh:mm:01に更新する。尚、hh:mmはオンコーディングで23:01として統一されている、と言うか、せざるを得ないのと、時間まではそれ程こだわりが無かったので。と言うのも、何月何日に何の言動があった、までは関心があっても、何時に、はログで言及すれば良いか、という思惑があったので。
こだわりがあるとすると、未来の記述にならないようには注意していたが。例えば、現在26時だとして、24時頃にあった事を書く場合、当日のログではなく翌日のログにするなど。…ただこの場合、Blosxomの仕様上、デフォルトでは未来日付は表示しない仕様になっていた筈なので…実際どうやって運用していたのかは忘れた。(もしくはこの様な事態は発生しなかった?)
また、同一日付で複数のログが存在する場合、カテゴリ(= ディレクトリ)が違うとは言えd20090504001.txt、d20090504002.txt(= 2009/05/04 hh:mm:02)、…、というファイル名末尾3桁がシーケンスの意味合いも兼ねていた。(さすがに999どころか59を超える事は無いだろうと)
その後、unlimited text works, 2nd.では1.の後者のパターンにしているが、難点としては無駄にファイル名が長くなる事、一々ファイル名や日付を考えなければならない事がある。

次の2.は、これを書いている現在は採用しておらず、3.に移行しており、ファイル名は完全に任意で日付を持たせていない。
いずれにせよ、自分の場合は、ローカルでファイルをぱっと見た段階で「何時書いたか?」には関心があっても「何を書いたか?」にはあまり関心が無かった、とも言える。
例えば過去ログを参照する場合、ログをエディタのgrepを使って検索しているので、さほど問題を感じない。
また、ファイルの中身まで読む処理に抵抗…コーディングが面倒、一々ファイル日付を指定して記述するのが面倒…があった。
1st.の頃は、ほぼ毎日書いていたので処理が煩雑になるので避けていたが、2nd.に移行して、「何時書いたか?」よりも「何を書いたか?」に主眼が移ったため、2.・3.の必然性が出てきたとも言える。また、ファイル名も無機質なd20090504001.txtでは「何を書いたか?」が分からないため、ファイル名で判別できる方針に移ったとも言えるが、1st.ではほぼ毎日書いていたため、一々ファイル名を考えるのが面倒だったのでd20090504001.txtでも問題が無かったとも言える。
ちなみに現在、hh:mm:ssはほぼ適当。さして重要性は無い。

3.に関しては、前提としてmetaプラグインが必要だが、taggingプラグインの前提条件になっているので導入済み。
例えば、このログは下記の記述であり、Blosxomの表示では、meta-tagとmeta-dateは削除されている。またはmoreプラグインのための記述。

+-------------------------------
|コーディング関連メモ
|meta-tags: 2008, 2009, Blosxom, Programming, このサイトについて
|meta-date: 2009/05/05 07:00:01
|
|<p>
|すぐに忘れるのでちょっとメモ。
|</p>
|
|<!-- more -->
|
|<h4>一覧</h4>
|
|<ol>
|<li><a href="#01">機能図みたいな何か</a></li>
| :

"2008"・"2009"とmeta-tagsにあるのは、Archivesプラグインを廃止した事に伴う代替策でログの作成年をタグとして管理している。Archives利用時は年月がデフォルトでそのまま利用していたが、その後2nd.の途中から年だけの管理、その後廃止。元々、年月の表示に関しては懐疑的と言うか不要論者なので。
以上から、現在は1.の後者と3.のパターンを並立させていて、1.の後者は敢えて別ログ(= ファイル)管理したい記事、例えば、Blosxomに関しての記述等、用途は限られている。

さて。
次の「レンタルサーバの仕様に関わる問題」であるが、要するに、自分がFTPするユーザとファイル日付を更新するユーザの権限が違うため、WebブラウザからFTPしたファイル日付が更新できない問題を抱えている。
これはどちらかと言うと、レンタルサーバの仕様に依存する問題だと思う。
これを回避するため、Blosxomのログのディレクトリ(デフォルトはentries)とは別に、FTPアップロードするディレクトリを新設し、Blosxomログディレクトリへコピー&日付更新を行っている。例えばPHPでは下記の処理を行っている。

|
+ Blosxomのルート
|  +- entries … UPDATE_PATH_TO : Blosxomログディレクトリ
|  :
+- works      … UPDATE_PATH_FROM_1 : FTPアップロードディレクトリ
+- temp       … UPDATE_PATH_FROM_2 : RSS取得処理の結果格納ディレクトリ

     :
  $pathArray = array(UPDATE_PATH_FROM_1,
                     UPDATE_PATH_FROM_2);
  $infoArray = array();
     :
  // ディレクトリからファイル&属性の取得
  foreach ($pathArray as $path) {
    $dir = dir($path);
    while ($file = $dir->read()) {
       :
      $infoArray[] = array(
        'pathname' => $path,
        'filename' => $file,
        'date' => func_getDateTime($path . $file),
       :
        );
    }
    $dir->close();
  }
     :
  // ファイルコピー&日付更新
  foreach ($infoArray as $info) {
    $str_file_from = $info['pathname'] . $info['filename'];
    $str_file_to = UPDATE_PATH_TO . $info['filename'];
    copy($str_file_from, $str_file_to);
    touch($str_file_to, (int)$info['date'], (int)$info['date']);
  }

function func_getDateTime($filename) {
// ディレクトリ&ファイルを引数として受け、UNIX日時を返す
// 1. ファイル名から
// 2. 中身を読んで(1.で失敗した場合)
     :
}

尚、ローカルではこの様な問題が起こらないと思うが(MS Windowsのため)、処理の統一化という面から、前述したディレクトリ構成と同じ運用を行っている。
以前は、entriesディレクトリで直接ファイルを作成・更新してファイル日付を更新するVBScript(= WSH)が存在した。

ところでtaggingプラグインであるが、新規のログを作成した場合、キャッシュを再生成する必要がある。
この仕様に対しては、新規・更新に関わり無く、上記のスクリプト実行時にキャッシュを削除する実装(unlink)を行っている。
なので、タイミングによっては、タグ一覧が表示されない場合がある。これは、キャッシュを削除した直後の起動でタグ作成のみを行って表示には反映されず、次の起動でタグ一覧が表示されるtaggingの仕様による。
…と思い込んでいた。
実際には、URLに"recache_tags=1"という引数を与えて実行すれば良いのだが、長らく放置していた。
今しがた、キャッシュを削除する実装に変えて、$fp = @fopen(URL_BASE . "?recache_tags=1", 'r'); という処理を組み込んでみたのだが、上手く行きそうなので、このままにする。

以上長々と。
今後も自分のニーズにより変遷するかもしれない。

閑話休題 #2

戯れにbackground-imageを変えてみた。

as is.

to be.

うーん…何か芸風に合わないなぁ…
と言うか、このブログのテーマに合ってるのかどうかという、根源的な問題に突き当たる気がする。
さて、このブログのテーマというかテーゼって何なのだろうか?

未来日記

todo的な意味合いを持つ未来日付のpostは、自分はプライベート濃度が高過ぎるという理由から、使っていない。
しかし、ネット&リアルで積極的に活動しているヒトは使っている場合がある。確かに常に先頭に表示されるので便利なのだが…
例えば、コミケ初日(= リアルな日付)にコミケ3日目(= 初日から見ると未来の日付であり、3日目の日付でpost)で初売りする同人誌のPRをしたとする。
勿論、このブログではその未来日付でpostした事になっている。
この時、Blosxomがどういう挙動を示すかというと、記事として表示されない。
ただし、$show_future_entries=1にすると表示できる。

と、2～3日だったら、recently friends activities...が消失してもまぁ良いか、だった。
しかし、年末の予定を載せられた日にゃぁアナタ…(w
これに対処するために、未来日付だった場合スルーするのが一番手っ取り早いかと。まだ実装はしていないが。

2009/08/25

XML/RSS→Yahoo Pipes→JavaScript

ここはバッチ処理を旨としているが、リアルタイムで情報表示もアリかなと思ってきた。
何となくできそうな気がするが、きっちり調べた訳ではないので、あくまで夢想レベルで。
要求定義は、アクセスの都度、マイクロブログの最新情報を取得してサイドバーに表示する、それだけ。「生きてるYo!」のお知らせ。
1時間間隔のバッチでも構わないのだが、鯖引越後、実は現在、cronが動かせない…正確には動くのだが、Web実行とcron実行でユーザが違い、それが原因でファイル更新権限に引っかかって上手く動いていないため、手動更新になっている…という状況。
しかしねぇ…マイクロブログを一人でやるってのも、あんまり食指が沸かないのだが…ネト友を作れない悲劇と言うか…リア友はmixi・BBSメインだし…

話は変わるが、CSSのリファインを行なった。
自分は伝統的に、レイアウト構造、ボーダ、色、の順でCSSを登録している。
つまり、あるオブジェクト単位で属性を書き出すのでは無く、レイアウトはレイアウトだけ、色設定は色設定だけ、みたいな、あまりお目にかかったことの無い記述をしている。
特に色設定に関しては、各オブジェクトをずらっと羅列しての色単位での設定にしている。
かなりスパゲティな状態だったのを、ダブっている設定や不要な設定を削ったのでシンプルになり、心持ち楽になった。

2009/07/27

SIMILE Widgets | Runway

SIMILE Widgets | Runwayだそうだ。
２ちゃんのまとめ系でたまに見るが、使えそうな予感。

2009/07/25

訪問者情報の表示

2つのレイヤに分けて考える必要がある。

まず、アプリレベルであるBlosxomについて。
refererプラグインが存在する。
で、実際に組み込んでいるが、現状は表示させていない。理由は…閑古鳥が住み着いているこのサイトの情報を表示するのは忍びないので。
しかしながらrefererプラグインが吐き出すログは、別途、PHPのスクリプトを書いて情報を確認している。

余談になるが、「何でこんな検索語で見に来るかなー」というのは相変わらず多い。
公開して色々とコメントしたいところだが、結果として更にこちらに来られても困るし、飛んで来る側にも面倒なので自粛している。
一方で、狙った訳ではないが、「そりゃそうだろうな、このサイトと他数サイトしかまとまった情報が無いよな」という検索語の場合、「おっしゃぁ！」という気分にはなる。

次に、ファームウエアレベルについて。
サイト移行するまでは、そういうのが提供されていなかったのだが、現在のレンタルサーバでは、Webanalizer・AWStats・Analogが用意されている。
3種類存在する理由が良く分からないが、何か目的なり見せ方が違うのだろうかと。

ちなみに、TumblrではNINJATOOLSを利用している。また、はてなダイアリーを利用していた頃は、なかのひとを使っていた。

ところでBlosxomのrefererタグの場合、あくまでもrefererなので、ダイレクトに飛んで来た情報は補足できない。なので、上記のログ解析ツールは有用ではあるが、定期的にチェックはしていない。
一方で、今後BlosxomからChyrpに移行・併用した場合、Chyrpがログ解析の手段を持たないため(おそらく)、別途解析ツールが必要になる。

で、例えば、上記解析ツールのログがプログラム(だけ)で取得できるのだったら、これも一つの記事になるんじゃないかと。
現状では仕組み的に困難かと思うが一応メモ。

2009/07/20

フローの情報をストックにするための実装…案倒れ

ブログは暗黙の了解で、一つの記事単位、キーとしては日付時間でシステムが成り立っている。
なので、リアルタイムの状況を記事として書いている場合、どうしても複数の記事に分かれてしまう。
これを回避するために…いや、回避は無理か…タグやカテゴリを設けたり、Blosxomで言えば…関連するログをヒストリカルに追っかける何等かのプラグインがあったと思うが…

ここのブログの場合、単に、過去ログを一つにまとめてしまえ、とか、記事が増えて別々にするのも面倒なので追記してしまえ(例えばこの記事)、という記事が多い。
これは、2nd.当初は全く想定していなかったが、ここに来てふとある考えがよぎった。なので、それを書き留めておく。

まず現行の場合、この記事みたいに、物理的に上か下に延びる形で同一テーマでの記事を追記している。
これを今後は下記の形式で、別々のパーツに分けて投稿し、プレゼン層のレイヤでまとめてしまえ、という発想。
勿論、Blosxomのプラグインと言う形でも実装できるが、多分やらない(能力的にできない)。なので、現行通り、バッチ処理で複数の記事を一つの記事にしてしまえ、という発想。

現行：
 tasklist.txt -+- 2009/07/20 フローの情報をストックに
               |             するための実装((案)倒れ)
               +- 2009/07/12 フローの情報をストックに
               |             するか?
               +- 2009/06/14 トモダチ情報の取り込み
                   :
対応後：
 tasklist.txt -+- tasklist.head.txt
               +- tasklist.20090720.part.txt
               +- tasklist.20090712.part.txt
               +- tasklist.20090614.part.txt
               |   :
               +- tasklist.foot.txt

みたいな。
補足すると、headにmetaタグを設けて記事の並び順(昇順・降順)を持たせる必要がある。
また、個々のpartに関しては、単にシーケンスを振って内部にmetaタグを設けて日付を管理する方法もある。
副産物として、head部分にコーディング関連メモにあるような、コンテンツ一覧を自動で生成することもできる。(現行は手動なので面倒)

話は変わるが、昨年から各所に投稿しまくった記事の見直しが必要かなぁという時期に来ている。
つまり当初は「これ、必要かも」と思ってブクマしたけど「やっぱり必要ないや」となるかもしれないしそうでないかもしれないし。
しかしながらこれを行なうにはそれなりの時間が必要なので未だ手を付けていないが。

2009/07/20

フローの情報をストックにするか?

プログラミングではなく、運用の問題として。
TumblrのdeviantARTタグの増加が激しい。
それもその筈で、基本は1件のpostに1件の作品がリンクするので仕方無い状況なのだが。
これをそのまま続けても問題は無いが、例えば、このブログでアーチスト単位にまとめようかなとも思って試しに開発環境でやってみた。
…のだが、あまり乗り気では無い。
理由は、異常に手間がかかるので。

手順としては、例えばターゲットとなるアーチストのタグを開き(ex. KimJonet)、イメージを一旦ローカルに落とす。
次に、そのイメージを更に小さくする。deviantでは縦横最大150ピクセルだが、このブログでは大きいので、縦横のどちらかが最大90ピクセルまで縮小する。
更に、そのイメージとリンクさせつつ、その作品のページともリンクさせるページを作る。
そして鯖にイメージ・ログをアップさせる。
…までをやってみたのだが、結構手間がかかる割には、余り達成感みたいなモノを感じないので。

このまとめページ作成以降、Tumblrでそのアーチストのpostを削除するが、削除以降のpostも通常に行なう、もしくはこちらのページに追記する、という作業もあり、何とも煩雑になる。
こういう面倒な作業こそプログラミングの出番なのだが、余り食指が動かない。

2009/07/12

トモダチ情報の取り込み

と言ってもFOAFのハナシでなく。
これはこれで今後対応しないといけなさそうな。うん、作ろう。

鯖移行も一段落、次期主力ブログツールも決まった状態なので、そちらに注力するのば筋かと思う。
のだが、次期移行は次期移行として、現行システムのメンテナンスというタスクも発生すると思う。勿論無視しても構わないが。

前々から、このサイトでやろうと思っていた事に、(リアルの)トモダチのサイト情報・ブログのRSSを取り込みたい、という課題があった。
技術的には確度90%で何の問題も無くできるのだが、本人に了承も無く勝手にやっていいのだろうかというモラル的な問題・葛藤があった。
今日その件について、候補者の一人から了承を得たので、まず第一の問題はクリアできた。
ちなみに本人曰く、「何か問題があったらこちらを閉じれば良いんでしょ」というスタンスで、「いや、そのりくつはおかしい」んじゃないかと…

次に問題なのは、自分もそこまで考えていなかったのだが、いざ取り込むとなると、どの様に情報を見せるか、という問題だった。
本人曰く、せめて最新3件にしてくれ、とは言ってるので、それには従うとして…でも、コメント等のRSSも別枠で存在するので、それも取り込んでやるという気ではいるが…このサイトにどう馴染ませるか、という問題が発覚した、もしくはそこまで深く考えていなかった。

例えば、このサイトで言えば、web activitiesタグ同様、タグを新設して各サイトを一つのログとして見せるのが一番簡単なのだが、件の本人以外に数人のサイト情報を事後報告・もしくは無許可で取り込みたいと思っている。
となると、各サイト毎にログが増える訳で、一般的には何の問題も無いかもしれないが、個人的にはログの増加は避けたいと思っている。
何故そうなのかと言われても困るが、データ数の多さを売りにも個人的な達成感にもしてないので…強いて言えば、「実は1998年から自分はこんなバカなコトやってますよー」みたいな。
なので、昔の感覚で言えば「リンク集」的な扱いにして、「トモダチ関連は一つのログ」が良いのかなぁというのが今の結論。

イメージ的にはル・マン方式で、こちらからRSSを定期的に取得して、トモダチサイトの一番若い(= 更新が新しい)情報をトップとして、以降はmore(= 続きを読む)、になると思う。
ところが、今までは、サイト間の連携が無かったので、RSS取得からログ出力まで一気通貫にロジックが組めたのだが、この案件の場合だと、まず夫々のトモダチサイトの情報を取得して、次に更新時刻をキーにして最新順位に出力、になる。
…というロジックは今までに無かったのだが、実は自分の各サイト情報も今は別々に扱っているが、一つのログとしてある程度まではロジックを組んでいた。
それを断念した理由は、Tumblrのタグ情報が重い(= 情報量が多い)ので避けていた、というのがある。
それを無理矢理押し通しても良かったのだが、見せ方に難があったので避けていた。
これを回避するのに、例えば、Ajaxによるタブを使う事でUI的にはスマートになるかもしれないが、ぶっちゃけ、放置していた。

ここまで来ると、連想配列にイチイチ溜め込んで事を起こすよりは、一旦RDB、今の鯖だとMySQLに情報を溜め込んで、そこから出力ファイル…ログを作成する方が得策なのかな、と思わなくも無いが、個人的には結構負担が大きいのでさてどうしたものか、と言うのが今の状況。

件の本人には「いえいえ、酔ってませんよ、今日中に作りますよ」とは言ったけど、色々と問題があるので一旦pendかなぁと。
更に言うと、一つのサイトにつき一つのソース|サブルーチン|関数が必要になるので、その辺の管理が面倒になってきた。
この辺、何となくだがオブジェクト的にプログラムを組み直しても根本的な解決にならない気がする。
ならばせめてソース管理を本格的に行なおうかと思ったりもして、調べてみた。
今まで意識しなかったが、CVSとかってバイナリ提供なんだと。いや勿論CVS使っても根本的な解決にはならないが、そろそろ導入を考えても良いかなでもローカルでCVS/Subversionってのも色気を感じないし…と。
スクリプトベースでリポジトリ管理をするツールもあるにはあるみたいだが(ex. MOONGIFT: » PHPで作られたバージョン管理システム「Kheops」:オープンソースを毎日紹介)、さてどうしたものかと。

2009/06/14

トモダチ情報の取り込みの誤報

もしくは勘違いについて。

ところが、今までは、サイト間の連携が無かったので、RSS取得からログ出力まで一気通貫にロジックが組めたのだが、この案件の場合だと、まず夫々のトモダチサイトの情報を取得して、次に更新時刻をキーにして最新順位に出力、になる。

Tumblrがこのトモダチ情報取得のためのロジックに近い、もしくはそのまんまだという事を忘れていた。

http://hoge.tumblr.com/api/read?num=1&type=regular
http://hoge.tumblr.com/api/read?num=3&type=link
http://hoge.tumblr.com/api/read?num=1&type=quote
http://hoge.tumblr.com/api/read?num=5&type=photo

…と、postするタイプ別にRSSを取得していた。
言葉で書くと余計に分かりにくいが、まず、RSSを取得してHTML templateをベースに一旦htmlファイルを作成、という一連の処理を別々に行なう。
次に、一つのログにまとめるために、先に作成したhtmlを読んで、ファイルの更新日付の若い順から(上記処理でプログラム内で最新投稿の日時をファイルの更新日付に修正している)、再度HTML templateを掴んでログを作っていたのだった。
勿論、MySQLを使う、連想配列を関数間で引き回す、というロジックにすればもっとCOOOLなロジックになるのは百も承知の上で。

ただ、このトモダチ情報の取り込みに関して今迄の処理と違うのは、今迄は各Webサービスの特性に合わせた項目を取得していた…例えば、TumblrのPhotoだったらイメージ・リンク先URL・本文、linkだったらリンク先URL・リンク先URLのタイトル・本文…が、今回は定型的に、本文タイトル・本文(の最初数十バイトでhtmlタグを削除)・リンク先URL・更新日時と決まった項目しか取得しない、という扱いになる。

2009/06/24

サーバ移行に関して

現状に関して、対応したい1点(まとめログ系の複数記述日のSIMILE Timelineへの展開)と、対応がまず無理だろうと思う1点(クラスによるコード書き直し)を残し、基本的には残タスクは無し。
ならば、コンテンツを充実させろよと思うのだが…

長年の課題であったレンタルサーバを移転する。予定。多少雲行きが怪しくなってきたが。

もう一つ。
Blosxomから別のツールへの移行。
次のレンタルサーバではMySQLが使えるので、時代に合った(wツールに乗り換えるかもしれない。
現状、可能性として高いのは、Chyrpかなぁと。
Movable Type・WordPress・Geeklog・MODx…等々、様々あるけど、どれもこれも世界観が広大過ぎて…
Chyrpは単なるWeblogだけでなく、Tumblogの機能も持たせる事ができるので…と言うか、Tumblogのオープンソース版というイメージがある(シンプルなブログのための軽便ツール、Chyrp - SourceForge.JP Magazine)ので、場合によってはTumblrからの移転(もしくは部分的なコンテンツの移転)も行う可能性がある…のだが、こちらのニーズを満たしていない部分があるので実装するしかないのかなぁと。
…と思い、ソースを見たのだが、いきなりではちょっと無理かと。
また、デザイン変更も、ちょっと今まで同様には行かなさそうなので、これも色々と調べなければならないかと。

とは言うものの、テーブル構成も複雑でなく、現状の基本部分はそのまま移行できそうだった。極論すればファイルを吐き出す替わりにSQLを発行すれば良さそうなので。

と、サイト移転はともかく、次期ブログツールに関しては、気長にやっていこうかと。

2009/05/11

一旦close?

デザインに関しては特に変更は無い。
自分が一番のユーザである以上、見慣れてしまい、他のサイトデザインに比べて明らかに「センス無いなぁ」と落ち込む事がしばしば。この辺が自分の限界かと思う。
確かにimageやらJavaScriptを駆使すればナウいWeb2.0には近付くのだろうけど、あまり食指が沸かないのが困ったトコロ。
とりあえず開き直ってこのままを維持。

taggingプラグインが使える状態になったので、アーカイブ(年月別集計)・カテゴリを廃止。
年月別集計は、年月別→年別と変遷し、現在、タグに持たせているため廃止。年レベルでなく、せめてクォータ程度まで細分化しようと思ったけど、意味を感じないので、そこまでは対応せず。
少し問題なのは、JSONファイルが最新日付だけのログを基準にしているのに対して、タグはそのログが書かれた年を列挙している。例えば、かつては別々のログだったものを一まとめにした煩悩のまとめ系に多い。2005年・2006年に書いたログを一まとめにした場合、タグは"2005"・"2006"であるが、そのファイル日付は2006年を設定している。
この辺、JSONを生成する時に、アンカータグのname属性をJSONに反映させる等の方法があるが、実装はしていない。
カテゴリに関しては、タグがあれば不要かと思って廃止。ログの件数が今後爆発的に増加するとも思えないので、ディレクトリ(= カテゴリ)に分けて管理せずとも、ファイル名だけでログの内容の判別が付くので。(ちょっと不安だが)

他、下に色々と書いたけど、対応は未定。ちょっと他の事をやりたいので。

2009/05/04

第1.5フェーズ以降

第1.5フェーズ

第2フェーズとは言い難いので。
また悪い病気が出てきて、見せ方を変えたいと。

らしくない、という意味合いで、Fashionista by dreamlogicあたり。
ライセンスが見えないが、これをそのまま(特にヘッダのイメージ)使う予定。
実は途中まで色々と対応していたのだが、訳あってpend。
横幅が少ないので、2カラムできない|やりづらいのが困ったトコロ。
既存の延長、という意味合いでは一番対応し易い。
らしくな(ry、Museum Themeあたり。
もっともこれはTumblrのテーマなので、それ相応の覚悟が必要だが、それなりにイケてるデザインになるかも。
見えないのがmoreの実装方で、Tumblrのタグにmoreを入れれば自動的にmoreされるのだが、なぜこう動くのかがcssを見てもイマイチ分からない。JavaScriptも使っているが、search用(これはこれで参考になる)とMicrosoft.AlphaImageLoader用なので、直接は関係無さそうな。
CSS 3のセレクタ「：target」でタブメニューをつくる - builder by ZDNet Japanあたりだが、こういう小手先のテクニックは今後色々出てくる気がする。
ただねぇ…出来合いのJavaScript、例えばあれこれポップアップやLightboxを組み込んでもイマイチ燃えないと言うか…
ついでにもしかしたら、PHPでインタフェース・抽象クラスが使えるので実験がてらソースをクラスに書き換えるかも。
Tumblrから日記タグのみの抽出。
いわゆる「日記ブログ」としての機能は、Tumblrで展開しているが、Tumblrのpostの流れが早いので、あまり日記として機能していない気がする。
しかし、これを実装するには、まず先にプログラム内部的に共通関数化しなければ実現できない。
他に、Kassandra Leigh Purcellのみを抽出、というコトもできるが。

第2フェーズ

更にその先のフェーズ2対応は、いよいよ自分もAjaxに進出か? みたいな。
非同期プラスJavaScriptあたりで。
ネタはまだ明かさないが(途中で飽きるか?)、それが既存のブログのユーザインタフェースと馴染むのか、現在検討中。

2009/02/09

第1フェーズのclose 2009/02

下記の「対応中案件(～2009/01)」を第1フェーズとすれば、何件か案件が残ってはいるが、とりあえずcloseにする。
要は「飽きた」からなのだが、この第1フェーズの積み残し案件・未記述案件について記述しておく。

Blosxomタグ

ログが数百件あるならばともかく、このサイトではそれ程の記事の増加を考えていないので、不要かなぁというのが結論。

Google reader shared item削除

ソーシャルブックマークは用途別にdelicious・hatena::bookmarkを使っている。
deliciousは真面目な話、hatena::bookmarkはおちゃらけ、何か一言申したい時はTumblr。
これまでは、各サイトのRSSをGoogle readerで読み、気に入った記事を共有アイテムにしていた。
もしくは、直接共有ブックマークする場合もあり、それは作業場所・環境に依存する。
自宅の場合だと直接共有ブックマークする場合も多いが、外や携帯だとできない場合があるので。
いずれにせよGoogle reader shared itemの存在意義はテンポラリ、という意味合いが強かったのだが、現在はスターを付けて内部的に管理しているため、Google reader shared itemが不要になった。