2006年6月アーカイブ

とりあえず、カテゴリは大分類で、タグは内容に沿ったキーワードとして使おうかね。

現状は、カテゴリが全く機能していなくて、アホなほどに煩雑化してる。なので、カテゴリは大きなハコとして整理し直すかも。

でも、700以上のエントリについていちいち変更するのは面倒だ。カテゴリの一括置換って出来るんだっけ?出来るなら問題ないね。タグはもう新しいエントリにだけつける。目についた古いエントリにはつけるかもしれないけど。

XML-RPC の仕様を確認してタグ操作が出来るようなら、SBSでつけられたタグをMTエントリにもつける様なスリプと書いて対応?9割以上のブックマークされていないエントリは放置かな。

RSS とか Atom の category にタグが使われているのはなんでだ?いや、カテゴリも category に含まれてるからいいといえばいいんだけど、ちょっと意味合いが違ったりしないかな?まあ、テンプレいじれば変えられるけど。問題は無いけどちょっと気になる。

LDR のレートって何?

巡回間隔を決める要素だと思ってたんだけど、ただ単にランキング統計用のデータなの?

レートでフィルタして低いレートのフィードは未読アイテムがたまってからまとめ読みとかはしないので、巡回間隔をレートでずらして更新通知を調整してほしい。

実際どうなんだろう。ヘルプを探してもよくわからないし。Lの外にあるまとめサイトとか探した方がいいのかな。意味分からん。

MT3.3 update

スタイルとか、埋め込んでいた JS とかはまだ。またダウンロードリンクとかぼろぼろになってるかも。

mt-static の URL を間違えてアップデート作業が動いていない事に気づかずずっと待ってたりしたけど、なんとか解決。

Emacs(mapae)からカテゴリ取得に失敗した。。。仕方が無いので、久しぶりにMTでポスト。

このブログ色々不具合出てるだろうな…。しばらくは調整の日々です。

SBS って何だろう

Livedoor クリップ
出ました。

いい機会なので、また SBS について考えてみる。例によってネタですが…。

ブックマークをブラウザからWebに

ブラウザのブックマーク管理インターフェースは大量のブックマークを上手く捌けない物が多い。『大量のブックマーク』を捌く事が必須である SBS を利用すれば、その辺最適化されたインターフェースを期待出来るかも。
ブックマークをWebに置く事で、どこからでも同じブックマークを利用出来る。

ブックマークのメタデータ(意味付け)

ユーザのブックマーク行動の結果、ブックマークに複数人による意味付けがなされる。ユーザ個々につけられたタグなどのメタデータや、機械判断による鮮度/クリックレートなどによる重み付けなど。人と機械による『Webコンテンツの評価付きカタログ』が作り上げられると言えるかも。
『ブックマーク=お気に入り』という考えでいけば、少々違和感があるかもしれない。ブックマークの際にいちいち『評価』するのは面倒。分類して整理するだけであれば、全て機械任せで間に合う。
『溜め込んで効率的に引き出したい』という目的と、『集合知(?)の結果作られるカタログを利用したい』という目的があるのかもしれない。

引き出しらくちん

ブックマークデータはメタデータの集合と言えるので、ブックマークの集合もメタデータフォーマットとして発行可能。フィード形式などで出力する API が用意されていれば、ビューを外部アプリケーションに依頼して SBS がサポートしない目的のためにブックマークデータを利用出来る。
入力にしても同じで、メタデータを受け取るための API が用意されていれば、外部アプリケーションで用意された類似データを SBS 側に還元する事も出来る。
データが行き交う交差点と言えるかもしれない。

SBS という形態は踏み台になるかも

大きなところから小さなところまで、実装が簡単な仕組みなので乱立している印象がある。『ブックマーク』というインプット方法はあくまで、インプットの1手段であって、『ブックマーク』が必須ではない。結局、出来上がってほしいものは『Webコンテンツのインデックス』だろう事を考えれば、各 SBS はいずれデータを吸収されるだけの踏み台サービスになるのかもしれない。内部的に重要なデータは隠すのかもしれないけど。

SBS はプロデューサー(?)が必要かも

とても個人的な感想なんだけど、いまいち何をしたいとかさせたいかが分からない。ただブックマークさせてブックマーク状況を中継して。digg は人気みたいだから、その辺を上手くやれてるんだと思う。他の SBS も大きなところは情報が集まるから、それを参照する目的で集まってもいるとは思う。
検索エンジンの劣化コピーで終わるのはもったいないと思うので、もう少し売り方というかその辺考えても面白いのでは?Google は世界的だけど、SBS は開発者の生活エリア限定なイメージ。シンプルなのはいいけど、なんだか寂しいかなと思う。

なんだかんだで、SBS はブックマークで終わればいいのかも

ソーシャルデータを活用して『目的』を持ったサービスを作る場合に、SBS のデータを利用する事になるのかな。SBS はブクッマークさせればいい?
でも、SBS 利用者層がかなり限定的な印象があるので、売り方変えないと集まるデータも偏ったものになりそう。そんな気がするのは僕だけですか?

夢を語る

ソーシャルサービスは専門分野を持つべきかもしれない。そうすれば目的がはっきりするし、濃いデータを集める事が出来る。で、ハブ的な役割をしてくれるソーシャルまとめサービスが出来て、その中で擬似的に管理作業を一元化するとか。一般化しすぎてぼんやりするくらいなら、割り切って突き詰めていくのもいいと思う。得意分野が無いなら、まとめサービスを狙うとか。

というわけで

全てフィクションです。

楽しい算数

結城浩著『プログラマの数学』を読んでお勉強中。

算数ドリルの購入を真剣に検討中。MacBook より優先度高め。鶴亀算解けるかな?

自宅 Mac(G4 1GHz)が重たく感じてきたので、MacBook 購入を本気で考える。

まず、Parallels のおかげで、快適っぽい仮想マシンを用意できそうなのは大きい。Parallels は IntelMac だけっぽいので、乗り換えざるを得ない。G5 買って G4 に Linux 入れてもいいけど、そろそろノートで出先で作業とか考えてもいい頃。

10.5 を待つべきだと思う。MacBook が出たてで、しかも Tiger 焼き直し。これは危険。なにが危険って、Apple は2、3回目のマイナーチェンジ(?)モデルがいいから。性能が上がって安くなるのは常套手段。10.5 が出るくらいには環境も整ってくるかもしれないし。

仕事では使えないのが残念。性能とかじゃなくて、MS Office が必須なので無理。Open Office で問題が起きなきゃいいけど、Project とか Power Point が正しく更新出来るか分からないし。まあ、買えばいいんだけど、なんかね。あと、社内ネットワーク環境にとけ込めるか微妙。人の手を煩わせる事になるとまずい。

家で G4 と共生させる場合、Synergy とか使うといいのかな。MacBook はあくまで端末。そうすると、外部公開したファイルサーバが必要だね。Subversion 環境は CVSDude があるし、平気かも。あと、せっかくのノートだし、ワイヤレスも欲しい。

心配だった CarbonEmacs も、よく見たら Universal マークがついてた。配布バージョンが駄目でも、情報集めて苦労したら自力でコンパイルとか出来るんだろうし。Emacs 位の大物になると、OS どころかチップが変わった場合の対応も素早いね。

んー、何とかなりそうだ。問題は燃えるか否か、かな。Dell は燃えるみたいだし、MacBook はどうだろう。バッテリー問題だとすると、キーパネルが熱くなるのは無視して平気?長時間使う場合はバッテリー抜けばいいのか。

黒モデルのメモリを 2GB にしても 23 ちょいだし、諸々込みで 30 で収まるかな?引っ越しを2年先延ばしにすれば…。

買って数ヶ月でモデルチェンジって事が一番怖い…。

オレオレ記法に修正を続けてます。

GMap も生成されるスクリプトをちょい修正してます。ブロック id が重複しちゃう問題があったので修正。あとは、吹き出しのテキストを変えました。

本命は、Hiki 記法の引用と整形済みテキストに対応。

と、ここで重大なミスに気づいた。Hiki 記法ってパクっていいんだか?どーしよ。標準化を目指してる記法を使うべきか?

開発チームの中だけではあるけど、社内では比較的普及しつつある Hiki 記法。いくつも構文覚えるのは面倒だし、Hiki でいきたいんだけど…。

Smarty modifier に対しての著作権とかライセンスは放棄してるし(ご自由に)、公開してる訳だからいいのかな?

で、加えて、コードが汚すぎるのでそろそろ整理していこうかと。


引用と整形済みテキストの記法を利用する場合、nl2br修正子は外さないと変に改行されるのでご注意。

今日のぴーね:GMap 対応

オレオレ記法の中で、GMap 記法に対応。

まだいじり中。住所書いたらそこにピン立てた地図が表示されるだけ。一応小さいコントローラつけてみた。

地図を使う機会が無いので、どんな表示がいいのかよく分からず。仕組みだけ作って、動きの JS は会社の GMapper な人にお願いしようかな?

月曜に、会社のぴーねに対応しよう。API Key 作って、ファイルアップして、サーバ上でテンプレ直接編集して。テンプレはローカルで持った方がいいかな?

作っておいてなんだけど、記法の Smarty modifier って配布されてたりするのかな?というか、記法ってテンプレで対応するものか?まあ、いいのかな。


>OpenPNE の中の人 ぴーね記法作ってくださいな。

社内 SNS への要望:
「Aタグ使ったリンクを貼りたいから、HTML タグ使えるようにしてくださいな。」
というわけで、対応しました。

HTML を使うってのは面倒が多いっぽかったので、Hiki から記法をパクって実現。記法のHTML変換は、Smarty の modifier を利用。

中では正規表現で無理矢理変換してる。リストとか整形済みテキストみたいなブロック単位をひとまとめにするのはめんどかったので、ワンラインものの使いそうなのだけ対応。

