I’m excited to announce that we are teaming up with Mailchimp and Mandrill to hold a Coderetreat on June 29th at our Krog Street office in Atlanta.

A Coderetreat is a daylong event where a small group of developers meet up to focus on improving their software design and development skills. It is an intense day of coding where we get to pair program with others, learn new problem-solving techniques and focus 100% on doing it right.

The event is free and is open to all software developers who are interested improving their software design and development skills. Participants will pair with each other during six sessions that will each focus on different aspects of crafting outstanding code.

If you are interested in attending, you can register here. There is a $10 deposit required to reserve your spot, which will be refunded when you sign in at the event. The event starts at 9:30 a.m. and will finish up around 6 p.m. Lunch and other refreshments will be provided, thanks to our co-sponsors, Mailchimp and Mandrill.

The post June 29th Coderetreat open for registration appeared first on Big Nerd Ranch.

There are many options for Ruby on Rails hosting, but Heroku is one that we recommend to clients and use internally for Ruby on Rails applications. Using Heroku? There are steps you can take to get more performance out of your Heroku application.

Measure

To optimize your application, you first need to measure your application’s performance. There are many ways to do this, including Heroku’s New Relic add-on. If you don’t worry about any other metric, you should at least be concerned with the average response time for your application.

You want this number to be as low as possible. You can monitor this number to see how changes to your code affect the responsiveness of your application. You can also use this number to figure out how many dynos your application will need for a given load.

First, we will need to know how many requests a dyno can serve in a second.

    requests_per_second_per_dyno = 1000 / average_response_time_in_milliseconds

Knowing the number of requests per second that a dyno can handle will allow you to figure out how many dynos you will need in order to handle a certain level of traffic. Suppose you know from New Relic that your site gets about 20,300 requests per minute and your average response time is 243 ms.

Doing the math:

    requests_per_second_per_dyno = 1000 / 243   # ~4.12 requests per second per dyno
    requests_per_minute_per_dyno = 4.12 * 60    # 247.2 requests per minute per dyno
    dynos_needed = 20,300 / 247.2               # 82.12... dynos

So if you want to handle 20,300 requests per minute, you’re going to need at least 82 dynos.

But let’s say you want to handle twice as many requests in a minute. You wouldn’t be able to solve this problem simply by adding more dynos, because Heroku currently limits you to 100 dynos for a web worker. Instead, you have to reduce the average response time of your application. If you could cut this number down to 123 ms per request from 243 ms per request, you’d have doubled your capacity without adding any more dynos.

So how do you decrease response times? Common methods include:

• Cache views when possible.

• Move long-running tasks to a background worker such as Sidekiq, Resque or DelayedJob.

• Add database indexes for slow queries where possible.

However, at some point it will become very hard to shave milliseconds off this number and you may wonder what else you can do (besides leaving Heroku).

Enter Unicorn

The Unicorn HTTP server can help you increase the number of requests per second that a dyno can handle. Unicorn allows you to have multiple workers processing requests on one dyno.

How many workers can one dyno have? It depends on the memory usage of your application. To figure out how many workers your dyno can handle, you need to know how much memory a single worker uses. New Relic’s dyno graph will show you this number. Keep in mind that your dyno is limited to 512 MB of memory, so to make use of two workers, your average memory usage for a dyno would need to be at or below 250 MB. The lower your application’s memory usage, the more workers a dyno can handle. If your application can handle 600 requests per minute with one Unicorn worker, it can handle 1200 requests per minute with two workers, 1800 with three workers, and so on.

Increasing the number of Unicorn workers rather than the dynos allows you to mitigate some of the pains associated with random routing, because you’re increasing the chance of routing the request to a free worker.

When configuring Unicorn for Heroku, there are a couple of values you want to pay special attention to:

• worker_processes – This tells Unicorn how many workers you want to run per dyno. Use your average memory usage per dyno to figure out what number is best for you. If this number is 1, consider using something else besides Unicorn.

