「YouTubeの人気動画をダラ見」っていうはてなの新サービス！いいかもお。。。

ここのブログ

YouTubeの人気動画をダラ見しよう！
http://zook.seesaa.net/article/33821415.html

でしったんだけど、はてなが、
ＲＩＭＯ
http://rimo.tv/
っていうサービスをはじめたんだって！！

以下斜体は上記ブログより引用

YouTubeの人気コンテンツを、
次々に自動で再生してくれるサービス
つまり、テレビのようにつけっ放しにしておいて、
興味がなかったらチャンネルを変えたり、電源を切る。
いたって操作はシンプルだ


で、見てみたんだけど、
はじめに、桜チラリだっけ、のＰＶで、そのあとからも、
おお、いいかんじ（＾＾）
あんまり好きではない音楽の場合は、先送りしちゃえば良いし。。

もちろん、世の中には音楽が好きでない人もいるだろうから、
その人はちゃんねるを変えればいいっていうわけ。。
といっても、いろんなチャンネルがあるわけではなく


１：音楽
２：お笑い
３：アート＆アニメ
４：ペット＆アニマル


だけなんだけど（＾＾；）。。。

おおおおお、このサービス、いいよお（＾＾）ｖ

Ｗｅｂ２．０のなかで、一番ウィリアムのいたずらのツボに
はまったサービスかも（＾＾）


これほどまでユーザーにとって受動的なサービスは、
今までのHatenaの（Web2.0っぽい）サービスとは離れてる気がするけど、


世間はそれを求めてるんだと思う。
だから、テレビをみるし、Ｙａｈｏｏでマッシュアップされている
ニュースをみる。

こりゃー、はてな、お金がなくなったら、
（いや、あっても）
このビデオの間にＣＭ流したりして。。

音楽チャンネルでエイベックスのＰＶがながれても、
ぜんぜん違和感なく見てしまうと思う。
（あ、レコード会社のＰＶだったら、逆に入って欲しい気がする。。）

大きなトラブルになるプロジェクトは、初期段階で兆候が顕れています

今日、たまたま検索していたら、興味深いサイトがひっかかったので、
ご紹介。。

　金融ビジネスアンドテクノロジーの金融ＩＴニュースコメント

で、その中でも
開発プロジェクト・リスク（遅延、中止が相次ぐ）
http://www.fin-bt.co.jp/comment371.htm
に（以下斜体は上記サイトより引用）


大きなトラブルになるプロジェクトは、初期段階で兆候が顕れています。


とかいてあって、そのあとに、その兆候が書いてある

第一に、アプリ・ドメインの選定を間違える。
第二に、意思決定メカニズムが不明確。
第三に、トップの参画が不十分。
第四に、検証不十分なプラットフォームの採用。
第五で最大は、下から信用されないＰＭです。


たしかに。。。


これが全て揃っているプロジェクトは、間違いなく破綻します。

っていわれちゃうと、ほとんどのプロジェクトが破綻したりして（＾＾；）


プロジェクトの失敗は、多くの場合、ベンダーに責任があると思われガちですが、真の原因はユーザー側にあることが大半です。ベンダーは、ユーザーの言いなりではいけません。正しいことを堂々と主張し、それを受け入れるユーザーとだけ付合うべきです。そうしないと、共倒れになります。


そのとーっり！！いいこというじゃん

---

あ、で、その記事の一番上の新聞の切り抜き？？写真。。

笑える（＾＾；）


業績修正のTIS、
「失敗案件ではない。結合テストに想定外の手間」


いや、結合テストに手間取ってるって言うことは、失敗なんじゃあ（＾＾；）
仕様書の設計の矛盾や想定漏れは、結合テストで現れるので、
そこで、「想定外の」ことがあるっていうことは。。。
失敗なのですよ（＾＾；）。。。と、おもうけど？

ある時点からの更新履歴をとる場合のRSSとPINGの話

　忘れそうなのでメモ
（すみません。メモなのでまとまった話ではないです..）　

