« August 2007 October 2007 »
blog header image
# Tags Hierarchies

I would like to explain an idea I have before I try to implement it. I wouldn't doubt if this idea has been done before but I can't find any Rails implementations of it.

I want to support a tag hierarchies on Hey! Heads Up. Tag hierarchies will result in implicit tagging, which most people do in their heads anyway. Examples of implicit tagging will probably help:

1. Something tagged 'hockey' should also be tagged 'sport'
2. Something tagged 'MacBook' should also be tagged 'Apple'
3. Something tagged 'Rails' should also be tagged 'Ruby'

"Why would I want all of these generalized implicit tags on my stuff?", you might ask. In Hey! Heads Up you can view your item lists by tag. If I wanted to read all of the sports items I'd have to go through hockey, football, baseball, golf lists individually.

I could support AND-ing these tags together in the URL -- and I want support that, as well as support OR -- but just being able to say "give me everything tagged 'sport'" would be much cleaner.

Tagging is a personal thing and it seems like everyone does it differently. That's one of the advantages of tagging over a predefined hierarchy. But a lot of people don't like to be redundant. If I tag something with 'hockey' I'm not going to explicitly tag it with 'sport' as well.

When tagging replaced hierarchies as the new way to classify/organize things in the "Web 2.0" world, we lost something. We lost the implicit nature of hierarchies because tags are a flat taxonomy. The upside is that now it's easier to classify things with tags that are orthogonal subjects -- like 'hockey' and 'book'. But the hierarchical nature of each subject that was so handy is lost, so my hockey book wouldn't be classified with 'sport' and 'book'.

How do I support a tag hierarchy taxonomy? I could make a global taxonomy for Hey! Heads Up and force implicit tags on people but that doesn't sound right.

A better solution is allowing people to create their own tag hierarchies. Then they can make the hierarchies for certain subjects as detailed as they want them to be. Every orthogonal subject would have its own tag hierarchy -- the subjects wouldn't be linked together at the top of the taxonomy.

Sure it's more work for people to set up but people who care about it will think it is worth it. People already set up tagging (labelling) for web applications like Gmail in advance. For everyone else, tag hierarchies will be optional and regular tagging will still be supported.

If Gmail had label hierarchies, I would definitely use them. But perhaps I'm in the minority.

How I implement tag hierarchies on the back-end isn't that important to this discussion but it could result in a new Rails plugin, if there isn't already one out there.

posted at September 27, 2007 at 11:29 AM EST
last updated December 9-, 2007 at 18: 1 PM EST

»» permalink | comments (12)

# Twisting Rails is Risky Business

I normally don't jump into the PHP vs Ruby/Rails debates but this time I can't help myself. Found via Darcy Whyte, Derek Sivers' provocatively titled article 7 reasons I switched back to PHP after 2 years on Rails deserves a reply from the Rails community.

Let's start with his quote: "...twisting the deep inner guts of Rails to make it do things it was never intended to do. But at every step, it seemed our needs clashed with Rails’ preferences."

Derek switched his project from PHP to Rails, didn't do things "The Rails Way" and wonders why it was difficult. The project failed and he rewrote the new version in PHP in two months, creating a smaller and custom framework inspired by Rails in the process.

The Rails framework helps developers if they follow the conventions and can hurt them if they deviate too far from them. Jeremy Kemper (bitsweat) knows this -- as do all good Ruby on Rails developers. From his description of his project, it sounds like Derek used Rails improperly.

Maybe Jeremy should have been more assertive about how Rails is meant to do things and explained The Rails Way better. When you're a Rails expert that's part of your job because people are still getting used to Rails' new approach and how it can help them. A Rails expert needs to explain to his boss the impact and risk of deviating too far from The Rails Way.

Of course PHP is a better solution than Rails for writing a custom framework, it's a programming language. He would have been just as successful writing his custom framework in Ruby. Trying to "twist" a framework like Rails into a custom framework is just asking for trouble. Use a hammer for nails, don't blame a wrench for not working well.

Sure, Rails has "The Rails Way" conventions for developers but that doesn't mean it's too templated and all Rails applications end up looking the same to users. There's a lot of UI flexibility available and copying existing "web 2.0" look and feel is a design decision. From the outside Rails applications can look like applications from any other framework or programming language.

Quote: "Is there anything Rails/Ruby can do that PHP can't do?"

No, there probably isn't. Is there anything PHP can do that Ruby/Rails can't? From the end-user perspective, probably not. So we're in a dead heat -- but that argument is a red herring.

If you follow The Rails Way, development can be *faster* than PHP because a lot of things are done for you, like object persistence with ActiveRecord. The tools need to be used as they were intended.

The moral for Rails projects is this: Learn about The Rails Way before you start. Don't go off the rails and override a lot of the default behaviour if you can't handle the business risk of doing so. Pun intended.

posted at September 27, 2007 at 09:52 AM EST
last updated December 9-, 2007 at 18: 1 PM EST

»» permalink | comments (0)

Search scope: Web ryanlowe.ca