危険なセキュリティホール
http://itpro.nikkeibp.co.jp/article/NEWS/20051231/226841/
メモ代わりにアップ。記事を読むと、Windowsメタファイル(wmf)の解析部分に問題があるみたいですね。久しぶりにwmfという言葉を聞きました。なんとなく懐かしいです。
2005.12.31
セキュリティに関する意識
/.Jの「Linuxでもbot感染が拡大」内のコメントから
今までWindowsで散々言われてきたことが、 Linuxで全く同じことが起きている、ってことだと思いますよ。
それを「Linuxも所詮は糞（ｒｙ」と思うのか、「Linuxも随分と普及してきたもんだなあ」と思うのかは、人それぞれだと思いますが。
「Linuxも所詮は糞」って思う人は、きっと「Windowsなんか使ってんの？」なんて言ってきた人たちでしょう。記事のコメント内にもありますが、本当にセキュリティを考えるならＷＡＮに繋がなければ良いんです。コンピュータルームに強固なカギをかけると最高ですね。
2005.12.30
ちょびっと変更
取得部分のみAjaxなRSSリーダー
http://souseiji.heteml.jp/ajax_rss/admin/
前に紹介した、取得部分のみAjaxなRSSリーダーをちょっといじりました。以前の明らかに使えない表示を変更して、左サイドバーに登録してるRSSのリストを表示して、右側にクリックされたRSSの内容を表示するHTML作成を追加しました。
これで作成した結果は、こんな感じです。
http://souseiji.heteml.jp/ajax_rss/users/souseiji.html
ちょっとやりたいことと近づいてきた気がします。
2005.12.27
PAIPO READERリニューアル！
Web型RSSリーダーであるPAIPO READERがリニューアルオープンしました！ぜひ使ってみてください。今回は裏側の仕組みを大きく変更しただけであり、表側の変更点はありません。
裏側の仕組みを変更したおかげで、ストレスのない閲覧が可能になってます。かなり良い感じです。
お気づきでしょうが、ただの宣伝だったりします。
2005.12.19
AjaxなRSSリーダーHTMLを作成するWebサービス
この前書いた奴を元にして、簡単なWebサービスを作ってみました。
見た目しょぼいし、safariで文字化けするし使えないサービス度満点ですが、せっかく作ったので、ココで紹介しておきます。
「UIはAjaxじゃなくて、取得部分だけAjaxなWeb型RSSリーダー」
http://souseiji.heteml.jp/ajax_rss/admin/
こいつで、作ったHTMLはこんな感じ。
http://souseiji.heteml.jp/ajax_rss/users/test.html
なんか使えそうで、使えなさそう（今のところは使えない）。これから色々考えてみます。
2005.12.18
ブログが「パーソナルブランド構築ツールである」という意見に対する批判
先日行われた「Japan Blogger Conferrence」に参加してきて、そこでしきりに出てた言葉は、「パーソナルブランド」という言葉でした。（遅刻して行ったので、最初の方は聞き逃したのですが…）
これは、ブログが個人のブランド戦略を担うツールとして世間一般に認識されてきたということでしょうか？確かにそういう面はあると思いますが、「世間一般」と考えた場合には、まだまだそこまでは至っていません。
では、今後を考えた場合にどうでしょうか？今後、ブログがパーソナルブランド構築のためのツールとして使われていくのでしょうか？
今後を考えた場合、ブログを書いていく総数が増えるに従い、「パーソナルブランド」といえるほどのブランドを構築できる人の割合は減ってくるように感じます。大抵は、ブランドを構築する以前に終わってしまうか、長々と続けててもパーソナルブランドという視点から見た場合、たいした利点も得られないというブログが大多数になるでしょう。（そして、そういうブログの管理者はこう言うはずです「俺はそんなつもりでブログ書いてないから」と。）
今現時点で、確かに「価値のあるパーソナルブランド」を構築できたという実績のある人も、今後そういう実績を作っていける人も居ると思いますが、ブログというツールでそういう価値を出していける人の割合ってのはかなり少ないと思います。
実は、これに関連する話題で、その昔、FDELPHIで活躍されていた、はぶあきひろさんがタイムリーな日記を書いてたので、リンクして紹介します。
http://d.hatena.ne.jp/habuakihiro/20051217#1134794980
そもそも、一番最初に会社を立ち上げたときから、NiftyのFDELPHIな人と一緒でした。
この日記は、はてなの社長である近藤さんの次の日記を受けての日記となってます。
http://d.hatena.ne.jp/jkondo/20051215/1134601112
最近はてなでの人材採用の中でちょっとした傾向が出てきているような気がします。それは、「興味深いブログを書いている人」の採用率がとても高いという点です。
この二つを読んで感じたのは、はてなの近藤さんが書いてる内容も、FDELPHIの時代の世界から、あまり変わってないんだなあってことです。FDELPHIには凄い人達が沢山いましたが、はぶさんのように「仕事でも繋がりが出来た」という人は極少数です。
これと同じで、ブログに関与しているいくつかの会社が「ブログ書いてるから雇いました」みたいな事が例えあったとしても、そこに至るまでの確率があまりにも小さすぎて世間一般の人達には、ほとんど関係のない話です。正直、FDELPHIで書いた方がよっぽど確率は高かったんじゃないかとも思います。（というか、「記事時間の管理者」という要素を考えた場合、Niftyのフォーラムの方がブログより信頼性が高いです。）
更に、近藤社長はこのように書いています。
採用の際に自分のブログの提出が必要な企業がこれから増えてくるかもしれません。
これは、いくらなんでも言い過ぎです(^^;。こんな企業がどんどん増えてきたら、ブログで書ける内容は無難なものばかりで、ブログ自体がとてもつまらないモノとなってしまうでしょう。（それか、全く関わらないという選択をする人も出てくると思います。）
更に、既にNiftyのフォーラムという場でも似たようなことが起こっていたのに、未だに全く普及してません。ということは、「根本的に何か欠落があるのではないか」と私は考えます。
まとめに入ると、ブログを「パーソナルブランド構築のためのツール」（近藤社長の言う「履歴書」って説も含む）と考えると、そこにはブランド価値というのを考えた戦略を考える必要性が出てきて、とてもめんどくさい臭いが漂ってきてしまいます。
というか、「個人の人間性や考え方」とかは変わっていくものなのに基本的に変化がご法度な「ブランド」って概念を入れるってどうなんだって思います。それとも、「考え方や人間性」が構築し終わった人しか書いたら駄目ってことになるんでしょうか。そんなの嫌だなぁ…。
2005.12.17
AjaxとRSS
これが「Web2.0」に該当するとは、とても思えませんが、Ajax使ってRSSを読み込む奴を作ってみました。まあ、取ってくるのはRSSのタイトル部だけですが。
http://souseiji.heteml.jp/rss/
使ったライブラリ郡は以下のとおり。
- Ajax部分：prototype.js
- RSSパース部分：Magpie RSS
お世話になったサイト
ほとんど自分の手動かしてません。コピペしてるだけで、さっくりできちゃいました。便利な世の中になったもんです。
2005.12.13
分類法の違い－ディレクトリ型とキーワード型
今回は、データ（主にブログの記事）の分類法の違いに関して話をしたいと思います。
ディレクトリ型とは、ある一つの記事に対して一つの属性を与えるタイプの分類法です。キーワード型とは、このディレクトリ型とは違って、一つの記事に対して複数の属性を与えることができる分類法のことを指します。
この二つの分類法は、どちらが良いとかどちらが悪いということはありません。適材適所に用いられるモノです。現在、Web2.0というキーワード（概念）の流れの中で「ディレクトリ型はもう古い」という印象を受けてしまいますが、古いのはディレクトリ型ではなくディレクトリ型を行っている手法が古いということに気付かなくてはなりません。
これを考える前に、まず「何故分類するのか？」という命題に対する、私の立ち位置を明らかにしておきます。
人が何故情報を分類するのかというと、後から情報を見つける手助けを先にしておくために分類を行います。つまり、分類することの一番重要な目的を「検索のため」と位置付けるということになります。
こういった目的に限定した場合、ディレクトリ型とキーワード型というものの優劣はそれほどつきません。何故なら、この二つの違いというのは、「後からどう探すか」という行動に影響を与えるため、その利便性は適材適所があるからです。
一般的に、ディレクトリ型は検索速度に優れる分柔軟性が欠けており、キーワード型は柔軟性が高いけれども検索速度に若干の難があるという傾向があります。
例えば、Windowsのファイルシステムを考えてみてください。Windowsのファイルシステムは完全にディレクトリ型です。Windowsだけでなく、ほぼ全てのOSが持っているファイルシステムはディレクトリ型ばかりです。キーワード型は、OSが標準装備しているファイルシステムを補完する電子ファイリングソフトを導入したりしないとできません。この場合、OSが利用するようなファイルシステムは「速度重視」ということになります（当たり前です）。
さて、上記のような基本的な概念を説明した上で、話を元の「ディレクトリ型を行っている手法が古い」というところに戻し、古いのはディレクトリ型という分類法ではなく、別の分類に対する概念が古い（というかネットとの親和性が低い）ということを明らかにしていきます。
現在ネット上で流行ってる「タグ付け」という言葉と「フォークソノミー」という言葉を考えてみましょう。「タグ付け」単体で考えると、タグで分類するというのは、一つの情報に同じ項目上で複数の属性を与えるわけですから、前述のキーワード型の考え方になります。そして、色んなところのフォークソノミーに関する説明を読んでると「タグ付け＝フォークソノミー」という勘違いをしてしまいそうになりますが（実際、私もそう思ってました）、実は違います。
大雑把に理解した範囲で説明をすると、「フォークソノミー」とは「タクソノミー」の反意語にあたり、タクソノミーが個人（もしくは一つの団体）が行う分類であるのに対し、フォークソノミーは複数人で行う分類という意味になります。
では、何故「タグ付け（キーワード型）＝フォークソノミー」、「ディレクトリ型＝タクソノミー」という認識が産まれたのかというと、フォークソノミーという概念が複数人が緩やかに繋がって情報を分類していくという概念になるため、柔軟性の高さからディレクトリ型よりもキーワード型の方が親和性が高いからということになります。タクソノミーがディレクトリ型というのは、明らかに間違った認識であり、多分「フォークソノミー＝タグ付け」というところから逆に「ディレクトリ型＝タクソノミー」という勘違いをしちゃったんじゃないかと推測しておきます。
つまり、何が言いたいかというと「ディレクトリ型によるフォークソノミーも十分にありうる」ということです。フォークソノミーとタクソノミーとの違いは、分類を管理をする主体が複数であるか単体であるかに過ぎないため、ディレクトリ型を複数人が管理しても良いわけです。
ただ、その場合、ディレクトリ型による分類は柔軟性に欠けるため母数が非常に大きな数字になってこないと、「全く分類されない」危険性が高くなります。そういう意味でキーワード型による分類でフォークソノミーが使われているのでしょう。
さて、長々とここまで書き上げてから、ネットをちらっと検索したらタクソノミーとフォークソノミーって色んな言説があることに気付きました（遅すぎ）。私は英語得意じゃないので、こういう外来語は日本語にしないと分かりません。というわけで、私が無理やり日本語に翻訳してみます。
- タクソノミー＝個人分類法
- フォークソノミー＝集団分類法
…全然、上手くまとまりません。誰か助けて！
PEARのライブラリ
PHPを使ってる人には馴染み深い存在であるPEARライブラリ。今回は、その中のHTTP_Requestクラスの不具合と、その修正方法について記述します。
このHTTP_Requestクラスには、通常環境であればほぼ問題にならないようなある不具合が存在しています。その不具合とは、HTTPリクエストにたいする応答ヘッダーに記述されている「Content-Length」に対応していないという不具合です。
では、何でContent(内容)の受信を終了する判定になっているかというとSocketクラスのバッファ状態がEOFになるまで繰り返すという処理になってます。具体的なコードを書くことはできませんが、このあたりはソースを追っかけたら即分かると思います。
さて、この問題は一般的に使われているHTTPサーバーであれば、ほぼ問題は発生しないのですが、HTTPサーバーの仕様によっては、受信処理がネットワークタイムアウトまで終了しないという問題が発生してしまいます。
この問題を解決するには、Content-Length分だけ受信するようにすれば良いだけなので、修正自体はとても簡単です。
というか、なんでこんなところサボってるのか謎です。
以前、PEARのDBクラスでMySQLのSelectDBがクエリーを送信するたびに実行されてる件について調査したときも、クエリー実行時に必ずSelectDBするコードが紛れ込んでて辟易したのですが、今回も同じぐらい辟易しました。
というわけで、PEARライブラリ自体はとても有用なライブラリ群であるけれども、更に活用していくためには、せっかくのソース付きライブラリ（というか、ソース自体がライブラリ）なので気に入らない部分は自分で修正しちゃいましょうという話でした。
Recent Comments