endot

A friend let me borrow his GH3 for Wii and two guitars.

This game is so much fun, it's emberrassing.

• Read More »

Just after 1:30PM today, I finished up my implementation of the first milestone of the NDWall project.  The best part was trying to figure out to construct the request to post new messages.  Here are a few screen shots of the app:

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.

• Read More »

The best way to learn a new programming language/environment is to make something practical with it.

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.

• Read More »

Wow. Wow. Wow.  Ubiquity. Like quicksilver for your web browser.

• Read More »

I want to thank everyone for their great outpouring of sorrow and commiseration when they heard I had reached my 30th birthday.  I guess I have to start "acting my age" and "knowing better," or something like that.

Anyway, thanks to everyone who sent a card.

(-:

• Read More »

One of the things that's been on my mind recently has been optimizing my work life so that I can either spend less time doing the same stuff or accomplish more in the same amount of 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.

• Read More »

As evidenced by my runnerplus page, I've reached one of my goals for 2008: I ran 500 miles. It happened right after the last long training run before the marathon. I definitely didn't expect to hit this milestone so soon in the year, but training for a marathon and logging more than 30 miles a week certainly got me there.

And speaking of the marathon, it was a lot of fun. We finished in 5:15:42, which is almost an hour and a half lower than my previous time. The weather definitely contributed to the better performance. The sun came out during the second half, but the ocean breeze kept temperatures down. Sara and I are already talking about doing it again next year.

One thing I noticed about training this time around is the sheer amount of energy and determination it takes to train. We started back in early January with little two or three mile loops and peaked in April with 147.4 total miles (almost 5 a day). May was particularly difficult because we started doing our weekday runs in the morning. It was great to run in the pre-dawn hours, but by 1 or 2 in the afternoon, our energy level was zilch. It was hard to concentrate at work and make it those last few hours. The weekend runs were almost a rite of passage. We'd get up as early as possible and then after two, three or four hours of running, we'd "lay low" the rest of the day. It was all we could do. Now that I look back on it, what really got us through was each other. It always seemed that when I didn't want to run at all, Sara was right there encouraging me and when she couldn't take another mile I was ready to go. I can remember toward the end of each successive long run cries of "you can do it" or "up and over" getting us through.

After all that, the marathon didn't seem so daunting in the days leading up to June first. However, we certainly hit the wall at mile 19 or so. As we pushed through we noticed more and more the shirts of other runners with Bible verses written on the back. One that stuck out was Philippians 4:13. Sara kept saying it over and over again, and our strength returned as we came through the other side. By the time we saw our family again at mile 24 we were running strong and knew we could finish well. In all my life, I've never felt anything like turning that last corner and seeing the finish line. We kicked hard and ran past the crowd with our hands in the air.

We're planning on running two more events this year; the America's Finest City Half Marathon and the San Jose Rock and Roll Half Marathon.

As far as mileage goes, I'm now up over 540 and who knows how far I'll run by the end of the year.

• Read More »

The recommendation I've heard most is that you should learn a new programming language once a year. I'm thinking my next one should be a functional language, like Erlang or Haskell.

I saw a Haskell snip today on Slick or Slack, and it definitely piqued my interest.

• Read More »

What Ruby on Rails is to web programming,

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.

• Read More »

I was handling a customer support request today and it read something like this:

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.

• Read More »