firefox2.0

ツール

最近こちらに書くようなことに時間を割けておりません。無念。
firefoxの2.0が出たって言うんで入れてみた、けど拡張の Tabbrowser Extensions が使えないってんで戻しました。てか『拡張』って言わなくなったの？アドオン？前からそうだっけ？なんか時代に乗り遅れてる感MAX。

さて

その他

すんごい、２ヶ月弱放置とかありえない。
というわけで試験までいよいよあと１週間。正直言って対策の程は思わしくありません。前回のエントリでいよいよと言い出してから９月の半ばぐらいまでは、それなりにちょこちょこはやっていた。けれども、結局ごっつい問題集の半分もいかない程度の進捗で９月後半はいろんな意味でそれどころじゃなくなったり、単純にモチベーションを欠いてしまった、というのがここ最近の話。書かなかったんじゃなくて単純に書くほどの進捗がなかったというわけです。
この３連休もそれなりにやろうとは思いつつ、結局大した成果もあげられぬまま終わりを迎えそうであります。まったくもって情けない。
来週までに試験を合格ラインに持っていくことはちょっと難しそうです。というかムリ。でも受験はします。受かる受からない以前に受けるべき理由があるので、来週は試験会場に行ってムダにあがきます。
それなりにネットワークの知識が身についたような気もするけどなー。今はその時期ではなかったということでしょうか。というのも、実は今日も半分ぐらいは業務の勉強とかしちゃっていたり。諸般の事情により、今はそちらへの注力が急務となっているのでまぁ仕方ないかなー、と。そんなこと言ってたらずっと受からない気もするんですが；-)
以上、言い訳なんてして良いわけ的エントリ。逝って良し。

いよいよ勉強開始

資格 ネットワーク

やっべ、更新し忘れてました。
実は先週の金曜日で朝読書のEffective Javaを一旦ストップして、ネットワーク試験対策を始めています。なんか中途半端な感じもしますが、なんとなく気がそっちへ向いたのと、Effectiveの方は先の内容を見るにあとでもいいかぁと思ってしまったもので、唐突ですが路線変更。
ほいでとりあえず朝はマスタリングTCP/IPを読んでみたり、3 Minutes Networkingをダラーッと眺めながら基本的な部分を思い出しつつ、定時後スパッと仕事を切り上げて、カードを切りつつ会社に居座り自席で過去問を解く（DBの直前一週間にやっていた作戦）というのを今週から始めました。まだ三日目ですが。
過去問はひとまず１５年度の午後Iをやってみたのですが、なーんか簡単なのもあれば、んむむー…ってのもあったりして。とにかく実務経験０のオレにはピンと来ない部分やぼんやりとわかっても言葉に上手くできない部分が多すぎて、現時点では厳しいなぁというのが率直な感想。まぁぼちぼちやっていこうと思います。

Effective Java（項目30〜32）

JAVA 読書

ああ、昨日は更新を忘れていた･･･orz
しかもちょっと浮気気味だったし、ダメだなぁ･･･

○項目30 ライブラリーを知り、ライブラリーを使う

  • 標準ライブラリーを使用することのメリット３つ
    • それを書いた専門家の知識とそれを使用した人間の経験を利用することが可能
    • 時間を自分が作るべきアプリケーションに費やすことが可能
    • 時間と共に、ライブラリーのパフォーマンスが改善されることが期待できる

  • 大部分のプログラマがライブラリーを使用していない、なぜか？

→ライブラリーの存在を知らないのではないか、知っておいて損はないのに･･･
→プログラマはjava.lang, java.util, java.io(ある程度)ぐらいはその内容について知っておくべき！！

  • もちろん場合によってはライブラリーは所望の機能を満たさないかも知れない

→まずライブラリーにないかを調べ、ないならば実装というスタンスは良いはず

  • これは決してあなたのプログラマの能力を非難しているわけではなく、その方が往々にして良い選択であるという話


○項目31 正確な答えが必要ならば、floatとdoubleは避ける

  • float型とdouble型は主に科学計算と工学計算のために設計されている（２進浮動小数点算術）

→広い範囲の大きさに対して正確な近時をすばやく行うために設計されている、が、正確な値を返さない
→特に金銭計算には適していない（仕事柄、生々しい話･･･）

  • 正確な答えが必要ならばint, long, BigDecimalを使おう

→特に気にならないのであればBigDecimal型は丸めモードなどもあり便利である
→法律で決められている丸めの規則に従ってビジネス計算をする場合に役立つ（生々し過ぎる！！）


○項目32 他の方が適切な場合には、文字列を避ける

  • 文字列は使うべきでない場面でも使用されがちである
  • 文字列は、他の値型に対する代替としては貧弱
    • データが数値ならば、int, float, BigInteger等の適切な数値型に変換されるべき
    • データが「はい/いいえ」の問いに対する答えならばboolean型にすべき
    • データが本質的に文字である場合にだけ文字列にすべき
  • 文字列は、列挙型に対する代替としては貧弱

→項目21 タイプセーフenumとintの方が列挙型としてはるかに優れている

  • 文字列は、集合型に対する代替としては貧弱

→ある実体が複数の構成要素を持っているならば、それを文字列で表現しようとするのは良くない

  • 文字列はケイパビリティ(capability)に対する代替としては貧弱

