Trainocate Japan, Ltd.

Win Win Windows
ホーム > Win Win Windows > システム開発

Win Win Windowsコラム
「Cordova」 やってます
執筆:鈴木和久

本格的に暑くなってきましたね。

昨夜、今年初めての「冷やし中華」を食しました。最近、少し体調崩して食が細くなりがちな私にとって、もってこいのごちそうでした。冷蔵庫にある食材だけを組み合わせて、ぱぱっと料理できる人を尊敬します。「あれがない、これがないから、それが作れない」となってしまいがちな自分の貧弱な料理スキルとは一線を画するプロフェッショナルな流儀。「まじ、リスペクト」です。

さて今回は、「Visual Studio Tools for Apache Cordova (TACO)」のお話です。


● なんだか、ラテンな響きですね?

「Apache Cordova」は、ハイブリッド アプリのフレーム ワークです。
カナダ バンクーバー、Cordova street に本社があった Nitobi Software 社によって開発された PhoneGap がベースとなっています。「Cordova street」の名称の由来は、「スペイン総督名」らしいです。

Nitobi Software 社は 2011 年に Adobe Systems 社によって買収されました。PhoneGap は Apache Foundation に寄贈後、Apache Cordova という名称が与えられ、オープン ソースとして開発が継続されています。

また、Adobe Systems 社は、Cordova をベースに +α の機能を追加した PhoneGap を継続提供しています。

MS_CO.png
※写真は本文とは関係ありません。

●Web アプリのフロントエンド エンジニアの方にこそ、お奨め

「ハイブリッド アプリ」は、スマートフォンやタブレットなどのモバイル デバイスにインストールできるアプリで、ソース コードを、標準 Web 技術である HTML5、CSS3、JavaScript で作成できます。「Web アプリ」との相違点として、ネットに接続していない状態でも実行可能で、モバイル デバイス上のセンサー、連絡先などのネイティブ機能に柔軟にアクセス出来て、プラグインによってネイティブ部分の機能拡張も可能なことなどが挙げられます。

Web アプリのフロントエンド エンジニアの方なら、ネイティブ アプリ開発に必要な、Java とか Objective-C、Swift などのプログラミング言語を追加で学習することなく、「今、持っているスキルだけ」で、Android、iPhone、Windows 10 mobile といったモバイルデバイス向けのクロス プラット フォーム なアプリを、単一のソースコードで開発できます。そして、開発したアプリは App Store とか Google Play、Windows ストアなどから配布できるのです。

●どうやって開発するの?

Apache Cordova によるハイブリッド アプリの開発環境として日本のアシアル社が提供している Monaca が有名です。Monacaデバッガーというアプリをスマートフォンにインストールすれば、前述のアプリケーション ストアに配置することなく、自作のハイブリッド アプリをテストすることができます。

Monaca 以外にも選択肢はたくさんあります。
Visual Studio ユーザーは、Visual Studio Tools for Apache Cordova を使えば、ハイブリッド アプリを開発できます。
Visual Studio Tools for Apache Cordovaは、Visual Studio 2013 から利用可能になった、Microsoft 社提供の Cordova 開発環境です。
Visual Studio 2015 から標準機能としてバンドルされています。


●「Cordova やってます」

グローバルナレッジでは、Visual Studio Tools for Apache Cordova を使った研修をご提供しています。Andoroid スマートフォンの実機を使用して、作成したアプリを USB 経由でインストールし、実行します。


▼ MSC0537G : Apache Cordova によるハイブリッド アプリ開発入門 
   ~Visual Studio によるマルチ デバイス アプリ開発~

 コース詳細、お申込みは こちら です!


[システム開発][2016年7月 7日配信]

Win Win Windowsコラム
第53回 [開発スキル再始動特集6] BBQ にてインシデント発生、その時チームは?
執筆:鈴木和久

会社で BBQ (バーベキュー) を主催するチームに参加しています。春秋 2 回開催することもあれば悪天候などが重なり 1 回も開催できなかった年もありましたが、かれこれ 10 年以上継続している恒例行事になっています。同僚だけでなく、その家族も参加するので回を重ねる度に子供達の成長に目を細めたりして、なんだか親戚の集まりみたいなほのぼのとした雰囲気のイベントです。


■ BBQ でプロジェクト管理実践


