One of the projects I’ve been cranking on lately is a little mixtape meets micro-blog service.

Rev1 is up now and ready for consumption. It’s called isfuckingaweso.me. Right now, Jeremy and I are officially spreading the awesomeness. With any luck maybe more will realize their lifelong dream of being awesome, too.

I’m not sure what the future holds for this project. The current goal is to keep it absolutely simple. Register and you’ll get a subdomain with your username. Upload mp3 and images and create short but sweet blog posts. Feedback welcomed, so let it flow!

I have a 256slice running on Slicehost. Over the weekend I tried to install the neat little gem, cheat. Why is it the simplest things never go as smoothly as planned? I issued the command ‘sudo gem install cheat’ and sat there waiting while it tried to bulk update my local gem repository. After about five minutes, I noticed it wasn’t updating like it normally does. In that time, my swap usage went through the roof, err a, I mean stack.

It turns out there’s a nasty memory leak in gem release 1.0.1 (I was a few point releases behind). No problem, I thought. I’ll simply update to gem version 1.2 which addresses a lot of the problems I was experiencing. Before doing this, I received an email from Slicehost support telling me I went way over my alloted swap usage. I replied back telling them my situation and promptly received an email from their support crew. And yet another reason why I love my Slice!

I thought I could simply perform a ‘sudo gem update –system’ and have it automatically bump my gem version to latest rev. Nope. It still tries to bulk update, first. So, now what? Another problem I’ve been experiencing with my Ubuntu slices: My local shell times out after a few minutes of inactivity. This is the kind of sheer madness ones grows accustomed to if you aren’t trying to perform long running tasks. Slicehost support was kind enough to point me to a fix for this problem. A few ssh_config tweaks later and everything seems to be all good.

Now, onto to the more pressing matter. It turns out every Gem release also has an incremental update version you can download and install directly without using gem to manage it for you. Outlined here, all you need to do is this:

1. Download the update version to your machine somewhere. (command: ‘wget http://rubyforge.org/frs/download.php/38844/rubygems-update-1.2.0.gem’)
2. From that same directory: ‘sudo gem install rubygems-update-1.2.0.gem’
3. Issue command: ‘sudo update_rubygems’
4. Clean up after yourself by removing the rubygems-update-1.2.0.gem package you just downloaded
5. Better living through Gems is just like it used to be!

Party on Interwebs…

I use Google Apps for Your Domain on a few of my sites. Mainly, to send email through Gmail from my RoR applications. (See my earlier post for help with this.)

Most recently, I discovered a nasty gotcha with using GAFYD a few days back. The basic problem for me started when my application began returning messages like, “The daily quota has been reached,” or something to the effect.

GigaOM has a nice post about the crappiness and general unhappiness his team is starting to feel since switching over to GAFYD. I actually commented on his post which was the inspiration for sharing it here with all my esteemed readers ;)

Well, I don’t share Om’s same sentiments. Partly, because I’m sure the volume of email I send through GAFYD hails in comparison to the great crew over at GigaOM. I do feel that there’s something missing from all the documentation Google provides to sell you on this service, though.

After digging around, I discovered each mail account is limited to 500 emails a days (free accounts) or 2000 a day (premium users). Now, is 500 or even 2000 emails a day fair? I think 500 a day is fair for a free service but I have a problem with a cap of 2000 if I’m a paying customer. This is ridiculous.

I’ve also read Gmail filters potential spam messages by monitoring the number of recipients for each email you send. There seems to be a general acceptance the number of recipients you can send a message to is around 50. So, make sure to avoid adding your entire address book next time compose an email.

In general, this is a good rule of thumb anyway. I can’t fault them for this, just not sharing this anywhere (I can find) in the GMail FAQ’s. One last ‘feature’ are BCC recipients could also raise a flag somewhere in its system. I haven’t confirmed this with them – just reiterating what I happened upon in a google group thread discussing this same topic.

Knowing is half the battle.

Alright, I admit I learned my lesson about serving a rails site in a shared hosting environment. The biggest takeaway is to make sure and freeze your gems and rails itself. This way your site will continue to run when changes are made to the shared hosting environment.

Case-in-point…

Goblr is ugly as sin but it served as my first attempt at coding a rails site. It was the perfect vehicle for me to learn about all the nuts and bolts which were part of rails 1.2.3, unix admin, and mysql. I put zero emphasis on the UI and concentrated more on the back-end development and feature sets. One of these days, I will contract with a designer to sizzle up the GUI. It’s flat out embarrassing, I know. But sacrifices must be made. It would still be on my dev machine if I sought perfection.

The problem started back in December when rails went version 2.0.x. My hosting company OCS Solutions automatically upgraded to the new and improved version. This wasn’t a huge deal, I suppose, except Goblr went down instantly. I ended up freezing rails to the last version I knew it worked with and the problem didn’t go away. This site gets relatively zero traffic – except for hordes of Muslims trying to sneak a peak at burka wearing belly dancers. So, I didn’t mind it was down at the time. But I also didn’t want it to go to the deadpool.

Last night, I was looking at some traffic reports and Goblr hadn’t flat-lined like I thought it did. WOW! I’m not sure where the magic happened but I don’t care. It lives in all it’s hideous glory. Now, I say this half-jokingly of course. If the site had any sort of traction I would’ve fixed it instantly. All of this just happened at the same time I was trying to finish the first version of Squabl so it was the last thing I wanted to deal with at the time.

