Finally, in July, the project was completed and I ordered a few hundred dollars worth of new gear to update a desktop machine that I had sitting idle and installed Ubuntu 9.04 64-bit. There are a lot of great things about Ubuntu linux and I was very impressed with the performance of the OS on a quad-core processor with a pile of RAM.

Unfortunately, it wasn’t a Mac. Let me explain what I mean by that.I was able to get a bunch of things working correctly on Ubuntu including multiple monitors, my development environment, and email/calendar/address book integration. It seemed with every thing that I tried to do, there was some little “gotcha”.

I installed the 64-bit version of Ubuntu 9.04 on my new hardware. Almost immediately I needed to get Flash player running inside Firefox. That turned into a 30 minute exercise of unzipping the 64-bit beta from Adobe and following a couple different blog posts to get it installed–only to have to redo the entire exercise when I updated to Firefox 3.5.

Then there was the issue of mail and calendar support. All my various email accounts are serviced by Google Apps and I use IMAP connections so that my desktop client and my iPhone stay in sync. Neither Evolution or Thunderbird let me set which folders were to be used for Trash, which meant that I now had an extra [Trash] folder in the list of IMAP folders. Had I been one of those folks that just use the web client, it wouldn’t have been an issue. Oddly enough (odd since I’m a web developer) I don’t like using web clients for mail all the time.

I mentioned that I got my multiple monitors working on Ubuntu. I’d purchased a GeForce card with twin DVI connectors so I could run both my monitors natively (as opposed to using the USB to DVI adapter like I do with my Macbook Pro). Multi-monitor support worked, but it treated the two monitors quite differently than any other OS I’ve used multiple monitors on. Application splash screens that displayed at startup were centered across both monitors as if they were one big desktop instead of 2 distinct monitors sitting side by side. That in and of itself wasn’t a deal breaker, but just another example of things you get used to working differently as I’ve used OS X for the last nearly 3 years.

Finally, not having as much choice in good, polished applications even though there are thousands of titles in the package manager contributed to me coming back to the Apple “fold”. GTD apps that fit my working style and a full-featured alternative to iTunes are two examples.

There were several software packages that were analogous to things I’d gotten used to on the Mac. GnomeDo is a respectable Linux alternative to QuickSilver which I use constantly. Workspaces in Linux operate much the same as Spaces in OS X, although there are some key differences when “ALT-Tabbing” between applications.

I’ll be the first to admit that Linux as a desktop operating system has come an incredibly long way in the last couple of years, but after having gotten used to the “fit and finish” of Mac OS X, it just doesn’t quite come close enough for me to leave the Mac.

How many times have you written an application or feature that solved a particular problem and then gone back to look at it later and thought to yourself “this is some really crappy code that I wrote–I wish I could redo this and do it ‘right’”? I know I have had that thought countless times looking at things I’ve written over the last 11 years of my professional development career. Did we think the code was “crappy” when we launched the application? Chances are the answer at that time was no. So, what changed?

The answer is “everything”. Tools changed, programming methodologies changed, we developers changed (through our experiences since the code release). All this change leads to a moving target for the definition of “perfect code”. What we think is nearly perfect today may look outdated in just a few short months and positively horrible a year or two from now.

Does this mean that we should haphazardly throw together something that will just barely solve the problem at hand because we can never write perfect code? ABSOLUTELY NOT!!! We developers should strive to do as great a job that we can with the tools and experience we have available to us at the time. All the while, however, we need to keep in mind that the final judgement of a programming endeavor is “does it work and solve the problem it’s supposed to solve” not “did I use the right design patterns and include all the current development buzzwords”.

Once you’ve delivered the application to the best of your ability, upgrade your abilities! Upgrading your abilities could mean learning a complimentary technology like jQuery or Flex, doing a proof-of-concept application using a development framework that you’ve not used before, or even brushing up on concepts within the languages you’ve been using (reading up on different ways to use CFCs, Custom Tags, etc or diving deeper into the SQL language to make your database interactions more efficient). Then, if time/budget permits, go back and look at the code that you’ve delivered through the “new eyes” that you’ve gained through this learning process. Most likely the level represented by “the best of your ability” has just gone up–and that’s a GOOD thing!

