Noel Rappin Writes Here

The Future, Soon

Noel RappinComment

It's been a while since I gave an update on the far-flung writing projects of Noel Rappin, inc. Here goes.

Rails Test Prescriptions 2: The Refill is heading out for roughly 50% draft complete technical review this week. I believe the reviewers have already been contacted, thanks to all of you who volunteered. There probably will be another round.

The review will probably take us through the end of March, at which time, I make any fixes suggested. My understanding is that the book has cleared the publisher review, which was, this time around, thankfully anticlimactic.

Being optimistic, I'll pick up the draft again in the beginning of April. There's something like three to four more months of draft writing to go, plus another round of reviews and edits, minus the fact that it will go on sale in beta before all that is complete. So, best case, it's on sale in August or September? That would be nice.

In the meantime, I'm making some forward progress on Trust-Driven Development, which I still am enjoying a lot, and which may eventually get a real promotional push and actually sell some copies. I expect that there will be at least one and hopefully two incremental releases of the book in the next month, and then moving toward a more complete draft later in the summer. The price will go up eventually, so now is a good time.

Once RTP: 2 and Trust-Driven Development get put to bed, next up is Master Space & Time With JavaScript version 2.

Here's what I know about it.

  • Updates to existing books will remain free to current customers.
  • It will move to current versions of jQuery, Backbone, Jasmine, and Ember, plus possibly start discussing ES6, depends on timing.
  • It will improve the setup of the sample code. It may break the Rails dependency, I'm not sure yet.

After that, who knows... Angular is not out of the question, but it is behind all these other things.

What I learned from reading 429 conference proposals

Noel RappinComment

I need to say this off the bat: this is my own experience, and does not necessarily speak for or reflect the opinions of Ruby Central, or any of the other conductors who chose individual tracks.

Also, I'm sure I'm leaving interesting things out, ask questions in the comments and I'll answer.

Are we good with that? Great.

Here are some things I learned from scoring and choosing my little corner of the RailsConf program. Which actually turned out to be a lot of fun.

The thing is: there is an essential arbitrariness to this process. I hope this isn't a surprise. But we've got fallible humans trying to guess how good a 40-minute talk will be from a 500 character abstract plus supporting material. Yeah, there were great abstracts. And there were awful ones. But there were an awful lot that were just really solid. Too many to fit the conference. So you have to pick. And inevitably that comes down to issues such as:

  • talks that might duplicate content
  • talks that don't seem to fit the conference or track
  • attempts to glean meaning from word chosen and words not chosen
  • an attempt to have a range of viewpoints, experience levels, and new and old speakers.

Ultimately, you have to pick what you think is best and hope you won't get too many people angry at you. I should mention here that I actually enjoyed the reading and rating all the proposals part, not so much the rejecting part.

Making the process blind does't keep it from being arbitrary, but it does change the flavor of arbitrary a bit.

What can I tell you that might help you in the future? A few things:

Things that get you in trouble

In no particular order, here are four things that got proposals in trouble:

Lack of detail or vague audience

The abstract basically boiled down to "I'm going to talk about X for a while", leaving out trivial details such as: "What is X?", "Why is it important?", "What will I learn about X?"

The slightly more advanced version of this is a talk that ends with something like "you will learn five techniques for solving your problem with X". That's better -- and if the proposer put some details in the extended field it worked out sometimes. (Disclosure -- I still end abstracts like this all the time. Which does not make it a good idea).

Better is "we'll learn to do Z, and other techniques that will allow you to do X". But granted there wasn't a lot of space in the abstract.

Pitchy

I was surprised at how many abstracts basically boiled down to "my company's product is awesome" or "my company's process is awesome".

Anything that felt like it was going to be a 45 minute commercial had an uphill battle from the reviewers.

If you are submitting a talk about something awesome your company does -- product or process -- try to make the proposal more generally about the problem. We want to hear about awesome things.

Aggressive

There weren't very many of these but they were maybe more memorable. Including language or terms in your abstract that seem unprofessional or aggressive was not looked on favorably by the reviewers. Often this was language, some times it was an aggressive or condescending tone towards other developers.

I solved the world

The last category is a little harder to describe... an abstract that basically went like this:

  • X is a hard problem
  • I solved a particular case of X
  • I will generalize my one solution to the entire universe of X

