Midnight Oil

If you’re seeing that exception, then I may have a solution for you. Following the reasoning of this blog post, it seems that it’s an issue with how Abingo namespaces the models.

Changing the two ABingo models to explicitly set the class name fixed it for me. YMMV

class Abingo::Alternative < ActiveRecord::Base
  include Abingo::ConversionRate

  belongs_to :experiment, :class_name => "::Abingo::Experiment"
  serialize :content
  ...
end

class Abingo::Experiment < ActiveRecord::Base
  include Abingo::Statistics
  include Abingo::ConversionRate

  has_many :alternatives, :dependent => :destroy, :class_name => "::Abingo::Alternative"
  validates_uniqueness_of :test_name
  ...
end

I’ve been playing with PubSubHubbub (PuSH) and Superfeedr for several hours now, and overall I’m mainly just disappointed. I’m not sure who is to blame, but it’s not the plug-and-play experience I had hoped for.

The Goal

I actually have a purpose, not just play. I wanted to sync up the Obsidian Portal blog (Atom feed available) with the Obsidian Portal homepage. Essentially, we’d like to display a teaser from the latest post on the blog, along with a list of some other recent posts that might be interesting.

The Plan

After putting it in the back of my head for a while, the idea of using PuSH to handle syncing the blog entries over to Obsidian Portal jumped to the forefront. The basic idea was simple: instead of building an RSS poller/parser/whatever, just have someone POST notifications of new blog entries directly to the main Obsidian Portal app. That’s exactly what PuSH is for. Excellent!

Looking around, I found that Superfeedr was a PuSH hub that seemed perfect for this kind of thing.

Poll vs Notify

The first thing I did was start playing around with using Superfeedr to poll the blog feed. This immediately became a frustrating experience. The polling speed was 15 minutes, so every little test/debug/experiment I wanted to try had a 15 minute window. Completely unacceptable.

So, I went out and downloaded a WordPress plugin to support PuSH on the blog side. Now the blog should send notifications to Superfeedr so there would be no need for polling.

Um…nope. I’m not sure if it’s the plugin or Superfeedr, but it’s still polling at a rate of about every 15 minutes. It’s sometimes faster, but on the order of 5-10 minutes instead of 15. That makes it tough to do the sort of playing around that is necessary to figure out the quirks of a new tool.

Post body, not params

Now, this is my own damn fault, so blame lies squarely in my lap on this one. I just want to make sure that other Rails guys reading this know not to make the same mistake.

The Atom entry you receive as part of a notification is in the POST body, not a parameter! This took me a long time to figure out (long time due to waiting 15 minutes between tests, due to polling ). Here’s eventually what I did in the action that receives a notification:

atom = request.body.read

Now you’ve got the Atom text and can parse and go.

Summary vs Content

The next wtf? moment came when dealing with summary vs content. In the Atom protocol, it’s possible to have both the full-text content and a summary. This would be perfect for me, since I could leave the full-text content for any Atom subscribers we have, while using the summary field for the excerpt that appears on the Obsidian Portal homepage. WordPress actually puts a summary/excerpt in by default. Excellent!

Bad news adventurers: For some reason, Superfeedr only displays the summary element if there is not already a content element. So, it’s content XOR summary. There may be a valid technical reason for this, but otherwise it makes absolutely no sense to me. Why truncate possibly valuable data? Why not preserve the underlying Atom feed as closely as possible?

An easy solution for me is to remove the content and only include the summary, which WordPress supports out of the box. Still, I really hate this, as I (as a user) much prefer when a feed includes the full text of the article. None of that “come to the site and see all my ads to read the rest!” crap. It irritates me that I’ve been unnecessarily backed into this corner.

No Updates

The worst thing of all is that Superfeedr doesn’t seem to send notifications for updated entries, only sparkly new ones. This is completely unacceptable for my purposes. Let’s examine a common scenario:

Blog post: “Go their too read more…”

First 20 comments: “You used the wrong ‘there’ and ‘to’, dumbass…”

Ok, so I update the blog post and thank the commenters for their kind words. Still, Superfeedr never sends a notification, so the changes aren’t reflected on the Obsidian Portal homepage which gets seen by way more people than the blog.

This decision really has me scratching my head. The Atom protocol (and WordPress feed) have an updated datetime field that can be used to determine when the last update occurred. It seems simple to check that field and send a notification if it’s changed since the last notification. Again, I don’t want to blame Superfeedr here if it’s a PuSH thing.

Going Forward

