The 10th and Last MWRC – March 21-22, 2016

SESSIONS

SCHEDULE

SPONSORS

5K FUN RUN

HOTEL GROUP RATE

LIGHTNING TALKS

Akira Matsuda

A Quest for the Ultimate Template Engine
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.

Ryan Davis

Standing on the Shoulders of Giants
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.

Ben Eggett

Writing Music with Ruby: A subtle introduction to music theory
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: http://youtu.be/FRxMhBsqXys 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

Aja Hammerly

Forensic Log Analysis with BigQuery
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.

Mary Elizabeth Cutrali and Danny Glunz

Meaningful Mentorship for Developers
“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.

Barrett Clark

"Good Enough"
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.

Ernie Miller

Humane Development
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.

Jamis Buck

Twisty Little Passages
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.

Randy Coulman

Solving Ricochet Robots
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.

Joe Mastey

Building a Culture of Learning
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.

Paul Hinze

Smoke & Mirrors: The Primitives of High Availability
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.

Coraline Ehmke

Data-Driven Refactoring
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.