hiromasa.another :o)

ぼくがブログをはじめたのは、2005/1 らしい。 ってことは、現在 2年半弱くらいでしょうか。 最初のうちはどう書いていいのか分からず四苦八苦しておりましたが、なんとか今日に至ります。 その間、いろいろ試行錯誤があったわけなのですが、ここで突然その手法(?)とかを書いてみます。

ぼくは独りよがりの文章を書くことが多く、個人ブログにしては長文に属するほうだと思います。 自分でも分かっているのです、誰も全部読んでないって（笑）

しかも話題が WP 書いてみたり Linux 書いてみたり、すすきの書いてみたり一見、一定していなく。 ジャンルテーマが決まっているブログならいいんですが・・・。

で途中から考え付いたのが、 wp-tegaki とかスクリーンショットを多く使う方法。 tegaki 文字があればそこに目が留まるし、スクリーンショットは別に興味がない話題でもぱっと目につくので、ぱらみすればそれなりに楽しいのではないかと・・・

というわけで、RSS は全文だしていないのですが、画像全部だすようにしています。 興味があったらでいいので本文までどうぞ。

実は hiromasa.zone は後期のほう、読んでくださる方が多くて、若干窮屈さもあったのですが、こっちにうつってだいぶ楽になりました。

ブログのテーマは一定していないようで実は自分の中では決まっていて、「コンピュータ好きの生態を、プロも腰を抜かす技術を持つ最強のエンドユーザに伝える」で、実は想定読者はいつも Masayan さんとか yutaka さんとかだったりするのですが、お楽しみいただけてますでしょうか。（笑）

では最後に、このブログのテーマを最大限あらわしているとおもわれる、夜 + コンピュータ。 We Love WordPress の写真を再掲。 galleryにのせてみたかったといううわさもあり。

初年度。

２年目。

この前。

Windows Live Writer は選ぶだけで写真加工してくれるので便利であります。

そしてこのサイトの影の Webmaster は言っている。

ぼの「彼はいつもぼののいいなりだYO!。」

うそですごめんなさい。。

WordPress 2.5 から備わっているショートコードという API の研究がてら、画像ギャラリープラグイン、 wp-kougabu をつくってみました。 ショートコードの動作をみるのが主体だったので、かなり動きはやばめのプラグインです。

とりあえず、実動作をみたほうがはやいと思うのでこちらよりどうぞ。

hiromasa.another のぽんこつギャラリーは、いままで コアを改造してやっていたのですが、今回から wp-kougabu で動かすようにしています。

hiromasa.another :o) » Gallery

画像リンクからその画像が使われている記事に飛びます。

68 queries. 0.268 seconds.

一応、プラグインも暫定的にダウンロードできるようにしておきます。 ショートコード API の作成サンプルくらいにはなると思います。

WordPress Plugins/JSeries » wp-kougabu

WordPress の投稿やページにアップロードされた画像ファイルを抽出し、サムネイル表示するショートコードを提供します。

もしも実働させてみよーって方は、サーバリソース的にやばいプラグインなのでソースを注意深くご確認ください。

使い方を簡単に書くと、プラグイン有効化後、ページ作成してその本文に [光画部] と書いてください。

**↑ほんとは "光画部"は kougabu と書いてください**

(書くとここでギャラリーが発動しちゃうので!)

動作を書きます。

