SQLインジェクション対応で思うこと

絶賛単純作業（見た目のみ）中の筆者です。

SQLインジェクション対応というのをやっているのですが、作業的には
１、共通関数（無毒化を行う関数）の作成
２、作成した共通関数を対象プロジェクトのソースの『適切な場所』に組み込む
だけのことです。
２、が対象プロジェクトの規模に比例して作業量が増えるのですけどね～
具体的には２プロジェクトで２０００本程度のSQL文の確認と共通関数組み込みとなります。

組み込んでよい場所だめな場所の判別もしているので、脳内では単純作業じゃないのですが、見た目は共通関数のコピペなので単純作業に見える、と・・・　orz


そんな作業をしていると、ふとWebシステムのセキュリティ対策について考えてしまったりします。
今回対象となっている「SQLインジェクション」はSQL文の可変部分に与える文字列を工夫することで悪さをしようというものです。
具体的にいうと・・・

Select カラムA From テーブルA Where カラムB = '（入力値）';

というSQL文があり、（入力値）は画面上のテキストボックスの入力値をそのまま入れるとします。
一昔前のクライアント－サーバ型システムでのDBアクセスではお約束といえる書き方です。
ここで、入力値に

”' or 'A' = 'A”

と入れるとどうなるでしょう・・・

Select カラムA From テーブルA Where カラムB = '' or 'A' = 'A';

条件部分が
「カラムＢ=""」　または　「"A" = "A"」
となってしまいました。

テーブルＡの全レコードのカラムＡの情報が取れそうな感じですね。

まぁ、これだけならあまり害はないのですが、いくらでも好きなＳＱＬ文に出来てしまう可能性があるのがわかると思います。
具体的には書きませんが、色々ＤＢを弄くれる可能性も・・・　ということで極めて危険なわけです。

対応の方法は色々とありますが、最低限「'」（シングルクオート）を「''」に置換する必要があります。


実はＳＱＬインジェクションというものは、厳密に画面の入力を定義してやればかなり防ぐことが可能だったりします。
入力値で攻撃する性質上、数値だけしか入力できないテキストボックスからは何も出来ません。
入力をプルダウンメインにしてしまえばもちろん何も出来ません。
入力可能な文字数が短ければやはり攻撃しづらい、と・・・
まぁ、フレームワーク側での対応が進んでいるので意識しなくても良いともいえるのが現在の開発環境だったりするのですけどね。

シンプルなシステム

あまりまとまっていませんが、現時点で筆者が考えている『シンプルなシステム』について少し書いてみます。

シンプル、とは何か？
構成がシンプル。
画面がシンプル。
機能がシンプル。
などなど・・・　色々ありますが、ここではエンドユーザにとって『シンプル』であることとしてみます。

エンドユーザは何かをやりたいからシステムを利用するわけですが、やりたいことが最短手順（または時間）で実現できるのが『シンプルなシステム』ではないか？　筆者はそのように志向しています。
極端な例を言いますと、自動販売機などはシンプルです。
お金を入れて、ボタンを押せば品物が出てくる。
まぁ、これはやりたいことが買い物という単純作業（お金と品物の交換）なのでシンプルになるのも必然ですが、企業などの業務ではどうなるのでしょうか？

残念ながら、企業などの業務でここまで単純な作業はあまり残らないと思います。
自販機で代替してみたり、計算機で自動化してみたり、そのような２０世紀末までに行われてきたＩＴによる効率化レベルの話で済んでしまいます。
いわゆる、人を機械に置き換えるレベルの話ですね。
「うちには人がやっている単純な作業が残っている」、と主張する方も居ると思いますが、その単純な作業というものには例外が多数存在するのではないかと思われます。
若しくは品質保持に人手が必須である場合、ですね。

では、単純ではない作業をいかにシンプルに処理させるのか？
そこが『シンプルなシステム』作りの鍵になるのではないかと考えます。

一つのアプローチとして、「単純ではないものは単純になるまで分割する」があげられます。
数学の微積分を思い出すとわかりやすいのですが（忘れた、という人は、少しでよいので復習してみてください＾＾；）複雑な図形の面積であっても、線の集合として考えれば求めることが出来ます。
これをシステムに当てはめると・・・　確かに単純な作業まで分割はできそうなのですが、手数や画面遷移・使用する機能が膨大になりそうです。現実的ではなさそうですね。

Ｗｅｂシステム、として考えると、いかにユーザに「見せない」か、が鍵だと考えます。
ボタンやリンクを極限まで減らし、かつ、左上から右下に進んでいけば処理を終えることが出来る。
ログインしたユーザが使わないボタン・リンクなどは一切表示しない・・・
これである程度のシンプルさは確保できます。
残念ながら、その先が筆者には見えていません。
恐らく、機能自体のシンプルさの追求が必要になるのですが・・・



書き出してみればまとまるかと思いましたが、そうは行かないですね＾＾；

ＯＢ会

今、東京から戻ってきて一息ついた筆者です。
昨日（金曜日）は当然ながら仕事があったので、日帰りで行って帰ってきたわけです。
なんでそんな強行軍だったかと言いますと、大学時代の委員会のＯＢ会だったのです。

筆者は大学時代、大学生協学生委員会という委員会に属していたのですが
（誤解なきように付け加えますが、社会主義的な『生協』のイメージは過去の遺物として扱われていた時代のことです。大昔はデモに参加した学生もいたとか聞きましたが、そんなことよりもお祭り騒ぎの企画の方が楽しい連中でしたので＾＾；）
電気通信大学生協が設立５０周年を迎えたことで、式典に出るという目的もありました。

残念ながら、例年のような、大学祭の喧騒の中でのＯＢ会ではなかった（大学祭は先週やったそうです）のですが、同期・先輩・後輩と久々に話してきました。
・・・順調かつ平穏に生活している者あり
・・・会社が買収されることになった者あり
・・・消息不明の者あり
色々ですねぇ。
筆者の同期は６名（筆者含む）なのですが、２名の現状がつかめていなかったりします。
まだ、入学から１２年しか経っていないのに、と言う感じですね。

