jstorimer

If you're willing to spend $300, I've done all my covers through 99designs.com and been very happy.

Hi. OP here.

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.

Correct. Later on I say:

  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.

It's linked near the bottom of that page. https://kdp.amazon.com/self-publishing/help?topicId=A301WJ6X...

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.

There are a million ways to do it :)

I've seen success from releasing the content for free with a paid version for ereaders, or doing it like I did and just offering the paid version.

Totally agree about the 10-90 split. I like to think it's more like 25-75 but you drove the point home ;)