April 9th and 10th in San Francisco was the first ever CodeConf. Read on for a recap on this incredibly insightful and wonderful conference.

h2. People

I know we talk about the presentations a lot when we do these conference recaps, but we always seem to gloss over the amazing people we meet at the most important times of the conference. I mean, that’s really what going to conferences is about: the people.

CodeConf was put on by some outstanding people: GitHub, but specifically Melissa Severini (@”luckiestmonkey”:http://twitter.com/luckiestmonkey). This was her first time organizing a conference and she killed it!

It’s always great seeing the faces of people I’ve known for what feels like ages but never had run into before. And all the old familiar faces were a sight for sore eyes.

At these kinds of cool conferences, it’s hard to find people that aren’t doing what they believe in and are passionate about. Nearly everyone I spoke to was working on awesome projects, solving hard problems, and having a great time: and that’s what I love about these conferences. It’s infectious.

Speakers

I won’t go without sharing some amazing insight from the speakers. But before I do that, I want to observe the great variety of speakers at the conference: not all speakers were professional developers, or at least not all had been so for long, and many of the speakers spoke about real issues with open source: abandoning projects, involving and embracing the community, and knowing better what to build. The variety of perspective was refreshing and essential to how awesome this conference was.

The Talks

Coda Hale’s excellent talk Metrics, Metrics Everywhere illuminated not only the real value of metrics, the business value that you can continually increase when making the right, informed decisions, he also outlined in detail how to measure and collect those metrics then how to understand and act on them. My favorite talk by far, the insight from this one talk answered many questions in my own quest to “make better decisions by using numbers”.

“We improve out mental model by measuring what our code does.”

In fact, John Eward started working on a Ruby Metrics library, inspired by both Coda’s talk as well as his original open source library for Java/Scala.

Jacob Kaplan-Moss, of Django fame, shared a very poignant, repeatable observation about good documentation: it’s fractal in nature, repeating these four elements at every level of detail:

• Introduction: for the uninitiated

• Overview: clearly describes in detail what something is and how it works

• Reference: go into detail about the actual implementation, such as the supported public API

• Troubleshooting: addresses (actually) frequently asked questions, how to begin disecting problems, or where to look for answers

Mike Krieger from Instagram talked about dealing with the uncertainty of new ideas, experimental features, and quickly iterating on ideas. The two goals to keep in mind are:

• Be wrong faster

• Make being wrong less painful

He did this by using agile tools like Python and Django and iterating quickly.

“Stand on the source code of giants.”

Jeremy Ashkenas, creator of CoffeeScript and Backbone.js, and developer at DocumentCloud, spoke on Code as Literature. He quoted Knuth and Dijkstra continuously providing counterpoints to ideas and brought back a key point in Coda Hale’s talk: “mind the gap” between our understanding and the reality of it. “Code has two audiences”, Jeremy points out: the computer and the developer. “Programming is constraining the unlimited possibilities” into the finite, but a program can be meaningless if there’s no clarity for either of them.

Nicole Sulivan’s talk reminded me of a recurring theme in my own thinking: simplicity changes based on the context. The simplest possible way to approach a problem will be different in one context than another, but it’s often better to not over-engineer something because you aren’t solving a real problem until you’re context changes.

Wil Shipley repeated a theme from Mike Krieger’s talk: the minimum viable product isn’t just reducing features, it’s “shipping fewer features, better.”

And the lightning talks were especially great: it was awesome seeing a brand new and awesome feature of GitHub, Issues v2.0, being deployed on stage.

Finally

I hear there will be plenty more conferences in the future from GitHub: I can’t lie, I am really looking forward to it.

There were some great notes from The Changelog Show’s Steve Klabnik on the conference talks:

• CodeConf: Saturday Summary

• CodeConf: Sunday Summary

Do you have any observations or stories you’d like to share from the conference?

The post CodeConf Recap appeared first on Big Nerd Ranch.

Virtually every application we push to production relies very heavily on open source code in one way or another. This means we’re utilizing the experience, knowledge, and expertise of the OSS (Open Source Software) community to solve many of our problems. Things that would’ve taken us quite a bit of time, money, and effort to iterate on in order to bring the quality to something on par with the OSS options are freely available and open for us to incorporate in our projects.

OSS is smart for us and smart for you since we’re often able to expand our knowledgebase and our expertise channels just by using the software and being a part of the community, something we do actively and constantly.

We contribute back as often as we can: bug fixes, new features, documentation, and sharing knowledge whenever possible. This is the essence of open source: the users of software giving back their own time and experience, especially when it benefits everyone.

Our standards for OSS remain high: we require that libraries and frameworks

• be well tested

• be well documented

• be implemented sanely: organization, style, dependencies (for debugging and contributing), and

• have an active community or maintainer

Tests give us confidence that the library works the way its described. A solid Readme and API docs gives us enough information to start using it and know where to turn when we need to know more. Sane organization makes debugging easier, contributing simpler, code spelunking more fun (because sometimes we just need to dive right into the code to solve our problems). Without an active community or maintainer, bugs will go unfixed, software will continue to rot (falling behind changes in more active projects like Rails), etc.

We constantly experiment with new libraries and tools all the time, but ultimately we make decisions that are in line with these requirements. Without these guiding our decisions, we could easily get caught under the bus when it becomes apparent software is broken, unusable, poorly documented, and unsupported externally.

Lets take a step back to one library we use constantly: Rails.

Rails

Yes, even Rails had to pass our requirements, and it does so with flying colors in case that wasn’t obvious. So much so that we’ve devoted ourselves to mastering application development primarily within its ecosystem.

How does it stack up to our requirements?

• Rails maintains a very detailed and extensive test suite, is fairly well documented internally, and has countless sources of external documentation through blog posts and on sites like StackOverflow.

• Rails isn’t just one big mess of code, either: it’s broken down into well organized modules and support libraries like ActiveModel, ActiveSupport, ActionDispatch, etc. And to tie it all together, each package provides a good deal of hooks to make getting deep into it very easy. This gives us quite a bit of power in our day-to-day development and for debugging when necessary.

• The Rails community is stellar: so many bright developers are constantly building excellent libraries, tools, and applications with it. We’re never at a loss for an answer because the community spreads knowledge so quickly and effectively. The core maintainers who organize the roadmap, handle bug fixes and accept patches, and work on new features are some of our personal heroes.

Rails isn’t always a perfect fit for every web application we build: Sinatra and Rack are on our short list for memory sensitive and fine-tuned performance applications that don’t require the development features that Rails provides. But even then, Rails 3 has opened even more doors for Rails to rock.

Rails isn’t great for any one reason, but if I were to choose which requirement Rails meets best: its community is by far its strongest proponent.

Next Up

Have any libraries, tools, or applications you want us to cover? Leave a comment below!

The post Open Source at Highgroove Studios: We're A Rails Shop appeared first on Big Nerd Ranch.

A little over a year ago, I weighed about 80 pounds more than I do today. Today, I am healthy, strong, energetic, happy, and more confident. Losing the weight took a lot of work, but that wasn’t really the goal, and it’s certainly not the end, either. The real motivation was to live healthier and be happier, and the real goal was (and is) always changing. To do this, I had to put lots of small choices into context: will this make me happier and healthier? Lots of small choices and small steps got me closer to my next, small goal. This, I realized, is a lot like how we approach “Big Projects” or “Big Goals” at Highgroove.

I didn’t realize at the time that I was making progress towards these “Big Goals” through many smaller, incremental choices. I’ve made plenty of big goals that, true to form, failed miserably: New Years Resolutions and major epiphanies for life change often fell flat, crushing my will and dashing my confidence.

Making big changes all at one time is dangerous: there’s plenty of opportunity to rush, screw up, and jeopardize the entire process with carelessness or lack of foresight – or just get too overwhelmed with enormousness of the end result. The more complicated or larger a task, the harder it is to be confident that what you’re doing is the right step and will be executed correctly.

Here are some tips I’ve found (with an emphasis on software development) for making Big Goals manageable and attainable:

• break up a big problem into many smaller problems: each with a tangible goal and a positive impact

• address problem points first: fix unstable, untested, critical, or problematic functionality and features first

• measure the effects of each change

• constantly reevaluate your progress and prioritize the next important step

Our agile development process often produces non-permanent code. Requirements and specs are constantly churning based on business needs, and soon enough growth can begin to require changes to logic or infrastructure. We have to always pay attention to the direction we should be heading to ensure a successful product, and sometimes that requires going backwards a little bit: but only when it’s healthy and beneficial in the long-term.

Being agile through big changes involves ensuring we have sufficiently tested each piece of the large whole. This may mean things like, testing the live site in a staging environment to get outside users (project managers, primarily) using and ultimately accepting stories.

In work, or in life, we always have to focus on small problems: bite off too much and you’ll choke.

After just one year, my life has changed drastically. Losing the weight wasn’t the ultimate goal, and I never would’ve gotten here if it was. The “goal” was to always be better, one step at a time. It was easy when the goals were always within sight and tangible.

Image License: Attribution, Noncommercial, No Derivative Works, by anthony_goto

The post Setting Big Goals, and Achieving Them appeared first on Big Nerd Ranch.

We’re still recovering from RubyConf (specifically the 10k, Jonathan’s first ever, has yet to release its iron grip on his calves), but we have had some time to reflect on what value we at Highgroove extracted from the conference.

What you missed

There’s something to be said for face to face interactions. For those of you unfortunate enough to miss RubyConf, you missed the most valuable part of the conference. Sure, there are links to slides to hold you over until the ever awesome Confreaks post the videos . But, sitting at your computer desk, you don’t get to continue the conversation once the video finishes. The conversation begins in the presentation but continues outside of it. The asynchronous communication of blogs, tweets and the friction of IM cannot compare to the tight, agile, serendipitous feedback loop of conversations.

Passion was dripping from the speakers and attendees alike, drowning conversations in enthusiasm about cool toys and awesome tools and the frequent opportunities to contribute back. It’s so evident when you’re watching excellent talks like Aaron Patterson’s where he poignantly and artfully shares technical insight, humorous anecdotes, bits of culture, and sage wisdom. That’s just something you often miss in the tweets and commits from across the globe.

It’s evident that the passion driving our community really pushes the quality of our work and makes the conference attendees, general Rubyists and Highgroove’s expert developers, excited about sharing what we find and how we triumph!

What we gained

Eric Hodel and Nathaniel Talbott caught us up to speed on Rdoc / Rubygems and RubyConf respectively. Daniel Jackoway impressed with his work on Ruboto and Nick Sieger’s talk on Warbler is immediately useful!

Other highlights include Eleanor McHugh and Elise Huard discussing concurrency in Ruby as well as Jonathan Dahl’s fantastic parallels between strong writing and strong code.

A few key quotes from Jonathan Dahl’s talk (here’s a copy of the same talk from an earlier conference”).

“Marketing is about obscuring rational thought.”

“Vague language and bad writing are a key tool to propaganda.”

“Bad writing is hard to understand, but also buggy.”

Finally, Tom Preston-Warner’s talk almost had us standing up and walking out to get stuff done. Now that’s a super inspirational talk.

And that sums up RubyConf as a whole: super inspirational.

What inspired you?

This post was written by Jonathan Wallace and Matt Todd. Chris Kelly also wrote up his reflections! Read his blog post.

The post ZOMG ROFLscale Rubyconf OR Why you missed out. appeared first on Big Nerd Ranch.

“On your mark, get set, GO!” Nothing like the thrill of starting an intense race, whether it be a short hundred-meter dash or a long, grueling marathon.

In our case, October 16-18, 2010, the RailsRumble 2010 48 hour competition, was a bit of both. We, Chris Kelly and myself with help from Jim Hodgson, represented Highgroove in friendly competition with over 150 other teams.

Much like other tests of physical prowess, participating in the RailsRumble becomes more a competition with yourself as you face challenges and battle yourself.

We of course had obstacles to overcome and odd things to bang our heads on, but we minimized our stress by setting up continuous testing and deployment with CruiseControl and Chef. Within minutes we had a deployed Rails 3 app and a failing build, hands free.

Our goal from the beginning was to build an app that helps our Results Only Work Environment track our results, holding us accountable and encouraging us to do so long term for things like team bonuses, quarterly reviews, et al. Having talked internally at Highgroove, especially with Charles Brian Quinn, the lead consulting partner, and Megan Zaki, our office manager, about how we do things and how we should be doing things, we were able to formalize a plan. As soon as the competion began and we had our infrastructure problems solved, we set off immediately to fill our Pivotal Tracker project with lots of stories. We set our velocity ridiculously high and set up releases and the imminent deadline. It was definitely important for us to know our plan of attack and to see what all remained to do.

At the end of our sprint, we had a functional application that could meet the minimum of our needs: Pivotal Tracker integration for results based on stories, helping us keep track of our results for iterations (weeks, in our case), and the minimal reporting needed to make sure we were on track in the short term. We definitely aspire to keep on crafting this into a tool we use daily in our organization and to help us stay organized, but before we do that we will be taking a step back and making sure this first prototype is the right direction.

The most important part of this competition for me is the personal challenge involved: motivating and kicking my own ass to stay focused and productive, making sure I’m not wasting my time doing things wrong, and making sure I’m producing at a high quality consistently.

I recognized in myself stubbornness and determination that is valuable but easy to cut myself with when I don’t learn to fail fast and find a better solution than the one I’m working on (that is clearly not working). I struggled with simple things like buggy Rails 3 support in Authlogic (“surely I’m doing something wrong… just what is it?”) and trying to do things “the right way” according to someone else’s library: I have to remind myself at times that I shouldn’t necessarily trust my tools so much and that my judgement is best for my situation. Essentially, I have to learn to trust myself better, and listen to myself sooner.

I know that I may not be very fast, but what I do produce is high quality. Putting myself under the knife and really pushing myself in a competition like RailsRumble has both underscored these things and helped improve both simultaneously. Practice makes perfect, but it also makes you faster.

Chris is also fairly new to our team and I haven’t had a lot of time to work on any new projects with him, so competing with him in the RailsRumble gave us this opportunity. Being the drivers for once allowed us to butt heads plenty and will help us work together in the future.

Everytime we felt like we might be getting stuck or heading down a rabbit hole, we reminded ourselves to keep a “bias towards action.” We do this in our daily work and it was especially important to keep true to it during the competition. This phrase is definitely at the heart of an agile team.

We crossed the “finish line”, or more accurately the deadline, about an hour before 8PM EST, midnight GMT. Instead of being panicked and running around unhappy and nervous, we sat back confidently sipping beers with our application tested, deployed, and functional. “We won’t win” (we didn’t even make it into the public voting round), but we met our goals and learned more about ourselves.

We win.

The post RailsRumble 2010 Redux appeared first on Big Nerd Ranch.

It’s late Friday afternoon, I’m angry at this problem I’ve been working on for an hour (or more), but I’m stuck. The sun is out and a cool breeze is blowing softly outside and I want to be riding my bicycle through the streets of Atlanta at full speed! Right now, I can think of nothing more than how much I hate this bug. I’m stumped.

What do I do?

At Highgroove, we’re experts at this Rails game: we have tons of experience building applications and fixing bugs, figuring out problems and crafting simple yet elegant solutions. Years of practice has fitted us with an intricate and intimate understanding of the tools we use, the methods we employ, and the goals we often aim for and achieve. Even with of all of this knowledge and experience, we don’t always have the answer. But what makes us true experts is knowing how to find it even when we don’t.

A big part of being an expert is knowing where to look when we don’t know the answer immediately. Our checklist, of sorts, often looks like:

• Refer to the relevant documentation

• Perform a quick search (Google or Bing, Stack Overflow, mailing lists, wikis, etc)

• Ask our colleagues

• Perform a more thorough search

• Ask the internet (Twitter, IRC, mailing lists, etc)

Most of the time we may just need someone’s directing words to point us in the right direction. Often when we go looking for this direction, our colleague or friend has actually solved the problem recently and will know the answer. It’s important to involve your team (those that would know) soon but respect their time and don’t pester. Do your due diligence and be quick about it.

If we get to the point where we have to ask the internet, that means it’s time to get some coffee, free our mind from the problem for a short amount of time, and let the responses come in. Find something else to work on, go for a walk, stretch, take a quick nap, or call a relative. Once you’re back working on the problem, first think about your solution and other solutions to your problem. Don’t get too involved with and dedicated to your approach: it’s OK to start over if you recognize that you’ve ventured off into some rabbit hole and need to get back on course.

Before you posit your problem to the internet, make sure you evaluate what you need to know and cut out any distracting details. Break your problem down into the minimum description and context, hopefully something tweetable. Let anyone who thinks they can help ask for more context. And of course be willing to patiently work for your solution: impatience will only lead to shoddy work and won’t solve any problems.

It would be silly to pretend that we know everything, so we embrace the massive amount of information sitting so very close to us and use it as often as possible. In turn, we’re learning and gaining more experience every day.

Back at my desk, I’ve decided I don’t know enough to solve my problem so I ask my colleague who knows where to look and together we solve my issue. Shortly after, we’ve deployed a fix and I’m out the door in minutes. I kick myself for not asking them sooner, but either way I’m out the door and on my bike with the wind in my hair and more experience under my belt. The weekend is always a bit better when I’ve solved my problem quickly, I’ve gained that experience and knowledge, and added another resource to utilize in the future.

The post Knowing How To Solve Your Problem appeared first on Big Nerd Ranch.

Most database-backed applications, especially Ruby applications written in Rails do fine with a SQL Database, like MySQL. Adam Wiggins of Heroku does a great job explaining how SQL Databases are an Overapplied Solution. There are definitely a few cases we’ve seen where a NoSQL solution like Redis can really shine.

At Highgroove, we’ve got several projects utilizing the Redis key-value store. Here are a few reasons you might want to look into Redis:

1) “Data is frequently written, infrequently read” – if you are making tons of writes and MySQL can’t keep up, Redis has been clocked at 110000 SETs (the INSERT equivalent) per second!