→ケイパビリティとは、どうやら識別用の偽造できないキーを指す模様、で、それに文字列は向いてないという話

Effective Java（項目28〜29）

JAVA 読書

昨日はお休みでした。気を取り直して再開。
○項目27 nullではなく、長さゼロ配列を返す

  • 以前やりました

→http://d.hatena.ne.jp/shaw27/20060726/1153866783

○項目28 すべての公開API要素に対してドキュメントコメントを書く

  • ドキュメントコメントをちゃんと書きましょうというお話
  • メソッドに関するドキュメントコメントは、メソッドとそのクライアント間の契約を簡潔に記述すべき
    • メソッドがどのように処理を行っているか、ではなく、何を行っているかを述べる
    • メソッドの全ての事前条件と事後条件を列挙する
    • メソッドのいかなる副作用も文書化すべき
    • 全てのパラメータに対する@paramタグ、戻り値があれば@returnタグ、スローされる全ての例外に対する@throwsタグ

  • その他、概要説明の際のHTMLのスタイルに絡む話もある、が細かくは割愛

→一点だけ、HTMLメタ文字はエスケープする必要がある

○項目29 ローカル変数のスコープを最小限にする

  • C言語ではローカル変数をブロックの先頭で宣言しなければならない

→Javaでは文が書ける場所であれば、どこでも変数を宣言できることを忘れず、活用する

  • ローカル変数のスコープを最小限にする最も強力な方法はローカル変数が初めて使用された時に宣言すること
    • 使用される前に宣言されているならば、それは散らかっているに過ぎない
    • 読み手の注意を逸らしてしまう
    • ローカル変数を早めに宣言することは、ローカル変数のスコープをかなり前方から始めるだけでなく、後方まで広げてしまうことでもある

  • ほとんどのローカル変数宣言は、初期化子を含んでいるべき

→変数を合理的に初期化するのに十分な情報がなければ、情報が得られるまで宣言を先送りすべき

  • try-catch周りは例外
    • 変数がチェックされる例外をスローするメソッドで初期化されるならば、その変数はtryブロック内で初期化されなければならない（ん？ちょっとわからん･･･）
    • 変数がtryブロックの外でも使用されるのであれば、その変数はtryブロックの前に宣言されなければならない

→これらの場合「合理的な初期化」をすることはできない

  • ループ変数の内容がループが終了した後に必要ない場合には、whileループよりforループを選ぶ（なるほど！！）
  • ループ検査がメソッド呼出しを伴い、そのメソッド呼出しがループごとに同じ結果を返すことが保証されている場合

→例えば以下のようなイデオムを用いることは、スコープ、パフォーマンスの両面から有益

// ランダムアクセスリストをイテレートするための高速なイデオム
for (int i = 0, n = list.size(); i < n; i++) {
  doSomething(list.get(i));
}

Effective Java（項目25〜26）

JAVA 読書

週明けの割りにテンションが低いのは昨日風邪を引いてしまい病み上がりだから。
○項目25 メソッドのシグニチャを注意深く設計する

  • メソッド名を注意深く選ぶ。名前は常に標準命名規約に従うべき。

  • 便利なメソッドを提供し過ぎたりしないようにする。個々のメソッドは「自分の役割」を果たすべき。

→これは言われてみればそうだけど忘れがちかも知れない

  • 長いパラメータのリストは避ける
    • 通常３個程度を実用的な最大値とみなすべき（でも今はIDEが協力だからなぁ･･･）
    • 同じ型のパラメータが何個も続くのは特に有害（これは同感）

→どうしてもパラメータが長くなってしまうなら、メソッドの分割を検討する

  • パラメータ型に関しては、クラスよりインタフェースを選ぶ

→例えばHashtableと書くぐらいならMapと書く

○項目26 オーバーロードを注意して使用する

→知らなかった、感覚的に間違っていた

//不完全 - オーバーロードの謝った使用！ ←また誤った！！
public class CollectionClassifier {
  public static String classify(Set s) {
    return "Set";
  }
  
  public static String classify(List l) {
    return "List";
  }
  
  public static String classify(Collection c) {
    return "Unknown Collection";
  }
  
  public static void main(String[] args) {
    Collection[] tests = new Collection[] {
      new HashSet(),         //Set
      new ArrayList(),       //List
      new HashMap().values() //SetあるいはListのどちらでもない
    }
    
    for (int i = 0; i < tests.length; i++) {
      System.out.println(classify(tests[i]));    
    }
  }
}

↑この結果は"Unknown Collection"を３回表示、となる。
→これはtests[i]はコンパイル時にひとまずCollection型となるため。実行時の型はオーバーロードの選択に依存しない！！
※ちなみにオーバーライドの場合は実行時に選択（これは感覚的に合っていた）

  • オーバーロードされたメソッドの選択は静的、オーバーライドされたメソッドの選択は動的

→この違いは多くのプログラマにとって感覚的ではない、困惑するのではないか

  • プログラマを困惑させない方法を考える
    • 同じパラメータ数のオーバーロードされたメソッドを提供しないことにする
    • 同じパラメータ数ではあるが、それらのうちの少なくとも１つがそれぞれ互いに型変換不可能である場合は大丈夫