え？　普通は「卒業から＊＊年」じゃないのか？！
それは酷と言うものでしょう。
４年で卒業できる学生の比率が６０％台の大学なので、裏を返せば３０％強の学生が留年するのです。
６人なら２人くらいは留年するわけで・・・
実際に、２年次になる時点で１名（試験のときに病気で入院した為）、３年次～４年次のあたりで１名の２名が留年しています。
筆者はかろうじて４年で卒業していますが、これくらいの厳しさでないと大学ではないのではないかなぁ（何せ、学生が堂々と救済処置を求めるので。お前ら学びたくてきたんだろ？ホンネはともかく、建前としては　と言いたかったのです）
などと在りし日を振り返ってきました。


全く関係ありませんが、東京は人が多いなぁ、そして交通費が安いなぁ
何となく名古屋と比較してしまっている自分がいました＾＾；

使える設計書・使えない設計書

ＣＯＰ１０が始まりました。

愛知万博の時は東京に居たのですが・・・

なんとなく「やっている」程度の情報しか入ってこなかったのを覚えています。

今回のＣＯＰ１０も同じ感じなのかなぁ？　と思ってみたり。

中京圏はローカルでの広報が多い気がするのですが、気のせいでしょうか？

今日のお題は　設計よもやま、という感じです。
といっても、設計の方法などについて論ずるわけではなく、設計書と製造の距離を埋める一つの方策を考えてみようと思います。

設計書というものはシステム開発に必須の文書です。
料理に例えるなら、レシピのような位置づけになります。
特定の相手に読ませるなら相手に合わせたレベルで、一般向けならそこそこ細かく、というあたりは共通してきます。
しかし、どのような相手であれ設計の次は製造作業があります。
設計書に書いてある内容を、製造者がコードに置き換えていく作業・・・
必要な事ですが、労力がもったいないケースもあります。
当然、途中で設計が変更されればやり直しが大変です。
設計変更に連動して製造も変更されれば、と思ったＳＥは数知れず、でしょう。
料理と違って、設計も製造もＰＣの中で行っているのですから。

そこで、製造のなかで定形化出来る部分を設計書に記載しておけば？
というベタなことを考えています。
実際に一部の設計書に対して私的に実験を始めていますが、評価はまだ先になりそうです。
項目名を書きかえると関連するソースコードが変更される。
ただこれだけなのですが、設計書をＯｆｆｉｃｅ（主にExcel）で記述している現状では色々な工夫を要求されます。
さすがにＩＤＥなどで記述したスケルトンなどを設計書と言うわけにはいきませんし、ＵＭＬは悪くないけどツール頼みなのが怖い。

結局のところ、自前で、多くの人が理解可能な作りで作るのがＢｅｓtなのかな？　と思い、ちまちまと工夫をしていこうかという感じです。




・・・具体的な事を伏せたら余りにも短くなってしまった。

貴方に積める善行は、母国語【日本語】を正しく使うことです

タイトルが元ネタありに戻った筆者です。
結構きついことを言うキャラのセリフから取ったので、かなりきついタイトルですね。
本文もタイトル並みにきついことを書くつもりですが＾＾；

ソースは雑誌なのですが、楽天が社内公用語を英語にする、という事をしているようです。
売上ベースで１％程度、海外は６カ国８拠点という海外進出度の現状（早い話が国内で仕事しているレベル）の楽天が、会議と名のつく場の全てで英語の使用を義務付けています。
参加者に必ず外国人がいるか？　というと、日本人だけの会議でも英語使用。
社員食堂のメニューの写真が載っていましたが、こちらも全て英語表記（ちょっと気取った店が黒板にメニューなどを書いていますがあんな感じ。「Udon」とか「Tempura」とかあるのが萎えるｗ）とても見づらいものでした。
採用・昇格などでＴＯＥＩＣの点が必須要件になるなど・・・
現在役職に就いている人は、その役職で求められる英語力を２年以内に身につけることを要求されて、飲み会に行く代わりに英会話教室通いをしているとまで書いてありました。


社内公用語を英語にすることのメリットとはなんでしょうか？
楽天では、グローバルに事業を展開する為に、という事を掲げており、一つの例として「鹿児島の支店での成功事例をフランスの支店で使用する」際の言語障壁をなくすことが出来るというのがありました。
人材面では外国人の採用を積極的に行うことができるとも。

正直なところ、その程度なのですよね。
外国人採用はどうでもいいとして（日本人が外国人に優る／劣るという議論はナンセンス）
例えば、
「沖縄で成功した事例を他の都市で展開する」
なんて事をやって成功するか？　というと可能性は低かったりします。
理由は様々ですが、その土地毎の特徴に合わせたカスタマイズが必要なのです。
ましてや国が違えば余計に大変なわけで。
日本人が、日本語で書かれた事例を見て、日本（の他の都市）で展開しても必ず成功するわけではないのに、何処の国の人かわからない人が、英語で書かれた事例を見て、どこかわからないところで展開することをメリットとしてとらえているあたりが楽天的すぎます。楽天だけに？ｗ

文章だけで正しく情報を伝達することがいかに難しいか。
最低でも母国語で正しく情報を伝達できないと、外国語を使っての正しい情報伝達は難しいのではないかと思うのです。

本当の意味でグローバルに仕事を、というならば、母国語をしっかり押さえつつ、事業展開する先の国や地域の言語を習得するべきでしょう。
現地では仕事相手の母国語で話す。社内では基本的に日本語（話をする社員の母国語が日本語なら。異なる場合に初めて英語が選択肢に上る）で話す。
言語とは意思疎通の道具であると割り切るなら、このような方法をとるべきでしょう。
【グローバルな人材＝英語で意思疎通できる人材】
なんて考えに縛られたＴｏｐに振り回される楽天社員。
こんなことに労力使っているのでは伸びる会社と思えないですね。

