Gregg Rothmeier - Big Nerd Ranch

Using an API to Back an iOS Application

Mon, 12 Aug 2013 16:35:59 +0000

] 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.

]]>

My Top 5 Pry Features

Thu, 08 Nov 2012 12:00:00 +0000

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:

	pry(main)> show-doc Array#sort!

	From: array.c (C Method):
	Number of lines: 9
	Owner: Array
	Visibility: public
	Signature: sort!()

	Sorts self. Comparisons for
	the sort will be done using the <=> operator or using
	an optional code block. The block implements a comparison between
	a and b, returning -1, 0, or +1. See also
	Enumerable#sort_by.

	a = [ "d", "a", "e", "c", "b" ]
	a.sort #=> ["a", "b", "c", "d", "e"]
	a.sort {\|x,y\| y <=> x } #=> ["e", "d", "c", "b", "a"]

view raw gistfile1.rb hosted with ❤ by GitHub

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

	pry(main)> def foo
	pry(main)* puts "Welcome to the foo!!"
	pry(main)* end
	=> nil
	pry(main)> show-method foo

	From: (pry) @ line 3:
	Number of lines: 3
	Owner: Object
	Visibility: private

	def foo
	puts "Welcome to the foo!!"
	end

view raw gistfile1.rb hosted with ❤ by GitHub

Search your Pry history

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

	pry(main)> hist --grep foo
	2: def foo
	3: puts "Welcome to the foo!!"
	5: show-method foo

view raw gistfile1.rb hosted with ❤ by GitHub

Edit and reload files

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

	pry(main)> edit dog.rb

	# opens up vim where I add:
	#
	# class Dog
	# def bark
	# puts "Woof!"
	# end
	# end

	pry(main)> my_dog = Dog.new
	=> #
	pry(main)> my_dog.bark
	Woof!
	=> nil
	pry(main)> edit dog.rb

	# opens up vim and I change it to:
	#
	# class Dog
	# def initialize(bark)
	# @bark = bark
	# end
	#
	# def bark
	# puts @bark
	# end
	# end

	[8] pry(main)> his_dog = Dog.new("Rufff!")
	=> #
	[9] pry(main)> his_dog.bark
	Rufff!
	=> nil
	pry(main)> .ls \| ack dog
	dog.rb

view raw gistfile1.rb hosted with ❤ by GitHub

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

Pry.config.editor = 'vim'

view raw gistfile1.rb hosted with ❤ by GitHub

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:

	pry(main)> .cd ~/code/rspec
	pry(main)> .ls
	Gemfile License.txt README.md Rakefile lib rspec.gemspec
	pry(main)> .pwd
	/Users/greggory/code/rspec

view raw gistfile1.sh hosted with ❤ by GitHub

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:

	pry(main)> my_array = [1, 2, 3, 4, 5]
	=> [1, 2, 3, 4, 5]
	pry(main)> ls
	self.methods: include private public to_s
	locals: _ _dir_ _ex_ _file_ _in_ _out_ _pry_ my_array
	pry(main)> cd my_array
	pry(#):1> ls
	Enumerable#methods: all? any? chunk collect_concat detect each_cons each_entry each_slice each_with_index each_with_object
	entries find find_all flat_map grep group_by inject max max_by member? min min_by minmax minmax_by none? one?
	partition reduce slice_before sort_by
	Array#methods: & * + - << <=> == [] []= assoc at clear collect collect! combination compact compact! concat count
	cycle delete delete_at delete_if drop drop_while each each_index empty? eql? fetch fill find_index first flatten
	flatten! frozen? hash include? index insert inspect join keep_if last length map map! pack permutation place pop
	pretty_print pretty_print_cycle product push rassoc reject reject! repeated_combination repeated_permutation replace
	reverse reverse! reverse_each rindex rotate rotate! sample select select! shelljoin shift shuffle shuffle! size slice
	slice! sort sort! sort_by! take take_while to_a to_ary to_s transpose uniq uniq! unshift values_at zip \|
	self.methods: __pry__
	locals: _ _dir_ _ex_ _file_ _in_ _out_ _pry_
	pry(#):1> cd ..
	pry(main)>

view raw gistfile1.rb hosted with ❤ by GitHub

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:

	pry(main)> [1, 2, 3, 4]
	=> [1, 2, 3, 4]
	pry(main)> a = _
	=> [1, 2, 3, 4]
	pry(main)> a
	=> [1, 2, 3, 4]

view raw gistfile1.rb hosted with ❤ by GitHub

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.

]]>

