（このエントリは Part 2 からの続きです。） さて、Part 2 のエントリでは、開発系エンジニアの 5 つの分類を示しました。この 5 つのロールに関して、昨今のトレンド及び育成ロードマップがどのようなものであるべきか、自身のスキルを高め、市場価値を高めるためにはどうならなければいけないのかについて考えてみたいと思います。 ［① 業務 SE （要件定義・業務設計）について］ 私がこの IT 業界に飛び込んだ頃は、まだ要件定義や業務設計に関してはあまり情報が整理されていませんでした。しかし...

（このエントリは Part 1 からの続きです。） ［システム開発プロセスの基本とエンジニアの分類］ 業務システムの開発には様々な人が関与しますが、どのような規模のシステム開発であったとしても、少なくとも以下のような役割（ロール）のメンバーが必要になります。そして、それぞれのロールには、他のロールとは異なる専門性が求められます。 この 5 つのロールを理解することは、開発系エンジニアが自らの専門性を深めていく上で極めて重要な指針となるもの ですので、これらについて解説します。 ① 業務 SE 業務...

ここ最近、組織改変などの影響もあって忙しい日々が続いている今日この頃。なかなか  blog エントリ書きも滞ってしまっていて申し訳ないのですが；、最近はコンサルの現場を離れて、少しバックエンド系のお仕事をしていたりします。といっても、プロジェクトの技術レビューや提案活動は以前と変わらず実施しているのですが、そんな中、営業支援でお手伝いをしていた案件のひとつが、全社開発標準の整備・強化プロジェクト。簡単に言えば、SIer のコアコンピテンスのひとつともいえる全社開発標準を整備・強化していくことで...

というわけで本当にまた久しぶりなエントリなわけですが；、なぜこれほどまでに忙しいのかはまた今度改めて書くことにしまして、まずはひとつご報告を。社内関連部署の多大なる協力によって、昨年公開した Windows Azure 実装ガイドを、最新情報にリニューアルして公開することができました！（嬉） Visual Studio Workshop #451 Windows Azure 上での Web アプリケーション開発基礎 こちらのリンク から辿ってダウンロードしてください。  なんとページ数は前回から大幅増量の...

※ （追加情報 2011/07/25） SQL Azure データベースの課金に関して、米国本社の担当者も交え、最終的な確認を行いました。結論としては、 定義上の最大容量（MAXSIZE）ではなく、実際のデータ容量（Current Size）に基づく課金が行われる という、当初通りの情報が正しい、ということになりました。弊社内の一部の担当者が誤解しており、社内で情報が錯綜したのが誤りの原因でした。謹んでお詫びすると共に、修正した情報を以下に掲載します。なお、本件については SQL Azure の課金に関する...

東北地方太平洋沖地震、時間が経つにつれて目を覆うばかりの甚大な被害が明らかになりつつあります。被災地の皆様には本当にお悔み申し上げると共に、亡くなられた方々のご冥福と、皆様のご無事と安全を本当にお祈りしております。社内でも何か手伝えることはないかという動きが出ておりますが、このエントリでは Azure 関連の各種の動きをまとめて随時お伝えしようと思います。 ミラーサイト構築支援 （New! 2011/03/18） 今回の地震に関連して、一部の Web サイトが高負荷でダウンする、という状況が発生しています...

さて、先週 Azure の実装ガイドラインを Web で公開 したわけですが、おかげさまでかなりのブックマークをいただいたり、資料のダウンロードをしていただけた様子。しかし、そもそも Azure を全く触ったことがない、という方には、あちらの資料ではややハードルが高いのも実際のところ。また、Azure に関しては情報が散逸しているので、「どこから手をつけていいのかわからない」という方も多いと思います。一昨日に、MCS の若手メンバの一人である増田さんが書いてくださった、初学者向けの Azure アプリ開発の...

※ 2011/10/31 追記：バージョンアップ版を公開しました。 こちらのエントリ もご参照ください。 というわけで皆様、大変ご無沙汰しております；。1 月に Windows Azure のエントリを書いて以来、Azure 案件で忙しい日々が続いており、とても blog どころではなかった．．．．というのが正直なところ；。現在はホントに Azure 一色な日々を送っているのですが、おかげさまでついに！ というかようやく！ Windows Azure の実装ガイドラインとなるコンテンツを公開することができました...

