2005年11月アーカイブ

気になったので、メモ。 RSSリーダー使ってません。 [絵文録ことのは]2005/11/30

「RSSリーダーを使う・使わないは、ウェブ利用技能の格差とかそういうんじゃなくて、閲覧行動の違いによるものではないの?」

フィードの履歴

RSS+SSEを少しずつ訳しながら読んでいる最中。

で、SSEではアイテムの更新履歴とかを参照できるとか。アイテム単位もいいんだけど、フィードの流れていくアイテムを履歴として追いかける事が出来ないかなと思う。

dc:sourceとかdc:relationとかを使う事は許されないだろうか。アイテム自身はrdf:aboutとかで示せるから、dc:sourceとか使ってもいいなじゃないかなと浅はかに思ったりする。これは、サーバ(publisher)がデータを保管し続けるってことが基本なんだけど、ユーザ(subscriber)の利便性とか考えると流れたアイテムを追いかける手段を用意するのはいい方法だと思う。

何かしらのタグを履歴URL用に割り当てて、そこから辿っていける様になれば途中からフィードを登録した場合でも色々見れるだろうし。ろくに調べてないから、既に用意されてたりするかもしれない。

# dcも適当なので、間違ってたらごめんなさい。

グーグル、新通話サービス「Click-to-Call」のテストを開始 - CNET Japan

これは『広告』からだから新しめなのかな?skypeとブラウザとの連携から、ウェブコンテンツから直での電話に対応みたいな事って、もう当たり前なの?

skypeは使った事無いし、VoIPすら使ってない。電話自体が全く興味がないというか苦手分野なので、さっぱり追いかけてない。で、ウェブと日常の連携を考えていくと、PCからの電話利用者が増えれば、当然ウェブコンテンツ上からのダイレクトコールにも対応していくのかなと思う。

まあ、出て来てから言ったところでどうしようもないけど、とりあえず気になったのでメモ。skypeとかどうなってるか調べてみた方がいいのかな?

メモ。
JUnitテストコードとテストデータを分離 - JTestCase 3.1.0 公開 (MYCOM PC WEB)

ユニットテストを行うときに、テストデータはそのユニットテスト内で作る事が常識らしい。当たり前なんだけど、データはSQLとか書いて(吐き出すプログラム作って)用意したらいいかなと勘違いしていた。

で、その際にデータを埋め込む事は考えた方がいい。不変だったり小さい物だったりするなら直接書いても問題は無い。ただ、それなりに変わる気配がある場合は、データを分離させて管理した方がいいかもしれない。

テストを手早く作る場合は面倒かもしれないけど、その辺りをフレームワークで対応してくれるような場合は積極的に取り入れた方がいいかも。

# 『分離重要』

引っ張り過ぎかもだけど、XML開発者の日に聞いたことからもういっちょ。

ブログの「次」はこれが来る。DWS(デーサイ)=データベース→サイト化ツールの時代 [絵文録ことのは]2005/11/29
筆者の考えとはずれるかもしれないけど、近いかもなと思った。

web2.0の基本(?)にアグリゲーションがある。で、アグリゲーションに大事なのは、拾ってくるデータの合意がなされているか。HTML拾って、パースして、DB突っ込んでってのはとても苦しい。で、合意がなかなかとれないなら、箱庭作ってそこでごにょごにょしたら面白いんじゃないか、って感じの事を山田さんが言ってた(と思う)。

で、DB中心にして、プラットフォームでパブリシングってのはこれに近いのかなと。Google Baseもだけど、まずデータを一定のフォーマットで集めて(用意して)、表現はプラットフォームがテンプレートとか使って自由に処理する。ここで、中心は『データ』であって『機能』ではない。通常、機能デザインからデータデザイン(モデリング?)が決まる(かな?)。ある商品のリストを作りたいから、こういうフォーマットのデータを用意しようみたいに。

データから入る事で使い勝手のいいサービスとかアプリケーションとか作れそうな気がしてる。

# ちなみに、作れそうも無いので『誰か』に期待組です。

『フレームワーク重要』の波に乗って、強めの関心を持っているフレームワーク。当然なのかもしれないけど、開発環境がフレームワークを基準に作られるのはいい事だと思う。
Ruby on Rails統合開発環境 - RadRails 0.5公開 (MYCOM PC WEB)

最近、自分が『厨』というやつだという事が分かって来て、最悪な事にフレームワークをずたずたにするような事をやらかしている事に気づいた。これはとても致命的なミス。ミスというか懲罰物。で、フレームワークを保護しつつ快適に開発を進められるツールがあると良いなと思ってたら、RubyではRails用の統合環境(eclipse)が用意されているらしい。