　ふつうのRSSサーバーだと、RSSには、最近の更新情報（30個分とか）しか載せない。
　なので、RSSをつかって、ある任意の時点から、更新された履歴の全部を仮にとりたいとすると（ふつうは、そんな使い方はしないけど、さっきみたいに、RSSフォーマットを使ってデータを集信する場合にはありえる）、

・一定時間ごとにRSSを取得して、
・その結果をDBとマッチング、
・更新された部分をDB修正する

っていう機能を持ったRSSアグリゲーターが必要になる。
（クライアントはRSSアグリゲーターにアクセスする）

---

　でも、この方法だと、それが、現時点で本当に最新かどうか分からないっていうことになる（RSS取得後にまた更新されてるかもしれない）。

　これを避けるには、更新されたたびにRSSアグリゲーターにpingをあげたほうが早い。

　でも、もし、更新されるときにRSSアグリゲーターにPINGを通知するなら、そもそも、RSSアグリゲーターはRSSを読みに行く必要はない。（でRSSを読まないでPINGだけで処理するなら、このばあい、”RSS”アグリゲーターとはいえない）

結論：
・データの更新履歴サービスなら、RSSを受け取るより、PINGをあるサーバーが受け取って、クライアントは、欲しい条件をCGIでそのサーバーに対して聞いたほうがいいかも。。。

ごめん、まとまったはなしではない。。

雑誌なんかの編集・更新を元にＲＳＳフォーマットの利用を考える

　ちょっと思いついたことでメモ。

　ＲＳＳフォーマットでデータ交換する（実際に書きたい内容は、descriptionにかく）と、タイトルを適切なものにすれば、ＲＳＳリーダーなんかで、汎用的に確認できるねっていうお話を、さっき、電車の中で思いついたので書きます。
　例として、雑誌なんかの自動編集をあげます。

　雑誌なんかの自動編集の場合、おおきなページ内のレイアウトはきまっていて、（たいたいＦＲＯＭ　Ａの紙面って、そーぞーつくでしょ　＾＾；）、その中の枠がいくつかあるかたちになっていて（２つ連続してとったりとか、変形して取ったりする枠もある）、枠の中を編集するということになっています。

　この（レイアウトの中にある、）枠１つ１つを小組（こぐみ）といい、この小組に、データをながすことによって、自動編集は出来ます。
　リアルタイムで時時刻刻と編集内容を変えたい場合（テレビ欄とかもそう。ニュースはもっと大掛かりな話（枠が浮動する）んだけど、にたようなもん）、一度流したものをそこだけ編集するっていうことになります。

---

　さてこのとき、小組の種類によって、流し込むデータはちがうんだけど、ここで、ＲＳＳを使って、

１チャネル１雑誌の１号分

１小組１アイテム

タイトルで何ページのどこの小組かわかるようにして

リンクは、あらかじめ、この自動編集で流し込むイメージデータなどを、どこかの
　　　　　フォルダにまとめておいて、そこのＵＲＬ

descriptionに
　　　　　ＣＤＡＴＡとして、自動編集として流し込むタグデータ
　　　　（あるいはＸＭＬ，ＣＳＶなど）

pubDateに更新時間

をいれておけば、タイトルとpubDataでどこの枠を、どう更新されているかが
わかるし（ＲＳＳリーダーでそういう機能あるかな？なければ、作っても簡単）
データ流し込みには、descriptionとリンクをつかえばいい。
　小組によっては、流し込みプログラムが番うかもしれないので、ＲＳＳを読み込んで
からタイトルを見てディスパッチするのかな？

　とにかく、小組以外は、共通に扱えるので、タイトル名を工夫することによって、
いろんな風に並び替え、絞込みが（違う小組のスタイル間でも）できる。
　そして小組のスタイルごとにプラグインを用意する形で、対応ができる。

　そのうえ、そのＲＳＳに対応するＸＳＬを用意しておけば、ブラウザでも見れるし。。。

---

　ということで、ＲＳＳとは関係ないデータでも、ＲＳＳでラップする（エンベロープとして利用する）ことによって、汎用的なＲＳＳリーダーでいろいろ見えたり、いろんな情報整理が出来て、さらに、新しい小組スタイルの追加も、プラグインで対応できて、おもしろそうだ。