• timeout – Heroku times out requests at 30 seconds. This number should be 30 at the maximum. If you don’t want your application waiting 30 seconds to timeout a long-running request, you could set this number even lower.

• preload_app – Set this to true. If you are using ActiveRecord, you will want to call ActiveRecord::Base.connection.disconnect! in the before_fork block and ActiveRecord::Base.establish_connection in the after_fork block. This will insure that the application is preloaded before it is forked.

• listen – listen takes a port and a configuration hash. One of the options is backlog. This number defaults to 1024. The documentation states:

“If you are running Unicorn on multiple machines, lowering this number can help your load balancer detect when a machine is overloaded and give requests to a different machine.”

This is exactly the case with Heroku. You will need to experiment with this number to see what works best for your application, but we have gotten good results by setting this number in the single digits. If you are using the default setting for the backlog, one slow request could potentially affect more than 1,000 requests lined up in the worker’s queue.

Conclusion

If you’re looking for ways to improve your application’s performance on Heroku, first make sure you are measuring performance and looking for ways to optimize your application. If your application’s memory footprint allows, consider using Unicorn to double, triple or maybe even quadruple the number of requests your web dynos can handle. If you decide to give Unicorn a try, be sure to dig in to the tuning docs so you are sure your unicorns are tuned to 11.

The post How to Improve Rails Application Performance on Heroku appeared first on Big Nerd Ranch.

The Global Day of Code Retreat is a daylong event where developers from around the world gather in small groups to practice their craft. It’s an intense day of coding where we get to pair program with others, learn new skills and focus 100% on doing it right.

Already sold? Sign up here to join us on December 8, or keep reading below to find out more–but read fast, because these events fill up quickly.

While code retreats happen throughout the year, the Global Day of Code Retreat is special because developers all over the world are hosting and attending the events on the same day. To learn more about code retreats, check out this post I wrote after attending one earlier this year.

This year’s Global Day of Code Retreat takes place December 8, from 8:30 a.m. to approximately 5 p.m. The event is free, but a $10 deposit is required. Your deposit will be refunded at the conclusion of the event.

Lunch and other refreshments will be provided, thanks to our sponsors: Big Nerd Ranch, Mandrill and Pardot.

The post 2012 Global Day of Code Retreat appeared first on Big Nerd Ranch.

About a year ago, I convinced our Charles Brian Quinn to take a chance on me. While I had nearly 10 years of experience in developing, deploying and maintaining web applications, I had no Ruby experience, no Rails experience and not one piece of paper certifying me of having any knowledge about computers in general. Despite all these deficiencies, I had done my homework; I knew beyond a shadow of a doubt that Highgroove was the place where I needed to be working.

Our hiring process is challenging, and not many people get through. It can also take a while to get a response, because our hiring mentality is “hire slow, fire fast.” Hiring slowly is a good thing: It helps us make sure that we hire the right person for the job, without relying on a “gut instinct” or rushing to fill a seat.

Needless to say, my story had a happy ending, and now it that I’ve been here for a year, I want to take a look at how being a Highgroover has changed my life.

My Colleagues

This is listed first because it’s the number one reason I wanted to work at Highgroove. Highgroovers not only contribute to some of the most important open-source projects (Rails, Brakeman, will_paginate) in the world, but they’re also extremely personable and passionate about sharing their knowledge with others.

I have certainly worked with some great developers at my past jobs, but these were much smaller teams. At best, I had five developers working with me at a company of about 25 employees. However, at Highgroove, we have 20 developers, which is the majority of the company.

I have the privilege to work with, learn from and teach 19 amazing developers. Working with this group of peers has been by far the biggest change in my life in the past year. I have gained new friends, I have grown so much, and every day I look forward to interacting with an awesome team.

My Environment

Many of our blog posts point out that we’re a Results-Only Work Environment (ROWE). To me, the point of working in a ROWE isn’t working from the beach, being able to take care of emergencies when you need to, or whatever other time-space thing you usually hear about when people are talking about ROWE. The best think about working in a ROWE is that it creates an environment of trust. Responsibilities and results are clearly defined. No one is “managed.”