• the_content が適応する部分（投稿やページなど）に kougabu ショートコードを書くと、WordPress のメディアライブラリからコンテントタイプ image の画像ファイルをすべてを取得し、整形して本文へのリンク付で画像ギャラリー HTML を出力します。
• ショートコードとは、[ショートコード] とかきます。 wp-kougabu の場合は、kougabu を[]括弧でくくってかきます。
• 取得してくる画像は、サムネイルではなく本物です。 HTML のタグでリサイズしています。 なのででかい画像をアップロードしている方で、大量に画像がある方は転送量がやばいです。 反面、うまく条件をくめば lightbox 系のスクリプトで"びょーん"ができるかもしれません。
• 現在、画像取得条件は最新のものから降順で、数くらいしか指定できません。 なので 1000枚くらい画像があると管理が大変です。 デフォルトでは全部出力します。 DB クエリー数はうちで 70 クエリ弱。 また、前述のとおりネットワーク帯域も消耗します。
• WordPress のメディア管理を利用したプラグインです。 なのでこの管轄以外でアップロードされたファイルは抽出できません。 また、ショートコードをつかうため、WordPress は2.5 以降、画像抽出にサブクエリとか使っているので MySQL は 5 系で、4.1 でも動くかもですが確認はしていません。
• メディアファイル抽出は、WP の標準的な手法で行って"いない"です。 コアと DB 解析でできた、のら SQL でとっています。 なので、WP のバージョンアップとともに動かなくなるかもしれませんし、画像がブログによっては抽出できないかもしれません。 一応、2.5 以前にアップロードされた画像もとれるようにはなっています。

てなかんじで、まだまだalpha版です。

では本題。 ショートコード API とは何か。

以下、kougabu と書いてしまうとギャラリーが動いてしまうので、サンプルは[光画部] と漢字で表記します。

• the_content の適応範囲（投稿、ページ、全文 RSS等）で、[光画部]等の [] で文字列が囲まれた形式、もしくは[光画部]ほげほげ[/光画部] 形式で書かれた形式がショートコードとして機能する。
• ショートコードのWordPress のコアの実装自体は、ただの the_contens のフィルタープラグインのひとつで、ショートコードを発見すると登録されている関数を呼び出し、置換してくれる。
• 登録は、 add_shortcode(’kougabu’, 関数名); という 2.5 で新設された関数で行う。 kougabu の部分が追加されるショートコード名称となり、関数名が実際に動く関数で、これの「return 値がショートコードと置換」される。
• ショートコードは引数をもつことができ、[光画部 属性1="値" 属性2="値"] が 2.5 の新設 API で簡単に取り出せる。 また [光画部]ほげほげ[/光画部] のほげほげ部分もとれる。
  要は、・・・wp-tegaki で苦労したのはなんだったんだ。（笑）

てな感じです。

属性取得部分は wp-kougabu のソースをみるのがはやいですが、

   1: extract(shortcode_atts(array(

   2:     ‘itemtag’    => ‘dl’,

   3:     ‘icontag’    => ‘dt’,

   4:     ‘captiontag’ => ‘dd’,

   5:     ‘columns’    => 3,

   6:     ‘max_width’  => 150,

   7:     ‘max_height’ => 150,

   8:     ’start’      => -1,

   9:     ‘count’      => 0,

  10: ), $attr));

こんな感じにするだけで、[光画部 max_width="200" max_height="200" columns="2"] とかのタグがプログラムから簡単に取得できます。

ちなみに wp-kougamu でこの指定は、横縦のサムネイルを MAX 200px (アスペクト維持)で、2 カラムという指定になります。 で、ソース上右に書いてあるのがデフォルト値です。 標準は横縦のサムネイル 150px の 3カラム。（他の属性もちょろっとありますので、興味のある方はソースをみてください）

というわけで、かなりプログラムを書くのが楽になります。

また、使う側にとっても、たとえばページの中にこういった動的なものを作る場合、以前はページテンプレートファイルを新規につくって、中に <?php kougabu(); ?> とかするか、php exec みたいなプラグインをつかって eval するしかなかったのですが、ショートコードを使うと、ページ作成画面から書くだけですみますので、かなり楽かと思います。

# wp-kougabu で nextpage まじえてページ分割をした図。 ちなみに、いまの属性だけだとなんちゃって分割しかできません。 理由は・・・やってみれば分かります。

基本的に、置換されるだけですので [kaomoji kao="1"] を顔文字画像とかにするプラグインとかはすぐつくれると思います。 難しいことは WP がやってくれるので、PHP の勉強用にも良いですね!

–

逆光は勝利! 頭上の余白は敵だ!

実はドキュメントと動画の融合っていうのって結構面白いなって最近思っていて、近頃、投稿が youtube ずいています。

