Jacob Burkhart jacobo

Title:

Being Present

Abstract:

Do you ever get distracted by a persistent bug in production while hurtling towards the ground at 122 mph?

Find it easy to think about CSS while sweating through an intense vinyasa flow yoga class?

Title:

Testing: The Hard Parts

Abstract:

The thing about sour beer is, it’s all about off-flavors. There is a variation of flavors and funk that would be undesirable, if not for the label of sour.

A similar license is granted to the test author. The tolerance for crazy goes way up. And sometimes, the crazy part is also the genius part.

Title:

Clever ideas from 2 years ago

Abstract:

In Late September, 2010, I left my job in Boston at 3M and moved across the country to work at Engine Yard in San Francisco.

I brought with me a collection of 40 open source repositories I had extracted from my work. I thought they would be invaluable, but I didn’t use a single one.

README-driven development is great. But what about a development-driven README? What if your README included coded snippets automatically pulled from your code? I've done it both ways, and I have an opinion!

Let's have a philosophical argument about it. Then I'll show you how I've implemented it in my case. And then we can argue implementation!

Building an API can be hard, but thanks to my mistakes: YOU TOO can write a sensible easy to maintain HTTP/JSON API for your product.

I don't have all the answers, but I've spent the last 9 months writing 2 interconnected APIs. We've re-written some parts, thrown some away, and turned others into open source libraries. I've been thankful for some decisions, and cursed for others.

Altogether we've learned a lot.

Let's review the process we took, and how I would do it differently next time.

	class Array
	def rand
	self[Kernel.rand(self.size)]
	end
	end

	module Lisonja
	class PartiallyStolenComplimentGenerator
	VOWELS = ['a', 'e', 'i', 'o', 'u']
	ADJ1 = ['elegant', 'hearty', 'beautiful', 'fine', 'fabulous', 'pretty',

	1 min:

	~Painless Javascript
	koting hatduklgg
	with wind tunnel

	~tenderlove.dup jremsikjr

	~iwanttolearnruby.com
	(collecting resources for learning ruby)

	You know JSON and REST
	You know Sinatra and Rack and RestClient
	But do you really know... how to build an API?

	Let's get to the Meat.
	How to build and test your API server and client at the same time.

	Your server should run your client tests.
	Your client test should run against your real server.
	Your client should ship with a fake that makes tests against it easy for integrators.

	1.8.7 gem-release [master]$ bundle
	Using gem-release (0.1.3) from source at .
	Using metaclass (0.0.1)
	Using mocha (0.10.5)
	Using test_declarative (0.0.5)
	Using bundler (1.0.21)
	Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
	1.8.7 gem-release [master]$ bundle exec ruby -Ilib test/gemspec_test.rb
	Loaded suite test/gemspec_test
	Started

	It's all well and good to learn about the principles of REST. And It's interesting to read about HATEOAS. And It's great to be able to look a the example of APIS like Twitter, Twilio and Amazon. But what happens you actually try to go and implement something. Where does it get tricky.

	You might guess that you have to compromise a few principle for the sake of pragmatism. But what else?

	I've spent the last nine months working on the Engine Yard Platform Services API. I can at least tell you about the hard parts for me. Where do you start, is a big one. How do you test, is another. The answers may surprise you.