I’m sure you have to choose a template engine when you’re working on a web app. So almost everyone here must have your favourite template engine, I guess.
Today I would like to tell a story about me and the Ruby template engines.
If you think you’re totally satisfied with your Ruby template engine, maybe you will learn that your template engine is not perfect. Or, for those who are already feeling unhappy with something in your template engine, I’ll tell you what you should do next.
Ricochet Robots is a puzzle board game for any number of players. While being a very fun game to play with some fascinating properties, it is also interesting to think about writing a program to play the game.
Let’s discuss a computerized player for Ricochet Robots that finds the optimal solution to any board in a reasonable amount of time. Along the way, we’ll learn about graph search techniques, data representation, algorithms, heuristics, pruning, and optimization.
Ruby is a fantastic language, but it could be better. While it has done a terrific job of taking ideas from languages like smalltalk, lisp, and (to an extent) perl, it hasn’t done nearly enough of it.
Big thinkers like Alan Kay & Dan Ingalls (smalltalk), David Ungar (self), Guy Steele & Gerald Sussman (scheme), and Matthias Felleisen (racket) have paved the way for so many programming language ideas that we should plunder the treasures that they’ve thought up. You might not know their names, but you’ve certainly used their technology.
I will survey a vast minority of these ideas and how they could help ruby. Ideas including: self-bootstrapping implementations and extensive collection and magnitude hierarchies from smalltalk, instance-based inheritance and JIT compilation from self, TCO and the overarching importance of lambdas from racket/scheme, and finally object level pattern matching and the combined object/lambda architecture from the View Points Research Institute.
Ruby is at its best when borrowing great ideas from other languages, but lately it has fallen behind in this. It’s time for ruby to step up and do more with these ideas, to keep pushing forward, to stand upon the shoulders of giants.
Ruby might be one of the easier languages for learning programming, but that doesn’t mean it holds the programmers hand in any way, or is somehow easy. Exactly the opposite. Ruby is flexible enough to allow coders to do just about anything the like, for better or worse. So why is it the language of choice at the coding bootcamps springing up across the country, when it allows new programmers to get into so much trouble? Are we doing these young programmers a disservice by teaching Ruby simply because we love our deliciously readable and expressive examples, or are we tapping into something better for students, an enlightened path that is more likely to propel them up and over the steeper learning curve Ruby demands? With Ruby, students are thrown into the deep end of a culture that believes strongly why we do things one way rather than another. There is a common goal to make the right way to do things also the easiest way. Collaboration is the norm, which is the best way to learn. I could go on, and I will, in the talk. I’ll expand on why Ruby is great as a first language because we are great as a community. We demand so much more from our junior programmers because the tooling is so good and the language is so approachable that students grasp advanced concepts much sooner on the path. We hold juniors to higher levels of quality, testing, and readability and they are better developers in the long run for it. Ruby is a great first language because discussions of the ‘how’ quickly give way to the ‘why’, and junior developers get it, and they don’t stay junior developers for long.
Research shows that opportunities for learning and career growth within a company are hugely important for employee retention and engagement. We also know that in the software world our tools become obsolete every few years. And yet even the most enlightened employers leave it to their engineers to learn in their free time. We’ll discuss some relevant issues and approaches to the problem with an eye towards changes that work in the real, deadline-driven world of software development. We’ll also talk about several things that have or haven’t worked in my experience trying to build a culture of learning in a regulated financial services company. For example, a company that’s hesitant to delay critical projects for formal training may be fine with lunchtime workshops. Participants should walk away equipped to start building momentum at any level in their organization towards constant learning and improvement.
Zed Shaw famously promised to kill progammers who didn’t learn statistics. I intend to save your life by teaching you just enough statistics to plan and improve your A/B tests, understand your performance metrics, and use good data to make important decisions. We’ll cover the basics of descriptive statistics, bust common myths, simulate the real world with code, address uncertainty using Bayesian statistics, and answer questions both inane and insane with Fermi estimation. Save your life and make better decisions by spending this session learning statistics.
“The delicate balance of mentoring someone is not creating them in your own image, but giving them the opportunity to create themselves.” - Steven Spielberg
In our world of never ending Stack Overflow answers and Github code reviews, there still remains some knowledge that can only be found through experience. Mentoring relationships are an indispensable part of any developer’s career and allow for experiential knowledge transfer. Programming, as a culture, has an underdeveloped network of mentors. As a community, we need to turn mentorship from a wishful yearly resolution into a cultural reality.
We’ll use research from scholars like Kathy Kram and historical examples of mentor-protege pairs (think: Larry Page/Marissa Mayer ), to get to the bottom of what makes a successful pair tick. Finally, we’ll share some of our experience in putting this research into action so that you may join us in discovering what it takes to cultivate a meaningful mentorship.
Many of the greatest achievements in the history of computers are based on lies, or rather, the strategic sets of lies we generallly call “abstraction”. Operating systems lie to programs about hardware, multitasking systems lie to users about parallelism, Ruby lies to us about how easy it is to tell a CPU what to do… the list goes on and on.
One of the primary “strategic lies” of the internet is the presentation of each service as though it were a discrete, cohesive entity. When we use GitHub, we think of it as just “GitHub”, not a swarm of networked computers. This lie gives us the opportunity to build high availability applications: apps designed to never go down.
Let’s take a tour through the amazing stack of tools that helps us construct high availability applications. We’ll review some of the incredible technology underlying the internet: things like TCP, BGP, and DNS. Then we’ll talk about how these primitives combine into useful patterns at the application level. I hope you’ll leave with not only a renewed appreciation for the core innovations of the internet, but also some practical working knowledge of how to go about building and running a zero-downtime application.
Rails gives us great conventions for building an application, but what conventions should we use when we are building a whole system that encompasses multiple applications? How should we name things? What abstraction layers should we enforce?
The MX team has been building a distributed system composed of Rails applications for the last 3 years. We’ll talk about failed ideas, conventions that have stood the test of time and some experiments that are underway.
There are dozens of code metrics tools available to Rubyists, all eager to judge our codebases and tell us things that we probably already know. But when technical debt is piled high and feature friction really sets in, we need more than to know that our User class has a “D” grade. How can we use tools and tests to help us formulate a refactoring plan that amounts to more than just rearranging bricks in a crumbling building? Let’s explore some of the more interesting code analysis tools, take a look at our testing techniques, and find novel ways to combine them into a meaningful refactoring strategy.
“I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is “messaging” - that is what the kernal of Smalltalk/Squeak is all about (and it’s something that was never quite completed in our Xerox PARC phase).” - Alan Kay
Object oriented programming is what gets a lot of attention, and it is often set in opposition to functional programming. However, it seems that OOP with its focus on classes, inheritence, and polymorphism missed what Alan Kay was really working on - messaging systems.
In this talk we will examine the fundamental pieces to what I am calling message oriented programming. We will look at the request/response message pattern, we will look at the structure of messages themselves, and we will look at how protocols can be created to enforce a sane message passing system.
We will also look at how this fits with Ruby, OOP, FP, and modern distributed computing patterns like REST, SOA and microservices. They are all related an it’s clear that message oriented programming has a place in the programmer’s toolbox. In fact, we are already using message oriented program to power modern applications, we just don’t know it yet.
This presentation will describe an approach to routing web requests efficiently through the use of a routing tree. A routing tree usually routes requests by looking at the first segment in request path, and sending it to the routing tree branch that handles that segment, repeating until the entire path is processed.
At any point while handling a request, the routing tree can operate on the request, for things like enforcing access control or object retrieval from a database, where such behavior is common for the entire branch. In addition to considering the request path, a routing tree also usually considers the request method, and may consider information from the request headers or request body when deciding how to route a request.
A routing tree’s request handling is similar to how a file system processes requests for files, where it looks at the first segment of the path, sees if it is a directory, and if so, looks for the rest of the path inside that directory.
This presentation will describe what makes routing requests using a routing tree faster and simpler than the routing approaches used by the popular ruby web frameworks.
It is a fact of life: When you are running a website stuff goes wrong. Someone puts a dictionary on the keyboard and reloads your site a million times. Your mobile app hits an error state and sends messages that cause 500s on your server. An external service takes 5 times as long as normal to respond to a request.
When responding to problems logs are frequently our go to for investigating events but plain logs aren’t user friendly or efficient. Using BigQuery for log investigation lets you use familiar tools like SQL to dig into your logs, extract the interesting data, and even make charts of the data.
Ruby doesn’t require developers to manage memory. It definitely makes our work less frustrating, but losing sight of the memory implications of our code, will get us into trouble! In this talk, I’ll go over common (and less common) memory pitfalls, why they work the way they do, and how to avoid them.
Let’s talk about language exploration. We’ll discuss how to learn a new language, considerations when introducing things to production, and come up with some ideas for Ruby and it’s ecosystem. Plan on dipping your toes in Elixir, Go, Haskell, Rust, and Scala during the session.
As a programmer, work-life balance has always been a tricky thing for me. Steve Wozniak commented that “you can’t stop the steamroller of technology change.” That notion has been applied to software. If you rest you risk being squished.
I wrestle with impostor syndrome, and maybe this is just an extension of that. As a rubyist it’s difficult to keep up. Everything evolves quickly (ruby, rails, gems, related technologies, methodologies). I consider myself a full stack developer, and a stubborn one at that. I’ve fought with a Makefile for weeks just to get some package to compile on some *nix variant.
We are paid for our ability to solve problems. It requires a lot of practice. I’ve learned to be ok with not knowing how to do things, but I still “hear the footsteps.” I don’t really know what it means to be “good enough” yet, but this talk will explore those lines between work/life balance and how we keep our edge on the job while being present in the moments off the job.
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 tradeoffs we’re making together.
A live coding session. Real maze algorithms. 3D surfaces. Animations, first-person fly-throughs of spherical and toroidal mazes. Hexagons, octagons, and regular tilings. Mazes in shapes you never even dreamed of.
Coloring techniques. Rendering techniques. Visualization. HOLY MOTHER OF THESEUS! This is going to be so hot.
But bring a seat belt, because it’s going to move really, really fast. Don’t blink or you’ll miss something awesome. Maybe bring some eye drops, too, because your eyes will get really dry from all that NOT BLINKING.
Think I’m joking? Show up and call my bluff.
I want to teach you a bit about music theory and how to write music, using ruby. I’ll also walk you through some principles of audio engineering along the way.
I’ll teach you how to write notes, octaves, chromatic scales, major scales, minor scales, modes, thirds, chords, chord scales, chord progressions and more.
Rather than keep talking, I’ve decided to give you a brief sample of my presentation:
If you are short on time,
Building a sound wave & note starts around :45 Visualization of the note audio wave starts around 2:40 Demos of notes, scales, chords, etc, start around 4:00