MSのVisualStudioもそういう感じかとは思うんだけど、ウェブ開発言語(?)系でこういうのがあるのは知らなかった。ウェブ系だと案件にあったフレームワークから作り始めるみたいな事が自然(?)らしい事も聞いたりして、あまり結びつきというか決定版を常に使うみたいな事はしづらいとかなんだとか。でも、その辺は拡張とかで対応してベースは常に同じやつでいいんじゃないかなとかも思う。基本を突き詰めるのはどこかが一手に引き受けてくれた方が効率的な気がするし。

というわけで、『Zend Studio+Zend Frame Work』出てくれないかな。symfonyが素晴らしいなら、symfony+eclipseとかでもいい(統合環境用意してくれるなら)。

自動テストもアジャイル

会社の方で、自動テストツールの見直しをしている最中。

で、色々見ていたら、どうもテストも迅速な開発が求められるらしい。当然と言えば当然。テストファーストの流れを考えると、テストを手早く作れなきゃ実装が押されに押される。

JMeterはGUIとかレポートの豊富さとかで、割といいかなとか思う。だけど、癖が強いというか、どうにも扱いずらかったりする。高機能故の弊害って事なんだろうか。

最近教えてもらったPHP用のSimpleTestっていうテストフレームワーク(?)が良さそう。テスト開発を迅速に行うとして、何がポイントになるのか。とりあえず、標準的な機能は備えているとして考える(何が標準かは考えない)。

レポート機能
テスト結果を詳細にレポートしてくれる機能。エラー箇所の特定が主な目的。動作監視などの目的でループ実行している場合の通知機能など。表示に拡張性があればなお良し。
開発環境
開発の手間を減らすツール群など。GUIベースでステップを減らす。プログラミング(スクリプト)言語を利用して慣れた環境を使える。プログラミング言語で作る事が出来れば、既存ライブラリなどを利用して独自の強力なテストツールを作る事も可能。コーディングの手間か、ツール習得の手間のトレードオフ(?)。
拡張性
提供されるフレームワークに無い機能が必要になった場合、フレームワークの提供元に依存する事無く機能を得る事が出来る。テスト開発自体の手助けにもなる(ツール改良)。
ラピッドな開発
小さな物を作る場合、手軽に開発を行える体制が必要。テキストエディタ1つで済ませる事が出来るのは魅力。
軽さ
簡単な動作監視を目的としてループ実行するような場合、実行環境に負担をかける事は避けたい。クライアント環境で実行する場合、テスト実行中は作業を中断する事態に陥ると最悪。

今まで、『テストツール』という言葉を使って来た。なんだか、これは違う気がして来た。テストツールというツールが存在する事はいい事なんだけど、効率とか色々突き詰めていくと使うべきは『テストフレームワーク』『テスティングフレームワーク』なのかな。

テストも『開発』するもの。

とうとうこの日が来た。

資料が出そろったのでwikiもとりあえず完成かと思います。
koshigoewiki:rest:第8回xml開発者の日 [KoshigoeWiki]

# 講演者の皆様、ありがとうございます。

IQテストで適職

右右か右左のモノ派。どっちが解き易いとかわかんねっつの。

現職がエンジニアで、陶芸家に憧れる。なので、ぴったんこ。
IQは57正解の102。平均の人。

RSS3.0はネタ?

なんだか、先のエントリで書いたRSS3.0はネタらしい。

RDFが複雑だとか冗長だとか言われてるから、XMLとかnamespaceとかを無くす事で皮肉って、「これでいいか?」みたく出してみたらしい。

で、別のRSS3.0もあるとかないとか。
RSS Version 3 Homepage

前者は、"Aaron Swartz"っていうW3CのRDFのワーキンググループ所属する、RDF推進派らしい。後者は"Jonathan Avidan"って人が初期ドラフトの"Editor and contributors"って事らしい。RSS3.0として本当に考えられてるのは、後者の方なのかな?どうもRSS2.0を継承(?)して考えられてるとかいないとか。

仕様は同じ名前なら旧版は淘汰されていって欲しい。

RESTのよくある間違い

鉄は熱いうちに叩けと言う事で、今のうちに読んでおく。
REST でよくある間違い
XML開発者の日で講演された山本さんによる翻訳。英文だと読む事に疲れて理解するまでに至らなかったりするので、非常に助かる。以下は読んだ感想というかメモ。

extedit

気になる。
MOONGIFT - extedit - オープンソースによるIT戦略支援 -

ブラウザ((X)HTML)のテキストエリアからコンテクストメニュー経由でエディタを起動、閉じたらその内容が反映される。ちょっとした手違いでテキストが消えてしまうような事態を防ぐ事が出来る。

なんで、windowsだけなのさ…。というか、IE限定?公開サイトで紹介されてたAreaEditorもIE限定か。IEコンポーネント使ってれば対応可能だとしても、職場の主戦場(?)はFirefoxなんだよな…。今更IE使いたいとは思わないし。OSXだと5.2とか使わなきゃだし、WSHが前提らしいから結局Windowsだしで…。

