Tuesday, January 28, 2014

Class factories in Coffeescript

There’s a neat trick for dynamically constructing heterogeneous classes using a single factory function in CoffeeScript.
(This is probably a common pattern among Coffeescript cognoscenti, but I hadn’t bumped into it, so I thought it was worth jotting down.)
I’m in the middle of writing a CoffeeScript application which handles a variety of related but different user interface widgets. I’d normally treat each as an independent class, and use mixins for the common functionality. But in this particular app, it turns out to be incredibly convenient to have a single factory method that takes a DOM element and uses a data-type attribute to generate an object of the correct class. That is, given

<article class="widget" data-type="Wibble">     … </article>
I’d want an object of class Wibble, and given
<article class="widget" data-type="Wobble">

    … </article>
I’d want a Wobble object.
The initialization code to create these objects will look something like

$(".widget").map(function (_,el) {      return Widget.for_element($(el)) })
Here’s what I came up with for the for_element factory method.

class Widget     @for_element: (el) ->         type = el.data("type")         new @[type](el)      constructor: (@el) ->  class Widget.Wibble extends Widget     constructor: (el) ->         # subclass-specific stuff         super  class Widget.Wobble extends Widget     constructor: (el) ->         # subclass-specific stuff         super
The fun part of this is that by namespacing the individual widget subclasses in the parent Widget class, I can use new @type to look up the subclass in the factory, and then instantiate the object.

Monday, January 6, 2014

I'm sick of site spam

Is this a way of fighting back?


The pragprog.com site tries to make it easy for our readers. We don’t want them to have to jump through hoops to register an account, post to forums, or note an erratum.  We don’t want to ban external links—they are useful when people want to reference some resource or gist.


And, of course, that means we attract out share of spammers, adding links to external sites and products. 


I spend a bit of time each week searching this out and deleting it. But I sometimes miss things, particularly when it is a site link in a user’s profile.


But Google notices, and it complains. Not to me, but to the owner of the site the links reference. That’s fair—the site owner paid someone to spam us, and Google complains to them, threatening to put their page rank in the crapper unless they remove the spam link.


But they can’t remove it, because it was added by some kid in link factory somewhere.


So instead they write to us. Here’s a typical email. 


from: Mr Woc <webmaster@worldofchat.co.uk>


Hi,


I work for the company touchlineban.co.uk.


Your web page:


http://forums.pragprog.com/users/73905


is linking to our domain and we have been given an email from Google regarding our linking habits!


Since this letter from Google our site is suffering very badly, I need to get this link removed.


Therefore I politely request that you remove the link to our site touchlineban.co.uk immediately or as soon as is possible.


Many thanks for your cooperation in advance.


If you have any questions please contact me here:


webmaster@touchlineban.co.uk


Also if you have any other domain linking to us please can these links be removed too?


Kind regards


I get these emails quite frequently.


So, this time I responded:


I will remove the link if you give me the name of the company you employed to add it in the first place.


I got a wonderful response:


from: Woccy <webmaster@touchlineban.co.uk>


It was a long long time ago i have no idea sorry, ive got thousands of links and hired 100s of people over the years.


Far easier for you to remove them otherwise i just have to put the url on a disavow file, which is never good for any site, as I have to get rid of the links one way or another


Ive replied from the touchlineban email too so you know its my site.


Many thanks


Jc


Oh, my heart bleeds. The poor fellow. He’s hired 100s of people to spam sites like ours, and has polluted the web with thousands of links to his football management site. He can’t be expected to remember any details.


So, here’s my thinking. What would happen if I create a page on our site where I collect every single spam link I find, and leave those links active forever?


Would this cause some pain to the folks who spammed us in the first place?


And would it hurt our own page rank? Is there a way to let Google know what we’re doing?

Saturday, January 4, 2014

Reactive systems have no top

