After two years of learning Swift, building two iOS apps and one Mac app, I decided it was time to venture into the web. As much as I love the Apple ecosystem and building apps for its platforms, two things motivated me to also give the web a try:

  1. Building apps for iOS is a game of numbers.
    High numbers, to be exact, because with a few cents lifetime revenue per user (since most of freemium users never pay), you’re gonna need a whole lot of them (users, that is). Instead, I want to give the IndieHacker/Bootstrapper world a try: deep down the niche, solving a big problem for a small market. A manageable number of customers, each of whom I can individually sell and cater to, with a decent margin for for every customer.

  2. Creating a B2B product, instead of chasing after consumers.
    Not that Apple’s platforms aren’t capable enough to attract professionals, but the SaaS route lives much more on the web than on the iPad.

Living without Apple’s 30% revenue cut is a nice bonus, even though I still believe it is a fair (yet still high) share. 30% might be compared to a wholesale distribution margin, and with all the amenities Apple provides to developers, I’m willing to pay for that. Also, Tim Cook loves service’s revenue, so I’ll let him have it.

Choosing a framework

An often cited fact is that there are more galaxies in the universe than grains of sand on the earth’s beaches. A less known fact is that there are also more web frameworks than galaxies in the universe.

Choosing a framework to start with was probably never easy, but in 2020 there’s a real choice overload: JavaScript frameworks are everywhere and Node has almost become the industry standard. Except now PHP lives again thanks to Laravel, Rails has another resurgence with DHH at the forefront and Hey.com making waves. There’s even people who swear on Java Springboot and .NET. And also, what about Django, Elixir…?

All of them have their merits, so personal preference is key here (assuming a basic CRUD-app, for which the technology hardly matters). I prefer convention of configuration, and a toolbox that comes with defaults for most tasks and has proven its worth. So I chose Ruby on Rails. Optimising for programmer happiness? Yes please. Rails has a large and mature ecosystem and feels like a “get the job done” kind of tool. Which is what I want. I don’t consider myself a particular gifted programmer, but rather someone who likes to build things with whatever tool does the job. From what I could find, Rails does fit that description.

Learn enough to be dangerous

So, where to begin? As with any framework, there are a plethora of courses, tutorials and books that cover the subject. Based on all I’ve read, the best bet is to start with Hartl. Michael Hartl. Which is basically the rest of this post: My experience with going through Michael Hartl’s “Ruby on Rails Tutorial” in the sixth edition.

The book’s premise is to take you from no Rails knowledge whatsoever to being capable to build whatever web app you want1. Having a basic understanding of programming (classes, methods, types & objects, inheritance and general Linux-based workflow with the command line and Git) certainly helps and lets you skip ahead a bit.

This is my first time going through a dedicated “course” with this book. With Swift and iOS, I went tutorial hopping and it took me months to get even a basic understanding of iOS app architecture. The goal with a dedicated, multi-week book is to get all of that in one consecutive learning experience.

The target is the same: learn enough to be able to venture forth on your own, with Google and StackOverflow by your side. Having a fundamental understanding of the core principles, combined with knowing what to type into Google when you hit a road block - that’s all I’m aiming for.

A Twitter clone in 14 chapters

The book covers a lot in its 14 chapters, so here’s a small summary of what you can expect:

Setup
The book walks you through installing Rails in various ways, setting up your development environment2 and the Git workflow for version control. You’ll also learn the basic organisation of a Rails app, its folder structure and most important commands. Before getting to the main app you’ll build during the course of the book, there is a small introduction to Rails scaffolding to get started. I was slightly awestruck.3

Deployment
One of the first acts in the beginning of the book is to deploy the little scaffolding app to production - as in publishing it live on the web. Along the way, you’ll learn a couple of Heroku commands (which is where the apps are deployed in the book).

