Video recording and production done by Ruby Australia
We have no problems justifying a refactoring effort when it improves performance or eliminates a code smell. What if I told you there's a way your refactoring could be even more impactful? One of the most costly and time-consuming things we do is on boarding. It takes an incredible amount of effort to bring a developer up to speed on a new codebase. In this talk, we’ll see real-world readability refactors, discuss how you can apply these techniques for the benefit of your current (and future) team members, and how we can continue to program with empathy and diversity in mind.
In human-to-human languages the same core ideas get shaped differently depending on the language in which they are spoken. What if every computational language engenders a set (or a subset) of culture and values, and as a consequence attracts and shapes a corresponding community? What are the values that entered into the language by way of its core committers and what are the values we identify with as a community. How can making these values explicit help us foster a better community?
The talk will focus on techniques I used to increase the performance of a popular concurrency framework, Celluloid, by upto 3 times. I'll discuss the areas where the Ruby application takes a performance hit and provide solutions for them.
Programming involves dealing with an overwhelming amount of complexity. The human brain can only deal with so much information to process before anxiety kicks in and your ability to proceed suffers. Functional programming provides tools to manage the combinatorial explosion of state and logic. Here we'll cover some practical uses of functional programming techniques in Ruby that can be directly applied to your everyday work.
We're seeing more evidence that the future of Ruby may not be tied to Rails as newer micro-frameworks and purpose built libraries are released to mass appeal.
In this talk we'll explore what happens when we take the most popular CMS for Rails, "Refinery CMS", and rebuild it with Hanami and dry-rb, plus reliable Frontend frameworks and libraries rather than a mess of Rails, jQuery, and organic CSS.
We'll provide you with both gems and solid advice to allow you to refactor your own applications to take advantage of the solid and agile foundation provided by Hanami and dry-rb.
Especially as Rubyists, Open Source is one of the foundation pillars of our industry. You probably use the power of open source software every day: in the code you write, the tools you build with, the servers you deploy to.
But perhaps it’s not quite the stable foundation we were hoping for? This talk will cover the various strengths and weaknesses of both open source and our reliance upon it, so we can trade in our assumptions for a greater awareness of the issues. Then together, we can find a path towards a more sustainable open source ecosystem.
This talk will discuss localization and internationalization for Rails applications. We’ll discuss available tools as well as best practices for building apps for localization. We’ll also talk about the more human and subjective struggles of translating ideas and concepts for new audiences.
This talk discusses a collection of things that have been helpful through the years. Some are supported by ActiveRecord, and some fall outside the scope of what ActiveRecord provides. You'll learn things like awesome datatypes, proactive and reactive performance testing, time-series data, backup and restore strategies, PostGIS, scripting with Postgres, and more!
This talk will be geared towards career changers, juniors, and those interested in becoming software engineers. It's a personal testimony of how I was able to change careers and become a software engineer without a technical degree.
Released in 1989 the Gameboy was the first handheld console of the Gameboy series to be released by Nintendo. It featured games such as Pokemon Red & Blue, Tetris, Super Mario Land and went on to sell 64 million units worldwide.
My talk will be discussing what components make up a Gameboy, such as the CPU, RAM, Graphics and Game Cartridge. How each component works individually and how they work together to let trainers catch em all. Then how to replicate the behavior of the Gameboy in code to eventually make an emulator.
Whenever the stereotypical Ruby developer hears the words "statically-typed", they have one of two responses:
they have flash-backs to their C++/Java days they prepare their memorized Alan Kay / Kent Beck quotes for battle. Now that stronger typing is coming to Ruby, maybe we need to calm down a little.
This talk is not designed to persuade anyone to drop our beloved Ruby, but maybe we can learn some lessons from our stronger-typed friends to bring even greater happiness than before.
We all want to have performant concurrent code, but threads are such a pain. Who wants to deal with race conditions in their code?! In this talk we show a better way of doing concurrency, the Actor model. No, that’s not just for Erlang or Elixir, we can have it in Ruby too.
Catching software bugs is a mysterious magic, unknowable by science, and untouchable by process. Debugging skills are instinctual and come only from years of experience.
False! Programming bugs, like real bugs, can be organized into a deterministic taxonomy. At its base, consistent and successful debugging is pattern matching. Classifying bugs by their attributes and behaviors makes the seemingly impossible possible—codifying the elusive “programmer’s instincts” into a logical debugging process.
We all use Bundler at some point, and most of us use it every day. But what does it do, exactly? Why do we have to use bundle exec? What's the point of checking in the Gemfile.lock? Why can't we just gem install the gems we need? Join me for a walk through the reasons that Bundler exists, and a guide to what actually happens when you use it. Finally, we'll cover some Bundler "pro tips" that can improve your workflow when developing on multiple applications at once.
HTTP/2 is here.
The first major revision since 1997 to Hypertext Transfer Protocol on which so much of the modern information transfer relies, HTTP/2 could have an enormous impact on the way we write applications.
The web industry never stops evolving and changing. We have to keep on our toes and learn the new hot thing. Whether you have limited time because of family, or just started on your way, self-learning is challenging, difficult, and sometimes even overwhelming. This talk is my list of tips, techniques, and strategies I use when I self-learn. Hopefully, you can find one or two things here to keep you motivated, and on your way.
Have you ever wondered what dark magic happens when you start up your Ruby server? Let’s explore the mysteries of the web universe by writing a tiny web server in Ruby! Writing a web server lets you dig deeper into the Ruby Standard Library and the Rack interface. You’ll get friendlier with I/O, signal trapping, file handles, and threading. You’ll also explore dangers first hand that can be lurking inside your production code- like blocking web requests and shared state with concurrency.
As our community matures, and technology evolves around us, how can we ensure Ruby remains vital?
Most of us have a “that day I broke the internet” story. Some are amusing and some are disastrous but all of these stories change how we operate going forward. I’ll share the amusing stories behind why I always take a database backup, why feature flags are important, the importance of automation, and how having a team with varied backgrounds can save the day. Along the way I’ll talk about a data center fire, deleting a production database, and accidentally setting up a DDOS attack against our own site. I hope that by learning from my mistakes you won’t have to make them yourself.
Serverless (via AWS Lambda), the new hotness, was definitely something we wanted to explore when developing the backend for our new Virtual Reality app. TLDR - despite expectations to the contrary we came back to Rails, specifically Rails 5 API mode. We'll walk you through our journey, what the different considerations were, what the different strengths of each platform are and how we reached our decision. We think it's essential that as Rails developers we have an understanding of Serverless, both as a replacement and as an augmentation to our skill-set and development environment.