fc2ブログ

アジャイル開発と契約6

 この記事はアジャイル開発と契約5の続きです。前回は品質保証について言及して終わっていましたので、品質保証についての事柄を書きます。
 一般的に、ソフトウェア/システムの品質保証内容は、機能保証性能保証権利保証の3つの保障を指します。この内、最もなじみ深いのが機能保証です。
 機能保証は大まかに言うと2つの事柄を指します。それは、仕様通りの機能を備えているという保障と、納品物が物理的に壊れていない事の保証です。まれに、取引契約でこの様な保障を交わさない場合もありますが、提供者(ベンダ)はソフトウェア/システムを完成する履行義務を負っているとみされますから、仕様を満たさない製品を納品すると、義務違反とみされてユーザーから訴えられる可能性があります。世の中の動きを考慮すると、今後告訴が増加する事が予測できますので、機能保証は非常に重要だと言えます。
 機能保証を考える上で、もっとも考えなくてはならない事がバグの存在です。バグがあると機能保証を満たさない事になります。しかしながら、バグが存在しない情報システムは存在しないと言われております。実際、広範囲の意味でのバグを0にするのはほぼ不可能だと言えます。ですから、その事を考慮したうえで基本契約を結ぶ必要があります。
 アジャイル開発を行うと、テストファーストもしくは迅速に対処しながら開発を進めますので、狭義のバグは少なくなります。しかし契約時には、フリーソフトとプラットフォームのバグについても考慮しなくてはなりません。購入者にはバグの見分けがつきませんので、あらかじめてはっきりしておかないと全てベンダの責任となってしまいます。また、ユーザーが要求をはっきりと行わない為に発生するバグもありますから、十分な注意が必要です。その事を良く考えずに、機能保証を安請負すると、後で深刻なトラブルが発生します。  

テーマ : ソフトウェア開発
ジャンル : コンピュータ

アジャイル開発と契約5

 この記事はアジャイル開発と契約4 の続きです。今回は、基本契約の重要な要素である、瑕疵責任について書きます。
 瑕疵責任と聞けば身構える人が多い事でしょう。しかし、アジャイル開発を採用すると、ウォーターフォール開発モデルよりも有利な点があります。それは、瑕疵の影響を軽減出来る上に、瑕疵の定義を明確化できる点です。
 従来のウォーターフォール開発モデルでは基本的に、要求定義→外部設計→内部設計→実装→テスト→検品→納入の様に一直線に開発されます。それ故、エンドユーザーが望んだものとの乖離が生じやすく、提供する製品やサービスの瑕疵を生みます。今までは、エンドユーザーが情報処理技術に弱く、日本の法律が整備されていないので法的問題に発展しにくく、あまり大きな問題になる事がありませんでした。また、ベンダとエンドユーザー共に、エラーに対する許容度が高く、瑕疵担保期間を設け、一定期間瑕疵に対応する事により許してもらえるケースが大半でした。しかし、瑕疵に敏感になっている世の中の流れを考えると、それは今後通用しないと考えるのが妥当でしょう。ここで重要となるのが、瑕疵を生む要因・瑕疵の定義・責任範囲の3点です。
 瑕疵は主に、ベンダとエンドユーザー間のコミュニケーション不足が原因で発生します。ベンダはエンドユーザーの業務と内部事情に関する完全な知識は持ちません。一方エンドユーザーも情報処理技術に関しては殆ど知りません。その双方がやり取りをするのですから、完璧な要求定義が出来ないのは当然の事です。完璧な要求定義が出来ないのですから、瑕疵が生まれる土壌がプロジェクト開始前から既に出来ていると言っても過言ではありません。この状態で、瑕疵に厳しい世の中で商売をするのは無謀です。瑕疵を生む原因を極力排除しなくてはなりません。それを行うのがアジャイル開発なのですが、契約時にちゃんと考えておかないと十分な効力を発揮しません。しかしながら、現状は瑕疵の定義も曖昧なまま契約するケースが多々あります。
 瑕疵とは、国語辞典によると「完全な条件を欠いている状態」です。一般的な情報サービスもしくは製品で言う所の「完全な条件」とは、あらかじめ契約した品質を満たす条件です。契約時の品質保証を満たしているか否かと考えるとよいでしょう。

