Raible Designs

Estimating Projects

Martin Fowler has a good post on the Fixed Scope Mirage.

Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don't get satisfactory software, then it won't cost them.

I see this often when looking for new projects. The potential client has a project they want done, and they want it done in X weeks/months. Why? Because they're willing to pay X dollars for the software and their next door neighbor (whose in IT) did an estimate for them while they were drinking beers the other day. I've learned my leason with these clients - run! Any client that estimates how long it'll take you to do something is going to be a nightmare to work for. Furthermore, if you get the gig - you've likely told them that you could do it in their timeframe.

Even worse are clients that want you to do a 1-2 week project. These are a nightmare because they tend to want lots of functionality, but don't want to pay for it - hence the 2 week project. From my experience, I've learned to only take clients that allow you to do the estimating and have projects that are a month or longer.

Resin slower than Tomcat, fails the AppFuse Test

As part of AppFuse 1.6, I was hoping to supply the option to use Resin instead of Tomcat. In reality, hardly anyone has asked for this on the mailing list - but since so many folks say that "Resin is better" - I figured I'd give it a whirl. I hate to be the guy that spoils all the Resin users mantra, but it seems like Tomcat is the better server. Why? Speed, compliance and shit works. Here are some things I found:

• Server startup time when AppFuse is only app installed (deleted work directories before starting):
  • Resin: 25 seconds
  • Tomcat: 14 seconds
  I also found that Resin loads my StartupListener twice b/c it's defined in web.xml and XDoclet puts it in the generated TLD. I think the best solution is to add a flag to XDoclet to allow you to exclude listeners from the TLD when it's generated. I commented out the entry in web.xml for this test.
• Running "ant test-canoo" which runs through all the JSPs using Canoo's WebTest (server already started):
  • Resin: 1st run (no compiled JSPs) - 53 seconds, 2nd run (compiled JSPs) - 24 seconds.
  • Tomcat: 1st run (no compiled JSPs) - 49 seconds, 2nd run (compiled JSPs) - 14 seconds.

I did have to hack a number of things to even run the tests (which verifies titles, success messages, etc.) on Resin. First of all, SiteMesh seems to puke with if you try to use <dispatcher>FORWARD</dispatcher> on the filter-mapping. I had to comment this out, resulting in a lots of HTML Tidy errors during the tests ( Error: <content> is not recognized!). I also had to turn off Resin's fast-jstl to bypass this bug. Finally, I had to revert the displaytag to using the non-EL version (which required changing titleKey -> title and name="${listName}" -> name="listName"). It seems that Resin enables EL even if you're using a 2.3 DTD. With Tomcat, and I believe the spec says this, EL is only enabled if you use a 2.4 XSD.

So there you have it folks, not only is Resin 3.0.9 slower than Tomcat 5.0.28 (JDK 1.4.2, Windows XP), but it's not standards compliant. Of course, the speed could be due to my using the open source version (with performance enhancements turned off) - but I'd think the other (albeit minor) stuff should be easy to fix. Everytime I try to use Resin, I end up finding bugs and going back to Tomcat. I guess this is another one of those days. I don't think I'll include a Resin installer as part of 1.6, but I might distribute one later if I can get these issues solved. I wonder if I should give Orion a run for its money?

P.S. Since I know people are going to ask: Tomcat 5.5.3 with JDK 5.0 took 9 seconds to startup. Running "test-canoo"? First run: 37 seconds, second: 14 seconds. Looks like the new compiler is quite a bit faster.

The Beauty of SiteMesh

I'm pumped that I recently switched from Tiles to SiteMesh in AppFuse. Not only was it easy to learn when I integrated it into Equinox, but it easy to replace Tiles with SiteMesh in AppFuse.

The best part of SiteMesh is once you have it setup and configured, you rarely have to muck with it again - it just works. In fact, it's so non-obtrusive that when I re-worked all AppFuse's tutorials last week, I was able to delete a whole tutorial. That's right folks, by removing Tiles and going with SiteMesh - the number of tutorials dropped from 5 to 4. Reduction in code and words needed to explain it is always a good thing.