BBQ は、よくプロジェクト管理系研修の演習課題になります。要求管理(要件管理)、リソース管理、スケジュール管理、リスク管理、インシデント管理など、プロジェクト管理に必要な多くの要素を含む上、業務内容に依存しないテーマなので題材として扱いやすいからでしょう。
最近では、食材や道具の調達から調理、そして後片付けに至るまで一手に引き受けてくださる業者もたくさん存在するので、BBQ のハードルはずいぶん下がりましたが、それでも悪天候への対応など幹事チームがやらなければならないタスクは多いでしょう。
私達の BBQ チーム(ただの有志の集まり) は、外部の BBQ 業者に頼ることなく全てを自前で執り行っており、その分タスクも多いのですがイテレーションを重ねる毎に各タスクのプロセスが洗練されてきたように思います。当初は食材が余ったり足りなかったりしたのですが次第に最適化されてきましたし、レギュラー メニュー(典型的な BBQ 串、ロースト ビーフ、スペアリブ) などのクオリティも向上してきたと思います。BBQ チームのベロシティ(対応力)が試行錯誤の繰り返しによって継続的に強化されてきたたからでしょう。


■ BBQ にてインシデント発生


先日開催した BBQ の目玉は「ソフトクリーム」でした。特別な機材を使用せず、ボウルと泡立て器及びボウルを冷やす氷(塩を加える)で作ります。テレビ番組で作り方を見ただけという「うっすらとした記憶」と、「材料と手順の箇条書きのみの頼りなさげなレシピ」で初挑戦するというリスクが一杯のメニューです。
それなのに当日会場に向かう道すがら、牛乳、生クリームにゼラチンを加えて溶かすための「鍋」と、氷を入れる外側のボウルを忘れた事に気づきました。これでは子供達が楽しみにしているソフトクリームが作れません。「やりたいことをやれない状況」つまり「インシデント」の発生です。
子供達をがっかりさせる訳にはいきません。他の参加者にお願いして急遽、鍋を持参して貰い、さらに会場に近いホームセンターでボウルを買ってきて貰うことで、対応することができました。
今回のインシデントは BBQ チームのメンバーが早期に気づけたので、時間内に対策が打てましたがデザートの時間になってから気づいていたら、ソフトクリームは作れなかったでしょう。


SoftCream.jpgのサムネール画像


■ TFS (Team Foundation Server) におけるインシデント管理


TFS では、プロジェクトで管理対象となるタスク、テスト ケース、バグ、リスクなどを、「作業項目」と呼ばれる要素として個別にデータベースで管理します。一度登録された作業項目は、チーム メンバーによって共有され、然るべき対処が行われた後、その対応の履歴が継続的に記録されます。削除することはできない仕様になってますので、完全に対応が完了するかキャンセルされるまでアクティブな状態でデータベースに残り続け進捗管理の対象となります。
第51回 [開発スキル再始動特集4] 世界はそれを探索的テストと呼ぶのです 」で御紹介した、探索的テスト(Exploratory Testing) の結果生成される「バグ作業項目」もその一つです。バグ作業項目は、テスト担当者や運用担当者が発見したバグの状況を障害報告書(チケット) として纏めたものですが、TFS では予期せず発生する例外を、「インシデント作業項目」として TFS のデータベースに自動登録してくれる便利な機能があります。


■ PreEmptive Analytics for TFS CE


PreEmptive Analytics for TFS CE は、アプリケーションで発生した例外レポートを収集し、開発チームの担当者が予め定義した規則としきい値に従って、インシデント作業項目を自動登録します。インシデント作業項目には、発生した例外の種類、スタック トレース、実行時にロードされたすべてのアセンブリ リストなどが含まれます。
例外発生時のインシデント管理を迅速に着手するための「予防的な対策」として利用することができます。PreEmptive Analytics for TFS CE によってユーザーやテスト担当者、運用担当者が認知する前に、いち早く詳細な情報を把握することも可能になりますので、致命的なインシデントになってしまう前に、有効な対策が打てる可能性が高くなります。
また、ソースコードを変更せずに既存のアセンブリ ファイルに後から機能を追加することが出来ますので、テスト環境で再現させることが難しいエラーが本番環境で不定期に発生するような、悩ましい状況でのエラー詳細情報の収集などで大きな効力を発揮します。


要求管理、設計、実装、テスト、運用にいたる全工程を総合的に管理するアプリケーション ライフサイクル マネージメント (ALM) と、チーム開発の活性化に関連する研修として以下をご紹介します。

Visual Studio によるアプリケーション ライフ サイクル管理 ~70-498対応~(MSC0462G)
※演習課題は BBQ ではありません:-)

その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM)」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年10月 7日配信]

Win Win Windowsコラム
第52回 [開発スキル再始動特集5].NET Frameworkも進化しています
執筆:大貫 淳子

