I'm all geeked up
Yep. I did it. I relived the pressures of my Math 8 final. I'm pretty sure I perspired a bit more at the real final though.
I don't know who this mm53bar guy is, but damn he's starting to freak me out. I used to go on those same type of road trips to the Loops and Cariboo College as a kid. And ooooooooohhh did I know I was a geek. I embelished it for humor's sake. Hell, I have a picture of me biting the medalion for Grade 12 Math achievement like I had just won a gold medal in the Olympics....yah.....geeky. To top it all off I even started my post secondary education at Cariboo College as a Math/Physics double major.
| You Passed 8th Grade Math |
![]() |
MSMQ Triggers and COM Components
I'm well past working on the first version of the MSMQ portion of our software project. As I'd mentioned before, I am going to post more info on the use of Invocation Parameters and their use when calling COM components. I should prefix this with the fact that all my experience is with MSMQ v3.0 on Windows 2003 Server.
There are a number of things that you must do to even have a shot at getting the MSMQ Trigger service to call a COM component.
1. If you are writing the component in .NET you will need to make it strongly named.
2. The class and the public function/methods in the component will need to be marked with[ComVisible(true)]
3. Your code will need to swallow all exception. If it does not the MSMQ Trigger service will stop. Not a good scenario.
4. When installing or upgrading the COM component you will need to perform a regasm <componentname.ext> /unregister and a regasm <componentname.ext>
5 After installing the component it will be in your best interest to restart the MSMQ Trigger service. I have run into situations where the install will complete successfully but the messages will just pile up in the queue not getting processed. Restarting the Trigger service will solve this.
6. Regardless of if you are working with a COM component or not, if you use the MessageQueue.Exists(QueuePath) method it will always throw an error/exception when the QueuePath points at a private queue. I, and Microsoft, guarantee this.
There are also a number of coding situations that you will most likely need to accomodate when you are having the MSMQ Trigger service call your component. Probably the one thing that you will most commonly do is have the Trigger service pass the Message Body to your component when it is called. What good is calling the component if you aren't going to be able to get the info from the message. A couple of other things that I have needed to work with are the Message ID and the Sending Queue. So how, you ask, does one configure the interface of the function that the Trigger service is calling? I don't know for sure how to call all the different Invocation Parameters so I will only concentrate on these three.
As with most of my luck, three different parameters equals three different incoming data types. Here's how I ended up coding the interface to my function (code changed to protect innocent programmers):
public void ProcessMessage(object objMessageBody, object objMessageID, string strSendingQueue)Okay. We see here that two of the three values are being passed as object and the third is passed as a string. The third one is the easiest. The value coming into that parameter is a simple string that is all inclusive of the data that you would need to do the following:
MessageQueue objMsgQueue = new MessageQueue(strSendingQueue)
The other two parameter are substantially different than the Sending
Queue. Lets continue with Message ID. This value comes from
ojbMessageID as a byte array ( byte[]
) If you look at the MSMQ Queue listing in MMC, you will see that
all the messages appear in that UI having a Message ID that is the
equivalent of <GUID>\#####.... At first glance the byte
array is longer than the 16 bytes that make up a GUID, but it doesn't
appear to have enough bytes to hold the number suffix either. I
played around and found out that the first 16 ( byte[0] to byte[15]
) can be used to create the GUID and the remaining bytes can be used to create the suffix number as follows:byte[] arrMessageID = (byte[])objMessageID;
const int GUIDLENGTH = 16;
string strMsgID;
int intMsgSuffix;
byte[] arrMsgGuid = new byte[GUIDLENGTH];
for(int i = 0; i < GUIDLENGTH; i++)
{
arrMsgGuid[i] = arrMessageID[i];
}
intMsgSuffix = 0;
for (int i = 0; i < (arrMessageID.Length - GUIDLENGTH);i++)
{
intMsgSuffix += arrMessageID[GUIDLENGTH + i] * Convert.ToInt32(Math.Pow(Convert.ToDouble(GUIDFACTOR), Convert.ToDouble(i * 2)));
}
strMsgID = new System.Guid(arrMsgGuid).ToString();
return strMsgID.ToString() + "\\" + intMsgSuffix.ToString();
Right.....so now we have the Sending Queue and the Message ID. Next stop bodyville. I only had one value to pull from the body of the message and it was always going to be an integer. Probably the most simple scenario that I could have to fight with. The Message Body arrives in our object parameter as an XML stream. Here's the code I used to grab my one integer value from the body.
int intValueFromBody;
Message objMsg = new Message();
objMsg.BodyStream = new System.IO.MemoryStream((Byte[])objMessageBody);
objMsg.Formatter = new XmlMessageFormatter(new Type[] { typeof(int) });
intValueFromBody = (int) objMsg.Body;
Like I said earlier, I have not had the pleasure of grabbing multiple values from the Message Body, but I'm guessing that I'm pretty close with this code.
Well folks, that's all that I have.
Programmer Characteristics
I'm sure you've all seen or made jokes about the things that make us programmers such a unique bunch. Things like socially inept, introverted, and fashionably challenged. Sure, you can take the easy road and pin us all together with those easy stereotypes, but let’s try for something a little more difficult.
For the last month or so I've been reading Code Complete. One of the last sections of the book, entitled Personal Character, was quite interesting and provided a look at the softer side of the people that are programmers. It covers everything from curiosity to laziness and habits. For those who haven't read the book at all, I recommend it. If you are looking to understand what should be driving programmers, and nothing else, read this chapter. Remember that it is only what should be driving programmers though.
We've all worked with them. They're lazy. The first ones to be gone at quitting time. Heck this type of coworker isn't restricted to the IT industry, but they certainly exist there. I worked with a guy a few years ago that would be gone from the office right at quitting time. If you saw him on his way out you would have thought that we had started spraying Anthrax into his office. It was so bad that if he had to transfer some information to you, so you could stay late and get some of his work done, he would rush through it in an attempt not to have to go back to his office after the Anthrax had been released. His effort during the day was limited to whatever minimum amount was needed to get the job done before quitting time. He showed no desire to keep himself productive or busy. All the things that endears coworkers to their teammates. I'm sure he was a decent guy, but his actions at work made interacting with him a curt and tense situation.
Tonight I was staying late at work to do some builds and installations into testing environments. Right near the end of the work day a coworker and I began debugging a defect that had just been discovered. Immediately we knew who had written the original code and said programmer was still at his desk. We determined that the code was at fault and not the database (it was a saving issue), and with all the timing in the world the original programmer decides that it's time for him to go home. Being the good guy that I am, I yelled at him (let us call him Ned) as he was leaving something like "He Ned, your code isn't working right wanna give me a hand?". Okay, that's the G rated version, but it gives you the basic idea. So we start walking through the code and notice the problem area.
Ned (without hesitation): The spec has changed.
Me: Ummmmm....OK.....it changed to state that this one entry should never be saved?
Ned: Well, maybe not.
Me: I didn't think so.
At this point I began to fix the offending code always checking with Ned to see if he knew of any reason that my changes would cause issues with the specs. Finally we get to the point of testing my updated code. Sure enough it doesn't work. Off we go on our debugging journey once again. I'm stepping over functions and checking the return values in the Watch window when I notice that a static datatable suddenly drop to 0 records. Let's return to the dialog now.
Me (mostly thinking out loud, but partially ensuring that Ned was still focused): Shit. Why the hell is it deleting that row in the validation function?
Ned: Okay, I'm going home now then.
Me (staring at his back disappearing through the doorway): WTF is he doing?
Other Programmer (aka Giggles the Clown): hehehehehehehehehe
Me to Giggles the Clown: Do you know of a way to rig up hand grenades to an office chair?
I learned tonight that not all people take ownership in their code. Not all people can sense urgency. When you get right down to it, some people think of a job as what you fill the time between morning coffees and quitting time with. I have half a mind to put Code Complete on his desk and suggest that he read it immediately. I just don't know if he'd ever do that, and if I'd ever get it back.
Damn Email
Coding Responsibilities
"In software development, we need to have personal quality assurances from developers that the code they write is secure"
"We need individual accountability from developers for end-to-end solutions so we can go to them and say: 'Is this completely secure?' "
For the past 5 years I've been working on software systems that manage and maintain data that is both sensitive and has had extremely high requirements for calculation accuracy. Sure they've not been systems which controlled aircraft, kept the pace set by pacemakers or dispensed cash from ATMs,but all the same, the clients and the people who's data was being stored would have thought the system required complete accuracy and security. When I'm working on any code I pride myself in writing solidly and bug free. I take ownership in both my code as well as the project as a whole. Not everyone does and not everyone needs to go to that extent.
I'm having problems wrapping my head around what Mr. Schmidt says. To me it sounds like he would like to find a way to hold every developer personally liable for code that they have written. I'm having problems with two things. Personal liability and the code I have written. The problem I have with the code I've written isn't because I distrust it's current state. Au contraire, I stand by it firmly. My problem is how do I even try to identify "my" code? Sure I wrote specific lines of code in a project. That code then was debugged by a different developer at some point and altered to change it's behaviour. Some time further down the road, that altered code was refactored or added to when new functionality was required. So now is that my code, is it the debugging developer's code or does it belong to the developer that refactored it? Let's even make the owner of the code more confusing. I write an entire module and another developer extends the module with new functionality. Am I the code owner of the module still? What about the situation where the architect's design the root of the security problem? Do we still place responsibility for writing the code, as requested / required, on the developer? What if the client has made a ludicrous request resulting, that they can't be talked out of, that opens a security hole? What then?
What I'm getting at is that ownership of code doesn't ever belong to one individual. At best it belongs to the team. More likely it belongs to the company or the client. Regardless it belongs to the developer, the team, the company and the client a little each. How can you assign liability to only one portion of a collaborative process?
I believe that feeling responsibility and having pride in the code that you write is very important. Enforcing or legislating this would be impossible.
The End of an Era
- "I left my last job because I had to do too much JavaScript and
UI." Sure. Most of us would rather be doing other things.
(Slim promptly assigned him to backend C# code.)
- "I don't like writing business logic." Okay.....but why did
you take a job with a consulting company then? We will never be
doing anyting but UI and business logic, and we already know what he
thinks of UI.
- "I want to get back to Java. Doing .NET has made me be treated like a junior programmer." Interesting statement for a guy with over ten years of experience and an MCSD. One would think good code, but that isn't the case. I know this because I'm re-writing a lot of what he created. Maybe it was nothing more than a complete lack of interest in what we were doing (see two points above), but it certainly makes him look more junior than anyone else on the team.
- "This UI stuff is giving me problems." Well....you're adding an image to a table......hmmm......Ahhhhh, poor muffin....
- "I have defects in the tracker? You mean I have to look in
it?" Ummmmmm....Easy Aragorn....easy....... I'm surprise
that she didn't do unto him as she might to an Orc.
