In case you're curious: here's what you'll see if you rescue your iPhone from a hot car:
Appel d'urgence indeed!
Most programmers know that having functions with too many parameters can be confusing. However, fixing such problems requires some intelligence. A programmer once saw some code like this:
SetObjectParams(obj, foo, bar, baz, quux, xyzzy, abra, cadabra, hocus, pocus, presto, shazam);
Finding a stylistic rule somewhere that said a function should have no more than five parameters, the programmer “refactored” it to this:
SetObjectParams1(obj, foo, bar, baz, quux);
SetObjectParams2(obj, xyzzy, abra, cadabra, hocus);
SetObjectParams3(obj, pocus, presto, shazam);
No, that's not how one resolves this problem. You fix this problem by defining functions that each do something simple, give each function a name that describes what it does, and let them take however many parameters make sense.
Menubar Countdown is a simple countdown timer that displays itself on the right side of the Mac OS X menu bar.
Version 1.2 has these new features:
To download the application or get more information, see the Menubar Countdown product page.
When I released Menubar Countdown 1.1, I whipped up an application icon by simply taking a screenshot of the menu bar and cropping it. The application icon looked like this:
Fugly, eh? Not only is it ugly, but the narrow shape makes it hard to recognize as an icon, and makes it hard to click.
For version 1.2, I wanted a better icon. I thought an hourglass would be a good symbol, so after a few hours of looking at images on the web and dinking around in Photoshop Elements, I wound up with this:
I'm was very happy with it. Unfortunately, the hourglass image is based upon a photo I licensed from iStockphoto. iStockphoto considers an application icon to be the same as a logo or trademark, and such usage is expressly prohibited by their licenses. I'm not a lawyer, but I assume this is to prevent someone from putting a stock image into a logo and then suing all the other users of that image for trademark infringement.
So, I again went to the web, to look for public-domain images I could use. I eventually wound up with this:
I don't like it as much as the last one, but I've decided I've spent too much time on my application icon, and not enough time on making the application better, so this will be the icon for version 1.2. Maybe I'll revisit it for the next version.
I remember the good old days when a Macintosh application icon was a 32x32 black-and-white bitmap. Those were pretty easy for a non-artist like me to create, using simple tools like ResEdit. Now, this stuff is better left in the hands of professional designers, but Menubar Countdown is free, so I trust users will be satisfied with my amateurish effort.
If there are any real designers out there who would like to give me a better icon, I'd definitely appreciate it.
One of my clients, whose e-mail system I have to use, uses a product called ESATInformer to filter spam. I don't understand exactly what the benefit of this system is.
When the system receives suspected spam, it keeps that spam message on the server, but it sends me an e-mail saying "We've received a message that might be spam. What do you want to do with it?" So my inbox still gets filled with unwanted e-mail about suspicious e-mail.
If I want to read the suspicious messages (and I usually do), then I have to send an e-mail request back to the system, which will then send them to me. It would be a whole lot easier if they would just let the suspicious messages through in the first place.
If your spam-filtering system is more annoying than spam is, then you've really screwed up.
I am sometimes asked by non-programmers how they can get into programming. They want to know what programming language they should learn, which programming tools to use, and so on. These are hard questions to answer. It's like asking "I'd like to be a musician. Which instruments and which pieces of music should I learn?"
Here is my advice:
Programming is a big field. Choosing a concrete goal narrows it to something manageable. Once you know exactly what you want to make, it is a lot easier to decide upon a programming language and tools.
Professional programmers don't "learn how to program" and then just apply that knowledge for the rest of their careers. Every day, we learn new things: programming languages, tools, libraries, operating systems, and so on. We pick it up as we go, learning what we need to know as it's needed. If you want to be a programmer, you need to learn how to do the same.