計算機 初歩の初歩 ～計算機は何故動く？ ソフトウェア編～

よくよく考えてみれば、計算機の動く仕組みはハード／ソフト両面から説明が必要でした。
ということで、今回はソフトウェア編です。

まずは前々回の内容から。

ノイマン型アーキテクチャの計算機は以下のようなステップを繰り返し行うことで計算を行う。

1. プログラムカウンタのさすアドレスから次の命令を読み込む

2. 命令長さの分だけプログラムカウンタを増やす

3. 制御装置で命令をデコードする。制御装置は計算機の他の部分に対して命令を出したり、

   繰り返しを行うためにプログラムカウンタの値を替えたり、条件分岐のためにALUの状態によって
   プログラムカウンタの値を替えたりすることができる。

4. ステップ1へ戻る

という部分がありましたが、この計算手順がソフトウェアの基本になります。

「アドレス」とはメモリ上のアドレス（番地）の事で、メモリ上の何番地の情報を参照する、という形で情報を見たり書いたりします。
機械語（演算装置が直接理解できる命令の事。"0"と"1"で構成される為、人間には非常に読みづらい）ではメモリのアドレスを指定するのですが、アセンブラや高級言語では直接のメモリアドレス指定はまず行いません。
しかし、メモリアドレスを意識しておかないと「何故動くの？」という問いに答えられないので書いてみました。
現実問題としてメモリアドレスを意識してコーディングすべき言語はＣ言語くらいまでです。
（VC++.netでは意識する必要性はありません。VC++までです）

ステップ２．の「命令長さ」ですが、メモリアドレスが指すアドレスは、命令の格納されているアドレスの一番先頭のアドレスです。
その為、アドレスに格納されている命令の長さの分だけアドレスの位置を移動させないとならないわけです。
このあたりの処理はアセンブラや高級言語で意識する必要はありません。

ステップ３．で構造化言語の要素（順次・反復・分岐）が登場します。
高級言語の場合、このレベルでソースの記述を行います。


さて、当たり前のように出てきた単語を解説しますと・・・
『アセンブラ』（wikipediaより引用）

CPUが直接実行できる言語は機械語のみであるが、機械語は数字（内部的には二進数）の羅列なので人間には理解しにくい。そこで、機械語を直接記述するのではなく、機械語の意味を表す略語でプログラムを記述することで、人間により分かりやすくしたものがアセンブリ言語である。アセンブリ言語の文法はCPUのアーキテクチャに依存するため、高級言語のような移植性はない。

アセンブリ言語を機械語に変換する事をアセンブル (assemble) すると言い、それを行うプログラムの事をアセンブラ (assembler) と言う。なお、アセンブリ言語の意味で「アセンブラ」または「アセンブラ言語」(Assembler Language)と呼ぶ場合も多い^[1]。

アセンブリ言語の命令は、アセンブラに対する命令（疑似命令）やマクロ命令を除き、機械語と1対1で対応し、プログラマがCPUの動作を把握しながらプログラムを記述する事ができる。そのため、

• 実行速度やプログラムサイズに制限があるアプリケーションで、高級言語であるコンパイラの最適化能力では達成できない最適化を手作業で行いたい場合

• CPUの動作をプログラマが完全に制御する必要がある場合

• メモリ容量や演算実行速度などのリソースに厳しい制約がある用途

などにはアセンブリ言語によるプログラムが行われる。現在でも、例えばOSカーネルやデバイスドライバ、組み込みシステムの開発といった場面で頻繁に用いられる。

機械語よりも人間に近いのですが、ＣＰＵの動作一つ一つについて記述が可能⇒記述が必要となります。
ずいぶんと書きづらいのですが、無駄な動きを一つもさせないというプログラミングが可能となります。
ちなみに、アセンブラは低級言語（低水準言語）と言われています。
レベルが低いのではなく、コンピューターに近い⇒原始的　という意味合いからのネーミングと思われます。

『高級言語（高水準言語）』（やはりwikipediaより引用）

「高級」の由来は、コンパイラなどで直接機械語にするのではなく、一度アセンブリ言語に変換されて、機械語に変換されることがあったため、アセンブリ言語を低級言語、低級言語に変換できる言語を高級言語と区別したことから。インタプリタなどでは低級言語ではなく、中間言語にされて実行されることが多い。

アセンブリ言語と比べ、

• 人間にとってわかりやすい

• CPUに依存した処理を書かなくてよい

• メモリ制御、IO制御等CPUレベルの操作を意識しなくてよい

という違いがある。広義の意味は主に三番目の理由からである。

人間寄りのプログラミング言語です。
機械語／アセンブラレベルの複数の命令を、高級言語の１つの命令で済ませることが出来ます。
現在のプログラマ（プログラミングが出来る人）はほとんどすべてが高級言語を扱っています。
たまに筆者のようにアセンブラ経験者（※筆者は大学の演習で使用しました）や、組み込み系一本でアセンブラばりばりな技術者がいますが例外的存在になりつつありますね。


一言でまとめると
『計算機は機械語しかわからないが、翻訳（コンパイル）することで高級言語による命令が実現されている』
のが現状であり、現在の計算機を動かしているソフトウェアとなります。
本当にプログラムを書けるというのは、機械語レベル（せめてアセンブラレベル）を理解して高級言語を使用している状態をいうのではないかなぁと思います。

尚、javaが環境を選ばずに動かせるというのは仮想マシン（ＶＭ）があるからなのですが、仮想マシン＝計算機と見なすとその理由がわかりやすくなります。
仮想マシンを使うことで、どのような環境でも同じ計算機で計算を行うという状況を作り出している。
その結果、環境を選ばない、という利点が生まれているわけです。
一つ余計なもの（仮想マシン）が追加されている為に動きが遅かったり、サーバやクライアントのスペックを無駄に要求されるのですけどね＾＾；　そんな理由から、筆者はjavaが好きじゃなかったりしますが、それも計算機の仕組みを知ればこそです。