What's tricky about this kind of proposal is that it's only subtly different from a really good talk:

  • X is a hard problem
  • I have an approach that worked once
  • Let's talk about when that solution is appropriate and when it is not

The difference is one of self-awareness and a little bit of humility. The first style sounds arrogant, and not in a good "I'm gonna give a great talk" kind of way, but more in a "I have no idea how complicated this problem really is" kind of way.

Ways to help yourself

The advice from my last post holds, especially Rule One: "Don't give them a reason to reject you out of hand". That's basics of grammar, and the structure of the abstract. Beyond that:

Make Your Argument

RailsConf, like many conferences, allows submitters to submit an abstract, which is public, and a private pitch that only the organizers see.

It was not unusual for the pitch to be stronger than the abstract, I think because people internalize "abstract" to mean "list what my talk is about" and "pitch" to mean "convince people to pick my talk".

This isn't academic writing, though, and you want your abstract to convince people to come to the talk. Think about what you would tell somebody to convince them that they needed to see your talk. Include that.

Vote Early and Often

I think there's a slight benefit in submitting early. About 40% of RailsConf proposals came in the last 24 hours.

In the specific case of RailsConf, if you submitted early you had more of a chance to get feedback from the organizers, which helped a non-zero number of people get selected. The crunch at the end of the time period prevented that level of feedback on the final batch.

Also, a lot of the last-gasp proposals were a little slapdash, almost as if they had been put together at the last moment.

Blind Proposals

RailsConf had an initial round where the bio and name were not connected to the talk, and it was rated by multiple reviewers (at least 3), followed by a final creation of the list, at which time names were attached to proposals.

