Today, the boy had his very first soccer practice. Loved it. (I think he enjoyed it, too.)

If you're so inclined, you can view the full set on Flickr.

This video's certainly made the rounds online, but it's still one of my favorites: Richard Feynman trying to explain, in layman's terms, how magnets work:

Because of magic, kid. Just accept it.

So the other day, I ran into a situation in which I was calling a function recursively in JavaScript and needed to reduce its complexity. (And don't act like this doesn't happen to you constantly, too.) As it happened, the function was just performing a calculation, taking a number and returning a number, and because of the way the function was being used, the overwhelming majority of the calculations were redundant; in a hundred calls, maybe 90 of them would've been calculated at least once before. Then I remembered to memoize.

What's Memoization?

Memoization is just a computer-sciencey term that means remembering a previously calculated result to avoid doing unecessary work. For example, if your function's purpose in life is just to add two numbers:

def add(a, b)
  a + b
end

... then no matter how many times you call it with 5 and 3, the result will always-and-forever be exactly the same:

> add(5, 3)
=> 8

Memoization just acknowledges that fact, and helps us play nicely with our resources.

Memoization in JavaScript

In JavaScript, because functions are first-class objects, memoization is pretty elegant: you just graft an object-literal onto your function object, and use that property to hang onto your calculations, returning early whenever you can. If you happened to be faced with calculating a Fibonacci number in JavaScript, your naïve, brute-force fib() function might look something like this:

function fib(n) {
  if (n < 2) return n;
  return fib(n - 1) + fib(n - 2);
}

> fib(20)
6765

On the surface, this might seem fine — until you're faced with a larger number:

> fib(1000)

... in which case, you should just go grab a sandwich, or maybe a nap, because it's going to be a while. On my hefty little MacBook Pro, my brute-force fib(1000) example ran for well over an hour until I got tired of waiting and killed it. Let's have a look at how memoizing helps.

Here's a new fib() function with memoization onboard:

function fib(n) {
  if (n < 2) return n;
  if (!fib.cache) fib.cache = {};
  if (fib.cache[n]) return fib.cache[n];
  return fib.cache[n] = fib(n - 1) + fib(n - 2);
}

In this extended version, we just:

• Add a cache property onto the function, to store intermediate results

• If the calculation's been done before, return the stored value

• Otherwise, calculate (and then store) the new value

Running fib(20) here, we see that the number of calculations was reduced from 10945 to just 19; fib(1000) returns in about 4 ms. Not a bad improvement.

And while that cache property's still squatting some memory, and you'll need to be mindful of that, you've solved the immediate problem by bringing your complexity down to something more linear.

But then that got me thinking: How would you do it in Ruby?

Memoization in Ruby

In Ruby, the concept is similar: make a hash (or more specifically, a Hash) and shove values into it, keyed by argument, as you go:

@cache = {}

def fib(n)
  return n if n < 2
  return @cache[n] if @cache[n]
  return @cache[n] = fib(n - 1) + fib(n - 2)
end

It's a teeny bit different, syntactically, since functions (or really methods) aren't first-class objects in Ruby (so we have to use an instance variable instead of a grafted-on property), but the gist is the same:

> fib(20)
=> 6765

> @cache.size
=> 19

There are some minor variations you'll see online (using blocks, etc.), but that's pretty much it: if you're memoizing in Ruby, you're probably using a Hash and an instance variable somewhere.

Happy CPU-friendly coding!

Messing around with the boys' wooden trains and Adobe Premiere over a lazy weekend.

I'm slowly working my way through The Audio Programming Book (obtained on a recent trip to MIT), and on reaching the section dealing with plotting audio envelopes, I ran into a snag I figured others might run into as well. I'd downloaded and installed gnuplot, and when I ran the command to plot my file:

plot "envelope.txt" with lines

... well, nothing happened.

So Here's What I Did

This fix assumes you've got XCode installed, which I do (version 4.6); I'm not sure if you actually need Xcode (although from this thread, it looks like you might), but I do, and these steps worked for me.