やはり、ちゃんと肉付けして説明すると講義数コマ分の分量のある内容だけに消化不良かもしれないですね。
そこまで書ききる気力がないので今日はこの辺で終了です。

計算機 初歩の初歩 ～計算機は何故動く？～

ブログのアクセス解析ツールを使うことにしました。
といっても、すぐに結果が出てくるわけではありませんのでしばらく待ちです。

さて、前回の反響も見ずに計算機初歩シリーズ第二回です。
今回はハードウェアの基本的な構成と各部の働きを見てみようと思います。
正直なところ、大まかに理解していればあとはぐぐる先生に質問できますので（←基礎知識なしではぐぐる先生に質問しても効果が薄いのです）最低限このくらいは抑えておこうというレベルで書いてみます。


ノイマン型の説明で
『ノイマン型アーキテクチャの計算機は5つの部分からなる。演算論理装置（ALU）、制御装置、メモリ、入出力と、これらを接続する情報経路である。』
と前回引用しましたが、これだけだと手元にあるパソコンのどの部品がどの部分に当たるのかわかりづらいと思います。
その為、もう一段階現在に近い説明を引用します。（引用元）

コンピュータは制御装置、演算装置、主記憶装置、補助記憶装置、入力装置、出力装置 で構成されています。

コンピュータの心臓部は中央処理装置 (CPU) です。

中央処理装置は制御装置と演算装置から成っています。

主記憶装置はプログラムやデータを記憶し、CPU の求めに応じて素早くデータを送ったり、 CPU から返された処理結果を記憶して、コンピュータの働きの中心となるメモリ  です。

大型コンピュータが中心であった頃の習慣で、CPU と主記憶装置をコンピュータ本体といい、 入力装置、出力装置、補助記憶装置はコンピュータ本体の周辺に設置されていたことから 周辺装置 (peripheral equipment) といいます。

入力装置はキーボードやマウス、 バーコードリーダーやイメージスキャナーなど、 コンピュータを操作したり、さまざまな情報をコンピュータに与えるために使用されます。

出力装置はディスプレイやプリンタなど、コンピュータの処理状況や処理結果を表示、 印刷するものや、 音声のデータを再生するスピーカなども出力装置の仲間です

補助記憶装置はフロッピーディスクや ハードディスク、CD-ROMドライブなどです。

ハードディスクに保存されているプログラムを主記憶装置に送ったり、 コンピュータで作られたデータをフロッピーディスクやハードディスクに保存する、 などというふうに使用されます。

ちなみに、この引用元は大学の講義資料のようなので堅いですが比較的整理されています。
独習時の参考サイトとしてお勧めしておきます。

ノイマン型の５つの部品と、上記引用との対応をとってみると…

・演算論理装置（ALU）＋制御装置　⇒　中央処理装置（ＣＰU）
・メモリ　⇒　主記憶装置
・入出力　⇒　入力装置・出力装置
・これらを接続する情報経路　⇒　（マザーボード上の回路（バス）・配線など）

となります。
尚、補助記憶装置はノイマン型では考えておらず、現実問題（主に費用の問題）として必要な為に追加されたものです。
計算機が直接扱うのはメモリ上の情報であって補助記憶上の情報ではないのです。


上記引用で、おおざっぱな理解は可能ですが念のため解説を。

０、（パソコン起動）
１、起動終了後、入力待ち状態になる
２、入力（キーボード・マウス・ＦＤやＣＤ挿入）に応じて処理開始
３、入力された情報が情報経路を通ってＣＰＵに伝わる
４、必要な情報を補助記憶装置から主記憶装置に読み込む
５、命令を実行する
６、必要に応じて処理後の情報を出力装置や補助記憶装置に送る
７、命令がある間、４、～６、を繰り返す
８、入力待ち状態に戻る

７、で「命令がある間」とありますが、命令の最中でも確認メッセージ表示（＊＊して良いですか？　Yes/No）の入力待ちのように入力を促す場合があります。

全て書いていませんが、装置間の情報伝達は全て情報経路を通じて行われます。

常に各装置をフル稼働しているわけではありませんので、複数のプロセス（上記１、～８、を行う手続き）を同時に動かしているのが現在のコンピュータ（正確にはＯＳ）です。
同時に、と言っても全ての命令や処理を一度に行わせるのではなく、作業予定表を作るようにして順番に処理を実行させます。この効率が良ければ良いほど各装置を有効活用できます。


深堀はいくらでも出来る分野なのですが・・・
あまりやるとこれだけでブログが一つ出来てしまうので、というより筆者のレベルの浅さが露呈する（笑）のでここまでにしておきます。

実際問題としては、どのような装置がどのような役割を担って計算機が動いているか、上記のレベルで理解していれば、調べものなり質問なりが比較的スムースに行きます。

計算機 初歩の初歩の初歩 ～計算機とは？～

技術的な話の少ない当ブログ。

このままでは良くない、と感じた筆者は抜本的な構造改革に取り掛かる。

しかし、その行く手には・・・

って、どこぞの予告編みたいですね。

かなり気合入れていますので、今回の投稿が予告編になってしまう恐れがありますが進めてみます。

この文章を見ているということは、読者は全て『計算機』を使用しているということになります。

さて、『計算機』とは何か？

パソコン？　スパコン？　マイコン？　ケータイ？　電卓？

どれも『計算機』に当たります。（マイコンや電卓ではこの文章は見れませんが＾＾；）

「パソコンの何処が計算機なのさ？」

と思われると思いますので、『計算機』とは何か、を書いてみようと思います。

Computer（コンピューター）の和訳（google辞書で翻訳）は

1. コンピュータ

2. コンピューター

3. 計算機

4. 電子計算機

5. 計算器

