diff --git a/book/format_test.go b/book/format_test.go
index 351b823..7153b23 100644
--- a/book/format_test.go
+++ b/book/format_test.go
@@ -19,10 +19,10 @@ func TestFilename(t *testing.T) {
func TestToMarkdownString(t *testing.T) {
- c := NewChapterFromURL("https://12factor.net/", "", []*ScrapeConfig{NewScrapeConfig()}, 0, func(index int, name string) {})
+ c := NewChapterFromURL("https://example.com/", "", []*ScrapeConfig{NewScrapeConfig()}, 0, func(index int, name string) {})
got := ToMarkdownString(c)
- want := "The Twelve-Factor App\n=====================\n\nIn the modern era, software is commonly delivered as a service: called _web apps_, or _software-as-a-service_. The twelve-factor app is a methodology for building software-as-a-service apps that:\n\n- Use **declarative** formats for setup automation, to minimize time and cost for new developers joining the project;\n- Have a **clean contract** with the underlying operating system, offering **maximum portability** between execution environments;\n- Are suitable for **deployment** on modern **cloud platforms**, obviating the need for servers and systems administration;\n- **Minimize divergence** between development and production, enabling **continuous deployment** for maximum agility;\n- And can **scale up** without significant changes to tooling, architecture, or development practices.\n\nThe twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).\n\nThe contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the [Heroku](http://www.heroku.com/) platform.\n\nThis document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and [avoiding the cost of software erosion](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/).\n\nOur motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books _[Patterns of Enterprise Application Architecture](https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)_ and _[Refactoring](https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)_.\n\nAny developer building applications which run as a service. Ops engineers who deploy or manage such applications.\n\n## [I. Codebase](https://12factor.net/codebase)\n\n### One codebase tracked in revision control, many deploys\n\n## [II. Dependencies](https://12factor.net/dependencies)\n\n### Explicitly declare and isolate dependencies\n\n## [III. Config](https://12factor.net/config)\n\n### Store config in the environment\n\n## [IV. Backing services](https://12factor.net/backing-services)\n\n### Treat backing services as attached resources\n\n## [V. Build, release, run](https://12factor.net/build-release-run)\n\n### Strictly separate build and run stages\n\n## [VI. Processes](https://12factor.net/processes)\n\n### Execute the app as one or more stateless processes\n\n## [VII. Port binding](https://12factor.net/port-binding)\n\n### Export services via port binding\n\n## [VIII. Concurrency](https://12factor.net/concurrency)\n\n### Scale out via the process model\n\n## [IX. Disposability](https://12factor.net/disposability)\n\n### Maximize robustness with fast startup and graceful shutdown\n\n## [X. Dev/prod parity](https://12factor.net/dev-prod-parity)\n\n### Keep development, staging, and production as similar as possible\n\n## [XI. Logs](https://12factor.net/logs)\n\n### Treat logs as event streams\n\n## [XII. Admin processes](https://12factor.net/admin-processes)\n\n### Run admin/management tasks as one-off processes\n\n\n"
+ want := "Example Domain\n==============\n\nThis domain is for use in illustrative examples in documents. You may use this\ndomain in literature without prior coordination or asking for permission.\n\n[More information...](https://www.iana.org/domains/example)\n\n\n"
if got != want {
t.Errorf("got %q, wanted %q", got, want)
@@ -32,10 +32,10 @@ func TestToMarkdownString(t *testing.T) {
func TestToMarkdown(t *testing.T) {
- c := NewChapterFromURL("https://12factor.net/", "", []*ScrapeConfig{NewScrapeConfig()}, 0, func(index int, name string) {})
+ c := NewChapterFromURL("https://example.com/", "", []*ScrapeConfig{NewScrapeConfig()}, 0, func(index int, name string) {})
ToMarkdown(c, "")
- filename := "The_Twelve-Factor_App.md"
+ filename := "Example_Domain.md"
if _, err := os.Stat(filename); errors.Is(err, os.ErrNotExist) {
t.Errorf("%s does not exist: %v", filename, err)
} else {
@@ -49,7 +49,7 @@ func TestToMarkdown(t *testing.T) {
func TestToMarkdownFilename(t *testing.T) {
filename := "ebook.md"
- c := NewChapterFromURL("https://12factor.net/", "", []*ScrapeConfig{NewScrapeConfig()}, 0, func(index int, name string) {})
+ c := NewChapterFromURL("https://example.com/", "", []*ScrapeConfig{NewScrapeConfig()}, 0, func(index int, name string) {})
ToMarkdown(c, filename)
if _, err := os.Stat(filename); errors.Is(err, os.ErrNotExist) {
@@ -64,10 +64,10 @@ func TestToMarkdownFilename(t *testing.T) {
func TestToHtmlString(t *testing.T) {
- c := NewChapterFromURL("https://12factor.net/", "", []*ScrapeConfig{NewScrapeConfig()}, 0, func(index int, name string) {})
+ c := NewChapterFromURL("https://example.com/", "", []*ScrapeConfig{NewScrapeConfig()}, 0, func(index int, name string) {})
got := ToHtmlString(c)
- want := "
The Twelve-Factor App
\n \n\n \n \n \n\n \n \n\n\n
In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:
\n\n
\n
Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
\n\n
Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
\n\n
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
\n\n
Minimize divergence between development and production, enabling continuous deployment for maximum agility;
\n\n
And can scale up without significant changes to tooling, architecture, or development practices.
\n
\n\n
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
\n\n \n\n\n
The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform.
\n\n
This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.
\n\n
Our motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring.
\n\n \n\n\n
Any developer building applications which run as a service. Ops engineers who deploy or manage such applications.
This domain is for use in illustrative examples in documents. You may use this\n domain in literature without prior coordination or asking for permission.
In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:
\n\n
\n
Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
\n\n
Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
\n\n
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
\n\n
Minimize divergence between development and production, enabling continuous deployment for maximum agility;
\n\n
And can scale up without significant changes to tooling, architecture, or development practices.
\n
\n\n
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
\n\n \n
Background
\n\n
The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform.
\n\n
This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.
\n\n
Our motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring.
\n\n \n
Who should read this document?
\n\n
Any developer building applications which run as a service. Ops engineers who deploy or manage such applications.
This domain is for use in illustrative examples in documents. You may use this\n domain in literature without prior coordination or asking for permission.
In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that:
\n\n
\n
Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
\n\n
Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
\n\n
Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
\n\n
Minimize divergence between development and production, enabling continuous deployment for maximum agility;
\n\n
And can scale up without significant changes to tooling, architecture, or development practices.
\n
\n\n
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
\n\n \n\n\n
The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform.
\n\n
This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.
\n\n
Our motivation is to raise awareness of some systemic problems we’ve seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler’s books Patterns of Enterprise Application Architecture and Refactoring.
\n\n \n\n\n
Any developer building applications which run as a service. Ops engineers who deploy or manage such applications.
This domain is for use in illustrative examples in documents. You may use this\n domain in literature without prior coordination or asking for permission.