たとえば、なにか PC 操作的なことでこれは便利！ とかいっても、なかなか伝わらないもので、逆に説明文書が長くなって、書いているほうも本当に伝わっているのだろうかと思ってしまうもの（笑） これが動画なら、いっぱつで伝わるんじゃないか！ってことで、たとえばスペシャルなキーボード操作を今回は例にしてみます。

今回のお題はキーボードマクロ。

キーボード操作こそ周りにやっている人がいてこそ盗む系の技であり、目の当たりにしないとなかなか実用度が分からない部分でもあります。

一応説明を書くと、キーボードマクロはテキストエディタなどに実装されている、「自分のキー操作を記録して再生する」機能です。 たとえば、CTRL +SHIFT + M して記録を開始し、できたところで CTRL +SHIFT + L で再生とかすると、繰り返し操作が簡単に・・・・。 ってもう文章での説明はいやになってくるような機能です（笑）

録画失敗して音ずれしちゃうましたが、雰囲気用に入れています

やっぱり使うと速い？よね？

今回は、<td> をうつところにキーボードマクロを使っています。 一行目の td の入力を記録し、ほかに適応しているという図です。 このようにキーボードマクロは、同じような操作のくりかえしがある場合に非常に有効な操作です。

もちろん、正規表現の置換をつかってやる方法もありますし、ひとそれぞれですが、キーボードマクロは「あんまり考えなくてすむ」という部分で強力な方法といえましょう（笑）

—

さて、いままで動画といえばテレビとかの領域でしたが、これは映像主体でわりと push 式にだらだらみるもの。 インターネットは逆に pull で攻撃的に自分から取りに行くイメージがあります。

また、Web の基本は半リアルタイム。 オンデマンド。 しかもテレビと違って文書を読むことに長けているインターフェースです。 これに好きなときに再生できる映像がまざってくると、なかなか面白いですね。

こう、このエントリも上からながめてみると、動画が途中にあって、複雑な文書では伝えずらいことが、ぽちっと説明がみることができるというのは、なにか可能性を感じます。 たとえば、音楽の説明は楽譜をみるより実際の演奏がいいし、お料理とかだと、まぜまぜしているところみれたらいいし・・・。

最近だと録画や編集もお手軽になってきたので、こういったサイトがどんどん増えるといいな、と思っています。

今日ちょっと事務所で話題になっていた、PC 操作の録画方法。 調べるといろいろあるようで、とりあえずうちに帰って実験してみました。 ぼくは結構スクリーンショットをみるのが好きなのですが、動画もあったらいいなーってことで、 WordPress の動きなどを撮ってみました。

そして youtube にのせても可読性ありなので、使えますね～。

録画には、Windows の 窓録を使わせていただきました。

窓録 ～DesktopCam～

デスクトップやウィンドウの静止画キャプチャ関係のソフトは数多くあるものの、動画として保存できるソフトとなると 数えるほどしかないように思えます。
しかも操作が複雑。これじゃぁ・・・うーん・・・。
それじゃぁ自分で作ってみようということで「窓録」の登場となりました。
Ver.4.0よりオリジナル録画エンジンを採用することで、Windows Media エンコーダーが必要なくなりました。
より簡単に、より高画質、より安定性の向上を実現しました。

起動するとびっくりするのですが、ウインドウがマウスイベント等含めて完全透過していて、その中での様子をマウスの動き含めて余すところなく録画してくれるというすぐれもの。

ぼくは Windows の背景を黒にしているので、黒がデスクトップです。 この中の様子が録画されます。 ウインドウを動かせば録画エリアが変わるという直感的な操作が可能です。

youtube に記載するということで、エリアを 640×480 のアスペクト 4:3 にして録画。 容量は上の動画で 130M ほど。 この大きさだとアップロードが大変なので、 mpeg4 に再圧縮して、13M ほどにしています。 圧縮はいつもの ffmpeg にて。

ffmpeg -y -i 窓録.avi -s 640×480 -b 1600k -aspect 4:3 -ac 2 -threads 2 -vcodec mpeg4 -an -f mp4 窓録.mp4

こんな感じでしょうか。 で youtube にアップロード。

