What I've Learned at UberConf - Part 1

I've come down to Denver this week for ÜberConf 2011. After the first full day of sessions, it's been a great time with lots of learning opportunities. I thought I'd share some of the insights I've gotten so far.

Java Script in HTML 5: Tim Berglund did a great job highlighting some of the JavaScript API's available in HTML 5, showing some nice concrete examples. I was most fascinated by Canvas and its graphics rendering capabilities. JavaScript's future is clearly brighter than its past.

NoSQL and Distributed Data: Again with Tim Berglund, he totally de-mystified this domain space. Before now, I'd heard alot of buzz about NoSQL, but didn't really have the opportunity to fully understand what it was. We went over several different databases, where we learned that they are mostly quite simple. I'm looking forward to trying out MongoDB, where my data is stored as a denormalized JSON document.

I also attended a detailed intro to Casandra, which has a great scaling strategy. Cassandra's modelling strategy is fairly simple as well. To over simplify, it basically amounts to a hash table of hash tables. I'd encourage you to check it out.

Finally, I went to an intro to Hadoop, where frankly I got a bit lost. What I did get out of this talk is that it is probably best to use Hadoop through other API's, such as Hive.

Architecture: I attended 2 great sessions by Ted Neward: Pragmatic Architecture and Architectural Kata. The Kata class is actually a workshop, where you have to work with a group of strangers to come up with an architecture for a complex fictional product, and then present it to the rest of the group. It's a difficult task, and quite fun.

I think my biggest take away for the day came from Ted's Pragmatic Architecture class, where he asked "When will you know if an architecture is bad?". The answer: "When you try to write code against it". The point is that it's important that software architects are involved in the development of code.

I've seen on several occasions where architects are former developers who are now some form of manager or in another role where they aren't directly involved in writing the software. The big question with this approach, how are you supposed to make sound decisions if you do not know the consequences of those decisions? How can you know if you're not doing the work?

So, for all you architects out there, the architectural committee doesn't need to be "the place programmers go to die" (another Ted Neward quote). Find a way to stay active in development or don't do the job. If you insist on doing it "old school", don't do it by yourself. It is vital to get feedback on any architecture from the developers.

That's all for today, I'll hopefully find the time to post about more exciting learning events over the next couple of days.