で、modifier をテストして、使えそうな事を確認できたので、さあはめ込みましょうってところで困った。default_modiriers に登録すればいいやって思ってたんだけど、それするとフォームの確認処理ではまるね。なので、日記限定で表示部分(body変数)のみに適用。そのうち対象範囲を広げていくかも。特に声がなければ無視しちゃおうかな。

Hiki の中とか Wiki が実際どう変換処理をしてるのかを見てないので、本格的に作り込もうとすれば改めてそれからやらないとね。今回はパフォーマンスの問題は考えてないし、単純な記法だけだからよかったけど。

Hiki よりはてな記法の方がなじみがあるのかな?まあ、使えてたみたいなので、いいでしょう。

勤め先の人が『社内 SNS いーよ』って日記に書いてるみたいで、反応も結構来てる模様。社内の情報共有ツールはまだまだ未開拓なのかな?『広まらなくてポシャった』ところも多いらしいし。Blog とか Wiki は割と使い易いだろうけど、SNS 使おうとすると『ちょっと行き過ぎくらいの遊び心』を持った人が上にいないと厳しいかもね。あと、細かい部分の修正作業が(時間とやる気的に)できる人も必要。

社内 SNS 担当開発者として地位を確立しつつあるこのごろ。どこで道を踏み外したんだろう?その反動か、来週はかつかつスケジュール。気合い入れ直すのにちょうどいい!さすがに今週は遊びすぎた気がする。

まあ、おおむね好評なようなのでひと安心。机が遠く離れた別チームの人との交流も出来るし、楽しく仕事ができるのはいい事です。


興味がある方は、↓よりどうぞ。svn でしか落とせないです。アーカイブはまだ用意してません。
koshigoe prototype

ねむ

お疲れ。

環境整備編に続いて、trace でとりあえず使えるかをテストしてみる。

USAGE:
	try {
		var o:Object = JSON.parse(jsonStr);
		var s:String = JSON.stringify(obj);
	} catch(ex) {
		trace(ex.name + ":" + ex.message + ":" + ex.at + ":" + ex.text);
	}

JSON.as(AS2) のコード内にある USAGE より、大体の使い方が分かる。というか、上をコピペして使った。

var jsonStr = '{"key":2, "obj":{"key":3}}';
try {
	var o:Object = JSON.parse(jsonStr);
	var s:String = JSON.stringify(o);
} catch (ex) {
	trace(ex.name+":"+ex.message+":"+ex.at+":"+ex.text);
}
trace(o.key);
trace(s);
trace(o.obj.key);

JSON.parse で json 文字列をパースしてオブジェクトに変換出来る。JSON.stringify でオブジェクトを JSON 文字列に変換出来る。簡単。
サンプル
外部ActionScript をどうロードするのか分からなかったので、パブリッシュ設定から適当に定義してます。

JSON フォーマットはうろ覚えだったので、シングルクォーテーション使ってエラーになったりしたけどご愛嬌。オブジェクトの入れ子も出来たし、それなりには対応できるっぽい。どれだけの長さに対応出来るのかとか、階層とか複雑さへの対応は分からない。valid な JSON じゃないと対応出来ないだろうし、Flash 内で使う訳だから、文字コードも UTF-8 が基本かな。

文字列をパースするだけなので、テキストデータは別途受け取る仕組みが必要。

XML だと DOM を使う必要があった気がするんだけど、これならオブジェクトを受け取れるようなものだから楽が出来るかも?


Flasher 的にどうですか?

人類みな兄弟

社内 SNS が本格稼働し始めた。

『友達リストに加えるために申請をしなければいけない』というのが気になってる。

SNS だから当然なんだけど、よほど大きな会社の社内 SNS として使わない限り、これは余計な物かもしれない。この件について、社内 SNS でアンケート中なんだけど、ログイン直後の寂しさ加減とか申請のめんどくささが不興みたい。

で、アンケート中ではあるんだけど、とりあえず強制的に友達にするバッチ処理でも書いておこうと動き始めているところ。

今回は、ぴーねのソースを使えるところは使ってみた。設定周りは強引にコピペだけど。やる事は、『友達じゃない人と友達になる』。

  • 設定(ライブラリのrequireとかインクルードパスの設定とか)
  • アクティブメンバーの id リストを取得
  • それぞれの id について、id リストを順に友達かどうか判定
  • 友達じゃない場合、友達リンクをつなげる
  • 全員の id について繰り返す
  • おしまい

ループ周りがいい加減さ爆発だけど、まあよしとします。テスト環境にはアカウントが2つしかないので、ちょっと困ってます。メールアドレス持ってないし。とりあえず、会社でテスト環境作るか、自分を人柱にするか。影響範囲は、c_friend だけだからどうにでもなる気がしてるんだけど、稼働し始めちゃったし、下手な事は出来ないかな、と。

そんなわけで、無保証すぎるコードは未公開。まあ、リポジトリにはいれてあるけど、それはそれ。

PHP で、web 上で実行中のスクリプトからバックグラウンドで動くスクリプトを動かす事って出来るんだっけ?レスポンスを待たずにほったらかしで動いてくれればそれでいい。フックだかなんだか?まあ、cron で定期的に動かしてもいいんだけど、招待されたメンバーが登録した時に、スクリプトをバックグラウンドで動かせばすっきりかな、と。

さて、『人類みな兄弟』プロジェクトは過半数の賛成をとれるでしょうか。無効票多数で終わるかな?

Selenium 注意報

使い方が悪かったのか、最近 Selium がぐずる事が多い。

  1. テストケースから呼び出すスクリプトをキャッシュする
  2. タイムアウトする
  3. メモリ食い過ぎ

open 命令でセットアップスクリプトを呼び出してるんだけど、これが変なところでキャッシュされてたりする。GET で呼び出してるからキャッシュされるのは当然なんだろうけど、ちょっと困る。ので、タイムスタンプをクエリにつけて呼び出すように修正。

ver.0.7 にして、やたらタイムアウトするようになった。サーバの不調とか、実行環境のパフォーマンスも関係してるんだろうけど、標準で30秒でタイムアウトだったので、これを長めにした。setTimeout 命令にミリ秒でタイムアウト時間を渡す。とりあえず5分にしてもタイムアウトしたので、これは Selenium じゃなくて実行環境の問題っぽい。

Firefox で全部のテストを回すと 500 MB オーバー。Firefox が悪いのか、テストケースをつめ過ぎなのか。とりあえず、テストスイートを分割する予定。

あと、テストケースはインクルードを上手く使わないと面倒が多いかも。ログインとか共通した命令セットが割とよく出てくるので、SSI なりテストケース自体スクリプトで書いて、PHP なら require/include とか使って上手く対応した方が良さげ。

ベンチマークとかとった事がないんだけど、JS を使いまくりなページを何度もロードした場合、PC に与える影響はいかほどだろう?この辺の影響で DOM パースが失敗してたりするかな?通しで失敗しても、個別で実行すると通る事がよくある。

まあ、調整を続けて上手くつきあっていきましょう。

パフォーマンス的にどうなのかよく分からないけど、Ajax 用のデータ提供が JSON メインになるとしたら、Flash から使えると便利だろうな、と。かなり今更だけど。

とりあえず、OSをインストールし直した時に放置していた Flash2004 を入れてみた。間違えて MX 入れそうになったけど、なんとか回避。ver.8 はお財布とモチベーションの問題で買ってなし。

Flash はビルトインクラスで JSON をいじれないっぽいので、AS 用の JSON パーサをダウンロード。
Introducing JSON
とりあえず ver.2 用を落としておいた。2004 では AS2 が基本だったっけ?

Flash は Flickr API 触って以来放置していたので、相当忘れてる。色々初歩から思い出さないと。今回の目的は、JSON データを呼んでプロパティを利用出来る事が確認出来ればいいので、AS メイン。確認は普通に trace だかなんだかでデバッグウィンドウ利用すればいいし。

会社の Flash チームの人に聞いた方が早いかな。まあ、リハビリネタとしてはちょうど良さげなのでチャレンジ予定。


Flasher さんは JSON とか使いたい要望持ってたりするのかな。XML ならビルトインで解決出来るし、他を使う理由はないかな。「データ提供側で XML 用意しろ!」?まあ、JSON オンリーな API なんて探す方が難しいか。JSON 使った Ajax インターフェースとの差し替え依頼出す場合とか、コスト削減考えたらありだよね?

そういうわけです。

以前も使おうかと思ってサーバにあげるまではしたんだけど、結局ぽしゃった。けど、最近こっそり Ruby 勉強してたりするので、この際 Hiki にしようかと。

魅力を感じるのは、以下。

  • Ruby!
  • SVN!
  • Japanese!
  • Emacs!
  • 会社で!
  • などなど…

Ruby ってのは、ソース眺める予定はなかったりもするけど、あったりもするかも。とにかく、Ruby をより身近にしておこう、と。

バージョン管理対応はでかい。これまで、Wiki の差分をみる機会はほとんど無かったんだけど、ちゃんと文書管理してこうと思うので、あると嬉しい事ありそう。というか、さくらのレンタルサーバにインストールできちゃったのが本当の理由かも。

国産だってのもいい。ありがちな言語環境での不具合もないだろうし。まあ、UTF-8 で作ってれば化ける事はまずないんだろうけど。困った事があっても、日本語で聞けるし、何より近場に詳しげな方がおられたり。

Emacs の hiki-mode (だったかな?)から直接ポストできるのもいい。正確には XML-RPC だけど、まあ Emacs。前はユーザ認証が上手く出来なかったんだけど、今回は失敗しても粘ってみる予定。

会社で、Hiki Farm 使ってプロジェクトごとにドキュメント類を整理/共有してる。ので、文法だとか見た目もなじみ深くなってきてる。これも大きな理由。

とまあ、そんなこんなで Hiki を使って情報整理をしていきます。もう結構長い事 DokuWiki を更新してないんだけど、まあ新たな環境で書くモチベーションをあげてきます。ブログだとかなりいい加減な書き方で、書けば書いただけ頭悪くなってる気がするし、なにより同じような事何回も繰り返してる。

