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. :)
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. :)
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.
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.
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.
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).
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().
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? :)
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. :)
I often do it multiple times per minute. That wouldn't fly if each required a clone. :) (See another post I made in this thread for what I'm doing that involves so much history mutation.)
Yep – and I did it all, using those tools, for a couple of years. :) Now, when I go back to Mercurial (which I know better than Git, mind you), I get frustrated. Those tools are much more blunt than their Git equivalents.
Git gives me everything I needed MQ for, but with the complete safety of the reflog. There is no such thing as a change I can't undo. The fact that patch management is "special" in Mercurial is the problem!
With respect to history modification:
First, I rebase a couple dozen times per day. I'm on a team that doesn't use merges unless we have a reason to (this makes it easier to bisect and think about history). I also create, destroy, and rebase many of my own branches every day.
Second, I amend commits a lot. I'll often spike some little piece of code I don't understand, then start amending the commit as I rewrite it with TDD, until the commit no longer contains any traces of the original spiked version. For more complex spikes and TDD rewrites, I'll do it over many commits, rebasing the spike over the rewritten version until the spike commit is empty and gets skipped by the rebase. Doing that in Mercurial would be... arduous. I can easily do multiple history rewrites per minute while doing this.
Third, I amend commit messages a lot, usually with "git rebase -i". Maybe I forgot the ticket number, or maybe the meaning of the commit changed (see the next point).
Fourth, I sometimes do drastic commit rearranging. This is harder to explain, but it usually involves splitting commits (in the simple case) or moving sets of related changes from one commit to another (in the complex case). These are sometimes at the file level, sometimes at the hunk level, and sometimes within a hunk. This is rarer than the others; I probably do it once or twice per week.
Fifth, I "git reset <ref>" a lot. It took me longer to start doing this, but it's useful in a lot of situations. For example, "oops, I accidentally created a merge bubble."
"""
I'm sorry for recommending software with a confusing interface. But you'll be spending a lot of time with it; it's worth getting over the initial hurdle of confusion.
"""
Note that I call it the "initial hurdle". I know both systems very well, and Mercurial gets in my way far, far more than Git.