Wednesday, June 29, 2005

I love Portland Patterns Repository

It seems that my idea of Firefighting simulations were already invented. There are two patterns on the PPR, one is Defect Seeding and the other is Mutation Testing. It seems that my firefighting simulation is exactly the Defect Seeding pattern and Mutation Testing is a technique for automatically changing programs and finding unit test failures.
Well, maybe some day I invent something that was not already invented. But I still think it may be useful here, and probably we'll start using it.

Monday, June 27, 2005

Little known, powerful APIs

Today, I'm working with an Exchange Event Sink. This article is an invaluable source for starting things. It may not be complete, but I'd spend at least two weeks digging the Exchange SDK to accomplish the same thing.
What I'm trying to do is a better integration between Exchange and Microsoft CRM. If this works, I'll publish it as an article. Microsoft CRM 1.2 standard e-mail support sucks: it needs a GUID on the subject with every message, it has no way of importing messages, the Exchange router is rudimentary at best.
For me, an obvious way of integrating Microsoft CRM and Exchange would be: for every e-mail that comes to CRM accounts, lookup the CRM based on the e-mail address and associate it with the proper contact. Either I'll discover that this is a stupid way for some reason, or I'll come up with something better than Microsoft did. I rarely bet I can do anything better than MS, but this time I'm pretty sure of this...
And what does this have to do with "Little know, powerful APIs"? The lesson here is: never underestimate those lesser known APIs, like Exchange APIs. Some of these APIs are very powerful, and you can produce some powerful software. Since those APIs are known only by a few programmers, often you can produce softwares with very little competition, if any.

Monday, June 20, 2005

Firefighting training simulations for testing code

I was watching this documentary about a new super cool firefighting training simulator, which was affordable enough that even small companies could use and that was very effective in detecting failures in firefighting procedures. Those failures, on real world situations, could lead to disasters, causing injuries and even deaths.

So, an idea stroke me: what if we did the same thing in software world?

I'll explain: most decent software companies now have a well-defined software testing process. But how can we detect problems on those testing procedures?
Let's say we stopped a bit every now and then to make a bug detection simulation.

One or two programmers would be responsible for intentionally introducing bugs that could cause a disaster. Only those programmers would know which bugs were introduced. The idea is making things fun, like a game, where those programmers try to break the testing process and the testing staff try to find those bugs as quickly as possible.

A summary of the simulation would be:

After finding (or not) the bugs and finishing the simulation, a few things should be assessed:

Friday, June 17, 2005

My own Daily WTF

What would you think of a programmer that coded an abstract class as a concrete class, and, instead of marking a few members abstract, implemented them as virtual and threw a "NotImplementedException"?
Well, I can imagine your face, and yesterday I was strugling again with System.Net.WebRequest and its memory leaks, trying to implement a new HttpWebRequest that used only WinHTTP to eliminate memory leaks definitively from every WebServices call we have. The funny thing is: WebRequest is a class coded like that. Someone at MS certainly think it's brilliant coding like this, and throws NotImplementedException on their code, instead of marking their members abstract.
A friend of mine here insisted that MS is not that bad at coding (and I do agree), and that there should be a good reason for that.
Today, I was reading my RSS feeds, and I found this post at The Daily WTF, describing a similar situation...
Sorry for my friend, but I really don't think that there's any good use for something like this.

It's been a long time...

Since I last posted... But this blog is not abandoned, only neglected :)
The truth is that I assumed the responsibility for both the sales and technical departments, and I was really tied to lots of meetings and understanding how I could make things work better, specially with our sales staff. Selling, instead of purely programming, is a new thing for me, and it's being great to grasp some sales concepts and gaining experience in another area. I've been programming since I was 11, this means that I am programming for 23 years as of now. I never worked with anything else, and go to sell my own software is a great experience, as I hear a lot of good things from our customers.
But I still code a lot, and I'll update more this blog from now on…

This page is powered by Blogger. Isn't yours?