Webサーバは要求に対してシングルスレッドだった！！
ただしWebrickに限る（たぶん）
動かしてみた。
１．サーバ
↑ Aブラウザが要求
２．サーバ（Aの処理が長引いている）
↑ Aブラウザが応答まち
３．サーバ（Aの処理が長引いている）
↑ Aブラウザが応答まち
↑ Bブラウザが要求
４．サーバ（Aの処理が長引いている）
↑ Aブラウザが応答まち
↑ Bブラウザが要求受付まち
Aの要求を返さない限り、Bはずっと要求を受け付けてくれるのを待機してる。
たぶん、タイムアウトの設定はあるんだけど、使い物にならないよね！！！*1
対策として、以下の方法ができそう。*2
- ApatchServerを使う
- 噂のWebSocketに対応しているServerを使う
- Webサーバとアプリサーバを分ける
かけだしたプログラマは夢をみるか
アイデム エンジニアキャリアHacks共有プロジェクト
5年後の「エンジニアの働き方」は、どう変わっていてほしいですか？
つられてみました。
想定対象読者
- IT業界の業務の従事した期間が通算して１〜３年
- ＳＥっていってるけどプログラマ
自分の現状
- 従事期間は3年
- ＳＥっていってるけどプログラマ
- 地方勤務
プログラマという仕事にあこがれたというより、「ものづくり」に憧れたとき、一番自分に合っていそうだなあと思ったのがプログラマでした。
あんまり業界分析とかしないままこの業界に入ってきましたので、「自分にあってそうだなあ」というてきとーな印象でしかありません。
（まあそれでも3年続いてるので、てきとーな印象もなかなか間違っていなかったのかもしれません）
現実のぼくが見ている世界
従事期間3年程度の私が見渡す範囲というとこんな感じになります。
赤いところが見えてる範囲です。（もじ汚い！！！）
会社のなかの、自分のかかわっているプロジェクトの事と、そのプロジェクトにかかわってくるメンバーのこと。
この程度しか見えていない…と思います。
仕事に従事するなかで、得たことを社内ではアウトプットしていますが「プログラマ」として技術的なアウトプットは出来てないなーと実感しています。
大体業務に忙殺されて自己満足におわっちゃうんですよね。
今は社内に目標とする先輩がいらっしゃるのでがんばれますが…
もし先輩がいなくなったら目標を失ってやる気も落ちるんだろうなあ…
話がずれました。
エンジニアとしてどうありたいか
やっぱり「技術」を突き詰めたい！
なんでもしりたい！たのしみたい！
5年後であっても、自分の考え方は変わらないと思っています。
MercurialとSubversionの連携
Subversionで管理しているリポジトリをマスタとして、後は自分でローカルにbranch分けていろいろしたい！と思っていたので、表題についてはずっと憧れてた。
今回なんとか導入出来たので、その手順など。
環境は中央リポジトリはsvnでWindows2003、クライアントはWindows7。
参考：
HgSubversion
HgSubversionでMercurialとSubversionを連携させる
hgsubversionの導入
hgsubversionでFreeBSD svnをもってくる
だいたい↑のところを見ていたらなんとかなる。
連携のためにやること。
- Subversionのインストール
- Mercurialのインストール
- hgsubversionのインストール
- Mercurialファイルの設定
- svnのクローンを作ってリポジトリ
Subversionのインストール
TortoiseSVNではだめらしいので、Apatch Subversionの何かしらをダウンロード。コマンドを提供してないとだめ！らしい。
参考にしたHPのLinkをたどってmsiをダウンロード。
→今回ダウンロードしたバージョン（Setup-Subversion-1.6.6.msi）
Mercurialのインストール
これはTortoiseHgでよい。インストールされるし、パスも通る。
TortoiseHgをインストールしました。デフォルトまんま。
→バージョン：tortoisehg-2.2-hg-2.0-x86.msi
hgsubversionのインストール
MercurialとSubversionの連携に必要。
コマンドライン（コマンドプロンプト）でインストール。
# プロキシの場合で接続しているときは、プロキシをセット。 set http_proxy=XX.XX.XX.XX:ポート番号 # ダウンロードしたいディレクトリに移動後、ダウンロードのコマンドを実行。 hg clone http://bitbucket.org/durin42/hgsubversion # パラメタにインストールパス指定してもいいよ。 hg clone http://bitbucket.org/durin42/hgsubversion win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension abort: error: getaddrinfo failed
なんかエラーが出る。wikiを確認したら、Mercurialの環境設定ファイルに以下を追記しろとのこと。
[win32text] warn = False
メモ）
環境設定ファイルの場所はどうやら一定じゃないらしい。ダウンロードしたバージョンやOSによるのかも。
TortoiseHgは(Windows) %USERPROFILE%\Mercurial.iniにありました。
(Windows) %USERPROFILE%\.hgrc
(Windows) %USERPROFILE%\Mercurial.ini
(Windows) %HOME%\.hgrc
(Windows) %HOME%\Mercurial.ini
(Unix, Windows)
Configure your hgrc to enable the extension by adding the following lines:
Mercurial環境設定ファイルへ追記
ダウンロードしたhgsubversionへのパスを指定。
hgsubversionが二つ出来ているので、二つ目までをパスに指定。
[extensions] hgsubversion = (任意のダウンロードディレクトリ)/hgsubversion/hgsubversion
次！にsvnのための追記。
[extensions] rebase= svn=(任意のダウンロードディレクトリ)/hgsubversion/hgsubversion
これでsvn://に対してダウンロード（クローン？）が可能になる。
カスタムコントロールとユーザコントロールの違いって？？
C#で人が作ったのを改造してコントロールの拡張ライブラリを触った事は有るんだけど、１からってどうしたらいいの？dllって？のレベルなので調べようとしたら、タイトル。
以下はそれっぽいまとめ。
ユーザコントロール
ベースはフォームっぽい。
その上に標準コントロールをのせて、共通で良く使うコントロールの組み合わせ・メソッド・プロパティを共通部品として扱おう、という扱いみたい。
カスタムコントロール
標準コントロールを拡張し、共通部品にするかんじ？
例えば、テキストボックスに入力規制機能をつけてみたり。
*1
BindingSourceと単純なコントロールをバインドする
BindingSourceとしてTextBoxをはじめとするUI系コントロールとバインドした時に、入力値が誤っている場合にフォーカスが外れなくなる障害が発生した。その調査を行っていて気付いたこと、分かった事について以下にまとめる。*1
バインドした時に期待されるのがBindingSourceとControlの同期である。ここでの同期とは以下の事を指す。
- Adapterを介して取得したデータ情報がBindingSourceに格納されることでバインドを設定した項目情報がControlに描画を含めて反映される
- ユーザがControlに入力した情報がプログラムを記述することなく、BindingSourceに反映される。
同期の仕組は「変更通知」により実現している。BindingSourceとControlがそれぞれ変更を通知しあって値を設定・描画等を行っている。
ControlからBindingSourceへの変更通知のとき、Controlの情報を「検査」する。
「検査」結果がOKであればBindingSourceに格納します。NGの場合は処理をキャンセルする。
以下にフローチャートを記述する。
検査はバインドしているDBの項目に一致しているかどうかを検査する。
例えば、日付型の項目とバインドしている(Control)テキストボックスに0000/00/00を入力する。すると、結果がfalse（DBに設定することが出来ない値）と判断され、処理がキャンセルされる。
この処理を行っている時に発生するイベントをValidatingとValidatedという。
ValidatingとValidated
このイベントはLeave→Validating →Validatedの順番で発生する。コントロールがフォーカスを失って(Leave)、ユーザの入力を検査し(Validating)、検査後にBindingSourceに値を反映する(Validated)。もし検査が誤った場合、Validatingは「フォーカスを失う」処理をキャンセルし、Validatedは発生しない。
対応策案
ValidatingとValidatedのため、バインドしたコントロールはDB登録が不可能な値を設定した時にフォーカスが外れない、という障害が発生した。この症状に対応するには以下の方法が考えられる。
- Control.CausesValidation プロパティをFalseにする
CausesValidationは前述したValidatingとValidatedを抑止するプロパティである。これをFalseにすると検査と検査後の設定処理が行われなくなるため、「誤った値が設定されたとき」にフォーカスが外れなくなることはなくなる。
- 問題点
ValidatingとValidatedはControlの値を検査し、BindingSoruceに設定する動作を行っていたため、これを抑止するとControlとBindingSoruceの同期がとれなくなってしまう。
対応策として、バインドしているControlの値を直接BindingSoruceに設定する事が考えられるが、バインドの利点が無くなってしまう。
- Leaveイベント時に値を設定する。
Leaveイベント時にDB項目として矛盾しない値を設定すると、この問題は発生しなくなる。
- 問題点
自動的に値が設定されてしまうので、入力ユーザが意図しない値が登録されてしまう可能性がある。
そのため、以下の制御が考えられる。
- ユーザが分かりやすいように背景色を設定する（登録する・しないはユーザまかせ）
- 異常フラグ等を設定して、登録前に全項目をチェックし、その状態の時は登録を行わないようにする（システムで制御）
参考：
http://msdn.microsoft.com/ja-jp/library/xz45s2bh%28v=vs.85%29.aspx
http://msdn.microsoft.com/ja-jp/library/ms993236.aspx
*1:前に調べたものをdocにまとめてたんですけど、間違いとかありそうなので、こちらにアウトプット。
図で〜とか言ってるところは、wordで書いてたので省略。後から追記するかもしれません。
■
私利私欲でごめんなさい！
テスティングフレームワーク利用について
仕事関係でちょこちょこ調べていたんだけど調べた結果、プロジェクト内では使わないことになったのでテキストをコピペ。使い方というよりは概念よりですね。
このまとめは私見がありまくってるので注意してくださいー。
利点
- テストを自動化、さらにプログラム化することで手順を踏んで値を確認する必要が無い。
- 作成の手間はあるが、1度作成してしまえば再度テストする時の手間が省ける。
- 仕様変更が行われた場合、プログラムを修正したとき既存の処理に影響が無いか確認するテストが前回作成したものを一気に行えばいいので簡単。
- VB限定かもしれないが、デバッグのたびにビルドを行っている→その必要が無い。
- 複数パターンを前もって登録しておけば何度も入力操作をおこなう必要が無い。
- テストを作成して保持することができるので、入力に関してはどんなテストによってエラーが出たかを管理することが出来る
- （形として残る）
- 複数テストを行う場合、操作の手間が省ける。
- （細かくテストを作成しておけば、そのテストを組み合わせて順次実行していくテストも作成可能？確認していない）
- テストファーストの場合
- テストがどれだけ完了しているかで進捗管理につながる
- そうでないとべつにそうでもない。
- テストがどれだけ完了しているかで進捗管理につながる
- テストが厳密に行う事が出来る→品質の向上？
欠点
- そこまでする必要があるのか。
- 慣れるまで時間がかかる
- 複数パターンを試したい時、初めの作成が多少手間（CSVデータの作成かメソッドの複数作成）
- UIの動作確認は行えない。あくまでメソッドの中身。表示の確認は現行通り。
- テスト項目をきめていない、そこまで厳密に行っていないので必要かよくわからない。
- メソッドのパラメータ→結果調査くらいならオブジェクトテストベンチで十分。ほかのオブジェクトからデータを設定などする必要があるデータは設定が面倒（複雑）
