わんくま同盟わんくま同盟
わんくま同盟 -> Blog's
わんくま同盟メンバの最新の記事
元ネタ：「安易な119はやめようというのは危ない...」
ちょうどタイムリーなことにカンブリア宮殿で救急医療の話が取り上げられていました。
私が前回、「ちょっとでも迷ったら119番しよう！！」という主張をさせていただきましたが。やっぱりこれは間違えていませんでした。
実際に番組内でも119番するのは控えましょうという話は全く出てきませんでした。
が、しかし、結論は正しくても、それをサポートしている様々な理屈が大きくずれていることに気付きました。
まず、119番の乱用について。
これは番組でも取り上げられていました。
実際にあった乱用の具体例を引用させていただきます。
- 昨日飲みすぎた。
- 深爪をした。
- 蚊に刺されてかゆくて寝れない。
- 隣の家の人が騒いでうるさい。
- 寒いから灯油を買ってきてほしい。
- ストーブのつけ方が分からない。
- 水虫がかゆくて寝れない。
- 「うちの子が大変なんです。」とかかってきたが、よくよく聞いてみたら「うちの子」というのがペットだった。
想像を絶する内容です。
こんなことで119番する方々に「119番乱用はやめましょうね。」と言っても、たぶんあまり効果ないですよね。
ここまでは前回のブログ通りです。
しかし、果たしてこういう乱用が原因となって大きな問題って起こっていますか？
例えば、こうした乱用が原因で119番につながりにくくなったとか、救急車が足らなくなっちゃったとか、救急病院のベッドが足らなくなったとか、たらい回しされてるうちにお亡くなりになったとか。
そんなことはないんです。こうした乱用は119番側で当然シャットアウトで、救急搬送が実際にされることはまずないんです。
いま最も問題なのは、救急搬送したくても受け入れ先の病院が見つからず、何時間もたらい回しされてしまうということなのです。
番組中でも、東京都内で４ヶ月も早く産気づいた妊婦さんが、たらい回しされた揚句、100km先の栃木県に搬送された例が紹介されていました。横浜から浜松にヘリで搬送された例もありました。
つまり、119番せずに自力で救急病院にかかったとしても、結局は救急病院のお世話になるわけで、何の解決にもなっていないのです。
さらに、過酷な救急医療の現場も紹介されていました。お医者さんをはじめ、多くの関係者が30時間労働です。人の命を預かるような方がそのような過酷な労働条件に立たされて医療事故が起こらない方が不思議です。
しかも、残業8時間ぐらいでプラスされる額が1～2万だそうです。
すべての元凶は政府の政策にあります。
医療費を抑えるために１５万床ものベッドを削減するそうです。
こうなると、救急病院から一般病院に転院することがままならなくなり、救急病院のベッドが空かず、さらにたらい回しが多くなるでしょう。
そして、病状が悪化してから運ばれる患者さんが増え、さらに入院期間が長くなり、医療費も上がるという...
最悪な悪循環。まさに
悪魔のスパイラル
です。
こうしたことに我々が対処しえることはあまり多くはありません。
あえて言うならば、常に健康に留意することぐらいだと思います。
そして、早期発見、早期治療につきます。
救急車呼ぶほど深刻になる前に、受診しておきましょうということでしょうか？
そして、
必要であれば無理せず119番をしましょう。
それ以上手遅れになる前に。
前回の脳卒中の奥様も数日後に脳ドックの受診を控えていました。
兆候はあったのです...
今では様々なサイトにログイン フォームがあったりしますが、このログインする時の ID にメールアドレスを使用することが多いようです。パスワード リマインダとの連携で考えればメールアドレスであった方が楽なんでしょうね。私はよくパスワード忘れちゃう人だからそんな風に安易に考えてしまう。
ログイン ID がメールアドレスでないところは、ログイン ID をも忘れてしまうことがあります。セキュリティ的にはメールアドレスでない ID 制の方が良さそうな気がしますが、そういうところに限ってパスワードが 8 文字までしか使えなかったりとお粗末だったりするのですよね。○○館なんて数字しか使えないとか、アフォかと。個人的には結局統一しないと覚えられない罠なので、もうメールアドレスでいいじゃんなんて思ってしまいます。その代わりパスワード強化を強制して欲しいです。
最近ではパスワードが英数字が混在でなければならないサイトも増えてきました。金融系なんかだと、これに加え IP 規制やキーロガーでの読み取り防止のためのソフトウェア キーボードもあります。このソフトウェア キーボードも本末転倒な実装をしている怖いサイトがあります。はい、怖いので通報しておきました。もちろん破る方法なんて書くと何されるかわからないのでなるべくぼかして通報しました。
金融系と言えば、ソニー銀行だと登録されていないパソコンからアクセスすると本人が考えた質問と答えを 3 回答えるハメになります。良いアイデアだけど非常に面倒くさいですね。三菱東京 UFJ ダイレクトだとパスワードには記号を最低 1 つ入れることになっています。また取引するためには乱数表が必要になっています。乱数表のおかげでパスワードをマメに変更する必要がないですし、連続試行で突破できる可能性も低くなります。ただ、乱数表を示したカードを持ち歩く必要があってつらいです。持ち歩くことによるリスクも考える必要があるのではないでしょうか。それに何よりこのご時世では、サイフの中身はカードだらけで入れるところなんてないです。乱数表は携帯に保存してパスワードかけて携帯で見るようにしています。乱数表が書かれたカードは本当なら処分したいところですね。それと、連続試行による突破防止のために金融系では、パスワード 3 回連続ミスでロックを実装して欲しいです。
あまり強化するとうるさい世代もいるので、イーバンクのようにオプション化しておくと全ユーザー層に納得させれるんじゃないでしょうか。
シュウたん美化バージョン。
…じゃなくてよその子ｗ
携帯 W61CA で撮影。
C#をお触り、タッチング、して4か月が経ちました。
私のことは今度から「”しーしゃーぷぁ～”の画伯」って呼んでください。
8割嘘です。
で。
詳しい言語仕様とか、突っ込んだ話は出来ないのですがこの4か月での何かしらの変化を描いてみようかと。
あっ、別に「C# VS <del>COBOL</del>VB」とかそういうあれじゃないですよ？
言語自体の良し悪しが語れるほどのスキルは持っていません。
単なる主観のお話。
○良かった点
･中括弧に嫌悪感が無くなった。
ので、苦手なJavaScriptとかJavaとかとにかく中括弧使う言語に苦手意識がなくなった。
･コードがすっきりしてきた。
･サンプルが豊富になった（最近ほとんどのサンプルがC#とかだったりするし）ので助かった。
･「コードの意味」を深く考えられるようになった（慣れないことをしたからこの歳で1から勉強できた）
･VB厨が！って言えるようになった。
×悪かった点
･VBのコードを書くときに文法を間違えるようになった。
最後に「；」とか打っちゃう。
「＋」と「＆」を間違えちゃう。
･大好きな青色が少なくなった
･とりこびっちとの心の距離が広がった
何にせよ、新しいことにチャレンジできたのがうれしかったです。
Visual Studio 2008 Team Foundation Server Service Pack 1 (Beta)が公開されています。こちら。
こちらはチーム開発の支援サーバーであるTFSのSP1のBetaですね。
こちらもWS2008に対応していたり、SQL Server 2008 CTP6に対応していたりといろいろ機能強化されているようです。
まま、こちらも評価したい人は環境に気をつけてくださいねー(^^;
Visual Studio 2008 Shell Service Pack 1 Beta 再頒布可能パッケージが公開されています。
integrated modeがこちら。
isolated modeがこちら。
こちらはいわゆるVS2008Shellの再配布可能パッケージ。
VS2008ShellはVS2008のIDEなどを利用して、ユーザーが独自ツールやプラグイン、また独自の言語開発環境などの作成を行えるVS2008SDKの中に含まれるShellですね。
こちらはそちらの再配布可能パッケージのBetaということのようですね。
まま、こちらも情報が少ないままですねぇやっぱり。
やはり一部のベンダーくらいにしか興味ないものなんでしょうか？ 結構利用すれば裾は広がりそうなんですが・・・ってまず自分がやれって話もありますが(^o^;;;;
Visual Studio 2008 Service Pack 1 Betaが公開されています。こちら。
ちなみにVisual Studio 2008 Express Edition SP1 Betaはこちら。
こちらも公開ですね。VS2008のSP1のBetaです。
SQL Server 2008に対応していたり、Entity Frameworkだったり、Silverlight用のWPFサポートだったり、C++用Office Ribbonだったりいろいろと機能強化も含まれているみたいですねー。
ただし、こちらも互換性の問題があるようです。
こちらをインストールすると
Expression Blend (all versions) （2.5 Betaを除くそうです。）
Silverlight 2 Beta 1 SDK
Silverlight Tools Beta 1 for Visual Studio 2008
これらとの互換性に問題があるので注意が必要だそうな。
また、既知の問題もいろいろあるようですので、Readmeも読んでおいてねーってことでした。
まま、試したい人も多いでしょうけど、現行環境には入れずにVPCなどでの利用にしておいたほうがよさそうですね(^^;
.NET Framework 3.5 Service pack 1 Betaが公開されています。こちら。
Microsoft .NET Framework 3.5 SP1 Language Pack Betaはこちら。
あくまでBetaですが、.NET Framework 3.5のSPがそろそろ姿を現しましたねぇ(^^;
ただし、今回も注意点があるようです。 Vistaでこちらの.NET FrameworkによってWPFを利用する場合は、VistaのSP1かMicrosoft Visual C++ 2005 SP1 Redistributable Package（いわゆるVC++ SP1 再配布パッケージですね)をインストールしないといけないっぽいですね。
ただし、互換性の問題があるようです。
こちらをインストールすると
Expression Blend (all versions) （2.5 Betaを除くそうです。）
Silverlight 2 Beta 1 SDK
Silverlight Tools Beta 1 for Visual Studio 2008
これらとの互換性に問題があるので注意が必要だそうな。
また、既知の問題もいろいろあるようですので、Readmeも読んでおいてねーってことでした。
まま、試したい人も多いでしょうけど、現行環境には入れずにVPCなどでの利用にしておいたほうがよさそうですね(^^;
まぁ、くれぐれも適用するにはReadmeを読んでほしいとのことですので、テスト前には気をつけてくださいねー(^^)
http://support.microsoft.com/kb/926892/ja
Office 2003 プログラムを使って、 2007 に Windows SharePoint Services 2.0 ドキュメント ライブラリの Office ファイルを変更すると、変更が保存されません。
ファイルは、次の 1 2007 Office プログラムで作成されました。
・ Office 単語 2007
・ Office PowerPoint 2007
・ Office Excel 2007
なんじゃ？っておもって、英文みたら、
The file was created in one of the following 2007 Office programs:
| • |
Office Word 2007 |
| • |
Office PowerPoint 2007 |
| • |
Office Excel 2007 |
・ Office Word 2007
だったよ・・・
柔軟な.NET構成セクションハンドラ（.config）の作成
http://japan.internet.com/developer/20050822/26.html
あ、あとでためそー
というメモ的なものですｗｗ
社内で、討論会をやるみたい
http://cityriver.main.jp/Diary/archives/002211.html
・ＵＭＬなんていらない
・TDDやらテストファーストなんて意味がない
・ソフトウェアファクトリで全部開発すべきなんだ
といったテーマを、賛成派、反対派でディベートしまくるみたい
ただでさえ熱く語る人がおおい会社なので、すごいことになりそうだ・・・
Visual Studio Team System 2008 Development EditionをTeam Suiteに上げてみました。
インストールされているプログラムの確認
Vistaであれば[コントロールパネル]-[プログラムと機能]でインストール済のプログラムを確認できるので、現在のインストール状況をまず確認してみます。
図にあるように[Microsoft Visual Studio Team System 2008 Development Edition - 日本語]がインストールされている事が確認できました。
Developer EditionをTeam Suiteにするにあたって、その方法としては次の２通りが考えられます。
- (1)Developer Editionが入っている状態でTeam Suiteを追加インストールする
- (2)Developer EditionをアンインストールしてからTeam Suiteをインストールする
まずは手軽にできそうな(1)の方法で行ってみます。ただし、結論から言えば(1)の方法は根本的ではないけれど問題がありますので、(1)の方法を採用する場合は最後までお読みになって判断してから始めてください。
なお、作業に先立ちODP.NETのアンインストールも行っています。
つづきはこちら
レジでお金を払う時に、明日健康診断があるのを思い出しました。
肝脂肪診断と蛋白下りるかもしれません。
内部的な話ですが秀丸メーラーでSMTPの設定が出来ず、
わんくまアカウントでメールを投げれません(´・ω・`)ﾄﾞｳｼﾖｳ
ここ数年携わったプロジェクトの幾つかのRDBのテーブル定義は、文字列属性がすべてvarchar2(n)でした。長さ1byteの項目でも、キー項目でも、複数項目からなる項目でも一律にvarchar2(n)です。
可変長の扱いはOverHeadが高い、Update処理の時、有効な項目データ長が確保されている行領域を超えるときは、行が取り直されるので置換コストが高くつく。というコスト意識がまず浮かんでスナオに賛成できません。
別の面では、項目長の意味合いが崩れる。とも思うのです。8byteの顧客コードのシステムの場合、「８桁の顧客コード」という桁数に意味があるケースもあります。"1234 "が "1234" になるのでは
意味が変わってくることもあります。
また、顧客コードを varchar2(8) にしているシステムと、char(8)としていいるシステムと連動したとき, '1234' = '1234 ' が成立しないので、要らぬ手間が生じたり、不毛なバグ騒ぎになったりします。
桁が固定している項目は固定長にしましょうと主張すると返ってくる反論は 「RDBもCPUも進歩して早くなっているのだから、varchar2()によるコストアップは知れている。それよりも、varchar2()で統一するメリットのほうが大である。他のシステムもvarchar2()に置換すべきだ。」
うーん。いいのかなぁ。引っかかるなぁ。古い感覚から脱皮できないのかなぁ。
varchar2() と char() の 動作振る舞いの差を認識したうえで、varchar2()に統一しているのなら一理あるようにも思います。しかし、それがインフラになっていると、初心者にとってはそれが当たり前になってしまい、違いを知ろうとしない開発者になったりします。
安易に作れるようになると、浅い開発者が増えるのは痛し痒しですね。
それとはまったく別次元の話ですが , Varchar2()の'2'に違和感を感じてます。 マジックナンバー感がするのです。
以前のORACLEはvarchar()があり拡張型として varchar2()が登場した背景があります。しかし、"2"にするのは軽いと思うのです。拡張やexpansionにナンバーを付けるセンスが如何とも。
PowerShellの拡張子が、PS1 というのもあり、末尾に数字を付ける文化って不滅なのかなぁ。
名は体を表わすべきだし、マジックナンバーは止めましょうと推進しているインフラ的な製品に"2" が付くのは落ち着かないです。
セッションネタです。
タイトルの通り、Visual Studio 2008 の Visual Basic コンパイラ は既存のコードに対する動作が Visual Studio 2005 から変更になっている部分があります。つまり、Visual Studio 2005 の Visual Basic で書かれたコードを Visual Studio 2008 でコンパイルした場合、異なる結果となる可能性があるということですね。
というわけで、ひょんなことからハマったりして凹む前にちょっと確認しておきましょう♪
１．ジェネリック パラメータと ParamArray パラメータを使用した場合の オーバーロードの解決動作が異なる。
さて、一つ目です。まずはコードから♪
Namespace Demo1
Public Class Class1
Public Overloads Sub Method(Of T)(ByVal a As T, ByVal ParamArray b() As Integer)
System.Console.WriteLine("おぱおぱ～")
End Sub
Public Overloads Sub Method(Of Y)(ByVal a As Y, ByVal b As Y)
System.Console.WriteLine("ばよばよ～")
End Sub
End Class
End Namespace
Demo1.Method はオーバーロードされていますね。どちらもジェネリック パラメータを持つジェネリック メソッドで、(1) のほうは２つ目の引数が ParamArray、(2) のほうはジェネリック型となっています。
では、以下のコードで Demo1.Method を呼び出した場合、実行されるのはどちらのオーバーロードでしょうか？
Namespace Demo1
Module Program
Sub Main()
Dim c As New Class1
Dim i As Integer
Dim s As Short
c.Method(i, s)
End Sub
End Module
End Namespace
実はこの呼び出しによって実行されるオーバーロードが Visual Studio 2008 と Visual Studio 2005 で異なります。
Visual Studio 2005 では (1) のメソッドが呼び出されます。これは、ジェネリックである Y に Integer 型と Short 型 の2つを指定することができず、s の型 である Short 型 は ParamArray である b へ拡張されるために起こります。
これに対して Visual Studio 2008 では (2) のメソッドが呼び出されます。これは Short 型が Integer 型に拡張されることによってジェネリックである Y は Integer 型 と推論されるためです。
ちゃっぴさんのblogに変な返答をしてしまったので、言い出しっぺの法則に基づき、方法論を考えてみました。
テーマはあるWebアプリケーション(以下、システムと言う場合はアプリケーション全体を指す)があったとして、
そのシステム全体でデータに対するアクセス権を管理するためにはどうしたらよいだろうか？です。
ここではOOP(オブジェクト指向)でいうObject単位での権限管理を考えます。
これらのObjectはRDBMSなどで管理されるような永続性のあるデータを想定しています。
ユーザの保有する権限の管理
例えば、システム内でプロジェクトを表現するクラスProjectがあったとして、
参照、新規、更新、削除の４つの権限を持つとしましょう。
さらに、Projectのインスタンス単体でこれらの権限が設定できるとしたならば、
ユーザ側の情報に、どのProjectに対して何権限を持つのかの情報を持たなくてはなりません。
まず、権限の種別を表す列挙を用意します。
public enum AuthorityType {
/** 参照権 */
SELECT,
/** 登録権 */
INSERT,
/** 更新権 */
UPDATE,
/** 削除権 */
DELETE,
}
そして、権限管理クラスでは対象となるオブジェクトのID・型とその権限を保持するようにします。
今回は簡単のためIDによって対象データを特定する方式をとっています。
一般的なWebシステムを想定するとすれば、このユーザの権限情報はセッションに保持されます。
このオブジェクトをProjectオブジェクトを操作するたびに権限確認のために引き渡すのはデータの取り回しがあまりに大変なので
HTTPの1リクエストごとに、1つのThreadが立てられることを利用してjava.lang.ThreadLocalに
この権限情報を格納して利用するとしましょう
。
ThreadLocalはそのThread内だけをスコープとするグローバル変数のようなものとイメージしてもらうと大体当たっていると思います。
/**
* ユーザが保持する権限を管理するクラス
* ユーザ単位で1インスタンスが作られる。
*/
public class AuthorityManager {
/** ThreadLocalでThread内をスコープとするグローバル変数を作る */
private static ThreadLocal<AuthorityManager> manager = new ThreadLocal<AuthorityManager>();
private static final String SESSION_KEY = "AuthorityManager";
/** セッションから権限情報を取得してThreadLocalに設定する */
public static void initManager(HttpServletRequest request) {
HttpSession session = request.getSession();
AuthorityManager auth = (AuthorityManager) session.getAttribute(SESSION_KEY);
manager.set(auth);
}
/** ThreadLocalから権限情報を解放する */
public static void releseManager() {
manager.remove();
}
/** 保有権限のList */
private List<Tips> authList;
static class Tips {
/** 対象オブジェクトのID */
int id;
/** 対象オブジェクトの型 */
Class objectType;
/** 権限タイプ */
AuthorityType type;
}
}
/**
* HTTPのリクエスト毎に権限情報を設定するFilter
*/
public class AuthorityInitFilter implements Filter {
@Override
public void init(FilterConfig config) throws ServletException {}
@Override
public void destroy() {}
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
// 権限情報をThreadLocalに設定
HttpServletRequest httpRequest = (HttpServletRequest)request;
AuthorityManager.initManager(httpRequest);
try {
// 実際のServletの処理
chain.doFilter(request, response);
} finally {
// 権限情報をThreadLocalから解放する
AuthorityManager.releseManager();
}
}
}
実装は省いていますが、保有データからユーザ側に保有権限のListを持たせ、権限認証の際に割符のように
操作対象となるオブジェクトと付き合わせようという思惑なのをイメージして頂けますでしょうか。
権限チェックを漏れがないように執り行う
さて、Thradにアクセス権限の情報を持ちました。
あとは対象となるProjectオブジェクトから権限のある場合のみデータが参照できるように網羅しなくてはなりません。
これは、Projectオブジェクトへのアクセス全てに対して
「権限チェックをし権限のないアクセスであれば例外を投げるという処理」
を差し挟むということですから、AOP(アスペクト指向)で言う「横断的関心事」となります。
さて、この横断的関心事ですが、AOP対応の言語であれば、言語機能を用いてウィービング
(アスペクトはWeaving、縫い付けると表現します)すればよいのでしょうが
ご承知のとおりJavaはそうではないので、なんらかの手段を講じなければなりません。
ProjectオブジェクトがDIコンテナによって管理されている場合、DIコンテナのAOP機能でウィービングする手が使えるでしょう。
DIコンテナは現行の非AOPな言語でAOPを実践するための工夫と捉えることもできます。
DIコンテナを用いていなくとも、Projectオブジェクトの取得する口が特定できるならそこを抑えてProxyを噛ませる手が使えます。
GoFデザインパターンのProxyパターンはOOPの範囲で出来るAOPへの対処法とも言えます
。
場合によってはダサいですがProxyクラスさえも用意せず、Projectオブジェクトの各メソッドに
権限チェック処理を直接実装する手法を用います。
横断的関心事を分離できていないわけですが、setter、getterなんぞそもそも処理が希薄なので割りきることもできることでしょう。
注意点として、Proxyパターンや、直接Projectオブジェクトに権限チェックを実装するような場合、メソッドの網羅は保証できません。
なんせ、手で個別のメソッドに対応を差し挟むわけですから。
機械的な網羅ではないのでヒューマンエラーで容易に漏れてしまいますし、なにより記述が面倒です…。
もちろん、Projectクラス自体をアーキテクト管理下に置いて、勝手に改変されないような状況である必要があります。
ここまですると、開発時に参照件のないProjectオブジェクトを取得して、その情報を参照しようとした時点で
実行時例外を起こすことができるようになるわけです。
もちろん、処理効率的にはよくないわけですが、セキュリティ的にはいくらかの安全性を担保できることでしょう。
まとめ
設計パラダイムとしては、まず該当オブジェクトへの操作に対する権限チェックをアスペクトとして捉える事。
また、これをうまくウィービングして全ての参照/設定メソッドに網羅させること。
そして、処理の実行体であるThreadと、操作対象であるオブジェクト
（上記例ではProjectオブジェクト）との間の権限確認を行います
。
Threadを用いないでオブジェクトを操作することはできないですし、アスペクト指向によってオブジェクトに対するアクセス全てに
権限確認処理をウィービングすることで、ヒューマンエラーによる誤操作をすべてはじき出すわけです。
また、悪意ある故意の操作に対しても処理をはじくことがある程度できます。
もっともThreadの持つ権限管理データまで改ざんされるとアウトなわけですが…。
なお、ここで挙げた設計方法は、1案に過ぎません。よりよい方法論もあることでしょう。
この方法論を試すのは自由にしていただいて構いませんが、
私はこの設計方法を採用して発生したいかなる損失に対してもなんらの責任は負わないものとします。
注釈
*1元のコメントではシステムの範囲を誤解させてしまいました… orz
*2
RDBMSでのプライマリキーとなることも考慮してIDによって対象となるObjectを対応付けていますが、
本当はProjectオブジェクトへの参照によって対応付けを行いたいところです。
Projectオブジェクトの数が限られ、システム全体で完全にキャッシュされるようなケースであれば容易でしょう。
全てキャッシュできるほどにProjectオブジェクトが少ないわけではないとすれば、
Projectオブジェクトの参照は同一に遅延ロードを実装する手法も考えられます。
なお、アクセス速度を考えるとListよりはMapなどの構造を取った方が適切でしょう。
このあたりは実際のデータを鑑みて考慮する必要があります。
*3
ただし、通常ServletではThreadがプールされるため、HTTPのリクエストの処理開始で格納し、
処理終了時には削除するようにしておかなければいけません。
これはjavax.servlet.Filterで処理することで漏れなく確実な処理を行うことができます。
*4
アスペクトがDIのすべてとは言いませんが、AOP対応言語ではDIコンテナを使う意味があまりないはずです。
DIはコンストラクタに対するアスペクトとして実装することができてしまう。
強いて言えば、設定ファイルを読み込んでリフレクションで設定を行うところが面倒なので、
そのあたりをやってくれる程度には便利と思いますが。
*5
例えば、Projectオブジェクトを取得するためのサービスが限定されているようなケースでは、
その出口を抑えて、GoFデザインパターンのProxyパターンを適用すればよいのです。
Proxyクラスの実装はProjectオブジェクトを継承し、全機能をProjectに委譲するようにしておきます。
ただし、getterメソッド全てに参照件のチェックを差し挟むし、setter全てに更新件のチェックを差し挟むわけです。
*6
ProxyパターンでAOPをする場合の最大の障壁は、オブジェクトの生成箇所をどのようにして抑えるかという点。
new演算子で生成されると手の打ちようがありません。
生成に関するデザインパターンなどを用いて、オブジェクトの生成部を一元管理できているようなケースではどうにかなります。
DIコンテナも生成をDIコンテナが一身に背負うことでProxyパターンによるAOPを成し遂げているわけです。
*7
変更する人が状況をよく理解している少数であったとしても、修正に際してAOPの対応漏れは容易に発生します。
誰もが変更できる状況下では維持するためのコストは膨大になることでしょう。
*8
1Threadあたり1Userという状況下である必要があります。
世の中にはあるいは1Threadあたり複数userとなるシステムもあるかもしれませんが、
そういうケースではこの手法ではうまくいかないことになってしまいます。
こんばんわー
薬のんで一時的元気なのんですー
さっき面白いアイデアをえぴさんからいただいて
考えてたらある疑問が・・・・・
わんくまってオスですか！！！！
メスですか！！！！
えぴさんさっきのアイデア実行しちゃうと思います♪
ぴんくまDayで☆
みんなの分作ったほうがやっぱかわいいですよね？
やっぱつくろうかなあ♪
MLで流します☆
お薬飲んだ後なので朦朧としてますちょっとだけ。
昔は disk I/O だけ意識しておけばよかったんですけど、最近はそうでもなさそう。
シャドウコピーを有効に出来ない
Windows Server 2003 から使えるようになった Volume Shadow Copy Service (VSS)。これ非常に便利ですよね。ですけど、これ利用するためには disk 容量に比例して memory を相当消費するらしい。
Scalability Factors for Shadow Copies
う～む。結構食いますのぅ。10 TB くらいになると 32bit OS はっきりいって使えんやん。これから構築するなら間違いなく 64bit ですね。
File server の場合、disk I/O を削減するために memory を大量に積んで置くべきですしね。大容量の memory support はやっぱり必要でしょう。
そういえば以前から Windows Storage Server というのがありましたが、これ 64bit 版あるのかな～？と思いちょっと調べましたが、どうやら無さげ。なんでやねん！ Windows Storage Server なんて file server 以外に利用しないんだから、真っ先に 64bit 化するべきだと思うけど。ついでに 2008 はまだ出ていないらしい。2008 は 64bit only でもいいんじゃない？
ということで、現在 Windows で file server を構築する場合、OS が利用する memory (利用する user の session 数を検討する必要あり) + VSS で見込まれる部分 + cache を考慮して見積もることになりますね。Memory は多めに積んどけば system cache で有効活用されるでしょうから、まあ現実的な費用の範囲内でできるだけ積んどけってことで。
ずっと memroy について書いてきましたが、CPU はどうでしょう。こちらは圧縮と EFS の利用状況によると思います。容量制限が厳しいと圧縮を使いまくりますね。これらを全く利用しないのであれば正直どうでもいいでしょう。
Disk は performance, 信頼性重視なら SAS。容量、価格重視なら SATA になるでしょう。最近は SATA でも hot plug に対応しているものが多いので、SATA という選択肢が増えてきましたね。
で、もち RAID にするのが当たり前ですが、費用面から一般的に RAID 5, RAID 6 を選択することが多いでしょう。RAID 5 を利用するか RAID 6 を利用するかは disk の本数により変わってきます。個人的には 8本あたりで使い分けるかな。
RAID 5, RAID 6 を利用する場合、software RAID は絶対にお勧めできません。Performance ガタ落ちです。安物ではなくちゃんとした array controller 利用しましょう。安物は本当の意味では software RAID になります。んまあ、普通に大手 vendor で server 手配した場合には問題ないですけど。
Performance を少しでも高めたいのであれば、disk の本数を増やしてください。RAID 5 で HDD 3, 4 本くらいでは、どんな array controller 積んでいても満足な performance 得られません。
ネタモト：http://blogs.wankuma.com/rti/archive/2008/05/12/137324.aspx
Rさんのところで、Overrideで解決してた部分がDelegateでやるように書いてた！と書いてある。
単純化されたパターンだから気になっただけかもしれないけど、個人的にはこういう感じで書いていくかなぁ～と思ったので書いておく。
LoadDataを公開するようにインターフェースILoadableを作成。
public interface ILoadable
{
DataSet DataSet { get; }
void LoadData();
}
んでもって、それを継承する形でクラスを作成。
public class LoadableImpl : ILoadable
{
public DataSet DataSet { get; set; }
public Func<BaseTableAdapter> GetTableAdapter { get; set; }
public void LoadData()
{
using (var a = GetTableAdapter()) a.Fill(this.DataSet);
}
}
後は、AAA用 BBB用 CCC用のインスタンス作るクラスを作って完成。
public class Factory
{
public ILoadable CreateAAA()
{
return new LoadableImpl
{
GetTableAdapter = () => new AAATableAdapter()
};
}
public ILoadable CreateBBB()
{
return new LoadableImpl
{
GetTableAdapter = () => new BBBTableAdapter()
};
}
public ILoadable CreateCCC()
{
return new LoadableImpl
{
GetTableAdapter = () => new CCCTableAdapter()
};
}
}
ということで、書いてる途中で思った。Gushwellさんがコメントに書いてあるコレでいいじゃんって。
public class Base<T> where T : BaseTableAdapter, new() {
public void LoadData() {
using (var a = new T())
a.Fill(this.dataSet);
}
}ということで、このエントリ書くのやめようかと思ったけど、書いちゃったので投稿。
ついでにいうと、これしきのことにインターフェースなんて…って思ってしまう部分も大いにある。
ここらへんのさじ加減は、何度も失敗して覚えていくのだろう。
なんか、カスタマイズして設置する事ができるみたいです。→あなただけのサーチ エンジンを作りましょう
ここを見ると、検索ボックスにどんなキーワードを足すと、どんな検索ができるのか、わかります。で、その完全ではないリスト。
- + （プラス）
「+語句」と指定することで、語句を必ず検索します。
「必ず」って、なんだよ！！and 検索じゃないのかよ！？でも、必ず検索してくれるようです。
- ""
空白を含む文などを、その通りに検索します。
日本語の場合、漢字とひらがなが混ざっていると、漢字とひらがなのところで単語を切って検索しやがります。「混ざる」だと、「混 ざる」になります。このため、「よくかき混ぜてから、ざるにあけます」も、ヒットしてしまいます。こういうのを防ぎます。
ただ、「"is 演算子"」とか、「"C#"」は、検索できないんじゃないかと思う。名前つけるとき、そういうことも考えてつけて欲しい…と、ふと思った。
- & （アンパサンド）
使用する必要はないはず。
- - （ハイフン）
この後に続けた語句は、検索結果から除外します。
MSDN ライブラリを検索すると、Windows API とともに Windows CE の API が検索されることがあります。こういうときに、「-CE」を指定すると、Windows CE の API は検索結果から外れます。
- |
「語句A | 語句B」と使用し、語句A、語句B のどちらかを含むものを検索します。
「デスクトップ」が、たまに「ディスクトップ」と書かれています。こういう場合、「デスクトップ | ディスクトップ」と検索すると、両方出てきます。
- ()
複数の語句をグループ化します。
モバイル関係もコンパクトフレームワークも検索対象から外したいときは、「-(モバイル コンパクト CE)」と指定します。
- AND （すべて大文字）
空白で区切る、「&」と一緒です。
- NOT （すべて大文字）
「-」と一緒です。
- OR （すべて大文字）
「|」と一緒です。
- feed:
「語句 feed:」と指定して、「語句」を含む RSS フィードや Atom フィードから検索します。
- filetype:
「語句 filetype:ファイルタイプ」と指定して、検索するファイルタイプを絞り込みます。.html, .txt, .pdf, .doc, .rtf, .xls, .ppt が指定可能です。
- hasfeed:
「語句 hasfeed:」と指定して、語句を含むフィードにリンクするページを検索します。
よ～わからん。ブログやニュースサイトのみが検索対象になるって事？
- inanchor:
「inanchor:語句」と指定して、ハイパーリンクの中に語句が含まれるページを、検索します。
これも、よ～わからん。「inanchor:jitta」としたら、「href="http～/jitta/～"」というリンクが含まれる場合のみ、対象になるのか？類似に「link:」がある。
- inbody:
「inbody:語句」と指定して、body 要素内に語句が含まれる文書を検索します。
SEO 対策などで、header 内に keyword で指定しているけれど本文にはその語句が含まれない場合は検索対象にしない、ってこと？そういえば、検索結果に対象語句が含まれていない場合があるのは、そういうこと？！
- intitle:
「intitle:語句」と指定して、title 要素に語句が含まれる文書を検索します。
- inurl:
「inurl:語句」と指定して、ページの URL に語句が含まれる文書を検索します。
- link:
「link:サイトまたはドメイン」と指定して、サイトまたはドメインへのリンクが含まれる文書を検索します。
- linkdomain:
「linkdomain:ドメイン」と指定して、ドメインへのリンクが含まれる文書を検索します。
- linkfromdomain:
「linkfromdomain:ドメイン」と指定します。「linkdomain:」とは逆に、ドメインからリンクが張られているサイトを検索します。
- site:
「site:サイトまたはディレクトリ」と指定して、指定したサイトまたはディレクトリのみから検索します。ディレクトリは2層まで指定できます。
と、ちょっと、MSDN ライブラリ...検索すると、旧ディレクトリからもわんさと検索結果が出てくる。そして、それをクリックすると、「旧 MSDN ライブラリの移行について」って出てくるよ。しかも、リダイレクトしてくれないよorz orz orz
検索条件に、「site:msdn.microsoft.com/ja-jp」を追加すれば、統合されたディレクトリからのみ検索してくれます。けど。そんなことはマイクロソフトがやってくれ！！
http://www.itmedia.co.jp/news/articles/0805/12/news084.html
Google、写真共有サービス「Hello」を終了。
すいません、Helloの存在自体知りませんでした。
恐らくその程度の知名度とユーザー数なんだろうなーとは思います。
なのでHelloが無くなろうが私自身は全く困りません。
が。
もし、万が一このHelloが日々の生活の中での重要なツールだったとしたら？
もし、Helloを使ったビジネスを展開していたとしたら？（もちろんそもそもこれらのツールはビジネス用途じゃないですよっと）
それが、急に「やめます」って言われたら？
こうした無料サービス（とか永遠のベータ版とか）は怖いです。とても。
Googleも企業として「ビジネス」を優先する権利がありますから、たとえばHelloが残り1ユーザーになるまでがんばります！とは言わなくても良いと思います。
たとえば「今月いっぱいでGmailサービスやめるよん」って言われても無料で利用中のユーザーは文句言えないわけです。
もちろん、お金を払って利用しているサービスであっても企業側の都合で突然中止、ということは十分考えられますし、実際にある話だと思います。
でも、Gmailが今終了されたら困るなー、とても困るなー、でも可能性が０じゃないからなーと考えていたら、散々言われていることですが「WEBの無料サービス」に依存しすぎるのは良くないのかなーと一考。
__END__っていうものがあることを先日知った。
知ったばっかりなので使いたくなるのが人情。
ということで使った！！
やっぱりRubyの用途は定型的なコードの自動生成が主なので、それ系になります。
今日使ったのは、あるフォルダの中にあるファイル名をもとにXMLを作るというものでした。
もっと具体的に言うと、あるフォルダ(javaのパッケージ)内にあるファイルをNetBeansのモジュールのlayer.xmlに登録するために<file name="...." url="nbresloc:/...." />を作るというものです。
使い捨てツールなので、さくっとね。
require 'erb'
# 一覧を取得したいフォルダのパス
PATH = "d:\\tmp"
list = Dir.chdir(PATH) do
Dir["*.*"]
end
template = ERB.new DATA.readlines.join, nil, "-"
template.run binding
# __END__の後にERBのテンプレートを書く
__END__
<%- list.each do |name| -%>
<file name="<%=name%>" url="nbresloc:/org/yourorghere/<%=name%> />"
<%- end -%>
__END__って書くと、そこでプログラムのファイルの終端を表すのと、DATAという特殊な変数を使って、__END__以降のデータを読んだりできる。
ということで、__END__以降にERBのテンプレートみたいなのを押し出すことが出来る。
ヒアドキュメントよりも楽チンかも。
帰阪してから初めて大阪の勉強会に参加させていただきました。
前の晩（というか、当日早朝？）に紅茶シフォンケーキを焼いて持っていきました。
生クリームは新鮮なものを使いたかったので、道具一式をもって現場でホイップいたしました。
# 緩めにホイップしたのは私の好みです。ソースとクリームの間っぽい感じにしました。
つけあわせに黄桃ひとかけらを添えました。
幸運にもゲットされた16名の皆様、お気に召しましたでしょうか？
実は、型から外すのに緊張のあまり失敗しまして、周りがたくさんこそげ落ちてしまいました。私はそのカスを頂いたのですが... ちょっとパサついてましたね...
しっとりシフォンが私の信条なので、正直失敗です。ごめんなさい。
今度リベンジします。
そもそも、スタッフの方へのねぎらいがメインの趣旨だったのですが、多くのスタッフの方が「お客さんに」と、遠慮されていました。
すばらすぃー！！えらい！！
希望者が多いようであれば、一人頭のサイズを半分にして、30人ぐらいに配れるようにしましょうか？
がしかし、7月以降は全日開催されるとのことなので、朝一はそないに集まらん可能性も...
アーリーバード特典として先着15名でよいのかしら？
さて、例によってセッション内容には触れず、メインイベントの懇親会から。
なーーーんども口を酸っぱ～～～くして言っておりますが、
わたくしとってもひとみしりんでございます。
懇親会でもどこに座ってよいやらドギマギドギマギ...
テーブルの端っこの方にちょこんと座りました（しかも、一つ空席を空けて... ごめんちゃい。よくよく考えれば隣の方にめっさ失礼ですよね。もちろん、のちに埋まりましたが... と、いうか、詰めて頂きました。）。
幸い斜め前に昨年大阪初参加したときにもお相手してくださった黒龍さんがいらっしゃったので、ちょっとホッとしました。
でも、みなさんにかまっていただけて、乗り切れましたわ。
# その時にあるお方から「関西？にあわなーい！」というコメントを頂いたのですが、大都会が似合うクールな洗練された大人に見えるってことでおけー？
数人の方からぢゃまさんの消息を聞かれましたが、いまだに行方知れずです。どこかでひっそりと段ボールハウスで暮らしているのではないかと推測されます。
えーぇ。あの髪形ぢゃあ全く違和感ありませんから。(^_-)
恒例のはずの自己紹介はトップだったのですが、「2次会はDDR大会で、3次会はおーるです。」と、振ってみたところ、20人近くが2次会へ...
が、しかし、実際にDDRをやったのは4人と、非常に申し訳なかったです。
# 移動する時に飲みチームと二手に分かれて後で合流という話もあったのですが、切り出すタイミングがなくなってしまって... ごめんなさい。
振り返ると、結局あまりお話ができなかったかもなので、2次会はふつーに飲みが良いかもしれないっすね。今度参加する時は2次会も取っときますか。
# 次回は残念ながら週またぎで東京出張の予定ですが...(T_T)
で、その後カラオケおーるだったのですが、その時点でも参加者13人。
# 一昔前は1次会でさぁーっと解散していたとはとても思えない参加率。これもひとえにわたくしの人とvbowrなにｦヴぃえpopiiiiiiiiiiiiiiiiiiiiiiiii
最初はひとつの部屋だったのですが、お店からのありがたいお申し出で、隣の部屋も使えることになりました。
そこで、禁煙／喫煙に分かれたのですが、禁煙チームがいつの間にやらネタ縛りになって行き、わたくし全くついていけずリタイヤしてしまいました... ごめんちゃい。
あのパワーはすごすぎます。
結局喫煙ふつー部屋に合流しました。
9人ぐらいが5時過ぎまで残り、花子さんをホテルまでお見送りした後に、最後は牛丼屋で朝飯食べて解散と相成りました。
大阪でお菜やみたいに勉強会と懇親会とを同じ場所で出来るところないもんですかねぇ。意外とゼクシィとか見るとそんな情報が得られたり...
# 今度立ち読みしてみよー。
なにはともあれ、関西の皆様。こんなやからですが、今後ともよろしくお願いします。
_(_^_)_
【業務連絡】
カラオケで発生した端数7,000円チョイをわんくまサーバー費として寄付いたします。
# あれ？なんだか計算合わんなぁ。一人頭420円×12（おひとりちょうどのお支払だったので）が寄付のはずなのに...
ちょっと、帰ってから確認します...
まとまりきらない&答えにならないグズグズなエントリ。
開発者であってもセキュリティ意識が低い場合が少なくない。
スケジュールに追われ、考えている余裕がないのかもしれない。
表に見えにくい部分でもあるしテストも難しいからかもしれない。
声高に言っても、現場まではなかなか伝わらない。
ほとんどの場合は、特別なスキルを要することなく、
ちょっとした手間と、常に意識することで回避することができるにもかかわらず。
大変なのは常に最新の動向を捉えておく必要があること。
今まで大丈夫だと思っていた実装方法が、
いつ何時「穴」になる可能性もあるかもしれない。
セキュリティ意識を持たせるにはどうしたらよいのか？
スピーカーの皆さん、スタッフの皆さん、チーム岡山の皆さんを始め、遠方から参加の方々もお疲れ様でしたー！
梅田の某百貨店バーゲン会場にてお目当ての商品を物色中に「花子さんが来阪している」という情報が入り、
急遽ドタ参加させていただきました。
●「ヒーローは突然に！？ Windows Server 2008参上！」 by ちゅき
セッションが延びていたおかげで、途中からちゅきさんのパフォーマンスを拝見することが出来ました。
予備校のカリスマ講師みたいで素敵でした。
●「自閉症.hack（自閉症って知ってるかい？）」 by Mr.T
技術系の勉強会ではとかく視野が狭くなりがちですが、そういう点でもこのセッションは有意義でした。
「自閉症の方との接し方」は大きな収穫でした。
●「Pythonを使ってみませんか？」 by ぴえろっち
ぴえろっちさんが、どんどんヘビちゃんに飲み込まれていく姿がとても微笑ましく、好感度抜群でした。
●「Visual Studio 2008 でいってみる？でもその前に・・・。」 by とりこびと
頑張ったとりこびとさんにねぎらいの言葉を掛けながら、皆さん会場をあとにされました。
●場外ハプニング
中さんに「上下不覚」という致命的なエラーが発生しました！
おかげで、懇親会会場を探す迷子くまーたちがビル中をウロウロ。
この後、懇親会が終わるまで中さんのエラーは復旧しませんでした。
◆最後に・・・
今年初めての勉強会参加でした。
以前は、スピーカーでもないのにやたら緊張していましたが、最近は、会場に入ると「懐かしい」と感じます。これって、もしかして、しみ込んじゃったのかしら？
次回、また楽しみにしております。
P.S ぜんぜん技術レポじゃなくてスミマセン。
ある日の出来事ですが、出来上がったコードが、今までに無いパターンだったので不思議に思った訳です。
こんなコードでした。
public class Base {
public void LoadData() {
using(var a = this.GetTableAdapter()) a.Fill(this.dataSet);
}
protected Func＜BaseTableAdapter＞ GetTableAdapter;
}
public class AAA : Base {
public AAA() {
this.GetTableAdapter = () => (new AAATableAdapter());
}
}
public class BBB : Base {
public BBB() {
this.GetTableAdapter = () => (new BBBTableAdapter());
}
}
で、妙に思って、よくよく見てみると、普段は以下のように書いていたコードなんだと思います。多分。
public class Base {
public void LoadData() {
using(var a = this.GetTableAdapter()) a.Fill(this.dataSet);
}
protected virtual BaseTableAdapter GetTableAdapter() {}
}
public class AAA : Base {
protected override BaseTableAdapter GetTableAdapter() { return new AAATableAdapter(); }
}
public class BBB : Base {
protected override BaseTableAdapter GetTableAdapter() { return new BBBTableAdapter(); }
}
ってことはアレですか、メソッドを
Override する場面ではラムダ式を使える
ってことになる訳ですか。そうですか。
今更ですか？
6000人で3300億円とか言ってたシステムhttp://www.asahi.com/national/update/0512/TKY200805120092.html?ref=rss
やはりどんだけ叩いてほこり出しておいても何かしら起こるものですよね、システム構築って。
いや、IBMさんが悪いとか言っているわけじゃなくて、単に完璧なシステムを作るっていうのはお金を積めるだけ積んでも難しいものなんだろうなーと。
恐らくですけど、超優秀なSEさんやプログラマーが集まっていると思うんです。銀行側だって、片手間で構築に携わっているわけじゃないと思うんです。現場は必死に忠実に仕事をしていると思うんです。
でも、不具合というのは無くならない（この例を見る限り）
色々な手法、色々な技術があり、毎年のように新しいものが出てきますが、「完璧ではない」から進歩していくんだろうなーと。
どこかで「このシステムだけは何も不具合なく動くと信じている」といった記事がありましたが、どこだったっけ・・・？
ということで、現場の方々がんばってください。
蔭ながらおーえんしています。
だって、引き落としとかできなくなったら困るもん。
