RubyFlow : The Ruby Community Blog

Home   Submit   Sign Up   Log In   leaders   Twitter   RSS Feed  

justinweiss — 16 posts

A reader had a question about getting started with TDD, so I answered it.
At some point in your Rails career, you’ll run into a controller that’ll make you want to give up programming forever. As great as it would be to just close your eyes and pretend it doesn’t exist, someday you’ll have to fix a bug in one of these controllers. And, being a good software developer, you want to leave the code better than you found it. But how do you refactor it, especially if you don't have good tests to rely on?
If you need something done in Ruby, a gem for it probably exists. Well, a dozen gems for it probably exist. Some of them are elegant, featureful, and well-maintained, and others were written to solve one use case the author ran into that one time. You have lots of gems to choose from, so how do you choose the right one? This choice is important — by the time you regret adding a gem to your project, it’s painful to change back.
Partial caching is a great way to get some major page speed improvements without a lot of work. But if you forget a touch: true on one of your associations, or your template dependencies aren’t working right, your cached partials won’t get updated. Rails' development environment usually runs with caching disabled, so you'll need a simple way of enabling caching temporarily to investigate and reproduce your caching bugs.
You know what you want to do, but your code just isn't cooperating. Maybe it has a few too many levels of indentation, or chains a half dozen methods, or looks asymmetrical. Whatever it is, something just feels off. You could ignore it -- I mean, you have a backlog full of features you still want to write, and it's really not that bad. But that would be a mistake: Your code is trying to tell you something, and you don't want to miss it.
Last week, I talked about three conventions that can help you beat procrastination and get your new Rails project started. But you still have a tough choice to make. Which code do you write first? Authentication? The part that talks to Twilio? And how would you even begin to work on the forum post recommender engine? Yep, at some point you actually have to write the code, and to do that, you need a place to start.
You’ve just typed rails new on your next project. Now what? Where do you start? There are tons of decisions you have to make up front, and it’s easy to feel lost, and procrastinate, and get frustrated, and never finish your app.
“Don’t Repeat Yourself” is one of the most valuable ideas from one of the most valuable books I read during my software development career. If you can refactor away duplicate code, you will produce more general, more stable code. When you start DRY-ing up your code, though, you’ll start to run into some problems: code that doesn’t handle edge cases well, code that’s too generalized and hard to read, or code that’s hard to find. If refactoring toward DRYness doesn’t work all the time, how do you know when you should refactor?
Good developers know they should test their code. Too often, though, the tests get skipped, rushed through, or never started. There are some really common traps I’ve seen people fall into, and they’ll kill your motivation to test every time.
Searching, sorting, and filtering in Rails controllers can be a pain. ElasticSearch and Solr are great, high-powered solutions, but are really big dependencies for a small app. Luckily, Rails includes scopes, which can provide you with a lot of what you need for simple searching, filtering, and sorting. If you take advantage of scope chaining, you can build the features you want without taking on big dependencies or writing a bunch of repetitive search code yourself.
I’ve heard from some people that are worried about breaking apart large Rails views into smaller partials: How much time does rendering a partial really take? Will the performance impact of calling the partials outweigh the benefits in code readability?

Here's a benchmark to get a sense of how much more expensive partial rendering can be, and whether it matters.
While you’re writing your Rails app, you might run into a problem that you could solve more easily with a different data store. For example, you might have a leaderboard that ranks users by the number of points they got for answering questions on your site. With Redis Sorted Sets, a lot of the implementation is done for you. Awesome! But where do you put the code that interacts with Redis?
Writing code feels so much easier than writing tests for it, and does that one-line method really need to be tested, anyway? But soon, your code is only 20% covered by tests, and any change you make to your code feels like trying to replace the middle layer of a house of cards without knocking the whole thing over. This isn’t a skill failure. It’s a process failure. With a few changes in how you write new features, you can protect your code without your tests slowing you down.
You’ve started a new project and it’s time for your code to depend on a third-party service. It could be something like ElasticSearch, Resque, a billing provider, or just an arbitrary HTTP API. You’re a good developer, so you want this code to be well tested. But how do you test code that fires off requests to a service that’s totally out of your control?
Robut is a simple bot that connects to a HipChat server using their new XMPP interface. Using simple plugins, it can listen, perform actions, and respond to what's being said. Robut includes some sample plugins, including a hook to the TWSS gem and an Rdio client for queueing and playing music.
Reactive Resource 0.5 has been released, which brings ActiveRecord-style 'has_many', 'has_one', and 'belongs_to' associations to ActiveResource models, provides better support for singleton resources, and fixes other miscellaneous problems I've run into while wrapping REST APIs.