Furthermore, SiteMesh continues to be evolving and getting better. Good stuff.

BTW, did you know you can use SiteMesh-style templates in your Roller blog? I'm using this feature on JRoller and it works great.

[DJUG] JMX and JDO 2.0

Last night I attended the local Denver JUG meeting. Chris Huston gave a presentation on JMX and Dion gave a presentation on JDO 2.0. Below are my notes from the event.
-----------------------------

Java Management Extensions one of the first JSRs and now included in to JDK 5. Monitors health of the system. Alter sys-admin of error conditions. Provides capability of to view and modify runtime parameters.

MBeans are deployed in an MBeanServer and their capabilities are exposed through Connectors. Then tools talk to these connectors to get their information.

JMX is covered by two separate specifications: JSR-3 (MBeans) and JSR-160 (Connectors). BTW, Chris has some good slide-making capabilities - I'll have to get some tips from him for my next preso. For example, he shows an entire class and its methods, then he fades it and zooms in on certain methods and highlights them to explain what they do.

Four types of MBeans: Standard MBeans, Dynamic MBeans, Model MBeans and Open MBeans. More info on these Mbeans can be found at http://docs.sun.com.

Standard MBean: All you need to do create an interface for your class your class name with "MBean" appended to it.

In order to deploy, you need to create and configure an MBeanServer. You can create an MBeanServer using javax.management.MBeanServerFactory.createMBeanServer(). MBeanServers keep track of MBeans using a javax.management.ObjectName. After creating and configuring an MBeanServer, you simply need to register your MBean using an Agent. All pretty simple so far, right? Now you have to use a Connector to expose your MBean to the outside world.

"Connectors are the fly in the ointment." MX4J is an open source project that has good Connectors: i.e. RMIAdaptor and HTTPAdaptor. There's also SNMP Adapters from a number of commercial vendors. In order to solve the current lack of good Connectors we have JSR-160: Distributed Services Specification. This JSR defines one connector: JMXConnector (part of JDK 5).

Chris is now showing us a counter widget deployed as a Swing app and managed using MX4J's web interfaces. Very cool stuff - the ability manipulate runtime parameters. As Chris stated - the real power of JMX will come from the tools. I wonder if there's MBeans available for monitoring webapps - seems like there'd be quite a market for management beans you could just drop in and deploy.

Notifications are another feature of MBeans and can be sent by an MBean. Two important interfaces: NotificationEmitter and NotificationListener.

Chris gave a good introduction to JMX, but I don't see myself using it anytime soon. It seems to be something that framework and container developers might use, but not many application developers. Maybe I'm wrong - are you deploying MBeans as part of your web applications? Chris mentioned that Hibernate and Spring have MBeans as part of their distribution - anyone using these? If nothing else, it's great to know that JMX is available if I ever do need to monitor and control applications.

-----------------------------
Now Dion's up after a 1/2 hour break with announcements. Dion is talking about JDO 2.0. I think JDO would be a lot more popular if it wasn't for Hibernate. Hibernate seems to have done JDO better and faster.

What is JDO?

• Allows for object persistence
• "I have objects, some need to be persisted"
• "Keep state and behavior together. That is the OO way."

JDO Main Objectives:

• To enable pluggable implemenentations of data stores into application servers
• To provide applicaiton programmers a Java-centric view of persistent information, including enterprise data and locally stored data.

Other Objectives:

• Transparent Persistence
• Persistence-by-Reachability
• OO framework on top of potentially non-OO stores.
  • RDBMS (98% of the time)
  • Files
  • TP Monitors
  • Legacy
  • Properietary
• Integrate with existing technologies
• Java compatible - no need to learn new language
• Usable in managed and non-managed environments
• Define easy semantics for caching objects
• Ability to run in all Java platforms (J2SE, J2EE, J2ME)

