You have a good ol’ Rails application that provides an API. That app is gaining momentum and getting tons of new users every day. You need to double the servers to accommodate the infrastructure to the demand. Then, you get the bill from your cloud service provider and... THE HORROR!! Is big enough to make you cry. Well, here comes Goliath. A very tiny, well designed and FAST non-blocking IO server that will put a big smile in your face, since you’re going to need much less money to serve the same (or more!) requests per second. A real case scenario, a social gaming application for mobile devices, will serve as guide to show you how good it is and how much progress can you make with just a little bit of work. From development tools and gems to deployment strategies, balancing and more, we’ll show you how a resource consuming Rails API turns into a nimble and fast Goliath API. The real time Internet is calling, and Goliath will hurry to make you more real time than ever.

I want to present on why, where, and when backbone would be beneficial to use. We went through the whole motion on our rails project and I want to share in detail how we came about utilizing backbone on our project and hopefully you can too! In the end, implementing Backbone and jasmine led to a cleaner, more organized and better tested code base.

From Amazon, to Spotify, to thermostats, recommendation systems are everywhere. The ability to provide recommendations for your users is becoming a crucial feature for modern applications. In this talk I'll show you how you can use Ruby to build recommendation systems for your users. You don't need a PhD to build a simple recommendation engine -- all you need is Ruby. Together we'll dive into the dark arts of machine learning and you'll discover that writing a basic recommendation engine is not as hard as you might have imagined. Using Ruby I'll teach you some of the common algorithms used in recommender systems, such as: Collaborative Filtering, K-Nearest Neighbor, and Pearson Correlation Coefficient. At the end of the talk you should be on your way to writing your own basic recommendation system in Ruby.

Building modern applications requires well-organized JavaScript, stylesheets, and images. Rails 3 gives us an excellent tool in the Asset Pipeline, but most developers see only a small part of the Pipeline's potential. With the growing popularity of client side applications built with Backbone, AngularJS, and JQuery, combined with syntactic helpers like CoffeeScript, LESS and SASS/SCSS, the Asset Pipeline has become extremely important to our apps. In this talk, I'll show you lesser-known uses for the asset pipeline, point out potential hazards, and help you build complex client applications that will stay neat and tidy.

You've probably heard of Python, the _other_ popular, dynamic, multi-paradigm programming language. It occupies much of the same space as Ruby, has many similar language features, and the syntax even looks pretty similar. But what are the specific strengths and weaknesses of Python when compared to Ruby? What use cases are conducive to one language versus the other? In this talk, we look at some of the differences in language design, exploring how they affect application development and maintenance. Later, we look at some specific scenarios and show how the strengths of each language apply.

This is a story about the path to mastery. We are all on the same journey and will encounter similar triumphs and turbulence. How did I start? What "red flags" changed my direction? What failures did I endure? And finally, what have I learned about learning that guides me today? The answers to these questions can shed light on your path. Ruby has catalyzed my rebirth as a software craftsman and being a Hashrocket Apprentice has changed my ideas about learning and mastery. The Hashrocket program is an Apprenticeship in the full sense of the word. The program teaches concrete techniques for learning, overcoming knowledge plateaus and taking the next step into mentorship. This approach to apprenticeship clears a path for beginners, rejuvenates the intermediate, and inspires the advanced on their own paths to mastery.

Amazon's Mechanical Turk has long been used for scientific surveys and image classification. But it has a much greater potential. We'll explore the creative possibilities of Mechanical Turk including story creation, testimonials, production descriptions, and the testing of product ideas. I will demonstrate the basics of the service that will allow you to begin testing and iterating on ideas quickly. We'll conclude the presentation by showing an advanced example of integrating with Rails and Mechanical Turk utilizing the Turkee gem. Mechanical Turk could quickly become your swiss army knife for getting your project off the ground.

The BDD hype cycle is over. Recently, there’s been a lot of backlash against popular BDD libraries like Cucumber. Some developers blame their test frameworks for brittle test suites and long build times. Others go so far as to claim that acceptance testing is simply not sustainable, period. In this talk, we’ll do some root cause analysis of this phenomenon with shocking results - it’s not the test framework, it’s not the methodology, it’s you. You’ve abused your test framework, you’ve cargo-culted the methodology, and now you’re feeling the pain. We’ll show you a way out of the mess you’ve made. We’ll discuss the main problems BDD was intended to solve. We’ll show you how to groom your test suite into journey, functional, integration, and unit tests in order to address build times. We’ll teach how to mitigate against brittleness and flickers, and how to let your tests reveal the intent of the application and actually become the executable documentation we’ve been waiting for.

