Your current filters are…
by Jeff Casimir
We're facing a tidal wave of rescue projects. So many developers dive into writing Rails applications without building a real foundation in Ruby. Instead we focus on the new whiz-bang features of Rails or the hot gem of the week—missing the awesomeness right in front of us.
Let's talk about Ruby and fill in some of the gaps. This isn't about mind-blowing features and crazy metaprogramming, it's about the fundamentals that are often overlooked in Rails applications.
Master these techniques, and write better applications with better Ruby.
Let’s face it. CSS is dumb. There is no such thing as a DRY CSS file and stylesheets are often the biggest blemish in an otherwise beautifully coded app. Sass is the future of stylesheets. Rails 3.1 includes it by default and the W3C is adding concepts from Sass to CSS itself. This talk will cover the rationale behind Sass, the language features it provides, and best practices you can apply to start untangling your stylesheets. Chris Eppstein, the creator of Compass and Sass core team member will present.
by Ryan Dy
by Erica Kwan
I work for a mobile payments company called Square. Square has a great development culture driven by a lot of smart people. Part of that culture includes acknowledging failures, figuring out what should have been done differently when failures occur, and learning how to fail less in the future.
I'm going to discuss the mistakes made when developing a major Rails app feature, the struggle to increase test coverage for the Square iOS client, and the consequences of bad architectural decisions made when creating a distributed build system. I'll then talk about how each of these were addressed.
What's a Ruby conference without lightning talks? And more importantly, who would want to find out?
by Yehuda Katz
Framework development comes with a whole different set of tradeoffs than application development. While code in applications is usually in service of a consumer-facing feature, framework code is by definition used by other developers writing unknown code. That means a heightened focus on architecture, code reuse, and developer usability. That said, as applications grow in complexity, parts of the codebase end up looking a lot like frameworks, mostly servicing code written by the application developers.
In this talk, Yehuda will cover some of his principles for building friendly, usable frameworks, and talk about how you can apply them to your application codebase as it grows in complexity over time.
by Chris Strom
You package your assets. You use CSS sprites. You serve up everything with gzip compression. You obsess over Yslow recommendations. But you are still not SPDY.
Fundamental limitations in HTTP and TCP/IP still add up to 60% overhead to your site. Find out how to reclaim that lost bandwidth and increase the robustness of your sites at the same time.
Goliath is an open source, event-driven I/O framework, much like node.js or Tornado, except that Goliath is based on EventMachine, features a Ruby API, and most importantly, does away with the asynchronous "callback muck" by utilizing Ruby 1.9's Fibers to preserve the nice synchronous look-and-feel of your code—which makes it easier to write, test, and maintain.
In this talk we will first explore why Goliath was built, and why the combination of Ruby 1.9, Fibers, and an asynchronous event-loop is such a powerful combination. We will take a look under the hood and work through several "Hello World" examples: streaming uploads and responses, websockets, and the general async API use cases. Further, we'll take a brief look at lessons learned from production deployments and what we've discovered while building Goliath at PostRank.
16th–17th September 2011