I'm was reasonably OK with this as a process. I think that the blind review does fulfill the function of forcing the review to focus on what's actually on the page, and not any knowledge of what the speaker brings to the table. I was unaware of the speaker for most of the talks I rated (in some cases the speaker inadvertently left in identifying information in the talk, which is a solvable problem, and in other cases, there is only one person who's talking about a given topic -- less solvable, but we do the best we can).

In general, the blind ratings were the basis of the final program, while granting that the difference between a talk rated 4, 4, 4, 3 and one rated 4, 4, 3, 3 is pretty minimal, and the conductors did do some curating where there were multiple closely rated talks. (Also there were a couple cases where one speaker had two highly rated talks, and so only one was considered... that kind of thing).

In conclusion

  • You absolutely can submit and be accepted to RailsConf even if you've never been a conference speaker before. We picked several first-timers.
  • The app that RailsConf used is going to be open sourced, so hopefully other conferences will pick up on the feedback structure that we used.
  • Sarah Mei is awesome. She rated all 429 proposals.
  • Your abstract and details are important. Make sure you are clear on who will get something from the talk, what they will get out of it, and why.
  • I'm reasonably happy about the "rate blind, then curate" process. It's not perfect, but I think it worked out okay.
  • I'm excited about the program we picked, and I'm really looking forward to seeing the talks. And hopefully seeing you there.

Experts, Passion, and Pinpoint Control

developmentNoel RappinComment

Quick and random:

The book Ball Four had a big impact on me as a kid. I stumbled across a copy when I was about 12. If you don't know, Ball Four, written by Jim Bouton and published in 1970, was one of the first big athlete tell-alls (though it seems much tamer these days than it did when it came out...) Anyway, a lot of the book can be read as the story of an articulate outcast trying to understand and navigate the other teammates that he's basically stuck with.

One passage from the book that's always stuck with me, is this one, which is Bouton taking about his early career:

When I first came up I thought major-league pitchers had pinpoint control, and I was worried that the best I could do was hit an area about a foot square. Then I found out that’s what everybody meant by pinpoint control, and that I had it.

How great is that? That is a form of impostor syndrome from a major-league pitcher.

It's a strategy I use to this day -- when I'm upset because I'm not sure if I qualify for some vague category like expert, or passionate programmer, or author, or senior developer, I at least consider the possibility that I'm setting the bar for that term too high, and that I'm already that thing.

Because experts look things up.

And senior developers ask for help.

And passionate programmers do other things sometimes.

And pinpoint control is a foot square.

Conference Prompts: Or How to Submit Proposals and Influence People

RailsConf, Speaking and WritingNoel Rappin1 Comment

I'm going to be conducting a few of the tracks for this year's RailsConf, specifically the Novice, Testing, and Crafting Code tracks. I'm very excited, this isn't an opportunity I've had before.

What I want from all of you is awesome proposals. I want to have to make hard decisions. I want to be inundated with all your amazingness.

Because I want to hear from all of you, here are some opinions on how to best present yourself in a speaking proposal.

Yes, You Can. In Fact, Please Do

In response to my initial round of begging for proposals on Twitter, somebody commented that they didn't think they were the most qualified person to talk on a particular subject.

To which I have three cheesy but true responses:

  • A conference that was limited to only people that really though they were the most qualified person to talk would be depressing, if not completely horrific.
  • You are absolutely the most qualified person to tell me what you think on a particular topic.
  • This is how you become qualified. You study something, you teach it to other people.

In other words, please don't let that stop you. If you don't submit a proposal, you have zero chance of being accepted.

(In a similar vein, here's a talk I once gave about how everybody has technical writing in them. Video's poor, but audio is okay.)

I can't speak for any of the other conductors, but I'm also looking for people who want to give shorter talks (10-15 minutes) with the idea that we might have a session that is 2 or 3 awesome shorter talks. If that interests you, definitely mention it when you submit.

What Should I Talk About?

Let's say, for the sake of argument, that I've convinced you that you should submit a proposal to RailsConf or the conference of your choice.

But you don't know what to talk about.

Here are some ideas. This is the kind of process I go through when I try to get ideas for a talk, though by writing it down I'm making it more systematic.

Think of these as prompts and use them as starting points to find an idea for a talk that excites you.

These are far from the only seeds for good presentations, but it's a start.

  • What is the last thing you spent more than 15 minute trying to figure out?
  • What is the last tool, process, or code you wrote that made you excited enough to tell somebody else?
  • What was the last question you asked a more senior developer?
  • What was the last question a more junior developer asked you?
  • What do you wish somebody had told you a year ago?
  • What was the last blog post or presentation in the community that you disagreed with?
  • Do you have a hobby or interest that informs your work?
  • What is the best line of code you wrote this week? How could you tell?
  • What was something you did for the first time in your last project? How did it work out?
  • What was something you did for the last time in your last project (or something you stopped doing for your last project)? How did that work out?
  • What is a tool or process you would like to learn more about?

Once you have an idea, try to answer these questions about it.

  • Who is the audience for this? It often helps to think of one specific person that you'd like to talk to.
  • Is there a story here? What is the beginning, the middle, and the end?
  • If a person watches this talk, what will they be able to do after the talk that they would not have been able to do before?

UPDATE 1/19 It seems worth pointing out that I'll be speakng at MountainWest RubyConf this year. The talk is on Smalltalk, and it's a direct result of a presentation I saw and wanted to respond to (I didn't actually disagree with the presentation, but I had another take on the topic). Also, I know for a dead certain fact that one of the other speakers is a much bigger Smalltalk expert than I am. And I am going to take may own advice and not let that bother me.

What Makes A Great Submission

I have opinions on the actual submission -- watch for updates after I dive into the actual submissions.

I'm going to share with you the first rule of submitting anything. This rule is applicable to any situation where a person has to spend a lot of time evaluating submissions -- resumes, conference proposals, writing submissions all included.

Rule One: The person reading these submissions is always looking for a way to save time. Don't give them a reason to reject you out of hand.

That means: if they have a format, hit the format. If they have a word count, hit the word count. Spell words correctly. Write in grammatical English. Sure, the reader might take extra time to figure you out if you bend the submission rules. But why take the chance?

Have somebody else read and edit you if you can. Find a buddy and read over each others. (I'm willing to be your editing buddy -- contact me via this web site).

In most cases, the talk descriptions on conference web sites are taken directly from the submission -- look through some, and see what makes them compelling.

Specifically for conference proposals:

  • Make sure you specify: a) who the audience is, b) what they should expect, c) what they will learn.
  • For a long time I was afraid to give out details of my talk in the abstract for fear of "giving stuff away". That was a bad idea. You need to give people an idea of what to expect. (The RailsConf CFP has a details field that lets you put in details for the organizers and not the abstract -- use that)
  • You don't have to explain why you are an expert, but if you have a particular reason why you might have insight into the subject, mention it. This reason is not at all limited to you having vast experience on the topic.

