Hi! I'm Elvio Vicosa, the author of Phoenix for Rails Developers, a book written for experienced Rails developers who want to use their existing knowledge to learn Phoenix.
I launched the book a couple weeks ago (on December 13, 2017), and so far it's made $6,159.00 in sales.
Rails is a great tool, but things are changing rapidly. Web applications are demanding concurrent and distributed features, and Rails is clearly not a good fit for that.
Phoenix is a framework written in Elixir, a language that has built-in support for concurrency and distribution. Due to its similarities with Rails, Phoenix is a natural choice for developers who want a complete web framework, without compromising speed and maintainability.
I've been working with Rails for almost a decade, throughout which time I've had the chance to build a variety of projects. Two years ago, when evaluating technologies to replace an existing Rails project, I stumbled upon Phoenix. I got really interested in the framework, since it was so similar to Rails.
The first time I started working on a Phoenix project, I spent a considerable amount of time trying to understand how to do the same things I was used to doing in Rails.
Phoenix for Rails Developers is the book I wish I'd read before working with Phoenix for the first time, and it will help Rails developers quickly get productive with Phoenix.
In total, I spent around six months writing the book — and the first step was developing the web application that the book uses as an example. I spent a couple of weeks building and simplifying it until I believed it was simple enough to serve as an introduction to Phoenix, while still being a complete and full-featured web application.
The most time-consuming part was writing the book itself. Although I've been publishing blog posts for a few years, writing a book was a completely different experience.
My writing schedule was simple: two hours a day from Monday to Friday. Since I have a full-time job, I usually wrote the book in the mornings (6am to 8am), which proved to be quite nice due to the silence and lack of distractions.
I wrote the entire book in Markdown. I used Jekyll to generate a single HTML file with all the book's pages, and then used that HTML file to create PDF and MOBI versions for publication. I used headless Chrome to create the PDF format and kindlegen to create the MOBI version. I then created an EPUB version from the MOBI file using calibre.
Before publishing the book, I put up a landing page explaining the book's idea along with the readers who would benefit from it. In the period of three months, that landing page generated around 500 email list subscribers for the book.
When I published Phoenix for Rails Developers, I emailed an announcement to subscribers and offered an exclusive 25% discount code. This approach was quite effective — the first sale came in within 10 minutes.
After the launch, my focus has been mostly on partnerships. I am quite happy that Plataformatec, the company that created Elixir, has helped me to promote the book.
Here are a few more ideas I am considering to promote the book:
Out of all the things I've done to promote the book so far, I am quite sure the most important one has been the email list. If I could go back in time, I'd for sure invest more time in building it.
Writing a book was a great experience and I really enjoyed it. In 2018, my plan is to learn more about marketing, copywriting, and to promote the book.
Phoenix is a relatively new technology, which will make Phoenix for Rails Developers a relevant book for quite some time.
Besides book promotion, I am already planning the development of my next side project: a SaaS application I'll be developing with Phoenix.
I think the biggest challenge has been to keep myself motivated throughout the process. Writing a book is hard — way harder than I thought. It's a lonely process that sometimes made me consider giving up.
One thing that helped me to overcome this loneliness was to publicly share the process of writing the book. Every day I could see new subscribers joining the list, and that interest kept me motivated.
As the launch date approached, so did my feelings of impostor syndrome. Questions like, "Will anyone pay for the book?" and, "What if people start complaining about it on the Internet?" were quite often a part of my thoughts. Those feelings didn't begin to dissipate until I started getting great feedback from actual readers who'd bought the book.
I would do a few things differently:
One of the most important resources for me was the book "Authority" by Nathan Barry (who's been interviewed by Indie Hackers about ConvertKit). I used Nathan's process to write, promote, and sell Phoenix for Rails Developers.
Being able to use a tested process was quite a relief, since I didn't have to spend time testing different approaches. This saved me from making lots of mistakes.
As a software developer, it's easy to get distracted by all the tools and technologies available to write a book. Avoid that all cost and just focus on writing the content.
You can find more information on my website or Twitter page.
If you want to know more about the book or the process I used to write it, leave a question in the comments section!
Hi Elvio! I saw that you're based in Berlin. How do you manage the legal stuff of selling eBooks while being based in Germany?
Do you need to be registered as a freelancer or did you register a small company that produces products? I imagine you're not writing invoices for every single book sale?
Writing books is work and a lot like coding. I love both :-) Your takeaway of focussing on the content and not the tools is gold. I write and publish with https://moopato.com/ , a tool I wrote way before I published my four books with it. Check it out before wasting time with running your own tool with jekyll, pandanc and co.
Some additional information I missed to add to the interview:
Oh I have other questions.
I am glad to answer :)
My initial goal was to have 12k words. The first draft was twice as much as that, so I ended up cutting some chapters that I previously intended to add.
The book is a collection of lessons I learned while migrating Rails projects to Phoenix, so they are entirely based on the overlapping parts of those projects.
The audience I had in mind while writing the book was: Developers using Rails professionally for some years. It assumes the reader know about Rails-specific parts, without spending time introducing/explaining it, cutting straight to the comparison/alternative in Phoenix.
Let me know if you have any other question
I wish people would stop focusing on teaching phoenix and start focusing on teaching Elixir. Learning Phoenix before Elixir is like Learning Rails before Ruby. Sure you can do it, but you'll be a much better developer if you actually learn the language.
Hi travism,
I am glad you brought up this topic, and I will explain why that's not correct.
Learning Rails before Ruby has its problems, because Rails is a customised project, using its own patterns and conventions that are not found in other Ruby projects. It extends the Ruby language, by adding a number of methods and helpers to standard classes.
When you say:
... you have the assumption that Phoenix is also a customised project, that has a different pattern found in "Elixir pure" applications. That assumption is not correct.
Phoenix, goes in the opposite direction. It is a plain Elixir (OTP) application, using Elixir's standard library to configure, build and run the application.
The result is: learning Phoenix (before Elixir) is not the same as learning Rails (before Ruby). Since Phoenix is just an Elixir application, developers can easily understand the patterns and standards present in Elixir itself.
I disagree whole heartily. If you have no understanding or concept of functional programming, haven't looked into OTP, GenServer, GenStage, and have never heard of Erlang, you're going to really struggle to put Phoenix to work.
You're going to have zero understanding of how things work or why. Pheonix isn't an "Elixir Application". It's an Erlang Application which gets compiled at runtime into BEAM assembly and the binary is loaded by the Erlang VM and run by the Erlang Code Server.
As a shop who focuses a lot of our energy on Elixir projects, the biggest take away we had in 2017 is to Erlang our Elixir.
What I mean by that is Elixir is NOT a language. It's a series of macros on top of Erlang that provides syntactic sugar. Once we had that very real "AHA!" moment, things drastically changed for us.
Learning to write Erlang in Elixir is the most beneficial first step someone can take to becoming an Elixir developer. If you then master Plug you essentially have Phoenix.
I've seen a ton of code come from Ruby devs who are "Rubying their Elixir" and it's really bad. It's full of if statements when they should be pattern matching, and their functions are handling too much logic. I'm a former Ruby dev myself and made this transition a couple years ago and this is all from my own experiences and mistakes.
Teach them proper functional programming first and then learn the power of OTP. After that most will probably decide that pheonix isn't even necesarry. We ended up ditching it in favor of just writing raw Elixir/Erlang back end applications. Especially since we use ReactJS for the front end in completely separate concerns.
Just my .02, learn however you want, but I think it's a big mistake to learn a framework before the language that powers it, no matter what. I would like to see a book on transitioning from Ruby to Elixir that talks more about letting go of OO programming concepts and focuses on the power of Elixir. I mean pattern matching is one of the coolest things about Elixir.
Some of us are focusing on Elixir first!
In 30 videos, I've made so far, zero use Phoenix yet and the first 5 didn't even use Mix. That said, Phoenix is a major reason people are looking at Elixir, so I can understand why so many resources start there. Let a thousand different curricula bloom, is my opinion.
don't disagree.. I did Rails for Zombies as my first tutorial as well, but even then I ended up going back to learn Ruby so I could truly take control of Rails. The same applies here imo.
I'm working on a similar product (different technologies). Do you think it's important to have a dedicated domain? I was planning to carve out a page on an existing blog.
I think a dedicated domain is not necessary. As a matter of fact, I believe it would be better for SEO to connect the book content to a personal website.
I only considered that after launching the book :)
Hey Elvio, thank you for this gold-filled interview. I'm very happy that the book is doing well. I have two questions for you.
How did you promote your landing page / email list initially?
What else would you have done to grow it further?
Hi derick.
I initially shared about the book in reddit and ElixirStatus (a website for Elixir news). Later on it started being shared and retweeted by different people, which helped a lot on the promotion of the book.
I would probably create a post series, covering each topic of the book. I believe that would attract more people.
Thank you! I wish you the best with the book and promoting it :)
Great job! After getting my SaaS to a stable stage, I am hoping to work on a ebook in the new year that also similarly talks about joining two popular technologies.
Thanks viperfx and good luck with your ebook.
Hey Elvio, nice interview. I especially find it interesting because I wrote an ebook called Angular for Rails Developers. Cool to see that you've also had success with the "X for Rails Developers" pattern.
Thanks!
Cross promo bundle opportunity!!
This comment was deleted 7 years ago
This comment was deleted 7 years ago
This comment was deleted 7 years ago