{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Ryan Fowler",
  "home_page_url": "https://ryanfowler.com/",
  "feed_url": "https://ryanfowler.com/feed.json",
  "description": "Notes on software and systems.",
  "authors": [
    {
      "name": "Ryan Fowler",
      "url": "https://ryanfowler.com/"
    }
  ],
  "language": "en",
  "items": [
    {
      "id": "https://ryanfowler.com/blog/hello-world/",
      "url": "https://ryanfowler.com/blog/hello-world/",
      "title": "Hello, World",
      "content_html": "<p>Every personal site begins with an empty page and a decision: what belongs here?</p>\n<p>For this one, the answer is <strong>writing</strong>. It is a place for notes about software, systems, tools, and the lessons that emerge while making things. The site itself follows the same practical spirit. A small Go program turns Markdown into plain HTML and CSS. There is no database, client-side framework, or build service to understand.</p>\n<h2 id=\"why-keep-it-simple\">Why keep it simple?</h2>\n<p>Simple systems are easier to change. The whole site can be built with one command, inspected with ordinary tools, and deployed almost anywhere. Every page continues to work without JavaScript.</p>\n<p>That does not mean the design must feel generic. Constraints can make the important choices clearer: type, space, rhythm, color, and the words themselves.</p>\n<blockquote>\n<p>The goal is not to use the fewest possible tools. It is to keep the distance between an idea and a published page short.</p>\n</blockquote>\n<p>There will be more here over time. For now: hello, world.</p>\n",
      "summary": "A short note about keeping a personal site small, fast, and easy to own.",
      "date_published": "2023-06-17T00:00:00Z"
    },
    {
      "id": "https://ryanfowler.com/blog/shape-of-a-useful-tool/",
      "url": "https://ryanfowler.com/blog/shape-of-a-useful-tool/",
      "title": "The shape of a useful tool",
      "content_html": "<p>The best tools can be difficult to notice. They fit the work closely enough that the interface recedes and the result stays in view.</p>\n<p>Software often moves in the other direction. A small need accumulates settings, modes, and extension points. Each choice makes sense in isolation. Together, they ask the user to understand the tool before doing the work.</p>\n<blockquote>\n<p>“The best modules are those that provide powerful functionality yet have simple interfaces.”</p>\n<p><small><cite>— John Ousterhout, A Philosophy of Software Design</cite></small></p>\n</blockquote>\n<h2 id=\"start-with-the-common-path\">Start with the common path</h2>\n<p>A useful tool should make its main task obvious. Good defaults are part of the interface, not an alternative to it. They encode a clear opinion while leaving an escape hatch for the cases that genuinely need one.</p>\n<p>This static site generator has one common path:</p>\n<pre><code class=\"language-sh\">go run ./cmd/site build\n</code></pre>\n<p>That command validates the articles, renders the pages, minifies the assets, and writes a directory ready to deploy. The implementation can change without making the publishing workflow more complicated.</p>\n<h2 id=\"keep-the-seams-visible\">Keep the seams visible</h2>\n<p>Simple does not mean opaque. Plain Markdown goes in. Plain HTML comes out. A writer can inspect either side with tools that will still exist years from now.</p>\n<p>A useful tool makes routine work quiet and unusual work possible. Finding that balance is less about adding features than deciding which ideas the tool can safely hide.</p>\n",
      "summary": "Good tools reduce the number of decisions required to do good work.",
      "date_published": "2023-06-16T00:00:00Z"
    }
  ]
}