It's on the front page, but at the bottom. DAS is a small one-man business, so I did the design myself (and I'm not a good designer). Sorry about that. :)

No, it's more subtle than that. By wrapping in parenthesis, you're making it an expression. When you just say "{}+[]" in e.g. Chrome, the first {} is parsed as a block. So what you see printed is the result of "+[]", which is 0. This is why {}+[] is not equal to {}+[] without parens. This may also be why Node gives different results; I'm not sure.

I didn't mention any of this in the talk (it would've killed the flow ;). Instead, I glossed over it and interpreted the syntax as any sane programmer would.

I understand why it happens. I'm saying that what you're pointing out is not in the nature of JavaScript, it's in the REPL. It's just wrong; there is no other situation where that code would evaluate that way. node is behaving "properly", showing you what value you can expect if you, say, assign that expression to a variable.

I guess it's an amusing bit of sleight-of-hand, but using it to mock JavaScript seems, I don't know, tasteless. Doesn't it have enough problems without inventing more?

It's a joke. Relax.

Yes, I saw the joke.

To clarify, I thought the first part of the talk was funny. Here's a weird bit of Ruby. Hah! Here's a weird bit of JavaScript. Hah! Here's some JavaScript to make you think it's weird in a way it actually isn't! Uh, okay? Just don't see what's funny about that, I guess.

There's no laugh track; that's the audience.

It's Keynote. I recorded those sessions as screencasts, then sliced them into tiny pieces so I can advance them perfectly with my talking. There are 37 slides in that four-minute talk. In some cases, the slices are only two or three frames long.

Ah that makes sense, thank you. I may steal that idea for future talks with R. Though, just embedding a shell in a slide deck would be very nice.

I like the sliced screencasts because they're so repeatable. I practice my talks a lot, and I can get the timing down perfectly because it's always the same. Highly recommended. :)

The preparation really shows -- great job. Ability to present really well is a critical skill for anyone with a product head.

I could port it to Python if you want? ;) I probably wouldn't have done this when Python was my main language, though. That community has a much harder time laughing at itself than Ruby's does.

Fortunately the Perl community have no trouble laughing at itself either! So here's a port to Perl :) https://gist.github.com/1204277

Moose's MOP makes this "port" quite easy (as does Perl having multiple inheritance!). Does mean it only works on Moose classes but a universal approach is also possible but it wouldn't be as succinct!

Python already has one base class to rule them all, `object`. From just the title I thought that's what the post was going to be about.

The same thing in Python would require you to import all modules, and place all functions and classes in those modules in one class. Probably can be done, but whether it's useful?

Maybe C or k? ;)

Done: https://github.com/garybernhardt/base/commit/65e8ca5d432be72...

I was tempted to leave the disclaimer off, both in the README and the blog post. But I think there's a strong enough chance of someone actually using it as it is... ;)

You can just create a new branch before you start the rebase, which achieves exactly the effect you ask for. Rebase is how you "create a new branch with only the clean commits".

But, most of us don't bother copying before rebasing. The reflog makes that pointless from a safety perspective and, without the safety need, there's not much reason to copy before rebasing.

I don't rebase everything. Merges still have their place.

An early draft of this post talked about the relationship between rebase and bisect, but I cut it out to focus on one topic. The tl;dr is that heavy merging makes it harder to reason about bisect (and, of course the history in general).

I don't think that Google Reader can export as JSON... ?

I often use vim for your python step. A sequence of 3 commands to convert opml to a file with feed urls, one on a line.

  :%!grep xmlUrl
  :%s/.*xmlUrl="//
  :%s/".*//

Edit: it relies on idiosyncracies about how google reader formats OPML, though.

I considered using Vim at the time. The nice thing about doing it all on the command line is that it's repeatable and persistent. I have a huge shell history, and that command will now be in my history for months. I rely so heavily on my history that I'll often remember a related command from a month ago, find it, then modify it for my current use. :)

:) Yes I can relate. I started saving my shell logs in 2006 and one of my most commonly used commands is cmd_grep.

I'm now watching http://blog.extracheese.org/2010/04/a-raw-view-into-my-unix-.... I've ended up constructing my own vocabulary (column, freq, etc.) for most common uses of perl/awk in the commandline. http://akkartik.name/bash.html

No, but Python can.

JSON syntax is Python/Ruby primitive syntax for lists and strings (although the reverse isn't quite true). Why add a library import and additional code on each side just to emit and consume what is effectively the same data? :)

Because it's a standard and not a hack, because you wont have to do workarounds like utf8 encoding unicode objects, and because it's also easy.

This is my personal list of RSS feeds, which I've been curating for many years, so I knew exactly what data was coming. It was a one-time hack: it got my RSS feed list into the database, and was never excuted again. It was also only for local testing purposes.

I think that it would be pretty crazy to import simplejson on the Python side, write extra code to dump the data to JSON, look up how to do it in Ruby (because I don't know off the top of my head), and add the code to load it from JSON. That effort would not change the outcome by a single bit. For other theoretical data sets, it would, but this is not other data sets.

If this code were ever going to be used again, sure, I'd transfer it in a safe way. But this is the equivalent of `grep`ing and `cut`ing at the Unix shell – the goal is to get data from point A to point B, never to be revisited. I reject the idea that, in this particular case, extra effort to serialize and deserialize JSON data is superior to adding five characters of str().