続く・・・

テーマ : ソフトウェア開発
ジャンル : コンピュータ

中の人の徒然草374

おはようございます。秋は読書派のインドリです♪
今月末に凄い本が出版されます。



これは凄い!コンパイラ好きならば飛びつく本です。
他に気になる本といえば、こちらの方はまだ買っていないので、今財布と相談しているところです。



購入予定の本がまだあるので買えないorz
こっちの方はWindows系の仕事が多いので購入しました。



この本は凄くお勧めです。凄く分かりやすい本で、サクッとF#について分かります。違う関数型言語を使用した経験のある人ならば、この本1冊で直ぐに開発出来るでしょう。
私は3時間未満で速読完了して、手ごたえを感じました。この本で、業務系システムの開発は出来そうだから、後は、コード引用符やPowerPackをじっくりとつついたらF#はOKになりそうです。この2つの説明がもっと深ければ、最高だったんだけどな。後はF#のソースコードと生成されるILを読もうと思います。
F#といえば、相互再帰関数の言語設計に感動しました。Scalaにて末尾再帰の限界について吃驚した事がありましたので(参考資料Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala) )、命令型言語を念頭に作成された仮想マシンは再帰関数をまともに扱えないのかと思っていました。
しかし、F#は相互再帰関数をちゃんと実装しています。どういう風に実装しているかは、今後生成されるILを読むまで何とも言えませんが、仮想マシンに一筋の希望が見えました。
F#の相互再帰関数から考えてみれば、プログラマの意図さえ組み取れれば、別に末尾再帰は難しくないと思います。末尾再帰というのは、スタックを使用した関数呼び出しをgotoを使ったものに変換しているだけです。goto文に変えるのは、別にどのような仮想マシンでも出来そうだから、今後より関数プログラミングが出来る環境が整うでしょう。相互再帰の様な文法が増えれば、関数プログラミングの世界が開けそうです。
関数型のサポートといえば、C#でも関数内に関数を定義したいな。ラムダ式と匿名関数がありますが、F#の様に自然な形で、関数内で関数を定義できません。privateにしても、一つの関数でのみ使用する関数を定義するのは美しくないし、保守の事を考えると望ましくありません。余計なヘルパー関数を外に出したくないから、関数内で関数を定義したいです。

テーマ : 裏事情
ジャンル :

ネタつつき85-エンドユーザーは何故過剰要求するか?

 エンドユーザーは要求がすぐ変わる、追加注文が多い・・・等と言った事をよく見聞きしますので、今回はその事について書きます。結論から言いますと、それは当然の結果だと言えます。何故ならば、日本の商習慣が「お客様は神様だ」を基本としている上に、情報産業がコストベース型の労働集約型産業だからです。
 これはエンドユーザーの立場になってみれば分かる事ですが、サービスではなく労働力(人)を売っているので、注文を後で言った方が有利になります。日本の情報産業は、サービスの内容ではなく、人月単価の労働力を売っております。情報システムの販売は、事前にコストの見積もりを立てて、金額を算出して契約します。
 これをエンドユーザーの立場で考えてみましょう。エンドユーザーにしてみれば、よくわからないものを人が100人、10か月必要だから○億万円などと言われているわけです。よく分からないものに多額のお金を支払うわけですから、如何にして価値のあるものを買うのかをエンドユーザーは考えます
 よく分からないものを買うわけですから、先ずは相手の出方を見る事になります。そうすると、往々にして自分が考えたものとは違う製品である事が分かってきます。多額のお金を支払うわけですから、当然エンドユーザーは製品が違う事に異議を唱えます。そうすると、開発側にしてみれば要求が変わったように見えます。
 次に、労働力(人)を売っている点がポイントです。エンドユーザーにしてみれば、サービスを売っているのではなく、労働力(人)を売っているので、追加注文をするのに心理的抵抗もなければ、お金を支払う側の当然の権利だと考えます。買っているのはサービスでなく労働力(人)なのですから、労働力(人)が変わらなければ、追加注文しても販売価格は変わらないはずです。
 私は開発側の人間なので、こうしたエンドユーザーの態度は好ましく思いませんが、エンドユーザーの立場でものを考えれば当然の結果というしかありません。この問題の解決法は、情報産業の構造が進化するしかありません。そうしないと、双方不幸になるだけです。