If MRI is a potato peeler that does one thing very well, JRUby is the Swiss Army Knife that offers developers a multitude of tools. JRuby opens doors that MRI has closed, being highly performant and offers access to Java libraries. From the perspective of a former MRI'er, I’ll discuss concrete examples of how to realize the benefits of the JRuby stack, drawing examples from my work on an open-source JRuby on Rails app.

Impress your friends, scare your enemies, and boost your productivity 800% with this live demonstration of vim and tmux. You will learn how to build custom IDEs for each of your projects, navigate quickly between files, write and run tests, view and compare git history, create pull requests, publish gists, format and refactor your code with macros, remote pair program, and more, all without leaving the terminal. Come prepared to learn and ask questions; this is serious business.

As Ruby and Ruby on Rails applications grow they see a lot of the same problems that any enterprise level software project will see at some point: longer running test suites, more complex code interaction, and a rising requirement to keep "all that stuff" in your head at once. Both Ruby and Rails offer many ways in which to structure code. We'll cover Ruby/Rails code structuring techniques like unbuilt gems and engines that you can use to get faster test suites, cleaner structures, and more flexible apps.

Code helps to achieve concrete goals, but it also gives us room to play in the sandbox. Recent experiences teaching programming have taught me that these two facets of writing code need to be taken into account when teaching. Students come in two broad flavors. Some have an overly specific goal ("I want to make a social app for cat owners to share pictures") that they pursue to the detriment of their overall learning ("I don't understand how printing 'hello world' in this black box gets me any closer to uploading a photo of Dr.Mittens.") Others come to the table with the very general goal "learn to program." I believe that we can play these two mutually beneficial but frequently opposed attitudes about programming off of each other in order to teach programming, learn new technology ourselves, even write better documentation. A firm understanding of this interplay in code (pragmatic construction vs. playful exploration) can help us not just teach, but also become better developers.

Many of us approach regular expressions with a certain fear and trepidation, using them only when absolutely necessary. We can get by when we need to use them, but we hesitate to dive any deeper into their cryptic world. Ruby has so much more to offer us. This talk showcases the incredible power of Ruby and the Oniguruma regex library Ruby runs on. It takes you on a journey beneath the surface, exploring the beauty, elegance, and power of regular expressions. You will discover the flexible, dynamic, and eloquent ways to harness this beauty and power in your own code.

What's the worst that could happen if your app has a dependency on a malicious gem? How easy would it be to write a gem that could compromise a box? Much of the Ruby community blindly trusts our gems. This talk will make you second guess that trust. It will also show you how to vet gems that you do choose to use.

Compliant APIs with Webmachine As web applications continue to move towards rich client-side experiences, the relevance of server-side rendered HTML diminishes. This is compounded by mobile applications consuming similar APIs as rich single page applications. This talk will discuss building lightweight standards compliant APIs with Webmachine, a REST toolkit written in Ruby. Webmachine provides a syntax which makes it easy to reason about your applications, while also providing an alternative to more heavyweight solutions such as Rails.

Basic understanding of mobile apps has become as important to programming as understanding web technology. Now through RubyMotion it's tangible through the language we love! But of course this raises a lot of questions. When RubyMotion first came out, less than a year ago, my co-founder and I attacked RubyMotion as Ruby developers, without the smallest experience of iOS. Since then, we've seen one app to the App Store, we've created a largely followed Open Source project for people like us (http://iconoclastlabs.github.com/rubymotion_cookbook/), written numerous blogs for beginners, and ultimately committed to other popular open source RubyMotion projects. Our proposal is to excite other developers to flex their mobile abilities, but to simultaneously give them an experienced view of the pitfalls from a Rubyist's view, and not from the common iOS perspective.

Recently, I’ve been really excited about hypermedia APIs, and what they mean for the API development process. At LA RubyConf, I will show - how to use a hypermedia API in Ruby - an example hypermedia API to see what they look like - the basic flow of using a hypermedia API - consuming the example API with Ruby

Money talks and user value is key to creating a profitable business. Yet, prioritizing short term feature development is clearly folly. How do you balance the competing priorities of code maintainability and banging out code as fast as possible? The secret is: these are two sides of the same coin. A team produces value by developing features quickly, while at the same time, avoiding crippling technical debt. Have you ever encountered impenetrable thousand-line functions? Or, have you ever spent a day refactoring code that you never looked at again? In this talk, I’ll discuss strategies for balancing competing priorities, such as scheduling refactoring and devops tasks alongside feature development. By optimally directing engineering efforts, PMs and developers can work toward the happy median of rapidly delivering features and an effective codebase.