2) “Data can be expired” – if you have data that can be expired on a regular basis, over time, or explicitly, like stats, logs, and session data, Redis can explicitly expire whole keys or quickly trim large lists of data in no time.

3) “Data is a collection of COUNTs, or SUMs of other data.” – if you have ever written an UPDATE statement that adds +1 to a record, you probably know that it is quite expensive, and could possibly be wrong. Redis has built in support for incrementing and decrementing values, quickly.

We love SQL Databases, so you won’t see us abandoning them any time soon, but we enjoy adding tools like Redis to our toolbelt.

More Information on Redis

Redis Project Page

Redis Wikipedia entry

A Collection of Redis Use Cases

The post Making the Case for Redis appeared first on Big Nerd Ranch.

Trying to handle image manipulation, creating PDFs, or in-memory caching in pure Ruby is like trying to win the Tour de France on your hipster single-speed bike. The single-speed works 90% of the time, but when you have demanding performance requirements, it’s not good enough. Many popular Ruby libraries, such as MySQL/PostgreSQL, RMagick, and most of the webservers Ruby applications are deployed on (like Passenger, Mongrel, and Thin), harness the blazing speed of the C language and libraries to handle the heavy lifting and performance-intensive business that Ruby can’t keep up with on its own.

In some of my recent work, I had the opportunity to delve into and expand on a Ruby extension written in C for looking up geographic information based on IPs. This library was vital to one of our client’s projects that has immense performance requirements without the possibility of full request caching. By utilizing the existing GeoIP C library for accessing their special in-memory binary database, we were able to keep up with the demand the application would be seeing.

As is common at Highgroove Studios, along with making sure our contributions to the library were open sourced, I took the lessons and experience gained from this unusual endeavor and presented them to our local Ruby User Group here in Atlanta. I focused more on exposing the bridge between the Ruby and the C environments and understanding the internals of the Ruby language from a C standpoint. However, armed with this knowledge, any Rubyist is able to open up most any Ruby extension or even the Ruby language implementation itself and understand what’s going on. My goal was to get the developers over the initial hurdle of being able to read the code and understand it enough to investigate further.

Personally, I gained from this experience a better appreciation for the real beauty of the Ruby language and the effort required to make it as fluid and dynamic as it is as well as having a more thorough understanding of the internal workings of the language. Working this close to the language core has also made a difference on my Ruby style, both in trying to fight the language less but to also use it more efficiently and effectively.

For more information, check out the presentation slides1 and some of the C examples I wrote for the presentation2. Also check out the GeoIP I contributed to which inspired this whole adventure3.

1 http://www.slideshare.net/maraby/writing-ruby-extensions

2 http://github.com/mtodd/ruby-c

3 http://github.com/mtodd/geoip

The post Writing Ruby Extensions in C the Highgroove Way appeared first on Big Nerd Ranch.