テーマ : 情報処理技術
ジャンル : コンピュータ

アジャイル開発と契約4

 この記事はアジャイル開発と契約3 の続きです。前回はアジャイル開発の問題点を挙げましたので、今回はアジャイル開発と、バリューベース型価格決定法のメリットについて書きます。
 アジャイル開発と、バリューベース型価格決定方式の組み合わせで、得られるメリットを大まかに言うと、コストと価格を分離できる事と、回転率を上げる事が出来る事です。この2点は商売に於いて大変重要な事であり、非常に大きなメリットだと私は考えております。
 情報産業は他の産業と比べるとまだまだ未成熟です。開発方法論や市場が未発達で、手探り状態での開発が余儀なくされました。そもそも、ウォーターフォール開発モデルで、バリューベース型価格決定方式を実施するのは無理があります。
 バリューベース型価格決定法で商売をするには、提供できるサービスの質を維持する必要があります。しかし,昔は開発方法論が未成熟で、ソフトウェアの品質はもちろんのこと、サービスを一定水準に保つ事が不可能に近い状態でした。また、ウォーターフォール開発モデルが全盛期の時代は、サービスを作成するノウハウもまだ確立されておらず、全てがオーダーメイドの製品でした。むろん技術者個人ではノウハウを持っておりましたが、開発全体でのノウハウの共有には至らない状態でした。そして、お客様もそれを容認している良い時代でした。
 古き良き時代は過ぎ去りました。全てが目まぐるしく変化し、お客様もより高い品質を求めます。そして、技術もそれに伴い発展してきました。今では、労働集約的な古い商売法は通用しません。変化する世の中に合わし、より早く、より良いものを作らないと市場から淘汰されます。これは、情報産業がやっと他の産業に追い付いた証拠であり、喜ぶべき事です。
 ウォーターフォール開発モデルとコストベース価格決定方式の組み合わせでは、今の世の中は生き残れません。何故ならば、人件費を中心とした労働集約型産業になり、生産性の向上にも限界があるからです。コストと利益が分離されていない状態ですので、コストがなければ高い売上が算出できない矛盾した状態に陥ってしまいます。コストを低く、売上を高くしようとすれば、事実を捻じ曲げてコストを架空計上しなくてはならないので、お客様を騙すしかありません。お客様を騙すのが嫌ならば、下請けにコストを押し付け、上前をはねる、社員にサービス残業を強要する・・・などといった非人道的手段しか利益を出す方法がありません。それは商売以前の問題です。他にも、人件費が高くなりすぎる、生産速度が低下する、回転率が悪くなる・・・等と言った経営上の問題が発生します。従って、コストベース型価格決定方式は、産業が未発達な状況下で仕方なく使用する価格決定法だと考えて良いでしょう。
 これは、10年以上前に既に言われている事です。この未発達の商売が通用していたのは、日本国内の市場だけで利益を上げられたからです。ですが、もう国内だけでは限界であり、国際市場を視野に入れないと生きていけない時代に突入しております。コストベース型価格決定法とウォーターフォール開発モデルの古い組み合わせでは、バリューベース型価格決定法とアジャイル開発が基本の海外企業に勝てず、遅くて人件費が高い状態では国際市場はもちろんのこと、目が肥えた国内市場でも通用しません。
 バリューベース型価格決定法とアジャイル開発の組み合わせは、今の時代必須だと言えるかもしれません。