以前に、コレクションとジェネリックコレクションを紹介しました。
ジェネリックコレクションは.NET Framework2.0からの機能です。
ということで、今回は.NET Frameworkのバージョンの推移について書きます。


■Windows 7では.NET Framework1.0はサポートされません。


2003年に登場した.NET Frameworkは1.0 →1.1 → 2.0 → 3.0 → 3.5 → 4 → 4.5 → 4.5.1とバージョンアップしています。2014年現在の最新は4.5.1です。
.NET Framework の登場はVisual Studioの発売と同じタイミングが多く、バージョンの推移とVisual Studioの関係は以下のようになっています。
winwin1.PNG


.NET Frameworkはその時の最新のバージョンがOSとともにインストールされています。
例えば、Windows 7には. NET Framework 3.5が含まれており、Windows 8.1には.NET Framework4.5.1がインストールされています。
参考).NET Framework のバージョンおよび依存関係(Microsoft社サイト)

.NET Frameworkは複数バージョンの共存が可能です。例えば、1.0、1.1、2.0、3.0、3.5、4を同じPCにインストールすることができます。(4以降は共存できません)

winwin2_2.PNG
(追記:Windows Server 2003、Windows Server 2003(R2) では、.NET Framework 4.5以降はインストールできませんでした。画像を差し替えました。訂正してお詫びします。)


◎(オレンジ)が標準でインストールされているもの、
○(黄色)がインストール可能なもの、×はサポートしていないものです。
4、4.5、および4.5.1はどれか1つしかインストールできないため、アップグレードするとそのバージョンが最新です。

Windows 7やWindows 8は、.NET Framework1.0および1.1はサポートしません。
OSをアップグレードするタイミングで、フレームワークも最新のバージョンに移行する必要がありますね。


■新しい機能がどんどん増えています!


ジェネリックコレクション、LINQ、匿名メソッド、ラムダ式、Async、Await ...などなど、機能拡張され、実現できる事が増えたり、コーディングが簡素化されたり、処理速度が速くなったりしています。

「新しい」ということは「前は無かった」ということです。

つまりその機能が必要なら「前は手作りしていた」ということになります。
「新しい機能」を知らないとこれからも「手作りしていく」ことになります。せっかくの機能を活用しておらず、"モッタイナイ"わけで、二度手間です。

例えば、複数行のデータの中で、3行目ごとにデータを取り出し、加算処理をしたい、といったロジックの場合は、ループや条件の処理を使用するので、10行程度になりますが、ラムダ式という記述を使えば1行で書けます。
クラス作成に必須となるプロパティも自動実装プロパティという機能を使えば、getブロック、setブロック合わせても1行のみです。

.NET Framework 4.5以降では、Async/Awaitという非同期処理のキーワードが増えています。


ボタンをクリックし、非同期で行う何らかの処理(下記の場合は10秒間休止)を呼び出し、戻ってきたら、また別の処理を実行するといったコードを、.NET Framework1.0の機能のみで書くと以下のようになります。呼び出しの処理はThread型のクラスとして定義しています。
public partial class Form1 : Form
private void button1_Click(object sender, EventArgs e)
  {
    this.button1.Enabled = false;
    SubThreadClass st = new SubThreadClass();
    Thread thread = new Thread(st.Run);
    thread.Start();
    thread.Join();
    this.button1.Enabled = true;
  }
}
class SubThreadClass
{
  public void Run()
  {
    Thread.Sleep(10000); // 10秒休止
  }
}

最新の機能で書くとこれだけシンプルです。
private async void button2_Click(object sender, EventArgs e)
{
  this.button2.Enabled = false;
  await Task.Run(() => Thread.Sleep(10000));
  this.button2.Enabled = true;
}

ライブラリーは使ってこその「貯蔵庫」です。
是非、.NET Frameworkの最新のクラスライブラリーを活用してください。

その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月29日配信]

Win Win Windowsコラム
第51回 [開発スキル再始動特集4] 世界はそれを探索的テストと呼ぶのです
執筆:鈴木和久

[第36回 テスト工程を凜として粛々と乗り切るのです] と、前回の [第50回 [開発スキル再始動特集3] そのプログラムのテスト ケース、網羅されてますか?] で、テスト自動化のメリットと課題についてお話してきましたが、今回は自動化できないテストについて取り上げます。


■あらゆる可能性を排除しない