結局、エディタで書いてから貼付けろってことかな。BlogとかWikiならともかく、ちょっとしたフォームの時を考えるとコンテクストメニュー(右クリック)経由は使いたいなぁ。

なんだかAJAXをHTMLレベルに落とし込んだっぽい、AHAHってのがあるとか。
rest/ahah - Microformats

MyWeb2.0経由でRESTってのに引っ張られてみてみたら面白そうなので。XMLHttpRequestで(X)HTML取得して、それをinnerHTMLとかに流し込んで動的に行こうじゃないかってこと?しっかりとドキュメント読んでないから自身ないんだけど、多分そうだと思う。取得結果が(X)HTMLだからCSSで色々いじれるぜってのも書いてある気がする。

AJAXをシンプルに利用場所を限定的にしたって事かな?とりあえず、ドキュメント量もお手軽な感じだし、ちゃんと読もう。

新フォーマットRSS3.0

第八回XML開発者の日で山田さんが話してて、MyWeb2.0でブックマークされてたのでチェック。
RSS 3.0
The Road to RSS 3.0 (Aaron Swartz: The Weblog)

XML開発者の日に行ってよかったなと思うのは、色々な話を聞いた結果物の見方が変わったって事。それだけ『出来ない君』だって事なんだけど。『制約は利用者側の負担を減らす』ってのをはっきりと認識できたのがとても大きな収穫。会の主題であるRESTとは直接関係ないんだけど、基礎部分がどういう意味を持って作られたとかその辺を教えてもらえた結果、漠然と「知ったつもり」になってた物の輪郭が多少はっきりしてきた。

何をどうするためにあるって所を認識するかしないかで、色々と出来る事とか変わってくるなと。何かを利用するときに選択する基準は、それを使うと何が出来るかをしっかりと考えないといけない。アーキテクチャスタイルとかデザインパターンとかの基礎部分では特に顕著で、この部分で選択を誤るととんでもない事になる。

かなぁ。

『とりあえず勉強しなきゃ』ってことで始めたデザインパターン。

Google Personalized Homepageとかnetvibesとかでは、1枚の紙に付箋を貼付けるような感じでモジュールを配置していく。

このやり方だと、モジュールの追加・削除が簡単。ただ、表示領域が狭くなる事の弊害がある。フィードとかでタイトルをリスト表示するときに、折り返されるからどうにもモッサリしてしまう。それに、1ページに機能が乱立するのも問題かもしれない。1ページで全てが完結するってのはいい事かもしれないけど、結局出来る事が制限されるような気もする。

ライトなものなら問題は無い気がするけど、ユーザビリティというか利便性を考えると、上手い事ページングというか『表現』を考えないとまずい気がする。個人的に、モジュール化する事で期待する事は、『機能連携』による恩恵。別にポケットサイズみたいな事はどうでもいい。付箋感覚でぽこぽこ貼付けられるのも面白いんだけど、使い続ける場合結局機能を要求する事になる。

なんでこんなことを今更考えてるかって言うと、ちょっと前に書いた『フィードリーダーはモジュールとして提供する』って所を考えてたらこの辺大事かなと。今は1つのアプリケーションとかサービスとして成立してるweb2.0的なやつも、色々とモジュール化した方が面白くなるんではというのがありそうだし。特に、フィードとかブックマークとかナレッジツール(?)周りはモジュール化して、プラットフォームに埋め込む形がいいかなと思う。

Windows Vistaでフィード周りがどう実装されるかがよくわからないけど期待してしまうのは、フィードがプラットフォームレベルでサポートされるから。OSの機能を利用してフィードをどう操作する事が出来るのか気になる。色々な機能からフィードをいじれるから可能性も色々と広がってくる気がする。一番はフィードの利用者層拡大だけど、この辺も大切。

で、とりあえずフィードとかブックマークみたいなリスト表示のものをどうするかをちょっと考えてみる。テキストリストは十分な領域が確保されてないと折り返しが必要になる。もしくは省略表記とか。で、十分な領域を確保しようとすると、1ページ1機能とか全幅かつ縦分割くらいの選択肢になる。あとはページングとかタブとか。リスト幅を節約する方法の1つに、リストアイテムのアイコン表現がある。URLの場合、該当ページのスクリーンショットからサムネイル作ったり。一覧からの視認(ぱっと見)はタグとか上手く使えそう。title属性とかでテキストを表示するとか。

とりあえず、折り返し表示されるものは出来る限り使いたくないな、と。

予想以上にBMされた

『第八回XML開発者の日』での講演内容を今日会社で報告(プチ勉強会)する目的で、取り急ぎながらwikiにまとめたのが昨日の夜。