続く・・・

テーマ : ソフトウェア開発
ジャンル : コンピュータ

VB.NETにあるモジュールとは何か?

 VB.NETから始めた人は、Moduleとクラスの違いが分からないと思います。そこで今回は、VB.NETのモジュールについて解説します。

Module Module1

    Sub Main()

    End Sub

End Module

 VB.NETを使用した事がある人は、このプログラムを目にすると思います。しかしながら、有名なのにも関わらず、意外とモジュールの正体を知らない人は多いと感じます。モジュールを一言で表現すると、グローバル関数の寄せ集めたものです。モジュールはオブジェクト指向の要素ではなく、構造化プログラミングの要素です。
 モジュールはオブジェクト指向の要素ではないので、クラスとの違いはそこにあります。例えば、モジュールはクラスの継承とインタフェースの実装が出来ません。次のプログラムはコンパイルエラーになります。

Class SampleClass
End Class
Interface ISample
End Interface

Module Module1
    Inherits SampleClass
    Implements ISample

    Sub Main()

    End Sub

End Module

「エラー1 'Inherits' は、モジュールでは有効ではありません。」、「エラー2 'Implements' は、モジュールでは有効ではありません。」の2つのエラーが発生します。既存クラスの継承が出来ないのは納得がいくが、インタフェースが実装できないのは納得いかない人もいる事でしょう。インタフェースが実装できない理由は、モジュールはグローバル変数の集まりなのでインスタンスを生成できないからです。インスタンスを生成しようとすると、「モジュール '' を型として使用することはできません。」と、コンパイルエラーが発生します。
 この様に、何かと制限が多いモジュールですが利点もあります。

Class SampleClass
    Public Shared Sub ClassMethod()
    End Sub
End Class

Module SampleModule

    Sub ModuleMethod()
    End Sub

    Sub Main() 
        'クラスの共有メソッドは、クラス名を指定する必要がある。
        SampleClass.ClassMethod()
        'クラスとは違い、名前を指定する必要がない。
        ModuleMethod()
    End Sub

End Module

このサンプルで示したように、モジュールは名前を指定せずにプロシージャを呼び出せるという利点があります(※ILではモジュールでも名前が指定されています)ただし、同じプロシージャを持つモジュールが複数ある場合、呼び出すプロシージャを一意に決定できないので、コンパイルエラーが発生します。注意して下さい。
 非常に紛らわしい事に、この規則も例外があります。次の場合は、コンパイルエラーになりません。

Imports System

Friend Module Module1
    Sub Method()
        Console.WriteLine("Module1のメソッド")
    End Sub

    Sub Main()
        Method()
    End Sub

End Module

Module Module2
    Public Sub Method()
        Console.WriteLine("Module2のメソッド")
    End Sub
End Module

この場合、Module1のMethodが呼び出されます。このコードは紛らわしく、保守性を下げます。従って、コード量を減らす為だけにモジュールを乱用してはならないと言えます。
 モジュールの本当の利点は、クラスでない事を明示できる事です。オブジェクトで表現するのが不適切な要素がある場合、モジュールは設計意図を明確化するのに役立ちます。例えば、Mainプロシージャは、オブジェクトに属するメソッドではなく、ただの関数と考えた方が自然です。
 最後に.NETはモジュールをどのようにして実現しているのかを書きます。実のところモジュールは、Microsoft.VisualBasic.CompilerServices.StandardModuleAttributeを指定したクラスです。モジュールはVB.NET言語だけのものではなく、C#やF#といった他の.NET系言語でもMicrosoft.VisualBasic.dllを参照して、クラスに属性を指定すればモジュールが宣言できます。

テーマ : プログラミング
ジャンル : コンピュータ

VB.NETのエントリポイント(Mainプロシージャ)

 今回はVB.NETのエントリポイント(Mainプロシージャ)について解説します。
 開発環境が初めに自動生成するのが次のコードです。

