Videos provided by Ruby Conf Australia via their YouTube Channel
Corey Haines helps developers improve their fundamental software design skills through the use of focused-practice events, such as coderetreat. He trains teams on development technical practices, and builds projects and products when not on the road.
(apologies for the poor audio)
New Relic recently made the big move to Ruby 1.9.3 which showed meaningful improvements over 1.8, particularly in garbage collection. So this talk is taking a look at what changed in Ruby's garbage collection that caused much of the improvements. We will start with the fundamentals of garbage collection but work down to the nitty gritty C code to get to the details of what's going on, starting with rb_newobj(). You should walk away with an understanding of how garbage collection works in MRI and a nice appreciation for the overall lifecycle of Ruby objects.
Most developers know enough about refactoring to write code that's pretty good. They create short methods, and classes with one responsibility. They're also familiar with a good handful of refactorings, and the code smells that motivate them.
This talk is about the next level of knowledge: the things advanced developers know that let them turn good code into great. Code that's easy to read and a breeze to change.
These topics will be covered solely by LIVE CODING; no slides. We'll boldly refactor right on stage, and pray the tests stay green. You might even learn some vim tricks as well as an expert user shows you his workflow.
* The Open-Closed Principle
* The types of coupling, and their dangers
* Why composition is so damn great
* A powerful refactoring that Kent Beck refers to as "deep deep magic"
* How to destroy conditionals with a NullObject
* The beauty of the Decorator pattern
* Testing smells, including Mystery Guest and stubbing the system under test
* The stuff from the last halves of Refactoring and Clean Code that you never quite got to :)
A fun code analysis.
How many companies are hiring Ruby developers right now? How many are finding qualified candidates? Why aren't workers swarming into our industry to fill up all these empty developer positions? Is learning Ruby really that hard? Why is learning Ruby so hard? Isn't it a language built by people for people? Shouldn't that be easy for anyone to pickup and use? Why isn't everyone building Ruby apps? I'm going to tell you. The good, the bad, and the goofy of trying to teach Ruby, Rails, and everything else we take for granted as RoR developers. There may even be a guest appearance from a real life Ruby Newbie to demonstrate!
Heroku has deployed millions of web apps. When you've run that many applications, it's hard not to notice when frameworks and developers do things wrong, and when they do them right. We've taken a look at the most common patterns and boiled down the best of our advice in to 12 simple factors that can help you build your next app to be stable, successful, and scaleable. After this talk you'll walk away with in depth knowledge of web framework design patterns and practical examples of how to improve your application code.
If you've ever done anything in ruby, you've probably used rubygems and to search or install your favorite gem. On October 17, 2012, rubygems.org went down. A Dependency API was built to be used by Bundler 1.1+ to speed up bundle install. Unfortunately, it was a bit too popular and the service caused too much load on the current infrasture. In order to get rubygems.org back up the API had to be disabled. You can watch the post-mortem for details.
Members in the community stepped up and built a compatible Dependency API service called the Bundler API. Working with the rubygems.org team, we were able to bring the API up for everyone within a week. In this talk, I will cover the process we went through of extracting the API out into a separate Sinatra app that now runs on Heroku. I'll go over how the API works and how Bundler itself uses it. Since we don't have direct access to their database, we needed to build a syncing service to keep our local cache up to date. We'll discuss the original sequential implementation of the sync code and how we improved performance through the use of a consumer thread pool. The sync time down was cut from 16 mins to 2-3 mins. Next, we'll talk about the productization steps we took for visibility to make sure the app is performing well.
We're prototyping a replay service, to replay production traffic to different Heroku apps. With this we can compare the performance between the current MRI app in production and the same app running on JRuby. This will also allow us to test any changes/features against real production load. We'll go over how to set this up.
One of the most notable things about Ruby is its community - the passion towards writing good code, the opinions on how code should behave, the tools it produces, the people it draws to it, and yes, occasionally the arguments and drama.
Is this something we should take for granted? Should we be actively guiding the community to behave in a particular way? What makes up a healthy community? Are there ideas and wisdom can we take from other communities? So many questions – let's see if we can find some answers!
As a rapidly growing company, GitHub's faced some challenges in how to make sure that everyone can get up and running on projects or continue to work on one of the dozens of existing projects if they've never set it up before. What a nightmare! That's what prompted @jbarnette and @wfarr to develop The Setup. The Setup aims to solve all the problems that used to plague on-boarding GitHubbers onto projects with a lot of automation and a case of the "It Just Works". This presentation talks about the history of The Setup, how it works, and some of the lessons learned along the way.
Social app development challenges us how to code for users' personal world. Users are giving push-back to ill-fitted assumptions about their identity — including name, gender, sexual orientation, important relationships, and other attributes they value.
How can we balance users' realities with an app's business requirements?
Facebook, Google+, and others are grappling with these questions. Resilient approaches arise from an app's own foundation. Discover schemas' influence over codebase, UX, and development itself. Learn how we can use schemes to both inspire users and generate data we need as developers.
Over the last two years, I've traveled the world to pair with expert designers and developers on short projects to learn their day to day secrets and understand their philosophies. I've condensed this to 45 minutes of tricks, insights, opinions, and old-fashioned rants from Ryan Singer (37signals), Kyle Neath (GitHub), Neven Mrgan (Panic), Zed Shaw, Gary Bernhardt (Destroy All Software), and others.
Most Ruby code makes heavy use of mutable state, which often contributes to long term maintenance problems. Mutability can lead to code that's difficult to understand, libraries and applications that aren't thread-safe, and tests that are slow and brittle. Immutability, on the other hand, can make code easy to reason about, safe to use in multi-threaded environments, and simple to test. Doesn't that sound nice?
This talk answers the question "why immutability?", covers the building blocks of immutable code, such as value objects and persistent data structures, as well as higher order concepts that make heavy use of immutability, such as event sourcing and pure functions, and finally discusses the tradeoffs involved in going immutable.
Aaron Patterson is one of Ruby’s most respected and loved programmers. A committer to both Ruby and Ruby on Rails and a member of Seattle's Ruby community, he also has a sense of humour that has endeared him to many audiences.
Mikel Lindsaar needs no introduction to the Australian Ruby community. He is the author of the Ruby E-Mail handling library, mail, and has worked extensively on the Rails ActionMailer component. Mikel is the only Australian member of the Ruby on Rails commit team.
Ruby has become a global phenomenon, and more people use it every day. But too often, Ruby is maligned for poor performance, poor scalability, and inability to efficiently parallelize. It's time we changed those impressions.
This talk will cover strategies for optimizing Ruby code, from using different Ruby implementations with better performance characteristics to generating code and avoiding excessive object churn. We'll see how one implementation, JRuby, optimizes different Ruby language constructs and how knowing a bit about your Ruby impl of choice will help you write better code. And we'll explore the future of Ruby for high performance computing and solutions to get us there.
If you don't know how to write faster, better Ruby code by the end of this talk, I'll let you buy me a beer and we'll keep talking.
Rails - a word that stirs programmer's blood. It brought us testing, easy web app building, database abstraction and hundreds of extension gems. Why not take it to another level and discover how Rails turns into a real OOP framework? By exploring chosen gems let's discuss what MVC really is and how it boosts your AJAX user interface, how to apply patterns like DCI, dependency injection and POROs to your database layer and how to expose your Rails system through a real RESTful API. Also, have you ever tried using Rails helpers outside of Rails, maybe in Sinatra? Let's do it and learn about some refreshing aspects of this framework.
RubyMotion has revolutionized native apps development platform for iOS devices. I would like to share some best practices/lessons learnt building apps using RubyMotion. This includes but not limited to:
What is RubyMotion
Using Obj-C, native C, gems in your RubyMotion application
DSL for views
ActiveRecord-like ORM for iOS
Testing storyboard interface (Rspec and TestUnit)
Releasing to AppStore
When you talk to most people about Rails performance the conversation usually turns to concurrency. How can my Rails app handle 60 simultanious requests per second? How do I webscale?
Although the topic of concurrency is important, we won't be focusing on that during this talk. We want to focus on end user speed.
For every extra second your application takes to load your conversion rates will drop by an average of 7%. While most people start tweaking their backends to squeeze every extra ms in response time, more often than not (80-90%) of the actual time spent loading your application is on the front end and the network stack. This is where you should start.
We will cover a range of techniques and provide benchmarks along the way to show how much performance you can expect from each step along the way. We'll also cover some backend performance tuning as well.
Here's some of the topics we'll cover:
How to accurately benchmark performance
Asyncronously loading assets
Reducing requests per page
Rails http streaming (chunked responses)
What is SPDY - and how to use it
What CDN is right for your app?
Server location and why it matters
Every year is an eventful one in ruby. Many rubies have been polished this year, and many new ones have been cut.
I'll take us through the state of things in MRI, jruby, rubinius and friends, and what we can expect from them next year, particularly in regards to ruby 2.0, which is scheduled for release just a couple of days after RubyConfAU.
Braintree is a payment gateway, so downtime directly costs both us and our merchants money. Therefore, high availability is extremely important at Braintree. This talk will cover how we do HA at Braintree on our Ruby on Rails application.
Specific topics will include:
Working around planned downtime and deploys:
How we pause traffic for short periods of time without failing requests
How we fit our maintenance into these short pauses
How we do rolling deploys and schema changes without downtime
Working around unplanned failures:
How we load balance across redundant services
How the app is structured to retry requests
Every application is different. Every application performs and scales in a different manner. What stays the same are the tools we use to monitor and diagnose our applications when they get sick or have a big night out.
In this talk I'll cover how realestate.com.au monitors and troubleshoots the performance and scalability of our Ruby and non-Ruby apps. I'll look at the tools we use to infer when/where things go wrong and several cases where things have gone wrong and how we've dug our way out of the whole.
Examples of areas covered include:
Vertical scaling our way out of I/O pain
Horizontal scaling our apps for throughput and availability
Using HTTP and CDNs to avoid the reddit-effect
Tools we use for establishing performance 'baselines'
Here's a situation we've all be in at one point. We have a program. We want to make that program faster. We know about threads, processes, fibers. Then you start programming and you have no clue what to do. I was there. It sucks. This talk guides you down the rabbit hole and brings out the other side.
Processes, Forking, Detaching
Parellelism vs Concurrency
The many many different ways I crashed my computer learning these things
Gotchas of each
Common ways you shoot yourself in the foot
This is a learning and informative talk. It's target at intermediate developers who have ruby experience but never written any multi threaded code.
On the internet, there seems to be two kinds of information available to do with "scaling rails", or on "scaling" in general.
Blog posts about how the really big boys are doing things
Blog posts full of non-production benchmarks explaining why you need a particular data store, templating framework, or anything else to be "web-scale"
This talk will hopefully be a third kind, practical advice to help you grow your application at the right pace alongside your business' growth, based on real world experience.
Topics covered will (probably) include:
Why you should probably choose Postgres or Mysql as your data store
Why going from one developer to two developers is the hardest
Why going from one server to two servers is the hardest
Why those two things are actually the same problem
How YAGNI and SRP apply to your hosting just as much as your code
How you balance your cost-speed-quality stool for developing your app up against the same cost-speed-quality tripod for your infrastructure
Why other people's advice on the topic can only ever provide a starting point, not a final answer
What's the worst that could happen if your app has a dependency on a malicious gem? How easy would it be to write a gem that could compromise a box?
Much of the Ruby community blindly trusts our gems. This talk will make you second guess that trust. It will also show you how to vet gems that you do choose to use.
There are four malicious gems I will be presenting:
Harvesting passwords from requests going through a Rails app
Exposing the contents of a Rails app's database
Compromising the source code of a Rails app
Providing SSH access to a box a 'gem install' time and stealing gem cutter credentials (and going viral)
My talk will increase awareness that these sort of gems can exist in the wild, show how easy it is for anyone to build malicious gems, and give easy techniques for identifying these gems.
Do you have a compelling talk that you could present in no longer than five minutes?
We have 45 minutes allocated to lightning talks, which will allow for about seven talks. Conference attendees will be given the opportunity to submit their lightning talk proposals on Thursday.
Dave Thomas needs no introduction to Ruby programmers. As co-author of "Programming Ruby: The Pragmatic Programmers' Guide" - fondly known as the "Pickaxe", Dave was instrumental in spreading Ruby beyond its birthplace in Japan.