At this point, having spent probably 5-6 hours playing with this, I’m reluctant to just chuck it. I’m in that “Surely the answer is just around the corner” mindset, but the lack of updates may be a deal-killer. If I have to manually poll for updates or manually edit entries that require update, then PuSH/Superfeedr becomes pretty much useless to me.

Should I switch to the official Google hub? I assumed that a commercial operation like Superfeedr would be preferable to the reference implementation, and I like their web panel more, but the lack of updates plus stripping the summary field are big no-nos in my book. Since I’ve already invested so much time, I guess I owe it to myself to give the Google hub a try before just throwing my laptop out the window.

Am I crazy? Stupid? I thought PuSH was supposed to be easier than this. If I’m not mistaken, my problem/goal is a textbook example of where to use PuSH/Superfeedr, but so far it’s been nothing but a major hassle.

This is just a brain-dump of everything I’ve learned while stumbling my way through setting up sSMTP with Rackspace email. For the record, I created a single email account on Rackspace and set up sSMTP on my server to authenticate with the credentials for this account.

From line override – @mydomain

When I enabled FromLineOverride, my emails stopped sending. I thought it was spam filters gobbling them up, but it turned out that Rackspace was refusing to send. Looking in the mail log (/var/log/mail.log), I saw this over and over:

RCPT TO: (550 5.1.0 : Sender address rejected: User unknown in relay recipient table)

I fought with this for several hours until the Rackspace help chat technician was able to guide me to a solution. Apparently, if you’re sending emails with a From address from your domain then the From address has to match up to either a real Rackspace email account, or it has to match one of your aliases. Forget about sending from no-reply@mydomain.com unless that’s a real box.

From line override – @mydomain – with catch-all set

Creating a catch-all email seems to change this behavior. Once your catch-all is set, you can send from whatever address you want on your domain. I guess it makes sense, as now any address is a valid return address on your domain.

From line override – @otherdomain

Strangely enough, if you use a From address with a different domain, it all works fine. So, you can pretend all day long to send emails from other domains and Rackspace doesn’t care. But, send an email from a pretend address on your own domain and you’re screwed. Weird.

cron jobs and From line

You have very little control over the From line created by your cron jobs. AFAIK, they’ll always use only the username of the user executing the job. If the output is emailed out then sSMTP will append your domain to this username. Rackspace will reject the email if there’s no account or alias with that name. This means you may need to set up an alias for deploy or whatever user you use for executing your app’s cron jobs, assuming you want to receive the emailed output.

ssmtp.conf is case sensitive

Maybe I’m wrong here, but I swear that ssmtp.conf is case sensitive for YES/NO, even though I’ve seen them used interchangeably in different tutorials. In my case, FromLineOverride only made a difference when I used “no” and not “NO”. Every other YES/NO option seemed to ignore the case. Maybe I’m just crazy.

SPF record

Don’t forget to set up your SPF record! Assuming you’re just going to send email through Rackspace, the following record should work:

v=spf1 include:emailsrvr.com -all

Note: That’s a hard-fail, since I’m a hardass

DKIM

Nope, not as far as I know. How hard would it be for providers to add this service? Maybe impossible if it would involve them signing emails with your key or something like that.

Well, that’s it. If I’m wrong, or there’s anything I should add, please let me know in the comments.

One of the most irritating things about CloudFront is the lack of SSL support. It’s incredibly frustrating to install an SSL certificate, get all your routing set up, then watch the browser freak out because one teeny-tiny image comes through without encryption. A major pain in the ass.

Anyways, it’s possible to sidestep the issue by requesting the image directly from S3 instead of CloudFront. You are no longer leveraging the CDN, but in my case I’d rather have the page load slightly slower than have the browser complain about security flaws.

CloudFront Helper

I wrote the following helper to make it all easy:

module CloudfrontHelper
  # Will return a URL to an S3/Cloudfront image. If the current request is HTTPS, then it will return
  # an HTTPS URL (ie. S3) and if it is HTTP then it will return a Cloudfront URL.
  def cf_img_url(s3_image, *params)
    if request.ssl?
      s3_image.s3_url(*params)
    else
      s3_image.public_filename(*params)
    end
  end
end

SSL Config in amazon_s3.yml

The final step is to turn on SSL support for attachment_fu

production:
  bucket_name: my-bucket
  access_key_id: asdf
  secret_access_key: xxxx
  distribution_domain: [my-cloud-distribution]
  use_ssl: true

Example Usage

