(..UGUGHAOMIGOD, he actually did. So gross.)

Ok. Did you hear the story about the reporter who interviewed Steve Jobs about the iPod, and Steve Jobs was outraged that the reporter’s iPod was in a protective neoprene case, which made it a) look ugly, and b) not gradually pick up that “scratched stainless steel” patina? Maybe this is like that. Maybe a brown paper bag is uglier than sleek faux-leather. Maybe a moleskine should look like it doesn’t often drink beer, but when it does…

Or maybe raw brown paper is DIY-chic. Maybe you can’t tell your moleskine from everybody else’s. Maybe your notebook already takes enough abuse. Maybe a brown paper cover is a good idea.

Whatever. I got the idea for this about a year ago, and did it just to see whether I could. (The moleskine elastic, as you’ll see, makes this a little trickier than your typical book covering.) I’ve done it several times, because I kind of like it. I finally googled today to see whether anyone else had instructions up for this, and was surprised I couldn’t find any. So here we go!

Materials

• Your uncovered moleskine notebook. I’m using a large, but I’ve also done this with small ones.
• A brown paper bag. For the large notebook, I’m using a bag that’s 7 1/16 x 4 1/2 x 13 3/4; for small notebooks, you can use something as small as a lunch bag.
• scissors
• a pen
• packing tape (optional – just for reinforcing some weak joints)

The Easy Part – a pretty ordinary book covering

This part is just like the book coverings you maybe made in school.

Cut down the seam of the paper bag, and cut off the bottom, so you have a large sheet of brown paper.

Fold the top and bottom edges of the paper down, so the book is the same height as the paper.

The paper folds create a sleeve, and you want to be able to slide the front cover into it. In fact, slide the notebook’s front cover into it now, and fold it back, around the book. If it looks like this:

…then cut the extra paper, so it looks like this:

Where it gets different

That elastic is getting in the way, right? Unwrap the book a bit, we’re gonna use the scissors – but read through this part all the way before you start cutting.

If you measure, you’ll see that the elastic is 1/4″ wide, and 3/4″ from the edge of the book cover (sorry for the blue-and-purple):

The trick is to cut some of the paper off of the cover-flap, so the elastics can get out. In this picture, I marked the parts to cut out with a black marker (the green arrows):

Make sure you cut on the back flap, not on the back cover. For some reason, I always screw this up – I want to cut the back cover. Don’t do that. Cut the back flap.

Leave at least 1/4″ between the cut and the fold. I cut a trapezoid shape, which makes it a bit easier to put it together, but it’s not that important. Here’s how it should look when you’re done:

You don’t have to reinforce this section with packing tape, but I’d recommend it – with the larger notebook, the elastic jerks this part of the cover around a lot, and the packing tape will make it last a lot longer. Don’t forget to do the bottom half, too.

Take the whole cover off the book – it’s easiest to put the back cover on first. Slide it in, so the elastic pops out of the cuts you just made:

Ok, this is the tricky bit – getting the cover on, and the elastic arranged right. Close the front of the book under, so you’re still looking at the back side of it:

Fold the elastic around the spine (to the right, in the above picture), so it’s holding the book shut. Here’s a close-up of the top of the book:

The hard part’s done! Wrap the cover around the back of the book. Before you wrap it around the front, take the elastic off again – you’ll need to open the notebook to get the front of the cover on. Open the front cover of the notebook, and slide on the cover flap. Pop the elastic back on, and…

All done!

Side Benefits

Moleskines famously sport that back accordion pocket. Covering one in brown paper like this means you can add two more:

The explanation comes in two parts:

After I announced I was releasing WordCram, I worked like mad on it. In my last post, the one announcing WordCram, I said “There’s still work to do, but that’s the fun part,” but I had no idea. And it’s not even a big library, or do anything useful! And there is certainly still work to do. I have a new, visceral appreciation for how much open source software developers give us. That’s the first part.

