中の人の徒然草379

こんばんは。読書三昧なインドリです♪
最近は堅い記事ばかりを書いていたから、今回は緩いものを書きます。
これは昨日の出来事なのですが、私は炬燵に入って本を読んでいました。
炬燵には魔性の魅力がありますよね。
炬燵に夢中な妹は、幸せそうな顔をして猫と一緒に寝ていました。
かくいう私もぬくぬくで、気持ちよく本を読み続けていました。

OSの世界に浸っていると、突然大きな物音がしたので、その方向をみました。
すると私の視界に、驚いた様子の猫と、妹が手握りしめて呻いている姿が映りました。
気になったので、どうしたのかと問いかけると、不思議な答えが返ってきました。
妹「私の手が、手が、手が！（途中聞こえない）に襲われたから・・・」
私「えっ？！何が手を襲った？」
妹「私の手が私の手を襲ったの。」
私「？？？どういう事だ？？？？落ち着いて話して。」
妹「あのね、兄ぃちゃん。私の手が暴走して、私の手とかに襲いかかってきたのぉ。」
私「そりゃ大変だ。そういえば、大きな物音がしたけど、それと関係あるのかな？」
妹「（恥ずかしそうに）う、うん。その音は多分、私が自分の手を壁にぶつけた音だと思うぅ・・・」
私「ぇ？自分の手を壁にぶつけたのか・・・」
妹「だってぇ、手が暴走するから、思わずやっちゃった・・・」
私「・・・変な夢見て、夢の中で暴れたら、実際に壁を殴ってしまったってこと？」
妹「そうみたい・・・まさか夢の中の行動が、現実とリンクしているとは思わなかった。それにしても手が痛い・・・」
私「また指の骨にひびが入っていたりして・・・」
妹「それ、嫌だなぁ。」

炬燵に魅入られた者には、何かが起こるのかもしれません。
皆さまも炬燵には要注意（笑）

実際のアジャイル開発

　今回はアジャイル開発の誤解で書ききれなかった事を書きます。アジャイル開発の経験者は知っていると思いますが、アジャイル開発で作られていない既存システムを、アジャイル開発でやり直すのは困難です。アジャイル開発をよく知らない人は、新規開発や受託開発はアジャイルに向かないと考えているようですが、事実はその逆です。
　ウォーターフォール開発モデルで作られたシステムの大半は、過剰装飾された文章が大量にあるだけで、肝心なユニットテストのコードがありません。この状態は、アジャイル開発の実践者にとって、最悪だと感じる状況です。レガシーコードと開発の役に立たない文章の山は、アジャイル開発の障害とすら言えるかもしれません。
　何故、テストコードがないレガシーコードが駄目なのかと言いますと、リファクタリングが出来ず、コードを把握するのに時間がかかるからです。この状態でアジャイル開発を行うのであれば、全てを捨て去り新規開発をした方がましだと考える人も多い事でしょう。かくいう私も、一度は新規からやり直す事を勧めます。しかし、大半の会社は捨てるのを惜しむので、その願いはかないません。ですから、アジャイル開発の実践者にとって嫌な状況なのです。
　特にC言語のレガシーコードは扱いにくい。Cのレガシーコードは絡み合っている事が多く、ユニットテストが行い難い厄介な代物です。この時点で、開発スピードが落ちる事が確定しています。アジャイル開発を知らない人は、普通の開発だと思うでしょうが、アジャイル開発で迅速に開発をしてきた者にとっては、苦痛以外のなにものでもありません。アジャイル開発は速いリズムが大事なのですが、それが崩されるので、作業進行が非常に鈍く感じて苦痛になるのです。
　では、アジャイル開発が既存のシステムの更新に向いていないのかと言いますと、そうではありません。レガシーコードは保守が高く付きます。レガシーコードを保持する会社は、知らないうちにコストとリスクを抱えている事になります。そのコストを、アジャイル開発をする事により軽減するのは、ビジネス的な観点から言っても合理的な行動です。全てのレガシーな生産物を、アジャイルなものに変える事は不可能ですが、徐々に変える事が出来ます。
　次に受託開発について言及します。結論から言いますと、アジャイル開発は受託開発に向いています。その理由は、アジャイル開発はコミュニケーションとフィードバックを重要視するからです。受託開発ではそれが可能なので非常に向いているのです。
　長くなったのでこれで終えますが、これからもアジャイル開発の本当の姿をお伝えしたいと考えております。