Module Module1

    Sub Main()
    End Sub

End Module

 このプログラムが、アプリケーションの開始地点となります。Mainプロシージャはこれ以外にも、いくつかの宣言方法があります。何パターンも考えられますが、違いを生む要因は3つで、その要因を組み合わせる事により、Mainプロシージャの宣言に違いをもたらします。
 1つめは、クラスとモジュールのどちらを使うかです。開発環境はモジュール内でMainプロシージャを宣言をしていますが、クラス内でMainメソッドを宣言してもコンパイルできます。

Class Module1

    Shared Sub Main()
    End Sub

End Class

Mainメソッドの宣言で、Shared修飾子を指定する理由は、エントリポイントはインスタンス単位にあってはならないからです。では、何故モジュールではShared修飾子を指定しないのかと言いますと、モジュールの全てのメンバは暗黙的にSharedが指定されているからです。
 2つめは、プログラムの終了コード値を返すか否かです。プログラムの終了コードを返す事により、プログラムをテストする事が出来ます。任意の終了コードを返したい場合は、SubではなくFunctionとしてMainプロシージャを宣言します。

Module Module1

    Function Main() As Integer
        Dim flag As Boolean = True
        If flag Then
            Return 0 '成功
        Else
            Return 1 '失敗
        End If
    End Function

End Module

この例の様に、プログラムが成功ならば0、失敗したら0以外の任意の数値を返します。なお、エラーを表す値の意味については人が定めます。開発するアプリケーションの仕様に基づいて、適切な終了コードを定義して下さい。定めたエラーコードは、列挙型で宣言しておくとよいでしょう。なお、終了コードを返すには、System.Environment.Exitメソッドを使用する方法もあります。
 3つ目は、コマンドライン・パラメーターを宣言するか否かです。コマンドライン・パラメーターを使用したい場合、Mainプロシージャで引数を宣言します。

Imports System
Module Module1

    Sub Main(ByVal args As String())
        'コマンドライン・パラーメーターを表示する
        Console.WriteLine("コマンドライン・パラーメーターを表示します")
        For Each arg In args
            Console.WriteLine(arg)
        Next
        Console.WriteLine()
    End Sub

End Module

ただし、コマンドライン・パラメーターを取得する方法はこれ以外にもあります。VB特有のCommand関数を使用すると、コマンドライン・パラメーターを1つの文字列として取得できます。1つの文字列として取得したくない場合は、My.Application.CommandLineArgsプロパティを使う方法と、System.Environment.GetCommandLineArgsメソッドを使用する方法があります。

テーマ : プログラミング
ジャンル : コンピュータ

アジャイル開発と契約3

 この記事はアジャイル開発と契約2の続きです。今回は、バリューベース価格決定方式の事柄について記述します。
 前回書いたように、アジャイル開発ではバリューベース価格決定方式にするべきです。これ以降、バリューベース価格設定方式を前提に話を進めます。
 基本契約を結ぶ際に、価格設定を明確化し、開発関係会社はもちろんのこと、エンドユーザーの同意を得る必要があります。アジャイル開発は、エンドユーザーも積極的に参加しなくてはなりません。契約時からエンドユーザーに参加意識を持ってもらいましょう。この時注意しなければならないのは、価格設定の説得力です。開発前にエンドユーザーに不信感を与えないように、客観的に見て納得がいく価格設定でなくてはなりません。納得がいかない価格設定により、エンドユーザーに不信感を与えてしまうと、たとえ契約が結べても上手くコミュニケーションがとれず、開発が失敗する恐れがあります。初めの印象は大切なので、あらかじめ価格設定はよく考えておく必要があります
 他にも価格設定には注意するべき点があります。それは、あらかじめ開発コストの監視体制を整えておくべきだという事です。バリューベース価格決定方式を採用しても、開発コストを詳細に把握する事が重要です。誤解する人がいるのですが、バリューベース価格決定方式で商売をする事を目指しても、コスト意識を疎かにしてはなりません。コストを把握せねば経営はうまくいきません。アジャイル開発を商売として成功させるには、適切な価格設定と適切な開発体制が必要です。
 アジャイル開発特有の問題として、コストが把握しにくい事が挙げられます。ウォーターフォールモデルでは、開発工程を厳密に区切るので、コストの見積もりは比較的容易です。しかし、アジャイル開発では、コストが分散して発生するので、従来よりもコストが把握しづらくなります。アジャイル開発はコストを管理する体制が重要だと言えます。コストをよく把握し、開発会社にとっても適切な価格設定にしなくてはなりません。
 あらかじめ価格決定設定を熟慮し、基本契約で価格設定をについての条項を設けましょう。後で個別契約する際に、揉めることなく、スムーズに契約金額を交渉できる基盤を整える事が肝心です。価格設定についての契約をおろそかにすると、開発どころでなくなります。
 続く・・・

