Rails 4.0 has yet to be released, but since it might be here by Christmas, it’s time to start getting ready.

Some Rails 4.0 features can be used today, and I describe how in the whirlwind tour I recently put together for the Atlanta Ruby Users Group.

Highlights of Rails 4.0

• Rails.queue

• strong_parameters

• Turbolinks

• Russian Doll Caching (cache_digests)

• ActionController::Live (streaming)

• PATCH verb

• Routing concerns

• Extraction of activeresource

• ActiveRecord::Relation changes and improvements

• Removal of plugin support (not gems; only those that are installed in vendor/plugins)

• Removal of Rails 2 finder syntax

• Deprecation of most dynamic finders

• Deprecation of eager-evaluated scopes

I recommend watching the talk, and using the slide deck as a reference.

Wanting to learn Ruby on Rails? Come to the next Beginning Ruby on Rails Bootcamp, Jan. 26-Feb. 1 at the Atlanta Ranch.

The post Rails 4.0 Whirlwind Tour appeared first on Big Nerd Ranch.

Staying on top of the new technologies and features in web development can be difficult. The volume of information being generated is vast, and I have found myself becoming discouraged when I can’t seem to keep up.

The primary ways I stay on top of the community are Twitter, selected newsletters (e.g., Ruby Weekly), and blogs.

Blogs are great, but they pile up quickly. However, I’ve found a compromise that works for me: my Blog A-List.

In the past, I would subscribe to any blog that seemed to produce interesting content. In my feed reader, I tagged them all as “technical.”

However, after a few days of being busy with client work or a vacation, the “technical” tag would balloon to hundreds of posts. I’d regularly have to declare RSS bankrupcy and mark everything as read.

This bothered me because I felt like while I could have skipped a lot of content I wouldn’t have read anyway, I might have missed out on some things that would have benefited me greatly.

Enter the “a-list” tag.

The post Blog A-List appeared first on Big Nerd Ranch.

There is a new drama in the software development community, and it’s about whether you should learn to code or not.

I think the best ideas are somewhere in the middle of all the extreme statements and blog post titles that get upvoted on Hacker News.

I think you should learn to “code,” but not because it might make you a “coder”.

More after the break.

Learning to create software has been empowering in my life, and is why I’m currently employed at Highgroove. Almost every day, I deliver some amount of code as a part of keeping my customers happy.

That said, as Jeff points out, I’m not delivering code just for the sake of delivering code: I’m solving a problem.

Solving problems is what makes customers happy and business commence. Solving problems is more important than the fact that I usually use software to do it. I agree with Jeff that there are cases where software is not the best way to solve a problem.

That said, learning to build software taught me how to break down problems into smaller parts, think about the solutions in terms of algorithms with discrete steps, and often–though not always–to convert those algorithms into code that a computer understands and can run through more efficently than any human brain.

Software forces me to know exactly how to solve a problem, because a computer will only do exactly what I tell it to do.

Do I always use software to solve problems? Definitely not. But do I often use the same problem solving techniques that learning to code taught me in order to solve other problems in my life and work situations? Definitely yes.

Can folks be taught to solve problems without using computer code? Definitely yes. But is learning how to “teach” a computer how to solve problems via code one of the best ways? I think yes as well.

Even if someone who learned how to “code” never ends up as a “coder” professionally, they will be much better for having learned to think algorithmically and in the abstract. However, I bet that knowing how to write a quick script here and there will make them much more valuable in whatever profession they choose.

The post Don't not learn how to code appeared first on Big Nerd Ranch.

Sunspot, a Ruby interface for Solr usually backed by ActiveRecord objects, recently introduced native geospatial searching capability in the master branch (currently a 2.0.0 prerelease).

While the functionality has not been released as a stable version yet, I felt that a blog post introducing the features is appropriate with the hope that folks will try it out and give feedback!

Read on for a short example.

