Ruby is almost synonymous with Open Source thanks to an amazing community. Managing a successful Open Source project requires maintaining a careful balance of pragmatism, exuberance, and patience.
As soon as you have your first contributor you have to begin to think about how to manage not just the code but also the people. There are no org charts or managers to lean on for assistance; you have to figure out how to keep your contributors happy and on the right path. The tone you set for your project early on will stick with it for a very long time, so it's important to be sure you're the one setting it rather than allowing it to happen outside your control.
Evan will discuss managing a project as well as how contributors can make life easier for fellow developers.
Are you confident that your code works the way you expect? Is it easy to change? Do you get accurate feedback when you do change it? If the answer to any of these questions is no, the problem is not your code: it's your tests.
We'll look at the state-of-the-art Ruby testing libraries and frameworks to start you off with an effective testing toolset. In addition to the toolset, we'll also explore the testing mindset. Should I mock this or stub it? Should I write a unit test or an integration test? How do I write tests that allow me to refactor with confidence? If you've ever asked yourself questions like these, this session is for you.
Intended for new testers; those who "just don't get this testing thing;" people with brittle, unwieldy test suites they need to work into shape; and everyone in between.
I secretly think that NoSQL data stores are rabbits. They're breeding under the floorboards when we're asleep. How else do you explain a landscape that includes Redis, Riak, CouchDB, Tokyo Cabinet, Flock, MongoDB, and Cassandra, among many others? Mopsy and Cottontail can't be far behind.
Given this, picking the right rabâ€¦ er, data store for your project can be a challenge. There are lots of factors to consider, such as tail fluffiness, consistency guarantees, replication strategies, and ear length.
But the Ruby API for the data store is important too. That's what you'll be dealing with day in and day out once you make your choice. If you can't stand the interface, you'll get sick of cleaning the cage pretty quickly.
In this talk, I'll run you through the mechanics of accessing several NoSQL data stores with Ruby. I promise not to bring a rabbit to the conference, and I definitely won't bring two. The last thing we need is more.
A radically new relationship between developers and our government is taking shape. All levels of governmentâ€”federal agencies, states, and citiesâ€”have begun opening their vast troves of data to citizens, free of charge and license.
It started small, but as inspired citizens, including many Ruby developers, have taken government data and created awesome apps, more and more governments have taken the leap to give their data away. Some have even started collaborating with citizens and creating new government services that never existed before.
It's a historic and powerful opportunity for us as Ruby developers, and we need to take advantage of it. This talk is about why you should care, what your fellow developers have been doing so far, and what you might do yourself.
Rails 3 has added quite a number of new ways to extend the framework. These include swapping in a new ORM that still works cleanly with ActionPack, a brand new instrumentation system, and ways to build custom controllers, mixing and matching the pieces that you want. In this talk, Yehuda will give an overview of these new systems, and show some real-world examples of using them in plugins and in your application itself. He will also talk about how to think about using the new Rails architecture to streamline your stack for performance-critical parts of your app, without losing the integration you've come to expect or the features you absolutely need in those cases.
Imagine you are at a conference. Imagine while you are at the conference, there are 30-minute sessions of various Ruby related topics. Imagine Bryan Liles is at this same conference. Imagine Bryan Liles. Imagine ActiveModel. Imagine Bryan Liles talking about ActiveModel. Can you imagine anything better? Maybe vanilla ice cream on apple pie. As a close second place, Bryan will show you why you need to at least investigate ActiveModel for your current or next project. Of course there will be tests, code, and more tests at Bryan's ActiveModel Extravaganza.
In this session, I will discuss why ActiveModel could be a great interface to allow Rails to get access to your data on your own terms. I'll start from the beginning, and using TDD, I'll explore the interfaces Rails 3 exposes in their API. Next, I'll explore the components of ActiveModel. Finally, I'll show you how I'm using ActiveModel right now, and give you a real-world war report. I repeat: There will be code.
In any discussion on how to improve your programming skills, one book gets more recommendations than any other: The Structure and Interpretation of Computer Programs (SICP) by Abelson and Sussman. SICP was the introductory computer science text at MIT for many years. But how much could a professional developer really learn from a first year CS book?
Last fall I embarked on an adventure and invited folks to join me in a weekly study of SICP. We worked the examples and compared our answers. I am here today to share what mind-blowing concepts we discovered in just the first two chapters of SICP. Expect to see some Ruby code like you've never seen before.
Modern acceptance testing frameworks like Cucumber express tests in natural language, enabling organizations to establish their own Domain Specific Languages (DSLs). This powerful capability is a huge boon for communication: technical team members and non-technical business stakeholders can use the same vocabulary in expressing both requirements and tests. However, just creating a DSL does not ensure we will write good, clear tests. Indeed, it is all too easy to create acceptance tests that contain so many extraneous details that the real intentions behind the tests are obfuscated. In this session, Elisabeth will demonstrate how to edit technically correct but verbose Cucumber tests to increase clarity, reduce extraneous distracting details, and improve maintainability. Along the way we'll see how paying attention to the advice in Elements of Style applies to writing better automated acceptance tests. Strunk and White would be proud.
Machine learning is a discipline that is concerned with the design and development of algorithms that allow computers to evolve behaviors based on empirical data â€” a fancy name for a simple concept. Behind all the buzzword algorithms such as Decision Trees, Singular Value Decomposition, Bayes and Support Vector Machines lie the simple observations and principles that make them tick. In this presentation, we will take a ground-up look at how they work (in practical terms), why they work, and how you can apply them in Ruby for fun and profit.
No prior knowledge required. We will take a quick look at the foundations (representing and modeling knowledge, compression, and inference), and build up to simple but powerful examples such as clustering, recommendations, and classification â€” all in 30 minutes or less, believe it or not.
The Rails revolution, and Ruby along with it, began in the loud public echosphere of startup companies. The arrival of the Rails framework and the "Web 2.0" explosion created a very thunderous effect. Magazine after magazine reported on Rails. All the hip, funded and loud startups were using Rails to build their wares. It became a thing that VCs would assume you were using, and if not, why? The first RailsConf was 90% attended by startups. Rails was a revolution. Since then the loudness has waned. Is the revolution over? Is Rails done? Au contraire, the revolution has gone underground. It's penetrating places that Twitter does not hear. It's building things that are not reported. It's entered the enterprise. This talk will document the rise of Rails and glorious revolution which we barely see, but is happening every day.
The Unix shell is widely despised as a modern programming language due to its arcane syntax, unpredictable control flow, and lack of support for fundamental constructs like: exception handling, objects, a module system, string functions, or even local variables! It's old. There are a billion implementations of the core language and userland utilities, each with subtle and incompatible differences. Documentation is too sparse or too dense or available only at your local library. It's a minefield.
But for all its perceived flaws, the Unix shell can be an amazingly productive environmentâ€”once you learn to hate it properly. It has super powers. Stuff you won't find in more general purpose languages. Learn to harness the shell's AWESOME POWER and you'll be able to quickly automate a wide range of tasks related to development workflow, source code editing, and systems administration/analysis.
In this talk, I want to show how to navigate the minefield, how to "think in shell," demystify the strange grammar (yes, there's an actual grammar in there), and compare approaches to common problems in shell vs. Ruby.
How do you develop software? Is it effective? Could you do better? Where could you put the least amount of effort to improve the most? When do you do that? What would your teammates answer? What can you learn from them?
I shall give you my answers. You will give me yours.
Arel (also known as ActiveRelation) is the Ruby relational algebra engine powering ActiveRecord in Rails 3. By replacing string concatenation with an object model to express SQL queries, Arel had a big immediate impact on the ActiveRecord codebase and opens the door for more powerful Object Relation Mapping (ORM) functionality in the future. This talk will introduce the concept of relational algebra, cover the past, present and future of Arel, and dive into how you can leverage it today either on its own, or in your Rails 3 applications.
When attempting to solve our latest 367 hidden gems of ruby 1 9programming conundrum, we typically reach for the latest Ruby Gem that solves the problem for us. Oftentimes in our search for a solution, we neglect to look through some of the great libraries that come shipped with Ruby. In this talk we'll explore some of the tools we can use that don't require a gem install. We'll especially focus on the new toys in Ruby's standard library that ship with Ruby 1.9, but also look at some of the toys that ship with Ruby Classicâ„¢. Be prepared to be amazed and entertained. But most of all, be prepared to go home with something useful!