Tobias Lutke wrote the first line of code for Shopify nearly 10 years ago to power his own Snowboard shop. Two years later Shopify launched to the public on a single webserver using Rails 0.13.1. Today Shopify powers over 40k online stores and processes up to half a million product sales per day across the platform. Over 30 people actively work on Shopify which makes it the longest developed and likely largest Rails code base out there.
This is the story of how Shopify has evolved to handle its immense growth over the years. This is what getting big is all about: evolving to meet the needs of your customers. You don't start out with a system and infrastructure that can handle a billion dollar in GMV. You evolve to it. You evolve by adding caching layers, hardware, queuing systems and splitting your application to services.
This is the story of how we have tackled the various scaling pain points that Shopify has hit and what we have done to surpass them, what we are doing to go even further.
Long-running branches are painful, but upgrading to Rails 3 requires one if you can't stop development, right? Wrong! At New Relic, we worked on upgrading to Rails 3 on master while letting development continue in Rails 2. We patched Bundler, built a backwards-compatible boot sequence, and punched ActiveScaffold in the face. Other developers, meanwhile, released 1400 commits worth of work without noticing any changes. We’ll talk about what we did, why we did it, and why we think this approach can help developers get over the hurdle into the Rails 3 promised land.
Ever wondered what Rails is doing behind the scenes? What happens to an HTTP request after it leaves your browser? How does Rails process the response?
In this beginner talk, Aimee Simone and Christopher Green break down the request/response cycle of a web application, navigating through the magestic internals of Rails. We'll outline the responsibilities of each Rails component, including its MVC framework and RESTful routing concepts. By following the flow from a client HTTP request to a completed server response, you'll gain a better understanding of the anatomy of a Rails application.
Unwieldy templates (a.k.a. views) are all too common in Rails apps, even among teams that otherwise craft high-quality code. Being brought into or having to maintain a project with poorly-crafted templates leads to extreme frustration and less than-adequite-velocity. At philosophie, we have started to use a few simple patterns that result in templates that are easier to maintain. By investing a small amount of time up-front learning and applying these patterns we have saved countless hours in the long run.
* The Decorator Pattern
* Using View objects
* Sanely building forms
* And more!
Why do we all know a developer who has been pounding out unmaintainable code for a decade or more? Why do people "believe in TDD but I don't have time to write tests during crunch?" How is it that we have an entire industry based around rescuing teams from acutely awful Rails apps?
It's because on the job experience is a poor teacher; plateauing as soon as the developer is able to ship code that meets requirements. Schools teach Computer Science which is only tangentially related to being a developer and most kata's are approached incorrectly, giving no value at best, and reinforcing poor practices at worst. On top of all this, our pairs (for the lucky ones who pair program) probably have not shown us anything new in months.
This presentation will give specific, concrete steps on how to slowly and steadily improve our game through practice and hard work. I'll identify what skill Rails developers should be focusing on and walk the audience through how to target and eliminate these weaknesses so that nothing but white hot joy streams out of our fingers and into our apps. There's no magic here, no secrets, and no hacks; just you and me working our butts off until we suck a little less.
Building a web app consists of stressful choices. Should the signup button be red or blue? Does my site's sales pitch sound awkward? What will the user think about my site the first five seconds they visit?
Using Rails and Amazon's Mechanical Turk service, I will show you how you can perform usability tests, A/B testing and gain valuable feedback on your site BEFORE launching your app to a single real user.
I'll walk you through :
1) Sample code for quickly integrating your Rails site with Mechanical Turk
2) How to structure your HITs (Human Intelligence Tasks) so that you solicit detailed feedback from the workers.
3) Integrating A/B testing so that you can quickly decide which design component is better
4) Tactics for stopping automated bots from ruining your usability tests
Good integration tests are hard. There are many approaches for testing server/client HTTP 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 and problems I've come across developing server/client APIs, while developing these in a highly distributed systems setup at Engine Yard.
Do you have to look at Rails models with 2500 lines of code? Or 200 line methods loaded with iterators, conditionals and instance variables? Not only you, even the code author does not understand what's going on in there.
I'll show you how you can craft simple and beautiful Rails application by adopting functional programming inspired ideas. Say goodbye to the mess you have by constructing tiny classes and functions that you can use to build up a complex system.
Behavior-Driven Development and Acceptance Testing are heavily intertwined and in many aspects are one and the same. Both focus on starting at the outer layers of your application by concentrating on what matter to users; behavior. In this session/workshop we'll talk about how testing can be used both for specifying your application yet to be develop expected behavior and as accurate, running documentation that can be used to validate your stakeholder's acceptance criteria. We'll talk about the different types of testing and do a few hands-on exercises to flesh out a Rails application with RSpec and Capybara.
The last few months have been pretty brutal for anyone who depends on Ruby libraries in production. Ruby is really popular now, and that’s exciting! But it also means that we are now square in the crosshairs of security researchers, whether whitehat, blackhat, or some other hat. Only the Ruby and Rails core teams have meaningful experience with vulnerabilites so far. It won’t last. Vulnerabilities are everywhere, and handling security issues responsibly is critical if we want Ruby (and Rubyists) to stay in high demand.
Using Bundler’s first CVE as a case study, I’ll discuss responsible disclosure, as well as repsonsible ownership of your own code. How do you know if a bug is a security issue, and how do you report it without tipping off someone malicious? As a Rubyist, you probably have at least one library of your own. How do you handle security issues, and fix them without compromising apps running on the old code? Don’t let your site get hacked, or worse yet, let your project allow someone else’s site to get hacked! Learn from the hard-won wisdom of the security community so that we won’t repeat the mistakes of others.
Your app is your business, so keeping it healthy is important. Unfortunately, most of the tools available today are more like your doctor verifying the fact that you've had a heart attack—after it's happened.
You can do better. In this session, you'll learn how to use metrics to be more proactive about monitoring your applications health, and to suss out the subtle but important warning signs that can help you prioritize developer time and improve the developer experience. We'll talk about how to instrument your code, what to measure, how to interpret the data, as well as how you can use the data to streamline your development process.
The dreams of developers working on monolithic Rails applications are frequently filled with sugar plums and service-oriented architectures--but like any kind of software design, SOA can easily become a tangled mess. Many of the same principles that guide our software design can guide our architecture design. We apply SOLID principles to applications to keep them loosely coupled, we design interfaces so we can send logical messages to our domain objects. We hide our databases behind abstractions because how we access our data shouldn't matter to how we consume it. Rarely, though, do we see the same practices applied to our services and APIs, leaving us with tightly coupled and difficult to extend service-oriented architectures. If you are facing the monorail to SOA challenge, consider looking at your services as objects and your APIs as messages. Service-oriented applications are complex, and the best way to fend off complexity is though object-oriented design.
Out of the box, Rails provides facilities for preventing attacks like SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and more. As a result, it's considered one of the most secure web application frameworks available.
Digging deeper, however, you can find a number of places where Rails' default behavior is not as secure as it could be. This talk will focus on longstanding, known weak spots that create risks for your application and business if you are not aware of them.
The field of natural language processing and the many topics encompassed within it (summarization, full-text search, sentiment analysis, content categorization, etc.) is one of fastest growing, most complex and most highly demanded knowledge sets in the software industry today.
From spell checking in your SMS client to programmatically evaluating what your Twitter followers think of you, there is no shortage of real-world text processing and linguistic analysis problems all around us waiting to be solved. As Rubyists and software engineers, its important for us to know what tools related to NLP are available to us and how we can make use of them most effectively.
While there are a number of really great open-source libraries for natural language processing in Ruby and many great strides have been made in recent years, there’s still often a need to leverage tools and libraries externally from the Ruby ecosystem. Some of the best open-source NLP frameworks available rely very heavily on contributions from the academic world where Ruby as a language doesn’t have the same presence as other languages like Python or Java.
In this talk, I’ll provide a beginner friendly introduction to NLP in general and I’ll give a quick overview of the tools and related projects that are currently available in the Ruby community. In addition, using real-world examples I’ll demonstrate how to painlessly leverage high performance, mature and well-established NLP libraries directly from your Ruby application using JRuby and JDK 7.
The future is real time! With the Rails 4.0 Live Streaming API we finally have the ability to easily add real time functionality to our apps. Learn all about the live streaming API, how best to take advantage of this in the browser, and how to deploy a real-time ready Rails app. Get ready to open your apps to a whole new world of interaction and functionality.
Topics we will cover:
* Live Streaming API
* EventMachine vs Rails 4.0
* Node.js vs Rails 4.0
* Polling vs Live Streaming
* Websockets & Rails 4.0
Developers: how many times have you had to completely rip out your hard earned code for a totally new site design?
Designers: how many times has a re-design taken 4 times as long as the developer said it would and not looked good in the end?
Change all that by using an incremental approach to design. Set up your code to change all the buttons at once or prioritize design changes to make each small change good enough for production.
A designer and developer will talk about the challenges and joys of making this process work in two production sites.
* What is incremental design?
* How to design with incremental changes in mind
* How to develop for incremental design, including utilizing SASS, structuring your mark-up and CSS, and structuring your Rails views and partials
In a world of public and private clouds, API-driven load balancers, and bare metal servers there has never been more choice when building your next scalable killer application. As the complexity of your application's deployment environment increases, the economics of automation start to pay off. In this session we'll discuss the challenges facing complex application deployments, strategies to make development environments mirror production, and how you can manage architectural changes with your application over time. Automate all the things? Let's find out!
Rails: the result of magical incantations, voodoo, and wizardry? Or: a collection of patterns from the most awesomest language in the world (Ruby)? We'll show three different areas of Rails that seem to be the most magical: before_filters and callbacks, Procs, and inheritance. In the workshop, participants will create their own Ruby object implementing these magical powers.
The Ruby on Rails developer faces an interesting duality. Their inner Rubyist is driven by a sense of beauty and explores a wide range of ways to solve a problem. The inner Railser is driven by a strong set of conventions and is guided by the Rails Way™. The /lib directory is where these developers meet and end result is a junk drawer of awkward code.
In this talk, I go over a few ways to keep this junk drawer problem from happening by adding some conventions I've created from building Rails in anger:
* Treat /lib as a temple (keep /lib in a state to extract to a gem in minutes)
* Avoid autoloading everything in /lib
* Use configuration to hide credentials from your library code
* Isolate your Domain Objects from library concerns through DCI
We hear the stories every so often. A study concludes that internet usage is making us "dumber", while another connects online activity to anxiety or depression. A respected journalist questions whether our advanced technology is really improving our lives. A mass movement of people deleting their Facebook or Twitter accounts sweeps through the community.
As developers, we hear these stories, and we shrug. Luddites and fearmongers, we call them. But don't they have a point? Do we truly understand what technology is, and how it impacts our society, the way we think and what we value? An important conversation is taking place. As Rails developers, as professionals working on the cutting edge of consumer technology, we should be involved.
This talk is a brief introduction to the philosophy of technology. We'll examine a few of the major views-- the writings of the philosophers, academics, and engineers who are asking questions regarding technology and society. We'll also explore what these questions mean for us as developers, what they can tell us about our profession, and what we can uniquely contribute to the conversation. We may not find a lot of solid answers, but we'll plow a rich field for discussion, and maybe gain a new perspective into just what it is that we spend our time doing.
One of the best ways to learn is to experiment with seemingly crazy ideas. When Rails 3 first came out, it became easier than ever to embed a Sinatra application inside your Rails application. But what if you wanted to implement parts of Sinatra in Rails?
Have you ever wished your controllers had Sinatra style routes? Have you ever wondered if you could render a template in the same context as your controllers? What about one single-file Rails applications?
In this talk, we are going to build all those functionalities into a Rails application, making sure we learn about Rails internals and have fun while doing it.
thoughtbot are creators of the open-sourced testing tools FactoryGirl and Shoulda Matchers.
We recognize Test-Driven Development (TDD) can be difficult to practice as features increase in complexity. Testing is often skipped when developers feel uncomfortable with TDD or have not yet seen certain approaches in practice.
We’ll describe specific techniques used in TDD which touch on: Integration testing with RSpec+Capybara, Model Associations and Data Validations, Asynchronous Jobs, Emails, 3rd Party Services, and JSON API endpoints.
Which of these will work for you?
We will look at code to see the structural difference between these two approaches and see what the speed, extensibility, and maintainability trade-offs are. At the end of the talk, you will be better equipped to chose a structure for your next rich-client application.
What do home ownership and leveraged buyouts can teach us about how to use technical debt to our advantage? How can we sleep soundly at night when we have accumulated mountains and mountains of technical debt? When is good enough good enough and when are we just deceiving ourselves?
In this talk, we'll explore split testing as a way to not only increase revenue and conversion through simple, surface-level changes, but also to dig deeper in order to help guide a product's roadmap by discovering which features customers really want and how much they're willing to pay.
Tests are supposed to save us money. How is it, then, that many times they become millstones around our necks, gradually morphing into fragile, breakable things that raise the cost of change?
We write too many tests and we test the wrong kinds of things. This talk strips away the veil and offers simple, practical guidelines for choosing what to test and how to test it. Finding the right testing balance isn't magic, it's a magic trick; come and learn the secret of writing stable tests that protect your application at the lowest possible cost.
Snappiness is an important key for any successful webpage. Most companies try to achieve responsive webshops by scaling their hardware big time. But Rails in combination with Nginx, Memcached and Redis is the key to deliver webpages very fast with a minimal amount of hardware. This talk will start with the basics of DHH's russian doll idea but will raise the bar than quite a bit. How can we combine fragment caching, page caching and HTTP caching to deliver personalized webshop pages for logged in users? How much brain can be delegated to Redis or the Webbrowser? Harddrive space is cheap. So use it! You'll get to know how to plan your data structure and where to use Memcached vs. Redis. Include the cache in the beginning of your development and not in the end. To make things a bit more interesting everything is replayed on a Raspberry Pi to show how much difference intelligent caching can make on any hardware. Save big time and get more clients with a faster web application!
Most of us know how to build beautiful web applications with Rails. With the help of templating tools like ERB and HAML our web apps create HTML documents, but, do you know exactly how those HTML documents end up in a browser?
During this talk I will show you the bits that make it all happen. We will dissect the relevant code within Rails, Rack and the thin web server to discover exactly how the web server starts and listens to a TCP port, communicates with Rails and returns the HTML document that your browser parses.
Why? Because we're curious about it, that's why.
In this workshop, we'll focus on two specific problems that plague testing complex systems: how do I create useful test data, and how do I limit my test to only the part of the system that I want tested. We'll cover data creation tools like factories and fixtures. We will also talk about how to effectively use mock objects. And we'll do all that against some code that shows off potental testing problems.
In this session we'll go off the Rails and take a look at what our Pythonista cousins are doing with Django.
I'll start with some live coding: recreating DHH's infamous 15 minute blog demo using Django and explaining the building blocks of a Django app along the way. I'll then take that app and use it to look at some design decisions Django makes, and how they compare to Rails. You'll see convention over configuration in places you didn't expect it, why Django doesn't need attr_accessible or strong parameters, and how the template method pattern could change your life.
Why talk about Python at a Rails conference? Seeing another way of doing things forces us to think about what we're doing, challenges or validates the assumptions we make about our work, and inspires us to try new things.
This talk will introduce Brainstem, a new Rails library for easily presenting and versioning complex ActiveRecord model relationships through your JSON API. Allow your internal or external API consumers to eager-load model associations, request custom scopes and sorts, load multiple objects by ID simultaneously, and generate JSON that uses references instead of repeating data.
While your Brainstem API can be consumed by any JSON client, it will truly shine when using the included Backbone integration, adding relationship-aware models, centralized data loading, and a smart caching identity map to your Backbone applications.
All of this is designed to reduce network requests and simplify development of HTML5 applications, especially mobile ones. With Backbone + Brainstem, loading a hierarchy of objects from your server can be reduced to one line of code and one network request.
This talk will survey Brainstem usage in Rails, then dive into how it can enable rich mobile HTML5 applications.
We've all heard how great the cloud is - but no one likes learning a new proprietary API if they don't need to. In this session, I'll demonstrate how you can develop, test and deploy ROR apps faster to HP's public cloud based on OpenStack technology. If you are new to the cloud or if you're just a CLI commando, I'll run through HP's Ruby CLI, spin up cloud servers and attach block storage faster than you thought possible. And, for Ruby Fog fans, I'll show you the HP Ruby Fog extensions that let you easily provision and manage cloud servers and storage using your favorite environment.
Your customers care about how fast your application works, you should too.... At Heroku we see millions of apps deploy and we know what it takes to get serious performance out of your code and Rails. In this talk we'll cover backend tips and frontend tricks that will help your Rails app go faster than ever before.
APIs are interfaces, just like UIs. But while a website or a mobile app is designed to be used by a consumer, an API has two very specific audiences in mind: other systems, and the programmers who build them.
A well-designed API can make or break an application. So how do developers build great APIs? What design principles should be followed? We will discuss these questions based on the work of thinkers in the areas of industrial design, writing, and product design theory.
Go has rapidly built a reputation as a great language for web development. But as Rails developers, we already have a really, really great language for web development -- why should we be interested in Go?
I’m convinced that every web developer would benefit from exposure to the Go approach to programming, which places a strong emphasis on up-front error handling and modular, namespaced libraries. Let's sit down and compare some code!
In this talk, we will:
* Compare idiomatic approaches to common problems such as error handling, dependency management and testing in Go and Ruby.
* Think carefully about tradeoffs between different programming styles and examine how programming languages encourage one style or another.
* Tease out common ideas and best practices that apply to all web applications, regardless of language or framework.
* Read a bunch of code.
We will not:
* Try to convince anyone to ditch Ruby/Rails and embrace Go.
* Make vague, unsubstantiated claims about the benefits of static or dynamic typing.
* Assume any prior knowledge of Go.
Let's be honest: ActiveRecord's got issues, and it's not going to deal with them on its own. It needs our help.
Don't think so? Let's take a closer look together. We'll examine the myriad of perils and pitfalls that await newbie and veteran alike, ranging from intentionally inconsistent behavior to subtle oddities arising from implementation details.
Of course, as with any intervention, we're only doing this because we care. At the very least, you'll learn something you didn't know about ActiveRecord, that helps you avoid these gotchas in your applications. But I hope that you'll leave inspired to contribute to ActiveRecord, engage in discussion about its direction with the core team, and therefore improve the lives of your fellow Rails developers.
WARNING: We will be reading the ActiveRecord code in this talk. Not for the faint of heart.
Self-documenting code is a pipe dream. TDD (or BDD) is not the panacea of testing. In the pursuit of test coverage we've forgotten what really matters: getting things done. Lets talk about putting documentation and testing into their proper place. Tools that ease maintenance, help other developers join a project, and reduce bugs.
I'm going to go over lessons learned in writing, maintaining, and introducing new developers to 20,000 lines of code. Specifically, how we are testing, documenting, and refactoring our code to stay sane, make the team happier, and get more done.
What is the best data storage option for your application? We have an abundance of conventional wisdom when it comes to building applications on top of a relational database in the Ruby world. Building an application on top of a NoSQL database is a different story. I will present a conceptual framework for understanding Access Patterns that jives with properties of databases, then review common NoSQL databases and propose considerations for choosing one over another. I will also review some uncommon NoSQL databases that address common use cases, and suggest that perhaps some of these should be used more often. Most importantly, I will describe the different state of mind that you should have when building applications on top of these NoSQL options, and provide visualization of non-relational concerns like: fault tolerance, availability, consistency, capacity planning, and horizontal vs vertical scaling. Whether or not you choose a NoSQL option for a future project, you won’t look at data storage options in the same way after this presentation. ;-)
This talk+workshop highlights some Ruby libraries that are particularly useful when developing Rails applications. In the talk portion, we'll give an overview of some specific classes and modules, and then in the workshop we'll break into groups to dive deeper into libraries of each participant's choice, with a focus on developing the skills needed to read and understand the Ruby documentation. Time and interest permitting, we'll incorporate test-driven development into our investigations.
Pry is the featureful development console for Ruby. From its humble roots as an irb replacement, Pry has grown into an indispensable tool for any Ruby or Rails programmer.
Using some real-life examples, I'll explain how to use Pry effectively.
We'll start from the beginning, with simple features for exploring libraries and source-code in glorious technicolor. Then we'll move up a level and discuss how to inspect, debug and even modify a program while it is still running. Finally we'll touch on some of Pry's more advanced plugins that can really help you get a feel for what your code is doing.
Your fledgling social network for hedgehogs is starting to gain traction, but now new feature requests are pouring in. How you can you meet the demands of an ambitious product team within your existing stack? There’s no time to waste, so we will look at how to leverage the venerable Postgres workhorse.
We will look at some of Postgres' unique features that lend themselves to solving the problems Rails developers face when moving from v1 products to v2 and beyond. We will focus on SQL and ActiveRecord, and talk about pragmatic solutions to hairy problems. Get practical, hands-on advice about using Postgres with ActiveRecord to support tagging, model hierarchical data, store arbitrary metadata, and add full text search to your application.
By the end of this talk, you’ll be able to go to your next meeting armed with confidence in your ability to build the ultimate hedgehog destination online.
Usability researchers have known for years that people browsing the Internet
don't read things word by word - they scan pages for the content they want. Yet
many API's and documentation resources are written as though users are reading
every word. If busy users can't find what they are looking for, you'll have
more support tickets (an expense), or more frustration (lost revenue).
Writing effective documentation requires knowing who your users are and how
they are finding answers to their questions. In this presentation, we'll
examine practical techniques to make your documentation work for busy users.
Looking at examples and user testing from our experience at Twilio, attendees will learn:
- how users find (or fail to find) your documentation
- how users view and get started (or fail to get started) with your product
- how to take advantage of underused documentation tools like your error messages, your API, and SEO.
We believe great work deserves recognition. The Ruby/Rails dev community is full of amazing contributors and unsung heroes who are busy producing educational content, developing plugins and gems, contributing to open-source projects, or putting on events to help developers learn and grow.
The Ruby Hero Award gives recognition to influential devs in the Ruby/Rails community and announces the winners at RailsConf.
Starting Rails applications is one thing, but how you apply the priciples of MVC as an application grows determine whether your application is modular and maintainable or a convoluted mess. In this session, we'll use an existing application to explore and practice some of the common mistakes, correct techniques, and concepts behind the techniques to improve your development patterns.
It's always inspiring to me to hear about how the technology stack I'm familiar with has been used to solve interesting problems; this is one of the extreme versions of that experience. Over the last few years, Rails has been used to solve several of the logistical pain points of the third largest fire service organization in the state of Missouri, and in this talk we're going to look at how it happened. Along the way we'll look at some of the challenges of working with such an out-of-the-ordinary organization and how Rails fit into addressing some fairly unique requirements and constraints. This is one Rails-in-the-wild case study that you won't want to pass up.
Elasticsearch is a powerful text search engine that's easy to configure and to integrate into your Rails and Ruby applications. But it's more than just a general text search engine--elasticsearch stores data in JSON format allowing for faceting and complex searches. There are gems that integrate it with ActiveRecord, but it can also be used easily outside of ActiveRecord. Learn from the real-world application of elasticsearch for general text searches to specific catalog-type searches.
We'll cover the elasticsearch basics, the existing gems you can use to integrate, and the lessons learned from integrating into existing projects. Examples include: how to index existing ActiveRecord models for general text searches, how to use elasticsearch for autocomplete, and how to use for complex queries.
We all know how to describe data using ActiveRecord models. Have you considered using a model to describe your service?
A service model provides a number of benefits including: easy to generate API documentation, consistent server side parameter validation, versioned APIs, easy to build clients, and more. It also represents a unified view of your API which helps to keep your code and documentation DRY. But what does a service model look like? For instance, did you know that your APIs can be described using just four parameter types? What if your could express your APIs using a Rails DSL?
This talk will introduce Seahorse, a DSL for describing API operations for just about any web service. It provides all of the above functionality, allowing you to describe your service model in a single place with Ruby code. We will demonstrate how to use Seahorse to generate clients, model existing real-world APIs, and even build one of our own.
Building services and integrating them into Rails is hard. We want smaller Rails apps and nicely encapsulated services, but services introduce complexity. If you go overboard in the beginning, you're doing extra work and getting some of it wrong. If you wait too long, you've got a mess.
At Yammer, we constantly clean up the mess that worked well in the early days, but has become troublesome to maintain and scale. We pull things out of the core Rails app, stand them up on their own, and make sure they work well and are fast. With 20+ services, we've learned some lessons along the way. Services that seem clean in the beginning can turn into development environment nightmares. Temporary double-dispatching solutions turn into developer confusion. Monitoring one app turns into monitoring a suite of apps and handling failure between them.
This talk looks at our mistakes and solutions, the tradeoffs, and how we're able to keep moving quickly. Having services and a smaller Rails codebase makes for scalable development teams, happier engineers, and predictable production environments. Getting there is full of hard decisions -- sometimes we get it right, sometimes we get it wrong, but we usually have a story to tell.
You have been doing this Rails thing for a while and you're starting to feel like it's time to give back. Great! Now what?
In this session we'll walk through the technical aspects of getting started with contributing back to Rails as well as the non-technical tips, tricks, and considerations to keep in mind along the way.
This talk will cover how developers can create their own engines, to add new controllers/models/views, rake tasks and/or generators. It will cover how engines can interact with Rails having their own initializers and middleware. Finally, based on our experiences converting BrowserCMS and its entire module ecosystem to work as mountable engines, this talk will cover how to make engines that are designed to work together, extend each other engine’s behavior and make it easy for developers to upgrade when you release new versions.
Are you a developer who's stuck behind a firewalled environment? How about a corporate environment with a lot red tape and access issues to get through? Some of us Rails developers don't have the luxury to work in a truly open environment where one can 'gem install rspec' and viola! we have testing. So what do we do about that? How do we use RVM to manage our gemsets and Ruby versions behind these restrictions? What about deployments? Is Capistrano even a viable option? I've been on a successful Rails project for two years that's had to tackle these kinds of questions. In this talk, I'll discuss my solutions to these problems so your project can be effective and efficient without any sacrifices. I'll discuss how to install and manage RVM in firewalled environments, use Capistrano for remote deployments, how to test your email notifications when your SMTP server is locked down, how to use Git when no Git hosting is available, and plenty of other topics.
When you're building a payment platform, you want to make sure that your system is always available to accept orders. However, the complexity of the platform introduces the potential for it to go down when any one of the moving parts fails. In this talk, I will show you the approaches that we've taken and the risks that we have to take to ensure that our platform will always be available for our customers. Even if you're not building a payment platform, these approaches can be applied to ensure a high availability for your platform or service as well.
New developments, interesting use cases and future plans. Edward will walk attendees through the dashboard and demonstrate the uses of new features such as Engine Yard Local. Whether you're a long-time Engine Yard user or just curious, this session will show you how to optimize your deployment experience.
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
You understand Ruby and Rails, and you've gotten the hang of using other peoples' gems - but what about writing your own? Gems underpin almost every piece of Ruby code we write - and so, being able to craft your own gems is not only incredibly useful, it provides an avenue for code reuse and open source sharing.
During this session, Pat will first discuss the ecosystem around gems and the knowledge required to write your own, plus a few tools available to assist with this, and some approaches for how to structure gems that integrate with Rails itself.
The workshop will then put this knowledge into practice by building our own gems from scratch.
The good news: you're quickly signing up new customers, you've scaled your Rails app to a growing cluster of 10+ servers, and the business is really starting to take off. Great! The bad news: Just 30m of failures is starting to be measured in hundreds or even thousands of dollars. Who's going to make sure the lights stay on when your app is starting to fall over? Or worse, what if your app is up, but sign-ups, payments, or some other critical function is broken?
Learn how you can build a robust monitoring infrastructure using the Sensu platform: track business metrics in all of your applications, any system metric on your servers, and do so all with the help of BatsD - a time series data store for real-time needs. We'll also talk about how to look at trending data and how you can integrate Sensu against PagerDuty, RabbitMQ, or any other third-party service. Oh, and of course - everything's written in Ruby, so you can even use your favorite gems!
As your simple Rails app grows into a larger system or set of systems, using simple constants and Yaml files for configuration may no longer suffice. The meaning of 'configuration' expands to include business logic alongside the customary hostnames and timeout intervals; the rate at which configuration changes are required increases; non-engineers begin to require the ability to make configuration changes themselves; different environments require different configurations. This presentation will examine several patterns that can be applied to handle these issues, keeping iteration team high and reducing the burden on your engineering team. We'll create and iterate on a simple game as a case study to illustrate the value of these principles in practice, and also look at a few open source projects that integrate some of these concepts.
* moving configuration values out of source
* sharing configuration across multiple applications/services
* working with sensitive configuration data (eg API keys)
* dynamically updating configuration without deployments or restarts
* cascading/overlaying configuration values based on environment and context
* running experiments and A/B tests
* change control
* testing and multi-stage deployment of configuration changesets
* allowing non-developers to change configuration values
Social app development challenges us to code for users’ personal world. Users are giving push-back to ill-fitted assumptions about their own identity — name, gender, sexual orientation, important relationships, and many other attributes that are individually meaningful.
How can we balance users’ realities with an app’s business requirements?
Facebook, Google+, and others are struggling with these questions. Resilient approaches arise from an app’s own foundation. Discover how our earliest choices influence codebase, UX, and development itself. Learn how we can use that knowledge to both inspire the people who use our apps, and to generate the data that need as developers.
Datomic is a new database categorized as NewSQL and was created by Rich Hickey. Everybody knows this big name and thinks of Clojure. It is true Datomic fits well to Clojure programming. However, it is not only for Clojure people.
Absolutely, Rubyists can use it. We have Diametric gem (https://github.com/relevance/diametric). Using Diametric, we can dive into Datomic from Ruby, from Rails.
On Diametric, Datomic's entity is an ActiveModel compliant. Diametric supports Rails' scaffolding. Its usage might look like Datamapper or MongoDB. Eventually, Diametric’s API design settled in a bit far from Ruby, Rails style. In another word, it is not ORM-like. Even though the API design may puzzle Rubyists, Diametric chose the one to expose Datomic's intrinsic properties. It is to leverage a good side of Datomic for us. I believe the more Rubyists use Diametric, the more they like it.
In my talk, I’ll introduce Diametric gem and how to use it as well as why its API design is good for us. Also, I will cover how Ruby helped to integrate Datomic API in Diametric gem.
Coming from a hacker background, I’ve continually been surprised by how frequently new grads lacked the skills needed, particularly in community learning. When I was asked to teach Ruby on Rails at Columbia University I observed that a significant number of the skills required to become successful professionals in the industry are acquired on the job and aren’t being taught in school.
This presentation will review:
- Lessons learned from the experience teaching in my alma mater’s CS program.
- How I developed a hacker-centric curriculum teaching not only the algorithms, but the keys to being a successful developer in the modern open source driven Rails community.
- How we as hackers can fix this.
As Ruby Developer I've had a pretty involved relationship with my Mac. I own iPads and iPhones since Apple started to make them. A few years back I told myself I was going to build apps for the Mac/iPhone/iPad but then reality sunk in when I started learning Objective-C and using XCode. The environment (and the language) felt like a trip back to 1995.
If you are a Web developer used to working with dynamically-typed, lightweight languages, following agile practices like Test-Driven Development, and comfortable with a Unix Shell, then jumping into a development world with an ugly cousin of C++ and an IDE that looks like an F16 cockpit just doesn’t seem appealing.
Luckily for us there is an alternative in RubyMotion, a Ruby-based toolchain for iOS that brings a Ruby on Rails style of development to the world of iOS application development.
In this talk I will show you how you can use well engrained Ruby practices like TDD to build iOS Apps with RubyMotion.
Nearly every developer will be asked to present to his or her peers at some point. Those that do it well will tend to have an outsized influence on their team, company, and community.
This talk will demonstrate (mostly by example) the straightforward techniques for giving excellent presentations, from a veteran conference speaker and teacher.
Topics to cover include:
* Phrases that turn your audience against you.
* Basic body language tips that affect perception.
* How to be more interesting than the internet.
* The power of live coding and demos.
* Being funny without resorting to reddit memes.
* How to get plenty of questions during Q&A.
* How to get an unfair amount of talk acceptances (aka 'Bribing conference organizers').
Underneath the beautiful veneer of our Ruby libraries lies a twisted tangle of writhing guts. Maybe you're curious how the pieces fit together or maybe you're tracking down a bug, either way it's easy to get lost in the blood and bile that ties our code together. In this talk you'll learn how to use simple and sharp Ruby tools to slice into large libraries with surgical precision. We'll do some live hacking on Rails on the stage and cover useful code probing techniques. Turn your impossible bugs into pull requests, and level up your programming skills by Dissecting Ruby with Ruby.
Explore tips to upgrade from each major version to the other, and how to efficiently tackle a 1.2 -> 4.0 upgrade through two different case studies.
The velocity of change for Rails versions has a side effect -- businesses hesitate to update to the latest version until their productivity drops and they're forced to update. What happens then? Let's explore a case study of a Rails app that followed this pattern.