安全な HTMLDocument の生成方法について - nothing but trouble
何が危ないのか img.onerror や img.onload は src 属性の内容が評価された段階で実行されるので、外部ソースに対して HTMLDocument を構築する際などで、意図していないタイミングでスクリプトが実行されるケースがある。 具体的には、以下のような場合。 var source = '<img src="not_found.jpg" onerror="alert(1)">'; var range = document.createRange(); range.createContextualFragment(source); // onerror が実行される var img = document.createElement('img'); img.setAttribute('onerror', 'alert(1)'); img.src = 'not_found.
apply/call での継承の話 - nothing but trouble
この件について。 http://d.hatena.ne.jp/iskwn/20091215/1260828978 継承というかスコープがわかりやすいというのもメリットだと思うけど、カプセル化しやすいのも大きなメリットかなと思う。 function Foo(){} (function(){ var bar = 'bar'; this.bar = bar.toUpperCase(); function baz () { console.log('baz'); } this.baz = function() { baz(); console.log('BAZ'); } }).call(Foo.prototype); function Bar(){} Bar.prototype = new Foo(); (function() { this.hoge = 'hoge'; this.baz = fu
プロンプトの色をローテートする - nothing but trouble
Introduction of the ZSH に載ってるやりかただと乱数を使ってるために同じ色になったりしてちょっと不満だったので zshrc を以下のようにしてみた。 PROMPT_COLOR=32 precmd() { PROMPT_COLOR="$[32 + ($PROMPT_COLOR - 31) % 5]";} PROMPT=$'%{^[[${PROMPT_COLOR}m%}%U%n@$HOST'"%u%{^[[m%} %(!.#.$) " RPROMPT=$'%{^[[${PROMPT_COLOR}m%}[%~]%{^[[m%}' これで、行が変わる毎にプロンプトの色が 32-37 の間でローテートしてくれていい感じになる。
Adium の負荷状況を見て再起動する Bash Script - nothing but trouble
Adium で Twitter などのサービスを IM で受け続けていると、やがて CPU 食いまくって kill しない限り固まる現象が頻発する。 これがウザいなあとおもったので簡単な Shell Script 書いてみた。 なんちゃって daemon がこんな感じ。ファイル名は supervisediumd にした。 1秒間隔で監視して CPU 使用率 75% 超えた状態が、10回続けば再起動する。 #!/bin/sh # settings COUNT_LIMIT=10 CPU_LIMIT=750 APP="/Applications/Adium.app" PIDFILE=$1 if [ -f $PIDFILE ] ; then echo "supervisediumd is already running" exit 0 fi trap "rm -rf $PIDFILE; echo
いまどきのイベントハンドリングは遅いのかどうか問題 - nothing but trouble
id:HolyGrail 周りで盛り上がってたので、ちょっと調べてみた。 DOMContentLoaded イベント使ったら、計測どころを何処にしていいかわからないので、それ以外の部分で。 昔ながらのやりかた。 <html lang="ja"> <head> <title>Test</title> </head> <body> <script> var start = new Date(); </script> <div> <ol> <li><a class="events" onclick="javascript:(function(){alert(1)})()">click!</a></li> </ol> </div> <script> var end = new Date(); alert(end.getTime() - start.getTime()); </script> </b
Function.applyを使って、クラスをMix-in - nothing but trouble
Firebugのコードを読んでから、apply廚になりはじめている。 var Foo = function() { this.name = "Foo"; this.foo = "foo"; this.hage ="foo"; } var Bar = function() { this.name = "Bar"; this.bar = "bar"; this.hage = "bar"; } var Hoge = function() { this.name ="Hoge"; } new Hoge(); // Object name="Hoge" Foo.apply(Hoge.prototype); new Hoge(); // Object name="Hoge" foo="foo" hage="foo" Bar.apply(Hoge.prototype); new Hoge(); // O
安全なブログパ−ツ用のJavaScriptの埋め込み - nothing but trouble
いつも仕事で、他所様のJSに影響与えないようにとか悩んだりするんだけど、どうするのがベストかなあ。 はまちちゃんがiframeが良いって言ってて、確かにざっくり試してみたら、Prototype汚染しないし、親frameのオブジェクトとか全く見えないけど、frameset許してないdoctypeだったりする所にそういうJS突っ込むのも気が引けるんだよなあ。 どうしよっかなあ…？
自分と他者とが楽に生きるための思考実験 - nothing but trouble
カウンタの数値でもなく、非アンテナ数でもなく、非ブクマ数でもなく、あなたのサイトはあなたにしか作れないからいいのです。 という言葉が、今、頭の中に降って来たんだけど、自分も含め、糞サイトはやっぱり糞サイトだと思います。 まあ、糞であろうと下衆であろうと、サイト持つ自由も言論の自由もあるよね。 いきなり話がずれるけど、批判を人格攻撃と勘違いする人と、人格攻撃を批判だと思ってる輩って、そこのところの勘違いをいつまで経っても修正出来ない人が多い気がするのは気のせいだろうか。この辺はネット暦とかあまり関係ない気がするけど。 そういう人と関わって一番面倒な場って、ネットじゃなくて、職場かなあ。 幸いそういう人間は、今は関わってないから非常に気楽だけど、｢ここ間違ってますよ。｣とか｢ここってこうした方がいいと思うんですけど？｣みたいな話をした途端烈火のごとく怒り出す人とかとは一緒に仕事したくないし、｢
疑心暗鬼の悲しさ - nothing but trouble
今の彼女さんは出来た人だからそういうことはないんですが。 ガチと似非の悲しさはこんな感じかな。 ガチデスマーチ 休暇 単に倒れただけ。起き上がれない疲労 ごめん。仕事が忙しく過ぎて時間作れない。 本当に缶詰。24時間に1食は普通。 似非デスマーチ 休暇 二日酔いとか女とか ごめん(ry 他の女と会ってる。 ここ半年で今思い出してもムカつくこと。 夜10時ごろに呼び出しかかった。半徹夜作業後で彼女と一緒にいたとき。 PGのバグだった。 俺の到着前にそのPGが｢合コン｣という理由で居なくなったこと。 悲しいこと タスクリスト整理したら現状のマンパワーじゃ、倒れる以外半年は休みなさそうなところ 頑張るところ GTDやれば本当に上手く行く? 信じていい? GTDダメでもタスクを速いペースでこなす。 教育も頑張って俺の負担を減らす。 PGバグによる影響を最低限に。 嫌がる奴も居ても、ローカル環境での
nothing but trouble - Zend Framework Programmer's Reference Guide 超流し読み
FAQやコーディング規約は読んでません。 超流し読みなので間違ってるかもしれません。 間違ってたら教えてくれるとうれしいです。 Zend Zend Frameworkの基幹クラス。 DRY原則に基づいてる。 スタティカルなメソッドしかない。 Zend::loadFile() include()のラッパ。失敗時に、Zend_Exceptionを投げる Zend::loadClass() "$className.php"みたいなファイルの$classNameクラスをロード クラスが無ければZend_Exception Zend::loadInterface() Zend::loadClass()のInterface版 Zend::isReadable() is_readable()のラッパ Zend::dump() var_dump()のラッパ Zend::register() 指定した名前の
訃報 - nothing but trouble
ここにも書かないと、mixiにいる人にしか伝わらないような気がするので、はてなでも書いておきます。 平凡にして非凡なる日常 等のサイトをやっていらした緑さんが亡くなりました。 6日の夜に病院に搬送されて、7日昼頃亡くなったそうです。 9日に告別式があり、俺は出席してきたのですが、個人は既に灰になっていたので、そのときは今一つ現実感が薄かったのですが、時間が経つにつれ、彼女がこの世から居なくなってしまったということが実感できるようになって来ました。 そういえば、正月におせち料理作ってみんなで飲み食いしたなとかそういうことを思い出したりしています。 mixiで追悼コミュが出来たり、偲ぶ会のようなものも2月末に行われる予定です。 彼女に縁ある人や、面識はないけど会ってみたかったという方は参加して頂けると故人も喜ぶのではないかなと思います。 mixiに入ってないという方も、連絡下されば招待いたしま
ぼくらのアイドル！デンマンさん！ - nothing but trouble
いや、初めて知ったのは、 アクセスアップのためのブログで使えるCSS（スタイルシート）研究 【その１】 - デンマンのブログ なんだけど、どうもなかなか素晴らしいお方なようで、気になってプロフを見に行きました。 んで、Firefoxでアクセスしたプロフで文字化けしまくったから、ヘッダを見たんですけど、metaタグが特に味わい深かったです。 <meta name="authors" content="Akira Kato & June Adams"> <meta name="copyright" content="(C) 2005: all rights reserved"> <meta name="date" content="7:23 p.m., Wednesday, August 17, 2005"> <meta name="file" content="C:\MyWebs\FreeC
最近のはてなの重さとかに疑問を感じたから調べてみた。 - nothing but trouble
彼女もエンジニアなので手伝ってもらいました。 pingの結果 221.186.146.25 g,f 221.186.146.27 www, ring, i, counter, graph, map, 2.0, d2 221.186.146.28 a 221.186.129.146 d 61.196.246.68 b, r httpsアクセス 前述のリストの一番先頭のドメインの方に飛ぶ。 ついでに言うと、gとfは、証明書のドメインが、[*.g.hatena.ne.jp]だと怒られる。 ちなみに、diaryだとpingは死ぬけど、httpアクセスだとちゃんと転送されたりする。httpsだとダメ。 結論 なんかぐちゃぐちゃしてるし、bとrが同じIPって負荷が高そうな気がするんだけどなあ。 あとwwwにサービス集中しすぎ。 ついでに言うと、raaaaaaaaaaaaaaa.hatena.ne.jp
nothing but trouble - 「はてな便利ツール＠RSSを一気に登録」について
ちょっと、引っかかるところが多かったので、念のため注意喚起しておきます。 先日、はてなブックマークで話題になっていたこのツール。 http://hatena.satoru.net/bookmark/rss/ 一応、はてなブックマークでも何人かの方がセキュリティ的な部分を気にしておられますが*1、宣伝疑惑の方*2が先行して、セキュリティ面での危険性を真剣に考慮している方が少ないような気がします。 このツールの何処が危険かというと、はてなという自分たちの運営しているものではないサービスのIDとパスワードの入力を促すところです。更に、フォームが暗号化されていないので、入力した情報は、第3者による傍受が可能です。 このようなサイトに対しては、まず、フィッシングを疑うべきでないかと思います。*3 私個人としては、件のサイトがそのような目的で作られているとは考えていませんが、基本的に他のサービスの会員
はてなブックマーク論争系で思うこと - nothing but trouble
ブックマークの「あとで」系タグ付ける人に、ノイズが入るから止めれと言う。 「あとで」系タグに文句言う人に、情報を取捨選択できるリテラシーを求める。 求めてることは、ある意味似てるなあと思った。 どちらもユーザに思想やら使い方を押し付けてるって感じで。 - んで、俺的な考え方は、以下のような感じ。 「あとで」系タグを付けるっていう行動は、流し読みしたり、ぱっと見て、後で読もうと思うだけの価値を見出せる記事だったから、とりあえず備忘録的にクリップしたんだと思う。 少なくともクリップする価値があると判断したからクリップしたんだろう。 他の人のことはわかんないけど、俺は少なくともそうだし、そもそも俺のブックマークのタイトルが、「とりあえずメモった、と」なんてタイトルになってるのは、最初からそういう備忘録的な目的だからなんだよなあ。 「みんながチェックしてるから…」って観点でブックマークすることはな
今日の反省 - nothing but trouble
Ajaxバリバリのwebアプリを作るときは、UIちゃんと考えないとダメだな。 どうもレガシーな感じで作ってしまって、動いた後で「ダメだ！使いにくい！」と放り投げて大幅に変更することになる。LLだからと気軽にと思ってたけどこれじゃ進まんね。 何だってしっかり考えないとダメってことか。方針なしでやりすぎた。 あとTTのせいなのか、テンプレのscript要素がまるまる吐かれないと言う現象に遭遇。何かの仕様くさいけど今日はそこまで調べる時間がなかった。 いや何年ぶりかのPerlで、しかもCatalystって自分の知識が古すぎて苦戦するね。 やっぱりJavaで実装する方が今の俺的には早いし楽なんだけど、それじゃあ広がりもないしね。 早くサクサク実装出来るようになりたいなあ。
恐怖！日本の駐車場を支配する月極一族 - nothing but trouble
子供の頃の話だが、うちの姉は月極駐車場を「月極(げっきょく)」という風変わりな姓を持つ人たちの所有しているものだと思っていた。 大人になってからも、月極という文字を見るたびに、このエピソードを思い出してしまい、「本当だったら物凄い金持ちだよなあ。」などと考えながらニヤニヤしてしまい気持ち悪い人になっている。 そして、あそこで母親がツッコミ入れていなかったら、どうなってたんだろうと思って少し怖くなったりしている。 あの時の会話はこんな感じだった 姉「月極さんってどれだけお金持ちなんだろう…。」 俺「月極さんって？」 姉「ほら、あちこちの駐車場で必ず名前書いてあるじゃない。持ち主の人だよ。」 俺「へー。凄いお金持ちだねえ。」 爆笑しながら母親がツッコミ入れるまで、素直な俺は完全に信じ込んでいた。 俺と姉の脳内にしか居ない月極一族だが、三十路になっても忘れる事が出来ない。 駐車場は支配できなかっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
唐突に思い出したけどhatenabarの話。 - nothing but trouble
リンク - nothing but trouble
今日のガックリ - nothing but trouble
