ちくのブックの最新の日記
ちょうど良い複雑さ
ちょうど良い複雑さというものがあると思う。
たぶん、今自分が使っているコンピュータはすごく複雑だ。何がどう動いているのか、さっぱりわからない。確かに鉛筆マークとか、矢印とか、マウスとか、人に気を使ってくれているのは分かる。その辺は、たぶんかなり頑張ってると思うし、The Demo以降頑張ってそっち方向に進化してきたし、これからもコンピュータはそっちの方向に頑張って進化していくんだろう。でもさ、すげー不思議なんすよ。本当にこれは0と1の集まりで動いてるのかね。なんかすごく疑わしい。中の人とか、本当はいるんじゃないのかね。
すごい不思議、PCって。
何度も言うけど。
「在るか無いか」っていうめっちゃ単純な仕組みを幾重にも積み重ねてったらすごい複雑になっちゃった感じ？わかんないけど。複雑でわかんないんす。おいら頭よくないんす。
なんで今欲しいのはパソコンをぱかって開けて中身を見て「ほうほう、こうやって動いているのか」っていうのが分かるくらいの、でもちゃんと仕事はするような奴が欲しい。ちょうど良い程度の複雑さを持ったOSが欲しい。
メモリを意識できるような言語で物を書きたい。
どうなってんだろなー。まじふしぎ。
ヒトにキを使う
相手に気分よくなってもらう事を一瞬のうちに、めちゃくちゃ少ない労力で、誰よりも早くやる事だと最近気づく。
「ヒトニキヲツカウ」て事の価値は、かけた労力とあんまし比例しない。
一瞬の判断と、少しヒトより早く動く機敏さ。
そういった意味で高度な知的労働なんかなーと思う。
深いぜ！
ヒトニキヲツカウ！
今まで自分があんましこういう事を考えてこなかったので、これからは心を入れ替えて「誰かにちょっと気分よくなってもらう」事をする事を心がけよっと。
新しいっすわ。
これは。
【日報081104】
【日報081104】
kakasiとの決闘を決意 23:13
kakasiクラス化プロジェクト発動
http://www.stackasterisk.jp/tech/php/php03_09.jsp
http://zapanet.info/phpdoc/language.oop5.html
&で参照引数
http://d.hatena.ne.jp/gallu/20060412
うむ。変な感じだ。クラスにしてはみたものの、上手く動いていない。うむ。
まずは処理だけを書き上げることにする。
とりあえずコピペコードは動いているっぽい。文字化けを改善せねば。24:20
http://hain.jp/index.php/tech-j/2007/02/13/%EF%BC%B0%EF%BC%A...
http://memo.xight.org/2007-02-14-1
24:30 Time Up
【研修ノート】
10/28/2008
実開発では、e.printStackTrace(), System.out.println()などは入れない！
コードを少しでも変えたら処理が変わったということになるので、
単体テストからやり直し。
ログ出力の規約を決めておく。それに沿ってログを出すようにする。
【トランザクション制御】
一つのトランザクションの中には一つのコネクション。
コネクションの管理はトランザクションの範囲。
コネクションを管理する一番いい層はビジネス層である。
なぜならビジネス層は一度の業務（一度のトランザクション）単位で分割されているから。
データアクセス層にはコネクションを作らない！
コネクションを生成するのはビジネス層にし、コネクションを引数としてDAOに受け渡す。
【三層に分ける】
ビジネス層には特定の技術に依存するような設計はしない。例：Connection
理由：しっかりと層を分けるためにそのように設計する。
三層に分ける理由。
大規模開発において開発者個々の技能において担当範囲を分けることができる。
個々の層の構成を見やすくする。可読性を上げる。
どうすればそのような設計ができるのか。
フレームワーク使う。よくわからん。
【テーラリング】
プロセスを設計する必要がある。プロジェクトに応じてプロセスを組み替える。
代表的なものはテンプレートとしてあるので、それを実際の状況に合うように
テーラリングをする。
【概念クラス図】
クラスを抽出する。
多重度が大事。
【ユースケース】
細かいことは書かない。
ユーザーから見たシステムの主な機能を書き出す。
【ユースケースシナリオ】
やりすぎない。
丁寧にやり過ぎない。
【画面】
画面があればユースケースシナリオが要らないこともある。
Webアプリの場合はこっちに力を入れるほうがいいかも？
画面大事だと思うらしい。俺もそう思う。
なんか作るもののイメージわくし。
【シーケンス図】
全て書いていくと膨大な量になり、大変非効率である。
代表的なものだけ書いていく。
一概にどのようなドキュメントを作るかというのは決まっていない。
正解は無く、その場の状況に合わせてプロセスを作り変えていかなければいけない。
ドキュメントはお客様に合わせる。
極端に作業を遅らせるようなドキュメントを依頼された場合は要相談。
分析をやっている間にアーキテクチャ（技術要素検討）をやっていく。
用件定義⇔技術要素検討
例：用件定義の段階でお客さんがJavaを使ってほしいなどの要求を出してきた場合。
【パッケージング】
レイヤは論理的にシステムを分ける。概念的に分ける。抽象的。
パッケージングはレイヤを参考にしてクラスを物理的に分ける。
相互依存、循環参照はだめ。絶対。
相互依存、循環参照はパッケージを変更した場合に影響範囲が大きくなる可能性がある。
とても危険なのよ。
クラスで循環参照、相互依存は御法度！for未熟者
ただ高度な設計テクで相互依存になっている場合はあるらしい。
相互依存になっている場合はまず作成者に理由を聞くべし。
＜クラス設計に関するメモ ＞
http://homepage3.nifty.com/satoshis/oo/memo.html
＜第5回 Webサイトの詳細設計＞
http://www.atmarkit.co.jp/fjava/rensai2/websys05/websys05.ht...
【インターフェースの導入】
変更や各兆字の影響や、再利用、チーム開発、テスト容易性の観点などから
インターフェースを導入する。
インターフェースがあればスタブが作成しやすい。
【技術要素の検討】
システムの特性に合わせてメリット、デメリットを検討。
同期 ：クライアントがサーバに要求を出さなければ動かない。
非同期型：クライアントが要求を送信しなくても動く。例：GoogleMap
【トランザクションスクリプト】
ビジネス層の設計方式のうちの一つ。
振る舞いと属性を分離していく。
処理のみの（ステートレスな）オブジェクトが、値のみを持つオブジェクトから、
必要な値をやり取りして情報結果を得る。
【ドメインモデル】
ビジネス層の設計方式のうちの一つ。
OO指向的な設計方法。
属性と振る舞いを持ったオブジェクト同士が、必要な情報を得るために、
メッセージをやり取りして最終的な情報結果を得る。
Patterns of Enterprise Application Architecture
http://martinfowler.com/eaaCatalog/
web.xmlを処理を追加する(Servletを増やす)ごとに更新していくのは面倒且つ危険。
Front Controller。受け付けるだけのServlet。
を使うことによって処理を増やすごとにServletの数を増やさずにすむ。
【設計クラス図】
実装技術を意識する。
クラス図には描き過ぎないように注意する。
【シングルトンパターン】
処理を表すクラスはシステム内で一つのオブジェクトしか必要ない場合が多い。
属性を持ってない場合はオブジェクト一つで済む場合。
一つしかオブジェクトが生成されないようにするための仕掛け。
オブジェクトが一つであることを保障する。
コンストラクタをprivate指定にしてしまう。
クラス内でオブジェクトをnewする。
オブジェクトはprivate static finalで。
public指定のgetInstanceを使ってオブジェクトを他のクラスに渡す。
