Highgroove Studios - Blog - Pit-side with Highgroove

Don't not learn how to code

2012-05-16T00:00:00-04:00

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.

How to recruit developers away from Highgroove

2012-05-10T00:00:00-04:00

You've read our blog, had Highgroove do work for you, watched our Tech Talks, attended the Atlanta Ruby User Group which we host, and all around think we're great.

Now, you've decided that what you really want to do is hire one of our developers full time to work for you. Maybe you're a recruiter looking to fill an 'awesome position at a big company in the Atlanta area', or maybe your startup is ready to take the next step and hire an in-house developer.

We get a lot of e-mails and calls from recruiters, and to be honest, most of them are absolutely terrible. Read on for some tips on how to recruit Highgroovers to come work for you instead. Seriously. Please. We're not telling you to not try and recruit our developers, but please stop wasting your time and ours.

First up, it's Highgroove's job to make our developers happy and to be the place that all developers want to work. We have a great culture, great benefits, and a bias towards making awesome anything which is not yet awesome.

Everyone's motivations for choosing to work at Highgroove are different and our turnover rate is extremely low, but there is always a chance your 'opportunity' is the one that someone has been waiting for. When people do choose to leave and go somewhere awesome, we all give them high-fives on the way out. We've had people leave for Twitter, GitHub, startup incubators, and even a law firm.

Before you get in touch with anyone, do your homework. Everyone at Highgroove has different skill sets, so read their profiles on our About page, click through to their Twitter accounts, GitHub accounts, blogs, etc, and find out what their technical skills are and what they are interested in. One developer might be a good fit for LAMP development in Antarctica, while someone else would be much better for Erlang in Brooklyn. Your chances of hiring one of us become greater than 0% if you have a perfect fit for someone. Hint: If you contact several people at once here, you're probably doing it wrong.

When you've narrowed it down to the perfect fit, don't pick up the phone. Developers are trying to get work done, don't like being interrupted, and universally hate these kind of phone calls. Send an e-mail, and make it good. If you want a response, your e-mail must be personal (not a form letter) and include the following:

Company: If we don't know who we're working for, we're not interested.
Location: Do we have to move or does remote work? Where?
Salary: "Based on experience" doesn't cut it. You're e-mailing us. Give us a range.
Office: Photos/Video online of the office somewhere is ideal. A cube farm with the lights off is only appealing to a small set of people.
Answer: What would I have done? For our list, head over to our Jobs page and read the "If you were with us already, you would have" section.
Answer: What would I be doing? 'Rails' isn't enough. What does the job actually entail?
Answer: Why would I be a good cultural fit? Coffee? Beer? Bicycles? Boats?

This gives someone enough information to find out if they're a good fit. Hopefully, you'll know before you send the e-mail (or get all the way through this list of requirements) if someone will be a good fit and your response rate will end up being pretty high.

Don't ask a developer if they 'have any friends that might fit this position'. That screams "I didn't do my homework and am just grabbing anyone I can find."

Do you really really want someone to work for you? Have someone important contact them instead of a recruiter or someone in HR. All of these are good choices: the person that wrote a programming language that is on your team, someone who is a popular speaker at conferences, someone that wrote "the book" on something.

And that's it! It doesn't seem too hard, but of the 36 e-mails I've personally gotten from recruiters this year, only one of them has met most of the criteria above. The phone calls (which, by the way, all get automatically sent to the voicemail box on Google Voice) all get ignored.

Most of this applies to other tech companies, but if they're not as awesome a place to work as Highgroove, you might have an easier time recruiting. So good luck! We look forward to your e-mails.

Debugging Remote Processes With Pry-Remote

2012-05-09T00:00:00-04:00

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.

When a process being run by Foreman hits a regular Pry breakpoint the process will halt, but you will never be able to interact with the Pry session. This effectively freezes the app, forcing you to kill the Foreman process.

To work around this using pry-remote you must first set it up in your project. First install the gem:

# Install the gem manually gem install pry-remote # or in a Bundler managed application # add the following to your test and # development groups gem 'pry-remote' # Then run bundler bundle install

Once the gem is installed, you can now add a breakpoint in your application with binding.remote_pry. When the breakpoint is hit, pry-remote will block your app and open up a DRb endpoint that a client can connect to. Running pry-remote in a shell will then connect to the session and you'll be able to interact with Pry as you normally would. Simply call exit in the Pry session to unblock the application.

Have you picked up any other tips or tricks while using Pry? Leave a comment below!

So you thought ROWE would be easy?

2012-05-08T00:00:00-04:00

I'm just a week into my first real job and I feel like the luckiest person in the world. Many people fresh out of graduate school still have to "pay their dues" at a company that values being in your cube by 8:00 am even if you were up until 1 last night getting another report finished. While graduate school is essentially a ROWE, there are still expectations to be in a chair from 9:00 - 5:30 (at least in my lab there were). While having the freedom to work when you want and how you want is amazing, it doesn't come without growing pains. After a couple of years of getting judged based on time in the lab, it's hard to remember that it's what I get done that matters and not when I do it. Read through to see how I managed to commit what would be a serious faux pas in any workplace other than a ROWE: I took a day off in my first week.

Only in a results environment is it ok for a new employee to go to a wedding in their first week. While I didn't actually take the day off since I was still responsible for my tasks, it's refreshing to be able to work on a plane, hotel, airport or anywhere else I can get work done. It tells me that my employer hired me because they trust me to do my job. In a traditional workplace, I may have not been able to get a day off for 6 weeks, but in a ROWE where time doesn't matter it was business as usual.

