Web Africa Programmers... not evolved yet?

Hi All,

We do apologise for the mail sent out earlier, we were performing an update to our mailing system and performing a dry run using real data to see how well it functions in a production environment prior to making it live. Unfortunately an error with the code itself resulted in that dry run instead being a live one.

Once we had realised what was happening we disabled the system and identified where the error was situated, the problem has since been resolved. We do agree with using a sandboxed environment in which to perform development, and in most cases this is what we do. However, ultimately testing must be done in a live environment to ensure all is 100% prior to making it truly live.

Again, we apologise and will be working on preventing this from happening in the future.

Usually when I do a dry run on a live environment with bulk emails I disable the SMTP service and let the emails queue, this then gives me the opportunity to investigate if the email is formatted correctly and sent out to real recipients. Once I've confirmed this I delete all the mails in the queue with no NDR. Using a test SMTP server usually gives you that edge (because its on a live network that nobody uses, you can stop the services)

I agree, dry runs etc... but next time keep in mind that **** can always hit the fan
 
I guess some people have too much time on their hands.. they sit and bitch about other people's mistakes and don't actually do anything else..

Acid has wasted at least 30-60 minutes bitching and moaning about 1 accidental e-mail.. With all the crap with Telkom, the gov't, other idiots and the crappy customer service in SA, you must not get anything done.. do you have time to eat, sleep and work?

Actually, this can't be considered spam, globally SPAM is unsolicited mail from an unknown source. You are a client of WA (prior or current relationship usually disqualifies an e-mail as being spam) and most likely have the option of opting out of their newsletters/updates.

If this would have been exposing client specific information, then that is different. It was basically a blank e-mail.. get over it and get a life.

There are more important things than 1 accidental message.
 
Actually, this can't be considered spam, globally SPAM is unsolicited mail from an unknown source. You are a client of WA (prior or current relationship usually disqualifies an e-mail as being spam) and most likely have the option of opting out of their newsletters/updates.
Globally
There is no reason why someone or somebody known to you cannot spam you.
 
In most countries (not SA apparently) spamming is unsolicited mail. If you are doing business with someone you are soliciting to them or vice versa. Therefore you have a relationship with them and can't (typically) be considered spam. You also have to have the option to opt out.

Globally= anywhere in the world. Not the internet according to Telkom and mWeb...

SA is still in the dark ages and most of the mail servers are not compliant to standards (no ptr, etc..). Until you can purchase a gigabit connection for under R150k per month in SA, things will stay this way.. Now that is all Telkom's fault..

If you want something to complain about, Telkom spends very little for their international bandwidth (mostly peering arrangements), probably less than R400k per month (which would buy about 5-10gbps easily). They turn around a screw the country instead.
 
Last edited:
Mistakes should be made on your dev environment and tested and tested AGAIN before anything should go live.

And because Live and Dev are two different environment, you will get situations where bugs leak through. Some idiot may even have hard coded a database to dev. One doesn't know what happened but people do make mistakes. A bogus email is not IMO the end of the world.

There are IMO different priorities. At my last job, someone sent out an email with all of the employees salaries. That is serious. I think the aggression in your post was not in line with the level of error that occurred.

Usually when I do a dry run on a live environment with bulk emails I disable the SMTP service and let the emails queue, this then gives me the opportunity to investigate if the email is formatted correctly and sent out to real recipients. Once I've confirmed this I delete all the mails in the queue with no NDR. Using a test SMTP server usually gives you that edge (because its on a live network that nobody uses, you can stop the services)

And how do you test the SMTP functionality without actually sending mails? You will probably say send 10 emails but how would that be testing the load capability of the system? If I need to send out 100000 emails, I need to know that the server/system can handle this. Obviously I would not do a test run to 100000 people. I am just trying to say that people can do all of the testing in the world and problems do occur.
 
I guess some people have too much time on their hands.. they sit and bitch about other people's mistakes and don't actually do anything else..

Acid has wasted at least 30-60 minutes bitching and moaning about 1 accidental e-mail.. With all the crap with Telkom, the gov't, other idiots and the crappy customer service in SA, you must not get anything done.. do you have time to eat, sleep and work?

Actually, this can't be considered spam, globally SPAM is unsolicited mail from an unknown source. You are a client of WA (prior or current relationship usually disqualifies an e-mail as being spam) and most likely have the option of opting out of their newsletters/updates.

If this would have been exposing client specific information, then that is different. It was basically a blank e-mail.. get over it and get a life.

There are more important things than 1 accidental message.

I can't remember if i ever bitched about it being spam. I bitch because I can (I think you're based in America now right? Check your rights, one of them is that I can bitch as much as I want)

As to exposing client specific information, I've seen this happen several times with WA, and its a small step away from possibly exposing this information. It's not a once off matter. And I will take the time out of my day to point out mistakes people make because I want them to IMPROVE their service.

Plus, this is what south africans do best.... bitch and moan
 
In most countries (not SA apparently) spamming is unsolicited mail. If you are doing business with someone you are soliciting to them or vice versa. Therefore you have a relationship with them and can't (typically) be considered spam. You also have to have the option to opt out.

Globally= anywhere in the world. Not the internet according to Telkom and mWeb...

SA is still in the dark ages and most of the mail servers are not compliant to standards (no ptr, etc..). Until you can purchase a gigabit connection for under R150k per month in SA, things will stay this way.. Now that is all Telkom's fault..