6. 高速演算機構

    となり、「計算の為の機械」と言えます。（「機械」と「器械」の差はスルーします。このへんを厳密に定義する人々もいるようですが本筋じゃありませんので）
   
   では、どのようにして正しい計算をする仕組みを作るのか？
   この理論の大本と言えるのが『オートマトン』です。
   wikipediaによると
   
   
   

   
   
   
   
   
   
   
   
   
   
   
   
   
   

   オートマトン (automaton (pl: automata)) とは「自動人形」を意味している言葉で、情報科学の分野においては、次のような特徴を持ったシステムのことである。

   • 外から、連続している情報が入力される
   • 内部に「状態」を保持する
   • 外へ、何らかの情報を出力する

   というのがオートマトンなのですが、ずいぶんと抽象的になります。
   具体的には有限オートマトンに詳しいのですがここをしっかり説明すると大学の講義数コマ分の分量になりますので、興味のある方はリンク先（wikipedia）を見てください。
   尚、リアルでの質問も受け付けます。（メールなどでの質問は申し訳ありませんが勘弁してください。参考サイトを検索する方が遥かに早いです）
   
   
   簡単に言うと、状態の遷移を示す為の理論です。
   
   
   　「状態：空腹」、「入力：食事」⇒「遷移」⇒「状態：満腹」、「入力：時間経過」⇒「遷移」⇒「状態：空腹」・・・
   
   
   と言えばなんとなくわかるかと思います。
   上記のオートマトンの説明に沿うならば、
   
   外からの情報入力（「入力：＊＊」）があり、情報入力に応じて状態遷移する。
   遷移元と遷移先の「状態：＊＊」を内部に保持し、「状態：＊＊」の情報を外へ出力する。
   
   と言えますね。
   
   
   どれほど複雑なプログラムでも、このような状態遷移が必須となります。
   初期状態と外からの入力がない限り、どれほど高度なシステムも動きようがないのがわかると思います。
   
   このオートマトンというものは、自動／半自動の仕組みの大半で使われていますので、身近なもので状態遷移を考えてみるのも面白いと思います。
   
   
   
   さて、オートマトンが状態遷移を示すのはわかるのですが、それのどこが「計算」なのか？
   次はそのへんを見ていきたいと思います。
   
   
   
   現在使用されている『計算機』の基本は、ほとんどが「ノイマン型」と言われるものを使用しています。
   この「ノイマン型」計算機は「チューリングマシン」の理論を使っているのですが、「チューリングマシン」は「オートマトン」の定義を拡張したものです。
   
   
   もう少し噛み砕いてに説明をしたかったのですが、これはそういうものだ、そういう関係だと思ってください。
   チューリングマシンとは（wikipediaより）
   
   
   

   チューリングの仮想機械は、

   1. 無限に長いテープ

   2. その中に格納された情報を読み書きするヘッド

   3. 機械の内部状態を記憶するメモリ

   で構成され、内部状態とヘッドから読み出した情報の組み合わせに応じて、次の動作を実行する。

   • ヘッド位置のテープの情報を読みとる

   • ヘッド位置のテープに情報を書き込む

   • 機械の内部状態を変える

   • ヘッドを右か左に一つ移動する

   上の動作を、機械は内部状態が停止状態になるまで反復して実行し続ける。

   というものです。
   オートマトンの拡張だけあって、似ていますね。
   情報の読み取り（オートマトンで言えば外部からの入力）、情報の書き込み（外部への出力）、内部状態の記憶（内部に「状態」を保持する）、とそろっています。
   
   
   実際には「無限に長いテープ」なんてものは存在しませんが、ノイマン型コンピューターでは有限の記憶領域の範囲内での計算を保証する作りになっています。
   ノイマン型とは（再びwikipediaより）
   
   
   

   ノイマン型アーキテクチャの計算機は5つの部分からなる。演算論理装置（ALU）、

   制御装置、メモリ、入出力と、これらを接続する情報経路である。

   
   
   

   ノイマン型アーキテクチャの計算機は以下のようなステップを繰り返し行うことで計算を行う。

   1. プログラムカウンタのさすアドレスから次の命令を読み込む

   2. 命令長さの分だけプログラムカウンタを増やす

   3. 制御装置で命令をデコードする。制御装置は計算機の他の部分に対して命令を出したり、

      繰り返しを行うためにプログラムカウンタの値を替えたり、条件分岐のためにALUの状態によって
      プログラムカウンタの値を替えたりすることができる。
      

   4. ステップ1へ戻る

   とあります。
   ようやく計算っぽい話（ステップ３．）が出てきました。
   
   
   外部からの入力（命令の読み込み）に応じて計算を行うのがノイマン型コンピューター。つまり、計算する為の機械。『計算機』です。
   ここまで書いて（全く厳密じゃない、さわりだけですが）ようやく『計算機』が『計算する為の機械』であるという説明が出来ました。
   
   
   ノイマン型アーキテクチャのステップ１，２はマシン語やアセンブラに、ステップ３は構造化言語に、それぞれ関連してきますので、ＳＥならば知っておきたいところです。
   というか、これくらいは知っておかないとプログラミング言語の基本をおさえたとは言えませんので。
   又、ノイマン型アーキテクチャの計算機の５つの部分は、ハードウェアの基本そのものになります。
   
   
   さて、ずいぶん大量の情報を垂れ流してしまいましたが、これが初歩の初歩の初歩。
   理解なしでもシステム構築が出来る世の中ですが、理解しておいた方がより良いです。
   続編の予定としては、この書き込みの派生として、それぞれの分野の話を書いていこうと思います。
   
   
   
   
   

ＤＢおほへ書

このごろ晴れが続くなぁ、と思っていたら、梅雨が明けているとかいないとか。

異常気象という気はありませんが、わかりづらい気候ですね。

とりあえず、脱水対策として家の冷凍庫の氷を量産しようと思います。
アイスティーを淹れるとすぐに氷がなくなるもので＾＾；

さて、本日のタイトルの元ネタは戦国モノです。
タイトルと内容はほとんど関係ありません。