Now, anywhere you need to display an image that’s hosted on S3/CloudFront, just use the cf_image_url helper and it will automatically route to either the S3/https version or the CloudFront/http one depending on the protocol for the request. Simple!

< %= image_tag(cf_img_url(@user.profile_pic)) %>

There’s been a lot of buzz surrounding Google Wave recently, and I’m proud to admit that I still have really no idea what it is. I’ve decided to ignore it and let the rest of the community digest it and tell me whether it’s the real deal or just a flash in the pan. Why? Because I’m trying to be an entrepreneur, and Wave is not going to make me any money.

I’ll admit, it’s tough not to get caught up in the excitement. Here’s a snippet from an email I received recently regarding a meetup to discuss Wave (original emphasis left intact).

I’m going to make this short and sweet. We have a meeting this Thursday July 16th. The next paragraph explains why, if you are a true web enterpreneur, you shouldn’t miss the event.

If you didn’t cash out during the DotCom boom and haven’t found success with the Web 2.0 surge including the Facebook and iPhone app bonanzas yet are still looking for opportunity then you need to seriously think about Google Wave. To learn how Google Wave could be the “3rd wave” of Internet Innovation behind “DotCom” and “Web 2.0″ come to our AWE meeting this Thursday July 16 as we’ll present Google Wave and have an open discussion on the opportunities that it presents.

Wow. When I read that, my first thought was: “I had better be there. I don’t want to miss the boat yet again.” I never made a Facebook app (except for work), and I likewise didn’t make a million in the App Store. I’m still working on making some Web 2.0 money, but it sure hasn’t resembled anything like a hockey stick. So, getting a foot in the door early on “the next big thing” holds somewhat of an allure for me, as I’m sure it does for any hacker.

However, I’m trying hard to keep myself head-down on DoLeaf and Obsidian Portal and ignore all non-core technologies. I don’t need a new toy, I need new customers. Plain and simple. Jon Crawford of Storenvy says it best: Stop learning new stuff! (13:40 minutes in) I think that’s the difference between a hacker and an entrepreneur. At some point, the entrepreneur has to do the 90% of the app that’s not cool and not fun. Hackers can put down their current project and pick up a new toy whenever they feel like it. It’s a good life, but I doubt it leads to financial success.

So, if you’re a hacker, please play with Wave, make something cool with it, then push it in my face so I can’t ignore it. Meanwhile, if you’re an entrepreneur who already has a project, I suggest you do what I’m doing: Get back to work.

Hosting a Rails app has always been a bit of a pain. Standard shared hosting was always pretty much out of the question, so most people naturally migrated to some sort of VPS. The obvious upside of being able to do whatever you want is a big draw. However, there is a dark side to every VPS: sysadmin work. Updating with patches, installing software, setting file permissions, and all that plumbing takes a lot of time. Then, there’s the big-daddy of them all: managing your own SMTP server. Sure, turning on Postfix or Exim is pretty easy. I just hope you don’t mind it when all your emails disappear into spam boxes.

For Obsidian Portal, we have been happily hosting with Slicehost for a while. Their uptime has been great, and we appreciate their services like automated backup and DNS management. However, we have been handling all our sysadmin tasks ourselves. So, when Ryan recently met one of the representatives from Blue Box Group, and he said that they’re happy to handle all that for us (at no additional charge!), we were quite interested.

Since we’re currently spinning up DoLeaf, we decided it would be a good time to see what we can get with a more hands-on hosting provider. And, after just a few days, we’re very impressed.

Choice of Distro

Blue Box’s basic installation is some flavor of Red Hat. Ryan and I are Ubuntu guys, so this was a problem. A single email to the support staff: “Hey, can you rebuild our server with Ubuntu server edition?” Answer: “Yep, it’s done.” Awesome.

Firewall

Anyone else think iptables is a bit of a pain? I can use Firestarter or Webmin, but when I try to manage it manually, forget it. Luckily it only has to be done once. Or, in the case of BB, never. Just send an email with the ports you want open. They set it up and replied, plus added a few standard ports that we forgot.

Rails Stack

BB supports several different Rails stacks. We’re used to Apache2 + Ruby Enterprise Edition + Passenger + Rails 2.3.2 + MySQL 5. Even though this kind of setup is pretty straightforward, it always seems to take me at least 1-2 hours just to get things set up in the most basic configuration. Now? You guessed it. Send an email and I’m done.

Functioning SMTP – The Great White Whale

