First, you can, you know, buy the book. Please.

An update to the Ember book should be going out next Monday or so. It has about 10-15 page chapter walking through a routing example with outlets and nested routes and the like. That’s puts the Ember PDF at just over 90 pages (including the back matter and contents and stuff), which compares favorably with the lengths of the other three books (97, 97, and 120, I think).

I think there are still a few things missing from the Ember book.

• More on views and handlebar helpers
• Ember data details
• Ember-testing details
• Anything else the Ember team adds before 1.0 (async routing, for example)
• I’d like to deal with some real-world examples, at least briefly, of things like authentication

This points to a final page count roughly in the range of the backbone book, about 120 pages or so. Actually, probably more. Sheesh.

What’s tricky about this is that ember-data and ember-testing are still not quite done enough to write about them without risking throwing everything out and starting over, so it’s hard to give a final schedule.

The other books are quiet at the moment, though the Backbone book could stand an edit.

Thinking Ahead

Meantime, there’s a slow but steady trickle of requests for a MSTWJS Book 5: Angular. (A five part trilogy would make me feel like Douglas Adams)…

I’m genuinely not sure if I’m going to do this. The considerations are:

Opportunity. There’s clearly some space here for a book that really explains Angular. According to a Twitter poll — which I’m sure is totally reliable — the overwhelming majority of existing MSTWJS customers would expect to pay for a Book 5. This actually goes a long way toward making me think this is worth my time. Writing tech books is kind of a hobby for me, but I’d still like to feel that I can make a little bit of money from them.

On the other hand, I’ve been working on this book for two years now. That’s a long time in Internet years, and doing an Angular version probably means another three to six months of work. There are other things I want to write, and it wouldn’t kill me to blog regularly again. (Actually, that implies that I once blogged regularly, which is not really true.) I really want to do this project book, and I’m starting to feel like I have new things to say about testing.

Anyway, right now I’m thinking that I’ll at least play with Angular a bit to see if I have any affinity for the tool at all. If I hate working with it, I’m not writing about it. If it passes that hurdle, then we’ll see.

If I do it, the likely scenario would be — don’t hold me to this, I’m just thinking out loud: * Priced at $7 or $9 based on length * Existing 4 book bundle owners would get a discount, possibly a limited time discount depending on what I can do via DPD. * At that point, new customers would get a five book bundle. I might raise all prices at that point — the hypothetical five book bundle would be nearly 600 pages. Not sure what that pricing looks like yet. $9 per book with a $25 bundle is one possibility.

Please let me know if you have thoughts about this — my perception of people’s willingness to buy an Angular book in this series is a major factor in whether I do it.

And, oh yeah, buy the book.

Thanks.

All of the MSTWJS customers out there have been either very patient in waiting for the next update, or you are completely disengaged. Personally, I’m choosing to assume patient.

I am continuing to work on the book, it’s just slowed down quite a bit. The next update will most likely be sometime after RailsConf — ideally sometime in the week or so following. So by, say, May 10th. I post this date publicly to increase the chance that I’ll actually hit it.

There are a few reasons why the book’s progress has slowed.

To some extent, it’s a deliberate slowdown so I don’t have to rewrite the thing a dozen times. Yes, Ember is in an API freeze, but they are still adding new things that preserve compatibility, and Ember-data is decidedly not in an API freeze. Just in the last week or so, integration testing tools are starting to emerge — see this discussion for details. Honestly, the fact that I had to throw my hands up over integration testing in the last update was very disappointing, and I’d very much like to get that working in the example.

There’s also been some fumbling about what I want to cover in the rest of the book and how I want to get there. This one, I think I’m getting a handle on.

I also got busy. For example, I’ve been starting this weekly sort-of-screecast series for Table XI called XI to eye. I’ve never done anything like it, but I’m pleased with how this is going. There are five so far, you can see them all at http://www.tablexi.com/blog/category/xi-to-eye. Please do check them out.

I’m also doing two sessions at RailsConf — a normal session comparing rich client MVC with the 37Signals Basecamp approach and an intro track session on testing complex systems. More on those next week, but I’m excited for both of them.

