If it's soap, why do I feel so dirty?

I have an son 19 months old. He wears white converse lo-tops, each one smaller than a computer mouse. My other baby is a rails app I've just started working on. It is 8 days old today! This little rails app has reached an important milestone. It is live! Deployed! It's like a toddler taking its first steps.

Me: "The internet is a big place baby!"
It: "Gaaaaaa!"
Me: "I don't quite understand."
It: "Gaaa Gaaaa Ga!"
Me: "One second. I'll take a look at the logs... Oh Yuck! Your diaper is full of XML!"
It: *crying*

Integration. Growing pains. You've been there. My little baby integrates with Adobe Indesign CS4 server. And boy, what a piece of junk it is. If you look closely at the words "Indesign Server" you can see that "Server" has been stuck on with a wad of chewing gum and a roll of tape. Integration is done through a little soap interface that doesn't really understand soap. The ruby gem savon couldn't get a message through. I nearly lost my cool. Just as I was about to get out my blowtorch and a troop of monkey patches I had a brainwave. The API only specifies one command, "runScript". Why do I need a soap library for an API with just one command? I don't! I simply created a template from the sample soap request supplied by their instructional PDF. Then I threw in a bit of string interpolation and presto! Soap without all the horrible boiling chemicals, lye and fat. (BTW, Sorry for the lousy baby metaphor. But not for the XML thing. I really feel the same about poopy diapers as I doo about XML.)

Engine Yard vs Heroku: Getting Started

Today we evaluated Rails cloud hosting offerings from Heroku and Engine Yard. Each company claims you will have your app up and running in minutes. I thought I would take a moment to share our experiences with each vendor.

Here is the Heroku narrative. Signup was simple. Just confirm your email address and you are in. Free rails hosting without a bunch of BS. And it is a good service. You can't beat Heroku for that. Deployment is simple if you run a vanilla application, but you can run into all sorts of problems if you don't. Heroku applications run in a sandbox where your filesystem is readonly (except tmp). We ran into 2 problems. First, we are using bundler. Normally you gitignore your .bundler directory in your application, but because of the heroku readonly filesystem you have to commit your .bundler directory so when heroku runs bundle install there is a environment.rb file already in place. Another gotcha is that we use sass, which compiles to css. You have to check in the compiled css files for the same reason. There is a gem called hassle (hilarious) that has been created to get around this problem. Finally, we got the app up and running on Heroku. I still give heroku high marks becuase of the free service and the possibility of a simple deployment. My Heroku pro tip: If you plan to go Heroku, deploy the moment you create the skeleton rails application and make deployment a nightly step in your CI server. That way when you introduce some dependency that Heroku hates, you know immediately.

Now for the Engine Yard narriative. Signup is again pretty easy with EY, but you have to have a credit card to do anything because creating an app instance costs 11 cents an hour. Move along freeloaders. No free rides at Engine Yard! Deployment is very customizeable, yet simple. Give them the URL to yout git repo and click "deploy". EY pulls your app and does the rest. While using bundler at Heroku was major ass pain, with EY it is a big benefit becuase you don't have to manually specify the gems on your server. Simply install the bundler gem. Then create a file called deploy/before_migrate.rb in your application. In that file you can call "bundle install", and you are all done! The beauty of EY is that you can use a fancy web interface to do nearly everything, or you can drop down to SSH and hack around at the command line. So though it looks harder because there are more levers and knobs, in the end deployment at Engine Yard is easier than Heroku because the environment is alot like your development environment. There are no magic readonly filesystem or special remote rake tasks. If I want to see what's up with the app I can just tail a log file or run script/console. Overall high marks for EY's customizeability, and ease of deployment. My EY pro tip: go look at "chef" the deployment tool that EY uses on github. If your app has any custom tasks that you need to run before it starts up you can specify them there.

What about cost? Heroku offers a free service, which is a totally awesome resource for the Rails community. Hats off to Heroku for that. On the downside, with Heroku everything is an add on. 20$ a month to send emails, 100$ a month for SSL, 200$ a month for a dedicated DB. That adds up! EY's cheapest option runs about 70$ a month. A dedicated DB system costs 170$ a month, but there aren't lots of add on hidden costs. The big kicker is that with Heroku you pay lots of money to run a single application. With EY you pay lots of money and get a server which means you can run as many applications on that one server as you like. I think you get more bang per buck with EY.

