…spices, at last :) Here at the Vamsoft HQ we have a nice backyard, an ideal place for a sunny mini spice garden. During the long winter (starving for fresh summer basil and tomatoes), I decided to finally utilize the backyard and plant a few of my favorite spices and herbs. The ORF Tech Support guy, Krisztian also liked the idea, so last Thursday we took the seeds, the flower pots, some soil and made our little garden with thyme, origano, basil and rocket/rucola.

I was a bit concerned about planting too early, but this morning I was suprised to see that only in five days the rocket started growing! That means pesto di rucola with fresh gnocchi within 2 weeks! :) No wonder why English calls rucola “rocket”.

Meanwhile, we have relased the 4th development release of ORF, with minor adjustments to the PowerLog format. The PowerLog report preprocessor is nearly complete, it is going to be integrated with the ORF Service in the next few days. The technology research with the embedded Internet Explorer control was successful, so now it is pretty sure that we will use embedded HTML for displaying and printing reports. Also, the decision has been made about the report resolution: it is going be 1 day, which means that the shortest period of time that reporting will handle is one day.

Well, this had to come. When we compiled the feature set for ORF 3.0, my estimation for Reporting was 35-49 days—making it the biggest single feature we ever added to ORF. This estimation assumed that reports will be generated from the current logs, but later several problems were identified with this concept. We faced with a decision: either we will generate reports that A) are useful, or just generate B) some eye-candy summary. We decided to go with the option A), which required a new logging medium and lots of related work, doubling the resources needed. This is reflected in development: we are about to reach the 49 days limit and Reporting is about halfway to be completed.

It became obvious that Reporting will predate other planned features of ORF 3.0. We have updated the ORF Development Roadmap according to this.

We apologize for this feature creep, I know many of you expected these features much. We will do our best to get them into ORF as soon as possible.

Refactoring done, PowerLog support is now integrated. We will release the first development version of ORF 3.0 to the Feature Test Program members next Monday. It is an important milestone, even though there is awful lot left to do.

Now that the Reporting feature is getting its final shape, we see that many report types requested by our clients will not get into 3.0, due to the compromises that we had to make between report availability and customizability. A good example is per-user reporting—that is, telling how tests worked for john@example.org and jane@example.org. Each report breakdown (per server, per virtual server, per recipient domain, per recipient) multiplies the amount of data to be processed, which affects report availability negatively.

Sure, it is impossible to meet everyone’s expectations, but can we do anything to allow clients to generate custom reports?

The first and most obvious answer is SQL logging. Once you have the data in a SQL database, you can do just about anything with it. Also, many administrators speak SQL to some extent. Can anything be wrong with this?

Well, yes. First, ORF PowerLog entries are quite complex structures and SQL logging would need some some 30+ tables (imagine your SELECTs). Second, you would probably have too much data to be queried. Third, (technical) supporting such feature would be crazy.

Ok, drop SQL logging and let’s see the next idea. What about providing the raw data to the interested clients and let them decide what to do with it? After all, this is what ORF will do internally. ORF will read the log entry, add 1 to the “Number of Tested Emails” counter, add 1 to the “Number of IP Whitelist Tests” counter, etc. and step to the next log entry. If you could do the same, you would have total freedom with data processing. Great, isn’t it? Can anything be wrong with this?

Well, yes. As you may already have figured out, this would require some programming skills and the number of administrators who can write scripts is much lower than those who master SQL. Sure, we can turn this into a mega-project (as opposed to publishing the log reader as a script-accessible COM API) and offer some smart GUI to reduce the code load, but in the end you would have to code a little for the custom reports.

Anyhow, if you are interested in this way of generating custom reports, post a comment. I am just thinking aloud, but let me know what you think.

This is a message to all the developers out there: Please don’t ship release code with debug prints!

We rely on DebugView a lot for debugging ORF internal releases and every software which pollutes the system debug output makes it harder to do. Not just for us, but for everyone else who uses this excellent debugging tool. Sure, we can exclude these processes from the trace, but time and time again a new one starts doing things like Office 2003’s type32.exe

[2932] Check exception: ..\dpgbase\regvalue.h (375), DPG::RegValue,class std::allocator > >::operator`class std::basic_string,class std::allocator >’, addr = 0x6126CA2E, last error = 123
[2932] Check exception: ..\dpgbase\regvalue.h (375), DPG::RegValue,class std::allocator > >::operator`class std::basic_string,class std::allocator >’, addr = 0x6126CA2E, last error = 123
[2932] Check exception: ..\dpgbase\regvalue.h (375), DPG::RegValue,class std::allocator > >::operator`class std::basic_string,class std::allocator >’, addr = 0x6126CA2E, last error = 123
[2932] Check exception: ..\dpgbase\regvalue.h (375), DPG::RegValue,class std::allocator > >::operator`class std::basic_string,class std::allocator >’, addr = 0x6126CA2E, last error = 123

Other notable programs are RssReader (ok, that is actually a debug release), Lookout for Outlook and Winamp, which dumps the entire playlist when it turns over.

Come on guys, it is only matter of conditional compiling.

Extreme Programming (XP) has a nice principle called “Refactor as you go”. XP says that we should favor the simplest solution for a problem. I like the idea for a number of reasons, but most importantly for its cost-effective nature. Simpler design is faster to implement, results in less code (less bugs) and source code that is easier to read. “Designing simple” means designing for today’s problems; solutions designed for tomorrow often take ages to implement and output large amount of code to be tested.

This is not without price, however. Sometimes the design is proven too static for new requirements (see our last case) and often little attention is paid to modular design, reusability or consistency. This is where refactoring (improving code without changing its functionality) and “Refactor as you go” comes into the picture. The principle says that we should refactor to better code in small steps, as opposed to making big changes at once, because big refactorings are hard to do, open the door for new bugs and break at least one more XP discipline (“Small Releases”).

When programming methodologies and real life meet, you can feel the electricity in the air. Simple design serves short-term business goals very well (“get that new version shipped ASAP!”), but time-consuming and seemingly useless refactoring conflicts with them (“hey, why does it take two weeks to add a new report?”). It takes some self-discipline to take the Red Pill of refactoring, instead of the Blue Pill of the Commando Pattern. After all, it so much easier to get the job done quick, leaving tons of “TODO: Refactor” comments behind and it is so tempting to say that users care little about the software internals as long as it works. But then, points when you when you have to do a bigger refactoring always come.

Most of this week was spent with refactoring. Yes, it is a pretty big one, which means that there is seemingly no progress. ORF PowerLogs are still not fully integrated into ORF. The refactoring will take at least one more week, but even in mid-term, these changes will pay the price back, because the source code will be much easier to maintain. Not only PowerLog integration will be faster, but adding new tests to ORF or changing existing ones will take less time.

Stay tuned.