There’s also been some laziness, and some lack of momentum caused by the combination of the previous points.

Still, hoping that this will move a little more rapidly in May — we’re now coming on the two-year anniversary of me starting the project (though I suppose I’d be done if I hadn’t decided to pick up Ember as a topic), and I’m certainly ready to move on. (I have some idea what my upcoming writing projects will be, just not sure which one I want to tackle next.

Thanks for your patience, if you are enjoying the book more will be coming — there will also be another errata catch up on the first three books. Please do help spread the word, or maybe buy it yourself.

It’s not done, of course. But it’s off to a good start, and I think it’s going to be great. Here’s the state of the world:

• Release 1 of the Ember book is $7, just like its recent siblings. The four book bundle is still $15.

• Release 1 is about 20 pages of content (plus the same intro, acknowledgments, and so on). It covers setting up the Time Travel app with an Ember front end, then the basic concepts involved in getting data from the server, displaying it to the browser and responding to actions. We basically end at a chapter break, so it’s a contained example, though obviously the rest of the book will take it farther.

• The code is written against Ember 1.0pre4, which means its current as of yesterday.

• Unlike some of the other betas, this one has been reviewed by a few people, including people who know more about Ember than I do, so I’m pretty happy with how it’s going so far.

• We don’t cover testing yet (in part because the framework does so much that there isn’t much logic to test yet). It’s coming, though. Trust me.

• The plan is for basically weekly releases until done.

• I don’t know how long this is going to get — to some extent it’s going to depend on the reception, more sales = more encouragement to write. It will be at least in the 100is page range as the previous books. If it gets much longer than that, I may raise the price at that time.

That’s the scoop. Buy it: http://www.noelrappin.com/mstwjs, enjoy it, spread the word.

Thanks

MSTWJS 3: Backbone

Master Space and Time With JavaScript, Book 3: Backbone is draft complete as of today’s release except for a page or so of summary at the end, which I will probably wait to write until the Ember chapter is complete.

The next release will be an edit pass, to clean up typos and bad sentences, smooth over the explanation, fix errata and generally polish stuff. I haven’t done any of this on the book yet, so it’s possible there will be some bigish changes depending on what I think is going on.

Any further releases will be errata and cleanup based.

MSTWJS 4: Ember

I’m starting to get actual questions about the Ember version.

In the wake of the Ember team getting their newest router API into master, and also updating a lot of their documentation, I’ve broken ground on this one and am moving forward.

I will release this in a pretty early state, I imagine, and continue with the weekly updates until it’s through, which I expect will be on the order of ten weeks. Ish.

I have two criteria for the initial release. The first is that I need the example in the book to go far enough to display some things on the screen and show off some event and property processing. Secondly, I have a couple of people who have volunteered to sanity check the book, and I’d like at least one of them to sign off on it before anything insane I write is exposed to the general public. So, optimistically, Jan 14, but maybe a week or two after.

MSTWJS 1 and 2

I do have some standing errata that have been reporting. I would expect not to see an actual update until after the Ember book is on sale, not least because then the update email can be used to tell all the free book one customers that the Ember book exists.

Next Projects

So, I do know what my next project is going to be, I’m planning on self publishing it. It’ll be Ruby and testing based, but I don’t plan to start on it until after the Ember book is out in the wild. I came up with an outline while I was waiting for the Ember team, but now that I they look solid, I want to get that out first.

I keep coming back to three different things -- this is a more personal set of lessons than the last batch, so maybe they'll be less generally useful. Maybe not, though. Think of it as a little long-term career management advice.

These are all things that I think I kind of knew going in, but there's knowing something and knowing something, know what I mean?

Also -- nothing here is meant to say anything against Groupon Engineering -- I freely admit that what I'm talking about are issues of me managing my life and time.

Coding is the Input to Everything I Do

I like coding. (I thought I'd start with something controversial…) I like it a lot. That said, I've never been the guy who needed hours more coding in his week above and beyond work. For most of my professional career, my personal projects have been writing projects. And while I love to continually learn new things, it's been a long time since I felt the need to forgo sleep to do so.

Groupon was the first time in my professional career where coding was not a primary responsibility -- my primary responsibility was organizing training. And I'll stipulate that I went into it eyes open. It sounded pretty good. No coding project deadlines, and I love to teach. A room of students who have to listen to me sounds good.

At first, I was actively building the curriculum, that was pretty good. Then there was less curriculum work to, and in for reasons that I don't really need to detail, the things asked of me became a lot more administrative. The point is that as I got further away from everyday coding, I felt like I got less good at all kinds of things that I want to be good at. I didn't have interesting problems to blog about, I wasn't learning new things as much. I felt less credibility as a teacher and speaker as I got a little removed from practice. Combine this with my occasional tendency toward impostor's syndrome, and things got less fun quickly.

There were options available to me at Groupon that I chose not to take for reasons good and bad. The main point for me is that by the time I realized what I was losing, it was hard for me to feel like I could get it back. The point for you, I guess, is to be confident in knowing what you like to do and what parts of your work are satisfying. Know what you need to have as your inputs to be successful over the long term.

Big Companies are not Small Companies.

I know, duh.

I've joked for years about "big company problems" vs. "small company problems". In a small company you have to maintain the CI server yourself. In a big company, there's a whole IT department, but it takes you six months to requisition a CI server. (True story, at Motorola. Also they told me the CI server was causing too much network traffic, and did I have to run it after every checkin.)

There are two structural issues at big companies that have tended to drive me batty. The first -- that people are often making decisions about other people who they don't know and only have a dim idea of what they do -- was not a major issue for me at Groupon. The second -- that big companies tend to encourage people to specialize -- decidedly was.

I want this post to be about me, not about them. So here's a related story: when I first entered the job market, I wound up with two serious offers, salary identical. One of them was at Nokia, for an R&D department in Boston where I would have done usability research tangentially related to what I had been doing as a grad student. The other was what we'd now call a small web consulting shop, 12 people or so separated between two cities. I'd never done any web programming. They had done only a little bit more (they thought of themselves as documentary filmmakers by trade). When I went for my interview, the CEO of the company was vacuuming the floor of their 2-person Boston office.

Obviously I went with the tiny company, which even as I type this sounds kind of insane. And while I'd love to say something self-serving about how I picked the job that scared me, I don't think that's true (both jobs scared me). I do think, though, that I was excited by the prospect of doing a lot of different things. Which I did, the job turned out to be a kind of immersion in the entire lifecycle of software projects in the way that pouring ice water on somebody's head is kind of a way to get their attention.

Ever since, I've been happiest when I've been able to do all kinds of different things on a regular basis. Big companies, of course, tend to specialize because they need to, and because they can. Once you have 200 developers, suddenly you can spare somebody to be full-time in charge of improving training. (Well, almost full-time…) Which sounded great, for a while, but then, see point #1. I flatter myself that I do a lot of things well, and whether that's true or not, I still want to try to do a lot of things.

Introversion and local maxima

This one is a little tricky and it's really a personal anti-pattern.

Look, I'm in introvert in the classic definition. Every time I've taken a Myers-Briggs test, I bury the needle for I and N. On a day to day basis, one thing this means is that, while I usually like my co-workers (and my Obtiva/Groupon collegues are an outstanding group of people), I'll often choose, say, eating at my desk over going up to a group in the lunchroom and joining up with a group of people.

On a related note, for most of my last six to nine months or so at Groupon I was a team of one. Then the person I reported to left, and I wasn't even reporting to anybody else in Chicago. I swear this is true -- I was literally sitting in a corner with nobody on my two orthognal sides. I'm saying I was a little isolated. I'm also saying that of course I could have handled it better. That's part of my point -- one thing I learned is that what seemed like the best thing to do on a day to day basis, ended up being isolating in the long term. I would be able to go large chunks of a day without interacting with co-workers. Even a staggering introvert like myself has limits.

What does it mean?

Dunno. Just being a self-indulgent blogger. I expect most of you to read this, roll your eyes and say "Duh."

I do know that I've spent most of my six weeks at Table XI coding and helping run a small web project. I know it feels great even when it gets weird. It feels like I'm using muscles that got a little rusty. (I'd have some technical blog posts for you, but I'm backed up with the book. Coming, I promise.

Table XI provides lunch in house every day, which makes it a lot easier to actually talk to co-workers. Which is good. (I realize this lunch thing sounds totally insane to a significant percentage of you. I'm okay with that.) During my first week, I had a meeting where we planned out what kinds of things would happen as part of my first few months. One of my cards was "do something new". I don't know exactly what yet, but it's important to me to keep moving forward.

Thanks for listening, I hope you will, to paraphrase Tom Lehrer, find this valuable in bizzarre set of circumstances some day.

Hold that thought.

So I just finished reading Laurent Bossavit’s self published book The Leprechauns of Software Engeneering, which I recommend quite highly. Bossavit looks at some of Software Engineering’s core pieces of received wisdom: that there is a 10x productivity difference between developers, that the cost of change rises exponentially over the course of a project. The kind of thing that all of us have heard and said dozens of times.

Bossavit does an interesting thing. He goes back to the original papers, sometimes wading through a maze of citations, to find the original source of these claims and to find out what empirical backing they may have. Turns out the answer is “basically none”. One by one, these claims are shown to be the result of small sample sizes, or no sample, or other methodological problems. They’ve become authoritative by force of repetition. (Which doesn’t mean they are wrong, just that we don’t know as much as we think we do.)

If you are like me, which is to say you are fascinated by the idea of empirical studies of software, but deeply skeptical of the practice, this book will take your head to some fun places.

The Bill James analogy, for example. What James is talking about is that in order to accurately value what you have, you need some idea of the context in which it occurs. In the baseball example, to know how to value a player who hits ten home runs (which we’ll pretend is average, for the sake of oversimplification), it’s helpful to have a good sense of how many players are out there who are capable of hitting twelve, or eight. If you erroneously assume that there are fewer players capable of hitting eight home runs then ten home runs, then some bad management decisions are in your future. Specifically, you’ll overvalue your ten home run player (or more likely, overpay for somebody else’s ten home run player, when your own eight home run player is a fraction of the cost.)

I’m wary of taking this analogy too far, not least because it doesn’t necessarily reflect well on my overeducated typing fingers. There are all kinds of reasons to think that the curved for web developers is different than for baseball players. We don’t have a good idea of what the distribution curve of productivity is for developers, even if we had a good idea of productivity is (we don’t) or a way of measuring it (ditto) or any idea of how individuals improve or decline based on teams (guess what). That said, I do not think that I have been on an actual team where people were genuinely 10x better than other people. (Total newbies notwithstanding, I guess). Ten times is a lot of times, that’s one person’s week being another person’s half-day. Sustainably.

But see what I did there? I palmed a card. I said that newbies don’t count in my personal recollection of my teams productivity. Why not? For a good reason — I don’t think the productivity of somebody in intense learning mode has a lot to tell me about how software teams work. But that’s my decision, and it’s subjective, and suddenly I’m deciding which of my hypothetical data “really counts” and which doesn’t. That’s a normal process, of course, but it’s not How Science Is Supposed To Work. In reality, I’m already skeptical of the 10x finding, and pulling newbies out moves the data in a way I’m comfortable with, so I’m not likely to examine that decision too closely. (See Bias, Confirmation.)

I spent about five years reading and writing social science academic work, and if there’s one thing I learned it’s to always be skeptical of any finding that confirms the author’s preconceptions. (See also: Stephen Jay Gould’s The Mismeasure of Man — well worth your time if you deal with data.) Data is complicated, any real study is going to generate a ton of it, and seemingly trivial decisions about how to manage it can have dramatic effects on the perceived results.

I spent a lot of time researching education, which shares with software engineering the idea that individual performance is much harder to measure, or even to define, than you might assume at first glance. Empirical education studies tend to fall into one of two groups:

1. A study under very controlled lab conditions, where the researcher is claiming that a clear data result is applicable to the larger world.
2. A study in the real world, with messier data, where the researcher is claiming that there is an effect and that it as because of some specific set of clauses.

Both studies are problematic — the first kind often have small or non-representative subjects, the second kind is often a long-term study of one group with real questions as to whether the result is at all reproducible. On top of which you have the Hawthorne Effect (any group that knows it is being observed tends to increase performance no matter what the intervention is) and the effect whose name I can never remember where the more attention is paid to a specific metric the less reliable that metric becomes as a proxy for overall performance.

Or, looking at this another way… I got in a conversation at SCNA this year about why SCNA talks so rarely have empirical results about the value of the software techniques discussed. My kind of glib answer was that we’re all a little afraid that empirical results wouldn’t support the value we perceive in what me might call the “SCNA way”. By which I partially mean that we’re afraid that a badly-designed study might suggest that, say, Test-Driven Development had little or no value, and we’d all have to expend energy dealing with it. (But of course, I’d say that any such study is badly-designed, because of confirmation bias.)

But I also mean, I think, that I’m not interested in that kind of empirical testing and as interesting as I find the pursuit, I have little confidence that it will have much relevance to my day-to-day work. Agile methods, TDD, what we call “good” coding practices make my job easier and more sane. I have my own experience to draw on for that — which I realize is not science, but it’s working for me. Asking them to be proven to be the most efficient way to design software seems like impossible icing on the cake. For me, it’s enough that the methods I favor seem to result in saner, more pleasant work environments. It’s weird to simultaneously be interested in empirical results in my field, and yet at the same time feel they are utterly separated from what I do, but that’s where I am.

Got A New Job, Got A New Office

First off, I’ve started a new job as a Senior Developer and Agile Coach at Table XI, putting me back in the realm of small, Chicago-based consulting companies. Very exited, Table XI seems like a great place so far. Hoping to do new things, challenge myself, and learn.

Book Update

Most importantly, you can still buy it.

It’s going slowly but steadily, thanks for asking. I’m determined to start releasing weekly even if it means that I cut off the book in mid-sentence. Hoping that will start next Monday. The remaining Backbone chapter is something like 1/3 to 2/5 done.

Next up, Ember. I was already placed on a blog post of Ember.js resources, which is quite flatteringly optimistic given that the Ember stuff doesn’t technically exist yet. A couple of members of the Ember team have reached out and offered some technical assistance, all of which is very nice, and motivating, and terrifying.

Anyway, the Ember stuff is going to be interesting because, first off, Ember is still a rapidly moving target. I had hoped they’d have locked down a 1.0 API by now, but given the comments made on the recent JS Jabber podcast, it looks like we still have some movement coming. Also, it seems as though the nature of Ember implies a more complex example to really show it off. Still hopeful that I’ll be able to start pushing out Ember content in December, though.

Cons

The video from WindyCityRails is now up, as well as the slides from the evolutionary decendent of the talk from RailsConf — the RailsConf video should be up in a couple of days. There’s a blog post in progress exploring the common theme of those talks, as well as a couple of speakers at SCNA who came at similar themes.

Am I misunderstanding agile? or is it inappropriate to try to peg velocity?

— Charles Max Wood (@cmaxw) October 26, 2012

@noelrap They’re telling us we behind on the sprint. My understanding of agile is velocity is set by team pace, not wishful thinking.

— Charles Max Wood (@cmaxw) October 26, 2012

@noelrap You can push for deadlines, but you can’t tell us that we’re behind on the sprint just because we’re not going to achieve velocity.

— Charles Max Wood (@cmaxw) October 26, 2012

After trying like six times to fit my response in a tweet, I gave up and remembered that I had this web site where once upon a time I wrote things that were more than 140 characters.

Disclaimer: I have no idea how Charles’ team is working and what might have been said in planning meetings or anything else.

That said, here’s what I think.

The goal of agile project management is accepting the inevitability of change through continual feedback, continual improvement, and a realistic sense of progress. In an agile project, things that are hard when done in bulk — testing, integration, estimating — are done continually, in smaller pieces, to reduce complexity and risk.

Yes, in a functional agile project, velocity is set by team pace. Ideally, you had a meeting at the beginning of the sprint where you estimated velocity based on past performance, and determined the stories you hope to get done based on point estimates of the stories and that velocity. (Point estimates, remember, are measures of complexity, not time…)

It’s possible to be behind in a sprint, in some sense, if it doesn’t look like you are going to complete the agreed upon stories. For example, a story may turn out to be way more complex then estimated. Or a bug may have turned up. (Although agile point estimates are robust against bugs as long as bug fixes remain a roughly consistent percentage of your time).

Remedies for this problem might include changing the point value of a story when new information is determined, splitting the story, lowering velocity estimates going forward, moving a story to the next sprint. Retrospective meetings are a great place for trying to figure out why a story was mis-estimated.

However, trying to assess the state of the project in the middle of a sprint can be a little misleading. There can be a kind of optical illusion if a lot of stories start at the same time, where progress is being made but not booked because the stories aren’t finished. (Sometimes this means you need more granular stories.) Often, it’s helpful to organize the daily standup by outstanding story to give visibility to how stories are moving.

Charles is right that one of the points of Agile project management is not to work by wishful thinking of when you hope things will get done. If a story is more complex than we thought, then it just is, and you need to adjust to that by dealing with the software triangle — change scope, change time, change budget.

Granted #1: This requires a fair amount of trust between the team and the management that when the devs say something is taking longer than expected, that’s assumed to come from a place of expertise, not ignorance. You build trust by being right, and admitting it when you are not right.

Granted #2: Velocity and story points are robust against underestimating, as long as you are consistent. What will happen is that your velocity will settle at a point that factors in the overestimate. However, if specific stories or types of stories are continually taking more time than expected, it’s worth trying to figure out why. If for one reason or another, you aren’t the expected velocity isn’t being allowed to settle to a new state, that’s where the wishful thinking comes in. (Although if your actual velocity is continually dropping, that indicates a problem, too.)

Granted #3: Sometimes there are really are business needs for particular deadlines. That doesn’t change the laws of software physics, but it does determine what a reasonable response is from the team.

Okay, that’s more than 600 words, and I don’t know if I’ve answered the question.

• In an agile project, velocity should be related to past performance, not hoped-for results.
• If velocity is being determined top down — for example just trying to determine the velocity by guessing total story points in the project divided by sprints before deadline — that’s not really in the spirit of the thing.
• It’s possible to miss expectations for a sprint, but the appropriate response to that is usually not “type faster”.
• This all critically depends on trust between the project managers and engineers.

Wow, it’s been a while since I blasted out a blog post that quickly. Felt good. Hope this helps.

var foo = function(a, b) { return a * b };

var bar = function(func) {
  return function() {
    return func.apply(this, arguments)
  };
};

baz = bar(foo);
console.log(baz(2, 3));

What we have here is a function, bar, that both takes a function as an argument and returns a function as it’s result. It’s transforming the function passed to it into a different function.

Okay, that’s cool in kind of an abstract way, but so what? Let’s play around with function that take and return functions to show off some potentially useful tricks.

I’ll note right here up top, that there are more complex, fully featured, and robust versions of all the things I’m showing here. I’m just playing with functions.

We can add diagnostics.

var foo = function(a, b) { return a * b };

var trace = function(func) {
  return function() {
    console.log("calling " + func);
    console.log(new Error("normal trace").stack);
    return func.apply(this, arguments)
  };
};

foo = trace(foo);
console.log(foo(2, 3));

All the trace function is doing here is logging a couple of things before actually calling the function — namely, it’s printing the function body (JavaScript doesn’t have a consistent way to get the function’s name), and a stack trace. The console output is:

calling function (a, b) { return a * b }
Error: normal trace
  at file:///Users/nrappin/Dropbox/coderx/blog/functions.html:8:17
  at file:///Users/nrappin/Dropbox/coderx/blog/functions.html:15:13

Okay, that’s kind of neat. You can also tweak it to do something like a Jasmine spy object, but it takes some object manipulation. Here we really start to take advantage of the fact that JavaScript functions are basically just JavaScript objects.

var foo = function(a, b) { return a * b };

var spy = function(func) {
  var returnFunc = function() {
    returnFunc.timesCalled += 1;
    returnFunc.args.push(arguments);
    return func.apply(this, arguments);
  }
  returnFunc.timesCalled = 0;
  returnFunc.args = [];
  return returnFunc;
};

foo = spy(foo);

console.log(foo(2, 3));
console.log(foo.timesCalled);
console.log(foo.args)

Same basic idea here, except we’re doing some dancing with scope to make sure we have access to all the variables we want to, when we want them. Specifically, rather than just returning an anonymous function, we’re giving it the name returnFunc. Inside the funtion body of returnFunc, we’re accessing properties of the returnFunc functional object itself. Specifically we’re incrementing a counter and adding to a list of called arguments.

After we define the function, we initialize the timesCalled and args properties, and return our functional object. This works because we can access properties of the functional object inside the function itself, which seems weird, but makes more sense if you think of it just as an ordinary object accessing other properties of the same object.

Here’s a related example — in this case, our function object has its own methods.

var benchmark = function(func) {
  var returnFunc = function() {
    returnFunc.startDate = Date.now();
    result = func.apply(this, arguments);
    returnFunc.endDate = Date.now();
    return result
  }
  returnFunc.elapsedTime = function() {
    return returnFunc.endDate - returnFunc.startDate;
  };
  return returnFunc;
}

foo = benchmark(foo);
console.log(foo(2, 3));
console.log(foo.elapsedTime());

In this one, we’re running the inner function surrounded by time stamps, and we’re adding a function to the function object, which again, seems weird. At the end, we can query a benchmarked function as to how long it takes. (Yes, I realize that the dev tools allow you to do this.)

Here’s one that might be more practical. Memoizing is the act of caching the results of function calls so that you don’t need to re-evaluate an expensive computation.

var memoize = function(func) {
  var returnFunc = function() {
    argsToCheck = (JSON.stringify(arguments));
    if (returnFunc.cache[argsToCheck]) {
      return returnFunc.cache[argsToCheck];
    } else {
      result = func.apply(this, arguments);
      returnFunc.cache[argsToCheck] = result;
       return result;
    }
  }
  returnFunc.cache = {};
  return returnFunc;
}

foo = memoize(foo);
console.log(foo(2, 3));

In this case, we hold on to the functional argument as before, but when we call the memoized function, we first compare the argument list against a cache. We’re using the JSON string version of the argument list, so we do have that conversion overhead. If this particular argument list has already been called, then we return the result of the previous call without recalculating. If not, we calculate the function, and place the result in the cache. So, our first call to foo in the example places (2, 3) in the cache, but the second call would retrieve it, to avoid that very expensive multiplication.

This is the beginning of manipulating functions in JavaScript — functional programming in general is a big topic, but worth looking at. Adapting a functional style where side effects and mutable state are downplayed in favor of manipulating functions, can really pay off in less complexity in your code.

Like this? You might like my book Master Time and Space With JavaScript, free sample available, and $15 for the whole thing.

Short version: expect an early beta of about 1/3 of the book to be out in about a week.

Longer version:

Work is proceeding steadily, the current draft of just hit 30 pages toward a target of around 90, though about 10 of that is the same intro and outro that the other books have, so it’s more like 20 pages toward a target of 80.

The structure of Book 3 is one chapter on replacing the existing app homepage with a very simple Backbone clone, then another chapter building a different page using Backbone that has more events and more complexity, then a third chapter talking about communication between Backbone and the server, and anything else that comes up. The exact division between the second and third chapters may change.

I will release the first beta when the first chapter is draft complete — this will be rougher than the other books because it hasn’t gone through rounds of review and editing, but I like how it’s going. I also need to clear through reported errata on the first two books, and probably clean up the landing page in expectation of doing another marketing push.

Thanks for being patient and for your great feedback.

Oh, and you can still buy it!