RSSって最近よく聞くようになったけど、結局なんなの？ RSS使うとどんなことが出来るの？ ていうか、便利なの？ そんな疑問を良く聞くわけで、その度にわかったようなわからんような答えで説明してるんだが、 （専門用語を全く使わずに概念だけ説明するというのは非常に難しい） そんな方に朗報。 ITMediaの記事内で、 RSSとは何かから始まって、今後どうなっていくのか、みたいなところが、 上手にまとめられているので、 RSSに興味のある人は一度読むべし。 ITmedia エンタープライズ：特集：第1回 RSSの要約配信はさらに加速する
CHEEBOWさんの『ヒビノアワ』より。
ヒビノアワ: amaztype すでに、ご存知の方も多いと思いますが……。 amaztype楽しいっすねー。 これは、入力した文字を、Amazonで扱っている商品の画像で、構成して表示しちゃうと言うもの。 だんだん、文字が形になって行くのを見ているのも楽しいです。すんごいなーこれ。 amaztype。 FLASHで作ってあるんだけど、自分の文字が構成されてく様子が楽しいの。 知ってるジャケや、印象的なジャケが、キーポイントに配置されると、 よっしゃ、とか思いつつ、 一瞬後にはくだらんジャケが追加されてたり。あああ… ジャケをクリックすると拡大されて、moreinfoで該当商品のページが呼び出せたり。 かっこいー ロゴ作るのに使えそうだけど、 そんなコトしたらとてもじゃないけど、著作権問題をクリアできそうにありません（苦笑）
最近、ようやくというか何というか、『文章の一部強調』をするようになってきました。 淡々と読ませたい（ほんとのこと言うと淡々と書いてるだけで読ませる気はさしてない）文章も有れば、 何となくリズムを持って読ませたい文章もあるわけで。 強調（太字、フォントサイズ拡大、文字色変更など）は、 その後者の方で、よく使うんだけど、ただ太字にしても、どーも、物足りない。 うーん。 かといって毎度フォント拡大するのは正直ダルイので（ボタン作れば良いんだけど）、 太字だけで済ませてました。 が、以前、サザエさん＋iPodで紹介したサイト、Truth Is No Wordsに、 面白いアイディアがあったので、それを拝借。 サイトを見てもらうと分かるんですが、 太字の文字の下に赤いフェルト風赤線が引っ張られている。 なんだかレジュメみたいだけど、これは凄くいいなぁ、と思ってソースを見てみたら、 なんと、背景画像でした。 うーむ。恐るべし。 strongタグに対してこれを設定してやることで、 こうなります。 Truth Is No Wordsさんのログを探してみたんですが 特にこれと言ってみつからなかったので スキンの元々のデザインなのかなぁ… さすがに画像をそのまま使うのは気が引けたので、似たような画像を作って下線としてみました。 どないでしょ？
PHPでは、ファイル読みだし・書き込みの際のロック関数が、 Perlに比べて強固（あくまで体感レベルの話だが）なので、 よくあるような、ロックファイルやディレクトリを用いたロック機構が導入されることは少ない。 実際、仕事で使用しているアクセスプログラムでも、特別なロック機構は装備していないが、 1アクセス/8秒というような状況でも（または意図的に更新ボタンを連打しても）データが飛んだことはない。 Perlで作成していた頃には、アクセスが集中すると飛んだことがあったから…ずいぶんと違う。 （もちろん、プログラムの構成スキルも上がっているのかもしれないが） とはいえ、全く何も対策をせず、関数だけに任せっきりと言うのではさすがに心許ない。 というわけで、既存のロック機構を補強する策を模索してみた…が。 正直言って、これと言って見当たらなかった。 まぁ確かに、flockが使えないPHPというのもかなり限られてくる（バージョン3.0.7未満）し… しかし、指示をより正確にして、機構を補強するという意味で、 以下のようなページを発見したので、転載しておきます。 PHP:ファイルのロック方法（排他制御）の例:WEB Artisan – ウェブ アルチザン んー、このままでいいんかなー… 有名カウンターとかどうしてんだろ？その辺。
文法に照らし合わせてみて正しいプログラム（ページの記述含む）を、 『Validである』という言い方をする。
valid 【形-1】 有効｛ゆうこう｝な、通用｛つうよう｝する 【形-2】 正当｛せいとう｝な、根拠｛こんきょ｝のある、主張｛しゅちょう｝の正しい、事実｛じじつ｝に合っている、妥当｛だとう｝な、確かな、穏当｛おんとう｝な、正当｛せいとう｝な手続き｛てつづき｝を経たblogが検索エンジンの検索結果を席巻して久しいが、 結局その理由も、blogの吐くHTMLが正しいから、ということに他ならない。 今仕事を手伝ってくれてるスタッフが、いわゆる『ホームページ作成ソフト』を使ってるのだけど、 その吐くHTMLのひどさと言ったらない。 もちろん、そのスタッフの仕事はしっかりしてるのだけど、ソースを眺めてしまうとね… あちこちに無駄タグがあったり、 改行の取り方がまちまちだったり、 font, b, i ,uタグ、tableタグ使い放題だったり、 もちろんそれだけでinvalidとは言えないけれども、 良いところと言えば、インデントをきちんとしてくれる…くらいか。 タイトルを入れるかどうかも明示的ではないし、うーん。 まぁ、作成ソフトは極端な例にせよ、 検索エンジンてのは、一般的にHTMLはValidではない、という視点に立って DBを構築してきたような気がする。 そりゃそうだ、人が書くだからどうしたって、人によって形式はまちまちなんである。 一方でblog（というか、CMS一般に）は形式自体はソフトにお任せだ。 全てほぼValidに従って整形してくれる。 ページ内にリンクも多いし、収集しやすいのは当然なんである。 何かを検索していてblogがヒットするというのは… 便利なことも多いが、必ずしも便利ばかりでもない。 blogのエントリは多くの場合、このサイトのように、メモのように書き捨てられている。 ひどい人になると、ニュースソースしかなく、外から見るとただの噂にしか見えない。 そんなサイトがいくつも引っかかってもねぇ…Validな検索結果とは言えない。 何か、新しいアルゴリズムを発明するべき時期が来たんでは…
ブラウザの持ってるステータスの中に、『参照元』ってヤツがあります。 要するにどのページからここへ来たのか、というデータで、 例えばあなたは、 から来ました、ということが分かるわけです。 NortonInternetSecurityを入れていたり、お気に入りから表示させると、 参照元が表示されない（ブロックまたは存在しない）ので、 上は多分空欄でしょう。 まぁ、別にそんな技術的な話がしたいわけではなくて、 参照元ってのを英語で言うとREFERER（リファラ）と言うんですが、 この綴りがどーも微妙で。 昔はこれ、REFERだと思ってました。 REFERじゃ動詞じゃん(refer to A: Aを参照する）、とすぐ気付くことだけど。 REFERの名詞はREFERENCE。 あれ？ 参照元の方はREFERERで、最後ERが繰り返してて、 いくつ繰り返すのか分からなくなったりする。 人によっては、REFERRERだと思ってる人もいるみたいで、 検索するといくつも出る。 REFER?REFERER?REFERRER? あぁ、書いててわかんなくなってきた。 正解はREFERER、ですね？（多分）
以前、以下のようなことを述べた。
HTMLの機能が既に一般人の満足できる水準に達している現在、 （この場合、ユーザビリティやアクセシビリティは考慮していない、表現したいことが出来るかということ） それ以上の後継言語が必要なのか、果たして一般化するのか、正直にいうと疑問だ。これはこれで間違っていない部分もある、 『私のホームページ』が欲しいライトユーザには、今も昔も関係のない物だ、 しかし、『ユーザーにとって』必要がない、という論点は間違っていた。 訂正し、改めて理由を挙げたい。 そう思ったのは…Ajaxを知ったからだ。 僕もよく分からないが、簡単にいうと、 JavaScriptと、XMLを使って、WEBベースでインタラクティブなアプリケーションを作り上げよう、 ということらしい。 上記、Ajaｘに関する和訳サイトで示されている2サイト、 Google Suggest[beta]と、Google Maps[beta]とが、 Ajaxのユーザに与える影響を、端的に示している。 （僕も含めた）一般ユーザはこれは作りはしないが… その技術の恩恵にあずかることにはなるだろう。 『私のホームページ』を作るのにも、より便利なアプリケーションが出てくるかもしれない（ちょうどblogのように） そう考えると、新しい言語体系を策定し続けることは決して無駄ではなくて、 ライトユーザ向けに下位互換を保つ必要がある、というのは事実ではあるけれども、 （そしてそれ故に、言語そのものの進化は体感的ではないかもしれないが） いずれ一般化するときが来るのかもしれない。 まぁ…たとえ100年経ったとしても、 人類の半分がプログラミングが出来る世界になる…とはとても思えないけれど。
存在は知ってたんだけど、仕事のサーバでのPHPのコンパイルが上手くいかなかったこともあって、 実際には使っていなかった、GD。 でもまぁよくよく考えたら、コンパイルでこけてたのはFreeType（日本語関連）だったので 別に画像の処理に関しては問題ないでしょ、ということでやってみた。 そもそも、NOBODY:PLACEはレンタルサーバだし、 その辺のインストールは問題ないわけだからね（多分） 基本的には、 1) 画像をデータとして読み込む 2) 画像データを加工 3) 保存するための新しい画像データを作成 4) 加工済みデータをそこへ放り込む 5) 出力 という認識でよいかと。 出力先がブラウザなら、アクセスの度に表示するプログラムになるし、 ファイルなら、サムネイルを作成するプログラムになる、と。 （この辺の関数に関しては、マニュアルの『XLI. イメージ関数(image)』に詳しいです） 追記に、このサイトで実際使ってる、（かなりいい加減な）プログラムを載せておきました。 幅・高さを検討しているところと、画像の形式によって使う関数を振り分ける処理が入ってますが、 まぁ、基本的には大したことやってません。 決められた幅（または高さ）まで画像を縮小するだけですな。 ちなみに仕事でこれをどう応用したかというと、 本来の目的の前の試験段階として、携帯でジャケ写が見られるようにしてみました。 ジャケ写のファイルは全てjpegで、かつジャケ写によってはファイルサイズがまちまちなので、 今まで実装は不可能だと思ってきたんだけど… GD使って処理してやれば簡単じゃん、ということに気づき。 しかし、なんだろう、加工済みの画像データ長を取得する関数が見つけられなくて、 本当は、ファイルサイズから縮小処理をしたかったんだけど無理なようで… 仕方無しに、現在は試験版として、幅で縮小処理してます。 （pngで出力するとやたら大きくなるのが気になるけど） てか、気付きつつあるんだけど、これ使えば、画像連結用プログラム(gifcat.php)使わなくても 一つの画像としてカウンターを表示できるんじゃ無かろうか？ しかも文字でも出来るんじゃなかろうか？ そしてフォントも変えられるんでは。 うーむ。時間見つけてやってみます。 GD、便利。
先日、RSSファイルにスタイルシートを適用してみました。 その際に、『概要（<![CDATA[ … ]]>）のタグが全部そのまま書き出されてる』わけで、 気になるなぁ…と言っていたのだけど。 それをなんとか解消する策を発見。 試験的に導入してみました。 とはいえ、XMLはおろか、XHTMLの知識も十分ではないので、 どっから手を付けて良いのかわからない。 どこか、いじりやすいサンプルを提供してくれているところはないか… 探してみると、発見。ありました。 HepCat Dev and Test: RSS 0.9x,1.0,2.0,Atom 0.3すべてに対応したXSLT 基本的には、自社開発されている、『HepCat』というRSSアグリゲータ（多機能なRSSリーダーというべきか。 リードするだけでなく、情報を効率よく取得、加工など様々な用途に利用できます → 用語） の出力に対応させたもので、決してMT用というわけではないんだけど、XMLはXML。 MTの吐き出すRSSファイルがvalidである以上、利用可能です。ハズ。 実際に適用してみる。 適用方法は、普通のCSSファイルと余り変わらない。 極めて簡単に書くと、 1) XSLTファイルをダウンロードし、適当な場所にアップロード。 2) RSSファイル内に、XSLTファイルを利用する宣言を記述する 以上。 宣言文は、XSLT用ということで以下の通り。
<?xml-stylesheet href=”ファイル” type=”text/xsl” media=”screen”?>CSSと同様に、保存、再構築。 これだけです。 このサンプルファイルが非常に良くできているので、 適用対象が、RSS1.0でもRSS2.0でもatomでも、問題ない。 ただ、このサイトがBulkfeedsを利用していないせいか、 コメントアウトしてある部分でエラーが表示されてしまったため、 該当部分を削除しました。これで問題なし。 できあがったファイル。 XSLT適用済みのRSSファイル(RSS1.0) 色や構成など、全くデザインをいじっていないけど、この完成度。遙かに綺麗。 RSSってのは、機械的処理が主流だけど、 元々は、サイトにある情報の概要をまとめることを目的に作られたんだし、 人への見え方を気にするのも、それはそれで筋は通ってるのかもな、と思いなおした次第。 それにしても、そろそろ、XML（少なくともXHTML）は勉強するべきかもなぁ。 XHTMLで知ってることといえば、タグは全て小文字、終了タグが必要、宣言文が必要…くらいだし。 HTMLの機能が既に一般人の満足できる水準に達している現在、 （この場合、ユーザビリティやアクセシビリティは考慮していない、表現したいことが出来るかということ） それ以上の後継言語が必要なのか、果たして一般化するのか、 正直にいうと疑問だが、プロとしてはやはり分かってないといけないようだ。 ことさらに必要性を説いて人に押しつけるつもりは、全くないけどね。
まずは、百式をご覧いただきたい。 百式は、毎日ひとつずつ、海外のドットコムサイトを紹介する、というページなのだけど、 そのエントリの一番下に、そのサイトへのリンクが貼ってある。 パッと見、何の変哲もないリンクなのだけど、これがCSSで制御されている。 目鱗だったのでメモっておく。 どの部分が制御されているかというと、表題にもあるとおり リンクの前に付けられた、矢印の付いたアイコン。 これは実は画像ではなくて、アンカーに設定された背景画像なのである。 通常、この手のアイコンを貼り付けるには、 実際に記述する部分でアイコンを画像として埋め込むのだけど、 もし、そのアイコンを変更したくなったら？ …当然だが、全てのエントリを書き換える必要がある。 MTであっても、テンプレ編集→全エントリ再構築ということに… しかし、CSSで制御していれば、CSSファイルを書き換えるだけで対応できる。 小さなことだがこれは案外重要。 これを参考にして書いたこのサイトでのCSSは以下の通り。 アイコンを付けないリンクと区別するため、classを付与してある。
これを実際に表示させたのがこれ。 リンク なんとも不思議な感じだが、これで綺麗に見えているのだから良いのだ。 あ、言うまでもないけど、例えばリンクテキストが2行にまたがったり、 paddingの数値と画像ファイルの幅が上手く合っていなかったり、 行の高さより画像の高さが大きかったりすると、上手く表示できないのでご注意のほどを。 ちなみにうちのサイトでは、MTのJavaScript関係をいじって これ用の編集ボタンを、エントリ投稿ページに追加してあります。 非常に便利。タグ部分<a href=”” target=”_blank” class=”OutLink”>リンク</a>CSS部分a.OutLink{ padding-left:15px; background:url(画像ファイル) left no-repeat; }