[css] @importを使うべきでない理由
実は以前に別の場所でも書いたのですが、今回Google Page Speedの方でも少しだけ触れられていたので、改めてまとめ。 自分でも経験があることなのですが、開発をやっているとどうしても、構造をモジュール化して複数のファイルに分割して管理したくなります。 StyleSheetにおいても同様で、プレゼンテーション層のコンポーネントにあわせてCSSを用意し、ページ構成にあわせて取り込むようなことをやりたくなるでしょう。 しかしその際、@import構文を使うのはパフォーマンスと挙動の両方に有害である可能性が高いと、「」の著者としても知られるSteve Souders氏が警鐘を鳴らしています。 使うべきでないポイント @importは、大きく分けて2つの観点で「使うべきでない」とされています。 ひとつは、パフォーマンスの問題。StyleSheetはほぼ全ての主要ブラウザでパラレルロードがサポ
はじめてのにき(2009-01-19)
_ デバッグ話 面白いな。 http://twitter.com/hyoshiok/status/1128189973 printf デバッグマンセーなのでしたすいません。 探偵の話でいうとデバッガ使うなんて なんかチートくさくて、 むむっ…ここがあやしい! という個所に数点 printf を仕込むだけで バグつぶせるというのがかっこいいのではないかとか。 いや、なんだろうな、やまぁ、デバッガもいいんだけど、 結局どういうパスを通ったか、 がサクっと見れる手軽な方法は結局 printf なんだよなーという。 というかたいていのバグは適当に printf 入れたら取れて、 逆にデバッガを使わせてくれるほどのバグを愛している気がする。 まぁ前の gdb 話とかもそうだけど、 hyoshiok さんの触ってるレイヤーが デバッガマンセー/printfとかデバッグするためにプログラムを変えるのはダ
Rubygrind - 兼雑記
あんま深く考えず valgrind を Ruby の head のテストに適用してみたところ、結構もにょもにょ漏れてるもんだなぁと気付いたので、いくつか修正してみたりしたのですが、その時案外困るのが、リークする最小のコードが簡単に作れない、ってことでした。 valgrind は C 言語的にどこで malloc を呼んだかは教えてくれるものの、 Ruby コードでどこだったかは教えてくれないからです。修正はできたけど具体的にどこで漏れてるかはよくわからん、ということさえありました。 というわけで、 Ruby 的にどこで漏れたかを教えてくれる valgrind 用の tool 、 Rubygrind を作ってみました。 http://shinh.skr.jp/binary/rmemcheck.tgz これを valgrind-3.3.1 のディレクトリに展開して、 > diff -u con
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