There's been a lot of momentum behind "Javascript Everywhere" and improving that "Everywhere Javascript" via languages that compile to Javascript, esp. Coffeescript. Perhaps it time that Rubyists looked at "Ruby Everywhere" via Opal. This talk will give an overview of what Opal is, what it can do, directions and desires, among other things in true Gangnam Style. Get your horse dance ready!

It may seem unusual, but my greatest understanding of software development comes not from computer courses or books but from my background in Theatre. In a performance many separate parts (acting, lighting, sound, costumes) must be developed independently, but still form a cohesive whole to express a director’s vision. The same is true of software development. Design, code, databases, testing, etc. must all connect seamlessly to form an illusion for your audience. This talk will show you how to coordinate these disparate elements and create an extraordinary experience. This talk will include information on assembling your cast and crew, dealing with divas, knowing how to say no to impossible requests, rehearsals, maintaining your sanity when receiving reviews, and much more.

Practicing Test Driven Development (TDD) is like falling in love. It may first seem like all your development problems will disappear. However, it’s not all unicorns and rainbows. You have to work at it, and keep working at it, for the rest of your development life. It is hard, and it’s natural to question whether the value is worth the effort. So why do it? Why would you bother going through all that trouble, dramatically changing the way you code, learn new domain specific languages, and initially slow down the rate at which you produce code when you have no time to lose? This talk will answer the "why" by sharing my experience of passing through the five stages of grief (denial, anger, bargaining, depression, and acceptance) as I learned TDD, and how acceptance grew to love. You will walk away from the talk with techniques for maintaining and strengthening your relationship with TDD. Test frameworks and languages may come and go, but the fundamentals and value of TDD remain.

Have you ever been forced into a corner for an estimate? Looked at git blame and wondered how to resolve the issue with the original author? Or wanted to be considered a 'consultant' instead of another technical cog in your client's business? The common pitfall in these situations is your ability communicate. In this talk we'll take a look at this fundamental skill, hack your brain to look at some of these situations differently and bring you out as a more effective communicator and therefore more awesome developer/human being.

Five years ago I was diagnosed Type II BiPolar Disorder, and ADHD. For years I was crippled by intermittent depression, lack of focus, and a general inability to get shit done. Here's some cherry picked symptoms of these disorders: irregular sleep schedule, ability to operate for days with little to no sleep. Racing thoughts. Hyper-focus. Difficulty dealing with day-to-day maintenance tasks. Social isolation. Thoughts of grandeur - thinking that the rules don't apply to you. We recently lost a good friend and developer to untreated mental illness. Depression and ADHD run rampant in the developer community, but we don't talk about it. A lot of our people are suffering unnecessarily.

Most Ruby code makes heavy use of mutable state, which often contributes to long term maintenance problems. Mutability can lead to code that's difficult to understand, libraries and applications that aren't thread-safe, and tests that are slow and brittle. Immutability, on the other hand, can make code easy to reason about, safe to use in multi-threaded environments, and simple to test. Doesn't that sound nice? This talk answers the question "why immutability?", covers the building blocks of immutable code, such as value objects and persistent data structures, as well as higher order concepts that make heavy use of immutability, such as event sourcing and pure functions, and finally discusses the tradeoffs involved in going immutable.

The greatest gift Matz gave us with Ruby was it's clear emphasis on making it easier to interface with humans, so why are so many applications concerned with easing the interface with their frameworks, services, or databases? The emphasis on Object Oriented Programming and Test Driven Development in the Ruby community push us to move the focus of our applications away from these, but to where? To tests? To objects? To behaviors? The Problem Domain is where our focus should lie. It's there that we can interface most closely with both our customers and our code.

Every experienced Rails developer understands the need to break that monolithic application into smaller, manageable components. Unfortunately, most seasoned developers envision nightmares of SOAP, RPC, DCOM, CORBA, Web Services, DDS, and WCF when they hear the word "services." How do we build a lean confederation of applications without falling into the same traps that gave the phrase SOA such a bad name? We'll look at the following topics: * Knowing when it's appropriate to build as an SOA * The pitfalls of maintaining distributed systems * Using the right framework (and language) for the job * Patterns and techniques for developing resilient and easy to maintain SOAs * Decoupling services through queues and gateways * Clear patterns for painlessly testing services This talk is a distillation of our experiences running large distributed systems at Engine Yard and the Southern California Earthquake Detection Center.

