Forget about JRuby. MacRuby? Forget it. Forget even Rubinius. As cool as each of them is, they are old. Like, you know, for adults. Introducing the real future of Ruby: KidsRubyâ€¦ because the future is about the kids!
KidsRuby was born as a fresh approach to the most important problem we as an industry face: who is going to maintain our code in its old age? Most of us in the Ruby community are aware that it is a great time to be a programmer. However, it's not so great to be some company trying to find an experienced programmer to hire. And the problem is only going to get worse, since the state of computer programming education is the US and UK is down, even as demand increases. Like becoming a master musician, master programmers are not created quickly. Many of the best programmers today started when they were young. There have been a number of excellent contributions for teaching kids to program using Ruby. The most famous Ruby environment for kids being Hackety-Hack, from _why the lucky stiff. However Hackety-Hack is showing its age and inherent limitations, especially if you want to use it with any normal gems, or want to contribute to it. Even the 1.0 release suffers from these problems. KidsRuby is a real Ruby, so that kids are not treated like second class citizens just because they are learning Ruby. It helps to solve a number of the biggest technical problems with teaching Ruby to kids. In 30 minutes I will share not just the technology used to build KidsRuby, but more importantly the social glue needed to help start out the next generation of programmers with the language we all love. It it time for a general call to arms to the Ruby community. We all need to get serious now about training the next generation of hackers. After all, think of the children!
Rubyists love testing, and test-driven-development is becoming the way to write code. But, do we do this with our command-line tools? How do you write a test that your awesome application cleans up its temp files? How does one make a failing test for a missing command-line option? What's the easiest way to check our app's exit codes?
This talk will answer these questions with some real-world examples. We'll talk briefly about the challenges particular to testing command-line apps, and then dive into some code where we'll show off techniques for organizing code for testability, tools for interacting with the filesystem, and how to create full-blown acceptance tests for your command-line app. In no time, you'll be able to write your command-line apps the same way you write your other code: test-first.
There are lots of reasons to understand distributed systems. Among them are the facts that the principles can improve your site's availability, performance, and even maintainability. We'll talk about principles, patterns, and pitfalls to watch out for when writing your first distributed system.
Interfaces are not created equal. Upon reaching the summit of a releasable product it is easy to lose sight of where you started. The disconnect grows as you explore how to build a bridge from internals to end users. Developing interfaces for others is one of the hardest things we do, but thankfully you are not alone. I have spent the last two years interacting with and creating interfaces to cloud services with fog. By exploring examples we can see patterns and establish best practices for APIs, CLIs and even library code.
Look at your Rails unit test suite. Now look at mine. Now look at yours again. Mine are sub-second. Yours aren't. Having a slow unit test suite can hinder an effective test-first or test-driven approach to development. As you add tests, the suite starts to slow down to the point where you stop running them after each change. Some people even talk about multi-minute unit tests suites! Band-aids like spork are just covering up the problem. Test-driven development is a major player in keeping your design malleable and accepting of new features, but when you stop paying attention to the messages your tests are sending you, you lose this benefit.
In this talk, I will go over some techniques for keeping your test suite lean and fast. Along the way, we'll discuss the design improvements that come out of these changes.
Now, look at my unit test suite again. Yours can be like mine.
CouchDB is an increasingly common member of the Ruby developerâ€™s toolset. Its flexible model, low footprint, REST interface, and wide library support make it a natural choice for many web, mobile, command-line, and desktop Ruby apps. As community manager at Cloudant, I can tell you that Ruby is the #1 language customers use to access our CouchDB hosting service. But unfortunately, itâ€™s also the language where I have observed the highest levels of egregious misuse. Out of the hundreds of Ruby production apps that use our service daily, an overwhelming majority are plagued by poor design, wasteful queries or inefficient indexing; and as a result, the average response time for our entire Ruby userbase is 2â€“3x higher than in other languages.
Beyond plain misuse, I have also noticed a rampant and severe underutilization of CouchDB; in most cases, it's dropped in as a replacement for MySQL and used in the exact same pattern you would a single-instance, relational database. CouchDB has much more to offer, and by leveraging some parts of its design, I believe it can help the average Rubyist solve very common pain-points or serve very common use-cases, from embedded Ruby apps, to mobile applications and of course, web services.
This talk will explain the best practices that I've observed, tried and implemented, from a large pool of examples that includes the customer apps I've helped optimize and debug, as well as my own. Due to the necessity of re-explaining some core CouchDB concepts, this talk may function as an introduction to CouchDB, but will also contain valuable lessons for the more experienced user
In this talk, JosÃ© Valim will share what he has learned about Ruby through writing a small programming language. He will discuss the basic structure of a programming language, suggest improvements and debate about Ruby's parser, object model, methods, iterators and blocks.
The Go programming language, invented at Google, brings a novel new approach to parallel programming. With a strong focus on developer productivity and software readability, Go shares a lot of design philosophy with Ruby while targeting a different set of problems. Though the use of new language primitives, goroutines and channels, Go applications can solve programs in a highly parallel fashion without the use of locks.
This talk introduces the Go programming language, discusses the innovative parts of the language's design, and demonstrates how these concepts can be applied to Ruby.
Programming languages must be implemented in Java or C, everybody knows this. Sure, a prototype in Ruby, but that would be unusable. After all, Ruby is made for web development, right? Hard tasks, like implementing a compiler, have to happen in far more manly languages. But wait, the Rubinius compiler is written completely in Ruby, and it seems to get pretty decent performance, maybe we can use that.
In this talk, we will explore the possibilities of using the Rubinius compiler tool chain to implement our own programming language targeting the Rubinius VM. We get all the hard work that went into Rubinius for free and above all, can do the heavy lifting in Ruby, everyone's favorite programming language.
As an example we'll use Reak, a Smalltalk implementation running on Rubinius.
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.
* WTF are modules, anyway?
* Writing utility objects
* Measuring performance
* Everything worth manipulating is a collection
* Rails "features" that Ruby does better
* Bringing science back into development
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.
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?
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.
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.