This is the first part of a series. Here are the other posts:

http://jeffmason.me/rails-phoenix-live-polling-part-1/ http://jeffmason.me/rails-phoenix-live-polling-part-2/ http://jeffmason.me/rails-phoenix-live-polling-part-3/

This is where tools like https://www.nitrous.io are awesome. We just hosted a RailsBridge-type event and we used Nitrous. Highly recommend this for teaching.

Here's my article about getting started with Rails on Nitrous.io:

http://railsapps.github.io/rubyonrails-nitrous-io.html

Nitrous.io is a great way for any beginner to get started, especially for those using Windows.

Nice! Open sourcing this is a great idea, Emerson.

Thanks, I think its the only way that we have a chance being a success.

Nope, that's it. We do have experimental internal apps we build in other languages, but most of our work is Rails apps.

Because of the reasons in the post, but mainly our design team. I didn't want to set up a WordPress instance and make them learn the intricacies of php and WP theme system. They already understand the Rails folder structure, Sass, Haml and all the other tools we use.

tl;dr: it made collaboration easier.

I'm going to agree on your point as well. Designing with things like WordPress, Tumblr, etc become a major pain quickly. Especially considering the speed at which you can design with a bare rails app.

It's painful. I hoped that an engine existed, but nothing fit our workflow. This seems like a good starting point, though. Maybe we'll convert to an engine and see how reusable it might be.

An engine would make some sense. I'd be interested in collaborating if you decide too: https://github.com/danawoodman

I used errbit for a while and it was losing stacktraces ;(. Wound up using https://github.com/getsentry/sentry and am much happier.

QCMerge is intentionally different than most conferences. We don't focus on a particular language or framework. It's about everything that goes into building a successful product.

The observations in the article are things we noticed after two years of the event. We didn't set out to "attract more women," but rather to attract more people.

This is a struggle, for sure. We want to keep them consistent but we also want to make sure we're keeping things moving. They shouldn't be a checklist, but actual features, too. Timeboxing work is the only workable solution I can see.

Page objects are the best things to happen to my cuking. Step definitions are a couple of lines at best and I'm dealing with a real Ruby object instead of some node from Capybara. I'm excited about Cucumber again.