As programmers, we're familiar with complex logic and decisions: complex boolean expressions, long if/else cascades, and convoluted cases. But we quickly learn to avoid them as much as possible, finding ways to simplify. That's because even though computers can handle that complex stuff, we humans like simple logic. We have trouble internalizing complex lines of reasoning. Our bias toward simple explanations shows in all kinds of ways. It affects how we think about politics, science, economics, and yes, programming. And it can lead us astray. Some things really are complicated, and to understand them properly requires thinking about the complexities. If we insist on simple explanations—or just default to them because we don't think very hard about it—we can reach the wrong conclusions. This talk will explore how to think about some important programming topics that are often misunderstood. You may leave the talk with your mind changed. You may simply find your position strengthened. At the very least, I hope you'll learn some new, clear ways of explaining things to those around you, helping them to think clearly about complex issues.
Rails 3.1 introduces a lot of new changes. In this session we'll cover most of the changes, including how to take advantage of them. From Reversible Migrations, the new Asset Pipeline, Coffee Script, SASS, and even HTTP Streaming. This will be a code-heavy talk demonstrating many of the new features in Rails 3.1.
You know how to raise and rescue exceptions. But do you know how they work, and how how to structure a robust error handling strategy for your app? Starting out with an in-depth walk-through of Ruby's Ruby's rich failure handling mechanisms -- including some features you may not have known about -- we'll move on to present strategies for implementing a cohesive error-handling policy for your application, based on real-world experience.
We all love Ruby. But let's face it: It isn't perfect. We each may have a personal list of complaints. Yours will vary; this is mine. These are the things about Ruby semantics and the Ruby core that I find counter-intuitive, difficult to remember, incomplete, improperly designed, or not quite adequate. There might even be one or two notes here on syntax, the most fundamental level of any language. And "hate" may be too strong a word; but once in a while, we have to ask what is lacking in our favorite tool, so that someday when replace it, we will have something better (whether that thing is called "Ruby 2.0" or something else entirely).
Ruby is a dying language. The same as the ones that came before it. Eventually, it will deprecate and be relegated to the history books. Does anyone know what the cultures or values of Fortran, Cobol, Pascal or Basic were? Does anyone know what was specifically accomplished with them? If you do know, do you really think that anyone besides a small circle within the tech-geek world cares? Only a few uber geeks still speak Latin, Greek or Sanskit. Yet, the entire planet knows about these languages and what they contributed. They care not just because of the monuments built, most of which have turned to dust and have become fables, but because of the ideas, culture and values that were created and passed on through the generations. Each of these languages created a distinct culture whose memorable flame burns eternal and contributed to the planet. What culture, if any, will Ruby on Rails create? The efficiency of Ruby on Rails, the demand for it, the convergence of economic and technical forces provide the tools and incentives to create a culture of our choosing that could be memorable for decades and longer. Will we seize the opportunity to create lasting positive change? Within 8 months of Ruby Nuby's first meeting, it has grown to over 700 members with training locations in 3 countries and multiple university partners . Ruby Nuby will present a systematic plan of how we can make Ruby on Rails as memorable as Latin, Sanskrit or Ancient Greek due the culture, ideas and values we will create and pass on.
Want to build your next application off of live Twitter updates? Twitter provides a streaming API that you can filter by username, keyword, or geo-location. Using a couple of great Ruby gems, we can store tweets from the streaming API into MongoDB, a NoSQL store that's perfect for analysis. I'll go over the basics of the Twitter API, MongoDB, the mongo and tweetstream ruby gems, and how to bring it all together into a sample application.
... Or, Lessons Learned While Using Ruby's MP System to Model a 2,500 Year-Old, Dead Language During LSRC III's Reject Conf, I began a project to model the linguistic behavior of verbs in Classical Latin. Owing to the irregularity of human communication, modeling the provision of unambiguous answers (return values) to ambiguously asked things (flexible / incomplete method calls) might have required hundreds, if not thousands, of method definitions or static values entered in a database. But what if heuristics could be given to a Ruby class such that it "thought" as language learners are taught to think? What if it could be taught to be flexible in respecting the ambiguous calls given and to still give precise, correct answers back - as human language learners are capable of doing? By adopting this design paradigm, code could become leaner and more reflective of human cognitive process. Thankfully for Rubyists, this is not a dream, this is reality. Our programs can operate more intelligently, more heuristically, and more insightfully. We can save ourselves days of development time by integrating this next tier of metaprogramming patterns I propose to demonstrate. While I will demonstrate these patterns by modeling linguistics based on the [LatinVerb library](https://github.com/sgharms/LatinVerb), these techniques have wider application across problem domains.
You can't do it all. Sometimes breaking the request/response cycle is just too constraining and you need to bust out of it. Enter asynchronous processing. Delayed Job and Resque, two takes at solving this problem, are popular tools. We'll explore their differences, demonstrate how to get up and running in minutes, and show you how to find the best fit for your project.
The world is full of poorly structured, overly verbose, untested code. But, a lot of people are doing amazing things and making insane amounts of money from bad software. As someone who might call himself a “software architect” or “craftsman”, this is difficult reality for me to accept. This talk explores the balance between pragmatism and perfection. Ruby, being as expressive and versatile as it is, makes it easy for newbies to write alien code that looks more like Java than anything resembling our beloved language, while those versed in "The Ruby Way" spend their days and nights obsessing over how to refactor ten lines of working code into three. There is a cost to writing good software. It takes time to write automated tests, refactor code, and do things right. You may miss opportunities to get your software in front of real people, get essential feedback, or even launch at all. I have seen and often written both abysmal software that makes me want to cry and glorious code that would make any mother proud; both were perfectly adequate for the task at hand. Bad software that ships is better than good software that nobody uses. Learn how to strike a balance between pragmatism and perfection.
In business, OPM(other people's money), is the preferred way to start a business. In today's web economy it is now possible to get your app up and running quick by using OPI. This can include everything from server hosting to video processing.
One much loved feature of Ruby is the ease with which the object model allows for internal DSLs. However, "metaprogramming" code, in Ruby, can be hard on the eyes which written in large quantities. "Lispy", a gem by Ryan Allen, was a first step toward a generic decoupling of internal DSLs from their implementation. I forked it, took it a ways further, and used it in a significant refactoring of a gem. During this presentation, I'll demonstrate how the LISPish notion that code is data can go a long way toward easing the burden of implementing internal DSLs
Keynote Day 1
Whether you're new to Rails or have been around few years, chances are that your views are primitive. Detonate what you know about how views are written and let's start over. In this session we'll discuss... - Why your views suck - Instance variables are stupid - Kill helpers and work with objects - Drawing the line between "C" and "V" - Treating views as API customers - Rethinking templating By the end you'll be dying to blow up your views.
A simple OAuth based protocol called OpenTransact will be described. Payments made across financial service providers using the opentransact ruby gem will be demonstrated.
I'd like to go through some of the fundamental concepts of the messaging library ZeroMQ, and talk about how to use it to architect distributed applications.
Go is a statically-compiled systems language geared to developing scalable and type-safe applications with the light touch of a dynamic language. In this session we'll explore Go from a Rubyists perspective, examining the CSP-based concurrency model which has gained it wide-spread press coverage, it's inference-based approach to dynamic typing and the inheritance-free object model this supports. Where possible I'll tie these concepts back to familiar Ruby idioms. Along the way we'll meet gotest (Go's testing and benchmarking framework), CGO (for linking to C libraries), goinstall (the remote package installer) and Go's powerful reflection and type manipulation features. By the end of the session you'll be comfortable reading Go source code, have a basic feel for developing with the language and the necessary background to get started writing your own concurrent Go programs.
The past 10 years has seen a revolution in the way we make phone calls and even the way we think about a telephone. Ruby is an ideal language to create power tools for building telephony applications. In this talk we will demonstrate how Ruby is the state of the art when it comes to interacting with the telephone network. Using the open source Adhearsion framework, we will demonstrate how you can easily integrate with existing Ruby applications or migrate legacy systems. We will cover how to get started immediately using cloud-based services, as well as how to build, deploy and manage your applications in-house. Network permitting, we will finish with a live demo designed to inspire ideas for ways you can integrate telephony into your application.
Everyone talks about writing web applications with Ruby, but it's great for applications of any kind. Shoes is a project that was started by _why the lucky stiff, and when he left, a plucky community of developers kept it alive. If you've never worked with Shoes, it's the only Ruby GUI toolkit that is truly Ruby, and not just a binding to another project, like QT or tk. It uses Ruby-only features like blocks heavily, and works on all three platforms. In this talk, Steve will do a small introduction to developing desktop apps with Shoes, talk about the challenges of maintaining a large polyglot project with an absent creator, and where Shoes is going in the future, as well as how you can get involved.
The need to maintain social activity feeds is an increasingly useful thing in a variety of software. Whether its a project management app or a social site, many kinds of software can make use of a list of events that have happened in the system, filtered for each user and listed in reverse chronological order. However, this sort of data presents many storage and privacy challenges. Gowalla has built Chronologic to meet all these needs. Chronologic is an application built for dealing with events, timelines, and pushing those events to the right subscribers. It is a general service for dealing with activity feeds. On top of that, it implements privacy, a flexible follow model, and the ability to fetch incremental updates to a feed. Chronologic is built with Ruby, Sinatra, and Cassandra. We'll show how this trio played nicely together and how it could be improved. Most importantly, we'll show how to get started with Chronologic, how to adapt it to your own application, and how to deploy it in your datacenter.
The Reactor Pattern's present in a lot of production infrastructure (Nginx, Eventmachine, 0mq, Redis), yet not very well understood by developers and systems fellas alike. In this talk we'll have a look at what code is doing at a lower level and also how underlying subsystems affect your event driven services. Below the surface : system calls, file descriptor behavior, event loop internals and buffer management Evented Patterns : handler types, deferrables and half sync / half async work Anti patterns : on CPU time, blocking system calls and protocol gotchas
Cloud computing scared the crap out of me - the quirks and nightmares of provisioning cloud computing, dns, storage, ... on AWS, Terremark, Rackspace, ... - I mean, where do you even start? Since I couldn't find a good answer, I undertook the (probably insane) task of creating one. fog gives you a place to start by creating abstractions that work across many different providers, greatly reducing the barrier to entry (and the cost of switching later). The abstractions are built on top of solid wrappers for each api. So if the high level stuff doesn't cut it you can dig in and get the job done. On top of that, mocks are available to simulate what clouds will do for development and testing (saving you time and money). You'll get a whirlwind tour of basic through advanced as we create the building blocks of a highly distributed (multi-cloud) system with some simple Ruby scripts that work nearly verbatim from provider to provider. Get your feet wet working with cloud resources or just make it easier on yourself as your usage gets more complex, either way fog makes it easy to get what you need from the cloud.
Two years ago Rackspace had a problem: how do we backup 20K network devices, in 8 datacenters, across 3 continents, with less than a 1% failure rate -- every single day? Many solutions were tried and found wanting: a pure Perl solution, a vendor solution and then one in Ruby, none worked well enough. They not fast enough or they were not reliable enough, or they were not transparent enough when things went wrong. Now we all love Ruby but good Rubyists know that it is not always the best tool for the job. After re-examining the problem we decided to rewrite the application in a mixture of Erlang and Ruby. By exploiting the strengths of both -- Erlang's astonishing support for parallelism and Ruby's strengths in web development -- the problem was solved. In this talk we'll get down and dirty with the details: the problems we faced and how we solved them. We'll cover the application architecture, how Ruby and Erlang work together, and the Erlang approach to asynchronous operations (hint: it does not involve callbacks). So come on by and find out how you can get these two great languages to work together.
Many of us deploy to systems which are completely different from the systems we develop on, and can be difficult to set up particularly if there are a lot of moving pieces in your setup. These could be things like message queuing systems, various databases or specific versions of scripting languages such as ruby. This makes it a very time intensive process to bring new people up to speed on your projects, and to get systems set up right the first time. What if you could have a system that would launch a virtual environment, provision and run all of your systems's various components, be repeatable and fit on a thumb drive? Vagrant allows this by putting a ruby DSL on top of Oracle's VirtualBox API. It allows you to set up and provision your servers using Chef or Puppet, and to reuse those scripts on your real production environment if you want. This makes your server infrastructure version controlled just like your application code. We will go through a setup of a Vagrant instance and show how using shared folders you can develop locally, but be developing on your "local cloud", your running Vagrant instance.
The session will dig into the internals of how Cloud Foundry the first Open PaaS, which is written entirely in Ruby works. We will walk through each component and how they communicate, how code gets bootstrapped, and why PaaS is so significant.