Good luck, and I look forward to hearing from you.

Monday Morning Me: October 7

Rails Test Prescriptions, trddNoel Rappin1 Comment

Monday Morning Me

I’ve skipped a few Monday Morning Me’s due to Ruby DCamp and a couple of other things. DCamp was awesome, and maybe beyond my humble ability to do a trip report. In the meantime..

Rails Test Prescriptions

Ground has been broken and progress is being made. Not a lot of ground, and not a lot of progress, but ground and progress nevertheless. So, yay, that.

When last I wrote about this, I was debating whether to use MiniTest or RSpec as the main test framework for the book. After a couple of impassioned pro-MiniTest pleas at Ruby DCamp last week, I’ve come around to the idea that MiniTest’s availability and simplicity trump RSpec’s mindshare and ecosystem, at lest for teaching purposes.

However…

The first real code section of Rails Test Prescriptions is a TDD walkthrough of adding a first feature to a new project.

One of the guiding principles of the book is that I want the advice and techniques to reflect effective practice, or at least effective practice as I understand it.

My normal practice for adding a new feature would be an outside-in approach: write an end-to-end test describing the new behavior, then fill in logic with focused unit tests. Normally, I would use Cucumber and RSpec for this. But, as mentioned, the book is using MiniTest instead of RSpec. And I don’t want to bring Cucumber in right at the beginning for similar reasons — too much to explain.

Which leaves me writing end-to-end tests using Rails integration tests (ugh) or Capybara, which, of course, also involves bringing in a new gem. Which I’m doing, but the Capybara MiniTest gem wants to use the MiniSpec syntax, which I don’t want to use because more explaining of details early on and all. (Update Mike Moore points out that I’m overstating the extent to which Capybara MiniTest wants to use MiniSpec as opposed to allows MiniSpec. I still am not sure that a lot of people are actually using MiniTest/no spec syntax/capybara.)

So it occurs to me that in the guise of coming up with a testing stack that will make sense to testing novices I have stumbled with the best of intentions into a set of libraries that as far as I can tell is in active use by effectively nobody in the entire world.

This is either insane, or so sane that it’s amazing. Statistically, the odds are on insane, but I’d love a second opinion.

It seems like my viable options are:

  • Do what I’m doing and assume that I can explain it well enough to make sense.
  • Back out and use Rails integration tests instead of Capybara
  • Back out and use RSpec instead of MiniTest
  • Back out and write the Angular book instead. (This is not really an option)

I’m open to comments if you have a suggestion.

Other than that, it’s just been a matter of getting used to changes in the build tools, and finding an editor setup that plays nicely with the formats that Prag uses. Nothing too bad, though I’m seriously considering that Editorial on the iPad has a real shot of becoming my primary editor for this book (writing it on the iPad next to coding on my laptop). Which is also clearly so insane that it may lap all the way around and become sane again.

Trust-Driven Development

Obviously, I’ve missed my plan to get something out in September. I have about 30 some odd pages of text, and I’d release it except that some of the sections kind of trail off in mid paragraph. I may just release it anyway, I have a beta reader or two looking at the manuscript to answer that very question.

If you want slightly earlier access, let me know via email (noel at noelrappin dot com). And, of course, you can by what exists of the book at /trdd.

Mastering Space and Time

So sales have started to pick up at the new price level. Not setting the world on fire or anything, but a more steady rate. Let me know if you are interested in writing about Master Space and time in JavaScript on your blog or something. And, the book is still available at /mstwjs.

Monday Morning Me: Sep 16, 2003

self promotionNoel RappinComment

Here’s what’s going on.

WindyCityRails

Had another great time at WindyCityRails. I enjoyed the talks, and it was great to meet new people/see people I don’t see enough in person. As usual, Ray and the WCR team had the logistics of the event down (even the WiFi was pretty fast for a conference.) The venue is really nice, if maybe not perfectly arranged for the kinds of talks being given.

I very much loved Aaron Kalin waling around in his stormtrooper suit on day two, in response to a bet from Table XI to donate $50 to Facing Disability for each hour that Aaron wore it. You can see some of the results: here, here, here, here, and here.