MT/はてなD/Hiki/Trac と、書きツールが散在する訳だけど、まあそれなりに使い道はしぼれてると思う。問題は、Wiki に『まとめ』として書くようなネタを仕込めるかどうか。これまで書いた事は、Web にあるドキュメントの焼き直しというかパクリばっか。和訳だとか、本のソースを言語移植したりとか。どれも中途半端。

URL はサブドメインが行き渡ってないので、ここでは割愛。後ほど右サイドメニューあたりにこっそりのせるかも。まだ何も無いので。

「Plagger って何?」って聞かれたら、「最強 life hacks ツールだよ。」って答える事にします。

間違ってるかな?RSS/Atom の閉める占める割合はどんどん少なくなってるよね?

"開発者向け"ってつけるべきかも。どうしよ。


いろんなアカウント情報を元にぶっこ抜く印象があるし、(レシピ作ってくれる)フロントエンドサービスをWebアプリとして作るのは難しいかな?デスクトップアプリとして、パッケージングしてくれたりしないかな。管理 GUI と Plagger のセット。そしたら、cookie の位置とか意識する必要も無くなるかもだし、色々楽しそう。XUL と絡めて Firefox 拡張?

愚痴るしかね

今大会が順当な試合結果で進んでる事考えると、まあこうなるんだろうという気はするけど、寂しいもんだ。

初戦はぐだぐだ。今日はそれなりに頑張ってたけど、相変わらず適当な事してる。もう、次は青より黄色応援したくなる。勝ち負け以前の問題。

プロとアマチュアの違いなのか、柔道みたいな必死さって無い気がする。カズとかラモスがいた頃は熱かった気がするんだけど。その辺もプロ化して間もなかったからかな。上手くなりたいとか、海外に買われたいとか、次への課題を探したいってのはいいんだけど、勝ちたいなら実力足りない分、気持ち入れてやってほしい。

今日のが今の精一杯なんだろうか。負けた訳じゃないし、善戦なんだと思うけどさ。作戦だか知らないけど、楽してたり適当な事してばっかな印象。弱い分、1蹴入魂みたくやってほしい。

ラモスのヴェルディだったり、ドゥンガのジュビロだったり。熱いオヤジがいるチームが好き。秋田のアントラーズとかね。ヒデは個人主義者っぽいし、誰かそういう人いたっけか。ジェントルマンなキャプテンなんてどうでもいい。ならず者がまとめていいとは思わないけど、おとなしく落ち着いちゃってるのは嫌。そういうのは陰でひっそりと活躍してて。

森本辺りがわがままに育ってくれると嬉しい。中盤に熱いオヤジを置いて、前のわがまま坊主の手綱を上手くとってくれれば、面白いチームが出来たりしないかな。後ろには頑固一徹なごついおっさん置いて。ころころ転がるやつは要らない。まあ、いないのを無理言ってもどうしようもないけど。

日本代表だし、応援したいけど、あまりがっかりさせられるとどうでもよくなってくる。実力で負けて、代表としての気持ちで負けて。気持ちでくらい勝っておこうよ。

マーケットでの価値とか、より上手くなるためとか、モチベーション作りは歓迎するけど、もうちょっと代表ならではの気持ちの入れ方を前面に出してもいい気がする。イチローだって代表ならではの姿見せてくれたし。

監督がどうとか戦術がどうとかって問題じゃない。導くのは監督の役割かもしれないけど、代表に呼ばれた時点で気持ち作りはしておくべき。呼ばれたって事は、代表として働いてほしいってことだし。そういう気持ちが無いなら最初から断ってほしい。

とにかく、次の開始15分で青か黄色のどっちを応援するかが決まる。日本がなめられて終わるのは悔しいけど、青に馬鹿にされてる気持ちの方がもっと悔しい。

そんな感じで、この際割り切っておく。


ハリー・キューウェルってハリー役の子に似てるかも?空飛ばないクウィディッチ。

日向君がいれば…

小学生時代の、あのギラギラした日向君が懐かしい。

キーボード買い替えた

HHKB を使ってたんだけど、今日普通のテンキー付き106キーボード買ってきた。検診を乗り越えたご褒美。

BUFFALO の Mac 用 BKBU-AJ206/WH2 ってやつ。薄型でパンタグラフキー。

薄いキータッチは割と好きで、いずれ買っちゃうだろう MacBook に備えて慣れておくためにも必須アイテム。

HHKB からの大きな変更点は、102 から 106 になった事と、Control キーが A の左に無いこと。記号系は会社のキーボードが106だからまだいいんだけど、Control キーは一大事。とりあえずリマップソフトを探しまわった。けど、使い方が分からずしばらく Google をさまよってたら、"System Preferences"からいじれる事が判明。修飾キー(Caps Lock/Control/Option/Command)は入れ替えられるとの事。『System Preferences -> キーボードとマウス -> キーボード -> 修飾キー』からいじれる(Tiger)。

あと、ホームポジションからキーまでの距離が微妙に違う気がする。1を押そうとすると2を押して、2を押そうとすると3を押してる状況。HHKB だと左上隅はESCキーなので、ちょっと厄介。ハイフンを沿うとしたらキャップ(だっけ?^)押してるし。

会社では同僚に借りてる HHKB Lite(106)を使ってるんだけど、どうしよう。家のが余る訳だし、返して自分の使おうかな。会社のデスクは狭めなので、長いキーボードはちょっと置きづらい。けど、せっかく 106 で統一できそうだし、会社はそのままでもいいかな。薄型に慣れれば、もう1つ買って持ち込んでもいいし。実は、HHKB Lite の打鍵音がうるさい気がしてちょっと気にしてるところ。

さあ、これで MacBook を受け入れる体制は整いつつある!

エアコンお掃除

素敵スメルを期待して、誇りまみれのフィルタを『水洗い->キレイキレイ->クリアクリーン』の3連コンボ。

きれいにして、エアコンをつけてみれば、不思議スメル。アップルミントの野望が崩れ去ったかと思ったけど、残りっ屁だったようで、しばらくしたら解消した。けど、残念ながらアップルミントの野望も達成できなかった。まあ、最後に水で洗い流して拭いて乾かしてるしね。

スーパーのお掃除コーナーとか探したら、『お徳用エアコン口臭スプレー』とかあるかな?まあ、無臭が一番なんだけど。防菌/防カビかねて、そんなアイテムがあれば試してみたい。

エアコンのフィルタってどんな洗剤で洗う物?とりあえずきれいになればいいやって、適当に見繕ったんだけど、かなりずれてるよね?


こういう悩みも『それPla』で解決できますか?『全国洗剤特価 RSS』かな…。

戦場より帰還

検診受けてきました。今回は若年層検診2だったので、便とバリウムはなし。

2週間くらい前からアリストテレスだかアンダルシアだかのダイエット方法を適当にまねてみて、腹減りつつの毎日を送ってました。

結果は、去年より1kg減で、肥満度も1.1%から-0.6に。体脂肪も1%くらい落ちてた。まあ、1年前との比較だから微妙だけど。気になるのは、コレステロールは減りつつも中性脂肪は増えてる点。病の兆候?

空腹時血糖値が増えて、血液周りが下がってる。成人病になりつつあって体力が目減りしてるのかも。やばい。

持病持ちなので、1つB判定だったけど、後は全部A判定。今すぐどうこうって訳じゃなさそうだけど、そろそろケアしていかないとまずそう。

どっかで運動しないと、ね。

PC 乗り換えは大変

デュアルディスプレイで快適な毎日を送ってるんだけど、PC 乗り換えのせいでいらつきもちらほら。

最近、諸事情で PC を変えたんだけど、Pen4 -> Celeron が意外なほどに響いてる。

  • Firefox
  • Thunderbird
  • Poderosa
  • Emacs
  • Explorer
  • PowerPoint
  • Google Desktop
  • Xkeymacs
  • Norton
  • TortoiseSVN
  • coLinux(256MB)

同時に立ち上げてるアプリは上記の通りで、XP を早くする設定を出来るところはしてる。だけど、やっぱもたつく。メモリは 1.5GB あるんだけど、CPU が悲鳴あげてるのかな?

まあ、アプリ立ち上げ過ぎ感もあるし、それはいい。問題は、Selenium テストを回している間。30 を超えるテストファイルを連続してまわすので、これが結構な負担。ひどかったのは、気づいたら 500 MB くらいメモリ使用してたとき。XP が HOME になって、P4 が C になったからなのかはわからないけど、これはひどすぎる。Firefox 自体がメモリ周りでヤバげなのかも。最小化してメモリ解放するやつ設定してたはずなんだけど。

Selenium テストは『JS 回し続けてもメモリが適度に解放されるブラウザ』を使った方がいいのかも。IE は妙に遅いので、IE Comporent 系も遅いのかなと思って試してなかったんだけど、Sleipnir とか Donut とか軽くて早そうなやつ適当に見繕うかな。ブラウザ仕様の問題でテスト通らないのは嫌だし、どれ使えば正解なんだろう?

この影響で最近仕事が進まない。テスト全体の調整作業を進めてるんだけど、通しテストに小1時間かかる。今日は、MySQL のバージョンを 4.1 から 4.0 に戻して、PHP もソースコンパイルからやりなおして、としてたらあっという間に時間が過ぎていった。lex がないとか yacc がないとか、見た事無い単語が飛び出してきてびっくり。パッケージで入れてた時は必要なかったのに。Flex と bison から入れなきゃいけないなんて…。

とりあえず、明日は勉強会の準備と軽装ブラウザのインストール作業をやります。テストの調整は帰り際にめどが立ったし、UI タスクもちゃんとやらないと。あー、勉強会ネタ無しだ。またごまかしかな…。

古い記事を読んで「なるほど」と反省。そういう事か。

