Extending my Reverse game coding spree, I decided to make a version in Logo. Of course, in order to really effectively program in Logo, I had to make a TextMate bundle for it.
It’s nice when minor obsessions come together like that.
(By the way, if you’re ever in a position where you’re trying to look up information on Logo on the web, be warned that it can be damned hard thanks to the conscientiously inserted alt text on five bazillion company logos!)
In November I wrote about rediscovering BASIC Computer Games, a book I had when I was learning programming in the ’80s. Flipping through it recently I came across a simple game called “Reverse”:
The game of REVERSE requires you to arrange a list of numbers in numerical order from left to right. To move, you tell the computer how many numbers (counting from the left) to reverse. For example, if the current list is 2 3 4 5 1 6 7 8 9 and you reverse 4, the result will be 5 4 3 2 1 6 7 8 9. Now if you reverse 5, you win.
I avoid XML as much as possible, but once in a while I’ve had a project where I thought about making an ad-hoc XML dialect. I’m going to file away Tim Bray’s recent blog posting to keep me out of trouble during those moments of temptation. His advice boils down to this: If you are tempted to make a new XML dialect, instead try fitting it into one of what he calls the the “big five”:
I’m an Emacs man myself. I’ve never really used vim at all, and I use vi only for crontabs and commit messages. I’ve always grasped in the abstract the potential advantages of its modal editing, but that’s as far as it ever went.
Jonathan McPherson’s site has a great introduction to using vim that opened my eyes. His explanations of vim’s features offer just the right amount of detail. Most importantly he explains why particular commands are a good idea. Not explaining that is one of the classic failings of manpages – and I suspect that the vi manpage is the beginning and end of many users’ attempts to learn it. They learn about insert mode, command mode, loading and saving files, and that’s about it. Luckily, those just happen to be the prerequisites for McPherson’s tutorial. Clever fellow.
I wish I’d known about retest when I posted about regular expressions recently. It’s a great little utility from Christof Hoeke that uses Python’s re module and SimpleHTTPServer power to give you an interactive regex tester right in your web browser. He says he’s only tested it on Windows XP, but it worked great for me on OS X 10.4.3.
Brendon commented on Sun Feb 18 18:29:06 2007:
Another good Regular Expression tester to check out is ReJax:
This is amateur science at its best. Peter Klausler, an aficionado of the Dvorak keyboard layout, decided to see if there were better permutations of keys yet unrealized:
…I constructed a complicated function that measures the amount of “work” needed to touch-type a given text with a given layout.
Very good. But where does the primordial soup of keyboard layouts come from?
…4096 keyboard layouts compete with each other. The layouts in the initial pool are entirely random. In each generation, they all race to “type” a word list, and their per-word times are multiplied by the word frequencies in the input sample. After the race, the fastest half are kept. The pool is then repopulated by generating a single mutation for each survivor.
Here’s another advice post. Luckily, many of you can test out of it, like a college Gen Ed requirement. Here’s the test:
^http[s]?://([a-z]+\.)?example\.com/$ (Answer below.)The target audience for this post is people who have heard of regular expressions, but don’t use them. Or who have used them a little, but have the feeling they really should know them better.
You’re right. You should.