ＤＢ（データベース）というのは、とても重要な割に理解している人が少ないものだと思います。
かく言う筆者自身、製造工程で使用する為のＤＢサーバくらいならなんとかかんとか作れなくもありませんが、実環境（実際にユーザが使用する環境）のＤＢサーバは厳しいです。
何が一番大変かと言うと、データが過不足なくリアルタイムに正しく存在しなくてはならない（しかもシステム稼働中を通してずっと）のです。
中身を理解していないとそんな保証はできないです。

大半のＳＥが基本的なＳＱＬ文（ＤＢを操作するおまじないと思っておけばＯＫです）が書ければそれで良いと思っている昨今ですが、筆者はある課題の為に調べ物漬け状態になっています。
その過程で出てきた話をちらっと書いてみようと思います。


一番単純なＤＢには、テーブルと呼ばれるデータ格納領域だけが存在します。
テーブルとは何ぞ？　といいますと、エクセルで作った表のようなイメージを持っていただくと良いかもしれません。
カラム（列）が幾つかあって、レコード（行）を構成する。
たとえば、名簿なんかがわかりやすいですが、学籍番号・氏名・備考、という３つのカラムが存在し、学生一人につき３つのカラムそれぞれに情報が入ったレコードが１つ作られます。

実際のＤＢでは、テーブルとテーブルの関係（上記の「名簿」テーブルの学籍番号と、Ａ講座の成績表テーブルの学籍番号を関連付けることで、Ａ講座の成績表に学生の氏名が登録されていないのに『＊＊さんの成績は【Ａ】です』という情報が得られる）が重要なのですがその辺はそこらへんの解説サイトなどにお任せします。
数学の集合論なんかと絡めても面白いのでしょうけどマニアックすぎるので＾＾；

では、単純じゃないＤＢとは？　というと、その一つとして「他のＤＢから情報を参照する」というのがあります。
社内で昔から使っているシステムのＤＢから必要な情報を取得したい、という場合などが該当しますが、この時に新しいシステムから比較的簡単に情報を参照する方法が【view】です。

えー、現役ＳＥの中からは「viewは複数のテーブルの情報をまとめるものだろ？」などと突っ込まれそうですが、その用途は無論正しいです。
しかし、viewは他のＤＢの参照が（恐らく）一番簡単に出来る手段でもあるのです。

～サンプル（始）～

CREATE OR REPLACE VIEW 【view名】 AS 

 SELECT dblink.【参照したいカラム名】

   FROM dblink('host=【ホスト名】 port=【ポート番号】 dbname=【ＤＢ名】 user=【ユーザ名】 password=【パスワード】'::text, 'select * from 【参照したいテーブル名】;'::text) dblink(【参照したいカラム名】 【カラムの型】);

～サンプル（終）～

はい、何のことやらな方もいるかと思われますが、これが他のＤＢを参照するviewを作るＳＱＬ文です。
ちょっと手抜きでPostgresのビュー定義からコピペしてしまいましたのでわかりづらいところがあるかもです。
簡単に説明しますと…

CREATE OR REPLACE VIEW　【view名】：CREATE VIEWの直訳でわかるように「【view名】という名前のVIEWを作る」という意味です。

SELECT　以下：SELECT カラム名　FROM テーブル名　が参照のＳＱＬ文の基本になります。そういうものだと思ってください。

SELECT dblink.【参照したいカラム名】：「dblinkテーブルの【参照したいカラム名】カラムの情報を取得する」という意味です。

FROMは長めなので分割して…
dblink('host=【ホスト名】 port=【ポート番号】 dbname=【ＤＢ名】 user=【ユーザ名】 password=【パスワード】'::text, ：【ホスト名】というホスト（ＤＢサーバ）に【ポート番号】番ポートからアクセスして、【ＤＢ名】というＤＢに【ユーザ名】と【パスワード】でログインする、という意味です。

 'select * from 【参照したいテーブル名】;'::text)：dblinkした先で実行したい参照用ＳＱＬ文です。

dblink(【参照したいカラム名】 【カラムの型】);：取得したいカラム（情報）の一覧です。カラム名と型（文字列なのか？　数値なのか？　日付なのか？　などなど）が必要です。

まとめると
『dblinkで接続した先のテーブルから、指定したカラムの情報を取得して参照する』
となります。
まとめるときに切り捨てた部分が技術的に重要だったりしますが、そこまで入れるとサンプルのＳＱＬ文が一番シンプルと言う＾＾；
ＳＥの会話は宇宙語だ、と思う人もいるようですが、このへんの感覚が理由なのかな？


自分用の覚書兼同じ悩みを持っている方の指針となれば、という記事でした。

システム試験におけるトリアージ

トリアージ（Triage）

人材・資源の制約の著しい災害医療において、最善の救命効果を得るために、多数の傷病者を重症度と緊急性によって分別し、治療の優先度を決定すること。語源はフランス語の「triage（選別）」から来ている。適した和訳は知られていないが、「症度判定」というような意味。なお、一般病院の救急外来での優先度決定も、広義のトリアージである。識別救急（しきべつきゅうきゅう）とも称する。（wikipediaより）

いきなり引用からですが、ＪＲ福知山線の事故などで知られるようになったこの言葉をシステム開発における試験フェーズと絡めてひとつ書いてみようと思います。

システム開発の試験はどれだけ理想的に進めてもちょっとした躓きで混乱や炎上がおこります。
混乱する原因は、「その不具合は何が原因なのか？」が大本です。
大まかにでも原因が特定できていないと、誰が対応すべきか／誰が対応するのが適切か、がわかりません。
最悪、全く知識のない人が調査をすることになって無駄に時間を費やすケースもあります。
原因がわからないから調査するわけですが、調査の適任者を決める為には原因個所がわからないと…　卵が先か？　鶏が先か？　という感じですね＾＾
なので、「大まかな」原因個所の特定が重要になります。
ちなみに、このときの特定は「ＡかＢ」という程度で構わないと筆者は考えています。
無論、「これこれ、こういう風になっているのが原因と思われるので、ＡかＢで問題があるのでは？」という推論が必須です。


