Raible Designs

Working too much - what about office hours?

I currently work too much. I can feel it in my shoulders and I know it because I hardly ever exercise. Even worse, I know it because Julie tells me so and Abbie doesn't get to see enough of her Daddy. In addition to working all week, I work early mornings on the weekends, but that tends to spill into late mornings. I also try to cram in a couple hours during Abbie's nap - which usually spills over past when she gets up. During the week, I'll start at 4 or 5, and I'll need to get something done, so I'll work until 7. After Abbie goes to bed, I often hop on the computer again and work until midnight or later. It's easy getting 8 hours in a day or 40 hours in a week for a client. It's hard doing AppFuse support and writing Spring Live on the side. I virtually ignore all the e-mail on the other open source projects I'm on - it's the only way to keep my sanity.

This madness is likely to continue. The only way to reasonably handle my e-mail (> 1000 day - after spam filters) is to check it every couple of hours. That can't continue, so I'm going to have to change my e-mail address. Sorry folks, it's the easiest solution. I'll decide my new one after the holiday weekend, but matt AT raibledesigns.com will start going to /dev/null.

Julie and I've been talking today and we're trying to come up with more solutions to me working so much - especially since a fair amount of it doesn't pay. We're thinking the best solution is Office Hours. When I work from home, I work too much. When I go into a client's office, I tend to end my day when I get home. So, from now on, I'm going to try and only work from 8 to 5 MDT (-7 GMT). Actually, Julie says she doesn't care if I work before 8, I just need to be done at 5 to play with Abbie and join Julie when she goes to bed.

To help accomplish this, I'm going to start closing the door to my office and using the backdoor to leave and come back during the day. Hopefully it'll be like an office away from home. I'll likely be working on Spring Live in the mornings from 4-8 and doing some AppFuse support as well. My best bet is probably e-mail/blogging from 4-5:30 and writing from 5:30-8 (at the local bagel shop). I'll let you know how it goes. I'd also like to hear other ideas from you "I work too much" guys/gals out there - I know there's lots of you.

JDNC: Simplifying Java Desktop Client Construction

Next session: Java Desktop Network Components. I'm trying to attend sessions that I don't know much about. J2EE ones are likely to bore me. I just noticed that Amy Fowler is one of the presenters - and I've heard she's hot - so I'm sitting up close (5th row).

JDNC is designed to provide shortcults for building common archetypal applications. Better clients with less effort. Less (maybe no) coding. Gentle learning curve and incremental development model. Assumes network or web data source. Geared towards Java application and XML developers. Sun is going to do a lot of work to get Tools vendors to include JDNC. It seems similar to AppFuse, but I'm guessing it's more of an API than a project template. Their goals seem to be the same - get something to show your manager in a matter of hours, not weeks.

Swing Extensions API: targeted for Swing developers, extended components with more features, networked data connectivity and data-binding. I wonder how JDNC compares to Spring's RCP project? Amy mentions JGoodies and how they'd like to include it as part of JDNC.

Feature Highlights:

JXTable: Asynchronous data loading. Sorting, filtering and highlighting.
JTreeTable: Hiearchical-columnar view (outline)
JForm: Data-binding and Validation (as you type). Sounds a lot like what Keith is working on for Spring.
Damn - missed one...

JDNC API: Very high-level components. Built on the foundations of SpringSwing/JFCX. Solution focused and conforms to the JavaBeans Architecture Spec - BeanInfos provided for tool friendliness. Encapsulates complex operations (threading, network connectivity, data modeling). Provides usability features.

Components: JNTable, JNTree, JNTreeTable, JNForm, JNEditor. These components wrap, rather than extend lower level component. Expose simpler API and provide more defaults (i.e. scrolling).

Now we're looking at the Bug Editor Demo (WebStart). The features they're showing are similar to what folks want in the display tag - sorting, filtering, column visibility. It's very cool to see that this is now a built-in feature of Swing. I wonder how hard it is to use JDNC and JGoodies in project? Is it just a matter of adding a couple of JARs to your classpath? It'd be cool to add J2ME and Swing clients to AppFuse. I think the hardest part would be emulating the current (container-managed) security model that exists in the webapp clients.

