Software is a field littered with tough problems. One of the hardest and most hated problems arises when handling mutable state. This becomes especially complex when we try to mirror the real world objects, which are constantly changing, as objects within our code. Dealing with the state of an object can be a slippery slope, particularly if we don’t know what tools to reach for. This talk will delve into one of the most elegant (but often ignored!) solutions for tackling mutable state: state machines. We’ll break down the theory behind state machines and learn how they’re not nearly as complex as they seem to be.
This talk looks beyond origami as a childhood pastime and an art form and instead, explores origami as a source of many interesting mathematical problems, including one called the fold-and-cut problem. The fold and cut theorem states that it is possible, given a piece of paper and any polygonal shape, to find a series of folds of that paper such that the given shape can be generated with a single cut. This talk explores two proofs of the theorem and and a Ruby implementation of a solver that determines the correct series of folds given any input polygon. There will be a live demo of the program and paper cutting!
When I became a parent, I was amazed at how similar raising a newborn was to becoming a developer and the ways in which both experiences affect one another. Coding sets you on a challenging path of a lifetime of learning… and in the end you still aren’t an expert! We will compare tradeoffs and decisions that relate to both situations offering insights and lessons learned. Then, explore the similarities between these two journeys and common approaches we use when coding and raising a baby. Whether you’re a parent or not, come discover these interesting and often hilarious parallels. Also, there might be a baby on stage.
Developer happiness is what brought me to Ruby in the first place. And of all the new compiled languages, Crystal is the only one that shares this value. The syntax and idioms are entirely Ruby inspired. Although Crystal looks very similar to Ruby, there are big differences between the two. Crystal is statically typed and dispatched. While there are no runtime dynamic features, the compile-time macros solve many of the same problems. In this session, we’ll take a close look at these differences as well as the similarities, and what Ruby developers can learn from this exciting language.
In this talk, we derive a simple 2D physics simulator, focusing on gravity and spherical objects. The speaker walks through a basic introduction to Newton's laws, and then derives a formula for a discrete approximation of the equations of motion. We convert the discrete approximation of the equations of motion into Ruby code, which accepts a state at a particular time, along with an interval of time, and then computes the new state at that following time interval. This updated state is then rendered using an HTML5 canvas element. The talk concludes with some demonstrations involving randomized initial conditions, highly symmetric initial conditions, and some awesome 3-body stable orbits.
Collaboration is the key for successful software development. It works best when code can be understood and contributed to by many. Sometimes we think the unwritten rules for successful online collaboration are obvious, but experience has shown again and again that it is not. So let's discuss these rules and write them down so we have them. We will discuss how to make successful code contributions to the projects we all rely on, and offer some strategies for encouraging contributions on our own projects.
Software fails a lot. We spend a lot of time trying to fix failing software... and sometimes we fail at that too. How can we get better at it? Here are some questions that this talk will try -- and probably fail -- to answer:
Why do we so often do things wrong when we know how to do things right? How can we create a supportive environment that is tolerant of failure? Why do we keep repeating the same failures? What do other companies do that make them better at responding to failure? What does a company's culture have to do with their ability to respond to failure?
How do we observe and reason about failure? Why is it so hard to estimate things that can fail and what can we do to get better at it? Can we measure how efficiently we resolve failures? What sort of failure response strategies could we use and what are their tradeoffs? What can system complexity and human psychology teach us about failure?
From systems thinking to project management to the interaction between culture and process, if you've ever wondered why you keep experiencing the same problems writing and shipping software then this talk is for you.
Assertions (or expectations) are the most important part of any test framework. How are they written? What happens when one fails? How does a test communicate its results? Past talks have shown how test frameworks work from the very top: how they find, load, select, and run tests. Instead of reading code from the top, we’ll write code from scratch starting with assertions and building up a full test framework. By the end, you'll know how every square inch of your testing framework works.
This talk is about the twin open source project goals of, on the one hand, increasing participation and contribution to an open source project, and on the other hand including everyone while eliminating discrimination and harassment (whether deliberate or accidental). I'll talk about different approaches to reducing discrimination, including better documentation, better development tooling, explicit onboarding process, and codes of conduct. I'll also cover concrete steps that anyone can take to help increase inclusion and participation in the teams, communities, and open source projects that they are involved in.
Our lives are filled with choices. And one thing's for sure: whether you're choosing what to eat for lunch, to add "just one more gem" to your Gemfile, or to start a new job, your choices *will* have consequences. If that's the case, let's step back for a moment to discuss how we tackle this thing we do so many times each day. Maybe we'll get better at making choices as a result? At the very least, we'll have some fun. Come equipped with your laptop or smartphone, as you'll be directly influencing the content of this talk as you make choices of your own! I hope you'll choose to join us.
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!
One of the most common reasons for using machine learning is because you want to use data to make sense of more data: given lots of things with many characteristics, how do you use them to categorize, make recommendations, or evaluate something new? We can use machine learning for all sorts of lofty goals, so let’s tackle a critical problem in our lives: whiskey. I’m a novice to whiskey, and so far I’ve stuck to the lighter stuff. Finding new ones to add to my collection has been decidedly unscientific. Given the data we have available about whiskey, let’s try doing a bit of machine learning by feeding it into TensorFlow, an open source library, to see what cool insights we can get into a complex spirit.