窓録さんは、なんと音声も一緒に録画できるということで、プレゼンなんかにもよさそうですね!!

—

・・・。 疲れているのでオチが思いつきませんでした。（←べつにつけなくてもいい

ぼくはお仕事では PHP とかはかきませんが、趣味で書くときはふだん仕事でつかっているようなツールをつかってかいています。

インターネットをみると、いわゆる Web 屋さんの方はあまりこのような環境をつかっていないみたいですが、ぼくらソフト屋さんのテキストファイル編集ノウハウは割と HTML とか CSS とか PHP にも転用可能じゃないかとと思い、ここに紹介してみます。

ソースコードを集中してかくときの、ぼくの勘所は、

• OS のファイルシステムを意識しないこと。
• シンタックスを機械的に間違えないようにすること。

です。 他のものが見えないようにすること、ミスを少なくすることで効率をあげます。

まー、ツールはなんでもいいとおもいますが、ぼくが普段つかっている Eclipse で紹介します。 いわゆる統合環境ってやつです。

実は Dreamweaver とかでもできるのかな、ともおもいつつ。 とりあえず、以下の環境は Windows/Mac/Linux で動作して、フリーでそろえることができます。

外見はこんな感じ。

ビューの並びとかは好きにできるのですが、左にそのプロジェクトのファイル集団。 右にソースコードとするのが一般的です。 これは逆にするひともいますね。 これで、OS のファイルシステムから必要な部分だけを見えるようにします。 ソース修正中に、システムファイルなんかみちゃだめです。

ファイルの数が増えてくると、さらにそのほかのファイルをみたくないときがあります。 たとえば WordPress でいえばテーマをつくっているときとか。 テーマのディレクトリさえみれればOKです。

そういうときは、該当フォルダを右クリックして「次へジャンプ」。

左は自分の作っているテーマのファイルだけになりました。 これで集中できます。

こうやってテキストファイルを編集していくわけですが、人間には間違えがつきもの。 間違って大事な部分けしちまったーとか、まちがってファイル上書きしちゃったーとか。 間違えはしょうがないけど、お客さんは待ってくれません（笑）

そんなことも統合環境にまかせておきましょう。 たとえば、Eclipse の場合は、バージョン管理システムなんかつかわずとも、勝手にある程度保存履歴をとっておいてくれます。

ちょっと小さくてわかりずらいですが、下のヒストリーペインがローカルの保存履歴。 保存した時間がでています。 ここに残っているものはいつでも戻すことができ、保存のたびに勝手に履歴をとってくれます。 また、保存単位でのファイル比較(diff)も可能で、上の絵のようにどこが変わっているのかを表示させることもできます。

では次はコード保管とシンタックス。 手で書いたら間違うようなことは、やってもらいましょう。 たとえば、CSS。

これは普通のテキストエディタでもできるのありますが、コード保管です。 Eclipse の Aptana プラグインによる機能。 IE/Firefox の対応具合とかもだしてくれます。

また、41 行目をみると×印がついているとおもいますが、これがリアルタイムシンタックスチェックです。 CSS に間違えがあるとエラーを申告してくれます。 いまは書きかけで、CSS が成立していないのででているわけです。 まさにリアルタイム。

ブラウザってやつは、エラーに寛容なので、逆に意図せぬ寛容さ具合でうまく動作しないことがあって、無言の不具合ほど解析が難しいものはない。 ってなわけで、そういうのを未然に防ぐことができます。

同じように PHP のシンタックスチェックの例。

これまた、小さくて分かりづらいですが、 53行目でセミコロンを忘れています。 忘れたまま続きのコードを書いた瞬間に、エラー申告がでてくれます。 ソース中の赤い部分と下のペインに出力されています。

これがない環境の場合、ブラウザで動かしてみてエラーがでてやっとわかることになりますので、非常に効率が悪いです。 リアルタイムシンタックスができる環境では、シンタックスエラーに関しては動作前からバグフリーとなります。

では、セミコロンをなおして・・・、と。

ありゃ、こんどはワーニングでちゃいました。（黄色） いわゆる変数の未初期化ワーニング。