We’ve always had problems with emails disappearing en-route. Getting Postfix set up is a 5 minute job, but your emails randomly get flagged as spam, especially by the big boys like Google and Yahoo. There are many different ways to counter this, like SPF and DKIM, but they are a pain to set up, and it’s always tough to know if you got it correct. This was the tipping point for me with BB. They have an SMTP server preconfigured with SPF and DKIM and you can use it for sending emails from your app. They limit you to 750 emails / hour, which is way more than most apps need, especially in the beginning. Considering that we had evaluated similar solutions that wanted to charge $0.01 / email, having this included for free in our hosting plan was mind blowing. Never again will I host anywhere that doesn’t do this.

And the cost?

The most surprising thing is that I haven’t been charged $0.01 for additional support. I’m still testing the waters to see exactly where that line is, but so far, I haven’t hit it. Plus, their prices are quite competitive. Slicehost is a little bit cheaper, but when you factor in the time saved on setup, I’d say we’re already way ahead.

We’ve only just started with Blue Box, and things may go south at some point, but for now we’re ecstatic with what we’ve received. If you want to spend more time coding and less time on irritating sysadmin tasks, then I highly recommend taking a look!

I’ve recently added a patch to attachment_fu that allows for serving out your S3-stored files via Amazon CloudFront. So, if you want an instant CDN, it doesn’t get much easier.

(Note: For Paperclip users, check out this writeup on intridea)

Get the plugin

Get the latest version of attachment_fu from github.

script/plugin install git://github.com/technoweenie/attachment_fu.git

Setup CloudFront

You’ll need to sign up for CloudFront. It’s as simple to join as any of the other AWS’s.

Once you’re signed up, you’ll need to create what are called distributions. These are essentially mappings from S3 buckets to CloudFront domains. You can use the command-line API if you want, but I found it easiest to just use S3Fox.

In S3Fox, find the S3 bucket that you want to serve out, right click, and choose Manage Distributions. You will see a screen like the one below:

Give the distribution a comment, make sure enable is checked, and click on Create Distribution. It will be InProgress for a few minutes, so just keep refreshing. Once it transitions to Deployed, you’re done!

Configuration

