ただ、WebRTCで顔認識させようとすると遅くてしかたがなかった。 最初は速いこともあるが、10回ぐらい認識をさせるとすぐに遅くなる。 とりあえず、デモ。 そこで、チューニングをしてみることにした。 まず、JavaScriptの定番の高速化を試してみた。 例えば、正の数で使える「Math.floor(x)」を「(x | 0)」に、整数で使える「x * Math.pow(2, y)」を「x << y」にする等。 これで、10~30%高速化できた。 次に、遅くなっている部分を調べたら、Web Workersで分散するための仕組みが遅くなる原因だとわかった。 これは、Web Workersを使わない場合にも影響が出ていた。 じゃあ、Web Workersを使えば速くなるのかといえばその逆で、20倍遅くなっていた。 詳しくは調べてないけど、多分Workerスレッドに処理データを渡す時にJSON化が
本来であれば、0.2に入っている「upload.cgi」を使えば良いのですが、Rubyの実装に変更があったためそのままでは動作しません。 「Digest::MD5.new(imagedata).to_s」の部分を「Digest::MD5.new.update(imagedata).to_s」に変更します。 (MacOSX 10.5の場合。これ以前のOSXでは修正が不要かもしれません。) また、「upload.cgi」は、同一ディレクトリにファイルを保存するため、実行環境配下に画像ファイルが入ってしまいます。 これでは、画像ファイルが実行ファイルと認識されてしまうため、ブラウザから参照する事ができません。 (仕様的にcgiファイルでも受け取り実行環境に配置されてしまうため、セキュリティ的にも危険です。) このため、画像を受け取る専用のアカウントを作成し、実行環境下でない「サイト」フォルダ(内
Javaによる実装のため、Mac OS X,Windows,Linux問わず動作するはずですが、開発環境がMacのため他の環境は試せていません。 GyazoはMacのscreencaptureコマンドを使っているため、キャプチャの範囲を選択した後にキャプチャされますが、Jyazoは全画面をキャプチャした後に範囲を選択し、選択範囲を切り抜いています。これは、リアルタイムで処理するのは遅すぎるためです。 マルチディスプレイ環境には未対応です。プライマリディスプレイのみキャプチャするようになっています。 Gyazoが内部的に持っているIDをJyazo独自のものにしています。 上記の通り、IDはJyazo独自のものを設定しています。 Gyazoのページには、アップロードファイルの一覧を表示する方法が書かれていますが、多分この機能にIDが使われていると思います。 しかし、これまでこの機能に気付いてお
elm.setAttribute( "name", "value" ).getAttribute( "name" ); Object.prototype.__noSuchMethod__=function(methodName,argsArray){ if(methodName.match(/^_[^_]/)){ var method=methodName.substr(1); if(this[method]){ this[method].apply(this,argsArray); return this; } } throw new TypeError(methodName+" is not a function"); }; elm._setAttribute( "name", "value" ).getAttribute( "name" );
前エントリで、『JavaScript:The Good Parts 「良いパーツ」によるベストプラクティス』が万人向けでないことを書きました。 自分の実力を顧みず、この本のベストでない部分をつっこんでいこうと思います。ゴリアテどころかゴリアテの集団に挑んでいくような状態ですね。 さて、全エントリで書いた通り、この本は悪い本ではなく良本であり、読む人が読むと良い刺激になるに違いないと思っています。これを契機によりよいJavaScriptの書き方について論議が進むのではないかと期待しています。しかし、対象と思われる層が中級者以上で、初級者が読むと逆に悪本になりかねない部分を持っています。勘違いしそうな部分、気になった部分を中心に記述していきます。このため、否定的な内容は沢山出てきますが、上記のような前提ですので、書籍全体がこのような内容が散見されるわけではありません。そして、これを読んで本の内
『JavaScript:The Good Parts 「良いパーツ」によるベストプラクティス』を読んだ。 人によっては良本なのかもしれないけど、良本とは断定できない内容。いや、悪い本じゃないんだけど、筆者の自己主張が強すぎる感じがする。「ペストプラクティス」と断定できないと思う。『「ベストプラクティス」の候補を列挙』しているといったところかなぁ。玉石混淆で、言い過ぎな部分ややり過ぎな部分がある。こんな感じなので、初心者にはお勧めしない。初心者が下手に読んでしまうと変なクセがつきそうな内容だった。サンプルコードを見てそれに突っ込みを入れられるぐらいのスキルがないとダメだと思う。ただ、突っ込めるのであれば楽しめるんかないかと思う。JavaScriptのこれまで見たことのないような記述方法は非常に良い刺激になった。javaScriptの凄い人の意見を是非聞いてみたい。
git svn clone [svnリポジトリURL] svnのリポジトリをcloneする git svn clone [svnリポジトリURL] -s 標準的な構成のsvnのリポジトリをcloneする git svn clone [svnリポジトリURL] -T trunk -b branches -t tags branchesやtagsを指定してsvnのリポジトリをcloneする git branch branch一覧 git branch -r リモートのbranch一覧 git checkout [branch名] branchを切り替える git checkout -b [gitのbranch名] [リモートのbranch名] リモートのブランチをgitに読み込む git svn rebase svnのリポジトリとローカルリポジトリを同期する
GreasemonkeyのAPIであるGM_setValueで保存できるデータの種類に制限があるのをご存知ですか? それを調べるために、次のようなUserScriptを実行してみます。 但し、unsafeWindowを使っているので信用のおけるsiteで実行してください。 // ==UserScript== // @name GM_xxxValueTest // @namespace http://www.kanasansoft.com/ // @include * // ==/UserScript== ( function(){ var data=[ ["Boolean",true], ["Number",12345], ["Number",12345.67890], ["String","12345"], ["Array",[1,2,3,4,5,"a","b","c"]], ["Dat
「参加してきました。」と書ける人は多くても「開催してきました。」とか「主催してきました。」ってなかなか書けないですしね。これが最後のチャンス、折角なのでこう書いてみました。 主催としての最後のKanasan.JSだったにも関わらず、起きたら9時をまわっていて大遅刻。37toさんに連絡し準備と進行をお願いし、急いで(ある意味開き直って)会場に向かいました。会場に着いた時には37toさんがうまく進行していたので、そのままおまかせして気になった点を説明するような方向で行きました。「kanasanが司会しているのをじっくりと観察して次回に備えて下さい。」というのが当初の予定だったのですが...。すいません。結果論ですが、おまかせして突っ込むスタイルだと、リハーサル的な形になったためうまく引き継ぎできたと思います。勉強会の色と規模にもよるでしょうが、勉強会の引き継ぎにはこの形が良いかもしれませんね。
ネット環境が貧弱な会場での配信は、通信が細切れになっていたため、flvが86個に分割されてしまっている。 Ustreamは配信者はflvをDownloadできるが、他の人はdownloadできない。 Downloadできたとしても、audioがNellymoserというとてもマイナーなcodecなため再生環境構築が面倒。 Downloadしたflvを会ごとに無劣化で結合したい。 できれば、沈黙部分を削除したい。 audioをNellymoserから他のcodecへの変換の仕方がよくわからない。 変換後のflvもしくはmpeg4等をUpしておくだけの十分なServerのストレージ容量が確保できない。 沈黙部分を削除できれば、もしかすると容量はそんなに必要ないかもしれないが、会ごとに4~5時間は当たり前なので手動では到底無理。 Podcast化できればいいが、PodcastのRSS(atom?
iPhone/iPod touchではBookmarkletが使えたはずと思い、登録してみようと思った。 だけど、右クリックができないので登録できない。 Safariとの同期ならできるけど、iPhone/iPod touch側で完結したい場合はどうするんだろうと。 そうしたら、nanki氏にこんな方法を教えてもらった。 なるほど。 賢い方法。 でも、これだとBookmarkletを作成した人が準備しておかないと、結局登録できない。 準備されていなくてもBookmarkletをBookmarkするためのBookmarkletを作成した。 「iPhone/iPod touchでBookmarkletのBookmarkを補助するBookmarklet」のアルファベットの頭をとって数字で省略、iB3という名前にした。 命名は37to氏。 かっこいい名前をありがとう。 もう少しで「iPhoneBoo
関西にもJavaScriptの勉強会が欲しいとはじめたKanasan.JS、初回はprototype.jsのCodeReadingでした。 初回の余りのレベルの高さからサイ本の読書会を併設して、以後交互に実施してきました。 prototype.js CodeReadingは今回で6回目、とうとうprototype.jsを全て読み終わりました。 サイ本がまだ途中なのであまりやり終えた感はありませんが、とりあえず少しは安堵しています。 サイ本読書会もあと数回で終わりそうなため、しばらくは読書会が続く予定です。 ただ、その後のKanasan.JSの方向性もまだ決まっていません。 prototype.jsの次はjQueryという意見もありますが、Roppongi.JSとかぶってしまします。 開催スタイルが違うのでべつにかぶっても良いと言えば良いのですが...。 一番現実的な案です。 オライリーのJ
(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)
widgetをドラッグして位置を変更する事ができます。 タイトルバーをダブルクリックする事でwidgetをたたむ事ができます。 タイトルバー右のボタンをクリックしてwidgetを閉じる事ができます。 タイトルバー左のボタンをクリックしてwidgetの設定を変更する事ができます。 widgetの設定には、現段階でwidgetの固定方法があります。 widgetの固定方法は、ブラウザの表示領域のどの角を基準にしてwidget位置を固定するかを選択できます。 widgetをたたむ時、表示されたままになるタイトルバーの位置はwidgetの固定方法に依存します。 ブラウザのウィンドウやタブ間でwidgetの位置を同期します。 setting widgetでDockの表示位置を変更できます。 Dockに表示されているアイコンをクリックすることで、widgetの表示/非表示を切り替える事ができます。 G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く