※ 本エントリは その 3 の続きです。（エントリが長すぎて投稿できなかったため分割しています） ［アプリケーションの修正と Azure 環境への再配置（アップグレード）］ さて、開発用ファブリックと Azure 本番環境では様々な相違点があります。Azure 本番環境で問題となりやすい制限事項としては、以下のようなものがあります。 この中でも、国際化対応に関連する問題はよくひっかかりやすいポイントになります。例えば、以下のような簡単な処理でも、Windows Azure 環境では、開発環境とは異なる動きをすることになります...

※ 本エントリは その 2 の続きです。（エントリが長すぎて投稿できなかったため分割しています） ［Azure 運用環境への展開］ さて、開発用ファブリック上で Web アプリケーションを開発・デバッグし終えたら、いよいよこれを本番環境である Windows Azure 運用環境へとアップロードします。この運用環境への配置（デプロイ）のためには、主に以下の作業が必要になります。 Windows Azure プラットフォームのアカウントの取得 SQL Azure データベースサービスへの移行 Windows...

※ 本エントリは その 1 の続きです。 ［開発用ファブリック上での動作確認］ 引き続き、”CloudService1” プロジェクトをスタートアッププロジェクトに変更し、Ctrl + F5 キーで実行します （※ サーバエクスプローラが pubs.mdf を握っているとエラーが発生するので、デタッチしてから実行してください） 。すると、タスクトレイに “Development Fabric” と呼ばれる Windows Azure エミュレータ環境が起動し、この中でアプリケーションが起動します...

というわけで Part 2. のエントリ のアップからしばらく時間が空いてしまってすみません；。実は社内に引きこもってひたすら Azure の Workshop コンテンツ を開発していたためなのですが、難産の末、ようやく開発が終了したのでこちらの blog に取り組めるようになった次第だったりします。先日の Tech Days 2010 で正式リリースされたこともあり、ちょうど Windows Azure を学ぶにはよい時期……に図らずもなってしまったので^^、ぜひこちらのコンテンツで、Windows...

※ その 2 のエントリからの続きです。（エントリが長すぎてポストできなかったため、分割しています。） ［③ Windows Azure ストレージサービス］ Windows Azure ストレージサービスとは、大規模・大容量の、高信頼性データストレージサービスです。内部的には、データを複数のサーバで分散・冗長化して保持するようになっているのですが、 外から見た場合にはこれが巨大な一つのストレージシステムに見えるようになっている 、というのが、この Windows Azure ストレージサービスです...

※ その 1 のエントリからの続きです。（エントリが長すぎてポストできなかったため、分割しています。） ［① Windows Azure コンピュートサービス］ Windows Azure コンピュートサービスとは、カスタムアプリケーションのホスティングサービスです。OS とミドルウェアがプリインストールされたマシンが提供されますので、そこにカスタムアプリケーションを乗せて実行する、という形になります。利用可能なサーバタイプとして、以下の 2 種類が用意されています。 Web Role サーバ ...

さて、Part 1. のエントリでは、マイクロソフトのクラウドコンピューティング戦略である “S+S” の全体像、そしてその中での Windows Azure Platform の位置づけについて解説しました。要点をまとめると、以下のようになります。 マイクロソフトのクラウドコンピューティング戦略は、オンプレミス型のソフトウェアと、クラウド型のサービスとを上手に組み合わせて、最適なシステムを構築する、というものである。 Windows Azure Platform とは、マイクロソフトによる PaaS...

※ その2 からの続きです。（エントリが長すぎてポストできなかったので分割しました。） ［クラウドコンピューティングに関する FAQ］ ここまでで解説はひととおり終了なのですが、よくある FAQ として、以下の 4 つの点を簡単にまとめておきたいと思います。 従来技術とクラウド技術の違い プロビジョニング パブリッククラウドとプライベートクラウドの境界線 マイクロソフトのクラウドコンピューティング戦略の 4 つの柱 ① 従来技術とクラウド技術の違い その昔、「フレームワーク」というキーワードが流行した際...

※ その1 からの続きです。（エントリが長すぎてポストできなかったので分割しました。） ［インフラから見た場合のシステム形態の分類］ さて、前述の図は、マイクロソフトが提供する製品やサービスを示したもの（＝すなわちマイクロソフトの立場で書いたもの）ですが、今度はこれを、ユーザや SIer などの観点から見た図、すなわち利用方法や利用形態の観点から整理した図に描き直してみたいと思います。 まず、前述の図だと、システム形態としては「オンプレミスか、Microsoft が提供するサービスを使うか」の二択のように見えます...

