1. Copy files to a temporary directory.
2. Dump the MySQL data into a file in that directory.
3. Tarball it up.
4. Scp that file to another server that I run.

At the time, I did this because it was the simplest thing that could possibly work.  It didn’t depend on any external facility other than mysqldump, tar, and scp.

Well, running that script on a nightly cron filled up my disk allocation on that remote server a couple times, so I got clever with the backup organization so I could quickly remove old backups while keeping sparser (monthly) backups for longer.  This only helped a little, because I was still nervous about deleting backups because I didn’t know what they contained.

I also have been using git more and more recently and I liked the idea of version control that can go in any direction.  So, in the spare bits of time I’ve had in the past few weeks, I wrote git_backup.pl.  It takes a git repository and does the following:

• git add <any new or modified files>
• git rm <any deleted files>
• git commit
• git push backup

Now, when the backup is run, only the small changes are sent to the remote server and I can look at the differences by examining the git log.

There are options for dumping database tables, changing the commit message and the remote that gets the push.  Running “git_backup.pl –man” will show all the options.

The source is (of course) in a git repo: http://git.endot.org/git_backup.git

The tree and history can be browsed at http://git.endot.org/.

So, it took me a little while to figure out that it’s a bug in the R.app code and you have to use a workaround.  Open R.app’s preferences and set the “R history file” key to something other than “.Rhistory”:

Now, after a restart, the .nateRhistory file in the working directory is properly updated.

From a related post from Steve McConnell:

Other debt accumulates from taking hundreds or thousands of small shortcuts–generic variable names, sparse comments, creating one class in a case where you should create two, not following coding conventions, and so on. This kind of debt is like credit card debt.

I was doing a review of some relatively mature (3 years) code today with the rest of my team and I found more instances of this kind of technical debt than I would like to admit.

There are other kinds of technical debt, and it’s easy to hate them and the reasons for incurring them, but this small stuff is totally under my control.  And it has to stop.

• Add a configuration/settings area for the application.  The keys are: Display Name, Username, Password, URL
• Move the downloading of new messages into a thread so that it happens in thebackground.

We set the deadline for this milestone to be last Saturday, the 17th of January.  I guess the first few weeks of the year got away from me, because by the time I woke up Saturday morning, I’d only done the first half of the
assignment.  Add that to the fact that I was out of network range this past weekend (due to a wonderful trip to see Sara’s Grandma), and it’s time for me to add a virtual $20 to the jar.

I’ll post again when I finish up this milestone and we figure out what milestone 3 holds.

It really doesn’t do much other than the two required features.  I haven’t profiled it to make sure there are no memory leaks, but I’ll do that soon.  The manual memory management of the iPhone is definitely odd for someone like me who’s done mostly garbage collected languages in his career.

To learn what I had to for this phase, I relied heavily on reading the sample applications from Apple and through several of the detailed guides that come with the SDK.  The Objective C primer was invaluable, as was the documentation on NSMutableURLRequest.  The documentation browser and search functionality in XCode is pretty good.

Anyway, I feel like I’ve learned a lot in the past few weeks, and I already have several ideas for milestone 2.  I’ll post again when we start that phase.

To that end, Dave and I started a little side project called (at this point) NDWall.  It’s an implementation of a “wall” where new messages can be posted and the 10 most recent can be viewed.  The server-side api is very simple.  Just two methods (GET and POST) on the api resource.  The data transport is JSON, the lingua franca of web APIs.

We’re each making our own version of the client, written in Objective-C using the iPhone SDK.  To help light the fire, the first version of the client must be written by midnight on Saturday, October 18th.  The first version must do just two things:

• Allow posting a new message to the server.
• Download and display the last 10 messages from the server.

We started doing this about a month ago, but kept pushing the deadline off as it approached, so this time, we agreed that whoever didn’t deliver this time would have to put $20 into a jar*.

I think it’s working.  This past Saturday, there was much documentation reading and code typing and instant message sending going on.  Tonight, I got my client to pull the data down for the first time.

This is fun.

* jar money purpose not determined at this time.

In the back of my head has always been Joel’s test, and in my feed reader the other day, I found a similar list; the humorously titled “Your Doing it Wrong if…“  I had to laugh hard at the fourth entry on that list, as I have written my own database abstraction layer (hereafter DAL).  I have all sorts of excuses for why it was written at the time, but I must say that after using it for almost three years, I think that using another (preferably open source) layer is the best idea.  I’ve come to realize (and have read in several places) that you shouldn’t write something that is not your core business.  If you’re selling stuffed bunnies online, don’t write your own shopping cart.  Buy one or use something like ZenCart or Magento.  Of course, if your business is the shopping cart (like, oh, Amazon), then go right ahead.