Everyone trusts that you will accomplish your results. There is no one coming around, probing you for progress reports or asking you some sort of silly question that basically boils down to, “Are you doing your job?”

On the flip side, problems do arise, and you are also trusted to raise your hand when one comes up. If you are unhappy about a process, unable to find the right solution or having trouble communicating effectively, you are trusted to make the issue known quickly, before it gets to be a bigger concern.

My Goals

I’m happy with what I have been able to accomplish this past year at Highgroove. I’ve gone from knowing almost nothing about Ruby to building and launching the two largest and most complex web applications I have ever created. Along the way, I gave a lightning talk at Ruby Hoe-Down, presented Tech Talks and made open-source contributions to OmniAuth, Compass and Mailchimp’s Uakari gem.

But there’s always room for growth, and now I’m aiming even higher. In my coming year at Highgroove, I plan to host regular code retreats, step up the frequency of my open-source contributions and help Highgroove with its marketing efforts, while making progress on my journey to become the best software developer I can be.

How has your professional development changed in the past year? What goals have you set for yourself in order to ensure that you are constantly improving?

The post The Highgroove Experiment: A one-year retrospective appeared first on Big Nerd Ranch.

This past Saturday, I attended the Atlanta Code Retreat at the Highgroove office. I hadn’t been to a code retreat before this one, and I really didn’t know what to expect. What I got a was a challenging but fun day of pairing with five different developers, and writing in four different languages.

What we did

The basic idea of the retreat was not to focus on coding a complete solution, but rather to write the best code possible. We were aiming to write small pieces of well-tested and DRY code that showed its intent through good naming.

The day was divided up into six sessions of 45 minutes, and in each session, we were paired with a different developer. The task was to code Conway’s Game of Life, with a new set of contraints for each session.

How it went

By the end of the day I had written code in Ruby, PHP, Java and CoffeeScript, and worked with developers with different levels of experience. I got the chance to use editors and even operating systems I had never used before.

Two sessions were especially challenging. In one session, we weren’t allowed to use any conditionals or loops. This was designed to push us towards using functional programming techniques, something we don’t do a ton of as Ruby developers. And in another session, we kept our pairs from the previous session and inherited another pair’s code. This was challenging because many groups got code in languages they weren’t experts in.

I found the “ping-pong” session to be the most interesting. One developer wrote a failing test and handed over control to the other developer. The second developer wrote the code to make the test pass, and then they wrote another failing test. When writing the code to satisfy failing tests we were encouraged to be “nefarious,” meaning that we wrote just enough code to make the test pass. For example, if the test was checking that some method returned 2, we would simply make that method return 2. Then we’d write the failing test to improve the code.

What I learned

Key takeaways from the event for me were:

1. Pairing is fun and productive! It is awesome to have someone with whom to work through a problem. A good pair will often catch your mistakes before you do. What’s more, you will likely create a more elegant solution than you would be able to do your own.

2. Testing is very important. Not only does it serve to validate the correctness of your code, it also serves as documentation for what your code does. When our pair inherited an incomplete CoffeeScript implementation of the game, we were happy to find that there were accompanying tests that made it easy to figure out what was done, as well as what still needed to be worked on. We were also able to continue development with the assurance that we weren’t breaking existing functionality.

3. While Ruby is awesome, using other languages can be fun. Writing in other languages makes you grow by encouraging you to think about things in new and different ways.

Code Retreats are a great way to sharpen your existing skills while learning new ones. What other types of events do you participate in to hone your skills?

Special thanks goes out to Highgroove Studios and Toolbox 9 for sponsoring the Code Retreat, and to Highgroove Studios’s Jonathan Wallace for leading and organizing.

Did you miss out on sign-ups for this Code Retreat? Like us on Facebook and follow us on Twitter to make sure you’re up to date on Highgroove events.

The post Atlanta Code Retreat appeared first on Big Nerd Ranch.

When developing software, face-to-face conversation is often the best form of communication (Agile Principles). While Skype and other tools allow you to get face-to-face from pretty much anywhere, there is really no substitute for spending some time in-person with everyone involved in developing software. At Highgroove, we often do remote work for many of our clients. Since travel can be hard and expensive, here are 3 tips for maximizing the value of your next business trip.

1) Get some work done together.

When you visit a client, chances are you will have some meetings scheduled. Often times these meetings are centered around planning. While sometimes these are unavoidable, try to keep them short, opting for spending time working on the product with the customer. You can do this by simply pairing with the customer, or even with their team. Working on a problem together will be easier for you because you have the direct attention of the person/people who know the most about the product. It will be helpful for the client because they will get a better sense of your workflow. Finally, it will be a win for everyone, because – “when was the last time you had a pairing session where neither party learned something?”

2) Do something that isn’t work together.

While business is the reason for the trip, try to plan some non-working time with your client and their team. Try to get as many people from the team to participate as possible. This could be as simple as going out to a meal together, or as exhilarating as a bike ride through a city you have never ridden in. Try to keep the conversation off of work. This is about forming some common ground over something outside of the codebase. If there are team members present that you normally don’t get a chance to interact with, make sure you try to spend some moments getting to know them better. That way when you do need to work with them in the future, it will be easier since you have already spent some time getting to know that individual.

3) Plan in advance, but adapt to changes.

It’s tempting to plan every minute of the trip down to the last second, but chances are, you’re over-planning. Just like we do Iterative Development at Highgroove, you can iterate on the agenda to adapt to what’s working. For instance, if you are pairing with a developer on a particularly tricky bug, it might not make sense to spend too much time – to get bogged down on fixing the bug, when time can be better spent hashing out how you would architect the next big feature.

How else can you make client visits more productive?

The post 3 Tips for Developers while Visiting a Client appeared first on Big Nerd Ranch.

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?

The post Spree Conference 2012 appeared first on Big Nerd Ranch.

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.

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?

The post Mailcatcher: Making email testing a breeze appeared first on Big Nerd Ranch.

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 post Great Office Rearrangement: Sit where you want appeared first on Big Nerd Ranch.

Active Shipping is a nifty Shipping API extension for Active Merchant. It provides methods for interacting with common shipping carrier APIs. Recently we used Active Shipping on a client’s e-commerce site to provide customers with many shipping options from several carriers.

Getting Rates

To get shipping rates for a carrier, you first need to “package” up some information about what you are shipping. Using the Package class you can build an array of packages. Use each package’s dimensions, weight, and the unit system you are measuring with (this will default to metric) to create a new package. Here in an example package:

From working with Active Shipping and various carrier APIs we have learned that all carriers require a package weight. Some will return results for a package with no dimensions. However, rates will vary greatly depending on the dimensions of your packages, so it is a good idea to always include them so that your rate estimates are accurate.

Along with the array of packages, Active Shipping needs to know some information about the origin and destination of your shipment. Using the Location class you can create an origin and destination location for your shipment. Here is an example of a destination (the origin is built the same way):

The Location class takes country, state, city, and zip. Working with Active Shipping and various carrier APIs we have found you can get away with just using country and zip code if needed.

Once we have an origin, destination, and packages we are ready to make request to the carriers’ APIs. Initialize the carrier you want to you use, then call its find_rates method:

Getting access to carrier APIs.

Each carrier requires its own set of credentials. You can sign up for each carrier’s service on their respective websites. While the UPS codes seem to always “just work”, you will need to pass :test => true as a param to get Fedex to work while you are testing your application. We were unable to get the USPS API to provide rates in test mode). To get the USPS API to provide rates you will need to contact and have your production API access turned on. The best way to do this is the call the number provided in the confirmation email they sent. Requests made via email seem to take a couple days to get processed.

Active Shipping is just one of the great extensions of Active Merchant. What other Active Merchant extensions are you using in your e-commerce sites/development?

The post Using Active Shipping for Shipping Rate Estimates appeared first on Big Nerd Ranch.