週末の夜に某テレビ局で放映されている「病名推理エンターテインメント番組」を時々見ています。経験豊富な総合診療医が過去に実際に経験した症例中、病名特定の難易度が高かったケースを題材に、3 人の研修医がその診療過程を疑似体験しながら病名特定に挑むという内容です。
問診、触診などの基礎的な診察プロセスに始まり、病因の仮説を立てそれを検証する検査を実施し、その検査結果から次の仮説を組み立てるということを繰り返しながら診療データを積み重ねていくのですが、そのデータ単体ではミスリードしてしまいそうなものも多く含まれます。「診察プロセス中に、あらゆる可能性を排除しないことが結局は近道」であり可能性の大小に関わらず丹念に「点」としてのデータを収集し「線」として繋げていくことが重要だと気づかされます。もちろん、人命が関わることなので、対応のスピードもとても重要です。


■原因不明のエラーは「探索的テスト」で対処


ソフトウェア開発の世界でも「原因不明のエラー」に遭遇することがあります。

原因を特定するために、まずは対象ソフトウェアを実行しエラーの状況を再現させようと試行錯誤するのですが、これが容易ではないケースが少なからずあります。「原因不明のエラー」が発生するのはテスト工程の後期から運用開始後のタイミングであり、その段階のソフトウェアは予め想定されるテスト ケースに基づくテストによって、完成度が高くなっているため簡単にはエラーが発生しないはずだからです。
この厄介なエラー状況を再現するためには、前述の総合診療医のチームと同じ作業が必要になります。エラー原因としての仮説を立てその仮説を検証する新たなテストを実行し、そのテスト結果をもとに新たな仮説を立てることを繰り返しながら核心に迫っていく訳です。ここで行われるテストは、予め準備されたテスト ケースには無い、言わばその場の思い付きのものであるため過去の経験を活かした戦略的な試行錯誤が重要になります。このようなテスト手法は「探索的テスト(Exploratory Testing)」と呼ばれます。


■「チーム」で一丸となって対応するために


Visual Studio と Team Foundation Server を組み合わせれば、探索的テストを効率化することができます。Microsoft テスト マネージャーというツールから探索的テスト セッションを開始すると、テスト ランナーと呼ばれる機能がテスト中にアプリケーションに対して行った GUI 操作の手順を漏らさず記録してくれます。また目的のエラーが再現できた時に、その場で障害発生報告書(チケット) を発行することができます。このチケットは「バグ作業項目」と呼ばれエラーを再現させた操作手順とエラー発生時のイベント ログなどの基礎情報、エラー画面のスクリーン ショットなどがアタッチされます。エラー再現手順を含め、ほとんどの情報が自動的に収集されバグ作業項目にアタッチされますので、作業記録としてのエビデンスの取得漏れを防ぐことができ、後続作業を担当するチーム メンバーの作業迅速化を強力にサポートします。
診療データのすべてが「電子カルテ」に集約され、病因を特定するプロセスに関わる複数の医師だけでなく原因判明後の治療にあたるすべての医師にも共有されるように、「バグ作業項目」は複数の運用担当者、アーキテクト、プログラマーなどのチーム メンバーによってプログラム修正などの対策が完了するまでアクティブな状態で共有されます。


Ticket.jpg


■探索的テスト結果からのテスト ケースの新規作成


「原因不明のエラー」はデータ入出力の微妙なタイミングに起因するものだったり、特定リソースの使用に関して、しきい値を超える状況がトリガーとなって発生するなど様々な理由により発生します。探索的テストセッション中に自動記録されたエラーの再現手順は、新たなテスト ケースのテスト ステップとして再利用することができます。このテスト ケースは障害対策後の確認テストとして使えるだけでなく、想定内のテスト ケースとして次回以降の開発作業で有効活用されることになるでしょう。テスト ランナーには「バグ作業項目」作成と同様に「テスト ケース」を新規作成する機能が含まれますので、バグ作業項目作成後すぐにテスト ケースを作成されると良いでしょう


探索的テストを含む戦略的なテスト方法と、チーム開発の活性化に関連する研修として以下をご紹介します。

その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月23日配信]

Win Win Windowsコラム
第50回 [開発スキル再始動特集3] そのプログラムのテスト ケース、網羅されてますか?
執筆:鈴木 和久

[第36回 テスト工程を凜として粛々と乗り切るのです] で「Visual Studio と Team Foundation Server を使ってテストを自動化しましょう!」という記事を書きました。テストの自動化によって、バグの修正や新機能追加後の回帰テストの効率化と、プログラムの保守性を高めるためのリファクタリング促進という効果が望めますよ!というお話でした。


今回は、自動テスト コードのその他のメリットについてご紹介します。


■他者が開発したソフトウェアの担当を引き継ぐとしたら...


例えばソフトウェア開発を外部委託したケースを考えてみましょう。あるいは、もう少し身近なケースとして、同僚が開発したソフトウェアの担当を引き継ぐケースでも構いません。どちらの場合も、既に単体テスト済のソフトウェア コードが存在すると仮定します。

