The Value of Reading Code

Posted in Code, Open Source Comments

skalnik

26

Jul

Here at Highgroove, we do code reviews, which ensures everyone is reading some code on a regular basis. However, being a developer usually means you'll be reading code regularly anyway. In the past, I used to avoid this if I could. However, now I've learned how much I can get from it, and use it to improve myself as a developer.

Reading code isn't easy, and I certainly didn't want to do it when my only goal was figuring out why a gem wasn't doing what it promised. It was much easier to just find someone familiar with it and pick their brain. However, there's more to be gained from reading source code than you may think.

Read more...

The Exit Interview

Posted in Business Comments

CBQ

19

Jul

We’ve got an amazing team of personable, optimistic, trusting, true-craftsmen developers (and a whip-smart office manager) at Highgroove.

We’d love to keep everyone on the team happy, productive, and with us for a long, long time. However, we realize that even our team of A-players may become ready to move on to different opportunities. We have alumni from Highgroove at some of the coolest companies in the world: Scout, Twitter, Github, and Scoutmob to name a few.

When it’s time for a Highgroover to move on, we have an awesome Exit Interview we give.

Read more...

Convince Me to Work in the Office

Posted in ROWE, Atlanta Comments

Patrick

12

Jul

Working for a company that embraces ROWE is great. If you’ve been following our blog, you’ve probably read about how we can work on our own schedule or work from where ever we want as long as we meet results. But, there’s also a more subtle advantage. Since working from the office is no longer mandatory, there is an added incentive for Highgroove to make the office somewhere we actually want to work, which translates directly into some awesome perks as an employee.

Everyone gets comfy Aeron chairs and their own workstation from day one. There was no “new guy” hazing period where I had to work in the back corner with a broken folding chair. I usually drive in to work just to dock my MacBook and use an extra 23” of screen space. We also keep the kitchen fully stocked with Clif bars and Arden’s Garden drinks. Not to mention we have a commercial grade espresso machine for the perfect coffee break.

The environment is great here too. We share an open room with half walls so we’re all available to quickly help debug a failing test or to discuss big infrastructure decisions. There’s always some music playing in the background from our turntable.fm room and there’s no problem with taking a quick break to watch a clip from Endhrian the Indian Terminator.

When you’re focused on results only, you should work hard when you feel the most productive but take a break when you’re just not in the zone. And it’s great to have a workplace that really caters to that idea. Some of our clients actually work out of our office because they like it so much. We even have a Highgroove Alum that decided to come back and work with us this week. And if you really don’t believe us, stop in and check it out! CBQ will even make you a tasty latte.

Optimistic Locking with MongoDB

Comments

Andy

06

Jul

At Highgroove, we build database-backed web applications. These days, there are many options when choosing a database backend. We normally start with relational database systems (e.g., PostgreSQL and MySQL) because they are very mature and feature niceties like ACID transactions and locks.

On the other hand, we also work with newer NoSQL database systems that often trade features like transactions, locks, and joins for higher performance and scalability. One popular option is a document-based store called MongoDB. By design, MongoDB does not support ACID transactions (though many operations are atomic) or traditional locks.

In many cases MongoDB, paired with an object-relational mapper like mongo_mapper is a great solution for Ruby and Rails applications. And after the break I explore a solution that allows a developer to “lock” a MongoDB document while still maintaining the high performance and other features MongoDB is known for.

Read more...

A SQL Pattern in Rails

Posted in Code, Keeping it Simple, HowTo, Atlanta, Ruby on Rails Comments

Jonathan

28

Jun

ActiveRecord is wonderful for the easy queries. But there are times, in the name of performance, when one must bust through the ORM facade and dip below into SQL.

Edit: Updated gist to fix SQL injection. Thanks to all the code reviewers, uh I mean commenters, for pointing it out!

Also pointed out in the comments, using lambdas in this pattern makes most sense for Rails 2. In Rails 3, AREL is composable so one can use class methods.

Wed Jun 29 13:55:27 EDT 2011

Read more...

RSpec Tip: let and nested describe/context blocks

Comments

Andy

21

Jun

At Highgroove, we test our code extensively. The best testing code has solid coverage, yet also shares many of the qualities of well-written code in general, such as readability and lack of repetition.

The popular testing framework RSpec ships with constructs that aid in writing elegant testing code. One advanced technique to keep things DRY is shown after the break.

Read more...

The Impact of Performance Tools on Performance -OR- Use Your Environments!

Comments

chris

13

Jun

