Blog Home  Home Feed your aggregator (RSS 2.0)  
Rays Development Blog - Saturday, October 11, 2008
A look into the mind of a VB Developer
 
# Saturday, October 11, 2008

Recently, in one of my many quests for knowledge about the good old NNTP protocol (be on the lookout for a really cool Usenet news reader to be released by Enterprocity within the next few months) I was pointed towards something called Postel’s Law, also referred to as the robustness principal.

 

In a nutshell the law is simple. It states:

 

“Be conservative in what you do, be liberal in what you accept from others.” – Jon Postel

 

You can see it for yourself right here at the bottom of page 12 in RFC 793 (TCP).

 

Since I am embarking on my new role as a Senior Software Engineer next week I thought that me getting pointed to this quotation form Jon Postel was quite apropos.

 

This is something that I have seen so much of over the last few years as my old role as a Senior Applications Engineer, both in the products that I supported as well as in the products that I helped others build. Many times companies can get involved in a finger pointing match over who owns a bug (us or them, it’s not OUR fault) or if something is even a bug or not. Many times engineering would point to a message we got from another component in the users solution (we did VoIP Gateways talking SIP so in these cases is was SIP messages) and said that the message was malformed in some way, and this was why our stack threw it on the garbage heap, or leaked memory, or threw an exception, or dropped a call, or some other undesirable behavior that caused someone to pick up their land line and call me.

 

It all boiled down to Postel’s Law. The third party SIP stack that we used (no names here please) was not very robust at all in its ability to take in things that were not 100% to the RFC. It was a good stack that did its job and had a good team behind it but when it came to handling SIP messages, it was very picky to say the least. One message that was not a complete verbatim to the ABNF used in the RFC and that message was ‘wrong’ and the behavior was indeterminate. That and the fact that there are some really nebulous areas in the RFC that did not help, made it look at times like the product had some serious issues, and in my opinion it did, from a users perspective. Taking this to another level, many of these malformed messages were in message headers that our product did not even care about, that just ended up adding insult to injury there.

 

In user land, people don’t care about all the stuff behind the scenes; they just want things that they paid for to work. Add to the fact that other products that may not have been better in all other respects did not have a problem dealing with these errant messages, and our product became even more suspect in the eyes of the customers. All engineers need to understand that a customer’s perception is reality. Even if YOU, as an engineer, know that the problem is really NOT with your product but with the other one, or a bug in a third party component that you use in your system, the customer sees an exception thrown in YOUR product or poor behavior in YOUR product and not the others; your product is the one with the problem.

 

So, this is just gentle reminder to all engineers out there (myself included) that not only do you need to validate all input to your systems (a good thing that some of us may take way too far) but you also need to decide HOW you are going to act when you detect that bad input. Throwing an exception when you are the upper layer, right next to a human user, may not be the best (be on the lookout for a posting on the use of exceptions :) ).

Saturday, October 11, 2008 12:54:58 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Design | Error Handling  | 
# Tuesday, August 05, 2008

Well I decided that I REALLY wanted to run Vista after all, so, since my old system had a problem with the video cards (they were only PCI) I decided to build a new system that WOULD be able to kick Vistas butt.

I think this one certainly qualifies. As you can see form the photo bellow, the heat sink on the darn CPU is the biggest I have ever seen.

Specs:

  • iStarUSA S-10000 ATX Full-Tower Server Case
  • Crucial Ballistix Dual Channel 4096MB PC6400 DDR2 800MHz EPP
  • Intel Pentium D 945 Processor HH80553PG0964MN - 3.40GHz, 4MB Cache, 800MHz FSB, Presler, Dual-Core
  • EVGA nForce 680i SLI Motherboard - T1 Version, NVIDIA nForce 680i SLI, Socket 775, ATX, Audio, PCI Express, SLI, Dual Gigabit LAN, S/PDIF, USB 2.0 & Firewire, Serial ATA, RAID
  • 2 - EVGA GeForce 8800 GT Video Cards - 512MB DDR3, PCI Express 2.0, SLI Ready, (Dual Link) Dual DVI, HDTV, Video Card
  • Thermaltake CPU Cooler / Big Typhoon VX / 4 in 1 / 6 Heatpipes / 120mm Fan
  • Ultra X3 ULT40064 1000-Watt Power Supply - ATX, SATA-Ready, PCI-E Ready, Modular

Damn! This thing is FAST! and runs Vista like a champ. The modular Power Supply is cooooooollll. No wires in the case but the ones you need. Rocks sweeeet!

So, now thew question is what do I do with my old system? A dual, dual core with Hyper-threading XEON 3Gig system.

I can't let the secret out right now but around the end of the month I might spill it... I do have plans for it though...

Tuesday, August 05, 2008 12:01:44 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Hardware  | 
# Wednesday, July 16, 2008
Opening post!
Wednesday, July 16, 2008 10:49:06 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Site Admin  | 
Copyright © 2019 Raymond Cassick. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: