prix fixe [ pree fiks; French pree feeks ]
noun, plural
- 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.
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:
- SQLite as our data persistance
- ERB Templates for rendering HTML
- JBuilder for serializing to JSON
- MiniTest as our testing framework
- Fixtures to generate test data
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 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.
-
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.