あなたがそのソフトウェアの結合テスト以降を担当することになった場合、どこから手を付けますか?

正攻法だと基本設計書や詳細設計書に目を通し、次にソース コードを解析することになりますよね?
また単体テスト内容とテスト結果を知りたければ、「テスト仕様書」等のドキュメントと、「エビデンス」と呼ばれるテスト実施時のスクリーン ショットやデータベース ダンプなどの膨大な作業記録を丹念に解析するになるでしょう。う~ん、想像するだけで気の重い作業です。もしかしたら「このコード、本当に単体テストしたの?」という深刻な状況にぶち当たるかもしれません。でも結合テスト以降に発生する問題を、あなたが解決しないといけないとしたら、避けては通れない作業ですよね。


■自動テスト コードはドキュメントの役割も担う


もし自動化されたテスト コード(テスト ドライバ) も一緒に作成されていればどうでしょう?テスト自動化のためには、[MS Test] などのテスト フレームワークに準拠したテスト コードの作成が必要ですが、これがあると前述の気の重い状況は一変するかもしれません。
その理由は、自動テスト コードそのものがテスト対象プログラムのドキュメントとして機能するからです。そこにはプログラムが満たすべき外部インターフェイスが具体的な実装として記述されているはずです。テスト対象コードに対する入力データとテスト対象コードの処理結果としての出力を設計書上の「用語」ではなく、そのものずばりのコードとして確認することができます。自動テスト コードに必要最小限の適切なコメントが付与されていれば、きっと展望は明るくなるでしょう。


つまり、あなたはテスト対象コードそのものを解析する前に、自動テスト コードを実行し解析することによって、テスト対象コードの処理内容と完成度を把握することができるということです。あなたがテスト対象コードを引き継ぐ前に、自動テスト コードをレビューしテスト ケースの不足があれば修正を依頼できる可能性もあるでしょう。


■テスト ケース網羅の分析も可能


自動テスト コードによって、機械的にテスト ケースの網羅率を「ある程度」分析することができます。Visual Studio の 「コード カバレッジ分析」機能は、自動テスト実行中にテスト対象コードに含まれるステートメントの、どの部分が実行されたかを追跡します。テスト対象コード内のすべてのステートメントが実行されれば、カバー率 100% になります。自動テスト コードによって実行されなかったステートメントがあれば、コード ブロック単位での未カバー率が数値として表示されます。また、その状態でテスト対象コードをコード エディタで開くと、自動実行されたステートメントと未実行のステートメントが色分けされて表示されますので、不足しているテスト ケースを明確に把握することができます。

CodeCoverage.jpg
Visual Studio の「コード カバレッジ分析」機能はレビュアーによるコード レビューやコーディング インスペクションによる目視でのチェックを補完するものとして期待できるでしょう。


■自動テスト コード作成と保守にかかるコストが課題


自動テスト コードのメリットばかりお話しましたが、自動テスト コード開発には工数がかかります。この工数と、それにより享受できるメリットのトレード オフになると思います。Visual Studio には自動テスト コード作成を支援する機能が豊富に提供されていますので、コストを抑えつつメリットを活かせるようにしましょう。テストの自動化によってテストのノウハウは「人」だけでなく「コード」に蓄積されていきます。

単体テストと GUI アプリケーション テストの自動化および、テストケースの網羅に関連する研修として以下の2コースをご紹介します。

Visual Studio を使用したソフトウェアのテスト ~70-497対応~(MSC0460G)

1日でわかる!ソフトウェアテスト技法(SWC0008G)


その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月17日配信]

Win Win Windowsコラム
第49回 [開発スキル再始動特集2] プログラムコードを洗練させよう ~配列からコレクション、そしてジェネリック~
執筆:大貫 淳子

前回の記事から引き続き、Visual Basic (以下VB)のお話です。

プログラムの外部インターフェイスを変更せずにコードを洗練させることを「リファクタリング」と言います。私は、良いプログラムコードとは、書きやすいコードであり、読みやすいコードであり、そして、保守のしやすいコードであるのがベストだと思います。
メンテナンスのしやすいコードは作った人だけでなく、その後にシステムに携わる人も幸せになります。プログラムは、そのコードを書いた人よりも、その後に運用していく人のほうが多く読む場合も多々ありますから、書きっぱなしではなく、ひと手間かけるとより素敵になるわけです。

今回は、この「コードを洗練させる」時に役立つかもしれないトピックについてご紹介します。

■配列で複数データを格納する

