Big Nerd Ranch recently sent Brian Gardner and me to the Railsberry Conference in Krakow, Poland. Having been to several Rails conferences already, I expected some technical talks, Agile process talks, and the requisite talk on refactoring.

What I found at Railsberry, which is advertised as the conference for “curious” Ruby on Rails developers, was far from formulaic and typical. It was one of the most unique, fun and well-organized conferences I’ve attended in my career as a developer.

A different kind of conference

So how did Railsberry show me a different kind of conference experience? First off, ask yourself this question: Have you ever been invited to attend a contemporary dance performance by the conference organizers? Odds are that you haven’t, unless you’ve attended Railsberry.

Have you been able to swing back and forth while watching a lightning talk? Odds are, again, that you’ll have to say no. But this is what the modus operandi is at Railsberry; in fact, upon arrival at the conference, you’re inundated with a different look and feel. The conference itself is an experiment, meaning that the organizers try different, new ideas and see if they work. They embody a curiosity towards everything that permeates the entire two-day, single-track event. I was actually initially greeted and welcomed by conference staff wearing laboratory coats! (Were they experimenting on me?) When a conference speaker wasn’t able to attend the conference, it was no big deal. The conference organizers simply opened the floor for more lightning talks.

Learning something new

Let’s not forget the reasons we attend conferences: to learn something new. And there was a slew of great talks by a variety of speakers from various professional positions. We listened to Gregg Pollack walk us through the current state of the online education business as it pertains to learning code. We were enlightened by Fred George’s talk on implementing Agile methodology for any development team. As a 40-year industry veteran, his insight into how a company “should” do Agile was eye-opening, to say the least. He even called out some of the practices that we currently use at Big Nerd Ranch (our ego is not damaged; indeed, we love learning from others as much as we love teaching). The most outstanding and thought-provoking presentation was Joseph Wilk’s talk called “Creative Machines,” where he explored the ways that computers can produce music.

All in all, this event is a standout amongst the global collection of technical conferences a Ruby on Rails developer could attend. It was entertaining, thought-provoking and fun. I can’t recommend this conference more highly.

The post Railsberry: A Different Kind of Conference appeared first on Big Nerd Ranch.

Since joining Big Nerd Ranch in April 2011, I have grown by leaps and bounds as a software developer and consultant, and I’m surrounded by the best team I’ve ever worked with. But despite this, my personal career goals and aspirations include giving up coding altogether.

Adding the sales engineer role

Fortunately for me, Big Nerd Ranch loves to experiment, and we add roles when we need them. We recently added a sales engineer role, and not only does this role align with my future career goals, it’s turning out to be a role that is really helping the company.

So what does a sales engineer do?  Where do I fit in?  Most importantly, how do I help close deals?

SELLING A PROCESS

Traditionally, sales engineers work for software product companies.  These companies have sales staff that can penetrate new markets, find new customers and do all the “sales things” right, but they are usually not very technical.  Their clients need to know how a software product will work, how it will integrate into their current IT infrastructure—and frankly, whether it will work at all—before signing any deal.  This is where the sales engineer steps in.

At Big Nerd Ranch, I don’t have to help sell a product.  I help sell a process.  This process works.  I’ve been involved with the process for a year and half and have delivered rock-solid web applications with confidence and ease because of it.  Because I have  experience working with Big Nerd Ranch’s iteration-oriented process, I’m able to advocate for it when talking to prospective customers.  I also have roots in a variety of industries such as health care, telephony and the software industry itself, so I am able to tie together my collective industry experience with what I have learned at Big Nerd Ranch to relate easily to clients and understand the problems they need us to solve.

During the services sales cycle, I’ve noticed that clients always want to know two things.  The first is our price and the second is our competence.  I help business development with the price aspect by reviewing ballpark proposals before they are put in front of potential clients.  If something in the ballpark seems a little strange, I will research the problem and see how easily we can solve it.  This can affect the length of a project, so I try to find any potential showstoppers or missing project components before the project begins.  The second component I work with is selling our collective competence.  Clients want to know that the money they spend will be in good hands, and I am conscious of this fact while communicating with potential clients.

At the end of the day, I thoroughly enjoy my dual roles at Big Nerd Ranch.  On one hand, I crank out Ruby code and Tech Talks.  On the other hand, I crank out new projects with the business development staff.  As Big Nerd Ranch continues to grow, I’m sure that the sales engineer role will expand and my development days will end.  Thankfully, I work at an awesome company with an awesome CEO who is willing to experiment and create an environment that nurtures professional growth.