またSalesforce.comの興隆にみられるように、企業の重要なデータをホスティングサービスに依存することに抵抗が少なくなってきたという地盤もある。特に中小企業、中でも情報化に乗り遅れた小規模企業の市場をいかに開拓していくかは、多くのアプリケーションベンダーにとって至急の命題となりつつある。「低コストでシンプルな方法を、より多くのユーザーに提供する」——それがこの市場攻略の鍵だ。
Microsoftの新サービス「Windows Live」「Office Live」は何を目指すのか? (MYCOMジャーナル)

『小規模企業の市場をいかに開拓していくか』という事で、コスト面を考えて Web アプリなんだね。『重要データをホスティング』とか『Webアプリケーションでも普通のバイナリベースのアプリケーションに匹敵する操作性のアプリケーション』については疑問だけど、購入資金を渋らざるを得ない市場での戦略な訳だ。

Microsoft はそうだとして、じゃあスプレッドシートを Web アプリとして提供しだしてるところはどう考えてるんだろう。やっぱ同じなのかな。ライトユーザが高いお金を払って Excel を買う必要がないようにするための救済措置。表計算アプリケーションが欲しいだけで、Excel が欲しい訳じゃないユーザは結構いるだろうね。

Excel だけじゃなくて、標準だけど高価な Office ツールについても同じでしょうね。一部のツールを使いたいけど、コスト面を考えると手が出せない。じゃあ、そこを Web アプリで拾いましょう、と。

ライト版を提供するだけなら、Web アプリである必要は無い気がするけど、そこは『ユーザ体験』を優先したり『低コストで似た事が出来る』現状を考慮したのかな、と思う。Web アプリ開発の主流は LL 言語で、LL 言語はアジャイルなリリースがし易い。『より良いユーザ体験』を迅速に提供する事が出来る。開発コストも LL 言語の方がきっと安い。流通についても安くあがるだろうし。

やっぱ、棲み分けってことだよね。要求に即した提供方法が確立されてきたよ、と。

KoshigoeBLOG: 本当にデスクトップソフトウェアは減りますか?
ASP で提供する事が望ましい種類のサービス(アプリケーション)と、デスクトップソフトウェアとして提供する事が望ましい種類のものがあるのかな?

この辺はデスクトップ?

Office の機能限定劣化版な印象があるβ版サービスはちらほらあると思うんだけど、あれってスプレッドシートをいじくれるだけとか、ライトユーザー向けなんじゃないの?Excel クローンと言えるほどのものがそうそう出てくるとは思えない。Windows Live を使った事が無いのでよく分からないけど、きっと Lite 版で止まるんだと思う。ブラウザっていう制約をかかえたまま、Excel と同等の事が実現できるとは思えない。そもそも、ウェブブラウザはアプリケーションを実行するために最適化される訳じゃないだろうし。アプリケーションを実行するために汎用しようとしても、結局は変な制約が持ち込まれる気がする。

この辺はサーバ?

一方で、ソーシャル的な利用目的を持ったツールはサーバインストールか ASP 型でいいんだろうと思う。ブログをデスクトップにインストールする意味は無いし、操作系に対する要求もさほど高くない気がする(JS で対応できる程度)。スケジューラ(カレンダーとか ToDo 管理)については、サーバが落ちたら致命的ではあるけど、それ以上に『どこからでも見れて更新できて関係者間で同期できる』事が重要な気がする。セキュリティがどうなるかは微妙ではあるけど、『ユーザ間での同期』を考えると一番手軽な実現方法かな、と。P2P は、現状ではリスクが高すぎるだろうし(ポート空けなきゃだよね?)。これも操作系はそんなに要求されないでしょう。メーラーに着いてもほぼ同じ。

要求されるパワーについても考える?

重たい処理をブラウザ上で実行するアプリで捌けるんだっけ?今は、JS 実行時間に制限があるよね?ループ回数も。ブラウザ向けに考えるとすれば、当然の措置だろうけど、アプリケーションの実行レベルで考えると、別の機構に投げないと処理しきれないよね?AJAX 使って、サーバに計算させた結果を取得?いちいちサーバに投げてると、遅延がひどくならないかな?Vista だと .NET な仕組みを利用して、CPU を効率的にフルに使える?

棲み分けでいいんじゃね?

一部のソフトウェアについて、サーバ上で動かした方がメリットが大きい場合に、サーバ上で動かす事になるって事なのかな。Office とかのビジネスソフトウェアについては、無理だと思うんだけどどうなんだろう。インストールしなくていいのは大きめのメリットだろうけど、かなり要求が高いソフトウェアを汎用フレーム(ウェブブラウザ)で使うってのは無茶じゃないのかな。ウェブブラウザが実行環境になるって仮定してるけど、そうなるとしたらアプリケーションへの要求がブラウザ開発の速度に足引っ張られる訳だよね。ビジネスマン達はそれを許容できる?ウェブブラウジングっていう本来の目的とは別のところに無理矢理対応すれば破綻するのは目に見えてるし。最初から専用アプリケーションとして存在してた方が安心できる気がする。

だからよう…

せっかく Emacs に慣れてきたし、デスクトップアプリはそのまま発展し続けようよ…。デスクトップアプリで出来る事がウェブアプリでも出来るようになったからって、無理しなくていいじゃん。ネットワークデータベースをデスクトップから使えればいいんでしょ?Google Desktop でいいじゃん。Web API(Web Service)が普及してきたなら、デスクトップアプリから使えるようにすればいいじゃんか。
LL 言語でデスクトップアプリが開発できれば喜んでするだろう?細かいところいじりたいなら、C とか JAVA とか喜んで勉強するだろう?XUL とか XAML とかに期待してたりするんだろう?

開発環境が快適なら文句無いよ

個人的には開発環境がライトであれば文句無し。デスマーチ云々な環境には近づきたくない。そのためには、サーバインストール型のソフトウェア開発がベストだって言うなら、それでいい。けど、利用者からすればそんなことはどうでもよくて、最高の利用感を得られる事が大事だし最低条件。ユーザの立場になれば誰だってわがままになるんだ。

最後に

導入コストについて無視してきたかも。

反論とかじゃないです、ずっと疑問だったので改めて書いてみます。
ドリコムの見る戦略的キーワードは「SaaS」「ソーシャルDB」「ロングテール」 - CNET Japan
目立つ流れはそんな雰囲気だと思うんだけど、本当にデスクトップにアプリ置かない状況が主流になるのかな?

個人的に、複数環境(デスクトップ)でデータの同期がとれれば満足だったりする。なので、データをネットワーク上に置いて、かつ作業分はデスクトップに残るようなデスクトップソフトウェアでいいんじゃないかな、と。差分を上手い事マージしてくれる事も大事。

OS API 使いたい

UI を良くするためには OS API が使えた方がいいはず。OS API を直接ソフトウェアから操作する必要もなくて、XUL Runner みたく間を取り持つ仕組みがあったっていい。XAML だか WPF/E だとかいうのでもいいし。『ブラウザ対応』嫌。エンジンを統一して、その上で動いてくれればいい。ブラウザ戦争に足引っ張られる未来は見たくない。まあ、VM が足を引っ張る事があるのかもだけど、足の速さを考えると、ハードウェアの進歩に期待した方がよさげ。

アプリを毎回サーバからロードするの?

サーバが落ちた場合使えないのは嫌。アプリとデータの両方がデスクトップに残るべき。ブラウザの拡張とかで入れてもいいんだけど、ブラウザがもっさりするのが怖い。使う時にロードすればいいのかもしれないけど、ブラウザごとに対応する事になる気がして怖い。
サーバ側の対応状況を上手く考えればいいのかな。データとアプリは別サーバに置いて、回線も別々の物を利用して。コストどんだけかかるんだろう?やっぱ、アプリはそれぞれデスクトップにインストールした方がいいんじゃないかな。

サーバって頑張れば落ちない物ですか?

トラフィック状況とかハードウェア障害なら、スケーラビリティだとか監視体制だとかで頑張れるのかな?じゃあ、ネットワーク設備に障害が出た場合とかはどうなるの?そこまで考えてられない?複数設備を利用する?
お金いっぱいあるところならなんとかなるのかな。

AJAX アプリって本当に使い易い?

個人的に楽しい驚きで割と好きなんだけど、ばらばらなインターフェースになるのは嫌。決定版フレームワークが登場すれば解決する問題なんだろうけど、それって各ブラウザにちゃんと対応される物?その労力は報われるの?非同期通信はローカルバッファを使えるようになれば後で同期とかもできるんだろうし、その辺のいらつきは今は我慢だと思うけど。
学習の手間についてちゃんと考慮されたアプリを作るのに、労力が最小限になる仕組みは必要だと思う。

じゃあ、複数環境にインストールできるの?

ライセンス(利用料金)の問題がある。CPU ごとの課金なんてやってられない。1アカウント1パッケージで無制限インストールがベスト。複数人の使い回しはデータで制限できるかも。「他人に除かれたり消されたりは嫌だっ!」て。効果無いかな。グループウェアっぽいやつはそれなりの料金とる?同期しなければローカルに好きなデータ残せるし、駄目か。
インストール作業のコストはどうなんだろう。個人的には問題ないんだけど、嫌な人の方が多いかも。
インストールが制限された環境に対応できないってのも問題か。サーバ上にあればキャッシュデータとかを消せばいいし。アプリ側で上手い事その手間を吸収してくれてると嬉しいかな。ポータブルほげほげに期待かな。

デスクトップソフトウェア作るコスト大丈夫?

デスクトップにソフトウェアを置いた場合、サーバ側でデータを処理する部分とクライアント側で操作を処理する部分が、変な風に分かれたりするかも。Rails で JS 書けるみたく、開発環境は同じでいけるかな?どうだろう。

実際のところどうなんですか?