Imagine a Rails application has an Office model that, among other things, describes the location of a company’s office. Through some other means (maybe geocoding), the application determines and stores the latitude and longitude of each office as #latitude and #longitude, respectively.

Setting up the Rails application to use Sunspot and Solr is easy, as described in the README, so this post won’t explictly cover it. To get these new features, though, make sure to use a 2.0.0 prerelease (e.g., gem 'sunspot_rails', '~>2.0.0.pre'). After setup, the Office model can be made searchable with:

When new offices are created and saved, they are also indexed in Solr. The #latitude and #longitude attributes are combined into a latlon typed field. latlon fields are specially indexed in Solr to respond efficiently to geospatial queries.

Now, it’s easy to search for offices within a specified area:

It’s also easy to sort results by closeness to a point:

There are a few more details in the README. To reiterate, these features are only in a prerelease version at this point (~>2.0.0.pre) and require Solr >= 3.1.

If you have any feedback, please file an issue.

The post Edge Sunspot: Native Geospatial Searches appeared first on Big Nerd Ranch.

A recent project we worked on at Highgroove involved scheduling events on a calendar. These events had a lifecycle of “statuses,” such as “pending approval” and “approved.”

All users were able to set the “status” to values such as “pending approval,” but only certain privileged users could move them to states such as “approved.”

We were already using CanCan for authorization, but there was no built-in facility for authorizing field-level changes. There were workarounds in certain cases, such as using custom actions, but none of these fit with our specific use case.

Read on for how we modeled the problem and used a Plain Old Ruby Object (PORO) to keep things clean.

We wanted to route edits to an event, including status changes, through the EventsController#update action because users could edit both the status and other attributes from the same #edit view.

We really wanted to avoid code that looked like below:

It might make sense for the controller to enforce the authorization, but it did not make sense to us for the code to perform the authorization to appear in-line within the controller.

At some point we realized that we could create a Plain Old Ruby Object (PORO) to model the “event status change” and then use the facilities that CanCan already provided to authorize the change.

First, we created an EventStatusChange class in lib/event_status_change.rb; note that this class has no Rails dependencies.

(Astute readers may have noticed that EventStatusChange could be implemented as a one-liner using Struct)

Next, we added code to the Ability class where CanCan authorization code normally lives:

Finally, we did have to keep some code in the controller, but it looks much cleaner:

We are not completely sure this is the best way to approach the problem, but it seemed pretty reasonable to us at the time. While not shown here, many of the pieces can be tested in isolation with external objects as stubs; we also found that ability to be a big win.

Have you ever tried to authorize changes to specific fields in Rails? If so, how did you approach it?

The post Rails and CanCan: Authorization for Specific Fields appeared first on Big Nerd Ranch.

At Highgroove, we love giving each other compliments. In fact, since everyone at Highgroove kicks ass in some way, compliments are constantly flying around (actually, I think that in and of itself was a compliment).

Well-deserved compliments foster teamwork, increase morale, and make us better as a team than we could be on our own.

One specific way we compliment one another is by giving the Highgroove Award. The award can be given by anyone to anyone; the recipient is recognized on the website and with a physical trophy (it’s a bit over the top on purpose!).

Read on for how we added a technical twist to giving the award.

Highgroove specializes in backend web application development, and while some of the backends we develop actually drive mobile applications on iPhone, iPad, Android, and other mobile devices, we don’t generally develop the frontends of these mobile applications in-house.

Even so, a few of us are curious and wanted to learn more about how to develop all aspects of mobile apps. It helps us understand how to build better backends.

The app allows any Highgroover to give the award via his or her iPhone. A recipient is selected and the reasoning typed in; the backend portion of the app redeploys the website with the new awardee!

Now anyone can give the Highgroove Award … even when we are on-the-go.

The Highgroove Award is a bit silly, but it helps us give each other serious praise in a light-hearted way. How does your workplace encourage compliments?

Aside: For a more detailed explanation of what goes into the backend and frontend of a mobile application, check out Dear business people, an iOS app actually takes a lot of work!.