Image credit: Twentieth Century Fox

The post What would you say ya do here? appeared first on Big Nerd Ranch.

I’ve been developing Rails applications since version 1.2. Having worked through several major Rails upgrades, I’ve learned the true value of writing tests. Simply put, tests provide confidence that features will work as designed, and will continue to work in the future. Read on and I’ll delve into my own process of deciding what to test.

Testing that fails

In the very beginning of my Rails journey, I approached testing with a fairly simple assumption:

Because Rails follows the MVC pattern, if the website behaves the way I want it to work, then the controllers and models also work as expected. Therefore, I only really need to write integration tests and can get by with relying on Cucumber.

I was a Rails newb at that time, so I knew that I wasn’t a great Ruby developer quite yet, and being able to write tests in Cucumber’s domain-specific language was alluring. I wrote tests that really only poked and prodded the view layer for “things that should be there” and checked that pushing buttons yielded the results I wanted. I presumed that I could tease out problems merely by clicking the same way a user would.

Unsurprisingly, this process broke down pretty fast. If I wanted to fix any test failures, I had to read the stack trace. And if the problem started in the model layer, I had to read the stack trace line by line until I reached a particular line that seemed suspect. As you might imagine, this was tedious and led to lots of “shotgun coding” where I would change some code in one place and pray that the error either went away or changed into something else.

Furthermore, a single failure at a lower level, like the model level or database level, would cause a large amount of the test to fail. This made it frustrating to debug the true source of a problem without once again reading the stack traces line by line.

Conclusion: It’s not practical to rely solely on integration tests.

It’s no coincidence that this realization came to me about a month after I joined the team at Highgroove. Faced with building an extremely complicated app with a large test suite, I realized that there was no way an integration test could conduct the level of testing required in order for me to feel assured that everything was working as it should be. So I made another assumption: If the controller and model level are tested thoroughly enough, it’s reasonable to think that the view layer is working just fine, too.

Again, this assumption worked pretty well for a while–until the view layer became more complex than just rendering views and buttons. If, for example, a system had multiple roles that showed different things to different people, it was incredibly cumbersome to test using just the view layer. And relying strictly on model and controller tests meant that I would miss out on testing any JavaScript, requiring me to test it manually.

Conclusion: It’s not practical to rely solely on controller and model unit tests.

How I test now

After swinging from one extreme to the other, I ended up landing on a strategy in the middle of my two previous methods. In order to reach 100 percent test coverage, I use elements of both of my previous strategies. I test only code that I wrote, and I test the code directly.

This means that:

1. A method in a model will necessitate a unit test.
2. A controller action will necessitate a controller test.
3. A conditional statement in a view template necessitates an integration test.
4. Javascript, except declarative jQuery (or another JS framework), necessitates an integration test.
5. I don’t test declarative statements provided by Rails or other gems (i.e., I don’t test that a model validates a name).

A bit of caution about #5: I advise this method only if you are an expert Rails developer and already know what the Rails declarations accomplish. If you do not have much experience with Rails, it’s quite helpful to write tests for validations, associations or other gem code so that you can understand what’s happening within your own application. Otherwise, you should rest assured that the gem’s authors wrote a test suite already and that the gem operates as documented.

Your tests should provide you with the confidence that you’re delivering code that works as intended, old and new features both. As your confidence and proficiency with Rails increases, the need to test declarative statements drops significantly. For example, I find myself testing model validity less and less as I have little need to test whether Rails’ built-in validations work properly.

I have developed my own particular style of testing, but I’m curious about how you test. Do you do the five things above? If not, which testing philosophy do you follow?

Image credit: tomcensani

The post Getting Jiggy With Testing appeared first on Big Nerd Ranch.

It is no secret that Highgroove is a bona fide Results-Only Work Environment. As a team, we focus on getting work done and ensuring client satisfaction. When, where, and how we work is irrelevant, because what we care about is the answer to one question: Is the client happy today?

I’ll admit that working in a ROWE isn’t always the cakewalk it sounds like. We still live in the real world, where time passes and deadlines creep up. So how do you keep the clock under control, as opposed to being controlled by the clock?

Time tracking isn’t easy, and there are lots of ways that we all try to make it easier. There are apps you can download, seminars you can attend and all sorts of books you can read in order to be efficient, manage time effectively and avoid procrastination. We’ve even talked about tracking time the ROWE way on our blog.