結局、会社での報告はまとまりのないいい加減な物になってしまい、同僚を混乱させた上に最終的にはなんだか同情されてた気がする。「REST最高!」な状態には持っていけなかった。ごめんなさい。

で、発表用にまとめたwikiが予想以上にBMされててちょっと困った。ありがたい事なんだけど、今日発表したらどうにもtypoだらけだし、意味わからないしと。一番やっちゃいけない、『発表者の名前漏れ』をやってた。SixApartの平田さん、ごめんなさい。急いで直しました。

とりあえず、wikiの方はtypoを直すとか程度で終わると思う。『まとめ』ってコメントに書いてくれた人もいるけど、『まとめ』というか『殴り書き』そのままです。

# インターネットイニシアティブの山田さんの資料が是非欲しい。どこかに置いてあるかな?

プレゼン資料が欲しい…。

カメラとかレコーダーとかの類いを用意せずに出席してしまった。なので、かなりメモしきれなかった。まあ、そういう阿呆がくる事は考慮してなかったんだろうけどさ。印刷代も馬鹿にならないしね。

メールとかしたら送ってもらえたりするのかな。アドレスもメモするの忘れてるんだよな…。帰り際に確認すべきだった。

###
発表者の方々に直接問い合わせるのって失礼?プレゼン資料を人に渡すの嫌がるとかもあるかな。ブロガーさんのはブログ回って探してみよう。

RESTを考えていく中で、フレームワークでのURIマッピングは重要らしい。

RESTの制約として、url-rewriteが禁止されている。なので、Apacheのmod_rewriteとかで無理矢理マッピングするのは駄目という事。で、柔軟性(?)とか設定ファイルの管理とか考えるとフレームワークに取り込んでしまおうと。フレームワークの制約の中でURIデザインが出来る様になるし、いい事ずくめ?

で、実現するにはどうしたらいいんだろうということで、symfonyのドキュメントを読んでみた(symfony PHP5 framework » How to setup a routing policy)。

Symfony can natively transform output URLs and interpret input URLs. Consequently, you can create bijective associations between URLs and the Front Controller. This rewriting, called routing in symfony, relies on a configuration file called routing.yml that can be found in the config/ directory of every application.

YAMLという規格を使って実現するらしい。とりあえず、symfonyを使えばCool URIでウェブアプリを実装できるという事か。

YAMLはとりあえずはてなダイアリー - YAMLとはで調べた事以上は知らないので、Rubyist Magazine - プログラマーのための YAML 入門 (初級編)とか読んで勉強する。合わせてというか、こっちが本命だったりするんだけど、symfonyのドキュメントを読まないと。

# そういえばZendがフレームワーク用意してくれそうなんだっけ?

Google Desktopは乱暴者?

Feedburnerを見てみてびっくり。

とりあえず、たいした事書いてないのに購読者数が増えたり。まあ、これは嬉しい気がするから良し。

問題は、Google Desktopから150を超えるアクセスがあるってこと。Circulationが3に対してHitsが156。これは、304とかを見てないからか?見ててもHitsは増えるのかな。3人で割って、24時間で割って、1時間に2Hits以上?Bloglinesだと5:9だから、やっぱ304な気がする。

JSのXMLHttpRequestはどうも20xとそれ以外みたいな分け方らしいというのを小耳に挟んだり。Google DesktopのモジュールはJSベースで開発できるらしいしそれが原因か?30xを理解できないクライアントでフィードを触るのは危険かも。

要チェック(自分)。

頭がパンクしそうになって帰って来た。

RESTはWWWのアーキテクチャで、スケーラビリティを向上させるために導入するものらしい。Uniform Interfaceとかサーバー側をステートレスにするとか。あと色々。

Cool URIのURIマッピングをフレームワークに取り込む事でURI設計に制約を設ける事は重要らしい。結果的にRESTに近づくとかどうとか。AtomPPはいい感じだけど、厄介な制約とかあって、結局Basic認証+野良XMLってのも捨てがたかったり。

AtomにはAtom SyndicationとAtom Publishing Protocolがあって、RSSと比べたりされてるのは前者。RESTを実装する際に利用されてるのが後者。

WebDAVとAtomPPとの比較は階層アクセスか直接アクセス(ハイパーリンク)か位しか理解できなかった。使い易そうなのはAtomPPだしAtomフィードの制約が問題にならない場合は、とりあえずAtomPP使おう。

トラックバックが海外では(あまり)使われていないってのはびっくり。SixApartが定める仕様で、MTから実装されているらしい。海外のウェブログ状況ではMTは後発だから、先行サービスではサポートされてないとか。ウェブログはトラックバックありきってのは日本独特。
トラックバックをシンプルにREST-likeに独立したプロトコルとして実装した事で、クライアントアプリケーションが作り易くなったとかユーザーに易しくなったとか。結果、利用者(対応ウェブログ)が増えて、SPAMもついて来たと。

