Alexandra Leisse
Developers, start designing!
We designers have been told for ages to learn how to program because we needed to know the technology. On the other hand, very few developers bother doing the same with design. This usually leads to worse results than necessary, and robs us of the opportunity to play on the same team.
This presentation is meant to contribute to the much needed discussion about how developers and designers can work together to achieve excellence without losing their minds. Attendees should leave the room afterwards with a certain insight in how ignorance hinders best outcomes and how they personally can improve the situation.
About Alexandra
Alexandra discovered the Usenet in 1994 and has been lost ever since. She started toying with web sites when browsers were called Lynx and she contributed to KDE. She spent 10 years living big drama on opera stages, is currently working as Lead Interaction Designer for Iterate AS and is the co-organiser of the Rails Girls chapter in Oslo. Follow Alexandra on Twitter.Andy Pike
Opening up to change
The one constant in software is change.
Your code will need to change and adapt over time. We should try to write code that is easy to change in the future. If possible, change without having to edit existing code.
This talk is all about the O in SOLID: the Open-Closed principle. I'll explain what the Open-Closed principle is, why this is important and how to structure and refactor code to make it "open for extension but closed for modification".
In this talk I'll show you, by example, how to make your code more changeable. In fact, so changeable that you will be able to extend what your program does and how it behaves without modifying a single line of existing code. Starting with a real world example that is painful to extend, I’ll refactor it over many iterations until it truly is Open-Closed. I'll show techniques, trade-offs and some gotchas from real world experience which will help you write more flexible programs in the future.
If you’ve never heard of the Open-Closed principle or are unsure how to put it into practice then this talk is for you. I would love to help open the door of this technique and give you the ability to alter your system in a painless way by opening it up to change.
About Andy
Andy is based in leafy Surrey in the UK and is Technical Director of LoyaltyLion, who offer loyalty programs to e-commerce stores by integrating with many popular platforms. When Andy isn't hacking on Ruby you'll find him mining for diamonds with his kids in Minecraft or watching the latest eSports tournament. Follow Andy on Twitter.Carina C. Zona
Consequences of an Insightful Algorithm
We have ethical responsibilities when coding. We're able to extract remarkably precise intuitions about an individual. But do we have a right to know what they didn't consent to share, even when they willingly shared the data that leads us there? A major retailer's data-driven marketing accidentially revealed to a teen's family that she was pregnant. Eek.
What are our obligations to people who did not expect themselves to be so intimately known without sharing directly? How do we mitigate against unintended outcomes? For instance, a social network algorithm accidentally triggering painful memories for families grieving their child's death.
We design software for humans. Balancing human needs and business specs can be tough. It's crucial that we learn how to build in systematic empathy.
In this talk, we'll delve into specific examples of uncritical programming, and painful results from using insightful data in ways that were benignly intended. You'll learn ways we can integrate practices for examining how our code might harm individuals. We'll look at how to flip the paradigm, netting consequences that can be better for everyone.
About Carina
Carina C. Zona is a developer, community builder, advocate, certified sex educator, and whimsical gluten-free baker. She has been an organizer & instructor for many tech women's organizations. Carina is the founder of @CallbackWomen. She spends a lot of time thinking about the unexpected cultural effects of our decisions as programmers. Follow Carina on Twitter.Étienne Barrié
Ruby keyword args and the options hash, from the parser to the virtual machine
Ruby has slowly but surely added support for keyword arguments.
Starting from the implicit braces for a hash at the end of an argument list, it has grown up to required keyword arguments in 2.1.
This talk will try to convince you that keyword arguments are a lie and don't even exist, and why you should use them anyway.
About Étienne
Étienne is a Rubyist with 10 years of experience, faithful to HTTP and enthusiastic git force pusher. He recently moved from Paris to Montréal to join the Shopify team. Follow Étienne on Twitter.Florian Weingarten
How to stay alive even when others go down: Writing and testing resilient applications in Ruby
Your application probably communicates with other services, whether it's a database, a key/value store, or a third-party API: you are performing "external calls". But do you know how your application behaves when one of those external services is behaving unexpected, is unreachable, or sometimes even worse, experiences high latency? This is something that you want to find out during testing, not in production, since it can easily lead to a series of cascading failures that will seriously affect your capacity or can even take your application down.
Shopify operates one of the largest Ruby on Rails deployments in the world. We serve about 300k requests per minute on a boring day, integrating with countless external services. Focussing on Resiliency has been one of the most impactful improvements that we made in terms of uptime in the last year.
In this talk, I will share some lessons learnt and we will walk through a series of ideas and tools that can help you make your application more stable and more resilient to the failure of external services, an issue that is often neglected until it's too late. More importantly, we will talk about how you can write meaningful and realistic integration tests and set up "chaos testing environments" to gain confidence in your application's resiliency.
About Florian
Originally from Germany, studied mathematics and computer science at RWTH-Aachen University, did some research on cryptography in a previous life, now working as an infrastructure engineer on the site-reliability engineering team at Shopify in Ottawa, Canada, poking holes into other people's code. Follow Florian on Twitter.Jain Rishi
Game Development - The Ruby way
Playing games is fun, but building one is even more fun! Add Ruby to the game development mix and it just cannot get more awesome. Gosu is the rock star library which is used for 2D game development. But you’ll need to know more than just your rubies to built a game. Rishi promises to show some cool examples built entirely using Ruby.
About Jain
Jain works as a Rails developer at JoshSoftware in India. He enjoys speaking at conferences and contributes to various open source projects. When not at work, he enjoys football, traveling and blogging. Follow Jain on Twitter.Jason R. Clark
Peeking into Ruby: Tracing Running Code
Your Ruby app is in production, but something isn't quite right. It worked locally, it passed CI... yet the running app is acting up. Sounds familiar? You're in luck! Multiple tools exist for grappling with a running Ruby app. This talk will introduce a variety of tools and techniques for peeking into what your Ruby app is doing.
About Jason
Jason fell in love with programming as a young boy watching his dad work in Clipper and dBase III (no, really). He works for New Relic on the Ruby Agent, and in his spare time contributes to the Shoes project. When not at work, he enjoys cycling, homebrewing, and hanging out with his family. Follow Jason on Twitter.Kerstin Puschke
Decouple all the things: Asynchronous messaging keeps it simple
If a customer changes their address, it's often not enough to update their master data record. E.g. the component processing customer orders might have to learn about the update in order to ship to the correct address. In a distributed architecture, you have to spread information about a master data update to several client apps. You can do this via REST, but if a client app is temporarily down or too busy to accept requests, it's going to miss the information. Adding a new client app requires changes to the master app. Asynchronous messaging helps to avoid such a tight coupling of components. And it offers much more than a simple action trigger: parallelizing computing-heavy tasks, load testing, or migrating existing components to new services are some of the possibilities explored in this talk. You're going to learn how to get started with asynchronous messaging from within Ruby, and how it helps you to keep your codebase clean and your overall system stable as well as maintainable.
About Kerstin
Kerstin is a software engineer living in Hamburg where she contributes to the backend of XING, a social network for business professionals with about 15 million users. She's also a co-organizer of the Hamburg Ruby user group. Follow Kerstin on Twitter.Laura Frank
Developing Ruby Applications with Docker
Docker’s lightweight virtualization may supplant our hypervisor-backed VMs at some point in the future, and change the way that tomorrow's Ruby applications are architected, packaged and deployed. Using Docker, your applications will sit atop an excellent platform for packing, shipping and running low-overhead, isolated execution environments. You will get a brief intro to the Docker ecosystem, get to know the tools and processes needed to create containerized applications, and learn best practices for interacting with the Docker API and CLI.
About Laura
Laura is an engineer at Codeship who loves containerized virtualization, specifically Docker. She started coding after receiving a hand-me-down DOS system and has been lost in the code mines ever since. Follow Laura on Twitter.Rachel Myers
Stop Building Services, Episode 1: The Phantom Menace
This talk runs through examples of services creating more brittle systems with worse failure cases. Building on those failure scenarios, I draw out guidelines for if, when, and how to consider Service Oriented Architecture. Software architecture is informed both by principles of software design and principles of operability; for lots of us, there are new skills to learn there. Also, set to music, this talk becomes a cool remake of StarWars, Episode 1.
About Rachel
Rachel is a developer at GitHub who loves Ruby; she also does things she loves less, like javascript (coffeescript, really), email, and front end performance monitoring. She is on the Board of, and a volunteer for, RailsBridge, which holds free workshops around the world to teach Ruby and Rails to marginalized groups, including women, people of color and non-English speakers. In her free time she likes doing her nails and playing legos, which don't really go together well. Follow Rachel on Twitter.Sam Phippen
Extremely Defensive Coding
Defensive programming is one of those abstract ideas that seems great. We all want to use these ideas to ensure the long-term maintainability of our codebases. It is, however, often unclear what we should be defending against and what form those defenses should take. We can find places where defensive patterns could be added by looking at the edge cases that occur in our system. Where it seems appropriate, we can then apply ideas and patterns from defensive programming.
In this talk we'll look at some of the extremely defensive patterns that have been driven out in RSpec throughout the years. We'll look at building Ruby that works accross a wide range of interpreters and versions (including 1.8.7!). We'll investigate how you can write code that defends against objects that redefine methods like send, method and is_a?. We'll also see how the behaviour of prepend can occasionally confuse even the most mature source bases.
You should come to this talk if you want to learn about inheritence and method resolution in Ruby, defensive programming techniques and cross interpreter Ruby patterns.
About Sam
Sam Phippen is a swashbuckling hacker from London, UK. He fixes every size of data problem at Fun and Plausible Solutions. He helps fight for the forces of justice as a member of the RSpec core team. He's sad that he can't hug every cat. Follow Sam on Twitter.Wesley Beary
API by Design
In a world of pervasive connectivity, APIs are more important than ever before.
We can learn much from the rich history of APIs, but even more promise lies ahead of us.
Difficult hardly begins to describe API development, but drawing from other disciplines provides a clearer path to superior APIs.
Building and evolving the Heroku APIs has been full of epic wins, tragic fails and ongoing struggles.
Learn about our journey and join our community to discuss, document, and build tools to realize the promise of a brighter API future.
