Archive for April, 2007

Learn Web 2.0 Development with TurboGears

I’ve been swamped lately, starting a new company and a new job, and a couple new book projects.

But I really want to start running some online classes again.

Classroom

I’d like to help people who are facing the learning curve of Web 2.0. Perhaps you’ve done some basic web stuff, but the thought of HTML+CSS+JavaScript+ServerFramework seems like it’s too much to learn on your own. My theory is that it’s better to learn in groups, so what I hope to do is organize some online classes which bring together groups of people who are interested in helping each other learn all this web 2.0 stuff.

I have some basic materials from the PyCon 2007 tutorials on TurboGears, which should supliment the book to provide plenty of material for the server side stuff. And we can use some existing resources for the HTML, CSS and JavaScript stuff.

I’d also be interested in doing a local class in the South East Michigan area on a couple successive Saturdays — but I need a good location, so if you’re in the area, and want to help make this happen drop me an e-mail at (mark at compound thinking dot com).

I’m still getting getting the website setup for all of this, and how I’ll be able to manage the bandwidth requirements of the class. An the class will be “free,” except that I’m going to ask people to pledge to volunteer some time on either a local charity, or working on some open source project.

This will be a learning experience for me too, so if you’ve done something like this before, feel free to e-mail me with whatever tips you might have (mark dot ramm at gmail dot com).

And if you’re interested in taking the class, watch hear for final details sometime next week.

Bar Camp Ann Arbor Mailing List

It looks like there are a few other people interested in bringing the Bar Camp idea to Ann Arbor that we ought to be able to make it happen this summer. If you want to find out details as soon as possible, please feel free to sign up for the Bar Camp Ann Arbor google group, or keep checking back here.

Of course, we’ll be hosting this in Ann Arbor, but we hope it will be a larger regional event. And if you’re interested in helping, feel free to email me (mark dot ramm at gmail dot com) and I’ll get you hooked up with the rest of the interested parties, and we can start rockin’.

Bar Camp Ann Arbor?

I’ve been toying with the idea of putting together a Bar Camp later this summer. I’ve got a potential venue, and some interested people. But I’m looking for some feedback, and some people who might be willing to help with some of the organizational details.

If you’re interested, or want to help out, drop me a comment or e-mail me at mark at compound thinking.com

Diagnostics, Problem Definition and “House”

There was a “House” marathon a couple weeks ago, and I caught a bit of it while working on some projects around the house. As I watched it became pretty clear that every episode is built around solving a complex medical problem. And 90% of the show is spent learning about the problem, finding new pieces of information, and testing incorrect assumptions.

I think this is a pretty good description of lots of a lot of projects I’ve worked on as a software developer and project manager. Lots of Software Developers want to get the “Problem Definition” done as soon as possible, and get on to the “real work” of solving the problem. But there’s real danger there, it’s easy to define and solve the wrong problem.

I like the system they use in House — there’s a central whiteboard which contains a description of the problem they’re trying to solve. As the show progresses, the problem definition is continuously updated, and the diagnostic team comes up with various theories. I’ve worked on projects where we the developers didn’t have a clear understanding of the problem, or where our understanding of the problem was months and months out of date.

The result was that we built the software that solved the wrong problem, or in the best case, software that solved the right problem in the wrong way. Either way, what we built fit the user stories we got for that iteration, but wasn’t “well designed” in terms of solving the core problem. In both cases, it was very clear as I talked to the end users after the project was completed, that we could have spent less time, and built better software if we’d just had a clear and up to date picture of the client code.

I think a problem definition whiteboard is a great addition to the standard Agile software system, and I’ve started thinking about how to integrate this into all the projects I’m working on.

I think this is particularly important for Open Source projects with a distributed team, so I’d like to integrate this idea with the TurboGears 1.1 development process. I’ve posted Alberto’s 1.1 roadmap on the Docs wiki (docs.turbogears.org) and I’ll try to keep that as up to date as possible, and to add a very clear problem definition to the top of the roadmap.