I’ve since moved on to a different hosting provider (Slicehost). Some of my earlier iterations of the Goblr video feeder were huge memory hawgs. And I mean huge. It wasn’t uncommon for it to use up 250-300MB of memory while it was running. OCS would manually kill these processes if they ran too long. Some of the bigger feeder jobs would take 6-8 hours. Anyway, OCS is a great hosting provider if you’re looking to cut your teeth in a shared hosting environment. I’ve never once had any of the same problems I had with my brief stint on Dreamhost. OUCH! That was painful. Big ups to the OCS team for putting up with my newbie on rails shenanigans!

I posted the first official release of ActsAsBlast last week. I seriously doubt anyone but me is going to use or work on this project :)

After integrating it into my development version of Squabl, I noticed a few more things which could make it more useful. Right now, it’s currently missing the email tracking capabilities for click-thru’s. Version 0.1.1 I say. As time permits I’ll continue to pump it full of steroids (like all good rails plugins) and PGH (plugin growth hormone).

Hope you like it world!

I’m Excited to Announce

ActsAsBlast is a new project I just hosted at googlecode. It’s my first attempt at creating a rails plugin. It’s by no means ready for production. I still have a few more milestones to reach before I give it the stamp of approval.

The main purpose of this plugin is to make it super simple to organize, send, and track email from your site. It’s perfect for a ‘Send to Friend’, ‘Welcome’, or ‘Lost Password’ emails. It provides a pre-built form and sample docs (as soon as I write them) to get you started.

Please email gmelton[AT]gmail[DOT]com if you’d like to contribute to the project and I’ll give you repository access.

Alright, I just successfully configured my domain to use google apps for email (phew.. the means one less thing I need to worry about!).

In a nutshell, the process went like this:

• I created a google apps account for my domain name. Really simple and free!
• Google needed to verify I owned the name. To do this, you can either copy and paste some code into your site or create a custom CNAME record with a code they give you. I elected to use the CNAME record. They say it takes them around 48hrs. to verify (it only took about 10 minutes, though). Once you’ve created the record be sure and click the button which tells them it’s ready to begin authenticating your site.
• After that, it was time to move on to my DNS settings. I ended up with these MX records:
  • name | data | auxillary
  • squabl.com. | ASPMX.L.GOOGLE.COM. | 1
  • squabl.com. | ALT1.ASPMX.L.GOOGLE.COM. | 5
  • squabl.com. | ALT2.ASPMX.L.GOOGLE.COM. | 5
  • squabl.com. | ASPMX2.GOOGLEMAIL.COM. | 10
  • squabl.com. | ASPMX3.GOOGLEMAIL.COM. | 10
  • squabl.com. | ASPMX4.GOOGLEMAIL.COM. | 10
  • squabl.com. | ASPMX5.GOOGLEMAIL.COM. | 10
• Slicehost has a nice tutorial here for help on this.
• Finally, I ended up with one more CNAME record:
  • name | data | auxillary
  • mail | gns.google.com. | 0

• Don’t forget to add “.” at the end of all the data entries or you’ll end up with your domain name concatenated to the end of each MX/CNAME record.

• While those changes were propagating I went back to google apps and enabled webmail. (There was another section where I had to confirm I entered the DNS settings so I could use my own subdomain to access GMail.)

• Lastly, I created a few users.
• Yayyyyyyyy!!!!

All this was fine and dandy. I was able to send and receive email directly from GMail using my domain without a problem. Now, I was completely amazed at this point that everything just worked. Now, the last piece to test was sending email directly from a rails app.

What I quickly discovered is my rails app didn’t send email directly out of the box using google apps. In other words, you’ll need to provide a work-around. The root of the problem is outlined here and has to do with the fact Google requires a special handshake using TLS – which isn’t supported by ActionMailer. The patch is to add a file to your lib directory and require it inside your environment files. Unfortunately, the site where the following code originated from is down:

Create the file lib/smtp_tls.rb…

require "openssl"
require "net/smtp"
Net::SMTP.class_eval do
  private
  def do_start(helodomain, user, secret, authtype)
    raise IOError, 'SMTP session already started' if @started
    check_auth_args user, secret, authtype if user or secret

    sock = timeout(@open_timeout) { TCPSocket.open(@address, @port) }
    @socket = Net::InternetMessageIO.new(sock)
    @socket.read_timeout = 60 #@read_timeout

    check_response(critical { recv_response() })
    do_helo(helodomain)

    raise 'openssl library not installed' unless defined?(OpenSSL)
    starttls
    ssl = OpenSSL::SSL::SSLSocket.new(sock)
    ssl.sync_close = true
    ssl.connect
    @socket = Net::InternetMessageIO.new(ssl)
    @socket.read_timeout = 60 #@read_timeout
    do_helo(helodomain)

    authenticate user, secret, authtype if user
    @started = true
  ensure
    unless @started
      # authentication failed, cancel connection.
      @socket.close if not @started and @socket and not @socket.closed?
      @socket = nil
    end
  end

  def do_helo(helodomain)
     begin
      if @esmtp
        ehlo helodomain
      else
        helo helodomain
      end
    rescue Net::ProtocolError
      if @esmtp
        @esmtp = false
        @error_occured = false
        retry
      end
      raise
    end
  end

  def starttls
    getok('STARTTLS')
  end

  def quit
    begin
      getok('QUIT')
    rescue EOFError
    rescue OpenSSL::SSL::SSLError
    end
  end
end

Add these settings to your environment file. (I needed to make a slight change from the original patch I discovered. The original patch had ActionMailer::Base.server_settings. Not sure if this is specific only to config/environments/production.rb because I added my change directly to config/environment.rb and ended up with this…

# config/environments/production.rb
require 'smtp_tls'
ActionMailer::Base.smtp_settings = {
  :address        => 'smtp.gmail.com',
  :port           => 587,
  :domain         => 'example.com',
  :authentication => :plain,
  :user_name      => 'mailer@example.com',
  :password       => ''
}