Tuesday, July 26, 2005

OpinionJournal on AFL-CIO Split

In OpinionJournal today, the article on the Big Labor split of the AFL-CIO that happened on Monday.

Although I agree with the article, we all know it's not going to happen. Labor is stuck in a "make the big companies pay" rather than looking at ways to become more competitive globally.

And for that, I see a completely different tact. The unions need to spend money globally. They need to be working in countries where this practice is going on. Why not figure out how to unionize Mexico, China, India, whatever? Big Labor's founding priciples are alive and well in these countries. Instead of whining about NAFTA and CAFTA, figure out what's required to assist those people and help improve their wages. Make it more expensive to do business in Mexico or India.

It reminds me of the story I read a while back about a company that was founded in appalachia, where much of the coal mining work had dried up. What did they open up? Call Centers. To compete with whom? Indian call centers? Was it cheaper? No, it was still a bit more expensive than outsourcing to India. But, their service scores were higher than an Indian call center. Is it worth it to spend the additional bucks for better customer service? For many companies the answer is yes.

Unions need to be rethinking things globally. It's not enough to do the reeducation suggested in the OpinionJournal article. It's about bringing the union movement to the people who need it. And they have to pick and choose their places. They need to avoid places that just opened a new plant, and come back in 5-10 years when they have a fighting chance of success.

Wednesday, July 20, 2005

Java Testing Hissy Fits, or How I Learned to Test Without JUnit

I recently ended up in a flame war about JUnit, TestNG, and JTiger on The Server Side. Check the link on the title to see the exact thread.

The downside is, I allowed myself to get drug into the flames. The upside is, I believe I was able to make my point that JUnit is not the be all end all of Test Frameworks.

JUnit is a wonderfully well supported tool. Is it the best thing? No. Is it pretty damn good? Yes....for authoring and executing unit tests.

Part of the issue I have with JUnit is that it seems that if you're trying to do something other than unit testing, you end up with a solution that is more about hacking the JUnit framework so you can run in a pretty GUI than actually authoring tests.

Let me outline an example. I will warn you that I am going to make every effort to obfuscate he actual innards of the software package I'm using such that I don't violate secret corporate type things.