Highgroove Face-off: Acceptance testing with RSpec versus Cucumber

Thu, 30 Aug 2012 11:00:00 +0000

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:

	fill_in "Username", with: "test_user"
	fill_in "Password", with: "secret"
	click_button "Login"
	page.should have_content "Signed in!"

view raw gistfile1.rb hosted with ❤ by GitHub

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:

	Feature: Search courses
	In order to ensure better utilization of courses
	Potential students should be able to search for courses

	Scenario: Search by topic
	Given there are 240 courses which do not have the topic "biology"
	And there are 2 courses A001, B205 that each have "biology" as one of the topics
	When I search for "biology"
	Then I should see the following courses:
	\| Course code \|
	\| A001 \|
	\| B205 \|

view raw gistfile1.feature hosted with ❤ by GitHub

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

	Given /there are (.) courses which do not have the topic \"(.)\"/ do \|number, topic\|
	number.times { \|n\| Course.create!(topic: 'something else' }
	end

view raw gistfile1.feature hosted with ❤ by GitHub

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:

	describe "Search courses" do
	it "by topic" do
	240.times { Course.create! }
	Course.create!(topic: "biology", name: "A001")
	Course.create!(topic: "biology", name: "B205")
	visit search_path
	fill_in "Search", with: "biology"
	click_button "Search"
	page.should have_content "A001"
	page.should have_content "B205"
	end
	end

view raw gistfile1.rb hosted with ❤ by GitHub

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:

	describe "Search courses" do
	it "by topic" do
	create_course_catalog
	create_biology_courses("A001", "B205")
	search_for('biology')
	page.should have_content "A001"
	page.should have_content "B205"
	end
	end

	# in spec/support/request_helpers.rb
	module RequestHelpers
	def create_course_catalog
	240.times { Course.create! }
	end

	def create_biology_courses(*names)
	names.each { \|name\| Course.create!(topic: "biology", name: name)
	end

	def search_for(query)
	visit search_path
	fill_in "Search", with: query
	click_button "Search"
	end
	end

	RSpec.configure do \|config\|
	config.include RequestHelpers, type: :request
	end

view raw gistfile1.rb hosted with ❤ by GitHub

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.

]]>

Managing States using state_machine

Sun, 03 Jun 2012 11:00:00 +0000

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.

	class Dog
	attr_accessor :name, :status

	def initialize(name)
	@name = name
	super() # Required by state_machine to initialize states
	end

	state_machine :state, initial: :sleeping do

	event :wake_up do
	transition :sleeping => :home
	end

	event :hear_something do
	transition all => :barking
	end

	event :walk do
	transition all - :sleeping => :walking
	end

	event :go_home do
	transition :walking => :home
	end

	event :go_to_sleep do
	transition all - :walking => :sleeping
	end

	state :home
	state :barking
	state :walking

	state :sleeping do
	def hungry?
	false
	end
	end

	state all - [:sleeping] do
	def hungry?
	true
	end
	end
	end
	end

view raw gistfile1.rb hosted with ❤ by GitHub

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

	> gonzo = Dog.new('Gonzo')
	=> #
	> gonzo.state
	=> "sleeping"

view raw gistfile1.rb hosted with ❤ by GitHub

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:

	> gonzo.can_walk?
	=> false
	> gonzo.walk
	=> false
	> gonzo.state
	=> "sleeping"

view raw gistfile1.rb hosted with ❤ by GitHub

state_machine provides nice helper methods named can_? 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:

	> gonzo.wake_up
	=> true
	> gonzo.walk
	=> true
	> gonzo.state
	=> "walking"

view raw gistfile1.rb hosted with ❤ by GitHub

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”.

	state :sleeping do
	def hungry?
	false
	end
	end

	state all - [:sleeping] do
	def hungry?
	true
	end
	end

view raw gistfile1.rb hosted with ❤ by GitHub

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.

]]>

So you thought ROWE would be easy?

Mon, 07 May 2012 11:00:00 +0000

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.

]]>