Scott Stroz posted an entry on Alagad’s blog today that talks about the value of continuously learning new technologies and techniques to grow yourself as a developer. One phrase in his article stuck out for me so much that, with his permission, I may print it and put it on the wall above my desk at home.

…if you ever stop learning, well, then the job has passed you by.

Sober words indeed, but, in my opinion, absolutely 100% true. So, as much to myself as anyone, I say, “stay hungry” for learning opportunities that make you a better developer and allow you to deliver better applications for your clients.

It all started yesterday morning when a client asked me to make some batch updates to the data in his MySQL database. So, I wrote a script to make the required updates. Before running the script, I made a backup of the database in case something went wrong. Everything was good so far. I ran the script, checked the database to see if anything looked amiss and called it a night (oh yeah, this was like 11:00pm last night). This morning, I get an urgent text message from the client saying that the data didn’t look quite right. No problem I think, I made a backup copy of the database last night, I can fix this. But nooooo, that database backup wasn’t around any more. Why, you ask? Oh yeah, that. I saved it to the same location that the regular, nightly backup saves to. So by the time I needed the backup this morning, it was already gone. Luckily, the eventual fix was very simple once I figured out where my script had gone wrong. It could have been really ugly though.

So, here’s to lessons learned:

• Don’t do production database work late at night. The root of the problem was that I misread the client’s original email and wrote my script incorrectly because of it. Part of that failing was the late hour and long day that preceded it.
• Plan, plan, plan and re-plan. Thinking my one backup was sufficient was my second mistake. When working with production data, you can absolutely not be “too backed up”
• Test your scripts on non-production systems first. This client doesn’t have a dedicated development system, but I do have a few-weeks-old copy of the database on my development machine. Another mistake I made was being lazy and not testing these changes on my local copy before applying them to production
• Have a plan in place to verify the database changes as soon as they’re made. My cursory inspection of the data didn’t reveal the actual problems that occurred. If I had done this when the client was available to test the changes, we’d have been able to immediately restore the database and assess what went wrong.
• Nothing is ever as simple as it seems. These updates seemed like a walk in the park and lulled me into not taking the precautions I knew I should have

So, in the end, my client has his data back where it belongs and I have a few things I’ve learned I’ll never do again. My biggest embarrassment in this whole thing is that I consider myself a senior developer. I’ve been writing web apps for almost 10 years across Oracle, MS SQL, MySQL and PostGres databases and I should have known better than to take shortcuts. My only excuse is that I’m human and I can only try to learn from my mistakes.

That all changed when I bought a Dell 17″ laptop and started using that as my primary machine. While you can leave the laptop open and use the internal LCD screen with an external monitor attached to the monitor connector, that configuration has never suited me well. I have this “condition” that things I deal with on a regular basis need to be symetrical (my wife thinks I should be in therapy for it, I think it’s just a matter of wanting things to look “right”), so having a laptop open next to an external monitor just never appealed to me.

About 18 months ago, our entire household converted to various models of Apple computers. I have been running an external monitor from the DVI connector built into my Macbook Pro since then. All the while, I have been searching for some sort of solution to let me run 2 (or more) external monitors from my laptop. I was excited about the announcement of the ViDock unit from VillageTronic until I found out the Mac version was $499.

In continuing to search this topic last week, I ran across this device that connects an external monitor via USB 2.0. After reading all the reviews, test results and opinions that I could find, I decided to take a chance on one. At $129 for the version that supports the higher resolution, it’s a lot less to invest in something if it turned out not to work as advertised.

The unit arrived yesterday afternoon (Tuesday) and I immediately ripped the box open. I had already downloaded the Mac drivers for it so I ran the install program which forced a reboot at the end of the installation process. Once I had logged back in, I connected the cables to the unit and plugged it into my USB hub. Within a couple of seconds, the second external monitor was working. All I had to do was make a couple of adjustments in the Displays Preference Pane to arrange them as they are arranged on the desk and put the dock back onto the display hooked directly to my DVI port and I was done.

So now, I have my Macbook Pro driving a Samsung 22″ LCD from the built-in DVI port and a Dell 20″ LCD from the USB adapter (and yes I’m champing at the bit to purchase a second Samsung 22″ so that both monitors are the same and everything is symetrical).

