prix-fixe

Expand History Expand History
Collapse History Collapse History

Prix-Fixe

prix fixe [ pree fiks; French pree feeks ]

noun, plural

  1. a fixed price charged for any meal chosen from the variety listed on the menu.

According to the Ruby on Rails doctrine:

Rails is an omakase stack, it still allows you to replace certain frameworks or libraries with alternatives. It just doesn’t require you to. Which means you can delay those decisions until you’ve developed a clear, personal palette that may prefer the occasional difference.

This project aspires to put that claim to the test.

The Rules

Once the rails new command completes, the project is forbidden from adding or removing a Rubygems, NPM, or Yarn dependency.

This means that we’re stuck with Rails’ out-of-the-box setup, including:

The only exceptions to this rule are dependencies in our Gemfile that were introduced by a rails new command. For example, the bcrypt gem, the image_processing gem, and the redis gem can be made available as dependencies, since they’re generated by rails new as commented-out lines in the Gemfile.

The Goals

The primary goal is to tell Rails:

I’ll leave it up to you

and to see what happens.

We’ll do our best to build an application with the exact combination of tools that Rails provides us with.

Rails tutorials of yesteryear often aspired to build toy “microblogging” platforms, so this project will too.

As an alternative to building a Tw*tter clone, we’ll be building a Mastodon client. Mastodon is built atop the ActivityPub protocol:

The ActivityPub protocol is a decentralized social networking protocol based upon the ActivityStreams 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

The ActivityPub W3C Protocol Specification

The Strategy

  • This application will be built atop a foundation of server-generated HTML, hyper-linked to one another through referencing URLs.

  • This application will be progressively enhanced in environments where JavaScript is available.

  • This application will be test driven.

  • Each commit in our version control will rationalize changes, illuminate details of interest, and (with any luck) will be informative to its reader.

  • The project’s story will be told by its git-read website.

The git history will start with a step-by-step example illustrating the project’s development style: Test-Driven Development from the Outside-in. The diffs in these commits will contain the minimum amount of code to transition from one test failure to another, and will often contain the terminal output from each test run.

Once we’re finished iterating through a single Red-Green-Refactor cycle, the granularity of our commits will increase in both size and scope.

For the reader’s sake, imagine commits added after the end of the first cycle as the output of adhering to the same process as those created during that cycle.