We've all been there. You jump onto a project, full of spit and vinegar, ready to unleash your talents unto this new world of development. Being of the Ruby community and TDD minded, we blissfully open /spec or /test and jump into the tests only to find something along the lines of: include "../spec_helper.rb" describe Widget do before :each do #{50 lines of setup for each test} end ... We groan and sigh when we see this because we know that slogging through this is going to be painful. Not just to write tests, but to run tests, and, as a result, to change code. How do projects end up here? How does it come to this? We've all reveled in wonder at how fast some project's test suites are, how comprehensive their coverage is, and how magnificent their code seems to be. They tell us TDD should be enlightening, magnificent and should guide our development. This often does not feel like it is the case. This talk is a brief foray into diagnosing pain-inducing tests, discovering how development leads to this unfortunate rabbit hole, and not only how to avoid going down this pit of pain, but how to claw your way back out and into the wonderful world of pain-free TDD if you happen to be in such a dismal, dreary place.

Many of us were taught "Skinny Controller/Fat Model" when we came to Rails. However, as our projects grow, we find our models exploding sometimes with frontend related code. Enter the Presenter. Keeping in line with the "Single responsibility principle", a Presenter or Decorator is used to extend our models and add view related functionality. In the talk, we will look at some different ways to implement and test a presenter.

With the rise of Ruby on Rails as the flagship web framework of the Ruby world far too many of us have been dragged into the comfort zone that is modeling our data structures the ActiveRecord way. It's just too damn convenient! With a simple command I can have all the basic files required for my logic to work, and that means little work and no thinking. This is all fun and games until you realize that your database is polluted with unnecessary tables, and you have to struggle to figure out where a particular piece of business logic should go because your models are not clear enough in their separation of concerns. These are all symptoms to a problem in your data modeling. So how do we go about this? What is a model really? What is the problem we are really trying to solve with ActiveRecord (or your ORM of choice)? When should we apply it and when should we stick to a plain old ruby object? What are clear, minimalistic patterns we can apply to our rails application to have coherent data structures that accurately represent the reality of your application and basically stay out of your way when implementing new stuff? All these questions and more should be answered in this zoolander-themed talk!

From DRB, XMPP, AMQP to Resque and Rails 4. Running a background worker process is a tool I've reached for often. And while the underlying tools may change, the same problems seem to crop up in every one. A failed request serves your fancy custom 500 error page, but what about a failed job? Is there such a thing as a "reliable" queuing system that will never lose OR double process any jobs? Are we talking about "simple" asynchronous method calls on models or should we build "pure" workers with only the knowledge of a single task? What does "idempotent" mean again? Please allow me to enliven the debates.

This talk uses Ruby implementations of Python's list, set, and dictionary (hash) comprehensions as an excuse to discuss functional programming in Ruby, focusing especially on using blocks to add syntax to the language. To provide a broader context, we briefly discuss some features of the Lisp programming language, including macros and lexical closures, and how they relate to "Matz's personal Lisp". The talk concludes by building up the full implementations (including tests!) of Python comprehensions in Ruby.

This talk will discuss tools and techniques for architecting Ruby applications with dependencies against volatile external HTTP services. Focuses will be on using Typhoeus to consume HTTP services currently, using Faraday to reduce application complexity through the use of Rack-like middleware layers in your HTTP request/response cycle, and using VCR to add deterministic testing against volatile external services.

You've heard of Chef, Puppet, and other frameworks that can help you build out your infrastructure. You've been meaning to play around with one or more of them for some time now. Now's your chance; Start cooking up on your own servers! In this tutorial, we'll provide an introduction to Chef with a focus on what you'll need to know to get a Rails application up and running. Topics include: Introduction to Chef; Nodes, roles, environments, and other terminology; Anatomy of a Chef run; Introduction to cookbooks; Provisioning an environment for a Rails application; Hands-on demo that will include provisioning servers for a Rails application; Deploying with Capistrano You won't be ready to compete in Iron Chef, but you will be ready to serve up your own Rails environment in no time. (This could be presented as a ~40-minute presentation or a workshop that runs from 40 minutes to a full day or anywhere in between)

Software licensing sets up rules for everyone to follow when contributing or using code. Some companies have specific policies on what types of licenses are compatible with their code base. Other companies put rules on their developers on how they're allowed to contribute code to software. Do you license your software?

I spend about 1/2 of my coding day in Erlang, and the other half in Ruby. I love the expressiveness of Ruby but the concurrency paradigm in Erlang. Is it possible for Ruby to borrow the "Actor Model" for concurrency from Erlang? In this talk we'll learn what the Actor Model is, how we can use it in ruby gems like girl_friday, and Revactor, and we'll actually implement a small "scheduler" to see how this model works. We'll talk briefly about Akka and Erlang to understand the roots of this programming model.

Rails is a great framework for creating web apps... for awhile. What do you do when your codebase grows large? How do you handle large teams of developers? When performance becomes an issue, how do you scale? Most importantly, how do you write code which can easily be refactored later? Learn lessons from several real life projects: how to partition your Rails app into distinct modular engines, how to speed up your test suite by only running code effected by your changes, how to add a layer on top of ActiveRecord to enforce loose coupling, and many more!

