Jeff CasimirCo-founder of Jumpstart Lab
I started teaching in 2003 with Teach for America in my native Washington, DC. I first taught middle-school students, then taught Computer Science to high schoolers, and finally helped start a new charter middle school in a role most easily described as “Vice Principal.” I love teaching developers because you are giving people the power to build their dreams.
Keynote: What is a Developer?
Jim WeirichChief Scientist at EdgeCase
Jim Weirich first learned about computers when his college adviser suggested he take a computer science course: "It will be useful, and you might enjoy it." With those prophetic words, Jim has been developing now for over 25 years, working with everything from crunching rocket launch data on supercomputers to wiring up servos and LEDs on micro-controllers. Currently he loves working in Ruby and Rails as the Chief Scientist at EdgeCase, but you can also find him strumming on his ukulele as time permits.
Keynote: Y-Not — Adventures in Functional Programming
One of the deepest mysteries in the functional programming world is the Y-Combinator. Many have heard of it, but few have mastered its mysteries. Although fairly useless in real world software, understanding how the Y-Combinator works and why it is important gives the student an important insight into the nature of functional programming.
Join with us on this journey of understanding. Be prepared to curry your functions and bind your lambdas as we delve into the whys and wherefores of this paragon of functional programming. Although you will probably never have a need for the combinator, the effort put forth to understand it will improve your functional programming chops. This talk is not for the faint of heart, but the successful student will be richly rewarded.
Also, you will understand why "Y-Combinator" is the perfect name for Paul Graham's start-up funding company.
Mike BurnsCompany: thoughtbot
Mike Burns plays many roles at thoughtbot, including the Haskell enthusiast, their sole Linux user, an object-oriented programmer, unix historian, and the head of the European branch. Talk with him about Scala, Android, Smalltalk, Scheme, how grep got its name, or Ruby if you must. He also has the power to accept your paperclip pull request; bribery is welcome.
When Not to Use Object-Oriented Techniques
Object-oriented Ruby is a hot topic in the Rails world and beyond, but it is not always the appropriate solution.
In this talk I discuss various OO techniques, when to use them, and when a simpler pattern exists in the functional, declarative, or procedural world — including, yes, the Rails framework itself. You will leave knowing when to use an aspect instead of a decorator, a mixin instead of a presenter, or a monoid instead of a factory.
Topics will include:
- The benefits of code coupling.
- What makes Rails so anti-OO, and why that is good.
- Testing non-object oriented code.
- Good uses of classical OO design patterns.
- How to use a continuation.
Mary CutraliCompany: LivingSocial
Mary began learning Ruby in her living room during July of 2011. She has learned so much in Hungry Academy and no longer considers herself an accidental Rubyist. Her interests include gifs of shiba inus, the garbage collector, email processes, and wearing scarves year-round.
Hungry Academy: Learning to Be a Developer in Five Months
Co-presented with Melanie Gilman, see below
Much has been said about LivingSocial's Hungry Academy by the people running it, this is the perspective of two graduates.
We started in Hungry Academy in March with almost no programming experience. We learned an incredible amount during the five months of the program, not just about Ruby and Rails, but also about what it means to be a developer and an active member of the open source community.
We'll discuss some of the highs and lows of our experience in Hungry Academy:
- Group dynamics and project teams
- Classroom dynamics and instruction
- Performance Evaluations
- Immersion in the Ruby and Rails community and culture
- Work/Life Balance
- Diversity - gender, age, ethnicity, marital status, etc.
- Transition into development roles at LivingSocial
Despite a few rough patches, which are to be expected during a program as new, unique, and innovative as this one, we consider Hungry Academy to be one of the best experiences of our collective lives.
Melanie GilmanCompany: LivingSocial
Melanie started learning Ruby and Rails in March in Hungry Academy, LivingSocial's intensive developer training program. With almost no programming experience going in, she succeeded in learning enough in five months to consider herself a real developer. She likes to eat almost every kind of food, solve Rubik's cubes, and one day wants to learn to write Ruby extensions in C.
Hungry Academy: Learning to Be a Developer in Five Months
Co-presented with Mary Cutrali, see above.
Adam HawkinsCompany: Radium Software
My name is Adam Hawkins. I'm a rubyist, rails guy, and general open source nerd. I love to contribute to open source projects I use as well as write my own. I scratch my own itches through my open source work. When I'm not coding I travel and enjoy trance in very heavy doses.
Advanced Caching in Rails
Caching in rails is complicated. There is: Page caching, action caching, fragment caching, low level caching, and HTTP caching. This talk will guide you through basics and best practices of each. Caching is extremely important your app's performance so this talk will help you get it right. It will cover:
- Auto-expiring cached content
- Caching collections
- Page/Action/Fragment/Low level (Rails.cache) Caching
- Explaining Rack::Cache
- Cache warming for JSON API's
- Caching at the model layer
- Techniques for caching multiuser HTML
- HTTP caching for public/private APIs
- HTTP caching vs Page/Action caching
- Tag based caching for easier expiring
Danish KhanCompany: GitHub
I realized I wanted to learn practical programming skills so once I found out about Ruby in college I immediately installed Locomotive on my Mac. Was extremely excited to find out I already had Ruby 1.8.6 preinstalled on my iBook G4 and started hacking on my first Rails project. I find teaching to be enjoyable and have been participating in the SF RailsBridge every so often. I'm still a level 1 whiskey/whisky drinker, but I'm working on that. Currently I am working at GitHub doing cool stuff.
Ruby is now 18 years old. It has become a very mature project and the developers that have been using it are a lot more mature now as well. Our community has long since crossed the chasm and we are in the early majority stage. This means that even though we have many people who are well versed in the language we are again having an influx of new people.
I want to help those new people feel comfortable enough to believe they can learn and become just as mature as the oldies who are part of the community. Also, I want to educate the oldies on how they can better help out these newbies.
The Ruby community has become very much like any other close-knit community. We are very biased towards certain philosophies such as agile development, pair programming, and TDD. Some might compare our community to other close-knit organizations such as fraternities/sororities, athletic clubs and the freemasons. They all have very idealistic philosophies they run their organizations on.
I want to show how we compare to these types of organizations. I want to highlight the good things we adopted from running our community this way as well as the bad. I want to show how we can improve and fix the bad habits so that we can create a more open community for new people to join and feel welcomed.
Steve KlabnikCompany: Jumpstart Lab
Designing Hypermedia APIs
Rails did a lot to bring REST to developers, but its conception leaves the REST devotee feeling a bit empty. "Where's the hypermedia?" she says. "REST isn't RPC," he may cry. "WTF??!?!" you may think. "I have it right there! resources :posts ! What more is there? RPC? Huh?"
In this talk, Steve will explain how to design your APIs so that they truly embrace the web and HTTP. Just as there's an impedance mismatch between our databases, our ORMs, and our models, there's an equal mismatch between our applications, our APIs, and our clients. Pros and cons of this approach will be discussed, as well as why we aren't building things this way yet.
Joe KutnerCompany: LogicHaus, LLC
Joe Kutner is the author of “Deploying with JRuby” from the Pragmatic Bookshelf. He has been building JRuby applications since 2006 for clients including IBM and NASA. Today, Joe is a professional software consultant and founder of LogicHaus, where he builds Ruby and Rails applications for customers of all sizes. He also contributes to several JRuby projects including TorqueBox and Trinidad.
Deploy, Scale and Sleep at Night with JRuby
Your website has just crashed, and you're losing money. The application is built on Rails, runs on MRI, and is served up with Mongrel and Apache. Having this kind of infrastructure means that you're managing more processes than you can count on two hands. It will take a while to get back online because there are so many components in your system; including resque, monit, cron, Ruby Daemons, and more. But the website has to get up and running if you are going to stay in business.
The problem I've just described is all too common. It has happened to everyone from small start-ups to large social networking sites that use Ruby to serve millions of requests. But the recent growth and increased adoption of the Java Virtual Machine (JVM) as a platform for Ruby applications means that this is no longer the only way of doing things.
In this talk, I'll discuss the new architecture and deployment strategies that JRuby enables, and why they're better for your Rails applications. I'll talk about what makes JRuby more scalable and show some benchmarks that prove it. I'll also discuss three deployment strategies that can be used with any Rack-based JRuby application, and provide an overview of how each one works. I'll focus on the technologies that make them possible, and when it's appropriate to use each strategy. They include:
Warbler: a gem can be used to create a self-contained web application archive file.
Trinidad: a light-weight web server for creating flexible, modular deployments that still feel friendly and familiar.
TorqueBox: an all-in-one environment that includes built-in support for messaging, scheduling, daemons and clustering.
Choosing the right JRuby deployment strategy will not only provide a powerful and reliable platform -- it will help you get more sleep at night.
Ville LautanalaCompany: Flowdock
Ville Lautanala is Lead Developer at Flowdock, a finnish startup working on collaboration software. He likes dangerous programming languages and distributed systems. In fact, he is so concurrent that he lived for a while on "semaphore bridge". He occasionally also makes small contributions to small open source projects.
The Tale Of A Server Infrastructure
This talk will explain how we got drunk and lost track of our servers, how we sobered up and still had a hard time administrating them, and how we finally managed to get on top of our server infrastructure and transform the architecture into the shiny majestic thing it is today. It is a survival story of sorts, where a Zookeeper and a Chef comes to the aid of a young newcomer trying to make it big in the bustling scene of startups.
This talk will discuss the architecture of our app and server infrastructure at Flowdock. We will talk about importance of decoupling in order to:
- ease development and maintenance
- scale your app
- maintain high-availability
- impress your friends with your architecture layout
- keep a zoo
Brandur LeachCompany: Heroku
Brandur is a Canadian computer engineer working for Heroku in San Francisco. While his career started doing .NET work for big enterprise, he eventually found nirvana working with open frameworks like Rails that act as the leading edge of the industry for ideas, and pack a far mightier punch. Today he works on the core Heroku API that empowers developers around the world, and acts as the nerve center for a highly distributed platform.
Post-Rails? Composable Apps with a First-class API.
Rails is the best framework for building web apps in the world, but is there a way we can get even greater leverage of Rails' strengths while producing a more maintainable system? Brandur talks about lessons learnt while separating API from the web, and how this pattern can be reused elsewhere for the greater good:
- More manageable codebases and healthier developers
- Using Rails for what it's best at—building web apps
- Keeping designers happy by giving them well-constructed APIs and saving them from constant operational load
- Using ActiveModel to face back onto your own platform
- Building self-service APIs for customers, but which are also reused by any number of internal components
- Opening the gates for the rest of the software ecosystem—Backbone apps and iOS
Terence LeeCompany: Heroku
Terence works at Heroku maintaining the Ruby stack and a slew of OSS projects such as Bundler and Resque, as well as helping with the Rails Girls movement. When he's not going to an awesome Heroku or Ruby event, he lives in Austin, TX, the taco capital of America, where everything is three times bigger!
(Terence loves Friday hugs, EVERY DAY OF THE WEEK! Give him a big one when you see him!)
Resque has been plagued by issues over the past half a year due to inactivity on the project. For instance, resque doesn't handle the cleaning up workers on distributed systems like Heroku. This issue (#319) has been open for over a year. redis.rb 3.0.0 came out on May 23rd which brings improved performance and backward incompatible changes. Also due to this inactivity, other queueing libraries like Sidekiq have come up to fill the void with new features.
This talk will journey through the takeover of Resque and the balancing act of solving the old bugs while moving the project forward. On the topic of old bugs, we'll cover the challenges of getting a stale project in order and into a solid state. Next up will be the work on Resque 2. Rails 4 introduces ActiveQueue and Resque is going to be a first class citizen in the Rails Queueing ecosystem. In order for this to happen, there will be a new Queue interface similar to stdlib's Queue class. We'll walk through reworking the Worker class so it supports both the current jailboxed Forked Consumer as well as a Threaded Consumer for heavy I/O jobs. We'll close with how the community can help with making Resque one of the best queueing libraries for Ruby.
Lourens NaudéCompany: Independent / Wildfire Interactive Inc.
Lourens is an independent consultant currently based in sunny Madeira Island, but originally from South Africa. He specializes in backend / platform / domain solutions and is well versed full stack, from VM to high level protocols and known for his offbeat Ruby patches and extensions. Current interests include disruptive communications technology like ZeroMQ / libxs and he is working on ZeroMQ monitoring features for better operations support.
ZeroMQ: scriptable sockets
ZeroMQ is a socket abstraction and concurrency framework that's changing the way we think and reason about distributed systems. Mailboxes, atomic message delivery and swappable transports allow for fast, flexible and resilient network topologies. It's I/O model also sits very well with all Ruby implementations. In this talk we'll discuss :
- What's wrong with socket I/O ?
- Supported messaging patterns
- Transport agnostic messaging
- Resiliency (operations and upgrades)
- Building out topologies just in time (interjection principle)
- Performance and throughput
- Mongrel2 Ruby adapter
- How to use it from Ruby
- Small case study
Katrina OwenCompany: Bengler
Katrina ran away from the circus and found her true home in the land of computers and code. She enjoys optimizing and automating, taking busywork away from smart people and putting it into code where it belongs. She is the problem solver you want on your side. She is driven by an inexplicable urge to refactor, and has for the past 6 years volunteered as a nitpicker at the javaranch.com Cattle Drive, where she attempts to brainwash others to write clean code. She appreciates a good steak, and admits to enjoying a nice stick fight.
Enter deadline center stage, exit best practices, quietly, rear stage left.
The results are rarely pretty.
Refactoring can pry panic’s fingers away from your poor, overburdened adrenal glands and restore your sanity. Not that it went missing, of course. Never that!
This talk will cover the two reasons why refactoring works as well as (or better than) whiskey, sky diving, and massages as therapy, explore a handful of effective strategies to ensure that the rubber meets the road, and contains gory before shots and slick after shots of ruby code that has served therapeutic purpose.
Rogelio J. SamourCompany: Hashrocket, Inc.
Born in El Salvador, Rogelio started tinkering with computers when his dad gave him a Tandy in the early 80's. He is passionate about using Computer Science to solve complex problems. He also thinks these things are rad: Vim, Ruby, Rails, Linux, Open Source Software, Marsupials, short walks on the beach (with his wife), and playing the guitar and singing made-up songs to his son. He loves Middle Eastern cuisine and dislikes talking about himself in the third person.
I know Kung Fu! (or neo4j on Rails without jRuby)
“Reality is a graph, embrace it!” Sure graph databases are really cool and have a timestamp dated next week, but do you know when you should actually use one? Sometimes living on the bleeding edge pays off and in this talk, I'll show you how you can simplify your application and model your data more naturally with a graph database. They are suited towards a specific problem that is actually quite common in today's applications and they may even apply to that thing you'll be working on during this talk!
I will use Neo4j to demonstrate how to model graph data and integrate it with Rails. We'll start with the basics of graph databases, go over working in a polyglot environment, and get started on our first Rails app using Neo4j. The tools and practices learned here will not only dazzle your boss but make your life easier when you introduce a graph database to your application back home.
Nick SuttererCompany: Independent
Nick Sutterer is proud to be a member of the Ruby open source community. His Cells and Apotomo projects have been bringing increased view modularity and event-driven programming to Rails for years. He has enjoyed attending, and speaking at, Ruby conferences around the world. Buy him a beer sometime, and with very little prompting, he will tell you why there should be no such thing as a double-render error, why you should not confuse your models with your resources, and how to play a mean bass in a punk rock band.
Off the Tracks - Challenging the Rails Mindset
Rails - a word that stirs programmer's blood. It brought us testing, easy web app building, database abstraction and hundreds of extension gems. Why not take it to another level and discover how Rails turns into a real OOP framework? By exploring chosen gems let's discuss what MVC really is and how it boosts your AJAX user interface, how to apply patterns like DCI, dependency injection and POROs to your database layer and how to expose your Rails system through a real RESTful API. Also, have you ever tried using Rails helpers outside of Rails, maybe in Sinatra? Let's do it and learn about some refreshing aspects of this framework.
Dennis UshakovCompany: JetBrains
Dennis Ushakov is the RubyMine Project Lead at JetBrains. His areas of professional interest include virtual machines design and managed runtimes in managed language implementation. His work at JetBrains is currently focused on Rails 3 and debugging support.
“Fighting Code Smells”, Ruby Code Analysis Tools
Nobody likes when their code smells. To help avoid it, dozens of special tools and approaches have been designed. Efficient coding tools, refactorings, code metrics, code analysis, code testing and debugging are all crucial for creating quality, maintainable code. During this talk we’ll show you how to efficiently detect code smells, eliminate them using refactoring, and validate the changed code. By the end you’ll have a ‘swiss army knife’ full of techniques for making better code.
Amanda WagenerCompany: Self-employed
Ruby developer from Christchurch, New Zealand, fascinated by the world and the ways we represent it in code.
Mind your Metaphors
Software development as engineering. Real world situations as objects. Development periods as sprints.
Metaphors are a powerful tool, and generally a positive one, allowing us to disregard some complexity in favour of focusing on the current situation. However, this reduction of complexity can blind us to other ways to discuss or approach a problem. Choosing the wrong metaphor can be dangerous; choosing a simplistic metaphor can be limiting.
This talk will encourage thinking about the metaphors behind the concepts we use, and what other metaphors could be considered in their place. Being aware of metaphors, consciously choosing which we use, and re-evaluating regularly will improve both our code and our discipline.
Jeremy WalkerCompany: Independent
I am a 28 year from Birmingham, England who's been programming for as long as I can remember. I am a full stack developer and have been coding in Rails since 2005. I am currently trying to spend more time contributing to open source and sharing my experience. I am technical co-founder of Meducation - a social education network for medical students and doctors.
How to be a More Productive Developer
Developers are a unique breed of people. We're highly intelligent, creative, problem solvers who have a unique and powerful set of skills. We are often passionate, determined and confident and we love challenges. But we can also be obsessive, difficult to manage and perfectionists. We can get caught up in solving problems that distract us from what we should be doing. We can be isolated and insular.
This presentation will look at who we are as developers and how to get the most from our unique skills. We will look at the areas that we can be weak in, and how we can avoid pitfalls of those areas. We will also look at how we differ from designers, managers, marketers and other types of people we may work with, and how we can work best with them.
This will be an interactive presentation where we build a picture of the average developer in the room.
We will look at:
- What makes developers special?
- How can we be more productive?
- Why do we spend so much time on open source?
- How can we work better with other developers?
- How can we work better with non-developers?
- Why are we so often entrepreneurs?