Ruby ships with an Interactive Ruby Shell (IRB) that every Ruby developer has played around with at some point. It's a great place to experiment with unfamiliar methods and running bits of code, but if you really want to dig into an object or do hardcore debugging, it can leave a lot to be desired.
Pry is a great IRB alternative that has a number of features that make it one of my must-have tools.
The Global Day of Code Retreat is a daylong event where developers from around the world gather in small groups to practice their craft. It's an intense day of coding where we get to pair program with others, learn new skills and focus 100% on doing it right.
Already sold? Sign up here to join us on December 8, or keep reading below to find out more—but read fast, because these events fill up quickly.
Requiring a would-be user to go through a sign-up process can often be too much
to ask. Instead of jumping through your hoops, many people will just hit the
'back' button and continue browsing Reddit without ever discovering how cool
your app is. In fact, I do it all the time.
Instead, why not treat your visitor as a valued customer with all the rights
and privileges of a full-blown user from the get-go? With soft sign-ups,
you can do just that.
Our clients increasingly need features that rely on file uploads. In
the past, we would typically use your average multi-part form with a file
input and post the data to our servers. Once the file was done uploading,
we would then turn around and push it to a cloud storage service.
But if you're using Amazon Simple Storage Service (S3) to store your uploaded files, you can now upload
files directly to Amazon without even touching your servers, speeding up
your app in the process.
Highgroovers take test-driven design (TDD) seriously, but it's easy to become overwhelmed by the number of tools available for
testing applications. However, if you know us even a little, you know that we have a lot of experience using different tools—and that we've developed some opinions about them.
To help others narrow down the options, I asked a couple of developers here how they felt about the two most popular tools for acceptance-level testing: RSpec and Cucumber.
It's 2012. We know it's the World Wide Web. We don't need to be
reminded of that by prepending www. to the URL of every site we visit. In fact, the use of www. as the
de facto subdomain of The Web was an accident. And
what's more, it was deprecated back in August of 2003.
I am over www. and hereby pledege to do my best to stop using it on the
portions of the Internet that I build. To be successful, I need the Ruby on
Rails-powered apps I create to also drop the dubs. The
powerful router in Rails 3 (and newer) makes this trivial. Peep this:
About three years ago, I worked at a product company where the central functionality in our app consisted of five or six domain models with excessive callbacks. I often found myself attacking the knotty nastiness for days at a time, trying to track down stubborn bugs.
Some time later, I stood up in front of the crowd at the Atlanta Ruby User's Group and said, "I hate callbacks! What good are they?"
This past Saturday, I attended the Atlanta Code Retreat at the
Highgroove office. I hadn't been to a code retreat before this one,
and I really didn't know what to expect. What I got a was a
challenging but fun day of pairing with five different developers,
and writing in four different languages.
When I started as Highgroove's first intern, I wasn't entirely sure how I would be introduced into the company. On the first day, I learned that I would be collaborating with each Highgroover for pair programming, which made it very easy to get integrated and meet everyone.
Read on to learn more about how pair programming helps developers start their time at Highgroove right.
For those following along at home, you know that we love to work iteratively,
and as such, work towards our big-picture goals one small step at a time. We
also take software quality seriously, and an important part of software quality,
particularly when it comes to web applictations, is security. We've begun to
develop a new process to address security in our applications. In the process we
also want to contribute back to the community where we can because it will make
the entire web ecosystem that much better. After the break we'll talk about our
high-level process and how we implement it.
When an app requires full-text search developers usually have two major
contenders to choose from: Solr and
ElasticSearch. Each addresses different use
cases, but generally, ElasticSearch performs noticeably
when an app expects frequent reindexing, as is often the case. Gems like
Tire make setting up ElasticSearch a breeze,
but setting up more advanced indexes and interfacing with ActiveRecord can
sometimes be a pain. Read on to see how to make your life easier with
ElasticSearch and Tire.
Often times the state of an object is tracked through boolean attributes, but
this solution doesn't scale well since each new state requires a new column in
the table along with logic to govern how the states change. If you have a
model which you need to track the states of, the
state_machine gem can be a
great solution. It stores the state of the object in a string-type column
(state in the example below), and adding states and transitions is as easy as
adding a couple lines of code to the model.
Last month on the 37signals blog, DHH wrote about testing like the
tsa. In the article
David argues for less strict test driven development and quotes Kent Beck in
I get paid for code that works, not for tests, so my philosophy is to test as
little as possible to reach a given level of confidence (I suspect this level
of confidence is high compared to industry standards, but that could just be
hubris). If I don’t typically make a kind of mistake (like setting the wrong
variables in a constructor), I don’t test for it.
At Highgroove, we feel this approach is not for everyone. Read on for more details on our approach.
Highgroove really likes Pry. It's a great tool for digging into your code and seeing what's going on with tons of great features. However, there are situations where using a standard binding.pry breakpoint will not block your program and allow you to inspect it. I recently ran into this situation when trying to debug an application that used Foreman to manage it's processes. Luckily, the pry-remote project turned out to be a great solution.
The latest version of Ruby comes standard now with Comma Separated Value support built right in via the CSV
library written by one of our very own alumni, James Edward Gray II. You might know CSV as the extremely portable format file used for everything from Excel Documents, to Numbers Spreadsheets, to lists of emails, to even generic data files. The CSV library is quite generic and useful by itself, but sometimes, you really need the expanded capabilities that only an Excel or Numbers document can support. Read on to find out how to generate Excel and Numbers compatible .xlsx files with Ruby.
As the web continues to mature, JSON APIs (and XML if you're into that)
have become increasingly important. But if you've tried to use Rails to
write an API recently, you know there are a handful of competing
methods and gems focused on making this better. I'm all for
interchangable libraries, but, as Yehuda Katz pointed out in his recent
talk at RailsConf, Rails needs a "convention over configuration" approach
to solving the JSON serialization problem once and for all. So I was
pretty excited when I heard about Jose Valim'sActiveModel::Serializer.
At Highgroove we really like testing and are constantly looking for ways to
improve our testing process, how quickly our tests run,
and how exactly we execute our tests. How often during your Test Driven
Development (TDD) cycle do your tests fail "mysteriously"? You've written your
tests, written your code, and most of them pass but one or two stubbornly fail
even though you are fairly certain they should pass given the testing setup
you've provided? At Highgroove we bias towards action so we are likely to
launch a debugger session or a pry session to get
to the bottom of this. Another approach, which won't break your existing TDD
workflow, is to use your test-suite in place of a more traditional debugger.
After the jump we'll talk about how we've been using this strategy to dig into
code quickly and easily.
Database-bound tests are a drag. Inconsistent tests are a pain.
Database-bound, inconsistently failing tests are the worst!
The following commit message is from a real code base:
Run in transactions by default.
When we added controller specs they weren't being run w/any kind of DB
cleaner b/c there was no default strategy and they weren't explicitly included
in a group. Now, we use :transactions be default, setting request specs to
Also, I saw a 2 second speed up from this change!
Let's look at what we changed in this commit to turn our inconsistently
failing database-bound tests into slightly faster, consistent, database-bound
This weekend we Highgroovers (a.k.a. Taconauts) took some time to do one
of the things we really love: create and release Open Source Software. In
fact, we released not one, but three new tools into the world:
grocer, git_tracker, and puppet-osx_defaults.
Refactoring is a something we spend a bit of time on at Highgroove, so much that David recently wrote about refactoring and related tools in Red, Green, Refactor and I'm writing with even more on refactoring and the 'Refactoring Rabbithole'.
"When refactoring, it's easy to see 10 other things that probably should/could be refactored"
Spending time on refactoring is a tough sell to clients: by definition, the 'backend' can be completely re-done without any visible changes in an application. As the complexity and size of a project grows, refactoring can be necessary to keep things as simple as possible, keep the code quality high, and keep the number of bugs low.
Ruby inherits the philosophy of "there's more than one way to do it," or TMTOWTDI, from Perl. Of course, TMTOWTDI is worthless unless at least a handful of those ways can be written clearly not just for the author, but (perhaps more importantly) for future readers and editors. So, how do you make the best use of the many ways Ruby and Rails allow you to do things?
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
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.
Read on to find out how lessons learned from facilitating compares to attending,
how the general "You" actually means "I" in the blog title, and how many times
it takes (me) to learn the four rules of simple design.
It's easy to say "We're agile" and "We use Behavior/Test Driven Development" and
thus "we use the right tools to empower our developers!" but what are those
tools? For me that discussion is entirely about the tool stack you choose, how
that stack empowers you as a developer to do things right the first time.
Luckily thanks to the ruby community as a whole we have a large number of
high-quality choice to choose between.
In Ruby, blocks are kind of a big deal. We use them for everything from basic
iteration to executing callbacks. They are also really handy for writing
Domain Specific Languages,
or DSLs for short. For example, checkout how blather
uses blocks to respond to an XMPP message.
In case you missed it, the awesome Globay Day of
Coderetreat occurred on
December 3rd. The amount of fun I experienced was unexpected and impressive!
I learned some things too. Read on to find out what.
(Also, don't worry if you missed the code retreat, sad kitten has some good news
for you at the end of this post.)
At Highgroove Studios, we're hyperspecialists in Ruby on Rails web application development. Not only do we write amazingly complicated code on time and on budget, but we follow up all our work with tests so we know our code works.
This is not without its problems however, as a test suite can become just as bloated and difficult to update as the code base it tests! This week, I'll talk about some of the ways I've learned to approach writing tests.
Cluster analysis methods have been gaining popularity as a way of Relating pieces of data in large datasets with one another. Examples in social networking are obvious: friends on Facebook cluster into cliques and communities, which cluster into even larger groups. Demographics and other marketing research can also be aided by sorting prospective customers into groups based on preference.
I recently got to work on some really interesting, big data problems at Highgroove. One of our clients needed to record every api call and analyze specific time periods for averages and usage metrics. Hadoop fits this use case pretty well with a distributed file system and map reduce framework built in. But, I'll be honest, I wasn't too happy about having to write map reduce jobs in Java. While looking for alternatives I found Wukong; a gem that adds a Ruby wrapper around the Hadoop Streaming utility. Here's an example of how easy it makes writing map reduce jobs.
You ever worked on a beastly project? And by beastly, I mean large,
enterprisey, many fingers in the pie (3+ active rails developers), non-sexy (not
social, not using NoSQL, not using Rails 3) project?
Here at Highgroove, we do
which ensures everyone is reading some code on a regular basis. However, being a
developer usually means you'll be reading code regularly anyway. In the past, I used to avoid this if I could. However, now I've learned how much I can get from it, and use it to improve myself as a developer.
Reading code isn't easy, and I certainly didn't want to do it when my only goal
was figuring out why a gem wasn't doing what it promised. It was much easier to
just find someone familiar with it and pick their brain. However, there's more
to be gained from reading source code than you may think.
Bug-free code is hard to come by, but we strive to do the best we can. The most important part of this is automated testing, and code coverage metrics are a commonly used indicator of the quality of tests. However, code coverage is a misleading metric: Having “Good” code coverge in your tests isn’t really an indicator of good testing, but having “Bad” code coverage definitely means that your tests are insufficient.
In Ruby (and most other common languages), it’s possible to get “C0” code coverage metrics. All this means is that a particular line of code was executed. It seems like this would be the holy grail of testing, but it’s anything but that. Heres a simple psuedo-ruby example of something that would not be adequately checked even with 100% C0 coverage:
simple_check? or (foo? and bar? or (baz? not bat?))
test "my_great_function should work" do
assert_equal true, my_great_function
The foo/bar/baz/bat logic never gets looked at in the test. While a contrived example, situations like this come up a lot in code and just because one line gets executed, there could be all sorts of bugs.
A more appropriate use of C0 metrics is to identify code that is “definitely” undertested. If you’re tasked with getting some legacy code that is new to you and isn’t very well tested into shape, running C0 metrics will give you the places you should start looking first.
Other types of coverage include:
C1 – branch coverage – each branch of each line of code. Some languages support this, but it’s a little tricky. “Good” tests should have ~50% or higher C1 coverage. A 100% C1 metric would mean that the example given above would be properly tested. There aren’t any C1 tools for Ruby yet.
C2 – path coverage – each path through each method is covered. A very hard metric to collect, and one that requires lots and lots of tests. It’s not recommended to try and improve this coverage metric as it will lead to an un-maintainable mess of test code that is at least an order of magnitude larger than your application code.
To get C0 metrics, we used and loved a little Gem called rails_code_qa with our Ruby 1.8 applications. It runs a handful of tools including rcov which provides C0 code coverage information, but due to changes in Ruby rcov no longer works with Ruby 1.9.
Enter cover_me. This gem gives you the same C0 sort of metrics that rcov does, but it works with Ruby 1.9. Setting it up is very straightforward, and the end result is a simple report (that automatically opens in your browser!) that provides C0 information both in aggregate and for each of your files. cover_me works with all the common Ruby test frameworks, and there isn’t a reason to not include it in all of your projects.
If your C0 coverage is around 100%, your code to test ratio is above 1:1 (We try for 1:1.4, you can get this number for Ruby on Rails projects by running `rake stats`), and you’ve been doing Test Driven Development all along, chances are pretty good that your code might well tested.
You are writing automated tests for all your code, right?
Highgroove does, and if you’d like us to take on a project for you, we’ll deliver uncommonly bug-free code.
Most developers think that every “other” developer’s code is “no good.” In fact, it is exactly this “Not Invented Here” syndrome that makes it dangerous for other developers to evaluate an existing project’s quality without a checklist or template as a guide.
Here are a few of the things in Highgroove’s Code Review tool-belt, that we look for:
Tests – This is a given – Ruby on Rails ships with a great test framework. Your app needs tests. The default suite will do! Many developer teams will even upgrade the testing suite, adding RSpec and Cucumber, Selenium for in-browser testing, rcov for code coverage, and FactoryGirl for fixtures and test data. Without tests, you’re bound to regress (“Jim fixed a bug, but looks like he added a few more…”). Bottom line: Tests = Quality.
Idiomatic Ruby and Rails – Did the developers use standard plugins, or did they re-invent pagination? Did they use a search plugin or did they write their own fancy-pancy algorithm for search? Are they using helpers, or just copy-pasting code all over the place? This can tell a lot about a code-base and how easy to maintain it is and will be long-term.
Code Look and Feel – We are actually looking for indentation, comments, and commented-out code here. This may seem strange, but projects that have lots of sloppy indentation means a developer didn’t have much respect for the code long-term. If they’ve got a lot of code commented out, it appears they “got something working” and then didn’t bother cleaning up. It’s the equivalent of a mechanic who fixes a car, but leaves bolts lying around, loose, dings up other pieces, and doesn’t clean up. Yikes!
Bootstrapping Documentation – How easy is it to get a new Developer up and running? This may seem strange to check for, but just looking to see how well the current Developers expect other Developers to be able to get up to speed is a sure sign of a quality application. It takes a high level of maturity to realize, as a Developer, that you will not always be the only one working on a project!
Even when we come across a project that may not contain many of these quality indicators, it’s not the end of the world. Once we’ve identified the broken windows, we can get to work fixing them.