Cedric is still not getting it
Me neither. Sort of.
While Cedric is wrong about the XML refactoring (Eclipse and IDEA both will attempt to modify class names in XML files), his point is still very valid. I like strongly typed languages, and the idea of putting class names and method names in an XML file doesn’t sound appealing. While IDEA does refactor class names, it won’t refactor method names (well), and it really never will — it’s just too difficult to pull off safely. Imagine refactoring “setId()”!
XWork’s IoC container only stores basic information: class names of the interface and the “enabler” (FooAware). Beyond that, the rest is determined via the interface signatures, meaning refactoring is easy.
In the end, I actually like IoC when used mildly for loose coupling of components. However, it is far from a paradigm shift. It just forces you to identify your dependencies and lifecycles much more cleanly than you otherwise might. There certainly is some power to simply calling dispose() or reset() and knowing that all the dependent objects will also get their dispose() or reset() methods called.
I’ve always been a big fan of build systems that work for the developer. I really don’t think that a single build tool (Ant, Maven, whatever) can address all the unique needs of a development organization. Typically there are always trade-offs to consider, such as how seperate should modules be (source compiled with every build, or jar files checked in to source control/downloaded by the build tool).
Vincent has been doing some thinking about build systems that is pretty interesting:
I’m glad to see people like Vincent (and the CruiseControl team, apparently) thinking about this kind of stuff. One thing to note is that you don’t really need a lot of complicated tools to achieve a working build system. The biggest thing needed is developing the process that your entire team has agreed to follow.
For example, suppose you mandate that all sub-projects shall be “disconnected” from each other. This means that rather than having a massive build that compiles everything every time, you build artifacts (jar files) that other projects depend on. Without fancy automated tools, you might require that the newest jar files be checked in to a CVS module called “builds”. Maybe as time goes on and your infrastructure improves, you might have a way to place those jars on a website and automatically download them (Maven does this, but I don’t like it purely because I don’t “get” how it would work with my IDE). The point is that in concept, both techniques are the same. Getting your team to agree to a process is the hard part. Tweaking that process as time goes on to optimize it will come naturally.
I’m very excited about trying out Selenium. When I was at Spoke, I spent a great deal of time building up an automated acceptance test framework. We used HttpUnit (and JWebUnit) and supported writing tests in Excel. We provided a nice interface that allowed test creators to drop Excel files in to a windows share. The tests would then be picked up every few minutes, run, and the results (along with screen captures and application logs) would be emailed back to the user. It made test creation really nice.
… However… the only reason we had to go through this complicated process was because the tools weren’t great. There wasn’t a nice set of tools that allowed users to create tests based on their browser’s behavior (rather than Java-based emaulation via HttpUnit). For JavaScript, this became especially painful.
Yes, there are some commercial tools out there, but none of them are very scriptable via Java (which I want, given that we use Java and it integrates well with Ant, JUnit, and things like BeetleJuice or Anthill). And on top of that, they all require that you use their entire suite, rather than just their browser scripting tools.
I plan to check out Selenium in-depth soon. Hopefully it will live up to my expectations and we can start to apply it for some testing at Jive.
I’ve come across a couple of interesting UIs. People are definitely getting creative with XmlHttpRequest. But it isn’t just XmlHttpRequest. It seems that people are now starting to embrace JavaScript and DHTML much more than they have in the past. Two particular URLs I recently came across:
It is clear that offering these types of “sexy” UIs is gaining momentum. As such, we’re going to focus quite a bit on this in WebWork 2.2. We’ll start with better XmlHttpRequest validation support, but we’ll also expand to just offering better CSS/DHTML/JS support for the UI tag libraries. If anyone is interested in this stuff, please let me know what you’d like from a framework on the rich UI front. We’re having a meeting about the features and I’d be happy to take any suggestions mentioned here to the team to talk about.
A while back Mike blogged about “open companies” in regards to the start a wiki war. I tend to agree that companies that embrace “openness” (which is a bit tough to define) tend to be the ones that can turn on a dime and confront new challenges more quickly. I tend to think that one could even offer the source for free (a la Resin) and merely construct the license agreement such that companies must pay for the product if they intend to use it commercially. I am one of those people that doesn’t believe that money is lost just because someone pirates software or music — only if they pirate it in lieu of buying it. Since corporations never risk getting in legal hot water, I don’t tend to be concerned with releasing the source provided the license protects me.