PHP などのスクリプト言語は変数の宣言なしに新しい変数を使うことができます。 これは、同時に変数名をスペルミスしても動作するというのと同意。 そして、スペルミスした変数の中身は"空"です。 意図せぬ値がはいったプログラムは当然うまく動きません。

というわけで、こういったいきなり出現した変数を申告してくれて注意を促してくれます。 スクリプト系の言語でプログラム書くならこれ必須じゃないかなーっておもうくらいの機能です。

というわけで、まだまだ統合環境には便利な機能があるわけですが、今回はこの辺で・・・。

特に下のほうに書いたソースのリアルタイムチェック系は、高度な構文解析がひつようなため、一般的なテキストエディタではできないことがほとんどだとおもいます。

このため、一般的に統合環境の動作はそれほど速くありませんが、1日作業くらいまでいくのであれば、全体的な作業時間を考えたら間違いなく効率はよくります。 よければおためしください。

WordPress 2.5 から追加されたギャラリー機能のテストです。

実は標準のギャラリーショートタグだと、Gallery ページでやっているように、本文にとばすようにはできないのですが、ちょっといじって飛ばすようにしています。

[hoge] 形式のタグをフックする API が今回から追加されているので、いろいろいじってみると面白いかもしれません。

hiromasa.another :o) » Blog Archive » WordPress 2.5 アップグレードと Gallery

ぼくがいいなと思ったのは、エントリにつけたメディアファイルを WordPress からうまいこと管理できるようになったことです。 実は構造的には前からできていたのですが、ユーザインターフェースが改善され、また API も使いやすいものになっています。

てなわけで、画像をはってみます。 Gallery ページの下に画像が追加されるはずです。（逆順のほうがいいかな。。）

今回のアップローダは、JPEG の情報を取得する機能もあるようですね。

xmlrpc 経由のアップロードでも正常に動作しています。

てすてす。（←一応、オチ

WordPress 2.5 がついにリリースされました。

2.2/3 は経過感がありましたが、2.5 は 2 系の集大成といった感じで、うまくパッケージされたというのが第一印象です。 実装仕掛中的機能がブラッシュアップされ、また面白そうな機能も追加されています。

WordPress | 日本語 » WordPress 2.5

6ヶ月間のコミュニティによる努力が、WordPress 2.5 というすばらしい成果になりました。バージョン 2.5 の数えきれないほどある改善点は、ほぼすべてが皆さんのフィードバックによるものです。例えば、複数ファイルアップロード、プラグインの簡単アップグレード、ビルトインギャラリー、カスタマイズ可能なダッシュボード、パスワードの salt 使用および Cookie の暗号化、メディアライブラリー、コードに干渉しないリッチテキストエディター、同時編集保護、フルスクリーンの投稿画面、投稿記事およびページ検索機能などです。

まず目をひくのが管理画面のデザイン変更です。

2.3 までの管理画面はシステム的で無機質なものでしたが、今回は角丸などをつかい温かみのある感じにリニューアルされています。 また、メニューも整理され分かりやすくなったと思います。

うわさのカラースキームは、上記、ユーザ->あなたのプロフィールからクラシックにも変更できます。

初めての人に、WordPress をすすめるときにはやや使い方の説明が大変でしたが、今回のユーザインターフェース変更でかなりよくなったような気がします。

新機能のチケットについては、おでさんがひろってくださっています。

WP 2.5の新機能 - チケット拾い読み « Odysseygate.com

というわけで、WordPress 2.5の新機能をチケットから拾い上げて見ます。細かい改善とか意味不明なものとかもいっぱいあるので、わりと興味のあるところ中心で(笑)。間違い等あったら教えてください！

ぼくがいいなと思ったのは、エントリにつけたメディアファイルを WordPress からうまいこと管理できるようになったことです。 実は構造的には前からできていたのですが、ユーザインターフェースが改善され、また API も使いやすいものになっています。

コアチームにからユーザに対して画像ギャラリー実装が提供されています。

Using the gallery shortcode « WordPress Codex

In WordPress 2.5, the Gallery feature allows the option to add an image gallery to a Post or Page on your WordPress blog.

