The Buzz about Fizz

Gregg writes about the FizzBuzz furor, and links to the original post, which states the hypothetical problem.

All caught up? Good. I’ll leave Gregg’s point to Gregg…

The thing is, the original codinghorror.com post brings up a valid point. The FizzBuzz test thingy–while admittedly arbitrary–is a shit or get off the pot situation. The solution is logically easy, therefore the resultant code should be easy to write.

Here:

def fizzbuzz():
    a = 1
    while a <= 100:
        b, c = a % 3, a % 5
        if b and c: print a
        if not b and c: print 'fizz'
        if b and not c: print 'buzz'
        if not b and not c: print 'fizzbuzz'
        a += 1

It may not be the most elegant way of doing it in Python, but do I get the job?

My point here is not to show off my hardcore Python coding skillz (I don’t have any of those), but if you’re interviewing programmers, it might be a good idea to use a FizzBuzz-esque litmus test at the very beginning of the interview; it could save you a lot of time.

Non-Extensible MovableType Tags

As I sift through the minutiae of updating the MMH design and layout (mean-ass gorilla, bitches!), there’s this wall I keep running head-long into. That is, the lack of extensibility in MovableType templating tags.

I’d really like to do some type of iteration or database-like call to get all of my previous posts which have more than X number of comments, so I can feature the “most popular” in a sidebar callout.

I could very well be missing something obvious, but it seems to me that aside from installing a 3rd-party plugin, I have to settle using the hard-coded tags the people at SixApart have decided are critical or at least useful.

I guess I’m asking for an API of some sort… which might exist… but I don’t know where it is, or how to use it (if it exists).

Throw the .DS_Store in the .Trashes

Say you’re going to do a production run of your company’s entire website(s) on a CD-ROM for distribution to customers who may not have access to the ‘net while on secure networks. Yeah, I know… a pretty specific case. But, also, just say that you’re going to distribute a CD-ROM that will be viewed on [whatever damned OS under the sun], and you’re developing its contents in OS X.

The first step is burning a master CD to provide to the vendor shop, right? They’ll glass master and mould-inject later. But, when you’re preparing that master CD, there are some OS X hidden files that you should delete from it before going ahead with the burn.

Why? Because who knows how other platforms will display the contents of your CD-ROM. Some can be configured to “show hidden files”, and others don’t know that file or directory names starting with a dot are supposed to be “hidden”, as many *nix & BSD systems assume.

First of all, immediately after the blank CD-R is mounted by the OS X filesystem, you should go in and kill the “.Trashes” directory it creates on mount. Open Terminal.app and

cd /Volumes/[volname_you_specified]

… then…

sudo rm -rf .Trashes

… and provide the password when prompted. You must have Admin. privileges to do this.

Next, we have to clean up those .DS_Store files that OS X’s Finder auto-generates when you view a directory [full expl.]. Since you can’t see them in the Finder, you’re stuck in command-line hell cd’ing to every directory in that branch of the filesystem and looking for/deleting those bastards.

You must be thinking: “But, Gary, there’s GOT to be a better way!”

Why… yes there is a better way. It’s called Python, and all OS X boxes come with it by default. The joy.

Use the os.path.walk() function to navigate the directory structure and delete all files named “.DS_Store”. Or, you could use the module I wrote to do specifically that. Source code here. Snag that, edit to your liking in your favorite text editor, open Terminal.app, rename it “kill.py” and chmod that fucker to 755.

Then, run it.

Diff’ing Directory Structures

Updated Jan. 21, 2008: The python script may not work very well; please check this post for the proper shell script format based on Gregg’s comments here.

Updated May 23, 2007 to fix link to Python text file.

What happens when you have two directories or folders that are supposed to be identical (think backup situation)? They’re supposed to contain all the same files and identical directory structure all the way down, right? But, what if those directories contain thousands of files and subdirectories? How can you be sure they’re identical without masochistically reviewing every… single… painful… thing? 36 lines of code later…