I released my second book, Master Ruby Web APIs, a few weeks ago. In this post, I want to come back to the creation process and share a few tips with you. I believe anyone can write a book and self-publish it the way I did, and I hope you will get some motivation from this post. While it’s far from easy, it comes with a lot of benefits that can make a huge difference in your life.
Why Write A Book?
Starting and finishing a big project is a rewarding experience. However, it seems to be complicated these days for people to do that, myself included. With new stuff flooding our devices every day, keeping our focus on the one thing that matters is becoming excruciatingly hard. But with the use of simple techniques and habits, it’s possible to do anything - the first time you do it, you’ll will prove it to yourself.
I wrote this book because I had something to share: how to create Ruby web APIs based on the industry standards and best practices. I know it’s going to sound cliché, but this is the book I wish I had before I built my first web API.
I’m not going to lie, though - I also wrote this book to earn money. I’m trying to start a business, and what I’m earning from the book will allow me to bootstrap it and get things going.
To summarize, I wrote this book for three reasons: to prove to myself that I could do it, to provide something useful to the Web community and to make a little income.
Self-Publishing
I’m self-publishing Master Ruby Web APIs, just like I did for my first book, Modular Rails. I chose self-publishing for a number of reasons.
First, let’s not forget that I would probably never get a contract with an editor. Even if I could, I would still prefer self-publishing.
Pros
- Self-publishing gives you more control. Actually, it gives you complete control. More ownership, more work, more rewards!
- It’s an awesome learning experience. I had to learn more about marketing and copywriting in order to be able to make some sales.
- Royalties from publishers are usually quite low. With self-publishing, you get more than 90% of the sale price.
Cons
Self-publishing also comes with a few cons.
- You have to do everything, including writing, coding, editing, marketing, or hiring people to help you with all the above. It can be very stressful to have no one else to rely on.
- You need to handle the review part of your book. You can always do it yourself, but a better option is to hire professional reviewers (or force your friends to read it).
- Without a publisher, you will have a much smaller reach. That means fewer sales (even though you’re getting more out of each individual sale).
- You need to handle the marketing which requires a lot of work. It includes building the landing page, sending emails, creating promotion materials, etc.
Now, let’s talk about the book itself, and the interesting part - how I wrote it.
The Landing Page
The first thing I did was set up a landing page about the book. This happened a year before the release, right after I published Modular Rails. After that, I didn’t do anything.
It wasn’t a strategy or anything like this, I was just busy with work and I didn’t find the time to get started. Fast-forward to a year later, when I decided to quit my job.
Over the past year, and without doing any promotion, I collected around 50 emails from people who were interested in Master Ruby Web APIs. It wasn’t that many, but to be honest, I didn’t really do anything to make it grow. Shame on me.
However, I did have the general mailing list from Samurails (my previous blog), and my first book, which altogether amounted to around 1000 people.
The original landing page was pretty simple. Since I’m using Unbounce to create my landing pages, I was able to find the pre-release version.
The first versionQuick plug for Unbounce - I could have totally created my landing page from scratch. However, I prefer to use and pay for a service like Unbounce because it makes it much easier to build different variants super fast. The a/b testing feature is also a must.
With the pre-release landing page ready, I needed a place to store the email addresses safely.
Collecting Emails
I’ve been using Mailchimp for a while now - ever since I first started collecting addresses on my blog, Samurails (before it became Devblast). It helped me launch my first book and send tutorials and articles to people who wanted to read them.
For my second book, I decided to keep using the tool that I knew. I was already paying for Mailchimp to use the automation feature, so it seemed like the best choice.
But another mailing marketing tool caught my eye. I’ve been following Nathan Barry for a long time, and I wanted to try the application he created, ConvertKit. The main difference between ConvertKit and Mailchimp is the way subscribers are handled. In ConvertKit, subscribers belong to forms, and broadcasts can be sent to a specific set of forms. There are also sequences, and an awesome automation system where pretty much anything can be automated.
After giving it a try, I completely switched to ConvertKit and I’m super happy with it.
Getting Started
Now we’re getting to the juicy part.
How the hell do you write 120,000 words and organize them in a compelling manner?
A journey of a thousand miles begins with a single step.
Well, just like any journey, you start with the first word. Then, you write the second, and so on. When I’m working on a book, I don’t spend too much time thinking about what I’m writing - I just let everything out. There is always time to organize, edit and improve on your raw material later. The first goal should be to have some meat to work with.
I find it’s better to work by iteration than to try to get it perfect on the first draft. If you’re more concerned about perfection rather than getting your thoughts down on paper, you’re setting yourself up for the dreaded blank page syndrome.
Sadly, I wasn’t getting my quota of words out every day. I needed to change something.
After procrastinating for a while, I finally decided to set some rules. I was going to write for at least 10 pomodoros per day. Until I set this rule, I had no idea how long I actually worked every day. Maybe 1 hour, maybe 5. Who knows? (It was probably closer to 0 or 1 hour though).
Sticking to this rule, I was able to produce a good amount of content for the book. The problem was that the book kept growing, and I wasn’t seeing the end.
I thought the book would be around the same size as my first one - ~ 200 pages. In the end, it grew to around 750 pages. This brings me to…
The Book Organization
I wanted to put a lot of things in this book - everything I had learned about web standards, RFCs, best practices and so on. To best organize these in the best way, I decided to divide the book into three modules:
- Talking about the basics and building simple APIs with Sinatra.
- Building a complete Rails 5 API and do everything from scratch, from scratch.
- What REST really is, and why the API we built in the second module doesn’t respect all REST constraints.
Each module had a goal. The first one was meant to introduce the reader to the concepts of the World Wide Web, HTTP APIs and Sinatra. With these concepts, it was possible to start building something more complex, like an e-commerce API with all the necessary components, such as a way to handle authentication, authorization, security, payments, and more.
Writing the first module was actually fun. I went to Penang, Malaysia, for a week and kept writing there, from coffee shops. It reached 25k words before I decided it was complete. The chapters covered a wide range of topics like versioning and caching. At this point, the book was as big as my first one. Maybe I should have stopped there. But I wasn’t happy - it wasn’t enough to “Master” Ruby web APIs.
The second module was meant to go deeper into explaining how things can be done for real world applications. I also wanted to share some knowledge about Ruby and how the language could be used to build everything needed, from scratch (yes, from scratch!). To do this, I decided to create specialized classes to handle the generation of the JSON representations instead of using something like Active Model Serializers or JBuilder. My goal behind this approach was to show how things are made in those gems. I believe that if people have an idea of the underlying functions of these libraries, they can make better use of them.
Not everyone liked this approach, and one person even complained about it, saying it wasn’t necessary and too complicated. That’s fair. It’s an approach that I thought was valuable, and that I wanted to have. Because this might not be everyone’s style, having a free sample of the first few chapters was really important, allowing customers to see how I write before they purchased the rest of the book. If someone is really unhappy with their purchase, I offer complete refunds, of course.
While I used Sinatra in the first module, I decided to go with Rails 5 and its new API mode for the second module. Some people also questioned this choice: Isn’t Rails slow? Why would you use Rails for a web API instead of Sinatra or Grape?
The thing is that most of the logic for a web API, just like a regular application, is not in the view layer. Having Rails conventions and features is great to keep complex applications organized. I wanted that to ease people into the module, but I also went the Rails way when I had to.
All things considered, I ended up being really happy with the second module. I used a TDD-like approach in it to show that automated tests matter, and will generally make your life simpler.
Finally, let’s talk about the last module. To be honest, it didn’t turn out as good as I had hoped. But I was running out of time, money and energy after completing the first two modules, which totalled a whopping 100,000 words. In this last module, the goal was to dig deep into REST and what it is. Then I explained why Alexandria (the app built in the second module) was missing a few of the REST constraints. After that, I showed how the application could be improved by adding the Hypermedia constraint.
This module can clearly be improved, and it will be. I’m planning to add chapters to that last module to improve it. Anyone who buys the book will, of course, get these for free. While the third module is lacking, I believe it’s still a very important read for any web developer. Understanding that REST doesn’t simply equal using HTTP verbs and resources is fundamental.
Master Ruby Web APIs will evolve with time.
The Tools
My writing setup is a bit peculiar. I came up with it right before publishing my first book because I wasn’t happy with anything else.
I use Markdown to write all my books. I actually use Markdown for everything these days, including this article. I just love it. To structure and generate the book, I used the Softcover gem.
I use the same text editor for both coding and writing: Atom.
Getting reviewers
If you’re self-publishing, you need to collect some early feedback before releasing. I asked some of my friends to read the book when they had time - only one of them actually finished it. I also decided to hire a native English speaker from Upwork to review the content. She provided some great feedback and helped me improve the book.
Recording Screencasts
Just like my first book, I’m using a tiered pricing structure with three packages. The biggest one includes a bunch of bonuses like screencasts and additional resources. The medium package is just like the complete package minus all the video content. Finally, people can decide to buy just the book for $39.
I recorded the screencasts with Quicktime on my Macbook and edited them in iMovie. I’ve since learned how to use Adobe Premiere and will be using it in the future.
Releasing with Gumroad (During A Power Outage)
After around 2 to 3 months of work, Master Ruby Web APIs was finally ready - not perfect, but ready for a first launch.
If you are not embarrassed by the first version of your product, you’ve launched too late. — Reid Hoffman, founder of LinkedIn
I was definitely embarrassed and was wondering if anyone would pay for it. After all, who am I to teach people?
I launched anyway, fighting off all the doubts and thinking about the next day where I would finally be able to relax a bit. I uploaded everything on Gumroad, shared the link on a few outlets (ProductHunt, Reddit, HN) and sent an email to my complete mailing list to announce the release.
No sales came in the first 30 minutes.
After that, a complete package. Then, a book. Then, another complete package. I was too excited to sleep. I was finally beginning to see the result of the past 3 months of work. I was checking my phone every 5 minutes, and sales kept coming in.
No matter how exhilarating the first 24 hours were, I think it’s important to manage your expectations My “great” might be much lower than what you have in mind. After all, I’m living in Thailand where life is cheap. After one week, and the end of the release promotion, I earned enough to justify the time I spent on the book.
The thing with books is that most of the income will come at the release - the amount needs to be big enough to live until the next project is ready.
Funny story, the day I was launching, there was a power outage in my area - and not a small one. Electricity was out most of the day. I was able to use a friend’s place to spend the night and release the book. Talk about stress!
The Result
I originally wanted to share the amount I earned from the book, to motivate people who want to get some extra income or change their lifestyle. But after reading here and there, I decided that it was maybe not the best approach. If you really want to know how the book did, feel free to contact me.
I got so much more than just money from releasing this book. I acquired new skills, met awesome people and added a new product to my portfolio. :)
The Future
I’m publishing this article two months after the release. Things have calmed down, and I had time to think about what I’m going to do next. It won’t be a book. I’m still planning to write some, but not right now.
I want to build stuff first.
