Wednesday September 14, 2005

Biled Again, this time because my design sucks Looks like I've been biled again. Unlike the last time, this time Hani doesn't offer any specifics, he merely says that my OSS efforts don't do anything other than the "very very basics".
Java, specifically, goes a long way towards ramming down a set of design principles. Said principles are followed fairly blindly by most practitioners. The OSS world is awash with examples of people who have read the right books, but have absolutely no skill or talent at conceptualising or grokking the underlying principles behind the books. To them, the design pattern is an end goal, not a tool. To pick one example (out of thousands), look at Matt Raible's OSS efforts. It has inheritance! It uses PATTERNS! It is LIGHTWEIGHT! Yet, I'd argue that it's very badly designed (if you don't believe me, just try getting it to do anything other than the very very basics.)
I'm assuming that Hani is speaking about AppFuse and Equinox, because my other efforts in OSS are minimal (Roller, Display Tag, XDoclet and Struts Menu). The reason I'm writing this post is because I'm curious to know what Hani tried to do that didn't work? Was it AppFuse/Equinox that failed? Or was it the underlying framework? Did he try to do indexed properties with WebWork or modify build.xml to deploy to Orion? Is the feature he's looking for something we can fix?
As a defense of my use of patterns, lightweight containers, etc. - it's not so much my doing that these happen to exist - they're more of a reflection on what user's want. It's a problem with Java developers in general - if you're not using patterns - users want to know why. Furthermore, most of the J2EE patterns in AppFuse are from the underlying frameworks, not from anything that I did.
As far as the design of AppFuse, I agree it could use some work. There's a lot of stuff in AppFuse that I don't use - so when I start a project with it - I usually rip out about 20-30% percent of it's features b/c I won't use them. Unfortunately, it's not that easy for others to do this b/c they don't know what they'll break if they remove a bunch of stuff. I'd like to move to a more modular, plug-in type architecture - but I have a feeling that that's the path to over-engineering. Even so, it would be pretty cool if it was possible to turn on/off features (even the use of a particular web framework) by changing a properties file.
Posted in Java
at Sep 14 2005, 08:58:58 PM MDT
8 Comments
WebWork Books
What is it about WebWork that makes it so hard to write books about? I remember talking to Kris Thompson (a.k.a. the guy that quit blogging) last summer about WebWork in Action. At that time, it was "almost done". Over a year later and it's still "due out next month" (or is it done?). Almost as bad is Matthew Porter's WebWork Live, which was started late last year. I remember Matthew saying he expected to finish the initial version in March - and there's still not an ERP almost 10 months later.
Here's my guess: the Manning book has been done for months, but the publishing process takes months. As for Porter, my guess is he's too busy providing outstanding support at Contegix to work on the book. Any good conspiracy theories out there? Maybe WebWork has too many patterns that need to be documented?
Posted in Java
at Sep 14 2005, 05:23:04 PM MDT
3 Comments
Search This Site
Recent Entries
- My TSSJS 2010 Presentations and Summary
- What's New in Spring 3.0
- Developing Rich Web Service APIs with Java
- C++, Java and .NET: Lessons Learned from the Internet Age
- Highly Interactive Software with Java and Flex
- The Cloud Computing Continuum with Bob McWhirter
- Software Quality: The Quest for the Holy Grail?
- What's Happening in the Java World?
- Fantastic Fun in Jackson Hole
- How We Hired a Team of 10 in 2 Months