I know. Blah blah blah, what is the verdict? Well, sorry to dissappoint, but as usual, it depends. If you want it to be free Heroku is the only game in town. If your application is very, very simple or doesn't have any of these constraints, Heroku is probably the way to go. But, if you are willing to pay for it you get more bang for your buck with EY.

Both companies have great offerings. I'd say use both of them. The great thing about being in the cloud is that you are paying on a hourly or per cpu cycle basis. Just turn the server on when you need it. If you aren't using it, you don't pay.

Rails for Fashionistas

Today somebody asked me if I would use Rails without plugins or gem extensions. Can you believe it? I looked her up and down and gave her the triple snap. Then I asked her If I looked like the kind of programmer that would let my apps go prancing around the inter-tubes naked? Like, even on a bad day I'm going to dress up my application in a few sexy little plugins, not to mention some tastefully chosen gems. At this point she asked me for advice on which plugins and gems to use. Here was my advice:

Wanna wear something classic? Will_paginate is like the little black dress of plugins. It looks good year after year. Want something a bit more risky? Haml and Sass are hot right now, but they'll both probably go the way of the swatch watch. What's out of date? restful_authentication is like soooo rails 1.x. Another thing is that the big fashion houses are always worth watching. 37 Signals? they are like Versace, Gucci and Prada all rolled into one. DHH, OMG, you brought sexy back. Thoughtbot? Yea, they're another one you can count on for high-end ready-to-wear accessories. Like, when I think about factory_girl's Factory.stub method I go out and by my infant son a new fur coat.

So, like, you can tell our conversation was going well, but can you believe it? Some neanderthal wearing a pager interrupted us. He started talking about Struts and some kind of config file generator plugin for eclipse he was working on. Before we could stop him he emailed us the url of his CVS repository. Then he got paged and had to leave. We both looked at each other and laughed until we cried. I mean, please! Don't talk to me about your Java frameworks. I don't shop at Wal-Mart and I sure as hell won't use J-terd. Hey Ricky Martin, 1995 called and they want their animated gifs back!

That's right sweetheart, Rails is all about the bling! Sure, sometimes late at night while github is down and the home shopping network is the only thing on TV I find myself thinking about something Zed Shaw said. Then I pour out some liquor for _why the lucky stiff. I hit rock bottom and imitate Marilyn Monroe making drunk kissy faces to JFK. Camellllotttt! Where have you gone!?! But then @wycats tweets about the Rails 3 beta and I'm like, "Screw it! Rubys are a programmer's best friend!"

Google Custom Search: Cool but Crippled

Wouldn't it be cool if you could jump over Google's fence, steal their magic 'web searchy thingy' and use it for your own insane schemes? Turns out you can. Some time ago Google created a little happy place called Google Custom Search (GCS) where anybody can have fun pointing that magic thingy at whatever they want.

Cool! Anything I want! Lets make a search engine for programmers! We'll only index useful sites about programming. Here is the algorithm:

1. Create a set of keywords that encompass all possible useful programming topics.
   
2. Use the keywords on sites like delicious to get a set of useful urls.
3. Create a GCS with all the urls

Implementation of that algorithm found here.

That is foolproof. NOT! Google limits you to searching only 5000 sites with GCS. Poop! But wait you say, 5000 seems like alot. Let's see: a quick first attempt at the above algorithm gave me 65 keywords. 10 pages of delicious search results for each keyword gave me 16,000-ish urls. Yipe! I tried running some searches with just 2000 urls and it was kind of sucky.

GCS Fail.

What's the workaround? The only thing I can think of is that maybe 5000 urls is enough for a decent search on one specific topic. Instead of creating one general programming search I could just create a million specific ones on demand. That makes a plain old Google searches sound easy by comparison. GCS is a nice idea, but they've crippled it so there is no possible way it can compete with the standard Google search unless you are working against an extremely focused collection of websites.