At my company, we recently finished rebuilding our front end – moving away from a strict single-page approach, and towards a hybrid approach.
What happened? The app became noticeably faster. New features were easier to ship. The codebase became easier to maintain.
We’ll use this experience as a jumping off point to discuss alternatives to the single-page approach, and why you might choose them.
Have you ever wondered how to use all of your cores?
The talk will take you on a path of writing a simple concurrent class. We'll start with a basic implementation and gradually improve it based on presented problems and newly learned facts. Our final solution will behave well in the face of concurrency and execute consistently on all Ruby implementations.
We’ll investigate various Ruby runtime differences that we’ve abstracted away with the synchronization layer of the concurrent-ruby gem. We'll go down to JRuby extensions, even volatile fields and compare-and-swap operations.
You use tools like Bundler, RVM, rbenv, or chruby every day. But what are these tools actually doing behind the scenes?
Let's take a closer look at how tools like these alter Ruby's behavior by tweaking the environment it runs in. We'll take the mystery out of load paths and gems sets. You'll come away with a better understanding of how tools like RVM work, and a better idea of where to look when they don't do what you expected.
You are happily writing new code for your system when all of a sudden the code is not behaving the way you thought it should. Perhaps you just created a failing test, and the code you wrote was expected to make the test pass ... but it doesn't. What's the first thing you do?
Some Rubyists will drop some "puts" statements into the code. Some will add a raise statement. And still others will depend on logging to trace the internals of the code. But a surprisingly few Rubyists will reach for the Ruby debugger.
Despite a general disdain for the debugger in the Ruby community, the Ruby debugger is a powerful tool that can quickly get to the heart of a coding problem. This talk will concentrate on getting Rubyists up to speed on the debugger, how to use it effectively and learning other general debugging tips.
Your app is a unique snowflake. Your tests are too… but they shouldn't be!
Years helping teams write better tests has taught me one thing: consistency is crucial. Inconsistent tests slow teams down, wasting time to understand how each test works. Deciding on conventions—even arbitrary ones—can prevent tremendous pain later.
This talk will introduce a ready-to-fork Test Style Guide of carefully-considered rules and templates for Rubyists. You can customize it to fit your preferred tools, too. Soon, you'll be on your way to having more consistent tests that are much more fun to maintain!
TDD has been tattered, torn, twisted, stood on its head, and pounded into an pulp of techno-fetishism. TDD was a game-changer, but the focus in the interceding years has shifted from technique to tools, and TDD has been devolving into a lost art. By tearing TDD down to its bones, this presentation presents TDD in its essence, free of tools, and reinforcing the primary focus on design principles. It attempts to convince you to return to a simpler time when TDD was still about design, and software developers were dutifully steeped in the critical importance of design principles. To avoid being held to any particularly offensive positions, this talk liberally attacking the status quo of testing and contemporary tool-focused TDD in Ruby, while introducing yet-another testing library in Ruby. :)
Elixir is one modern language that is introducing many Rubyists to the world of highly scalable, highly distributed, functional programming-based programming. In a more narrow scope, one language feature that many people liked is the now famous Pipe Operator "|>". There is nothing like this in Ruby. But could there be such an operator? And if it could be done, would it be useful? I started a pet project called "Chainable Methods" to address just that.
Ever wanted to rewrite performance sensitive code as a native Ruby extension, but got stuck trying to navigate the depths of Ruby’s C API before you could get anything done? Or maybe you’re just not comfortable with C and want an easier path.
Do you know any Go? Well, if you do, you’re in luck! Join us for this talk about a tool named gorb that will quickly and easily let you generate native Ruby extension wrappers for your Go programs. And if you don’t know Go, come anyway, it’s really easy to learn! We’ll have you writing blazing fast code that you can use right from Ruby, in no time at all.