［アーキテクチャ編］巨大な定数クラスを作ってはいけない
定数クラスについての指針は，アプリケーション開発指針などに簡潔に記されていることが多い。大規模プロジェクトであるにもかかわらず，役割や目的に応じた定数クラスの分割方針が示されず，単に「定数に関しては，分散しないよう定数専用のクラスを用意する」などと記されている場合は，一つの定数クラスに全定数の定義が集中し，巨大な定数クラスができ上がってしまう。 実装者の作業効率が悪化する 通常，定数クラスの利用者となるプログラマが必要とする定数は，一つないし数個に限られる。プログラマが，図2のような巨大な定数クラスから，必要な定数を探すことを想像してほしい。 【Javaの場合】 public class Construct { /** 処理結果コード : 対象なし */ public static final int NOT_FOUND = -1; /** 処理結果コード : 正常 */ public s
Amazon EC2で「スケールアップ」のジレンマ
米Amazon Web Servicesの仮想マシン・ホスティング・サービス「Amazon EC2」を使っていると，可能な限り課金を抑えるために仮想マシンのスペックをこまめに増減させる「スケールアップ/ダウン」を試みたくなる。しかしサービスの前提は，数を並べるスケールアウト。このギャップは埋まりそうにない。 まずEC2をご存じでない方のために，サービスの内容を簡単に説明しよう。EC2は，ECサイトで有名な米Amazon.comの子会社である米Amazon Web Servicesが手がけている仮想マシンの時間貸しサービス。「仮想マシンを即座に生成」「不要になったら消す」といった柔軟性が売りのIaaS（Infrastructure as a Service）である。このEC2を，ITproは関連記事の抽出に使っている。もともとはクラウド・コンピューティングをテーマにしたITpro Magaz
実開発で分かったGoogle App Engine for Javaの“すごさ”
ゴールデンウィークに特に予定のなかった筆者は，「ちまたで噂のGoogle App Engine for Java（GAE/J）とFlexでスケジュール共有ツールでも作ってみよう」と思い立ちました。およそ5日間かけて開発を進めたのち，2009年5月6日に「ご都合.com（画面1）」を公開しました。その後，はてなブックマークやニュースサイトなどでご紹介いただいたおかげで，公開後6日で約2000人の方にご利用いただいています。 そこで本稿では，この「ご都合.com」の開発で実際に筆者が得た経験を通じて，GAE/JによるWebアプリケーション開発の実際とそのポテンシャルについて紹介します。 米Googleが2008年4月に発表したGoogle App Engine（画面2）は，「自分が開発したWebアプリケーションをGoogleのデータセンターで運用できるクラウドコンピューティング・サービス」です
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
すごい現場
皆はどんな現場で，どんな仕事をしているのだろう。何に悩み，どうやって乗り越えているのだろう。プロの仕事とそうでない仕事の境目はどこにあるのだろう。システム開発や運用の現場を歩き，そこで見聞きした面白い話，感動的な話，すごい話を紹介します。 ・大企業からベンチャーまで ぼくはこんな現場を歩いてきた ・SEを潰した値引き 信頼も連帯感も消えた ・期限は明日――若手SEの気迫を見た ・寝不足のプレゼン ドリンク剤も効かず ・中国の開発現場もすごい 若き社長が率いる修羅場 ・オンラインダウン発生！ あの日，何もできなかった ・建築設計事務所で見た 巨匠のすごいレビュー ・コンサル泣かせの現場 “小さな王国”の弊害 ・逝去した巨匠への追悼 感激したあの言葉 ・人の話を聞かない40代 あるコンサルの失敗 ・過ぎたるは及ばざるがごとし 作りすぎたRFPの悲劇 ・人間万事塞翁が馬 得難いレクチャーの裏事情
特集2 ユーザーの本音を掘り出し，合意に導くヒアリングの技術
図3 ユーザーの協力を得られるようにヒアリングの場の冒頭で伝えるべきこと<br>上司に言われてヒアリングの場に来たユーザーは，趣旨を理解していなかったり，“やらされ感”にとらわれたりしがちだ。そこで，ユーザーに積極的に協力してもらえるように，ヒアリングの場の冒頭で伝えるべきことを挙げた。(1)(2)(5)はやる気を高める，(2)～(4)は何を話せばよいか分かるようにする，という効果を狙ったものである ITエンジニアにとってヒアリングとは，ユーザーとのコミュニケーションの根幹を成す。難しい合意形成の成否も，聞き方一つで大きく変わる。 第一線で活躍するIT エンジニアやコンサルタントが現場で培ったヒアリングのテクニックをまとめた。 日本ヒューレット・パッカード（HP）の伊吹進吾ITコンサルティング本部エクスプレスサービス部コンサルタントは，ヒアリングに関する苦い経験を忘れられないでいる。 5年
見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること：ITpro
秋田県大館市は2008年12月，市庁舎にIP電話を導入したことを公開した。同市は2005年6月に1市2町が合併して現在の大館市となった。以前の市と町の庁舎を有効活用するため分庁舎制をとっていたが，8庁舎9事務所間の連絡を公衆回線で行っていたため「多大な電話料金が生じていた」（大館市）。2006年，本庁舎の構内交換機を交換する時期に合わせ更新を検討した。電話料金の削減を狙いIP電話を検討したが，ベンダーからの見積もりは約2億円。電話料金の削減をあきらめて従来と同じアナログ交換機を更新する場合でも約2000万円との見積もりだった。 このとき，自前でのIP電話導入を提案した職員がいた。前述の中村芳樹氏である。中村氏は同市商工課の職員。電話網を担当する総務課ではなかったが，趣味で中学生のころからパソコンを使っており，独学でプログラミングも学んでいた。市でIP電話の導入を検討していることを耳にした中
Part5 SOAP，WSDL，REST――Web APIの基礎技術を学ぶ：ITpro
Web API（WebサービスAPI）をプログラミングで活用するにあたって，ぜひ知っておきたい基礎技術が三つあります。古典的な技術の代表としてSOAPとWSDL，そして昨今急速に普及してきたRESTです。ごく単純に言ってしまうと，前者は「高機能で複雑」，後者は「シンプルで簡単に利用可能」と区別できるでしょう。現時点では，そのシンプルさが多くの開発者に受け入れられたおかげか，REST方式が（先達である）SOAP方式を圧倒しているように見えます＊1。 もっとも，だからといってRESTがSOAPよりも優れていると結論付けるのは早計でしょう。昨今では，SOA（Service Oriented Architecture）という言葉に代表されるように，大規模なシステムを「サービス」という単位で構成し，互いに連携し合う設計手法が注目されています。特に，SOAを実現する具体的な基盤技術として注目されている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