F#の列挙型とパターンマッチ

　F#はパターンマッチと、データ構造の使い型をセットで覚える必要があります。そこで今回は、列挙型の宣言とパターンマッチについて解説します。
　先ずは、F#で列挙型を宣言する方法をサンプルで示します。

//列挙型を宣言
type Number = 
  | One = 1
  | Two = 2
  | Three = 3;;

凄く簡単なので、列挙体を宣言はサンプルを見れば直ぐにわかると思います。
　今度は、この列挙型を使って、パターンマッチを行う関数を定義してみます。

let childCount x =
  match x with //定数パターンを行うmatch式
  | Number.One -> printfn "い～ち"
  | Number.Two -> printfn "にぃー"
  | Number.Three -> printfn "さぁ～～ん！"
  | _ -> printfn "分からないよぉ";;

この列挙型を使ったパターンマッチは定数パターンです。定数パターンについては、F#の定数パターンで解説しているので読んで下さい。この記事のサンプルと今回のサンプルを見比べると、列挙型を使った方が、プログラムの意図が分かりやすくなっているのが分かると思います。
　もしかしたら、この様な簡単なサンプルでは分からないかもしれませんが、列挙型は大変重要です。実務で定数パターンを扱う際には、直接数値を書くのではなく、列挙型を使用しましょう。列挙型を使用すると、プログラムの変更が行いやすく、可読性が上がります。例えば、60万行のプログラムを要するプロジェクトがあるとします。この状況下で、次に示すサンプルの様なプログラムが多ければ、プログラムの保守と変更がやり難くなります。

//数値を直接書いた酷いプログラム
let SelectAction x = 
    match x with 
    | 0 -> 
    | 1 -> 
    | 100 ->

let Foo x = 
    match x with 
    | 10 -> 
    | 20 -> 
    | 999 ->

let y = Foo 999;;

※このサンプルはコンパイルできません。
この調子で永遠とプログラムが続いていると、何をしているのか分かり辛く、プログラムの変更が困難になります。例えば、このサンプルで、Foo関数の999を333に変更する場合の事を考えてみます。この場合、全プログラムのFoo関数呼び出しの引数の値や、その数値を返す関数などを全てチェックして、漏れなく333に書き変えなくてはなりません。チェックが漏れると、プログラムが正常に動作しません。この作業は非常に退屈で、間違いが起きやすいので、列挙型を使う方が良いという事が分かって頂けると思います。
　定数パターンは列挙型と共に使用しましょう。

アジャイル開発によくある誤解