Personally, I prefer a very simple method that requires only a bit of self-awareness and discipline.

Routine is key

How do I make it easy to get work done on time? One word: Routine. My day usually looks like this:

1. Wake up at 7:30 a.m.
2. Walk the dog and feed the cats.
3. Review my calendar and reminders.
4. Work for Highgroove clients for about 6.5 hours.
5. Work on other results for Highgroove for about 1.5 hours.
6. Promise myself that I get to go home early, watch a movie or surprise my girlfriend by making dinner if, and only if, I stay focused, organized and on task.

6 is the cornerstone of the Results-Only Work Environment. If I am efficient and quickly get results accomplished while maintaining the craftsmanship that Highgroove expects, then I’ve earned the freedom to go home and do whatever I want.

That’s it. There’s no super-secret system or formula that I use, nor any specific app. It all boils down to knowing that in a ROWE, I’m free to come and go whenever I want. That knowledge is motivation enough for me to be the most productive and awesome developer for Highgroove that I can be.

Ok, here are some apps

If you really want some apps to try out, here are a couple that we use at Highgroove. Give them a try, but remember: it’s not the app that you use, it’s the discipline that you bring into your daily life that really makes working in a ROWE possible.

• Things
• Lets Freckle
• Toggl
• Klok
• Tictoc

What about you? Does your routine help you accomplish tasks and defeat your deadlines?

Image credit: garlandcannon

The post Managing Time in a ROWE appeared first on Big Nerd Ranch.

I am pleased to announce that this week is my 1 year anniversary as a Developer at Highgroove! Because of this important milestone, I thought it would be appropriate to write a blog post summarizing my experiences with Highgroove thus far. Highgroove centers everything around 4 Core Values (Personable, Optimistic, Trusting, and Craftsmanship) so what has the last year taught me about them?

Personable:

I will admit, when I changed jobs a year ago I was pretty blunt with some clients. This was brought to my attention because we do retrospectives on projects every week where clients are asked a series of high level questions regarding the projects progress and client happiness. Prior to working for Highgroove, none of my other jobs asked customers about their thoughts in the way that Chris’ Retrospectives do, so I was a little surprised when CBQ approached me to talk about it. In a completely positive way, I was coached on how to deal with clients in a more friendly, less direct fashion, and here I am now a better Consultant because of Highgroove’s never ending open communication ethos.

Optimistic:

I’ve always had an optimistic outlook on life in general, but I had a small seed of doubt about my Developer skills when I started Highgroove because I had never had a formal Development position before. My professional career has thrown all kinds of crazy, high stakes situations at me where millions of dollars were on the line. Handling those was really no problem for me. But Sitting in a quite room coding hearing the Espresso machine do its thing with Turntable.fm playing in the background?. A little daunting at first. What I learned very quickly at Highgroove that helped me get over my initial fear was how open and willing to help everyone on the Highgroove Team is. I learned that there are a lot of Ruby, Gems, Test Frameworks, development practices I absolutely did not know, but I was never harangued over my lack of knowledge. To the contrary, I was taught all the things that my cohorts know and caught up. It wasn’t easy, but if it hadn’t been for Highgroove’s rock star team, I wouldn’t be anywhere near as optimistic about my projects as I am now.

Trusting:

Trusting at Highgroove means to trust that Highgroove uses the best processes, employs the best people, and provides the best tools for all developers. For a new guy just joining, it takes trust to throw out everything you taught yourself and learn things the Highgroove way. Like the Trust Fall excersice, I had to dive into the way Highgroove does business and believe that it would lead me to project success. The end result: I don’t get called at night because software isn’t working. I don’t work on weekends because my software is tested before its deployed. I don’t worry about a server going down because we don’t manage servers manually. We use the best processes, the best tools, and we have the best people. One year later, I absolutely trust that the “Highgroove Way” is the way to deliver software.

Craftsmanship:

I dislike things that don’t work. I hate bad software. I can’t stand being woken up at midnight because someone else’s bad code is crashing. One of the main reasons I came on board at Highgroove in the first place was Highgroove’s commitment to delivering working, well tested software. The quality of my code has increased significantly thanks to Highgroove’s weekly code reviews. I have taught myself the art of refactoring, so the code I write is easy to change, easy to understand, and also wrap my head around code I’ve inherited quicker than before joining Highgroove. Apart from these skills, Highgroove’s environment instills a feeling of pride in ones work. I write working code. I write great software. I write code that does not wake anyone up in the middle of the night. That is what Craftsmanship is all about to me.

