Your current filters are…
by Adam Hawkins
Caching in rails is complicated. There is: Page caching, action caching, fragment caching, low level caching, and HTTP caching. This talk will guide you through basics and best practices of each. Caching is extremely important your app's performance so this talk will help you get it right. It will cover:
by Ro Samour
“Reality is a graph, embrace it!” Sure graph databases are really cool and have a timestamp dated next week, but do you know when you should actually use one? Sometimes living on the bleeding edge pays off and in this talk, I'll show you how you can simplify your application and model your data more naturally with a graph database. They are suited towards a specific problem that is actually quite common in today's applications and they may even apply to that thing you'll be working on during this talk!
I will use Neo4j to demonstrate how to model graph data and integrate it with Rails. We'll start with the basics of graph databases, go over working in a polyglot environment, and get started on our first Rails app using Neo4j. The tools and practices learned here will not only dazzle your boss but make your life easier when you introduce a graph database to your application back home.
Much has been said about LivingSocial's Hungry Academy by the people running it, this is the perspective of two graduates.
We started in Hungry Academy in March with almost no programming experience. We learned an incredible amount during the five months of the program, not just about Ruby and Rails, but also about what it means to be a developer and an active member of the open source community.
We'll discuss some of the highs and lows of our experience in Hungry Academy:
Despite a few rough patches, which are to be expected during a program as new, unique, and innovative as this one, we consider Hungry Academy to be one of the best experiences of our collective lives.
by Danish Khan
Ruby is now 18 years old. It has become a very mature project and the developers that have been using it are a lot more mature now as well. Our community has long since crossed the chasm and we are in the early majority stage. This means that even though we have many people who are well versed in the language we are again having an influx of new people.
I want to help those new people feel comfortable enough to believe they can learn and become just as mature as the oldies who are part of the community. Also, I want to educate the oldies on how they can better help out these newbies.
The Ruby community has become very much like any other close-knit community. We are very biased towards certain philosophies such as agile development, pair programming, and TDD. Some might compare our community to other close-knit organizations such as fraternities/sororities, athletic clubs and the freemasons. They all have very idealistic philosophies they run their organizations on.
I want to show how we compare to these types of organizations. I want to highlight the good things we adopted from running our community this way as well as the bad. I want to show how we can improve and fix the bad habits so that we can create a more open community for new people to join and feel welcomed.
Developers are a unique breed of people. We're highly intelligent, creative, problem solvers who have a unique and powerful set of skills. We are often passionate, determined and confident and we love challenges. But we can also be obsessive, difficult to manage and perfectionists. We can get caught up in solving problems that distract us from what we should be doing. We can be isolated and insular.
This presentation will look at who we are as developers and how to get the most from our unique skills. We will look at the areas that we can be weak in, and how we can avoid pitfalls of those areas. We will also look at how we differ from designers, managers, marketers and other types of people we may work with, and how we can work best with them.
This will be an interactive presentation where we build a picture of the average developer in the room.
We will look at:
by Terence Lee
Resque has been plagued by issues over the past half a year due to inactivity on the project. For instance, resque doesn't handle the cleaning up workers on distributed systems like Heroku. This issue (#319) has been open for over a year. redis.rb 3.0.0 came out on May 23rd which brings improved performance and backward incompatible changes. Also due to this inactivity, other queueing libraries like Sidekiq have come up to fill the void with new features.
This talk will journey through the takeover of Resque and the balancing act of solving the old bugs while moving the project forward. On the topic of old bugs, we'll cover the challenges of getting a stale project in order and into a solid state. Next up will be the work on Resque 2. Rails 4 introduces ActiveQueue and Resque is going to be a first class citizen in the Rails Queueing ecosystem. In order for this to happen, there will be a new Queue interface similar to stdlib's Queue class. We'll walk through reworking the Worker class so it supports both the current jailboxed Forked Consumer as well as a Threaded Consumer for heavy I/O jobs. We'll close with how the community can help with making Resque one of the best queueing libraries for Ruby.
by Katrina Owen
Enter deadline center stage, exit best practices, quietly, rear stage left.
The results are rarely pretty.
Refactoring can pry panic’s fingers away from your poor, overburdened adrenal glands and restore your sanity. Not that it went missing, of course. Never that!
This talk will cover the two reasons why refactoring works as well as (or better than) whiskey, sky diving, and massages as therapy, explore a handful of effective strategies to ensure that the rubber meets the road, and contains gory before shots and slick after shots of ruby code that has served therapeutic purpose.
by Mike Burns
Object-oriented Ruby is a hot topic in the Rails world and beyond, but it is not always the appropriate solution.
In this talk I discuss various OO techniques, when to use them, and when a simpler pattern exists in the functional, declarative, or procedural world — including, yes, the Rails framework itself. You will leave knowing when to use an aspect instead of a decorator, a mixin instead of a presenter, or a monoid instead of a factory.
Topics will include:
by Jim Weirich
20th–21st September 2012