Crystal is a language that looks a lot like Ruby, but is much faster and protects against certain errors, like preventing variables from being nil.
Crystal’s standard lib comes bundled with support for WebSockets, OAuth and other nice utilities. It has a very simple testing framework, dependency management system, and even web frameworks.
This is a very exciting time to come aboard the Crystal train, especially coming from a Ruby background.
So you're building a Rails API and you want to do it right--following RESTful best practices, with endpoints that can sideload related resources, paginate and filter with grace. The JSON API Specification (jsonapi.org) aims to help you do this without spending a month bikeshedding or reinventing the wheel. But does it really work? Based on my experience using it in my last project, this talk will help you decide whether to use it and how to do so with Rails.
This talk will detail some of the lessons the speaker learned from writing a gem that allows its users to easily implement a cloud-based proxy cache for their Rack app. Proxy caching is similar to a browser caching, except that the cache is shared by every client making requests to a server. So, as soon as one client requests a given path, any subsequent requests to that same path will return the cached version (as long as certain conditions are met). The gem implements a Rack middleware to catch requests and return cached responses before a server is ever hit. That means public pages that don't change often can load lightning fast and the burden on a server can be substantially lightened.
When we integrate with external services, we are designating a new source of truth in our application, and we as developers have a responsibility to respect this truth with a rigorous interface. How can we move beyond 'service objects' and avoid a VCR-blasted test-suite while still maintaining tests that *actually* cover our new truths? In this talk, I'll propose breaking down the integration into layers of interface with our system, and discuss ways to separate their various duties through POROs. The end result: Exhaustively tested, easily readable integrations for those who think someone might be watching.
Hanami (formerly Lotus) aims to be Rails rebuilt with an eye towards modularity and composability. Hanami’s components work well together, giving you the full framework experience that you’ve enjoyed in the past with Rails. However, they’re modular enough that you can use parts of Hanami to augment your existing applications. We’ll take a tour of the framework and see how apps written in it compare to their equivalents in Rails and Sinatra along the way.
Understanding performance output can feel like reading tea leaves. It makes sense to a few people, but many of us are left in the dark; overwhelmed and frustrated by the data. On top of that there are a ton of performance tools to choose from; StackProf, RubyProf, AllocationTracer. Where do you even start? While working on speeding up integration tests in Rails source, I learned that the key to improving the performance of Ruby code is having a baseline, not relying on one profiler and understanding the advantages and limitations of your tools. By utilizing these methods, integration tests are now 3 times faster than they were in Rails 4.2.0, with more improvements being made every day. In this talk we will not only look at how to read performance output, but when and how to use the right profilers for the job. We'll discuss a variety of methods and techniques for benchmarking and profiling so you can get the most out of any performance tool.
Metaprogramming is a powerful technique that sets Ruby apart from other contemporary languages. It allows compact and elegant solutions to seemingly intractable problems. Serving as the foundation of some of the mostly widely used frameworks and DSLs in the Ruby ecosystem, it’s arguably the single most defining feature of Ruby. Unfortunately, that expressive power has traditionally come at the expense of performance.
We’ll show you how JRuby+Truffle has eliminated the cost of metaprogramming so Rubyists can write idiomatic Ruby without having to worry about hidden performance trade-offs.
Submitted for your approval: a circle of torment unchronicled by the poets of old, a terror at the heart of many a horror story: SystemStackError: stack level too deep
Tremble no more! Conquer the well of eternity!
Behold the secrets of tail recursion and tail call optimization in Ruby! Witness the metamorphosis of a simple function as we explore the hidden power of tail call optimization buried deep within the Ruby VM! Follow the transformation to the revelation of tail call optimization's most ghastly secret: in many ways it's really just a special type of loop construct! The horror!
What’s a mock? What’s a stub? How about a spy? Or a double?
There are a lot of different tools to create isolated tests in RSpec. The terms aren’t necessarily totally clear. In this talk, we’ll look at what the different kinds of test isolation tools in RSpec are for, some testing smells they can create, and how to fix those smells. This talk will be perfect for those already a little familiar with RSpec and looking to improve their testing skills.
This is a different kind of Docker talk. We will side-step deployment orchestration. We won't mention scheduling and service discovery. And we won't even talk (much) about docker repositories. Instead, it's all about developers! Building applications today using Docker has never been easier. We will look at why using Docker now in development makes sense. Then dive into using new tools, techniques, and workflow practices. We will also cover emerging community "container trends". Folks should leave this talk feeling ready to try container-based development.
React is a powerful JS (I know!) library for building user interfaces. Our goal is to build a blogging app with markdown editor and live HTML preview powered by Ruby on Rails and React.
In doing so we will learn what makes React more than yet another JS library blowing up Hacker News.
What trick do companies like Google and Heroku know about API development that you don't? How do they reduce the maintenance burden of maintaining client libraries while also making their server-side validation and response generation simpler? Schemas!
Whether you're building APIs for the public, for internal micro-service infrastructures, or even just consuming other's APIs, Schemas can make your life easier. This talk will break down the differences between Descriptive Schemas and Prescriptive Schemas, and when you might want to use each. We'll look at real examples of usage in the wild, and tips for implementing Schemas in your environment.
Pry bills itself as "a powerful alternative to the standard IRB shell for Ruby", and it ain't kidding. With integrated tools like Slop and Method Source, Pry is a full-fledged Swiss army knife of command-line kung-fu at your disposal.
But why stop there? With an architecture built for plugin extension, the limits of Pry are really only a reflection of the limits of your own imagination.
So come learn the basics of creating a Pry plugin as we dive into some of Pry's internals and walk through the process of creating a plugin that adds a custom command to the Pry CLI. Where you take it from there, only you know.
Code reviews are not about catching bugs. Modern code reviews are about socialization, learning, and teaching. How can you get the most out of a peer's code review and how can you review code without being seen as overly critical? Reviewing code and writing easily-reviewed features are skills that will make you a better developer and a better teammate. You will leave this talk with the tools to implement a successful code-review culture. You'll learn how to get more from the reviews you're already getting and how to have more impact with the reviews you leave.
Congrats! You've built the one API to control them all, and it's amazing. It's fast, well-architected, and Level 3 Hypermedia. However everyone is still using your competitors sub-par product... Why? We developers are lazy and you're making it hard for us to use. We're diving into your SDKs tests to solve basic tasks, your SDK + API errors annoy and don't help us fix our mistakes, and the lack of logical defaults leaves us playing parameter roulette.
Let's explore how to build API-enabled products that fellow developers will love using with great docs, tooling, support, and community.
Run your app faster, with less RAM and a quicker boot time today. How? With science! In this talk we'll focus on the process of turning performance problems into reproducible bugs we can understand and squash. We'll look at real world use cases where small changes resulted in huge real world performance gains. You'll walk away with concrete and actionable advice to improve the speed of your app, and with the tools to equip your app for a lifetime of speed. Live life in the fast lane, with science!
Capybara has allowed us to build complex and ambitious applications with the confidence that everything comes together in the user experience we're targeting. As the capabilities of the web have grown, interactions and behavior in our applications have become more complex and harder to test. Our tests become coupled to CSS selectors, fail intermittently, take longer and our confidence dwindles. In this talk, I'll go over best practices for working with a large capybara test suite and dig into APIs and options we can use to bring back the confidence Capybara initially gave us.
With the rise of client-side frameworks you might wonder if your days using Ruby are numbered. You came to Ruby for its expressiveness and beauty. You don’t want to leave that completely behind.
Luckily, you don’t have to. With a nod to the Single Responsibility Principle we all love, this talk looks at how to leverage a front-end framework like Ember.js to handle application state at the UI layer and leave Ruby or Rails to do what it does best — everything else.
Something to keep in mind: that everything else is the heart of your entire app.