Sessions at MountainWest RubyConf 2011 on Thursday 17th March

Everything you need to know to run your very own Faux-pen Source project in the Fascist style. I'll cover the history of Fascism, how it works, relevant scholarly research, and how you can leverage fascist tactics and "the community" to further your own goals.

For professional grade Rails applications MVC just isn't good enough, have you ever wondered:

• Why you need a quasi global variable like 'current_user' in order to test web application logic.
• Why you end up re-writing so much application and view logic when someone asks you 'ajax that form'.
• Why it's hard to drop someone on the 'front-end' at the same time tons of commits are flying around onthe 'back-end'.
• Why artifacts like 'password_confirmation' pollute your models.
• Why using your application logic outside the web stack, for instance in a background process or command line application, should be so damn hard.
• How to avoid silly side effect mistakes like N+1 queries in your views.
• Why you often end up designing your database to support your routes.
• Why you break forms with the addition or removal of a database column.
• Why it's so hard to reason about caching.

Ara T. Howard will discuss how ancient design patterns can bring new life to modern web platforms, letting web developers support modern javascript interfaces, mobile applications, non http usage, and simpler testing while simultaneously liberating the front end development to those who do it best.

This is not a scientific talk. It's a survey of each step in my process of creating something meaningful out of a pile of data. The talk will be a blend of anecdotes, process, data sources, tools available, and good ol' hacks. We live in a world filled with recorded data. Lots of that data is online, and retrievable in some fashion. Unfortunately, that data is often sparse, poorly labeled, and uninsured. Enter Ruby, with a wide variety of gems and libraries to help us trudge through funky data, store it, sort it out, and spit shine it for the masses.

The world of concurrent computation is a complicated one. We have to think about the hardware, the runtime, and even choose between half a dozen different models and primitives: fork/wait, threads, shared memory, message passing, semaphores, and transactions just to name a few. And that's only the beginning.

What's the state of the art for dealing with concurrency & parallelism in Ruby? We'll take a quick look at the available runtimes, what they offer, and their limitations. Then, we'll dive into the concurrency models and ask are threads really the best we can do to design, model, and test our software? What are the alternatives, and is Ruby the right language to tackle these problems?

Spoiler: out with the threads. Seriously.

The single most important driving force that has kept me going since I started working with Ruby is the community itself. I will discuss various aspects of why I love the Ruby community and present my thoughts on our unique and awesome community with it's rosy effervescent essence

This talk will teach you how Opscode designs and writes Chef cookbooks to be sharable - not only in the Open Source sense, but sharable between various internal infrastructures and environments. Come to this talk if you want to learn more about:

• How Chef uses attributes
• How to dynamically build configuration with search
• Accessing internal Chef objects within recipes

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 (http://github.com/geemus/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.

Redis is an "advanced key-value store" but really, it's much more than that. Redis goes above and beyond GET and SET, and it's time for you to learn how that can help you write faster Ruby apps. We'll explore the rest that Redis has to offer, such as sorted sets, publish/subscribe, transactions, and more with real-world use cases of each.

Ruby on Rails is a wonderful framework that makes creating websites simple and fun. But, perhaps because it is a pleasure to work with, Rails can be overused. A simple CRUD application can quickly become a behemoth, it's responsibilities encompassing far more functionality than one application should. In the startup world, one such app can run an entire business.

Monolithic Rails applications are an anti-pattern that hamper productivity, increase bugs, and, if you are a startup, can threaten your business. How do you fix the problem? Decompose your application into several independent, reusable services. This talk relates my experience leading a team of developers who re-architected a monolithic Rails app -- an app that effectively was the business -- into a service-oriented architecture (SOA). Using targeted code examples, it seeks to describe not only the advantages of a service-oriented approach, but also techniques for refactoring a production application into a more distributed architecture without destroying the business in the process. Finally, this talk highlights some common SOA pitfalls and describes effective ways to avoid or remedy them. Attendees will walk away with a clear demonstration of how to refactor or think about building their app with SOA in mind.

Implementing a Service Oriented Design with Ruby can lower maintenance costs by increasing isolation, scalability and code reuse. That's the theory, anyway. It's true, but in practice there are lots of nitty gritty details of rolling out a service oriented design that can reduce the expected benefits -- or even leave you worse off than you started.

This talk will shed light on what it takes to successfully leverage a service oriented architecture. Emphasis will be on less discussed considerations like testing strategies, dependency and release management, operations and developer tools rather than the happy path of how to implement and consume services. Examples will be provided from our experience building tool to analyze home energy use in order to help people save on their power bills.

In the end, you'll walk away with a deeper understanding of how to weigh the pros and cons of introducing services into your architecture, and you'll have learned some techniques to make the transition smoother if you decide it's right for you.

Then it starts to scan the computer and transmit bits of information every time he clicks the mouse while he's surfing. After a while, [...] we've accumulated a complete mirror image of the content of his hard drive [...]. And then it's time for the hostile takeover.
-- Lisbeth Salander in Stieg Larsson's "The Girl with the Dragon Tattoo"

Hacker dramas like the Stieg Larrson book make for good fiction, but we know that real life rarely matches drama. And with all the security features that Rails 3 has added, surely it is difficult to hack a typical Rails web site.

Right?

Wrong! Without deliberate attention to the details of security, it almost certain that your site has flaws that a knowledgeable hacker can exploit. This talk will cover the ins and outs of web security and help you build a site that is protected from the real Lisbeth Salanders of the world.