「大まかな」原因個所の特定を行わずに、不具合に対処した場合はどうなるでしょうか？
このような場合、難しそうな不具合はリーダーや上級ＳＥなどが担当し、それ以外はなんとなく（件数を頭割りするなど）それぞれのメンバーが担当することが多いと思います。
難しいところは実力のある人が、というのは正しい判断ですが、簡単な不具合に未熟若しくは担当外を担当する人が時間を取られて全体の不具合対応の進捗の足を引っ張ることも多々あります。
進捗が上がってこないとリーダーなどの負荷が増大し、さらに適材適所な不具合修正が出来なくなる悪循環に突入します。
この結果が炎上です。


混乱も炎上も極力避けたいモノですので、不具合の報告を受けた際に何が原因かの切り分けを行うべきです。
その際に便利な考え方が冒頭に書いた「トリアージ」です。


医療の現場だと「命の選別」とまで言われるのですが
（黒タグ：死亡もしくは手当てをしても助からない。　　赤タグ：すぐ手当てが必要。　　黄タグ：すぐにではないが、手当てが必要。　　緑タグ：軽症。
黒タグが付けられた人は今息があっても手当の対象にならない）
システム開発現場では以下の基準での「選別」が考えられます。

　緊急：機能停止または他の機能への影響が大きい不具合。対処は可能な限り早く行う。

　要対応：機能がとりあえず使える、局地的な影響があるような不具合。対処は緊急の次に行う。遅くとも翌日（または２～３日。開発のスピード感に依存）には改修する。

　要検討：機能が問題なく使えるが、何らかの問題があるような不具合。対処は一週間程度のスパンで考えればＯＫ。

　不急：機能が問題なく使え、何らかの軽微な問題があるような不具合。対処は急ぐ必要はないし、運用でのカバーなどで対処不要なケースが多い。

この基準と、大まかな原因特定を組み合わせることで各担当者の分担の最適化と改修予定が立てられます。
要検討や不急の不具合については、比較的時間のある担当外の人が見てもよいわけです。
逆に、緊急や要対応の不具合は原因と思われる個所を担当した人が見ることで迅速な対応が可能になります。
システム開発の場合、黒タグはありませんが（例外として、システムの制約で改修不可能な不具合と言うのがあります。これは黒タグ扱いに近いです）不具合の深刻さと対処期限で切り分けることで全体の進捗が滞らないようにし（他の機能に影響する不具合を放置すると、影響先の機能の試験などが滞るため）、対処期限を守る為に大まかな原因特定で適任の担当者を割り当てることを目指す考え方です。


以上が、システム開発の試験における「トリアージ」の基本的な考えですが、実践する場合はどうなるのか？
こちらについては、筆者の考えがまとまりましたら書いてみようと思います。
とはいえ、経験から出来るようになっていたようなところがあるので難しいのですが＾＾；

論点をずらすこと・ぼかすこと

暑いですねぇ。
本日の予想最高気温は３５度だとか…
体温並みの気温は勘弁してほしい。
テンプレ演説の幸福実現党とか、２０ｍ程度の長さの駅ビルの通路に６名のビラまき要員を配置する公明党とか、帰宅時間帯の名駅前で歩道の半分を通行できないようにして演説してる民主党とか…
こっちも気温と同じくうんざりです。
さわやかな気持ちになるべく、おいしいお茶でも淹れましょうか。


今回は議論の話の続きのような感じで進めてみようと思います。

真っ向から衝突する議論。
これってわかりやすいですし、充実感も納得感もあります。
しかし、摩擦を生むのもまた事実。
その為、論点を『多少』ずらしたり、ぼかしたりするという技巧が存在します。
そうすることで真っ向からの衝突にならない分、摩擦が少なくなるわけです。
良い技巧だと思ってしまいそうですが、実はとても大きな問題をはらむ技巧だったりするのです。

右に図を書いてみました。
基準線、とあるのが論点に真っ向から向かうイメージ。
A,Bは論点をイメージしています。説明用に２つ用意しました。
そして、論点をずらした場合として、ズレ１、ズレ２の２通りを用意しています。
適当な人の絵は議論の参加者です。
尚、参加者からの距離は論点の背景と参加者の知識や概念の距離とします。
たとえば、フェルマーの最終定理に関する議論、なんて話の場合はほとんどの人にとってかなり遠くにAとかBが配置されます。

正しい論点のずらし方は、ズレ１の状態にすることです。
参加者が認識しうる範囲でずらす（距離の異なる場合でも論点とズレの線が交わっている）状態ならば、理解しづらくあっても理解できないことはまずありません。

では、ズレ２の場合はどのような状況なのでしょうか？
ズレ２はAとは交わっていますが、Bとは交わりません。
これは、論点の背景を熟知している人は理解できるけど、そうでない人は論点を認識できない状況を意味します。
先ほどのフェルマーの最終定理でいえば、
　　3 以上の自然数 n について、xⁿ + yⁿ = zⁿ となる 0 でない自然数 (x, y, z) の組み合わせがない
というのは論点がわかっても、そこから少しでもズレると（たとえば、正則素数／非正則素数とか、「すべての楕円曲線はモジュラーである」とか…　フェルマーの最終定理の証明に使われた定理・概念です）全く理解の範囲外になってしまうわけです。
ちなみに、上記で挙げたズレの例は数学的にはそこまで大きくありません。（谷山・志村予想はずいぶん遠いのですが＾＾；）


論点をずらすのは危ないことなのです。




では、論点をぼかすのはどうでしょうか？
こちらは説明を省略する、若しくは抽象化するという方法をとります。
「黒こげになった、かつては食材であったもの」
「真黒な炭化物の塊」
「炭」
いずれも漫画などで出てくる失敗料理の描写ですが、「焦がして失敗した料理」と書く場合に比べて、伝わり方が変化します。
上から順に、情報を欠落させてみたのですが…
いずれの例にしても作り手が泣きそうな表現ですね＾＾；


文学作品や文章などで多用するのは良いのですが、議論を行う際に多用すると論点がわからなくなりそうですね。
実際にぼかしたことで議論が迷走、なんてことも起こりえます。
大抵無駄な時間を使うことになるわけで…


