Elixir Wordl from Ganesan Janarthanam

Oft repeated, rarely heeded…

Deploying Elixir

When any serious app is 100% done, there’s another 50% left to do, and that 50% is deployment. For complicated or large apps, there’s no easy way to do this.

A reader asked me about Elixir and deployment:

There is definitely a lot of excitement around Elixir and I like it. What I am concerned with is are their any production deployment issues with Elixir? I have not don’t one myself but Elixir depends a lot on Erlang and Erlang libraries which have some kind of unique release process or so I have been told. I am not sure if I understood it correctly but I believe Erlang is released in such a away that it is self reliant and doesn’t depend on any external dependencies. How would Elixir behave if the system Erlang version moves ahead?

And I responded:

Elixir is just Erlang, as far as Erlang is concerned. This means that Elixir code can be deployed alongside Erlang code—the two coexist.

However, you have to be careful when looking at Erlang deployments.  Up until now, these have tended to be large-scale, distributed, and highly redundant systems. The goal has been seriously high reliability. Now no system like this can be deployed just by pushing a button—there’s a lot of planning, and a lot of configuration and scripting.

As a result, a “classical” Erlang deploy can be a big beast. Your Elixir code can join in this fun if it wants to.

But Elixir also offers simpler options. For example, deploying an Erlixir web app to Heroku is just about as easy as deploying any app to Heroku—just push to a repository.

So the short answer is that deployment in any language is not just one topic—it varies greatly depending on the application’s characteristics. At the large scale end, Erlang (and by extension Elixir) has a great story—it is mature and proven. At the small scale, deployments such as Heroku make it easy. And in the middle—well, that’s where the interesting stuff will happen.

Pragmatic Royalties—2013 Edition

Back in 2009, I posted a summary of the breakdown of the royalties we paid on our titles. Susannah, our managing editor, has been suggesting for a while that I should update it. I was surprised by what I found.

Here are the 2009 numbers:

Compare with 2013:

Below $10k, the numbers are about the same. That’s not surprising—mostly they reflect the vanity titles that were around in 2009. But above the $10k mark, things are a little different.

In 2009, 70% of titles made more than $25k. By 2013, that number has grown to 74%.

In 2009, 41% of titles made over $50k. By 2013, it’s 46%.

And while roughly the same percentage of titles made between $75k and $100k (12% in  2009, 13% now), there’s a big increase in the $100–$200k wedge, up from 4% to 12%. The only drop at the top is the >$400k wedge, and that simply reflects that we haven’t had a title as big as the Rails and Ruby books recently, while the overall number of titles has grown.

These numbers were pleasantly surprising. I know that as a business we are insulated from the plummeting fortunes of more conventional publishers. But I hadn’t realized that were were even more attractive to authors now than back in 2009.

Maybe it’s time for you to consider writing a book…

Smart Constants

I’ve been really enjoying James Edward Gray II’s Rubies in the Rough articles. Every couple of weeks, he publishes something that is guaranteed to get me thinking about some aspect of coding I hadn’t considered before.

His latest article is part I of an exploration of an algorithm for the Hitting Rock Bottom problem posed by  by Gregory Brown & Andrea Singh. At its core, the problem asks you to simulate pouring water into a 2D container, filling it using a simple set of rules.

As I was coding up my solution, I found I had code like

case 
  when cave.cell_below == " "        then cave.move_down
  when cave.cell_to_the_right == " " then cave.move_right
  # ...
  else
    cave.move_up
    cave.move_left until cave.cell == "~"
    # ...

Here ” “ is a cell containing air, and ”~” a watery cell. So clearly we should create some named constants for that:

AIR   = " "
WATER = "~"

case 
  when cave.cell_below == AIR        then cave.move_down
  when cave.cell_to_the_right == AIR then cave.move_right
  # ...
  else
    cave.move_up
    cave.move_left until cave.cell == WATER
    # ...

But it occurred to me that we could use Ruby’s singleton methods to give AIR and WATER a little smarts:

WATER = "~"
AIR   = " "
[WATER, AIR].each do |content|
  def content.in?(cell)
    cell == self
  end
end

# ...
case 
when AIR.in?(cave.cell_below)        then cave.move_down
when AIR.in?(cave.cell_to_the_right) then cave.move_right
# ...
else
  # ...
  cave.move_left until WATER.in?(cave.cell) if AIR.in?(cave.cell)

Now you could argue that the cave object should do this: cave.watery?, or that the individual elements in the cave should be objects that know their moisture content, rather than simply characters. I don’t agree with the first (simply because the cave is the container, and the water/air is the separate stuff that goes into that container). I have a lot of sympathy for the second, and I’d probably end up there given a sufficiently large nudge during a refactoring. 

WATER = "~"
AIR   = " "
[WATER, AIR].each do |content|
  def content.in?(cell)
    cell == self
  end
end

# ...
case 
when AIR.in?(cave.cell_below)        then cave.move_down
when AIR.in?(cave.cell_to_the_right) then cave.move_right
# ...
else
  # ...
  cave.move_left until WATER.in?(cave.cell) if AIR.in?(cave.cell)  

But, for the problem at hand, simply decorating the two constants with a domain method seems to result in code that is a lot more readable. It isn’t a technique I’d used before, so I thought I’d share.

(And remember to check out Rubies in the Rough…)

Followup to my EMail experiment

So the Hacker News folks are having a discussion about my email experiment last April. Many interesting points were raised. One fair question is “how did the experiment work out?” 

In short, it worked incredibly well.

I was mostly worried about annoying the folks sending me email. But the only feedback I got was positive. 

I was also a little worried about folks abusing the [urgent] flag. But that didn’t happen, either. I had perhaps 5 or 6 urgent emails, and they were indeed things I needed to handle when I got back. Maybe I’m just lucky when it comes to the people who correspond with me.

The experiment had two positive effects on my life. First, the vacation was genuinely a lot nicer not having to worry about the sacks full of mail piling up for me when I got back. Was that selfish of me? Perhaps a little. 

I wasn’t expecting the other side effect. Since I returned from vacation, the quality of email I receive has improved, and the quantity I receive has dropped. I still enjoy interacting with all the people I need to interact with, and I still get to answer all the questions that need answering. It just seems that my inbox is somehow more focussed.

I have a theory. I think that, during the course of the preceding few years, I’d become something of a slave to my email. I’d answer stuff as it arrived. And those rapid responses would in turn trigger another round of email, and another. There was almost an adreneline rush to it.

So my vacation broke that cycle. And now things are sane (or at least closer to sane).

So I'm trying an email experiment

For the next 2 weeks, here’s my vacation message:

Subject: I’m on vacation, and I’ve deleted your message—really

I know this sounds brutal, but here’s the deal.

I can’t remember the last time I took a vacation where I didn’t actually end up working a few hours each day handling e-mail. I felt I had to, because if I didn’t, the Inbox would just grow and grow, waiting for me when I got back—the idea that I’d be flying home to 5,000 messages would always be nagging at me, detracting from my holiday. So I worked (which also detracted from the holiday).

 This time, I’m taking a different approach. I’m asking for your help to make my break more enjoyable.

 I’m going to be discarding email I receive. That’s right—your email will be recycled into warm, fluffy bit-jackets for underprivileged children. I won’t see it.

If it’s something you think I really, really need to know, you can bypass this brutality by putting “urgent” in the subject line. But before you do:

• if it is something that can be handled by the wonderful Pragprog support folk, could you send your message to support@pragprog.com


• if it can wait until I get back on April 25, please resend your message then.

It’s an experiment. Bon voyage à moi!

Dave