Posted by Oleg on November 27th, 2009

No Comments

Active state for link_to == active_link_to. A solution for building navigation systems in Rails.

I have a question for you. How do you deal with the logic of setting links as active in your navs?

Actually, I don’t want to know. It’s probably awful. I might have a pretty good solution for you. Let’s take a look at a very simple nav. These examples all use HAML:

Right, that’s great. But how do I insert logic as to what link gets marked as active? To begin, let’s quickly install this random gem:

And then change our nav a bit:

And that’s pretty much it.

So, for example, if you navigate to /kittens/1-my-fluffy-kitten navigation link for ‘Kittens’ will have ‘active’ class attached to it. It’s almost like magic.

You probably noticed that ‘Home’ is highlighted as well. It happened because whatever URL you are currently on is a child of the home_path. I guess we want to mark it as active only if we find ourselves on the home page and not anywhere else. We can fix this:

Hey, wanna render a sub nav when you find yourself browsing /puppies or any page under that URL? It’s just sooo easy:

And that’s the skinny of what active_link_to is for.

For more documentation on more functionality checkout project on GitHub: http://github.com/theworkinggroup/active_link_to

  Posted by Jack on September 24th, 2009

9 Comments

Rails mass mailing – it shouldn’t be this complicated

The requests we get from our clients for “social networking” type tools and features has grown exponentially over the past two years. To make a user experience relevant, easy, secure, means that an application will need to send email notifications to that user (to register, to tell them of friend’s messages, to send them newsletters or updates, to send tickets, calendar bookings .. the list goes on).

Why is this a problem? Because sending an email is not an instantaneous action. The more emails you try to send, the longer you may have to wait as the application sends them. Imagine an app that lets you invite 300 friends to an event. Multiply this with 300 people sending the same invite to their friends.

While Rails was kind enough to provide a simple way to send emails, it left out one important detail. You can only send one at a time!

If you find yourself in the unfortunate position where you need to mass mail then you’re on your own. So what do you do? You Google around of course. Someone is bound to have figured this one out.

It looks like there are 3 ways to solve this:

1. Use existing email marketing services

You can go with this option. There are plenty out there: Mail Chimp, Constant Contact, Thin Data, Campaign Monitor, Campaigner and others. All you need to do is generate some kind of mailing list and import it into one of these systems and then keep it up to date. But that’s not always practical. Not if you want your users to be able to initiate the mass mailing by themselves.  Don’t get me wrong, these services are great at what they do, but what we really want to do is to send mass emails from our own app.

2. Use existing code

If you really want your Rails app to be able to send mass mails at a click of a button you can try using Eric Hodel’s ar_mailer which is on version 1.4.0 as of June 2009. This has the advantage of letting you use the email addresses that you already have on your system (no exporting and importing to a different system) but before you get to that you still have to integrate it with whatever version of Rails you happen to be using.  Assuming you get it working properly, now you have a brand new background process to take care of.

Ar_mailer is great but leaves you half way there.

* The queue is not smart enough to prioritize emails. If one user sends 5000 invitations and after that another user wants to recover his password, he’ll have to wait until all 5000 emails are sent before he gets his password back. The users receiving the invitation won’t notice if  it takes a bit longer to reach them, but the guy that is trying to recover his password will be upset if he doesn’t get it right away. This is obviously not good enough.
* How do you monitor if an email has been sent or failed?
* If you have an email template and your client wants to change it all the time, what do you do?

3. Build it all from scratch

Even if you decide to do it yourself from scratch you’ll still need a queue to store the emails that will be sent at some time in the near future by another process running in the background. From there on, it depends on what you really need. Be prepared to put aside some extra time because it ain’t simple.

So what would be the perfect solution? Simply put: I don’t want to have to worry about it. I want to be able to say: “Here’s my email, here’s the list of people I want it sent to. Go and do it … please”.

Wouldn’t that be great? Sure it would! We’ve encountered this problem enough times to make us want to solve it for good.

And so we’ve set out to build it and this is what we think a mass mailing solution:

1. I want to be able to use it independently of the language I’m coding in – it needs to have an API
2. I want to be able to use the same code I have right now (layouts, email templates, etc.) – it needs to integrate easily
3. I want to know if a specific email was sent, failed or if it hasn’t been sent yet and I want to know why – it needs reporting
4. If a client complains that the emails aren’t rendering correctly I want to be able to see what they are receiving – it needs to let me look at the emails sent
5. I want to be able to easily resend any email – it needs to let me act on it
6. I want to create and manage email templates so that my client can edit them without asking me every time and without forcing me to change the code and to deploy my app all over again – it needs an optional template management system.
7. I want the queue system to be smart enough to distinguish between a single email and a batch of 5000 emails and prioritize them accordingly – it needs a smart queue system.
8. And most importantly, how can all of this be done with minimal effort to set it up each time I create a new app. – it needs a plugin.

Postage App!

