早起き&ちゃんとしたシャツを着用 だった為、疲れてしまった。
配属先の雰囲気は初めてプログラマーのバイトをした某A社の雰囲気にスゴイ似てる。初めてなのに何故か懐かしさを感じた。やっぱり初日は覚えることが多くて大変だなぁ。早く現場になれていきたいと思う。とにかく人の名前を覚えねば...。なんか、今までとはまた違った世界に突っ込むことになりそう。 果たして凶と出るのか吉と出るのか?
早起きは三文の得。
コレ、普通に現代でもまかり通るな。やっぱいつもより１時間も早いと電車が空きまくりで本が余裕で読める!
距離は遠くなったが、虎ノ門まで通っていた頃よりも楽かもしれない。
遂に明日から本配属。
議事録作れるのか、電話応対できるのか?仕事についていけるのか?不安は尽きない。
一足早く社会人となったbona先生が言っていたように、研修中はまるで高校生のような生活だった。クラスとか響きからして懐かしい。classは全然懐かしくないんだけど。
研修修了式のスピーチのときにもちょっと言ったが、学生時代の抜けを埋めることが出来たのがでかかったな。関数従属とか完全に忘れていた。ネットワークとかも。
プログラミングもJavaに限られているが面白い子ネタを大量に知ることが出来たので面白かった。本も一冊読み終えたしなぁ。あとはJ2EE関連か。バイト時代はフレームワークに隠されていた部分をじっくり勉強する時間があったのでこれも自分にとってはかなり+だな。
研修後半になるに連れてとにかく密度が高かったように思う。最後のスピーチはえらい緊張していたが、元々挙動不審者らしく、飲み会では「いつも通りじゃね?」と言われていた。むしろ落ち着いていたように思われていたらしい。むぅ。
しかも最後の最後でやらかすしな(´Д｀)
最後の飲み会で講師の方とちょっとしゃべった。同じフロアらしいのでこの先も普通に会いそうだなぁ。「この会社を辞めないで欲しい」と言われたのがスゲェ嬉しかった。
ちなみに、自分の職場は南側にあるらしく、暑くて、ジャングルっぽくて、獣のにおいがするらしいです。これなんて研究室?ここにきて院生時代に逆戻りなのだろうか?
関西方面に行ってしまった同期となかなか会えそうにないのが寂しいところだが、まぁ同じ屋根の下だし、意外なところで会ったりとかするんだろうなぁ。結構泣いていた同期も居たが、一時的なお別れじゃ、オレは泣かん。
とりあえず初日から遅刻するわけにはいかんので、明日はすげー早く行こうかな。
ニコニコ動画でものすごい勢いでハイテンションになってしまう洋楽集 Vol.2'を聴いてやっぱり欲しいなぁと思った曲。
Slipknot - Wait and Bleed
親友が好きな曲。オレもこの曲はイイナァと思う。
DJ Technorch - SigSig Dark Side Remix
ﾊｰﾄﾞｺｱﾀﾉｽｨｰ(´Д｀*)
高校生は高校生でも、まるで化学の期末テスト前日のような気分。一応一週間前から勉強を開始したものの、なんだかんだで1,2日前が本当の戦いになってしまうのも高校生時代から変わらず。
--
朝からSJC-WC 310-081の試験を受けに高田馬場まで行ってきました。
結果は69問中53問正解でなんとか合格。試験の途中、ワカラン問題ばっかでこれはもうｵﾜﾀと思ったが、後半自分の得意な分野だったのでなんとか踏みとどまった感じ。正答率76%。やっぱPのときと比べると悪い。WCの方は基本的に暗記ゲーって感じだ。コードを考えて云々という問題では無いので勉強しても、どうも面白みを感じられず、個人的にはつまらなかった。
しかし今回の勉強のおかげでJSPの奥深さも知るキッカケにはなったと思う。タグライブラリやEL式はすげー便利だな。とはいってもJSPで本格的にロジックを組む気には全くなれないが。
とりあえず、なんとかpassしたのでまたいつもの本に戻るとしようかな。
---
定時後は数人で飲んでました。出張の日はいつもよりも疲れてしまう。むぅ。
あとスピーチを同期全員の前ですることになってしまった! （´・ω・｀）何を話せばよいのやら～
んー、定時後に暇なメンツで月島行ってきたけど、あの辺りってすっげーもんじゃ焼き屋があるんだなぁ。
ビニールもらってその中にカバン入れて油の匂いを防ぐのはナイスなサービスだと思った。
ただ、カバンは良いんだけど、上着は結局下のシャツが油臭くなっちゃうのであんま意味無かったな(´Д｀;
久々にもんじゃ食ったけど(5ヶ月ぶりぐらいか?)やっぱうまいなぁー。
ちなみに3年近く大学近くのぽんぽこに通った成果を遺憾なく発揮したような気がします。
自分は基本的に安定志向です。
FreeBSDもstableしか使えないチキンなので正式版をすげー待ってたわけですが、よーやくリリースされたみたい。
スラッシュドット・ジャパン | Firefox 3正式リリース
手動変更を要した拡張
-Tab Mix Plus
→ココからFirefox3対応版を取ってきた。
-All-in-One Gestures
→対応してなかったのでFireGesturesに乗り換えた
-url_breaker
元々長いリンクを折り返すための拡張だったが、3になってから本体がこの機能を有することになったので削除。
使用感
最近、mixiがすげー重くて数秒フリーズとか当たり前だったのがフリーズしなくなった!
ニコニコ動画も同様
体感でも明らかに軽くなったと思う。さっさと入れて正解だった。わっほぃ。
Effective Javaよーやく読了。
2年ぐらい前だか、siに「えー、マジ未読ー?」ぐらいの勢いで言われてしまったのだが、確かにこの本はJavaを扱う技術者なら早めに読んでおくべき内 容だった。個人的には2〜3章がすげー参考になったかな。hashCode()の挙動とか、まさかSJC-Pで役に立つとは思わなかったわ。
問題は読みづらいって点と事前に知っておくべき事柄が多い、つまり若干敷居が高いってことだな。少なくともGoF23パターンは知ってないと2項目 のsingletonで早くもﾊｧ?な事態になる。果たして2年前のオレに読めたかなぁ...ちょうどデザパタの本を読んでいた頃だったような気 が...。
この読みづらささえなければなー。もしオレが英語圏の人間だったらこの本は文句無く良書だよ。あのゴスリングも10年前に欲しかったと言ったのも頷ける。
とりあえず読み終わったものの、まだノートにまとめきれてないのでしばらくはまた読み返すことになるのかな。早く自分が理解した形でまとめなければ...。
日曜にamazonから注文した本が届いた。
ちなみに前回買えなかったRozen Maiden 1 新装版もついでに注文し、Rozen は即発送可能、インターフェイス指向設計は2-3週間待っててね状態だったのですが、先にこっちが届きました。why(´Д｀?
インターフェイス指向設計
― アジャイル手法によるオブジェクト指向設計の実践
色々とレビューが挙がっており、面白そうだったので購入。(参考[1][2])
オライリーにしては薄目の本。Effective Javaよりもちょっとだけ薄い。
早速1章辺りを呼んでみたけど、やっぱオライリーの訳本は秀逸だなぁ。元が洋書だって意識せずに読める。
とりあえず1ヶ月を目標にがんがって読む。
かき氷が食いたくなって、ちょっとコンビニに寄り道して買って、風呂上がりに食った。
で、ちょうど去年のこの時期から研究室でかき氷食いまくってたことを思い出した。
...まぁ、それだけの話のなんだけれども。
以前、ちょろっと報告したSJC-P 310-055
だけど、Sunから合格証書が会社の方に届いた。
カードがなかなかカコ良かったので社員証の裏にでも入れておくかな。
ビニールで包まれてるのはバッジ。でかでかとSunマークがあるので
これを付けるとまるでSunの社員みたいだな。(´Д｀
次はSJC-WCかぁ。覚えることが多そうなのでそろそろ取りかからねば。
前回からの続き。
この章からプログラミング一般に関して。啓蒙的な話が多い。知ってることが多かったのでここは比較的読みやすかった。
--------------
29.ローカル変数のスコープは小さく
C言語みたく、冒頭で宣言しない。宣言は必要になったら。
使い回しが効かなくなるのでbugも減る。
全く関係ないが、この章で面白かったのは
for (int i=0; i
for (int i=0,n=list.size(); i
本当に効果があるのか調べてみた。
package test;
import java.util.ArrayList;
public class Test {
public static void main(String[] args) {
ArrayList list = new ArrayList(10000);
for (int i = 0; i < 10000; i++) {
list.add(new Object());
}
long start = System.currentTimeMillis();
for (int i = 0; i < list.size(); i++) {
for (int j = 0; j < list.size(); j++) {
;
}
}
long stop = System.currentTimeMillis();
System.out.println((stop - start) + " ms");
start = System.currentTimeMillis();
for (int i = 0, n = list.size(); i < n; i++) {
for (int j = 0, m = list.size(); j < m; j++) {
;
}
}
stop = System.currentTimeMillis();
System.out.println((stop - start) + " ms");
start = System.currentTimeMillis();
for (Object o : list) {
for (Object oo : list) {
;
}
}
stop = System.currentTimeMillis();
System.out.println((stop - start) + " ms");
}
}
list()呼び出しまくり版は422 ms50000回に変更したら
list()呼び出しまくり版は5125 ms
list()1回だけ呼び出しは4500 ms と何故か差が縮んだ。なんでだろう。
for(int i = 0; i < list.size(); i++)
{
for(int j = 0; j < list.size(); j++);
}
と変わらなかったのに対して
list()1回だけ呼び出しは
int i = 0;
for(int n = list.size(); i < n; i++)
{
int j = 0;
for(int m = list.size(); j < m; j++);
}
何故か最初に宣言したiがforブロックの外に追い出されてる。
for(Iterator iterator = list.iterator(); iterator.hasNext();)
{
Object o = iterator.next();
Object oo;
for(Iterator iterator1 = list.iterator(); iterator1.hasNext();)
oo = iterator1.next();
}
Iterator を使用したコードに機械的に置き換えてる。
public boolean hasNext() {
return cursor != size();
}
public E next() {
checkForComodification();
try {
E next = get(cursor);
lastRet = cursor++;
return next;
} catch(IndexOutOfBoundsException e) {
checkForComodification();
throw new NoSuchElementException();
}
}
まぁ、このペアを10000の2乗回呼んでるわけだから、そら重いよなぁ。
--------------
30.ライブラリーを使え
自分で1から作るよりライブラリーを使用した方がメリットが大きい。(既にある。bugが少ない。勝手に保守されていく。)まぁ、これは当たり前の話か。
Random.next() → 乱数の範囲を絞るのにmod演算はダメ。コレ、昔やらかした思い出がある。
nextInt()使えって事です。
あとbit演算の話が面白かったかな。((n&-n) == n)がtrueならnは2の乗数とか。
こーゆうbit演算のテクニックを集めた本とかってないのかしら?
--------------
31.浮動小数点数(float, double)
あくまでも近似値なので、正確な値(例えば金額計算とか)が知りたいときはint, long, BigDecimalを使う。
パフォーマンスが重要なら→intやlongを整数部、小数部に分けて使う。
パフォーマンスは重要じゃない。longに分けられないぐらいの桁数、もしくは分割がめんどくさい→BigDecimal使え。
--------------
32.文字列使用を避けるべき場合について
-他の方で表現した方がよい場合 数値データはintやdouble、はい/いいえの2値データならboolean。列挙型とかもStringで表現しない → 分かっていても守られなくなりがち。
-集合を文字列で表現しない→解析にコストがかかる。
-ケイパビリティ(capability;偽造できないキー)として文字列は使わない
本では例としてThreadLocalのダメな設計例を挙げている。
set(String , Object);やget(String);みたいなインタフェースだと2つのスレッドで渡す文字列が被ったときにヤバイことになる。この場合、set(Object)にして内部で一意なkeyを生成して管理すべき。
→もっといいのはjava.lang.ThreadLocalを最初から利用すること。
--------------
33.文字列の結合
+による結合はO(n^2)
→連結回数が固定ではなく、大量の連結はStringBufferつかえという話なのだが、本はJava1.4までの話なので、Java1.5だとどうなんだろう?
JVMもかなり最適化されたという話だし、スレッドセーフでなくなる代わりに高速化されたStringBuilder(そもそもStringBufferなんて複数スレッドで共有とか普通しないもんな。)も登場したし、よくわからんので後で調べる。 → [開発] [Java] [メモ] StringBufferよりもStringの方が文字列結合は速い？
StringBuilderを使うようにjavacが自動変換してくるのか。賢いな。
でもループ内での+による結合はやっぱり遅いみたいだ。
--------------
34.型を指定するときはインタフェース
もしくは似たような共通の機能を有する親クラスにしろという話。
インタフェースにしておけば実装クラスが切り替わった場合の変更が最小限で済む。
・そもそも実装を切り替える場合ってあるのか
→あるインタフェースを実装している既存のクラスよりもパフォーマンスの良い新しいクラスが現れた場合など。
以前紹介した「HttpSessionの実装について」の5系から6系までの変更とかがよい例だね。
--------------
35.リフレクションの使いどころ、使われどころ
リフレクション:クラスの情報を動的に取得できる仕組みのこと。
ただし、動的なのでコンパイラーによる型検査の意味はなくなる。コードも複雑になりがち。パフォーマンスも悪いというデメリットもある。
→クラスブラウザ、オブジェクトインスペクタ、コード解析ツール、インタプリタ的な組み込みシステム、又はRPC(Remote Procedure Call)とかニッチなもので使うぐらい。
p.147-148より
あなたのアプリケーションがこれらの分類のどれかに属するかどうかについて何らかの疑問があれば、おそらくは属してません。これは、「そんなことで悩んでるようなペーペーには無縁な技術なんだよ!(#ﾟДﾟ)」という皮肉だろうか。(´Д｀)
普通の場面ではデメリットだらけなのでリフレクションは使わない。
唯一よくある例としてはフレームワークの基幹部分。URLから動的にアクションを生成して呼び出すときとか。
コンストラクタに引数いらないならClass.newInstance();の方を使って生成すべき。
--------------
36.ネイティブメソッド
JVMの最適化が進んでいるのでパフォーマンスの為にネイティブメソッドを書くのは×
デメリットの方が大きいので(C、C++で書くのでメモリ領域に関して安全でないし、保守もしづらくなる。)ネイティブメソッドの使用は、低レベルリソースや古いライブラリにアクセスせざるをえないときだけに留める。
--------------
37.最適化の話
工程の早い段階で最適化はしない。
良い(おそらく、可読性の高いということなのだろう)プログラム>>速いプログラム
API、通信プロトコル、永続データのフォーマットに関する設計は後々のパフォーマンスに与える影響が大ということを意識する。
どうしても最適化をするのならプロファイラーを使ってボトルネックになっている箇所を特定してから最適化する。そしてチューニング前後の結果を比べる。
ボトルネック特定後は、細かいチューニングの山よりはプログラムの中に潜むO(n^2)なアルゴリズムをO(nlogn)とかに書き直した方がよっぽど効果がある。→だから最初にやるのは選択したアルゴリズムの検証から。
--------------
38.命名規則
まぁ、知ってる内容だったので割愛。
ひとつ思ったのは、BeanでもないのにgetHoge()やsetHoge(Hoge)という名前にするのはやめようかなぁってことかな。
hoge()やhoge(Hoge)でもいいかもしんない。
自室のちっこいTV
待機 3w
on 60w
ハブ 1w
ルータ 3w リンク確立 5w
e-yamaの15inch液晶ディスプレイ
待機 1w
使用時 18w (まぁ輝度を抑えて使用しているからか、思っていたより低かった)
いよいよ一番測ってみたかったPC。構成はこんな感じ。なんだかんだでもう3年目突入か。
待機 1-2w
PC起動時 95w
アイドル時 90w 全然減ってねぇ!?Σ(ﾟДﾟ ; )と思ったらC'nQがoffになってた...orz
いつoffにしてしまったのか...。まぁ気づいただけでももう良しと言うことにする。
アイドル時(C'nQ on) 76w
15w低減。もっと早く気づくべきであった。
firefoxが固まるほど激しくタブを開いたとき 97w
オレのRadeon X800(無印)に火を噴かせてみる。
TC:Eメニュー選択 120w
プレイ中 123-125w
BF2;メニュー選択 117w
ロード時 119w
プレイ 130w
やはりRadeon が電気食うなぁ。
ちなみにBF2はサーバへの通信中などCPUを多用する場面ではこまめにGPUをセーブしてるっぽい。ところどころで消費電力が減るのを確認。ちょっと賢い。
うーん、【詳細版】Atom 230とCeleron、Core 2、Athlon X2を比較：ニュースを 見た後だと、Athlon X2 4850eを積んだシステムの負荷時=自宅PCのアイドル時の消費電力なのでしょんぼり。3D描写能力はこっちの方がイイに決まっているが、そんなゲー ムってワケでもないしなぁ。次のお給料が出たら、PCをそろそろ組み始めようかしら(´¬｀;
びびったのは自室のストーブ。まぁ流石に今日は暑かったので点火状態までやってないが、火つくまで615wをkeep(ﾟДﾟ )ﾏｽﾞｰ
あと待機電力もバカにならないってことだね。こまめにコンセントは抜いておいた方がいいね!
土曜日は大学の友人達と神田で飲んだ。
神田まで時間があるのでdesutanと秋葉原〜お茶の水あたりをぶらぶらしておりました。
--
秋葉原でついにワットチェッカー買っちゃったよ。
今まで低消費電力スレをウォッチしていた身としてはいずれ買わねばならないと思っていたので遂に...って感じだ。
ラジオ会館あたりを見ていたのだけど、あの辺はやっぱり面白いな。カールコードなキーボードなど古いパーツとか見てるとなんだか楽しい。高校の部室に居るみたいだ。
パーツ屋も見て回った。CPUやメモリが安い安い。500GBHDDも最近じゃ1万円あれば買えちゃうのね。
そろそろ新しいマシンを買ってしまいそうだ。
キーボードも見た。cherryの黒軸の押し心地はなんかクセになりそうだ。ただ、少しオレには重いな。茶軸はなんだかすごく軽く感じた。店頭展示品でみんなが押しまくってるからか?HHKBの静電容量無接点スイッチとはまた違った押し心地なのでちょっと興味が湧いてきた。
残念なのはテンキーが漏れなくついてきてしまうのでスペースを取ってしまう点だな。HHKB並のコンパクトなキーボードならなぁ...。
--
御茶ノ水では本屋に行った。
店頭で立ち読みした感じだと「実践 パケット解析 ―Wiresharkを使ったトラブルシューティング」や「ビューティフルコード 」が面白そうだった。
が、まだ読んでない本が自宅があるので買うのは我慢する。技術書は読める状態になってから買うことにした。欲しいときに買って、寝かしておいてそのまま第2版が...なんてことになりそうなので(´¬｀;
ビューティフルコード、表紙も綺麗だけどオライリーなんだよな(失礼?)
オライリーってどうしても白黒なイメージがあるなぁ。
まぁ昨日行って気になったものはだいたいこんな感じか。
【速報版】Atom 230とCeleron、Core 2、C7を比較：ニュース
ACアダプタ駆動は卑怯だろ...常識的に考えて。
たしかAthlon64でもACアダプタなら25w近くで運用できるって報告がどっかにあがってたな...ココにあったような気がする。
Atomだとアイドル時でもあんま変動ねぇなぁと思ったら、なるほど、デスクトップ版だからspeedStep未実装なのか。自宅サーバ用途にしたいんだけど、自宅サーバって基本アイドル状態だからなんかもったいない気もする。むぅ...。
それにしてもC7の立場が非常にヤバイ。VIAにはもっとがんがってほしい。
アウトプット量の方が少ないな...どーもいかん。
前回からの続き。
--------------
23.パラメータの正当性検査
(本当は無い方がイイのだが...)メソッドに渡す制約がある場合、その制約についての説明をドキュメント化する&制約違反を起こしていないかチェックする。(もし変なパラメータが渡ってきたらさっさと例外を投げる。)
まぁ当たり前の話だよね。
変なパラメータを受け取ったときに投げつける例外の例として本では3つの例外を挙げている。
-IlligalArgumentExceprion
-NullPointerExceprion
-indexOutOfBoundsExceprion
個人的にはどうも下2つには納得行かないのだが...。わざわざプログラマーが外に投げるべき例外なのかな?
[追記]
よくよく考えたら3つとも実行時例外だから大差なかった。
オレの作ったライブラリーが悪いんじゃなくて、利用してるお前の使い方が変なんだよと意思表示したいときは投げてもいいのかもなぁ。
他にもこれはどうなんだろうと思うところがあって、例えばprivateなメソッドに渡すパラメータのチェックはassert使うことを推奨しているのだが、assert使うにはVMに引数-ea必要だし見落としがちにならんかなぁ?と個人的に思う。
privateなメソッドに対してはtestを書いた方が良いんじゃないかねぇ?
メソッドで生成したデータが次のメソッドに投げられ、そこで使われるような場合は特にちゃんと(作られた時点で)検査すべき。データを作った側か、使う側に問題があるのかハッキリする。
検査のコストがでかい場合は検査を諦めるという選択肢も考慮に入れる(まぁ、当たり前か)
検査の途中で発生してしまった例外をさっき紹介した例外に置き換えたい→例外翻訳イデオム(項目43)の導入を検討する。
--------------
24.防御的コピー
外部から可変オブジェクトへの参照をもらって内部変数にsetするだけでは脆い。
(外部にある参照から内部を書き換えられる可能性がある。ちょうど昨日書いた"HttpSessionの実装について"の冒頭がコレに当たる)
可変なパラメータを渡される前にコピーを取ってから受け取る。(その際に妥当性チェックが必要ならコピーに対して行う)
そして、渡すときにもコピーを取ってから渡すようにすれば外部から内部をいじれなくなる。
パラメータとして渡されるオブジェクトがオーバライド可能なクラスなら...→cloneは使わずにコンストラクタを使ってコピーを作る。 cloneを使うと生成したオブジェクトを全てリストに保持しちゃうような悪意に満ちたサブクラスのオブジェクトを渡されたときに困る。(でもコレはいく らなんでも考えすぎなような気もするが...まぁ、ここまで想定できるようになれば完璧なんだろうが)
不変クラスだけでなく、可変クラスでも外部から勝手に内部オブジェクトを弄られると困るような場合もこの辺のことは頭に入れておくべき。
可変オブジェクトを構成するプリミティブ型データだけを持つという手も有効。多分こっちの方がコストも抑えられて楽。(例:Dateのオブジェクトを持つのではなく、DateのgetTime()で返されるlong値のみを持つ...とか。)
--
とりあえず今日はここまで。
続き。
--------------
25.メソッドの設計について
-メソッド名は適切に。
SunのJavaコーディング規約
deleteとremoveどっちがいい?→選択する単語については"The Java Developers Almanac"を読めってことらしい。だいたいの傾向が分かる。ちなみにこの場合はdeleteを選択するべき。
-1つのクラスに便利なメソッドを集中させない→使う側が迷う。
-メソッドの引数は多くても3つまで。同じ型のパラメータが続くのは特に酷い。
→んじゃどうするのか?
1.複数のメソッドに分ける方法(ここ、すげぇ読みにくかった...)
例.Listインタフェース
本では
このインタフェースは、サブリスト内の要素の最初あるいは最後のインデックスを見つけるメソッドを提供していません。
とあるが、ここで言ってるメソッドとは正しくは指定した要素がサブリスト内の最初(あるいは最後)に現れる位置のインデックスを返すメソッドのこと。
最初この文章を見たとき、なんで3つ引数が居るのかワケ分からなかったけど、こう解釈すればlist.indexOfSubList(obj, fromIndex, lastIndex);となるだろう。
このようなメソッドを作るのではなく、subList()とindexOf()を組み合わせて使うようなapiにしろと言っているようだ。こうすれば引数の数が2,1に分かれ、しかも使い勝手がいい。
2.パラメータをまとめるstaticなメンバークラスを作る。
-パラメータの型は具象クラスよりもインタフェースを選ぶ。
→インタフェースを実装する他のクラスのインスタンスも渡せるようになる。
-関数オブジェクト
StrategyやVisitorパターンのような使い方にとどめる。関数オブジェクトをメソッドからメソッドに渡すような、駆使しまくりな使い方はしない。lispでやれってことですね。
--------------
26.オーバロードとオーバライド
どちらも多態性関連の用語だけど、メソッドの選択は
オーバライド:実行時に決定
オーバロード:コンパイル時に決定(静的)
といった違いがある。同じパラメータ数のオーバロードされたメソッドは極力避ける。作ったとしても型が根本的に異なる(つまり親子関係がない)ようにする。
--------------
27.nullを返すメソッド
nullを返すと利用者側にnullチェックを強制してしまう。これは色々とメンドイ。ifの条件式が汚くなりがち。
例えば、配列を返すときに配列がカラだった場合、nullではなく長さ0の配列を返すようにする。
別の例:collectionのtoArray(T[])
引数から受け取った配列を利用。
Null Objectパターンもこの辺の話と関連あるね。
--------------
28.javadocコメントの書き方
公開APIにはドキュメントを必ず書く。前の項目と被るけど、パラメータの制約やメソッド実行による副作用があるならちゃんと書くべき。
ドキュメントに式を書いたときは&や不等号に注意する。(ちゃんとHTMLのエスケープシーケンスで書いてるか?)
これ、完全に守ってなかったな...でもイチイチ特殊文字をエスケープシーケンスで書いてられるか!ってところ。もう少しjavadocが賢ければいいのに。試してないけど「AnyEdit」ってプラグインがあった。
-英語ドキュメントの話
インスタンスメソッドの説明でthisが出てきたらそれはメソッドが呼び出されたオブジェクトのこと。
ドキュメントコメントの最初では概要を説明する部分。ピリオドを使うとそこで途切れるので注意する。HTMLシーケンスでピリオドを打って解決という手もある。
メソッドコメントの継承も可。(ただし、コメントをそのまま丸々使う場合のみ。部分的な修正は出来ない。)
複数のメソッドの相互作用によってプログラムが機能している場合
→全体のアーキテクチャを説明する外部ドキュメントを別に作り、その外部ドキュメントへのリンクをjavadocコメントに書く。
激しく迷う。
北森瓦版 - VIA "Isaiah"をローンチ―製品名はVIA Nano processor
ローエンドのTDPは相変わらず低いな...
PINUPS - 上田新聞 blog版: Atom搭載Mini-ITXマザーボードが6月5日頃に発売
atomもそろそろきそうだし...。
はやくベンチマークこねーかなー。電気食わない方をサーバ用として狙う。
本屋に行ったらあったのでつい買ってしまった。
家族をとるか、キャリアをとるか?という新たな問題に移ったね。
加藤助教授koeeeeeeeee!!
http://perl-mongers.org/
もの凄い勢いでfeed登録した。
Javaと言っても今回はj2ee。
sessionにコレクション系クラスのオブジェクトを最初に突っ込んで、それをgetしてきてコレクションに要素を追加、再びsetし直すみたいなコードを書いたんだけど、よくよく考えたら getした参照からsession弄りたい放題じゃね?と思って別にsetし直す必要ないよねー的なことを報告書に書いて提出したら、この前の金曜日の飲み会で「挑戦的な報告を受け取ったから自宅の環境で試しにやってみたんだけど再現しなかった～」と言われてしまい、なぬー?と思い少し実装がどうなってるのか気になったので調べてみた。
HttpSessionはインタフェースなので実装クラスがまずなんなのか調べる。
→org.apache.catalina.session.StandardSessionFacadeというクラスらしい。
apache tomcatのホームページからソースを取得。
今回はtomcat-4.1.37
tomcat-5.5.26
tomcat-6.0.16の3つを調べた。
StandardSessionFacadeはあくまでもStandardSessionのラッパー的存在なのでStandardSessionの方を見ます。
まず
public Object getAttribute(String name) {
if (!isValid)
throw new IllegalStateException
(sm.getString("standardSession.getAttribute.ise"));
synchronized (attributes) {
return (attributes.get(name));
}
}
ちなみにattributesの宣言はprivate HashMap attributes = new HashMap();
HashMapは同期化されないのでsynchronized でくくってますね。
public Object getAttribute(String name) {
if (!isValid())
throw new IllegalStateException
(sm.getString("standardSession.getAttribute.ise"));
return (attributes.get(name));
}
attributes の宣言はprotected Map attributes = new Hashtable();
Hashtableは同期化されるのでsynchronized ブロックがごっそり消えてるね。
てかHashtableの存在を今まで知りませんでした( ; ´Д｀)
public Object getAttribute(String name) {
if (!isValidInternal())
throw new IllegalStateException
(sm.getString("standardSession.getAttribute.ise"));
return (attributes.get(name));
}
attributes の宣言はprotected Map attributes = new ConcurrentHashMap();
HashtableをConcurrentHashMapに置き換えてパフォーマンスアップしてるらしい。
参考:Javaの理論と実践: 並行コレクション・クラス
なんかHash系クラスの紹介になりつつあるが、どうやらgetでオブジェクトのコピーを渡しているわけではなさそうだ。
多分報告書を大分はしょって書いたので講師の方はstringとかの不変クラスをぶちこまれたのではなかろうか?自分の言葉足らずだったかも。てか冒頭の方法はそもそもカプセル化破壊を利用しちゃってるしなぁ。混乱を招かないためにもgetしたらsetし直すという方針がHttpSessionの正しい使い方なのかも。
