My biggest beef with J2EE apps is how much you have to rely on config files. Yes, using config files allows you to be super flexible and "plug" in the features that you need. My gripe is that there is only run-time checking if you've configured something properly. No compile time checks.
Configuration sounds like a great idea. Here's the catch: with (struts) web apps, you're got config files tied to each other, tied to resource files, tied to Java classes, tied to just about everything. And if you're misconfigured something and you're lucky, the error message has something to do with your misconfiguration.
If you read this blog, then you know that I can't spell. I rely heavily on auto-complete to catch spelling and typing errors. That's why I don't like config files.
I also don't like manual testing. I love unit testing. I don't like coding without a test to show what and why I am changing code. So, when I am configuring the Commons Validator, I want to know that it's set up correctly and checking the right thing. That means I was looking for a nice way to check the validation in a unit test, without having to drive through the action class. I want to test it as a unit, in isolation (as much as possible). I am pretty disappointed that I have not found an example of how to check that things are being validated correctly without using strutstestcase and building up a request string. :-(
Which brings me to my original point. I'm okay with things blowing up with they are configured properly (fail early, fail fast). I'm not cool with the potential for validation to be skipped because of a mis-configuration, especially without having any unit tests. Manually testing isn't an option. I don't like getting any bugs back from QA.
The Validator isn't a new tool. There should be examples out there. If they are, I just have not found them yet. When I find the example, or make one of my own, I'll post it here.
Lack of unit tests isn't an option.
You really really need Ruby on Rails. I'm serious. :)
ReplyDeleteHow does ruby on rails solve his problems? Does it not have configuration files? Does it somehow provide better validation for the configuration files. It's an interpreted languages, so I'm pretty sure there's no compile time checking, because it's not compiled. That's one of his biggest beefs. Having to wait until runtime to figure out there's a problem.
ReplyDeleteRyan: Oh, I do think that many of my issues with Java web dev. work would be solved by using RoR... I know that. :-/
ReplyDeleteKibbee: no, Ruby doesn't look like it would help me too much on the spelling problems. I don't think that it even makes sense to have auto-compleate in it! (Madness I say! Madness!!!!) But there are other things that it does that make so much more sense[1]: 1) like putting the validation directly into the "class". You don't have to add in a special library or subclass a special type of object. 2) Urls actually make sense (unlike in Struts). 3) CRUD operations happen out of the box. No need to add in (another) framework just to make db access easier. etc.
[1] Note: My understanding of RoR is very limited... so please forgive the errors.
Rails has much less configuration overhead and uses no XML for configuration.
ReplyDeleteRails uses an ideology they call "convention over configuration', which means if you follow a default convention you don't have to configure as much. BUT you still could configure and break the Rails conventions when you need to do exotic things (like connect to legacy databases that don't follow the Rails default schema). The lack of config files results in much faster development time and much less brittle products.
As for Ruby being dynamically-typed and not having compile-time type checking, I've personally found that it's been an incredible advantage for refactoring speed. However, you MUST MUST unit test code written in a dynamically typed language to get this benefit because of the lack of static compile-time type checking.
That's not a big deal because Jim and I unit test anyway. If you make a typo, you find out when you run the test suite.
I was concerned about the lack of compile-time type checking and IDE "intellisense" support but it's been a non-issue over the last year on Rails development for me. It's completely changed my mind about dynamically-typed languages. Having static type checking and unit testing together (like with Java development) seem almost redundant to me.
Try out Rails!
From working with PHP for my own site, I can tell you how much I hate non-compiled languages. So, you write unit tests, but if you don't have 100% code coverage with your unit tests, then you can't even be sure you didn't make a typo. And I know you should have 100% code coverage, but in reality, nobody does. Oh, and lack of intellisense sucks. Unless you've memorized the API, which is impossible, it's very hard to find that function you want, or remember exactly what every parameter is. Sure you can always consult the documentation, but that take much longer than just typing obj. and having it list the properties. If you don't know what function your looking for, then the docs would probably work better, but for simple stuff like forgetting which order the params are in, Intellisense is a must have.
ReplyDeleteAnd could you please explain this whole Rails default DB schema stuff? Does your database have to conform to some specific schema, just to work with rails? It sounds to me like ASP.Net all over again. It works great if you follow the guidelines and don't try to do anything they didn't expect, but once you try to go a little bit outside the box, and do something they didn't plan on, it becomes next to impossible. Most people in industry, although they use .Net tend to shy away from the whole Drag and drop, there's your webform thing. They'd much rather write their own code, where they know what they are doing, and where it wouldn't be a complete rewrite if they wanted to change to another platform. Or wouldn't want it to be a complete rewrite when the next version got released, and their old programming model got changed, with all the tools getting end-of-lifed.