An interview too often feels like a first date - awkward, strange, and not entirely predictive of what’s to follow. There are countless books and websites to help you when you’re a job seeker, but what about when you’re the one doing the hiring? Will you just ask the same puzzle questions or sort algorithm problems? What are your metrics for evaluating or contextualizing the answers? In this talk, I’ll describe successful practices and techniques to help you find someone who will innovate your business, bring new energy to your team, get the work done, AND be someone you’ll want to work with.
What does accessibility entail as it is related to the web? Most developers don't consider that someone with visual impairments may use the web and don't think about what this experience may be like for someone who has a visual impairment. The current trend is to push access-driven design to the end of feature building, but we will explore why this needs to be a top priority.
Every once a while, Rails might behave in strange ways that you did not expect, and it could be difficult to figure out what is really going on. Was it a bug in the framework? Could it be one of the gems I am using? Did I do something wrong?
In this session, we will look at some tips, tricks and tools to help you debug your Rails issues. Along the way, you will also learn how to dive into the Rails codebase without getting lost. The next time you a mysterious bug finds its way into your Rails applications, you will be well-equipped to pry open the black box yourself!
We know that low bus numbers, silos, and grueling hours can make hiring a dev nigh impossible. So why are bad conditions accepted as facts of life for open source software maintainers? Let's stop.
Come learn about how maintainers can become leaders instead of heroes, techniques for building an awesome team for your project, and the ways that everyone else can jump in and support open source software in an effective and sustainable way.
Do Users Love Your API? Developer-focused API Design
We all run bundle install so we can use some gem or other, sometimes several times a day. But what does it do, exactly? How does Bundler allow your code to use those gems? 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 us 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.
So Long, Hoboken: Migrating a Huge Production Codebase from Sinatra to Rails
Software is grown, not built, and that becomes clearest when we need to change it. This talk will discuss the motivations behind a framework migration, how to divide that migration into soluble subproblems, and how to conquer those subproblems in a test-driven way, all while ensuring the new codebase is designed with further growth in mind. We'll touch on mounting Rack applications inside Rails, SOA architecture, and how to map components of one framework to another.
Do you want to use your coding skills for good rather than for evil? Did you ever want to build something to make your city or your community suck less? Here are some lessons from a civic hacker on how to kickstart your project. Hint: it's nothing like writing a gem.
What actually happens when we visit a website? As developers, we're supposed to know all about this, but when our browsers have millions of lines of code, and our backends have fancy service-oriented-architectures with dozens of components, it's hard to keep it all in our heads.
Fortunately, we have amazing tools to help us. We can bypass the complexity of browsers and servers, and simply examine the communication between them. Let's use these tools and look at the underlying patterns shared across the entire web, from the simplest static pages to the most sophisticated web apps.
Bootcamps and other non-traditional education options are producing junior developers that can't wait to jump into their first jobs, but many teams are still figuring out how to successfully onboard people whose skills are solidifying and may be hesitant to add a junior to the group. As a junior, how do you go about finding a place for yourself? From thinking through what type of company may be the best fit to strategizing how to find a mentor to help guide you, this talk will discuss what you can do to make sure you get your career off on the right foot.
Over 10 years ago the first line of code was written for what would become Shopify. Within this codebase we can see the evolution of Rails from the early 0.13.1 days to where we are today, on Rails 4.1. Through the history of this git repo we can revisit some of the significant changes to Rails over the years, and simultaneously observe what has withstood the test of time. By looking at the challenges that we have overcome while building and using Rails, we can inform future decisions so that we can continue to build a framework, and applications, that last years to come.
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!
Shopify is an e-commerce platform that powers over 150,000 online shops such as Tesla and GitHub. During the weekend of Black Friday and Cyber Monday, the platform gets hit with over a million requests per minute resulting in over 6,000 orders per minute (~50 million dollars.)
Learn how we scale our Rails app and the measures we take (load testing, monitoring, caching, etc.) to ensure that there are no hiccups during this important weekend.
For developers, there are two things that are certain for time zones: you can’t avoid having to deal with them, and you will screw them up at some point. There are, however, some ways to mitigate the pain. This talk will discuss tactics for avoiding time zone mayhem, using a feature to send out weekly email reports in a customer’s local time zone as a case study. It will cover idiosyncrasies of how time zones are handled in Ruby and Rails, how to write tests to avoid false positives, and advice on how to release time zone-related code changes more safely.
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.
Getting started with testing Rails applications can be a frought process. There are a range of different test types that one can write. It's often not clear which type one wants. Without care your tests can begin testing the same behaviour. This is problematic.
In this talk we'll cover the most common types of test you'll encounter in your Rails applications: feature, controller and model. We'll also talk about ways you can design your tests to ensure your suite is robust to changes in your system. If you'd love to learn more about RSpec, Rails, and testing this talk will be great for you.
Like most programmers I am lazy. I don't want to do something by hand if I can automate it. I also think DevOps can be dreadfully dull. Luckily there are now tools that support lazy DevOps. I'll demonstrate how using Docker containers and Kubernetes allows you to be lazy and get back to building cool features (or watching cat videos). I'll go over some of the pros and cons to the "lazy" way and I'll show how these tools can be used by both simple and complex apps.
Contributing to Rails for the first time can be terrifying. In this lab I’ll make contributing to Rails more approachable by going over the contributing guidelines and technical details you need to know. We’ll walk through traversing the source code with tools such as CTags, source_location and TracePoint. Additionally, we’ll create reproduction scripts for reporting issues and learn advanced git commands like bisect and squash. At the end of this session you’ll have the confidence to fix bugs and add features to Ruby on Rails
Whether it’s through bootcamps or sheer willpower, hundreds of freshly-minted developers have used Rails to begin their careers. But all of the well-formed Twitter clones in the world are not a replacement for experience working on an active project.
Enter open source. Open source contributions hone crucial web development skills, like version control; comprehension of an full code base; and even an understanding of agile processes--not to mention being a clear indicator of your hirability. Join us to learn how to push through any intimidation and strengthen your portfolio with open source!
Docker has taken the world by storm as a tool for deploying applications, but it can be used for much more than that. We wanted to provide our students with fully functioning cloud development environments, including shells, to make teaching Ruby easier.
Learn how we orchestrate the containers running these development environments and manage the underlying cluster all using a pure ruby toolchain and how deep integration between Rails and Docker has allowed us to provide a unique experience for people learning Ruby online.
Payoff has a crazy goal; we want to solve America’s credit card debt problem. After a risky 8-week Ruby rewrite of our 500k line C# personal finance website, we decided that wasn’t audacious enough. So we set out to become a financial institution in order to help folks get out of credit card debt. In the past 16-months, we taught the rest of the engineers Ruby, figured out how to lend money, wrote all the systems and automation needed for a small bank, and hired 70 more super nice people to make it real. If you have a crazy goal to change the world, come listen to our story.
In Rails 5, the old way of returning false to implicitly halt a callback chain will not work anymore.
This change will impact any codebase using ActiveSupport, ActiveRecord, ActiveModel or ActiveJob.
Methods like before_action, before_save, before_validation will require developers to explicitly throw an exception in order the halt the chain.
This talk will explain the motivations behind the new default, will delve into the internals of Rails to show the actual code, and will help developers and gem maintainers safely upgrade their apps to Rails 5.
Fostering diversity is a commonly cited goals for the tech community, and - let's be honest - the liberal arts are kicking our butts at it. This was not always the case, though; until very recently, the faces of the liberal arts were exclusively white and male. This changed thanks to distinct strategies and deliberate cultural shifts brought about in the late 20th century, some of which the tech community has copied and others we can use more effectively. In this talk, we will explore some of those strategies by examining the education, history, and culture of the liberal arts.
With projects like Doorkeeper, OAuth has pretty solid support in Rails when dealing with one application. However, when Rails applications get larger, many project teams break up their monolithic application into services. Some suggest installing Doorkeeper on every service, whereas others recommend routing all traffic through a single service.
Recently, we worked on a project where neither of these solutions seemed right. Join us as we talk about our experience in federating OAuth in order to handle over 30,000 concurrent users.
Like an espresso, code is better served in small portions. Unfortunately most of the time we build systems consisting of a monolithic application that gets bigger and scarier by the day. Fortunately there are a few ways to solve this problem.
Everyone talks about how good microservices are. At a first glance an architecture of small independently deployable services seems ideal, but it's no free lunch, it comes with some drawbacks.
In this talk we'll see how microservices help us think differently about writing code and solving problems, and why they are not always the right answer.
Component-based Rails helps you regain control over your sprawling Rails application. It helps you structure your new Rails application in a way that it will stay more manageable longer. It helps you think completely differently about writing applications - not just in Ruby and Rails!
This session will help you pass the initial hurdle of getting started with component-based Rails. While there is nothing really new, there is a lot that is just a little different. We will go over those differences so your start with component-based Rails is a smooth one.
Discover the benefits of training your entire organization to contribute code. Kickstarter teaches GitHub for Poets, a one-hour class that empowers all staff to make improvements to our site, and fosters a culture of transparency and inclusivity.
Learn about how we’ve made developing with GitHub fun and safe for everyone, and the surprising benefits of having more contributors to our code.
Managing your infrastructure with configuration management tools like Chef melds the practices of development and operations together. This workshop will focus on a development practice - Test Driven Development - and how that method can be applied to managing your Rails infrastructure and deployments. You will learn how to: Analyze your application and define your infrastructure needs (databases, load balancers, etc.), define unique infrastructure requirements for Rails applications (i.e. asset pipeline), capture your requirements in tests using Test Kitchen, ServerSpec, and other frameworks
"Did you really think you could make changes to the database by editing the schema file? Who are you, Amelia Bedelia?"
The silly mistakes we all made when first learning Rails may be funny to us now, but we should remember how we felt at the time. New developers don't always realize senior developers were once beginners too and may assume they are the first and last developer to mix up when to use the rails and rake commands.
This talk is a lighthearted examination of the kinds of common errors many Rails developers make and will dig into why so many of us make the same mistakes.
New programmers often react with dread when the word "refactoring" starts getting thrown around at standup. Maybe you've seen fellow Rubyists struggle with old code, or a colleague spend days on one module only to end up with exactly zero changes to functionality. What exactly is refactoring, and why would anyone want to do it? What are some tips for approaching a refactor, both generally and in Rails?
Modern distributed systems have aggressive requirements around uptime and performance, they need to face harsh realities such as sudden rush of visitors, network issues, tangled databases and other unforeseen bugs.
With so many moving parts involved even in the simplest of services, it becomes mandatory to adopt defensive patterns which would guard against some of these problems and identify anti-patterns before they trigger cascading failures across systems.
This talk is for all those developers who hate getting a oncall at 4 AM in the morning.
Agile. Scrum. Kanban. Waterfall. TDD. BDD. OOP. FP. AOP. WTH?
As a software developer, I can adopt methodologies so that I feel there's a sense of order in the world.
There's a problem with this story: We are humans, developing software with humans, to benefit humans. And humans are messy.
We wrap ourselves in process, trying to trade people for personas, points, planning poker, and the promise of predictability. Only people aren't objects to be abstracted away. Let's take some time to think through the trade offs we're making together.
Background job processing is an important component of most large Rails applications. Two of the most common solutions - Resque and Sidekiq - are largely differentiated by one underlying architectural decision: processes or threads?
Is this talk, we'll provide a gentle introduction to threads and processes, and then crack open the Resque and Sidekiq gems to see how they work. Along the way, we'll learn a bit about concurrency at the OS and Ruby layers, and about how some of the tools we rely on every day are written.
Developers are trained to communicate to things with a goal in mind. When you're talking to something like, say a computer, you type in your code and it responds by giving you back what you want. Simple and straight-forward. Talking to humans? That's more of a challenge. Why? Because communicating with people requires a special set of skills - namely, empathy and a little bit of storytelling. In an industry filled with brilliant minds, great ideas and mass disruption, so few of the best and brightest know how to tell their compelling story. This workshop will teach you how.
When you want to talk to someone, where do you turn? Skype? Slack or HipChat? Maybe even an old-fashioned telephone? As great (or not) as these are, they all fail in one important way: Context. As developers, why don’t we enable our users to communicate where they are doing everything else, right inside the browser or mobile app? The technology to make contextual communications is evolving quickly with exciting technologies like WebRTC, speech recognition and natural language processing. This talk is about how to apply those building blocks and bring contextual communication to your apps.
Every interview you conduct is bi-directional and creating a bad candidate experience means you'll fail to hire the team that you want to work on – you can't hire great people with a mediocre hiring process. The experts in this session have analyzed thousands of interviews and will share how to create a great candidate experience in your company and how to scale your teams effectively. Candidates can use these same lessons to prepare for interviews and evaluate the companies interviewing them.
We will talk about introspection features of Ruby interpreter (MRI) to solve troubles on your Ruby on Rails application. Rails application development with Ruby is basically fast and easy. However, when you have trouble such as tough bugs in your app, performance issues and memory consumption issues, they are difficult to solve without tooling. In this presentation, I will show you what kind of introspection features MRI has and how to use them with your Rails application.
Ruby is a productive language that developers love. When Ruby isn't fast enough, they often fall back to writing C extensions. But C extensions are scary for a number of reasons; it's easy to leak memory, or segfault the entire process. When we started to look at writing parts of the Skylight agent using native code, Rust was still pretty new, but its promise of low-level control with high-level safety intrigued us. We'll cover the reasons we went with Rust, how we structured our code, and how you can do it too. If you're looking to expand your horizons, Rust may be the language for you.
Through practical examples and demos, learn how to utilize the various aspects of Microsoft Azure through Ruby. Dive into the Ruby SDK for Azure as well as the Azure gem for fog. Explore cloud storage, virtual machines, and networks among others. Also, learn about the upcoming Spartan browser, and remotely test your site on it from any platform at http://remote.modern.IE
What does haggling at a garage sale have to do with load balancing in distributed systems? How does bidding in an art auction relate to cloud service orchestration? Familiarity with the ideas and technologies involved in cloud computing is becoming ever more important for developers. This talk will demonstrate how you can use game theory — the study of strategic decision making — to design more efficient, and innovative, distributed systems.
We talk about bringing new developers "up to speed quickly." Imposter syndrome is bad enough, but often junior developers feel pressured to learn faster and produce more. Developers often focus on velocity as the critical measure of success. The need for speed actually amplifies insecurities, magnifies imposter syndrome, and hinders growth. Instead let's talk about how we can track and plan progress using meaningful goals and metrics.
While most parts of Rails have been thoroughly overhauled during the past few years, one part has stubbornly refused improvement. The view layer is still by default using ERB to transform your app’s objects into HTML. While trying to solve a seemingly unrelated problem we discovered a design that suddenly enabled us to move past the limitations of ERB while still integrating closely with Rails. We could now separate presentation logic from display structure; reason about our views and how they relate; and dramatically improve our code. We called the library Curly, and it's pretty awesome.
Performance regressions in edge Rails versions happen quite often, and are sometimes introduced even by experienced Core commiters. The Rails team doesn’t have any tools to get notified about this kind of regressions yet. This is why I’ve built RailsPerf, a regression detection tool for Rails. It resembles a continuous integration service in a way: it runs benchmarks after every commit in Rails repo to detect any performance regressions. I will speak about building a right set of benchmarks, isolating build environments, and I will also analyze some performance graphs for major Rails versions
When we want to offer customizability to the users of our applications, things can get tricky. How do we allow users to customize the look of the user interface while reusing the static CSS we’ve already designed?
There is a way, but it is fraught with many dangers. Learn about the power of dynamically generating CSS from Sass files. Tackle the foes of dynamic content injection, rendering, caching, and background processing. In the end, we will look triumphantly at our ability to reuse our application styles to create customizable interfaces for our end users.
We all run into legacy code. Sometimes, we even write it ourselves. Working with legacy code can be a daunting challenge, but there are ways to tackle it without taking on the risk of a full rewrite.
There is a deep satisfaction that comes from conquering a nasty piece of legacy code. The ability to achieve this goal depends on both testing and refactoring.
We'll learn how baby-step refactoring techniques lead to a better understanding of the code and a high-quality design while always keeping the code running.
When Voldemort and his forces threatened us all, two of the three wizards (and witch) who led his defeat were not raised in the magical world. Schools like Hogwarts can help us identify and train those with innate magical talents and interests whom we might otherwise never discover.
But how to find and teach those beyond the reach of our owls? This talk explores our options and will serve as a call to action for the Magical world.
As we will see, these challenges are almost magically mirrored by the Rails community as we seek to find and train developers from non-traditional paths.
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 handle complex apps such as a chat app not written in Ruby.
A lot of people have being using Rails to develop both their internal or external API, but building a high quality API can be hard, and performance is a key point to achieve it.
I'll share my stories with APIs, and tell you how Active Model Serializer, component of Rails-API, helped me. AMS have being used across thousands of applications bringing convention over configuration to JSON generation.
This talk will give you a sneak peek of a new version of AMS that we have being working on, it's new cache conventions, and how it's being considered to be shipped by default in new Rails 5.
If you missed a few days of the Heroku's changelog, not to worry! We're here to fill you in with all the critical info and killer tips. In this session, we will discuss major updates to the Heroku platform and the ways you can use it to make developing your app even easier. We'll leave plenty of time at the end for any questions.
RSpec is often described with the word “magic” by both its users and its detractors.
Understanding how RSpec matchers, doubles, and specifications work will help you as an RSpec user. You will be able to take advantage of RSpec’s flexibility to make your tests clearer and more expressive. You’ll also get some exposure to new RSpec features, like compound matchers.
Walking through a typical RSpec example, we’ll show the RSpec internals as RSpec evaluates matchers and uses doubles. You’ll leave with a better understanding of how to harness RSpec in your own tests.
We had a real-time API in Rails that needed much lower latency and massive throughput. We wanted to preserve our investment in business logic inside ActiveRecord models while scaling up to 1000X throughput and cutting latency in half. Conventional wisdom would say this was impossible in Ruby, but we succeeded and actually surpassed our expectations. We'll discuss how we did it, using Event-Machine for the reactor pattern, Synchrony to avoid callback hell and to make testing easy, Goliath as the non-blocking web server, and sharding across many cooperative processes.
Most of the four learning stages - unconscious incompetence, conscious incompetence, conscious competence and unconscious competence - are bridged by acquiring experience. But the gap between unconscious incompetence to conscious competence is where the most discomfort and discouragement occurs.
Helping new developers bridge the void ensures a vibrant, accessible community, and having visible members/mentors in each stage encourages newcomers' learning. This talk illustrates (literally!) how to help new colleagues build this bridge and prevent losing them in the what-do-I-even-Google abyss.
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.
Did you know that Shakespeare wrote almost no direction into his plays? No fight direction. No staging. No notes to the songs. Of the 1700 words he created, there was no official dictionary. That’s right the author of some of the greatest literary works in history, which were filled with situational complexity, fight sequences and music, include NO documentation! How did he do it?
In this talk, we're going "thee and thou." I'm going to give you a crash course in how: Shakespeare writes software.
The rails "official stack" tests with minitest. Each revision of rails peels back the testing onion and encourages better testing practices. Rails 4.0 switched to minitest 4, Rails 4.1 switched to minitest 5, and Rails 4.2 switched to randomizing the test run order. I'll explain what has happened, explain the motivation behind the changes, and how to diagnose and solve problems you may have as you upgrade. Whether you use minitest already, are considering switching, or just use rspec and are curious what's different, this talk will have something for you.
Working with large CSS codebases can be hard. Large-scale refactors, or even just tweaking styles on our more general elements, could end up having unintended consequences on the rest of the site. To catch these problems, we manually check every page on our site, which is a slow and error-prone approach. We need a better way to test our CSS. This talk will walk through how we implemented a visual CSS testing framework using RSpec & Selenium, using automatic screenshot comparison to catch style regressions.
Every week we hear news of another security breach. We’ve learned that retailers aren’t safe from their HVAC vendors, Seth Rogen can stir an international cybersecurity incident, and not even the venerable OpenSSL can be trusted.
If you're concerned about the security of your Rails app but don't feel like you can spare the time or effort to implement two factor authentication, this talk is for you. We'll discuss the best ways to protect your users' accounts and live code the integration of two factor authentication into your Rails app in less than 15 minutes using Authy.
0:12 - Obie Fernandez
1:28 - If you know who this is please send a msg to email@example.com
2:21 - Lance Gleason @lgleasain
7:10 - Claudio Baccigalupo
12:10 - Christopher Rigor @crigor
15:30 - Chris Kibble @ckib16 -
17:53 - Reid Morrison @reidmorrison
23:17 - Joshua Quick
24:34 - Jason ?
25:50 - Amy @sailorhg
27:59 - André Arko @indirect
31:04 - Shane Defazio -
33:16 - Jeremy Evans @jeremyevans0
37:53 - Isaac Sloan @elorest
43:05 - Joe Dean @joeddean
48:40 - Nitie Sharma
52:12 - Mike Virata-Stone @smellsblue
56:45 - Gabriel Halley @ghalley
01:00:55 - Aaron Harpole @harpaa01
1:03:05 - Ryan Davis @the_zenspider
01:06:47 - Elle Meredith @aemerdith
01:12:04 - Gonzalo Maldonado @elg0nz
01:17:43 - Peter Degen-Portnoy @PDegenPortnoy
01:21:56 - Jeff Casimir @j3
01:27:30 - Ivan Tse @ivan_tse
01:32:11 - Hsing-Hui Hsu @SoManyHs
1:36:57 - Adam Cuppy @adamcuppy
Rails and the ActiveRecord gem are really handy tools to get work done, and do it quickly. They aren't a silver bullet, though. Sometimes the database is the best place to run a complicated query. Especially when you have big transactional or time-series data. Databases are also incredibly powerful, and can do remarkable things at scale. Why not take advantage of that power?
This talk will discuss some of the things that you can do with PostgreSQL that will both blow your mind and also help you transform data into knowledge. Let's have some fun playing with data together!
How does a Ruby debugger look and work on the inside? Is it difficult to write a debugger? Hear the full story of supporting Ruby 2.0 straight from the maintainer of the RubyMine debugger. In this session we'll expose debugger internals, including different APIs used by debuggers; review how they evolved; and look at what it takes to keep the performance of a debugged application at a reasonable level. We'll also talk about alternative implementations including JRuby and Rubinius.
The most useful APIs are simple and composeable. Omnipotent DSLs can be great, but sometimes we want to just write Ruby. We're going to look at the process of designing a new API for attributes and type casting in Rails 5.0, and why simpler is better. We'll unravel some of the mysteries behind the internals of Active Record. After all, Rails is ultimately just a large legacy code base.
In this talk you'll learn about the process of finding those simple APIs which are begging to be extracted, and the refactoring process that can be used to tease them out slowly.
Rails apps start out quickly and beautifully, but after a year features are a struggle, tests are slow, developers are grinding, and stakeholders are unhappy. "Skinny controllers and fat models" hasn't worked, and "use service objects!" is awfully vague.
This talk explains how to compact the "big ball of mud" at the heart of your app into a bedrock of reliable code. It gives the steps to incrementally refactor models into a functional core and gives explicit rules for how to write light, reliable tests.
We're web developers. But how well do we know the web's core protocol, HTTP? In this lab, we'll explore the protocol to see exactly what's going on between the browser and the web server.
HTTP methods (GET, POST, PUT, etc.)
We'll investigate how we can take advantage of HTTP features to troubleshoot problems, and to improve the performance of our Rails apps.
Running tasks outside the request-response loop is a must in modern web apps.
ActiveJob is a great addition to Rails (in 4.2) providing a standard interface to various asynchronous gems (Delayed_Job/Sidekiq etc). Has it also ushered in something else? A way to do 'Service Objects' the 'Rails Way'?
For dynamic apps, Rails has taken a backseat to client side frameworks such as AngularJS, Ember and Backbone.
You grok SOLID. You practice TDD. You've read Sandi's book…twice. You rewatch Destroy All Software monthly. You can pronounce GOOS. You know your stuff!
But some of your coworkers say your code is too complex or confusing for them. You might rush to conclude that must be a them problem.
But doubt lingers: what if they're right?
After all, the more thought we put into a bit of code, the more information that code carries. Others must extract that embedded meaning, either by careful reading or shared experience. Sometimes boring code is better. Let's figure out when to be dull.
Typical Rails applications have database schemas that are designed for on-line transaction processing. But when the data volumes grow then they are not well suited for effective data analysis. You probably need a data warehouse and specialized data analysis tools for that. This presentation will cover * an introduction to a data warehouse and multi-dimensional schema design, * comparison of traditional and analytical databases, * extraction, transformation and load (ETL) of data, * On-Line Analytical Processing (OLAP) tools, Mondrian OLAP engine in particular and how to use it from Ruby.
Trailblazer introduces several new abstraction layers into Rails. It gives developers structure and architectural guidance and finally answers the question of "Where do I put this kind of code?" in Rails. This talk walks you through a realistic development of a Rails application with Trailblazer and discusses every bloody aspect of it.
When a Fortune 500 company wants to use your app but can't risk sharing sensitive data in the cloud, you'll need to package and deploy an autonomous version of it behind their firewall (aka the Fog). We’ll explore some methods to make this possible including standalone VM provisioning, codebase security, encrypted package distribution, seat based licensing and code updates.
In this hands-on lab, we will get you started with running your Rails applications on AWS. Starting with a simple sample application, we will walk you through deploying to AWS, then enhancing your application with features from the AWS SDK for Ruby's Rails plugin.
React is the best way to bring interactive UIs to your Rails apps. But using React.js on Rails can be hard. NPM libraries are difficult to include, JSX seems nonsensical, and “can we still use CoffeeScript?”
Applications today are spidery and include thousands of possible optimization points. No matter how deep performance testing data are, developers are still at a loss when asked to derive meaningful and actionable data that pinpoint to bottlenecks in the application. You know things are slow, but you are left with the challenge of figuring out where to optimize. This presentation describes a new kind of analytics, called performance analytics, that provide tangible ways to root cause performance problems in today’s applications and clearly identify where and what to optimize.
Learning to keep your Rails application secure is an often-overlooked part of learning Rails, so let's take a trip through the world of Ruby on Rails security! The journey will start with an overview of security features offered by the popular web framework, then we'll detour through dangerous pitfalls and unsafe defaults, and finally end with suggestions for improving security in Rails itself. As a bonus, we'll talk about how to integrate security into the development process.
User Centered Design as a process is almost thirty years old now. The philosophy has permeated our products and the way we build our interfaces. But this philosophy is rarely extended to the code we write. We'll take a look at some principles of UX and Interface Design and relate them back to our code. By comparing code that gets it right to code that gets it desperately wrong, we'll learn some principles that we can use to write better, more usable code.
A gentleman wizard and his sarcastic manservant examine a common anti-pattern in schema design, in which indexes are “left for later”. The pitfalls and dangers of this approach are set forth. Right incantations (which is to say, scenarios and sample code) for battling this devious tendency will be presented, with all magic (that is, “buzz”) words thoroughly demystified and clearly explained. Walk away with a new understanding of why your application tables deserve indexes from day one, and how to make sure you’ve got them covered.
Rails comes with many powerful security protections out of the box, but no code is perfect. This talk will highlight a new approach to web app security, one focusing on a higher level of abstraction than current techniques. We will take a look at current security processes and tools and some common vulnerabilities still found in many Rails apps. Then we will investigate novel ways to protect against these vulnerabilities.
Most of us have some form of cache anxiety. We’re good at caching static content like images and scripts, but taking the next step - caching dynamic and user-specific content - is confusing and often requires a leap of faith. In this talk you’ll learn new and old strategies for caching dynamic content, HTTP performance rules to live by, and a better understanding of how to accelerate any application. This is just what the doctor ordered: a prescription for cache money.
Developers often refer to their trade as both “art” and “craft," using the two interchangeably. Yet, the terms traditionally refer to different ends of the creative spectrum. So what is code? Art or craft?
Come explore these questions in this interdisciplinary talk: What is art versus craft? How does coding fit in once we make this distinction? Is the metaphor we use to describe coding even important––and why? You’ll walk away from this discussion with a better understanding of what creating and programming means to you, and what it could mean to others.
With the "Path to 2.0" CFP EmberCLI was and is projected to become a first class citizen in the Ember world. And there was much joy. However, it placed a question mark on the Rails integration story. First we had globals, then ember-rails, then Ember App Kit. Just as a bead was being drawn on the proper way... EmberCLI. EmberCLI Rails is a new gem which facilitates an integration story we can love.
Full stack testing (no "Air gap")
Potential for simple deployments
Let's learn how easy integration can be.
Payments applications typically require a strong audit trail, very predictable failure behavior and strong transactional integrity. In Ruby/Rails, ActiveRecord allows any part of the code to modify anything in the database, failures are often silently ignored, and database transactions are hidden for convenience by default. In this talk I'll explore how to solve those problems and use RoR to build a large scale payments system.
The need to keep your personal information, sensitive or nonsensitive, secure from prying eyes isn't new, but recent events have brought it back into the public eye.
In this workshop, we'll build and upload public keys, explore Git commit signing, and learn to sign others' PGP keys. If we have time, we'll exchange key fingerprints and show IDs, then discuss signing and verifying gems.
You'll need a photo ID and your own computer for this workshop.
According to Gartner, there will be nearly 26 billion devices on the Internet of Things (IoT) by 2020. ABI Research estimates that more than 30 billion devices will be wirelessly connected to the IoT by 2020. This discussion provides examples examples, ideas, tools and best-practices for Rails developers to start building IoT applications that connect their web applications to the real world.
Our code is full of hidden assumptions, things that seem like nothing, secrets that we did not name and thus cannot see.
These secrets represent missing concepts and this talk shows you how to expose those concepts with code that is easy to understand, change and extend.
Being explicit about hidden ideas makes your code simpler, your apps clearer and your life better. Even very small ideas matter. Everything, even nothing, is something.
So you are building an app that has a ton of forms each with tons of fields. Your heart sinks as you think of writing and managing all those models, migrations and associations. PostgreSQL JSON column and ActiveRecord::Store to the rescue! This talk covers a way to wrap these Rails 4 features to simplify the building of extensive hierarchical data models. You will learn to expressively declare schema-less attributes on your model that act much like “real" columns, meaning they are typecast, validated, query able, embeddable, and behave with Rails form builders.
You may be surprised to know that the things that you learn after talking to hundreds of programmers (mostly about Ruby) is that the lessons you learn are mostly lessons about people. The oddest thing about this is that it's had a very profound effect on the way I write code.
We will walk through the years of podcasting and screencasting shows like Ruby Rogues, Rails Coach, and Teach Me To Code and discuss what we can learn from each other, what I've learned from you, and how that changes who we are and how we code.