As for my own talk (slides, video coming eventually, I assume), I was happy with it, but hope I get to give it again, because I feel like I was still discovering some ideas about how I was approaching the topic. For example, the framing idea of how practices get to become your new normal practice really only fully formed the night before, but I’m really interested in exploring it.

Also, as much as I really wanted to tell the “little web engine” story, I don’t think it’s as funny to anybody else as it is to me. (Right now, I have a much better time getting jokes to land in workshops then in formal talks, which is frustrating.)

Master Space and Time

The update is that today is the last day of the current pricing scheme. Tomorrow, the prices go up to $10 per book, or $25 for the bundle. So, if you want to get the cheaper price in under the wire, go to /mstwjs.

Rails Test Prescriptions

I’m currently in the process of auditing the existing book to determine all the things I wrote that still make sense, and all the things I wrote that don’t.

I’d like the next version to hit the “good tests equal good design” button a lot harder, and I’m trying to see how to structure the book to get that to work.

I’m also trying to figure out the minitest/RSpec balance. I’ll describe the basics of both, but I think I need to pick one as the primary focus of the code samples.

In favor of minitest: it’s the Rails default, it’s arguably simpler (or at least, it’s simpler internally), and the existing RTP code examples are compatible.

In favor of RSpec: it probably still has a larger share of Rails developers, it’s more expressive, and it has a more interesting ecosystem.

Anybody with an argument for focusing on one or the other that goes beyond “I use that one” is welcome to chime in.

Trust-Driven Development

I’m Doing an edit/finish some half-finished sections. I’d like to get a 30-some-odd page initial release out sometime in the next 10 days. Again, if you want to get it before the price goes up, it’s available at /trdd.

Rails Test Prescriptions 2 Is Coming

Rails Test Prescriptions, mstjs, trddNoel Rappin2 Comments

I’m pleased and more than a little surprised to be announcing the existence of Rails Test Prescriptions 2, (which may not be the final title).

You have questions. Even if you don’t, I have answers.

Can you give the news in the style of a movie poster tag line?

Sure.

Coming in 2014. It’s time to get your prescription… refilled.

Rails Test Prescriptions 2: The re-prescriptioning.

When did this happen?

Really, just last week. I got an email asking if I was interested (Spoiler Alert: I was.), and we went very quickly through to contract.

What will it cover?

It’s a little up in the air still, but broadly, we’ve got this:

  • Updates to the big tools. Rails 4, RSpec 3, minitest replacing TestUnit.
  • Changes to the ecosystem, so updates to a bunch of other tools, including FactoryGirl, Cucumber, Capybara
  • Some deprecations — there are some tools discussed that are basically not anymore.
  • New tools. I think the biggest class of tool not discussed in the original RTP is quick startup tools like Spork and Zeus. I’d like to cover continuous integration options, too, we’ll see if I can make that fit.

Over and above all of that, of course, is the fact that the discussion over good testing practice has changed. There’s a lot more talk about maintaining large test suites, writing faster tests, and using tests to drive better Rails application design. I’m planning to talk about that aspect of testing as well.

I am really open to feedback and ideas about what to include and what can be safely removed (any Rails performance testing fans in the audience?)

Timeframe?

Good question. I’d bet at least spring for the first beta. Ask me again in a few weeks.

Are you insane?

I assume you are referring to the fact that I have other writing projects in process.

Yeah, that. Well?

I’ve got it under control.

Yeah, I’m gonna need more than that, writer guy

Okay, let’s take them one at a time.

Okay. Master Space and Time with JavaScript: Ember

Well, the nice folk at Ember central were nice enough to release Ember 1.0, making my plan considerably more concrete than it might otherwise be.

I’m currently working on the draft-complete release of the Ember book, which I expect to release this week. Code up to date with Ember 1.0 and Ember Data 1.0 beta. Info on the Ember inspector, and more stuff on components and promises in Ember routing. Maybe another goodie or two if I have time. That should take me roughly to 115 - 120 pages, a complete draft, and it will trigger a price increase. If I release the book this week, the price increase will come about 9/16. You can still buy Master Space and Time With JavaScript with the handy-dandy purchase link.

The Ember team has announced plans to do new point releases every six weeks. My expectation is that through the end of 2013, I’ll fix errors, and come back toward the end of the year to see if there is anything that needs updating or adding. Probably the same through at least the beginning of 2014.

