2008年11月のあいそるニュース
社員旅行
2008-11-28 18:48
先週の土日を利用してプロフェッサ社員一同で社員旅行に行ってきました。行き先は冬に入りますます寒さ厳しくなってきた北海道です。
飛行機に揺られ旭川に着いた時の気温は-4度。結構甘く見ていた私は手袋も持っていかなかったのでいきなり寒さの洗礼をくらいました。
上の写真はそんな寒さの中空気を読まず社員に向かって雪を投げつけた社長たちです。
本気でやり返していた我が部のプロジェクトリーダーがちょっと面白かったです。
その後バスに乗ること30分ほどで最初の目的地である旭山動物園に到着いたしました。
あいにくの雪でしたが、動物好きの人達は妙にテンションが高かったです。
動物園自体はさほど大きくは無かったのですが、レッサーパンダがつり橋を渡ったりと色々サービス してくれる工夫が人気の秘訣らしいです。期待通りのかわいい姿を見せてくれるのですが、あまりに空気を読む動物達は少し不自然で、中に人が入っているのでは、とか余計な事を考えてしまいました。
実は最も不自然だったのはヤギの鳴きまねをしていた我が社の社長なのですが、ここではあまり触れません。 少し触れるとするならば、本物のヤギよりもお客さんの目を引いていた事は確かでした。 そしてビックリするほど似てました。
一向は動物園を後に札幌市内へ。ホテルにチェックイン後キリンビール園にジンギスカンを食べに行きました。
ジンギスカンも期待を裏切らない味で皆大変満足でした。
そんなこんなで1日目は終わり、2日目は自由行動です。
我々のチーム人はこんなルートを行きました。
10:30 札幌駅のJRタワーへ！
11:30 札幌市内の食堂で海鮮丼を堪能
13:00 電車へ小樽へ行き、観光＋お土産を買い物
17:00 札幌へ戻り新千歳へ
楽しかった旅行もこれで終わりかなと思いきや、やはりハプニングはつき物なのか、新千歳では先輩が迷子になり 館内放送で呼んでもらう場面も。私も迷いそうでした。
帰りの飛行機は夜発だったので時折眼下に写る街の明かりが綺麗でした。
途中短い時間でしたが強い揺れが起こり、高所恐怖症の同期の社員が、その飛行機よりも大きく震えていたのが印象的でした。
北海道に比べると東京はまだ寒くないと感じつつ、たくさんのお土産を持ってみんな楽しそうに帰ってきました。 こういう息抜きがあると仕事もがんばれるのかなと思います。
Posted by A.S
メールサーバとMXレコード
2008-11-27 19:58
一つのドメインにはメールサーバを複数台存在させることが出来ます。 障害対策の為の冗長化や負荷分散など、メールサーバを複数台用意する理由は様々ですが、そのドメインに用意されているメールサーバがいくつなのかはWindowsのコマンドプロンプトで簡単に確認出来ます。
nslookupコマンドでMXレコードの確認
メールサーバはWindowsのコマンドプロンプトでnslookupコマンドを実行すれば確認できます。
nslookupとはDNSサーバから情報を取得するコマンドです。DNSサーバにはいくつかの情報が保持されていますがその中でメールサーバの情報を特にMXレコードと呼びます。（MXとはMail Exchangerの略です。）
具体的に以下の通りnslookupコマンドを実行すれば指定されたドメインのMXレコード情報が取得できます。
nslookup -type=mx ドメイン
※指定するのはドメインです。詳しくはドメインとFQDNという記事の図を御覧ください。
例えば「example.jp」というドメインのMXレコードをコマンドプロンプトで確認する場合は、以下のようにコマンドを実行します。
|
C:\> nslookup -type=mx example.jp ・・・・左記のように入力してEnterキー。 Server: fsr.example.jp Address: 192.168.1.1 Non-authoritative answer: example.jp MX preference = 10, mail exchanger = mail1.example.jp ・・・・① example.jp MX preference = 20, mail exchanger = mail2.example.jp ・・・・② example.jp nameserver = ns1.example.jp example.jp nameserver = ns2.example.jp mail1.example.jp internet address = 192.168.200.2 ・・・・・・・・・・・・・・・・・・③ mail2.example.jp internet address = 192.168.200.3 ・・・・・・・・・・・・・・・・・・④ ※実際にはexample.jpというドメインは存在しませんので、上記のようには表示されません。ご注意ください。 |
上記の①と②がMXレコードの情報です。
これは「example.jp」というドメインのメールサーバは①と②で表示されている通り２台存在し、そのメールサーバの名前はそれぞれ「mail1.example.jp 」と「mail2.example.jp 」であると表示されています。
また、③と④は正式にはAレコードと呼び、それぞれのメールサーバのＩＰアドレスが具体的に表示されています。 このように実際に身近に存在するドメインを入力すると、色々な結果が出てくると思います。
これらの情報はそのドメインのＤＮＳサーバ（コンテンツサーバ）に登録されている公開情報であり、 メール送信サーバが宛先のメールサーバに送信する際には、このMXレコードを取得して送るべきメールサーバのＩＰアドレスを取得しています。
preferenceによる優先順位
①と②の行を確認すると、preferenceという記述の後ろに数値が指定されています。
これはメール送信サーバが、まずはどこの宛先のメールサーバにメールを送信すべきかの優先順位となります。
ちなみにpreferenceが小さいほど優先順位は高くなります。
※preferenceは値自体に意味は無く、相対的な順序を定義するものです。よってドメインによってその値の大きさはまちまちです。
メール送信サーバは優先順位が高い（preferenceが小さい）サーバからメールを送信するルールとなっており、 仮に優先順位の高いメールサーバが故障してしまいメールが送信できなかった場合は、 次のメールサーバに送信するようになっています。
|
example.jp MX preference = 10, mail exchanger = mail1.example.jp ・・・・① example.jp MX preference = 20, mail exchanger = mail2.example.jp ・・・・② |
負荷分散・冗長化
大規模なメールサーバはMXレコードがいくつも定義されており、
且つそれらMXレコードのpreference値が同じになっている場合があります。
メール送信サーバはpreference値が同じサーバが複数存在した場合は、
基本的にランダムに一つを選んでメールを送信します。つまりここで負荷分散を行っています。
例えば、以下のようなMXレコードのドメインがあれば、まさにそのような狙いがあります。
※以下の例では、preferenceはすべて「10」という同じ値になっています。
|
example.jp MX preference = 10, mail exchanger = mail1.example.jp example.jp MX preference = 10, mail exchanger = mail2.example.jp example.jp MX preference = 10, mail exchanger = mail3.example.jp example.jp nameserver = ns1.example.jp example.jp nameserver = ns2.example.jp mail1.example.jp internet address = 192.168.200.1 mail1.example.jp internet address = 192.168.200.2 mail1.example.jp internet address = 192.168.200.3 mail2.example.jp internet address = 192.168.200.4 mail2.example.jp internet address = 192.168.200.5 mail2.example.jp internet address = 192.168.200.6 mail2.example.jp internet address = 192.168.200.7 mail2.example.jp internet address = 192.168.200.8 mail2.example.jp internet address = 192.168.200.9 |
preference値が全く同じMXレコードを定義するだけではなく、上記のように更にそこに定義されたサーバの同じ名前に複数のIPアドレスを定義することによって更に負荷分散をさせることができます。
上記の例では、例えば「mail1.example.jp」に対して3つのIPアドレスを定義しています。
一般的に負荷分散を行えば、同時に障害対策にも有効となります。yahooメールやhotmail等の非常に大規模なメールサーバは必ずこのような対応をしています。実際に、「yahoo.co.jp」ドメインで上記のnslookupコマンドを実行すれば一目瞭然でしょう。
補足
最近はこのpreferenceを利用して既存インフラを殆ど変更することなくスパムフィルターを設置してくれるサービスが存在します。
これに関連して2008年12月3日にMXレコードとスパムメールという記事も書きましたので、是非御覧ください。
Posted by T.S
SQLを外出しファイルにした場合の注意点
2008-11-26 04:54
SQLを外出しの設定ファイルにする理由
前回「SQLを外出しの設定ファイルにする理由」という記事を書きました。 この記事が多くの人に読まれているようですので、前回の記事で伝えきれなかった注意点を補足として述べたいと思います。
以下の内容は前回の記事の内容を理解していただいた方を前提として記述しております。 まだ御覧になってない方は、先にこちらをご確認いただければと思います。
SQLの共通を図ってはならない
SQL文字列をハードコーディングせずに設定ファイルに外出しする理由は先の記事で述べたとおりSQLコマンドインジェクション対策です。
SQLの共通化が目的ではありません。逆にSQLの共通化はやってはならないといつも社内の開発者には言っています。
具体的には下図の左のようなSQLの共通化はＮＧです。 SQLはソースコードの一部と考えるべきです。仕様が変更された場合はSQLも変更になる可能性が高いものです。 よって下図の右のように分離したSQLはソースコードと一対一にすべきです。
下図の左のような共通化をしてしまうと、仕様変更でSQLを変更することになった場合、そのSQLの依存に足を引っ張られて他のソースコードにまで影響を及ぼしてしまい、全体的にメンテナンスがし難いアプリケーションとなってしまいます。
弊社のフレームワークのSQLの定義ファイルにはそのSQLを特定するidを記述するのですが、idの命名規約はクラス名+連番ということにしています。 つまり複数のクラスからSQLを共通的に使用出来ない命名規約にしています。
共通化を図るのであればSQLではなくソースコードの共通化を検討する
仮にあまりにも同じSQLをいくつも定義していることに気づいた場合は、 それはSQLを共通化するのではなくソースコードそのものを共通化して切り出すことを検討すべきです。 具体的には下図のような考え方になります。
以上となりますが、そもそもにSQL文字列をハードコーディングせずに設定ファイルに外出しするのは、 大量にSQLを扱う大規模アプリケーション開発に有効なものです。
先の記事でも述べたとおり、 弊社のフレームワークでは開発者に対してSQLとソースコードを分離することを強いる仕組みになっており、 弊社のフレームワークを使用しているWebアプリケーションは必ずSQLコマンドインジェクション対策がなされていると保障が出来ます。
逆に小規模なWebアプリケーションの場合は、注意してSQLコマンドインジェクション対策を徹底すればよいだけですので わざわざSQLとソースコードを分離するメリットは少ないと思います。
Posted by T.S
UPSの交換作業
2008-11-22 13:38
弊社のサーバ群で、ファイルサーバやActive Directoryサーバ等の重要情報を管理しているサーバはUPS(無停電電源装置)を使用しています。今までのUPSは寿命を大幅に超えて使用していたので、新しく右図のオムロンBU100RWを購入して交換作業を行いました。
設置作業をするには社内の重要サーバの電源を一旦落とすので、 社員が帰宅する業務後になるのを待って私ともう一人の担当者の２人で細々と作業しました。
UPSは重たいのでラックの一番下に配置するとして、まずはレールをラックに固定しました。
サーバラックに固定するネジ受けはケージナットといい、一般的にはM5とM6の2種類の規格があります。
M5とM6は見た目はそっくりですがナットに小さく書かれていますので分からなくなったら確認出来ます。
具体的にはネジの太さが違うようです。
私は今までもサーバのラックを相手に何度も格闘したことがあるのでその辺は心得ています。
というわけで、上図のようにレールをラックに固定しました。このレールの固定は結構てこずりました。 M5とM6を間違えるなよと、もう一人の担当者に偉そうにいっておきながら、私が間違えました。 アセアセしながらケージナットを付け直して、左下図のようにようやくレールが付きました。
以下はレールをつけ終えた２人の会話です。
T.S.：「いや～、やっとレール付いたね。」
A.T.：「やりましたね。てゆうかこのレール要るんですかね？」
T.S.：「必要に決まってるじゃん。これが無いと、UPSが下に落ちるよ。」
A.T.：「でもこのラックって下に既に棚板ありますよ。」
T.S.：「ほほぅ」
そんな小競り合いがありつつ実際に右上図の通りUPSをラックに載せてみたら、やはりレールの意味があまりありませんでした。
※サーバとレールがネジで固定されて、そのまま手前にスライドできるレールが多いですが、これはそのタイプではありませんでした。
気を取り直して、そのまま最後にナットでUPSを固定して設置作業は完了しました。
その後は動作テストを繰り返していたら終電になってしまいましたが、なんとか交換作業が完了しました。
これで急な停電にも安心です。
Posted by T.S
ネガティブキャッシュ
2008-11-19 07:53
システムの世界で「キャッシュ」とは一時的にデータを蓄えておくことです。ブラウザのキャッシュは身近な例です。
システム開発者であれば更新頻度が少なく、且つ使用頻度の多いマスタデータや設定情報をキャッシュするのはよくあることで、 開発したシステムのパフォーマンスを上げるためのテクニックとして多用されています。
ＤＮＳサーバに関して学んだ際に、「ネガティブキャッシュ」を知ったときには感心した記憶があります。
ＤＮＳサーバの「キャッシュ」とは、一般的な考えと同様に「○○の結果はＸＸだ」という情報を一旦保持しておくものですが、
「ネガティブキャッシュ」とは「○○の結果は無かった」という情報を保持しておくものです。
具体的に説明しますと、そもそもＤＮＳサーバはブラウザに入力された文字列をＩＰアドレスに変換する作業を担ったサーバですが、
仮に間違ったＵＲＬが入力された場合、ＤＮＳサーバはＩＰアドレスに変換できません。
その場合、ブラウザには「このページは表示できません」といったような内容が表示されます。
しかしそうなるとユーザーは概して何度もやり直しをするものであり、
これが繰り返されるとＤＮＳサーバに余計な負荷がかかります。
その負荷を防ぐ為に一度失敗した内容は、しばらくはキャッシュしておくのがネガティブキャッシュです。
これはある意味、逆転の発想だと思って感心したわけです。
正しい結果だけではなく、データが無かった（取得に失敗した）という結果をキャッシュしておく発想は、
私はなかなか思いつきにくいものでした。
そんな小さな感心をした際に、今後非常に検索に時間のかかるオンラインシステムを開発する機会があり
検索結果をキャッシュしておく仕様になったとしたら、
その時は検索の結果でヒットしなかったという情報もキャッシュしてみようなんて思ってました。
※結局そのようなシステムを開発する機会はありませんでした。残念。
余談ですが、このネガティブキャッシュの考え方を実生活のどこかで適用できないかなとアレコレ考えた事があったのですが、 その一つが電話帳でした。
仮にＤＮＳサーバを電話帳に例えると、下表の山田太郎の情報はキャッシュで山田次郎の情報はネガティブキャッシュになるというわけですな。 （まぁ現実的には有り得ない話です。。。）
| 名前 | 電話番号 |
|---|---|
| 山田太郎 | 03-5789-xxxx |
| 山田次郎 | 電話は引いていません |
Posted by T.S
Excelによるドキュメント
2008-11-17 01:19
IT業界ではExcelによる設計書等のドキュメントは非常に多いです。
実際私も表計算ソフトとしてではなく設計書のエディタとしてExcelを使用することが殆どです。
また様々な現場を見てきましたが、少なくとも私が経験したプロジェクトの現場ではExcelによる設計書が大部分を占めていました。
※ドキュメントの種類によってはWordやVisioが標準となっている現場も幾つかありました。
弊社でもドキュメントの大部分がExcelです。 気になって実際にドキュメント成果物を確認してみました。 弊社のあるプロジェクトでは、納品するドキュメント成果物は全３２種類ありましたが そのうち２８種類がExcel、２種類がWord、残り１種類がHTMLでした。圧倒的にExcelが多いです。
ネットで検索してみるとIT業界でのExcel設計書に触れた内容の書き込みや記事を目にすることが出来ます。
意外だったのは、ネット上では以外とExcel反対派が多い印象を受けました。
※主にExcelに反対している人がその事を書き込むからかもしれません。
設計書等のドキュメントは自社で使うだけではなくユーザが確認するものですので、専用のソフトが必要な形式よりは、 Office製品の方が無難だという選択に異論はありません。 またOffice製品であればMicrosoftが存在している限り、長期に渡ってサポートされる形式だというのも 企業システムのドキュメント標準として重宝される理由の一つだと思います。
Web制作会社などではたまにPowerPointで設計書が記述されているのを見かけたことがありますが、 大規模な開発プロジェクトの現場ではあまり見かけません。 個人的にPowerPointを否定する理由は私はあまり思いつかないのですが、 PowerPointはプレゼンテーション用という印象が強くて、開発者は使用経験が少ないので好まれないのかもしれません。
ネット上での多くの意見と同様に、私もExcelに適したドキュメントとWordに適したドキュメントは それぞれ違うと思います。基本的に、文章を主としたドキュメントは当然Wordが適しており 弊社も計画書や報告書及びオペレーションマニュアルの類はWordで納品します。
Excelに適しているドキュメントとWordに適しているドキュメントを分類すると下記のようになるようです。
Excelに適しているドキュメント
- 一覧表
- マトリックス図（設計資料やテストケース等）
- クラス図、シーケンス図、ＥＲ図などといったダイアグラム
Wordに適しているドキュメント
- 報告書
- マニュアル
結局、Excelは印刷するときにはみ出たりして色々と不便なところもありますが、
守備範囲が非常に広く設計書として未だにこれを越える形式が無いというのが現実です。
MicrosoftのVisioは悪くないのですが、ダイアグラム（図面）の作成に特化している気がします。
もっと文章も含んだ設計書全般をカバーする汎用的な製品が欲しいものです。
個人的にはOffice製品の一部として、「Microsoft Design」みたいな感じでIT業界の設計書の記述に特化した 製品を出してもらえば、絶対使います。
Excelでよく使用するショートカットキー
最後に、システム開発の設計工程では作業時間の大半はExcelを使用しますので、
極力キーボードから手を離さずに（マウスを使わないように）作業するクセの中で
私は以下のショートカットキーをよく使用します。
ちなみに、実際はマウスを使ったほうが早いと思われるような作業も、
私は意地になってマウスを使わずに作業したりしています。
| [Ctrl] + [O] | ファイルを開く |
|---|---|
| [Ctrl] + [N] | 新しいブックの作成 |
| [Ctrl] + [W] | ブックを閉じる |
| [Ctrl] + [F6] | 複数ブックを開いている場合のブックの切り替え |
| [PageUp]/[PageDown] | シートの切り替え |
| [Ctrl] + [-] | 削除 |
| [Ctrl] + [Shift] + [+] | セルの挿入 |
| [Ctrl] + [1] | セルの書式設定 |
| [Ctrl] + [Y] | 直前の操作を繰り返す |
| [Ctrl] + [Z] | 直前の操作を取り消す |
| [F2] | 編集モードへ切り替え |
| [Shift] + [F10] | 右クリック |
Posted by T.S
テキストファイルとバイナリファイル
2008-11-14 00:07
「テキストファイル」とか「バイナリファイル」とかいう言葉を聞いたことがあると思いますがそれぞれどういう意味で何が違うのでしょうか。
簡単に言うと、テキストファイルは文字データのみで構成されたファイルで、バイナリファイルは文字以外のデータが含まれているファイルということになります。実際にメモ帳等のテキストエディタで開けばよく分かります。
見分ける方法として、上図の通りテキストエディタで対象のファイルを開き、文字化けしなければそれはテキストファイルで文字化けしたらそれはバイナリファイルと考えてほぼ間違えありません。
バイナリの原義は「2進数の」という意味です。だからバイナリファイルは2進数で構成されているファイルということでなんとなく理解できます。 しかしそれじゃテキストファイルは2進数じゃないのか、という妙な疑問が湧いている方がいるかもしれませんので 今回はこの「テキストファイル」と「バイナリファイル」の違いにこだわって分かりやすく解説したいと思います。
まず、結論から言うとコンピュータに保存される全てのファイルは必ず0か1の2進数で構成されています。それはバイナリファイルだろうとテキストファイルだろうと同じです。 テキストエディタではなく、バイナリエディタと呼ばれるツールでファイルを開けばそれが明確に分かります。
上図はバイナリエディタで開いたテキストファイルとバイナリファイルです。
上記で述べたとおりどちらのファイルも0か1の2進数で構成されていることが分かります。
※上図のバイナリエディタは、2進数ではなく分かりやすく16進数で表示されています。
どちらのファイルも2進数で構成されているのに、テキストファイルとバイナリファイルの違いはなんなのでしょうか？
という事で、もう少し具体的な例を挙げましょう。
「文字コード」という言葉を聞いた事があると思います。
「文字コード」に関して厳密に説明するとまた奥深い話になってしまいますので割愛しますが、
コンピュータで文字を扱う為に文字一つ一つに数値が割り当てられており、それらの一連のルールを「文字コード」言います。
先に述べたようにコンピュータが扱う全てのデータは必ず0か1の2進数で構成される数値ですので、
文字をデータとして保存するにもその一文字一文字を数値で保存しているわけです。
有名な文字コードのASCIIを例にとって説明します。 ASCII文字のコード体系では、半角大文字のアルファベットABCのそれぞれの数値は左下表の通りとなります。16進数で、Aは41、Bは42、Cは43です。 このアルファベットABCを表す16進数の数値を右下図の通り実際にバイナリエディタに入力して保存します。
バイナリエディタで保存したファイルをメモ帳で開くと、右図の通り「ABC」という文字になって表示されます。
つまり実際には数値としてコンピュータに保存されているファイルは、バイナリエディタで開くとそのままですが、
テキストエディタで開くと、人間に分かりやすく文字に変換して表示してくれると言うわけです。
上記の例を踏まえてテキストファイルとバイナリファイルは何が違うのかというと、 テキストファイルもバイナリファイルと同様に2進数で構成されているが、 そのデータが文字を表す数値「だけ」で構成されているもの を特にテキストファイルと呼んでいるのです。
何度も言うようにコンピュータに保存されている全てのデータ（ファイル）はバイナリです。
データに着目して考えると、考え様によってはコンピュータが扱う全てのファイルはバイナリファイルと呼び、
その中でデータが文字を表す数値だけで構成されているものをテキストファイルと呼ぶことが出来るかもしれません。
つまり右図の様に、バイナリファイルはテキストファイルを内包するという関係も考えられるわけです。
FTPを使用したことがある方はご存知かとは思いますが、FTPにはアスキーモードとバイナリモードがあります。
左図の有名なFTPツールのFFFTPにも当然アスキーモードとバイナリモードを変更できる機能があります。 これらのモードの違いを簡単に言うと、テキストファイルを転送する為のモードがアスキーモードで、バイナリファイルを転送する為のモードがバイナリモードとなります。
バイナリファイルは必ずバイナリモードで転送する必要がありますが、テキストファイルは必ずアスキーモードで転送しなければならないかと言えばそうではありません。上図の通り、テキストファイルはバイナリファイルに含まれるからです。
ではどういう時にアスキーモードの転送が役に立つかといいますと、改行コードを自動的に変換してくれるのです。 ご存知の方は多いと思いますが、環境によって改行コードは異なります。例えばLinuxとWindowsでは改行コードは違います。 バイナリモードでアップロードすると改行コードの変換はしてくれませんが、 アスキーモードでテキストファイルを転送した場合は環境に応じて改行コードの変換を自動的にしてくれるのです。 これが場合によっては便利というわけです。
補足
尚、説明の過程として上記の通りバイナリファイルはテキストファイルを内包する、つまりテキストファイルはバイナリファイルの一部と申し上げましたが、この言い方や上記の図は一般的ではありません。 バイナリというデータに着目するとこのように考えることは出来ますが、 一般的にはテキストファイルは文字データだけで構成されたファイルを指し、テキストファイルを除く「それ以外」のファイルをバイナリファイルと呼びますのでご注意ください。
Posted by T.S
電車内でのノートＰＣ
2008-11-12 08:26
この間の話です。
私は空いていたので電車のシルバーシートに座っていました。
何駅か通過して、そのシルバーシートに営業マン風の若いビジネスマンと老婦人も座ってきました。
若いビジネスマンは、座るとすぐにノートＰＣ（Let's noteだった）を開いてカタカタと操作を始めました。
ほほぅ、忙しいんだなと私は隣でうなずいてました。
ところが、その隣に座っていた老婦人が、その若いビジネスマンに注意をしたのです。
「ここは仕事をする場所じゃ無い」とゆっくりと強い口調で怒っていました。
若いビジネスマンは、一瞬「何で？」という顔をしながらも、渋々と席を立ち
車両の端に移動して、ノートＰＣへの作業を続けてました。
※ああ、とりあえず仕事は続けるんだ。忙しいのね、と内心思いました。
正直言うと、私もその若いビジネスマンと同じで「何でダメなの？」と思いました。
私も混んでなければ電車内の椅子に座ってノートＰＣを操作する事があるからです。
満員電車でも無いのに、この状況でなぜノートＰＣはダメなのかと悩んでしまいました。
シルバーシートだからダメなのか、微弱な電磁波を発するからか、とも思いましたが
「ここは仕事をする場所じゃない」という老婦人の言葉と口調は、合理的な理由がある訳ではなく
根本的に電車内でノートＰＣを操作するな、と言っていると感じました。
※ちなみに「仕事をする場所じゃない」ということであれば、ノートＰＣでゲームをやっていたら仕事じゃないからＯＫかな？ と思ってしまうのは私がヒネクレているからでしょう。
世代や価値観の違いはあると思いますが、公共の場ではそれを不快と感じる人がいる以上、
その人に対して配慮する必要があると思います。
少なくとも今回の件で、私は車内が混んでいなくとも電車でノートＰＣを操作することに対して不快に感じる人がいると初めて気づきました。
今後は自分も気をつけようと思いました。
一昔前は携帯電話のマナーに関してよく話題に上がりましたが、
最近はポータブルゲーム機の電車内での利用マナーが問題になっていると聞いたことがあります。
電子機器などはますます小型化されいつでも何処でも利用できる時代になりましたが、
このような進化が早いモノに対しては、それに対するマナーも変化が早いように感じます。
実際、携帯電話の電車内でのマナーは、携帯電話が普及してすぐの時代は電源をOFFにしましょうと言われてきましたが
様々な理由で最近はシルバーシートの周りでは電源OFFでそれ以外はマナーモードにしましょうと軌道修正されているようです。
今回の電車内でのノートＰＣの使用に関しても、仮に全く同じ状況だとしても１０年後の老婦人はまた見方が変わっている気がします。
Posted by T.S
SQLを外出しの設定ファイルにする理由
2008-11-10 08:04
SQL文字列をハードコーディングせずに設定ファイルに外出しにしているシステムをよく見かけます。 弊社が独自に開発して使用しているWebフレームワーク及びバッチフレームワークでも同様にSQL文字列をソースコードと分離させて、SQLはXML形式の設定ファイルに記述するようになっています。
SQLとプログラムソースを分離させる理由は、開発者によって意図がそれぞれあると思いますが、 少なくとも弊社のフレームワークで言うと理由は下記の３つです。
- SQLコマンドインジェクション対策
- SQLの可読性・メンテナンスビリティの向上
- SQLの一括調査対応
SQLコマンドインジェクション対策
SQLとソースコードを分離させる主目的はSQLコマンドインジェクション対策の徹底です。 上記に３つ理由を挙げましたが、主目的はこれで残り２つは副次的なメリットになります。
弊社のフレームワークでSQLを実行するには、まず右図のようなXMLファイルに定義します。
通常SQLを実行する場合、条件の値はその時々によって変わりますのでその変数の部分を「?」で記述しておき、
パラメータとして値を渡すとフレームワークはＤＢにSQLを実行し結果を返す仕組みになっています（下図参照）。
外部から渡されたパラメータをSQL文字列の一部とする際には、
必ずエスケープしなければならないというのが、SQLコマンドインジェクション対策のセオリーです。
弊社のフレームワークでは下図のような仕組みとなっており、①で設定したパラメータをフレームワーク側でエスケープしています。
※弊社のフレームワークはJavaで出来ており、内部的にはこの仕組みはPreparedStatementを使用しています。
SQL定義ファイルに定義された変数の部分を変換するには必ずフレームワークにパラメータを渡す必要があり、
フレームワークはクライアントから渡されたパラメータを必ずエスケープします。
つまり弊社のフレームワークを使っている限り、
プログラマがうっかりSQLコマンドインジェクション対策をし忘れるということがありません。
静的なSQL文とパラメータを分離することにより、フレームワークは例外なく外部から渡されたパラメータをエスケープできるのです。
これがSQL文字列とソースコードを分離する理由です。
しかし、この方式には一つ問題があります。
事前にSQL文字列として定義しておくには、非常に開発工数を要する場合があります。
例えば右図のように複雑な検索条件を指定出来る画面の場合、事前に全ての検索パターンのSQL文字列を定義ファイルに定義しておくことは困難です。
通常は入力された条件を基に動的にプログラムでSQLの検索文を生成します。
そのようなケースを考慮し、例外として弊社のフレームワークは動的に生成したSQL文字列を実行できる仕組みが用意されています。 このメソッドは推奨されないメソッドとして定義されており、必ず第三者によるソースコードレビューをするという運用にして SQLコマンドインジェクション対策漏れを防止するようにしています。
基本的にはSQLコマンドインジェクションは、オンラインから悪意のあるユーザがパラメータを入力する為、 オンラインのWebアプリのみ必要なもので、バッチ処理には不要と考えていました。 実際、弊社のバッチフレームワークの初期のものはオンラインと異なりSQLは定義ファイルではなくソースコードに埋め込んでいました。
しかし、バッチ処理だからSQLコマンドインジェクションによる事故は絶対に発生しないとは言い切れず、 また弊社のWebフレームワークとバッチフレームワークに互換性を持たせるように改良された為、 現在は弊社のバッチフレームワークもSQLは外出しの設定ファイルに記述するようになっています。
SQLの可読性・メンテナンスビリティの向上
SQL文字列を設定ファイルに外出しにする事で、SQLの可読性が向上しメンテナンスしやすくなるという副次的な効果があります。
左上図の通りSQL文字列をソースコードに含めると"+"演算子で文字列を連結する必要があります。
このようにソースコードに記述されているSQLをSQL*Plus等のツールを使用して直接データベースに実行したい場合は
この演算子やダブルクォーテーションを取り除く必要があり面倒です。
定義ファイルに記述されていれば、ほぼそのままコピー＆ペーストで使用できます。
逆に開発する際にも、定義ファイルであればSQL*Plus等のツールで作ったSQL文字列をそのまま貼り付けるだけで
JavaのStringに変換する必要がありません。
SQLの一括調査対応
SQLを外出しの設定ファイルにする理由として、これを一番の理由に挙げる開発者がいます。
つまり、後からSQLだけを一括して調査しやすくしたり、また万が一データベースのテーブル名が変更された場合等も一つのファイルだけを一括置換するだけでよいからというものです。
確かに過去のテスト工程で、あるSQLの結合文が好ましくないことが発覚し同様のSQL文が無いか一斉に調査した事がありました。
この時はSQL文が外出しのファイルで一元管理されていてなかなか便利だ感じことがあります。
しかし、スキルの低い開発者が多いプロジェクトならともかく、
私たちの現場ではこのようにSQLだけを一括して調査するケースはそう滅多にあることではありません。
データベースのテーブル名が変更されるなんてことも滅多にありません。そんなことされたら一大事です。
というわけで３つ挙げた目的のうち、後の２つはこじつけがましいと思われるかもしれませんが、 ここまで書いて私も若干こじつけがましいと思いました。
補足
この記事の続きとして、2008年11月26日にSQLを外出しファイルにした場合の注意点という記事も書きました。SQLとソースコードを分離する際の注意点を記述しておりますので、是非御覧ください。
Posted by T.S
失敗しない要件定義
2008-11-07 08:24
私たちは多数の大規模システム開発を経験しており、失敗も数多く経験しております。 特に要件定義はお客様の協力が必要であり、様々なお客様に合わせて対応を変える必要があるので難しい工程です。
要件定義とは
そもそも要件定義とは、ユーザからの要求をどのようにシステム化するかをユーザとベンダーが協力して定義する作業の事です。
要件はユーザが出すものと決め付けているベンダーも見受けられますが、ユーザが出すのはリクエストであって
それをどのようにシステム化するかを検討・整理し、要件定義書にまとめるのはベンダーの作業となります。
また、単にユーザのリクエストを聞き入れるだけではなく、ユーザの業務を全て理解した上でその裏に存在する
潜在的な問題を見つけ出し、システム化による解決策を提案することが真のベンダーの役割だと思います。
そのような難しい要件定義ですが、私たちが失敗しないように特に心がけている事を以下にいくつかご紹介します。
1) 要件定義から技術的なリスクも検討する
要件定義工程では技術的なリスクも散在しており、業務知識を有したＳＥだけが参加すればよいというものではありません。
弊社の特徴でも申し上げている通り、
私たちは新規システム開発の要件定義には基盤ＳＥも参加しています。
これにより、要件定義工程でも技術的な問題、パフォーマンスの問題、インフラの問題等、様々なリスクを早期に発見することが出来ます。
2) 早期に最終的な画面イメージに近いものを作成する
開発システムの規模によもよりますが、弊社にはWebデザイナーも在籍しており、基本的には新規に開発するシステムは 要件定義や外部設計の時点で最終的な画面イメージに近いものをユーザに提供しています。
初期段階では紙ベースで進めても問題ないと思われるユーザインタフェースですが、
実は画面イメージは重要で、本物に近い画面が相手だとエンドユーザは実際の業務がイメージし易くなり、より本気になって検討して頂けます。
※ちなみに要件定義の段階で全ての画面イメージを作ることは出来ません。全ての画面イメージをそろえるのは外部設計工程であり要件定義時はその一部を使用します。
紙やExcelベースだと、根本的な仕様であっても後から変更できるだろうという意識が働いてしまい、 初期段階ではあまり真剣に検討して頂けず、終盤の工程で多数の変更要望が発生する場合が多くあった為、 初期検討段階からなるべく最終的なイメージに近い画面を作成し、ユーザにご確認頂いております。 早期に最終的な画面を提出することに関しては手間もかかり賛否はありますが、弊社は経験的に この方が最終的なリスクが少ないと判断しています。
3) 出来ない事は出来ないと伝える
ユーザの要求を全て受け入れるわけにはいかない場合があります。
技術的に実現困難なケース、私たちのスキルを大幅に越えているケース、明らかに納期に間に合わないケース等様々ですが、このような場合はユーザに出来ませんと正確に伝える必要があります。また、後述の通りそのような事を躊躇わずに言える関係になる事が重要です。
無論、出来ない出来ないというだけでは能がありません。代替案をユーザに提示することが望ましいことです。
これらは非常に当たり前のことですが、実際明らかに納期に間に合わない仕事を出来ると言い張って弊社から仕事を奪い去り、 そして大失敗をしたプロジェクトを弊社は目の当たりにした事があります。
4) 早期にユーザと円滑なコミュニケーションが取れる関係を築く
当たり前過ぎる事ですが、ユーザとの関係は非常に重要です。
要件定義工程はプロジェクトの初期の工程であり、ユーザとのコミュニケーションも遠慮がちになってしまいますが、 実は最もユーザとのコミュニケーションが重要な工程と言えます。
要件定義工程で腹を割って本音でコミュニケーションが取れれば、ユーザの業務の理解が進み業務の改善ポイントや、
より良いシステム化のヒントを得るチャンスがその分増えます。
私たちは早期にユーザと円滑なコミュニケーションが取れるように心がけております。
以上の通りいくつかポイントを挙げましたが、要件定義は他の工程と異なり基本的には人間のみを相手にするので、 言うまでもなくヒューマンスキル、特に高いコミュニケーション能力が必要です。
また、コミュニケーション能力だけでなく要件定義時にはユーザの言葉の意味が理解できなければなりません。 例えば保険システムを構築する要件定義の場合は、最低限保険業務に関する専門知識が無ければ会話がスムーズに進まず、 必要以上に要件定義工程に時間がかかってしまいます。
私たちはいかなる保険業務システム開発にも対応できるように、
常に議論が活発な現場でコミュニケーション能力を磨き、また保険業務に関する勉強会を開く等して、保険業務知識の向上に力を入れております。
これにより私たちＩＴソリューション部は、高いコミュニケーション能力を持ったエンジニアが大半を占めており
また保険業務に関する高い専門知識を有したＳＥが多数在籍おります。
Posted by T.S
よく使うデザインパターンとは
2008-11-05 08:47
GoFによるデザインパターンはオブジェクト指向の学習教材としては非常に有効だと思いますが、 実際の業務アプリケーションの開発現場ではどのくらい使用されているのでしょうか。
私自身、デザインパターンを使うことでレベルの高いソースコードだと思われたいという、 あまりにも稚拙な理由でよく使っていた時期もありました。誰もが陥りやすい若さゆえの過ちです。
今はGoFのデザインパターン以外にも、たくさんのパターンが存在しているようですが、 少なくとも私の経験の中でGoFの23のパターンのうち、今でもよく使うものを選んでみました。
私はJavaによる業務Webアプリケーション及びそのフレームワークの開発者なので、制御系のシステム開発は経験がありません。 それ故、使用するパターンが業務Webアプリケーション開発向けに偏っていると思います。 あくまでも私（筆者）の独断と偏見ですのでご了承ください。
よく使う
- Template Methodパターン
- Iteratorパターン
- Singletonパターン
- Flyweightパターン
たまに使う
- Observerパターン
- Proxyパターン
見栄を張らずに言うと、未だによく使う・たまに使うパターンは上記の６種類くらいです。 どれもこれもデザインパターンの初級レベルのものばかりです。
Template Method パターン
私がフレームワークを開発する際には、フレームワークとビジネスロジックとの関係は必ずこのパターンを使用します。 StrutsのActionクラスもこのパターンを適用していますので、よく見かけるパターンだと思います。
場合によっては私はサブクラスが実装すべきスーパークラスのメソッドをabstractにしない場合があります。
こうすることにより、スーパークラスにデフォルトの振る舞いを記述できるからです。
例えば、右図のようにスーパークラスにmethod1,method2,method3が定義されており、 それぞれデフォルトの振る舞いが記述されていれば、サブクラスではデフォルトの振る舞いと異なるメソッドのみ オーバーライドすればよいことになります。
具体的な例を挙げますと、業務アプリケーションで様々な形式のデータファイルを読み込ませる機能があったとします。 ファイルの読み込みは基本的には似たような処理が多いですが、ファイルの形式によって部分的に異なる所もあります。 このような場合は、サブクラスにてデフォルトと異なる部分のみをオーバーライドでカスタマイズすることにより対応できるわけです。
Iterator パターン
ある共通メソッドの戻り値として複数の値を順番付きで返す必要がある場合、Listを使うのが最もシンプルだと思います。 無理してIteratorパターンを使用する必要はありません。
しかし、例えばその戻り値のListの要素が数万～数十万件になる可能性がある場合はListで返すとなると
それだけ要素となるオブジェクトのインスタンスを一気に生成することになりますので、
メモリが溢れる(Out Of Memroy)可能性があります。
そのような場合はIteratorパターンを使用し、次の要素が要求される度にその都度インスタンスを生成するようにします。
また、戻り値の要素１つ生成するのに非常に時間がかかる場合で、且つその戻り値を利用するクライアントは 各要素を一気に使用しない場合も、Iteratorパターンが効果的だと思います。
Singleton パターン
Javaの場合、教科書通りgetInstance()メソッドにsynchronizedを使用して記述しているコードを たまに見かけますが、synchronizedはコストが高いのでstatic変数を定義してそれを利用するのが最もシンプルだと思います。
ただしsynchronizedを使用しないとした場合、そのstatic変数となるオブジェクトに初期化ロジックが必要な場合は タイミングに悩みます。単純にstaticフィールドでnewしたりstaticイニシャライザを使用すると そこでエラーが発生した場合はキャッチできないからです。
public class Singleton {
private static final Singleton singleton = new Singleton();
上記の場合インスタンス生成時にエラーが発生した場合はキャッチできない。
下記の場合も同様にstaticイニシャライザ内でエラーが発生した場合はキャッチできない。
private static Singleton singleton = null;
static{
singleton = new Singleton();
・・・
}
}
結局Singletonとしたいオブジェクトを生成する際にエラーが発生する可能性がある場合（例えばＤＢにアクセスする等）は、
別途initializeというメソッドを用意し、Webアプリケーション起動時のリスナーでそれを呼び出すことにより
エラー発生時はExceptionをキャッチして異常を検知するようにしています。
※initializeメソッドはprotected等しかるべきスコープにする必要があります。
もっとスマートな方法はないかといつも悩みます。
ちなみにSingletonという考え方は、Singletonパターンを学ぶ前からやっていた事ですが、
コンストラクタをprivateスコープにするという発想はこれで覚えました。
Singletonパターンだけではなく、インスタンスを生成する必要の無いstaticメソッドだけを定義した共通メソッドだけのクラスも
私はコンストラクタをよくprivateスコープにしています。
Flyweight パターン
ファイル等に定義してあるアプリケーション独自の設定情報の管理はFlyweightをよく使用します。 Flyweightというとカッコよく聞こえますが、要は単なるキャッシュです。
Observerパターン
フレームワークを開発していると、たまにXXXXListenerというインタフェースでクライアントに通知をする仕組みを考えますが これがObserverパターンになります。
よく言われているようにobserverとは「観察者」という意味ですが、 実際このパターンでのObserverクラスは「観察者」ではなく「通知」を受けるクラスになります。名前から入ると理解を誤りますので注意が必要です。
Proxyパターン
先に述べたIteratorパターンと同様に、生成コストが高いがそのインスタンスをクライアントがすぐに使用することが無い場合は、 Proxyパターンを適用する事があります。
リソース削減・パフォーマンス向上のパターンが多い
と、ここ最近自分が開発したシステムをアレコレ思い出してみたのですが、よく使っているパターンと言えばこんなもんです。
シンプルで分かり易いものが多いです。
保険系システムに限ったことではないと思いますが、システムが扱うデータ件数が大量であり、また関連するテーブルが多くなってきている為か、よく見ると消費リソースを抑えたりパフォーマンスを上げる為のパターンを多用しているということに気付きました。
デザインパターンではもっと複雑で難易度が高くかっこいいパターンが沢山あるものの、
ソースコードに格好つけて自己満足する為に使用することが目的ではありません。
適材適所に適用することが大事です。
そんなことを心に留めながらいくつもシステムを作ってきましたが、
ここ数年で上記以外に実際にデザインパターンを適用する機会はあまり無かったと思います。
といってもそれはあくまでも私（筆者）の経験と発想力がまだまだ未熟だからからかもしれません。
でも、Visitorパターンは一生使わないだろうと思います。
Posted by T.S
五反田まで散歩
2008-11-03 22:37
先月、昼休み中の恵比寿までの早歩き散歩を紹介しましたが、今回は更にハードルを上げて 五反田→白金高輪近辺までの散歩にチャレンジしてみました。
かなりペースが速く、しかも最後の２００メートルは散歩どころか走って会社に戻りました。 歩いた距離を測定したところ、50分で約5kmとなりますので時速6kmで歩きました。 がんばりました。
Posted by T.S