It’s quite a revelation if you’ve never done anything on the web: a couple hours into the book and there is a URL that hosts an app you’ve build. This is also part of what makes this book so cohesive: from first setup to a live app on the interwebs, it’s all there.

Hatching Twitter
The main project of the book is building a Twitter clone: users, posts, images, following and being followed. This makes up roughly 80% of the book and is what serves as the example for every new concept or tool:

  • creating the basic layout and main pages
  • user modelling: Michael takes a deep dive with building your own user management, incl. password hashing, security, authentication and authorization
  • session-token and cookie-based login
  • account activation and password reset, including sending emails for both
  • building posts (with image attachments), following and followers

All of the above - of course - being deployed to Heroku in the end. You can now look for investors.

Along the way
While building your own personal Twitter clone, Michael introduces a whole range of methods and paradigms.

  • seeding the database with test data
  • implementing gems (‘add-ons’ for Rails, like resizing images)
  • test-driven development (TDD) is at the core of the book, with (almost) every piece of code being unit tested, included in integration tests and using fixtures (test-data)

For me, I gained a whole new appreciation for TDD. There is something extremely satisfying about running a large number of tests with hundreds of assertions and ending up with a bright green bar and 100% passing. It also adds confidence that your code is actually working. I probably have some tests to add in Xcode.

From Zero to Rails in three weeks

It took me a couple of weeks with a total of ~40 hours (courtesy of Timist) to get through the book, knowing nothing of Rails before starting and skipping some of the optional exercises. I did however have some prior experience, such as this blog (which runs on Jekyll, a Ruby-based static site generator, and deploying said blog to AWS S3/Cloudfront), Git (for the blog and all Swift codebases) and basic command line interaction (running a few Linux servers).

Through the course of the book, Michael proves to be a great tutor, with a learning curve that I found to be just right. New tools and paradigms are introduced gently, and whenever you are exposed to new concepts, there is enough room to take it in. Numerous times I skipped to the next piece of code and got stumped with something I had not seen before, only to discover that it was explained in detail in the next paragraph. You are never left alone, and if there’s code that would require a “jump ahead”, Michael tells you what you need to now - and what not. Considering all of the educational books I’ve had to go through, this one might be one of the best.

My goal at the beginning was get to the point from which I could venture forth on my own: building a decent general understanding of the fundamentals, knowing how to start and how to keep going - that is, knowing how to ask Google the right questions. Michael Hartl’s “Ruby on Rails Tutorial” delivers that and a whole lot more. Considering the book is just US$40, that really is an amazing value and I’d highly recommend it to anyone.

Really, anyone. Imagine the world we could live in if everyone was capable of creating software for the web. If learning programming for the web is something you’re interested in, there is a free sample chapter you can check out. Give it a try.

And now, onwards to the next chapter:

$ rails new user-feedback-app

  1. “Whatever web app you want” might be a bit of an hyperbole, but as a close approximation I think it holds true: starting as a one-person-show, with Google and a large community by your side, the “whatever” part is most likely just a time constraint. ↩

  2. Hartl recommends to use AWS’ cloud IDE, aptly named Cloud9. I was insistent on running Rails locally on my Mac and fought with Ruby and its versions for two days. Still stubborn and resisting Cloud9, I begrudgingly set up Docker to run Rails in a container. That worked great, until a few hours later it didn’t. As a last resort before migrating to Cloud9, I tried running Rails locally on my Mac again. Which then worked. Oh well. Just follow Hartl’s recommendation and use Cloud9. ↩

  3. Rails scaffolding: freaking amazing. The amount of boilerplate code required to get a basic list view on iOS (even though SwiftUI will make a lot of that easier) is ridiculous. On rails, setting up a basic data model, a few relationships and the required views takes 20 minutes. I know, it’s far from a production ready app - but considering the amount of internal (Excel replacement) tooling I’ve seen professionally at various companies, this is often all you need. Slap basic HTTP Auth in front of it, host it in an internal network. Done. Freaking amazing. ↩