The Highgroove blog. Sit pit-side with us to learn how we work. Sometimes technical, sometimes business-oriented, but always focused on simple solutions.
You are browsing posts about Code. Check out all posts on our blog.
by gregg
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.
→ Read More
by stafford
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.
→ Read More
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.
→ Read MoreThe Liskov Substitution Principle (the "L" in SOLID design principles), is a simple, yet powerful concept that can be used to improve your design. It states:
→ Read More"if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program."
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.
→ Read More
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.
→ Read More
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:
Let's talk about what's going on there...
→ Read More
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?"
Today, I have the answer.
→ Read More
by stafford
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.
→ Read More
by jonathan
Hey, have you heard about the first Highgroove-hosted Code Retreat? We're polishing our silverware and painting the walls in preparation[1] for helping developers to level-up their skills.
Read on to find out more.
→ Read More
by tomer
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.
→ Read More
by jonathan
A long time has passed since we've last spoken about processing background jobs. Much has changed regarding the tools for asynchronously processing long running tasks in Ruby and Rails. Most recently we've favored Resque, especially now that Heroku's cedar stack supports it.
There's one problem with Resque. Enforcing strictly serial job semantics is impossible in Resque without custom development or limiting the number of workers.
So, NEVER use resque for serial jobs, OR read on to find how we resolved this dilemma with resque-lonely_job gem, a new resque plugin.
→ Read More
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.
→ Read More
by brian
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 better 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.
→ Read More
by gregg
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.
by aubrey
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 saying:
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.
→ Read More
by andy
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.
→ Read More
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.
by jonathan
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.
→ Read More
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's ActiveModel::Serializer.
→ Read More
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.
→ Read More
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.
→ Read More
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 use :truncation
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 tests.
→ Read More
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.
→ Read More
by chris
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.
→ Read More
by brian
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?
→ Read More
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.
→ Read More
by jonathan
Waaaayyy back in December, I had the pleasure of attending a code retreat. In that post, I discussed what I learned.
This month, I had the pleasure of facilitating a code retreat a few weeks ago. Thanks to Highgroove, TapJoy, FourAthens, and my co-coordinator Travis Douce, the Athens Code Retreat was a resounding success.
Also, a special shout out to our Code Retreat homies in South Africa led by Corey Haines, who handed off the baton to us late in their day but early in ours.
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.
→ Read More
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.
→ Read More
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.
→ Read More
by vanstee
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.
→ Read More
I've often felt like Ruby Regexp captures are a bit clumsy.
Let's say we need to break apart phone numbers:
After executing this match, we might do something like this with the parsed number:
What's up with the dollar signs and the sequential numbers?
I feel like I'm writing assembly code and referring to registers or memory offsets or something.
If I'm a new Ruby programmer reading this code, I might have no idea what is going on here.
We can do better → Read More
by jonathan
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.)
→ Read More
by andy
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:
So what's the solution? Fake the filesystem during unit tests.
More after the break.
→ Read More
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.
→ Read More
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.
→ Read More
by jonathan
RubyConf, ahhh Rubyconf.
How was it this year you ask? To answer that question we must first address the question:
How was my first ruby conf?
→ Read More
by vanstee
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.
→ Read More
by jonathan
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?
→ Read More
by skalnik
Here at Highgroove, we do code reviews, 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.
→ Read More
by jonathan
Edit: Updated gist to fix SQL injection. Thanks to all the code reviewers, uh I mean commenters, for pointing it out!
Wed Jun 29 13:55:27 EDT 2011
by andy
At Highgroove, we are pragmatists. While we value writing clean, maintainable, and extensible code, we also value shipping features for our clients in tight iterations.
Sometimes it feels like achieving both of these goals is simply not possible … and yet focusing on either one at the expense of the other is not satisfactory either.
To achieve a balance, we aim to periodically refactor our code: improve or restructure it without affecting its external function.
More after the break.
by chris
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:
def simple_check? true end def my_great_function simple_check? or (foo? and bar? or (baz? not bat?)) end test "my_great_function should work" do assert_equal true, my_great_function end
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:
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:
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.
Photo Credits:
