Thanks for the comments about atomicity vs. thread-safety. Absolutely on point. The article started out demonstrating what happened with concurrent Array mutation, but then I put in that += operation and didn't address it. Sorry for not making the distinction. Atomicity is absolutely a different issue than a thread-safe collection. I'm publishing something new tomorrow that addresses this point.
To bring things back to code, the point I was originally trying to make is that this code is not thread-safe.
array = []
threads = []
10.times do
threads << Thread.new do
100.times { array.push(rand) }
end
end
threads.each(&:join)
# 10 threads each inserted 100 values, result should be 1000
puts array.size
Specifically, too many Ruby programmers won't think twice about this operation not being thread-safe:
array.push(item)
But there's no such guarantee. This is demonstrated nicely when this code example is run on an implementation with no global lock, try it on JRuby.
There are some very specific caveats that MRI makes for concurrent IO. If you have one thread that's waiting on IO (ie. waiting for a response from the DB or a web request), MRI will allow another thread to run in parallel.
AFAIK there is no spec. MRI is the reference implementation, but many things are experimental or intentionally unspecified.
Given that MRI ships with a GIL, the only core classes that are intentionally aware of multi-threading concerns are Mutex, ConditionVariable, and Queue.
Before Pat announced he was writing an ebook, I was following the articles he wrote on his blog. He has a real knack for making difficult concepts easy to understand using diagrams and simple language. And on top of that, he asks interesting questions. You might think that Ruby internals are a dull topic, but everything I've seen him cover has fascinated me.
Because I've already learned so much from this articles, I was eager to buy this when I saw the announcement in my inbox.
I would. There really wasn't much 'bother' to speak of once I understood how it worked. And even though it wasn't as fruitful as other efforts, many small returns add up quickly.
I didn't have a formula in mind with the fake sales page, but my conversion rate was 3-4%. Not bad.
In my mind it wasn't scientific. If I could put a sales page for a product that doesn't exist and even one person attempts to give me money, imagine what I could do if I had a real product and could even show a sample, testimonials, etc.
The fake sales page, for me, was just to test that I wasn't off my rocker with the idea and to get a little motivation to push forward.
I have spent a bit of money on advertising (<$200) and saw almost no returns from it.
It's always easier to target an audience that you are familiar with and are a part of. Since I would have bought this book myself if someone else had wrote it I knew what people would want to know and how to reach them.
If I were targeting the book at sysadmins, for instance, I would have had no idea how to get in front of them or talk to them at their level.
re: pricing, nope. I think the discounting works because it's intermittent and gets people sharing. If I were to lower the price permanently I wouldn't expect sales to remain that high.
346 hours is both an underestimation and an overestimation. I can say that I definitely did not sit down at the keyboard for 346 hours to put this together. But how do you account for time spent thinking about the content, planning, visualizing, etc? What about the fact that most of that time was 'overtime'? ie. over and above my full-time job.
The other perspective here is that this took a lifetime of work. I've been learning about the source material for the past several years. Obviously it wasn't just to write this book, it has many practical applications besides. I've 'practiced' teaching people and writing for years before this, all of that certainly contributed. This quote sums it up nicely: http://www.marketingquoteoftheday.com/pablo-picasso-on-prici....
I don't think it's fair to try to trim down a project like this to an hourly rate because it simply doesn't work like that. I could stop putting time and effort into the project right now and I would still see some money come in, arbitrarily increasing that hourly rate.
Just to drive home this point having a book with my name on it opens up new opportunities. If I were to write another book and spend the exact same amount of time putting it together my 'hourly rate' would probably increase because I now have more people listening to what I have to say and trusting that I will provide something of value. So investing time now into this project is a long-term investment that I may not make back on the sales of this book, if you know what I mean.
I've no idea if it's feasible to write like this for a living. There are lots of people (even in the tech education space) who make a living selling their own products, but typically not just books. Look at people like Marc-Andre Cournoyer or Peter Cooper who have written books but make their living through some combination of teaching mediums (video, webinar, books, training, etc). For many of them their first product was an ebook.
Just to clean things up, this book was written out of love. I felt like I couldn't not write this book once the inspiration came. That being said, there was also a financial motive. I wanted to be compensated for my work, but also wanted other people to place value on the material. Too often free material is considered worthless because there was no exchange made for it. "If you don't give anything you don't get anything", so to speak.
Yeah, pricing on the Kindle store is a bit of a nightmare. From what I've read the only folks making money on there are selling books for $0.99 and selling tens of thousands of copies (or more).
The royalty from the edition on the Kindle store is like 1/4 of the royalty from selling it on the website. I published it to the Kindle store more as an experiment than anything else to see if I could reach a wider audience there. I still make more sales on the book website than with Amazon.
I had < 250 twitter followers when I started, < 50 blog subscribers. I had some reputation as a Ruby developer from open source work and participating in different things but I would say I had a very small network to start from.
I kept the 'fake' sales page as simple as possible. It was static HTML (written with slim-lang) and pushed to heroku (free hosting). I spent $100 on Adwords to get traffic. That bought ~300 visits which led to ~15 people clicking my 'Buy' button. The page wasn't all that different from what I have now, list the benefits of the product, what buyers can expect, etc.
I didn't pay for Twitter ads. In the beginning people retweeted my announcement. Later on readers of the book would share the link to their followers.
I'll publish another post detailing my toolchain, but here's the overview.
I wrote the book using Markdown and styled the PDF with CSS using PrinceXML. The kitabu framework (http://github.com/jstorimer/kitabu) held it all together and automated the translation to different formats.
In the beginning I had to dive into the different formats to get them all working as I wanted but now I've got that automated.
There are many ways to do pricing and I won't pretend that my method was scientific. Lowering the price of the book may (or may not) have increased revenue. I priced the book this way because I felt it was fair value for the content.
The first promotion was advertised on Twitter and RubyFlow. The second was advertised on Twitter and RubyWeekly. Twitter has always been the best way to spread news about the book.