　アジャイル開発は未だに誤解される事が多いと感じます。そこで、今回はアジャイル開発の誤解を取り除くべく記事を書きます。
　アジャイル開発は、本当に大規模システムの開発に向いていないか？で、アジャイル開発が大規模開発で使えないという誤解について書きました。その他によくある誤解は新規開発に向かないというものです。
　私は新規開発と既存システムの革新に、アジャイル開発を使った事があります。その経験を踏まえて言うと、どちらも大差ないという事です。アジャイル開発は新規開発に向かないという人の意見を調べると、根拠として見切り発車を挙げています。しかし見切り発車は、現実を知らないウォーターフォール開発モデルのアーキテクチャもよくする事です。そもそも、システム開発は変化がつきものであり、どれだけ事前に準備をしても変化は起こります。ならば、初めから変化を受け入れるというのがアジャイル開発の本質です。その本質を理解していない人は、多くの誤解をするようです。
　しかし、だからと言って、見切り発車が良いと言っているのではありません。アジャイル開発に不慣れな人は、直ぐにコーディングを始めなくてはならないという誤解を持っていますが、決してそんな事はありません。そんな事をすれば失敗するのは当たり前です。私はビジネス特許関連の、全国規模の基幹系業務システムの開発を手掛けた事がありますが、その時もアジャイル開発を行いました。開発規模が大きくなると、コミュニケーションの重要度が増してきます。また、利害関係者の数に比例して、変化の発生率が高くなります。私が発案者だったので、多くの関係者が常に私に内容を聞いてくる状態でした。また、多くの要求とその変更が私に寄せられました。その状態でしたので、コミュニケーションを重視しない、ウォーターフォール開発を行う理由はありませんでした。これは、このケースに限った話ではありません。
　システム開発で重要なのは、核となる要望を聞き入れ、早期に動くものを見せて、フィードバックを得る事です。これは新規開発でも非新規開発でも変わらない事実です。この世は常に変化をし、誰もシステムの全容を把握していません。エンドユーザーは実際に稼働するシステムに触れ、自分たちの要望をはっきりさせていきます。それに加えて、よりよいものを人は求めます。ですから、仕様変更は悪ではなく、さらなるビジネスチャンスです。それに対応するのは、ビジネス的に考えても合理的な事です。
　システム開発の本質は変わりません。システムの核となる部分を見失わず、変化を恐れずに、人の役に立つシステムを作るのがシステム開発の本懐です。現状では、これを実現する方法はアジャイル開発しかありません。しかしそれは入口にしか過ぎません。アジャイル開発という言葉に縛られていては本末転倒です。アジャイル開発という言葉に惑わされず、常によりよい方法を追求する。それが我々開発者の役割です。物事の本質は実にシンプルなのです。

スレッド数決定問題5

　この記事は、スレッド数決定問題4の続きです。引き続き、並列処理における、生成スレッド数の決定問題を語ります。
　改めてスレッド数の問題を定義すると、ある時間内でスケジューリング対象となる、物理的なスレッドの数を決定する事です。「ある時間内」と「スケジューリング対象」いうのがポイントです。並列処理システムは時間が非常に重要です。直列的なシステムは、あまり時間に注意を払わない傾向があります。しかし、並列処理システムを同じ感覚で構築すると、パフォーマンスが悪く、バグが多いものになってしまいます。
　並列処理システムを設計する際には、処理が行われるタイミング・処理で使用する物理スレッド数・処理対象となるリソースを考慮して注意深く設計しなくてはなりません。この3つの要素が重要な理由は、処理時間が重なると物理スレッドの数が増加し、共有リソースに関する問題が発生するからです。例えば、処理Aと処理Bの処理時間が重なり、それぞれがCPUの論理コア数と同じだけ必要とする場合、重なった時間帯のスレッド数はCPUの論理コア数の2倍となってしまいます。この場合、想定したパフォーマンスよりも下がってしまいますし、デッドロックや優先順位の逆転などの並列処理特有の問題が発生する可能性もあります。
　プログラマは、自分が担当しているシステムの部分について、慎重に実装作業を行います。ですから、1つの処理単位で見れば、正しいものを実装するでしょう。しかしながら、正しい設計を行っていなければ、プログラマが予期しない問題を抱える事になります。その様なシステムは、長期間稼働した後に、色々なトラブルがエンドユーザーの元で発生します。これは避けるべき最悪の事態です。

　続く・・・

F#の定数パターン

　F#はパターンマッチが大事です。ですから、パターンマッチについて解説していきます。今回は一番基本的な、定数パターンについて書きます。
　定数パターンを簡潔に言うと、指定された値にマッチする処理を行う事です。他言語の使用経験がある人は、switch文やSelect Case文を思い浮かべるとよいでしょう。