Anyway, I was talking about DALs with a friend today, and he mentioned this blog post, which speaks out against these layers.  The post rails against them as a method of keeping software database independent.  I agree with him that that is not a good reason by itself to use a DAL, but it got me to thinking about why I use one.

My answer to that question comes from Mr. Code Complete himself, Steve McConnel.  He’s quoted on a Coding Horror post as saying:

Nobody is really smart enough to program computers. Fully understanding an average program requires an almost limitless capacity to absorb details and an equal capacity to comprehend them all at the same time. The way you focus your intelligence is more important than how much intelligence you have.

At the 1972 Turing Award lecture, Edsger Dijkstra delivered a paper titled “The Humble Programmer.” He argued that most of programming is an attempt to compensate for the strictly limited size of our skulls. The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.

The purpose of many good programming practices is to reduce the load on your gray cells. You might think that the high road would be to develop better mental abilities so you wouldn’t need these programming crutches. You might think that a programmer who uses mental crutches is taking the low road. Empirically, however, it’s been shown that humble programmers who compensate for their fallibilities write code that’s easier for themselves and others to understand and that has fewer errors. The real low road is the road of errors and delayed schedules.

The best reason to use a DAL (or any abstraction, for that matter) is outlined above: to encapsulate a set of functionality (data persistence) and then remove it from the front of the programmers mind.  This frees the mind to concentrate on higher level concerns like (hopefully) the core business logic.  Of course, DALs tend to grow and morph until they become bloated and try to accomplish less important tasks (like database independence), but the real benefit of using them is to write less code and when you write less code, you will naturally create fewer bugs.  I don’t want to avoid SQL because I hate it or can’t use it, but rather because it is unnecessary to always have it in the front of my mind.

Of course, using or not using DALs should never be a hard and fast rule.  If your application only persists to one table (or a few), or has very tight memory requirements, or uses gypsy midgets, feel free to skip a DAL.

And, as always, these are strong opinions, weakly held.

Good luck.

and Capistrano is to deployment,

now Castanaut is to screencasts:

#!/usr/bin/env castanaut

plugin "safari"
plugin "mousepose"
plugin "ishowu"

launch "Mousepose"

launch "Safari", at(20, 40, 1024, 768)
url "http://gadgets.inventivelabs.com.au"

ishowu_set_region at(4, 24, 1056, 800)
ishowu_start_recording

while_saying "
  Tabulate is a bookmarklet developed by Inventive Labs.
  You use it to open links on a web page.
  It's meant for iPhones, but we'll demonstrate it in Safari 3.
" do
  move to(240, 72)
  tripleclick
  type "http://gadgets.inventivelabs.com.au/tabulate"
  hit Enter
  pause 2
end

So cool.

I changed a setting and now I get an error. What’s wrong?

My knee-jerk reaction was to think, “Well, then what was the error?!?” You see, I’m a problem solver. I love to dismantle things and figure out why something isn’t working properly. To me, the first step toward the solution is to figure out what the problem is. So my first attempt at formulating a response went something like this:

Here’s how to figure out what the error was. Come back when you’ve done this minimal amount of work.

Ooooh, snarky.

Before I hit ‘Send Reply’, I took a bit of time to explain the situation to a co-worker and made the point that figuring out the problem is a vital first step to working toward a solution and that there are common ways of discovering what a particular error is (logging, debug flags, etc.). I also stated that these problem solving tactics are learned best by experience as opposed to reading or hearing about them.

Then, my mind came up with this question: “Was I ever not a good problem solver?” That question suddenly humbled me and gave me a new perspective on the whole situation. I changed my response to first validate that the way the customer was changing the setting was correct and that the error was indeed an unexpected result. I went on to explain how to figure out what the error was and that I’d help them figure out what was going on.

You see, snarkiness is fun, but it’s rarely edifying for the snarkee.

I don’t post this to boast of my humility. In fact, I’m quite embarrassed about the way that I initially reacted. It’s my hope that this will remind you to always remember that you were once the student.

http://www.codinghorror.com/blog/archives/001048.html

Also:

http://www.jnd.org/dn.mss/simplicity_is_highly.html
http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

From the Norman essay:

Logic and reason, I have to keep explaining, are wonderful virtues, but they are irrelevant in describing human behavior. Trying to prove a point through intelligent, reasonable argumentation is what I call the “engineer’s fallacy.” (Also, the “economist’s fallacy.”) We have to design for the way people really behave, not as engineers or economists would prefer them to behave.

I find myself re-learning this again and again.