But all that stopped last April, when my employer began going through some – I guess “changes” is a safe enough word. Nevermind what they were. It got me thinking it was time to find a job I liked better. The job search is the second part of the explanation. I didn’t want another ordinary-business kind of job, but I didn’t know which direction to head in. After  sinking myself in some Processing.org dataviz, science, and Ruby, talking to a bunch of excellent people, and finding some luck, I got a spot on the SeeClickFix team, doing Ruby on Rails, and helping citizens improve their community.

Get a great job, working in a great language, making the world a little bit better:

I start in September, right before I start classes at Ruby Mendicant University. It’s been a busy spring and summer, and it’ll be a busy fall, too.

And at some point, I have some WordCram things to finish…

I found wordle.net a few years ago and really liked it, and after seeing the code for Algirdas Rascius’ Scattered Letters on OpenProcessing.org, I tried making some of my own.  It was fun, but I thought it ran too slowly to bother bundling it into a Processing library.

After reading the Wordle chapter from Beautiful Visualization, I learned a few new tricks, and it’s a bit faster now, so here it is.  There’s still work to do, but that’s the fun part.

Here’s my highlights and impressions.

Innovation

Rolf Skyberg explained where corporate innovation initiatives come from, and Simon Wardley talked about innovation. Those links are to the talk descriptions, but you can watch Simon’s talk on youtube, since it was a keynote.

As a company ages, Rolf says it gets more risk-averse, and that stifles innovation. He names each life-stage of a company for its most prominent employees: innovators, rock-stars, proceduralists, optimizers, and vultures. Once the company becomes so risk-averse that new ideas are stifled, and it starts losing money, the CEO assumes the problem is a lack of new ideas, rather than a culture that can’t absorb them.

As a technology matures, Simon says it gets more stable and ubiquitous, becoming a commodity. This “creative destruction” frees us up to do more interesting things.

I’ll be going back over their presentations, thinking about the commonalities between their talks.

Google’s Go

Rob Pike’s talk Public Static Void gave some context around Google’s new(-ish) language, Go, which I’d pretty much ignored. A few choice bits:

• “there’s a false dichotomy between nice & dynamic & interpreted, and ugly & static & compiled”
• Scala is “beautiful and rigorous”
• (my favorite) “a language should be light on the page”

Processing

I got to show Processing to a bunch of people, which made me happy — Processing is a great tool, and a lot of fun. Kathryn Aaker was there, and she even made a sketch on the flight home.

I also talked with a guy whose name I can’t remember, and whose card I didn’t get, about how his friend used Processing to teach math concepts to his kids. That’s a pretty amazing thing. Take that, Mathematician’s Lament!

Scala, Mirah?

I really enjoy Processing, but…Java. Can we have something fast, but with closures and easy syntax, please? Either Scala or Mirah might meet that need.

Mirah is a Java compiler that reads Ruby-like syntax: looks like Ruby, but it’s still Java. That seems promising, but I don’t think you can use, say, Array.map, since it’s not part of Java’s core library.

Scala is a functional/OO hybrid language that brings closures and higher-order programming to Java, with a helping of type inference. It seems promising, but it also seems like a lot of features mixed in together; compared to Io or Scheme, there’s tons to learn. But maybe that’s the wrong way to look at it — maybe it’s close enough to Java that it’ll be fairly quick to learn.

Powell’s Technical Books

Powell’s books is humbling, and amazing. There are whole sections I’m not even smart enough to understand. I still walked out with three books, though.

The first one is The Philosophical Programmer, which I’d never heard of, but for $6, I had to grab it.  (Yes, it’s an old library book.)  I got A Little Java, A Few Patterns because I loved The Little Schemer.  Grammatical Picture Generation is about writing tiny languages that generate fractal-type images, something I’ve been playing with recently.  And I actually bought Beautiful Visualization at the conference itself, not at Powell’s.  It’s fantastic, though, I read it the whole flight home.

OK!  Enough fawning over books, I’m embarrassing myself.

Asynchronous JavaScript

My team’s been bogged down lately by some ASPX pages with very complex javascript behavior. Somewhere between Stratefied.js and Reactive Extensions for JS, there might be a way to tame them.