The 【gallery】 shortcode is used in a Post or Page to display a thumbnail gallery of images attached to that post. It can be used in its simplest form like this:

これはぼくも昔からやってみたかったことなので、早速 .another にもつけてみました。 メディアとエントリの対応がとれているという部分にいろいろな可能性を感じます。

hiromasa.another :o) » Gallery

画像リンクからその画像が使われている記事に飛びます。

よければご覧ください～。

tegaki もショートコードだなと、ふとおもった。。。

(2008/03/30 追記あり)

RC 3 までいっている WordPress 2.5 ですが、現在のところをタグ管理について不可解な動作があるようです。 ぼくも気になったのでちょっと調べてみました。

わーどぷれすっ！ » WP 2.5 のタグ付け機能のバグ

2.3 からひきづってる（と思われる）カスタムなタグスラッグを設定しているときのタグの重複問題が 2.5 RC1 でも解決してないことに今頃気づいた。

WordPress は仕様書なんてないので、どの動作が正しい動きなのかわからないところもあるのですが、tai さんご指摘のようにユーザーインターフェースと見た目の動きは、おそらく間違いなく開発元も不具合と認識するような動作です。

ポイントとなるのは (wp)_terms というテーブル。 なんとか DB 設計書から仕様を読みほどいてみます。

Database Description/2.3 « WordPress Codex

Table: wp_terms

wp_terms は以下のような形をしています。

name カラムにタグ名、slug カラムにスラッグ値がはります。

term_id はプライマリキーで、id 番号がはいります。 じゃーこの番号が、何をキーにして増えていくかというと、 slug が UNI (ユニーク) なので slug になっています。

ってことは、

• name (タグ名) は重複を許す。
• slug は一意である。

という仕様に見えます。

ここで、いまの不具合に目を向けると、

• 1. 新規タグ A (name) を作成する
• 2. A の slug を変更する
• 3. 再びタグを add するときに A を指定する

こうすると、A タグが 2 つできてしまうという現象です。 実はデータベースの構造だけをみるとこれは、

要は slug がキーになっているので、違う slug は別タグ(term_id) 扱いです。

ユーザインターフェースがおかしいのはおいておいて、仕様だとするとなにをしたいのかよくわからないですが、たとえば

plugin と addin というタグを extention という slug にまとめることが可能。

という動きともとれます。

もしこの DB 仕様のまま何かをなおすとすれば、ユーザインターフェース側を、

タグ add 時点に重複する name をみつけた場合は、どの slug ふるのかを決めさせる。

と変更することになると思います。

まぁたぶんこれはなくって、単純にデータベースの設計がおかしいのだとは思いますが。。（笑）

てなわけで、tai さんがチケットきってくれたので、こちらで真相がわかるに違いありません。 また、yuriko さんが折衷案のパッチをなげてくださっています。

Yuriko.Net: WordPress で日本語タグ重複問題解決パッチ案

とりあえず、taxonomy が post_tag の場合はタグ名でも比較チェックを行うパッチを考えてみました。手元のテストでは重複問題には対処できましたが、副作用がどれだけあるかは不明です……。

#6313 (When you have a custom tag slug, it will duplicate tags) - WordPress Trac - Trac

When you have a custom tag slug that is different from the tag name, you will have duplicate tags after saving a post with the tag.

さぁ、真相はいかに。

追記。 ぼのさんより指摘あり! いろいろ話していて、

• wp_terms の name はテーブルとしてはユニークにならない。 カテゴリ名その他とかもはいるから。
• なのでこのテーブルとしては slug ユニークでよい。
• でも、それだと wp_taxsonomy の存在意義がなぞ。

うーん、そういうことかー。 wp_taxsonomy もみないといけないということなのだろうか、、どうしたらいいのか良くわからなくなってきてしまいました。。 ２時間くらい考えることが必要そう。（笑

ぼのさん、まかした。

何を隠そう、いわゆるサイトのフィード配信の実装がというのは、どうもぼくの好みに動いてくれないのです。 考えれば考えるほど釈然とせず。 ちょうどぼのさんも、悩んでらっしゃるようでしたのでトラックバックしてみます。