The post Kumbaya, My Award appeared first on Big Nerd Ranch.

We help one of our clients operate a high traffic API that, among other things, returns data that is associated with an IP address range. It’s similar to querying for information from WHOIS.

The IP address ranges are specified in a MySQL database with ip_start and ip_end columns. The IP addresses are first converted to their representation as 32-bit integers.

For instance, the range 1.1.1.1 to 1.1.3.3 would look like:

ip_start     ip_end     ...

16843009

16843523

…

Read on for more about how we helped optimize the queries that search for an IP within these ranges.

Loading new information into the API required that we test whether a new IP range overlapped with a current range in the database.

It is relatively easy to write a query that tests whether one range intersects another in SQL:

Unfortunately, even with indexes, this query requires a full table scan in MySQL. On a large table, the query took around 0.25 seconds. While insignificant for one-off queries, loading thousands of new ranges made the time really add up.

We scoped out various solutions, but the one that ended up working best was modeling the problem using MySQL Spatial Extensions.

While IP ranges are not a typical use case for spatial extensions, they can be modeled as 1-dimensional lines. And given that spatial indexes are very efficient at doing queries like Intersects(), we found the solution to be really performant.

The following SQL snippet creates a column called ip_range on the table that is then populated with rectangles in 2-dimensions that represent the IP ranges. We only care about 1-dimension, so the height of the rectangles is unimportant:

With that column and the spatial index, queries to test for range intersection can be written as:

This query achieves the same thing as the earlier query, but runs much faster.

Have you modeled a problem with the geospatial features of a database?

The post Using MySQL Spatial Extensions for Range Queries appeared first on Big Nerd Ranch.

I have only been a professional software developer for a few years, but I feel like I have already acquired bad habits.

One of the hardest for me to break is the desire to create software in a cloistered environment where the requirements are stable and the best technical approach always wins over other constraints like schedule and cost.

Thankfully Highgroove’s iterative software development process forces me to flee from these broken methods of building applications.

Read on for more of my thoughts.

I have a formal degree in computer science, and I am glad I have it. However, all the assignments I completed in school had requirements that were set in stone. These requirements would be published, often on physical paper, and given out well in advance of the due date. This works well when attempting to be fair to all students, but customers in the real world rarely have requirements as stable as a classroom assignment.

The first company I worked for out of college claimed to do iterative development, but the process really felt like waterfall with a few small modifications. The solution to customers changing their requirements was to try to nail down those requirements sooner. Code was delivered in big releases every 6-9 months.

These experiences started to shape my instincts: sometimes I feel that uncertain or unclear requirements are a problem that must be solved before development can start in earnest.

That is so foolish. I am learning that developing interesting software often means it is impossible to know the “right answer” up front … and that is OK.

The answer to uncertainty in software is not to view it as a problem, but to embrace it.

How am I learning to do that .. practically?

Bias towards action: if the “right answer” to a problem seems unclear, bias towards implementing some solution (even if you know it’s not the best). Get it out there for the client (or even the client’s customers!) to use as soon as possible. The best solution will come by iterating on the non-ideal solutions you unabashedly tried at first.

Test-driven development: Coming up with solutions quickly is good, but not at the expense of bad code quality. The biggest wins of TDD are not code correctness (though that’s a nice byproduct), but the design feedback it gives. If the tests are hard to write, you are probably writing smelly code.

SOLID design principles: Learning about–and attempting to follow– the principles of the SOLID mnemonic have lead to improvements in the code I write. SOLID code is better able to handle the changes that will inevitably come when doing iterative development. For Rubyists specifically, I highly recommend Gregory Brown’s article and Jim Weirich’s talk.

In short, bad software development habits are easy to pick up, especially in formal education and in companies that have not truly adopted an agile/iterative approach. What bad habits have you broken–or are still breaking–when developing software?

The post Breaking Bad Software Habits appeared first on Big Nerd Ranch.

