Programming is hard, correct? Code, tests, design patterns, abstractions, deployments, are the things we do everyday and coding can be a craft; it takes skill, patience, perseverance and sometimes downright stubbornness, but what is the result of all that hard work? What are we striving to achieve?
As programmers we often talk at length about how to build things. Questions like, what is the right level of abstraction? what database should I use? where should I deploy? etc etc. Indeed there is complexity in the craft of programming and in answering those questions. By why do we ask them in the first place?
You build software, you've put in all that hard work, and now you've launched. Time to learn about what you really do for a living!
Rubygems.org provides every Rubyist with an amazing service: all the libraries in the Ruby world. As amazing as that is, installing gems can be a time-consuming and even error-prone process. (Just ask the Travis guys.) In this talk, you'll learn about the recent dramatic changes in Rubygems and Bundler to improve speed and reliability by rewriting the Rubygems client/server architecture. I'll show how the new system caches more information, makes fewer requests, and takes less time to install gems. Finally, I'll cover how the changes allow worldwide mirrors of rubygems.org, improving things for Rubyists around the globe.
Why this talk?
This talk exists primarily as a "State of the Gem Ecosystem Address", to tell everyone how things are going, what we've been working on, and why they should care. It also tries to point out the benefits that every Rubyist gets from the Ruby ecosystem, while gently letting them know that those things don't happen for free. Hopefully, by providing that information, we can ask people to contribute time and effort to improving things for everyone and sound like we are leading by example, rather than demanding that someone step up to solve the problems for us, already.
In Ruby 1.9 the MiniTest testing framework was introduced. This lightweight testing framework is fast, powerful, and easy to understand, yet so many people over look it.
In this talk we'll look at using MiniTest in a simple, non-Rails, project and then work up to using it in a Rails application. We'll look at both the TestUnit and RSpec style syntaxes that MiniTest offers. We'll also learn to write custom matchers, run specific files, and much more.
Testing is important to all Ruby developers, and with such a powerful testing library already bundled with Ruby, shouldn't we learn how to use it?
You may have this vague sense that you don't know Ruby as well as you think you do. And you worry that you're not learning and growing as a developer in your day job as much as you did when you first picked up Ruby. Perhaps you've lost that spark of excitement you experienced when you discovered new ways to solve problems with Ruby.
There is a way to re-invigorate your code and coding practices. Teach everything you know.
This talk will focus on some of the principals of teaching and why it can be an effective tool, not only for others to learn, but for you as the teacher to really deepen your knowledge of the subject. It will be specifically centred around using Ruby, and some of the ways I have discovered work well for teaching it as a first programming language.
What is common between Rails, Sinatra and numerous other Ruby frameworks?
They are built on top of Rack or have Rack interfaces for allowing application servers to connect to them.
A deep-dive of sorts on Rack and see what it takes to build a framework, helping us understand these better and ultimately rolling our own.
Almost anyone doing a Ruby app ends up using Rack in one way or the other without ever realising the magic and simplicity that it provides. This session should help decoding that and provide ways on writing your own frameworks.