Back when I used to consult into projects in trouble, there was a trick that always worked, Look for classes or modules named XxxManager. These puppies would always be at the epicenter of the structural spaghetti. Invariably they’d be doing too much, with lots of conditional code and a fair amount of poking into the business of the things they were supposed to be managing.


So we’d pick them apart, split out functionality, and see if there was a way to either eliminate them, or turn them into something less coupled (my favorite approach when appropriate would be to turn each into a state machine).


But, as they say, the cobbler’s children have no shoes. I fell into the trap myself this week.


Over the Christmas break, I’ve been amusing myself by writing a terminal emulator in Coffeescript. Part of the intent is to allow me to record and then play back interactive sessions. The playback will have a bunch of bells and whistles (including fast forward, rewind, step-by-step and so on).


image


To manage all this (yes, there’s that word) I wrote a class called Driver.


Perhaps it was the eggnog, but the usual alarm bells were muted. I happily coded away for half a day, hacking more and more stuff into the driver. We had events, callbacks, a little RxJS, and lots of asking other objects for status.


And it bogged down. Every change got more difficult. Every test harder to write. And it wasn’t fun.


So I took the dog for a walk, and the dog told me I was being stupid. I’d written a manager class. It wasn’t called PlaybackManager—that would have been a giveaway. I’d called it Driver. That kind of pathetically meaningless name should also have been a giveaway, but until the dog pointed it out, I’d kinda spaced it out.


So I got back, gave the dog a treat, rolled back the code to the start of day, and looked for a good name for a class that would drive the playback. I ended up with VcrControls. What did it control? A class called Player. The Player class had methods such as play()rewind(), and step(). The VcrControls object sat between the UI and the player. And the code just fell into place.


In a way, this is a variant of the “tell, don’t ask” rule. 


Reactive systems have no top—they are lots of components that transform data and events. There’s no place for anything called a manager in such a system. And careful naming (cf Driver…) is a quick way of working out when you break the rule.

Monday, December 30, 2013

Tuesday, December 24, 2013

Friday, December 20, 2013

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.


Friday, November 1, 2013

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:


image



Compare with 2013:


image



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

Wednesday, February 1, 2012

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…)

Saturday, November 12, 2011

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).

Thursday, April 14, 2011

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

Monday, October 19, 2009





When we started the Bookshelf, we wanted our authors to share in the success of their books, so we set our royalty rates to between 40% and 50%. That is, an author will receive between 40% and 50% of whatever gross profit we make on a book. We felt back then, and we still feel, that this is the highest overall royalty offered by any technical publisher (most publishers offer something in the 10–18% range).


But it isn’t always easy to compare different publishers, because the definitions of gross profit (or whatever they use) differ wildly. Our definition is that we take whatever money we receive from the sale of a book (in whatever form), deduct the direct cost of production (which is zero for eBooks, and a couple of dollars for paper books), and then split what’s left according to the royalty rate. We also account for our costs of copy edit, indexing, and typesetting by splitting them (again according to the royalty rate) between the author and us. So if a book costs $5,000 to copy edit, index, and typeset, and we’re paying 50% royalties, then the author’s royalty account starts with a $2,500 negative balance.


We don’t pay advances, but we do pay royalties quarterly. If a book enters our beta program, the author starts receiving the royalties at the end of the quarter.


In the last few years, we’re had a number of prospective authors tell us that other publishers woo them by saying that our 40–50% royalties are somehow illusory—that by the time the author gets a payment the figures have somehow been shaved down to the point where we pay the same as everyone else. And that’s just FUD.


So, in order to help people compare, attached is a chart. It shows the royalties we’ve paid so far on our titles that have been in print for at least a year. Eight percent of the titles have earned less than $10k. Several of these are vanity titles we produced on behalf of private companies, the others are books that sold into very specific, narrow niches (because we felt someone should do it, and even at these low volumes we can do so profitably).  Ninety-two percent of our titles paid more than $10k in royalties, and forty-two percent paid more than $50k. Twelve percent earned into six figures.