Stratefied.js introduces new language constructs to javascript to implement concurrency semantics. I’m not 100% on the semantics themselves — they bear looking further into, but they don’t seem terribly complicated. The part I thought was neat was how they’re implemented in all browsers, even geriatric IE6:

<script src="stratefied.js" type="text/js"></script>
<script type="text/sjs">
  /* your code here, including new syntax */
</script>

Notice the type attribute of the second script?  Once the page is loaded, Stratefied.js loads all scripts of type “text/sjs”, and does some source-transformation, turning the new constructs into (I’m guessing) gnarly, but standard, javascript.

Reactive Extensions for JS come from open source’s best friend Microsoft. The gist is this: asynchronous coding with call-backs is hard, but if you treat events (from the user, from ajax HTTP, or whatever) as a collection that you can subscribe to, and you can map and filter those collections with anonymous functions, it’s easier. We’ll have to see. The speaker, Erik Meijer, gave a pretty similar talk at MIX.

Badges, with Ribbons

They took some flak for the ribbon color-text, especially for the desperate perl hackers, but they were pretty good about it. They even asked what ribbons we’d like to see next year, so we don’t have to customize quite so much.

Inspiration and Awesomeness

The world is full of inventive, stubborn people doing really cool things to make the world better. Mifos.org helps microfinance banks run smoothly. Arduino and Plumbing making hardware hacking accessible to whole new audiences.  OpenSETI wants to involve programmers more in finding whether we’re alone in the universe.  Code for America can help our government be more efficient and transparent.  If you ever wanted to start contributing to open source, joining any of these projects should be a great start.

Pretend You Were There!

Or re-live the experience, if you were!  Here’s the keynotes on youtube, and photos on flickr.

At work, our app’s links are usually wired to javascript functions that use jQuery to scrape the form data and post it to web services via ajax. We normally disable links and buttons something like this:

var updateLink = $('#updateLink');  // Find the link.
updateLink.click(function() {       // When it's clicked...
   updateLink.disable();            // disable it...
   ajax({
      data: getFormData(),          // ... & send the form data
      url: 'http://someWebService', // to some web service.
      success: function(results) {  // When the service
         if (results.hasErrors) {   // finishes,
            showErrors(results);    // show any errors,
            updateLink.enable();    // and enable the link
         }                          // so they can try again.
      }
   });
});

We added those enable() and disable() functions to jQuery — they just add or remove the disabled attribute from whatever they’re called on. But it seems Firefox doesn’t support disabled on anchor tags, like IE8 does, so we couldn’t stop the repeat-calls that way.

We got to thinking, what if the link always called its javascript function, but the function could turn itself off after the first call, and back on after a successful ajax post? That led to this:

function makeGated(fn) {
   var open = true;
   var gate = {
      open: function() { open = true; }
      shut: function() { open = false; }
   };

   return function() {
      if (open) {
         fn(gate);
      }
   };
}

makeGated takes your function, and wraps it in another function, a gate function (it “makes your function a gated function”). When you call the function it creates, it will only call your function if the gate is open — which it is, at first. But then, your function can decide whether to close the gate (that’s why the gate is passed to your function). You could use it like this:

var updateLink = $('#updateLink');  // Find the link.
updateLink.click(
   makeGated(function(gate) {       // When it's clicked...
      gate.shut();                  // shut the gate...
      ajax({
         data: getFormData(),       // ...same as before...
         url: 'http://someWebService',
         success: function(results) {
            if (results.hasErrors) {
               showErrors(results);
               gate.open();  // Open the gate
                             // so they can try again.
            }
         }
      });
   }));

We dropped this in, and it worked pretty much as expected: you can click all you want, and the update will only fire once; when the update completes, it’ll turn back on.

The downside? Since it doesn’t disable the link, the user has no idea what’s going on. In fact, since the closed-gate function finishes so quickly, it seems like the button’s not doing anything at all, which might even make it look broken.