テーマ : ソフトウェア開発
ジャンル : コンピュータ

VB.NETのコメント

 コメントは地味ですが、プログラミング言語の特色が表れています。

Module Module1

    Sub Main()
        '単一行コメント
        REM これもコメント
        REM 複数行可能? _ 
            ここはコメント?
    End Sub

End Module

 VB.NETは「’」でコメントを指定します。さらにREMステートメントでもコメントを記述できます。ステートメントならば、行連結文字( _ )を使って、複数行を指定できると思いがちですが、残念ながらコンパイラはエラーを出します。
 ちなみに、REMはRemark(コメント行)を表すBASIC言語の予約語です。歴史を感じますね。

テーマ : プログラミング
ジャンル : コンピュータ

アジャイル開発と契約2

 この記事は、アジャイル開発と契約1の続きです。今回は基本契約について書きます。
 アジャイル開発は、ウォーターフォールモデルとは違い、比較的短い期間で結果が出ます。また、ユーザーが積極的に介入する事により、開発対象となるシステムが変化します。従って、ウォーターフォールの様に、一度の契約で全てを決定する方式は向きません。それで、個別に期間ごとに契約を結ぶのが自然なのですが、期間ごとに白紙から契約を結んでいてはコストがかかり過ぎます。そこで、各契約の基本となる契約を定義します。
 基本契約では、契約に関する共通事項を定めます。具体的には、「知的財産の扱い・瑕疵責任・責任範囲・価格の算出法・セキュリティに関する事柄(個人情報の取り扱いなど)・再委託の有無・紛争を解決する仲裁機関・訴訟の必要が生じた場合の管轄裁判所」が基本契約で決定するべき事項です。プロジェクトによっては、まだ他にもありえますが、きりがないので一般的な事例のみを考慮して話しを進めます。なお、納期については、アジャイル開発の性質上変化しやすく、正確に見積もるのは不可能です。納期については事前に厳密な契約を結ばない方がいいでしょう。その様な事をすると、後々トラブルの元となります。
 これらの事柄の中で、アジャイル開発で特に注意するべき事項は、価格の算出法・瑕疵責任・知的財産の取り扱いの3点です。これから順番に、この3点について解説していきます。
 価格の算出法は、大別するとコストベース型とバリューベース型の2つが存在します。コストベース型とは、開発側のコストを基準として価格を決定する方法であり、日本では一番多く採用されています。悪名高い人月単価は、コストベース型に属しています。一方、バリューベース型とは、実現した価値により価格を設定する方法です。例えば、品質・稼働率・初期不良対策・連絡体制・障害対応体制などが、バリューベース型で基準となる項目です。アジャイル開発では、その性質上バリューベース型が適しています。何故ならば、アジャイル開発は迅速に開発する事が本懐ですので、開発時間が短くなりなり、コストを価格基準とするコストベース型だと、価格が下がってしまうからです。売上が下がるのを喜んで行う会社が存在するとは思えませんので、バリューベース型価格決定方式が最適だと言えます。
 続く・・・

