This inaugural #nerdlearn will focus on THE FUTURE OF RAILS (yes, in all caps), but going forward we’ll choose topics that influence the entire sphere of being an excellent developer.

RSVP here: http://guestli.st/55083

MEET THE PANELISTS:

Pete Forde, Unspace:

In 2004 Pete founded Unspace Interactive. Not long after, he transition from proprietary Microsoft development to becoming one of the first adopters of Ruby on Rails. He was the curator of the RubyFringe and FutureRuby conferences, and hosts the popular monthly “Rails Pub Nite” developer event — of which there has been over 50 to date.

An avid traveler and occasional touring rock drummer, Pete is passionate about music and film photography. He recently co-founded BuzzData, a data publishing and collaboration hub.

Pete also likes to explore places you’re not supposed to go:

—–

TWG’s own, Scott Tadman (brought to you by the number 4):

Since 1990, before most of us had even heard of the web, Scott’s been a database manager, network engineer, system administrator, software developer, creative director, writer, and electrician. So you can bet he’s involved at every stage of the projects TWG produces.

Scott is TWG’s Senior Architect; co-founder of PostageApp.com; and 4-time Science Fair Winner when he was a kid (unfortunately no photo available).

He is also the #4 Answerer on Stack Overflow for ruby-on-rails so be sure to ask him lots of questions at #nerdlearn – http://stackoverflow.com/tags/ruby-on-rails/topusers

You can also find Scott at: twitter.com/tadmanter & github.com/tadman

—–

Kevin Faustino, Nulayer:

Kevin is a passionate programmer and craftsmanship advocate who works at Nulayer as a Senior Software Developer. He has been professionally developing for 6 years, with the last 3 years focused on Ruby and Ruby on Rails.

When not working, he is organizing the Toronto Ruby Brigade and blogging at adventuresincoding.com.

You can also find Kevin at: twitter.com/kfaustino & github.com/kfaustino

We also suspect that Kevin likes Lost:

Meet Kevin, Scott and Pete on May 19th, 6:30pm at TWG HQ: http://guestli.st/55083

Other upcoming Dev events you might be interested in:

May 20th: Ruby Job Fair at Unspace, featuring Rubyists, Employers, and Spiked Tea – http://rubyjobfair.ca

June 2nd: Technologic at UnSpace, featuring Giles Bowkett – http://technologicto.com

TWG is a web development shop for designers, coders, thinkers and friends. Each day we pour all of our creative energy into what we love, and that makes getting out of bed in the morning the easiest decision to make all day.

For some, working at TWG will be a career, for others, it will be a stepping stone on the way to other even greater things. And we’re fine with that, because we know that everyone’s path is a little bit different. In fact TWG’s Big Hairy Audacious Goal is to become the best web application shop in the world to Learn, Work and Innovate. If you’re still intrigued, please read on..

In the winter, we take a week off and head somewhere sunny to regroup, re-energize and dream up the next big idea we want to tackle.

In the summer, we take a week to head somewhere north with a nice lake, to sit around campfires, play music, and assess our progress and plan for the months ahead.

And in between, we do all sorts of good stuff in our studio, building web and mobile apps for our clients, as well as designing and developing our own products to bring online. We’re primarily a Ruby on Rails shop that has recently started to work with html5, iOS and other mobile technologies. If you’re a talented web developer, and think you have plenty to learn and plenty to share, please read on..

So what do you bench?

There are some things you should know something about. For each line that you satisfy, count 2 points:

You have very good HTML and css skills
You have a solid grasp of javascript, jQuery, ajax, json
You have experience coding in Ruby on Rails,
You know what OOP is and what to do with it
You have written tests in either UnitTest, RSpec, or some other test driven framework
You have experience using mySQL or PostgreSQL
You use code versioning systems like git, svn, cvs
You have worked in php, or asp,

Context points. For each line that you satisfy, count 1 point:
You speak another language or have a *fünny* last name,
You ride a bike a lot,
You can play a musical instrument,
You play a team sport,
You paint, draw, sculpt, build,
You have a blog,
You use twitter regularly.
You truly enjoy learning and teaching

So what do you bench?
If you score OVER 14, then send us your score breakdown and get in touch today!

How To Get In Touch:
To avoid people who don’t like to read or have fun, or robots that like to spam the world, we want you to email us at info@twg.ca and place the the immortal words of Lionel Ritchie in the subject line: Hello, is it me you’re looking for?

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

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!

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.