Archive for March, 2009

Aside

Need way too much information, fast? Try Google Alerts

I just wanted to take a second to mention a fantastic Google tool that most people don’t seem to know about. Google Alerts allow you to be notified by email every time there are new search results for keywords you have specified. There are some settings to help filter your results and you can also decide how often and in what format (individual emails or digest) your notifications are delivered. You have to be somewhat specific with your keywords or your mailbox will be overflowing within minutes. I set up an Alert based on the term “iPhone” with no filtering and a day later my mailbox was so full that Outlook locked up and I had a max capacity warning from my hosting provider…oops. However, if you set up an Alert for “Crestron” or “touchpanel design” and you limit your results to blogs and news items, you will undoubtedly start getting useful information as soon as it becomes available. Just try to resist the temptation to set up an Alert for all new “American Idol” news and your mailbox should be okay. Additionally, if you are an avid Twitterer, Google Alerts are a great way to find useful, up-to-date topics to Tweet about. You will need a Google account to use Alerts, but quite frankly, if you don’t have one yet, you’re missing out on all kinds of excellent, free tools and services.

Aside

Netflix + inventive, lazy person = The Mailbox DVD Player!

This little nugget of ingeniousness is going to pay for my early retirement. The idea came to me as I was sprinting to my mailbox in the freezing rain the other day to get my latest Netflix deliveries. I thought to myself, what if the mail carrier could just load my movies for me at the mailbox? It seems silly at first, but after all, that’s what people said about Netflix in the beginning also.

The Mailbox DVD Player in action (prototype, of course)
The Mailbox DVD Player in action (prototype, of course)

At first, I thought of simply duct-taping an “el cheapo” dvd player to the mailbox, but then I figured, why not have a mailbox with the dvd player built in? It could be completely discrete, the disc drawer wouldn’t even be visible when it was closed. Security would be no problem because the entire unit would be built out of half-inch titanium (I don’t even know if that’s possible or if it would actually increase the security of the thing, I just wrote it because it sounded cool and I don’t feel like doing Google research on titanium right now…this whole post is a joke anyway, so don’t leave me some uber-nerd comment about how titanium wouldn’t work for whatever reason). Your mail carrier would have a user-definable “pin” that he or she could enter to open the drawer. Once the movie is loaded, all control of the unit is handled via rs-232 by your control system of choice from inside the house. The single-disc model is shown here, but a 6-disc changer version would also be available for Netflix subscribers who receive more than one movie at a time.

Aside

I mean really, when’s the last time you used the “stop” button?

In a previous post, I talked about going through your old bag of programming tricks and eliminating those that are either outdated or just no longer practical. This post is along the same lines, as it about getting rid of things you don’t need. Many programmers, myself included, tend to fall into the habit of what I call “conditioned programming”. We program systems the way are used to and we don’t really stop to think about what we’re doing from one system to the next. This often leads to stubbornness or bullheadedness on the part of the programmer when asked why the system works the way it does. We get defensive; after all, it’s not our problem that the customer was sold a product that is way over his head, we just program the commands that are on the factory remote, right? Well, frustration with misleading sales staff aside, it is always in the programmer’s best interest to analyze and evaluate the needs of the customer for each system he or she programs.

Many end users can tell you right away that they never use certain commands for a particular device. This can clear up confusion from the get-go, reduce clutter on the touch panel and ultimately make the system much easier for the customer to operate. You can also make some executive decisions of your own and give the axe to buttons and commands that you’ve been including for years but are seldom used by most of your customers. I just recently had the revelation that the “stop” command could be eliminated from a number of devices for which I had been habitually including it. And if you’re still putting the “angle” button on your DVD pages you should really be taken out back and taught a lesson. Seriously though, if you are an efficient programmer it will be no big deal to add these obscure commands back in if the customer specifically requests them. I personally find it helpful to create an Excel spreadsheet that lists optional device commands and system features so I can fill it out when I meet with a customer (of course, this could be due to the fact that I am an organizational freak who will find any excuse I can to create an Excel spreadsheet).

If you are already following the programming practices I’ve outlined here, I’m sorry you just wasted your time reading this, but if you quite often fall into the habit of “conditioned programming”, I think you will find it helpful to start analyzing your projects a little more. It will make your customers happier, reduce service calls, and keep you in the habit of regularly revisiting your programming practices.