I’ve got my travel plans set for Oredev this November, so now it’s time to think about what I’m doing there. It’s my big conference trip for the year and I’m looking forward to catching up with some friends on the other side of the Atlantic. Just for once I’m trying to get my talk preparation all put away so I can enjoy the other sessions. I think my agenda right now is a lot of Rest, HTML5/CSS3, NoSQL technologies, Ted Neward’s Scala workshop, and some of the general software design topics. For my part, I’m giving talks on:
For as long as I’ve been involved with Object Oriented Programming I’ve heard the exhortations to “favor composition over inheritance.” My own experience has validated that advice, but solid material demonstrating or explaining this advice seems to be lacking. Even if you accept the benefits of a compositional design there’s still the looming issue of determining just how you can compose your system and many developers struggle with object structures and relationships. I think it’s important to have mental tools to help you think through object designs by identifying key designs and the responsibilities that need to be assigned to the objects in your system. One of my favorite design techniques is the venerable “Responsibility Driven Design” approach dating back to the SmallTalk community in the 80’s. In this talk I want to present some scenarios from my work that demonstrate how a focus on compositional design contributes to both reduced developer effort and an improved ability to continually enhance existing systems and how using concepts from Responsibility Driven Design like object role stereotypes that helped me make design decisions.
I’ve gotten a *lot* of experience over the past 3-4 years in constructing Fluent Interface and internal DSL’s with C#. I’d like to share some lessons learned about both the mechanics of creating a DSL (i.e., there’s more tools in ye olde toolbox than method chaining), and the possible applications of small internal DSL’s. Specifically, I’ll be sharing my experiences with using the patterns for Internal DSL’s that are documented in Martin Fowler’s recent book on DSL’s.
My team has a fairly comprehensive suite of automated tests against out web application that have repeatedly found regression issues to the point where we feel confident in our ability to make widespread changes in our application architecture. After a very difficult ramp up period, we’ve managed to learn quite a bit about how to express automated tests to create executable specifications. We’ve learned how to make data population efficient, how to design software for easier test automation, how to write UI driver code, how to tighten up the feedback loop, how to deal with an Ajax heavy world, and how to keep the tests from being too brittle in the face of change. In this talk I’ll present our lessons learned and lead a candid discussion of our experiences to help your team make the cost versus benefit decisions on whether or not to automate testing against your web application. My team uses Selenium, StoryTeller, and TeamCity/Hudson for test automation, but I feel like our lessons learned will translate to other tools like Cucumber and Watir as well.