The 4th Annual Rocky Mountain Ruby Conference, held in Boulder, Colorado in 2013.
When smoothing wood with a hand plane, you should always work with the grain rather than against the grain.
It's becoming increasingly clear that what we normally think of as rationality is fairly rare. Much of what we do is governed by our brain operating on autopilot. Reasoning is the expensive stop-gap our brain uses (sometimes!) when the cheaper solution isn't working right.
Programming is typically seen as an occupation that requires thoughtful precision and rationality: we will work against the grain of our brain. The resulting nicks and chips are only evidence that we should try harder!
What if we try to work with the automatic part of the brain, rather than against it? In this talk, Brian Marick will discuss how he tries to do just that.
A detailed, deep-diving, in-the-deep-end and occasionally humorous whirlwind introduction and analysis of a suite of modern (and delightfully archaic) database technologies. How they work, why they work, and when you might want them to work. For no extra charge I will attempt to explain the oft-misunderstood CAP theorem, using databases as a device for understanding the trade offs and compromises inherent in building complex distributed systems.
Including but not limited to:
We as rubyists tend to write software that runs on the web, without a deep understanding of what it would take to write the plumbing for that same software. I think it's useful to have a basic understanding of how some of the lower level components of a system work.
I'll discuss the basics of systems programming, using Ruby. I'll talk about syscalls and kernel space vs user space. I'll cover a bit about file descriptors and what they're for. And hopefully I'll walk through a small example of a working webserver using those primitive syscalls.
In the beginning was the static resource, and it was good. It was easy to reason about. It was easy to host, once you got over the hurdle of getting an internet connection and installing a web server. It just wasn't very... dynamic. So we started a journey to build increasingly dynamic web sites. This leads to increasingly complex infrastructure used to host what are basically content-only web sites.
Middleman allows us to return to simpler days by building data driven sites. It provides elements that Ruby on Rails developers are familiar and comfortable with such as layouts, templates and partials. Amazon S3 gives us a great, highly available and very cost effective way to host the resulting site.
This talk will focus on how to use Middleman to build a data driven site and publish it to S3.
Rails is a great framework for creating web apps... for awhile. What do you do when your codebase grows large? How do you handle large teams of developers? When performance becomes an issue, how do you scale? Most importantly, how do you write code which can easily be refactored later?
This is a story of a real life project built from day 1 with all these questions in mind. Learn about the problems we solved and lessons we learned: how to partition your Rails app into distinct modular engines, how to speed up your test suite by only running code effected by your changes, how to add a layer on top of ActiveRecord to enforce loose coupling, and many other patterns that can be applied to your own Rails apps!
Rails is a framework well known for ease of development. This ease is achieved by a lot of 'magic' that happens behind the scenes. One of pitfalls of such magic is a false sense of safety it gives, including sense of safety from concurrency issues for single-threaded environments. You may never discover any problems before the launch, or even after, while your site traffic is pretty sparse. But here comes a glorious moment of popularity - and together with more traffic it brings more and more concurrency-related problems.
In this talk we will look at different aspects of concurrency, from simple ones that are even mentioned in Rails documentation, to more complex problems that even seasoned developers tend to miss or fail to pay sufficient attention to.
This is the story of Ruby at Square. As Square grew, we invested heavily in a service oriented architecture (SOA) and mainly used Java as our language of choice for new service development. Recently we finished a project, named Minecart, to deeply tie Ruby applications into our Java service infrastructure. To accomplish this we had to dive into the bowels of JRuby. To date, Square is roughly around 50/50 Java services vs Ruby services and everyone enjoys the benefits of a standard ecosystem. I will share many of our learnings along with a couple of practical examples and pitfalls for integrating Ruby into a custom Java framework.
It's not your fault. Code rots. We don't hold entropy against you, but we expect you to give a damn.
This story is about code that brings new meaning to the word 'legacy'. The accidental discovery of this body of code provoked a moral crisis. I wanted to pretend I hadn’t seen it, yet I couldn't justify tiptoeing quietly away.
This talk examines the dilemmas we face when balancing our choices today with their cost tomorrow.
It's not your fault. Even so, it is your responsibility.
At Rocky Mountain Ruby 2012, Mike Gehard hosted a Growing Developers Panel which discussed how senior engineers, companies and code schools can help alleviate the shortage of quality software developers.
Two to three months before the conference, Comverge had one Junior engineer on staff, but no formal training/mentorship program. Since that conference, we have hired an additional junior engineer and put both of them through our Junior Engineer program.
This talk will cover the process Comverge uses when bringing on Junior software engineers, from interviewing techniques to on boarding and the first couple months of on the job training. This training includes Pivotal Tracker, Git branching strategies, learning to love pull requests, TDD, BDD and learning our products.
Go has rapidly built a reputation as a great language for web development. But as Rubyists, we already have a great web development language -- why should we be interested in Go?
After using Go at Braintree, I’m convinced that every web developer would benefit from exposure to the Go programming style, which emphasizes small, composable packages and up-front error handling.
In this talk, we will:
Compare idiomatic approaches to common problems such as error handling and program organization in Go and Ruby.
Tease out common ideas and best practices that apply to all web applications, regardless of language or framework.
Read a bunch of code.
We will not:
Try to convince anyone to ditch Ruby and embrace Go.
Make vague, unsubstantiated claims about the benefits of static or dynamic typing.
Assume prior knowledge of Go. In order to make informed comparisons with Ruby, I'll go over the basics of the Go language, but explaining Go won't be the focus of this talk.
It's been scientifically proven that more diverse communities and workplaces create better products and the solutions to difficult problems are more complete and diverse themselves. Companies are struggling to find adequate talent. So why do we see so few women, people of color, and LGBTQ people at our events and on the about pages of our websites? Even more curiously, why do 60% of women leave the tech industry within 10 years? Why are fewer women choosing to pursue computer science and related degrees than ever before? Why have stories of active discouragement, dismissal, harassment, or worse become regular news?
In this talk we’ll examine the causes behind the lack of diversity in our communities, events, and workplaces. We’ll discuss what we can do as community members, event organizers, and co-workers to not only combat this problem, but to encourage positive change by contributing to an atmosphere of inclusivity.
Objectives: -Educate about the lack of diversity and why it is a problem -Examine what is contributing to both the pipeline issue as well as attrition -Isolate what is and isn't working -Inspire direct action by examining our own behavior and learning more about the people around us so we can empathize better
You’ve heard the claims or know from experience that test-driven development (TDD) produces better code. Perhaps you’ve also heard that to write better code you should be following the SOLID principles. Is there a connection between practicing TDD and writing SOLID code?
In this talk, I’ll use examples gleaned from real life to demonstrate how TDD prompts us to produce code that conforms to the SOLID principles, and how the SOLID principles are where we should turn when our tests are causing us pain. In doing so, we’ll learn what each principle really means and why it’s valuable.
Mike Nicholaides has been a Rails consultant since 2006 and has always obsessed about writing clean, clear, and concise code. He organizes the Code Retreat in Philadelphia where the focus is on learning TDD, communicating with code, and of course, having fun.