If you want something to complain about, Telkom spends very little for their international bandwidth (mostly peering arrangements), probably less than R400k per month (which would buy about 5-10gbps easily). They turn around a screw the country instead.


You really have spam on the brain don't you?
 
And because Live and Dev are two different environment, you will get situations where bugs leak through. Some idiot may even have hard coded a database to dev. One doesn't know what happened but people do make mistakes. A bogus email is not IMO the end of the world.

and that is just one such example.
Most companies are not in the position to afford a dev server identical to the live one.
What with SQL server fees (enterprise is $20-30K ?), sever costs and so on, most dev machines are probably running MSDN developer software - which is different.
In addition, these machines are often underpowered compared to the live one, and lack clustering / mirroring / log shipping and so on.

If your dev environment perfectly duplicates your live, then:
  • You are a very large corporate, OR
  • using pirated software, OR
  • have WAY too much money to waste

    Even if we remove M$ from the equation and you use OpenSource, how many of us are fortunate enough to have dev environments with multpile CPU machines, with RAID drives, and all in a nice high-availability system?
    Hands up?
    Thought so.




 
And because Live and Dev are two different environment, you will get situations where bugs leak through. Some idiot may even have hard coded a database to dev. One doesn't know what happened but people do make mistakes. A bogus email is not IMO the end of the world.
By making sure dev is an exact copy of live in all manner. Thats why you don't dev on a windows 98 machine when you're developing for a windows 2003 server. Monkeys know better...

There are IMO different priorities. At my last job, someone sent out an email with all of the employees salaries. That is serious. I think the aggression in your post was not in line with the level of error that occurred.

True, but I'm making sure that this does not happen by being aggressive about this. Their programmers are on the verge of sending out some kind of sensitive information, and if you didn't notice in my signature, I kinda like them. I've seen one company fail dismally because of the stupidity of one person... see this as a precautionary measure from a loyal customer

And how do you test the SMTP functionality without actually sending mails? You will probably say send 10 emails but how would that be testing the load capability of the system? If I need to send out 100000 emails, I need to know that the server/system can handle this. Obviously I would not do a test run to 100000 people. I am just trying to say that people can do all of the testing in the world and problems do occur.

Live SMTP should be able to handle this load already seeing as they already send out thousands of emails per day, so thats why you set up a dummy/test SMTP to test your new bulk email code.

Testing the mail server to see if it can handle bulk email and testing your code that sends the bulk email is 2 different things and should be handled that way... separately.
 
Last edited:
and that is just one such example.
Most companies are not in the position to afford a dev server identical to the live one.
What with SQL server fees (enterprise is $20-30K ?), sever costs and so on, most dev machines are probably running MSDN developer software - which is different.
In addition, these machines are often underpowered compared to the live one, and lack clustering / mirroring / log shipping and so on.

If your dev environment perfectly duplicates your live, then:
  • You are a very large corporate, OR
  • using pirated software, OR
  • have WAY too much money to waste

    Even if we remove M$ from the equation and you use OpenSource, how many of us are fortunate enough to have dev environments with multpile CPU machines, with RAID drives, and all in a nice high-availability system?
    Hands up?
    Thought so.





With Web Applications you only need to have the server software setup correctly, doesn't matter re: raid drives or speed of CPU etc. Most companies who don't have the money to invest in additional server software use their brains and get the Microsoft Action Pack. Costs are minimal and you get all the software and licenses for free (I think the only one you pay for is the OS)
 
and that is just one such example.

If your dev environment perfectly duplicates your live, then:
  • You are a very large corporate, OR
  • using pirated software, OR
  • have WAY too much money to waste

    Even if we remove M$ from the equation and you use OpenSource, how many of us are fortunate enough to have dev environments with multpile CPU machines, with RAID drives, and all in a nice high-availability system?
    Hands up?
    Thought so.

Pick me. I work for a 'large corporation'. haha

Dev. QA and Prod servers.
 
By making sure dev is an exact copy of live in all manner. Thats why you don't dev on a windows 98 machine when you're developing for a windows 2003 server. Monkeys know better...

But it can never be an exact copy. IP Addresses, Databases (I would hope) etc are always going to be different. Hardware is more then likely going to be different as people don't have R700K to spend on a Dev box. The point I am trying to make is that there because these environments are different, there is always a potential for issues to creep in, not matter how much you test.

In an ideal world, one would have a Dev, Test, Qual and Live environments and the likelihood of issue creeping in are almost zilch.

see this as a precautionary measure from a loyal customer
Indicating that someone should lose their job does not sound like a precautionary measure. It sounds rather drastic in my book.

Testing the mail server to see if it can handle bulk email and testing your code that sends the bulk email is 2 different things and should be handled that way... separately.

But how do you test the mail server :)
 
I think MS don't charge for SQL dev boxes.

They do - but only a small fee. The point is (as you have said in this thread), is it is still no tthe same system.
There are a host of things that differ - and most companies simply cannot afford to have two systems that are identical.
Let alone spend months on one deployment...

In the words of a wise man, "**** happens".

The worthy stand up and apologise and move on.

I can barely even count the times bugs were released in our systems - and I have been developing for a goodly long time. Had a couple this week alone. Anybody who can stand in front of me and claim to have bug free code is either a liar, or should go apply for the role of God.
 
Top
Sign up to the MyBroadband newsletter
X