BenCurtis.com

If you were secretly wishing for yet another Rails conference to happen, wish no more, for acts_as_conference is here! Personally, I’m excited about it, for a few reasons.

First, it’s being put on by the fine Rails for All folks, and they do good stuff. Second, this looks like it’s going to be a smaller conference, and that’s a plus in my book. Third, it’s going to be in southern Florida in the winter. You can’t lose! :)

If you’d like a quick and dirty UPS rate calculator to use in your Ruby/Rails projects, check out this bit of code I did, based on the great shipping gem:

http://pastie.caboo.se/103505

Changes from the shipping gem include replacing REXML with Hpricot and adding a method to get a list of available methods and rates for a particular package. It uses the UPS Online Tools, so you’ll need to get a shipping account with UPS to use it, but you can get one of those for free and fairly painlessly.

I’ve used this code in a few e-commerce projects now, so hopefully it will work pretty well for you, too. Use it as you wish, but you get no warranty. :)

Since I’m building a very focused piece of HR software that hiring managers and recruiters can use to manage sourcing of resumes and other recruiting activities, I’ve been watching the various vendors like LongJump and Coghead, who promise a software silver bullet: delivering software without the expense of developing it. I’m not convinced they are going to deliver on that promise.

In some respects, I’m sure the applications they will help their clients build will be fine—they’ll do one thing (perhaps even doing it well), and cost very little to build, and everybody will be happy. In other ways, though, I think those applications will fall short, simply because the thought, the planning, and the refinement that go into a software application built by designers, developers, and domain experts working together with their respective skill sets just won’t be there.

As I’ve been working on Catch the Best, I’ve been reminded how an idea for an application can start out very small, but the deeper you dig into it, the more complicated it gets. Of course, this is one reason why trying to preserve simplicity in software is so hard. But on the flip side, your application can’t be so simple it isn’t useful. This can be a fine line to walk in order to deliver excellent software, and just handing someone some building blocks and saying “go build it yourself” will have mixed results.

In other words, sometimes the just-add-water brownie mix gets the job done. If you want the best brownies, though, it needs a little more effort than that. :)

Do you want to sell something with your Rails application? Do you want to integrate PayPal Website Payments Pro with your Rails application in 20 minutes or less? If so, then buy my latest guide, Integrating the PayPal API with Ruby on Rails! The five-page step-by-step guide on how to add PayPal to your Rails app includes a fully-functional sample application that has all the code you need to see how to integrate PayPal into your own application.

Once you’re convinced you can’t live without it, go buy the Rails PayPal guide!

Would you like to know how you can drop the request processing time for an action from 2 seconds to 0.2 seconds? With some excellent tools, some patience, and these tips, you too can speed up critical parts of your web application.

I recently had the opportunity to help a client (and all-around good guy) improve the efficiency of the API portion of his web application. His developer had done a great job with the logic and functionality, but they thought it would be a good idea to have me take a long look at the code to see what improvements I could make. Here are five tips you can use to speed up the slow requests in your Rails app.