AJAXがRESTを駄目にするってのは言い過ぎ。AJAXでも状態に対してURIを発行する事は出来る。Web2.0を考えると、リソースとかCoDとかが変わって来てるんじゃないかと。remixingの影響で1つのURIに対して複数のリソースが紐づいたり、XMLHttpRequestの影響でクライアントが複数のコネクタを持ったりと。AJAXを活用してよりスケーラブルなRESTを実現できるかもね。

取り急ぎだけど、wikiにまとめてみた。
koshigoewiki:rest:第8回xml開発者の日 [KoshigoeWiki]

行って来ます。

とりあえず、思い浮かぶままにメモ。

フィードリーダー必須機能

未読管理
複数環境で利用する場合に重複した記事を扱う手間をなくす(状態維持)
2度読みを防止して最新情報を探し易くする
見逃しを防ぐ
フィードに掲載されたアイテムは全て取得可能
帯域軽減
更新状況を確認して無意味なアクセスを制御する
読み易さ
大量のアイテムを簡単にさばける様に連続フィールドをサクサク読み進められる
購読リストのエクスポートとインポート
登録の手間を減らす
カテゴライズ
フィードの性質に従った分類
コンテンツへのアクセス
アイテム全文を必ず取得できる
登録し易さ
feedプロトコルやブックマークレットなどを利用して半自動的な登録を可能にする
読める
規格に依存せずにvalidであれば全てのフィードを読める
利用者に技術的な要求をしない

フィードリーダー発展機能

未読管理のスケジューリング
不在期間の更新アイテムをスケジューリングによってリーダー以外に退避させる
更新通知
未読アイテム数の通知
別クライアントでの購読
メールクライアントなどへの移送
アイテムのフィルタリング
キーワードなどによるフィルタリング処理
購読リストの共有
知識共有など
保管
クリッピングやマーキングで注目するアイテムを保管する

どうでもいい事だけど、先のエントリーでスケジューリングとか考えててふと思った事。

Bloglinesに限らないけど、数日放置するととんでもないことになる。

最近、ToDo管理とか業務効率とかに興味がある。
i d e a * i d e a - バブルマップのすすめ ~ ストレスすっきり解消型ToDo管理手法 ~

優先度を視覚的に表現するってのはいい感じ。で、それを紙に書くのが素敵。ToDo管理をする際に、トラッキングを考えるとデジタルデータで残す事は大事。でも、1日の予定とかは紙とかに書いて目につくところに常に置いておく方が好き。

どうも年の割には物忘れが激しいらしい。注意力散漫というか、いい加減というか。なので、最近では癖になってきた『仕事する前に紙に書く』事にはかなり助けられている。個人的(当たり前?)に『タイピング』より『書く』方が印象に残る。PCのデスクトップ上に付箋を貼るよりも、紙に書いて貼付ける方が好き。許されるならでっかいボードに沢山貼りたい。

後、大事な事を誰かに伝えて答えをもらいたい場合、相手に直接渡す事も大切かなと思う。BTSで管理してる中で、『確認』プロセスだけはBTSからのメールに加えて確認バトンを渡す様にしている。直接相手に渡す事でコミュニケーションが生まれ、注意して欲しい事とかを直接相手に伝える事が出来たりする。

チーム作業で一番大切な物はコミュニケーション。コミュニケーションはやっぱアナログが一番。

styleCatcherでデザイン変更

何となくブログのデザインを変えてみようと思い、styleCatcherを利用。

テンプレートをMT3.1の頃の物を使い続けていて、styleCatcherに合わなかったのでdefault_template内の該当ファイルをそのままコピペしてしまった。テンプレートをデフォルトに戻す際は、"Template Backup and Refresh Plugin"を利用して、テンプレート編集メニューの『テンプレートを更新する』から行わないといけない。ファイル内ではMT_TRANSタグが使われていて、そのままりようすると表示されないテキストがぽつぽつ出て来てしまう。

JSとかCSS周りで色々と不具合が出てそうだけど、とりあえずこれで良し。

参考:Movable Type 4989 - Troubling

# んー、#moreは無きゃ駄目なのか?2重のパーマリンクとかよろしくない気がするけど…。

メモはSocialである必要も無い気がして来たので、Bloggerを利用して個人ナレッジベースを作成。

Bloggerにはカテゴリがないみたいで、del.icio.usとかを利用して無理矢理記事にタグをつけるみたいな使い方らしい。サイドバーにdel.icio.usのタグを表示させて、カテゴリーアーカイブ代わりにdel.icio.usを使うってことか。エントリーの下部にdel.icio.usへのポストリンクをつけるために、テンプレートに以下を追加。

