• An Arduino microcontroller. Thanks to RAD, I learned about Arduino, which gave me the ability to program hardware. It's something I've always wanted to do but never knew where to get started. I have one now, and I hope to complete an in-depth personal project next year.
  
  
• Apple's iPhone. Not because of the music, videos, and photos, but so they can deploy their creations using the iPhone SDK. Who doesn't want to make their own light saber battlegame utilizing GPS and accelerometer data?
  
  
• A trip to a software development related conference. A conference represents fun to be had learning and socializing with other geeks, and an opportunity to see what cool things other people are working on. Pick one according to the type of work they do, or the language they use most. Pick one unrelated if they want some adventure.
  
  This year I attended Lone Star Ruby Conference and had a great time learning things I never would have thought about to begin with. Even more fun were the conversations with other programmers who I'd met online, and some I'd never talked to before. (Here's a link to LSRC, whose website is down at the time of writing.)
  
  
• Books are always a good idea. This year I've especially enjoyed Founders at Work: Stories of Startups' Early Days and The Mythical Man-Month. Founders at Work was great for its insight into the minds of companies' founders (I especially enjoyed the interview with Steve Wozniak). Mythical Man Month is worth reading several times because of the wealth of timeless advice found in its pages.
  
  
• Parts to build a new computer. Many developers are - shall we say - frugal, and would love to have new equipment to work on, but never seem to justify the cost to themselves. Get them a motherboard, processor, video card, hard drive, optical drive, and tons of RAM and let them go to town building their own. Just make sure all the parts are compatible (and ask if you don't know!).
  
  After swearing off desktops last year, my MacBook Pro display went kaput recently this year (which Apple so graciously fixed out of warranty for no cost, except haggling), so I built a 64 bit dual quad PC with 8GB of RAM. Now I'm having fun writing programs without the 4GB memory restriction. Bloatware here I come! (Just kidding of course. The extra RAM and cores come in handy for bioinformatics research).
  
  Plus, the languages, platforms, and frameworks I use don't scale, so I need the extra processing power.

Those are some things I've enjoyed playing with this year. T-Shirts didn't make my list.

What's on yours?

Let's recount what we know about the situation:

• It was making a ton of money.
• There was an application running it.
• There was no source code for the application, and no vendor to contact to get it.
• The application had to access a database by knowing the DB file location.
• Gulfomatic's Solutioneers tried several potential solutions before finding the one that worked

That's all we know initially. What does that tell us?

• Our solution needs to be implemented quickly, and we have money to spend if we need to.
• Even if the application itself is the cause of our problems, we can't change it because we lack the source code, so our solution has to be done outside of the app itself.
• Whatever solution we come up with has to take into account the fact that we're using a file path to access a database.
• You can work methodically - trying the simplest solutions first, and revise them as more information presents itself.

But where do we go from here? The answer came from shag in the comments to the original post:

any clue as to what we're working with here? what kind of app are we talking about? what are the pieces in the puzzle that makes it go? what are the symptoms? what kind of access do we have? what kind of layers to we have? what kind of hardware do we have? what kind of os do we have?

i think we need to address what we are dealing with prior to the how to resolve the problem.

that being said, from a high level (and i mean like jupiter), some basic things are:

- identify symptoms
- scour logs

We start by identifying the symptoms. In this case, the application is crashing. What are the potential bottlenecks in the system that might cause it to crash? Are we lacking bandwidth? Is the web server crawling to a halt? Is the application itself using too many resources? Can the DB handle the load being thrown its way? Maybe the combination of these things is just causing the computer to crash.

Reading the logs and monitoring the different processes will probably give you an idea of who is the culprit.

Check the application logs if it has them. Check the web server and DB logs. Check your OS logs. Just like in programming, you cannot just make changes in random places to improve performance. You need to analyze the system's behavior to find the bottleneck, which will tell you where your changes will be most effective.

That gives us several potential bottlenecks:

• Insufficient computational ability in processor speed, disk space / speed, or memory. Completely a hardware problem.
• The web server + database + application combined are just too much for the current hardware to handle.
• The database itself just cannot handle the number of requests being sent its way.
• The application (which lacks source code!) is the bottleneck. It hogs processor cycles and memory like a squirrel hoards nuts.

(What did I miss?)

Given what we know about the situation, what would you do in each scenario?