Sorry, zoned out on e-mail for a while there.

Amy is now showing code and how to create a form for the detail view. It's interesting that the data-binding, including exceptions, is similar to Spring.

JDNC Markup Language: Looks very cool. You can actually develop a Swing app with XML!

Important thing to remember: JDNC simplifies rich client development on all levels. Overall I think JDNC is a very cool open-source project - it's nice to see Sun trying to make developer's lives easier. For more information on developing Swing apps, checkout javadesktop.org.

Being an independent sucks

Richard Monson-Haefel seems to hate being an independent consultant. Personally, I love it - but I've only been doing it for 3 years. He's been independent for 5. I hope when my 5 year anniversary rolls around - I'm not looking for a full-time gig. But you never know. One of the things that I see a lot of independent consultants doing wrong is traveling. Traveling sucks - plain and simple. Being away from your family in the name of a higher hourly rate seems stupid. Then again, I've been fortunate enough to always find work in Denver - half of it where I'm working from home. I do realize that a lot of independents don't live in a tech-rich town like Denver, but why don't you move! Actually, the only reason we're still in Denver over West Palm or San Diego is because the contracts keep flowing. If they dry up - yeah, we'll probably be moving closer to the ocean. But if we move and I'm traveling for gigs - what's the point? I guess Julie's happiness (she loves the ocean) plays a part, eh? ;-)

I traveled a lot in March and April, but I don't plan on doing too many more stints like that. I guess June-July might be a bit rough with JavaOne and OsCon, but after that - I hope to stay put. We'll see - let's hope I get lucky enough to continue finding local contracts.

NYC Seminar: Flex and WebWork

Christophe talked about Flex, it's architecture and built the data grid for the Flex pet store in a matter of minutes. After seeing this presentation, I definitely think Flex is wicked cool. It's too bad that it's price tag is $6K/CPU. However, Vic is probably right - this stuff should be the next generation of webapps. I'd order the developer CD but it sounds like something I'd play around with and never use. It looks so easy to use that I'm willing to bet I can wait until a client demands it - then learn it in a matter of days - or even hours. I did end up asking Christophe about unit testing these Flash UIs. They're working on it, but nothing exists yet.

Now Jason is up - the last session of the day.

What is WebWork 2.0?

• The 2nd generation of WebWork
• A web MVC Framework
• a wrapper on top of a generic Command Pattern implementation (XWork)
• A small but powerful tag library

XWork is where Jason spends most of his time. XWork is a generic command pattern implementation. Actions are command objects in XWork. XWork adds advanced features.

• Interceptors: setting parameters, workflow, etc.
• Results: includes one for chaing to another Action
• Simple IoC container
• Powerful expressional language (OGNL)
• Flexible type conversion
• Metadata driven validation framework

What does WebWork add?

• Adapter for Http request/response
• Integration of Session / Application Scopes
• ServletDispatcher translates HTTP Requests into Action execution
• Request parameters passed to Action Results
• Supported view technologies: Velocity, Freemarker, XSLT Jasper Reports, JSP

Action is a simple interface with an execute method. ActionSupport is a useful base class.

I gotta say - one of my favorite things about WebWork is the fact that all its UI tags are built using Velocity. This means that you (the developer) have full control over what HTML is generated from the JSP tags.

Interceptors have been nicknamed "Domain AOP." Interceptors allow custom code into the call stack and much of the WebWork "magic" happens with Interceptors. WebWork has a number of built-in interceptors:

Setting Parameters

• ParameterInterceptor
• StaticParameterInterceptor
• ChainingInterceptor
• ConversionErrorInterceptor

Defining Workflow

• DefaultWorkflowInterceptor
• PrepareInterceptor
• ServletConfigInterceptor

Preventing duplicate posts

• 2 types of token interceptors

Interceptors can be grouped into named Interceptor Stacks (i.e. defaultStack, validationWorkflowStack).