This talk will try to give you some insight in a day at the office while implementing a custom SpreeCommerce web-shop. Showing the tools of the trade and discuss choices made while implementing designs and developing extensions. Utilizing the powerful SpreeCommerce eco-system and show you how to implement designs, extend default behaviour using custom extensions and avoid some pitfalls. The following subjects will be addressed: * Theme development using Deface (or not) * Test Driven Extensions * Pitfalls to avoid * Spree Best Practices

At YP, we've built out our own traffic light indicator using Arduino, Sinatra, and Jenkins, to show our current continuous integration status. Learn about how the traffic light system works, how it's affected our approach and enthusiasm for testing, and how you can build your own traffic light to monitor your tests.

ActiveRecord is an easy-to-understand design pattern that deals with the problem of persisting application objects to an underlying data store. The ActiveRecord gem is a mature battle-tested implementation of this design pattern used in millions of Rails deployments. This talk will first do some code spelunking in ActiveRecord. We’ll look at what design patterns are used inside this gem and trace a few common actions to see how they execute. Following this, the implementation of an adapter for a new database named Akiban will be discussed and a demo of this adapter in action will be given. We’ll touch on what is involved for a developer to build a new ActiveRecord adapter. We’ll also show some of the unique aspects of this database and adapter, such as the ability to retrieve an entire object in 1 request.

The problem: we need (good) developers. The status quo: companies know how to identify the best people with Computer Science degrees. Hacker schools like Dev Bootcamp are graduating dozens of new programmers every couple of months, but how do you determine whether someone without a CS degree can really code? How does interviewing them differ from interviewing a traditional CS graduate, and what are acceptable knowledge gaps for a junior developer? This talk will explore best practices for interviewing and training this new breed of junior developer, based on interviews with companies that have hired them and surveys of the developers’ experiences on the job.

You saw the talks. You heard the news. Object-oriented development is the way to go. You feel fired up about starting to use these techniques in your work, or your side projects and... oh jeez! Where do you start?! This talk is a guide to tell you how to do just that. This will include discussions on how you can reap the largest benefit, where to focus your efforts to produce results quickly, and how to make sure you're not spinning your wheels or going down paths that will lead to obfuscated code later on.

We all know that message queues are great, right? All you need to do is add more hardware and you can scale out forever! ...Until your favorite cloud provider sends you a bill. In this talk, I will go over how we scaled our high traffic messaging platform while minimizing the amount of hardware needed.

For four years I lived with a chef from the sixth best restaurant in the world. After taking a hiatus to work in sales, I came back to coding this year, and found that many of the things I learned from him had direct application to my coding practice. As developers, we have more in common with chefs than with other office workers, like say, accountants - we are creators. The concepts of working clean, layering simplicity, shaving seconds off of repetitive tasks all apply.

I am a programmer turned sales guy turned programmer. I grew up as a socially awkward kid, and set my mind to figuring out how to talk to people. I learned that conversation is a skill - like programming - that can be learned by anyone who wants to. In this talk I give very simple concepts on how to have a conversation with anyone, and have them feel it was the most interesting conversation they've had all day.

Hosting your software and maintaining it against the guarantees of availability is a challenge. We are building a scalable and available SaaS to serve our application. This talk will describe the details of how we do it with AWS while dealing with eventual consistency, provisioning latency and managing load in case of usage spikes as well as dead zones. We do this while being cost conscious and balancing availability and user experience at the same time.

One of the biggest problems in web development today is scalability. It's a big problem, and not always easy to solve, the sheer number of requests that large applications need to process is huge, and increasing every day. One of the most elegant and widely adopted techniques to deal with this is favoring modular architectures over monolithic ones. Having a distributed network of tiny apps makes it easier to have a robust, maintainable codebase. Adopting the Unix philosophy of doing one thing right is a topic that has been coming up on conferences and blog posts all over the world lately, and with good reason. But is a modular architecture always the best solution? Is then a monolithic approach "wrong" from the get go? Sometimes building a modular system is worth it, sometimes it just isn't. In this talk I put forward my thoughts and experiences dealing with refactoring your application into several small ones, how to build a monolithic app that can be easily split, how to approach the refactor gradually and incrementally so as not to lose the ability to deliver new features, and how to decide when it's simply not worth it. Talk Length: 25~ minutes.

Tammer Saleh, cofounder of Thunderbolt Labs will take you through the process of writing a RubyMotion iOS application that interfaces seamlessly with a backend Rails API. He'll explore all of the modern iOS techniques through RubyMotion, while using Storyboards, Bundler, and pulling data from a JSON API. In the process, he'll discuss the merits and pitfalls of using RubyMotion, and when it is and isn't appropriate for your project.