When JDO first started, a bad thing happened - the object database guys were heavily involved. JDO 1.0 had 80% of its Expert Group from object database vendors. JDO 2.0 got object guys off the committee and real-world (relational) folks onto it.

JDO 1.0: Most of it is not very new - just a standard way of implementing persistence. Other proprietary tools already accomplish most of what JDO is.

JDO 2.0 Strategic Goals:

• Easy to Use
  • natural programming model
  • configuration and deployment
• In a Wide Variety of Environments
  • J2SE (rich clients)
  • application, web servers

JDO 2 Status: First Early Draft Review is out there. Soon there's going to be a Community Review - then things will start rolling after that.

JDO 2.0 Goals:

• Maintain JDO 1.0 Compatibility (big thing with Sun)
• Standardize Mapping to Relational DB (was vendor extension in 1.0)
• Multi-tier Development Improvements
• Usability Improvement
• Better Object Modelling
• Richer Queries - JDOQL, SQL and Named Queries
• More Vendor Support - try to get Hibernate and Oracle on the bandwagon for political reasons

Dion's take on politics between EJB 3 and JDO 2

• Let's get a standard around transpanent persistence first
• Let's have a standard that can be shared between various groups: J2EE, J2SE, J2ME
• Why have more than one O/R mapping specification?
• Specifications such as EJB could be an umbrella spec for the cross cutting concerns

Why are people even arguing about it? Money. Because companies have invested a lot of time and money into X technology and therefore they bash the other. This problem might be solved by an O/R Mapping JSR that both EJB and JDO have to adhere to.

JDBC vs. JDO

JDO will use all J2EE services inside a container.

Deployment time scalability - database becomes bottleneck as number of users increases. JDO middle tier can relieve this load on the databse. JDO's configuration can be altered at deploy time to handle better scalability through caching.

JDO 2.0 Multi-tier Development - big thing is disconnected objects through attach/detach. Very simple API for detaching and re-attaching objects. Internally there's a version that's used to determine if the object is the same one.

JDO and EJB
As opposed to Entity bean, JDO instances...

• May have subclasses
• May exist outside a container
• Has 1 optional interface to implement
• Accessible as transient objects

And as of JDO 2 (new and improved object modeling!)

• Persistent Abstract Class Support
  • map abstract classes to tables
  • map properties, fields to columns
  • create new implementation instances
• Persistence Interface Support
  • map interfaces to tables
  • map properties to columns
  • more, but I missed them

Some argue that JDO is what Entity Beans should have been!

• JDO is "purer" way to use OO
• Since Entities should be used via local interfaces, why not just do Session Facade -> JDO objects
• CMP in Sun AppServer uses JDO

Some argue that JDO complements Entity Beans because Entity beans can use JDO.

EJB3 is totally moving directorys with regards to Entity Beans, and they are much more like JDO.

EJB3 EntityManager == JDO PersistenceManager == Hibernate Session

JDO and Connector Architecture - JDO is NOT a framework, but plays well with others!

The JDO architecture uses the J2EE Connector architecture for application servers. The JDO PersistenceManager is a caching manager as defined by the J2EE Connector architecture.

A PersistenceManager may define the following Connector components:

• ResourceAdapter
• ConnectionManager
• ManagedConnectionFactory
• ManagedConnection
• LocalTransaction

Persistence Contract (behind the scenes)
- To achieve transparence, JDO:

• Defines a PersistenceCapable interface
• Used too mandate binary compatibility among all vendors (optional in JDO 2)
• Uses tools to make a class persistence capable

- Declares any fields available for persistence storeage

- Defines methods that allow JDO instance management

• jdoIsDirty()
• jdoIsDeleted()
• jdoMakeDirty()

JDO has a number of callbacks that you can implement: jdoPostLoad(), jdoPreStore(), jdoPreClear(), jdoPreDelete().

In JDO 1: one interface: InstanceCallbacks
In JDO 2: InstanceCallbacks purely extend interfaces: LoadCallback, StoreCallback, etc.

