This year I was fortunate enough to be able to attend RailsConf for the first time in my ~7 years of on-and-off Rails development. It was an awesome experience overall, especially because I was joined by 13 of my remote, Articulate teammates!

Articulate Co-Working Space

Since the conference started on Tuesday, we decided to arrange for a co-working space on Monday in the Jitterbug room at the Catalyst Ranch. It was an incredibly energizing and creative environment with fantastic hospitality.

We spent our time reviewing the progress and state of our projects, discussing better ways to share common code across project teams, and of course, attempting to solve the ever-challenging problems with caching.

A few of us were asked if we wanted to give lightening talks over the lunch hour, I agreed and was initially prepared to give a fun talk on Sass, but then teammate inquisition inspired me to make a last-minute transition to the topic of BEM instead. Considering I threw together my slides in about 20 minutes, I’d say it went pretty well. :)

Best of Sessions

Advanced aRel: When ActiveRecord Just Isn’t Enough | Video | Slides
Cameron Dutro

So, prior to starting with Articulate, I had been on a ~3 year hiatus from the world of Ruby On Rails. When I left off (at MetaSpring), I had been working in Rails 2. Starting up at Articulate, I entered the world of Rails 3 and 4. Needless to say, there were a few significant changes between Rails 2 and 3, so jumping back in was kind of like learning Rails all over again.

One thing about Rails 2 that I remember was having to manually write complex SQL queries to get around ActiveRecord’s inefficient join methods. It turns out that a lot of people still do this in Rails 3 and 4, simply because they don’t know about aRel – which allows us to compose complex queries in a purely object oriented fashion. And it’s no surprise that people don’t know about aRel – it’s horribly (read, barely) documented.

aRel can be complicated and challenging to remember the syntax, so Cameron built an awesome tool, Scuttle.io, that allows you to paste in an SQL query and generate an aRel version of the query. Pretty freaking impressive.

Panels: The Future of Rails Jobs AND Teaching The Next Great Developers | Video

The next highlight of the sessions, for me, was based around the future of the tech industry – specifically, jobs in the rails community and producing the next generation of developers – a topic that is pretty relevant to me as I launch a new chapter of Girl Develop It in Ann Arbor. There was SO much great content and bit of overlap between the panels, so I’m just going to give you the bullet point highlights of both…

  • Developers need to learn how to learn, and learn fast.
  • Developers need to be able to admit when something doesn’t click and find help.
  • A good way to build confidence and avoid impostor syndrome is through humility – working with people newer to code than you, remembering what it was like, and being comfortable with the notion that, “Yes, this is hard.”
  • Teams that build up people tend to keep those people.
  • Collaborate, pair, mentor, be mentored, lead.
  • Make mistakes and learn from them.
  • Set reasonable goals, reassess them on occasion. It’s ok to pivot!
  • If you’re a teacher or mentor, aid students through the job search, help them prep for interviews, and make sure they’re aware of non-dev technical jobs (PM, BA, QA, etc.)

All the Little Things | Slides
Sandi Metz

I had never seen Sandi talk before, nor have I read any of her books yet, but after hearing her speak about refactoring like a pro at RailsConf, she’s definitely one of my new role models.

I loved her “squint test” approach to identifying code smells – if you squint and see many differing levels of indentation, you’ve likely got too many conditions and thus complexity; if you squint and see different syntax highlighting colors all over the place, you’ve likely got too many differing types of abstraction. In refactoring, aim to reduce this indentation and group like colors together.

Another great point she made was to refactor through complexity – you’re not going to go from bad => good in one step, it’s going to be messy in the middle, but you have to keep going. Without realizing it prior, this is definitely something that I already do! :)

And lastly, she pointed out that, “duplication is far cheaper than the wrong abstraction.” So don’t try to abstract too early, before you truly understand where the abstraction is needed.

Bring Fun Back to JS: Step-by-Step Refactoring Toward Ember | Slides | Video (from MountainWest JS)
Brandon Hays

This talk was, without a doubt, one of the most entertaining, passionate, and inspirational talks of the entire conference. He started out by conveying the common occurrence of temporary code made permanent; of a light sprinkle of application JS that turns into tsunami of spaghetti code when developers get new feature requests and just “agile that code” right in. He coined terms like “cloudgineering”, “craftsmanshipping”, and “clouditecture”. It was glorious.

After heading down the rabbit hole, Brandon took us on a journey through the world of refactoring and Ember.js – showing us step by step how to convert your agiled code into a robust, flexible, and scalable framework with Ember.js.

He closed by very humbly thanking the community for being so supportive as he found his way from being a timid beginner in the industry 4 years ago, to the confident speaker that he is today.

Girl Develop It Chicago Connections

Finally, I must mention the awesome ladies of Girl Develop It Chicago whom I was fortunate enough to spend some time with during the conference. The co-founders, Liz Abinante and Kathryn Exline, were a wealth of knowledge for me while I flooded them with questions and how-to’s regarding the start up of our local GDI chapter in Ann Arbor.

I’ve spent a lot of time with the Detroit chapter and am familiar with how they work, but since Ann Arbor is such a different demographic, we (co-organizer, Ronda, and I) didn’t have a solid idea of where to go with the group and how to approach the knowledge diversity in the area. Chicago seems to be much more of a parallel to Ann Arbor, so hearing about how they plan and the types of a events they put on gave us a lot of fuel to run on.

I was even fortunate enough to attend a fantastic RailsConf speaker event that they put on and was gifted with a set of stickers to hand out at our Ann Arbor launch party on June 4th!

Overall, RailsConf was a blast and I hope to make it out again next year. Of course, the people are really what make any conference an excellent experience, and the Rails community was no exception. New friendships were forged, old friendships were strengthened. Good times were had all around. Until next year!