さて、今回のエントリは Windows Azure Platform について解説するわけですが、Windows Azure Platform は実際のところ、既存のシステムの在り方をすべてリプレースするような、万能なサービスというわけではありません。このため、Azure を利用するにあたっては、 そもそも Azure というものが、マイクロソフトの製品やサービスの中でどのような位置付けにあるものなのかを正しく理解することが重要 です。そして、マイクロソフトの製品やサービスの中での Windows...

というわけで、みなさま明けましておめでとうございます。更新が滞っているこの blog ですが、面白いネタがないとなかなかエントリを作成できないのも本音なところ。がしかし、今年最初のビックニュースはなんといっても 1 月から始まった Windows Azure の商用ラウンチ。興味がある方も非常に多いと思いますが、「そもそも Windows Azure ってなによ？」というのがなかなか分からない、という方も多いと思います。実際、いろいろなところで話を伺うと、以下のものが混同されているような場合が少なからずありました...

さて Part 1. のエントリ では、業務処理の終了パターンの分類と、各アプリケーションタイプにおける基本的な実装パターンを整理しました。要点をまとめると、以下のようになります。 業務処理の終了パターンは、以下のように分類される。 突き合わせエラーについては、バックエンドのモジュール（BC や DAC）との連携によるチェック作業が必要になる。UI 部単体でチェックが可能なのは、単体入力エラーに限られる。 .NET Framework では、UI 開発技術として、ASP.NET, Silverlight...

まず最初のエントリでは、「エラーチェック」とひとくくりにされている「エラー」を、体系的に分類することを試みてみます。このエントリでは、 Web / Windows、あるいは Java / .NET などといった技術論とは無関係な部分 に��いての解説を進めていきたいと思います。 エラーチェック（ユーザ入力検証）の意味 正常終了／業務エラー／システムエラーの分類 業務エラーの細分化 アーキテクチャから見たエラーチェックの実装場所 ※ なお、本エントリで解説されている分類方法や命名方法は、あくまで nakama...

というわけで久しくエントリをアップしていなかったこの blog ですが、最近、複数方面からお叱りの言葉が……； 忙しかったこともあってエントリをサボっていたこともあったのですが、ちょうどいいネタがなかったのも実際のところ。がしかし、先日 2009/9/26(土) に行った、 わんくま同盟さんでの勉強会 のネタが blog 化するにはちょうどいいだろう、という感じなので、その資料を使いつつ、blog エントリを書いてみることにします。 今回の解説ネタは、更新系業務アプリケーションで求められることになる...

さて、Part 1～3 の解説で、Windows フォームにおけるマルチスレッドアプリケーションをスクラッチで開発する方法について述べてきました。結論としては、実は Windows フォームにおけるマルチスレッドアプリケーション開発は恐ろしく厄介で面倒である、ということになると思うのですが；、とはいえ 長時間を要する処理があるため、どうしてもマルチスレッドアプリにしなければならない。 ということも当然あると思います。幸い、.NET Framework 2.0／Visual Studio 2005...

さて、前回の Part 2. のエントリでは、タスクスレッド（UI の背後で動作させる処理を動作させるスレッド、すなわちマニュアルスレッドやプールスレッドの総称）の様々な起動方法について解説しました。主な方法として、以下の 4 つの方法がありました。 マニュアルスレッドの新規作成 プールスレッドの利用 非同期デリゲートの利用 タイマの利用 さて、いずれの方法を利用する場合であっても守る必要のあるルールとして、 UI スレッド以外から UI コントロールの読み書きをしてはならない 、というものがありました...

さて、前回のエントリでは、Windows フォーム内部におけるスレッドの構成や、メッセージループの働きなどについて解説しました。中でも重要なこととして、以下のようなキーポイントがありました。 UI スレッド上で、長時間処理を動かしてはならない。 長時間処理は、マニュアルスレッドやプールスレッドなどの、他のスレッドに切り出す。 UI スレッド以外から、UI コントロールを触ってはいけない。 マニュアルスレッドやプールスレッド上から、UI コントロールを読み書き・操作してはいけない。 上記の 2 つの重要ルールについて...