When you type “cap deploy”, “ey deploy”, or “git push heroku master” your intent is to deploy your local application source to your running system on the Internet. That seems to be the point - you changed your code, and you want to Just Ship It. But what is your actual objective? Is it really to just “deploy app code changes”? Is this “app-centric” view and user experience satisfactory?
Code deployment is your intent on some occasions. On others you want to change your product
In the early days of a project, Rails absolutely dazzles.
Tragically, the very same forces that make it so easy to add new features to a brand new Rails application are the ones that start to hold you back as the number of features grows.
Your test suite gets slower and slower, and refactoring becomes more and more of a chore. Everything seems coupled together, and it's hard to see much of a structure other than the MVC triad.
In this talk, Matt explains why this happens, and shows you a way out, using a ports-and-adapters or hexagonal architecture to introduce a separation between your application's domain logic, and the Rails framework.
With practical examples, you'll learn how to apply techniques like:
This talk is suitable for advanced Rubyists who want to enjoy the benefits of Ruby's great Object-Oriented and functional programming features in their Rails applications.
In this talk we will build a face detection and recognition app all in Ruby with the power of MacRuby... in 10 minutes! The purpose of this talk is to demonstrate how one can take advantage of Apple API's and Ruby tools to quickly build powerful desktop applications.
In this talk, I'll dig into how this type of caching allows us to cache far less data than traditional methods, invalidate fewer records, improve our cache hit rates, and scale to hundreds of thousands of memcache of requests per second with a 98% cache hit rate - all while showing users data differently based on perspective.
In this micro talk, I'll review the basic theory behind hash functions and hash tables, show you the new internal data structures that Ruby 2.0 uses to save keys and values, and present some performance data that proves this optimization exists and how much time it will actually save you.
Most Ruby programmers spend significant time writing, maintaining and troubleshooting automated tests. While recent discussions in the Ruby community have focused on whether we're writing too few or too many tests, this talk looks at how we can write "sensible" tests that allow our applications to deliver the most possible value with the least amount of development time and effort.
This talk is a sequel to the talk David gave at RubyConf 2010, and will focus on refactorings that we rely on to reduce duplication, and their implications, both positive and negative.
Here's the quick story of what's worked, what hasn't, and the lessons learned as we try to solve the developer shortage.
We'll take a Grape API from zero to cache in 10-minutes. This cookbook includes support for ETags, handling relational data, 304s, etc., based on several months of incremental development at Art.sy.
How to build your own online maps and free yourself from Google Maps limitations and fees.
In this talk we will cover the "hidden" features of Rake that are not typically used by the casual Rake user. We will learn about the convenience of file lists, dynamic generation of tasks, rule based file generation and more.