One of the more complicated Ruby/Rails projects we work with at Highgroove has many points where it interacts directly with the filesystem.

Writing tests for an application whose code requires reading from or writing to the filesystem presents challenges, especially if done naively.

While it’s tempting to simply use the real filesystem during unit tests, this presents a few problems:

• The tests may be brittle, breaking on systems that are not setup just like the initial developer’s local environment.
• Setting up fixtures on the real filesystem may not be plausible; for instance, if the code interacts with system files (such as in the example coming below!).
• Test code must be careful to clean up afterwards, even in error cases. Otherwise, the file system could be left polluted, dirtying the developer’s machine and possibly breaking tests on the next run.
• Tests running in parallel may interact with one another, causing random failures (e.g., on a continuous integration server or with parallel_tests).
• The filesystem is slow; when attempting to make unit tests as fast as possible, the time to write, sync, and/or read from the filesystem may become significant.

So what’s the solution? Fake the filesystem during unit tests.

More after the break.

Consider the following (contrived) piece of code:

Now, what’s the best way to test it? The tests can’t touch /etc/passwd due to permissions, and even if they could, writing to /etc/passwd would be destructive to the system.

How about mocking File.read?

Assuming we’re using RSpec and mocha for mocking:

This works, but tightly couples the test code. What if someone comes along and refactors the production code, making use of File.readlines instead of File.read.split?

The code still works, but the test breaks because File.read is stubbed, not File.readlines. In fact, it’s now reading from the real system’s /etc/passwd. The code still works, but the test broke. Ugh!

A better solution is to stub the entire filesystem at a higher level, giving a blank slate each time a new test runs. Nothing is ever actually written to the filesystem.

Enter the fakefs gem.

It’s trivial to get up and running. If using bundler, I recommend adding it to the :test group:

Next, configure RSpec to include the fakefs helpers to automatically activate and deactivate fakefs whenever a test is tagged with fakefs: true:

And finally, write tests that are tagged with fakefs: true. But this time, test code can manipulate any part of the filesystem, knowing it’s completely emphemeral and isolated:

Voila! While there is a bit more test code, the test is verifying behavior, not the specific implementation. Do you have any other tips for testing code that interacts with the filesystem?

The post Fake It appeared first on Big Nerd Ranch.

Like many software professionals, developers at Highgroove tend to code a lot outside of the work we do for our clients. In fact, Highgroove specifically allots each developer time to work on non-billable projects. Usually this time is used for some combination of sharpening our axes by reading technical material or watching screencasts, and working on open-source software or other internal projects.

Because Highgroove is a results-only work environment, making sure we are meeting or exceeding results is very important. Last night, a few of us hung around at the office and worked on an internal web application to help us track these results, holding us accountable and encouraging us not only achieve them day-to-day, but to do so longer term.

The application development was already well underway before the hack night, but was rough around the edges and already had some bugs logged.

I gave everyone an overview of the app and the tasks that needed to be done (in rough priority order), but allowed each leeway in exactly what to work on.

Working on the same project with a focused team of incredibly smart folks was really exhilarating! Immediately, small groups formed and took on specific chunks of development. We divided and conquered: “Oh, Patrick’s working on that view now, let me go bang out the functionality behind it real quick.”

Inevitably, a technical rabbit hole appeared. In this case, an issue with Google Apps OpenID that was preventing developers from logging into the application on their local machines. We came up with a hack solution that allowed work to continue, and made sure to timebox fixing the actual problem: “OK, try 15 more minutes, and then let’s ‘give up,’ regroup and try something new.”

Finally, it was refreshing to use the same processes we use with clients for our own application: planning iterations, using Pivotal Tracker, writing tests first, constant communication with our office manager, Megan, the “customer”. Eating our own dogfood makes us even better!

In the end, we got a few bugs and features pushed up, a few more in progress, and a really nice frontend design that’s well under way!

Have you hosted a hack night as a company? How did it go?

The post Highgroove Hack Night appeared first on Big Nerd Ranch.