すごい面白かった。会いたかった人にも沢山会えたし。 適当な感じのスライドですが、そこそこ反応があって嬉しかった。 [Shibuya.xss] セキュリティ小ネタ二本 View more PowerPoint from send_
Shibuya.xss で話してきました - nothing but trouble
すごい面白かった。会いたかった人にも沢山会えたし。 適当な感じのスライドですが、そこそこ反応があって嬉しかった。 [Shibuya.xss] セキュリティ小ネタ二本 View more PowerPoint from send_
Sinatra での HAML::Template.options の設定に悩む - nothing but trouble
Sinatra で以下のように書いたとき Haml::Template::options[:escape_html] = true このようなエラーが出ることがある uninitialized constant Haml::Template (NameError) ものによって出たり出なかったりなのでどういうタイミングでどう書いてあったら期待通りに動くかわからなくて、ざっと Sinatra::Base の set 呼んでるところあたり見て、以下で大丈夫な気がしたので書いてみたところ、問題ないようだ。 set :haml, :escape_html => true 結局、なんで上手く動いたのか、なんでダメだったのが全くわかってないし、やっぱり俺は Ruby 全然使えてないなあと改めて思った。 まだ、ソロでフレームワーク使えるレベルじゃないのかな。 文化だったり文脈だったりがもっとわかれば、突
安全な 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 の間でローテートしてくれていい感じになる。
if 文と {} とコーディングスタイル - nothing but trouble
最近、また if 文における {} 省略の話をよく見掛けるようになった。何年たっても繰り返される話なんだろうなと思う。 なので、人のことをとやかくいう前に、自分のコードの変遷を考えてみると、簡単に言うと以下の様になる。 OOP 厨以前 {} 必須派 {} なしはバグの温床 OOP 厨時代 {} 以前に分岐ありえない {} 以前に分岐は悪。クラス分けするのが正義 OOP 厨脱却後 分岐はあり。{} は基本的に使わない 後々ややこしいことありそうだなと思うところは {} つける {} ありの部分は、将来リファクタリング入る可能性もあるので要注意 三項演算子の話も似たようなことでよく出てくる話なんだけど、どっちの話も同じような話で、そもそも意味がわかってないという人と、使いかたが合理的じゃないという人が槍玉に上げられてるような気がする。 で、そういうことが発生しないようなコーディング規約みたいな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
