These videos were recorded and produced by Steel City Ruby Conference, they were not produced by Confreaks, LLC.
I am a developer, and I have Type II Bipolar and ADHD.
Over the last six months I've been writing and speaking about mental illness in the developer community, ever since we lost one of our coworkers, Caleb Cornman, to untreated mental illness. There's a lot of shame around being sick, and mental illness is treated much differently than physical illness, which causes people who are suffering to avoid finding help.
In this talk I will share the story of my struggles with depression, and getting diagnosed with ADHD and Bipolar, why it's especially relevant for developers, and how we can help those around us who are suffering from mental illness.
You've landed a great opportunity to work with some of the smartest people in the industry. You can barely contain the enthusiasm to learn and contribute to the team. You may not have all the required technical skills on day 1, but you are confident that you will get there with the support from your team. It's exciting & stressful at the same time because you need to start contributing right away.
A lot of developers find themselves in these shoes, just as I did in not-too-distant past. This talk offers specific strategies developers of all skill levels can use to start making an immediate impact. These strategies have enabled me to contribute quickly on a new team and I want to share it with you so that they can help you on each new project or team you work with. I also want to share specific gotchas and share some tips on how to adapt and continue to improve once you have become productive member of the team.
The talk will primarily focus on:
Techniques for quickly learning a new codebase
Finding ways to have a significant impact quickly
Ways in which you can continue to be more awesome
Hey, nerds. How good are you at real collaboration? I don't mean cooperation, where everyone's doing their part. A collaborative solution is more than the sum of those parts. And I don't mean choosing the best idea among the competitors. Collaboration lets us create new ideas that none of us could have come up with on our own. Let's talk about what gets in the way of that kind of juice. Open up, make mistakes, learn, grow, and watch what emerges when we collaborate.
We use Ruby in our Web applications. We use Ruby in our scripting. We even use Ruby in our mobile phone applications these days. But here's something new: Using Ruby to control flying robots.
The Parrot AR Drone is a consumer grade quadcopter designed to be controlled from your smartphone over a WiFi signal. However, the network protocols for controlling the drone are open and published in the AR Drone SDK, so what is more natural than using our favorite programming language to communicate and control these fun devices.
This talk will cover the nature of the AR Drone protocol and the details of getting a Ruby program to communicate to and control the drone. We will talk about the challenges of remote controlling flying objects. And if all goes well, we will actually demonstrate all of the above.
After all, admit it. When robots finally take over the world, wouldn't you prefer that they are programming in a friendly programming language like Ruby?
Community-building can seem like a herculean effort that must be coordinated among many. But it doesn't have to be. One is plenty.
How can we handcraft a fulfilling code career? How can we support peers in developing theirs, whether newcomer or artisan? How can we contribute, without having to be expert? How do we develop social capital among community members, and channel those investments into people who are just entering? How will we craft a thriving community, using only simple tools & scarce local resources?
We'll examine the history of major successes -- in Ruby community, Python, and well beyond -- and extract lessons to apply generally. It's a story that weaves in personal narratives of rising into that, both well and clumsily. It's about transforming minor ambitions & frequent iterations into a scope of change that looks amazing. By making choices to do small things well and thoughtfully, rather than with concern for how they scale.
How much code coverage does it take it ship a minimal viable product? How many Scrum Certifications does it take to make your team agile? How many languages learned make a journeyman a master? Currently, in software, there is an expressed desire to be taken seriously as craftspeople. To this end, we've introduced process, metrics and quantifiable boundaries as goal posts to hold up to those who may not understand what is involved in shipping quality software. As this practice becomes normal, developers are faced with an ever-expanding landscape of techniques, practices and pressure from thought leaders to take extra course work or certifications to validate the assertion that you are, in fact, a software developer. While some may see this as a necessary evolution of our field, I see it as a albatross round the neck of the creative developer looking to explore the depths of what is possible. While the safety of a well worn path may provide solace to the uninitiated, I find dogmatic implementation oppressive and exclusionary to those interested in exploring alternative approaches to solving problems with technology. Join me in an exploration of what I believe makes us unique as a subculture in this business world; examples of how we came to be by challenging the established idioms of the past in order to move forward into something exciting and new. To be our best we must be willing to dive into the unknown, to loose the binds of convention and explore the vast expanse of the unfamiliar. We must dare to be wrong, to be new, to be foolish, to be amazing and keep software weird.
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.
A talk about metaprogramming, coding for fun, and the joy of sharing.
*NOTE: at around 33:30 minutes there are a couple missing slides. We apologize.*
Your code can only say what it does right now. You can’t look at a method and see its history: the alternative approaches that have been considered, the algorithms that have already been outgrown, the simpler code that has been replaced, or the complicated code that’s been refactored.
Not capturing this knowledge is a huge loss. In Deliberate Git I'll share how to use Git to write detailed commits that craft a cohesive story about the code without giving up a good programming flow.
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
Our cap and puppet workflow using git
How vagrant can provide a sane test environment
Some pitfalls you should avoid"