unlimited text works, the 3rd.
my portal, hub, information assemble site (beta version)

Delusion、欲望

2009/07/03 tags: , ,

あくまで欲望、として。

実はWeblogの実装レベルでの仕組みって、物凄くシンプルじゃないかと思う。
日々入力されるデータを時系列でソートして画面に表示しているだけ、になるんじゃないかと。

欲望記述

業界人向けに言えば、帳票出力プログラムと何等変わらないと思っている。
生のデータをHTMLを経由して出力するのも、オーバレイに相当するし。
なので、その気になれば、メインフレームででもBlogは…Web-logになるかは微妙だが…実装できる。

実際、自分も一時はPHPで独自実装して公開していた。
実装で面倒だったのは、それ以前に使っていたHNShnfをパースする部分だったが、そんなに難しいものではなかったと思う。
という状況が2003年下半期。その後、Weblogというものを知り、Blosxomに乗り換えた。
乗り換えた理由は単純で、車輪の再発明の無駄さ加減を悟らされたのと、Blosxomのシンプルさに魅力を感じたので。

それから6年が過ぎ、高度に発達した各種CMS・Weblogツールであるが、様々なニーズを取り込んだりフレームワークとしての機能、その他諸々の実装をしてきたためか、かなり誇大化してるんじゃないかと思う。
それはそれで良い事だと思うが、今更乗り換えるのもしんどいなぁという思いは今もある。例えChyrpに乗り換えるとしても。
また、日本(だけ)で異様に使われているらしきBlosxomを未だに使っている意地もあるし、現行ユーザの手前、おいそれと脱落するのも…いや一度もリアルで顔を合わせた訳では無いけど…
実際、Chyrpその他のCMS・Weblogツールを触って感じたのは、自分がWeblogに求める機能って、物凄くシンプルなんじゃないかと思えてきた。
ではそれが何であるかと言うと…

Blosxom、プラス、ページの概念、プラス、Tumblrの一部機能(Photo・引用・リンク)程度でいいんじゃね?

ページを持たせるのは、プラグインを探せばありそうな無さそうな…
他にあるとしたら、同一Blogで干渉しない複数の時系列が扱える機能とか。
多分こういう実装は無いと思う。
自分のTumblrで言えば、現在Tumblrがいわゆる日記ブログとして機能している一面があるが、一方で日々deviantARTの投稿があるため、本当に読ませたい記事がすぐに過去のモノとなる。そういうのを避けるにはTumblrで複数アカウントを持つ方法も考えられるが、そこまでやろうとは思っていない。

逆に個人的にWeblogで不要な機能として…

  1. トラックバック・コメント機能
    何度も繰り返しになるが、ここは大本営サイトなのと、Weblog再構築時のコメントデータの扱いが面倒
  2. 年月関連
    タグで代用(もしくは、同一デザインの別ページ扱い)
  3. カテゴリ
    タグで代用
  4. 入力フォーム
    これには反発があるかもしれないが、自分には不要で、ローカルのエディタで書いて鯖にFTPすりゃいいんじゃね、と

…など。
逆に優先順位は高くないけど絶対に外せない機能としては、RSS、モバイル対応(複数表示可能な表示テンプレートで代用?)あたりか。

こういう風に思いを巡らせると、どうしても独自実装したくなる欲望に駆られる。
Blosxomのプラグインを実装する方向では無く、一からスクラッチした方が早いんじゃないかと。
元データはBlosxomのデータそのままでPHPで実装して、と。
前述したページ機能は、通常のログのディレクトリとは別のディレクトリを作成して、とか、Tumblrの引用・リンクはさほど問題無いけど、Photoに難あり(直リンはマズいか、タイトルはどう扱うか)、とか。
ただ、一番の問題は、プラグイン機能の実装方が良く分からない点。
Blosxomの場合、プラグインディレクトリに存在するファイルを動的にincludeして、イベント毎に呼び出してるみたいだが、それをPerl以外の言語で実装する方法が良く分からない。
逆に言うと、分からないならば実装しない方法もあるし、多分その方がシンプルになるんじゃないかと思わなくは無い。(本当にそうなのか疑問あり)

と、かつて通ってきた道を再び繰り返そうとしている。
もっと他にやる事あるしとか、そもそもブログでやる事って、ブログを構築する事自体が目的じゃなくて(今ここ)、それを利用して何等かの情報を発信する事じゃ、というリミッタを自身に掛けているが、それも何時まで続くかはよく分からないし、来週には全く別の事を考えてるかもしれないので、一応メモしておいた。
もっと時間があれば、と思うが、あったらあったで何もしなさそうな気がする。

2009/07/03

欲望分析

そもそもBlosxomをBlosxomたらしてめてる存在理由って何だろーと。

自分の中では、ログの形式、つまり、RDBを使わずテキスト形式であり、そのテキストは第1行目がタイトルになり、テキストファイルの日付が表示のソート順になる。
…だけにしたいのだが、多分、Blosxom本体も(簡易)フレームワークになっているので、それも存在理由になるかもしれない。

今現在見えている事として、前者のテキストファイル形式である事を実装するのは、さほど困難だとは思っていない。
しかし、後者のフレームワーク的な実装方が見えていない。
ただ…便宜性・拡張性を考慮しての実装だったとした場合、拡張性を考慮せず、一直線に処理を実装する、という方法はどうか? と思う。

2009/07/20


関連するかもしれない投稿

次期主力ブログツールとして、Chyrpを第一候補に挙げ、様々な状況を確認して、問題無ければ(もしくは、代替可能ならば)、Blosxomから乗り換えようと画策中。 とりあえず、年内(2009年)に確認できれば良いか、というスパン。 …ではあったのだが… 2009年年末での状況 下記の記事は、それまで使っていたBlosxomから現在のWordPressに乗り換えるまでの苦悩と葛藤…という仰々しいモノではないが。 当時、自分は次にT
Previous Entry

すぐに忘れるのでちょっとメモ。 補足: Blosxom上でのシステム開発?をクローズしたので、この投稿は基本的には更新されることはありません。 以下の文章は、「Blosxomをカスタマイズする」ではありません。 勿論フレーバーとそれに伴うプラグインの出力レベルでの改修は数多く行なっていますが。 かいつまんで言えば、「WebサービスのRSSフィードをBlosxomの投稿ログとする」改修です。 発想
Next Entry

あわせて読みたい