Ways to make classes persistence capable: byte code enhancement, annotations (maybe for JDO 2.1).

JDO Interfaces: PersistenceManagerFactory, PersistenceManager, Transaction (new set/getRollbackOnly() in JDO 2) and JDOHelper (class with static methods, for use by persistence-aware classes), Query, Extent. You'll probably never use an Extent; like "select * from table". Represents all instances of a class or subclasses.

A persistence cabable class is just a POJO - you could use the same class for JDO and/or Hibernate. A default contructor is required in JDO 1, but not in 2.

JDO 2.0 has "use cases" for lazy-loading. This enables you to configure fetching based on certain situations. Sounds pretty cool.

Extent is usually optimized for better performance. If you're selecting all records from a table, you're probably better of using Extent vs. Query in order to avoid OutOfMemory errors.

New in JDO 2: ability to specify query filters in other languages - i.e. SQL or HQL or user-defined. These languages are up to the JDO vendor to implement.
JDO can use stored procedures if you map it in your metadata.

JDO 2.0's Query API looks very rich. It allows you to limit your results to certain properties/columns, as well as set what type of to return.

JDO 2.0 supports obtaining a java.sql.Connection from PersistenceManager. However, this may reduce portability since not all SQL is portable b/w databases.

Overall, I thought this was a great talk by Dion. If you're looking to start working with JDO 2.0, I'd recommend JPOX (also see JPOX with Spring or Tapestry). Unfortunately, their implementation still requires you to "enhance" your classes at build-time, but hopefully they'll have a transparent mechanism for manipulation (i.e. cglib) soon.

DJUG: JavaServer Faces and Java Studio Creator

Tonight's DJUG meeting looks to be another dandy one. Bill Dudney is doing a talk on JavaServer Faces and Java Studio Creator.

This talk will take you through the basics of building a JavaServer Faces application. You will understand how to build a basic JSF application. We will build an application manually and then build it again with Java Studio Creator. If time permits, we'll compare the two implementations to identify when and how to use JSCreator effectively.

I'm mainly looking forward to it because I know Bill uses a PowerBook and Creator sucks on the Mac - even though Bill doesn't think so. Should be fun heckling him from the crowd. Of course, I'm also looking forward to learning more about JSF since I'll be using it next week.

[NFJS Denver] Racing Sheep, AppFuse and Spring

Today, I forgot my laptop at home and therefore didn't get a chance to do any real-time blogging. It was quite nice in fact. I realized I forgot everything about halfway into my drive (30 minutes) and decided it wasn't worth turning around. Therefore, it was a day for just sitting back and soaking it all in.

This was quite a conference. Never have I seen so many great minds and influential Java Gurus in one place. The speakers were awesome, and to make things even better - I got to meet and shake hands with most of them. Who says the community in Java sucks? I'll tell you what - the Java community in Colorado is rockin'! The online community in Java might be a little terse - but the face-to-face community is a different story.

Ugh - I just had one of those "write a huge long paragraph and then lose everything" moments. Who was at fault: a combination of IE and Roller. I accidently hit the back button and Roller kicked me back to the login page. When I clicked the forward button - Roller/IE didn't return me to my post -> hence I lost everything. Sometimes I hate webapps. Time to finish the rest of this post in an HTML Editor where I can hit Ctrl+S all the time.

The first session I attended this morning was Dave Thomas's Herding Racehorses and Racing Sheep. Thanks to Carl Fyffe for recommending it. The first part of it was about how developers have different levels of expertise and how they learn. Novices are productive and learn well if they have a specific set of instructions. This is in contrast to Experts - who are more efficient if they're given freedom and lack of rules. Most folks in the room considered themselves Experts. Dave estimated the room's average was 4.5. From there, we proceeded to talk about the fact that most developers think they're smarter than they really are. Lastly, Dave touched on Personal Knowledge Investment and how we all need to take time to invest in our own knowledge. It's your #1 defense against offshoring. You know its working if you still have a job at the end of the year. You know it's really working if you're doing what you want to be doing, programming in your preferred platform. This talked rocked and I highly recommend it.

