] At this year’s annual Clash of the Coders, I teamed up with Steve Sparks and Mark D to create Krëndler, a framework that can be added to any iOS application to record and play back a user’s touch events. Steve and Mark took care of the iOS aspect, while I created an API for them to use to store the touch event data they collected.

The problem

Leading up to the competition, we discussed what the schema of the JSON sent to the server might look like. While we were able to brainstorm some possibilities, we didn’t yet fully understand the domain or what would make the most sense for storage. In the face of this problem, I saw two reasonable solutions.

First, I could go the traditional Rails route and use a relational database. Since I wasn’t sure what the schema would be, I would be forced to store it in a text column or possibly leverage PostgreSQL’s hstore until I knew enough to be able to create matching models/tables/relationships for the data.

Alternatively, I could use a schemaless database. It would make setting up dead simple, but would be limiting later in development if I needed to query on embedded documents.

MONGODB to the rescue

This application was a prototype developed in a very short timeframe, so I made the choice that benefits developer time and went with MongoDB, with mongoid as the ODM. The great thing about this choice was that I could set up an endpoint for the client-side guys to store/retrieve JSON dumps of their touch event data without having to know anything about the data they were sending. As I needed to access data, I could set up just the fields and relationships I wanted at that moment. Through this process, the schema and the application grew organically together. And now that the JSON schema has stabilized, I have the information I need to make a more educated decision about how the data should be stored.

The next time you find yourself prototyping an application, consider if the advantages of a schemaless database will help you develop faster. However, don’t get too attached to your prototype—while MongoDB can help you get running faster, don’t force it to solve a problem that would be better handled by a relational database.

Editor’s note: Want to learn more about APIs and iOS apps? Patrick Van Stee led a great Tech Talk on HTTP API design for iOS apps, covering best practices for modeling resources, tools to help build APIs, and production and deployment-related problems.

The post Using an API to Back an iOS Application appeared first on Big Nerd Ranch.

Ruby ships with an Interactive Ruby Shell (IRB) that every Ruby developer has played around with at some point. It’s a great place to experiment with unfamiliar methods and running bits of code, but if you really want to dig into an object or do hardcore debugging, it can leave a lot to be desired.

Pry is a great IRB alternative that has a number of features that make it one of my must-have tools.

Pry has five features that make it great:

View the documentation or source for a method

You may often find yourself wondering about the difference between methods like #reject and #reject!, but you don’t feel that it warrants a full Google search. Pry provides a show-doc method that makes this painless:

If you’re working with your own code and want to take a quick look at the source, there’s also show-method:

Search your Pry history

Pry’s hist --grep makes it easy to search through your Pry history:

Edit and reload files

Rather than switch between Pry and your editor, you can use edit to open up a file for editing:

The only “gotcha” is that you need to make sure you specify your editor in a .pryrc file:

Additionally, the -t flag opens up a temp file, giving you a full editor to define a method, class or other ruby object, if you find doing it line-by-line in Pry to be too tedious.

Run shell commands

You can run shell commands by prepending the command with a ‘.’. This is great when you’re working on a gem and want to edit a file without leaving Pry:

Any command with a ‘.’ in front will be forwarded to the shell, so you could even commit your code from Pry.

Dive into objects

You can navigate around Ruby objects as if there were folders by using cd and ls:

ls is useful for when you forget the name of that variable you defined earlier, and cd can be useful for diving into objects.

Bonus!

This feature is available in IRb as well as Pry, but it’s something that I use very often:

These are just the highlights of Pry and some of the commands I use. You can find more information on the commands on the Pry wiki and by using the help command in Pry. If you’re looking for more help with debugging, make sure you check out Aubrey’s post on pry-remote.

These are my favorite Pry features—what are yours?

The post My Top 5 Pry Features appeared first on Big Nerd Ranch.

Highgroovers take test-driven design (TDD) seriously, but it’s easy to become overwhelmed by the number of tools available for testing applications. However, if you know us even a little, you know that we have a lot of experience using different tools–and that we’ve developed some opinions about them.

To help others narrow down the options, I asked a couple of developers here how they felt about the two most popular tools for acceptance-level testing: RSpec and Cucumber.

Approaches to TDD

If you’re unfamiliar with either of these tools, here’s a quick overview of their approaches to TDD:

