February 2015 marks the tenth anniversary of DHH sharing commit rights to Rails. Doubtless there is now much legacy Rails code. Why do developers typically hate legacy code? What characteristics of a Rails application earn it the right to be classified as "legacy"? Whilst these should not be difficult to answer, perhaps there are more important and challenging questions that we ought to consider. How can we learn to love legacy code so that it, in turn, becomes more loveable? What practical steps can we take to tame a legacy codebase so that it becomes more of a pleasure to work with?

You've learned about Service Oriented Architecture. You want to use it. You know the benefits to testing speeds, to team velocity, and page load (why do in sequence what can be done in parallel?). Problem is, you're tearing your hair out trying to figure out how to actually pull those services out of your monorail.

This isn't about the metrics to determine what should be pulled out into a service. This talk isn't even about optimizing the service you pull out. This talk is a step-by-step approach about how to successfully pull a service out of an existing app and optimizing its performance.

Matz announced in his RubyConf 2014 keynote that Ruby 3.0 might have a static type system. What does that really mean? How should we feel about it? Will Ruby 3.0 still be Ruby? In this talk I’ll unpack what Matz said and make some educated guesses about what it means for the future of Ruby.

Two thirds of honeybee hives have died out in Virginia. Is it possible for us to devise a way of monitoring beehives in remote locations to find the cause? Enter a raspberry pi + rails. Using a combination of this robust hardware and software solution, we were able to successfully track, monitor and provide real time reporting on the well-being of hives from across the county. Find out how we used ruby, rails, solar panels and other libraries to provide insight into this problem.

Do you need Ops in your new startup? If not now, then when? And...what is Ops?

Learn how to scale ruby-based distributed software infrastructure in the cloud to serve 4,000 requests per second, handle 400 updates per second, and achieve 99.97% uptime – all while building the product at the speed of light.

Unimpressed? Now try doing the above altogether without the Ops team, while growing your traffic 100x in 6 months and deploying 5-6 times a day!

In the 1980's, Nintendo had plans for making a knitting add-on to the NES, with an interface that resembled Mariopaint, but with patterned mittens, sweaters, and scarves as output. Sadly, this product never saw the light of day. Devastated upon hearing this and dreaming about what could have been, a group of engineers (who knew nothing about machine knitting) set out to hack a knitting machine from the 1980's to be computer-controlled, using a tutorial from adafruit as a starting point.

Mention the word architecture and you're sure to hear criticism about the difference between waterfall and agile processes. Spending time on extensibility? You ain't gonna need it, they say. Worried about speed? Cries of premature optimization ensue. But that MVP you're building is going to form the core of a business solution that will presumably last for years. Short-sightedly painting yourself into a corner is not a good way to start it off. But it doesn't have to be a choice between cowboy coding and analysis paralysis. We can take a step back and explore ways to budget for basic architecture, plan for the future, lay the foundations for growth, and avoid becoming riddled with technical debt.

Australia's had a vibrant nation wide Ruby community for a good 7 years now. We're definitely well into the second act of our story arc, but what does that mean? Where do we want the community to go from here? Is there something special about the Ruby & Rails platform and community that can give us a unique third act?