//数を覚えている途中の幼児
let childCount x =
  match x with //定数パターンを行うmatch式
  | 1 -> printfn "い～ち"
  | 2 -> printfn "にぃー"
  | 3 -> printfn "さぁ～～ん！"
  | _ -> printfn "分からないよぉ";;

//いくつまで数を数えられるかな？
let a = childCount 1
let b = childCount 2
let c = childCount 3
let d = childCount 4;;

子供が一生懸命に数を覚えている様子をサンプルプログラムにしました。この子供は幼いので、まだ3までしか数えられません。このサンプルを見れば、定数パターンのイメージがつかめると思います。1～3の処理については問題がないと思います。最後の_（アンダーバー）は、ワイルドカードパターンです。
　ワイルドカードパターンは、任意の値にマッチします。このサンプルの様に、想定している値以外を表すのに使う場合が多いです。また、任意の値のみ処理をする場合、ワイルドカードパターンは必須です。試しにワイルドカードパターンを消して実行してみて下さい。警告25（FS0025）が表示されるはずです。
　F#コンパイラは、match式で想定される全パターンが、指定されているのかチェックしてくれます。もし警告を無視して関数を無理やり束縛し、予想外の値を指定して実行すると、マッチが失敗してMicrosoft.FSharp.Core.MatchFailureExceptionがスローされます。基本的に警告を無視してはなりません。

参考資料：プログラミングF#

中の人の徒然草378

こんばんは。今日も元気なインドリです♪
今日はなんとなく、言語を女性にたとえてみようと思いました。

• C：C姉妹の長女。モダンな技術は持っていないが、時間を問題にしなければ何でもこなせる。性格は大らかで従順。職業は自営業。最近はもっぱら社会基盤の構築（OS）と、人員育成（コンパイラ）に力をふるっている。大らか過ぎて、番地に関するトラブルを起こしやすいのが玉にきず。人を信じやすいのが原因かもしれない。　
• C++：Cの妹。職業弁護士のツンデレ女性。有能で殆どのシステムを作れるが、真面目すぎて融通が効かないので、予期せぬトラブルが起こる事も・・・。その一方で、抽象的な事も得意とする意外な一面も持つ。「細かい事を言うのは、貴方のためなんかじゃないんだからね！」
  
• Java：C++の妹。細かい性格で、時には危険な事をする姉C++に反発し、無難で堅実な性格になった女性。C++と大喧嘩した事もある。職業は普通のOL。
  
• C#：C++の親戚。大学を卒業してまだ間がないので、柔軟で今時ふうの女性。オブジェクト指向に拘らない技能を習得している。職業は派遣社員。
• VB：親切さがうりの高校教師。親切すぎて、多くの事を聞いてくるため、C姉妹が好きな人には嫌われるかもしれない。「改行する時はアンダーバーって言ってね」
  
• LISP：偉大なる思想家。彼女と話した者は、新しい考え方を持つだろう。
  
• Scheme：LISPの妹。年は余り離れていない。大学教授をしており、彼女の授業「計算機プログラムの構造と解釈」は有名である。口癖は「以下同文」と「続けます」。
  
• Haskell：職業科学者。必要な事しかしないものぐさな女性。純粋で答える事以外の事が嫌いなので、圏論の考えを取り入れて行動し、返事をする事以外は極力見せないようにしている。
  
• OCaml：有能な秘書。状況に応じて、色々な対応をする事が出来る。行動派の女性が多くいるが、彼女は事前に仕事を見極めて注意をする事が出来る。
  
• F#：OCamlの妹。彼女もまた秘書である。不景気な故か、翻訳家もぼちぼちしている。
  
• Erlang：女性グループ名。離れたところでも同時に仕事を展開するのが得意。
  
• Perl：便利屋さんをしている女性。多様性を好み、「やり方は一つじゃないわ」が口癖。最近Parrotに住む事を決めたらしい。
  
• Ruby：便利屋さんをしている女性。柔軟で簡潔な事を売りにしている。
  
