Author: Josh Symonds

Catching Ajax Errors with Prototype and Rails

Prototype

In an exclusively Ajax application it can be difficult for a user to determine when their connection to the server has dropped. For example, we at Pathfinder use an excellent internal tool to keep track of our time, and the primary screen in it provides a lot of Ajax-y fields. But if, say, I disconnect my laptop, plug in at home, and forget to connect to our VPN, I can waste quite a lot of time and energy putting in information without realizing it isn't being sent to the server at all.

To fix this problem is a little less obvious than it might seem at first glance.

Continue reading »

Uploading Files to Rails Metal

I was fooling around with Rails Metal earlier today to get a better feel for it. One of the most obvious uses for me is disassociating an upload task from your application; a single Rails instance blocks while waiting for an upload to finish, so particularly for very large file uploads, your application can stop responding to users if all instances are taken up by uploaders.

With Metal, you can spawn separate tasks on different process IDs: then when you need to upload, Rails calls to them and that Metal handles the upload (and blocks), while the application instance itself is free to service other requests. This article was super helpful in describing how to use Rackup to start a Metal piece as a separate process. But in all my searching I didn't find anything clearly delineated on the Internet for how to make Metal work with file uploads, so this is how I did it.

Continue reading »

Escaping the Iterative Development Trap

Mandelbrot Set

While designing software it's easy to fall into the trap of iterative development. Iterative development allows us to work quickly, exchanging rigorous requirements-gathering for rapid design and development -- and as good developers, it is our responsibility to make sure that the code we create now works well with future iterations of our program. However, I find that code created as part of this process can frequently be too complicated, too generalized, or both. When creating agile software we must keep in mind the requirements of the future, but design strictly for the requirements of the present. If we are snared by the trap of iterative development, we risk wasting time, money, and people on code that may not be useful in the future -- or, even worse, code that the client doesn't want and can't use.

Continue reading »

Topics: ,

Rails Worst Practices: 13 Coding Nightmares You Should Avoid

I've been extremely frustrated by existing Rails projects that get handed to Pathfinder for fixing. Almost invariably they're filled with some of the worst Rails code I've ever seen. Happily we have amazing Rails developers on staff, so we can make great, usable changes to even the most obfuscated code; but that doesn't mean we have to write happy blog posts about how great that code is. No sir, I'm here to tell you how it sucks.

A lot of people have spent a lot of time writing about Rails best practices. If you need some good examples, you need look no further than Noel's previous blog posts (or, to be completely immodest, my own). This is not a post about best practices. This is about the worst of the worst, the things you should never, ever do, the stuff of coding nightmares. So before we start, make special note: this isn't a blog post to make your code better. This is triage. We're only trying to stop things from getting worse.

Continue reading »

Topics:

Pimp my Rails: Five Plugins & Gems to Make Rails Better

Shamelessly dovetailing off our very own Brian Dillard's blog entry earlier this week, Pimp my jQuery, I wanted to jot down a few of my favorite Ruby on Rails tools that I would find life completely unbearable to be without. While they might seem like simple, small changes, these plugins have saved me huge amounts of time and I think the least their authors deserve are some nice shout-outs.

Continue reading »

Topics:

8 Tips & Tricks When Starting Objective-C iPhone Apps: [self.paradigm shiftFrom:@"ruby" to:@"objective-c"];

All languages have something interesting to teach us about the art of programming -- and as a Ruby developer almost exclusively, I've always been afraid of strongly typed languages like Java and C++, or the great-grand-daddy of them all, C. So when I decided to tackle Cocoa to work on iPhone apps I went in somewhat leery of how I'd have to change, but hopeful that I'd become a better, more versatile programmer. After a few weeks I would say I've achieved my goal, but it's certainly taken a lot of blood, sweat, and tears to get here.

