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.
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.
All of the non-developer employees here at Highgroove recently spent a day with Andrew Fuqua for a hands-on agile training, where he took us on a quick tour of a full iterative project. We planned a project and learned to create measurable steps toward our goals.
Most importantly, I learned that agile isn't just for developers—it's useful for everyone. The agile principles can apply to all of us.
Last weekend, I participated in Rails Girls, an event that introduces women to development in Ruby on Rails. This particular event was held in Washington D.C., a hotbed for the tech industry.
As a Rails Girls DC coach, I cheered on the girls as they worked through building a web application, and lent a hand when a little help was needed. There were several other coaches, and more significantly, several other female coaches. While I anticipated enjoying Rails Girls DC, I didn't expect that I would be so encouraged and excited by working with others at the event.
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.
About a year ago, I convinced our Charles Brian Quinn to take a chance on me. While I had nearly 10 years of experience in developing, deploying and maintaining web applications, I had no Ruby experience, no Rails experience and not one piece of paper certifying me of having any knowledge about computers in general. Despite all these deficiencies, I had done my homework; I knew beyond a shadow of a doubt that Highgroove was the place where I needed to be working.
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?"
Picture it: A programmer in the eleventh hour of his months-long development cycle, desperately trying to complete his feature list. His palms sweaty, he slugs down another cup of coffee, trying not to think about the client meeting toward which he and his team inexorably march.
Software testing is out the window at this point. Sleep is a forgotten concept.
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.
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.
To be an awesome conference attendee, an amazing community member, and get the
most out of any conference, follow our super easy guide to being awesome at a
conference. Or, alternatively, what I did wrong at RailsConf
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.
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
I started watching Gary Bernhardt's Destroy All Software screencasts
recently and after watching a specific episode, I had to have his Ruby
testing setup. After sitting in Vim config for a while, with some
improvements I made, I started feeling like I should somehow contribute my
changes back. After I started adding a few more changes suggested by fellow
Taconaut Steven Harman, I decided it really needed to be a Vim Plugin.
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.
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?
One of my least favorite chores as a developer is dealing with email. I’m not talking about my inbox. That is a post for another day ;). I’m talking about emails sent by web applications. Whether it is a sign up confirmation email, a receipt from a purchase, or reminder for your dog’s birthday. Chances are, if you have a web application, it sends email.
Traditionally, my workflow for testing these emails has not been very elegant or even efficient. It would either involve creating a bunch of users with different emails accounts I own, or telling the back-end to send all emails to my email address. While both of these work to some extent, the former is very time consuming and the later isn’t really testing the system the way it is meant to be used.
Mailcatcher one-ups both of these methods big time. Mailcatcher provides you with a local SMTP server for you to send your emails to in your development environment. Mailcatcher also provides you with a webmail interface to view all the emails your system has sent.
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.)
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.
At rubyhoedown, the inimitable Jim Weirich gave an
awesome presentation on using the debugger in ruby. Before his new found
respect for the ruby debugger, Jim told us that puts statements worked just fine
And this is true. You can get by with puts. But, you can get by much faster
using the debugger. Read on to find out when to use the debugger and how.
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.
Before getting the opportunity to work with the Highgroove team I spent
considerable time checking out their website. It might have been embarrassing if
it didn't have such a fun vibe to it. The picture on the front page of folks
energetically making coffee certainly drew me to the site as much as having a
good friend happily working there already. It definitely did not hurt that
there was a Velociraptor craftily hidden behind the classic Konami code either.
During my interviews I couldn't help but almost sound fanboy-ish in describing
my own coffee-dorkdom and mentioning that I had read the blog and bios often
during the preceding weeks. I did so just to get a feel for the team with and
for whom I hoped to be working. What I didn't realize at the time was the
breadth and depth of the knowledge base the crew has, and it is stunning!
Early in my tenure at Highgroove someone offhandedly said "the community is the
documentation" and proceeded to comment that this why participation in (not just
attendance of) conferences, Ruby User Groups, and hackfests is so critical to
being a successful ruby developer. This proves itself to be more and more true
the more I learn about Ruby.