Spinach Pasta

Spinach pasta is fun to make if you like doing a lot of work! Also, it’s fun to eat. And green.

  • 8 ounces fresh spinach
  • 12 oz all purpose flour
  • 3 eggs

First, prepare the spinach. Prepare water for shocking: a bowl of ice water will do. Boil several quarts of water, immerse spinach, bring (back) to a boil, then, using tongs, remove spinach and add to ice water. When the spinach is cold, drain.

Squeeze the spinach with your hands until it is quite dry. You should have less than four ounces. Coarsely chop and add to a food processor with the flour and eggs. Pulse until it comes together.

On a floured counter, knead 5-10 minutes until smooth and elastic. Put in a plastic bag and refrigerate for at least 30 minutes up to 24 hours.

Roll and cut as per pasta machine directions or roll and cut by hand. This recipe makes more than you think. Serves 4 to 6.



Kale and Sausage Pasta, Mojito

I’m going to kick off the summer CSA section with a recipe that I’ve made a few times this spring but that really got improved with the mint I got in my first CSA box. Also, this is recipe for celebration and it’s really great to have a first box from a good CSA run by good people. We signed up for a full box from Lovefood. So far the name is apt. Their mint is fantastically flavorful.


  • 3 sprigs mint
  • 3 oz white rum
  • 1 oz to 2 oz simple syrup
  • 1.5 oz fresh lime juice

Put two sprigs of mint in a highball glass and gently bruise. Add rum, lime juice, and syrup. Stir. Add ice cubes. Stir. Garnish with the third sprig of mint.

Kale and Sausage Pasta

This is a family favorite adapted (if it differs at all, I’ve made it so many times I don’t look at the recipe book any more) from Alice Waters’ wonderful The Art of Simple Food. This is almost always one of the kids favorites; it’s pretty quick to make; it’s even pretty good cold (pack lunch).

I think the key to this recipe (most recipes) is to make sure you get the good stuff. That means pork sausage with real flavor. Our favorite is Willow Creek, available at the Dane County Farmer’s Market and at the Coop.

Use real Italian Parmigiano-Reggiano cheese. The key difference between this and substitutes (there are some good ones in Wisconsin!) is the way it melts and dissolves into the dish.

In a cast iron dutch oven, brown in two batches:

Remove the sausage to a bowl and drain excess fat. Fry, scraping up the browned bits of sausage:

  • One large yellow onion, diced fine


  • 1 1/2 t red pepper flakes
  • 1/2 t black pepper
  • salt to taste

Let the onion cook until it’s softened and beginning to brown, 10 minutes. Add:

  • 2 bunches kale, rinsed, drained, stemmed and chopped

Cook to soften (10 minutes). Add:

  • 4 oz Parmigiano-Reggiano cheese, grated fine on a microplane

Add salt and pepper as necessary. Add:

  • One pound chunky pasta (gemelli), cooked al dente in salted water and drained.

If you cook the pasta al dente and mix everything together hot the pasta will absorb some of the liquid (but this is a pretty dry dish).

I like this topped with more cheese and some Crystal hot sauce.

Closures in Node.js with Async.js

I recently had a chance to use closures as part of solving a real world problem. The elegance of the approach helped to improve my attitude about working in JavaScript. Don’t get me wrong – Node.js’s asynchronous approach is a thing of beauty. But there’s a lot of ugliness in JavaScript as well and this is the first thing besides Node.js itself that struck me as particularly beautiful.

The problem is this: I have a list of questions, each of which has an associated policy. For a particular user, I need to check the policy to see if it’s appropriate to ask the question for this user.

So, policy evaluation is per user and per question. However, my API offers the ability to get all relevant questions for a particular user. So every time, I need to evaluate policy for a set of questions. Each policy evaluation may involve an async call to the data store. The policy evaluation function for a particular user and question returns a boolean, like this:

To minimize impact on the data store, I want to do these calls in series, a functionality provided by the javascript Async.js library through async.filterSeries. However, the iterator argument to filterSeries takes a single argument (i.e. the question). I could work around this by making the arr argument an array of objects with both a user and a question but that’s inefficient and inelegant.

A much more elegant solution is to use closures to produce just the iterator function I want: one for a particular user.

Now, I can call this function to produce the iterator when I need it:

UUID Uniqueness

A little while ago, someone asked me about collisions in UUIDs:

Any idea what kind of guarantees of uniqueness these tools argue/provide? For example if I use them to generate 10**15 IDs over 10 years, what is the probability that I will get a collision? Do they have a reference to the algorithm they use?

Well, in terms of financial guarantees, none. If you use this free software and it doesn’t do what you expect, you get back what you paid for it.

However, the proposed standard does “guarantee” uniqueness; this is clearly part of the design. An implementation which follows this specification has a component which is derived from the MAC address of the generating host for what is called “the spatially unique node identifier”. Other components include the time with 100 ns resolution, and a counter, which is incremented each time a UUID is generated and set to a random value when the counter becomes unavailable.

My envelope here shows that to generate 10**15 UUIDs over ten years (on a single machine), you’d have to generate another one every 315 ns or so (I’ve got 315.36*10**15 ns in ten years). Since this is close to the clock resolution, you might be relying on the counter mechanism, perhaps quite a bit at times depending on the characteristics of the UUID request arrival process. You’d have to have a pretty big bit bucket – you’d be generating nearly 50 MB/s for ten years, over 14 petabytes total, at 128 bits per identifier.

If the machine crashes, the 14 bit counter gets set to a random value. Suppose the clock also gets set backwards (overlapping a period where UUIDs were generated). If the implementation followed the spec, the chance of the counter repeating itself at the exact time the clock repeats itself is pretty small (i.e. effectively 0). One could calculate a meaningless, ridiculously small positive probability by making assumptions about the rate at which clock resets occur, and the rate at which requests occur, using standard approximations of the general birthday problem. Or not.

Frankly, the most likely source of failure would be an implementation interaction error such as: the source for the random number that the counter uses isn’t very random (i.e. 2 bits instead of 14) or the clock really has a resolution of 1 second, but the implementation relies on it being much finer. The implementation is simple and designed to be fast; it’s not so likely that the implementation would be wrong as that assumptions made in the implementation are invalidated as the underlying system changes.

There’s a political / privacy issue also with the use of standard UUIDs; the MAC address of the generating host is essentially included verbatim. So, if you drop a UUID in the course of committing a crime, this may be used in the investigation or case against you. That’s the privacy part; the political part is the public outcry regarding the privacy part. The specification addresses these concerns by proposing alternatives to the MAC address based UUID.

Thinking ahead, the UUID clock field will rollover around 3400 A.D.

Blog at WordPress.com.

Up ↑