Okay. What about Trust-Driven Development?

That’s obviously a little more problematic. But I’m really happy with the book, it’s fun to write, and I’m going to keep up with it.

The initial release will still come in September, hoping for this week, but that one looks optimistic. Next week is a better bet. That release also triggers a price increase. And of course, you can still buy Trust-Driven Development at the fabulous purchase link.

After that, I’m not sure. One thing about this book, though, is that it is kind of a nice palette cleaner to break up writing just about code all the time, so I’m actually looking forward to having that as a project during breaks in the Rails Test Prescription 2 process, such as technical reviews and so on.

So maybe I am insane after all.

Anyway, I’m very much looking forward to revisiting Rails Test Prescriptions, fixing all the things I got wrong last time, and making all new mistakes. Hope you like it.

All I Post These Days Is Status Updates

Self Publishing, mstjs, trddNoel RappinComment

Here’s where we are at the moment.

Master Space & Time With JavaScript: Ember

I think I may have finally gotten my head around the Ember release plans. My current understanding is that:

  • A 1.0 final release of core ember is imminent, possibly as soon as September 1.
  • There’s another major overhaul of Ember-data (the “jj-abrams” reboot branch), which will become the master branch sometime between now and the 35th of Octvember. In other words, who knows?

Which leaves me with the following plan:

  1. Once Ember 1.0 is released, I’ll start on a relatively minor revision of the book that will make sure it works with 1.0, allude to some new features, maybe talk about the Ember Inspector if I get ambitious.
  2. I actually don’t plan to add all that much new content, it’s already 108 pages, I doubt it will go above 130. (For reference, the Backbone book is 120, with longer code samples). I want to go through an authentication example. I may talk about components or more advanced view topics.
  3. Some of that is just going to wait until Ember-data gets sorted out, so I’m not rewriting the thing over and over.
  4. The 1.0-related release may be the one that triggers the price increase (based on length). We’ll see. But it’s coming.

You can buy Master Space and Time with JavaScript.

Trust-Driven Development

Work is proceeding on this a little faster. I think I have about 30 pages of text (it’s a little hard to tell because I have a lot of blank chapters adding pages).

I like what I have, but the organization is going to need work. Right now it’s really a set of interconnected essays about project topics (already written topics include points and velocity, user stories, iteration management, the introduction, and a couple of other topics.

The current plan is to start releasing actual text around WindyCityRails, September 12th. That triggers the price increase from $15 to $20, but I’ll probably soften the blow with a promotion over WindyCityRails.

If it’s not ready then, plan B is the same thing but over Ruby DCamp two weeks later.

You can buy Trust-Driven Development.

And another thing…

Weird as it may sound, this represents me trying to clear the decks because a new project has come up. It’s not official yet, and it’ll get its own blog post when it is.

More State of The Stuff, July 2013

mstjsNoel RappinComment

Ongoing update and stuff

I know, I haven’t been blogging much. I can always tell when I’m putting things off because the half-finished blog posts stack up.

First, Master Space and Time In JavaScript is still on sale, and for the moment it’s still $15. Somebody using the twitter handle @shakerdev just called it a “great fucking read for JS devs.” So, I’ve got that going for me.

The ongoing projects list looks like this:

Master Space and Time Book 4: Ember

Still caught in the tension between wanting — really wanting — to get this one done, and the fact that the Ember team keeps releasing cool new stuff and not going to a 1.0 final release.

I should mention, in the wake of some comments on line about Ember’s volatility and books, that no matter what else I wind up doing over the next few months, my plan is to continue to keep the Ember book current through at least Ember 1.0, and I hope somewhat beyond that.

My planned topic list hasn’t changed a ton:

  • More on views and handlebar helpers
  • Ember data details
  • Ember-testing details
  • The new async routing API — this will probably include a short section on promises, which may get promoted to book 1.
  • I’d like to deal with some real-world examples, at least briefly, of things like authentication
  • I also may switch from jasminerice to teaspoon as a test runner, which may also mean going back and retro-fitting earlier parts of the books.

Angular Update

Since I last blogged about this, I’ve taken one baby step towards an Angular book, namely getting a new branch up in the book’s code repo set with Angular. The goal is to create the basic admin console stuff similar to the Ember book example. If I feel like I can do that and explain it clearly, then I’ll start writing. I think the odds are at just over 50/50 that I’ll do it. If I do, it will probably go on sale as a beta in very early stages.

Project Book Update

I should probably put this higher, but it’ll get its own post in a week or two.

A while back, I casually mentioned on Twitter that I was thinking about writing about how to deal with projects. This met, I think it’s fair to say, with near-total indifference.

Nevertheless, I’m still doing it, because I want to write some of this stuff down. The book now has a title, a scratch cover, and about 15 pages written. Final length will probably be in the 120 page neighborhood, but who knows.

Full announcement, including the title, and cover and a way to be notified when it goes on sale, will come when I get to a) 25 pages and b) a coherent outline.