VB にも他の言語同様 「配列」という機能があります。1つの変数名で複数のデータを保存できます。

文字列型の配列を定義
Dim myArray() As String

再定義する場合は Redim、
元の値を保持しつつ、配列のサイズを拡張する場合は、ReDim Preserve というキーワードを使います。

1件目(インデックス0)へAAA、2件目(インデックス1)へBBBを代入
ReDim myArray(0) = "AAA"
ReDim Preserve myArray(1) = "BBB"


複数のデータを増やすときはループなどを用いながらReDim Preserveで追加できます。これはとても便利で、VBならではのキーワードです。C# には用意されていません。

ですが、この記述では、データの追加は末尾にしかできません。

■コレクションを使おう

そこで、配列を「コレクション(Collection)」という機能に置き換えてみます。コレクションはVB6からも使えていました。(が、私は知らずに配列をずっと使っていました)。今回は.NET FrameworkのSystem.Collections という名前空間の ArrayList クラスを使用します。

文字列型のコレクションを定義
Dim myCollection As New System.Collections.ArrayList

データの追加はAddというメソッドで利用可能です。

1件目(インデックス0)へAAA、2件目(インデックス1)へBBBを代入
myCollection.Add("AAA")
myCollection.Add("BBB")


コレクションでは、途中の要素追加が簡単にできる Insert というメソッドも用意されています。

インデックス 0 に 要素「XXX」を挿入し、既存の 2 件がスライドします。

myCollection.Insert(0, "XXX")

同様に途中の要素削除も簡単にできます。
メモリの使用も効率化されており、特に何度もデータを追加する場合には処理速度に差が出ます。私のPCでは5万件のデータの追加で1秒以上の差が出ました。(マシンスペックやメモリ容量で変わります)


■ジェネリックコレクションでさらに進化

ただ、このArrayListは、配列のように格納できるデータの型に制限がかけられないため、文字型や数値型や日付型などの異なるデータ型の値を格納することができます。これはこれで便利な場合もあるのですが、取り出す際に、必ずデータ型を調べて然るべきデータ型に変換しなければなりません。データ型を間違って変換してしまうと、実行時エラーである例外が発生します。
コレクションに格納されるデータ型が一種類で予め決まっているのであれば、データ型を宣言し間違った型のデータ格納をコンパイル エラーとして実行前に検出できた方が安全です。またコレクションからデータを取得する時にデータ型の変換が不要になります。
このような型の安全性と、コレクションの柔軟な使い勝手を両立するために、.NET Framework 2.0 からは 「ジェネリック コレクション」 という機能が追加されました。

前述の ArrayList を ジェネリック コレクションの List(of T) というクラスで置き換えてみます。

Dim myCollection As New System.Collections.Generic.List(Of String) myCollection.Add("AAA")
myCollection.Add("BBB")



ジェネリック コレクション定義時に文字列型(Of String)と指定しておくと、文字以外のデータは格納できません。コンパイル時にコンパイル エラーが発生します。

なお、2次元配列など、配列のほうが使いやすいと思われる場合もありますので、適材適所で使い分けてください。

既存のプログラム、正常に動作しているプログラムに手を入れるのは勇気のいることですが、プログラム言語仕様はバージョンアップし続けています。新しいキーワードや文法が登場するのにはそれなりの理由があり背景があるはずですから、それを取り入れることによって改善することも多くあります。リファクタリングによってメンテナンスがしやすくなったり、機能アップするメリットもあります。
プログラムを変更するとテストも必要になりますね。効率の良いテスト手法が導入されていれば、リファクタリングも気軽に取り組めるはずです。このテスト手法も進化しています。これはまた別の記事で紹介します。

その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月 9日配信]

Win Win Windowsコラム
第48回 [開発スキル再始動特集1] そのシステム、東京オリンピックまで使えますか?使いますか?
執筆:大貫 淳子

こんにちは。
しばらくシステム管理系の話が続きましたので、ここからはシステム開発系の記事を書きたいと思います。どうぞよろしくお願いします。


さて、みなさま、Visual Basic (以下VB)という言語はご存知ですか?
Windows OSとの相性も良く、特にバージョン6.0 (以下VB6.0)は人気があり、多くのシステムに利用されています。

私もVBが大好きです。大文字小文字が区別されないというのは有名なところですが、コード エディターのヒント表示(インテリセンス)がC#よりも速く、入力する記号類も少ない(;や{}は不要です)ので、タイピングそのものの時間がかかりません。また、VBで作成したデスクトップアプリの実例が多いので、「こんなことやりたいな」と思った時に、参考になるサイトやコード例もたくさんあります。「社内のツールを作りたい」という理由で、VBのコースを受講される方も多いのがうなずけます。


