なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
日本語入力を支える技術、本日発売 - 射撃しつつ前転 改
発売ですよ、というだけではアレなので、日本語入力と私、という題目で自分語りでもしてみようかと思っていました…が、時間もないのでそれはまた今度にして、細かなトピック選択について少し触れてみようかと思います。（写真は昨日既に入荷していたジュンク堂池袋店です。右上に見えるプログラミングコンテストチャレンジブックもオススメ！） データ構造については、カッコウハッシュ、ダブル配列、LOUDSを選択しました。カッコウハッシュはやや唐突な感じがしますが、本当はfujimapまで紹介してfalse positiveを許すとサイズが小さくできるねー、とかやりたかったのです。fujimapをボツにしてしまったので、結果としてカッコウハッシュはちょっと浮いてしまったかなと思います。ただ、面白いデータ構造なので知っといて損はないでしょう。ダブル配列、LOUDSあたりは選択としては特に異論もないところかと思います。
最近気になっているJSライブラリ - 射撃しつつ前転 改
時間があったら調べたいんだけど、無いのでリストアップだけ。 EaselJS html5のcanvasだと一旦描画したオブジェクトの移動とかできないので、シーングラフを管理してくれるっぽい感じのライブラリ。 paper.js EaselJSと似たような感じ。どっちがいいのかわからない。 d3.js グラフ描画ライブラリっぽい。なんかいろんな種類のグラフが描ける。グラフがかっこいい。 now.js 複数のクライアントでデータを通信するコードを簡単に書くためのライブラリ。チャットとかがすごい簡単に作れる。
Googleのトップページを開いた時の各ブラウザでのCPU使用率 - 射撃しつつ前転 改
os0xさんが追試をしてくれたので、ちょっとだけ反応。 私も別のマシンで確認してみました（というか、前のエントリ書いた際のPCが今手元にない）が、Core2 Duo 3GHzのマシンでgoogle.co.jpのトップを10個ぐらい開くと、FirefoxのCPU使用率が4〜7%ぐらいでした。検証時の環境はCore2 DuoのノートPCで、負荷が低いときは1GHz動作なので、クロック比で単純に計算して一個あたり4〜7 * 3 / 10で、ここから計算した値でも、1.2〜2%になります。概ね前のエントリで挙げた数値であると言えると思います。環境はUbuntu 9.04で、Firefoxは3.5.2を使っています。CPUの使用率はtopコマンドで見ました。 os0xさんはFireBugでプロファイルを取っておられますが、mozilla/js/jsd/jsd_step.cあたりをちょっと見た限り、F
毎秒100回の落ち穂拾い - 射撃しつつ前転 改
前のエントリで起こったいろいろについて書いてみる。こぼれ話という訳じゃないから、落ち穂拾いというのもおかしいけど。 まずは良かったこととか技術的な補足とか。 情報化タブは次のバージョンで負荷を減らすように手を入れるとの力強いお言葉をpiroさんからいただきました。 フォーカスが外れたときにはこの毎秒100回のタイマーは外しといてもいいと思うんだけどそういう実装はできないか、とid:ofkに聞いてみた（彼はJavaScriptに超詳しい）ら、できるけど、タブで非表示状態になった場合にもフォーカスが外れる訳ではないので、あまり意味がないだろう、という答えが返ってきた。特にGoogleの場合は最初から検索フォームにフォーカスを当てていて、これを放置して別のタブに行くような人がわざわざフォーカスを外す事は考えにくいので、ほぼ意味がないだろうと。 後で考えたんだけど、フォーカス回りの挙動はなにかの規
Googleのトップページを開くと毎秒100回JavaScriptが実行されるよ - 射撃しつつ前転 改
FirefoxがCPUを常に15%ぐらい食うのが気になっていたので調べてみたら、Googleのトップページを開くとものすごい勢いでJavaScriptが実行されることがわかった。具体的には、var k=t.value;k!=h&&X(0);h=k というコードが毎秒100回実行されている。このせいで、自分の使っているPCだと、Googleのトップページを開くだけでCPU使用率が2%ぐらい上がっているようだ。Firefox特有の問題というよりは、ウェブページ側の作り方に依るものみたいだ。たぶん他のブラウザでも問題は変わらないだろう。 Googleのトップページの場合、コードを調べてみた限りでは、原因はどうも検索候補の自動補完用のコードみたいだ。現在の入力文字列が過去の記録と違ったら補完の提示をやり直す、みたいなことをやっているように見える。 HTMLではテキストボックス内のテキストが変更され
そろそろChaIMEについて一言いっておくか - 射撃しつつ前転 改
2月は割とガンガンと開発をしてきたのだが、3月に入ってさすがにエネルギーが切れてきたので、一旦、気分転換にエントリに書いてみることにする。 ChaIMEというのは主に研究目的のかな漢字変換エンジンである。奈良先の小町さん(id:mamoruk)がメインで開発していて、自分もここしばらくはアクティブに開発している。こちらでデモを試すことができる。ChaIMEの特徴はひたすらに統計情報で変換をするところなのだが、今回はそういった話ではなく、もうちょっと一般的なかな漢字変換についての話をダラダラと書いてみようと思う。 デモを見て分かる通り、今までのChaIMEはステートレスで、ひらがな列を入力に対してそれっぽい変換候補を複数出力してさぁ選べ、という形だった。文節境界を変更したり、文節毎に候補を出すことはできない。これは単に実装コストの問題で、研究用途で実験をする際には文節境界を変更してどうたらこ
新はてなブックマークでも使われてるComplement Naive Bayesを解説するよ - 射撃しつつ前転 改
新はてブ正式リリース記念ということで。もうリリースから何週間も経っちゃったけど。 新はてなブックマークではブックマークエントリをカテゴリへと自動で分類しているが、このカテゴリ分類に使われているアルゴリズムはComplement Naive Bayesらしい。今日はこのアルゴリズムについて紹介してみる。 Complement Naive Bayesは2003年のICMLでJ. Rennieらが提案した手法である。ICMLというのは、機械学習に関する（たぶん）最難関の学会で、採択率はここ数年は30%を切っている。2003は119/371で、32.1%の採択率だったようだ。 Complement Naive Bayesの位置づけは 実装が簡単 学習時間が短い 性能もそこそこよい という感じで、2003年段階にあっても、絶対的な性能ではSVMに負けていた。しかし、学習が早いというのは実アプリケーシ
これからのDouble Arrayは動的更新に対応するべき - 射撃しつつ前転 改
Double Arrayのコードなんて1年以上いじってないくせになにを言ってるんだこの口はと言う感じですが、Double Arrayを作るのであれば、動的更新に対応させるべきであると、そう思うわけです。 Double Arrayのメリットは Trieである 速い (Ternary Search Treeとかと比べると)サイズも小さい という感じだった訳ですが、速度はともかく、サイズではTxが使っているようなLOUDSやLOUDS++などの圧縮しちゃう方式に勝てないので、静的な辞書としては、速度が超重要なところ以外ではLOUDSやLOUDS++を使った辞書を使うのがいいのかなと思う訳です。辞書引き以外の部分がボトルネックであることも多いだろうしね。 と言うわけで、簡潔データ構造に比較してDouble Arrayでなにか便利な事ができないかなというと、圧縮をかける方式ではやはり、動的な更新が難
Zinniaの多クラス分類法 - 射撃しつつ前転 改
ZinniaというSVMベースの新しい手書き文字認識エンジンがリリースされたので、早速ソースコードを少し読んでみた。 文字認識というのは、機械学習では多クラス分類という問題に分類される。しかもクラス数が認識したい文字数（数千文字程度だろう）分だけ存在するという、なかなか計算量的に厳しい問題である。二値分類器を使って多値分類器を構成する方法にはone vs rest, one vs one, その他にもいろいろあるらしいが、その中のどれを使っているのかというところに興味があった。Webによると、50〜100文字/秒の認識速度と書いてあったので、コードを読む前の予測としては、one vs oneかなーと思っていた。（速度的にはone vs oneの方がone vs restより速い。） しかし、そんな予想を裏切り、recognizer.cppの148行めあたりからには以下のようなコードが書いて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
