マイクロサービスとドメイン駆動設計の設計思想のメモ - プログラマの思索
@yusuke_arclamp さん、@sugimoto_keiさんが、マイクロサービスとドメイン駆動設計の設計思想に語っているつぶやきが参考になったのでメモ。 以下は、疲れた頭で思いついたことを書き殴り。 間違っていたら後で直す。 【元ネタ】 マイクロサービスとドメイン駆動設計の設計思想のTwiiter拾い - Togetterまとめ Martin Fowler氏がマイクロサービスの特徴について語る マイクロサービス移行の代償 マイクロサービスとSOA マイクロサービスアーキテクチャとは何か - arclamp SOAとマイクロサービスを複合設計に当てはめると見えるもの: ソフトウェアさかば マイクロサービスはコア資産 - Martin FowlerのMonolithFirstを読んで -: ソフトウェアさかば さかばさんはTwitterを使っています: ".@akipii こんなのもあ
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点 - プログラマの思索
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。 【参考】 GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録 GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ] Fujimura ? GitHubで既存のissueに対してpull requestする hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記 bleis-tift/Git-Hooks かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハー
ドメイン駆動設計に出てくる「モデル」とは何ですか？～第28回関西IT勉強宴会の感想 - プログラマの思索
第28回関西IT勉強宴会でドメイン駆動設計の講演を聞いてきた。 講演よりも1時間の質疑応答の方がとても参考になった。 ラフなメモ書き。 【元ネタ】 第28回 関西IT勉強宴会 : ATND 関西ＩＴ勉強宴会のブログです: 2013-12-13（金）第28回関西IT勉強宴会 ドメイン駆動設計を知ろう ドメイン駆動設計を知ろう(発表資料) ドメイン駆動設計入門 - Digital Romanticism ドメイン駆動設計の意義～MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築: プログラマの思索 ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り: プログラマの思索 SNSチームでのドメイン駆動設計の実践 | GREE Engineers' Blog 第53回 SEA関西プロセス分科会「ぐるぐるDDD/Scrum – モデリングと実装のうずまき
ドメイン駆動設計の意義～MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築 - プログラマの思索
ドメイン駆動設計の意義～MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築 @digitalsoul0124さんのBlogを読んで、自分は「ドメイン駆動設計」を完全に理解していないことに気づいた。 ラフなメモ書き。 論理的な文章でないので後で直す。 【元ネタ】 ドメイン駆動設計入門 - Digital Romanticism モデルが息づく場所 - Digital Romanticism 戦略的デザインに関する意思決定のための６つのエッセンス - Digital Romanticism ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り: プログラマの思索 ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プロ
ドメイン駆動設計を考え直す - プログラマの思索
「UMLモデリングレッスン 21の基本パターンでわかる要求モデルの作り方」を読んでいたら、とても面白かった。 OOAはDOAよりもモデリングが優れている本が多い気がする。 ラフなメモ書き。 【元ネタ1】 UMLモデリングレッスン - 安藤友晴＠北海道のてっぺん 「UMLモデリングレッスン 21の基本パターンでわかる要求モデルの作り方」では問題回答形式で、概念モデルについて説明しているのでとても読みやすい。 21のパターンも提示しているが、そのうち興味を引いたのは「リビジョン」パターン。 「リビジョン」パターンは、変更履歴を表現する概念モデルのパターンなのだが、部品表の仕様変更や自動車損害保険の契約変更にも適用できた、という話が興味深かった。 全く違う分野でも、概念モデルによる似たような解決方法があり、それがパターンになる。 OOAではオブジェクト指向らしくパターンも重視する。 そのおかげで
サーバー構築を構成管理とTDDで作業する時代になってきた - プログラマの思索
ChefやPuppetなど、サーバー構築をプログラムで作成する時代になってきた。 しかも、サーバー構築を構成管理とTDDで作業するのが最近の流れのようだ。 クラウドが当たり前の時代になった今、もう一つの技術革新が生まれているように思う。 クラウドについてはまだ理解不十分だけれども、気になる記事をメモ。 【元ネタ】 Chefのテストスイーツを色々試してみた （1） - カイワレの大冒険 Chefのテストスイーツを色々試してみた （2） - カイワレの大冒険 Chefサーバを動かすまでの方法をまとめてみた（自動化のススメ） - カイワレの大冒険 2008年出版された「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」では、ラストマイル問題が提示されていた。 ラストマイル問題とは、いくらソフトウェアを作っても、本番環境へリリース＆稼働確認するの
業務ロジックをデータモデリングはどこまで表現できるか？ - プログラマの思索
「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日本におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model
アジャイルの概念を取り入れたCMMI - プログラマの思索
岡本 隆史さんが、アジャイルの概念を取り入れたCMMIの記事を公開されていたのでメモ。 ラフなメモ書き。 【元ネタ】 徹底検証！ CMMIはアジャイルの改善にも役立つか？－ ＠IT情報マネジメント CMMI | CMMI Solutions | Translations | CMMI 日本語翻訳版 上記の記事を読むと、スクラムを例として、アジャイル開発のワークフローにCMMIの概念をマッピングして整合性を取ろうとしているように思える。 ScrumとCMM/CMMIの親和性については、「スクラム入門-アジャイルプロジェクトマネジメント」の一番最後の付録で既に書かれてる。 「スクラム入門-アジャイルプロジェクトマネジメント」では、ScrumのプラクティスはCMMMIのレベル2、3のKPAをほぼ網羅しており、不足しているKPAは、プラクティスの制度化とソフトウェア外注管理だけだという指摘がある。
分散バージョン管理はバージョンではなくリビジョンを管理する - プログラマの思索
InfoQの分散バージョン管理の記事を読んだ後に、もう一度、JoelがMercurialについて書かれた記事を再読して、ようやく分散バージョン管理が従来のバージョン管理ツールと何が違うのか分かったのでメモ。 ラフなメモ書き。 殴り書きの部分は後で直す。 【元ネタ】 分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project JoelもMercurialを使っている: プログラマの思索 InfoQ: エンタープライズ分野での分散バージョン管理システム 分散バージョン管理の可能性: プログラマの思索 (前略) 分散バージョン管理で実際のところ一番重要なのは、「分散」という部分ではないのだ。 重要なのは、このシステムが「バージョン」ではなく「変更」(注釈：リビジョン)で物事を捉えているということだ。 (中略) Subvers
分散バージョン管理の可能性 - プログラマの思索
InfoQに分散バージョン管理の可能性の記事があったのでメモ。 ラフなメモ書き。 【元ネタ】 InfoQ: エンタープライズ分野での分散バージョン管理システム (引用開始) DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30
ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り - プログラマの思索
エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。 @sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。 ラフなメモ書き。 【元ネタ】 ドメイン駆動設計: プログラマの思索 ドメイン駆動設計よりもパターン本が好き: プログラマの思索 ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 DOAとOOAの違い: プログラマの思索 Agile開発に足りないもの～モデリング技術: プログラマの思索 ドメイン駆動設計の本の違和感は二つある。 一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。 もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。 前者は、「ドメイン駆動設計」というタイトル通り「
「Redmineによるタスクマネジメント実践技法」はお早めに！ - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmine運用例part3～OpenPNE3 - プログラマの思索
Redmine.JP | Redmine on Twitterで、OpenPNE3が何故Trac＋SVNからRedmine＋Gitへ変更したのか、その理由と運用例が書かれていたのでメモ。 内容がとても素晴らしいので、共有する為に書く。 #下記は僕の想像の部分も含む。 【元ネタ】 【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git) - openpne-dev | Google グループ OpenPNE 3 - Ticket Workflow (ja) - OpenPNE Issue Tracking System Ope
Rails検証報告書 - プログラマの思索
日本OSS推進フォーラムという団体がRailsに関する調査結果を公開していたのでメモ。 【元ネタ】 日本OSS推進フォーラム 「RubyTF_Ruby_on_Rails検証報告書」 （PDF：975KB） おそらくIPOの外郭団体のような立場で、日本の大手SIの技術者がRailsを調査したらしい。 その報告書を読むと、Railsは企業向けにそこそこ使えるが、スケールアップやセキュリティ、技術蓄積にやや難がある、とのこと。 報告書で興味を引いたのは、セキュリティに関する所。 リダイレクト、Web アプリケーション内リンクをSSLにする対応は特に問題なく非常に簡単。 Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。 ここの仕組みが非常に分かりやすい。 Railsでは、HTTPセッションをシリアライズ化してCookieに書き込む。 この時、サーバーにもハッシュ
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 - プログラマの思索
TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。 TestLinkでテストしていきながら感じたことをメモ。 【1】ウォーターフォール型開発では、下流工程にテストが来る。 単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？ テストは基本的に、V字モデルの左側の工程の検証作業になる。 単体テストは開発工程の検証だが、結合テストの違いは何だろうか？ 単体テストは、最低限動作することを保証すること。 Exceptionが発生するようでは話にならない。 ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。 だから、コードカバレッジが非常に重要になる。 結合テストは、複数のモジュール同士を結合して動作するのを検証する。 普通のプロジェクトでは、結合テストで火を噴くことが多い。 理由は、結合テストになって初
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
