Category Archives: css
[css]wordpressテーマのcssに毎回追加する独自cssは別ファイルに分離しておくとよい。
非常に非常にいまさらなことですが、知らなかったというか毎回追加してましたよ。
wordpressでテーマのstyle.cssにないタグを使用している場合、テーマ変更のたびに毎回テーマのstyle.cssに手で追加していたのですが、別のファイルに分離しておいて、それをstyle.cssの冒頭でimportしてやるだけでよかったのですね。知らなかったです。誰も教えてくれなかったですorz
今回サイドバー右側下のGoogleが買収したといわれるfriendfeedのカスタマイズを別のcssファイルに用意して、それをstyle.cssの先頭でimportするというやり方をやってみました。すこぶる簡単。
importの記述は、
@import url('hogehoge.css');
とても簡単ですね。
ちなみにcssのオーバーライドってのも知りました。
cssは親→子、外側のタグ→内側のタグという具合にcssは継承されていくのですが、親の継承を蹴飛ばして、子は独自のcssを！って具合に使うのがオーバーライドです。上書きという感じでしょうか。
firebugで見るとこんな風になっている部分です。
奥深くまで知ろうとすると一筋縄ではいかないスタイルシートですが、ちょこちょこカスタマイズができるくらいのことを知っておくと、何かと便利ではないかと思います。
その昔に購入した一冊。
 |
Web標準の教科書―XHTMLとCSSでつくる“正しい”Webサイト 益子 貴寛 秀和システム 2005-07 |
[.NET]Frameworkの管理外「アンマネージドリソース」の解放と関係。
昨日の[.NET]独自実装クラスにはIDisposableインターフェースを実装すべき?について、調べたのでリンクをば。
» いまさら聞けない、IDisposableインターフェイス
» [.NET]IDisposable インターフェイスをしっかり理解しておきたい。
» IDisposableインターフェースの使い方について
一番上の記事がわかりやすいかったです。
ガベコレによってオートマチックに解放されるのがマネージリソースで、
開発者が責任を持ってマニュアル管理しなければならないのがアンマネージリソース。
マイクロソフトから提供されているクラスについては、ガベコレがマネージリソースを回収するときに、
アンマネージリソースの解放も一緒に行われるが、それは、そのようにそのクラスが実装されているからにすぎない。
自分でアンマネージリソースを扱った実装をするクラスについては、
ガベコレはあくまでマネージリソースしか回収しないので、自らの手でアンマネージリソースを
解放してあげるように実装しなければ、いつまでたってもアンマネージリソースは解放されない。
また、ガベコレが回収を開始するのは、マネージリソースが足りなくなったときに限られる。
アンマネージリソースが足りなくなっても、ガベコレは何もしてくれない。
当然のことだが、アンマネージリソースの解放を怠るとメモリリークが発生する。
いつまでたっても解放されない。.NET Frameworkなのにメモリリークが・・・という原因のひとつはここにあるようですね。
IDisposable インターフェイスが実装されているということは、
クラスがファイル、ストリーム、およびハンドルなどのアンマネージリソースを利用していることを、
クラスの利用者（開発者）に知らせることを目的として実装されていると考えると理解しやすい。
つまり、Dispose()がコールできるクラスはアンマネージドリソースを利用しているから、明示的にメモリ解放してね、プログラマさん。ということですね。実装されているのにはちゃんとした理由がある。なるほど。
間違ってもマネージリソースしか含まないクラスに対して無闇にIDisposableインターフェイスを実装したり、
必要なタイミングでDispose()が正しく呼び出されていなかったりすることがないようにしませう。
これこれ。ちゃんとIDisposableインターフェースが実装されているのには理由があって、それに該当しないクラスは実装してはいけないわけですね。やみくもはダメですよと。
3番目の記事より。
こうすることによって、あなたが開発したクラスの利用者が、万が一 Dispose を呼び出し忘れても、最悪 GC の動作タイミングで、Finalize が呼び出され、アンマネージドリソースが解放されます。つまり、GC の仕組みをアンマネージドリソース解放の為のセーフティネットとして利用しましょう、というカラクリなのです。
クラスの利用者が Dispose を呼び出した場合には、Finalize が GC から呼ばれなくても、もはや何も問題は起きないので、GC 呼び出しオーバーヘッドを減らす為に「Finalize を呼ばなくていいよ」と宣言します。これが SuppressFinalize の意味です。
SuppressFinalize を書くと共に Finalize から Dispose を呼ぶ、これを忘れては、上記のカラクリが活きてません。
ではアンマネージドリソースを利用しているのでIDisposableインターフェースを実装。しかし、その実装方法にも決まりがある。ここのところは注意しなければいけないですね。最悪GCのタイミングでDisposeされるように実装。GCがFinalizeを呼び出したときにすでにDispose済みなら余分な負荷を生まないよう、Dispose済みであることを教えてあげなければいけない。のか。
ここでふっと。Finalizeってあまり意識したことがないかも。
[.NET]独自実装クラスにはIDisposableインターフェースを実装すべき?
今日聞いた話。
「自分で実装したクラス(IDisposableインターフェースは実装していない)から生成されたインスタンスで、スコープを抜けて誰からも参照されていない状況であっても、ガベージコレクションの対象とはならず、メモリ解放されない」ということがあるそうです。
だから、IDisposableインターフェースを必ず実装して、インスタンスを破棄するタイミングで必ずDispose()をコールしたほうがよい。という説明をされました。
すべての状況で上のことが当てはまるのか、それとも特定の状況の場合なのか、そのあたりについてははっきりしないようなので、少し調べてみようと思いました。
なにかご存知の方がいたら、コメントをいただけたらと。。