Using different ‘environments’ in Ruby on Rails development is an established best practice. Rails provides you with 3 default ones: Production, Development, and Test, and at Highgroove we like to add a ‘Staging’ environment as well. Heroku supports multiple environments, and they make life a lot easier when building applications.

In the production environment, some things are cached by default, while in the development environment, things are loaded whenever they are changed which makes working on a project a lot easier because you don’t have to restart the server to see your changes. A staging environment lets you ensure that your staging system and production system stick to their own databases and API services without requiring any server customizations other than setting RAILS_ENV.

This all sounds great, but if you’re not careful early on it can lead to some intersting problems!

Read more...

First Month Down

Posted in ROWE Comments

drice

08

Jun

I am coming up on my first month at Highgroove and I am loving it. Free espresso is a pretty quick way to get on my good side! In all seriousness though, I am 100% glad to be here and surrounded by expert Ruby and Ruby on Rails developers and open source contributors.

So the obvious question is “What is so great about Highgroove?” Its pretty easy: I can do whatever I want, whenever I want, and its no big deal. I don’t have to frantically call CBQ if I’m running late because of the renowned Atlanta traffic. There is no late. I don’t have to ask to work remotely. There are no mandatory office hours. Its absolute freedom, which was something I didn’t really have at my other jobs.

This works because Highgroove is a bonafide Results Only Work Environment . What this means is that employees are held accountable only for getting their jobs done. That’s it! It sounds like most companies would already do this, but you would be wrong. Have you tried to go home at 3 before and not had to slip out the fire escape, avoiding all eye contact along the way praying your supervisor doesn’t pop around the corner? I certainly have.

Simply said, Highgroove is a breath of fresh air and I am looking forward to what the months ahead have to offer!

How “Results Only” is your office? Can you work from home whenever you want? Could you hop on a flight to NYC and work at Starbucks all week if you wanted to, while getting in some sightseeing along the way?

Deploy Code Your First Day

Posted in Business, ROWE Comments

Patrick

07

Jun

- SMASH Rocket Club 5-9-09 4 by stevendepolo, on Flickr"> - SMASH Rocket Club 5-9-09 4" align="right">

What do new hires at a software development shop typically do on the first day? They probably read through documentation, checkout some code, and maybe make some commits on a project. At some of the more progressive companies, new employees might even get to push changes to a live production server. At Highgroove, in my first week, I learned that we follow the philosophy of “Bias Towards Action” and actually “Deploy Code on the First Day.” It’s simply the best way to bring people up to speed and make sure they are comfortable deploying and delivering working software.

Read more...

Customer Service for Consultants

Posted in Business Comments

Brandon

31

May

At Highgroove, we value customer service along with programming. Our customers arrive at our shop with concerns needing attention. Here are a few common ones:

• They are new to software development
• They have a fixed budget
• They have a defined time frame
• They need help on an existing project which is in trouble
• They need assurance we will be available after the project is complete

It helps us to imagine questions our customer might have:

• Am I choosing the right team to bring my project to life?
• Will my budget be spent wisely?
• Will my project be done on time?
• Can these consultants succeed where others have not?
• Who will I call when I find a bug, or need a new feature?

Staying mindful of our customers allows us to deliver better service. Here are some techniques we recommend:

• Use your customer’s terminology. It might feel good to ramble on in code-speak in front of a customer, but resist the urge or stop yourself short if you catch yourself doing this. Customers who are new to software development are better served if you stick to the terminology of their domain, rather than indulging in yours.

• Always deliver working software. Customers on a fixed budget are stranded if you’re halfway done with bunch of features but you’ve blown the budget. Break features down into small stories which can be accurately estimated. Then, commit and deploy these completed stories early and often, steadily delivering value.

• Be brutally honest when estimating time. This is personally a tough one for me. Resist the urge to be an overly optimistic Superman. Customers take your word when you give estimates. Make sure that your features will be ready for the demo they’ve scheduled.

• Know when to say no. Many projects are in trouble because they’re lacking constraint. Customers with a troubled project are likely in need of a fresh set of eyes to trim the fat and ship a working product, rather than a perfect one.

• Establish a relationship. Some consultants are passionate about programming at the expense of customer service. They can be overly defensive when times get rough, even abandoning projects and burning bridges. Customers are best served by consultants who keep a cool head and guide a project to completion. When a project is complete, the bumps in the road become memories, and a satisfied customer provides new projects and enthusiastic referrals.

What techniques do you use to deliver better service to your customers?