2 types of actions possible: Model-Driven vs. Field Driven (merging of Action and ActionForm). ModelDriven Interface - public Object getModel(). Porperties of the model will be available as simple properties - "user.name" becomes "name". To use, you have to add ModelInterceptor to your WW config file.

OGNL (Object Graph Navigation Language). An expression and binding language for getting and setting properties of Java objects. Normally the same expression is used for getters and setters.

XWork Validation Framework

• XML based. Validation file in the same package as the class. Defines one field validator and the error messages to add if it fails.
• Bundled validators - supports required, range, email, url and OGNL Expressions (very powerful).
• JavaScript support recently added for simple validators - nothing for expressions though (tough to do).

Doh! Jason's demo didn't work. I did a lot of demos in my preso so I couldn't help but say "shoulda used a Mac!" These PowerBooks might be a bit slow for development, but they're definitely nice for this traveling salesman thing.

This is where you get your money's worth: All the speakers and attendees comparing frameworks, talking about their problems and trying to figure out a better way.

Supporting OGNL in Tag Libraries

Adding support for JSTL's Expression Language was fairly easy to do in the Display Tag. It was as simple as adding an ExpressionEvaluator and subclassing the ColumnTag and the TableTag. From there, all that was needed was needed a new TLD to reference these new classes.

So the question is - would it be just as easy to support the OGNL Expression Language? Does it have an ExpressionEvaluator I can write with the same simplicity as the JSTL version? If I could figure that out, I think creating OGNL-aware versions of the displaytag and struts-menu would be a piece of cake. All you'd need to do would be to change you're TLD's URI and you'd be off to the races!

How do you get around Struts' single inheritence model?

Adrian Lanning sent me an interesting e-mail yesterday. He's looking for a better way to extend Struts. I thought I'd post his message here and see if anyone has ideas.

I am a big struts fan and use it for my projects but I think there is something fundamentally wrong with the design. The real crux of the matter may be that Java is a single-inheritance model and Struts is designed more for multiple-inheritance.

Example 1.
Complexity when trying to use "extensions" to struts that have their own RequestProcessors. Such as my extension for roles (mentioned below) used together with Asqdotcom's ActionPlugin which is a plugin but still uses its own RequestProcessor, plus another hypothetical extension which has it's own RequestProcessor. Basically the only way to use them all is to modify the source of one or two to extend the others which doesn't seem like a good design.

Example 2.
Extending LookupDispatchAction to include per-method validation (set in struts-config.xml). Basically same problem. Need to combine functionality of ValidatorAction and LookupDispatchAction but can't extend from both. Have to modify source. Actually Brandon Goodin wrote this already (I find it very useful). It's called ValidatorLookupDispatchAction.

I know this is a common issue with single-inheritence models/languages. It would be really easy to extend Struts in a multiple-inheritance model.

* THE POINT *
I was just wondering if you knew of a better way to design when dealing with single-inheritance models to avoid problems such as these.

Personally, I don't find the need to extend Struts that much, so this is not much of an issue for me. I think Struts 2.0 will solve many of Struts single-inheritance design by declaring interfaces for all core components. I wonder when 2.0 is roadmapped to ship - sometime in 2006? ;-)

Later: The article, Security in Struts: User Delegation Made Possible, by Werner Ramaeker provides a good example of a Struts extension strategy.

Tucson Rocked - long live the Saguaro

We arrived back in Denver safe and sound this evening. The only casualty was we forgot Abbie's pack n' play in DIA's parking lot. Doh! Maybe we can call and get it back tomorrow.

Erik Hatcher recommended some good spots to check out. We had dinner at El Charro's in downtown Tucson. We also spent a day touring Saguaro National Park and the Desert Museum. We played lots of Pinochle and my Aunt and Mom had a great time with Abbie.