So we chucked it, and hid the links instead. It’s not as nifty, and it’s not reusable, but it’s clear enough for both end-users and programmers who don’t grok higher-order functions. Even when you have a nice, flexible language, and can make a sweet little hack, it doesn’t mean the dumb approach won’t sometimes win out.

Array.new(5) { 'yo' }
# gives:
["yo", "yo", "yo", "yo", "yo"]

# Closures, too!
i = 0
Array.new(4) { i = i + 1 }
# gives:
[1, 2, 3, 4]

I tried to recreate this in JavaScript:

new Array(5, function() { return "drip"; });
// gives:
[5, function() {
    return "drip";
}]

Oops! I guess the Array constructor works differently in JavaScript. No worries, we can just call map on the new array.

new Array(5).map(function() { return "drip"; });
// gives:
[, , , , ]

…um, what? Shouldn’t that be ["drip", "drip", "drip", "drip", "drip"]? If I call new Array(3), I should get a brand new array, with 3 slots, all set to undefined; and I should be able to map over it, and fill up the array.

Let’s see what its elements are:

var array = new Array(5);
array[0]; // undefined, as expected
array[1]; // also undefined

So far, so good. What arguments are passed to the function?

function printAndDrip(arg) {
    print(arg);
    return "drip";
}
array.map(printAndDrip); // prints nothing, and returns [, , , , ]

It looks like the printAndDrip function is never being called, almost like the array has no contents.

Let’s try setting a value manually, then mapping:

array[2] = "hey there"; // [, , "hey there", , ], as expected
array.map(printAndDrip);
// prints "hey there", and returns [, , "drip", , ]

So, it only calls the function for values we’ve manually put there. Maybe map doesn’t call the function if the value of a slot is undefined? I know, I’m reaching here…

array = [1, undefined, 2];
array.map(printAndDrip);

/* prints:
1
undefined
2
then outputs:
["drip", "drip", "drip"]
*/

So it does call the function for undefined values! Then why didn’t it in our newly-created array?

This is when it hit me, and it’s a funny JavaScript fact that I always forget: JavaScript has fake arrays.

They’re actually closer to hash tables, whose keys are numbers. ["zero", "one"] is just syntax sugar: it creates an object with two properties, named 0 and 1; 0 points to “zero”, and 1 points to “one”.

// pretty much the same:
var arrayLiteral = ["zero", "one"];
var objectLiteral = { 0: "zero", 1: "one" };

Apparently, if you use the new Array(10) constructor, it creates an array with length 10, but with no named properties.

We can see the properties an object has with the hasOwnProperty method, so we can use that to test our hypothesis.

var emptyArray = new Array(10);
emptyArray.hasOwnProperty(0); // false
emptyArray.hasOwnProperty(1); // false

var fullArray = [1,2,3];
fullArray.hasOwnProperty(0); // true
fullArray.hasOwnProperty(1); // true
fullArray.hasOwnProperty(99); // false: gone past the end

So where does that leave us? Nowhere, really. At least I’m a little clearer about JavaScript’s fake arrays. Imitating Ruby’s Array constructor is pretty much out; it’s easy enough, though a bit unsatisfying, to hand-roll our own:

Array.filled = function(n, fn) {
    var array = [];
    while(n-- > 0) {
        array.push(fn());
    }
    return array;
}
Array.filled(5, function() { return "drip"; });
// gives:
["drip", "drip", "drip", "drip", "drip"]

Perhaps the folks working on the new JavaScript standards can put in a line-item about initializing Arrays with all the right numbered slots, and that’ll be unnecessary.

While writing this post, I used the JavaScript Shell 1.4 in FireFox 3.6.3 on Windows 7. I also redefined Array.prototype.toString to display JavaScript arrays the way you type them.

Problem: the default Array.prototype.toString hides any nested structure.

[1, 2, 3, 4, 5].toString(); //-> "1, 2, 3, 4, 5"
[1, 2, [3, 4], 5].toString(); //-> "1, 2, 3, 4, 5"

Solution: override Array.prototype.toString.