There are a lot of reasons to calculate your code coverage, and a lot of pitfalls. Of all the analytics you can run on your application and test suite, coverage data often has a lot of noise in the signal. What are the best metrics for measuring your coverage? Which metrics matter to your team and your company? Is 100% coverage a desirable goal, or is there a better way of measuring a killer test suite? What are the ideal tools for the job? We'll discuss how we can push code coverage in Ruby forward, both with new tools and with changes to Ruby itself.

Beginners have so much to teach the world. They approach every new experience with a sense of wonder and fear. That first sketch, that first cut, that first stroke - opens up a new world of opportunity. We all forget that we were once beginners. We embrace our mastery and revel in our conquests. Few take the time to step back and see the world through the eyes of a beginner, yet there is so much we can learn. Designing for beginners is designing for all. Challenge your experience, cast off your expectations, and re-learn how to begin again. In this talk we will delve into the experience of beginning, cover techniques to transcend your own mastery, and meditate on designs for a better world.

We know Rails is awesome at making websites, but what about APIs? Often, the default `respond_to :json` isn't enough. I'll show you the best gems to turn Rails into a lean, mean, API-servin' machine. Both JavaScript and Ruby clients will be discussed as well.

Teamwork ain't always easy. From meetings where everybody has something to say but nothing gets done to poor decisions being made because the most senior or most forceful team member won the argument; sometimes you long for the days of high-walled cubicles and lone ranger coding. Long no more. In this workshop, you will learn about two simple techniques that drastically improve a team's ability to work together toward common goals with less conflict and more genuine collaboration. Sound like a group hug session? Only if that's what your team decides to do. This is a hands on, practical approach to common problems teams of all sizes face.

We all know the problem of the monolithic rails app, and we've all accepted the divine words of Service-Oriented Architecture. But what does your world look like once you get there? Or say, maybe, three-quarters of the way there. Allow me to show you some of the mistakes we've made at Engine Yard on this path. It can be a bumpy road, but I promise you the destination is worth it.

Once the realm of shadowy government organizations, cryptography now permeates computing. Unfortunately, it is difficult to get correct and most developers know just enough to be harmful for their projects. Together, we’ll go through the basics of modern cryptography and where things can go horribly wrong. Specific topics: * Cryptographic primitives * Secure password storage * Subtle flaws that can leave you insecure * Why you should use TLS/SSL and GPG instead

There was once a time where gaming in the browser meant Flash. That time is no more. Based on OpenGL ES, WebGL brings the 3D world to the browser without any plugins. Three.js, a scenegraph library for WebGL, allows us to make creating 3D web apps easier by abstracting away many of the low-level API calls. In this session, you’ll learn the basics of game programming, WebGL, and how to use Three.js to create WebGL applications.

"I know I should write some tests, but I can't afford the time. I have to get this feature out the door." That's absolute crap, friends, and if you hear someone say it you should slap them. "Tests" are not the same thing as test-driven development. TDD is one part of a professional process known as "software engineering", designed to improve both quality and productivity. While a prescribed process may instinctively feel tedious compared to gut-instinct hacking, in practice you will get the job done faster. (Side note to the organizers: I gave an early version of this talk to the meetup recently; feel free to ask Alf for a review.)

The web is changing and new changes are coming. How will the new RFCs will affect the web as we know it? What technologies will raise again? Is Ruby prepared for this changes? I want to answer these questions and talk about new web technologies and how we need to change to adapt to this upcoming era. From web sockets to WebRTC. From distributed to decentralised. The storm is coming… are you ready?

Hey, I know this puts you in an awkward position because you like rails and you hang out with her all the time, there is no easy way to put this but the thing is: I'm having affairs with other frameworks, and of course it won't be easy talking to her about this. So I was wondering if you could come and be a mediator for it? I hope things don't turn ugly. The truth is: I like rails, it definitely has a special place in my life, but I've been around, and I've talked to people, and I find that there are others who are sometimes more fun to hang out with in certain situations. Sinatra is just fantastic to look at, although I have to admit Padrino is also pretty awesome and fun to be with, Camping is super crazy (but believe me, she can definitely teach you stuff), and of course there is also Rack, she is kind of shy and usually doesn't go out with anyone if her friends are not coming, but she can be a lot of fun once you get to know her. The thing is: I want to be open to Rails and tell her why I like her, I still want to spend time with her, but I think it's time to explain why our relationship shouldn't be exclusive, so you know.. hopefully we could still be friends? Talk Length: 25~ minutes.