After that I attended Rick Hightower's TDD for the Web Tier. It was a good talk and I learned about jWebUnit. This tool is similar to HttpUnit, but it simplifies the API. It has the same functionality as Canoo's WebTest - allowing to easily test interactions on a web page. It looks like a great way to test your view layer, though I prefer Canoo. The main reason is because Canoo Tests are a bit simpler to write - especially if your QA folks are writing them. I had some success with this at Comcast - where our QA guy actually wrote quite a bit of XML to test our webapp. Rick also covered Cactus fairly extensively (with examples) and a I learned some things about Cactus I didn't know. Cactus's beginXXX is for setting up client parameters, testXXX is for executing and testing server-side code and endXXX is for testing the client side response (i.e. an HTML page). Rick definitely has a lot of experience with test-driven development and has motivated me to learn to use my IDE more for testing. It's simply faster and therefore will make me a more efficient developer. Rick was saying that he uses AppFuse with MyEclipse all the time. He says he hardly ever has to restart Tomcat and he can easily run XDoclet on a single file. The update for Eclipse 3.0 M9 is due out in a week - I might have to make an effort to get AppFuse to be MyEclipse-friendly then.

Julie and Abbie showed up for lunch and Abbie got to run around and wink at all the boys. It was cool being able to introduce them to all my "Java buddies."

After lunch, there was an Expert Panel Discussion where we talked about all kinds of topics: Hibernate, Personal Knowledge Investment, Tools/IDEs and of course, .NET. From there, I attended Rick's talk on AppFuse. It was great to hear Rick's perspective of AppFuse. When I talk about AppFuse, I tend to talk a lot about the reasons I created it and how it came to be. Then I talk about the technologies it uses. Rick talks more about his experience with it and how you develop applications with it. He had a lot of code to show and the talk went really well. Then again, I'm biased. I've never heard Rick speak before this weekend, and I have to say - he's a lot better than I expected. He has a lot of humor and experience in his talks and was quite enjoyable to listen to. I hope to work with him someday, that'd be a good time. If anyone is learning more about AppFuse, and you're local - I'll be talking about it at the Denver JUG and Boulder JUG next month. I also plan on releasing AppFuse 1.5 and AppFuse Light this week.

For the last session of the day, I attended Rod Cope's Easy Enterprise Applications with JBoss, Hibernate, AspectJ, and XDoclet. Rod is going to be my new boss in a week, so it was definitely cool to hang out with him this weekend. Rod is a good speaker, but his presentation wasn't teaching me much, so I left. He was talking about how extracting 75 lines of Hibernate code (many try/catches, lots of transaction/rollback code) into aspects can save you a lot of time. I don't use aspects, I use Spring - and my Hibernate methods are typically 1-3 lines of code. I'm sure if I'd stayed, I could've learned more about AspectJ - but frankly, it doesn't interest me that much.

I snuck out of the room and went to the 2nd half of Spring in Action by Craig Walls. I met Craig for the first time at this conference and I thoroughly enjoyed talking with him. He seems to be a very easy going guy and he definitely knows a lot about Spring. I learned some different ways of writing controllers - extending the Abstract Controllers, rather than using the Controller interface and SimpleFormController. It was interesting to see how flexible Spring is and how his way takes about the same amount of code as the way I'm doing it. It was a good talk and I look forward to downloading his sample app. Hopefully he'll post a link soon on his blog. I'd be happy to host a demo.

What a great conference. I left with a headache today because my brain was so full.

[NFJS Denver] Richard Monson-Haefel and Groovy Programming

Groovy makes for easier for loops. As an example,

for (Iterator i = r.iterator(); i.hasNext();) {
    System.out.println(i.next());
}

... becomes ...

for (i in r) {
  System.out.println(i)
}