I think a lot of people are in a similar position to me: trying to pick up Objective-C to do iPhone programming, and coming in with only a book or two as their guide. Most of the books out there for learning Cocoa and the iPhone SDK are very good but there are a lot of gotchas and stylistic tricks that really mean the difference between comprehending a statement and staring at it in horror and confusion until Google comes to your rescue. The aim of this blog post is to come to your rescue instead of Google. These are the 8 biggest foul-ups that I wish I had known before I started learning Objective-C. Hopefully you'll learn something here that will prevent you from making an idiotic mistake I already made.

Continue reading »

Topics: ,

Rails Performance, Code Metrics, and Locking Down your Application: Tips & Tricks from Windy City Rails 2008

Windy City Rails was the best Rails conference I've ever been to, which is easy for me to say since it was my first actual Rails conference. But even speaking from a fairly uninformed point of view I found it very full of quality. In case you didn't know, it was created by ChicagoRuby, sponsored by Pathfinder (us) among others, and you can find tons more details if you're interested at http://windycityrails.org/. Anyway, it was this last Saturday the 20th, and after four days of digestion I am prepared to deliver some of the highlights:

Continue reading »

Selling Git on the Business End

Git Logo

Today I gave a presentation on why Git makes sense for an agile consultancy like ours. It was more challenging than I initially imagined; there are many, many blog posts out there discussing why Git is technically superior to Subversion. But when I searched for posts discussing the business merits of Git I came up short. Git is faster, branches better, it has a local copy of the repository, it's small and cheap, but these are points that sell an engineer. What sells the administrators, the business analysts, the project managers?

I came up with a few cool scenarios to illustrate why we, as a business, should adopt Git -- essentially, why it makes not only my life easier, but why it will make the decision makers incredibly happy too. Then my colleague Jason Sendelbach and I gave a short talk on not only the why of the Git, but how we can start using it. Here I'll summarize our presentation. If you want to use Git in your company, but you have problems selling it to the administration, feel free to crib liberally. These points worked great for me.

Continue reading »

Topics:

Getting Started with Facebooker

Developing for the Facebook platform can be a big headache, and on Rails your headaches are unfortunately compounded from the get-go. While the otherwise-inferior PHP users get an API library from the Facebook development team (I'm kidding, I love you PHP guys), on Rails we have to deal with gems that aren't even at version 1.0 yet. While Facebooker is quite good at this point, its documentation covers a rather sparse selection of its impressive feature set, and RFacebook, which is better documented, hasn't been updated in aeons and is way more difficult to use besides. And unfortunately the standard Facebooker tutorial doesn't include the newest features from the recent Facebook profile overhaul or even all the necessary steps to get a new Rails application running on Facebook. So, enter Josh.

In this blog post I'll tell you the best way to integrate Facebooker into a new Rails project so you can start developing social networking applications quickly and easily, and how to hook them in to Facebook's new profile plan. The goal is that by the end of this post you'll have a totally working Facebooker Rails application and you'll understand how to develop in it at least a little bit.

Continue reading »

DRYing up Rails Controllers: Polymorphic and Super Controllers

Controllers are an obvious point to find repeated behavior in an application. Identical methods across many controllers are a very common problem: consider comments, for example, where you might encounter an add_comment and remove_comment in every controller. Or think of all the controllers that render the same actions in the same way. Maybe they implement very basic CRUD functionality but have very complicated AJAXy tricks. You find yourself typing in those tricks over and over again on every controller. Let's fix that! By using a few neat techniques, we can significantly DRY up our controllers and end up with code that's not only very reusable, but very easily changeable to effect significant alterations in our application.
Continue reading »

Pretty Blocks in Rails Views

One of the easiest ways to improve the readability and reusability of a Rails application is to refactor the view layer. I find that most Rails code I look at in models and controllers tends to be very good, but views are a huge mess of single-use partials, repeated behavior, and lots and lots of missed opportunities to implement some really graceful and reusable helpers. I wanted to whomp up a quick blog post discussing some of my favorite techniques for making views prettier.

Continue reading »

Topics: ,

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com