Array.prototype.toString = function() {
    return '[' + this.join(', ') + ']';
};

[1, 2, 3, 4, 5].toString(); //-> "[1, 2, 3, 4, 5]"
[1, 2, [3, 4], 5].toString(); //-> "[1, 2, [3, 4], 5]"

Firebug was apparently written for the Mac, because it uses Monaco all over the place. That would be very nice, but on Windows, a bold Monaco is a wider Monaco.  This makes the line number gutters uneven, and makes the screen flash when you scroll through text:

I finally got irritated enough to google it, and I found this post by Thomas Scholz (it’s in German, here’s Google’s translation).

The details: Firebug’s CSS files are located in its extension directory, which is probably someplace like this:

• Vista: C:\Users\{USERNAME}\AppData\Roaming\Mozilla\Firefox\Profiles\{alphanumerics}.default\extensions\firebug@software.joehewitt.com\skin\classic
• XP: C:\Documents and Settings\{USERNAME}\Application Data\Mozilla Firefox\Profiles\extensions\firebug@software.joehewitt.com\skin\classic

Search-and-replace the Monaco away, and restart Firefox.

I wanted a function to make saw-step sequences: (1 2 3 2 1 2 3 2 …). You give it the low bound, the high bound, and the step-size. For example:

• (saw-step 1 4 1) gives (1 2 3 4 3 2 1 2 3 4 3 ...)
• (saw-step 0 15 5) gives (0 5 10 15 10 5 0 5 ...)
• (saw-step 0 5 2) gives (0 2 4 5 3 1 0 2 4 5 ...)

I’ve coded this kind of thing up in ruby, javascript, or java a dozen times, though it’s usually inside a loop, not returning a list. Something like this:

var min = 3;
var max = 7;
var step = 2;

var n = min;
while(shouldContinue()) {
    doSomethingWith(n);
    n += step;
    if (n+step > max || n-step < min) {
        step *= -1;  // turn around
    }
}

My first try in clojure took a similar tack. I never got it right, but it was something like this:

(defn saw-step
  [min max step-size]
    (let [step (ref step-size)]
      (iterate
       (fn [x]
         (if (or ( min (- x @step)))
           (dosync (alter step -)))
         (+ @step x))
         min)))

It’s a disaster — the parentheses don’t even match — but you get the gist. I was trying to cram the same imperative algorithm into clojure: keep some mutable state, add step to it, and when you reach the edges, mutate step to change direction. I kept getting bugs where it would go one step beyond the edge, or it would start working its way back from one edge, only to turn around again, and bounce against the edge forever.

I gave up and went to bed, but a few days later, I had better luck.

