DevDog

3 Rules

There are 3 basic rules to software programming. Most people don’t know them. Or if they do, they probably don’t know how to properly articulate them. So I’m going to spell out the 3 rules for you. This was talked about a lot at my last job early on when dealing with problems and support issues. Just about everything came back to one of these 3 rules, and unfortunately, rule 3 was more popular than even we believed.

Cryptogram #1 – Solution

So, its been a few days, did you figure out the solution to our first cryptogram?

This one I thought was pretty easy if you are a geek. And seeing as my blog is pretty tech related, I figured that a lot of people would get this one. Maybe its just me, but when I see certain encoded lines, I can pretty much guess that they are encoded with base64. Maybe I’ve been around email too long.

Cryptogram #1

So I’m experimenting with a little contest to see how smart my 3 readers actually are. Every couple of weeks I’m going to post a puzzle. They’ll be pretty easy to start off with and get increasingly more difficult as time goes by and I have time.

Without further ado, here is the first cryptogram.

V2l0aCBmYWl0aCBhbmQgaG9wZSwgdGhlIGRyZWFtIGJlZ2lucyBhbmV3

Good luck!

For each cryptogram, the solution will be posted the following Monday.

Update: Answers are posted on Wednesday, not Mondays.

A device attached to the system is not functioning

As you’ve read before, I’ve had a variety of battles with the Hosted Messaging and Collaboration framework from Microsoft.

Today was another day for battle. And an interesting battle it was.

So here is the situation that I was running into. Within my code in the customer portal, I have a notification that is sent out that has a full back trace of what happened on the system, what was inputted and what was the error message that was returned. I of coarse try to give the user a friendly version of the error message to the screen before sending off this plethora of valuable detail. Out of this pile of data, I find the following error message has been returned:

One Character == World of Suck

Ladies and Gentlemen, today you are going to learn a lesson on why you do NOT edit the active directory directly for exchange attributes.

Background

A long time ago, we had a very crappy provisioning system for our hosted Exchange 2003 platform. It worked ok, but missed a lot of things that we wanted to have set. They also were kind of pricks when it came to licensing so making a ton of money on the platform was hard to do. So, we decided to roll our own. It wasn’t that hard to reverse engineer what was being set for users, groups and contacts. There were a few obstacles of coarse but we were able to get a pretty good provisioning system setup. However, this too had its faults. Sure we had total control over the code and could update things as we needed. But we were still working in a void. We really didn’t know _everything_ that was happening on the system that needed to actually happen. Plain and simple, we were missing things. Not to mention future services would require the same amount of dev time reverse engineering what needed to be set. That’s not a scalable solution.