I used to use blog@ryanlowe.ca on places that were posted publicly like blog comments and domain registrations. I also used to use it on this blog for people to contact me about Ruby on Rails freelancing work. Over the years it became a serious source of spam and almost no useful emails. So as of today, blog@ryanlowe.ca bounces anything sent to it.

If you are looking for a freelance consultant with three years of full-time Ruby on Rails experience then I'm your guy. Contact me at rails AT (this domain). Cheers!

Hey! Heads up lets you manage "temporary" links. They are temporary because you don't know if you want to keep them yet or not. Maybe someone sent you an article/video/website but you don't have time to check it out. You'll still want to keep track of it until you do read it but do you really want to bookmark it in the browser or on a site like del.icio.us? H! is a "TODO" list of these temporary links, so you can prioritize them.

Once you do check out the article, H! lets you send it to other people that use H! (and soon to anyone by email). When H! "sends" the item the other people are notified by email that there's a new item in their H! incoming list. Right now this email appears to be from Hey! Heads Up <help@heyheadsup.com>. Replies to this email address get forwarded to me, the website administrator.

But there are all sorts of problems with this approach to notifying by email, primarily spam filters. Many people are now filtering email by their contact list and/or a whitelist to reduce spam. Unless help@heyheadsup.com is on their whitelist, people don't get H! notifications.

So my question is: would it be better to "forge" these notification emails to appear as though they are coming from the sender of the item? Presumably these people are already in the contact lists of the people they are sending H! items to, so the notification has a much better chance of making it through the spam filters.

As well, seeing a notification coming from a specific person instead of help@heyheadsup.com for everyone could make it easier to sort and prioritize these notification emails in a person's email inbox.

Why is forging emails bad? Some spam filters could flag emails sent by mail software from one domain (like heyheadsup.com) and forged with a "from" with another (like gmail.com). But I've seen the technique used in a lot of places, so it's hard to say how much it is frowned upon. As a website creator, forging emails would essentially be sending emails on a person's behalf.

How about the industry leaders? Facebook's notification emails have a from text that looks like: Facebook <notification+m1--ujud@facebookmail.com>. The strange reply address could be used to sort feedback but otherwise it's a little confusing. To top it off, using a similar-but-not-quite-the-same-domain (facebookmail.com instead of facebook.com) for emails is a common phishing technique.

Are there more precedents? Is there any consensus? Opinions are appreciated. Would you want a site to send notification emails in your name?

BTW, if you want to give H! a try it is in alpha testing. Fire me an email at blog[at]ryanlowe[dot]ca to join the alpha test group.

pre·tire·ment is when a person take themselves "off the market", moves from downtown to the suburbs and subsequently raises kids on a responsibly-attained fixed income. Fun is sometimes deferred until the retirement years and money is (again) responsibly saved to pay for it. Other features of pretirement include a mortgage, car lease payments, thirty pounds and a sudden interest in interior decorating.

As the name suggests pretirement often directly preceeds retirement, although this isn't always the case, see: born-again bachelor on page 862.

An un·ter·view or a re·cruit and switch occurs when a person is recruited to work at a company, but the company interviews the person as though they had applied for the job. The affect is amplified when the recruiter doesn't participate in the first interview and the reasons for recruitment in the first place are lost in the shuffle. Relatively common in the high tech industry.

Standard Disclaimer

Entries in the Sarcastic Dictionary volumes I through XIV are not to be taken seriously ...with the possible exception of volume IX, it's exceptionally biting.

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.

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.