The web is turning twenty-three this year. We'll examine the what the web has become in that time, and more importantly, how (or if) it can move forward. Is Zed Shaw right, and are its problems inherent in the thinking of those who created it? Is the relatively young App Store economy destined to replace it? Or is there another way? We'll examine the web's competition, strengths, and weaknesses as both an application platform and a document platform.

There's a lot of ways to organize and manage designers and developers. Does specialization help small development teams, or should everyone be a generalist? We'll discuss the advantages of each of those strategies and try to settle on the best way to foster innovation, happiness, and joy for one and all.

Got test coverage on your controllers, models and even views? Strict about TDD? Enforce code coverage on pain of build failures? But what about your Javascript? Javascript is code too! If it's code we should be writing tests for it. JCov is a test framework agnostic, lightweight, headless Javascript test runner that reports code coverage. In Ruby naturally! We'll discuss Javascript testing in a Rails project, how JCov works behind the scenes and how to get it integrated with your favorite test framework.

We've all been there: there's a bug in a library you're using, but you don't know where to start. You open the code, and are immediately assaulted with dozens of classes, hundreds of lines and of course little to no comments. Learn how to use ruby to dig into large ruby libraries with surgical precision. We'll cover some useful tricks and of course do some live spelunking in Rails on the stage. Turn your impossible bugs into pull requests by code spelunking Ruby with Ruby.

Ruby is well know for being an Object Oriented language, all of us use this programing paradigm every day, but Ruby also offer us concepts from functional programming in a natural way on the language. So in this talk I will try to show you how to use our beloved Ruby with a different programming paradigm

When someone asks you what makes your company **special**, you'll probably say you create something that has _beauty, quality and innovation_... The problem is, thats what all companies say. You think you are, or want to be **better than the rest**, but when are you better than the rest? **Metrics is everything**, without numbers there's no way to tell if you're getting better at what you do, there's no way to tell (and show) if you're better than your competition. But how do you measure the beauty of your designs? The quality of your software? The innovation of your products?

Good integration tests are hard. There are many approaches for testing server and client libraries all with various tradeoffs and problems that come up. Some are obvious, some are a little more tricky. I'll run through some approaches I've come across developing server APIs along with their corresponding clients, while developing these in a highly distributed systems setup at Engine Yard.

“Fat models” cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle (SRP). “Anything related to what a user does” is not a single responsibility. Early on, SRP is easier to apply. ActiveRecord classes handle persistence, associations and not much else. But bit-by-bit, they grow. Objects that are inherently responsible for persistence become the de facto owner of all business logic as well. And a year or two later you have a User class with over 500 lines of code, and hundreds of methods in it’s public interface. Callback hell ensues. This talk will explore patterns to smoothly deal with increasing intrinsic complexity (read: features!) of your application. Transform fat models into a coordinated set of small, encapsulated objects working together in a veritable symphony.

We've all been there. The coffee shop chat where someone says SOLID and another person says BDD. And while I can't solve the emacs VIM divide, I *can* show you how we can unify the many TDD religions by building only what we need. In this talk I will walk through code samples and guide you through the approach we use at Thunderbolt Labs, where we're always focused on shipping features without sacrificing quality.

You're building your app and building a business. New requirements come in, and your increasingly large team makes reasonable decisions. You extract new services, and background long-running tasks, and all of sudden: complete mayhem. What is going on? This talk will take you on this journey, illustrating in detail just how reasonable decisions can have massive impact on your technical architecture, and what you can do to keep things maintainable. It's all based on my 12 month journey taking LivingSocial's payment process system from a synchronous, in-process monolithic rails app to a multi-service architecture of APIs and Resque jobs, all while attempting to keep things working.

Do you find yourself looking at something less than ideal and just calling it technical debt? Do you look at work you did a few months and only then realize it's not quite right? Do you propose "hacky" solutions to appease a project manager eager to get something done quickly? Are you scolding by your team lead for trying to make "perfect" code? This talk will straighten ALL of that out. We'll talk about the difference between technical debt and sloppy coding, and dispel the myth of perfect code. I'll arm you with the confidence to deliver quality, and the sense to keep from over-engineering and getting lost chasing the dream of beautiful code. Through the simple acts of testing, editing, and review, you'll deliver clean code on a schedule, and have the confidence to insist on it.

Do you ever get distracted by a persistent bug in production while hurtling towards the ground at 122 mph? Find it easy to think about CSS while sweating through an intense vinyasa flow yoga class? No? Me neither. And that's a really good thing. Physical activities that demand our full attention allow us to enter a heightened mental state I call "Being Present". For me, the activity is surfing. Take a seat in the sand, slather on the sunscreen, and I will tell tales of the mystical art of wave riding. My best days of work alway begins with a trip to the beach.