ここまで書いておいてなんだけど、マーケティングリサーチっぽい事は全くしてません。なので、実際どんな反応があるのかとか知りません。はじめの方で書いた通り、個人的にはデスクトップソフトウェアとしての形で十分な気がしてます。支払うお金についての心配はあるけど、そこが解決したらサーバ上においておく理由が特に見つからない。
データさえサーバで握っちゃえば、提供側にも問題ない気がする。ソフトウェアのアップデートにしても、自動アップデート機能を組み込んだソフトウェアはたくさんあるし、開発スピードは問題ない。フィードバックだってサーバに集めればいいんだから、どっちがどうって訳じゃないよね?
Rails で作れるとかの開発環境の問題は、仕組みの進歩次第かな、とも思う。OS API を使ったソフトウェアを開発するための簡単な仕組みが整えば、足の速い開発体制を整える事も難しくないのでは、と。

まあ、夢なんですけどね

いつ来るか分からない未来に妄想膨らませて、妄想に依存したビジネスしても餓死するだけだって事なんでしょうか。今は今のトレンドを押さえてそこで勝負すればいい、と。あまり変な風に考えすぎちゃ駄目ですね。

つまり

ビジネスな話に首を突っ込むな、と。どうも、『お金』の面で考え足らずな事を書き散らす癖がついてるようです。『夢に生きるのが漢の浪漫』とかって立場から批判してるんじゃなくて、現実的な話として『お金』を抜きにした思考に偏ると『イイもの』は出来てこないよ、という反省です。

ちゃんと考えないとね

いまいち考えがまとまらないので、『サーバ上にソフトウェアを置いた場合』について考えないとですね。デスクトップソフトウェアを否定するくらいの勢いを持って、つらつら考えてみるかもです。


ご協力お願いします:
  • どこかにまとまったドキュメントとかあったら教えてください。書籍でもいいです。
  • コメントとして『そこはこうじゃね?』といった事を教えていただけたりすると喜びます。
  • del.icio.us とかはてなブックマーク以外で API たたくデスクトップソフトウェアってありますか?
技術者視点、経営者視点など、色々な視点で考えた場合どうなりますか?

どうしようもね

| コメント(2)

残り2つ勝ってくれ。

MacBook 触ってきた

熱い!

ビックカメラの Mac コーナーで触ってみたんだけど、熱い。MacBook はキーパネルがうざいほど熱くて、MacBook Pro はアームレスト(って言うの?手を置く部分)が熱い。裏面とかなら、机においておく限り問題は無い。移動中に膝上で触るほどのハッカーじゃないし。でも、キータッチで熱さを感じるのは微妙かな、と。どうなんですかね?

BootCamp のデモもしてたので、触ってみた。意外なほどに快適。VirtualPC みたいな仮想環境じゃないし、何より Intel チップだし、なのかな?キーボードショートカットがよく分からなかったけど、IE も普通に立ち上がるし、軽く触った程度なら違和感無し。起動にかかる時間は分からなかったけど。けど、まあ 重要なのは、Intel チップの恩恵で、OSX 側で素敵な仮想マシンが立ち上がるようになるかな、という期待。Parallels のが良さげという話題は耳にするけど、coLinux は動かせないのかな?VMWare でもいいし。有料ってのが気に食わない。それなら、OSX の BSD 環境を汚さないようにして環境作った方がいい気がするし。

コンテキストメニューを開くために、トラックパッド2本指押し挑戦したけど、微妙だね。楽しいんだけど、あれが使い易いかはわからない。

さて、実際に触ってみて感じたのは、『欲しい!』ってこと。無駄に職場で触ってる姿を想像してみたり。多分、自宅の PowerMacG4 より早いんだろうし、シネマディスプレイとのデュアルを考えれば(出来るか知らない)、MacBook の 13 インチも悪くない。1280x800 らしいし、字が小さいかもしれないけど、エディタとかターミナルなら問題ないと思う。壁紙のせいかもしれないけど、画面がやたらうそくさくきれいに感じた。ハイビジョンとかのはめこみみたいな感じ。

PowerMacG5 もいいかもとか思ったりもしたけど、値段を考えると MacBook でいいかな、と。無茶しようかな。時期的にちょうどいいんだよね。引っ越しを先延ばしにすればなんとかやりくりできるし。

熱は我慢するとして(冷却装置まわりで回避できるとこまで頑張る)、うるさくなくて早いんだったら我が家の 3代目 Mac として期待。ただ、ノート買っちゃうと無駄に持ち歩きたくなるんだよね。会社に自分 PC 持ち込むってのはどうなんだろう?セキュリティ考えれば駄目だよね。

Mac って買うタイミングが難しいんだよね。今日買っても明日にはいいやつが安く売られてるかもしれないし。あー、CarbonEmacs とかの対応状況見ておかないとか。エミュレータ通して動かすんだよね。

ワールドカップが終わる頃には結果が出てるでしょう。

そろそろ Ruby

使い始めます。

ので、とりあえず会社の勉強会で教えてもらった本をいくつか買ってきました。ついでに、TCP/IP の入門本(今更?)と Ajax イン・アクションも。

目標は RubyCocoa。どうせ Cocoa 使うなら、ObjectC(だっけ?)の方が色々勉強になるのかもしれないけど、まあ Ruby メインでやっていって、その派生として Cocoa(GUI/OS API) とか Rails とか経験できるといいのかな、と。

がんばれ、おれ。

シネマディスプレイと仮想デスクトップで、一面 Firefox + Emacs + Terminal を利用中。

会社でマルチディスプレイ使うようになって、『ドキュメントを見ながらエディタで書く』事はかなりイイ。で、これまでは Terminal - Emacs だったんだけど、Browser - Emacs がいいのかも、と。Firefox は色々入れすぎてるし、なんとなく全面で使いたいので、用途限定ブラウザとして Camino を使ってみる。割とさくっと表示されるし、余計な物を入れてないプレーンな状態なので軽め。見る事が出来て、検索がそこそこ使い易ければよし。

Emacs を横分割バッファにして左 w3m で使おうかとも思ったけど、php.net で関数検索したら落ちたのでやめ。右バッファからのブラウザオープン命令を左バッファに伝える方法も分からないし。何より、w3m 使った事無いし。

OSX のデフォルトブラウザはそのままにして、Emacs からブラウザを開く場合に Camino を使うようにしてみた。Camino で外部からのオープンを新規ウィンドウで開くようになってたので、それも新規タブで開くように。