power source* » [アンケート] power source* のフィード配信形式

そんな中、今月中にリリースされるであろう WordPress 2.5 では、フィード設定で「全文」を選ぶと、more（続きを読む）以降も掲載される運びとなりました。そう、完璧な全文配信となるのです。

しかも、本当は、記事を更新したらそれを再送信したいとさえ思っているのです。^*1

# コピペで手書き文字までもってくる Windows Live Writer すげー。（余談

ぼくがおもう、RSS 系情報配信の問題点は、

• 完全な配信管理するなら、サイトの全"記事"を１ファイルで配信しないといけない。 RSS はただのファイルなので、初期状態、その人にとっての新着なんかわかりようないので、やるなら全記事ださないと不完全。
• push 配信じゃないので、情報の伝達がクライアント（フィードリーダ）依存である。 記事の修正がいきわたらない可能性を常にはらんでいる。 たとえば初期記事をとってキャッシュされ、その後あまり更新されないような実装だとかなり寒い。

という感じです。

このようにフィード配信はかなりいーかげんな世界で動いているので、情報の伝達手段としてはあんまりあてにならない方式になってしまっていて、自分てきには、

あ～、RSS なんかなんとなく最終更新の通知がいけばいいや。

みないなイメージでいます。

そんなこんなで考えたあげく、うちは抜粋配信。 単純に、みんなに ping うつだけじゃつまらないということで、抜粋文をつけているイメージです。 画像とかつけて遊んでいるのはそのせい。

ぼくは投稿後、割とすぐに記事を修正することが多いので、特に Google Reader とかは初期投稿を超速でとりにくるので、全文配信してると修正前の誤解をあたえてしまう内容が配信されてしまうという怖さもあります。 キャッシュされるとおわるので。 これはちゃんと推敲しろって話ですが（笑）

ほとんどの方は、RSS を時系列の新着としてみていて、記事をクライアントに配信、タンキングするという機能としてはみていないと思います。 また、フィードリーダーも基本的にはニュース的にどんどんみていくインターフェースになっています。

なので、ぼのさんが指摘されているように昔の記事の修正で内容が "age" されてくると、わりとハテナ？となってしまいます。 もちろんフィードリーダも、あとでその記事を活用できるようにタグをつけ、URL ユニークで記事を更新タンキングする機能はありますが、活用している人は少ないのではないでしょうか。

重要な情報はブックマークして本サイト側をみると思います。 これはおそらく、無意識に RSS の記事配信やフィードリーダーのタンキングを信頼していない証拠です。

というわけで! ぼのさんのサイトのような、辞書的に調べ物ができるレベルの記述があるサイトさんは、

more までがよい （←今コレ）

がよいのではないでしょうか。 更新があればサイト側を拝見します。

とアンケートに答えてみました。

ちなみに最後にぼくの RSS リーダの画面です。

抜粋すらひっこめて、全部本サイトで拝見しております。 なんかやっぱりテーマの中で見るのがすきなのです。

意味と表現の分離なんか、コンピュータの方式とか仕組みのメリットだけのはなし。 本質的にはできないこと。

MSPゴシックで HERMES とか CHANEL とか Apple とかのロゴ描かれてたら、"意味"ないよね？ あたりまえですがデザインにも当然多大な意味があります。

インターネットの有料レンタルサーバの初期一時代を築いたミクストメディアさんがピンチに陥っているようです。

ここのブログの"前身" hiromasa.zone はこのレンタルサーバにホスティングしているサイト。 ここ hiromasa.another にうつってからも、データを残して稼働中でしたが、今月に入ってから Web サーバと MySQL のコネクションがとれなくなっており、閲覧不能の状態でした。 また、15日前後からは POP サーバが落ちたようです。

運よく、 .zone.ne.jp の Web サーバ自体は生きています。 他のサブドメインに関しては、ダウンしてしまったところもある模様です。

この関係でメールアドレスが使えなくなっています。 昨日も書きましたが、これをごらんになられた方は、大変お手数ですが連絡先アドレスの変更をお願いいたしたいと思います。