My Aunt Mary Craig is quite a woman. She grew up in Montana during the great depression and her mom and dad (Hilma and Hank) were gold miners. They never made any real money off of it, but my Aunt has many stories about living in mining camps and helping her dad out when she was a kid. Her most amazing feat was going back to school in her 40s, getting her CPA and becoming the head of the Department of Revenue for the State of Montana. After that, she went on a speaking tour of the US about her childhood and how she became of the of the top 10 business women in Montana (at the time).

Meeting with Rick Hightower was a real treat and I got a lot of great ideas, and a ton of motivation from our meeting. I expected to sip Starbucks for about an hour, but time flew and we ended up talking for around 3 hours! Heckuva guy - he had a lot of knowledge and a great perspective on the whole independent consultant lifestyle I live.

Unlike most vacations where I drag myself back to the computer, I abandoned all electronics for the weekend and now I'm super motivated to pound out some code this week. My sister flies into town a week from today for a few days, so I've only got 7 days until the next vacation begins. Family Rocks!

Going Pragmatic on CVS and Unit tests

After reading this thread comparing JUnit in Action to Pragmatic Unit Testing, I broke down and bought both the CVS and Unit testing books. They're short and sound sweet - just how I like 'em. I'm hoping I can knock each one out in a few days.

I definitely need to learn more about using (when/how) Mock Objects for unit testing - my fingers are crossed that this book has the answers I'm looking for.

Tapestry vs. Struts

I've been watching the Tapestry mailing lists in hopes of picking up some tips before I start learning it. In reality, I'm waiting for Tapestry in Action, which will hopefully make it easier to learn. Today, there was a very interesting thread comparing Tapestry to Struts. It looks to me that Tapestry is easier to develop with once you get the hang of it, but apparently, it has a steep learning curve.

The Tapestry Mailing list is interesting - it seems to have a different level of users. Maybe it's just me, but they seem to be a more enlightened crowd. You could almost say the same for the WebWork mailing lists. If I compare these two lists to the questions on the Struts mailing lists - it seems like there's a bunch of idiots over there (on Struts). Don't these people know how to use Google?! To be fair to Struts, I have a theory.

If WebWork or Tapestry ever becomes as popular as Struts, they'll get their fare share of idiots too.

It's just the nature of mailing lists - it's so much easier to ask your question than to look for the answer. Which reminds me...

The Verge Web Framework

After reading this post on the Server Side, I'd hate to be the guy who invented Verge. He's getting pounded like a rabbit during mating season!

Personally, I don't think there's anything wrong with another web framework. Competition is good. The funny thing is that I've never had a need to migrate away from Struts. I do admit that the IoC (Inversion of Control) in WebWork looks cool, but I don't have a need. After reading most of Rod Johnson's J2EE Design and Development, I do understand IoC (I didn't have a clue before), but I still don't see how I need it. I've never run into a problem with Struts that I couldn't solve. Maybe it helps that I've written my own app to make Struts development simpler.

Even though I do like Struts, and I do find it easy to develop with, I also plan on stuffing my head in a couple of books and learning all about Spring, Tapestry and WebWork. Why? Mainly because I'm a fool and I can't be happy just sitting on the couch and watching TV (which would probably help my blood pressure and make my family happier). I'm a fool because I'd rather learn than relax. Back to the point - why do I want to learn these "big 3?" To be honest, it's primarily because some big names (and folks I'd consider friends) are saying they're cool and they'll make my job easier. If only I wasn't so easily influenced...

What I hate about all of this is that as soon as I decide to integrate Spring into AppFuse, it becomes more complicated. Yes, an XML BeanFactory file is more complicated than Interface i = new InterfaceImpl(), especially for newbies.

Furthermore, I'm willing to bet that I'll end up writing workarounds for issues I encounter in Tapestry and WebWork. I'll even put my money where my mouth is - if your framework doesn't require me to write any workarounds, I'll donate $100 to the project. Heck, if it really is that cool - I'll donate money regardless of workarounds.

The worst part is that there's really no reason to convert my Struts webapp to these newer, cooler frameworks. About the only good reason is so I can say "I know the XXX Framework." I doubt XXX Framework will make anything easier, but it certainly might make my webapp a whole lot cooler.