I’d welcome publishers who talk down our royalty payment schedules to publish their figures. I know many will have some titles that earn a lot more than $400k. But I’d be most interested in the distribution—how much does a typical author make? I’m proud of the fact that we’ve set up an environment where authors of good books can earn back at least a reasonable portion of the investment they made in writing.

Thursday, June 11, 2009



Here’s another piece of music I wrote. This one I started over a year ago, but then put down for a while. I think it really wants to be a lot longer piece—maybe one day.

Monday, May 11, 2009



In my ongoing attempt to keep myself honest, here’s another piece I wrote, again played by Mike Springer. I’m not sure how to categorize this one—I wanted to play around with 7/8, and ended up with what I think are some interesting patterns. 

Sunday, May 3, 2009





I’ve known Chad Fowler for almost ten years. He’s a seriously good guy: musician, developer, leader, and friend. So when he came to me some years ago with an idea for a book, I jumped at it. I was hoping for something good, but what we got was something truly great.


Andy and I wrote The Pragmatic Programmer over 10 years ago. It was a book full of advice on the job of programming, from low-level coding to teams and projects.


Well, Chad had written the companion book. Where our book looked outward at the job you were doing, The Passionate Programmer looked inward at the person doing the work. It’s a book about finding fulfillment in what you do. It’s a book about rekindling the fires that you felt when you first entered the profession. It’s a book about creating a career, rather than turning up for a job.


I was blown away.


And then I did something really stupid. The book came out about 5 years ago, and outsourcing was big on everyone’s mind. So I thought “let’s make a jokey title that’ll grab people’s attention.” I called the book My Job Went to India (And All I Got Was This Lousy book).  I’ve already blogged about how stupid that was—it was probably the single dumbest thing I’ve done since I got into publishing. The title put people off; it gave them the wrong idea. The book was really nothing to do with outsourcing, but you wouldn’t know it from the cover. This book deserved so much better


So, four years later, we revisited the book. Chad’s given it a spring cleaning, revising and updating it. And we gave it a new title and a new cover, both of which do a better job of conveying the energy and enthusiasm that lie within.


I’m not into selling: my philosophy with our books is “if they’re good, people will buy them.” But this book is different. I really think it can make a difference. So I’d love for you to read the extracts and maybe take this book home with you. I honestly think you’ll thank me (and, most importantly, Chad) if you do.

Wednesday, April 8, 2009

Twitter Should Move Away from Ruby

Oh dear. The chattering classes are at it, talking about how the Twitter folks are dissing Ruby by announcing the replacement of some Ruby code with Scala code.


Please stop.

At the kinds of volumes that Twitter handles (and with what I assume is a somewhat scary growth curve), Twitter needs  to improve concurrency—it needs an environment/language with low memory overhead, incredible performance, and super-efficient threading. I don’t know if Scala fits that particular bill, but I know that current Ruby implementations don’t. It isn’t what Ruby’s intended to be. So the move away is just sound thinking. (I suspect it also took some courage.) I applaud Alex and the team for this.


Instead of defending Ruby when it’s clearly not an appropriate solution, let’s think about things the other way around.


The good folks at Twitter started off with Ruby because they wanted to get something running quickly, and they wanted to experiment. And Ruby gave them that. And, what’s more, Ruby saw them through at least two rounds of phenomenal  growth. Could they have done it in another language? Sure. But I suspect Ruby, despite the occasional headache, helped them get where they are now. 


And now they’ve reached the status of world-wide wunderkind, it’s time to move on. 


I for one wish them luck. I look forward to the day when our online store reaches the kind of size where we have to move away from Rails. I’ll tweet the fact with a tear in my eye, while my yacht sails me off to the sunset.

Thursday, December 25, 2008



I decided a while back to publish the music I’m writing, if nothing else as a way of keeping myself honest. So, here’s a little piece of fluff I wrote just to play with time signatures—alternating 5/8 and 6/8 has a nice drive to it. It’s played by my music teacher.