When we started this crazy thing back in 2011, we chose the name Cascadia Ruby because we wanted to make it clear that we serve the entire Pacific Northwest region. This year we're making good on our promises and holding Cascadia Ruby in Portland, Oregon.
It'll be the same Cascadia you know and love, just a little further south. We're really excited about what we've got brewing: a beautiful venue, fascinating talks, and an amazing after-party hosted by our Adamantium sponsor New Relic at their stunning offices overlooking downtown Portland. We think you're really going to like it!
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
The idea of plastics as cheap substitute materials has been wide spread for decades -- sometimes justifiably, but frequently not.
In use since the mid 19th century, polymers come in an incredible variety of types, and have been seen in surprisingly different ways. There are, in fact, plenty of historical examples of plastics as explicitly desirable materials, known by name and sought after by consumers; some recent trends suggest that may happen again.
This presentation gives an overview of polymers in history, fads they spawned and reacted to, and the developments that lead to their alternating embrace and ridicule. It also looks at the consequences of these trends. While potentially the most recyclable materials on earth, public perceptions of polymers and the designs they encourage actually work to keep them disposable; the presentation concludes with steps to combat this.
Getting our clients clear on the story behind their product is critical to creating the best possible product. Using principles of traditional storytelling, we can walk our clients through simple exercises to clarify, solidify, and streamline the product story. I’ve created exercises to share with you that are engaging, easy-to-use, and versatile enough for a wide-range of product development, but focus on reaching the core of your product story. Spending the 30-45 minutes on these exercises (or any combination thereof) will help your entire team understand the motivation behind your product, provide a structure to your design and development, and help ensure that your consumer hears the exact story your client is hoping to tell.
Whether we knew it beforehand or not, we've deployed bad code. Sometimes it fails in a small, containable way. Sometimes it fails catastrophically in a great conflagration of NoMethodErrors, lost revenue, and anxiety. As software developers, we've all made mistakes.
But due to the heightening sense of impostor syndrome in the Ruby community, it can be difficult to talk about our programming missteps; we often fear that we'll be thought of as incompetent.
This talk will uncover the psychological underpinnings of hiding failure. Additionally, it will discuss practical techniques for authentic and honest public postmortems, so that we can learn from our own mistakes and teach others, ultimately benefitting and enriching the entire Ruby community.
"Software engineering" is a lie. Sure, we may write software, but we're not even close on the "engineering" part. We're craftspeople. We craft software. We cut and chisel and sand our code to make it fit and, like good woodworking, each endeavor is unique. In any form of crafting, it is sometimes necessary to have a specialized tool for a specific task, a tool uniquely suited to the way you work. We should be able to make and use these tools better than most, but it isn't a widely adopted practice. While many of us may use a programmable editor like vim or emacs, far fewer actually program it to meet our needs. Fewer still will write a tool specific to helping them code in some way.
Because I can enthusiastically talk about this topic for days, I'm forced to split this up into multiple parts. This will be part 1 & 2 (out of 4... or 37?). Part 1 will focus on how some of my developer tools work, showing the architecture and implementation details of flog and flay. Part 2 will demonstrate how to write one of your own from scratch. In the end you should have a much better handle on how to create tools for your own craft.
We as rubyists tend to write software that runs on the web, without a deep understanding of what it would take to write the plumbing for that same software. I think it's useful to have a basic understanding of how some of the lower level components of a system work.
I'll discuss the basics of systems programming, using Ruby. I'll talk about syscalls and kernel space vs user space. I'll cover a bit about file descriptors and what they're for. And I'll walk through a small example of a working webserver using those primitive syscalls.
The software development world is a twisty maze of passages, all alike (at first glance). It can be slightly perilous and a little scary, especially if you’re just starting out.
How should you know what job to take? Or what salary to accept? And if you've been doing this a while, how do you manage the day-to-day challenges of work? How do you know what positions or promotions to accept or decline?
During this talk we'll examine the 16 year career of a software developer, namely me. We'll review my personal and professional choices and see how they impacted my life and career, and, hopefully, learn from my mistakes.
Most developers code to music...some are even musicians themselves. Is it possible to streamline workflow by adjusting how we listen to music and what music we listen to?
Studies have shown that exposure to certain kinds of music can help to develop cognitive strength and improve performance of tasks. This talk will explore those studies and show what sort of things can be done to improve the listeners environment and help people to create better code.
"but in this world nothing can be said to be certain, except death and taxes" -- Ben Franklin
If Ben was a programmer, he probably would have said "death, taxes, AND BUGS". How we handle things when something goes wrong can be the difference between an all-nighter and a good night's sleep.
Drawing on my experience development, QA, and release management I'll share ideas for handling the unexpected without losing your mind. I'll discuss writing a good bug report, figuring out what is really broken, and what to do when it seems like nothing is working.
This is a talk about the tools, insights, and tribulations of implementing a video transcoding farm in EC2 with open source tools and Ruby. A selection of small adventures where Ruby was used to gain an understanding in an already existing tool, or implementing a tool or integration component to solve a problem.
* understanding mp4 file formats with ruby and finding a 1 bit bug in ffmpeg
* moving 200GB files around both digitally and physically
* launching EC2 instances to run a single command
* wrapping long running processes with ruby command and control
* SimpleDB as a metadata store for S3
* hacking a workflow with google spreadsheet
* debugging a remote 3rd party wireless network
How many hours have you wasted building awesome software that nobody uses?
It’s one of the biggest frustrations for developers, and managers trying to keep developers. But there is a solution. User testing is a simple way to keep product development on course. And it’s not just for big companies with big budgets.
In this talk I’ll introduce a simple no-frills approach to usability testing tailored specifically for engineers. We’ll discuss how to interpret results, and finally how to incorporate the results back into the development cycle.
"That's stupidly awesome" or "You're such a jerk :)"
The above is obviously positive, but how would you train a computer to figure that out? So much of our language is contextual and has subtle hints of sentiment that this is a tough problem in natural language processing.
Though there is a great algorithm called Support Vector Machines that can find a close solution! And there's a great Ruby library for you to use as well.
Join us for this talk where we'll go detecting sentiment in tweets using support vector machines. At least join us for the various bouts of swear words and confusing lexicon of the English language.
Fluency is "what you can say without having to think about how to say it." "Refactoring" is a language that describes ways to make your code suck less. I want to inspire you to become more fluent in that language, so you can make your code suck less without having to think about it.
I'll walk you through the process of reworking a 50-line Rails controller action that's hard to comprehend, let alone refactor. We'll tease apart fiendishly intertwined structures, embrace duplication until we grok what it's telling us, use evil hacks to our advantage, and uncover responsibilities—and bugs!—that weren't obvious at first glance.
If baseball is America's Pastime, then surely poker is America's Game. From Rounders to Celebrity Poker, Kenny Rogers to World Series of Poker events on constant loop on ESPN, poker is everywhere in our popular culture. An iconic game of the Wild West, today it has lost much of its stigma and emerged as a preeminent game of skill and intellect dominated by mathematicians, stock brokers, and developers. What has software development brought to this American tradition, and what lessons does poker have to offer us in return? What can we learn from another field? In this talk, I'll give you a crash course in poker, discuss statistics and odds, the psychological aspects of the game, and the business side of managing a career as a professional gambler. You'll come to see that it's not that different from being a developer. After all, its not just poker that could be called 'the hardest way to make an easy buck known to man.'
Programmer. Computer Scientist. Software Engineer. Software Craftsman. Principle Architect. Designer. Developer.
These are the words that we use to describe our profession and ourselves. We are encouraged to study Computer Science, however a large percentage of us are self-taught or have entered programming through related fields. This sits in stark contrast to most other engineering disciplines, and this diversity is possibly our greatest strength.
We are computer programmers, but we are also artists, teachers, mothers, social advocates, athletes, scientists, writers, gardeners, and many more. It’s important for us to take the time to look at problems through many lenses, and form diverse teams that allow us to solve problems from many different angles. There is no ‘one size fits all’ approach to programming – we are all standing on the shoulders of giants.
Programming sits at the intersection of science, art, and craft. I contend that, given introspection on each of these facets, we will all improve. I’ll provide concrete examples of how to apply formal Computer Science techniques to real-world problems. I’ll outline the benefits of treating code as an art form. I’ll explain how problem solving in programming maps directly onto other crafty domains. But most importantly I’ll discuss the importance of taking the time to look at problems from different perspectives. No matter what path you have taken, there is always more to be learned by walking in the footsteps of another.