<a href="http://del.icio.us/post?url=<$BlogItemPermalinkUrl$>&title=<$BlogItemTitle$>">post del.icio.us</a>

del.icio.usのタグはtagrollsを利用して貼付けてみた。
del.icio.us/help/tagrolls

使い勝手を良くするには、まだまだいじらないとだけどとりあえず試してみる。

キーボードが欲しい

またそそられるキーボードが出て来た。
NIPPON STYLE:: 防水ステンレスキーボード&トラックボールマウス

LEDキーのやつはいつでるんだ?
Optimus keyboard

Optimusの方が欲しい感は強いんだけど、面白さ的に防水にもそそられる。Apple純正を使ってるけど、なんだかすぐ汚れるから早いうちに切り替えたい。

最近勉強不足を実感して来たので、デザインパターンから勉強してみようと本を購入。

増補改訂版Java言語で学ぶデザインパターン入門
結城 浩
ソフトバンククリエイティブ (2004/06/19)
売り上げランキング: 7,578

最初から読み進めてみて、とりあえずUMLを多少分からないと駄目らしいのでそこからメモ。

2.0.3からずっとアップデートせずにいたら、2.1.1使ってる人のファイルが開けなかった。

バイトがどうこうというメッセージが出てしまう。どうやら、XML宣言部分が省略されているらしい。2.1.1にアップデートしてとりあえず対処したけど、これはどんな目的で変更したんだろう。

JMeterもまとめないとなぁ。seleniumとか追っかけたいけど、まずJMeterだよな。

C.C.を予習

多分、そのうちC.C.に対応しないといけなくなるので予習。
軽くWikiの方にまとめた(永遠の草稿)。

タグから興味マップ

MyWeb2.0のタグがついに500を超えた。

個人的に、タグの数を抑えるのはどうも無理っぽい。それでも、これを整理したい。

PHPで関数とかを試す環境

terminalでPHPをシェルっぽく実行できるphpaを試そうかと思ったら、readlineがMAMPでは無効になってて挫折。ブラウザ上から実行できるPHP Interactiveで代用。

PHP Interactiveは結構前に知ったんだけど、いまいち活用してこなかった。ソートとかXMLパース関係でもうちょっと使ってもいい気がする。環境変数とかを使う際にも結構ファイルを作って実行したりしてる気がするから、これからはこれを活用して多少なりともスピードアップをはかろう。

来週木曜はXML開発者の日

いよいよ1週間後に迫って来た。

まずい、予習してない。隅っこでおびえながら聴いてるしか無いかな。翌日に会社の勉強会で発表しなきゃいけない雰囲気だし、どうしよう。

ノリでなんとかするしか無いかな。REST周りだけでもしっかり予習していこう。あと1週間あるし、週末を使えば何とかなるか?

Googleのサービスラッシュにあやかってみた。

Google Analytics
Google Base

目的がはっきりして使ってる訳じゃないから、特に書く事はなかったりする。

Baseの方はようやく使える様になったみたいなので、ここのトップをReviewとして登録してみた。テキストフィールドも基本的に選択式(候補が選べる)みたいで、サクサク登録できた。ラベル入力でtypoが許されないらしく、怒られてしまった。親切な作りなんだけど、軽くへこむ。勉強しなきゃなと。

Analyticsは奇麗なUIが素敵。レンタルサーバーについてるWebalizerはApacheのログから集計する分、余計なデータも拾ってるからちょっと嫌だった。別に解析結果から何をしようってつもりも無いんだけど、無料だし折角だから使い続けてみる。BlogとWikiにコード埋め込んでみた。ドメイン直下にコンテンツ置いてなくて、コードが見つからないっていうメッセージが出続けたので、/index.htmlを作ってそこにもコードを埋め込んで解決。

パーソナライズとかサイトマップとか、どんどんローカライズされていい感じ。MyWeb2.0はずっと米版なのかな。

フィードにC.C.を入れる

以前、C.C.はchannelレベルなのかitemレベルなのか迷った事がある。これは、再利用の対象を考える事で整理できそうな気がして来た。

フィードリング

RSS2.0の仕様書を読み返してみて、commentsで何か出来ないかなとひねり出してみる。

RSS 2.0 Specification
ちょっとしたメモ - RSSのtaxonomyモジュール
FOAF -- メタデータによる知人ネットワークの表現

検索履歴を記録して、エンジンを利用者ごとに最適化するサービス。
使うほどに賢くなる日本語の「Googleパーソナライズド検索」開始 - CNET Japan

会社で.jpなのに、どうも右上が怪しい感じがしてた。これまではFirefoxの検索窓をgoogle.comで使って来たけど、これで.jpでも使える様になった。