VB6.0の開発環境は1998年に発売し、メインストリームサポートは6年後に終了、延長サポート期間も2008年4月8日で終了されています。VB6.0で作ったアプリケーションの動作にはランタイムが必要なのですが、こちらのサポート期間は何度も延長されています。発売当時OSであるWindows 98の時代から、Windows XP → Windows Vista → Windows 7 → Windows 8と何世代ものOSで動作可能です。
それだけシステムが多く使われ、安定稼働し続けていることのあらわれなのだと思います。

【参考】Windows Vista、Windows Server 2008、Windows 7、およびWindows 8に対するVisual Basic 6.0のサポートに関する声明


Windows 8でもランタイムをインストールすれば動作していたVB6.0ですが、いよいよ、Windows 8.1がVBランタイムをサポートする最後のOSになりそうです。
【参考】Bring back Classic Visual Basic, an improved version of VB6


Windows 8.1のサポート期限は2023年1月10日です。
【参考】Windows 8.1 サポート ライフサイクル ポリシー


2020年には東京オリンピックが開催されます。
ちなみに、Windows 7のサポート期限は2020年1月14日なので、東京オリンピックまで持ちません。
【参考】マイクロソフト プロダクト サポート ライフサイクル
システム開発は開発するまでの要件定義や設計と、移行期間、運用期間、稼働後のしばらくのドタバタ(本当はないほうが良いのですが・・・)までの期間を必要とします。
のんびりオリンピックを観戦したいですよね。


ぜひ、早めに、新しい環境により適したシステムに移行しましょう。
VB6.0以降は、VBの文法が活かせるVB.NETがVisual Studioで利用可能です。VB.NETは内部バージョンを持っており、VB6.0を引き継ぎ7.0から始まり、現在11.0まで上がっています。バージョンが上がっただけ、できる事も増えています。


次の記事ではVB6.0 からVB.NETで変化したプログラムコードの紹介をします。


その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月 3日配信]

Win Win Windowsコラム
第38回 プログラミングしてみませんか?
執筆:大貫淳子

前々回のコラムではALM (Application Lifecycle Management) にまつわるテスト工程の話をしましたが、DevOpsというキーワードもここ数年耳にすることが増えています。
「開発部門(Development)と運用部門(Operation)の垣根を越えてITをビジネスに活かそう」という意味です。
開発のサイクルが短くなり、また改善やリリースの頻度が上がっているため、ツールを利用した情報共有や自動化もDevOpsの重要な要素です。


クラウド化によりフルスタックエンジニア、マルチスタックエンジニアが必要とされてきているように、プログラミングはプログラマだけがわかればよいという時代は終わり、今後は誰もがプログラミングにも携わる可能性があります。


プログラミングそのものもITの進化とともに変化しています。
フレームワークと呼ばれる枠組みにより、イチからすべての処理をコーディングするのではなく、必要な部品を取り入れ組み合わせながら作れるようになりました。開発環境としてのツールも充実しており、キーワードが間違っていたら即座にエラーを知らせてくれたり、キーワードを途中まで打つとヒントを表示してくれたり、テストが自動化できたり...、と至れり尽くせりです。


プログラミングのエッセンスは、様々な分野でも活かせます。
プログラミングでは処理の手順を「アルゴリズム」と呼びますが、これは普段の仕事の中でも、「効率よく、無駄なく、もれなく」作業を行う脳のストレッチとなります。一日に何度も同じ作業があるならば、それを定例化できないか考えてみたり、同じ作業をしている人と情報共有し効率化を図ってみたり...。


プログラムにより作業が効率化できるとしたら、運用部門にもハッピーなことが沢山あるはずです。人事異動のたびにActive Directoryの設定を手作業で行っているとしたら、プログラムを作ればボタン一つで完了するかもしれません。


プログラミングは難しいものではありません。
まずは、使いやすいフレームワークや開発環境に触れてみませんか?

基本から学習したい方はこちらのコースがおすすめです。
C#によるデータ構造とアルゴリズム
Visual Basicによるデータ構造とアルゴリズム

[.NET Frameworkシステム開発][2014年3月19日配信]

Win Win Windowsコラム
第36回 テスト工程を凜として粛々と乗り切るのです
執筆:鈴木和久

●要件定義工程はもちろん重要、だけどテスト工程だって...

お客様とシステム開発プロジェクトの失敗要因についてお話させていただく時に、「結局、要件定義が甘いんだよね」という声を数多くいただきます。ウォーターフォールにしろ、アジャイルにしろ、これがもっとも重要なプロセスであることは疑いようがありません。

