I love Ruby, but last year I found myself at the Smithsonian Institution coding in, of all things, PHP & Drupal. And I realized that despite my ambivalence towards those technologies, I had no compelling-enough reason to propose Ruby as an alternative. How did we get to this point? I’ll tell 3 reasons we didn't use Ruby, and reflect on whether these are things we want, or problems we should solve.
Monads are in danger of becoming a bit of a joke: for every person who raves about them, there's another person asking what in the world they are, and a third person writing a confusing tutorial about them. With their technical-sounding name and forbidding reputation, monads can seem like a complex, abstract idea that's only relevant to mathematicians and Haskell programmers.
Forget all that! In this pragmatic talk we'll roll up our sleeves and get stuck into refactoring some awkward Ruby code, using the good parts of monads to tackle the problems we encounter along the way. We'll see how the straightforward design pattern underlying monads can help us to make our code simpler, clearer and more reusable by uncovering its hidden structure, and we'll all leave with a shared understanding of what monads actually are and why people won't shut up about them.
As Rails developers we depend on the network. But if you're new to web development, it's probably a mystery. That's a problem. Knowing how the network works is critical for fixing certain types of bugs and for diagnosing performance issues.
In this talk, we'll follow the lives of a TCP and an HTTP request, marvel as they pass through your browse, OS, router, web server and app serve. Finally, we'll discuss how this knowledge is used to fix common bugs and increase app performance.
Board games are seeing a huge resurgence right now, everywhere you look people are playing new games. The Internet and crowd funding has made it possible for almost anyone to design and develop a physical board game.
Join me while I share the story of how I used Ruby to design my first board game. How I honed the game mechanics and optimized all the different moving parts. You will leave this talk knowing the process of designing and developing a board game from scratch and how Ruby can help you iterate fast on new ideas using simple code, simulations and some statistics.
Storage gets cheaper every year and as a result many folks are turning into data hoaders. Maybe your current project has gigabytes or even terrabytes of data sitting in storage. Perhaps some has used the words "big data", "data mining", or "personalized experience" as an excuse to keep paying the storage bills.
Do you actually look at that data? How often do you use it? Is it really worth keeping it around? Do you know what questions it can answer?
In this talk I'll discuss how to use data to drive improvement and when to let it go. I'll focus not only on analysis tools, but also on interpretting data and how to decide if your data is valuable or clutter.
The real world is a messy place, and software reflects this to some extent. This messiness, however, doesn't mesh well with the general tendencies of software developers, who like to try to simplify the world with assumptions. When those assumptions later turn out to be wrong, bad things happen.
In this talk, we'll discuss three perennial sources of bad developer assumptions: floating point numbers, dates and times and the names of people, places, and things.
We'll illustrate why each of several commonly-made assumptions is incorrect, show how to use Ruby to arrive at the correct answer, and empower you to make better decisions about your code in the process.
With the increase of code academies training new engineers there is an increase in junior engineers on the market. A lot of companies are hesitant to hire too many young engineers because they lack sufficient resources to train them. This is a talk about how to make junior engineers into independent and productive members of your engineering team faster and cheaper by outlining a plan for how to onboard engineers effectively based on data and anecdotes gathered from companies in San Francisco.
Over the past years I've created numerous open-source libraries, but my biggest and most popular open-source Ruby projects aren't my own. Three years ago I took over Grape and more recently Hashie Hashie. Both are very important to the community and used by thousands of projects.
Taking over someone else's project without just forking it away is both a commitment and a challenge. It's often ungrateful work, but it's really important. In this talk I'll give some history, motivations and practical tools of how to do it. What do to when maintainers go MIA, and more.
As someone who once cut teeth in quantitative finance, I can tell you that a huge fraction of 'data science' is data collection. Yes, it's kind of unsexy, but it's hugely important. If you have bad data, you have no chance of drawing good conclusions from your data consistently. That was the thought behind the Fluentd project: we realized that the reality of data collection (especially for log data) is messy, and we wanted to clean it up.
In this talk, I plan to code live onstage to show how easy it is to get started with Fluentd by creating a useful data collection pipeline.
Hashes are very useful for labeling little bits of data. But do you know how cool they really are? For instance, whether a hash has 10 keys or 10 million doesn't change how long it takes to find the key you're looking for.
How does that work? I'll show you! We'll build our own hash class in Ruby. I'll also show you that "Big O" analysis isn't scary as we make our hash lean and mean.
Finally, we'll see what our hash can teach us about related topics, like programming languages and databases. Come ready to learn!
We all love ActiveRecord. Its amazing. But how exactly does ActiveRecord handle generating complex SQL queries? How Joins, Associations and Table Relations are handled? Most of this raw power comes from ARel. ARel is packed up with many features for complex query generation.
Lets build our own ORM on top of ARel to see it in action. In the process we will also explore about how ActiveRecord hooks up with ARel.
This talk describes Relational Algebra, Object and Collection modelling of ARel using a tiny ORM at its base. At the end of talk you will be equipped with better understanding of ARel and AR as an ORM.
As developers, most of our time is spent on computers and electronic devices; but sometimes good old-fashioned pen and paper is the best way to explore and develop our ideas. Sketchnoting combines hand-drawn elements and text to enhance focus, improve memory, and visualize important concepts. The practice of sketchnoting is not about the ability to draw—it's about the ability to listen.
This talk will cover tools and techniques to visually capture ideas, how to approach the mental multitasking required to sketch during technical talks and meetings, and why "I can not draw" is just a mental barrier to embracing creativity in your notes.
For software engineers, troubleshooting is one of the toughest and most important skills to develop. When problems arise, a beginning developer's first instincts are to panic and head to StackOverflow. Rather than quick fixes, it's important to seek a deeper understanding of what went wrong.
Biologists, chemists, and physicists increase understanding about the world by applying the logical steps of the scientific method to discover solutions to complex problems. Like scientists, developers can learn troubleshooting skills by treating each problem like a mini "science" experiment.
In this talk we'll explore how using the scientific method can lead to greater understanding and more viable solutions to complex problems.
The increasing accessibility of computing and scripting languages means more and more of us don't have computer science fundamentals and hand-wave our laptops and servers as magic. But, it doesn't take much to learn that the wizard box you type on every day is just layers of simple logic wrapped and reused all the way up. Indeed, starting with a single nand gate you can build the entire realm of boolean logic, and from that, a computer.
Working through a curriculum called Nand to Tetrisand its associated text book The Elements of Computing Systems, the Seattle.rb Study Group did exactly that. In just 12 short weeks,we went from nothing to a whole stack computer starting from just a single nand gate. We built a (simulated) computer, an assembler for its machine code, a virtual machine, a high level language compiler, and an OS with games to run.
In this talk, I will start with the nand gate, and build up a working computer explaining each layer as I go. You may not be able to build along with me in just a half hour, but I hope to infect you with my love for this curriculum and hopefully have it spread to your ruby/study group.
Lightning talks are back! Share your Ruby-related talk of four minutes or less with 400 of your closest friends. We welcome the wacky, the serious, the ranty, and the technical.
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. The Gilded Rose code kata is a coding exercise for practicing refactoring and testing skills in a legacy codebase.
In this presentation, I use the Gilded Rose kata to demonstrate techniques for safely working with a legacy codebase and using pure baby-step refactorings to improve the design.
Congratulations. The Internet is now the center of civilization as we know it, and we are the ones who shape the Internet. Our skills are in high demand, we are paid well, we find our work challenging, interesting, and even sometimes fulfilling. These are the glory days of our industry, and we should soak up every minute of it!
But with such great power comes a great deal of responsibility. Will we be looking back in the near future, wondering if we squandered our opportunities to shape the digital world accordingly?
There's no doubt that we value humanity, intelligence, and compassion. Let's take a look at the ways our industry can ensure these values are reflected not just in the people we are, but the way we work.