Video recording and production done by RubyConf AU
OpenStack at NTT Resonant: Lessons Learned in Web Infrastructure
Rubygems.org provides every Rubyist with an amazing service: all the libraries in the Ruby world. As amazing as that is, installing gems can be a time-consuming and even error-prone process. (Just ask the Travis guys.) In this talk, you'll learn about the recent dramatic changes in Rubygems and Bundler to improve speed and reliability by rewriting the Rubygems client/server architecture. I'll show how the new system caches more information, makes fewer requests, and takes less time to install gems. Finally, I'll cover how the changes allow worldwide mirrors of rubygems.org, improving things for Rubyists around the globe.
Why this talk?
This talk exists primarily as a "State of the Gem Ecosystem Address", to tell everyone how things are going, what we've been working on, and why they should care. It also tries to point out the benefits that every Rubyist gets from the Ruby ecosystem, while gently letting them know that those things don't happen for free. Hopefully, by providing that information, we can ask people to contribute time and effort to improving things for everyone and sound like we are leading by example, rather than demanding that someone step up to solve the problems for us, already.
When a round-trip delay just doesn't cut it, more complex approaches can be crafted with libraries like Backbone to create a truly client-side application. The asset pipeline remains a perfect complement, allowing all sorts of optimisations.
But going beyond these simpler approaches is all the rage with Angular leading the charge. We'll look at building Angular apps leveraging the pipeline for templates, compilation, and more.
Quickly touching on some more esoteric applications, we can also export rails routes for use in client side templates, automatically create sprite sheets, and even generate icon fonts, optimising assets along the way. The Rails asset pipeline is still Da Funk; a fantastic tool for front end developers.
A detailed, deep-diving, in-the-deep-end and occasionally humorous whirlwind introduction and analysis of a suite of modern (and sometimes delightfully archaic) database technologies. How they work, why they work, and when you might want them to work in your Ruby and Rails application.
At no extra charge I will also 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:
The goal of the talk is to shed light on the wide range of options outside of the "traditional" PostgreSQL or MySQL. Ruby on Rails has a rather myopic focus on particular patterns of database interaction and technology on which lead developers to overlook other tools that may be really well suited for particular use-cases.
Programming can be an all consuming job. So can parenting.
How do you keep up with new technology, contribute to open source, earn some money, and be there for your children? What do you focus on and what do you discard? Is it even possible to do it all?
As the mother of a 3 month old, I certainly don't have all the answers. This talk will collate suggestions from programming parents all around the world, so we can make new mistakes going forward, instead of repeating those of the past.
Join me as we dive under the hood and take a rip-roaring tour of the internals of Ruby's canonical implementation.
This talk will have you hanging on the edge of your seat as we push the very limits of the Ruby language and take advantage of a few interesting bugs to do things you never thought were possible.
You'll laugh, you'll cry, and hopefully you'll come away from this talk with some fresh knowledge on just what makes Ruby tick.
What is common between Rails, Sinatra and numerous other Ruby frameworks?
They are built on top of Rack or have Rack interfaces for allowing application servers to connect to them.
A deep-dive of sorts on Rack and see what it takes to build a framework, helping us understand these better and ultimately rolling our own.
Almost anyone doing a Ruby app ends up using Rack in one way or the other without ever realising the magic and simplicity that it provides. This session should help decoding that and provide ways on writing your own frameworks.
In Ruby 1.9 the MiniTest testing framework was introduced. This lightweight testing framework is fast, powerful, and easy to understand, yet so many people over look it.
In this talk we'll look at using MiniTest in a simple, non-Rails, project and then work up to using it in a Rails application. We'll look at both the TestUnit and RSpec style syntaxes that MiniTest offers. We'll also learn to write custom matchers, run specific files, and much more.
Testing is important to all Ruby developers, and with such a powerful testing library already bundled with Ruby, shouldn't we learn how to use it?
You may have this vague sense that you don't know Ruby as well as you think you do. And you worry that you're not learning and growing as a developer in your day job as much as you did when you first picked up Ruby. Perhaps you've lost that spark of excitement you experienced when you discovered new ways to solve problems with Ruby.
There is a way to re-invigorate your code and coding practices. Teach everything you know.
This talk will focus on some of the principals of teaching and why it can be an effective tool, not only for others to learn, but for you as the teacher to really deepen your knowledge of the subject. It will be specifically centred around using Ruby, and some of the ways I have discovered work well for teaching it as a first programming language.
Ruby 2.1 is about to be released, it will include a generational GC, performance improvements and a much improved platform for diagnostics and profiling.
In this talk I will cover many of the new profiling and instrumentation APIs introduced in Ruby 2.1, introduce you to the new GC and show you some cool tools you can build on top of this. I will cover memory profiling, GC instrumentation, the much improved stack sampling, memory profilers, flame graphs and more.
In my wildest dreams, I never thought that I would become a software developer. I thought that I wasn't smart enough, that I needed a computer science degree and to have been writing code since I was young. But, the traditional path to becoming a developer is changing. This talk will focus on alternative and untraditional paths to becoming a developer such as programs like Railsbridge, mentorship and apprentice programs. These alternative paths ultimately foster a more diverse and inclusive community, which drives economic growth and produces more innovative solutions.
The objectives of the talk are:
to bring awareness to the educational alternatives to computer science degrees to encourage empathy when mentoring a beginner to get the audience to see a different perspective and embrace differences in the industry
Congratulations. The Internet is now the centre of civilisation as we know it, and we are the ones who shape the Internet. Our skills are in high demand, we are paid well, we find our work challenging, interesting, and even sometimes fulfilling. These are the glory days of our industry, and we should soak up every minute of it!
But with such great power comes a great deal of responsibility. Will we be looking back in the near future, wondering if we squandered our opportunities to shape the digital world accordingly?
There's no doubt that we value humanity, intelligence, and compassion. Let's take a look at the ways our industry can ensure these values are reflected not just in the people we are, but the way we work.
The ability to repeatably and automatically build your servers in code is essential for managing a modern Ruby application's server infrastructure.
Solutions such as Chef and Puppet are often used to solve this issue, but for some teams, this might be too costly to learn and implement effectively. Bridging the gap between these larger solutions and shell scripting is Ansible, a light footprint provisioning tool using SSH and YAML files to quickly define repeatable server creation and configuration steps.
This talk will cover:
introduce server provisioning at a high level explain how Ansible fits into that pattern describe simple Ansible commands and modules run through a basic playbook example, bringing these elements together summarise other functionality offered by Ansible
Not too long ago, a small group of developers inside Envato embarked on a mission: take an idea, and turn it into something real. To accomplish this goal, they didn't just have to build the product, but change the way they were writing and shipping code as well. In the end, the way they were delivering was radically different to anything they'd ever done before. The result? Mission accomplished.
This talk explores the core tenets of the team's delivery process, and explores the reasons behind the decisions that were made. It mixes anecdotes with practical examples, showing how changing the way you think can really help get things done.
Some of the tenets in the talk include:
Level up your CI to continuous deployment Time is valued above all Staying lean with YAGNI Pay the refactor cost upfront Testing is best done in production Do things that don't scale Living on the bleeding edge The only way to move is forward After listening to this talk, you will know how easy it is to introduce these principles into your Rails app. You'll be armed with ideas of what you can take home to your team, in order to deliver better and faster than before.
So you think that concurrency is a subject lost in the Ruby world? That it's not practical because of the GVL? That the concurrency paradigm that's bundled with Ruby (a.k.a threading) is not the best way to do concurrency? Or that you already have multi-processes and don't need multi-threading concurrency.
Think again. The Ruby concurrency story has advanced a lot in the last couple of years. Have you heard of people talking about actor-based concurrency, using futures, Software Transactional Memory etc. and want to know more about those?
This talk is a primer on these different paradigms of concurrency, briefly touching on the traditional threads-based model, but focusing more on modern paradigms like actors/futures/STM, with examples and live-demos. Along the way we'll also see what's already possible in Ruby (and in other implementations like JRuby and Rubinius, using gems like Celluloid and friends)
Too many startups do this thing where they build their reputation with all these great technical blog posts and fascinating public talks, and then they become a Real Company and suddenly decide they're too cool to be open and transparent. Maybe the lawyers get to them, or maybe all the cool ninja rockstars become managers.
In any case, I think that's stupid. I don't want GitHub to be one of those companies. I think the scaling problems we face — both technical and human — as we near five million users and 250 employees are super interesting to talk about and learn from.
A lot of my talks like How GitHub Uses GitHub to Build GitHub and posts like How GitHub Works are nifty, but they represent a snapshot of the company when we were 30-75 employees. We're 217 today, and things inevitably changed to grow the company to that scale.
This talk is a retrospective: it takes a closer look at specific things that we've said over the last few years, and then details the adjustments that were made as we've grown.
From time to time, when building Ruby apps, you realise there are no libraries available for what you need. Even worse, Ruby doesn't quite perform as quickly as we would expect in certain areas. There are, however, a lot of high performance, mature technologies built in C that can easily be ported to be used with Ruby. By doing this, we get to keep using our favourite language, opening it to a plethora of applications that were not possible before, and still keep things snappy.
In this talk, I will walk you through the ins and outs of building Spyglass, an OpenCV binding for Ruby. I will also talk in detail about some gotchas (memory management, lack of threading), good practices (C objects as first class citizens, how to properly test extensions), why mkmf needs to be retired and some great examples of extensions you probably already use and should be looking at.
We take for granted the wealth of knowledge and wisdom that goes into each library we use within our programs. Many of the them we use today are built on top of libraries that have existed much longer than most of us have been programming in Ruby.
Allow me to guide you through some of these unusual and mysterious libraries that are made available in every Ruby installation. I'm talking about the standard library, which has largely been apart of the Ruby ecosystem since before gems were available.
There's around ~70MB of code in every installation, and it's just waiting for those eager to explore and discover what the pioneers of Ruby have provided for us.
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!
Recently it has become common practise for development teams to deploy their code several times a day, as well as encouraging new developers to deploy on their first day at work.
In our talk, we will discuss how we use continuous deployment to push these practises to the extreme. Automatically deploying the master branch on new changes is an awesome way to improve your development process.
Automatically deploying master will fundamentally change how you work. Gone are the days of the epic pull request. You'll quickly find yourself writing smaller more manageable chunks of code, that overall have a great impact on the quality of the software you produce.
By the end of the talk you'll know how to change the GitHub merge pull request button into a deploy button - and have the confidence to do so.
Some things we'll go over in the talk:
How to setup your CI environment for deployments Why having fast tests are important How to use your Staging environment for testing deployments How to use feature flags to hide deployed features from some users Zero downtime deploys, even when there are database migrations Your new deploy button, AKA The GitHub merge pull request button What to do when deployment goes wrong
JRuby is a fast implementation of the Ruby language on the Java Virtual Machine.
You may wonder if it can be faster. You may have heard of the slow startup time. Can it load faster? You may have heard that your favorite C extension does not work on JRuby. What about cross-platform C extension API?
This talk will discuss these questions.
This year (2014), the project will release a major milestone: JRuby 9000 (仮). Main new features of this release include:
Ruby 2.1 compatibility New compiler Better InvokeDynamic experience
So you want to be an open source contributor? Think you can handle supporting multiple rubies, tracking down weird bugs, stomaching all that the wider developer eco system can throw at you? Well good reader, I can tell you stories that will turn your stomach, and blind your eyes.
Let me take you on a journey deep into the depths of open source triage and follow the kind of madness that comes from tracking down bugs across differing versions of Ruby and VMs.
Finally let me entertain you with stories of the perils of dogfooding your testing framework, and throw in some stories about the kind of hackery you can commit with a bit of mischievousness.
It's almost inevitable in any Ruby Project - you hit that stage where your logic starts getting more complex, you start doing more stuff that needs to happen but doesn't have to happen in the foreground - or you just want things to be faster.
You move your logic out into workers and do the work in the background.
This talk is going to be all about Sidekiq - a threaded background job implementation written in Ruby - and, in two parts: How you can use it and how you can bend it to your will.
Part 1: Intro to Sidekiq
The boring: a brief introduction to sidekiq, how it works - what it's advantages are. The stuff you need to know about it, why it's useful to consider - even if you're using CRuby / MRI.
Part 2: Hacking Sidekiq
The cooler part - once you know what Sidekiq is, I'm going to show how you can use Sidekiq in your product, how you can extend it and bend it to your will. I'll go into how it implements itself in ruby land and how it interacts with the Redis.
I'll show how you can use the existing middleware (and write your own) to add behaviour to your code, patterns we've found useful for implementing and testing workers as well as the even more interesting side - using Lua support in Redis to implement stuff in Sidekiq.
I want to encourage developers to look at extending their tool set to work better with not just ruby - to become comfortable with how they work internally (e.g. you should really learn how to love redis) and what you really need to be careful of (e.g. bugs that manifest when the site is under less load than usual - a real world example of going too far).
Finally, I'll end with an important question: Why not just use a proper message queue?
You probably use Ruby everyday, so why not use Ruby to automate some common tasks? What if you could spin up an EC2 instance and have it automatically configure your web server, database, users, and more? What if you could effectively capture and replicate your production environments reliably and consistently? What if you could then give developers production-like environments as Virtual Machines, with no additional work? What if you could set up your new laptop with multiple Ruby versions, your favourite software, and even change the desktop background - from a single command? The good news is - you can!
Chef is a configuration management and automation tool that solves these problems and many more. In this talk, you'll learn common just how easy it is to capture your infrastructure in Chef. Save time and money by using Chef's Ruby DSL to "define" your laptop.
How many times have you bought a new laptop and realise just how much stuff you installed over the years? If you're using Chef, run a single command
Smalltalk is an object-oriented, dynamically typed, reflective programming language. Smalltalk is a "pure" object-oriented programming language, meaning that, unlike Java and C++, there is no difference between values which are objects and values which are primitive types. In Smalltalk, primitive values such as integers, booleans and characters are also objects, in the sense that they are instances of corresponding classes, and operations on them are invoked by sending messages.
Smalltalk leaves a long shadow on the programming landscape and can be considered both as an ancestor and influence on the design of Ruby. This talk introduces Smalltalk to Rubyists and covers software principles which can be applied to Ruby applications, both large and small.