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.

Change the World — One Program at a Time

This is a very late comment about Pycon2007.

At that conference one Ruby/Rails book author said something like; “I really like the vibe here. Everybody here is talking about making a difference, educating third world children, building better communities, and making the world a better place.” And he was setting this as a stark contrast to his experience of RailsConf where “everybody was talking about how much money they made.”

On one level it’s hard to fault the Rails conf people for this. Money does on some level validate what they’ve been doing, and it isgood to feel that kind of validation.

But, I think it’s fair to say that the Rails people have been too focused on proving something, and that has lead to a perception that many rails folks have a chip on their shoulder, or are totally focused on money as a metric of success. The extent that some elements in the Rails community have embraced this perception (as mentioned on Martin Fowler’s recent blog posting), is actually a bit frighting.

So, I think Chad is doing exactly the right thing by encouraging the Rails community to take a look at how they can improve their image. A couple days ago Chad posted a blog entry entitled “Change the world” and I hope that it makes an impact in the Rails community. I definitely see Chad Fowler many of the other members of the Rails community that I know personally as good guys, and I’d like to see the current negative stereotyping of the rails community come to an end.

I’d like to see the Rails community as a whole step up to the plate, and focus their attention and marketing efforts on new projects with altruistic goals. Turn the whold Buzz machine towards something that will really change people’s lives — replacing Java just isn’t a worthwhile goal when compared with helping to feed hungry people.

So, in the hope that a little good natured competition can spur things forward, I’d just like to mention that I think the Python community is beating the pants off of the rails community in the change the world department. Here are a couple of projects that I could think of off of the top of my head which the Python community is working on:

• Irrepressible.info — which is focused on fighting censorship
• the OLPC project — which aims to bring better educational materials to millions of underprivileged childeren around the world
• the Open Planning Project – which aims to provide tools for grass roots community improvement tools.

On another note, over the last 6 months or so Compound Thinking has been been working for Philantech on a project called PhilanTrack which takes a slightly different tack. The goal of the Philantrack project is to make it easier to manage the process of giving, receiving and reporting on grants.

The idea is that “greasing the wheels” of grant giving, and allowing non-profit organizations to focus more on doing the work, will make the nonprofits more efficient, more fun, and ultimately make the world a better place.

We may not think about it, but we geeks have a lot of individual power, and collectively we really can make the world a better place. If you’re working on a Rails or Python app that can change the world for the better, drop a comment here and let us all know.

Code Mash

Some friends of mine are putting together a non-denominational developers conference called code-mash in Ohio this January.

Looks like Python and Ruby are both going to have a good number of talks. I’ll be talking about SQLAlchemy, which is the best object relational mapper I’ve ever seen. There’ll be talks about Test Driven Development in Python, Enterprise Architectural Patterns for Python developers, along with lots of cool talks about Lean Software Development, the side benefits of Test Driven development.

You can still submit a talk proposal before November 30th, and you’ll get free room and board. I think it would be great to see somebody talk about Dabo and Desktop application Development in Python, and they seem to be missing any talk about OSX/Cocoa stuff, which I’m sure is because they haven’t had any proposals yet.

It would also be nice to see a good cross platform development with Mono talk…

I’m really excited by the opportunity to get developers of all kinds together and talk about how to be productive and learn more about the strengths and weaknesses of the various tools/frameworks people are using.

Will Ruby and Rails save my IT Department?

My client is not an IT person and he knows nothing about programming…. I started sharing [Ruby on Rails] with him…. About ten minutes into my presentation he interrupted me and said, “So, this could save my IT department, couldn’t it?”

This is from Dave Thomas’ blog, where he is quoting an e-mail where Eric Knapp just gushes about the possibilities that Rails brings to the table. It seems nice enough, and everybody is well intentioned. But, I must admit I have my doubts. First of all, it sounds like a thousand non-technical managers getting sold on some new technology without taking time to understand the real life benefits and risks.

But it goes further than that, I doubt that Rails will ever save anybody’s IT department.

Can it make IT departments more productive? Absolutely. But when a department is broken that’s not usually just because they have bad tools, it’s because the staff either aren’t interested in finding better tools, or they are crippled by organizational red tape, or they are too afraid to tell management that the current tools suck.

“Whatever they say the problem is, it’s always a people problem.”
– Gerald Weinberg

Rails, TurboGears, Django, Plone, and even Zope and EJB 3 all offer the hope of more productive web development. Better tools are important. But a growing, healthy, team can discover, evaluate and when necessary the fit between these new tools and their current projects is the critical factor in long term success.

Rails may appear to be the world saving framework today. But it is not the end of the road, people are hard at work inventing better tools (for example, SQLAlchemy is poised to become a far better Dynamic Language based ORM than ActiveRecord), and if your team can’t evaluate new tools as they come they will end up stuck when Ruby on Rails is surpassed by other tools.

If you Rails is the end of the line, rather than just a remarkable jump forward –which will itself be left behind by new tools in the future — you’ve been fooled by the hype machine.

By the way, since I’ve noticed a few people in the Rails/Ruby community have a thin skin, this whole post should in no way be understood anti-rails. The problem is not the technology it is the marketing and the the uncontrolled hype which doesn’t admit the limitations of the technology.

But, in the same way that Rails won’t save your IT Department, TurboGears will not save you, nor will Zope, or EJB 3.

You have to save yourselves by becoming a place where software teams have the freedom to learn, grow and experiment with new tools.

Python, Ruby, Rails and Readability

When developing code you should always choose readability over convenience. Code will be read many, many more times than it is written…

–Practices of an Agile Developer by Venkat Subramaniam Andy Hunt

This quote from Ruby advocate and Rails book author Andy Hunt, explains why I work in Python even though Ruby has anonymous blocks and slightly less historical baggage than Python.

I recently taught a couple of free introductory classes, one for Python and another for Ruby. People with little experience in either language, could quickly read Python code. But with Ruby — and Rails in particular — there is so much heavy use of the “power features” of the language — like dynamic classes — that code readability was severely compromised. New programmers were quickly confused and lost. There were lots of “where does this happen” questions. Dave Heinemeier Hanson carries most of the blame here: Rails is built on his philosophy that values “convention always trumps configuration” and “less code is better” so highly that other critical considerations like the value of locality and orthogonality play in making code readable. In my view this is a serious mistake. After all, Code is read more often than it is written!

Wherever possible methods should be understandable on their own. No matter how powerful dynamic classes and objects are, using them means there will always becode elsewhere in your system that changes the behavior of the code you write — that means you have to know about and understand all of that elsewhere just to understand — and debug — the object in front of you.
For example, Rails has this nifty feature where Database classes map to table names that are the plural of the class name. This auto-pluralization like other Rails hacks is cute and fun at first, and it certainly makes the surface of the code shiny and pretty, but it also creates a layer of indirection and “magic” that obscures what is happening under the covers.

Of course, sometimes you have to make hard choices and it’s worth sacrificing code readability for other concerns. I’m not disputing that, I’m just saying the code you write — if it’s used and maintained — is going to be read many, many more times than it is written. So, you ought to optimize for the code reading experience, and more than any other language I’ve used, Python is designed just that.