行動を監視されてる感じがして色々批判はあるみたいだけど、検索を利用者ごとに最適化するには行動記録が必然。これをサーバベースにするのかクライアントベースにするのかってのは色々考えられるかもしれない。ただ、ブラウザ利用の場合クライアントサイドに記録するためには、多分cookieになる。それ以外に考えられるならいいけど、cookieは別サービスからクラッキングされる危険性もあるしどうだろう。

そういえば、googleアカウントって何だろう。ずっとGmailアカウントで使ってるから、その辺全く調べてない。正式サービスは一律で専用のアカウントが用意されてるのかな。これまでのデータを引き継げるなら使った方がいいかも。メールアドレスがアカウントってのはどうも危険な気がする。

IMAPでRSS購読

Web上のフィードをIMAPサーバに送信して、IMAP対応メーラーでフィードを購読する。
rss2imap - RSSの管理をIMAPで行うソフトウェア

日頃使い続けてるサービスからか、どうにもネタに困るとSBSを考えてしまう。

とりあえず、そろそろ何かしらの変化を見せてくれ。どこも作った後は大して変わらない。データもそこそこ集まって来てるだろうし、ここらで面白いフィードバックを返してくれ。タグとか時間変化とか何でもいいから、ソーシャルである事の価値を与えて欲しい。

まさか、これでSBSっていうサービスが完成した訳じゃないと思う。未だに『タグ』ってものが曖昧なままなのに、それを取り入れているSBSが『これでよし』な訳がない。どこぞのサービスではタグが固定されてたりするし、『タグ』ってものでラベリングする意味がはっきりしない。そういう状況を打ち破る一つの方法がSBSだと思ってる。

本当にしつこいけど、SBSは『ブックマーク』のまま終わるのか?ナレッジベースとして、ソーシャルでオンラインである事の強みみたいな物を活かして、素晴らしい価値を提供してくれたりはしないのか?

ネタに困ってひねり出そうとしたけど、結局残りかすしか出てこなかった。自分で考えて自分で処理しろって言われたらそれまでのネタ。

反省。
切込隊長BLOG(ブログ) - 「Web 2.0」とやらについていけない人、集まれ!!

でも、web2.0って技術者向けでいいんじゃないの?技術を使ってお金を儲けるのはビジネスマンの領分だ、と言ってみたい。「ウェブが一般的になって結構起つしそろそろまとめてみるか」ってことで、技術傾向をまとめてみた結果のアウトプットがweb2.0とか。そんな程度で考えてた。ビジネス向けに分かり易く納得できる様に説明出来てないってのは問題だけど。

まあ、web2.0なんてのはことさら構えて口に出すもんじゃないし、ある目的を達成するために成功してるやり方取り入れて、面白い物を提供するって考えてれば問題ないでしょう。じゃあ、何やるのってなると困るんだけど。

面白いもんは面白いし、具体例が沢山でてくるならそっから正解とか不正解とか考えていこう。

portabilityだかavailabilityだか

どういう用語が当てはまるかは分からないんだけど、『データの持ち運び易さ』みたいな事は大事だなと。

MyWeb2.0の文字化け回避

MyWeb2.0のSaveブックマークレットは日本語が文字化けするので回避する。

OSXのFireFoxはフォームパーツがもっさりしてる。
Firefox まとめサイトを見てたら、これを解決してくれるアプリケーションがあった。

Travellers Inn - Software: Aqua Firefox Set
インストーラを実行して終了。
「アプリケーションの検索」に随分時間がかかったけど、無事インストール出来た。

# フォントが勝手に変更されてた…

テストと正規表現とID

JMeterを利用したテストで多用するのが、正規表現を利用してレスポンスから特定箇所の抽出。

クリエイティブコモンズのライセンスを埋め込んでも、使われなくては意味が無い。ライセンスを意識してコンテンツを選別しようにも、ライセンスが埋め込まれていなければ意味が無い。

Creative Commons: search results
Google Advanced Search
Yahoo! Search - Web Search

Dokuwikiのプラグイン"keyboard"を入れてみた。

<key>C-x</key>とか書くと、CSS効果でキーのアイコンっぽく表示される。

インストール手順(詳しくは上のURLで)
まずはダウンロードして解凍。
lib/plugins/に解凍して出来たkeyboard/を入れる。
keyboard/style.cssの内容をテンプレートのCSSにコピー。
KoshigoWikiではsidebarを利用しているので、lib/tpl/sidebar/design.cssにコピー。

編集画面にショートカットボタンを追加
アイコン画像をダウンロード(keyboard.png)。
lib/image/toolbar/にアイコン画像をアップロード。
inc/html.phpのhtml_edit関数内に、"formatButton..."が連続しているところがあるので、そこにコードをコピー。
inc/lang/ja/lang.phpにアイコンのALTテキストをコピー。
コピーするコードは配布ページから。

