Category Archives: edge_rails

Asset Pipeline has been extracted as sprockets-rails

The asset pipeline which was introduced in Rails 3.1, has been extracted to a separate gem called sprockets-rails. Performance for assets compiling has been improved. There is a open pull request to merge turbo-sprockets-rails3 to sprockets-rails, whic…

Action and Page caching has been extracted as gem

With the commit c82cf81f00f
Action and Page caching has been extracted from Action Dispatch as `actionpack-action_caching` and `actionpack-page_caching` gems

Edge rails: Now create HABTM join tables easily using migration helper

Earlier whenever we wanted to create a HABTM join table, we do this like: Now, in edge rails after this commit we can use a migration helper for the same:

Mob Refactoring

January 30, 2014

When teams try to take control of their technical debt and improve the maintainability of their codebase over time, one problem that can crop up is a lack of refactoring experience. Teams are often composed of developers with a mix of experience levels (both overall and within the application domain) and stylistic preferences, making it difficult for well-intentioned contributors to effect positive change.

There are a variety of techniques to help in these cases, but one I’ve had success with is “Mob Refactoring”. It’s a variant of Mob Programming, which is like pair programming with more than two people (though still with one computer). This sounds crazy at first, and I certainly don’t recommend working like this all the time, but it can be very effective for leveling up the refactoring abilities of the team and establishing shared conventions for style and structure of code.

Here’s how it works:

Assemble the team for an hour around a computer and a projector. It’s a great opportunity to order food and eat lunch together, of course.
Bring an area of the codebase that is in need of refactoring. Have one person drive the computer, while the rest of the team navigates.
Attempt to refactor the code as much as possible within the hour.
Don’t expect to produce production-ready code during these sessions. When you’re done, throw out the changes. Do not try to finish the refactoring after the session – it’s an easy way to get lost in the weeds.

The idea is that the value of the exercise is in the conversations that will take place, not the resulting commits. Mob Refactoring sessions provide the opportunity for less experienced members of the team to ask questions like, “Why do we do this like that?”, or for more senior programmers to describe different implementation approaches that have been tried, and how they’ve worked out in the past. The discussions will help close the experience gap and often lead to a new consensus about the preferred way of doing things.

Do this a few times, and rotate the area of focus and the lead each week. Start with a controller, then work on a model, or perhaps a troublesome view. Give each member of the team a chance to select the code to be refactored and drive the session. Even the least experienced member of your team can pick a good project – and they’ll probably learn more while by working on a problem that is on the top of their mind.

If you have a team that wants to get better at refactoring, but experience and differing style patterns are a challenge, give Mob Refactoring a try. It requires little preparation, and only an hour of investment (although I would recommend trying it three times before judging the effect). If you give it a go, let me know how it went for you in the comments.

[…]

The Ruby Rails Aggregator