I got in today at 0830 for some breakfast, talked with some coworkers and tablemates, then moved out to the first session.
My first session was once again with Jeff Brown of G2One. He talked about Test Driven Development with Groovy and Grails. TDD is one of those things that I know I should do but don’t discipline myself to do. Groovy does some nice things that I like from Ruby. Duck-typing is great when you are working with tests. You aren’t writing a bunch of interfaces just to make the compiler happy.
Another interesting test piece is the Expando class in GroovyTest. Expand allows you to create a class that pretends to be anything you need such as a file. Therefore you can test object that, for instance, write to the filesystem without actually writing to the filesystem in your unit test.
Interesting clarification was the differences between mocks and stubs. Mocks have strong expectations and stubs have loose expectations. The stubs in GroovyTest are slick. You call new StubFor(class) and get a stub back that you can overload the functionality of, allowing you to change the functionality of a Groovy or Java class for the purpose of your test.
For my second session I had some hard choices to make. I selected Mark Richards talk on Java Persistence over the Powerful Metaprogramming Techniques with Groovy with Jeff Brown, but it was a tough choice. Mark is a Director and Senior Architect at Collaborative Consulting LLC and the Author of Java Transactional Design Strategies.
Mark was a dynamic speaker and really engaged people. His focus was that there will never be a silver bullet for persistence. Each toolset has it’s strong points and weak points. He started talking about the types of Java persistence frameworks, specifically Object-Relational Mapper, SQL Mapper and Standards Based Frameworks.
One of the big differences between an ORM and a SQL Mapper is that where ORM maps objects to tables, a SQL Mapper maps objects to result sets. This has hefty implications if you need to change from MySQL to Oracle. In a ORM the SQL is generated by the API so you don’t need to do anything but change the dialect used by the ORM.
iBatis is a SQL Mapper that keeps the mapping of statements, result sets and such in XML. Since the SQL is not generated automatically you have the chance to tune your queries.
He tangented off to a couple of things. One was the Triangle of Knowledge. The first area is what you know, the second area is that which you don’t know, and lastly is the things that you don’t know that you don’t know. This is important in learning anything new, you can focus on the things that you NEED to know, as opposed to know that you don’t know and therefore can look up. I like to think of this as Just In Time knowledge.
The big finale was talking about the impedance mismatch between reporting queries and ORMs. An ORM is great when you need CRUD operations, but the moment you need to run a complex reporting type query there is no longer a table to map to and no key to get the data from the cache. iBatis makes things easier in that case, but CRUD is a pain. The end result is to combine ORM and SQL mapping frameworks. One limitation, however is that you cannot combine iBatis and Hibernate in the same transactional unit of work. Therefore it works when you have a project with separate CRUD and reporting areas of function.
My brain is a bit full, so I am glad that lunch is next!
BTW: Acronym of the day: RDD – Resume Driven Development. i.e. when someone makes choices based on what technology they want on their resume instead of the requirements of the project.
Recent Comments