(setq browse-url-browser-function 'browse-url-generic
      browse-url-generic-program "/usr/bin/open"
      browse-url-generic-args '("-a" "Camino"))

Emacs と Terminal を別画面にしてどうなるか心配だけど、しばらくはこれでいってみる。

自分を追い込んでみる

ACL 設定がようやく反映されたので、CVSDude 上でおもちゃ置き場 Trac をセットアップしてみた。
koshigoe prototype - Trac

ネタがないのにあれだけど、無駄に自分を追い込んでみます。先日の OpenPNE のも svn で落とせるようにしました。自動アーカイブは準備してないので、それは時間があればやろうかと。

Trac は使い慣れてないので、どうやって運用するのかよく分からないけど、適当にやります。

何か作ってみて Blog に Zip のリンクを貼るって事をしたりするんだけど、版管理とか面倒だし、いっそ SVN ホスティングで Trac やっちゃえと。そんなノリです。

RSS 普及物語

ネタです。

RSS って何に使えばいいのかな?

「特価情報とかクーポン情報が着いたセールス情報を受け取りたいな。」
「楽天のメルマガ読めば?」
「駄目だよ、メールアドレスは友達以外に教えちゃいけないんだ!犯罪に巻き込まれたらどうするんだい?」
「大げさだな。じゃあ、RSS を購読すればいいじゃないか。あれなら何かに登録する必要はないよ。」
「RSS ってなんだい?それに購読?僕は離島に済んでいるけど、ちゃんと届くのかい?」
「宅配便で届ける訳じゃないよ、インターネットで受け取るんだ。」
(RSS 講義中。コーヒーブレイクを数回。)
「分からないよ。なんで専用のソフトをインストールしなきゃいけないのさ。ユーザー登録?だから嫌だって。」
「わがままだな。」
「そういうなよ、ちゃんとダブルクリックは出来るようになっただろ?」
「もう、ダブルクリックとメールの読み書きくらいは家のおじいちゃだって出来るよ!」
「それで、RSS なんたらは使わないで済む方法ってあるのかい?知ってるんだろう?」
「えーと、どうしようか?」

RSS って言葉を使わずに届けたいんだけど

「言われた通り、RSS を RSS リーダーで読ませるためのボタンを用意しました。」
「ねえ、気になったんだけど、RSS を読む事が出来る人ってどれだけいるの?」
「え?さあ、うちのサイトを見てる中で言えば、5%超えればいい方じゃないですか?」
「そうか、じゃあ RSS を配信しても集客は望めないのか。」
「いや、そうとも言えないんじゃないですか?RSS は伝搬するって言いますし。」
「うん、確かに露出機会が増えたりといった話は聞くんだ。けど、サイト訪問者に効果がないというのもねぇ。」
「そうですねぇ、じゃあ RSS だって分からなくしたらいいんじゃないですか?」
「どういうことだ?」
「つまりです、"Outlook Express で購読する"というボタンを置いて、ボタンをクリックしたら Outlook Express で読めるんです。」
「それに意味はあるのか?」
「いいですか?オフィスワークをする人は大抵 Outlook Express を常に立ち上げています。」
「うん。」
「そして、メールを読む事は仕事として認められています。」
「んー、私用でなければね。」
「ふふ、RSS であれば、メールボックスに証拠が残らないので、私用かどうかも分かりません。」
「それは困るよ、君!」
「もちろん、ネットワーク管理者が通信状況を細かくチェックしていれば分かりますけど。」
「…。」
「重要な事は、使い慣れたソフトウェアで情報が受け取れるという事と、仕事中の楽しみを見つけられるってことです。」
「仕事は遊びじゃないんだ!却下だよ!査定を楽しみにしていたまえ。」
「はぁ、落ち着いてください。これは極論ですよ。」
「…。」
「RSS を知らないサイト訪問者に自然に RSS を受け取ってもらう自然なシナリオだとは思いませんか?」
「まあねぇ、私も新作のパターがヤフオクに出品されている事を仕事中でも知れれば嬉しいがね。」
「でしょう?」
「じゃあ、やってみようか。頼んだよ。私は会議があるから、じゃあね。」
「え?!…、あー、できるのかな?」

それ hoge で出来ないの?

「(上記について)こんな話をスターバックスで耳にしたんだけど、どうかな?」
「そうですね、"feed://"を利用すれば、ボタンとアプリケーションを関連づける事は可能です。」
「おお!じゃあ可能なんだね?」
「落ち着いて、アプリケーションが"feed://"をサポートしている必要があります。」
「ふーん、とりあえず Outlook Express が対応してればいいよ。してるでしょ?」
「(仮にしてないとして)いいえ、残念ながら RSS リーダーしか対応していません。」
「それは困るよ。何とかならないの?」
「沖縄合宿しますか?まあ、"feed://"との関連付けを設定する必要があるので、ユーザーに負担が無い訳ではありませんし。」
「熱海じゃ駄目?そうんなんだ。」
「もし、"アプリケーションとの関連づけ"が標準になれば、プリインストールソフトウェアの初期設定項目に関連付けが入るかもしれませんね。」
「どういうこと?」
「ユーザーはコンピュータの電源を入れるだけで済むんです。」
「それは凄い!けど、それは難しいね。」
「ええ、ビジネスな人たちでの調整が必要ですね。」
「そっか。頑張るよ….別の話になるけど、イベント情報を RSS で配信した場合、Outlook のカレンダーにインポートする事は可能?」
「Outlook が RSS を読めるかは、ハワイ合宿次第ですけど、まず RSS を拡張しなければいけないというのが気になりますね。」
「アラスカがおすすめだよ。拡張すれば詰め込めるはずだよね?何が気になるの?」
「つまり、放し飼いのオオカミを調教する負担を Outlook(アドオン) に要求する事になるんです。」
「負担させればいいんじゃない?」
「待ってください、それだけじゃないんです。仮に Outlook が対応した場合、」
「場合?」
「パブリッシャであるうちも対応せざるを得ないんです!」
「駄目だ!そんな事は許せない!…、けど、やろうよ。」
「中2からやり直してください!」
「高1にまけてよ。どうすればいいのかな?」
「そうですね、規格の管理団体に参加するか、メジャーな RSS 利用者間で同意をとって業界標準の策定を進めていくかでしょうか。」
「んー、難しそうだね。規格なんて分からないよ。けど、ここを乗り越えたらパブリッシャとして幅が広がるね。」
「そうですね。ブリテン合宿次第ですね。」

引き続き、補完財

KoshigoeBLOG: RSS パブリッシャにとっての補完財って何?
Joel本に影響されて、『経済学』とかのビジネスな面も多少考えないとと暴走中。

さて、先のエントリの続きで、『RSS はいったい何に要求されるのか』という事を考えるところから始める。

『何に要求されるのか』を考えるってことは、『どんな用途があるのか』って事を考える事なきがする。これは、「こうしてああしてこれになる」っていうコンサルティングだし、「この問題はこう解決します」っていうサポートだと思う。

まあ、具体的に要求をあげられる訳じゃないんだけど、仮に決まったとする。フローを整理すると、『要求に従って企業がパブリッシャを利用して RSS を作り、パブリッシャもしくは企業が要求元に届ける』という事に。

パブリッシャにとって RSS が行き着く先は、企業に対する要求元。要求元からさらに別の要求元へっていうのは、コンサルティングとかの役割として、パブリッシャは(今は)無視。抜け落ちてるところはいっぱいあるだろうけど、こう考えるとやっぱり、『RSS の受け手をコモディティ化する』って事なのかな?

じゃあ、RSS リーダーが普及すればいいのかっていうとちょっと違う。受け手は、『RSS を読みたい』なんて要求は滅多にしない。『企業が出すプレスリリースを素早く読みたい』って要求を出したとしても、そのデータが RSS であるかメールであるかはあまり関係ない。

つまり、『要求に応えられて RSS を理解できるクライアント』がコモディティ化してくれれば、RSS パブリッシャは嬉しい訳だ。

『ドキュメントデータをプッシュして欲しい』要求に対しては、すでにコモディティ化しているメールクライアントにアドオンとして用意するだけでいい。

Podcasting の様に『メディアデータをプッシュして欲しい』要求であれば、iTunes が対応してるし、できるか知らないけど WMP で頑張ればいい。

『インターネット(ウェブブラウザで見ている)操作と連携したい』要求であれば、ウェブブラウザのアドオンとして対応させればいい。XUL だとか Flash だとか Javascript(+CSS) だとか XAML だとか。

問題は、RSS っていう規格が持つ限界をどう解決するか。『要求はあるんだけど、RSS では表現できない内容なんだ』って事があるかもしれない。けど、これもまたクライアント次第。『こういう目的でこういう情報を載せたいんだ』って事を上手くフィードバックすれば、規格を管理しているところが整理してくれるかもしれない。XML の諸刃の剣な『名前空間による拡張』を使ってもいいかもしれない。よく練られたアイデアであれば、後からついてくるかも。まあ、HTML とか Javascript とかの二の舞になるかもだけど。ただでさえ、RSS1.0/RSS2.0/AtomFeed なんて乱世な訳だし。

とにかく、パブリッシャとして生きていく事を決めたとしたら、RSS をどう使うかを考えて、使い道を考えた RSS を受け取る方法を考えなきゃってことかな。あれー?全部やんなきゃってこと?あー、クライアントアプリについては第3者パワー(親切な開発者)を活用するために、たたき台を作ればいいのか。どう使うかってのも実際に使ってる人たちのフィードバックをどうにかして受け取る努力をしたらいい訳だし、受け取る経路が企業経由(パブリッシャの顧客)でもいい訳だ。

疲れた…。久しぶりに RSS について技術じゃない方面から考えた方がいいかなぁと、思いつきで考え始めたんだけど、迷走し続けてしまった。ビジネスな話はさっぱりなので、このテーマに関しては勤め先の偉い人が考えてると思う。近々全体ミーティングがあるので、ちょっと注目。まあ、話を聞く前に自分なりの整理をしておくといい事あるかな、と。


結論を出せたようで出せてないんだけど、『RSS の普及』に関して1つみんなが知ってる事は、『最終的に受け取る人には RSS って言葉を使わせない』って事だよね。

Joel本を読んでて、「よくわかんね」なのでメモ。

スマートな企業は彼らの製品の補完財をコモディティ化しようとする。

単純に考えれば、こんなとこ?

  • RSS リーダー
  • Mash up サービス

思いつかない…。"Mash up"でくくっちゃ駄目だよね。別に RSS である必要は無いし。RSS が使われてるのも、限界はあるけどフォーマットが統一されてるだけやりやすいって事だろうし。

まあ、とにかく、『補完財』を『コモディティ化』したら『スマート』らしいので、考えなきゃね。最近、おなかが気になるし。

RSS リーダーはコモディティ化してるよね?外部ドメインとの HTTP 通信をどうするかを考えなければ、JS で簡単に作れる訳だし。アグリゲーションを考えなければ、何も難しい事は無い。

分かり易い困りどころは、『活用する人(ユーザー)』が少ない事?ユーザーがたくさんいてこそ『コモディティ化』?そもそもコモディティ化って何?

「コモディティ化」とは、高付加価値の製品の市場価値が低下し、一般的な商品になることを指す。
技術の側面から見ると、技術としての競争力が低下し、一般的な技術となることと言える。技術開発を行うに当たっては、研究開発費を回収できるだけの収益を得られるかがビジネス戦略上、重要となるため、収益を得ることができる期間に関わる、技術の「コモディティ化」の早さを検討する必要がある。
コモディティ化 - 産学連携キーワード時点

『高付加価値の製品の市場価格が低下し、一般的な商品になる事を指す。』か。リーダーが高付加価値だとは(人によっては利便性は高いけど)言い切れないし、一般的だなんて言える訳が無い。そもそも、ブログ RSS がほとんどな現状を考えれば、付加価値をパブリッシャがつけて、それでリーダーの価値を高めるみたいな状況な気もする。パブリッシャが補完財?

『鶏と卵』の話もJoel本にはあったけど、そこはこの際無視。『企業向けの RSS パブリッシャにとっての補完財』について考えていこう。

リーダーの話はいったん置いておいて、"Mash up"系で考えてみる。RSS みたいにその辺さまよってたり、作法を守れば貰えるデータをつなぎ合わせて、面白い形で見せるやつ。簡単なもので言えばポータル系。RSS 発行しておけば、集客目的の場所に拾ってもらえるよ、と。インターネットの向こう側の人は"RSS"なんて知らなくて良くて、『新鮮な情報が大量に!』みたいな。

『メールマガジンの代替』ってのもあるんだけど、あれは現状『RSS 知ってる事前提』だし、ちょっときついかも。『RSS を購読する』必要があるし。リーダーがもっといい名前つけてもらって、それが普及すればいいのかも。メールクライアントで対応するのもよし。『新着情報を購読する』みたいなボタンを用意して、そこからメールクライアントに渡せるようになればいい。"feed://"をメーラーで受け取ればいいのかな?"RSS"が隠れるからいいんじゃね?リーダーの話に戻っちゃったけど、コモディティな(?)メールクライアントが RSS を隠す上手なインターフェース持ってれば一気に解決?ああ、ローカル環境に依存するね。メールで言う『サーバに残す』を上手い事解決しないと。メールクライアント開発元がプロクシ用意する?Bloglines とか LDR と契約?

RSS は、使い手がいなければ出し手が渋るし、出し手がいなければ使い手が渋る。けど、3つ以上の規格があって、認証がどうこうってんだから、クライアント次第な気がする。『こんなん出来るよ!』ってなれば出し手も追随するだろうし。クライアントの用途が一般向けなら、それだけ一般向けな出し手が増えるかな、とか。

んー、パブリッシャって必要?『RSS を作る(生み出す)』事がパブリッシャだとすれば、パブリッシャは RSS リーダーと一緒にコモディティ化だよね。RSS 生成っていう『単純なタスクをこなすだけ』じゃなくて、『用途別の付加価値』とか『用途別 RSS の効率的な管理』とかが重要なのかな。Windows 使う理由が「Word と Excel が使えるから」だとすれば、パブリッシャは『ユーザーがしたい事を上手にこなせる何かを持っている』必要がある訳だ。じゃあ、その何かを使って RSS を作ったとする。で、RSS は何に使うの?Word なら会議だとか納品先に提出するとか、Excel なら明日送る請求書とか成績評価とか。RSS は何から要求されるんだろう?

結局、最初に戻ってしまった。頭の中は自分的に整理できた(気になる事を書き出せた)気はする。けど、何も解決してない。

長くなったので、ひとまず区切り。

KoshigoeBLOG: OpenPNE のデータエクスポート
1日経ってないけど、後日談。

エクスポートスクリプトが会社サーバで動く事を確認してほっとしてたら、[それPla]ツッコミされてた。確かに、アプリケーションを汚さないで済むので、Plagger 使って外からひねり出した方がいいんでしょう。

まあ、勉強がてら遊びがてらの『お題』として取りかかったものなので。後、会社サーバは『Perl 未開の地』だったので、『Plagger 入れるのは地獄』と判断してたり。

で、帰宅1時間前に、開発チームのおもちゃとして中長期的に遊べる気がしたので Plagger を入れてみる事に。自宅サーバでの経験から、CPAN 上で"test Plagger"したんだけど、やっぱり途中で止まる。で、1つずつ足りないのを入れていって、"./plagger"で"config.yaml"が無いってとこまで済んだ。じゃあ、"bloglines2gmail.yaml"でテストしてみようと、Trac 見に行ったら、"apt-get"云々なページを発見。
Debian Unofficial Package

結局、CPAN 経由では上手くいってなかったので、"apt-get"で入れる事に。3桁のパッケージインストールを経て、無事動く事を確認。yum でも入れられるみたいなので、もう『Plagger はインストールが地獄だから…』なんて言い訳は言えなくなった。ネットワークの状態が良ければ、多分5分かからないで動かせるようになる。

"apt-get"で入れると、"/usr/bin/plagger"が出来るんだけど、"apt-get"経由でアップデートも出来るのかな?svn でとってきて"./plagger"で動かせばいいだけかな。

ちなみに、今回のスクリプトは OpenPNE コミュニティへの還元を考えてません。認証ポリシーだとか、DB 不可分散だとか、フレームワーク云々だとか、今回の目的に不要なところはとことん省いてるので。「じゃあ公開すんな!」って話になるんだけど、まあそれはそれ。誰か突っ込み入れてくれたりするかな、と。後は、「Plagger 使ったら負けだと思う。」な人もいるかもしれないし、(Perl 的に)サーバ用意できない人もいるかもしれないし。

そんなこんなで、色々と突っ込みありがとうございました。


1つのはてなブックマークに[それPla]を大量につけてる人がいたけど、あれはボットな人だよね?


いつの間にやらリポジトリからログイン無しで export/checkout できるようになってました。やっぱり ACL 設定は時間がかかるみたいだ。
"svn export http://svn2.cvsdude.com/koshigoe/prototype/mod_openpne"
日付のタイムゾーン表記が正しくなかったので修正。

はじまりは、「社内 SNS(OpenPNE)から RSS をはいたらどうかっ!」。

まあ、せっかくなので、RSS を吐くというよりもデータエクスポータとして用意した方が自分が楽しいかなと思ったので、RSS と JSON はくようにしてみた。日記とコメントについて、みんなか個別で吐く。

URL は "OPENPNE_URL/export.php/diary|comment[/nickname]/rss|json"。最新 15 件のアイテムを掲載。日記にコメントをバッグな感じで入れようかと思ったんだけど、めんどかったので省略。

認証処理はなし。その辺は、利用するクライアントの実装に左右される現状だと思うので、.htaccess に Order 書くなり、Basic 認証かけるなり、WSSE とか使ってみるなり、とご自由にがポリシー。cookie 使えばスマートなのかも(Plagger はそうしてるんだっけ?)。

サーバ用件としては、php-json と PATH_INFO が使える事。mod_rewrite は利用せず。スクリプトは OpenPNE のライブラリを完全無視。半使い捨てスクリプトなので。php-json は json で出力しなければ必要ないはず。Debian で php5-json があったので嬉しくなって(?)無理矢理対応してみただけです。

かなりやっつけなので、バグがどうとかここがどうとかはやる気次第で fix。

とりあえず、最近借りた CVSDude に置いてみたんだけど、認証無しの checkout/export がよく分からなかったので、危機回避だって言い訳してみる。ので、ZIP で置いときます。
OpenPNEデータエクスポータ
mod_openpne の下の、"public_html"以下は、OpenPNE の構成に従ってます。

DB 直読みなので、OpenPNE のバージョン次第で動かなくなる予定。ちなみにテスト環境では、2.0.7.2 だと思う。'06/06/04 よりは前に落としてきたと思うんだけど、自信無し。"OpenPNE/setup/sql/mysql_001_table_structure.sql"を見る限りは大丈夫だと思う。Excel 無いので、2.0 の DB 定義は見れなかった…。

本当は、OpenPNE のライブラリを利用して DB がどうとかは考えない作りにすべきなんだろうけど、まあネタ的に還元できるものじゃないし、内輪ネタで終わるだろう事を予想して、です。

そういうわけ(?)なので、明日暇を見て社内 SNS に仕込んでみます。


!注意!

ライセンス云々はまったくなし(GPL にひっぱられるのかな?)なので、どうぞご自由に。添削とかは嬉しいのでよろしくお願いします。DB 内のデータを壊す事はありませんが、下手においてデータが外部に公開されても責任とれません。必ずサーバ設定なりなんなりでアクセス制限かけてください(特に、WWW 上で利用中の方)。認証かけた RSS を外部サービスでどう読むかとかは Google 先生と相談してください。最後に、『やっつけスクリプト』だと言う事をお忘れなく。

中で使ってる PEAR::DB と Smarty は OpenPNE 付属のやつをロードしてるんだけど、MySQL と PHP の相性しだいで、PEAR::DB が使えないかも。会社のサーバでは PEAR::DB は最新のをインストールして使うようにしました。

[それPla]をいただいたんですが、OpenPNE側の対応への期待と、Plagger 入れるのめんどくさい、あたりで使ってません。インストール地獄を乗り切る自信がなかったのもので…。
たぶん、必要な時間は手作りと大差ない気がする(Perl 環境から用意するので)。長期的に遊んでみたい気もするので、ただいまインストール中です。

今日まで見逃してた Flickr RSS を購読します。

仕事でユーザビリティ改善タスクを進めてる最中なんだけど、『ベストプラクティス!』なサンプルがさっぱりなので、どうしたもんかと悩んだ結果、「そういや Flickr にキャプチャがアップされてた気がする」という結論に。で、いつの間にやら眠らされてたアカウントを起こして、Flickr 内で検索。機械系のインターフェースも一緒に引っかかったけど、まあそれはそれでよしでしょう。

で、"userinterface"タグについて RSS を購読しようと思ったんだけど、検索結果から RSS 購読ボタンを探せなかったので、Flickr Service をうろついてみれば、ちゃんと用意されてた。RSS だけじゃなくて、"php, php_serial, csv, json, sql, yaml, cdf and more."と、色々なフォーマットで取り出せるみたい。
Flickr Services

見た目についての RSS を購読するという事で、しばらく使わなかった LDR をまた使うようにしてみた。RSS も rss_200_enc(enclosure 付き RSS2.0)を選んでみたけど、特に違いは無い感じ。

とりあえず、上の2つを購読してみる事にしたんだけど、購読者1人だったので、なんだか間違った事してる気分。クエリの並びでユニーク(パーマリンク)扱いになってるのかな?クエリ部分のパラメータの並びって内部的にはソートされてるのかな?というか、ソートして内部的には1つの URL として扱うのが普通なの?

さて、これで面白そうな UI 情報が集まってくれると嬉しい。


使いどころがあるか微妙だけど、RSS の URL を簡単(?)に取得したかったので、ブックマークレットを書いてみた。最後のは普通にタグ未指定の URL をブックマークしておいて、ひな形的に利用する目的で使ってみる予定。


検索結果をプレビューする目的で、Flickrfox と Flickr Sidebar 入れてみた。

関係ないエントリにコメントされてたので、多分スパムな気はするけど、RSS2PDF にそっくりなので、サービスの宣伝かな?
RSS2GIF

RSS の URL 入力すると、GIF 画像と、貼付けタグが表示される。相変わらず日本語は化ける。

RSS2GIF
<!-- BEGIN of RSS2GIF HTML-Code -->
<!-- ( Do not change this HTML-Code to keep the image working! ) -->
<a href="http://blog.koshigoe.jp/" target="_blank"><img src="http://www.rss2gif.com/button.php?feed=http://blog.koshigoe.jp/index.xml&count=5" border=0 alt="RSS2GIF"></a><br><a href="http://www.rss2gif.com"><img src="rss2gif.gif" border=0></a>
<!-- ( END of RSS2GIF HTML-Code ) -->

日本語環境では使えないけど、ネタ的にはあり?RSS をサイト内に貼付けたい場合に、ul もいいけど、PDF だとか GIF だとかで表示するのも、ね。

今更なんだと思うんだけど、見逃してたのでメモ。

XUL の Windows 版?XUL は Mozilla の上で動いて、XAML は Windows の上?WPF/E だとかいうのを使うと、Safari とか Firefox の上でも?

いまいちよく分からないんだけど、どうも XUL で出来る事は XAML でも出来るらしい。という事は、IE を開発用にカスタマイズする事も出来るようになる?Web アプリのインターフェースを Windows API を使って作り込む事が出来る?Windows Only が増えそうな気配がして嫌なんだけど、WPF/E に従った(?)状態であれば OSX でも使えるのかな?

XAML を Windows アプリにコンパイルできるとか、Amazon が XAML アプリを作ってるとか、なんだか凄い事なのかな?

.NET 使えるようにならないと駄目なのかな?「XUL+JS でいけるか?」なんて期待してたんだけど、どうなんだろう。XAML を JS でコントロールできるとしても、また変な独自仕様が生まれそうだし。ブラウザの世界では統一なんて夢のままってことかな。

個人的には Windows には用はないんだけど、仕事上ではメインだし、ちょっと注意していかなきゃいけない技術かも。

Google Notebook 挫折気味

使い続けようかと努力したけど、思うほど使い勝手良くないかも。

軽い『まとめ』として期待してたんだけど、SBS ほどの手軽さが無い。表示上の位置を自分で操作しなきゃいけないのが何より面倒。ポスト時のインターフェースが問題なだけなきはするけど、ちょっと嫌になってきた。

はてなブックマークを中断してた時期にたまったノートを全部はてなにポストしたんだけど、ちょっとした量になってた。スパムじゃないのでご勘弁。

ノートはやっぱ『切り抜き』だけにしないと駄目だね。まあ、今の Google Notebook だと、大量のノートを上手く捌けそうも無いし、SBS の RSS を Plagger に食わせて Gmail で管理するのが簡単かも。

大量データを上手い事捌ける素敵なインターフェースが欲しい。どこかに置いてあるデータをインポートしてくれる機能も必須。ついでに、メタデータ拾って勝手に分類してくれると素敵。後、管理インターフェースの方でドキュメントの一部切り抜きとか出来るとワンダホー。最近になってキャプチャを管理する目的で、Picasa を使い始めたんだけど、あれを Web ドキュメントに上手く持って来れないかな?

SBS はブックマークしてメタデータをつけられればいいわけで、そこに UI を期待するのも微妙。ドキュメント管理アプリケーションって形で管理に特化したアプリケーションに UI を期待したい。

時代は Trac?

| コメント(5)

バージョン管理のホスティングサービスCVSDudeを使ってみる。

専用サーバ借りて色々いじろうかとも思ったんだけど、セキュリティ対策とか諸々管理とか、面倒だし多分無理。なので、WWW に置けたら楽しそうな Subversion のホスティングサービスを探してみた。

プロジェクトを立ち上げれば、Sourceforge なんだろうけど、別にそういう訳じゃなくて、雑多なドキュメントとかメモとかも管理したいので、CVSDude を使ってみる。CVSDude は、CVS と Subversion を選べる。で、無料版もあって 5MB のリポジトリを解放してもらえる。Web じゃあるまいし、5MB ってのはキツい気がするので、奮発して有料版を使う事に。

有料版では、1GB の容量が使える。で、ViewVC と Trac をリポジトリ(モジュールだっけ?)ごとに利用する事が出来る。ちょうど、Subversion を使った Wiki を使いたい頃だったので Trac を準備。

CVSDude では、割とセットアップ周りに時間がかかるのが減点。まあ、しょうがない事だとは思うんだけど、有料アカウントが有効になるまで 20 分くらいかかって、ACL の設定にも反映まで時間がかかる。

そんなこんなで、なんとかいじくれるようになった Trac。この Blog とか Wiki に書いてた事を Trac に持っていってみる予定なんだけど、微妙に使い方がまとまらない。Wiki に書くべきか、ファイルに書いてリポジトリにチェックインするべきか。多分、Wiki をインデックス的にしておいて、リポジトリへのリンクを上手く活用してファイルを読んでもらうのがいい気がしてる。Trac の Wiki はそれほど表現力がある訳じゃないし。

書きかけの文章(メモ)を会社と家とで共有したい場合、メールとかファイルアップロードとかで対応してたんだけど、これからは Subversion で出来る。これは多分結構大きいメリットで、書きかけだとしてもログにメモを残せて履歴の差分がとれる。他の方法でも実現できるだろうけど、手順的に Subversion(バージョン管理システム) を利用するのが自然。リポジトリを使い続ける限り、コンテンツとメタ情報が全部残るし、履歴見れたり差分とれたり Trac 使って検索も出来る。

問題があるとすれば、『何入れよっか?』って事だね。物書きじゃないし、何かアプリを作ってる訳でもない。出来る事と言えば、メモ書いたり使い捨てスクリプト書く事くらい。

そういえば、チケット機能はどうしようかな?コメント欄扱い、とか?書く事の ToDo リストとして使う?

怠けたせいで大損だ!

朝日新聞の契約がようやく切れたとほっとしてたら、相変わらず新聞がポストに入ってる。

うざったいけど電話するのも面倒なので捨てて、集金もこないしほっといたんだけど、今日来た。
「3,4,5 に入ってた分サービスするから6,7,8とってよ。」

まあ、捨ててたにせよ商品を受け取ってた訳だし、連絡してない自分が悪いんだから 3,4,5 は払いましょう(足りなくて帰ってもらったけど…)。でも、6,7,8 の判子は押しませんよ。明らかに『戦略』として確立したやり口でしょう、それは。そういうの腹立たしいので、どうせ払うにしても、『過去の分』だけにする。

まあ、あれですね。『訪問販売』の類いは100%無視すべきですね。欲しいものがあれば自分で買いにいくか取り寄せるべきだ。

さて、支払いまで1週間あるし、お金おろしてくるべきか、法律勉強すべきか、消費者センターに相談に行くべきか…。


新聞屋さんってどこもこんな感じ?西東京市に住んでるんだけど、問答無用なやり方は反感買うだけじゃない?

社内 SNS が Grouptube から OpenPNE に切り替わりつつあるこのごろ。

OpenPNE はどうも RSS をはいていないようで、何かアイデアを書いてもそれが読まれるまで微妙な時差がある。仕事してると、『通知』されないとそのまましばらくログインしないってことはよくある。なので、何かしらの方法で『通知』してくれると嬉しい。

標準セットアップをしていると cron 使ってデイリーでメール通知はしてくれる。更新された日記とか、足跡ランキングとか。けど、やっぱ RSS は欲しいところ。だけど、認証 RSS はまったくもって未整備状態(だと思う)。Basic 認証書けたとしても、受け取れるかはクライアント側の対応状況にもよるし。

で、『RSS は社内だけで受け取れればよし』っていう制約をつけると、やりやすくなる。どうにかして RSS を生成して、生成した RSS を社外からアクセスできない位置に置いたらいい。社内であれば、認証がどうとかなんて意識する必要ないし。チーム間で秘密にしなきゃいけない事も、今のところ無い。

で、RSS を作る方法なんだけど、今のところ『どうしよう?』な段階。OpenPNE の API を利用するか、それとも DB ぶっこ抜きなスクリプトを書くか。正直、適当スクリプトを書くのが楽かな、と思う。SNS 案件がありそうなら、OpenPNE を探る意味で API 利用もありだけど、特にないし。

あとは、全体、ユーザ別、何かの条件とかでのフィルタリングが必要かも考えないと。まあ、考えるだけで、実際にやるかは分からないんだけど。意見だけ出てる段階で、本当に必要なのかは分からない。

ちなみに、まだ OpenPNE を外部からアクセスできない状況なので、月曜あたりに外部アクセスできるようにしようかなと計画中。セキュリティ的に色々つめないと。

あと、しばらくセッションを PHP のものを利用していたんだけど、どうも有効期限が上手く設定できてなかった感じ。php.ini で24分有効で、OpenPNE で5日有効になるように設定してると思うんだけど、その辺の設定が上手くいってない感じ。なので、セッションは DB で管理するように変更。これで、頻繁なタイムアウトと自動ログインできない問題が解決できればいいんだけど。月曜にチェック。

もう1つ大事な問題。実は、OpenPNE はセットアップしただけで、こまごまとした設定は人任せだったりする。ので、モジュールがどうとかっていう事については知らない。OpenPNE で出来る事できない事を調べてから動かないとね。


REQUEST/19 -
要望は出てるけど、まだ取りかかってない、という事らしい。

Scuttle + Plagger に挑戦

atode.cc クローンを Scuttle の RSS を対象にテスト。
subtechグループ - Bulknews::Subtech - atode.cc クローン by Plagger

del.icio.us の URL を Scuttle の URL に修正すれば問題無し。1エントリ1メールで無事取得。
Gmail だからなのか、スタイルは完全に壊れ。

なんで、Scuttle かってのは、社内リソースを『読んで』メールしたかったから。自分に『後で読む』じゃなくて、チームに『後で読んで』。ドラフトを Wiki にまとめて、レビュー前のプレビューを呼びかける目的で URL を貼ったメールを ML に投げたりするんだけど、URL だけのメールって基本的にスルー感たっぷり。特に、レビュー前プレビューみたいな強制じゃないお願いメールだと顕著(だと思う)。ので、ちょっとでも目に留めてもらえる可能性をあげられたらな、と。

ブックマークにたまった内容を cron 経由でメールするよりは、今見てるコンテンツをブックマークレットで直接メールする感じの方がやり易いかも。『読んで』はそうそうあるもんじゃない気がするし。

ひとまず、自分用にセットアップして試してみようかな。

MT を使ってみようと始めたブログ。気がついたら1年以上書いてました。

なんとなく、独自記法を持つホスティング系のサービスに乗り換えてみようかと検討中。

プロフィール

このアーカイブについて

このページには、2006年6月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2006年5月です。

次のアーカイブは2006年7月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。