I’m very excited about this, I think it’s going to be good.

If you’ve ever worked on projects with people who are not you, this book will help you.

Pricing

If you follow me on Twitter, you may have noticed that I was discussing book pricing with Jim Gay of Clean Ruby fame. This was in the context of a new Ember book from Giles Bokett, that is priced at $47.

It seems like Giles, at $47, and I, at $7, are both sub-optimal in terms of maximizing revenue from our Ember work. I generally err on the side of under-pricing my stuff though some combination of my own insecurity and also the idea that an inexpensive book is accessible to more people.

Still, there’s erring on the side of inexpensive, and then there’s not having confidence in the value of your work. The full set of Master Space and time With JavaScript is going to be about 125 - 150% the length of Rails Test Prescriptions for less than 2/3 of the price. (And yes, I know that page length isn’t really a marker for anything. Still…)

Which is a long winded way of saying that the price of MSTWJS will be going up, with the actual date being either a) the draft-complete version of the Ember book, b) the first beta release of the Ember book over 120 pages (currently at 94), or c) the on-sale date of a currently-mythical Angular book. Exact pricing still TBD, though I’m still open to argument. I’ll probably also add some kind of workaround for students and others for whom the price is a hardship — not sure what that will look like yet.

Finally

Buy the book, please: Master Space and Time In JavaScript.

State of The MSTWJS Union, June 2013

mstjsNoel RappinComment

Here is the state of the Master Space and Time With JavaScript Union as a I currently understand it.

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.

Status Update

Self Publishing, mstjs, self promotionNoel RappinComment

It’s been well over a month since the last official update to Master Space and Time with JavaScript, and since I was hoping to get updates out more-or-less weekly, it’s probably a good idea to check in and let you know what’s going on. (Could be worse, though, I’m still hoping to post my top 10 books I read list. From 2011.)

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.

Announcing Ember! Master Space and Time With JavaScript Book 4

JavaScript, Self PublishingNoel Rappin6 Comments

You have no idea how happy I am to announce that Book 4 of Master Space and Time with JavaScript: Ember is now on sale. You can buy it at /mstwjs

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: /mstwjs, enjoy it, spread the word.

Thanks

State of My Stuff, January, 2013

Self Publishing, self promotionNoel RappinComment

The state of the Noel Rappin publishing — I can use the word “empire”, right?

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.

More Lessons Learned

MeNoel Rappin1 Comment

Last year, when Obtiva was purchased by Groupon, I wrote a "what I learned" post talking about things I thought I came to understand about software projects after working on a bunch of them. Now that I've moved on from Groupon, I started to think about what, if anything, I learned while I was there.

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.

Leprechauns and Unicorns of Software

softwareNoel Rappin2 Comments

Something like 25 years ago, Bill James wrote an essay asserting that one difference between smart and dumb baseball organizations was that dumb organizations behaved as thought Major League talent was normally distributed on a standard bell curve, and smart organizations knew that talent is not (it’s the far end of a bell curve).

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.

What's Up?

MeNoel RappinComment

Oh yeah, things happening…

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.

Velocity, Agile Estimation, And Trust

AgileNoel Rappin1 Comment

Charles Max Wood posted this on Twitter:

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.

Functions that return functions are the luckiest functions in the world

JavaScriptNoel RappinComment

Here’s some JavaScript:

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.

Master Space And Time Status Update

Self Publishing, mstjsNoel RappinComment

Here’s a quick status update on Master Space and Time With JavaScript, book 3…

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!

Depending on jQuery and Perspective

JavaScriptNoel RappinComment

