ドメイン特化言語の感想～ドメイン専門家とプログラマが会話するための環境作り - プログラマの思索
ファウラー著「ドメイン特化言語」を読んだ。 やはり、ファウラーはIT業界の未来について、いつも一歩先のことをよく考えている。 自分が理解できたこと、感想をラフなメモ書き。 【参考】 ごあいさつ - DSL翻訳者の悩み 48章(DecisionTable)のクラス図 - DSL翻訳者の悩み 41章(Dynamic Reception)のクラス図 - DSL翻訳者の悩み 【1】ステートマシンの例からDSLの意義を考える 第1章で、ステートマシンの例を持ちだして、DSLが何故必要なのかを説明してくれている。 自分が本を出版してみて分かったことは、本の最初で、この本で言いたいことは何なのか、を明示することが重要。 普通は最初に、具体例や問題を提示して、本で言いたい主張を概略的に述べると、読者を引き込みやすい。 ステートマシンの例では、Javaで実装したステートマシンを各インスタンスごとに振る舞いを
Gitの差分比較が重要な理由 - プログラマの思索
Diffが重要な理由について良い記事が書かれていたのでメモ。 【元ネタ】 テキストでないファイルのdiff（差分）をとる方法 - ザリガニが見ていた...。 (引用開始) 一旦diffの恩恵を経験すると、差分をとれない環境というのがとても不安に思えてくる。あの、MacBook ProのRetinaモデルのデスクトップピクチャに採用された写真家のKent Shiraishi氏も、常時モニタを２台並べて写真の色合いのチェックをしているそうである。曰く、自分の感覚なんて当てにならない、正確な色を再現するためには完璧にデジタル調整されたモニタを並べて、その違いを感じて現像するそうである。つまり、色の差分を見ているのだ！差分を知ることはとても大切。写真でも、テキストでも。 (引用終了) プログラム、テキスト、WordやExcelのドキュメント、そして写真すらも差分比較するのは重要という指摘。 テキス
【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy - プログラマの思索
【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy 【1】最初に断っておくと、本資料は完成版ではない。 TiDDを原則・価値・プラクティスなどで体系化した場合、どのように表現できるか、作業仮説として作成している。 だから、説明不足や不整合の部分もある。 特に、発表時間が25分枠だったため、言いたいことをかなり濃縮しているので、行間を読み取ってもらえると嬉しい。 体系化の方針としては、ツールに依存しないように説明することと、プラクティスをパターン言語で表現することに注力した。 TiDDはRedmineでもアナログでも運用可能であるし、そのような事例も既にある。 だから、ツールに依存しないように抽象化した概念でより普遍的に説明できないかと思っている。 また、プラクティスを特定の状況の問題に対する解決法
パターンランゲージの形式と正当性 - プログラマの思索
パターンランゲージについて調べ直している。 コプリエンの組織・開発工程のパターンランゲージの序文がとても意味深だったので、理解できたことをメモ書き。 「プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集」にも記載されている。 【元ネタ】 生成的開発プロセス・パターンランゲージ はじめに 生成的開発プロセス・パターンランゲージ - lamuuの勿忘草日記 Scrum:超生産的ソフトウェア開発のための拡張パターン言語 - XPとパターン Ralph Johnson'sの見解 - 組織パターンとプロセスパターン(石井 勝) 【1】アレグザンダーが生み出したパターン言語というアイデアを、IT業界にも使えないか、という発想が生まれた。 GoFもケントベックもカニンガムもコプリエンもその流れにいる。 その辺りの経緯は「パターン、Wiki、
プログラマの思索
astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ
パターン、Wiki、XPは良書 - プログラマの思索
「パターン、Wiki、XP」を読んだ。「ThoughtWorksアンソロジー」のようにエッセー風だが、本質的なことがたくさん書かれているような気がした。 感想をラフなメモ書き。 【元ネタ】 パターン、Wiki、XP - 第1部：建築 - Li:d tech パターン、Wiki、XP - 第2部：ソフトウェア開発 - Li:d tech パターン、Wiki、XP - 第3部：Wiki - Li:d tech Smile Experience: パターンランゲージの会 404 Blog Not Found:時を超える創造の原則 - 書評 - パターン、Wiki、XP 書評リンク集 - 『パターン、Wiki、XP』サポートWiki 『パターン、Wiki、XP - 時を超えた創造の原則』感想、少しばかりの余談 - antipop 『パターン、Wiki、XP』と「協働＝お互い様」のマーケティング |
分散バージョン管理のブランチは仮想フォルダ - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
バージョン管理ツールを使うとやる気が出る - プログラマの思索
「バージョン管理ツールを使うとやる気が出る」という文章に激しく同感。 【元ネタ】 論文を書くときにTeXを使う個人的な理由 - より良い環境を求めて (前略) それからバージョン管理ツールを使うとやる気が出る。 これはgitwebを使い出した効果で、履歴一覧で前回の変更からの経過時間が「1 hours」とか出る。 これが「5 hours」とかになってくるとやばいという気になってきて、とりあえず何でもいいからコミットする。そうすると、やる気はやり始めてから出るの法則で少しずつ進む。 「3 days ago」とかになってきたらもう「。」を「．」に変えるだけとか「である．」を消すとかそういう些細なことでも何かコミットしなきゃという気になってきて、そこから書き始めることができる。 (後略) ソースだけでなくExcelやWordに書いた設計書もバージョン管理すべき。 更新履歴を見るだけで、更新しなき
Redmine＋Mercurialの設定方法 - プログラマの思索
RedmineとMercurialの連携の設定をメモ。 【元ネタ】 RedmineでMercurialを使う方法 - 床のトルストイ、ゲイとするとのこと TortoiseHgでExcelの差分を見る方法: プログラマの思索 All In One Redmineを見つけた: プログラマの思索 Windows＋Redmine0.8.4＋ToroiseHg0.8.1では2箇所でエラーが発生する。 修正方法は下記の通り。 【修正対象】 lib/redmine/scm/adapters/mercurial_adapter.rb 【修正箇所】 L27 HG_BIN = "C:/Program Files/TortoiseHg/hg.exe" L40 theversion = "1.3.1" L27では、元来Unix上のHgのパスをTortoiseHgのパスへ変更する。 L40では、Mercuiralの
チケット駆動開発を開発プロセスへ理論化できるか？ - プログラマの思索
下記Blogで、これがやりたいことなんだ！と思ったのでメモ書き。 【元ネタ】 実践バグ管理―プロジェクトを成功に導くための (単行本) - watawata日記 まあ要するに僕が読みたいのはバグ管理も含めた構成管理とか開発プロセスの本なんだｗ。 僕が考えるプロジェクト管理サーバーのイメージは下記の通り。 RedmineやTracのようなプロジェクト管理機能を持つBTSをチケット駆動でタスク管理する。 Subversionで、ソースコードだけでなく、WordやExcelの仕様書もバージョン管理する。 更に、trunkとブランチを上手に使い分けて、メインラインモデルとしてコードラインを並行開発する。 Hudsonで、継続的インテグレーションを実現するだけでなく、並行に走らせて、ビルドや自動テストの工数を短縮する。 TestLinkで受入テストを効率化する。 VMWareでテスト環境、本番環境を
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
金曜にバグを発生させるコミットが多い - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プロジェクト管理サーバーとは - プログラマの思索
僕が考えているプロジェクト管理サーバーについて良い記事があったのでメモ。 【プロジェクト管理サーバーのイメージ】 そろそろプロジェクト管理ツール群について一言言っておくか - Talking Nonstop プロジェクト管理サーバーの目的は、SW開発で必要なインフラを提供することにある。 基本は、タスク管理(Redmine・Trac)とバージョン管理(Subversion)。 タスク管理の目的は、プロジェクト内部の作業全てを見える化して、一元管理すること。 RedmineやTracの運用の鍵は、タスクをチケットにどこまで分割して、アジャイル開発のイテレーションへどのように落とし込むか、という点にある。 つまり、分割したチケットをリリース単位にまとめて、小規模リリースできるか、という観点が大事。 バージョン管理の目的は、プロジェクト内部で発生する全ての成果物を一元管理すること。 バージョン管
Redmineにお勧めソース機能が欲しい - プログラマの思索
今日、XP祭り関西2009が無事終了した。 参加してくれた人、ありがとう！ 「チケットファーストでアジャイル開発！」で講演した時、ぽろっと話した「お勧めソース機能」を参加者の一人から質問されたので、メモしておく。 【仕様】 Redmineのリポジトリ欄で、選択したソースを表示した時、関連する他ソース一覧を表示する。 具体的には、そのソースを過去に修正した全てのソースのうち、 ・同じチケットでコミットされたソース ・同じリビジョンで何度もコミットされているソース で頻度が高い順番に表示する。 【要件】 本来のイメージは、Amazonのお勧め商品やiTunesのお勧め曲の表示機能みたいなもの。 例えば、Amazonの商品画面では、「この商品を買った人は過去にこんな商品も買っています」という商品が頻度の順に表示される。 iTunesでも同様に、この曲をダウンロードした人は、他にこんな曲もダウンロ
Subversionを見直せ - プログラマの思索
SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iPadと教育 - プログラマの思索
Vistaの無限再起動 - プログラマの思索
hgbook 日本語版のHTML公開 - プログラマの思索