MinGW - Wikipedia
MinGW（ミン・ジー・ダブリュー、Minimalist GNU for Windows）はGNUツールチェーン、GCCをWindowsで利用できるようにする開発環境である。Windows APIのためのヘッダファイルを含んでおり、GCCでネイティブWindowsアプリを開発できる。MinGW自体はほぼ開発終了だが、後継のMingw-w64が積極的に開発されている。 MinGWプロジェクトは32ビット環境向けに主に2つのパッケージを配布している。ひとつはWindowsに移植したGCCで、コマンドラインやIDEから利用できる。もう1つは軽量のUNIX風シェル環境であるMSYS (minimal system) である。端末エミュレータのrxvtと開発ツールのautoconfを実行するためのコマンド群も含まれている。これらはCygwinをフォークして誕生した。 Win32 APIを利用するため
4.ｼｽﾃﾑ開発工数の概要見積りの実施方法(How)
（３．２）工程別基準工数比率 1)工程別基準工数比率 前項の作業内容を前提とした工程別基準工数比率の一般平均は、図ＭＩ－４のとおりである。 図ＭＩ－４ 工程別基準工数比率 いっせい移行とは、例えば開発したシステムを全支店にいっせい移行する場合。 順次移行とは、例えば、同じシステムを全支店に移行するに際し、移行リスクを回避するために、第１段階では関東以北の支店を、第２段階では関西地区を移行、第３段階で残りの全支店を移行するというように、地域別に段階を分けて移行する場合を示す。 順次移行の場合は、第１段階ではテスト・移行工程に必要な工数は「0.5」相当必要であるが、第２段階以降は、段階ごとに「0.5×ｎ％」相当の工数追加が必要となる。 ｎ％は一般に２０％±１０％程度を追加する。 2)工程別基準工数比率の変化（91.12改訂） 工程別基準工数比率は、システム別特性（システム設計難易度）によって、
Androidアイコンジェネレータ
ガイドラインに沿ったアイコンを簡単に作成できるツールです。 「ファイルを選択...」から、白黒画像ファイルを選択してください。 Androidのアイコンを作るときには、公式で決められた、アイコンのデザインガイドラインに従う必要があります。 そのガイドラインでは、グラデーションの色や、影の付け方などが細かく決まっていて、普通に作ろうとすると結構大変です。 そこで、このツールを使えば、ペイントソフトで描いた白黒画像を選択するだけで、アイコンを生成してくれて、とても簡単。 アプリ開発はもちろん、モックの作成にも使えます。
Dynamic systems development method - Wikipedia
Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method.[1][2] First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method.[3] In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution deliver
7つのアジャイル開発手法の実践ガイド（第2回）
アジャイル開発手法を採用すべきだということはわかっていても、いろいろある開発手法をすべて検討しようとすれば、調査だけでかなりの時間がかかってしまいます。組織にとってどの方法論が適しているかを知るにはどうしたらよいでしょうか。この2回シリーズでは、7つの人気の高い開発手法の表と裏をすべて紹介し、組織に最適な開発手法を選ぶためのヒントを示します。第2回では、AUP、クリスタル、DSDMについて説明します。 はじめに 本稿は、さまざまなアジャイル開発手法を紹介する2回シリーズの記事の第2回です。本シリーズでは、7つの人気の高い開発手法の表と裏をすべて学習し、組織に最適な開発手法の組み合わせを選べるようになることを目的としています。第1回では、アジャイルの概要を説明し、エクストリームプログラミング（Extreme Programming：XP）、スクラム、リーン、機能駆動型開発（Feature D
はじめて使うJazz ― チーム開発のためのオープンな統合プラットフォーム
チーム開発のためのオープンな統合プラットフォーム「Jazz」 Jazzプロジェクトと言っても日本ではご存じない方もいらっしゃるかもしれません。「Jazz」とは、ソフトウェア開発チームのコラボレーションを支援するための新しいテクノロジー・プラットフォームであり、それらを開発するプロジェクトの名称です。大きな成功を収めたEclipseプロジェクトの次のステージとしてIBMが進めているプロジェクトです。Jazzプロジェクトは、人々がソフトウェア開発においてどのように協調して働くべきか、すなわち、いかにコラボレーションし、生産性を向上させ、透明性を確保してソフトウェア開発を行うかという観点で開発されています。 Eclipseは、エディター、コンパイラー、デバッガーなど開発者がこれまで別々に利用していたツール群を1つの環境に統合したプラットフォームを提供することによって開発者個人の生産性を向上させて
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
第13回 ［データモデル編］発注者が確認しやすいようにCRUD図をアレンジする
CRUD図を利用して発注者とレビューをされたご経験はありますか？ CRUD図というと一般的には以下のような図をイメージされるのではないでしょうか。 このCRUD図を使って，機能とデータの抜け・漏れや処理の集中，不完全な分割などがないかどうかを検証する「CRUD分析」で発注者に確認したいことが発生したときに，CRUD図をそのまま見せても，発注者はなかなか理解しずらいものです。 確認したい内容に絞り込んだ表を作成する そこでCRUD図をそのまま発注者に見せるのではなく，以下のようにアレンジしたCRUD図を作成してみましょう。 この図のポイントは以下の通りです。 ・申請書作成や承認といった処理のタイミングごとに，各エンティティの作成，参照，更新，削除があるかどうかを表した表形式にする。 ・確認したいエンティティとタイミングのみ記載する。 ・エンティティの数が多い場合は分類する。 ・作成，参照，更
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
良いユースケースを書くための発想法
システムの要求仕様を決めるのに、ユースケースを使うことがよくあります。 しかし、ユースケースは上手く書けない、何を書けば良いのか分からない、という人も、少なくありません。 たいていのユースケースは、アクターが１人２人いて、アクターが行える操作がいくつか丸で描かれて、それらが線で結ばれているだけの、とてもシンプルなものです。しかし、シンプルすぎて、何の役に立つのか分からない、という人もいます。 役に立つユースケースを書こうとして、細かいことまで書き込みすぎてしまう人も良く見かけます。しかし、それは誤りです。 ユースケースは何のために書くのでしょうか。ここでは、ユースケースの目的をはっきりさせて、良いユースケースを書くための考え方を紹介します。 開発者は、細かいことまでユースケースに書き込みがち Design Wave Magazine 2007年5月号別冊付録「組み込みシステム開発者＆LSI
POJOがしめすアプリケーションの形 (arclamp.jp アークランプ)
Javaの世界では、POJOというものが流行している。Plan Old Java Objectの略で、Martin Fowler氏らの造語だ。シンプルで、依存性をなくしたオブジェクトのことをさす。しかし、このPOJOというものをどう捉えるべきか、まだまだはっきりしていないのではないかと感じる。ここでも、僕なりの説明を試みるわけだが、正解といえるかは分からない。ただ、方向性としては間違っていないと思っている。 POJOとは まず、POJOを、もう少し詳しく定義するなら、「自分がするべきことに対して最低限しか知らないオブジェクト」、さらに「実行環境やフレームワークのことは一切知らないオブジェクト」といえるのではないか。たとえば、ビジネスロジックを担当するPOJOであれば、自分のするべきこと、まさにロジックと、そのロジックに必要な他オブジェクトのインターフェース（まさに、interface）し
＠IT：Spring Frameworkで理解するDI（1）
DI：依存性の注入とは何か？：Spring Frameworkで理解するDI（1）（1/3 ページ） Javaのエンジニアであれば最近、「Dependency Injection」や「DIコンテナ」「Spring」、または「Seaser2」といった名前を目にしたことがあるのではないでしょうか。これらは次世代のEJB（EJB 3.0）に取り込まれる動きがあるなど、最近非常に注目されているキーワードであり、今後のJava開発を語るうえで避けては通れない概念の1つになるとされています。 この連載は、「Spring」というフレームワークを利用して、J2EE開発における「Dependency Injection（DI）」というデザインパターンから得られるメリットを紹介し、J2EEの今後の方向性を理解する助けとしていただくことを目的としています。 Dependency Injection：依存性の注入
第8回 ウォークスルーとインスペクション--設計・開発の早期に欠陥を発見・除去し品質を作り込む
「ウォークスルー」と「インスペクション」は，システム開発の早い段階で欠陥を発見・除去するための方法である。開発者自身やチーム内の「モデレータ」と呼ばれる調整役が自主的に運営することが特徴だ。今回は，品質向上に欠かせないウォークスルーとインスペクションの具体的な実施手順を解説する。 布川 薫／日本IBM 前回は，プロジェクト遂行段階における品質のトラッキング方法（品質保証活動）の概要を説明した。今回は，システム開発において最もポピュラーで効果的な品質保証活動の1つである「ウォークスルー」と「インスペクション」の進め方を，読者が今からすぐにでも実行できるよう，具体的に説明しよう。 欠陥の発見が遅れれば遅れるほど，修正作業の手間がいたずらに増えることは，この連載でも再三強調してきた。肝心なのは，設計・開発の初期段階から，頻繁に欠陥の発見・除去活動を行い，テストの段階までに持ち越される欠陥を最少限
＠IT：連載：【改訂版】初歩のUML
ユースケースとは何か？ なぜ必要か？ 今回は、だれも書いたことがない視点から、オブジェクト技術者が理解しておくべきユースケースモデルについてのノウハウを解説します。そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきりしないと、よいソフトウェアなど作れるはずがありません。 筆者が初心者のころ、よく「構造化されたソフトウェアを考えてみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろうと試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」が目的であっては何も作れないのです。 では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソフトウェアがどのような人に、どう使われるか」ということなのです。今回は、UML
ユースケース駆動開発実践ガイド (OOP Foundations) | ダグ・ローゼンバーグ, Doug Rosenberg, 三河 淳一, 船木 健児, 佐藤 竜一 |本 | 通販 | Amazon
だれも教えてくれなかった外部設計の「極意」---目次
外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 ［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回 ［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回 ［画面編］画面遷移を
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Error in Report Manager - 'Unexpected end of file has occurred. The following elements are not closed: html.'