I don't know if you people already knew this, but Redis is the ultimate tool for hacking something together and shipping it straight to production. And let me tell you, I've shipped my share of hacks to production. The secret, of course, is key expiration. Plus you don't have to ship migrations, so reverting your hacks leaves way less cruft! Allow me to show you some real-world examples. That you too may be engorged with the sense of power I first experienced when I realized how easy this is. Cheat sheet: redis.set("foo", "bar") redis.get("foo") #returns "bar" redis.expire("foo", 5.minutes)

Rails is pretty great. It looks for the definition of User in "user.rb". It knows that my views for WatsitsController are in views/watsits. And I can even have an auto-generated blog in 5 minutes thanks to scaffolding. But couldn't we go so much further? What would happen if we took the rails ideal of Convention over Configuration to it's limits? How about default implementations of controllers. What about some default views? Couldn't our entire set of models be simply inferred from our database schema? Let's go there.

It's your first day at Hogwarts.com, and everything is wonderful and thrilling. Upperclassmen and teachers, far wiser than you, introduce you to your new home, show you where to sit, who to talk to, and leave you to your studies. You dig in, and soon find a dusty book with a cryptic warning: "Do NOT on any circumstances make ANY change to this without talking to Doug!!!" Who is Doug? You didn't meet any Doug. You ask your mentor, and they don't know a Doug.. in fact, there's no Doug at the company.. and no record that a "Doug" EVER worked here! Sound familiar? Approaching a legacy code base can feel like unraveling a mystery, not just about the code, but about the personalities who wrote it.. and may still be writing it! What lessons about working successfully with legacy code can we learn from Harry and his friends?

Do you actually know how deliberately acquire, sharpen, and retain a technical skill? In this talk, I'll discuss common strategies to enable you to be more focused, creative, and productive while learning, by using play, exploration, and ultimately failure. You'll leave knowing several "Experiential Learning" patterns and techniques that can help you turn failure into success. When was the last time you failed in a spectacular fashion? Was it really so bad? If you want to succeed, you first need to take a little time to fail.

As the web applications have become more interactive and complicated the need to create systems have grown. The line between back-end developer and front-end developer is also becoming a bit more blurry. Discover how to create a modular rapid prototyping system with Middleman and how to create a modular front-end architecture using Slim, Sass/Compass & Cells.

<a href="http://www.vatrexadvice.com/">valtrex generic</a>

G2Mtdk , [url=http://zitbmdbmsrqx.com/]zitbmdbmsrqx[/url], [link=http://oednhukfswbg.com/]oednhukfswbg[/link], http://ctuipckabsfy.com/

<a href="http://www.getedtabletsonline.com/">sildenafil</a> 155 <a href="http://www.usaglobalquotes.com/">car insurance in florida</a> 306978 <a href="http://www.treatingedonline.net/">generic cialis online</a> 688154 <a href="http://www.insureyourselfcheap.com/">cheap auto insurance</a> 410 <a href="http://www.edmedspartners.com/">cheap generic cialis</a> iosw <a href="http://insuredcar.net/">gap insurance medical</a> 8(( <a href="http://www.therapyfored.com/">viagra cheap</a> 085

<a href="http://www.usaglobalquotes.com/auto-insurance-quotes-nevada.html">Las Vegas auto insurance quotes</a> ifowsp <a href="http://www.getacnetreatment.net/">accutane online</a> 203 <a href="http://www.edmedscosts.com/">levitra</a> >:-OOO <a href="http://www.insureyourselfcheap.com/">cheap insurance</a> :-DD <a href="http://www.aforaubergine.com/">car insurance new york premium by area</a> 08326 <a href="http://www.lbprolife.com/">cheap car insurance quotes</a> fsfp <a href="http://choosecarinsurance.com/">insurance cheap office</a> >:-OO

<a href="http://www.houseofruffians.com/">Auto Insurance Costs</a> coj <a href="http://www.edmedscosts.com/">levitra addicting online games</a> :))) <a href="http://www.palaumantarays.com/">auto insurance auto insurance</a> haqh <a href="http://www.anystatecarinsurance.com/cheap-car-insurance-LA.html">cheap car insurance Louisiana</a> zgg <a href="http://www.therapyfored.com/">viagra online</a> 8))

<a href="http://www.accesstomedssavings.com/">prednisone</a> svsjh <a href="http://www.autoprotectionoptions.com/">auto insurance quotes</a> mbben <a href="http://www.treatingedonline.net/">purchase cialis</a> cvbt <a href="http://www.bestqualityedtreatment.com/">cialis</a> 8]]] <a href="http://edsupertabs.com/">buy cialis online</a> %] <a href="http://www.buyedtabletsonline.com/">buy viagra</a> 022