The Eric Wroolie Blog

Overpass Experiences

Everyone’s You-Tubing

by Leave a Comment

In the past week, two friends have posted new movies on YouTube.

Ted Falagan (that’s what the T. stands for) my childhood friend and writer/director has made another new film with his Fault Line players in San Diego called Killers and Casualties:

Having grown up with Ted, I have to admit that I’m just a tad bit jealous here.

Charles Nwokolo, a friend I worked with at BNP Paribas, posted this topical video on the state of fame:

I’m starting to think that maybe I’m wasting my time with all this . . . typing.

 

Morning has broken

by 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.

Log Everything – do it for your support people.

by 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.”