Compound Thinking

Relational Databases as an “implementaiton detail?”

I found this little tidbit in amidst the hugely overraught comment treads on Derik’s post describing his return to PHP from the wonderful world of Ruby on Rails:

I loved the part about the database as an “implementation detail.” That sings to me.

–Daniel Waite

And, in spite of the poetic hyperbole of folks like Daniel, I think relational databases exist for good reasons and knowing about how they work is a good thing. Active record treats the database kinda like a big hash table in the sky, which is OK for some applications, but not so OK for others.

I find that large, complex apps have a way of growing in unexpected ways over time — and relational algebra is much better designed to handle unexpected requests for complex datasets than hash tables or even the most well designed objects. SQL, and relational algebra are implementation details in the same way that using a hammer is an implementation detail in building a tree house. Sure you can do without, but you will have a harder time, and will definitely end up building a different treehouse!

Don’t misunderstand me, Object’s are good things, and I sure as hell hope people understand them, use them, and make great software with them. But relational algebra is a good thing too. And it’s become clear that any really good database toolkit can’t forsake one in favor of the other, and that’s why SQLAlchemy, Storm, DejaVu, and Hibernate are all better tools than Rails’ Active Record.

As for Derik’s original article. In spite of all the brouhaha, Derek’s post basically says: “hey I liked Rails, and I learned a lot about good programming from it. And ultimately it was easier to get my site rewrite done in PHP because I learned rails first.”

I think it’s obvious that Rails could have done the job for Derek, but two things got in the way:

• everything was already in PHP so Rails wasn’t and incremental update, it was a rewrite.
• Active Record got in the way of using SQL as a relational algebra engine, rather than a glorified hash persistence mechanism.

TurboGears users should pay attention to both points. If you have a large complex app, you’ll be better off with an ORM that treats SQL as a full partner, which is why we’re migrating the defaults to SQLALchemy which does a fantastic job of making both relatinal algebra, and object oriented programming part of it’s core.

The second point is much harder to deal with, but if you can wrap existing application functionality in a larger TurboGears app, and migrate it piece by piece you’ll definitely have more success. I’ve been doing a lot of Web Service architecture stuff this year, and that’s proven to be a great way to connect existing resources to TurboGears applications.

Undo, it’s the right kind of cool for your app!

I still keep seeing lots of web applications which use pop-up alerts to make sure users don’t accidentally do something “terrible.” Occasionally that’s OK, but most of the time what you really want to do is make users feel comfortable with your UI, and big scarry warnings are the oposite of safe and comfortable.

And in lots of cases, undo is way better, users can fix things themselves, and they don’t have to worry that their actions are irreversible. Here’s a good blog post about how to implement simple undo functionality for your ajax based TurboGears applications (OK, so there’s nothing turbogears specific here, you can do this anywhere, but I recommend you do it with you TG applications, because it’s the right kind of cool. The kind that makes users feel safer, and makes their lives a bit easier.

It’s easy to fall into the trap of adding cool javascript animations that look awesome, but don’t increase usability. Simple undo is the oposite of all that, it’s pure user friendly goodness, and more people ought to be doing it.

Change the world with TurboGears, and get paid to do it!

I’ve done a bit of consulting work with the Law School at Stanford University recently, and they are looking for a full time coder to help them change the way patent law is handled in the US.

They have a very cool TurboGears application that will radically improve the transparency of the way out legal system handles “intellectual property.” And they plan to make orders of magnitude more intellectual property data publicly available than we’ve ever seen, and they intend to do it with a python/TurboGears based system.

Ultimately I think this data has the potential to:

• to expose people who abuse patent, copyright, and trade secret laws,
• and to highlight problems with the way intellectual property laws are enforced,
• and ultimately to give us the raw data we need to make intelligent and lasting changes in the whole system.

At the same time it can help to prove that you can build high-traffic, robust systems with Python and TurboGears. They are also doing all kinds of interesting things with search, language processing, and have some amazingly smart people on their team. But they need a fantastic web developer to help them get this amazing stuff into the hands of real people soon.

Which is where you come in, if you’re available or can make yourself available, and you want to be part of something really impressive, feel free to drop me an e-mail at compoundthinking@gmail.com, and I’ll put you in contact with the right people.