With Groovy, you can remove semi-colons and use dynamic typing. This means you can basically remove any types (i.e. List). The nice thing is that typing is a choice - you can use static typing like you do in Java write now.

One thing I forgot to mention about this conference. Jay Zimmerman (the organizer) has a pretty good idea. The full schedule is printed on the back of the conference badges attendees hang around their necks. This makes it very easy to find and decide what session to attend. I wish more conferences would do this.

Richard is going through closures, native list looping and how you can remove classes and method declarations. It seems to me that one of the coolest features of groovy is that all of the shortcuts are optional. This is huge IMO, because it means the developer has a choice - which is always nice. Richard says that in his experience, a program written in Groovy is about 1/5 the size of the same thing written in Java (an 80% reduction in code). Someone in the room asked about performance. I was surprised to hear Richard say that Groovy was a bit slower. After asking about this, it turns out that Groovy can be executed as a script or as native bytecode (if compiled first). So when Richard said "it's slower" - he meant the script version is slower - because it's interpreted - just like any scripting language.

Sweet - I just got a connection on the hotel's wireless network. I was in the midst of reading some RSS feeds in NetNewsWire and noticed a JRoller blog with additional coverage of this conference. ... Sorry, I got sidetracked for the last 20 minutes with the Spring developer's mailing list - talking about simplifying Spring forms in JSPs.

Back to Groovy. Richard, and several members of the audience, are talking about closures. I still don't really get what they are and why they're important. I guess I shoulda been paying attention. ;-)

Groovy has regular expressions built-in - based on JDK 1.4 Regex. In Groovy, == is the same as .equals() in Java. And === is equal to == in Java. Apparently, they did this because folks usually use == when they really want to get the functionality of .equals(). I like the idea that == in Groovy means the same thing as == in JavaScript, but I don't know how I feel about ===. I'm guessing that using .equals() is still possible.

Richard has a good presentation style. He does a lot of coding during his presentation - writing scripting, compiling and executing them. Unfortunately, since I got internet access, I haven't been paying attention as much as I should - but at least 75% of the class seems to be extremely engaged. An interesting thing about this conference vs. the MySQL Conference in Orlando. At MySQL, almost all the presenters had PC Laptops. In fact, I was one of the only ones with a PowerBook. At this conference, Bruce Tate is the first one I've seen that uses a PC. Almost all the presenters are using PowerBooks - mostly 15".

Groovy can be used for easily writing XML as well as enhancing your Ant build scripts. One thing I'm hearing at this conference, as well as seeing on blogs recently is that AppFuse's build.xml could probably use some refactoring. With Ant's new import feature and the ability to write scripts in build.xml - it's likely it could be greatly simplified. Then again, it ain't broke - so why should I fix it?

Richard's showing us how easy it is to write XML using Groovy's shell:

import groovy.xml.*;

x = new MarkupBuilder();
a = x.Envelope { Body("Hi")}

If you run this, you'll get:

<Envelope>
  <Body>Hi</Body>
</Envelope>

An interesting thing from the above demo. When Richard added "print a" as the last line in the script, it printed "Envelope" after the XML output. He said this is because the last line in Groovy is treated as the script output. That's kinda wierd IMO. GroovySQL - pretty cool and simplistic. A nice feature is that connections are automatically closed (when the script completes). Another thing Richard mentioned is that Files are also automatically closed - even when used inside an Iterator. It seems to me that Groovy is trying to stop many newbie Java developer mistakes, as well as do more automatic resource management (closing files and connection). This is actually similar to Spring in how its JDBC and ORM support manages closing connections behind the scenes. Good stuff - another tool to make life easier for Java Developers.

[NFJS Denver] Dave Thomas and Open Source Ecosystems

Dave's talk is about bringing open source development practices into a corporate environment. The talk is not about developing open source, it's about learning from open source. Open Source is a way of developing software, a way of structuring communities and a release for frustrated developers. Dave definitely hits the nail on the head with communities and frustration. It's refreshing to work on open source projects where you have a say in the design and release goals. It's especially nice with software like Roller and AppFuse - I'm my own customer so I tend to know what I'd like to see the software do.

