Video's were recorded by a local videographer and are being hosted by Confreaks, LLC.
A musical selection for your enjoyment.
Ever have one of those days where you sit back at the end of the day and realize that you didn't get anything tangible done? Why do those days happen? Many times is it because we lack focus during the day to complete even the simplest of tasks. Our modern lives don't allow us to practice focus; in fact they conspire against us being focused. This talk will explain why focus is important to productivity and teach one way you can practice focus through meditation.
Michael Feathers will be giving the opening keynote this year at Rocky Mountain Ruby. Michael is well known in the software community for his work with XP/Agile, improving software development and working on large legacy codebases. Don't miss his opening remarks which will definitely be thought provoking.
The effects of API design will likely live with your project for a long time, often beyond your tenure with the project. Yet good API design is very rarely discussed and often leads developers to the conclusion that good APIs are something that "we know when we see them."
This talk will attempt to layout a set of fundamentals for good API design so that we can begin to really understand the difference between well-designed APIs and those that are mediocre. It will also explain about various trade-offs that are made when designing APIs and some of the pros and cons that come with each trade-off. Finally we'll take a look at some good APIs and bad APIs in Ruby.
REST is an architectural style for distributed systems. However, many implementations forget about the distributed part of REST and simply map CRUD operations to HTTP verbs in a monolithic application. We're gonna go further and learn why hypermedia is the crucial part of REST architectures and how machines can browse resources just like humans using self-describing representations.
Monolithic applications are boring, so let's separate things and create a REST system as it is intended to be. Let's build a simple system using the Roar gem, Rails and Sinatra and discuss the benefits and drawbacks we get from distributed hypermedia systems.
People often think of design as something that helps solve problems, but design should actually prevent problems in the first place. While you may not be a designer, applying tenets of design thinking to your life and work will help you make better decisions, build better stuff, and give you a framework to keep life and work moving forward.
You know how to raise and rescue exceptions. But do you know how they work, and how how to structure a robust error handling strategy for your app? Starting out with an in-depth walk-through of Ruby's Ruby's rich failure handling mechanisms -- including some features you may not have known about -- we'll move on to present strategies for implementing a cohesive error-handling policy for your application, based on real-world experience.
Ever wonder how software is designed and developed at GitHub? Are you curious about how new features are deployed to the site? (Hint: ask the robot.) Want to know why we don't have any managers and don't track vacation days?
This talk will explore running your company like an open source project and give some insight into how GitHub continues to leverage ruby and other open source tools to keep up with massive data loads and a growing community of users.
Many of us are familiar with the old adage about writing code "for people to read, and only incidentally for machines to execute" (thanks, Abelson and Sussman) - but it's easier said than done. The fields of object-oriented design, patterns, and software architecture are vast, but primarily concerned with the mechanical structure of code - what if we took a step back from the nuts and bolts of the code and look at the way we as humans read and write it? Can we use our understanding of the psychology of human cognition to better understand our target audience, and in turn write code that is more intuitive, readable, and maintainable? This talk will walk through some of the basics of cognitive psychology and relate them back to concrete ways that we as developers can optimize our code for high performance in the interpreter between our ears.
Learn how to go inside out vs. outside in so you can tap into your intuition to make strong decisions and come up with innovative solutions. It might just help you invent the next big thing rather than being the next Groupon clone.
At least since node.js everyone knows that real time HTTP responses are the next big thing. The secrets of handling incoming requests asynchronously with Ruby is not yet far spread among Rubyists, as the internals needed for such responses are neither specified nor documented and there is a lack of tools. Still, it is possible to use Server-Sent Events, WebSockets and akin with Rack today. This talk will demonstrate the underlying technologies and how to use them in your Ruby application.
In under two months, my team: * Learned all about Rails 3.1, Backbone.js, CoffeeScript, Sass, and CouchDB * Wrote a new application that deploys open source stacks in the cloud * Created some stacks (e.g., Rails, Tomcat, BIRT) * Went to production on Amazon EC2
The Ruby community is obsessed with testing, supposedly. In my experience about four out of five applications have either zero or completely ineffective test coverage.
Have the courage to change it. Whether your own projects or recovering someone else's mess, let's talk strategy:
* Starting with metrics
* Refactoring for understanding
* Comment-driven development
* The unit testing foundation
* Bug reports are your best integration tests
* Focusing on value
Rescue projects are popping up everywhere, and a strategic testing approach can save the day.
As Ruby continues to mature as a language, its use in large scale (enterprise!) codebases is expanding - and the need to integrate into larger architectures is already here. It is tempting to build networks of APIs in order to integrate applications, but there is an answer - messaging. This talk will reveal the benefits of messaging, and describe patterns that can be implemented at any level - from workers on single applications, to integrating separate codebases, all the way up to massive, concurrent service-oriented architectures that rely on messaging as the backbone. Prepare to be assaulted with an inspiring way to integrate and scale - and leave armed with the tools required to do so.
Cassandra is a highly scalable and fast database engine based on its column architecture. It's a powerful alternative to most RDMS systems. Adding it to Rails gives you a great way to get a scalable system with many rows that can grow to meet your needs.
As practitioners who comprise the Ruby software community, we have made great strides to establish testing as a best practice. We have done so in order to build quality into our processes and systems.
Now more than ever before, rich user interfaces are prevalent, and testing tools have made great strides; specifically with regard to Jasmine.
The purpose of our presentation is to provide fellow software developers with actionable knowledge of how to:
* Add Jasmine to your a
Seleniumâ€™s a wonderful tool for automating acceptance and functional tests; however, real-world implementations bring a lot of pain. I suffered all that pain, and more, as I piloted an effort that started out with Selenium IDE, moved through RC, and ended up with WebDriver. This talk covers things like setting up baseline data, creating backing test frameworks, dealing with brittle tests, and figuring out how to appropriately manage all those incredibly slow Selenium tests so that you actually get effective, useful testing in. Learn from my pain (and successes!) so that you donâ€™t have to suffer it in your own projects!
"A Documentation Talk" sounds pretty boring, right? Wouldn't it be scandalously titillating if this talk's title included detailed analysis of the expectations and results of the talk itself? Jeez it's like someone's making an overt metaphor for how Rubyists document their code.
At GitHub, we add docs to every single method we write, and we couldn't be more excited about it. It means faster and simpler code. It means stronger tests. It means your developers can pay attention to new commits without stressing about them. Documentation will make your project so very happy.