しかし、開発チームのプログラマーとしてプロジェクトに参加した経験から言うと、一番大変で多くの時間を要し「改善の余地も多いのはテスト工程」だと思います。IPA(独立行政法人情報処理推進機構) の「ソフトウェア開発データ白書」によると開発プロジェクトの全工程のうちテスト工程が占める工数の比率は 3 割~3.5 割程もあることが分かります。実際はもっと多いような気もしませんか?

プロジェクトの失敗要因として真っ先に挙がる上流工程の問題は、会社全体を巻き込む大きなトラブルになりがちなのに対して、テストのトラブルは現場で解決できてしまうので失敗要因として上位にランクされないのかもしれません。

ただし「解決」といっても、文字通り命を削る作業をしてプロジェクトを存続させることもあるようです。これでは本当に「解決」とは言えません。私が新入社員の時に最初に参加したプロジェクトのテスト工程で、重要なサブシステムを担当していた先輩がプレッシャーで休みがちになった時、毎朝先輩の家までお迎えに行くのが私の業務のひとつでした。

テスト工程のプロセスを改善すればチームメンバーも凜として粛々とテスト工程を乗り切れるはずなのです。その結果プロジェクト全体の工数は圧縮され、品質の高いシステムが提供されます。

●可能な限りテストを自動化しましょう

マイクロソフトでは、早くからテスト工程の自動化に取り組み、テスト担当者が直接テストをするのは最小限なんだそうです。どういうことかというと、テスト担当者はテストスクリプトを作成し、テスト自体は夜間に自動実行されているのだとか。

テスト結果は関係者に配布されるとともに、バグのあるモジュールは担当者に通知されます。この時、オリジナルのモジュール作成者に戻されるとは限らないそうです。つまり、他人が作ったコードをデバッグしなければならないわけです。

最初からそれが分かっていれば、コードを書くときにも「いつ、誰が見ても分かるように」ということを心がけるため、結果として保守性が上がるかもしれません。

この話、同僚の横山がMicrosoftの方との雑談の席で聞いた話の伝聞なので、聞き間違いや勘違いがあるかもしれませんが、ありそうな話ではあります。

●テストの自動化にはツールを活用しましょう

マイクロソフトでは、テストを自動化するためにさまざまな内部ツールを持っているという話です。製品として販売されたものとして Microsoft Test(MS Test)なんかもありました。MS Testに付属していた自動実行ツールは、当時のSystems Management Server (SMS、現在のSystem Center Configuration Manager)のアプリケーション配布にも使われていました。

現在、MS Testは、開発ツールであるVisual Studioと、チーム開発をサポートするTeam Foundation Serverの一部になりました。ビジネス層のクラスやデータ層のクラスの単体テストの自動化はもちろん、GUI アプリケーションの手動操作を記録し自動再生するテストコードを生成することもできます。

自動化されたテストは繰り返し実行可能です。これはバグの修正や機能追加後の回帰テスト(デグレード テスト・リグレッション テストとも)を効率化することにつながります。また積極的なリファクタリング(コードの洗練)を行うための勇気(せっかく動いているコードを弄るのには勇気がいりますよね)を与えることになります。

●MCP(マイクロソフト認定技術者プログラム)試験もできました

テスト工程を改善することにより、高品質なアプリケーション早く提供できるようになります。マイクロソフトとしても利点が大きいため、MCP(マイクロソフト認定技術者プログラム)試験もできました(70-497 : Visual Studio 2012 を使用したソフトウェアのテスト)。

この試験に対応した研修が、「Visual Studio を使用したソフトウェアのテスト ~70-497対応~」です。今の所、この試験に対応した研修は他社からは提供されていないようです。

系統だったテストを漏れなく、効率よく実行・管理するために、ぜひ本研修の受講を検討してください。

[システム開発][2014年2月19日配信]

※Microsoft、Windowsは、米国Microsoft社の登録商標です。
※Oracleは、米国オラクル・コーポレーションおよびその子会社、関連会社の米国およびその他の国における登録商標です。
※PMI、PMP、PMBOKは、プロジェクトマネジメント協会(Project Management Institute, Inc.)の登録商標です。
※ITIL®はAXELOS Limited の登録商標です。
※American Management Association は、米国アメリカン マネジメント アソシエーションの登録商標です。
※BOOT CAMP、NEW TRAIN、Glovalueはトレノケート株式会社の登録商標です。
※その他このサイトに掲載された社名、製品名は、各社の商標、または登録商標です。

© Trainocate Japan, Ltd. 2008-2017, All Rights Reserved.
  • Get ADOBE READER