(defn saw-step
  [min max step]
     (cycle
      (into (vec (range min max step)) ; vec, so (into) adds to end
	    (for [x
		  (iterate #(- % step) max)
		  :while (> x min)] x))))

The first not-entirely-wrong step I made was to try breaking the list of numbers I wanted into two parts: the going-up numbers, and the coming-down numbers. (0 2 4 5 3 1) is just (0 2 4) + (5 3 1). The (range min max step) part gives you the going-ups, and the (for [x (iterate ...) stuff is the going-downs, as a list comprehension.

(One mistake I made was trying (range max min step) for the going-downs, which yields an empty list; another was using (iterate dec max), which never ends, because it keeps decrementing into the negatives. I found my way out with the list comprehension, but I bet there’s a better way.)

Once you have those two lists, you can use into to add each item from the second list to the first, giving you (0 2 4 5 3 1). That goes into cycle for a lazy, infinite sequence.

The solution’s not too bad: a saw-step is a cycle of the going-ups, followed by the going-downs. The code looks about that way.

(It occurred to me after that I could always use a default step of 1, and pipe the result through a scaling map. That would give me the bounds I wanted, with the extra benefit of evenly-spaced steps. Maybe I’ll remove step later.)

Alan Perlis said, “A language that doesn’t affect the way you think about programming, is not worth knowing.” He also said, “The only difference(!) between Shakespeare and you was the size of his idiom list – not the size of his vocabulary.”  Clojure’s changing my mind, a bit at a time.

UPDATE: it turns out the technique described below is known as debouncing. What an awesome name!

My last job was for a company that made case-management software. With this software, you could track all kinds of data about your case: you could categorize it, sub-categorize it, say where and when it happened, note whether it was still open, track who was responsible…all kinds of stuff, great for data fiends.

One of our customers’ favorite features was the reports, and they were pretty spiffin’. But, not being ones to rest on our laurels, we were adding pivot-table reports, so you could count the number of cases, grouped by any criteria you wanted. The input screen let the customer pick their pivot criterion, and which criteria they wanted as columns, for sub-counts. We struggled to name these UI fields — something lucid, something explanatory, something evocative — something to make them understand what kind of report they were in for. After a while, we decided to just show them: when they changed their pivot criterion, we’d run some javascript to render a skeleton report, same as the real report, but minus the data. It would save them time, and save our servers.

The javascript was pretty involved. It had to generate the same HTML as we did for the pivot table, which meant it had to know (or make up) values for each criterion, like all the case categories and sub-categories, and which sub-categories belonged to which categories. And we let the customers pivot on up to THREE, count ‘em, different criteria. And it had to happen each time the user picked different pivot criteria. It took a few tricks, but we got it working. It ran slowly, maybe a few seconds, but it was quick enough, probably, especially once we threw in a little “please wait” spinner. Then we realized we needed to re-render whenever the window resized.

No biggie, I thought, and I quickly added window.onResize(reportPreview);. It worked great, except it re-rendered the report with every pixel-wide movement of the mouse, as the window was dragged to new widths and heights. Calling a function, one that runs for a few seconds, a hundred times in the time it took to widen the browser an inch, meant a locked browser. It meant “time to get more coffee,” and after, “time to fix the bug.”

I knew we could delay calling reportPreview, but we only wanted to delay it when the window was being resized — when the user changed the columns, there was no reason to wait. I was sure window.setTimeout() would do what we needed, but I didn’t want to muck up reportPreview() with it.

I’d been reading The Little Schemer lately, and noticing some striking similarities between javascript and scheme: first-class functions, and higher-order functions that take functions as arguments, and return other functions as values. It was fun reading, with its strange teacher-student dialog style. The material was better than brainteasers, and I knew it would make me a better programmer down the road, but I didn’t think of it as relevant to the day-job, as…applicable.

Then I realized higher-order functions were a way out of this. I could write a function, delay, that would wrap one long-running, slow-poke function in another function: an intermediary that you could call as many times a second as you wanted, but it would only call the slow-poke once things had settled down. delay would let us keep setTimeout out of reportPreview. Something like this:

function delay(millis, slowPoke) {
    var timeoutId = undefined;

    // This is the intermediary.  Call it lots, it won't hurt.
    return function() {
        if (timeoutId) {  // If we're waiting...
            clearTimeout(timeoutId); // re-start the clock.
        }
        timeoutId = window.setTimeout(slowPoke, millis);
    }
}

The first time you call the intermediary, it tells the window to call slowPoke after a bit, but every time you call it after that, it starts the clock over. It’s like when you’re in a five-minute time-out, and you start acting up after only three, so your mom says “Ok, buster, another five minutes.”

var fiveMinutes = 5 * 60 * 1000;
var screamAndShout = delay(fiveMinutes, function() {
    getBackToPlaying();
});

screamAndShout(); // Aw nuts, I'm in time-out.

// I'll be good for as long as I can, but...
screamAndShout(); // dang, five MORE minutes!

Once delay was in place, running reportPreview when the window was resized was no problem.

function reportPreview() {
    // recursion, DOM manipulation, insanity...
}
columnPicker.onChange(reportPreview);
window.onResize(delay(100, reportPreview));

After testing, we found that delaying it for 100 milliseconds made all the difference in the world.

Do you have a war story? Share it, and start the healing: tell a short one in the comments, or link to a longer one on your own damn blog.