Here's how I made this work (presumably in order):

• Open Terminal (Applications » Utilities » Terminal)

• At the command line, accept the XCode Build terms of use:

  sudo xcodebuild -license
  

• Download and install Aquaterm, which you'll use to do the actual plotting.

• Download the GNUPlot source.

• Build it:

  cd ~/Downloads/gnuplot-4.6.1/
  ./configure
  make
  sudo make install
  

At this point you should have everything set up. Now, let's get to plotting!

• Get yourself a breakpoint file (here's the one from the book). I'll assume you've downloaded mine and then also assume it's in your Downloads folder. Back in Terminal, change to your Downloads folder:

  cd ~/Downloads
  

• Then run gnuplot:

  gnuplot
  

• At the gnuplot> prompt (again, assuming envelope.txt is in your current directory), type:

  plot "envelope.txt" with lines
  

• Switch to Aquaterm (annoyingly, this doesn't seem to happen automatically). You should see this beautiful little graph:

Hope it helps! Good luck, fellow student of audio geekery.

In the wake of the Instagram terms-of-use kerfuffle, the Facebook acquisition (I'm not a big Facebook fan), and just being somewhat irritated at all my photos being cropped in ways I'd rather them not be, I've gone back to using Flickr exclusively. Their fantastic iOS app made the switch even easier. Some recent pics, posted using my Jekyll plug-in for Flickr:

Follow me there! Or here, if that works better for ya.

This is a couple of months old, too — it's a not-so-great photo of me presenting my new music platform (powered by Rhapsody, yo!) at MIT, part of the annual Music Hackday Boston thrown by the EchoNest. There were about 300 developers there, about a third of whom were MIT computer-science students, and I think it's fair to say that I've never been so nervous in all my life. I taught for a couple of years in college, too, but that was nothing compared to this.

I could barely speak — zero saliva, spotlit and sweating — and while I vaguely remember all the right words coming out of my mouth and in generally the right order, and according colleagues I did fine, I don't remember much of anything else. In the months since, I've started to warm to the idea of doing more public speaking in this new role and beyond, but man, I still have a lot of practicing to do.

Not long after giving this talk, I went for a walk around the MIT campus, stopping by the legendary Media Lab and then stumbling on the unbelievably amazing and awesome MIT Press Bookstore — if ever there was a bookstore crafted just for me, this would be the place (pic). On my way back to the hackday, new books in hand and thrilled all the history and prestige of the whole thing, I managed to get myself stuck inside a revolving door.

This is a bit old, but I unearthed it over the weekend while sifting through our hundred-thousand-odd photos and videos, and it gave me a giggle.

I have a huge weakness for this sort of thing, so apologies if it isn't quite your brand of humor.

We went simple this year — no traveling, no guests, just our own little nuclear fam, minus a snoozing three-month-old. Here's a classy little animated GIF for your enjoyment.

Happy Holidays, dear visitor.

Years ago, I worked with a guy who was fond of coming over to my desk with his laptop and asking, "Can I get your opinion on this?" To which, as someone who almost always prefers giving his opinion to doing actual work, I'd invariably (and enthusiastically) oblige.

Equally invariably, his work would look great — well organized, neatly designed, on the surface of things, perfectly fine. But too often, the effect of some tiny decision he'd made along the way would reveal itself in some simple scenario or other, the intended experience would start to bend or just break, and I'd sort of lean back and say something like, "Hm. Well, what about when someone wants to do x?"

"Yeah, I thought about that", he'd say, "but then I couldn't figure out where to put this other thing, and then everything got all complicated, so I figured what the heck, it's probably fine."

"Yeah," I'd say, unconvinced. "Hm."

"Yeah. Okay, thanks. I just needed to talk through it."

"Oh, sure. No problem."

And then we'd ship his stuff, and life would go on. Nobody ever died, but it always sort of irked me how basically okay he was — how basically okay a lot of people are — with delivering work that not only fails a two-minute sanity check, but regularly ends up causing downstream problems of surprising, often unresolvable, complexity.

This sort of thing happens all the time in software, as often in programming as in design. I'm often reminded of this quote from David Heinemeier Hanssen, creator of Ruby on Rails, in Founders at Work, describing how hard it was to undo an early database-design decision he'd made while putting together Basecamp:

One of the technical mistakes we made early on was that we had this notion that Basecamp was for creative services firms. Set up like that, you have a firm and you have a client, so it's a one-to-one relationship. That assumption went very deep. For instance, in the database there's a client ID and a firm ID, and now that people were using it, you'd have setups where people wanted two firms. So now what did we do? Basecamp simply couldn't do that. And that assumption was so deep at the roots of the system that it took us about a year and a half to fix, which was not a good thing.

A year and a half.

Of course, we all make these kinds of mistakes, and to DHH's credit, the multi-firm requirement clearly came later. I'm sure if someone had said, "Well, what about when someone wants to have two firms, David?" he'd have acknowledged the possibiltity, added another table, tweaked a few lines, and moved on to build the mountain on top of that assumption instead. These things happen, not because people are idiots, but because software is hard.

But when you're in the design phase and someone points out a problem and you deliver your flawed design anyway because you don't feel like thinking about it anymore, that's a problem. You should not be okay with that. Being okay with "probably fine" when probably fine demonstrably fails, sucks.

Just the other day, I stumbled onto an API-development forum somewhere and observed a conversation in which someone was designing a new service and wanted to know what the others thought of its RESTfulness. I'm going on memory here, but it went something like this.

"Looks okay," someone said. "But does the part on the right really belong to the part on the left, or is the left thing really owned by the right thing?"

"Well, neither," the first guy said.

"Then should the right thing maybe go on the left, and the left thing be passed as a parameter?"

"I don't think so, because doesn't a parameter imply it's optional?"

"No."

"I'm pretty sure it does."

"Google searches are query parameters, and they aren't optional. But even so, you can imagine a world in which that particular parameter really would be optional; you might need it today, but it's totally possible that tomorrow your users would want a version that didn't require it."

"Maybe. But you know, not today."

"Also, it's a POST — but what's getting posted?""

"Nothing," he said. "But GETs are idempotent, and this service returns something new with every call."

— and then a momentary, impassioned-but-civil RESTful debate, and then finally —

"Yeah. Well, it's probably fine. Thanks."

And of course, the second guy was totally me.

I've been accused, deservingly, of the bad kind of perfectionism in my work over the years — I wrestle with it constantly, actually. I'll spend days making CSS tweaks when I should be writing code just to get (what I think is) the perfect gradient, weeks on an API to achieve the right level of expressiveness. And I've been blindsided by surprise requirements, too. It happens to all of us.

But when someone points out a real problem with my stuff, I listen — not because I'm some virtuous a-hole, but because I've had to pay dearly for my own design mistakes before, and it sucks.

Laziness sucks — don't be that guy. It might take a little effort, and you might have to throw some work away, but there's no better feeling as a developer than when some random requirement from a wacky product manager flies at you from out of nowhere that you had the forethought, and taken the time and extra steps, to prepare for. And there's nothing worse than knowing some corner you knowingly cut two years ago is making your colleagues' lives, if not your own, a living hell.

Yesterday I wrote a (probably too) long-winded post about getting going with Jekyll, the excellent blog platform by Tom Preston-Werner, for which I'm currently writing a book. And I introduced a couple of simple Jekyll plugins, one for embedding Flickr photos:

{% flickr_photo 7996362013 %}

... which gets you something like this:

...and one for SoundCloud sounds:

{% soundcloud_sound 17542146 %}

... which gets you something like this:

Today, I'm going to share a couple of additional Jekyll-related projects you'll hopefully find as useful as I would've back when I needed them.

One of the things I found most frustrating when I got started with Jekyll was the complete lack of simple starter kits. The source of Jekyll proper was completely open, but that source was of the app, not for a Jekyll-powered site. What I needed was just enough code to be able to see Jekyll run, see what it did, and understand what I needed to do to extend it. In my post I mentioned Octopress, which I discovered along the way and which is great, if a turnkey Jekyll-powered site is what you're after, but I wasn't. I wanted something super-simple, super-bare-bones — something that showed me where to put my posts, how to write them, where the CSS went, what this Liquid stuff was, and how the whole thing worked in general.

Unbelievably, I found nothing. Which of course just might've been incompetent Googling on my part. Nevertheless, I weant ahead and came up with something of my own. Two things, actually. Here's how they work.

Starter Kit #1: Just the Bones

The first kit is about as basic as it comes — just a home page and one very simple, very boring post.

The important thing here is that you get the standard directory structure, a home page showing how Jekyll renders its site object (which contains all of your posts), a configuration file in the right place, CSS and JS placeholders, a shared header and foooter and a Jekyll-appropriate .gitignore. Here's what the directory structure looks like, for example:

... and the contents of index.html, just to give you a sense of things:

---
---

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" href="/css/site.css">
    <script src="/js/site.js"></script>
    <title>My Blog</title>
</head>
<body>
    <header>
        {% include header.html %}
    </header>
    <div class="container">
        {% for post in site.posts %}
            <article>
                <h1><a href="{{ site.base_url }}{{ post.url }}">{{ post.title }}</a></h1>
                <p>{{ post.date | date_to_string }}</p>
                <p>{{ post.content }}</p>
            </article>
        {% endfor %}
    </div>
    <footer>
        {% include footer.html %}
    </footer>
</body>
</html>

To make a new post, just follow Jekyll's convention of naming the file using the date, a URL-friendly name, and an extension of .markdown (if indeed you want to use Markdown, which is totally optional):

touch _posts/2012-10-09-my-second-post.markdown

You'll find the project up on Github. As long as you've installed git (which, if you haven't, you can get here), open a Terminal window, navigate to wherever you'd like to create your new blog, and then:

cd ~/Documents
git clone git@github.com:cnunciato/jekyll-starter.git
cd jekyll-starter
jekyll --server

... and your new Jekyll site should be up and running at http://localhost:5000. If you have any troubles, feel free to post an issue, or if you'd like to contribute, send me a pull request.

Starter Kit #2: Jekyll + Bootstrap

To use the excellent Twitter Bootstrap for layout and general widgetry (as I did, and which I heartily recommend), I've got a starter kit for that, too. I'll post on that one tomorrow.

A while back, I heard about this thing called Jekyll. Apparently, it was a "blog-aware static-site generator," was open-source, and had something to do with Ruby, blogging, Github, and Tom Preston-Werner. Programmers seemed to like it (many mentions on Hacker News), so I figured, since I'd managed, with so much effort and so many times over the years, neither to find nor create a satisfying blog platform of my own, that I should maybe sit down and give it a try.

My biggest gripe — well, I have two of them. (Actually I have dozens of gripes, but I digress.) As a non-programming person who wants to set up a blog, your only real option is to use one of the many hosted services: your Bloggers, your Wordpresses, your Tumblrs, etc. My wife's been paying for TypePad for years, and has a lovely (if much too rarely updated) blog, but every time she sits down to craft a post, it's rage against the machine: the WYSIWYG editor is crap, won't put her pictures where she wants them, things start wrapping all stupidly, or the links all break — it's always something, and I usually have to jump in and fix things at some point, if only to bring her blood pressure back down to normal human levels. Ultimately it works, so we stay with it, but I'd be lying if I said we didn't hand over our eight bucks every month without at least some grudging gnashing of teeth. At least for my part, because as a programmer, I know it should be lot easier than it is.

If you do know something about programming (even if it's only a little HTML), you might not realize you can actually craft everything yourself; even the faciest of platforms has only one job, and that's to deliver HTML to a browser. If you can write this much HTML:

<h2>Good Morning, Readers!</h2>s
<h3>October 8, 2012</h3>
<p>A funny thing happened to me on the way to work this morning...</p>

... then you can build and manage your own blog. It doesn't take much. Just about anyone can learn enough HTML in an afternoon to build a basic blog.

But then of course, once you know a bit of programming, you tend to want to know more, and everyone eventually wants at least something they've seen somewhere else on the Web: you want to upload pictures from your phone, you want to set up comments, you want tagging, you want RSS, take your pick. Basic HTML certainly works, but only gets you so far.

Since I'm a programmer, I've generally opted to roll my own. I started ten years ago with Classic ASP and an Access database, graduated to C# and SQL Express, and eventually settled on ColdFusion, also with SQL Express (and don't laugh, by the way — CF is definitely weird, but incredibly flexible and productive). But the pain of building and managing a homegrown, relatively feature-rich content-management/publishing system just got to be too much for me. When I was 25, I had all the time in the world to muse on database schemas and to craft obscure, intricate features (however cool I might've thought they were at the time), but today, with three kids and a career, free time is scarcer than diamonds. If I'm lucky, I can steal an hour or so in the morning to write. But rarely more. And I'm usually not that lucky.

All this is to say that my relationship with blogging over the years has been of the on-again, off-again variety — mostly off-again, because I feel about blogging the way I feel about coffee: it shouldn't be that hard. Coffee is ground-up, roasted beans with hot water filtered through them; you don't need a $3,000 machine to make it. (Although feel free to click that affiliate link if you disagree.) That's why I love my Chemex: it acknowledges that essential simplicity, and gives you suitable (and suitably priced) tool for the job.

So when I heard about Jekyll, and how it seemed to have grown out of that same minimalist ethos, I was interested.

Unfortunately (at least for me), Jekyll's how-to documentation is split into two general categories:

• The official documentation, which is nicely contained in the Jekyll wiki but not nearly complete enough to get started from square one, and

• Spread all over the freaking Internet, mostly on random programmers' Jekyll-based blogs in the form of very specific, sparsely described code snippets that end up raising more questions than they answer.

After that initial dive-in, and an investment of several hours, I still had one rather problematic question: How does this goddamn thing work?

Yes, I understood all of the words in the documentation, and yes, I realized all I had to do was run jekyll and some sort of magic happened and out popped a simple, static Web site, which sounded awesome. And I could see all the configuration options and Liquid template extensions, yes. All that looked great. But where did the configuration file go? Did I have to create one myself, or was there some default I could get started with? What, exactly, is Liquid? And I see this stuff about categories, but what about tagging? I had no idea how to get started, so with time as scarce as it was, I set it down, hoped to come back to it, didn't, and then lost interest. At one point, I discovered Octopress, which is based on Jekyll and which seemed rather nice, but which I discovered after another investment of time also suffered from inadequate documentation, ironic complexity, and lots of bugs, so with yet another wistful sigh, I git rmed that project, too, and hoped to come back to the whole thing again for another try someday.

Which, after some time away, I did. And somehow, through the magic of random Web browsing coupled with pure experimentation and trial-and-error (including the reading of many error messages), I came to realize that the answer to that one, basic question I'd had was simply this:

Jekyll is a Ruby script that, when you run it, reads every file of your site and pulls it all into one big Ruby object called site. If a file contains some special YAML at the top of it, Jekyll will use that YAML to stick some properties onto the site object for you (e.g., some tags, a date, an arbitrary Ruby object of your own creation, whatever you like). Then, once all the files have been read and the site object created, Jekyll will render the site object in a directory called _site by looping through all of your posts (which you put into a folder called _posts) using the HTML templates and Liquid expressions you provide. If you'd like Jekyll to do something more than just that, you can create a Jekyll plugin by writing a little Ruby code and putting it into the _plugins folder.

That's it. That's all I needed to know, but for some reason, nobody explains it that way. Jekyll builds one big Ruby object and then spits it back out as static HTML. Finally, it made sense. And I was off and running — and this blog is the result.

So, a couple of things to take away from this experience:

• Somebody needs to write a book on Jekyll. I've decided that person might as well be me, so I've started writing it and am well on my way. You can follow the progress of my Jekyll book on LeanPub.

• Plugins are really easy to write, provided you know the magic words. I've written and open-sourced a few plugins of my own already that I also use on this site: one for embedding Flickr photos, one for SoundCloud sounds and a couple of others for working with video clips.

• Jekyll is, at its core, so simple that even non-programmers can learn to use it with a teeny bit of effort. This is one of the major goals of the book, too — helping aspiring, technically inclined bloggers use Jekyll and other open-source goodies to seize the means of production, as it were.

Jekyll is the publishing tool I wish I'd had in 2001. I hope to be able to help a lot more people start using it.

As you'll no doubt derive from nearby posts, we gave birth to a daughter a couple of weeks ago — our third offspring in as many years (and likely, i.e., surgically, our last). I took three weeks' paternity leave, roughly half my annual vacation, and could easily take more, were it not for the mountain of work that'll surely be waiting for me when I go back.

A few things I've learned so far:

• I could get seriously fat being around all this food all day long.

• Unless you constantly clean up after yourself and everyone else, your house will go to complete shit within the span of a single day.

• If you spend all your time cleaning up, you won't spend any with your kids, so yeah — good luck with that.

• Being able to support one stay-at-home parent is a gift, but to do the whole thing right, it's really better with two, for so many reasons. Might sound unrealistic — but then again, depending on your real (i.e., actual/practical, as opposed to imagined/self-imposed) situation, maybe it isn't. I know for us, it's a conceivable option — one with clear tradeoffs, but still possible.

• Boys in particular need time and attention. And challenge. Otherwise, they will explode.

• Earplugs, dude. Sometimes you just need to take some edge off the goddamn noise.

• Time-boxing helps: breakfast between 7 and 8, then we play, then do puzzles, then lunch, then naptime, then a snack, and so on. Structure is better for everyone, including you. You don't have to hit all the marks every time, though; just having the time slots there for use helps to ground things in general and keep everyone from going nuts.

• The stresses of work seem plainly ridiculous when you're on vacation, such that ultimately you realize most of it just doesn't freaking matter. I love my work, love what I do, but it's not curing cancer, and it sometimes helps to be reminded of that.

• Grocery carts are unimaginably filthy. If you must touch one, be sure to sanitize first, lest you space out momentarily and raise your fingers to your mouth, delivering a payload of Streptococcus pyogenes on the very day your wife goes into labor, leading immediately to a nasty case of strep throat and then, secondarily and even better, to a life-threatening peritonsillar abscess that's relieved by draining (a traumatic procedure itself that no man should be forced to endure) but which ultimately necessitates a tonsillectomy. I'm just saying, it happens.

• Naps are for you, too. Take them while you can.

• Speaking of which, no matter what, whatever work needs to be done in your neighborhood, be it lawn-mowing, gas-powered leaf-blowing or even jackhammering, it will unfailingly commence the moment you put your kids down for a nap. Behold, I'm not even kidding — as I sit here writing this, my kids in bed, this is happening right out front:

More as they come to me.

Ironic, sure, but hey — it works.

This week, the boys got to know their new baby sister. And in addition to winning a bout with strep throat (and some rather traumatic oral surgery — I have photos of this, too, but I'll spare you; they're gross), I learned a little bit more just how hard it really is to be home with the kids all day long.

Respect, woman.

Actually it's not David Shields — it's a couple of other writers he quotes in his book, Reality Hunger, which I've been ambling through (and enjoying) on paternity leave — but it's apt, on the characteristics of the lyric essay, a form I've been messing around with lately myself:

The lyric essay doesn't expound, is suggestive rather than exhaustive, depends on gaps, may merely mention. It might move by association, leaping from one path of thought to another by way of imagery or connotation, advancing by juxtaposition or sidewinding poetic logic. It often accretes by fragments, taking shape mosaically, its import visible only when one stands back and sees it whole. It partakes of the poem in its density and shapeliness, its distillation of ideas and musicality of language, and partakes of the essay in its weight, its overt desire to engage with facts, melding its allegiance to the actual with its passion for imaginative form. It gives primacy to artfulness over the conveying of information, forsaking narrative line, discursiveness, and the art of persuasion in favor of idiosyncratic meditation. Generally it's short, concise, and punchy, like a prose poem. It may, though, meander, making use of other genres when they serve its purpose, sampling the techniques of fiction, drama, journalism, song, and film. The stories it tells may be no more than metaphors. Or, storyless, it may spiral in on itself, circling the core of a single image or idea, without climax, without a paraphraseable theme. It stalks its subject but isn't content to merely explain or confess. Loyal to that original sense of "essay" as a test or a quest, an attempt at making sense, the lyric essay sets off on an uncharted course through interlocking webs of idea, circumstance, and language — a pursuit with no foreknown conclusion, an arrival that might still leave the writer questioning. While it's ruminative, it leaves pieces of experience undigested and tacit, inviting the reader's participatory interpretation. Its voice, spoken from a privacy that we overhear and enter, has the intimacy we've come to expect in the personal essay, yet in the lyric essay the voice is often more reticent, almost coy, aware of the compliment it pays the reader by dint of understatement. Perhaps we're drawn to the lyric now because it seems less possible and rewarding to approach through the front door, through the myth of objectivity. Similitude often seems more revealing than verisimilitude. We turn to the writer to reconcoct meaning from the bombardments of experience: to shock, thrill, still the racket, and tether our attention.

And then:

"Essay" is a verb, not just a noun; "essaying" is a process.

Um, yeah. That.

If you're at all interesed in this kind of thing — narrative forms, fiction vs. nonfiction, montage, etc. — this is a fantastic book. I only hope it continues to hold up this well through the end.

Ladies and gentlemen, allow me to introduce the newset member of our little nucular family, Miss Rosemary Ruthanne Nunciato — born August 21 at a little past 10:00 PM.

Many more to come, of course.

PS: Three kids in three years! Holy shit!

I saw them perform this live in L.A. late last year (front row!), and it was amazing. Once I dig up the damn videos, I'll post a few of 'em here. Rivers doesn't quite have the voice to pull this off, or the right kind of voice, or whatever, but it's still fun, and since I don't have much else to say this morning, this is what you get. Enjoy, Internet person.

I've been on SoundCloud since first hearing about it a year or so ago, and always been a fan — although I've used it mainly for capturing sounds of my kids, which, of course, I happen to adore, but almost surely would bore you to death. But I've always loved the idea of moving bytes of sound over the generally-silent Web (one thing I like about working at Rhapsody), and occasionally I'll stop by the 'Cloud to see what's new and interesting.

Which is to say, holy shit, there's a lot happening on SoundCloud.

Like this — Hype Machine Radio, the podcast from the excellent music blog, which has apparently been happening for several months now, totally without my knowledge:

Good stuff.

Stumbled onto this gem via BoingBoing, which characterized it as presaging Heath Ledger's incomparable performance as the Joker. I see the similarities, but was much too enthralled by the sheer cringeworthiness of the interview to notice much else. It's 1979 and Waits is just 29 years old, clearly working out the details of his nascent persona.

A must-watch for Waits fans, of which I'm a big one. I watched it on my phone on the ride home yesterday, and I must've been making a scene with my giggling because when I reached my stop, a smiling old guy tapped me on the shoulder and said, "That was Tom Waits, right? I saw him in concert back way back when." I said I had too, 10 or 12 years ago in L.A. One of the best shows I've ever been to.

Welcome to the new blog. Here's where I'll put lots of interesting things related mostly to my non-work life. If you're more interested (as some are) in my work-related life, that's cool -- keep an eye out here and I'll point you in the right direction over the next few days as I get that particular thing into shape.

Keep an eye on the RSS feed for updates.