テーマ : ソフトウェア開発
ジャンル : コンピュータ

プロフィール

インドリ

Author:インドリ
みなさん、はじめまして、
コンニチハ。

ボクは、無限の夢(infinity dream)を持つネタ好きな虹色の鳥インドリ(in dre)です。
色々な情報処理技術を啄ばむから楽しみにしてね。

http://twitter.com/indori
は別人による嫌がらせ行為です。
私とは関係ないので注意して下さい。
次はなりすましブログなどをするかもしれませんが、ここ以外でブログをするつもりがないので、ここ以外にインドリのブログがあったとしても無視してください。


何度言っても分からない人がいるので、ここにコメント欄へ書き込むときの注意事項を書きます。


一、社会人としてのマナーをわきまえましょう。
一、妄想に基づく書き込みを止めてください。
一、暴言の類は書かないで下さい。
一、某誹謗中傷サイトの書き込みは彼らの妄想に基づく書き込みですから無視して、ここへ書き込まないで下さい。
一、コメント書く前に他のコメントよく読んでから行って下さい。
一、言いがかかり等の行為を禁止します。
一、その他常識的に考えて迷惑なコメントはしないで下さい。


以上のルールを守れない人のコメントは削除します。



利用上の注意
ここに紹介してある文章およびプログラムコードは正確であるように心がけておりますが、内容を保証するものではありません。当サイトの内容によって生じた損害については、一切の責任を負いませんので御了承ください。


執筆したCodeZineの記事


【VB.NETで仮想CPUを作ろう】

  1. VB.NETで仮想CPUを作ろう
  2. レジスタの実装
  3. 仮想CPUのGUI化
  4. テストドライバの改良
  5. CPUの基礎動作の実装
  6. MOV命令の実装
  7. ADD命令実装
  8. SUB命令実装
  9. INC命令&DEC命令の実装と命令長
  10. MLU命令の実装とModR/Mについて
  11. DIV命令の実装とイベント設計について
  12. 機械語駆動式 関数電卓を作ろう!
  13. 機械語駆動式 関数電卓を作ろう! 解答編(前半)
  14. 機械語駆動式 関数電卓を作ろう! 解答編(後半)


【仮想ネットワーク実装でTCP/IPを学ぼう】
  1. TCP/IPの基礎と勘所
  2. ネットワークアクセス層の勘所
  3. インターネット層の勘所
  4. トランスポート層の勘所
  5. アプリケーション層の勘所
  6. セキュリティの基礎と仮想ネットワークの仕様
  7. GDI+と独自プロトコルの定義



【並列化】
インテル Parallel Studioを使って並列化プログラミングを試してみた
並列プログラミングの効率的なデバッグを実現する「Parallel Inspector」


【TBBシリーズ】
  1. インテル スレッディング・ビルディング・ブロックの概要
  2. インテルTBBから学ぶループの並列化
  3. スレッドセーフとインテルTBBのコンテナ
  4. インテルTBBのスレッドクラス


【OpenMPシリーズ】
  1. OpenMPの基礎構文
  2. OpenMPの実行時ライブラリと並列ループ
  3. OpenMPのメモリモデルとfork- joinモデル

最近の記事
最近のコメント
月別アーカイブ
カテゴリ
Ada (9)
COBOL (5)
C (9)
C++ (11)
C# (370)
D (25)
Java (8)
Perl (1)
Ruby (14)
PHP (2)
Boo (2)
Cobra (2)
LISP (6)
F# (33)
HTML (0)
XHTML (0)
CSS (0)
XML (0)
XSLT (0)
Scala (4)
WPF (0)
WF (2)
WCF (0)
LINQ (4)
MONO (5)
Linux (0)
MySQL (0)
ブログ内検索
リンク
最近のトラックバック
RSSフィード
ブロとも申請フォーム

この人とブロともになる

QRコード
FC2カウンター