あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
政府機関や企業から独立した組織として情報セキュリティ対策活に取り組んでいるJPCERTコーディネーションセンターが、ソフトウェアの脆弱性を減じるための資料「ソフトウエア設計工程における脆弱性低減対策 「セキュアデザインパターン」（日本語版）」（pdf）を公開したと、ITmediaエンタープライズの記事「ソフトウェア設計の安全性を高める技術資料、JPCERT/CCが日本語公開」が伝えています。 ソフトウェアのデザインパターンとは、ソフトウェアの設計をするときに使える設計ノウハウをまとめたものです。有名なものに「ギャング・オブ・フォー」と呼ばれる4人の専門家によってまとめられた書籍「オブジェクト指向における再利用のためのデザインパターン」で紹介された23種類のパターンなどがあります。 この資料ではどんなデザインパターンが紹介されているのか、のぞいてみることにしましょう。 アーキテクチャ、設計、
ソースコードの分かりやすさは、「単一責務の原則」と「関心毎の分離」により適切に構造を分割した、バランスのいいところにあると前のエントリに書いた。では、そこにモジュラリティが加わるとどうなるだろうか。 モジュラリティとは、システムを幾つかのモジュール*1に分離し、さらに分離したモジュールを組み合わせて新しいシステムを組むソフトウェア開発法、とここでは定義する。分かりやすい例はEclipseだ。例えばPyDevを導入すればPythonの開発環境が手に入る。このように言語環境ごとに作られたプラグインを導入すれば、それぞれの言語で開発ができるIDEが構築できる。EclipseはIDEとして必要な機能の全てをプラグインという形のモジュールに分離し、組み合わせる事でモジュラリティを実現している。*2 モジュラリティの利点と欠点を上げてみよう。 利点 モジュール毎に独立して開発できる モジュールに分割で
利己と利他で分けましたが、どちらが良いとか悪いとかはないです。開発動機は利己か利他なのですが、結果的には社会に役に立ちます。アプローチが違うのです。 そのアプローチによって、仕様決定工程、意思決定者、品質評価者、開発工程、価値基準はまったく別物だと言う事です。 利己的開発：自分自身の問題を解決（開発）するアプローチ 自分の困っていることを発見、開発。そして同じ問題で困っている人が使い、社会に役に立とうとするアプローチです。 すごい製品やサービスを生み出す最も単純な方法は、あなたが使いたいものを作ることだ。 自分の知っているものをデザインするのなら、作っているものがいいかどうかすぐに判断がつく。 僕たちに必要なものを作ったまでだ。 〆 〆 〆 発明家のジェイムズ・ダイソンは、自分の問題を解決した。 自宅を掃除機で掃除をしているとき、紙パック式の掃除機がどんどんパワーを失っていくこ
透明性の原則デバッグや調査が簡単になるように、わかりやすさを目指して設計せよどういうこと？デバッグを楽にするタメには、透明性と開示性を意識して設計することです。透明なソフトウェアシステムとは、一目見てすぐに何をどのようにしているのかが理解できるシステムのことです。開示性を持つプログラムとは、内部状態を監視、表示する機能を持っており、適切に機能するだけではなく、適切に機能しているところが見えるようになっているプログラムのことです。これらの性質を持つように設計するということは、プロジェクト全体に暗黙の影響を与えます。少なくとも、デバッグオプションは「オマケ」であってはならないという考えが貫かれるはずです。デバッグオプションは、最初の段階から設計に組み込まれていなければなりません。プログラムは自らの正しさを実証することができなければならないのと同時に、オリジナルの開発者の問題に対する考え方を将来
単純性の原則単純になるように設計せよ。複雑な部分を追加するのは、どうしても必要なときだけに制限せよ。どういうこと？プログラムは、さまざまな圧力によって複雑化する傾向があります。技術を誇示しようとするプログラマの気持ちも、そのような圧力のひとつです。プログラマは、複雑さを処理し、抽象を手玉に取る能力を誇る聡明な人々です。プログラマは、もっとも美しく入り組んだコンポーネントを作れるのはだれかを示すために、同僚と競い合うことがよくあります。しかし、設計能力が実装/デバッグ能力を追い越してしまうことが多く、高くつく失敗をもたらすことになります。過度な複雑化の原因としてよく見られるのが、プロジェクトの要求の問題です。プロジェクトは、顧客が望んでいるものとか、ソフトウェアが実際に提供できるものといった現実の問題によってではなく、市場の変わりやすい流行によって支配されがちです。だれも使わないような（しか
ちょっと前からDIコンテナの必要性について考えているのだけど、 結論としては「DIコンテナは必要なところに使えばいい」と思う。 必要なところの例は、DBコネクション周りの設定ファイルを 本番環境と開発環境で変わる場合。 DBの接続先が変わる（または変える予定がある）場合は、 そこはDIや設定ファイルとして外部で制御できるようにすべき。 ただ、こういう環境の差異の吸収目的以外の使用でDIが絶対に必要になる という箇所はあまり思いつかない。 テスティングしやすくするためにDIコンテナ使うのだったら、 TDDで書いてテスティングの時だけDIコンテナ使えばいいのでは？と思う。 で、自分なりに考えたSlim3にDIコンテナが無い理由なんだけど、 App Engineの場合、DIが必要になりそうな「本番と開発環境の差異」を Googleが提供しているもので吸収することができるから。 Slim3だとAp
バグゼロのための設計原理 昨今、いかにソフトウェアの不具合を減らすべきかという議論がいろいろとなされています。現状として、量産直前での総ざらい、過去トラチェックで不具合を発見しても、待ち構えているのはあまりにも大きな手戻りと、穴を空けてしまう日程への困難な交渉業務です。 そこで、よく言われるようになってきたのが、“日々の品質の作り込み”＝“先手管理”が大切だということですが、スローガンとして理解できても、さて担当として何を実践すればよいのか迷うところです。もう少し、具体的にブレークダウンした方法論は、何かないのかと調べてみました。 その結果、以下の表に示す七つの実践原理をソフトウェア工学の論文より見つけてきました。［君島 浩氏（富士通）論文より部分引用］ 少しでも皆様のお役に立てるようここに公開します。
七つの設計原理概要障害を作り込まないために考慮すべきプログラム構造上の七つのポイントである。実際に検出された障害の一件一件について、どうしたら開発時に障害を作り込まないようにできたかという観点から根本原因を分析した結果、導かれた原理である。一覧単純原理 自然であれという原理同型原理 形にこだわるという原理対称原理 形の対称性にこだわるという原理階層原理 形の階層的美しさにこだわるという原理透明原理 透明性こだわるという原理明証原理 ロジックの明証性にこだわるという原理安全原理 必然性を意識するという原理 参考ソフトウェア品質知識体系ガイド―SQuBOK Guide作者: SQuBOK策定部会出版社/メーカー: オーム社発売日: 2007/12メディア: 単行本Amazon.co.jpで詳細を見る3.4.29Ｔ：七つの設計原理【富士通】 日野克重，ソフトウエア障害の分析と予防，第４回ＳＰＣシ
皆さんは，自分が構築するシステムがユーザーにとって使いやすくなるように，普段から何か工夫をしていますか？レスポンスなどの性能要件や，情報漏えい対策などのセキュリティ要件は，十分に考慮していると思います。これら性能要件やセキュリティ要件と比べると，使いやすさ，すなわちユーザビリティについて考慮することは少ないのが現実ではないでしょうか。 ユーザビリティを向上する施策は，以前から研究・実践されてきました。しかし，それは，ユーザビリティに関する高度なスキルや知識を持ったプロフェッショナルによって実施されることが多く，特に情報システムの分野では実施されることは少なかったのです。ユーザビリティの向上施策は，高度なスキルと知識がなければできないものと思っている方が多いと思います。しかし，やり方が分かれば，実践できることは多いのです。 筆者が所属する日立システムアンドサービスでは「ユーザビリティを向上す
システム開発を効率化するために、過去に開発した資産の“流用”がよく行われている。エクスプレス開発の場合、最初から“再利用”を前提に開発を行い、その“開発思想”を記録として残すことで、より積極的に既存資産を活用する。 前回『“すべてを任せてもらえる「専門家」になろう 』では、顧客企業との打ち合わせの早い段階で、SEが「専門家」と認められれば、スケジュールを含めたあらゆる提案が受け入れられやすくなる──すなわち短納期化に貢献する、といったことを解説しました。 ただ、これは短納期化に不可欠な要素ではありますが、直接的に寄与するわけではありません。短納期化には、もっと具体的な考え方や方法論、そして、日ごろからの準備や工夫が必要なのです。今回は、そうした短納期化の方法論の1つとして、「システムの再利用」について解説したいと思います。 “流用”と“再利用”は違う SEやベンダのスタッフは「過去の開発資
すでにあるものを使う――再利用はソフトウェア業界長年のテーマだが、一筋縄ではいかない。その問題点とは？ ソフトウェアの開発生産性の向上は、開発組織にとって永遠のテーマといえるでしょう。さまざまな言語やフレームワークが“生産性の向上”をうたい文句に、世に現れては消えていきます。しかし、それら新しい道具立てへの関心は、主に、「ゼロから構築するときにいかに速く」という文脈で語られることが多いように思います。その一方で、“再利用”はそもそも「いかに作らずに済ますか？」を念頭に置いた異なるアプローチです。ソフトウェア再利用は、『ソフトウェア再利用の神話』（※）という名の書籍が出るほど、1つの理想とされながらそれをどう実現するか？という具体化の段階で多くの組織が立ち止まってしまう“難しいテーマ”と思われています。 筆者が所属するIBM Rational部門は、オブジェクト指向技術を土台に、設計開発の技
Railsを使って既存のJavaアプリケーションを書き直しているのだが、当時自分たちでで書いたプログラムに対して標題の言葉が浮かんでしまう。 当時、既にEJB(EJB1.1)に見切りをつけて独自のDAO(今のように立派なものではなくハッシュに属性を格納しただけのシンプルなもの)を使い、フロントコントローラー+MVC、ビューはJSP(除くスクリプトレット)とかなりシンプルにしたつもりだが、今見るとどうしても冗長で七面倒くさく感じる。 結局、当時は生産性が大事と言いながら、実は生産性のことなんてこれっぽっちも考えていなかったんだだろうか。いや、そんなことは絶対に無い。 同じようなケースを経験されている方はたくさんいるだろうと思うが、 「ひょっとしたらここは〜と変更されるかもしれないので結合を緩くしておこう」 「ここは〜のように修正されてもコンパイルの必要が無いように括りだしておこう」 「データ
2009-09-26 北陸Scala第1回開催 2009-04-04 第十四回java-ja勉強会 - 第1回チキチキ 地方巡業withひがやすを飲み会in富山開催 2009-03-20 わんくま大阪勉強会#28 「ジェネリクスを使おう！」 2008-11-08 わんくま富山勉強会#1 開催 2008-08-09 わんくま東京勉強会#23 「C#登場前夜」 2008-04-01 *で始まるタイトルはエイプリルフールネタです 2008-01-26 わんくま東京勉強会#16 「ライブプログラミング」 2007-12-08 わんくま名古屋勉強会#1 「わんくま初めてのJava」 2007-07-28 開店
公私共にモチベーション低いですが、久しぶりに独りよがりなデザパタ講座です。 今回はGoFデザインパターンより、「Proxyパターン」をぬるーく解説します。 ■Proxyパターンの概要■ Proxyとは「代理人」という意味です。 現実の世界での「代理人」のイメージは、弁護士や税理士など、 本人ができない仕事をするという意味合いで使われることが多いが、 GoFのProxyパターンにおいての代理人オブジェクトの役割というのは、 本人ではなくてもできるような処理について、要求を委譲されるオブジェクトのことを言います。 代理人オブジェクトでは処理のできない要求のみを、本人オブジェクトが引き受けて処理をします。 つまり、RealSubject(本人オブジェクト)へのアクセスを制御するために、Proxy(代理人オブジェクト)でRealSubjectをラップします。 生成にコストのかかる要求や、生成に注意
目次 プラトン的モデル 言うべきことを言う コンテキスト 価値提案を把握する 単一責任システム エンティティは ID とライフサイクルを持つ 値オブジェクトは記述する 集計ルートによりエンティティを結合する ドメイン サービス モデルの主要な操作 リポジトリにより集計ルートを省略する データベースの関連事項 DDD の使用を開始する ドメイン駆動設計 (DDD) とは、洗練されたオブジェクト システムの設計に役立つ原則とパターンをまとめたものです。設計に DDD を適切に適用することで、ドメイン モデルと呼ばれるソフトウェア抽象化を実現できます。このモデルにより複雑なビジネス ロジックをカプセル化できるため、実際の業務とコードとの間に存在するギャップを小さくすることができます。 この記事では、DDD に関連する基本的な概念と設計パターンについて解説します。機能豊富なドメイン モデルを設計し
どうも。夏休みボケなDQNです。 id:kagamihogeさんの「リッチなアプリ開発はデータバインディングが一つのキモ」が 非常によいエントリです。 とりあえず重要なのは、Web ベースの業務アプリの流行の一つに、 再びクライアント側重視の流れがあるらしいこと。Web アプリは、サーバサイドで 色々ゴチャゴチャ処理したあと最後にヴァーンと html を吐き出して終わり、というシンプルなのが 基本形である。しかし、Ajax, Flex, Silverlight などなど―どんな技術を採用するのかの 違いはあるが―こうしたリッチな技術を使う場合、データ表現は html、サーバ側で何がしか処理、 とシンプルな分離だけでは収まらなくなる。 http://d.hatena.ne.jp/kagamihoge/20080925/1222337488 この辺に激しく同意ですね。言い方を変えれば、クライア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く