hiromasa.another :o) » Blog Archive » 【重要】業務連絡（メール不通です）

どうやら、SMTP は生きていてしまっているようなので、送信すれども返事がない状態となっている可能性があります。

お心当たりの方は大変申し訳ないのですが、

h1romas4@gmail.com

まで再送お願いいたします。

hiromasa.zone の Web に関しては、リンクをかなりいただいていましたので、URL をそのまま 301 リダイレクトをして、サイト自体をここ .another と同一のコアサーバにもってきました。

hiromasa.zone : o)

http://zone.maple4ever.net/

301 リダイレクトしていますので、現在リンクはそのまま生きます。（ただミクストさんが今後どれくらい"もつ"かはちょっと未知数ではありますので、もしも必要なブックマークなどありましたら変えたほうがいいかもです!）

一応、WordPress を使っているサイトでの URL 変更を伴うサーバ間の引越しの方法などを書いてみます。

• ファイルを元サーバから FTP でフルバックアップ。
• MySQL のデータを元サーバから、phpMyAdmin などでフルエクスポート。
• フルエクスポートした SQL ファイルをテキストエディタで開いて、たとえば今回の引越しなら、http://hiromasa.zone.ne.jp/ 文字列を http://zone.maple4ever.net/ に置換する。（画像等のリンクぎれや、自サイト内部のリンクを引越し先にしてしまう）
• 先サーバに同一バージョンの WordPress を通常インストール、セットアップ。（いきなりプラグイン、作成テーマはいれない）
• 先サーバに、先ほどフルエキスポートしてリンクを変更したファイルを、インポート。
• wp-content/uploads など、画像系を元サーババックアップから、先サーバに FTP でアップロードする。 パーマリンクを使っているのなら、管理画面から再設定する。
• これで、default テーマ WordPress でデータだけ引っ越された状態になるので、データが移行されているかを確認する。
• プラグイン、テーマファイル、元サーババックアップから wp-contents/ に格納して動作確認する。（プラグインのアクティブ状態は復元されるハズ）

という感じになると思います。 URL の置換部分がキーポイントですが、、単純置換だとまずい部分もありそうですが、あんまり考えると面倒なのでこうしています。

.zone -> .another の引越しの場合は、WordPress 以外、自作の CMS みたいなプログラムで動いているページもあり、もうちょっと手間がかかっていますが、PHP 4 -> 5 であったにもかかわらず、いくつかの文字コード系の不具合だけで移行できました。

—

1999年とか2000年とか、有料レンタルサーバがあまりなかった中、また Apache の設定が非常にあまく各社手探りだった中、 いまでは当然の CGI に suexec をきちんとかぶせるとかしていたミクストメディアは、いわゆるハッカーグループに好んで使われたサーバでした。

おそらくサーバ管理者の方は技術に長けた方だったと思われます。

いまならもう書いていいと思いますが、 hiromasa.zone の MySQL は人の使っていない速いものに移してもらっていますし、Web サーバ側も RAID5 の上位のサーバにいれてもらっていました。 言葉にはならない、技術者どうしの空気をメールで楽しんでいました。

ミクストメディアのなかのひと何とかがんばってください - 地に足がついている日記

2chで、ミクストメディアのなかのひとがんばってと書いている人の多くは、老舗個人サイト運営者じゃないかなあと思います。今はワンクリ、アングラ専門などと悪徳業者呼ばわりですが、ミクストメディアは、インターネット創生期、いろんな人を助けてくれたとても良い会社だったと思います。ですから、是非なかのひと、がんばってください。

同感です。

そんなこんなもあって、ぼくも８年か９年使っていましたが、今回は技術担当者が不在になるという事態で最後を迎えることになりそうです。 （うわさによると身売りするとか、なんとか）

ミクストつかっている全盛当時のサイト、結構今も記念碑的に残っていましたが、先ほどアクセスしてみたらダウンしはじめているようです。

一世代を築いたサーバとともにおちる当時のサイトをみながら、hiromasa.zone に

rm -Rf public_html/

して、ちょっと不思議な気分になった本日でした。