Using RSpec for acceptance testing isn’t very different from using it for unit testing, except that the functionality is greatly extended by using capybara to interact with the browser. For example, to log in a user, the capybara bit might look like this:

Cucumber also uses capybara to drive the browser, but affords the use of steps like “login a user with name ‘bob’ and password ‘sekret’” that are far easier to read than the more procedural steps used by RSpec.

The differences come down to readability

Because both RSpec and Cucumber require capybara to interact with the browser, you might wonder how different they could really be. The difference comes down to readability. Cucumber is often sold as a way of letting a (technically-inclined) client write the cuke to describe some very high-level functionality:

Behind this are step definitions that tell Cucumber what each step means:

I should note that while it’s possible for a client to write the features into cukes, doing so usually doesn’t work out well. Cucumber uses high-level language to describe interactions, but is more coupled to the implementation than a service like Pivotal Tracker. Asking a client write all of the cukes will likely result in the developer having to rewrite or tweak the cukes so that they make sense from a design perspective.

That said, the pros and cons of Cucumber already become apparent. On the one hand, Cucumber tests can be incredibly readable. By focusing on high-level functionality and using domain-specific terms, it is a quick way to answer the “What does this app do again?” question with minimal effort. On the other hand, you have to write the step definitions so Cucumber knows what to do with the English-worded steps, and there’s a second layer to your test that has to be maintained.

In contrast, RSpec favors more low-level details. For example, the same cuke above may look like this if writen for RSpec:

While the spec isn’t as inherently readable as the cuke, my example doesn’t fully show how RSpec can (and should) be used. It’s easy to add a helpers module to your spec_helper to transform the previous spec into something more easily read:

Using a technique like this makes RSpec seem a bit more like Cucumber, so you might wonder why you would bother to take the additional steps. The Highgroovers I spoke with are willing to put in a little more effort with RSpec so that they’re able to stick with one tool throughout.

Tools don’t make bad tests, developers do

No matter which tool we prefer individually, everyone here agreed that tools aren’t what create bad tests–the person writing the test (and the application) lead to bad tests. Regardless of whether you prefer Cucumber or RSpec, it’s important to follow good design principles.

What are your favorite testing tools and what led you to pick them over the other options?

Image Credit: The image appears in Susan Herbert’s The Catropolitan Opera. Via syrupofwahoo.

The post Highgroove Face-off: Acceptance testing with RSpec versus Cucumber appeared first on Big Nerd Ranch.

Often times the state of an object is tracked through boolean attributes, but this solution doesn’t scale well since each new state requires a new column in the table along with logic to govern how the states change. If you have a model which you need to track the states of, the state_machine gem can be a great solution. It stores the state of the object in a string-type column (state in the example below), and adding states and transitions is as easy as adding a couple lines of code to the model.

Here I’ve created a ruby model to describe my dogs.

So with this in place we can fire up irb and create a new instance of the Dog class:

As you can see, since we set initial: :sleeping as an argument in the call to state_machine all new instances are created with the state of "sleeping". One of the nice features of state_machine is how easy it is to define events and how states should change as a result of calling an event. For example, gonzo is sleeping now, so let’s see if we can go for a walk:

state_machine provides nice helper methods named can_<event name>? in order to check if calling the event has a transition defined for the current state. Since gonzo’s asleep, he can’t go for a walk, so if we try calling gonzo.walk we get false. First things first, we have to wake him up before taking him on a walk:

When declairing a state, you can pass it a block to define other methods as I’ve done with the hungry method. Since a dog is willing to have a cheese-snack any time of day, we can use the following to return true for that method call when in any states other than “sleeping”.

While this example is obviously a simple case, it’s easy to see how this approach scales well to more complicated state relationships. The state_machine gem integrates with a number of libraries including ActiveModel classes, ActiveRecord models, DataMapper resources and Mongoid models. Another feature that some may like is its support for generating a directed graph using the graphviz library. If you ever need to track the state of a record, state_machine is definitely worth a look. What’s your preferred method for tracking states?

Image is my own (it’s Gonzo).

The post Managing States using state_machine appeared first on Big Nerd Ranch.

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

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

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

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

Image from Flickr user windy_

The post So you thought ROWE would be easy? appeared first on Big Nerd Ranch.