The reported errata for Master Time and Space With JavaScript (buy it here) has been pretty light so far. A bunch of typos, some setup weirdness.

And one interesting issue worth exploring. What is a dependency, and maybe more to the point, where is a dependency?

This issue was raised by a reviewer whose name I’m not going to mention — that’s not a reflection on the reviewer, but rather a reflection on the fact that I’m going to put words in his mouth to expand on his brief comment on the issue, so my interpretation of his position may not actually be his position.

Anyway the reviewer had a comment about when to convert to and from jQuery objects. He raised it in the context of the autocomplete example from the please-go-pay-for-it Book 2, but it also applies to the toggler example in just-for-free Book 1, and really, in any case where you have a JavaScript object which uses a data type that is a jQuery object.

Here’s the deal. I have an object — in this case it’s my autocomplete selector, but I’ll pretend it’s a generic widget because the exact object doesn’t matter — which is being initialized via a function call like so.

    widget = new Widget({parentSelector: "#autodiv"});

The key point here being the parentSelector: "#autodiv" option. In the eventual constructor, that #autodiv is immediately converted to a jQuery object (The example in the book is more elaborate, I’m simplifying to focus on the issue at hand…)

    var Widget = function(options) {
        this.$domParent = $(options.parentSelector);
    };

The reviewer’s point was that he’d rather convert the selector to jQuery in the call to Widget and pass the argument to Widget already converted to a jQuery object, rather than have the Widget constructor do the conversion:

    widget = new Widget({domParent: $("#autodiv")});

    var Widget = function(options) {
        this.$domParent = options.domParent;
    };

I’m not convinced yet that one way is better than the other — I haven’t changed the book code, but I certainly respect this reviewer’s opinion on how to structure JavaScript. But I do think that the two options make different assumptions about the structure of the application that are worth teasing out.

In my structure, jQuery is treated as an implementation detail of the Widget. Since jQuery is an implementation detail, outside code wouldn’t be expected to know about it, so outside code communicates to the Widget via a selector. Now, I grant that there’s a little bit of fiction there, since the selector syntax is (somewhat) jQuery specific. If I really wanted to isolate jQuery, then the calling argument should just be the DOM ID, and the Widget would also be responsible for converting the DOM ID to a jQuery object, with the intermediate step of building a jQuery selector string:

    widget = new Widget({parentId: "autodiv"});

    var Widget = function(options) {
        this.$domParent = $("#" + options.parentId);
    };

The advantage of treating jQuery as an implementation detail of my widget is that the rest of my code does not need to know or care about it, and I can presumably even test other parts of my code without jQuery even being around. Also, if I choose to swap jQuery out for some reason, the rest of my code doesn’t need to know, only my widget needs to be changed. I would consider the conceptual point about jQuery being an implementation detail of the widget to be important even if I find it exceptionally unlikely that I would swap out jQuery. (For one thing, it also protects me against jQuery itself changing).

In my reviewer’s structure jQuery is a dependency of the application as a whole. Looked at from that perspective, it makes sense to convert everything to jQuery objects as early as possible, to maintain consistency of representation across the entire application. The code as a whole may be easier to read, since we aren’t continually having to worry about whether an object is a jQuery object or just some kind of DOM identification. If multiple widgets are all using the same jQuery object, then we might prevent some duplicate conversion to jQuery objects. This probably simplifies the internal code at the cost of making us more dependent on jQuery itself. As a practical matter, that tradeoff might be worth it — once we’ve decided to use jQuery, changing it is probably unlikely.

Essentially, it’s a question of where you draw your boundaries. I’m not sure there’s a long-term practical difference between these two structures, in that I don’t think one of them necessarily leads to better or more flexible code over time, especially given even rudimentary attention to practical details. But I do think you should be clear about which structure you are using — mixing the two by treating jQuery as a specific dependency of some parts of the code but a general dependency of other parts would probably lead to confusion later on.

Update:

A reddit commenter asked why I wasn’t passing a DOM element into the Widget, as in:

new Widget({parentSelector: document.getElementBy("autodiv")});

My response: I have nothing really against passing in a DOM element beyond it being a little verbose and an old-timey superstition against using getElementBy. Using a DOM element still keeps the dependency in the widget.

Like this? Go ahead and read Master Time and Space With JavaScript