タグ

ブックマーク / www.artonx.org (6)

  • L'eclat des jours(2009-12-04)

    _ RubyRails ジュンク堂で、前田さん、大場さん、松田さんのトークショー。 前田さんと言えば、ついにRubyの仕様ドラフトが公開されたわけで、ご多忙のことだと思うけど、その話は出なかった。でも、RubySpecを使って1.9.2のバグつぶしに協力して欲しい(そうしないとRuby 1.9完全対応となるはずのRails3も困るよね)という話はあった。 というわけで、AWDwR3は、汽車、ディーゼル車と来て、レールが敷かれていない空へ向かって飛び立ちそうなところに来た(で、Rails3=AWDwR4では空を飛んでいるだろうという話となる)。 RailsによるアジャイルWebアプリケーション開発(前田 修吾) 蒸気機関車が煙を吐いている。 RailsによるアジャイルWebアプリケーション開発 第2版(Dave Thomas) もう石炭じゃないよ。 RailsによるアジャイルWebアプリケ

  • L'eclat des jours(2009-12-01)

    _ IE7, 8 (6) と静的コンテンツ IEは、Last-Modifiedがレスポンスに入っている場合には、次回のリクエストにIf-Modified-Sinceを付ける。Last-Modifiedを最初に送らなければ当然送ることはできないからだ。 このときのリクエストはHEADではなくGETとなる。以前は最初にHEADを送ってきたような記憶があるが、今は304をGETに返せば良いから直接GETを寄越すのだと思う。 かつ、既定の状態だと、Last-Modifiedを送った場合は、最初の時点からキャッシュを積極的に利用する(ように見える。ETagに比較して)。 一方、Tomcat 5.5(他のバージョンは知らない)は、静的コンテンツの送信時にETagは付けるがLast-Modifiedは付けない。ETagはマルチホストのときに厄介とかいうより前に、アプリケーション的な操作を行うには便利では

    Nagise
    Nagise 2009/12/01
  • 読みやすいソースコードとは - L'eclat des jours(2009-11-23)

    _ 読みやすいソースコードとは きむら(K)さんの日記読んでて、はて、確かにおれも読んだのだが、まったくどこだかわからんぞ、と気になってさがした。 ソースコードのコメントよりも空白行のほうが理解を助けるという研究結果 元のペーパーはRaymond P.L. Buse and Westley R. Weimer: Learning a Metric for Code Readabilityらしいけど、www.computer.orgがDNSで引けないのでまったく読めない。 で、名人がクリーンだとかビューティフルとか言う世界ではなく、いよいよソースコードそのものの読みやすさについて定量的な分析が行われるようになったのだなぁという感慨というか来ちゃったなぁ感というかがある。 次に来るのは、多数が読みやすく書きやすい言語ってものの設計と実装が来るのだろう。(でも、多数の人間ではなく、機械生成しやす

  • ログに見るEclipse脳 - L'eclat des jours(2009-10-02)

    _ ログに見るEclipse脳 なんで以下のようなコードが生まれるのだろうか? ... } catch (Exception e) { logger.error("xxxでエラーになった"); } loggerはLog4JLogLogのインスタンスなので、あと3文字追加すれば、 ... } catch (Exception e) { logger.error("xxxでエラーになった", e); } となって、話が異様に簡単になる。 なっていなかったので、例外になったという事実だけを淡々と記録したログを前に途方に暮れて調査に無駄な時間を使うことになった。 どうも、彼らはユニットテスト(xUnit系の話ではない)時に、loggerの行にブレークポイントを置いて調べるから、eをLogLogのメソッドに送る必要性をまったくわかっていないようだった。 実際にインストールして動作させて異常時にログ

    Nagise
    Nagise 2009/10/02
    ブレイクポイントのせいでロギングが疎かになるのだとしても、IDEによって解決できる気があまりしない。catch節で常にログ出力ならeを補完できようがそうでもないしね。
  • 5年後に後悔しないJavaプログラムの書き方 - L'eclat des jours(2009-07-02)

    _ 5年後に後悔しないJavaプログラムの書き方 ここ数日、死ぬほど後悔しまくっているので、あらためて(というのは、数年前にも一度後悔しまくって、そのときの知見はあらかた処方箋とかコーディングの掟に書いているからだが)後悔しないための書き方をいくつか紹介する。 とにかく、ファクトリメソッドパターンを使うこと。 これは当に重要。しかも簡単でありながら効果は絶大。 だめな例。 public class FooBar { private Connection conn; ... protected void setup() { ... conn = DriverManager.getConnection(url); ... } urlを指定することや、DriverManagerの実装を交換すれば良いだろうと想定していても(というか、Connectionならそういう方法もあり得るが、そうはいかな

    Nagise
    Nagise 2009/07/02
    コンストラクタにAOP噛ませることができる言語とかになれば話は違ってくるんだろうけどね。拡張の余地を残すようにカプセル化を考える。いざとなればここでパージして交換できるよねってのが重要
  • L'eclat des jours(2009-04-24)

    _ 実用的な脳みそ 昨日は、リファクタリング・ウェットウェアのちょっと気持ち悪い点にフォーカスしてみたが、実はそれほどぶっとんだことをアンディハントは書いていない。 せいぜい、プラグマティックな効用もあるようだから現代のシャーマニズムも取り入れてみました、程度だ。多分。書いている人も気にはしていて、 さあ、ここは我慢して私の話を聞いてください。というのも、「妖精が使う魔法」のようにうさんくさい話と思われそうだからです。 なんていう言葉がちょくちょく出てくるからだ。 それどころか、 数年前、右脳に基づくありとあらゆる長所を約束した自己啓発が続々と出版されました。右脳の料理まであったと思います。 もちろん、そんなのは意味がありません。「アホだ!」と言ってもいいくらいです。 と、自分の脚に銃を撃つ始末だ。というのも、うさんくさいことを言い出す奴は、他人のうさんくささに不寛容だし(だめだ、フ

    Nagise
    Nagise 2009/04/24
    プログラムについての解説書は、ここで挙げられているロッククライミングのレクチャーように、苦労を体験してからでないと価値を理解できないものが多い感触
  • 1