• Python：陽気でお笑い番組「空飛ぶモンティ・パイソン」が大好きな公務員。彼女が作った書類は、見やすいので好評である。
  
• PHP：海外事業部で働いている女性。他の女性とは違い、仕事範囲が明確に決まっている。生涯海外事業部で働くであろう。書類整理が得意。
  
• JavaScript：デザイナ。彼女のお陰で店の見栄えが良くなったと好評である。名前が似ているので誤解されやすいが、Javaとは赤の他人である。
  
• Scala：Javaと同居している庶務課で働いている女性。その器用さが売りである。
  
• Clojure：Javaと同居している謎の女性。LISPの子供だと言われている。得意技はSTM。
  
• SQL：資料整理を生業としている女性。情報基地内では彼女の右に出るものはいないと言われている。しかし彼女本人は色々な悩みを抱えている。FROM句を一番先にしておいた方が良かったと後悔している。
  
• OZ；魔法使い。何でも出来るであろう万能性を持つ。
  
• Prolog：理屈屋ぽい僧侶。その独特さから嫌われる傾向があるが、極めて優秀である。意見を統一化する事を信条としている。
  

スレッド数決定問題4

　この記事は、スレッド数決定問題3の続きです。引き続き、並列処理における、生成スレッド数の決定問題を語ります。
　バッチ処理では、CPUのコア数よりも少し多くのスレッドを多く生成するとよいと書いた理由は、もうひとつあります。それは、大量のデータを処理する場合、少数のスレッドに任せると、何度もクオンタムを使いきってしまうからです。ラウンドロビンスラケージュラで、クオンタムを使いきると、公平にCPUを使用する為に、他のスレッドに実行する権利が渡されてしまいます。そうすると、何回もコンテクストスイッチ（コンテキストスイッチとも呼ぶ）が発生しますし、他のスレッドがCPUを使っている間、バッチ処理を行うスレッドは待たなくてはなりません。この状態になると、単位時間当たりのデータ処理件数が減ってしまいます。処理するデータ量も考慮し、スレッド数を決定しなくてはなりません。
　対話処理の場合は、スレッド数はコア数よりも少しすくなくする必要があります。何故ならば、対話処理に於いて最も重要なのは、応答時間だからです。常にCPUのコア数と同じだけスレッドによる処理が行われていると、ユーザーは応答性が悪いシステムだという印象を持ちます。そういった印象はマイナス評価に結び付きます。常にCPUのコア数と同じだけのスレッドを生成するのではなく、ユーザーに応答する為のスレッドを生成する余地を残しておかねばなりません。そうする事により、直ぐに応答できるシステムとなり、ユーザーの印象が良くなります。
　察しがいい人は気付いたと思いますが、こうした事から、並列処理システムを構築する場合、システムの特性と局面を見極め、無計画にスレッドを生成してはならないと言えます。もちろん、直列的システムでも設計は重要ですが、並列処理システムはそれ以上に重要なのです。他にも語るべき事がありますが、長くなったので終わります。

続く・・・

F#の勘所

　みんな、F#で遊んでいるかな？難しい事を考えなくても、素直になればF#は難しくありません。F#を知れば、新しいプログラミングスタイルを楽しめます。だけど、命令型言語に慣れた人にとっては、とっつきにくいのも事実だと思います。そこで、今回は、F#の萌えポイント（注目するべき特徴）について書きます。
　F#は関数型言語です。ですから、関数をファーストクラスオブジェクトして扱うのが特徴です。ここが分かり難いという人は、データと関数は殆ど同じという事を思い出して下さい。プログラムは0と1の羅列です。そもそも、コンピューターに、関数とデータの区別はありません。人間が0と1をデータとして扱えばデータ、関数として扱えば関数というだけです。そう考えれば、引数として関数を渡す事も、戻り値として関数を返す事にも違和感がなくなります。
　でもそれはF#に限った話ではなく、関数言語共通の事柄です。F#にもやはり特徴があります。それは、パターンマッチです。パターンマッチの使い型を覚えれば、F#プログラミングが快適に出来るようになるでしょう。パターンマッチを学習する際には、リスト・シーケンス・判別共用体といった、データ型をセットで覚えましょう。アルゴリズム＋データ構造＝プログラムなのでこれは問題ないはずです。
　最後に、F#を習得する上でバイブルと呼べる本を紹介します。現在バイブルと呼べる本は、F#開発チームのChris Smith（クリス・スミス）氏が著したプログラミングF#です。この本はとても分かりやすくてお勧めできます。MSDNを読むよりも早くF#を習得できるはずです。