プラグインの言語ファイル
lib/plugins/keyboard/lang/以下にはde/とen/しかないので、en/をコピーしてja/にリネーム。
気になるならja/lang.phpの内容を好みで修正。

正しく作業するためには、配布ページのドキュメント(英語)を読む事。

# XHTMLの独自マークアップにスタイル当てて実現

SBSをノートベースにしたサービスがあった。
TagFacts

MyWeb2.0のAPIをもう1度調べて軽くwikiにまとめてみた。
koshigoewiki:myweb2.0 [KoshigoeWiki]

以前作ったSBSのタグレポートで今週のメール通知を見てみる。

はてなBMの/entry/はなぜかフィード未対応。

更新を追う意味でもフィードを出してみてもいいと思う。
と、いうわけでbookmarkletで出してみる。
チェックしたいページ上でBookmarkletをクリック。
RSS2.0で/entry/の内容を取得。

無保証です。
とりあえず、socialのデータを集める補助ツールとして試作。

# 前も同じ事してた気がする…

###
↓で直接とる
http://koshigoe.sakura.ne.jp/HatenaBMEntry/feed.php?permalink=***

Rojoの怪

ここしばらくRojoを試している。

SBSホームレス

はてなBMに出戻ってみたけど、1日で家出。

パーソナライズされたホームページをweb2.0的(?)に考えてみる。

ウェブアプリケーションをリリースするまでに、開発チームで追いかける情報を考える。ただし、システムは出来上がっていて、修正や機能追加などによるリリースとする。

グループ開発は難しい

精神的に未熟なせいか、グループ開発がものすごく難しく感じる。

さっき取り出したMyWeb2.0Betaのデータをはてなにインポートする。

ぼやきだけ残してもしょうがないので、試作品をアップ。

はてなブックマークに出戻ってAPI生活を送るために、MyWeb2.0 Betaのデータをエクスポートする。

どうやるんだろうと考えて、間違いに気づく。

ブックマークをアイテムに持ったフィードに、コメントを含めるのは違った。
各ブックマークごとにコメントをアイテムとしたフィードを作るのが正解か。
そうすれば、長文でも問題なくdescriptionに入れられるし、添付とか更新チェックとか出来る。

一度に全ての情報が得られるってのもいいけど、不要な物まで含めてってのは邪魔な気もする。
各個の情報は出来るだけ高い純度を保つ方がいい。
利用する側が使い方を選べるような情報提供の仕組みを作る事が大事。
出来る限りシンプルにするのが気持ちよく使える方法かな。

commentsにコメントフィードのURIを埋め込めば良さげ。

# やっぱSBSとは違うサービスになるのかな

SBSまわりでつらつら考えてて、ふと疑問。
amazonのAWSいじってたときとかは強引にdescriptionにつめてたけど、本来どこにいれるんだっけ。

単文ならcategoryとかdc:subjectでいい気がするけど、description並なのはどこだ?
SBSでつけられた各人のメモ(あるなら)を含んだフィードを手に入れたい。
RSS2.0のcommentsはURIだった気がするし。
適当な名前空間さらってコンテナ作ればいいのかな。

軽くgoogle先生に聞いただけじゃ出てこなかった。
日(日の出)を改めてじっくり探そう。

SBSのSocialを意識してみる

SBSの使い方をあれこれ模索中な中で、socialである事の意味を考えてみる。
といっても、無断リンクがどうこうとかは考えない。
あくまで、疑問に思った所とかを整理する意味で考える。

SBMのお宝を眠らせない

フィード経由で、気になる記事を見つけてはSBMに切り抜いてる。
問題は、記事をさっと眺めただけで終わらせてしまうところ。

RSS2PDFは古いらしい

サービス自体が古いとかじゃなくて、話題に上った時期が結構前だったということ。
百式 - 違った楽しみ方 (RSS2PDF.com)で、8/2に紹介されてた。
はてなブックマークでもその頃に30人くらいがブックマークしてる。
なんで知らなかったんだろう、スルーしてたのか。

まあ、知ったのが3ヶ月遅れとかはどうでも良くて、気になるのは日本語対応は恐らくずっと先だろうということ。
先日メールの返信をもらって安心(納得)したばかりではあるけど、やっぱ気になる。
外人に日本語フォント理解しろとかは難しいか(日本語フォントがほぼ有料ってのも関係するのかな)。

XMLデータをPDFにするのはXSLT経由なのかな。
XML->HTML->PDFとかって流れ?
HTMLのPDF化サービスは日本で出て来て欲しいんだけど。
PHPとかのライブラリで出来るかな。

プロフィール

このアーカイブについて

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

前のアーカイブは2005年10月です。

次のアーカイブは2005年12月です。

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