HTTPUnit: Unit test your web apps!
One thing I've always missed when developing web applications is unit testing. One can always unit test portions of the app, which usually amounts to testing the layers underneath the actual user interface code, but that's really not the place where the biggest disconnects happen. The place where you have real problems is in the user interface talking to the model code via HTTP.This is something the windows interface people have been dealing with for years, and they have a lot of decent solutions out there for automated UI testing, but most of them are fairly sensitive to things like widget placement, etc. There are also products like Silk that will both do functional and load testing of your app. But almost all of these are targeted at QA folks, which are far too late in the game to actually let you catch your errors. Usually by the time things get to QA as regressions, you have to go through a bug process, etc, and it's just a huge pain. There was an old Rational ad that I always think about when I'm unit testing: Is a mistake a mistake if nobody ever sees it?
Anyway, HTTPUnit seems to me to be the clostest thing to the missing link I've yet seen. It simulates the servlet container and the browser (including javascript, frames rendering, etc) and lets you unit test servlets, jsps, etc, along with write java code that actually walks click paths in the application, sets form values, does posts and verifies UI integrity. All for the developers. All without having to start Weblogic. I'm currently working on integrating it with my application platform to ensure that it serves our needs, but the promise so far is huge.
Hiring & Women in Software
I'm currently in the middle of trying to bring in an engineer to my current company to help with a product we have in the works. I've plowed through hundreds of resumes, we've done phone interviews, etc, culling out all but around 10-12 of these people. I've been through this process many, many times, and the one thing that really jumps out at me is: When you get down to the short list, I'm starting to notice more and more women in tech that are really really qualified. My wife always says that to be a woman or a minority and to make it as a software engineer, you have to be twice as good as the average person to get noticed.What I find encouraging is that after the dotcom crash and the whatever the hell we're in now, it seems like the numbers for women showing up in the hiring pool that are actually really qualified and solid candidates are really looking up. It gives me some fairly large measure of hope for fixing the gender gap in software, I suppose.
The Evils of Downcasting, or Why I Miss Smalltalk
When I learned how to develop using OO, I learned that any downcasting was a "funny smell", and could always be eliminated. My experience of developing this way led me to develop code that was extremely tight and easy to maintain. I had found my development nirvana. All I had to do was follow this pattern, and all was well.Then I started working in Java. Did I mention I learned how to properly do OO using Smalltalk? All of my Java code always seemed like a hack. There were static "helper" functions cropping up that constantly made me ill. And most importantly, I was writing code that did conditional downcasts that I couldn't work around.
Then it dawned on me: in Java, if I need it, I can't add a method to string to clean my code up. Swing is fixed. All my commericial libraries have fixed APIs. In Smalltalk, if you need to add a method to Boolean, you just go right ahead and do that. The libraries and your code merge into one sort of blob that are both honed to each other. This is a clean, elegant blob that works perfectly, but it also means that you incur the penalty of maintaining all that gargantuan amount of code you've just "tweaked" to make cleaner.
I'm really not sure which is a better tradeoff, but the idea of tweaking the JDBC drivers and the appserver to really make my code smooth, and then incurring the weight of maintaining those 250-500kloc of code that I could previously write off as someone else's problem doesn't sound all that hot. Maybe I'll live with my Java hack code and simply remember OO nirvana like a sweet, pleasant memory.
Bonkers: Mate for the Masses
In the last few months, I've started drinking Yerba Mate instead of coffee as my primary caffeine source. It's a much happier buzz, as it doesn't leave you feeling all shitty and jittery after 12 hours of slugging it down while coding. After having been off coffee for a while and then going back to it briefly, coffee to me feels like some sort of toxin I'm bringing into my body, while mate feels cleansing.What I discovered today was Bonkers, which is a non-loose Mate in tea bags. The genius thing there is they have super caffeinated Mate, which is like making a good thing 10x better. It's called WIRED & CRAZY MATE; I encourage you to go find some at your grocery store (I shop at the Piedmont Grocery, which is Divine, and carries all the Bonkers you need).
NTFS Maximum Path Name Length
So a useful tidbit for windows users: NTFS, at least on XP (and probably everywhere), has a maximum path name length. When I found this out, it really felt like being tossed back into UFS circa UNIX System 3. The maximum length of a path on Windows (at least from the command line) is 256 characters.
What this means from a practical perspective is that if you have deep path structures in your webapp, and you have your appserver deeply structured (such as WebSphere), you'll run into stray messages like:
(The system cannot find the path specified)
The problem is, WebSphere puts the app (by default) at C:\Program Files\WebSphere\AppServer\installedApplications\hostname. When you tack this onto the deep, nice file structure you have in your app, suddenly you're looking at paths far in excess of 256 characters long. And the beauty of it is, WebSphere fails silently and tells you that it deployed correctly. You only see the above message when you try and copy the files manually into the deployment directory using something like ant.
The solution is to tell the appserver to deploy the app (when you're pushing it in the deployment tool) into a shorter path, like C:\temp\ws. This way, it will actually deploy correctly when it says it did.
Perl is the Yugo of Programming Languages
I, like 99% of the rest of the world, saw this article on Java being the SUV of programming languages. I'll spare you the lawyer jokes (note the url).The part that really blows me away is that people actually believe this sort of junk and then parrot it to the rest of the world. How is Java too powerful? It has OOP that works and wasn't tacked on as an afterthought? It helps you structure your code so you can actually not end up with a total mess at the end of things?
My only retort to this article is that scripting languages should be used like duct tape. They seal up big cracks in software systems so they work, but they're almost always a hack, and when you try not to make them a hack, it's a hell of a lot more work than it would have been to actually write it using a full featured language in the first place.
I'm not here to argue about strong versus weak typing. I'm here to encourage people to actually TRY the technology in the real world before they start becoming a pro or con evangelist. And, yes, before you ask: I've written more Perl for money than I care to recall. There's a reason why I use Java now, and it's not because it's fashionable.
Ruby, C#, and Python: Whither the Software Wind Blows
I've been looking for quite a while as to what is going to be the "next big thing" that is going to take off in the software world. At the rate that most of us were used to in 1999, the "hot new things" in Java and XML are starting to grow whiskers.Over the last 6 months, I've had the opportunity to put out ads and get resumes for various software positions in the bay area. 6 months ago, we would get 200 responses to a job posting in the first day, and about 500 in the course of a week. We put out an ad last week for a java/XML person, and got a grand total of 100 resumes in a week. I see this as a definite sign of real economic recovery. We also didn't get any resumes from the people that were applying for jobs way below their skill sets, which I find relieving. At one point, we were hiring a junior engineer and got a resume from one of the original multics designers. That was a depressing day.
Anyway, long story short: it seems economic recovery is upon us, in some sense (cross our fingers). With this recovery, I'm seeing a lot more mention of alternate technologies and people pursuing real project development in things like Ruby and Python. And, of course, C# is rapidly gaining momentum. There's a feeling of a breath of life and fresh air in the industry, like someone opened the attic and remembered that a long time ago we used to actually invent new things and not keep banging out junk using the same old tools, and maybe they should invest some time, money and effort in moving things forward.
Here's to the future.
Patterns of Enterprise Application Architecture, or Working Around The RDBMS
I've recently been readin Martin Fowler's latest book, Patterns of Enterprise Application Architecture. This, honestly, is the best patterns book I've read since the original GoF patterns book. It had the same effect of both showing me names for things I already knew how to do, quantifying the tradeoffs of the various decisions and showing me new ways to do things that I hadn't thought of. I fully recommend everyone working on enterprise software (C# or Java, in particular) buys it and reads it cover to cover.The thing that struck me most about the book is always the thing that struck me most about dealing with enterprise software in general: the RDBMS is like a giant boat anchor that's unfortunately necessary. It seems like a massive chunk of the book is dedicated to dealing with getting your clean object model into and out of the database while not sacraficing too much efficiency or cleanliness. To his credit, Mr. Fowler does a great treatment on the subject that's clear and easy to understand and implement. I thank my lucky stars that hibernate exists, and implements a large number of the patterns in the book cleanly and efficiently so I don't have to.
Intellij "Aurora": Great new UI, and lots more great plugins
If you're an intellij user, I encourage you to download the latest "Aurora" release from the JetBrains EAP (Early Access Program). It has a great new UI and a killer set of features that just made things that much better. In particular, the new JUnit runner is just too cool for school. The thing that got me to download Aurora in the first place was the Auto Boxing Plugin, which is a plugin that lets you do:Integer i = 12;And will "auto suggest" that it be changed to:
Integer i = new Integer(12);Which conveniently solves a major language shortcoming with just an IDE hook. It does a LOT more than that though, working around a lot of other Java foibles cleanly and gracefully.
Test Driven Development with Databases
I, like I suspect many people, have always had a problem with test driven development for enterprise systems. The unit tests that you read in the books all have no side effects. They check that the code runs, and if they fail, no big deal. However, the reality for enterprise systems is that tests have side effects: they mutate the data in the database. If they fail in ways you don't expect, they can horque the data that they are depending on to run, and the whole system breaks down. My experience is that in this situation, unit testing gets pretty quickly tossed out the door, because as soon as you end up having to diagnose the data to get your tests to run after they've clobbered it, it becomes very labor intensive and breaks your train of thought and productivity rapidly. I had the opportunity to talk to someone that does a lot of test driven development against enterprise systems, and he offered me the nougat I was missing. Props to ThoughtWorks. The two necessary things are:- Data sets for the tests are as important as the test code, and are fixed. These are guarded with the same care that you guard the test code itself. This I had managed to figure out on my own.
- Test code, when it runs, has a harness around it that always, when the execution is complete, rolls the transaction back. This way, even if the test fails mysteriously, it won't clobber the underlying data that the tests depend on.
Anonymous no longer
Cameron mentioned me in his /dev/null blog, and pointed out that I was ranting anonymously, which I found both suprising and pretty amusing. I mean, someone is actually reading this.. that sets a much higher standard for me to live up to; delivering quality content. This is me on the left, and this was me while still in grad school. My name is Kris, and I can be contacted at kris at further dot com.
