Anyway, it was a ‘Happy Birthday‘ email, and no, my birthday is not the January, 1st.

It’s very unlikely that I entered 01/01 as my DOB: I try not to tell it to online stores when the field is not required; even when it is I prefer to enter 02/29 to minimize the number of such automated HB congratulations.

So it got me thinking: why on earth would their database contain 01/01 as my DOB?

My best guess is that they are storing date of birth as a unix timestamp. And at some point the value I provided (NULL) got converted to 0 (zero).

And zero seconds since the Epoch means 01/01/1970: so, their software decided I just turned 45 and sent me a happy birthday email (I didn’t think it was possible, but my opinion about that particular store got worse).

What lessons should developers learn from this story?

1. Never use TIMESTAMP when you can use DATE data type. They are different, and date of birth is definitely a DATE.
2. Do not confuse NULL and zero (or empty string). NULL is a special value, meaning ‘NOTHING’. There are cases, when it’s the same as zero (e.g.: number of items purchased), but generally it’s not the same (as in my example with non-entered DOB).
3. Use DEFAULT values properly. 0 and NULL are not necessary the same.
4. Treat data carefully during upgrades/conversions. I’m not sure if the DOB field was there when I was registering at the website, but it could be introduced in the database later – and all old records may have got their values for DOB field set to 0 instead of NULL.

In my last guess is true, I’m not the only one who got that stupid ‘Happy Birthday’ notification when we should have received ‘Happy New Year’ notification instead.

Happy New Year to all (if any) readers of this blog!

Time:         Wed Sep 24 05:21:12 2014 -0500
Account:      val
Resource:     Process Time
Exceeded:     1844 > 1800 (seconds)
Executable:   /bin/bash
Command Line: -bash
PID:          21234 (Parent PID:21233)
Killed:       No

I was confused, because everything I was doing there ran smoothly and quickly – no scripts hanging or something like that.

Then I realized I could run `top` to see whether the process (I had its PID) is still there.

It was. It was my bash session. Server was notifying me that my terminal session was using resources excessively – by simply staying connected to the server.

Okay.

On June 27, 2010, between 06:00am and 10:00am CST, our Development and Database teams will be performing several upgrades of the infrastructure that support Orbit.

Jun 16:

On June 13, 2010, between 01:00am and 02:00am CST, our Product Support team will perform a reboot of ******.**.***** which provides load balancing services to you.

1 hour later:

Today you received a maintenance notification dated for June 13, 2010. The incorrect message was sent out and the correct will be sent at approximately 2pm CST.

5 minutes later:

On June 20, 2010, between 06:00am and 10:00am CST, our Networking group will be performing code upgrades on ******.***** to resolve several bugs.

3 hours later:

We apologize for the recent notifications which have had incorrect information. The correct change window for this maintenance is from 00:01 to 05:00 CT rather than 6:00 to 10:00 CST as previously sent.

The correct text should have read:

On June 20, 2010, between 00:01am and 05:00am CT, our Networking group will be performing code upgrades on *****.***** to resolve several bugs.

Jun 18:

On June 27, 2010, between 06:00am and 10:00am CST, our Development and Database teams will be performing several upgrades of the infrastructure that support Orbit.

Jun 25:

On June 27, 2010, between 06:00am and 10:00am CST, our Development and Database teams will be performing several upgrades of the infrastructure that support Orbit.

Jul 9 and Jul 15:

Scheduled Maintenance
June 24, 2010

Jul 19:

Emergency Maintenance
July 20, 2010

Well, my first CRM emailing script sent same email to couple of customers 5 times before I realized something is wrong in my coding. Since that, I have extremely strict testing policy for every application which sends out mass emails.

The easiest way to do a quick test is replacing actual customer’s email address with special test accounts in the test mode and counting number of emails received as well as validating their contents (proof reading + %username% quick tag replacements and such).

It doesn’t take much time but prevents you from annoying your customers – “hey, what kind of IT company are they if they can’t even handle their own mass mailing properly?”