Tag Archive for 'development practices'

Tracking Changes in Your Database

Everyone likes a good story, even one that relates to a database. When you are working with a database that is shared among different users you will eventually see this scene, or perhaps experience it yourself:

You, or someone else, are staring at the computer screen looking at a record that has changed since the last time you looked at it and you mutter to yourself, “Who changed this record?  This is not the same as the last time I looked at it!”

An audit log is like looking at a record through time.  It will let you trace any changes that have been made on a piece of data in your database.  For example, in a contact management system an audit log will let you see address changes over time for a particular person.  You can use an audit log in an ordering system to track changes made to each invoice over time.  It is also an important tool for determining workflow processes. Remember the old adage, “who what when where why and how”.  Who changed this record? What data was changed? When was it changed? Why was it changed?and How?  An audit log can tell you all of these things (except probably the “Why”).

Continue reading ‘Tracking Changes in Your Database’

 

I’m just a stupid developer, don’t confuse me… part 3 of 3

I’ve been posting about a few principles that have helped me minimize the pain of understanding complexity in my own code. See part 1 of this series where I briefly discussed leaving yourself and others notes about the “why” of your design decisions. And see part 2 for discussions about simplifying your code.

Continuing with the movement towards simplicity; whenever possible make functions and scripts single use and encapsulated. We can think about breaking functions (or scripts) down into their smallest useable parts as simplification, or we can talk about it as encapsulation. We broke down a confusing custom function into separate parts in order to improve readability. What we also gained was some compartmentalization and modularity. It’s difficult to separate the two principles of simplicity and encapsulation.

Continue reading ‘I’m just a stupid developer, don’t confuse me… part 3 of 3′

 

I’m just a stupid developer, don’t confuse me… part 2 of 3

See part 1 of this series where I briefly discussed leaving yourself and others clues about the “why” of your design decisions.

The second principle I want to talk about helps with the “how” and “what”.

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.
- Albert Einstein

Or how it’s more often paraphrased:

Make things as simple as possible, but not simpler.

Take the time to make things simpler. This is much more about the “how” and “what” of programming.

Continue reading ‘I’m just a stupid developer, don’t confuse me… part 2 of 3′

 

I’m just a stupid developer, don’t confuse me… part 1 of 3

Our human brain has the amazing capacity to remember and understand the things we do. What’s more amazing is our brain’s capacity to overestimate how much it has the ability remember and understand the things we do. My average shelf life for remembering how my code works is about two months. That is to say if I don’t touch a part of an application for up to two months, I can jump in and get back to work, no problem. After that I have to study it a bit and get my bearings again. The longer I go the worse it gets. Your mileage may vary, but no one can escape this problem.

There are a few things that have helped me minimize the pain described above, which I’ll be posting about over the next couple of days.

Continue reading ‘I’m just a stupid developer, don’t confuse me… part 1 of 3′

 

Speak your Mind. Using Comments, part 1.

Recently I was on a family trip to Pittsburgh.  We were walking around the campus of Carnegie Mellon and I saw this memorial brick;
Eschew Obfuscation

It got me to thinking about some of the monster databases that I have had to take over for clients.  When I take over a project, often I am spending a great deal of time just trying to figure out what the developer was trying to do.

Our earlier posts on this blog are generally concerned with improving the user experience(better printing workflow) or getting more out of your data (One Report two sets of summarized data).  Today I would like to return to that lowly person, the developer.  Anything that I can do that can make my job easier will make be a better developer and ultimately make my customers happier.  Or as my grandfather would say to my grandmother, “What would you do if I got hit by a bus?” Continue reading ‘Speak your Mind. Using Comments, part 1.’

 

PauseOnError Day 1

My wife, 3 year old son and I hopped in the car at 6:30 this morning and headed north from Philly to NYC.  I was headed to PauseOnError; Andi and Sam were going to hang with our Brooklyn friends, some of whom we hadn’t seen since we moved from Brooklyn in 2007.

I arrived at the Ace Hotel – a gorgeous, hipsterish old/new world style hotel on 29th street – close to 9 AM and squeezed into the crowd in Molly Connolly’s room for the intro session.  I then spent the better part of the day hopping around the various sessions and talking.  The mood was pretty festive and congenial, like partying with a bunch of geniuses.

Continue reading ‘PauseOnError Day 1′