Open Source is driven by need, whereas many commercial products are not. Dave has had a fair amount of experience (in consulting) where he's written several thousand lines of code that never got deployed. Open Source software is measured by value - "release early, release often", encourage value, respond quickly. One of the greatest parts of open source (IMO) is feedback. Since I've been working in small development teams for the last couple of years, its essential for me that I get feedback from the community to tell me if my code looks good. It's a great way to get code reviews. BTW, speaking of feedback, Roller now has a WishList. Let us know what you want to see in Roller and we'll try to accomodate the most popular wishes.

Open Source is likely to produce high-quality applicable products because it's: driven by need, measured by value, and controlled by an evolutionary process. It also results in a very unique structure of community: volunteer, self-organizing, and geographically and culturally dispersed. Open Source projects don't have org charts. Teams are built by accretion - roles are recognized by people who can fill them, agreed by consensus. I can see where Dave is going with this. If you were able to say "I'm good at X" and you would end up doing X - development teams could be much more productive. Open Source projects consist of an Owner, Committers and Helpers. Helpers are usually power users that suggest changes and suggest improvements. In my experience, the most successful projects have very involved owners. After the Helpers come the Users - a.k.a. the Parasites! (Dave's words not mine).

This guy is good, there's been lots of laughter in this room. Dave is truly engaging and funny.

Open Source is a release for developers. Developers typically leave their day jobs, go home and work on their own time, for no money. Managers want to know why more than anything. What can you do in a corporate environment to make developers excited about their work. How can managers make developers enjoy their day job as much they enjoy open source development? One guy in the room suggests that open source allows developers to "do what they want to do" rather than "what they're told to do." Dave refutes that in saying that most of the open source work he does is support on existing projects. The crazy thing about open source - there's hundreds of thousands of developers, tens of thousands of projects - many of which produce high-quality software for little or no money with little or no management. Corporate managers wish they could figure out how to harness this energy for their own software development projects.

The major difference between open source and corporate projects? In open source, the person who starts the project cares and is capable of creating the solution. In a corporate environment, its rare that the person in charge of the project really cares - and its even less likely that they'll be the one who implements it. The solutions that Dave has seen work is when a Senior Developer and a Business Analyst are married. This way, you end up with a team that cares and acts similar to an open source project's owner. It sounds a bit far-fetched to me. The best way to bring open source practices in to a corporate environment is to adopt Agile Methodologies. Speculate -> Collaborate > Learn.

My battery is about to die - I'd better sit back and listen and quit blogging until the next session. I'm having a tough time deciding if I should go to Advanced Version Control (Thomas) or Intro to Spring (Tate). I think I'll go to Spring and if its too basic, I'll skip out and go to Dave's CVS talk.

Full Time vs. Contract

I talked with some folks yesterday about joining their company as a full-time employee. Their opportunity sounds awesome: using open source tools to develop a product. The opportunity certainly appeals to me. In a sense - I could get paid to work on AppFuse. I could get paid to do the stuff I wake up early and go to bed late for. I could spend more time with my family because I'm doing my "moonlighting" stuff during the daytime.

At least that was their sales pitch.

In reality, no company in their right mind is going to pay me to work on all the open source projects I contribute to: AppFuse, Roller, Struts Resume, Struts Menu and DisplayTag. Sure, they might allow me to work on AppFuse and Roller for a few hours a week, but I can guarantee that I'll still want to contribute to the others - and hence, continue to burn the midnight oil. I've also started to think that the main reason for doing stuff "after hours" is because I spend my evenings with Julie and Abbie - whereas I used to work in the evening.

More than anything, the opportunity really got me thinking about doing full-time work vs. contract work. I've been doing contract work for almost 3 years now - and I've only had 2 months of no work in that 3 year period. So that whole contracting is so unstable has been a myth for me. In fact, I see contracting as more stable than an employee position because I control my own destiny for the most part. NOTE: This post is likely a bit biased because my contract just got extended until the end of the year and I'm working on an AppFuse-based application. In other words, I love my job right now.

The thing I enjoy the most about contracting over full-time is freedom. I am planning to take 7 weeks off in the next few months (3 weeks for Spring Live, 4 weeks for the new baby) - and with a full-time gig, that would be impossible. I also like the ability (again, this is probably because my current client is so cool) to take a week off to attend a conference, or take a few days off to run off and do some training. The fact that I'm not tied down to one client/company is awesome. With the full-time opportunity I'm considering, I feel like I'd be marrying a woman I met just a few weeks ago. I guess most full-time gigs are like this after you've been set free with contracting.

One of the main reasons I'm considering this full-time gig is because I don't know where I want to be in 5 years. Most of my career aspirations have been met. When I started in this industry, I wanted to gain enough knowledge about what I do to speak at conferences and such. I did that last week and it was a blast - but I don't really want to do that every month - especially if I have to travel. Traveling away from my family is no fun - and happiness is more important than anything. The nice thing about the full-time gig is that its centered around a product, rather than services. Services (i.e. consulting) are great - but they're only good as long as I'm capable of working. Developing products that earn money while you're on vacation - that's the ideal situation.

The only thing I don't like about my current contract is that I'm a lone wolf. I'm the only guy developing the current app - which is great, but there's no "team spirit." My favorite job ever had awesome team spirit. This opportunity is a startup, which often leads to team spirit - but they also enticed me with ideas of working with a smart bunch of developers. If you've ever worked with smart people, you know that this is a real treat. Learning from your peers just by going into the office is quite a rush. When someone tries to find their answer on Google before asking you - it's refreshing. But is this worth giving up freedom for?

Another important consideration is compensation. Contracting tends to pay 50%-100% more than a full-time position. Of course, this full-time opportunity has options (which supposedly narrows the gap), but we all know that those rarely come to fruition. And if they do - it usually takes a couple of years. I am well aware that a cool job is waaayyy better than a good paying one, but still - getting paid well is nice.

Lastly, to throw a wrench into everything, someone sent me an e-mail last night suggesting they might (someday) be interested in paying me to do full-time AppFuse development. Heh - now that sounds like the ultimate dream job.

i18n - synching up Struts and JSTL

As he did with Roller, Jaap van der Molen made some enhancements to AppFuse to fully support internationalization. He also translated all the existing keys to Dutch. What a guy, eh?!

After I installed this enhanced version of AppFuse, I noticed a few quirks. Namely that my default language was Dutch. To me, this meant that my browser's local must be Dutch. However, since it wasn't, I knew there had to be an issue. After a bit of Googling, I found my answer. It turns out that if you don't specify the language on your default properties file, JSTL won't pick it up - and it defaults to the first one with a language specified. This means that you must have ApplicationResources_en.properties instead of ApplicationResources.properties. Also, another quirk is that you need to synch up Struts locale-setting and JSTL's locale-setting. To do this, I added the following method to my ActionFilter.java class:

    // keep JSTL and Struts Locale's in synch
    Locale locale = (Locale) session.getAttribute(Globals.LOCALE_KEY);
    if (locale == null) {
        locale = request.getLocale();
    }
    if (request.getParameter("locale") != null) {
        locale = new Locale(request.getParameter("locale"));
    }
    session.setAttribute(Globals.LOCALE_KEY, locale);
    Config.set(session, Config.FMT_LOCALE, locale);

Even with all these "hacks" - Mozilla and Safari handle this stuff differently on the Mac. Jaap says that everything works fine on Windows w/o these hacks, so maybe it's just an OS X thing. Regardless, to make things easier, I've added the ability for users to switch between languages by clicking on their language of choice.

There's nothing like adding a new feature to something you're about to demo! I'm on in 45 minutes - the butterflies are fluttering like mad...