We are currently developing this system which will help us build better apps. We’re building it according to our needs and we think that these might also be the needs of other developers out there. Check it out and sign up for an update on the developer free release!

  Posted by Georges on September 2nd, 2009

19 Comments

Livin’ on the edge: Ruby, Rails, and Snow Leopard

Snow Leopard is out and I like having the latest and greatest, so I bought a new hard drive and clean installed Snow Leopard on it. This meant that I had the opportunity to reinstall my development environment with the benefit of a few years of experience and the advice of my fellow TWG’ers.

Here’s how I got my newly installed Snow Leopard up to speed for Rails development.

Ruby 1.9.1

First, I got Ruby up to date. Snow Leopard comes with Ruby 1.8.7 by default. There are many benefits to going with Ruby 1.9.1, so I went with that.

I wasn’t 100% ready to commit to Ruby 1.9.1, so I used rvm to manage my Ruby interpreters. Many gems aren’t ready for 1.9 prime-time, so I wanted the ability to drop back to Ruby 1.8 if this blew up in my face. For an overview of what is working under Ruby 1.9, check out isitruby19.com.

I installed rvm with:

Check out the rvm site for more information. There’s some great documentation there.

Next, I ran

to see all my installed Ruby interpreters. When you do this, you’ll see that the only Ruby installed is the system Ruby 1.8.7.

I ran ruby -v to see which Ruby was being used by default. I saw that I was using Ruby 1.8.7:

rvm will happily install and activate any version of Ruby you want.
I got it to install Ruby 1.9.1 with the following:

rvm will check to see if 1.9.1 is installed and, if it isn’t, it will download and install it for you. Once that is done, I ran rvm list again and now saw Ruby 1.9.1 listed as well as Snow Leopard system Ruby.

After that was complete, I ran rvm 1.9.1, and then ruby -v and saw that it worked:

But, I wanted Ruby 1.9.1 to be the default on my system. I got rvm to set that default by executing:

Now, the system is set to use Ruby 1.9.1 by default.

Side note: one of the neat features of rvm is that it can change your Ruby interpreter on-the-fly for you. This change isn’t permanent and only lasts for as long your Terminal session is open. For example, you can open one Terminal, execute ‘rvm system’, and have that Terminal use the Snow Leopard Ruby 1.8.7 while another one is running Ruby 1.9.1. This is very handy for compatibility testing.

MySQL

The next piece of the puzzle was MySQL. I have found that the best way to install packages like MySQL is via MacPorts.

If you haven’t done it yet, install MacPorts from here. There’s a package for Snow Leopard, so be sure to select that one.

The MacPorts MySQL package is called mysql5-server-devel, so I installed that:

MacPorts will handle all the dependencies and then install MySQL. I followed all the post-install steps that the installer recommended – start-up items, etc. The MySQL it installed is 64-bit, as it should be.

I then had to connect Ruby with MySQL and I needed the gem for that. To properly install the gem, I had to specify the architecture and the location of the mysql_config5 utility. The arch setting ensured that I got a 64-bit gem to go along with my new 64-bit MySQL installation.

Ruby Gems

I then ran gem list to see what gems I had installed. If you do this, you’ll see what I saw: not much. This makes a lot of sense because gems are installed relative to the version of Ruby they were installed with. So, all the gems that Snow Leopard had installed for Ruby 1.8.7 are no longer around for use. It was at this point that I was happy I used rvm. I dropped back to 1.8.7, got the list of installed gems and proceeded to re-install them under Ruby 1.9. But, dear reader, you don’t need to do this! Here’s how to get back to the default Snow Leopard gems under Ruby 1.9:

This’ll take a while. Go grab a coffee. Run around the block. Do something fun.

If any of these fail for you, check out isitruby19.com for tips on how to get it working.

Passenger

The next piece I needed was Passenger aka mod_rails. I needed version 2.2.5 (newest as of writing) for this to all work together. I installed it with:

This retrieved and compiled Passenger 2.2.5 for me. It might get a newer version for you. Once that completed, I ran:

The Passenger module depends on your current Ruby version, so you have to re-compile Passenger if you change your Ruby version. It is important that the Passenger compilation properly links with the Ruby interpreter you want to use. In this case, that’s Ruby 1.9.1.

When you do this the Passenger installation, double-check the paths that the Passenger compilation process outputs and ensure that it is properly finding the Ruby 1.9.1 installed in your .rvm directory. If you see paths that don’t go to .rvm in your home directory, then it is doing it wrong. If this happens, ensure that rvm is set to use 1.9.1 by default and try again.

Next, I edited my httpd.conf just as the Passenger installer recommended. I opened it up with open /etc/apache2/httpd.conf and pasted in the Passenger lines.

The Passenger Preference Pane makes everything easier, so definitely wanted that.
I got lucky and found that it had just been updated to support Snow Leopard, so make sure you get version 1.3 or greater.

Taa daa!

That’s it!
Set up a Rails project in the Passenger Preference Pane and try it out! You should see your fully functional Rails app running.