We’ve added one new option to the amazon_s3.yml file that comes with attachment_fu, distribution_domain. Copy the Resource Url (something like http://XXXXX.cloudfront.net) from S3Fox and enter it in your amazon_s3.yml file as the distribution_domain. Make sure to only get the domain and strip off the ‘http://’

Next, you’ll need to update all your has_attachment models that you wish to serve out. For each of these, add a cloudfront option like so:

class MyClass
has_attachment(
:content_type => :image,
:storage => :s3,
:cloudfront => true,
:max_size => 1.megabytes,
:processor => "Rmagick"
)
end

You’re Done!

That’s it! Now, everywhere you use myobj.public_filename, it will use the CloudFront domain and serve it through the CDN.

Bonus Points: CNAME

If you think the XXXX.cloudfront.net domain is ugly, you can set a CNAME on the distribution and do some DNS monkey-business to choose your own CNAME. I’ll do this at some point (and update this blog post), but so far it hasn’t been important to me.

Update I finally bit the bullet and went with Mailchimp. It was a great decision and it’s worth every penny. I’ll leave the original post up in case it’s useful to others.

In a nutshell, mailcar makes it (a little) easier to send a mass emails from your Rails app.

Get the plugin!

Newsletters, feature updates, or God forbid, security breach notices all require sending potentially thousands of emails. There are plenty of service providers who will do it for a fee, but if you’re a small-ish site run by stingy admins (like Obsidian Portal), then you don’t want to drop $100 every time you announce a new feature.

Mailcar is my attempt at simplifying this process a little and making it slightly fault tolerant. You can initiate a mass mailing, let it run for a while, stop it, resume it, and generally not worry about double (or infinite) sends or getting irreversibly interrupted.

In it’s current state (0.1) it does not work out of the box. You’ll need to edit the code directly to insert your own ActionMailer model, and add a function for extracting the list of email addresses. There’s probably other stuff too. I still wanted to post it because it’s a good starting point and the code is very simple, so you should have no trouble finding where to make modifications.

If anyone finds this plugin useful, please take a moment to refactor it and make it more reusable. Send me a pull request or a patch and I’ll put your name in the credits. Hopefully we can get it to a works-out-of-the-box state.

One final warning: sending thousands of emails without knowing what you’re doing will almost certainly land you on a spam blacklist. Double and triple check that your SMTP server is set up correctly with RDNS, SPF, HELO, and other acronyms that I don’t know. Don’t ask me about it because I don’t know. I’d just rather roll the dice on getting blacklisted than pay the bulk sender fees.

We’re currently evaluating possible payment gateways for our new project, DoLeaf. Given that it’s a marketplace app, your standard one-size-fits-all payment system just won’t work. We need to be able to transfer money from any buyer to any seller, and hopefully take a cut for ourselves in the process. With that in mind, we’re looking at both Amazon FPS and PayPal Express (via ActiveMerchant).

Here is our list of pros and cons for each solution:

PayPal Express

Pros

• Can assume that most sellers will already have a PayPal account.
• Buyers are used to using PayPal.
• Integrates with ActiveMerchant, and PayPal + AM looks fairly simple.

Cons

• High barrier of entry for sellers:
  1. Seller must sign up for PayPal Premier or Business account.
  2. Seller must create API credentials (PayPal provides a walkthrough)
  3. Seller must provide us with their credentials (cut & paste, with the possibility of typos and such)
• Credentials are quite sensitive and must be treated as such, with encryption in the database at the very least.

Amazon FPS

Pros

• CoBrand UI can be used to install recipient tokens, making setup easy for sellers.
• Tokens are transferred automatically, meaning no possibility of typos or transmission errors when seller is etting up.
• Can run all the transactions for a cart quickly and seamlessly, rather than 1-per-seller.
• Probably could set up a 1-click ordering sort of system.
• Overall fees will probably be lower since there’s only 1 transaction per sale (rather than 1 for buyer-to-seller and 1 for seller-to-us)
• Tokens are not nearly as sensitive as PayPal API credentials.

Cons

• FPS and Remit are both still kind of unstable.
• Locks us out of ActiveMerchant, unless we want to support multiple pathways.
• No convenient pre-built seller interface. We’d probably need to create an account panel for handling refunds and such.

Thoughts

Overall, I’m leaning toward PayPal at this point. ActiveMerchant and the ability to possibly integrate future payment gateways with ease is a big plus in PayPal/ActiveMerchant’s favor. In addition, people are used to using PayPal for these sorts of transactions. So, buyers in the market we’re targeting will almost certainly have a PayPal account, but not necessarily an Amazon payments account. If only there were a way to make it easier for sellers to get set up.

Anyone else go down this path and come to a different conclusion?

You’re here because you want to be fully RESTful with Flex, found as3httpclientlib, and are now having some troubles. It could be because of the wonky Flash TCP security policies, problems with maintaining Rails sessions, or any one of a handful of other problems. Well, let me take away your burden, friend: Give up now and descend back into the darkness that is GET and POST.

Adobe, in their infinite wisdom, saw fit to only cover the basics with their built-in HTTP services. GET, POST, 200, 404, 500. Maybe there’s more, but not much. Stray into such strange territory as 201 (Created) at your own risk. Luckily, an enterprising 3rd party came along and figured out a way to get around this, creating the as3httpclientlib. Cleverly using XML sockets and connecting to port 80 allows for building your own web service controls inside of Flash. Brilliant! Unfortunately, it’s useless (or nearly so) for use in a real Flash app with a Rails backend. Give up!

I wrestled with as3httpclientlib for a few days, hoping that I could pair up Rails’s RESTful view of the HTTP with Flex. The first hurdle (as you know doubt know by now) was dealing with the Flash TCP security policy files. This stymied me for a few hours, as I had trouble serving the file from localhost to localhost. Eventually though, I figured it out. Still, requiring access to port 843 is a big red flag, as it immediately knocks out shared hosting and many other situations. So, unless you have control of every single server your Flex app will ever need to connect to, you’re screwed. One red flag…

Following my limited success with the policy files, I decided to push ahead. Immediately, I ran into problem two: session management. Without going into too much detail (since I don’t really understand it myself), the session information is not preserved across subsequent calls using the as3httpclientlib. URLLoader uses the browser’s connection to make the requests, and the browser handles transferring the session information back and forth. So, except in certain specific cases, using the URLLoader means that your Rails sessions just work. Not so with the as3httpclientlib. I didn’t test in detail, but it looks like a total game ender. I don’t think it’s possible (or at least easy) to read the cookies from Flash, and you’re going to have to manage sending that information yourself anyway. Red flag number two goes up…

Take my advice: Give up now and go back to URLRequest and URLLoader. The RESTafarian in me hates to say that, but you necessarily have to give up a lot of ivory-tower purity when you descend into Flex development.

Note: This is not a knock against the as3httpclientlib. From what I can tell, it’s a great library. I lay the blame for my problems at Adobe’s doorstep.