スレッド数決定問題3

　この記事は、スレッド数決定問題2の続きです。引き続き、並列処理における、生成スレッド数の決定問題を語ります。
　前回述べたように、コア数と同数のスレッド数が基本ですが、これはあくまでも基本です。並列処理システムを構築する際には、より深く考えなくてはなりません。先ず考えるべき事は、システムの特性です。
　システムの特性を大別すると、大量のデータを処理するバッチ処理と、ユーザーの指示に基づき、少量のデータを処理する対話処理に分類できます。バッチ処理か、対話処理なのかによって、最適なスレッドのあり方は事なります。システム規模で考えた場合、大概は2つの側面を共に持っていますが、重視する目的と局面により、処理特性が存在していますので、分類に従って検討する事が出来ます。
　バッチ処理の場合、データ処理件数が重要です。つまり、短時間でどれだけ大量のデータを処理する事を重要視します。この場合、データの並列処理という形が最適です。データの並列処理とは、大量のデータを複数のスレッドに分割して、並列処理を行う並列処理の方式です。データの並列化を行う事により、単位時間当たりのデータ処理件数を増やす事が出来ます。
　データの並列処理を行う際には、スレッド数はコア数よりも少し多くする方が良い場合も多々あります。この理由は、OSのスケジューラの動作原理にあります。前にも述べましたが、OSごとにスケジューラは異なります。しかし、基本思想は似ております。
　現代的なOSは、基本的にラウンドロビンスケジューラをもとに改良を加えたスケジューラを使用しています。簡潔に言うと、ラウンドロビンスケジューラとは、スレッドまたはプロセスに、クォンタムと呼ばれる実行を許可する一定の時間間隔を割り当てる方式のスケジューラです。時間を使いきったスレッドは、たとえ処理途中であっても停止され、違うスレッドが実行されます。こうする事により、飢餓状態（常に実行をまっている状態）になるスレッドを無くし、公平に処理が実行されるようになります。
　ラウンドロビン法による公平なスケジュールは、汎用目的には良いものです。しかし、バッチの処理の場合、とにかく処理件数を上げるのが目的となりますので、如何にして多くのデータを処理させるかが問題となります。公平にスケジュールされると、データを処理しないスレッドの実行権が渡されますので、これを如何にして避けるかが課題となります。そこで、考えられる一つの方法として、スレッド数を少し多く生成し、CPUが割り当てられる確率を増やす事が考えられます。例えば、実行可能状態スレッドの数が10で、データを処理するスレッドが1つだけの状態ならば、選ばれる確率は10％です。選ばれなければ、処理は実行されず、単位時間当たりのデータ処理件数が減ります。そこで、データを処理するスレッドを5個に増やせば、選択される確率が約35.7％に上昇します。選択される確率が増えれば、単位時間当たりに処理できるデータ数がアップします。
　具体的に、バッチ処理で、どれぐらいのスレッド数を割り当てるかについては、分割によるオーバーヘッドを考慮して決める事になります。前にも述べましたが、並列アルゴリズムは、直列アルゴリズムと比べると、余分な処理が必要となります。ですから、多く分ければ分けるほど、そのオーバーヘッドの割合が大きくなります。オーバーヘッドが大きくなりすぎれば、余計にデータ処理件数が減ります。従って、実際に測定しながら、最適なスレッド数を微調節する必要があります。
　長くなったので続く・・・