We have a great list of speakers for RubyNation 2013, including lots of well-known Rubyists such as Avdi Grimm, Bryan Liles, Nick Gauthier, Rich Kilmer, Evan Light, John Athayde, Bryan Helmkamp, Sandi Metz, Steve Klabnik, and our own Russ Olsen.
|09:00-05:30||Rails Girls DC Training Session|
|06:00-08:30||RailsGirls DC/RubyNation Twisted Willow Party Sponsored by AT&T and SAIC|
|08:00-09:15||Registration and Breakfast|
|09:30-10:10||Russ Olsen: Insight, Intuituion and Programming|
|10:20-11:00||Bryan Liles: Why We Do What We Do|
|11:30-12:10||Sandi Metz: Magic Tricks of Testing||Christopher Lee: RubyJS - Take Ruby's core with you client-side|
|12:20-01:00||Nick Gauthier: Rails 4 in Production||John Downey: DevOps for the Rubyist Soul|
|02:20-03:00||Jason Clark: Make an Event of It!||Bryan Helmkamp: Rails Application Security in Practice|
|03:10-03:50||Rachel Ober: How to Be A Ruby Mentor||John Schneider and Leo Zhadanovsky: DevOps At Obama for America and The Democratic National Committee|
Afternoon Break and Snack
|04:20-05:00||Emily Stolfo: Hacking the Academic Experience||Christopher Sexton and Josh Szmajda: Making AngularJS play nice with Rails|
|05:10-05:50||David Copeland: You Might "Are Gonna Need It" - Avoiding the MonoRail||Lauren Voswinkel: Putting Off Persistence|
McGinty's Pub Party Sponsored by Sequoia
|08:30-09:45||Registration and Breakfast|
|09:45-10:25||Kerri Miller: You Can't Miss What You Can't Measure||Josh Adams and Adam Dill: A Survey of Robotics with Ruby|
|10:35-11:15||Rich Kilmer: RubyMotion and Bluetooth 4||Dan Bernier: Object-Functional Fusion in Ruby|
|11:35-12:15||Andy Pliszka: Scaling Large Rails apps with Gems and Engines||Jim Gay: Following the Path of Programs|
|12:25-01:05||Evan Light: If It Bleeds, It Leads||Steven Haddox: PEACE: Programming Expertly Amid Corporations and Enterprises|
|02:25-03:05||John Athayde: The Timeless Way of Building||Benjamin Smith: Hacking with Gems|
Afternoon Break and Snack
|03:45-04:25||Dave Bock: Lightning Talks|
|04:25-05:05||Steve Klabnik: Rescuing Resque: An OSS story|
|05:15-05:55||Avdi Grimm: Code to Joy|
RubyMotion is a wonderful toolchain for iOS (and now OS X) development using Ruby. With RubyMotion, developers can finally write full-fledged native iPhone, iPad and Mac apps in Ruby, the language you all know and love. In this session, we will cover how RubyMotion works, we will talk about its internals and what makes it unique, and we will show how easy it is to write an iOS or Mac app with it.
In a past life Rich wrote parts of RubyGems, organized RailsConf and RubyConf, helped creating RubyMotion and was a VP at LivingSocial. These days, Rich is hacking on a very cool RubyMotion project!
Christopher Lee has over 12 years of software engineering and architecting experience. He works mainly in the Federal software development space as well as being Director of Software Development at Sequoia Holdings Inc. He enjoys all things technology, tinkering with the latest libraries and frameworks, working at all levels of the application stack and helping enable good teams to be even better.
What's the worst that could happen if your app has a dependency on a malicious gem? How easy would it be to write a gem that could compromise a box? Much of the Ruby community blindly trusts our gems. This talk will make you second guess that trust. It will also show you how to vet gems that you do choose to use.
Benjamin Smith is a developer at Pivotal Labs. He has a strong passion for TDD, pairing, Agile and using technologies that get out of the programmer's way. When not writing code, he follows his other passions into the outdoors to rock climb, back country snowboard, kayak and surf.
In Rails, we have a beautiful framework that can take us from a blank slate to a fully-functional app in little time. However, doing things "The Rails Way" has a lot of implicit dependencies, including persistence. Are you really equipped to make one of the largest decisions about your app before any of your code has even been written? By putting this decision off you can get a feel for your domain before ever committing anything to a db schema. This means fewer migrations and fewer db-related hacks. Also, these practices encourage encapsulation and interchangeability, which means you get the ability to choose which datastore is best for you. Not just on an application level, but on a per model level as well! During the talk we’ll be walking through simple examples at different points in application lifecycle. These snapshots will address the biggest pain points of a persistence free process and leave you in a position to put off persistence in your own app development!
Lauren has been doing web development for nearly a decade. Spending the first five years of her time in front-end development, she has since started diving deeper into the stack. She is currently burning her spare time by working on a project aiming to make organizing events or hangouts less of a pain. When she isn't programming, she can be found teaching courses or TAing with Girl Develop It! Pittsburgh, discussing queer and gender theory, encouraging tech diversity in whatever way she can, doing trick shots with a whip, or fire spinning.
Rails makes everything so darn easy sometimes. We're told to follow the "happy path", and not worry too much about what might come - "You Aren't Gonna Need It". Fast forward 12 months, and you're fighting the dreaded MonoRail, with a 10 minute test suite, obese models, and an uphill battle when you try to extract to services. Let's face facts - you can't live forever with one Rails app. Someday, perhaps sooner than you think, you'll have many apps forming a service-oriented architecture. The fact is, there are some things you're "gonna need" and a bit of planning up front will make your life easier later. In this talk, we'll talk about what's so difficult about Monolithic Rails apps, and how to move to, and plan for, a service-oriented architecture without getting wrapped up over-engineering things.
David Copeland is a programmer and author. He wrote "Build Awesome Command-Line Applications in Ruby", and has over 16 years of professional development experience. Mr. Copeland has managed high-performance, high-traffic systems at LivingSocial, helped build the engineering team at Opower, and worked consulting gigs both large and small. Currently, he's a lead engineer at fashion start-up Stitch Fix, building a platform that will change the retail shopping experience.
Everyone casts the 'Enterprise' as the most horrid place in the world to be a Ruby developer, and they used to be right. The efforts of those fighting for agile and development best practices inside the firewalls of large corporations often go unnoticed, but have made huge strides. This talk will demonstrate how to create a development environment and production setup that are nearly identical to those commonly used by the majority of Rubyists, only within the shackles of minimal sudo privileges. It will identify open source hosted alternatives to things taken for granted by other developers. Lastly, a demonstration will be given showing how to automatically deploy a 'Ruby Support Server' to provide these services for all Rubyists within an organization. The once forsaken desert of Ruby in the enterprise has become a lush land of opportunity where the intersection of security doesn't have to cost developers the luxuries of comfortable coding.
Steven has over a decade of programming experience and has been a Ruby developer since 2008. His career consists of a wide-variety of development and production environments which have led him to create tools like RVM::FW to help ensure that development can be consistent in a multitude of circumstances. You can follow him on Twitter or App.net as @stevenhaddox or read his blog at: http://stevenhaddox.com.
AngularJS is an amazing project but getting it to play nice with Rails can be daunting. It doesn't have to be. The Angular team says that it "is a toolset for building the framework most suited to your application development. It is fully extensible and works well with other libraries." Let's learn how to adapt it to work well in the Rails ecosystem. By following the Rails conventions in an Angular Way. After a quick primer on Angular, we will cover topics like dealing with the asset pipeline, unit testing your JS, file organization and integration with Rails-based APIs. MINASWAN and so our frameworks should be also.
Christopher was the first of 3 engineers at a little company called Radius Networks, where they build analytics systems for the real world. He cofounded the Arlington Ruby Group, helps organize RetroRuby unconference, and builds Captured http://www.capturedapp.com. When not writing code, Christopher plays LEGO with his son and does gymnastics with his daughter. He occasionally blogs at http://www.codeography.com.
Out of the box, Rails does its best to help you secure your app. Unfortunately, without consistent application of secure development principles, practices and tools, it's just a matter of time before vulnerabilities creep in. Despite Rails' secure defaults, most Rails applications have vulnerabilities, many of which are easy to detect and fix. As a community, increased awareness and understand of web application security puts us in the best position to avoid breaches (like the GitHub SSH key fiasco), and keep our businesses safe. The best time to start locking down your app is now, not after your first close call (or worse). We'll walk through exactly what you need to reduce the risk of a security breach to your business, beyond the Rails defaults.
Bryan (@brynary) is the founder of Code Climate, an automated code review tool for Ruby apps, and the lead organizer of the Gotham Ruby Conference in NYC. For the last seven years, he's been active in the Ruby community as an acclaimed speaker, author and open source contributor. In 2009, he received a Ruby Hero Award for his efforts.
Resque is a great open source project that many businesses rely on heavily, yet fell into a certain state of disrepair. I thought that was a shame, so I did something about it. This is the story, with tips and tricks for helping out on open source projects that may need a hand.
Rails committer, Jumpstart Lab Instructor, nomad philosopher
We all know and love Ruby, but there is a large target audience of new programers who haven't discovered it yet. As experts in Ruby, we need to be able to mentor a new thriving generation of Ruby programmers. Most of us are familiar with the push the past few years for everyone to learn programming (even Mayor Bloomberg got in on the action!) Some of us met the policy with excitement while others of us were worried that it would bring upon the next wave of "horrible developers." In this talk, Rachel will discuss how experienced developers can better approach newcomers and create a better community. The talk will cover the different motivations that novices come into her classroom with and how to best approach questions from rookies. With a better understanding of how people learn and how to teach, we have better tools to equip ourselves and as a side-effect, improve our own understanding of a programming concept through the fresh eyes of someone new to Ruby. The goal is to create a welcoming and thus more effective learning environment, be it in a classroom, the office, a meet up, or online.
Rachel Ober is a developer at Paperless Post in New York City. She also co-organizes NYC Ruby Women and teaches the Ruby and Rails portion of the "Front-end Web Development and Ruby on Rails" course at General Assembly. With a love for making things easy and pleasurable to use, Rachel focuses on a great user experience.
Ruby developers have many great options for simply hosting their web applications. But what happens when your product outgrows Heroku? Managing your own servers can be an intimidating task for the average developer. This session will cover the lessons we've learned at Braintree from building and maintaining our infrastructure. It will cover how we leverage Ruby to automate and control all of our environments. Some specific topics we'll cover orchestrating servers with capistrano, using puppet for configuration management, a cap and puppet workflow using git, how vagrant can provide a sane test environment, and some pitfalls you should avoid.
John Downey is a developer working at Braintree. Braintree helps businesses accept credit card payments online with great development tools and first class support. There he has worked on their highly available infrastructure and integrations into the banking system. In his free time he contributes to open source projects and mentors high school students in the FIRST Robotics Competition.
When I was asked to teach Ruby on Rails at Columbia University I observed that a significant number of the skills required to become a successful professional in the industry are acquired on the job and aren’t being taught in school. The fundamentals of Computer Science are still incredibly important to cover in university curricula but practice is just as important as theory. There is currently a significant difference between what university CS departments teach and what professionals do; if these programs hope to prepare students for graduate school as well as for the “real world”, they need to incorporate more emphasis on contributing to and using open source software, tools such as github, and sharing and reading other people’s code. Many of us professionals thrive on open source software and wouldn’t hesitate to copy-and-paste a snippet from StackOverflow, but academia isn’t teaching this type of resourcefulness to students. This presentation will cover: - Lessons learned from the experience teaching in my alma mater’s CS program. - How I developed a hacker-centric curriculum teaching not only the algorithms, but the keys to being a successful developer in the modern open source driven Rails community. - How we as hackers can fix this
Emily Stolfo is a Ruby Engineer and Evangelist on the MongoDB drivers team at 10gen and an adjunct faculty of Columbia University. Before joining 10gen, Emily worked as a Rails developer at a NYC startup but her history with Rails goes back to a research project at Paris' Louvre Museum. She has a degree in Computer Science and Art History and likes to run and attend concerts when not teaching Rails at Columbia in her free time.
The upsurge in asynchronous programming has brought event-driven patterns to the forefront. But even if you aren't re-writing your app in Node.js, evented patterns can improve your application. This talk demonstrates concrete examples of how events can benefit the various layers of your application. It shows how events can pitch in the fight against fat controllers (and fat models too!) It applies eventing to simplify testing and decouple our app from external dependencies. It even reveals how eventing can help shape data to provide flexibility and auditing.
Jason fell in love with programming as a young boy watching his dad work in Clipper and dBase III (no, really). The obsession sparked there continues to this day. His current language crushes are Ruby and Haskell, and he works for New Relic on the Ruby Agent. When not at work, he enjoys experimenting with programming languages, cycling, homebrewing, and hanging out with his family.
The Rails 4 beta is out (or maybe by the time this talk is given, the release!) and it’s packed with some amazing new features, especially when it comes to performance. Nick Gauthier has been using Rails 4 for a few months now and in this talk he’s going to share some of his favorite parts. From the clearer folder structure all the way to the guts of streaming responses, we’re going to see what Rails 4 is all about.
Adrift at sea, a GPS device will report your precise latitude and longitude, but if you don't know what those numbers mean, you're just as lost as before. Similarly, there are many tools that offer a wide variety of metrics about your code, but other than making you feel good, what are you supposed to do with this knowledge? Let's answer that question by exploring what the numbers mean, how static code analysis can add value to your development process, and how it can help us chart the unexplored seas of legacy code.
Kerri Miller is a Sr Software Developer and Team Lead based in the Pacific Northwest. She has worked at enterprise companies, international ad agencies, boutique consultancies, start-ups, and every place in between. She mentors and teaches students and interns through RailsBridge and other programs. Having an insatiable curiosity, she has worked as a lighting designer, marionette puppeteer, sous chef, and professional poker player, and enjoys hiking, collecting Vespas, and working with glass.
We all know Ruby supports functional style programming: it’s got blocks! But it’s still, at bottom, an object-oriented language. What are some ways we can combine OO and FP to good effect? * Passing blocks: the Strategy pattern was never so easy! * Breaking big loops into smaller loops with collect, select, and inject * Recursing through tree structures, like DOMs, JSON objects, hashes, and file systems * Composition, currying, and closures: declaratively writing validations, adapters, parsers, formatters, transformers, translators... We’ll take a look at examples like this, and how they’ll help you break down problems and DRY up your code.
@danbernier has hacked with Ruby since 2005. He works at SeeClickFix, in New Haven, CT, where he helps run newhavenrb.org. He blogs at invisibleblocks.com.
You've read blogs and seen talks with people telling you how to code. For anything you want to know, someone has already figured it out, and hopefully written a concise guide about it. For most people that's where the journey ends. In this talk, Bryan will explore why we do what we do. Starting with Ruby, which we all know and love, we'll unravel some of the reasons of why. We'll then move on to more esoteric topics, skipping right past the how and diving right into the why.
Bryan Liles is a well known programmer hailing from Baltimore, Maryland and he is officially the Greatest Man Alive. It even used to say so on his Twitter bio, and those are never wrong. Bryan has competed frantically for paychecks while securing government networks, protecting foreign travelers, and simulating diseases. He's even made a web site or two. Currently he develops top secret projects for Thunderbolt Labs.
Ruby's great and robots are neat, so we'll start off with a survey of robotics in ruby and then dive into some specific, fun projects such as: - Using JRuby on Android to control GPIO on the Raspberry Pi via drb - Controlling a Sphereo, Roomba, Parrot AR Drone with ruby via artoo.io - Reactor loops in ruby to control robots
Josh and Adam have been developing software professionally for over 14 years each, focusing mostly on web applications. Josh is serving as CTO for isotope | eleven, and Adam's working with various startups to help them solve sneaky math problems and/or usability concerns :)
"Design patterns" is a common phrase that is often spoken in the course of design and development of web applications. But it's genesis is not from programming, but Architecture. They come from a trio of books in the 1970s by Christopher Alexander, the most famous of which is the middle book: "A Pattern Language". The issue arises that Pattern Languages, much like spoken languages, are most effective when the speaker is fluent. We'll look at the origin of pattern languages and why they can be dangerous and even detrimental tools in the hands of the inexperienced designer and developer through examples of bad grammar and poor idiomatic choices (aka antipatterns), and perhaps some architecture as well.
John Athayde is a designer and developer who spends a lot of time fighting bad coding practices in the Rails view layer. He is currently the Lead for UI/UX and Front-end Development–Internal Apps at LivingSocial. Prior to LivingSocial he was the lead designer at InfoEther and ran Hyphenated People with Amy Hoy. He is currently looking for a large piece of land where he can garden and play in the dirt in between design and code sessions. In his free time, he plays guitar and keyboards for DC's own Juniper Lane. He holds his Masters in Architecture from Catholic University of America.
Scaling of large Ruby apps is difficult and frustrating. Tests take hours to run and provide little confidence. Adding new features to large applications takes longer than necessary. Working on large Rails applications is not exciting and lowers the team morale. In this talk I will demonstrate how to scale Rails application using Gems and Rails Engines. Divide and conquer approach results in fast test and well architected modular applications.
Andy Pliszka (@AntiTyping) is a developer at Pivotal Labs and the organizer of AlgorithmsNYC Meetup. He worked on multiple projects ranging on financial exchange written in Erlang, web applications using Ruby on Rails, and computer vision using Python. He enjoys implementing computer algorithms in variety of computer languages.
Clean code, pragmatic code, confident code, beautiful code. There are many coding ideals worth pursuing. I want to talk about joyful code---those techniques and idioms that surprise and delight us with unexpected elegance.
I got into Ruby because writing it made me happy, and after all these years it still finds ways to make me grin. Join me for a random walk through the Ruby language and standard library, stopping in to visit some of my favorite tools, hacks and implementation patterns. Some you may know. Others, more obscure. My goal: to rekindle in you the joy of code, to inspire you to share that joy with your peers and with the next generation of developers, and most importantly, to bring a smile to your face!
Avdi Grimm has been hacking Ruby code for over 10 years, and is still loving it. He is chief aeronaut at ShipRise, head chef at RubyTapas.com, and a Ruby Rogue. He lives in southern Pennsylvania with his wife and five children, and in his copious spare time blogs and podcasts at Virtuous Code and Wide Teams.
Tests are supposed to save us money. How is it, then, that many times they become millstones around our necks, gradually morphing into fragile, breakable things that raise the cost of change? We write too many tests and we test the wrong kinds of things. This talk strips away the veil and offers simple, practical guidelines for choosing what to test and how to test it. Finding the right testing balance isn’t magic, it’s a magic trick; come and learn the secret of writing stable tests that protect your application at the lowest possible cost.
Sandi Metz has 30 years of experience working on projects that survived to grow and change. She’s the author of the recently published “Practical Object–Oriented Design in Ruby” and (as all who read the book know) an avid cyclist. Fundamentally, however, she is someone who writes object–oriented code.
A Presidential Campaign is a billion dollar, over 6000 person organization that exists for roughly two years, and then disappears. How do you setup a systems infrastructure for such an organization? How do you avoid organizational silos? Why even do DevOps? What was the culture like and how did it meld with the traditional culture of political campaigns and committees? What are some lessons learned from the 2012 campaign -- what things worked and what didn't? What apps were written in Ruby and how were they deployed? Come learn about the answers to all of these questions, as well as our technology stack (AWS/Puppet/Ubuntu/CentOS/Github/Juniper/Nagios/OpsView and much more), why we chose it, how we set it up, and how we made it work.
Leo Zhadanovsky is a Senior Solutions Architect at Amazon Web Services. He was previously the Director of Systems Engineering at the Democratic National Committee. From 2009 to early 2013, he ran the DNC's physical server and cloud footprint. In 2010, the DNC successfully ran and deployed many applications, such as a Call Tool and Voter Registration website, that were written in Ruby and ran on AWS. In 2012, the DNC supported the Obama campaign with various backend APIsm, web sites and a large Vertica cluster.
Lightning Talks hosted by Dave Bock
David Bock is a founder at CodeSherpas, where he actively consults as a software engineer, project manager, and team mentor for commercial and government clients.
We programmers tend to think of ourselves as concrete, logical thinkers. We work from step 1 to step 2 through to step N. So we say. But real life is not like that: One minute you have no idea how the new design will come together and the next, well, there it is. One minute you haven't a clue as to why the program is doing *that* and the next it is all just obvious. And we have all seen code that is wonderful -- or horrible -- in some indescribable way. In this talk Russ Olsen will explore the role of insight and intuition in programming: How does intuition work? How do you generate more of those AH-HA moments? And when should you ignore that voice whispering into your inner ear?
Russ Olsen likes to think that the technology is there to solve problems for people, not the other way around. Russ started his career doing that other kind of engineering, the sort that involves electricity, gears and getting dirty. Pretty rapidly the wonder of computer programming lured Russ away, which probably explains why most of his fingers are still intact today. Russ can be found on twitter at @russolsen and at RussOlsen.com.
Creating software is difficult. It's not just you that needs to understand it, it's the users, the business owners, and the other developer who needs to pick up where you left off (even if that's you a year later). Keeping your code free of distraction means staying focused on what really matters. Building software is a constant reminder of how many ways there are to skin the cat. While they may be no right answer, there are good and better answers. Together we'll talk about object-oriented programming and techniques to make sense of our business. We'll explore modeling with DCI and how this affects your thinking by keeping the right things together and distractions away.
Jim is the author of Clean Ruby (http://clean-ruby.com) and has been exploring object-oriented techniques in his code. His 4 children have taught him to embrace chaos and attempt to make clarity.
Many of us came to Ruby by way of Rails (including yours truly about six years ago). We came because our current solutions were clumsy and inconvenient. We came because we appreciated the relative simplicity that Rails offered. And we came because we believe that change is often a good thing. But not all changes are beneficial. Over several blog posts, books, and a couple of years, the Rails community has begun to choose complexity over simplicity. Let's talk about why. And let's talk about how we can try to recapture that simplicity that we so once adored.
When not polishing his bio for conferences, Evan (@elight) works as a freelance consultant and developer tutor working remotely from the cradle of culture and beacon of brilliance that is Ocean City, MD. He also organizes, if it can be called organized, the annual Ruby DCamp unconference that has never, in fact, been run within the borders of Washington, D.C.