In this scenario, I am testing HTML pages that are constructed using, for lack of a better term, flexible container objects. (If you know what pattern this is, please comment about it and I'll correct.) The main container contains some beans containing text to display on the page. Think of it as a bunch of beans with getText() type methods. Some beans can be named as keys differentiate the container it from another customer's page. Each bean can be organized into smaller sub-containers that further describe the text within them. Each bean gets a name that describes what the text inside it is. It's a loose format and can be used for many different clients very quickly because you don't have to develop custom beans. You just tie them together.

Each container object is constructed by parsing a binary image file. The object is then loaded to a database for access via JSP.

So what am I testing? I'm testing that no links that have been parsed are broken. That no images are missing. That the HTML is valid.

Pretty simple tests? Can be done via a spider? Probably, once you find a way to generate all of the encoded URLs. What about just mocking a container up with limits?

Ahhh, there's the difficulty. Because I'm reverse engineering these objects from a binary file, we might make a mistake. Instead of grabbing 4 "line" beans in my address area, I've grabbed 3! What caused this? Is it a problem? How will I catch this?

So you say, unit test your parsing. Can't do that, how do I mock binary data? How do I know what the limits are? I have a client that one day sent in 5 lines of address, and we handled it fine, because I didn't enforce an artificial limit that the client claimed to be true.

YOU MEAN YOU CAN'T TRUST YOUR CLIENT? RUN FOR THE HILLS!

Well, it's not that I don't trust them. It's just that their systems are legacy and the business rules are generally so old that no one can remember them all. So I expect any limits provided to break within 6 months of production. Hence, we code loosly to try to prevent any breakage. It's an art form. Too loose, major problems. Too tight, missing data.

So in essence, I test the object AFTER I parse it. I create my own acceptance test that says, I expect to have say 4 lines in my address or whatever.

What can happen, and has happened, is I find I've gotten 10 lines! Uh oh! So now, I can go back, look at the specific input stream and figure out what needs to be changed, on my end to make it work...the client isn't going to change.

In the flame war, a great comment was made:
Testing is a trade-off because the time is limited and the tests are endless.
This is exactly why this had to be automated. And exactly why JUnit could not work. You see, I had a test suite running in an ultra-hacked JUnit. I overrode about half of the relection methods in TestCase! Not ideal because I shouldn't be spending all of this time working on a framework. I should be writing tests!

It's also not ideal because of how JUnit handles memory. Once I start generating dynamic tests, the memory usage is incredible. I essentially could test two thousand objects. But it's not uncommon to have fifty or one hundred thousand to test. I need to leave for the day, set up a script and start testing on today's runs. It's not continuous integration, but it's the best I can do with the environment.

Unfortnately it's not as simple as just calling getters. It's generating the testcases dynamically. TestNG allowed me to replace the hacked TestCase with a @Factory annotated method:

@Factory( parameters = { "testClass",
"runID",
"limit",
"JDBCURL",
"DBUser",
"DBPassword",
"URLPrefix",
"URLSuffix",
"CipherAlgorithm",
"CipherKey",
"voucherString"} )
public Object[] factory(String testClass,
String runID,
String limit,
String JDBCURL,
String DBUser,
String DBPassword,
String URLPrefix,
String URLSuffix,
String cipherAlgorithm,
String cipherKey,
String voucherString) {
List fixtureList = new ArrayList();
List objList = getObjList(runID,
JDBCURL,
DBUser,
DBPassword,
URLPrefix,
URLSuffix,
cipherAlgorithm,
cipherKey,
voucherString);
int intLimit = 0;
try {
intLimit = Integer.parseInt(limit);
} catch (Exception e) {
intLimit = 100;
}
try {
Class theTestClass = Class.forName(testClass);
Class[] args= { String.class, String.class };
Constructor theTestConstructor = theTestClass.getConstructor(args);
Utils.log("TestFactory2", 2, "Adding test instances");
for (int j=0; j < objList.size() && j < intLimit; j++) {
fixtureList.add(
theTestConstructor.newInstance(
new Object[] {(String) objList.get(j),
(String) objIDs.get(j)}));
}
} catch (Exception e) {
e.printStackTrace();
}
Utils.log("TestFactory2",
1,
"Returning " +
fixtureList.size() +
" test objects from factory method and beginning tests.");
return fixtureList.toArray(new Object[fixtureList.size()]);
}

I hope that's readable. I know that blogger is having trouble dealing with the Java 5 object reference on the list.

Each test object takes a URL and an ID. They then use a setUp with @Configuration(beforeTestMethod=true) to resolve the issue of OutOfMemoryError that JUnit provided. TestNG requires a few extra hits to the J2EE container because of the setUp grabbing the webpage, but that's not a big concern. Then each @Test() method just uses the webpage object to test whatever it needs to test!

The other advantage of this, is that it can also be used to troubleshoot production issues without having to pull data down to an alpha environment. For example, if a problem occurs, with a specific type of end user, I can quickly setup a test to determine how many customers are impacted by the actual data in the database, rather than (yet again) have the client overstate the problem as the end of the world.

In essence, the flexibility of TestNG solves my unique problems. I'm not writing unit tests. If I was I'd probably use JUnit. It's a really nice thing to have a "standard" like JUnit. But it's nicer to have something like TestNG in my toolbox for the situations where JUnit just isn't the correct solution.

That said, I will be interested to see if JUnit 4 provides the flexibility I require. I would be quite surprised if it is, but I welcome that surprise.

Wednesday, July 13, 2005

Rockstar Boo!

Well, it appears RockStar has essentially shifted from being closer to the Apprentice to closer to American Idol.

FWIW, I found it to be much more entertaining with INXS playing Donald Trump than Dave Navarro playing Paula Abdul. I guess it'll shift back and forth, but I was really more entertained by the Apprectice like format of the first episode than the second.

If the Carolina boy doesn't go from the voting, INXS should boot him in the next cycle.

Tuesday, July 12, 2005

Andrulis Gone

And pandemonium ensues at the Big Soccer Crew Forum and Crew Fans everywhere celebrate.

This season is toast, I don't even care. It's just good to have Greg out. A nice enough guy, but it's pro sports and that just doesn't cut it.

IT Investment Keeping Mortgage Rates Low?

This is a theroy that's been tumbling about in my head, but stay with me for a little while. And please forgive me for using terms that aren't quite correct (but feel free to add comments to correct me, I'd appreciate the lessons).

What if, the real reason mortgage rates are staying low is that lenders have found ways to reduce their overall costs of originating those loans.

The reason I think about it from this different perspective is that I don't really understand why the talking heads have been wrong about the rates. Too often I've heard...rates are going up...and they, well, don't. I mean not enough to be concerned about.

What if the real reason is competition and the drive of these companies to find ways to reduce costs. Costs of selling the loan, costs of originating, etc. Today you don't have to talk to a person to get a loan.

But that's not the whole story.

Backend systems, the ones that process payments, or do background checks are being moved off of hardware that is more costly to run. Not just from a programming/support resource standpoint, but from energy standpoints. They're being moved into Linux or Windows farms, which are easier to find cheaper resources to maintain.

Every one of the companies involved looks for ways to reduce costs. Why? Because then they can offer a better loan rate. They can offer something that their competition can't, and make a better profit. This competition helps to keep rates down. They're not "artificially low" by any means, investment in IT solutions to reduce overall costs is allowing products to be produced that couldn't exist 20 years ago, when the costs to run the back office were much higher as an overall percentage of operations.

Then again, maybe this is just a small zit on the rear of the mortgage industry. But for some reason, I think there's a little more to it than that.

Monday, July 11, 2005

INXS RockStar

Interesting, this RockStar show.

At first I was a bit wary that we were looking at American Idol, but it's not.

I was also concerned about cramming 15 performances into an hour show...unimportant, at least at this stage.

Some acts they thought were good, I found to be weak. I believe they eliminated the right person. She was just not the right fit. And probably about 4 or 5 actually look like they could fit at this point.

It would be interesting to see the winner be a woman, but I think they have the largest challenge.

Interesting to see them not even mention Dave Navarro's Jane's Addiction membership. Then again, Perry's probably got some sort of lawsuit to prevent that. Why? Who knows?

Should be interesting to check out tomorrow's show where they had to fight over 14 songs and figure out who would sing what.

Links to essays in Best Software Writing I

Brevity.Org Has published a list of essays that exist in the book "Best Software Writing I". These are definitely fun to read, and actually are good columns about real issues.

I have just read a few, but Larry Ostermans' column on metrics is especially insightful. For those of you who are working in shops that have taken on corporate wide quality initiatives, like Six Sigma or CMM, you might find the simple example of a QA team as a microcosm of some issues you may see in your own shop.

Likewise, Starbucks does not use Two Phase Commit is also quite interesting in looking at how a "web services" (asynchronous communication) problem is handled in a coffee shop.

These articles aren't Java, .Net, or OSS fanboys whining about various assorted crap. They actually deal with issues, the types of things you hope your management is trying to understand. It's good to see.

Saturday, July 09, 2005

Roller Coster Tycoon 3: Soaked --- Too Easy!

So I picked up Soaked the other day.

This after spending some good gaming hours over a month finally completing all of the scenarios on the original RCT3.

Soaked, is really pretty and sweet...but there's one small problem. The scenarios are cake.

I've had the expansion for a little over a week, and have completed 4 of the 9 scenarios, while spending perhaps 2 hours of gaming time on each....Max.

Hopefully they get more challenging. The problem is the new "challenge" items that appear. They tend to be extremely simple, which can instantly gain you $5000 in cash, which eliminates debt problems.

In RCT3 I found myself having to restart a scenario after making poor judgement calls. In Soaked, I've made poor calls, and been able to dig myself out. In RCT3, I found some scenarios taking 4 to 5 years...in Soaked, I've finished them in 6 months.

Beautiful game, but where's the challenge?

Final Patio Pix





Very long delay in getting pics up, but here they are.

The steps are filled with decorative rock, and the new rock garden area next to the steps is now completed.

Tuesday, July 05, 2005

KDF-E42A10 Also Too Wide

I found the following link to Sony's documentation to find the width of the new 42" Grand Wega A10.

Alas, the same issue here as with the Samsung 42". They're both about 1" too wide. The 42" A10 is 39 3/8" wide, which means it's either a "really expensive" 37" panel TV or a heavy tube TV that will fit in the 38.5" wide cabinet (where 38" is truly ideal).

Maybe the 2006 models will have something that will truly work out for me. It's sad as these models are said to "fit in the same space as a 36 inch tube", when in reality, 36" tubes shouldn't take up 39+ inches of width.

It's very frustrating and unfortunate. I'm sure Sony and Samsung make a lot more off of their rear projection units than their tubes.

Russian Astrologer Sues NASA Over Comet

My only question on this story is, what took them so long? And now, how long before the American astrologists start to sue.

ShareThis