タグ

ブックマーク / la.ma.la (11)

  • 最速インターフェース研究会 :: 「ニコニコ動画はYouTubeにとって脅威になったのでアクセス拒否された」みたいな論調に話を持って行きたがる人たちについて

    割とどうでもいいとは思ってるんだけど書いておくことにする。ここら辺読んで思ったこと。 http://shi3z.cocolog-nifty.com/blog/2007/02/youtubeweb20_0171.html http://blog.livedoor.jp/lalha/archives/50154713.html http://mindclip.blog55.fc2.com/blog-entry-121.html 通常の利用頻度でAPI使ってて他は大丈夫なのに自分だけアクセス拒否された!ってことなら、敵視されてるんじゃないか とかそういう陰謀論が起こるのも理解できるんだけど。 「アクセス拒否=敵視されている」みたいな発想が短絡的だと思う。利用方法に問題があって異常なアクセスがあれば、普通にアクセス拒否すると思うんだけど。敵視してるとかそういうのとは全く関係なしに。 YouTube

  • フィードリーダーの脆弱性まわりのこと

    最近、FreshReaderに脆弱性があったということで、いくつか調べて直したり、赤松さんと連絡取り合ったり、それからはてな使ってないのにユーザー様とか書かれて不愉快な気分になったりしてたんですが。 この記事はひどすぎると思う。 フレッシュリーダーの脆弱性に関連してSage++のこと そもそもの問題として「ローカルディスク上のHTMLファイルをブラウザで開くと超危険」です。XMLHttpRequestやIFRAMEでローカルファイルの内容を読み取れるからです。Sageに脆弱性があるということは、あらゆる個人情報の漏洩につながります。「開発者の個人情報を晒すリスクが云々」というのは、個人的には分からなくもないですが、ユーザーの個人情報を危険に晒していることを認識すべきです。 開発者人が過去に書いているので、危険性の大きさは十分に認識できているはずです。「脆弱性がある」と公表してしまった時点

    setamise
    setamise 2007/01/26
    『そもそもの問題として「ローカルディスク上のHTMLファイルをブラウザで開くと超危険」です。』
  • 最速インターフェース研究会 :: ウェブ型のRSSリーダーのシェアを調べてみた

    このブログの2007年1月15日から2007年1月21日までのログを集計してみた。はじめに断っておくと、あくまで「このブログに対するアクセス」の集計結果であってフィードリーダーのシェア統計としては全く信頼できない。イギリス人に母国語を訊いたりインド人に主を訊いたりするぐらい予想通りの結果だ。 はじめに ウェブ型のRSSリーダーというのは乗り換えるにしろ使うのをやめるにしろ、購読リストをスッカラカンにしてから辞めるという人はあまりいない。あるいは登録しているだけで全然読まれないというケースも良くある。なので、feedburnerのアクセス解析で表示されるような購読者数というのはあまり当てにならなかったりする。(Bloglines一強だったころは当てになった) というわけで、特定のRSSリーダーでのアクティブな購読者数を調べるには、記事文内の画像へのリファラで集計して実際にその記事が読まれ

  • 最速インターフェース研究会 :: livedoor Wirelessのラの字も考えてないWeb屋のネタ帳の誤読記事

    livedoor wireless、MACアドレスによる認証を開始--ニンテンドーDSにも対応 http://japan.cnet.com/news/com/story/0,2000056021,20339983,00.htm に関して、Web屋のネタ帳の人が 「セキュリティのセの字も考えてないライブドアの公衆無線LANサービス」という記事を書いているのですが、 http://neta.ywcafe.net/000698.html 何か色々間違ってると思うので、書いておきます。これはライブドアの中の人じゃなくて、1ユーザーとしての立場で書いてるのと、あとネットワーク管理者でもなんでもないんで、そこら辺信頼できるかどうかは各自ご判断ください。 まず、実際自分で試してみたのですが、これは接続したい機器のMACアドレスを事前に登録しておくとWEB認証をスキップできるというもので、そもそもWEPキ

    setamise
    setamise 2006/12/26
    大変勉強になった。うちの小学校では教えてくれなかったので
  • 最速インターフェース研究会 :: Firefoxの拡張MozLabの中に含まれるMozReplがヤバすぎる件について

    MozLabという拡張を昨日知ったのですが http://dev.hyperstruct.net/trac/mozlab この中に含まれているMozReplというのがヤバい。Firefoxにtelnet接続できるようになる。 とりあえずRubyで書いた簡単なサンプル、今見ているページをリロードするだけ。 require 'net/telnet' telnet = Net::Telnet.new({ "Host" => "localhost", "Port" => 4242 }){|c| print c} telnet.puts("content.location.reload(true)") telnet.close ひたすら自分が見ているURLとページタイトルを記録する系とか簡単に作れそう。 今見ているページのURLとタイトルを取得するサンプル。 require 'net/telnet'

    setamise
    setamise 2006/09/28
    Firefoxにtelnetで接続できるようになるMozlabという拡張
  • 最速インターフェース研究会 :: 全てのWeb開発者必見:fluxiom

    fluxiomである。 http://www.fluxiom.com/ fluxiomはRuby on Railsで作られた、ソーシャルとタギングを備えたオンラインファイラーというようなものらしい。まだサービス開始していないが、デモムービーが公開されている。 fluxiomを開発している会社はscript.aculo.usの開発元ということであるので、 当然「Rails + prototype.js + script.aculo.us」で作られている、ということになるのだろう。 と思ってみたら、開発者のBlogに追記されていた。「Ruby on Railsで作られていて、Flashは一切使っていない」ということである。 http://mir.aculo.us/articles/2005/11/24/fluxiom script.aculo.usは「web2.0 JavaScript」だそう

    setamise
    setamise 2005/11/26
    一応ぶくま
  • 最速インターフェース研究会 :: Fasterfoxが酷すぎる件

    Fasterfox http://fasterfox.mozdev.org/ Fasterとか見るとつい試してみたくなる衝動に駆られて試してみたんだけど、これはひどいなと思った。 リンク先読み機能ってのがデフォルトで有効になっているんだけど 先読み機能は他にダウンロードしている場合はそちらに優先権を譲るので競合して帯域幅をパンクさせることはありません。それどころか使用していない帯域を有効活用する機能です。 どっちも自分のことじゃないか、相手のサーバーのことはどうでもいいのか。まあ俺は基的には帯域幅よりサーバー負荷より人間の1分1秒のほうが貴重だとは思ってるんだけど。 del.icio.us開いたら片っ端から先読みし始めるし、既読のページにもかかわらず先読みするし節操が無い。読みもしないページを片っ端からダウンロードすることが有効活用と言えるのか? もしもローカルネット内でキャッシュプロキ

    setamise
    setamise 2005/10/17
    他マシンのFirefoxも設定変更
  • 最速インターフェース研究会 :: XMLはメタデータというより生データとしての利用価値が高まりつつあり、AjaxによるUIの切り離しがそれを加速する

    全部まとめて色々書こうかと思ったのだけれど、どうにも上手くいかないので、少しずつ分割して書くことにする。 まず最初にこれなのだけれども http://johnvey.com/features/deliciousdirector/ これは何かというと「JavaScriptで書かれたdel.icio.us APIのクライアント」である。最初に全てのブックマークを受信して、その後のタグによる絞込みなんかは全てJavaScriptで行う、というものだ。 とりあえず、実際にこのデモを見るのが早いだろう。 http://johnvey.com/features/deliciousdirector/demo.html この方式では、ブックマークの件数が1万件を超えるようなケースになると破綻することがわかっている。 del.icio.usのAPIでは特定のタグを含むブックマークを取り寄せることも出来るので

    setamise
    setamise 2005/06/29
  • 最速インターフェース研究会 :: 画像のインクリメンタル検索

    あまり大っぴらに公開できるものではなかったのだけど、去年の夏ごろに画像をインクリメンタル検索するスクリプトを書いた。必要なのは検索の対象となるテキスト情報だけで、ブラウザ上で軽快に動作する。なかなか使い物になった。 動的にイメージタグを生成するので、画像は必要に応じてロードされ、重くならない。対象のデータが1万件程度であれば問題なく、検索ヒット数に制限をもうけて、ヒットしすぎた場合は打ち切るようにしていた。サーバーサイドと連携するようなタイプにすれば1万件以上でも問題なく動かせるだろう。 ふと、Picasa2はどんな感じなのかな、と思って試しに使ってみたのだが、インターフェースかくあるべし、というべき素晴らしいものだった。 現状、日語のファイル名に対応していないけれど、インターフェースに興味がある人は必見だと思う。 http://www.picasa.com/ -文字列でのインクリメンタ

    setamise
    setamise 2005/06/27
     ★★★、「検索にタグやフォルダは不要」という意見。要検証。
  • 最速インターフェース研究会 :: JavaScriptにBlogの全文検索をやらせてみる

    というのを作ってみました。 http://la.ma.la/search.html ---- http://kengo.preston-net.com/archives/002021.shtml http://johnvey.com/features/deliciousdirector/ これ見てすげーなーと思って同時にここ数ヶ月のもやもやしていたものを文章に書き起こそうという気になったので明日にでもアップします。 超高速全文検索を作ってみた MovableTypeの検索機能って、 検索結果が表示されるまでの速度が遅いっすよね。 まあ遅いっつっても30秒も待たないけど、早くはない。 原因はMovableTypeの構造とかサーバー構成とかいろいろ。 そこで最速インターフェース研究会で発見した JavaScriptBlogの全文検索をやらせてみるという記事を参考に それをちょっぴり改造してサ

    setamise
    setamise 2005/06/27
     ★★★ 優れたインターフェース。使って楽しく、見てかっこいい。理屈じゃない。
  • 最速インターフェース研究会: Amazon最速検索を作ってみた

    デモここから。 http://la.ma.la/misc/aws/demo.html 説明書はこれ。 http://la.ma.la/misc/aws/ -IE6、Firefox、Opera8で動作確認しています -Safariではスクリプトの動的ロードが出来ない関係で、動きません。 -IFRAME内にパラメタ渡したCGIでscriptタグ生成とかやれば出来ないことも無さそうだが面倒なのでパス。 このエントリで書いた http://la.ma.la/blog/diary_200504140039.htm >検索エンジンがJavaScriptで検索結果を出力するインターフェースを備えていれば、CGIが使えないサーバーでも、クライアント側の制御だけで動的に検索結果を読み込むことができるようになります。 この理論を実際に実践してみた、といったところです。 Ajaxというよりむしろ、ブラウザベース

    setamise
    setamise 2005/06/21
     ★★☆
  • 1