But enough about ROWE. This first week has been occupied mostly with pairings, which is a perfect method for introducing the new-guy to all of the projects and techniques used by others in the office. I've learned about the tools that other developers use (some software we recommend) and was even able to get my hands a little dirty adding a feature to one of our non-profit projects (Bike Spot). In between pairings I've been hacking on our chatbot "Groovebot" (really, it's Hubot) so it can give us a radar image to help us better time our bike commutes home and it can even tell you a little about that beer you just heard about.

Everyone here has been amazingly helpful to me and have made my first job as a software developer a dream. This is a fantastic group of smart people and I look forward to all of the projects I get to work on with them in the future.

Image from Flickr user windy_

Why we Turn Down over 89 Percent of Developers Who Apply

2012-05-07T00:00:00-04:00

It's true. We're hiring. Like a lot of technology companies. But, did you know that we are turning down many qualified applicants? Since we started tracking, only 11% of applicants who go through our hiring process become "Hired Full Time" employees of Highgroove. That means about 1 in 10 who apply receive an offer letter. Why is it we can -- or rather why we have to be so picky in who we hire?

Hiring is hard. Ask any growing company or entrepreneur (or a team of entrepreneuring developers) what's their hardest challenge and they'll tell you -- it's hiring the right people.

As President of Highgroove, my entire function is to put the right people on the bus, and that means both developers and clients. Many of our clients (and soon-to-be-clients) recognize that our secret sauce (the parts that we haven't published on our not-so-secret-sauce site for software companies) is what makes us awesome. It's what makes us a tremendous value for smart CTOs looking to gain an edge in building ruby and rails backed web applications. So with all this demand for development, why are we turning folk down?

It really comes down to culture. Highgroove has a unique company culture that cannot be bent or compromised by bringing unqualified people on the team. It's one of our competitive advantages, and to quote David Cummings:

Corporate culture is the only sustainable competitive advantage that is completely within the control of the entrepreneur. Develop a strong corporate culture first and foremost.

-- The Top 3 Things Every Entrepreneur Needs to Know.

This culture is impossible to summarize in a sentence or blurb, but is quantified in numerous ways from our "Bias Towards Action" mantra, to our values we reiterate consistently in our Highgroove Award, to even how we structure the company.

"Having a great company culture" isn't even new in the management world. It's not unique to technology companies, either. This is why we promote competitive events like a Latte Art Competition, hiring a personal trainer on-staff, and sponsoring a bicycle race/club team.

To make sure we're a good fit, we use a variety of tools including a hiring process centered around Topgrading (Topgrading: The Secret to Hiring A Players), and hyper-focused on the culture fit equation. No, we don't have any silly programming challenges that don't mean anything to anyone except the interviewee trying to prove how smart they are.

So, it's not enough for a potential candidate to be a programming "expert" -- in fact, it's not even mandatory that a candidate be a Ruby/Rails guru. We're not hiring for that. We're hiring professionals who fit our culture. If a candidate aligns with our company culture (and they'll find out quickly in our extensive, in-depth hiring process), interviews with us, and makes it on-board, they'll be doing Ruby and Rails their first day. And in our bootcamp, once on-board, they'll learn more of the Right Way to do development, and be doing client work and internal work soon there after.

Are you curious if you would be a good fit at Highgroove? Send us your github username, and we'll point you to the next step.

Image Credit: balloo from f0nq.com http://www.f0nq.com/8/rock-and-roll-surf-ninja

Use Ruby to Generate Formatted Excel Documents

2012-05-01T00:00:00-04:00

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.

Another Highgroove alumnus, Emily Price, recently introduced me to axlsx, a Ruby gem which generates "Office Open XML Spreadsheet documents." axlsx provides support for charts, images (with links), automated and fixed column widths, customized styles, functions, merged cells, and more.

It is super simple to get started. Let's check out a few of the features.

First, if you plan to use the generated file with Numbers, make sure to set "use_shared_strings" to true.

Next, after creating a workbook via a block, we'll set up some styles to use later.

p.workbook do |wb| # define your regular styles styles = wb.styles title = styles.add_style :sz => 15, :b => true, :u => true default = styles.add_style :border => Axlsx::STYLE_THIN_BORDER pascal_colors = { :bg_color => '567DCC', :fg_color => 'FFFF00' } pascal = styles.add_style pascal_colors.merge({ :border => Axlsx::STYLE_THIN_BORDER, :b => true }) header = styles.add_style :bg_color => '00', :fg_color => 'FF', :b => true money = styles.add_style :format_code => '#,###,##0', :border => Axlsx::STYLE_THIN_BORDER money_pascal = styles.add_style pascal_colors.merge({ :format_code => '#,###,##0', :border => Axlsx::STYLE_THIN_BORDER }) percent = styles.add_style :num_fmt => Axlsx::NUM_FMT_PERCENT, :border => Axlsx::STYLE_THIN_BORDER percent_pascal = styles.add_style pascal_colors.merge({ :num_fmt => Axlsx::NUM_FMT_PERCENT, :border => Axlsx::STYLE_THIN_BORDER })

Next, we'll create a worksheet for and add a few rows. Note that the worksheet name is limited to 31 characters.

wb.add_worksheet(:name => 'Data Bar Conditional Formatting') do |ws| ws.add_row ['A$$le Q1 Revenue Historical Analysis (USD)'], :style => title ws.add_row ws.add_row ['Quarter', 'Profit', '% of Total'], :style => header # Passing one style applies the style to all columns ws.add_row ['Q1-2010', '15680000000', '=B4/SUM(B4:B7)'], :style => pascal

Finally, we add a few rows using custom styles for each column, merge some of the title cells, and then serialize the file out to disk!

# Otherwise you can specify a style for each column. ws.add_row ['Q1-2011', '26740000000', '=B5/SUM(B4:B7)'], :style => [pascal, money_pascal, percent_pascal] ws.add_row ['Q1-2012', '46330000000', '=B6/SUM(B4:B7)'], :style => [default, money, percent] ws.add_row ['Q1-2013(est)', '72230000000', '=B7/SUM(B4:B7)'], :style => [default, money, percent] # You can merge cells! ws.merge_cells 'A1:C1' end end p.serialize 'getting_barred.xlsx'

Here's the completed example.

# adapted from http://axlsx.blogspot.com/, https://gist.github.com/2484520 require 'axlsx' p = Axlsx::Package.new # Required for use with numbers p.use_shared_strings = true p.workbook do |wb| # define your regular styles styles = wb.styles title = styles.add_style :sz => 15, :b => true, :u => true default = styles.add_style :border => Axlsx::STYLE_THIN_BORDER pascal_colors = { :bg_color => '567DCC', :fg_color => 'FFFF00' } pascal = styles.add_style pascal_colors.merge({ :border => Axlsx::STYLE_THIN_BORDER, :b => true }) header = styles.add_style :bg_color => '00', :fg_color => 'FF', :b => true money = styles.add_style :format_code => '#,###,##0', :border => Axlsx::STYLE_THIN_BORDER money_pascal = styles.add_style pascal_colors.merge({ :format_code => '#,###,##0', :border => Axlsx::STYLE_THIN_BORDER }) percent = styles.add_style :num_fmt => Axlsx::NUM_FMT_PERCENT, :border => Axlsx::STYLE_THIN_BORDER percent_pascal = styles.add_style pascal_colors.merge({ :num_fmt => Axlsx::NUM_FMT_PERCENT, :border => Axlsx::STYLE_THIN_BORDER }) wb.add_worksheet(:name => 'Data Bar Conditional Formatting') do |ws| ws.add_row ['A$$le Q1 Revenue Historical Analysis (USD)'], :style => title ws.add_row ws.add_row ['Quarter', 'Profit', '% of Total'], :style => header # Passing one style applies the style to all columns ws.add_row ['Q1-2010', '15680000000', '=B4/SUM(B4:B7)'], :style => pascal # Otherwise you can specify a style for each column. ws.add_row ['Q1-2011', '26740000000', '=B5/SUM(B4:B7)'], :style => [pascal, money_pascal, percent_pascal] ws.add_row ['Q1-2012', '46330000000', '=B6/SUM(B4:B7)'], :style => [default, money, percent] ws.add_row ['Q1-2013(est)', '72230000000', '=B7/SUM(B4:B7)'], :style => [default, money, percent] # You can merge cells! ws.merge_cells 'A1:C1' end end p.serialize 'getting_barred.xlsx'

If you're an auditory learner, you can check out my tech-talk on axlsx.

To learn more, check out the axlsx blog.

What are some other Ruby gems you love to use?

Finish Weekend ATL

2012-04-30T00:00:00-04:00

Highgroove Studios is proud to be helping Collective Idea bring Finish Weekend to Atlanta this June:

We've all heard of startup weekends. Many of us have participated in one. Coming up with a new idea is easy, so is getting started. Finishing is hard. Finish Weekend helps you get it done. Come finish those projects you've put off to the side. Maybe you just need a bit of web help, a logo, or some code written. We'll help you finish.

Head on over to finishweekend.com to register, and then come join us the first weekend of June to get your project launched.

Rails Needs to Make JSON Serialization Easier

2012-04-26T00:00:00-04:00

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.

Instead of dealing with JSON views or presenters, ActiveModel::Serializer adds a new layer between rendering JSON in a controller and defining a custom to_json method. Now when rendering JSON in a controller Rails will look for a Serializer for the matching model and defer to that for generating the payload. Here are some examples to get you up and running.

We can start with a really simple Cat model.

Now lets write a controller action. Not really anything exciting yet.

OK so here's where the magic happens. Let's say we want to change up the JSON a little bit. For example we want to include the owner's attributes as well. Well that's super easy. Just make a CatSerializer in app/serializers like this.

Now look how our JSON response has changed!

/* Standard */ [ { "id": 1, "name": "Felix", "mood": "crazy" }, { "id": 2, "name": "Gorbachev", "mood": "awesome" } ] /* With a Custom Serializer */ { "cats": [ { "id": 1, "name": "Felix", "mood": "crazy", "owner": { "id": 5, "name": "Pat Sullivan" } }, { "id": 2, "name": "Gorbachev", "mood": "awesome", "owner": { "id": 6, "name": "Aaron Patterson" } } ] }

This isn't a very radical change in how some of the other decorator gems work, but I think it does a really good job at making serialization a first class citizen. Also the fact that it was built by 2 Rails core members probably gives it the best chance for some day being included in all Rails apps be default. Now they just need to convince DHH that it's a better approach than using JSON views with Jbuilder. :P

RailsConf 2012

2012-04-24T00:00:00-04:00

Highgroove sent me, Jonathan, and Patrick to RailsConf 2012. I've been learning a lot by going to some great talks and enjoying talking to my fellow Rails developers. If you see any of us, feel free to say hello!

There's a big push to make this the most public RailsConf ever, so all talks are being recorded. On top of that, I have also been trying to take notes and make them public.

I've looked around on where to best put my efforts of note taking, and I found the repository of notes started by newhaven.rb. After a good pull request, they've given me push/pull access, which is awesome! You can check the notes out on GitHub.

So what kinds of awesome talks have I attended so far?

Keynote by DHH about not being scared of progress
Steve Klabnik's talk on Designing Hypermedia APIs
Practical Machine Learning & Rails
Ruby on Rails on YOUR ROOMBA!
Scaling StillAlive from a RailsRumble project to 50,000+ users
Building realtime web apps with streaming REST
Keynote by Rich Hickey (developer of Clojure) on simplicity

It's been fantastic RailsConf so far, and I'm looking forward to the rest of it.

Live from Startup Weekend Atlanta

2012-04-21T00:00:00-04:00

Startup Weekend in Atlanta kicked off last night with over 116 participants, and 48 pitches, eventually forming into 18 teams. The concept behind Startup Weekend is to start something up -- a concept, business, or idea, over the weekend. It's centered around technology, with people dividing themselves into categories like: "business folk", "designers", "developers", and other niches. Yup, there was a technology lawyer, there too.

What kinds of ideas are being worked on right now?

I took quick notes on all the pitches, and here are some trends:

Crowdsourcing - ideas pitched on crowd-sourced recipes, carpooling, ticket/event booking, and educational ideas
Gamification - making a game out of education, fantasy sports (fantasy daily sports),
Photo sharing - and even photo manipulation around faces (think: a light version of photoshop to make you look sexy)
Jobs and finding talent - ideas were pitched on eliminating recruiting
Online Dating - and to an extent, verifying who is who, and finding folk through your social network

The micro trend of the night (in my opinion) was: "making something sexy" -- be it "sexy discounted cash flows" (best pitch of the night), your own photo of yourself, and even one team wanting help making their Ruby on Rails app sexy!

We're happy to be a part of this event, as sponsors, along with friends Mailchimp, Pardot, Appcelerator, Peer1 Hosting, and even Microsoft to name a few!

Stop by our table and say hello, if you're around!

The Beltline Bike Shop 'Bike Rack Locator' App

2012-04-21T00:00:00-04:00

The Beltline Bikeshop App, Bike Spot, is LIVE and available to install on your iOS device!

If you know us, you know we love bikes here at Highgroove. Any cyclist in Atlanta has encountered the 'parking' headache of looking for a spot, much less a rack to lock to while getting around on two wheels. Bike Spot is a bike rack locator designed to track, record, and locate bike racks around town.

Sounds awesome, right? "But how can I use it?" you ask.

So imagine you're about to embark on a bike ride, and wondering where the nearest bike rack will be. Here's how the Bike Spot app works:

Look for the nearest bike rack at your destination - Simply open the app and allow it to pinpoint your location
Zoom in/out to find the for the closest rack - More are being added regularly but maybe your favorite rack isn't included yet. Add it!
Find a new rack, photograph it - The app makes it easy snap a photo of any bike parking
Promote the app! - This app isn't only for Atlanta. Its merits apply in any city, any town, anywhere!

Bicycle commuting in Atlanta grew faster than anywhere else in the United States and its no secret that cycling is a positive, healthy way to get from point A to point B!

We're honored to have had the opportunity to contribute to this collaborative On The House project between with Hybrid Design, several Highgroovers, namely Daniel & Andy, Matchstic and the Beltline Bikeshop! A few weeks ago, we swung by the Beltline Bikeshop to celebrate the app's completion and to check out the shop. The Beltline Bike Shop is a tremendous asset for Atlanta and Highroove was excited to lend a hand to such a great cause. At the shop, the take donated bikes and invite kids in Southwest Atlanta to earn a bike of their own through community service. More info here.

Visit their website to learn more about the app, or download it from the app store! Download the here or in the app store.

Do your favorite businesses have bike racks? Are they listed in the Bike Spot app yet?

Edge Sunspot: Native Geospatial Searches

2012-04-17T00:00:00-04:00

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:

# Offices within 100 kilometers of (32, -68) Office.search { with(:location).in_radius(32, -68, 100) } # Offices within a bounding box of 100 kilometers from (32, -68) # A bounding box may include areas beyond 100 kilometers of # (32, -68) so offices may be returned that are outside the # desired region; however, the search may be more performant. Office.search { with(:location).in_radius(32, -68, 100, bbox: true) }

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.

Essential Developer Tools

2012-04-12T00:00:00-04:00

Read on for why you should be using a combination of Sublime Text 2 and Vim instead of Textmate…

LOLJK. The tool you should use is the tool which is best suited for you to solve the problem at hand. There is no one right tool that everyone should be using. We could go on and on about different editors as that is something that developers are very passionate about but the fact is that each developer at Highgroove has a different set of software that they use to get their job done. We have a recommended list of Software for Developers that can be pretty useful, but to each their own! Part of everyone's job description is:

Buy any tool that you think might be useful, Highgroove will reimburse you, and you must present to the team how your experiment works out and if the tool makes you more productive.

Software aside, Highgroove has a policy of buying the best tools available for developers, and there is a short list of things that we think are absolutely crucial for keeping developers happy and cranking out high-quality software. Some people argue that you should penny-pinch in every aspect of your business, but with our goal of developer happiness, we disagree.

Physical comfort comes first! While our personal trainer goes a long way, we have an office full of Aeron chairs and adjustable height desks. An ergonomic evaluation is happening in a few weeks, and we'll be figuring out how to make our sitting and standing desks more comfortable. Every desk has a laptop stand and a big external monitor (Currently 24" Dell 1920x1200 displays, but we have one Apple Thunderbolt 27" display that everyone is trying out), and everyone gets an external keyboard and mouse or trackpad of their choosing.

Also very important to productivity and happiness is a top-of-the-line laptop. SSDs and maxing out RAM are both great for running huge test suites and working with Big Data, and while it seems most of us end up with 15" MacBook Pros, we'd let someone scoop up something else if it works better for them. Laptops enable working from anywhere, and we're all pretty used to seeing photos from people 'ROWEing' it from decks, patios, the beach, etc. Just yesterday I was on a Skype call with someone that was working from their bathtub at home. If WiFi doesn't reach, we have a Clear Spot 4G and pay for iPhone tethering as needed.

We know we can't think of everything, so when someone at Highgroove wants something to help them work, we make it happen. Legos get added to the grocery list and show up the next day, hundreds of tiny buckyball magnets are stuck all over the place, and we have some super-nice condenser microphones for clearer conference calls and podcast recordings. And the sharks with lasers attached to their heads? We're not supposed to talk about those.

Did we leave anything out? What non-software tools help your software business be awesome?

Cast aside that debugger and use your test-suite

2012-04-10T00:00:00-04:00

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.

Often the above situation comes about during testing of complicated objects where a given assertion relies on several elements of state being correct. For this discussion the examples will be in RSpec 2 though any test-suite should be able to perform the same assertions with a simple change of syntax.

Assume you start with a simple example such as

class RailsyObject < ActiveRecord::Base def compound? # These properties could be attributes or computed attributes (self.simple? && self.clean?) || self.complicated? end def complicated? # ... snip ... end end

If the #compound? example above fails then clearly one of the three properties being checked is not in the expected state. You could do something like launch the debugger, launch the rails console, or bind a pry session and dig into the objects. All of these would work so lets examine the rails console version:

Loading development environment (Rails 3.2.3) 1.9.3-p125 :001 > FactoryGirl.create :railsy_object (0.0ms) begin transaction SQL (2.8ms) INSERT INTO "railsy_objects" ("clean", "created_at", "simple", "updated_at") VALUES (?, ?, ?, ?) [["clean", nil], ["created_at", Mon, 09 Apr 2012 11:39:38 UTC +00:00], ["simple", nil], ["updated_at", Mon, 09 Apr 2012 11:39:38 UTC +00:00]] (1.2ms) commit transaction => #<RailsyObject id: 4, created_at: "2012-04-09 11:39:38", updated_at: "2012-04-09 11:39:38", simple: nil, clean: nil> 1.9.3-p125 :002 > ro = _ => #<RailsyObject id: 4, created_at: "2012-04-09 11:39:38", updated_at: "2012-04-09 11:39:38", simple: nil, clean: nil> 1.9.3-p125 :003 > ro.simple? => false 1.9.3-p125 :004 > ro.clean? => false 1.9.3-p125 :005 > ro.complicated? => false

If we had used pry, ruby-debug, or even awesome_print and examined the object manually, we would have almost certainly done exactly those queries of our object to determine state. Since we doing proper TDD we probably have both our tests and our code open simultaneously, and some way of quickly running our test-suite such as vim-vroom or guard-rspec or some other custom set of bindings or tool, so why then do we context switch into yet another tool to debug object state when RSpec is essentially a DSL for doing just that?!?

Thus we can change our spec to do our custom querying as follows:

describe RailsyObject do describe "predicates" do before do @railsy_obj = FactoryGirl.create(:railsy_object) end describe "#compound?" do it "should pass for the default object from FactoryGirl" do @railsy_obj.should be_simple @railsy_obj.should be_clean @railsy_obj.should be_complicated @railsy_obj.should be_compound end end end end

which produces:

$ bundle exec rspec spec F Failures: 1) RailsyObject predicates#compound? should pass for the default object from FactoryGirl Failure/Error: @railsy_obj.should be_simple expected simple? to return true, got false # ./spec/models/railsy_object_spec.rb:12:in `block (4 levels) in <top (required)>' Finished in 0.01648 seconds 1 example, 1 failure Failed examples: rspec ./spec/models/railsy_object_spec.rb:11 # RailsyObject predicates#compound? should pass for the default object from FactoryGirl

In all likelihood we want to change our object creation step in FactoryGirl for this test of the predicate. We can make that deterination and change in one place without context switching, and decide to leave or remove those predicate checks before moving onto the next story or riding bikes. What do you do to debug or otherwise investigate the state of your objects without breaking your flow?

Sane Rspec config for clean, and slightly faster, specs

2012-04-06T00:00:00-04:00

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.

Prefer isolated tests

Whenever possible I strive to write isolated tests, stubbing out collaborators where necessary, while driving from the outside of the system downward, one layer at time. However, there are occasions where you must hit the database.

Testing ActiveRecord scopes and higher-order acceptance tests are two cases where I believe it is okay to have tests that cross layers, and may even hit a database.

Ensuring idempotent tests

When you are going to hit a database, your tests should be good citizens and clean up after themselves.

If you're using Rspec with Rails your tests run within a transaction by default. Yay!

Unfortunately, test tooling like Capybara won't work with transactions and you'll be forced to resort to techniques like database truncation to ensure proper data clean up. I really like Database Cleaner for that job.

An example Rspec configuration

What follows is the Rspec configuration we ended up with after the previously mentioned commit. Or at least a very close approximation of it

A few key take aways:

To start, turn off Rspec's built-in transaction support as we'll handle that with database_cleaner.

Next we configure a default clean-up strategy for every Rspec suite. We'll use transactions by default, being sure to clean up any thing that might have been left behind with a truncation.

We make a special exception for request specs, which are often driven by Capybara, and switch them over to truncation.

Then, before every test runs start Database Cleaner

And finally, after every test runs, tell Database cleaner to clean up using whatever strategy it is currently configured with.

For posterity's sake, you can see a full before and after of this particular spec_helper on The GitHubs.

vim-vroom

2012-04-03T00:00:00-04:00

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.

Announcing vim-vroom! An easy way to run your Ruby tests without leaving Vim. If you're hackin' away at some Ruby code, you can open up your test file and hit r (mapped to :VroomRunTestFile) to have it run that file. Now you can bounce around anywhere in your application code and just be a r away from running your last test file. If your testing framework supports it, you can also use R (mapped to :VroomRunNearestTest) to run the nearest test in the file as well.

Currently, MiniTest/Test::Unit, Cucumber, and RSpec are all supported. I've tried to ensure everything is easily customizable for whatever workflow you may have, and whatever preferences you may have. Things such as clearing the screen before running tests, color usage, key mappings, and more, are all optional and can easily be toggled on or off with just 1 line in your Vim config. Everything is documented for easy access in or outside of Vim. There aren't any known issues at the moment, but if you run into one, please file a GitHub issue, or, if you're particularly vimscript savvy, fork the project and send me a pull request!

Weekend Update: Open Source Software Contributions

2012-04-02T00:00:00-04:00

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.

Announcing: grocer

Grocer interfaces with the Apple Push Notification Service to send push notifications to iOS devices and collect notification feedback via the Feedback Service. There are other gems out there to do this, but Grocer plans to be the cleanest, most extensible, and friendliest.

Andy, Patrick, and I built the grocer in the course of just two days. Andy and I started it with a morning-long ping pong-pairing session on Thursday, the three of us hacked on it through the afternoon and most of Friday, and pushed it out Friday night.

Announcing: git_tracker

Some simple tricks that make working with Pivotal Tracker even better... and easier... um, besier!

I technically pushed the first version (0.0.1) of git_tracker a week ago, but it went v1.0 Saturday afternoon. Please give it a shot, and feel free to open issues and send pull-requests.

Announcing: puppet-osx_defaults

This is a simple puppet module for managing the defaults system in OS X. It currently has support for defaults domain keys whose values are boolean, integer, or string types.

Will, a lover of all things automated, whipped together a Puppet script for sane OS X defaults.

Image credit: http://timmyclunkers.tumblr.com/

Staying in the Groove at Highgroove!

2012-04-02T00:00:00-04:00

Anyone that knows anyone at Highgroove knows we're not your run of the mill rapidly growing Ruby development shop. We're a unique team of creative individuals bent on productivity hacking and iterating on client needs until the app is awesome. Sure we've got some great perks and compelling reasons to make the commute into the office despite being a ROWE. What do we do at Highgroove as a group to intentionally keep our culture cool/unique as we continue to grow? Read more to learn about we stay keep our groove at Highgroove.

Most everyone at Highgroove pens an entry here on the blog describing their initial days and weeks. Like Will put it, getting into the groove involves getting accustomed to working in a ROWE, following all 12 agile principles and getting on the iterative schedule we use for client facing and internal work. Plus we have Tech Talks, Team Dinners, unlimited vacation and even unorthodox approaches to office life like unassigned seating and having a personal trainer. These are all integral components to what makes the culture at Highgroove awesome!

Andy gave me the idea for this post after reading Karen Rubin's Harvard Business Review article entitled "How Start-Ups Can Maintain Company Culture While Growing" Karen focused on two of the 12 Things You Might Not Know about company culture at the second fastest growing SaaS company in history: Hubspot. According to her, (and we agree!) the two approaches to keeping Hubspot's culture vibrant and true to the original vision of the company are communication and measurement.

Here are three examples of what that means to us at Highgroove:

The Highgroove Award | Our award exists on the website and as a physical trophy The Highgroove Award even ultimately became an app! To us the Highgroove Award is about communication and measurement. It encourages compliments and is a gauge for how we as a team are embodying the Highgroove Values of being Personable, Optimistic, and Trusting, while exercising Craftsmanship in all that we do. At Highgroove, well-deserved compliments foster teamwork, increase morale, and make us better as a team than we could be on our own.
Weekly Iterations | Everything revolves around single, double or 4 week iterations. If something doesn't work, scrap it. As as our friends at Matchstic said last week: "The best idea wins, no matter where it comes from." Iterative development relies on this level playing field of communication to stay agile as well as providing the framework for the collaboration we promote in everything that we do. For Highgroove this means, as Chris put it "Iterations hurt [a] developers self esteem. Iterations are great for developer self esteem." Lastly, we end our iterations on Tuesdays putting any potential crunch time then and not on a Friday or the weekend. Cool, right?
Surveys & more! | At Highgroove we're constantly looking for ways to gauge employee (and client) happiness. This focus on morale measurement facilitates identifying issues and obstacles as well as determining when and if if we've moved beyond them. in fact, we're working on releasing a public version of some of the things that make Highgroove work smoothly. A internal tool that we use as a "How's it going?" for projects and organizations that we hope to release soon. Stay tuned!

In the same way we endeavor to participate in and contribute to the Ruby and open source community. In this way we share our approaches to keeping our culture cool and unique, and may help to improve the company culture for other companies around us.

Does your company have a unique culture? How do you keep it that way?

Highgroove Made Me Super Efficient And All I Got Was This Lousy Free Time???

2012-03-27T00:00:00-04:00

At Highgroove, I've become a stronger developer, consultant, and mentor every day. This didn't happen on accident! On one hand, Highgroove's philosophy to provide the best tools possible in the software development industry saves me time because I spent less of it waiting for tests to run and more time analyzing hard problems. On the other hand, I have a Results Only Work Environment (ROWE) where I can leave when my work is finished, take a mental break whenever I need to, and work when where and how I please.

Despite these things that set Highgroove apart from most employers, I have found the dark side to all of this productivity: What do I do with all of the free time I have now? When you don't have to stay at the office for 10 hours a day just to save face, impress your bosses, and hopefully not get passed up by someone else who is better at sucking up than you are, this becomes a real problem!!! In this blog post I'll address this problem and show some creative ways to help unwind after a long day (or night!) of programming.

So what are some ways to enjoy hyper-productivity? For starters, I highly advise doing something that you are passionate about. You will be motivated to do whatever it is that you chose to do, you will enjoy doing it, and you will want to continue! Secondly, I advise slowing down and not worrying about being productive while you're off the grid. Why do you want to rush through your free time? Enjoy it!

At Highgroove, several folks already have hobbies outside of the office and have no problems making use of their free time! For example, several Highgroovers meet at a local cycling track and run circles around each other. Some volunteer for local charities like Habitat For Humanity or the Georgia Aquarium.

For some readers though, picking up a brand new hobby is easier said than done. What if I don't like going outside? What if I get hit by a bus riding my bike in Atlanta traffic? What if I fail? For those of you who are concerned about starting new, I recommend taking a deep breath and a thinking about what the main goal really is: that you are doing something new and exciting and that the outcome doesn't matter. With a new attitude in place, pick a new hobby! To help with this process, here are some examples to help pick out your new found free-time killer:

Running and being active outdoors
Take time off and Travel to somewhere you've always wanted to visit
Learn a new language (Human languages only!)
Cook and take the time to go to a farmers market, prep everything, and make it all from scratch. Frozen meals absolutely do not count!
Volunteer at a local non-profit. Here's a list of a bunch of them
Invite a friend you haven't seen in a while to hang out at a local hotspot. Work is not a topic to be discussed!

The only goal now is to keep yourself accountable regarding your new hobby. Highgroove has plenty of experience getting things done, so if you need some organization help, check out Chris' tech talk on Things!

Highgroove strives to support a positive life-work balance by providing the best tools possible and a ROWE. Does your workplace encourage you to get away from the office?

The anti-meetings - The Weekly Huddles

2012-03-26T00:00:00-04:00

Meetings. Quick chats with our customers, daily if possible, don't count as meetings. They keep everyone on the same page to make sure good progress is being made for them, to address any questions or concerns they may have, and possibly to plan the next steps to take in developing their app. By "meetings" we mean that word that brings dread to the heart of anyone who has ever looked at their schedule and seen only two hours of their daily schedule available for actual work, and in fifteen minute blocks no less.

At Highgroove we have a few tactics for avoiding just that. Firstly, we don't have many. Moreover, all meetings are optional, and you can come and go as you like. A quick glance at my calendar shows vastly more pairings, personal trainer sessions, hack nights, team dinners, and other informal team outings than it does meetings. We consider this a win. Like all companies we still need some variety of status updates, the kind of subject matter that would usually go into a weekly company or organization meeting. To address that need we "bring it in" for the weekly huddle emails.

From our own documentation on one such huddle "This is a quick huddle-style meeting - not a working meeting. Just a high-level, decision-making quick meeting focussed on removing impediments and moving forward." To facilitate those goals only the absolutely necessary parties are involved. Anyone is welcome but very often developers are not involved in the sales process and would rather get tacos than talk sales and marketing numbers.

On the business side of the house our huddles have a fairly strict script. The list of bullet points that make up the script can be answered effectively with little analysis, and decisions can be made. This eliminates that weekly PowerPoint snooze fest many are familiar with. To keep the rest of the team in the loop during their taco or Cherri-induced coma, an email is sent out with details from the huddle. Again, in the interests of brevity and focus, the script is copy/pasted into the email with any salient details on each one quickly described.

On the developer side of the house the process is almost identical but with slightly more developer-centric information. The content is entirely collected by email or our tracking tools like PivotalTracker, Reflecticle, and LetsFreckle, and allows everyone to have a feeling for what's going on around them. After reading the huddle email we know who's blogging and giving tech-talks this week, and on what subjects, who is on vacation, what clients are saying on other projects, and what special events are coming up. All-in-all it may take some time to compile, in small time slices, but it takes just a few minutes to read at your leisure without ruining your workflow, the one you always get into just before that big meeting...

What do you do to eliminate meetings and make sure you can be more productive to ride bikes and eat tacos?

Open Source Hack Night

2012-03-20T00:00:00-04:00

Last night at the Highgroove Studios office, we held the March edition of Hack Night, our monthly social coding gathering. We focused on starting, polishing, and/or discussing open source projects ranging from the super useful to the super silly (beer is always provided at our hack nights...)

While CBQ hacked away at some Rails documentation using docrails, others were busy building and even releasing other tools.

Roughly an hour into hacking, Andy announced a new release of the zonebie gem, written by him and Patrick, which is a gem that runs Rails/ActiveSupport tests in a random timezone to spot pesky bugs.
Steven and Andy, seeing the need for a lighter-weight delegator than what is found in Ruby's standard library, hatched the idea for and released the first iteration of DumbDelegator.
Will released Bootlace, a gem for bootstrapping Ruby applications.
Jonathan released Yamldiff, a gem that prints out a list of missing keys for two yaml files.

These are all works in progress, and we keep an active public Pivotal Tracker project for our open source ideas in order to track our progress and encourage conversation. We want to continue honing our own skills while bettering the development community through continual projects. Some of the results of our efforts are, we feel, pretty sweet.

All-in-all, we had a pretty productive open source hack night. We were super excited to have Jonathan, Greggory, and Ben (along with other Hack Night guests) join in the fun, set up some github accounts, and eat some pizza with us.

Are there any of our open source projects that you can fork and improve? What other projects should Highgroovers consider next? Jump in and get fork'n!

Spree Conference 2012

2012-03-15T00:00:00-04:00

Last month I had the privilege of attending the very first SpreeConf in New York City. If you aren't familiar with Spree, it is an awesome Rails e-commerce engine you can use to build a full-featured online store. The conference was held over two days; the first day featured several training sessions. The sessions covered a range of topics including theming, configuring, and testing Spree. The second day was filled not only with talks related to Spree, but to e-commerce and Open Source in general.

The conference coincided with the 1.0 release of Spree. Throughout the training talks and into the second day, presenters were quick to point out some of the awesome new features now available with Spree. One of the most exciting is the inclusion of the Skeleton CSS framework, which helps Spree provide a great shopping experience no matter what device your customer is using. The admin backend and default front-end theme have also been revamped to be easier to use and customize.

Highlights of the conference for me included Brian Quinn's talks on Deface and Spree's hidden gems. Ryan Bigg navigated to a meme-filled slide deck to talk about his experiences working with engines for Spree and for Rails in general. He concluded his talk by pushing a Rails Guide on engines to Github. After his talk the Spree team gave everyone a copy of his book Rails 3 in Action.

Ryan McGeary gave a very inspiring talk about Open Source. He told a story about his quest to create a Spree store that connected to a Makerbot to offer just in time inventory. While in the end the result wasn't practical for running a business, his point that he was able to do so with very few lines of code by modifying existing Open Source code to suit his needs. He is then able to share that code for others to improve on - "Standing on the Shoulders of Giants."

While the conference was aimed at Spree developers and store owners, it was clear from the start that this conference was mostly about celebrating Open Source, and not just software. The keynote speaker for the event was Bre Pettis, founder of Makerbot Industries. Bre shared an example of how the Makerbot community works together to solve problems. Collaborators from around the world had been working on printing a working clock derived from a clock mechanism one person posted on Thingiverse (Thingiverse is sort of the 3D-Printing version of Github), but no one was successfully able to get it work alone. So Bre organized several Hackathons where Makerbot provided space and food for everyone to come together and work. Eventually the team was able to build a working clock.

Bre's point was that electronic collaboration can get you really far; however, there is no substitute for face to face interaction, and that most of the important work is done over food anyway.

Overall the conference was huge success. Not only did I learn a lot about Spree, and Ruby in general, but I also met some awesome developers from around the world who are truly passionate about Open Source. Every now and then, we as developers need something like a conference or meet-up to remind us how exciting our jobs are, and how lucky we are to be part of such an great community.

What is something that has gotten you excited about Ruby and/or Open Source recently?

ROWE, ROWE, ROWE your boat: Work can be a dream!

2012-03-13T00:00:00-04:00

Imagine you are a recent graduate eagerly awaiting the next chapter in your promising future. From a very early age you were always told that "the world is your oyster" from your parents, peers, and teachers -- a thought so established in your mind, that you are anxious for what lies ahead. Within weeks you are confidently striding through the doors of your first real job in the so-called "real world." Armed with the knowledge and work ethic instilled by the demanding four years previously spent at university, you feel almost unstoppable. You quickly make eye contact with your manager, and before you can greet him with your million-dollar smile, he informs you in his monotonous lack-of-coffee voice: "You’re late." Suddenly the feeling of inadequacy takes over and reality sets in -- you're five minutes late. The expectation of the future becomes grim and you’re convinced that work is anything but a dream... or is it?

For many, the scenario above is commonly associated with what a typical 9-to-5 job feels like. You come in at 8:55 (if you are running late, swing by the local donut shop to distract and disarm), pour yourself a cup of coffee, and proceed to chain yourself to your cubicle until lunch rolls around. You repeat a similar process in the afternoon.

Even if your work place is somewhat "progressive", and it's not a big deal when someone rolls in late, comes in early, stays late, or simply needs to "leave early" for a doctor's appointment, there's a moment of guilt or shame -- "do I need to ask permission?" or "should I get credit for staying later than everyone else?"

At Highgroove, we operate just a tiny bit differently. We are hyper-specialists in the web development world, and that means we strive to deliver results. We are a Results Only Work Environment (ROWE) which simply means that our talent can work whenever from wherever, as long as the results are met.

When I was first introduced to ROWE, I had a difficult time understanding what I had to do -- results are one thing (they're actually clearly defined), but when do I come in to the office? When is an ideal time to leave? Heck, do I have to come in at all?! After a few days, I realized all I really "had to do" was to deliver the results for the iteration, that's it. Armed with tools to enable development and communication where ever and when ever (I choose), and a team to help me out, I set to it.

You're probably wondering why anyone in a ROWE would want to come into the office at all. The office doesn’t have to be a scary place. In fact, we tend to come into the office because it helps us accomplish our results faster than if we were working from somewhere else. Our office has everything from Herman Miller chairs to generous 24” displays, along with a plethora of knowledge willing to be shared by other Highgroovers. For many, transitioning from a typical 9-to-5 job to a ROWE can be really difficult because the typical metric of hours worked doesn’t matter anymore. As a fresh graduate, I was afraid of managing my own time, but then it became apparent to me -- I’ve been practicing ROWE for more than four years across the street at Georgia Tech!

Attending university has offered some of the best experiences of my life, and ROWE enables us at Highgroove to continue living our lives while working in complete freedom. Everyday feels like a Saturday and while I haven’t been at Highgroove that long, working here has been unreal! Now excuse me, the weather is sunny and 72F out, so I’m going to take off and go for a drive, since I just finished my result of a blog post, and some work for a client!

Image Credit: revstan on flickr

The Highgroove Test

2012-03-12T00:00:00-04:00

Prior to working at Highgroove, I worked for a number of softare product companies. One of the best metrics I've found for measuring how great a company is to work for as a developer is the Joel Test, which is a list of 12 simple questions. I've worked at companies that have scored high and companies that have scored low, and please believe me when I can tell you that the issues on that list really do make a difference.

My only issue with the Joel Test is that it is really geared toward software product companies. While a lot of the ideals translate to a software consulting company, the specific questions don't always apply when you are working on a lot of projects for a number of clients. So, in an effort the help measure what makes great software consulting teams so great I present...

The Highgroove Test

Do you give your customers access to their source code?
Do you document projects expecting that your developers will eventually be "hit by a bus" (no longer be on the project)?
Do you track results instead of tracking time?
Do you promote Test Driven Development?
Do you use and contribute to open source?
Do you use code reviews?
Do you use the best tools?
Do you only hire the best developers?
Do you require constant learning from your developers?
Do you favor simple solutions?
Are your developers your project managers?
Do your developers deliver code to customers at least daily?

Like the Joel Test, this isn't meant to be the be-all-end-all list of what software consulting teams should do, but we at Highgroove believe that a team that can answer yes to these 12 questions consistently is a great team to be a part of.

1. Do you give your customers access to their source code?

A developer should never have to feel that their customer doesn't have access to the work that's being done. The source code is the client's property and it's important to be as transparent as possible.

2. Do you document projects expecting that your developers will eventually be "hit by a bus"?

With many of the developers at Highgroove biking to work though Atlanta's busy streets this issue is almost more literal than figurative. Each project should have a README with all the steps needed to get the development environment up and running with no outside input. The issue tracker should have all the information on what has been done and what will be done in the project. To achieve this at Highgroove, we make our Pivotal Tracker projects the authoritative source for all information about the project. Nothing should live solely in a developers head.

3. Do you track results instead of tracking time?

Tracking time gives developers the wrong incentives. A software consulting team should push to work as efficiently as possible. Tracking hours pushes developers to stretch work to take an allotted amount of time, and forces them to focus on the clock instead of focusing on cranking out functionality. It's inefficient and lowers the morale of the team. Your work place shouldn't just be results only, so should your projects!

4. Do you promote Test Driven Development?

Consultants need to deliver well designed and bug resistant code efficiently and consistently. The best way to do this is having automated testing as a key part of your development workflow. This should be part of the team's culture. If you are not worried about catching guff for not including tests in that last commit, then your team is not as serious about testing as it should be.

5. Do you use and contribute to open source?

If your team falls victim to the Not Invented Here Syndrome you are wasting your time and your client's money. Period. Making use of existing, open software allows you to leapfrog ahead and crank out value for your clients. Contributing back to the community can get you great karma, but more importantly better code, great marketing, and the ability for developers to scratch an itch for projects they love to work on.

6. Do you use code reviews?

Code quality should be consistent across all members of the team. One of the best ways to ensure this is to have regularly scheduled code reviews from all different members of the team. As a developer you get yet another pair of eyes to guard against issues with your code and designs; As a reviewer you get to learn from all of the work your colleagues are doing. This is one of the best ways to foster growth in the team as a whole.

7. Do you use the best tools?

This is the only hold over from the Joel Test. This is amended a little because as a developer who uses VIM and Unix for my development environment it felt odd to say "Do you use the best tools money can buy?" A simple idea is encapsulated in this question. If you are a software development team and there is something out there to make your developers more awesome, why are you not using it?

8. Do you only hire the best developers?

I do not want to be the best developer in my team. To clarify, I definitely strive to be the best developer on my team, but I do not want to be surrounded by developers aiming straight for the middle. If a team is great and getting better, you as a developer have room to grow and get pushed to improve every day. Mediocre developers are a liability and can drag a great team down.

One key point about this question is that ability should not be confused with experience. A fast learning developer who is committed to improvement is often a much better addition to a team than someone who has been doing a less than stellar job for a few years.

9. Do you require constant learning from your developers?

Learning should be part of the culture of a great software consulting team. Your clients expect their developers to be up on the latest and greatest. Moreover, encouraging learning helps to keep developers engaged as they get the chance to tinker with new technologies and best practices. Learning is a huge part of what we do here at Highgroove, from our weekly tech talks to our new company book club.

10. Do you favor simple solutions?

While, as a developer, it is always tempting to engineer a bomb proof stats engine that can generate beautiful graphs of everything you could ever possibly want to know, sometimes all you really need is a CSV file that can be opened in Excel. Consultants should focus on giving the client what they really need, instead of what they are asking for on a specific day and give suggestions accordingly. Moreover, there are few bigger drags on morale as a developer than pouring hours into a solution that you know in your heart is superfluous.

11. Are your developers your project managers?

At certain scales having a separate project manager is unavoidable and can be very helpful. However, at Highgroove we've found that when we are able to break up projects very granularly and empower developers to manage their own projects, they are much more efficient. With developers interfacing directly with clients, there is much less overhead in communicating issues back and forth. This is more rewarding for the developer and creates more value for the clients.

12. Do your developers deliver code to customers at least daily?

There no longer any reason for a developer to collect requirements, go into seclusion for three months and then deliver code to the client only to have something to be a little off. Tools like Github and Heroku greatly reduce the friction associated with releases so that they can be done multiple times throughout the day. This allows clients to catch issues or change their minds very quickly with a minimum of rework on the developers part. The tighter the feedback loops is, the happier everyone involved with the project will be.

Here at Highgroove, we are very proud to be able to answer yes to all 12 of these questions. We believe that the way we work is a major part of how we do a great job for our clients and what makes us such a great place to work.

What else? Can you think of a better way to test for great software consulting teams?

Refactoring: where to draw the line?

2012-03-06T00:00:00-05:00

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.

Refactoring should be done to address needs, but due to the huge number of patterns, developer habits, and differing intentions, it's easy for developers to get carried away. In the worst possible case, you end up with 'the rewrite' where part or all of the backend of an application is rewritten from scratch. This is typically not cost-effective, but is actually needed occasionally.

More frequently, a developer will be implementing a small feature and see 'one small thing' to fix. Then they see a related method that could be more readable, some inconsistent naming, and before you know it they've spent the entire afternoon going down the rabbit hole and touching every file in the project.

A recent project that Highgroove took on to get in 'launchable' shape looked like it was going to just require a little bit of polishing and a 'new sign-up flow', but ended up not having any test coverage and had a lot of code from it's previous development team that was overly complex (some of which was intentionally obfuscated to make it harder for 'hackers'). Our customer wanted to launch their product ASAP, but there were some features they needed that weren't yet built.

We explained their current situation, testing, and refactoring, to the customer and outlined several options:

The "Nuclear" option - Redoing the application from scratch, and doing it in the Right Way following industry standard best practices.
The "Cross Our Fingers" option - Building the new sign-up flow, but sticking with the pattern of the rest of the system and not writing tests because we couldn't adequately test new features independently without touching the rest of the system.
The "Refactoring" option - Identifying parts of the system that we would need to interact with, writing tests for them, and refactoring them as needed to enable clean integration with the new features we'd be developing.

Hopefully you can guess: they chose the last option. We spent several iterations adding tests, improving code quality, and once we got the point where we could start adding the new functionality, we stopped. There were still random abbreviations, huge swaths of untested code, and things that we didn't understand, but our client had a time budget that we needed to stick to. This was hard! As developers, we like doing things the Right Way which means shipping high-quality, well-tested applications. In this case, we had to settle for something much less than perfect.

For every major issue we identified, we updated the README with suggestions for future development, and for every issue regardless of size we created stories in pivotal tracker, anywhere from "Refactor the Foo model to replace all occurrences of SOS with SaveOurShipMessage or save_our_ship_message" to "Figure out what the baz method does, give it an appropriate name, write tests, and refactor for readability." Some of these things got done as we wrote code that interacted with them, and many more are still in their backlog, hoping to be eventually done.

Just like any new functionality, for any refactoring ideas we make stories for each one. We keep these stories as descriptive and simple as possible, and they get prioritized by the client like any other stories. Seeing these stories pile up in the backlog and knowing that the issue won't be forgotten is usually enough to keep me from taking refactoring further than I need to.

How do you control your insatiable urge to rewrite everything? How do you sell refactoring to customers?

Startup Riot Sponsorship Worth It

2012-03-01T00:00:00-05:00

Last Wednesday CBQ and I attended Startup Riot on behalf of Highgroove. We heard 3 minute pitches (and 3 minutes of questions from an expert panel) from 25 startups. This is easily the biggest event in the Atlanta startup community; missing it is not an option and sponsoring was a no brainer for us. We love working with startups, since we used to be one. Read more to learn about how we sponsored this event, and what we got out of it.

First of all: What is Startup Riot SHOW?

"Startup Riot SHOW is an all-day event which highlights 25 startups through three minute, four slide presentations given by the startups. The startups subsequently answer questions from a judging panel for three minutes. There are a few important aspects that make Startup Riot SHOW different than any other startup conference you've heard about or been to."

Pitching an idea in three minutes isn't easy. It's the perfect amount of time for each presenter to not only convey what problem they intend to solve but also how. At Startup Riot, our involvement was not confined to three minutes but rather three events.

Highgroove achieved three goals with our sponsorship:

MAKE | Collaborating: At the MAKE event we blogged live about how we lent a hand to developers there by offering help in the form of knowledge and programming chops. This environment is an extension of how we operate internally: collaborate, iterate and ship it, quick! We love building great web apps and the MAKE event allowed us to share our expertise. In addition to helping establish us as experts at building back-end web applications, we made some great connections and saw some of our open-source libraries for Rails in action, in the wild.
JOIN | Recruiting: At the JOIN event we manned a table to present the allure of what brings the best Ruby developers to work here. A recruiting event is a long-term investment. The people you meet are looking for a great job, but they also know people who are looking for an great job, too. Even if they're not a good fit for your company, you might have a connection for them, and they might have a connection for you. It's networking 101, and Startup Riot's JOIN event has netted us one fantastic hire, and we've got a few more in our queue (in our hiring process right now).
SHOW | Networking: And lastly, at the SHOW event we mingled with some Atlanta's most passionate and capable entrepreneurs. It was personally exciting as a rookie in the startup scene. By the end of the day networking and note taking had paid off. I had signed up for numerous Betas, exchanged cards, and handed out lots of wolfbrains.

Congratulations to viaCycle on winning 1st place! We, of course, couldn't be happier about more bikes on the streets here in Atlanta. More photos from the event are here. We're already looking forward to next year, Sanjay.

For more on Startup Riot itself, check out:

How does your company give back to the community that supports you?

Image credit: eyelovelife

Writing Readable Ruby

2012-02-28T00:00:00-05:00

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?

Before Ruby, the experience I had in dynamic, interpreted languages was with Python – a language with a totally opposite motto, "There should be one, and preferably only one, obvious way to do it." As such, Ruby and Rails were somewhat of a shock. The first thing that comes to mind about loose dynamically-typed languages like Perl and Ruby is usually, "But it'll be so easy to write bad code!"

And it is! As the author of Eloquent Ruby says, Ruby is a "language for grownups," meaning that writing ugly, hard-to-maintain code is certainly possible, but this freedom allows for beautifully expressive, concise, and readable code.

Here are some guidelines that I and other Highgroovers use to make sure we achieve the latter whenever we can:

Write functional. Why write code that looks imperative when it doesn't really change any state? Enumerable methods like sort_by and reduce go a long way towards making code understandable in less time, as does the ubiquitous Symbol#to_proc.
Use method synonyms that make sense. It seems like many newcomers to Ruby are wary of using more than one name for the same method. For example, you can retrieve the number of elements in an array with #count, #length, or #size. Which one you use depends on why the number of elements is needed, and what "sounds right" in the given section of code. Synonyms also make it easier to
Make syntax English-like when reasonable. Readers of _why's poignant guide know this already, and know how it can make reading code more like a game than a chore. This includes using the right synonyms for a method as above, as well as choosing your own variable and method names cleverly. Why name a method that returns a list of primes less than n like primes(n) when it could just be primes_less_than n?
Review! Of course, it isn't always possible to stick with these guidelines. Business logic can get messy and working with legacy code can make English-like syntax a pipe dream. But having your code reviewed can reveal which bits can be fixed easily, as well as which bits are completely opaque to a newcomer.

As an example of putting these into action, let's write a method that turns a hypothetical Rails model into a hash of its reports; we need to convert every report to a hash, combine them, and return it. Here's the straight imperative way:

It gets the job done, but it ain't pretty; again, the #merge! method seems out of place, since it implies a change in state and the only thing really changing is the return value, which should be expected.

Here's a more functional way:

This is a bit shorter, and the fact that @reports is the "subject" being method chained and then returned makes it clearer that the return value is just some transformation of the model's reports. But let's try to make it almost readable English:

This is much shorter, and translates easily to its purpose: Take this instance's reports, map them to hashes, and reduce them by merging them together. It's also nearly point-free since the map and reduce blocks just take method symbols.

Of course, personal tastes will vary on whether this is the ideal way of representing this or that method. But for me, the guidelines above have led to generally clearer, more comprehensible code during review.

How do you make sure your code is clear and concise?

Salesforce on Rails with the Databasedotcom Gem

2012-02-28T00:00:00-05:00

At Highgroove, we're always looking for new ruby gems to help speed up development and keep the code DRY. The gem I found this time was Heroku's very own Databasedotcom gem, a fantastic Salesforce.com API wrapper for Ruby! I must admit, I wasn't very surprised to find a gem since Salesforce owns Heroku, but I did not expect it to be so fantastic and easy to use. Here's how!

There are only a few steps involved in getting the Databasedotcom gem connected to your salesforce instance and working:

Create a new Databasedotcom::Client instance - client = Databasedotcom::Client.new(:client_id => ENV['SALESFORCE_KEY'], :client_secret => ENV['SALESFORCE_SECRET'])
Authenticate with Salesforce - client.authenticate :token => SALESFORCE_OAUTH2_TOKEN, :instance_url => INSTANCE_URL, :refresh_token => SALESFORCE_REFRESH_TOKEN
Create a Ruby Class from a Salesforce Object - client.materialize("Contact")
Use the newly available Ruby class named 'Contact' and use ActiveRecord::Base methods on it. The gem will translate the ActiveRecord syntax into SOQL and API calls for you just like you're used to in Rails with any other database adapter!
For example: Contact.find_or_create_by_FirstName_and_LastName(:FirstName => 'Daniel', :LastName => 'Rice')

There are many other ways to use this gem, and its possible to interface with custom objects and custom fields, but I wanted to mainly illustrate how few lines of code it takes to make a Salesforce integration thanks to the awesome job by the Heroku team.

To see more use cases, features, and general information about this gem, please check out the Databasedotcom gem's README on Github.

Image Credit: Salesforce.com *No Software logo is a registered trademark of Salesforce.com

Rails and CanCan: Authorization for Specific Fields

2012-02-24T00:00:00-05:00

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:

class EventsController < ActionController::Base load_and_authorize_resource def update # UGH! if @event.status != params[:event][:status] unless current_user.admin? || ["pending approval"].include?(params[:event][:status]) render status: :unauthorized and return end end # ... end end

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:

class Ability include CanCan::Ability def initialize(user) # ... can :perform, EventStatusChange do |status_change| user.admin? || ["pending approval"].include?(status_change.new_status) end # ... end end

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

class EventsController < ActionController::Base load_and_authorize_resource def update if @event.status != params[:event][:status] authorize! :perform, EventStatusChange.new(@event, params[:event][:status]) end # ... end end

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?

Why Highgroove has a Personal Trainer

2012-02-21T00:00:00-05:00

At Highgroove, we have a personal trainer, Cherri, on-staff and on-site, available twice a week to us, scheduled via Appointment Slots using Google Calendar. Our personal trainer has been with us since December of last year, and we just added more sessions. We have been delighted at the opportunity to get in shape (although, perhaps, temporarily less thrilled when "core day" came around). Personally, having someone motivate us to exercise -- someone who thoroughly knows what they are doing was exactly the motivation I needed to start working out again. But we've also realized getting a gym session in during the afternoon has benefits for developing software (along with developing sweet abs).

The sessions are personally catered to each of us, last just thirty intense minutes, and with the gym just downstairs, it's a quick walk over to start working out. It's an even quicker walk when Cherri sends you an email, reminding you that your session starts in 1 minute. With such a short work out session, and scheduled in the middle of the work day (almost all sessions are after lunch), you would think it would cause a break in productivity, but the opposite actually happens.

In fact, Lifehacker has posted about the benefits of a workday workout, explaining that it improves energy and alertness as well as productivity. The article fits my and other Highgroover's experiences perfectly: working out gives an energy boost that used to be gained by an extra double-shot of espresso, and also gives us time to mentally work out the programming problems wracking our brains. We can return to work refreshed (if a little sweatier) and ready to tackle things from a new perspective. It almost seems counter-intuitive, but after a work out, we have all remarked on the productivity increase. It's real!

What healthy habits give you a productivity boost?

Working Hard or Working Efficiently?

2012-02-21T00:00:00-05:00

Companies often feel that they are getting the most out of their employees if everyone is working as hard as possible for as long as possible. However, this can be exhausting on the employees and can lead to diminishing returns. We feel that the better approach is to emphasize efficiency over effort, and our level of productivity speaks for itself.

Working in a ROWE gives us an advantage in working efficiently because we can better handle common productivity pitfalls. Stress rears its ugly head in many projects. In a typical 9-to-5 (or even later) the employee is chained to their chair and must work until the end of the day, or until a moment of escape presents itself. How much work is actually done in those last few hours as stress goes up and morale goes down? Because we have the freedom to work when we want we are able to step away from our projects for a few hours, do something that relaxes us, and try to tackle the problem in a better mindset. Given the break time we may work fewer hours in the day overall, but those fewer hours produced more than the stressed employee. The resulting code is also likely of a higher quality due to the more focused employee making fewer careless mistakes.

We are also able to avoid burnout by taking advantage of productivity bursts. Every developer has been on a programming tear, where they are able to crank out code at a blistering pace and don't want to stop for fear of losing momentum. When they are done they may have completed a day's work in a few hours. What to do next? Whatever you want, as long as you're meeting your client's needs.

Emphasizing efficiency over effort leads to happier employees, fewer errors, a higher quality product, and happy clients. Everyone wins. What other strategies can you use to maximize efficiency?

Another Reason To Use Github

2012-02-20T00:00:00-05:00

While getting to know the very sweet Github Api v3, I ran into a little bug when trying to page though results coming back from the service. While it was frustrating at the time, Github's support and resolution blew me out of the water.

For a new in-house project, we would like to be able to grab the commit messages for a number of our repositories that live in Github. Using the octokit gem with the auto_traversal option turned on, this is trivially easy. Because of a bug in the Github api, when the gem tried to page though the results, the link it got for the next page was always the same. This caused an infinite loops of http requests, and me to try to pull all of my hair out.

Once I threw a few pry bindings into the project and was able to track the issue, I was able to easily hunt down Github's support for issues with the API (it was right on the docs page for the API). All that was required to get a fix deployed for the issue was a quick email with steps to reproduce the bugs and less than 24 hours of patience!

The fact that the Github crew was able to submit a fix to their live service before I could submit a pull request to octokit with a workaround reminds me why they stand out in my mind as a great web app. Not only is their site feature rich and easy to use, but they've got a great team backing the technology up. That's why we at Highgroove trust them with our code and why we recommend them to clients.

Live from StartupRiot MAKE

2012-02-18T00:00:00-05:00

The StartupRiot MAKE event kicked off last night at ATDC with the help of Sanjay Parekh and some very awesome sponsors and teams.

We're happy to be a part of this awesome event. At 5 pm on Friday, teams started trickling in and sponsors started setting up displays. The food arrived and many people began networking and planning already.

At 6 pm, Sanjay announced the teams, and each team got up and spoke about what they were building, and what they needed -- be it a designer, some mobile development help, or back-end development.

There are some awesome prizes, but I am pretty sure the teams that are here, while they are happy to win, are actually here because they enjoy making and building things using technology. You can actually tell, because in addition to building products (we've already seen a few working demos), they're helping each other, offering encouragement, and feedback.

A few of us from Highgroove are here this weekend offering help in the form of knowledge and programming chops. Since we've built products and services for companies both big and soon-to-be-big, we're pretty opinionated about what we've seen that works and doesn't work in a modern web application. Our actual real service, though, that we're offering is something that comes natural to us: "Just Keeping it Simple" and saying "No" to:

complicated features (keep it simple!)
overly generic solutions (hyper-specialize instead)
building it yourself (instead of leveraging open source)
scaling too soon (start small, scale later)

Good luck teams!

Tech Talk on Visualizing Scaling

2012-02-17T00:00:00-05:00

This week's Tech Talk was on Visualizing Scaling, and Consistent Hashing techniques for scaling data.

Patrick talked through several visualizations he created in HTML5 to visually explain many common scaling techniques.

If you've heard of the techniques and algorithms: "sharding" or "master-slave", or even "consistent hashing" for distributing data across servers, but never really known how they work, this talk goes through the basics and shows visually how data can be scaled out across multiple servers.

"I never really understood some of these techniques until I saw them visually", says Patrick, who has implemented many of these techniques for Highgroove's many clients. He details the pros and cons and even how and when to start considering these techniques for scaling.

Check out the animations here on Github:

https://github.com/vanstee/distributed-data

And, be sure to check out the video on Vimeo:

Consistent Hashing Tech Talk

Interested in attending (or even presenting) at our weekly Tech Talks? Check out our upcoming Highgroove Events on Facebook.

If the Shoe Fits, Ship it!

2012-02-17T00:00:00-05:00

In January of 2012, after spending the holidays 'funemployed' (OK, just on vacation) down in sunny Florida logging some EPIC miles, I very excitedly boarded the Highgroove ROWE-boat as our first Account Director.

The month of January left me dazed but not confused. Working in a ROWE environment means results are expected immediately (and that results are all that matter). I hit the ground running and quickly found that everyone here is equally vested each project's success. That is to say, pardon the pun: "the rising tide lifts all boats" here at Highgroove. By leveraging constant communication, the best tools, pair programming, code audits, and project retrospectives -- we truly are an agile shop.

Read on to find out how I learned about what we do best, what makes us different, and what that means to me as our Account Director.

After only having been on the job not even two months, I am still new but no longer the new guy. Reading Andy's Post 2 Months in at Highgroove, I feel humbled to be listed alongside some pretty amazing colleagues here. Similar to Will's First Reactions at Highgroove, I've been good friends with several Highgroovers for years. Plus, I knew Highgroove worked on amazing projects with even more amazing clients.

What we do Best

We know that our clients benefit from constant communication with developers. Small issues are consistently caught before they become large problems. Our collaborative environment is filled with brilliant people producing refined, simple solutions in Ruby and Ruby on Rails to complicated and challenging backend software application projects. Not to mention, those brilliant people don’t have to freak out if they're running "late" into the office because of the worst traffic in the country. As Daniel points out: There is no late to the office, since work can be done (and is done) when and where it makes sense. Highgroove uses collaborative, agile tools because they lead to extremely high quality code at every stage of a project. My long time friend and resident Methodologist, Chris Kelly, emphasized this in a great post on iterations last year. Let's review:

We're Project-Manager-less. We offer clients direct Contact with developers who actually do the work. No watered down communication or confusion.
We're hyper-specialists. We're experts in backend web development in Ruby and Ruby on Rails. We know what we're good at, and stick to it.
We're ROWE. We don't care when or where work happens, all that matters is that the work gets done.
We're Agile. Highgroove walks the walk and follows all 12 Principles on ALL projects.

What makes us Different

Ok, those are neat characteristics but what REALLY makes us different? Our friends at Matchstic helped us uncover our Core Values (Attributes) at their Brand Camp. Hear it straight from the horse's mouth, as CBQ shares the camp's impact on our business.

Our Core Values are:

Personable
Optimistic
Trusting
Craftsmanship

Knowing our core values helps us not only know what shoes fit in the client department, but also how to hire, how to communicate and what firms we should partner with. I have found (like all Highgroovers) that I identified with each attribute, which is how I knew I was at the right place.

What that Means to me as our Account Director

Now back to the 'shipping'. Since we're an agile shop, one of my favorite parts about working at Highgroove is our 'Bias Towards Action'. We just Ship it! and then we iterate and ship it again until it's the best it can be. As Account Director this all means one thing: The value we offer resides in our proven process and unique brand. Our office manager Megan underscored the importance of this this process at an Agile Workshop she attended, because it supports client needs at the highest level, encourages focused development, and fundamentally promotes efficiency. And there's where the rubber meets the road and why being in the 'Highgroove' truly sets us apart. We know what shoe fits whether it means:

the right client fit for a project,
the right tools and
the right team

I am now a bona-fide member of the just 'Ship It' club, in my both my personal and work life. At Highgroove we know what fits best, we know what sets us apart, and we just 'ship it!'

Have you ever thought about what makes your company really unique?

You Must Teach To Be Taught

2012-02-14T00:00:00-05:00

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.

The purpose of a Code Retreat is to get better, to practice one's craft in a setting without the pressure of "getting it done, yesterday(tm)." Throughout the Code Retreat, we emphasize the 4 rules of simple design. Another way to paraphrase them:

Tests pass.
Good naming.
No duplication / Don't repeat yourself (DRY).
Small.

To facilitate self-improvement, we dedicate the last session of the day to the closing circle. In the closing circle, three questions are asked of every participant.

What did you learn?
What most surprised you?
What are you going to do differently going forward?

In my original blog post), I boldly claimed that one could code the Game of Life in 45 minutes if and only if they practice four or five times and skimp on tests. Oh, how wrong I was!

One pair, which included Andy, managed to write a completely functional version in 30 minutes. They even had time to invent their own spaceship. How is this even possible? Other groups took the fast and loose approach. "We know the problem domain. We have the technology. Tests? Where we're going, we don't need no stinkin' tests!"

What was the first pair's secret sauce? TESTS! GOOD NAMES! DRY! SMALL METHODS! SMALL CODE BASE! Amazing!

I learned magnitudes more facilitating than I did attending. I saw novel approaches that impressed and stretched my understanding of the problem domain. I saw good coding practices win out over the quick and dirty style again and again.

What have you learned when teaching that you didn't learn as the student?

Mailcatcher: Making email testing a breeze

2012-02-09T00:00:00-05:00

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.

Mailcatcher is written in ruby and is available as a gem. The gem's site offers detailed instructions on how to use Mailcatcher with a Rails app or even a PHP app. Without going into the details here, after you have installed Mailcatcher, you basically just set whatever is sending mail to use Mailcatcher's SMTP server. Then any emails sent by your site will be collected in Mailcatcher's webmail interface. Check it out:

Mailcatcher has really eased the pain of dealing with emails in web application development. What are some tools you have found or made that have made development more fun for you?

Red, Green, Refactor - The Tools For Success

2012-02-07T00:00:00-05:00

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.

Generally when we talk about TDD and being agile, beyond the process of choosing features to deliver the maximum customer facing value, we refer back to the simplest possible workflow of "Red/Green/Refactor." Within that workflow you write tests that fail, make them pass (with the focus on getting that done without polishing), then refactoring, to polish where necessary. The subject of testing is a huge one with a large body of prose already written on the subject. Rails Test Prescriptions and The RSpec Book are fine examples of such, along with a huge menagerie of blog posts, podcasts, and screencasts to choose from.

I propose a slightly different day-to-day workflow that I see used to great success.

Hack around and choose your course
Red - write some tests that fail but will pass when your code meets your needs
Green - the code is written, the tests pass, life is good.
Refactor - Don't Repeat Yourself (DRY your code out). Or don't, if Ya Ain't Gonna Need It (YAGNI).
Continuous Integration
PANIC OVER SECURITY
Ride Bikes

This isn't the "pure" TDD process, but one that just adds a couple of unspoken facets of the process that are already used widely, just don't fall into the pithy "Red/Green/Refactor" process.

Ruby has a functional programming feeling with its composition of methods, distinction of methods with side-effects from those that do not (via the ! suffix), and it comes with some variety of REPL via IRB (or the new awesomeness in Pry). This allows us as developers to spend some time touching code and experimenting before we decide exactly how we might like a function to operate, and thus before getting into the main development workflow for a given feature.

Tools to support step 0:

Irb - you already know about this but it's easy to overlook.
Pry - the new slickness that is 1-part Irb replacement, 1-part debugger, and a pinch (or three) of awesome. Watch the screencast to get a feel for it!
good-ole-pencil-and-paper, a whiteboard, some origami paper
whatever tool gives you a feeling for the right way to proceed without being trapped in analysis-paralysis.

Once you're ready to write some tests that will fail, you likely already have a test framework of choice, and even a workflow for running those tests. You may run them from within your editor, have a terminal window ready, willing, and able to run them with a single command (and a shortcut into your history like ctrl-R), or you may let something else automagically run them for you and report back.

At Highgroove many of us find a combination of running tests manually and automatic test running and reporting to be most useful. To accomplish this I use the testing framework selected for the project along with Spork and Guard. Spork is a test server that constantly keeps your rails code loaded and ready to be tested rather than loading each time in a rake task. Spork should be your first step to speeding up slow-running test-suites. Guard is Spork's right hand man. It watches code for changes on disk and automagically runs the correct associated tests. Guard will even notify you via Growl, Libnotify, or your other notification framework of choice that you've broken things, or that everything is still hunky-dorey and you should keep hacking away and/or ship!

When I run tests manually I often want to run a single test, or set of tests manually. Using Rspec2 you can accomplish this with tags or calling the specific spec by line number via bundle exec rspec <path to spec>:<line no. of spec to run>.

Testing is not only a matter of making your tests all turn green. Poorly written tests can certainly be green and still not indicate that your code is working as intended. Perhaps you simply forgot to include any assertions (I've certainly never done that) or you're testing your factories rather than your models (never ever once again). Code quality tools can help you with that as well, and it's not entirely certain as to whether they fit in the "Red/Green" phase of development, or in the "Refactor" phase. I like to split the playing field and say that code-coverage tools belong in the red/green phase as they allow you to check the quality of your tests which firmly live in "red/green" while other code quality tools (such as static analysis tools for cyclomatic complexity) belong in the "Refactor" phase. We've discussed code-coverage in Ruby before so have a look there for a refresher, but if you're not using one of these tools it may be time to roll it into your workflow. Cover-me even has a nice post-test HTML coverage report to show you how well you've done. This allows a very tight development loop to make sure the tests are covering the right things the first time.

Tools to support steps 1 and 2:

Testing frameworks: MiniTest, Test::Unit, Rspec, Cucumber, etc.
Spork and Guard
Coverage tools: cover_me, SimpleCov, rcov (for Ruby 1.8 apps)

So you've got good tests, good test coverage, everything is green, and you're ready to refactor. If you are struggling to start your refactoring process then either it's good enough as it is or maybe you need some inspiration. Sometimes your code just doesn't need to be refactored. It is easy to fall into the premature optimization problem and abstract/refactor/clean your way into a corner that you will undoubtedly undo later when the customer asks for more or different flexibility. So maybe just delay refactoring if there isn't an obvious need. In the case of needing some hints as to where to refactor the Rails Best Practices site has you covered.

There is no replacement for a good set of eyes on the code and intuition as to where you can refactor. To this end Highgroove's internal code reviews go a long way to getting our code refactored quickly and elegantly.

Since we are not constantly reviewing or pairing there are some tools to help us along including the excellent Flog and Flay, a pair of tools to find complex code and duplicate code, along with an interestingly macabre theme. Another tool is Excellent which produces warnings about "smelly code" via static analysis. Finally we have the big kahuna: Rails Code QA. This package wraps up other code quality packages (including Flog and Flay) to make a single rake task that does it all.

Tools to support step 3:

At this point you have your local code automatically being tested, you've run the tests you need to focus on, you've refactored with the help of tools, the rest of your development team, and the community's collective knowledge. If you are working on a feature branch, that branch needs to be merged into a staging or production branch, and hopefully tested before being pushed to client or customer facing environments. This is where Continuous Integration (CI) comes in.

A CI environment is constantly running all of your tests on whatever branches it needs to in order to make sure that any merge artifacts don't make their way into production. You may choose to run your own CI environment via Jenkins or Goldberg, both of which are lightweight and well supported, or you may choose to "outsource" your CI to a service. Travis-CI has gotten a large following in the Ruby community thanks to its super simple setup, integration with Github, and quality service. I was recently introduced to Tddium by a co-worker while struggling to setup an internal CI system for a customer. It looks very well backed and supports pretty much all of the services we employ day to day. If you don't want to do operations to make sure your CI is up and running then looking to one of the latter services is a great route.

Tools to support step 4:

Local CI tools: Jenkins, Goldberg
Hosted services: Travis-CI, Tddium

Great! Your code is tested locally and in CI, everything looks solid in terms of functionality, and Rails automagically does everything right for security. It's time to go ride bikes right? Well maybe not. There is a comprehensive and excellent Rails Security Guide because it's not so simple. This isn't to say that Rails security is as hard as it could be, but as with everything getting it right requires knowing and following the best practices created by the community.

Luckily for us the Brakeman Scanner project integrates beautifully with the tight testing workflow described above. Brakeman is a static-analysis based security-focussed scanner aimed at Rails applications. It is under active development and the progress has been phenomenal. We did a brief tech-talk about it recently and to say we are enamoured of it may be an understatement. Even a couple of the bugs described in the tech-talk have been fixed since then! Combining Brakeman's fantastic scanner and our automated testing tools works out of the box in two ways. Firstly there's Brakeman's reporting which is excellent and could certainly be wrapped in a rake task to create a cover_me style report after each test run. Secondly there is guard-brakeman for local-scanning and testing as well as notifications via your system notifier when new security issues are introduced, just as if a test failed. For CI environments Brakeman works with Jenkins out of the box and adding support to other CI environments should be a fairly simple operation.

Tools to support step 5:

Brakeman, Guard-Brakeman

Making your development and testing loop as tight as possible allows you to have confidence that your code has been written in a process that promotes testing, coverage, and automated quality tests so that you can focus on what's important: shipping code and riding bikes.

Tools to support step 6:

Kumbaya, My Award

2012-01-31T00:00:00-05:00

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 Highgroove Award iPhone App was born as a recent weekend hack project.... And refined on a recent hack night.

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!.

Great Office Rearrangement: Sit where you want

2012-01-27T00:00:00-05:00

At Highgroove we are are always trying out new ways to improve our process and environment. One of my favorite experiments has been doing away with assigned seats. Our Results Only Work Environment allows each person to decide when and where they do their work. While it is true no one is required to come into the office, the reality is many people prefer to be in the office. It is not hard to see why. Every member of the team gets a massive monitor, a super comfy Aeron chair, and all the espresso and snacks anyone could ever need. Although most people come into the office regularly, each team member's hours can vary wildly. When we had assigned seats you could come in the office and be isolated just because your neighbors on a different schedule. Conversely, you could come in and be surrounded by a couple developers talking out a difficult problem when you really need to get something else done. In short, assigned seats just aren't very ROWE.

The Setup

The fact that we hyper-specialize in back-end Ruby development means that everyone uses the same equipment and has basically the same needs. While this made doing away with assigned seats much easier than it would have been for a firm where there are many different types of specialized workers, we still had some issues to work out. First we had to deal with everyone's "desk stuff". If you have worked at a place with assigned seats you have probably noticed that you and your co-workers tend to "nest", building up a collection of trinkets, tools, and other things that may or may not be needed to get the job done. The amount of "desk stuff" has always been limited at Highgroove by small desks. Our work is done in the cloud using tools like Google Apps, Pivotal Tracker and Github. We generally don't need desk space for much more than a keyboard, mouse, snacks and maybe a latte. If the desk is holding much else, chances are that stuff is in the wrong place. If the "desk stuff" is information you or your team members need and exist nowhere else, you are working in a silo. That is bad. If the "desk stuff" is something not related your current tasks, it is clutter: a distraction at best, it should be elsewhere. Where do we put all this stuff? We have a cubby section where each developer can safely store their stuff like bike clothes, business cards, notebooks, and other things we use but don't need constantly to do our work. We also use cubbies to store our keyboards and mice when we leave, so that others can use the vacant desks.

Cubbies were about the only addition we needed to make this work. We provide everyone on the team with the best equipment available, so there is no inequality; no good desk or chairs to fight over. If you were implement this policy in an office where there were several different types of desks and chairs you would want to make sure there are enough setups of each type to make everyone happy.

The Results

We've been running this experiment for several months now. The no assigned seats policy allows everyone the chance to switch things up and get to know each other better. The policy also allows team members to have more control over their environment. When there are a lot of people in the office, desk selection can be slim, but so far no one has been without a desk, or has vocally complained about having to sit at a desk they don't want to. Some people still sit in the same desk everyday. Other people sit at a different desk every time they come into the office. The point of ROWE is that we are all responsible adults, perfectly capable of making our own decisions. We decide when it is time to work and time to play. The next logical step was to remove assigned seating for those who decide to work in our office. Doing so has given each member of our team the more control over their work environment, and has also made for a more open and collaborative workplace. What steps have your team taken to make your office more awesome for everyone?

Tech Talk on Brakeman

2012-01-27T00:00:00-05:00

Dave's Tech Talk this week is on security on web applications, focusing on Ruby on Rails applications, and using the static analysis security scanner called Brakeman (brakeman on github).

In this talk, Dave looks at how static security analyzers work, and how we used it to find some very tiny (already fixed within a few minutes of finding) possible security weak-points in an application we built for a client.

Static analysis looks at your source code and looks for known vulnerabilities. As opposed to dynamic scanners, or intrusion "detection" scanners that scan a live site from the outside -- these are run on the code itself.

In Ruby this is hard because it's a dynamic language. Because of this, Brakeman (and any static analysis scanners) will identify "false positives" (code that isn't necessarily a vulnerability) but they're easy to track down, and safely ignore.

Dave notes, that because of Ruby's dynamic-ness, if you are doing a lot of method_missing meta-programming, it won't be able to analyze your code. The practices and places it does identify are easy to see, and you can apply Brakeman's other recommendations in your meta-programming code, to secure your web application.

Check out the talk on Vimeo: Tech Talk on Brakeman

Image Credit: fishywang on Flickr

Hack Night at Highgroove

2012-01-26T00:00:00-05:00

Highgroove hosted our monthly Hack Night, and with 20 attendees, this was our largest yet.

To program a computer in a clever, virtuosic, and wizardly manner. Ordinary computer jockeys merely write programs; hacking is the domain of digital poets. Hacking is a subtle and arguably mystical art, equal parts wit and technical ability, that is rarely appreciated by non-hackers. See hacker. -- Urban Dictionary: hack

Hack Nights are a chance for Highgroovers to simply "hack" which means: to experiment, learn, and play with technologies we might not get to during our day-to-day. So, what did we hack on?

the io language using Day 1 of the io chapter in the Seven Languages in Seven Weeks book
game programming (the wolfbrain) on the Sifteo Game Cubes in C#
a remote music playing server with voting and control from our chat room for the office
adding functionality to some of our favorite ruby gems and libraries including brakeman, and a yet-unreleased crazy-math backend algorithm solver
an iOS app for awarding Highgroovers the coveted Highgroove Award
a search-across-the-company app using some new search technologies powered by Ruby
and much, much more....

Thanks to all who came out. Stay tuned for our next Hack Night in February by liking us on Facebook and Twitter.

Maintaining Clients (keeping everyone happy)

2012-01-24T00:00:00-05:00

Far too often there exists a chasm between the client paying for and the developer working on a particular project. One party has a longterm vision; a vision that will ultimately impact his/her financial future. The other party has a much closer view of the project, which creates the risk of getting tunnel visioned. The client worries about when the project will be completed; the developer worries about how the project will be completed. When this happens, communication becomes difficult and frustration builds. How can this be avoided?

At Highgroove, we know that there is no replacement for good communication. This perhaps requires a bit more work from our clients than they might initially anticipate, but by maintaining frequent contact, we prevent frustration and confusion from creeping into the process. By keeping our clients actively involved (i.e. forcing them to accept/reject stories in Pivotal Tracker), they know exactly where the project stands and what work remains. This helps the project stay on track and gives us, the developers, quick feedback about whether or not the work being done is acceptable.

When we are able to maintain this level of communication with our clients, we can develop a comfortable working relationship that allows us to honestly question features or approaches that would complicate projects and potentially delay launching. At Highgroove, we earnestly want our clients' projects to succeed. We hope that our clients choose us not for only our technical skill, but our dedication to giving them the best version of their vision. By striving to cultivate a successful working relationship, we go beyond maintaining happy clients: we promote successful enterprises.

Tech Talk on Riak

2012-01-20T00:00:00-05:00

Will's Tech Talk this week is on Riak. "Riak is an open source, highly scalable, fault-tolerant distributed database." -- Riak Overview on Basho.com.

The main use-case is to use in web applications that have heavy requirements for data, where lots of data must be "written" or "read" in a distributed fashion, but needs to be high-availability.

Will also went over one of the main Ruby libraries named ripple that is a rich Ruby modeling layer for Riak, Basho's distributed database that contains an ActiveModel-based document abstraction.

Riak works great when your database gets painful. If you have an application that just has tons of writes, or tons of reads happening, and the database is just dragging, Riak is a great choice for storing and reading data quickly. Adding Riak along-side your database to alleviate performance is a great way to scale out and make your web application more performant.

Check out the video on our Tech Talks page: http://vimeo.com/highgroove/videos

Git Treeishes Considered Awesome

2012-01-19T00:00:00-05:00

As developers, we love having quality tools like git, available to us.

Using git, we can easily navigate through all the code ever "committed" or added to a project throughout its history. We do this via git treeishes. Treeishes are git's way of referencing commits and relations between commits. Treeishes can improve your workflow immensely if you're a frequent git user.

In this post, we'll cover some of the more basic treeishes and then work into the advanced ones, with some real-world examples.

The Basics

You'll probably be familiar with the types of treeishes in this first section if you've ever used git before. The following section will cover some more advanced uses of treeishes that even long-time git users may not know about.

SHAs

Every commit in git is identified by its SHA — a unique hash. These hashes are pretty long (40 characters in fact), but git also allows you to reference any commit with any truncated version of its hash so long as the truncated portion is unique (generally, this means at least 5 characters long).

Branches, Remotes, and Tags

Branches, remotes, and tags are another kind of treeish. Each of these is actually just a pointer to a git commit.

Advanced Treeishes

Now we're getting to the really good stuff!

It's important to have a good understand of the git reference log (reflog for short) which enables most of the more advanced treeishes.

The git reflog is a running log of recent changes to tips of branches. In practice, this means that every time you commit to a branch, pull commits down from a remote repository, or checkout a new branch, your reflog will update. It's important to recall that reflogs are specific to individual checkouts of a repository so the reflogs for the same project can differ across machines.

Here's an example reflog from one of my personal projects:

› git reflog 0a4faaa HEAD@{0}: checkout: moving from 0a4faaaf0081e2a5e439e79f48e236cdfbcb687b to i-herd-u-liek-chef 0a4faaa HEAD@{1}: commit: Remove unnecessary comment. d4fdbdb HEAD@{2}: commit: Real namespaces in the app code now. fc16081 HEAD@{3}: commit: Suddenly, NAMESPACES b36e3a8 HEAD@{4}: clone: from git@github.com:wfarr/censored.git

This reflog shows that some of the more recent changes to this project include:

Cloning the project from the remote repository
Making a few commits
Checking out a new branch from the tree at 0a4faaa (which just happens to be master)

Using the reflog, git can infer some interesting relative context for commits that will allow us some more flexibility in what we can get at with treeishes.

Date Specs

We use the date spec here at Highgroove as part of our weekly code reviews. With the date spec, I can easily look at the activity on a feature branch over the course of the last week:

Tilde Spec

Similar to the ordinal spec, the tilde spec allows you to reference the Nth grandparent of a commit.

This is useful just to go back 2 or more commits in time in one command.

Caret Parent Spec

Unlike the tilde spec, the caret parent spec allows you to reference the Nth parent of a commit. The distinction here is important as the caret parent spec can walk backwards through commits that have more than one parent (merge commits), while the ordinal spec cannot.

The caret parent spec looks like:

The caret parent spec and the tilde spec can also be chained together, so master^^ would actually point to the same commit as master~2.

Range Spec

The range spec allows you to express a range of commits as a first-class object in git. These are frequently used for things like diffs where you may want to view the changes across a number of commits.

For example, the following command would show a diff of all commits between master and my current feature branch:

You can also refer to the range from the current commit through all commits after it by just leaving off the other ref after the "..".

All of these treeishes are available from the git command line interface -- though if you're using a GUI to interact with git your particular application it may support some or all of these. I know that Github's compare view can be used with treeishes as well. Hopefully if you're not already using treeishes you'll find that they're as useful to you as they are to us.

How are you using git treeishes to improve your workflow?

Image credit: @moonlightbulb

Simple Design, the Highgroove Way

2012-01-16T00:00:00-05:00

Highgroove Studios has taught me a lot about Software Development, Consulting, and building new web applications. Apart from the myriad of technical skills I've added since I came on board, Highgroove is a fantastic company to learn how to build your own web apps, how to design them, and how to remain focused on the most business critical aspects of the system. Highgroove taught me these things by adhering to a process which manages Agile development, responds to changing software requirements and business needs, and encourages constant communication. While these are all noticed by clients, there is one part of the Highgroove process that goes largely unseen; however, it is just as integral as the former three. That behind-the-scenes aspect of the Highgroove development process is keeping the software as simple as possible to meet current demands.

Keeping software systems simple is fundamental to the development style at Highgroove. What I've seen a lot of developers do (not the Highgroove developers of course!) is create an application that is too complex for the current applications scope, which wastes precious time in the process. The unfortunate side effect of creating apps that are too complex for what is actually needed is ultimately an app that performs poorly under load, is prone to errors, and is very difficult to change. All of those things affect a projects budget and could have been avoided. At Highgroove, we leverage the Open Source community and Ruby on Rails to build scalable web applications. This web application development framework comes with a core set of plugins but also enjoys a host of plugins and libraries all available for free. We don't write custom loggers. We don't write google apps or Facebook authentication from scratch. We hardly even have to write SQL. We leverage the network of freely available, well tested and trusted plugin library to accomplish these basic tasks for us. Once the common system functions are handled, that allows Highgroove to focus solely on business logic and building the app. That really means we get more done, in less time, and on budget too!

At Highgroove, we do not believe in creating Rube Goldberg machines…we just want to build the best possible app with the least amount of complexity that does exactly what you need. Its because of this ethos that Highgroove's customers succeed (and I grow as a developer and a consultant too!).

How do you build apps?

Image Credit: Wikipedia

Getting into the Groove

2012-01-16T00:00:00-05:00

Going in to my third week here at Highgroove, I already feel like my first couple weeks have been some of my best in any work environment, both in terms of my personal productivity and my happiness at work.

I'm still completing my undergraduate degree at Georgia Tech. As any student at Tech will be quick to tell you, the school is often very demanding of its students. This can often make a good balance between work and school difficult, and juggling the two over the past couple years of school has been challening.

Enter Highgroove, a ROWE (Results-Only Work Environment).

I've been lucky enough to call a good portion of the Highgroove staff friends for a while, and I'd known that Highgroove works on amazing projects with even more amazing clients. This was more than enough to get me excited to work with Highgroove. But hearing more about how Highgroove is a ROWE during my interview process really interested me.

A ROWE sounds pretty self-explanatory — it's all about results. Focusing on results rather than time spent "working" (who hasn't checked on Reddit at work before?), allows us to work in a fashion that's all about personal responsibility and trust. I can take a day to study for a big exam if I know I'll have some time later on in the iteration to make sure I'm hitting my results. Reading the ROWE book (ironically, the one requirement we have at Highgroove besides meeting results) and working in a ROWE has already taught me a lot: mostly I don't think I could go back to working any other way.

Highgroove gives me control over my time and allows me to focus on getting things done — whether for work, school, or me — in a completely guilt-free environment. And I'm loving every minute of it.

Using MySQL Spatial Extensions for Range Queries

2012-01-10T00:00:00-05:00

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:

ALTER TABLE ip_ranges add ip_range POLYGON NULL; UPDATE ip_ranges SET ip_range=Polygon( LineString( Point(ip_start, 1), Point(ip_start, 0), Point(ip_end, 0), Point(ip_end, 1), Point(ip_start, 1) ) ); ALTER TABLE ip_ranges MODIFY ip_range POLYGON NOT NULL; CREATE SPATIAL INDEX index_ip_ranges_on_ip_range on ip_ranges (ip_range);

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

SELECT * FROM ip_ranges WHERE Intersects(ip_range, Polygon( LineString( Point(@new_ip_start, 1), Point(@new_ip_start, 0), Point(@new_ip_end, 0), Point(@new_ip_end, 1), Point(@new_ip_start, 1) ) ) );

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?

Hadoop Across Availability Zones

2012-01-10T00:00:00-05:00

Hadoop is a great solution to the big data problem and with the instant access to servers and storage in the cloud, it's easier than ever to spin up and manage your own cluster. If you haven't heard too much about it yet, hadoop provides access to a distributed file system along with a framework for running map reduce jobs over the data. It takes care of replicating chunks of data to each node and running jobs in parallel for you. However, when you want to expand your hadoop cluster across availability zones you can run into some unexpected problems. So lets dig into the ideas we tried and the final solution that worked the best for our configuration.

Communicating across data centers is a pretty old problem with a lot of different solutions so we wanted to start out with the simplest thing we could think of. First, we decided to allow access by adding an elastic ip to each node and adding those addresses in the security group of the opposite availability zone. So this would basically just allow open communication from certain public addresses on the internet, which isn't a bad solution. But if you ever need to replace or spin up a new node, it requires a decent bit of manual intervention to reassign the elastic ip or to create a new one and add it back to the security groups. Another downside is that, due to hadoop's fancy hostname resolution, we can only utilize tasktrackers within the same availability zone as the namenode.

So next we tried using OpenVPN to create a bridge across the two networks, but there was one small problem. Because we didn't have full control over what ip address our servers were assigned, there was the potential for two machines with the same ip on separate networks which would cause all kinds of weird problems. Amazon's VPC can help solve this problem by giving you more control over the network but we decided to go a different route.

Instead of using a classic VPN solution, we gave tinc a try. Tinc is still considered a vpn daemon but instead of using it for a point to point connection, because it is so lightweight, you can install it on all of your servers and expose a new network interface to route traffic over. This allowed us to easily configure the vpn on the production system and then just switch the interface hadoop was listening on once everything was up and running. So here's how we set it up.

Three files make up the basic configuration. The tinc-up script is responsible for creating the new network interface. The tinc.conf names the local node and keeps track of all the other nodes it needs to talk to. We also need a hosts file which is named after the local node we set in the tinc.conf. This file includes attributes for setting up the connection to the vpn like the external ip, vpn ip, vpn subnet and public key. Since we have everything already set up in chef we just set up a cookbook that ran a few searches across our servers and generated all the configuration files we needed. We also took advantage of hadoop's rack awareness feature to make sure data is always streamed from the closest node and also makes sure replicas are spread across different data centers. There was only 1 problem that we came across which again involved hadoop's hostname resolution. Map reduce jobs were periodically failing because the tasktracker would sometimes use the ec2 hostname and resolve the ip of a datanode incorrectly. So, we had to setup a tiny dns server to make sure that hostnames always pointed to correct tinc address. After fixing that everything worked great. We also had the added benefit of being able to connect through the vpn and access the files from hdfs directly using hue.

Since we quickly covered a lot of new technology, here are some useful resources for when you want to try this out yourself:

What other tips do you have on breaking the single availability zone barrier?

Tech Talk on RescueTime

2012-01-06T00:00:00-05:00

Stafford is talking about productivity hacking with RescueTime. "It's like server analytics for you and your time," says Stafford.

We all like to think of ourselves as productive, but we can all use some help being more efficient. One tool Stafford likes using is RescueTime that tracks where you're spending your time while using your computer.

RescueTime runs in the background, and tracks applications that are open. It then tries to help you classify which applications are productive and which are non-productive. It can show you how much time you're spending browsing Facebook, versus writing code. You can even help it learn which tasks for you are more productive -- for some people, email is productive, for others, maybe not.

There are some very cool charts that show where time is spent, in your browser, in your code editor, in your email client, etc. It can show you when you're most productive, just by knowing. It also has a competition aspect, you can see how your productivity numbers stack against others, and even yourself each week.

Stafford goes in once a day to clean up his RescueTime and reclassify events like: "Chatting" which may be with a client, or with a friend.

Stafford also showed off the project view, which helps him realize what tasks he's worked on for a client/project.

Stafford ended saying: "It's a good gauge of when I'm being productive. If I'm not being productive, it's time to leave and get away, go do something else, and come back when I'm productive to work."

Check out the video on our Vimeo channel, in our Tech Talks.