top
NOTE: 何度もスパム書き込みがあるのでUser-Agentが"Mozilla/5.0"からのアクセスを拒否*1するようにしました． NOTE2: 何度もスパム書き込みがあるので213.182.176.XXX/24からのアクセスを拒否するようにしました． NOTE3: なにかよいスパム対策を教えてもらえませんか?: 2006-07-23 - kou →スパム対策 NOTE4: 効果があるかどうかはわかりませんが、スパム判定にlist.dsbl.orgとniku.2ch.netを利用するようにしました。: 2006-08-02 - kou: 参考: スパム対策 NOTE5: 非常に心苦しいのですが、スパム対策のためにプロテクトキーを入力しないと保存できないようにしました。JavaScriptを利用している場合は自動で入力されるようになっています。: 2007-04-01 - kou [R
Matzにっき(2006-01-31)
<< 2006/01/ 1 1. [教会] 元旦 2 1. 出産 2. 帰省 3. 到着 3 1. デジタル体重計のユーザインタフェース 4 1. [OOP] Classbox 2. [OOP] Classboxの実装 5 1. 帰宅 2. PCレスライフ 6 1. PC修理 7 1. 雪かき 2. [言語] プログラミング言語SRU 8 1. [教会] 断食安息日 2. あーめん 3. 筋肉痛・体調不良 9 1. 米子 10 1. [原稿] オープンソースマガジン3月号 11 1. [原稿] 日経Linux 3月号 12 1. [Ruby] Charming Ruby Compiler 2. [Ruby] The Open Nature Of Ruby 13 1. ニート娘に悩む親 2. Python Status Update 3. 泥縄 14 1. 宣教師のお手伝い 2. Simpl
オブジェクト指向設計の原則 - Akaponのブログ
「JavaプログラマのためのUML」から，簡単なまとめ(メモ)。 設計品質 設計の臭い 硬直性：変更しにくいシステム。変更の影響範囲が広い 脆弱性：一部を変更するとあちこちに綻び(エラー)が生じるシステム 低移植性：分割できない複雑なシステム 粘着性：？ 不要な複雑さ：今必要でない将来のための汎用性による複雑さ。YAGNIの原則違反 不要な繰り返し：コピペによる重複したコード 不透明さ：分かり難さ，設計意図が見えない 依存関係の管理 複雑に絡み合ったコードにならないように依存関係を管理する。 クラス設計の原則 クラス，モジュール設計における原則。クラス分割，依存関係の指針。 単一責務の原則(SPR: Single Responsibility Principle) クラスを変更する理由がただ一つになるように，責務を一つにする 自分の持つ属性に責任を持つなら，外部の環境に依存してはならない(
Design Principles Behind Smalltalk
BYTE Magazine, August 1981. Reproduced with permission. (c) by The McGraw-Hill Companies, Inc., New York, NY. All rights reserved. The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone. Our work flows from a vision that includes a creative individual and the best computing hardware available. We have chosen to concentrate on two principle are
Retirement note for Model View Presenter Pattern
This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and I won’t be doing any corrections or updates until I’m able to find ti
Presentation Model
This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and I won’t be doing any corrections or updates until I’m able to find ti
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://alohakun.blog7.fc2.com/blog-entry-117.html
プログラミング言語論教材
抽象データ型
http://www.ogis-swe.jp/process/am-res/am/artifacts/crcModel.html
どっとねっとメモ:DataSetを利用したドメインモデル
mixi(ミクシィ)
http://moudamepo.net/wiki/index.php?TellDontAsk
http://www.object-arts.com/Lib/EducationCentre4/htm/helpcontents1.htm
http://www.object-arts.com/EducationCentre/Patterns/MVP.htm