The Eric Wroolie Blog

Overpass Experiences

  • Blog
  • Videos
  • Overpass Apps

Powered by Overpass Apps

Morning has broken

May 18, 2009 by wroolie Leave a Comment

My 11-year anniversary as a British resident passed this weekend.  11 years ago, I came to the UK without a job and without a plan of what I was going to do.

As I write this, it is Monday morning.  I am heading into London very early because I have to make time in my schedule for a meeting with the Chinese British Business Council.  It is 5:45am.  The sun is already in the sky and it is a beautiful morning.  I’m always surprised with how early the sun rises here in the summer time.  I know summer days are longer, but Summer days in San Diego are nowhere near as long as they are in London.

11 years ago, at this time of year, I remember going to bed in a very jet lagged state with a single plan – I was going to get up early, get dressed, and try to find a job.  I woke up in the morning with the sun shining through the curtains.  I went to the bathroom, took a shower, and got dressed.  I looked a the clock and was shocked to find that it wasn’t even 5 o’clock yet.  No one would wake up for a few more hours.  The streets were quiet, but the sun was shining.  Outside, it looked like the type of day where you could have a picnic. 

Today, on driving to the station (I didn’t take the bike because I’m in suit-mode), the Radio 1 DJ commented “No one is awake at this time of morning because they want to be.”  But, again, the sun is shining, the streets are empty.  I don’t know why no one would be awake at this time.  Is there really a reason to ignore a beautiful morning because of what the clock says?

The English Summer is here.  We get long days.  We get optimism—but still peppered with English pragmatism (venturing on pessimism) — “Yeah, but it will probably rain this weekend.”  We get beer gardens at the pub.  We get daylight until 10pm.

Filed Under: Living in the UK

Log Everything – do it for your support people.

May 8, 2009 by wroolie Leave a Comment

I’ve worked on a lot of systems over the past 11 years.  I heard the same discussions.  I heard the same arguments.  I’ve heard the same excuses.

One the issues that always seems to be in contention is how much a web application should log about user activity.  My stand has always been “Log everything you can about what is going on.  The only reason you should cut back is due to storage limitation.”  For some reason, this always causes arguments with my fellow developers.  (It ranks up there with the statement “Our app should be cross-browser compatible.”)

One of my big problems with applications written by junior (and some senior) developers is that they don’t log enough.  On a development machine or server, logging is not really needed—you can set a break point or log onto a server to see what’s going on.  In a production environment with tight change controls, this is not possible.

I’ve looked after third-party software applications in large companies which would routinely fail.  The company would spend a fortune for a software package from a small start-up no one has heard of.  We get this software, install it on our servers and before long, we have our first exception.  Angry users call me.  I call the vendor:

“We are getting an error number x00012012928 when click on the save button.”

“Hmm. What happens when you click on the popup?”, he asks.

“The application crashes.  Now no one can log in.”

“Can you check to see if the server is still up?”, they ask.  This is when I glean that he doesn’t really know what’s going on.  He’ll ask for a reboot next.

“The server is up.  I can still get to the web pages. But no one can save anything.  Can I talk to the developer.”

“I am the developer” the snooty developer replies.

“Okay.  So why is it doing this?”

“Oh.  Umm. . . .  It shouldn’t happen.”  Yeah.  No sh*t.

“What is x00012012928?" I ask trying to move things along.  “It looks like an internally generated error number.  A description of the error would have been nice.  I’ve checked event viewer but see nothing.  It looks like the exception is being caught, but not handled.  What would generate this number?”

“It could be a number of things . . . “  This is the wrong answer.  If you are going to raise your own errors, be as specific as possible.  You can’t anticipate every error, but you can differentiate between db or web error for example.   This conversation goes on and on where eventually I need to get someone with server admin rights to send him an IIS log so he can review it for a few days.  Meanwhile, I have to try to calm down an angry user base and continue to chase the vendor.

I’ve been in the above situation at least a half-dozen times in different companies.  It most definitely is not an exaggeration.

I like to contrast this with a friend of mine who wrote an application where he logged everything.  He kept log files as text files in a web root where he could access them securely with .htaccess rights.  Every day, a new file was generated and files over 30 days old were deleted. 

One day, he got a call from an irate user.

“I’m trying to use this rubbish application and it isn’t working.” angry user yells.

“I see. What is your username?” the developer calmly asks.

“John_Smith”

“I see you logged into the application 3 times today.  Did you get an error every time or just the last time.”  Already the developer with logged activity at his disposal knows more about the user’s problem than the user knows.  If there was an exception, he would have been able to see it in his logs.  If there is no exception listed, he can view user activity.  “I see the last page you accessed was the transaction details page.  Is this where you get the error?  Can you describe it?”

“The button does not show up to save the data I entered,” the calmer user explains.

“I see.  This is a common problem.  You left a mandatory field out.  You should see it highlighted in red.”

“Oh yes.  I see it now.  How did I miss that?  Thanks.”

So the developer had 3 things working for him:

1.  He had more information at his disposal than the user had.  He could identify an exception or user error.

2.  He did not try to make the user feel at fault when he clearly was.  (“This is a common problem” may necessarily be true, but there is no better way to put someone on the defensive than to accuse them of being wrong)

3.  He spoke in a calm, unassuming, and sympathetic voice.  A user can quickly tell whether you are doing everything you can to help him or if he has to try to prove to you that his problem is real.

So, I’m always in favour of extreme logging.  I hear the same excuses every time why this can’t be done.  “It will take up too much space.”  “It will be too difficult to clear down.” “Nothing should go wrong with the application, because we tested it.” “We will log the exceptions.  That’s all we need.”

Filed Under: Uncategorized

Nike “Onwards” Video

May 3, 2009 by wroolie Leave a Comment

So, Nike has this nice little animated video.  Like most things that Nike seem to produce media-wise (I’m not talking about the sweatshops), it’s more inspirational than anything else.

It’s a nice little video so I thought I would share it here:

Onwards from AKQA on Vimeo.

Filed Under: Running

  • « Previous Page
  • 1
  • …
  • 48
  • 49
  • 50
  • 51
  • 52
  • …
  • 111
  • Next Page »

Recent Posts

  • My Gig and the Imposter Syndrome
  • Getting Picked Last for Teams in PE
  • One Little Growth Opportunity at a Time
  • I’m sorry if I look like I know what I’m doing
  • New Years Reclamations