I have noticed that the performance of the USB adapter is not as good as the built in card, but that is to be expected due to the bandwidth limitations of USB 2.0. For instance dragging windows has a noticeable “choppiness” to it on the USB monitor vs the built-in one. For this reason alone, I decided to discontinue my use of Leopard’s Spaces function. The way I’m using it now is that I have my Eclipse coding environment set up on the USB driven monitor taking up the entire screen. There isn’t much motion that happens on that screen other than scrolling code up and down or opening the various panels that I use in Eclipse, so the performance is more than adequate to handle that.

The folks that were testing these had 5 of them hooked up to a mediocre Dell Inspiron 9400 driving 5 separate external monitors with the same kinds of results that I’ve noted here. If this continues to work well, I may purchase one or two more and run 3 or 4 screens off of this thing. I had contemplated purchasing a Mac Pro for the desk to get multi-screen capability. This solution saved me over $3,000 so I’m definitely glad that I ran across this link last week.

For the lasst two weeks I’ve been able to successfully maintain 0 messages in the Inbox folders of my 3 main email accounts. I’m definitely not “there” yet with the whole Getting Things Done method of managing what you need to do, but I do feel like this is an important baby step.

One of the features of ToodleDo that I’ve really taken advantage of is the ability to create a special email address that will automatically create a task in your list when you send an email to it. There is a certain syntax for the subject line that lets you set certain parameters on the task automatically. Anything in the body of the email automatically gets put in the notes section for the new task. Below is an example:

This is my super important task name !!! #next Monday *ProjectA @work

The first part of that obviously is the task name. The three !’s give it a priority of 3 (Highest). #next Monday sets the due date. *Project A identifies which of your projects you want to associate this with. Finally the @work identifies the context where this task should be completed.

So now when I read an email, I do one of three things:

Read it, answer it right then if I can do so in 60 seconds or less and archive it

1. Read it and delete it if it requires no action from me
2. Read it, forward it to my ToodleDo email address and archive it if it’s something I need to address in the future.

This eliminates the problem with tasks falling “below the fold” in your Inbox and languishing there until months from now when you decide to clean up your Inbox. It also dovetails with the idea of keeping all your tasks in one place (ToodleDo for me) so that there is less of a chance that something gets lost.

Anyone else using something similar to this? Any tips on further refining this method to be more productive?

Last week while browsing through the iTunes App Store, I decided to purchase a copy of ToDo. ToDo is a nifty GTD-based application for keeping the items in your to do list moving and making sure that you don’t lose track of anything. What impressed me most (other than the fact it is a very nicely built application) was its ability to synch with 2 totally unrelated online task management services (ToodleDo and Remember the Milk) which means that you no longer have to keep a duplicate to do list on multiple devices AND you can now take that one, central, authoritative to do list with you wherever you go.

That’s when it hit me. When I’m looking for providers of services that I am in need of, I no longer look at any services that are just online, or just installed on my laptop. If the service I’m looking at doesn’t have touch points for my computer, my iPhone and web-based access, I’m just not interested. It appears to me as though this is the direction that things are moving. People don’t single access points to their data any more and the trend is growing.

As a developer that lives in this space, this revelation was pretty significant for me. It made me realize that any application that I build from now on is going to require those multiple touch points if it is to be a complete success.

Bring on the clouds I say…I like this trend even if it took me longer than the average bear to figure it out.

I’ve been really horrible the last (nearly) 2 months in not blogging at all. So much has happened in that time frame that I can’t explain it all. cf.Objective() 2008 combined with the pre-conference Mach-II training is a not so distant memory. I’m back to traveling each week for the foreseeable future and my wife and I have been busy like crazy the last few weeks trying to get our house ready to put on the market.

I do have two or three interesting posts lined up for the next few days however. One of the things I’ve been focusing on after talking to folks at cf.Objective() back at the first of May is reworking my local development environment to make it more flexible and “standard” (I know, everyone has their own “standard”). I’m going to start a series of posts that detail what I’ve done with my environment and why I’ve set it up that way. I’ll give a little bit of technical detail in how to go about setting your system up this way (assuming you’re on a Mac–PC users will have to adapt a little bit to fit their environment).

I’m not quite finished with my setup just yet. We geeks are always trying to change and improve things right? So stay tuned, I’ll post the first in the series in a couple of days and we’ll roll on from there.