I tried to post this yesterday, only to discover much to my embarassment that my domain registration had expired last week. Oops.
Anyways, I’m back at SD Expo, which is what started this blog in the first place. That first experience is what helped push me in a different direction in my career, away from pure management and back into hands-on technology.
Two disappointing changes from last year: the bean bag chairs are gone, it’s impossible to find an open electical outlet, and the (free) wifi is unusably saturated. On the other hand, some of the talks are exactly the same, at least in title, to talks from 2 years ago. Many are new, however, including an entire track for Ruby.
Yesterday, I went to a service oriented design talk by Michael Rosen in the morning. The most interesting thought that came out of that for me was the idea of dividing your services ecosystem into two tiers: a lower-level tier of utility and integration services, and a higher-level tier of business-level services. For example, you might have an Authorization service at the utility/integration level, or a facade for a legacy system at the utility/integration level, but you’d have a “Booking” service at the business tier. This allows you to make different choices about things like transport mechanism and granularity at each level. It also allows you to keep your business services level ‘pure’ and isolated from compromises you must make when integrating legacy systems.
In the afternoon, I went to a Java Security talk by Allen Holub in the afternoon. I’d hired Allen to do an object oriented design class at my company a couple of years ago that I thought was really good. His talk on security was pretty good too; the most salient thing I got from the talk is that the Java security apis really are hellishly complicated, it’s not just that they look that way. Previously, I’d thought that it was just because I didn’t “get it.” But in reality, they’re just too complicated, as I’ve found is the case with many Java APIs. For example, just as the connection string in JDBC contains a lot of vendor-specific parameters smashed into an ugly string, the factory methods in the security api also do.
Today so far I went to a domain specific language talk by Juha-Pekka Tolvanen. This one was one of the sessions I was especially looking forward to because it seems like such a big and obvious win. I came away from that talk with a good link to DSM resources, but with the disappointing news that where these languages tend to be the most successful is in embedded and product markets (like cell phones), where a vendor churns out lots of variations on the same basic product line. There was one example from an insurance company, though, so there’s still hope for me.