With all of that said, the last year at Highgroove has been one of the most productive years of my professional life so far. I am very much so looking forward to what the next year will bring.

The post 1 Year of Highgroove: A Retrospective appeared first on Big Nerd Ranch.

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 post Highgroove Made Me Super Efficient And All I Got Was This Lousy Free Time??? appeared first on Big Nerd Ranch.

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

The post Salesforce on Rails with the Databasedotcom Gem appeared first on Big Nerd Ranch.

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

The post Simple Design, the Highgroove Way appeared first on Big Nerd Ranch.

At Highgroove Studios, we’re hyperspecialists in Ruby on Rails web application development. Not only do we write amazingly complicated code on time and on budget, but we follow up all our work with tests so we know our code works.

This is not without its problems however, as a test suite can become just as bloated and difficult to update as the code base it tests! This week, I’ll talk about some of the ways I’ve learned to approach writing tests.

Since I began working for Highgroove Studios back in April, I have been innundated with the importance of thorough and reliable testing. Given the culture of performance and quality at Highgroove Studios, I knew that I had to find a way through the maze of test frameworks and options.

After struggling with some very large, brittle test suites, it dawned on me that good test design, just like designing the application itself, was the key to success. Maybe challenging some of my own assumptions about testing was in order as well!

Once I realized that I needed to focus on writing better tests, instead of writing them faster and getting them to pass, I turned to Google and found some really good stuff that I wanted to share:

• Cucumber Blog
• Cucumber Issue Tracker on Github
• Cucumber Style Guide
• Essay on TDD and Agile methodology
• Rspec Best Practices

What all of this information made me realize was that I was trying to accomplish all of this with just a single test framework and certain ones align to Test Driven Development (TDD) and Acceptance Testing (BDD – Behavior Driven Development) better than others do. (Figure 2 in the AgileData link explains visually why I was wrong!)

After spending the time pondering my own practices, I decided to split apart the two tasks (BDD, and TDD) into Cucumber and Rspec tests, respectively. After making the switch from an all-or-nothing, single test suite mentality to a “use what works best” mentality I’ve seen both the quality and ease of coding of my test increase. Its amazing what happens when you stop trying to cram a square peg through a triangle hole!

I prefer both Rspec and Cucumber for TDD and BDD, but you might have a different method. If so, what is it and how does it make your day-to-day test writing simpler and more efficient?

The post Don't Settle on Just One Test Framework! appeared first on Big Nerd Ranch.

So you’ve got an awesome web application up and running. You want to keep your users engaged. You could try to handle collecting emails, writing your own newsletters, managing the list, keeping content fresh, tracking who read your messages, and so on (and so on) – all within your own app; however, there’s a better way. We recommend using Mailchimp. It’s actually very simple to integrate Mailchimp into your own Ruby on Rails application. Quick. Easy. DRY. Just the way we like it.

At Highgroove, we’re notorious for not wanting to re-invent the wheel. We LOVE using plugins, open-source libraries, ruby gems, and other external integrations in our apps. Mailchimp.com is one of those external services we regularly rely on.

A fairly common scenario is to collect user emails and send them a subscriber newsletter. We need all the basics: collect the email itself, ensure the email is real, send the actual newsletter on a certain schedule, and allow users to opt-out or change their email profile settings.

The first step to completing this online subscriber newsletter is to signup for Mailchimp.com. Once that is done, provide your API Key to us.

The second step is to create a List within Mailchimp. This List could be called “My Sites Newsletter”, for example.

The third step is to install the Gibbon gem. This is essentially a Ruby wrapper for Mailchimp.com’s own API.

Now that we’ve taken care of all the setup of Mailchimp, the next couple of steps will show you just how amazing Mailchimp.com and Gibbon really are:

On a basic level, all we need in the Rails application’s code is an HTML form that collects an email address and some code within a controller method to save the submitted email address to Mailchimp. We do this in two steps:

First, create your form (this example is a HAML template):

Two, in your controller, add a line like this:

Once you’ve done the above, your Rails app is fully integrated with Mailchimp! The content, frequency, and other settings that have to do with your newsletter are all controlled in Mailchimp’s very simple interface.

The only question you’ll have left at this point is “What cool feature can we add next?”

The post Email Marketing for your Rails App Made Easy With Mailchimp appeared first on Big Nerd Ranch.