CSS Day 2

Tuesday we got an early taste of winter as it snowed an inch or so here. The first session of the day was "Efficient Enterprise Builds with Apache Maven". I learned some of the upcoming features in the upcoming release of maven. One that I really have been waiting for is being able to include pom.xml snippets (rather than only extending). They call this feature "mix-ins" and looks like they will eventually replace "profiles". I also learned that we should revisit the way we manage our repositories at GL. Also remind me to talk to management about making m2eclipse part of our standard RAD install. I also learned more about creating archetypes and how they can help us bootstrap new projects.

Next was "Mastering JavaServer Faces". The first part was mostly basics and a review for me. The rest was a focus on third-party libraries which are really needed in order to unlock the power of JSF. I was glad to see our choice of facelets and RichFaces re-affirmed. These were two of the presenters most recommended libraries. I didn't know a whole lot about RichFaces and came out extremely impressed, especially with the built-in ajax support, as ajax can be tricky with JSF. RichFaces handles it all for you with a rich set of custom tags/components. I think we can use it to enhance the Branded MPN user experience dramatically. Also discussed were offerings from apache including the MyFaces JSF implementation as well as the component libraries Tomahawk, Trinidad, & Tobago. There is a bit of overlap between these 3 libraries which can make choosing one difficult. Again, the presenter suggested turning to RichFaces first, which was comforting as it is already approved for use at GL. Facelets was recommended over tiles for JSF templating support, also comforting as it is used in the Branded MPN.

After lunch was a mostly philosophical presentation titled "Object Orientation, Domain Driven Design and the Honour of the Programmers' Guild". Refactoring is absolutely essential in order to make OO work. Development cycles should use a "wave" approach where the first wave is the core development and implementation of features and the second wave is a refactoring phase to clean up the code and improve the design to align with the business/domain concepts. Code should be written consistently with the terminology of the business/domain and it is a collaborative effort with the business area/clients. I think we do an okay job here but collaboration with the business areas could be better. To paraphrase the presenter:
"The business area knows the concepts of the business, but not necessarily how to logically group and implement the features, and the effect of feature requests on the rest of the system. This is the expertise of the development team. It is important for business and development to be on the same page, so the business concepts are reflected appropriately in the code. As the development team implements features, new logical concepts may manifest themselves, and it is important to share/agree these concepts with the business area so we all are using the same glossary". Refactoring can be harmful however, if it is done without a full logical understanding of the problem domain (Milking a cow analogy). He finished with a story about a guy who worked on the dominant product in the industry (MARC, I think physics related). Again and again, he was not allowed to refactor, became increasingly frustrated and eventually quit. He subsequently built a new, better product (ABAQUS) which ended up replacing the former as the dominant, standard application in the industry. Developers must stand up for what they feel is right, and management should respect those in the code.

Next was a session titled "Pragmatic REST" which was my first hardcore exposure to the concepts and implementation of a REST-ful web application. I learned some of the best practices and common anti-patterns.

Finally was a presentation "Domain Driven Design and the power of Value Objects". GL terminology: VO's are really what he calls DTO's (J2EE patterns book used bad terminology and was eventually revised). Value objects should be business objects that reflect the domain model, encapsulating data and behaviors to improve API clarity and to swallow computational code, thus improving service implementation clarity, and reuse (Phone number example).

Wednesday's agenda includes more REST, Cloud computing, development process improvement/refactoring, SOA, and agile development.