論点はずらすにせよぼかすにせよ、その危険性を認識したうえで慎重に、というのが必要ですね。

激速心地の有頂天変

本日２回目の投稿。
明日までこのネタを取っておくのはもったいないので書いてしまいます。

GoogleのChrome（クローム）というブラウザをご存知でしょうか？
6/10に最新版が公開されたのですが、ふと気になってインストールしてみました。
実は筆者、以前（2009年前後）にもChromeをインストールしたことがありますが、その時（バージョン１か２の頃です）は大して感心しなかった記憶があります。
何というか、「劣化IE（インターネットエクスプローラ）」というレベルだったもので。

さて、今回インストールしたのはバージョン5.0.375.70（細かい数字は気にせず、バージョン５でOK)
それまでのバージョンとは異なり、MacとLinuxでも使えるようになったこのバージョン。
実はそれ以上に大きな差があったのです。
wikiより主な変更点を抜粋しますと…

～　主な変更点　～

Mac OS XとLinuxに対応。

JavaScriptが30%〜35%高速化。

Adobe Flash Playerの標準搭載および自動アップデート。 (10.1公開以降から)

Geolocation API、File ドラッグ＆ドロップ(HTML5)、Web Storage (sessionStorage)、Web WorkerでのWebSocket対応。

ブックマークだけでなく、ブラウザの設定の同期。

拡張機能のシークレットウィンドウでのオン・オフの選択。

～　主な変更点（終わり）　～

普通に使う人視点で翻訳しますと…

　～　主な変更点（翻訳版）　～

Mac OS XとLinuxで使えます

動きのあるページの表示や画面の更新が30%〜35%速くなります。

動画の表示に使うソフト（Adobe Flash Player）のインストールやアップデートを気にしなくてOKです。

開発者向けの話なので省略。（位置情報取得関数の標準装備、ファイルのドラッグ＆ドロップへの対応、データを溜めて処理を高速化、並列処理？？）

インターネットエクスプローラなどの設定やお気に入りをChromeでもそのまま使えます。

拡張機能のシークレットウィンドウでのオン・オフの選択。

　～　主な変更点（終わり）　～

すみません、最後のは翻訳出来ませんでした＾＾；

実際に使ってみると…

（筆者ブラウズ中……）

速い！

とにかく画面表示が速くなります。

インターネットを利用する場合、以下の手順を踏むのですが…

　利用者

　　↓

　パソコン

　　↓

　ブラウザ（インターネットエクスプローラなど）

　　↓

　電話回線など

　　↓

　インターネット

　　↓

　サーバ（複数のサーバを経由して辿り着いた、利用者が見たい情報のあるサーバ）

　　↓

　ホームページなど

今までのインターネットの高速化は「電話回線など（ADSLとか光回線とか）」に終始してきました。

（サーバはアクセスが集中しない限り速度に影響しません）

そして、動きのあるページ／動画の多いページの表示の際には電話回線などの高速化にプラスして「パソコン」の高速化が要求されました。

しかし、「ブラウザ」の高速化は遅々として進んでいなかったのが現状でした。

Chromeは「ブラウザ」レベルでの表示の高速化を行ってくれるのが画期的です。

いいことばかり書いてしまっていますが、これからChromeを使ってみて、業務に使えないか検証してみようと思います。

検証と言っても大したことをするつもりはありませんけどね＾＾；

尚、Chromeのダウンロードはここからできます。

GoogleのTopページからでもあまり迷わないと思いますが、念のためリンク張っておきますね。

情報は儚きソフトウェアの為に

タイトルにネタを盛り込みたい今日この頃。
元ネタがわかった方はお伝えください。口頭で一発で正解された方（先着一名）には銘茶一煎分を進呈します。

一昨日・昨日と将棋の名人戦第三局が行われていました。
棋界の第一人者：羽生名人に、あまり目立たないＡ級の常連：三浦８段が挑戦しているのですが…
羽生３：三浦０　という一方的な展開となりました。
尚、名人戦は７番勝負なので先に４勝したほうが勝ち。つまり、羽生名人の防衛にリーチですね。
２ちゃんねるで戦況の書き込みがリアルタイムで行われるのですが、その中に将棋ソフトでの解析結果を載せる人々が居ます。
チェスだと人間以上と評される「ディープ・ブルー (Deep Blue) 」が存在しました（現在は解体されています）が、トッププロに勝てる将棋ソフトは今のところないとされています。
解析結果を流し読みしてみたのですが…　ソフトがトッププロに及ばないせいか、または対局者が悪手・凡手を指しているからか、ソフトの解析結果と実際の棋譜は随分異なっていました。

ソフトは過去の戦例（棋譜）を元に先を読むものが多いようですが、今回の棋譜を並べてみると一般に重要視されているものとは異なる要素で勝敗が決したように感じます。
異なる要素、とは　「玉の広さ」とでも言うものです。
私自身専門家でもなければライトな愛好家レベルなので用語が異なっているかもしれませんが、平たく言うと、『王将が安全に動ける範囲の大きさ』のことです。
相手の駒はもちろん、自分の駒も王将の逃げ道を塞ぐことがあります。実際に私自身、王将の左側に矢倉の組みかけの銀・金が居て右から相手の飛車が…　即詰み　なんてこともありました。
この「玉の広さ」というのは、実はコンピューターで評価するのが難しい情報になります。
人間だと、視覚情報としてどこまで安全かが（ルールを知っている人なら）わかります。
しかし、コンピューターだとその判断には何手分かの読みが必要になります。
（実際には人間も読んでいるんですけどね＾＾；　大した読みではないことが多いので視覚情報のみで判断できることが多いです）

プロの対局は片方が詰まない形で、もう片方が詰む形になった時点で投了することが多いですが、詰む・詰まないを読みきるための情報をソフトに与えた時、コンピューターはトッププロと互角に戦えるのかな？　と思います。