Apps
Contact
Seminars
RSS FeedOctober 16th, 2007
Good QA practice
When a good QA tests an application, she creates data that is meaningful. This data is a good reflection of the real world, or at least of the testing scenario being tested. For example, if she is creating a document with the latest word processing software, she would create a document “ISS Research Report”, or “King Lear”, or “Yard Sale”. Or, she may create a document “Deletable Document”, “Read only Document”, “Tabular Document”.
When a bad QA tests an application, she creates data that is by design temporary. The usual documents created are “Alice1″, “Alice2″, “Alice3″, “BobTest”, “asdkfjsdf” etc.
After a good QA has finished testing an application, the test data becomes a good demonstration, and an automatic user guide.
After a bad QA has finished testing an application, DBA has clean up tasks.
October 6th, 2007
Method chaining does not work
When I learnt J2EE/Enterprise Java (as if that happened one fine day), I was taught there are two architectures of writing request processing methods in servlets – one of them is servlet chaining, and the other is servlet includes.
These two architecture options manifest whenever we are writing OO or Procedural code, and let us refer to them as “Method chaining” and “Method composition” from this point onwards.
Method chaining roughly looks like this:
Method composition roughly looks like this:
[Seasoned IT architects also recognize shades of "Pipes and filters" and "Controller" architectures here.]
While these two options may exist, the truth is method chaining almost never leads to modular code. The reasons are somewhat obvious, each delegating method needs to do many activities, and in some preset sequence.
Method composition, on the other hand, allows smaller, modular methods to be written, which can then be used from multiple sources. For example, “method 3″ may be a simple method such as “validateNumericData”, which simply validates all numeric data within the request.
These two architectural options are not disjoint, and certainly, one may use method chaining, and using method inclusion where necessary. In that case, the following design principle should be respected:
- Method chaining should be set in the framework. In other words, developers should not choose to chain on short notice.
- Method composition can be used more at the freedom of developers.
October 2nd, 2007
Is Java really object oriented?
I came across this really funky Java code.
License
{
Product,
Version,
Key
}
LicenseManager
{
// all the methods that operate on License, including constructors, toString, and other methods.
}
Obviously, my friend, thedeveloper think that she is writing code in Java, so it has to be object oriented. But then again, she underestimates herself. The way this code is structured, the “License” entity is basically just a type (a “struct” in C).