- 更新
2023-12-08
- 作者
@voluntas
- バージョン
2023.2
- URL
タイポなどは Twitter の @voluntas までお願いします。
2023-12-08
@voluntas
2023.2
タイポなどは Twitter の @voluntas までお願いします。
2020-05-06
2020.5
このプロダクトに興味がある人はこの資料に Star をつけてもらえると嬉しいです。
2023-12-14
2023.1
@voluntas
概要
アジャイルプロジェクトのアーキテクチャは、別々に記述され定義されなければなりません。すべての意思決定が一度にされるわけでもなく、プロジェクト開始時にすべての意思決定がされてるわけでもありません。
アジャイル手法では、ドキュメンテーションに反対はしませんが、価値のないドキュメンテーションはいけません。チーム自身の助けになるようなドキュメントは価値がありますが、ちゃんと最新化し続けなければなりません。膨大なドキュメントでは、最新化されなくなることでしょう。小さくまとまりのあるドキュメントは少なくとも更新される可能性はありますよね。
また膨大なドキュメントはだれも読みません。たいていの開発者はソースコードサイズの合計よりも(byte的な意味で)大きな仕様書が書かれたプロジェクトを少なくとも1回は経験したことがあるでしょう。開くのにも、読むのにも、更新するのにも、そんなドキュメントは大きすぎます。一口大のピースに分解すれば、すべての関係者にとって消化するのは簡単になりますよね。
プロジェクトが動いている間、追跡するのが難しいことの1つに、ある意思決定の裏に隠された「思い」があります。プロジェクトに新しく参画した人は、それまでに決定されたことに困惑したり、戸惑ったり、喜んだり、怒ったりすることでしょう。理念や因果関係を理解しておかないと、その人は次の2つの選択をすることになります。
2023-07-09
2023.2
1
2023-10-04
@voluntas
2023.2
relx コトハジメ の内容を把握している読者を想定しています。
Dockerイメージなどを開発環境にしていると、なるべく実際に動く環境に近いような動作環境でテストしたくなります。
一方で、開発環境というのはなるべく手間なく勝手にコンパイルやテストが走ったり、変更点を勝手にリロードしてほしいものです。
relx を使ってリリースイメージに近いような環境でソフトウェアを起動しつつ、 sync を使って自動コンパイル&リロードする環境を作ろうというのがこの記事の趣旨です。
2014-09-22
0.2.1
@voluntas
概要
2024-04-16
@voluntas
2024.2
概要