Rails did a lot to bring REST to developers, but its conception leaves the REST devotee feeling a bit empty. "Where's the hypermedia?" she says. "REST isn't RPC," he may cry. "WTF??!?!" you may think. "I have it right there! resources :posts ! What more is there? RPC? Huh?"
In this talk, Steve will explain how to design your APIs so that they truly embrace the web and HTTP. Just as there's an impedance mismatch between our databases, our ORMs, and our models, there's an equal mismatch between our applications, our APIs, and our clients. Pros and cons of this approach will be discussed, as well as why we aren't building things this way yet.
So in this talk I'll demystify Backbone. I'll show several very different ways I've used it on real Rails apps. You'll get a feel for the circumstances when Backbone makes sense, and moreover, when each of the different approaches to Backbone make sense.
Many people know that machine learning techniques can facilitate learning from, and adapting to, noisy, real-world data, but aren't sure how to begin using them. Starting with two real-world examples, we will introduce you to some libraries that bring machine learning techniques to your Rails applications. We will then dive into the art of feature design, one of the first practical roadblocks that many people encounter when applying machine learning. Feature design is the challenging, subtle, and often trail-and-error process of selecting and transforming the data you provide for your learning algorithm, and it is often the hardest part of using these techniques. Our goal is for you to come out of this talk with the tools necessary to think about machine learning and how to apply it to your problems.
In this talk we start with the basic concepts of CoffeeScript and move on to the more powerful and fun features of the language. While we're looking at CoffeeScript we'll see how it relates to the Ruby code we write everyday. What do Ruby 1.9 lambdas and CoffeeScript functions have in common? Which of the two languages supports splats, default arguments, and ranges? The answers may surprise you.
It is no secret that location has become ubiquitous. Mobile GPS, available data sets, and easy-to-use mapping services have brought geospatial information within reach of web developers. Location already plays a significant role in many of the major services such as Twitter, Facebook, and Google, not to mention legions of startups.
However, for those of us implementing more than the most trivial features, it is also true that location is challenging. A significant learning curve awaits us, involving spatial databases, coordinate systems, interchange formats, and plenty of math. Our Ruby-based tools lag a bit behind those available to our Java- and Python-oriented colleagues, and effective documentation is scarce.
This presentation aims to jump-start Rails developers hoping to go beyond putting a few pushpins on a Google Map. Rather than spending a lot of time explaining the many concepts involved, we'll bypass the learning curve and jump straight into walking through code for a few nontrivial applications. The hope is that the conceptual knowledge will come naturally as a result of seeing it in action, but pointers to online resources will also be provided to fill in any gaps.
A thorough understanding of Ruby, Rails, ActiveRecord, and SQL will be assumed. No prior knowledge of GIS or computational geometry will be required, though it may be helpful.
This panel is made up of EY Support Engineers and Developers and they are ready to answer your questions! Want to know more about deploying to the cloud? What does PaaS mean to you? What is the EY Stack?
Most of us have been there. That website you want to use, from your mobile device, that just refuses to cooperate. From the Flash-only, to the can't f**king log in, to the redirect-to-mobile-and-stay-there sites, there's more than enough websites out there to invoke Mobile Rage.
Although we all know that the best mobile development strategy is "mobile-first", we also all know how many sites and applications out there were designed and built by people who didn't imagine how fast mobile would take over.
Come learn about the common mistakes most people make for mobile, and some of the simple solutions you can use to help reduce Mobile Rage, without having to do a complete rewrite.
Basics of Rails Engines
Rails Engine Patterns
Improved Productivity Tips
Summary of Benefits and Trade-Offs
Attendees should walk away with an overview of Rails Engines and guidelines on how to utilize them effectively.
Ever run into a really gnarly data problem and wished you had a do-over? Tired of wrestling with ActiveRecord to model a really complex domain? Looking for a good way to echo state changes to external systems? Then grab a cup of joe and settle in for a look at event-sourcing your data.
Event-sourced data uses Plain Old Ruby Objects (POROs) to model your data and exclusively uses events to mutate state on those objects. By serializing the events, the state of your data can be recreated for any point in time, and outside listeners can create specialized purposeful datastores of the data, enabling complex business requirements with fewer hassles. We'll also touch on other architectural patterns like DCI and CQRS that play well with this idea.
Have you ever wondered what makes Rails tick? Bryan Liles will cover two of the pillars of the Rails foundation: ActiveSupport and ActiveModel. Together we will discover where some of Rails’ ease and power originates and how make use of it in your projects.
Progressive Enhancement isn't important on the mobile web because it's all Webkit right? Not so fast. Even among Webkit implementations events, css, and performance vary widely. We'll talk about the darker corners of the mobile web and show how jQuery Mobile can help you build Rails applications that are reliable, accessible, and support more devices.
With more than a million user submitted recipes and an active user base of 15 million monthly unique users, cookpad.com is the world's largest recipe website, and an essential tool for the 50% of all Japanese women in their 20's and 30's who use the site regularly.
The Cookpad.com service is built on Rails and is running entirely on AWS in Tokyo, where more than 30 engineers are working in small agile teams to bring more value to users every day.
As you know, Japan had a huge earthquake and tsunami last year, and some of those affected didn't have cooking facilities, water or basic foods for long time. Many Cookpad users immediately uploaded simple recipes that could be made without the basics in adverse conditions, and helped those in hardship immensely allowing them to enjoy food with their families at that difficult time.
In this session, I'll talk about the COOKPAD way of creating services and the technologies behind them, and how we improve peoples lives through cooking every day.
StillAlive.com was born from the 48 hour intense 2010 Rails Rumble and has grown! Having recently passed our 50,000,000th site result, this talk discusses the real world challenges and optimisations required to take a code base born from the fires of YAGNI to a production system.
This talk isn't about how you can scale from 0 requests to 500 billion requests per microsecond, but give a practical view to some of the performance problems we faced as the application steadily grew from a hack job into a functioning system.
The journey will go through the mistakes we made, challenges faced and real world optimisations discovered, including some tricks we learnt along the way from concurrent index creation to using the ZeroMQ messaging framework with Rails
Based on Chapter 4 of the Ruby on Rails Tutorial by Michael Hartl, “Rails-flavored Ruby” covers the aspects of the Ruby programming language most important for developing Rails applications. Topics include hashes, arrays, and other objects; blocks; functions; and classes.
A glimpse of some of the features coming to Sass in the pending 3.2 release. Plus, a huge announcement about the project that's been months in the making as we have secretly toiled away on something that we think will be awesome. Hear it first at this talk. Repositories will be made public when the talk is over. Shh! Its a secret!
Over the past year, Heroku has expanded by going polyglot and supporting languages like Java, Clojure, Python, Node.js, and Scala in addition to Ruby. In this session, we will discuss major updates to the platform and our emphasis on making the Ruby developer experience even better. We'll leave plenty of time at the end for any questions.
As more people collaborate on the web with your applications, its not enough to just persist data to the database; it needs to be pushed out to your users web browsers so that they're always working with the freshest data.
In this session, Brad will show how to build a real-time layer on top of an existing Rails application's authorization and resource logic so that you can build on top of the hard work already invested in your Rails application.
Topics that will be discussed include:
Why I didn't choose Socket.IO
Stream application resources into Backbone.js models to keep data fresh
Hook into ActiveRecord to push representations of data into a message queue
Message queue naming conventions public/private resource streams
Exposing message queues to HTTP
Securing streams with existing application authorization logic
Considerations for streaming in a production environment
Rails makes it very easy to rapidly develop web applications, but doesn’t always make it so simple to deploy or secure them.
This talk is going to focus on best practices to secure your rails application, learnt through multiple high profile projects and penetration tests. The talk will be practical and show that this isn’t necessarily hard if thought about from the start.
We’ll also touch on getting the right balance of security without it getting in the way of the users.
Working with Rails often means switching between several Ruby versions back and forth which is made almost seamless by RVM. It also involves several simple command line tools like Pry, Guard, and Pow and that will make your development life so much easier.
Scopes are a great way of encapsulating query logic in a granular, reusable way. This talk will cover some techniques you can use to keep those scopes as composable and portable as possible. We’ll cover how to use Arel directly, while avoiding the common practice of using SQL fragments, and show you how this can make your scopes more reusable, while at the same time preventing you from using database vendor specific operators, such as ILIKE.
Rich Hickey, the author of Clojure and designer of Datomic, is a software developer with over 20 years of experience in various domains. Rich has worked on scheduling systems, broadcast automation, audio analysis and fingerprinting, database design, yield management, exit poll systems, and machine listening, in a variety of languages.
When he isn't ruining people's lives by writing software like phuby, enterprise, and neversaydie, Aaron can be found writing slightly more useful software like nokogiri. To keep up his Gameboy Lifestyle, Aaron spends his weekdays writing high quality software for ATTi. Be sure to catch him on Karaoke night, where you can watch him sing his favorite smooth rock hits of the 70's and early 80's.
There are many people in the Ruby/Rails world who contribute to our community and rarely receive any recognition or payment for their work.
They create educational content, develop plugins & gems, contribute to open source projects, and even put on events which help educate and make our lives as developers easier.
Ruby Heroes was created to show some gratitude and give these people the recognition they deserve. Hopefully the type of recognition that keeps them doing what they’re doing, and continuing to make our community stronger.
Are you having trouble launching new features because of friction between development and operations? At CustomInk, we've reduced this friction by making changes to our teams, processes, and tools. Come find out what we've been up to and learn how you can implement similar changes in your own environment.
There's always a bit of tension when getting features from idea to production. In this talk, we'll look at some of the changes CustomInk has made to reduce this friction and keep the new features coming. Gone are the days of bi-monthly deploys, office pools dedicated to guessing when this deploy will be rolled back, and the ceremony surrounding the deploy-rollback-fix-deploy cycle. Today, ideas flow from product managers to developers to production with ease thanks to a number of changes that we've made to our teams, processes and tools.
During this talk, we'll look at:
How product managers drive the release cycle
Ideas and customer feedback
Prioritizing development requests
Managing branch merges and deployments (yes, product managers can help here!)
How operations enables developer productivity
Spinning up development environments - Vagrant, Chef
Infrastructure Automation - Chef
Enabling Continuous Deployment - Capistrano and caphub
Failing gracefully - Fault-tolerant load balancing with ldirectord
How developers get their code running in production
Continuous Integration - Jenkins, Green Screen
Staying on topic: Deploying changes when they're ready
Getting rid of the over-the-wall mentality - Dev & Ops working together
Enabling developers to do it themselves
Pair programing infrastructure automation
Keeping the process light and the communication flowing
Presenter and Decorators are design approaches that can be used in Rails applications outside of the standard Models, Views and Controllers. These approaches are becoming more and more popular as teams search for new ways to identify and manage the complexity within their applications.
In this session Mike Moore will defined the Presenter and Decorator approaches using simple and clear terminology. Common design problems in Rails applications will be shown using real-life code examples and refactored toward Presenters and Decorators. Code will be improved and strengthened by identifying and respecting the dependencies within large applications.
Every young company expects to grow quickly, but is your engineering team really ready for it? In 3 years, iTriage went from a kitchen table to one of the leading mobile consumer healthcare apps with over 5 million downloads. Staying ahead of this growth didn't just mean hiring more Rails engineers.
Patrick will discuss what iTriage did (and continues to do) to stay ahead of our growth, including: - Technical architecture, including use of Rails Engines to enable a modular, RESTful service-based design - Enabling high quality iPhone, Android and Web apps - Development and release management processes - Recruiting and hiring approaches
I regularly write code that does something great but is slow as a dog. Denormalizing / pre-computing / backgrounding are all fine, but they're all an investment and they leave tentacles all through the code. I want to be able to try out slow but very useful code in my app without the friction of performance concerns, but also without worrying that my ops engineer is going to kill me in my sleep.
Wouldn't it be nice to add one line to our models that takes care of caching, cache keys, backgrounding, dog-piling, and cache warming? Oh, and it should give the UI clear consistent hooks so that it's clear whether the data is ready so the UI can render a spinner or disable a feature until the computation is complete.
We'll take a look at a series of techniques that we use at PatientsLikeMe to allow us to safely and quickly put some very expensive queries on the website so that we can evaluate whether it's worthwhile to create longer term solutions. The solution we've come up with is a lot of gloss over memcache and resque that makes it feel like we can memoize any method in our application and lets us focus on the goals of the algorithms rather than their performance and architecture.
This talk will feature: memcache, resque, a bit of metaprogramming, a look at caching in the wild and code that fixes some usual problems, and a fairly epic SQL query with some nice Postgres features you should know about.
You should come if: you want to take a look at some practical solutions that we use in production to be able to roll out computationally expensive features.
Google loves speed, and we want to make the entire web faster - yes, that includes your Rails app! We'll explore what we've learned from running our own services at scale, as well as cover the research, projects, and open sourced tools we've developed in the process.
We'll start at the top with website optimization best practices, take a look at what the browser and HTML5 can do for us, take a detour into the optimizations for the mobile web, and finally dive deep into the SPDY and TCP protocol optimizations.
We'll cover a lot of ground, so bring a coffee. By the end of the session, you should have a good checklist to help you optimize your own site.
Rails is so popular to be used to fast build a website, at the beginning we sometimes write codes too fast without considering code quality, but after your company grows fast, you have to pay more attentions on code review to make your website more robust and more maintainable.
In this talk I will introduce you a way to build a semi automatic code review process, in this process a tool will analyze the source codes of your rails project, then give you some suggestions to refactor your codes according to rails best practices. It can also check your codes according to your team's rails code guideline. So engineers can focus on implementation performance, scalability, etc. when they do code review.
This talk applies the concepts of chaos theory to software development using the Bak–Tang–Wiesenfeld sand pile model as the vehicle for exploration. The sand pile model, which is used to show how a complex system is attracted to living on the edge of chaos, will be used as a both a powerful metaphor and analogy for building software. Software, it turns out, has its own natural attraction to living in its own edge of chaos. In this talk, we'll explore what this means and entertain questions for what to do about it.
The speaker's hypothesis is that by understanding how complex systems work we can gain insights to better understand and improve the act of building software. By looking through the lens of the sand pile model we'll explore the following:
what the sand pile model can tell us about software development
how software is naturally attracted to its own chaos
the impacts on software living perpetually on the edge of chaos
how existing software practices can be used to detract software away from chaos
what this means not only for our software, but for our teams, and ourselves individually
This thought-provoking perspective will leave you with new ways to think about software. You’ll walk away having learned a little about chaos, complexity, and how they apply to software with a thought-provoking perspective and inspiration for thinking about software in new ways.
Schemaless database are a joy to use because they make it easy to iterate on your app, especially early on. And to be honest, the relational model isn't always the best fit for real-world evolving and messy data.
On the other hand, relational databases are proven, robust, and powerful. Also, over time as your data model stabilizes, the lack of well-defined schemas becomes painful.
We will explore the power of hstore and PLV8, explain how to use them in your project today, and examine their role in the future of data.
Rails is huge. Even if you have worked with it for a long time, it's unlikely that you have stumbled across everything yet.
Do you really know what all of the built-in Rake tasks do? Have you seen all of the methods ActiveSupport makes available to you? Are you aware of all the queries ActiveRecord is capable of?
In this talk, I'll dig into the extras of Rails and see if I can't turn up some features that you don't see all of the time, but that might just be handy to know about anyway. I'll make sure you come out of this able to impress your friends at the hackfest.
A recent report by Veracode (http://www.veracode.com/reports/index.html) found cross-site scripting in 68% of surveyed web applications and SQL injection in 32%, even though these are well-known, easily preventable, and easily detectable vulnerabilities. As applications grow larger, it becomes harder and harder to manually verify that every line of code is adhering to security guidelines - even given the built-in protection available with Ruby on Rails.
Brakeman (http://brakemanscanner.org/) is an open source static analysis tool which provides painless vulnerability scans of Rails code from "rails new" through deployment. Running Brakeman as a part of continuous integration provides feedback during all stages of development and can alert developers immediately when a potential vulnerability is introduced. Bringing security testing as close to the developer as possible (even scanning as files are saved) means security problems are caught faster - and the sooner problems are found the cheaper they are to fix.
As a static analysis tool, Brakeman can be run without worrying about deploying the whole application stack: no webserver, database, configuration, or application dependencies required - not even Rails itself. This allows fast, easy vulnerability scans on any Rails project.
We talk a lot about testing in the Ruby and Rails community, but somehow security testing is passed over. This needs to change!
This talk will cover how to incorporate Brakeman into Rails development and how it can improve application security, as well as a look into how Brakeman works internally.
Ruby on Rails claims to be "optimized for programmer happiness and sustainable productivity." I strongly disagree with the latter assertion. In this talk I will channel my half decade of industry Rails experience into expounding this position and providing constructive feedback as to what needs to change---in both the framework and the community---before we can support this claim. I'll also cover practical techniques you can use to be sustainably productive on your own projects in the meantime.
Anyone who develops with Rails uses the Rake tool all the time. Rake will run your tests, migrate your database, and precompile your assets. But did you know you can define and build your own Rake tasks? This short talk will cover the basics of using Rake and writing simple automation tasks to make your development process smother.
Rails 3 and above includes a powerful instrumentation system, ActiveSupport::Notifications, which can be used to track performance and event information for all aspects of your application. Notifications are light-weight, easy to setup, and can be consumed by multiple subscribers (logs, audit trails, consolidated metrics, other parts of your application).
In this session we’ll start with the basics of ActiveSupport::Notifications and work our way to powerful advanced use cases. Topics we’ll explore include:
How to set up and use notifications
Logging what you want from any tier of your system
How to capture and aggregate performance/business data for the metrics you care about most
Conditional monitoring in production: flag on and off data by system or customer to get to the root of problems more quickly
Using ActiveSupport::Notifications in non-Rails applications and your own libraries
While Node.js is the hot new kid on the block, evented libraries like EventMachine for Ruby and Twisted for Python have existed for a long time. When does it make sense to use one over the other? What are the advantages and disadvantages to using node over ruby? In this talk, you will learn how to get the same power of concurrency enjoyed by Node.js while continuing to write in the language you know and love. Topics covered will include pubsub with redis or faye, building evented rack applications, and running evented applications alongside existing Rails apps.
There’s no need to reinvent the wheel. There are over 30,000 RubyGems available on just RubyGems.org, alone. But with so many out there, it must be impossible to find the right one, right? In this talk we’ll learn about some resources which help you find the right gems, as well as how to intelligently decide if a library is right for your project.
Rails got much more modular after 3.0 rewrite. But do you know how to use specific rails elements outside Rails? What if you would like to use ActionView with some other library (like webmachine)? Have you ever needed to render view with layouts outside of the rails stack? Or maybe you wanted to build some kind of system that fetches templates from database rather than from files? Router anyone? You know that you can use it outside rails too?
In this talk I will dive into Rails internals and will show you what's there and how you can use it outside rails.
Although I will focus on using those parts standalone, this knowledge will most likely help you also build your apps if you ever need something sophisticated that requires modification of regular rails behavior.
"Stack Smashing" refers to an internal project where I took our production Rails application environment down from over 100 virtual machines to 2 physical machines. Our application environment for Major League Gaming consists of 13+ inter-connected applications with millions of users to provide functionality such as single-sign on, online video (both video on demand and UGC), news and live competition information, photo galleries, profiles, and much more. We simply needed a simpler infrastructure in which to develop and deploy our applications. In this talk, we will cover the following:
Network topology before and after, as well as the makeup of our virtual and physical machines.
Detailed discussion of Chef recipes, NGINX, HAProxy configurations and updates to standard configurations.
Application and service monitoring and configuration.
Application migration from the old stack to the new stack.
Rails 3 to Rails 3.1 upgrade insights.
Strategies for service configuration to handle failure.
Offline processing with queueing and queue management.
Simplifying, standardizing and sexy-fying your Capistrano-based deployment tasks into a reusable gem.
Behavior driven infrastructure monitoring and validation.
Adopting an opt-in continuous deployment strategy that is integrated with our continuous integration environment.
This will be a very code and example-focused talk. Come and learn about the ways that you can simplify your existing infrastructure.
What does it take to deploy an application without any downtime?
More than most Ruby developers would expect, turns out; what is aggravated by the lack of documentation and other resources on this topic.
In this talk we'll dive into both development practices (hot compatibility, database migrations, caching) and deployment setup (Heroku, Unicorn, HAProxy), covering everything you need to know in order to ship code without affecting a single customer.
Building safe web applications isn’t always easy. The good news is that Rails provides a lot of features that will help you along the way. Aaron will walk you through the common mistakes made by web developers, and how to account for them while working with Rails. He will also walk you through some tools you can use to make securing your applications much much easier.
Although XMPP is most often used as a chat protocol, it can also provide a robust asynchronous communication channel in other application scenarios. In this presentation, we will provide introduction to Strophe.js, XMPP4R, and ejabberd, which are the XMPP components that we use to integrate our device automation framework and living room devices under test. By using these off-the-shelf components, we addressed our needs for getting around internal firewalls, application security (based on SASL), and asynchronous command-response handling.
In this talk we will explore the best practices in using interfaces as the foundation for designing object oriented applications in Ruby and Rails. We will talk about some of the techniques that make it possible to write loosely coupled components that can be easily extended to respond to requirement changes.
David Cohen is the founder and CEO of TechStars. Previously, David was a founder of several software and web technology companies. He was the founder and CTO of Pinpoint Technologies which was acquired by ZOLL Medical Corporation (NASDAQ: ZOLL) in 1999. You can read about it in No Vision, All Drive [Amazon]. David was also the founder and CEO of earFeeder.com, a music service which was sold to SonicSwap.com in 2006. He also had what he likes to think of as a "graceful failure" in between.
David is a active startup advocate, advisor, board member, and technology advisor who comments on these topics on his blog at DavidGCohen.com. He recently co-authored Do More Faster with Brad Feld. He is also very active at the University of Colorado, serving as a member of the Board of Advisors of the Computer Science Department, the Entrepreneurial Advisory Board at Silicon Flatirons, and the Board of Advisors of the Deming Center Venture Fund. He is a member of the selection committee for Venture Capital in the Rockies, and runs the Colorado chapter of the Open Angel Forum. His hobbies are technology, software/web startups, business history, and tennis. He is married to the coolest girl he's ever met and has three amazing kids who always seem to be teaching him something new.
Ruby's favorite podcast comes to RailsConf! Join the Ruby Rogues (David Brady, James Edward Gray II, Avdi Grimm, Josh Susser, and Charles Max Wood) for this live episode on What Rails Developers Should Care About.
If you've listened to the show, you probably know that the Rogues favor:
Good Object Oriented design
Test Driven Development
The Law of Demeter and Tell, Don't Ask
Scaling performant code
Since this is a live episode, we want to interact with the audience. Each Rogue will give a brief introduction on what's important to him as a Rubyist on Rails, then we will turn the session over to your questions. We will take them over the Internet and/or live, before and during the show.
In the 21st century successful teams are data-driven. We’ll present a complete introduction to everything you need to start monitoring your service at every level from business drivers to per-request metrics in Rails/Rack, down to server memory/cpu. Provides a high-level overview of the fundamental components that comprise a holistic monitoring system and then drills into real-world examples with tools like ActiveSupport::Notifications, statsd/rack-statsd, and CollectD. Also covers best practices for active alerting on custom monitoring data.
When Ruby on Rails burst onto the scene in 2004, it excited web developers by showing that you could build next generation apps quickly and efficiently. Rails was one of the first frameworks to embrace Ajax, giving everyone the power to do partial page updates and whiz-bang effects in a conventional, effortless way.
In 2007, the Rails team embraced RESTful conventions, making API development a no-brainer for new applications. Because RESTful JSON is so easy in Rails, Rails applications tend to implement APIs on balance.
Then it was time to polish. Both the 2.0 and 3.0 releases cleaned up the code-base and found ways to take emerging conventions and make them easier to use.
But now, like in 2004, another revolution is brewing. Increasingly, developers are moving their view layer from the server into the client, using RESTful JSON and client-side templating to increase responsiveness and bring applicable aspects of desktop applications to the web.
Like last time, not every application needs to jump head-first into this new world. But just as in 2004, Rails has an opportunity to embrace the future, and bring its ruthless insistence on convention over configuration to bear on this problem.
Rails already has the plumbing to be a fantastic conventional JSON server. The question is: will we take the challenge, or will we desperately cling to the past, hoping that the future will never come?
Redis is a darling of the NoSQL crowd and for good reasons. It's easy to setup and has blazing fast performance. In this talk, drawn on real production experience and real code straight out of the DueProps codebase, Obie will introduce and demonstrate key Redis application patterns vital to today's Rails developer. Emphasis will be placed on real-world constraints and how to leverage Redis to improve scaling and performance over plain-vanilla ActiveRecord applications.
Concepts covered: * Adding Redis-based flags and other properties to ActiveRecord objects * Event tracking with Redis sets * Graphing relationships between (User) objects with Redis sets * Time-ordered activity feeds with Redis sorted sets * Applying security restrictions to display of activity feeds with intersection of Redis sorted sets * Aggregating group activity feeds with union of Redis sorted sets * Applying Redis sorted sets to scoring and leaderboard programming * Integrating Redis with Rspec and Cucumber * Debugging tactics for when things go wrong or are unclear
Chanko provides a simple framework for rapidly and safely prototyping new features in your production Rails app, and exposing these prototypes to specified segments of your user base.
With Chanko, you can release many concurrent features and independently manage which users see them. If there are errors with any chanko, it will be automatially removed, without impacting your site.
Chanko was extracted from Cookpad.com where the team uses it daily to test new features live, in production, on the largest Rails site in Japan which serves 500 million page views a month to a user based of over 15 million highly engaged uses.
This talk will explore the story of Ezra's travels through the history of ancient Rails 0.6 when he first picked it up in 2004 all the way through current times and extrapolate out to the future of the Rails and Ruby platform and how much of a success it has been. We will talk about the twisting path from way back then to now and beyond and explore what Rails was, is and will be as time keeps on slipping into the future.
This talk will be chock full of aqdvancxed tech as well as ramblings of a Rails industry Vet who has been "On the Rails" for 8 long years now and has played a major part in shaping what has been, is and will be(at least in his own mind where he is absolutely a legend, in reality he's just a schmuck who hacks ruby)
I want to share with the Rails community my story and experiences and hopefully impart some wisdom and some hard learned lessons about life, liberty and the pursuit of a rails app that doesn't use 400Mb of RAM per process ;)
Heard about the big Basecamp launch this March? Wondering what's new, how it's shaping Rails, and the tech behind it? We're going to go over some the practices and patterns in the new Basecamp's code base and you can learn how to improve your app with them.
Some of what we'll go over:
Employing concerns to share code across models/controllers
Stacker, the CoffeeScript component behind the "page" based layout
Why polling for updates still works at scale
Client side testing without the hassle
Using jbuilder to keep view data out of models
Keeping your team's sanity with a single setup script
How to keep your app alive even if external dependencies like Redis are down
Why tagged request logging and action/controller SQL query logging can make finding bugs easier
Even the simplest of Rails applications can eventually grow into a twisted mess of complexity. At some point you will need a background task, or a long-running service, or a scheduled job, or all of the above and more. All of these little bits of functionality added to an application ad hoc can keep you up at night with cold sweats and nightmares. But it doesn't have to be that way.
In this presentation, we will examine a complex Rails application - complexity that is eventually common to most modern Rails apps: background tasks, scheduled jobs, WebSockets, long-running services, caching and more. We will look at the challenges inherent in these features for both development and deployment. Then we'll look to TorqueBox for simple solutions to these complex problems. You'll never have that long-runing service using the wrong Ruby code again; no more environment variable nightmares in your cron jobs. You can sleep better now.
TorqueBox is a Ruby application server that is built on JRuby and JBoss AS7. It provides asynchronous messaging, scheduled jobs, long-running processes, caching, simple deployment, and much more. TorqueBox is designed to bring the power, scalability and stability of these time-tested JavaEE services to Ruby applications through a simple and expressive Ruby interface.
You know 'em, you love 'em -- five-minute talks by attendees on topics that they're passionate about. Hosted by Dr. Nic Williams, presentations in part 1 are:
* Dr. Nic Williams - Introduction
* Dan Hassin - Objective-C and Rails
* - Wind Tunnel
* Tony Arcieri - Threadsafe on!
* Jim Remsik Jr - Tenderlove.dup
* John Krueger - Json + Webworkers = Win!
* Amanda Wagener - iwanttolearnruby.com
* Mark Simonoan - what private teams can learn from open source
* Jesse Wolgamott - sidekiq-in-1-minute
* Akira Matsuda - Modeling on Rails
* Jonathan Wallace - RO - Results Oriented
* Jason Lewis and Micah Gates - gem install job_interview
MiniTest is the no-nonsense testing framework you already know how to use. If we strive for cleaner and simpler code in our own work, wouldn't it be nice to have that in our test framework too? Whether you're a Test Unit fan or RSpec fan, you'll feel right at home using MiniTest. Its simplicity makes it fast, easy to use, extendable, and maybe most importantly, easy to understand. Plus, Rails 4 uses MiniTest.
Other programming languages have powerful features that are often enviable while working in Ruby: Python’s function decorators, Scala’s partial evaluation, and Haskell’s lazy evaluation, among others. Fortunately, Ruby’s metaprogramming facilities give us the ability to add these features to Ruby ourselves, without the need for the core language to be changed.
This talk will walk through adding simple (yet functional) versions of the previously mentioned features to Ruby, using Ruby, and discuss the dos and don’ts of responsible Ruby metaprogramming.
Unless you have been living under a rock for the past year you might know of Travis CI, the continuous integration service for the open source community.
Travis started as a single GitHub project which was a rails app and a resque background task. Compare that to 12 months later where Travis is now four separate deployable apps, uses two different rubies (1.9.2 and jruby), and comprises a total of 10 GitHub projects.
Apart from looking at how Travis works now, we will also look at how it got there, and how we broke Travis up into smaller more manageable, more concise encapsulated services.
There’s all kinds of discussion on how to make test processes work, and how to make tests fast, but it sometimes seems like there’s not much discussion on how to make tests useful. What makes a BDD test valuable, in that it will save more time that it will cost in maintenance? I’ll claim that there are five things that you should look for in your tests: independence, repeatability, clarity, conciseness, and robustness. These features will make the tests easier to write, easier to verify, and easier to keep consistent as your application becomes more complicated. You’ll leave this talk ready and able to write great tests.
“A testing tool by any other other name would assert as truthy.” – some guy. You’ve seen Rails’ built-in Test::Unit in the morning session. This afternoon, we’ll introduce RSpec, another popular testing tool. We’ll overview basic structure, contexts, “should” expectations, mocking and stubbing. We’ll also cover Rails model, view, controller, routing, helper, and request specs.