This is a list of all RailsConf 2011 presentations, including keynotes and regular talks, with the highest-rated talks at the top. Ratings were provided by RailsConf attendees. Unrated presentations are at the end.
This site is not affiliated with RailsConf or O'Reilly media. It is provided as a free service by me (Brian Morearty).
I figured I wasn't the only one who missed some of the better talks and wanted an easy way to identify them.
Once you've identified one you want to watch, find it on one of these places:
(As of this writing, only some conference videos have been uploaded to these sites.)
In this talk Señor Engineer Aaron Patterson will talk about the adventures he’s had over the past year. Topics will include (but are not limited to), ARel, ActiveRecord, ActionPack, Code Refactoring, and Sausage. Though these topics may go their separate ways, they are not worlds apart. Attendance is required as there will be homework assigned.
ZURB is an interaction design and strategy company with more then 12 years of experience helping companies make users happy through great web interactions.
In this talk Matt Kelly (Lead Engineer) will explain the benefits of removing page loads from web applications to vastly increase the perceived performance of the app, and allow interactions and transitions that are not possible with a traditional page load.
The bulk of the presentation will be presenting Backbone.js and walking through each of the steps to create a pageless app using Backbone.js and Rails. With each step the design and interaction decisions will be explained, and what not to do with pageless apps will be illustrated.
The following details will be covered:Baltimore’s Rails community is welcoming this year’s RailsConf with Ignite, an un-official pre-party taking place on Monday, May 16 at 6:00pm. Ignite will once again be held at the Sheraton Inner Harbor – one of the two official hotels for RailsConf.
What is Ignite? Fast-paced, fun, thought-provoking, social, local, global – Ignite is all of these and more. It’s a high-energy evening of 5-minute talks by people who have an idea – and the guts to get onstage and share it with the rest of the Rails community.
For more information on Ignite, visit igniterailsconf.com. Don’t forget to purchase your tickets.
The talk will cover techniques that can be used to troubleshoot production ruby deployments from three perspectives: the operating system and process, the C code VM, and the Ruby code in application itself. Each tool will be presented with a variety of real-world examples of how it was used to solve problems in a popular library or application.
Tools we will cover include:
Calling all RailsConf attendees: do you have something awesome to share with the Rails community? Can you tell us in 5 minutes what it is and why it’s awesome? If so then sign up for the RailsConf Lighting Talks. Lightning talks are a great way to drum up interest in your open source project, show off a killer new product or API that you’re launching, or share some wild and crazy thing that you’re doing with Ruby, Rails or anything else that would be of interest to the Rails community.
Sign up will be outside of the speaker lounge onsite at the venue. There will be a limited number of slots so get there early and put your name down.
Do you need to start learning Ruby on Rails? In this morning tutorial the Envy Labs team will lead you through all five labs of their Rails for Zombies course. Unlike other tutorials, all you need to start coding Rails is a laptop with Wi-Fi and a modern browser. All coding will be done through our web application, and there will be plenty of lab assistants to help you if you get stuck along the way. Once you’ve joined the undead and finished the corpse, Michael Hartl will be running the afternoon session of this day long Intro to Rails tutorial, which you are highly encouraged to enroll.
Note: This will mostly be the same content you can access online at railsforzombies.org. However, nothing beats the experience of a live presenter and having live help if you get stuck on a lab.
**Thank you for registering for Rails for Zombies! All you’ll need to attend the course is a working laptop with wifi, and a browser which isn’t Internet Explorer (also your iPad won’t be good enough, sorry). Before you come to the course we recommend you play through http://www.tryruby.org/. It’s an in-browser Ruby tutorial.
See you at RailsConf!
There are many people in the Ruby/Rails world who contribute to our community and rarely receive any recognition or payment for their work. They write educational blogs & tutorials, create plugins & gems, contribute to open source projects, and even put on events which help educate and make our lives as developers easier. Ruby Heroes was created to show some gratitude and give these people the recognition they deserve. Hopefully the type of recognition that keeps them doing what they’re doing, and continuing to make our community stronger.
At the award ceremony we’ll be handing out several trophies to people we believe to be Ruby Heroes, and giving them the round of applause they deserve and might not get otherwise. Come show your gratitude.
If you know someone who has contributed to our community this year please take a moment to show some gratitude by nominating them on RubyHeroes.com .
Let’s get together for an informal meet-up to discuss how we’re using Rails, or how we could use Rails, in higher education. The focus will be from an academic computing perspective – developing web applications to support teaching, research, and administrative systems – but other perspectives are also welcome.
The moderator is an application developer at Williams College. She was a Rails developer at start-ups for five years before recently moving to academia.
The path to becoming a “Top Gun” of Ruby on Rails starts with first being interested in airplanes, flying really fast, and making smart-assed jokes like “There’s two Os in ‘Goose’, boys.” The achievements and glory seem to only if you come first, “No points for second place.”
At the end of Top Gun, Maverick gets the girl and becomes a Top Gun instructor. Time to teach. Time to share the wisdom. Time to create more fighter pilots.
That’s where we are now with Rails community. We have thousands of Top Gun Rails developers, but we need another 100,000 or 1,000,000 amateur pilots. We need to continue to bring developers and designers into the Ruby on Rails community.
RailsInstaller started as a mission to help Windows developers get started in Rails. It’s now much bigger. Can we get Ruby on Rails onto every developer’s machine?
Diving head-first into RubyGems is rough: there’s a myriad of documentation sites, blog posts, screencasts, and manpages to read, and it’s tough to find “the” guide on how to publish your first RubyGem. In this session you’ll learn why making them is important for your Rails application’s maintainability and how distributing your code in gems even internally is helpful. You’ll find out what happens from “gem push” to “gem install”, and how Rails’ engine system makes sharing application and business logic easy.
“Fat Models, Skinny Controllers” they scream. Pushing your logic down to the model layer is a key step to improve testability, maintainability, and code quality. But many developers now have “junk drawer” models that don’t realize these goals. Having a fat model isn’t enough!
In this session we’ll explore techniques for improving your models including:When you leave this session you’ll be dying to refactor!
If you’ve built at least one Rails application you should do fine in this talk. Attendees will get hands on experience implementing some of the core Rails Best Practices using the interactive Rails for Zombies code engine. There will be 5 labs, and about 75% of the lab will be spent coding in the browser.
Note: This is not the second part of the “Intro to Rails course”. If you’re new to Rails you should check out Rails for Zombies in the morning, followed by Michael Hartl’s Intro to Rails – Part 2 in the afternoon.
**Thank you for registering for Rails Best Practices! All you’ll need to attend the course is a working laptop with wifi, and a browser which isn’t Internet Explorer (also your iPad won’t be good enough, sorry). As was mentioned in the talk description, the content for this tutorial will be the same as our Best Practices Course over on www.CodeSchool.com, except in this case WE’RE DOING IT LIVE. You don’t need to buy the course on Code School beforehand, we’ll hook you up to the system when you get in.
See you at RailsConf!
Lucky developers get to work on a team with a full-time designer. But many of us become responsible for the design of our sites – even if we don’t necessarily have an “eye” for design.
Great design is hard; mediocre design is easy. I will give beginner developers enough information to be “dangerous” with design.
Developers will be able to apply these recipes to their projects immediately, to achieve some of the polish found on sites that were designed by a professional team.
We all know that Rails is great for building traditional web applications that serve dynamic HTML pages. But more and more, people are reaching to other tools, like Node.js, when they build web applications with a lot of logic in the client. People often use the argument that when you remove the view helpers, there isn’t much of value left in Rails.
In fact, because the Rails framework made an early bet on the REST architecture, it is extremely productive for building applications that mostly communicate over HTTP using JSON payloads. In this talk, Yehuda will talk about what makes Rails so good as the server for rich clients, and how to structure your application to take the most advantage of these properties.
Kick start your Wednesday at RailsConf with a FUN AND FREE 5k race around the Baltimore Inner Harbor Promenade. Runners and walkers are welcome (the course is as flat as a pancake). We’ll start along the water near the Maryland Science Center. The race starts at 7:00am, so please arrive early to pick up your bib. Register to Run
Keynote by Eric Ries, creator of the Lean Startup methodology and author of the popular entrepreneurship blog Startup Lessons Learned.
About the book
The Lean Startup movement is taking hold in companies both new and established to help entrepreneurs and managers do one important thing: make better, faster business decisions. By testing assumptions earlier, faster, and with more rigor, you can improve your success rate. Bringing principles from lean manufacturing and agile development to the process of innovation, the Lean Startup helps companies succeed in a business landscape riddled with risk. In this presentation, author and serial entrepreneur Eric Ries will share practical solutions based in his work building IMVU to more than 25 million members worldwide and his experiences consulting to more than a dozen technology startups.
Eric’s upcoming book, The Lean Startup is available to be pre-ordered on his website: www.theleanstartup.com
8:00pm – 10:00pm Music Jam, Ballroom I/II
Bring an instrument (or your voice) and let’s make music!
Many Rails developers are also musicians. Whether you play jazz, rock, blues, pop, or whatever the case may be, come along and meet and play with other musical developers. Don’t worry if you can’t bring your own instrument, stop by anyway. There will be a full set of drums, bass, and guitars thanks to The Hybrid Group.
8:00pm – 10pm BoFs, Ballroom III, Ballroom IV, Room 345, Tables 1 – 5
Birds of a Feather (BoF) sessions provide face to face exposure to those interested in the same projects and concepts. BoFs can be organized for individual projects or broader topics (best practices, open data, standards). BoFs are entirely up to you. We post your topic online and onsite and provide the space and time. You provide the engaging topic. Learn more about BoFs
Resources are always limited. One of the most important decisions to make in any company is when to build vs. buy resources. Those resources can be technology-, team- or business-focused. This talk will outline guidelines of when to buy vs. build, featuring some fun and surprising examples.
LivingSocial is one of the fastest growing companies in history. You will learn lessons we have learned—sometimes the hard way.
Whether you’re in a startup or a product or service company, you need to hear this talk. Your customers may be weighing the same decision. Building vs. buying can apply to the team itself. What can you outsource to an external team? When should you grow a team one at a time vs. acquire a team and merge?
This session is sponsored by LivingSocial
Choosing a data storage engine is an important decision, but it doesn’t have to be painful if you know the landscape. We’ll look at several DBMSs (and a few you’ve never heard of), compare and contrast them based on use-cases, and how to plug each into Rails (even running together!).
Authoring the book “Seven Databases in Seven Weeks” has opened up a whole world of database alternatives that I never before seriously considered. It’s an important decision to be made by research, not buzzwords – and we’ve sifted through them so you don’t have to. At the very least we can settle the Mongo v. Couch debate (hint: they’re both awesome).
This talk will include:
Among the DBMSs we’ll spy are: mySQL, PostgreSQL, Redis, memcached, Riak, Cassandra, HBase, MongoDB, CouchDB, Neo4J, OrientDB, and others time permitting.
Everybody wants to do test-driven development, but switching to TDD or BDD on an existing project that doesn’t have tests presents special challenges. Often, the current code is a tangled mess of dependencies that defeats the very concept of unit testing. Worse, if somebody has attempted TDD in the past, you might have a test suite that needs to be fixed before any new tests can be written.
Don’t give up. Adding test-coverage and TDD to your application will make it easier.
This session will describe techniques that you can use to bootstrap a test-driven process into your project. You’ll see how to use “black-box” techniques that don’t depend on the structure of the code and “white-box” techniques that interact with the code more directly.
Topics covered will include:
At the end of this session you will be ready to attack the most monstrous of code bases with TDD.
“Then it starts to scan the computer and transmit bits of information every time he clicks the mouse while he’s surfing. After a while, [...] we’ve accumulated a complete mirror image of the content of his hard drive [...]. And then it’s time for the hostile takeover.”
—Lisbeth Salander in Stieg Larsson’s “The Girl with the Dragon Tattoo”
Hacker dramas like the Stieg Larrson book make for good fiction, but we know that real life rarely matches drama. And with all the security features that Rails 3 has added, surely it is difficult to hack a typical Rails web site.
Right?
Wrong! Without deliberate attention to the details of security, it almost certain that your site has flaws that a knowledgeable hacker can exploit. This talk will cover the ins and outs of web security and help you build a site that is protected from the real Lisbeth Salanders of the world.
OmniAuth allows any app to authenticate through a growing list of external providers such as Twitter, Facebook, and more. By leveraging OmniAuth in your application you can easily tap into the power of social sign-in. In this talk attendees will learn:
Are your methods timid? Do they constantly second-guess themselves, checking for nil values, errors, and unexpected input?
Even the cleanest Ruby codebases can become littered over time with nil checks, error handling, and other interruptions which steal attention away from the essential purpose of the code. This talk will discuss strategies for writing your Ruby classes and methods in a confident, straightforward style; without sacrificing functionality or robustness. In the process, we’ll cover concepts and techniques including:
Nobody likes when their code smells. To help avoid it, dozens of special tools and approaches have been designed. Efficient coding tools, refactorings, code metrics, code analysis, code testing and debugging are all crucial for creating quality, maintainable code. During this talk we’ll show you how to efficiently detect code smells, eliminate them using refactoring, and validate the changed code. By the end you’ll have a ‘swiss army knife’ full of techniques for making better code.
This session is sponsored by JetBrains
One of the most important current trends in the high-tech industry is the rise of spatial and location-based technologies. From reading GPS information to displaying Google maps, many web developers have had to interact with geospatial systems. However, the Rails geospatial stack has so far tended to lag behind those of similar frameworks such as Django, in capabilities and maturity. As a result, few Rails developers have been able to move beyond showing a few pushpins on a map.
We’d like to have a meeting for developers and anyone interested in geospatial libraries and tools for Rails. The goals of this meeting are to:
Our vision is to make Rails THE world-class platform for developing geospatial applications.
Pivotal Tracker is the world’s most popular agile project management application, and it all started here in the heart of the Rails community exactly three years ago. In addition to a demo, we’ll take a look back at why we built Tracker in the first place, how it grew from a simple tool that we needed as a consulting company to a major transformational force in modern software development, one that powers many of today’s fastest growing companies. We’ll talk about some of the challenges along the way, and look at the exciting road ahead, including new features in the works.
This session is sponsored by Pivotal Labs
Rails is a great framework for building web-based systems, but many of us don’t have much experience outside of port 80 or 443. Dave Troy developed a scalable server architecture for Shortmail.com, implementing stateful, secure services such as LMTP, SMTP and IMAP using EventMachine and Rails. He’ll talk about those design patterns and how you can build interesting new internet services using Ruby.
The DRY Principle (Don’t Repeat Yourself) tells us that “every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” A powerful guideline, but it is often heeded without a clear understanding of its underlying motivations, nor consideration for other principles that might lead the code in different directions. In this talk, we’ll explore duplication in code in a variety of forms and the risks associated with each. We’ll look at strategies for reducing duplication without sacrificing design basics like encapsulation, low coupling, and high cohesion. We’ll look at other principles that are often left behind in the name of keeping the code DRY, and how to balance them to keep your code flexible and maintainable
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.
Online games pose a few interesting challenges on their backend: A single user generates one http call every few seconds and the balance between data read and write is close to 50/50 which makes the use of a write through cache or other common scaling approaches less effective.
Starting from a rather classic rails application as the traffic grew we gradually changed it in order to meet the required performance. And when small changes no longer were enough we turned inside out parts of our data persistency layer migrating from SQL to NoSQL without taking downtimes longer than a few minutes.
Follow the problems we hit, how we diagnosed them, and how we got around limitations. See which tools we found useful and which other lessons we learned by running the system with a team of just two developers without a sysadmin or operation team as support.
This presentation is a case study in introducing Ruby on Rails into a highly available NASA Earth Science Data Search and Order system. The NASA ECHO system is a publicly accessible system that catalogs roughly 100M pieces of Earth Science metadata. Our metadata database is a three node Oracle RAC cluster of roughly 1TB in size representing several PBs of raw science data. The majority of the system system was implemented in Java with one significant exception: the web client used by 98% of our users was written in Perl. After over a decade of maintenance the Perl based application had reached the end of its serviceable life and we had the opportunity to build a new client application.
The ECHO team conducted a survey of modern development technologies including Flex, Python/Django, JSF2/Spring and Ruby on Rails. We chose to implement the new client using Ruby on Rails with JRuby which led directly to reimplementing multiple core pieces of the system beyond the client application.
The impacts on the ECHO team, including our stakeholders, were immediate and sometimes subtle. The technology selection caused shifts in our architecture and design, development and deployment procedures, requirement definition approach, testing approach, and, somewhat surprisingly, our project team structure and software processes.
This presentation discusses our experiences, including technical, process, and psychological, using RoR on a production system. During this session we discuss:
This presentation targets experienced developers and project managers who are interested in how Ruby on Rails can have cascading effects beyond just the development team. In addition, our experiences can provide Rails shops and consultants some insight as to how to successfully move client projects to Rails.
Keynote by David Heinemeier Hansson.
Testing and craftsmanship are huge in the Ruby Community, but most people ignore testing the JavaScript parts of their applications, thinking that it’s too hard to test that. This talk will show them that it’s not hard, and hopefully inspire people to bring their testing skills to the front end. As more and more web applications rely on JavaScript for a lot of their view and controller logic, it’s time everyone started testing their JavaScript code properly.
This talk will be presented together with Jonas Nicklas. Jonas is the author of Capybara, the most popular library for JavaScript-enabled integration tests.
We gave a version of this talk at RubyConf 2010 (http://speakerrate.com/talks/5077-the-front-end-testing-frontier) and got lots of great feedback. I strongly feel that it is much better suited and more needed at RailsConf though, since it’s all about testing (the non-Ruby part of) web applications.
A huge step forward in the third version of the Rails 3 framework is the modularity it provides. This modularity is the result of a long refactoring effort to make it easier to extend or modify Rails to suit our application’s needs.
In this talk, José Valim will briefly present the SOLID Design Principles, discuss how they were applied during the Rails 3 Refactoring and how such principles can improve your code. To support this discussion, he will show some architectural changes done in the Rails framework during the years and how those design principles led to the so-called Rails modularity. He will explain why these changes matter to Rails and its ecosystem.
Birds of a Feather (BoF) sessions provide face to face exposure to those interested in the same projects and concepts. BoFs can be organized for individual projects or broader topics (best practices, open data, standards). BoFs are entirely up to you. We post your topic online and onsite and provide the space and time. You provide the engaging topic. Learn more about BoFs
Change.org is hosting a happy hour! Growing in membership at over 10% per month, Change.org is the world’s fastest growing social action platform. RSVP to come share drinks with a few of the Change.org folks and hear about how the application of web technology has been successful in things like persuading 1-800-Flowers and FTD to implement fair-trade practices, convincing Apple to remove an anti-gay iPhone app from the app store, and helping to curb the practice of “corrective” rape in South Africa. Space is limited so RSVP now at http://changeorg.eventbrite.com
Location
Pisces Room (15th Floor)
Hyatt Regency Baltimore on the Inner Harbor
300 Light Street
Baltimore, MD 21202
(connected to the convention center via walkway)
This talk is made up of 6 discrete chapters:
Chapter 1: Indexing [Beginner]. We will cover what to index in your database and how to index it in Rails. All the code is backed up with benchmarks that show the kind of performance boost you can expect to see in your application when you index correctly.
Chapter 2: Foreign Keys [Beginner]. Foreign keys are important for data integrity. We’ll show how Rails model validations can be circumvented and why it’s important to put foreign keys on your data. We’ll show how to use the ruby gem foreigner to add foreign keys in your Rails migrations.
Chapter 3: Geospatial Extensions [Intermediate]. Geospatial data has quickly become a key feature of many sites, especially social networks. We’ll show how to use geospatial extensions in the database to store geospatial information. We’ll also cover geospatial indexing with code examples to show how attendees can query data quickly and accurately.
Chapter 4: Full Text Search [Intermediate]. Almost every site has a search bar, and it has to work well. Third party search solutions can be difficult to setup and maintain, but we can get up and running quickly with full text search in the database. We’ll have benchmarks to show it’s fast, and also illustrate the quality results you can get when your search is backing by a tokenizing and stemming search system that supports ranking and automatic highlighting of results.
Chapter 5: Joins, Aggregation, and Views [Advanced]. AREL has given us a new way to view the database. What used to be a cumbersome and ugly way of doing complicated queries (find_by_sql) can now be elegant, chainable, and powerful with AREL. We’ll step through and example of how you would go about constructing a complicated query by joining multiple tables and aggregating the data. Then we’ll show how to create a view on that data and access it via ActiveRecord.
Chapter 6: On the shoulders of giants [Advanced]. This chapter focuses specifically on the contrib section of PostgreSQL. There are a lot of great tricks here, like using chkpass to supply a “password” column type that automatically encrypts passwords and lets you query them (no more salt+hash!). hstore lets you store hashes and intarray lets you store arrays in the database, and they’re both indexed so you can query the data without pulling it out of every row. isn lets you store isbn, upc, ismn, and issn ids and handles validation and check bits for you automatically. xml2 lets your store xml in the database and supports xml validation and xpath querying on the column.
Having built two object mappers in Ruby (MongoMapper and ToyStore), I would like to throw out a crazy thought. What if, on your next project, you ditch the ORM.
No ActiveRecord. No DataMapper. No anything. Just you and a lower level driver, whispering sweet nothings into Ruby classes and modules. Could you? Would you? DARE you?
We Rubyists are all about aesthetics, right? We love declaring has_many and belongs_to! Scope this! Boom! Instant magic happens behind the scenes. Fancy proxies are assembled, relational algebra is executed, and SQL queries fall from the heavens.
Your ORM does not have to do everything for you. This talk will teach you to:
The whole team at New Relic has been busy building the next generation of our app management tool and we couldn’t think of a better place to show it off than at RailsConf. Join us for a presentation and demonstration of some remarkable new capabilities that we think you’ll love. We can’t wait to see you there!
This session is sponsored by New Relic
It’s not what you code, it’s how you code it.
Rails development is exploding, many new applications are being created daily. Coding these applications in a maintainable and clear manner means more than just writing specs and tests. There are a lot of parts to a functioning Rails application, and all of them are critical to the ongoing maintenance.
Maintainability is more than just making it easy for you to fix bugs. Do you really plan to be the only person who will ever be able to maintain your application for the rest of your natural life?
Drawing on 10 different real world, in production, Rails applications, this talk will cut through the theoretical jargon and dive right into what makes the different applications easy to maintain or a horror to run.
Some working titles in the presentation are:
This talk will be very useful to any Rails developer who wants to build a system that will operate for the long run and more importantly, allow you to hand over the maintenance to a third party at some point, allow you to get on with your life.
The Rails View layer is the Wild West. Bad mustaches, crazy fights over simple things, and complete and utter confusion abound. When do we use a helper or a presenter? How do we keep logic and markup separate? What’s this here new fangled boilerplate and HTML5/CSS3 thing?
Well, friend, good news. We’re here to show you the ropes so you can clean up this town and put your Rails apps on the path to prosperity.
Some highlights:
Bonus: Up to three hours of an extended Wild West metaphor, to include plenty of painful and unnecessary John Wayne, Tombstone, and Bonanza references.
About the presenters:
John Athayde is a UI/UX/Design type who comes from an architecture (of the building variety) background. He’s been in the Rails community since 2006 and has broad experience in e-commerce and running creative teams. He currently is the UI/UX/Design and Product Manager at InfoEther, Inc.
Bruce Williams is a longtime speaker, trainer, designer, and book contributor in the Ruby and Rails community and has experience in everything from low-level data processing backends to front-end user interaction. He is senior developer and systems designs consultant at InfoEther, Inc.
When not giving talks on the subject, John and Bruce are busy writing a book focused on Rails view techniques, available soon from the Pragmatic Bookshelf. No word yet on whether the cover art will include spurs.
People keep inventing new programming languages. What is programming, and how can the design of a programming language help or hinder that process? We have learned a lot over the last five decades: principles, conventions, theory, fashions, and fads. “Those who cannot remember the past are condemned to repeat it.”
In this antiphonal multimedia presentation, we survey numerous design features and important lessons from the past that future programmers—and future programming language designers—ought not forget. We illustrate each lesson by discussing specific programming languages of the past, and endeavor to shine what light we can on the future.
The world of web development is changing. As Avi Bryant pointed out at Golden Gate Ruby Conference 2010, more and more development is getting pushed into the client, which means that more and more of our applications are being written in JavaScript. However one of the major problems that Ruby/Rails developers face as more and more logic is pushed into the client is how do we maintain our disciplines? How do we keep writing high quality maintainable code when we have to work in another environment?
The Ruby/Rails community is known for it’s adoption of agile practices like TDD, and aggressive refactoring. Yet when we move into the browser, most developers seem unable to keep up the same kind of workflow, particularly when it comes to testing. Many reasons have been offered as to why this is the case: The testing tools for JavaScript just aren’t good enough. The browser just isn’t conductive to testing. The DOM is too much of a pain. Yet none of these issues are the biggest reason why.
Why is it that developers have a hard time writing tests for a PHP application? It isn’t because of PHP as a language, but the way that PHP is generally written. A single page that has business logic intermixed with application logic, which is itself intermixed in the display logic will never be testable. However when PHP is written in an isolatable way, breaking the code into units which do a single thing, PHP is almost as easy to test as Ruby. The same is true of JavaScript.
Specifically, the talk will focus on the following ways to break your JavaScript into testable chunks:
The Ruby community has been tremendously successful at getting Agile/XP practices adopted into the mainstream of our community. Now it’s time to continue to expand that influence as some of our developers move into languages like JavaScript, and as we build the next generation of web applications.
Join Dr. Nic Williams for a whimsical journey through the rich history of our favorite programming language. Ruby has come quite the distance from being a language that was designed by Matz to be “more powerful than Perl, and more object-oriented than Python”.
He’ll take us through the storied evolution of Ruby before addressing the future—What will your investments of time and talent yield? Why Rubinius? Why JRuby? Why YARV? Get the answers to these questions and more with the characteristic cheek you’d expect from a man who once wore a tutu on stage.
This keynote is sponsored by Engine Yard
The financial market data application that we’re building sustains an average write load of around 10,000 writes per second. Scaling a system to handle this many writes while responding quickly to user requests is quite challenging. Our data store is able to keep the data, but the indexes required to respond to user requests would completely overload it. To solve the problem we moved to storing indexes in Redis. Its functionality and high speed made dealing with this write load manageable.
This talk will cover what types of operations and data structures Redis provides that enable it to ac as an indexing server. It’s a case study of using Redis as more than just a key value store or the backend for Resque. I’ll cover the design issues with keeping indexes in Redis and making sure that they get updated if there is an outage. Cache warming, data structures, and advanced Redis use are all part of the talk.
BohConf is the official RailsConf 2011 unconference. At BohConf, we’re going to get our hands dirty writing code and sharing ideas in an open and free-form environment. This hacking-centric event will include community code drives featuring well known OSS authors, a code retreat, a programming competition, and barcamp-style discussions. It is free and will run alongside RailsConf in the convention center. Everyone is welcome at BohConf.
More details will be available on the BohConf website soon. Follow @bohconf on twitter for more updates.
Where and When is BohConf Happening?
BohConf is happening in conjunction with RailsConf at the same time and same place (Baltimore Convention Center). It will be happening Monday, May 16 – Thursday, May 19.
Who Can Go?
Anyone with a RailsConf badge. If you aren’t planning to attend RailsConf but still want to go to BohConf, just register for a BohConf Only pass (its free!). You’ll also get access to the Exhibit Hall and Birds of a Feather sessions.
Who is organizing BohConf?
BohConf is organized by SmartLogic with help from B’more on Rails.
HTML5 is the new hotness, but this tutorial aims to get past the hype. I will lead the class in a series of exercises that build understanding of new browser capabilities. We’ll make a simple multiplayer game that uses sprite animation on the canvas and websockets for communication among clients via an EventMachine-powered Ruby server.
The example will make extensive use of:
Note: The only pre-requisite is to have the latest version of Chrome, Safari, or Firefox installed on your machine.
Smart developers have been using Ruby on Rails to rapidly build web applications for over 5 years now. Cutting-edge projects have aged into old, moldy, legacy apps. Rails 3 and Ruby 1.9 offer performance improvements and new features that are guaranteed to take the squeak out of that old wheel and grease the tracks of new development. We’re going to walk through upgrading real projects and then work through some stumbling blocks taken from the audience.
We’re going to specifically talk about:
NOTE: We’re going to walk through migrating a legacy Rails application to Rails 3.1, but in order to solve the hard problems attendees are going through, I’d like to attack real issues. If you are attending this tutorial, feel free to send examples of issues you are having ahead of time to crnixon at crnixon dot com. Please put [Rails3] in the subject line.
Depending on the time we have and the interest, we’ll pull examples from the audience and have a workshop on those problems. Attendees should bring their problem applications and have a way to do remote screen sharing. A VNC server will do if you are running Linux or Windows; OS X users can use built-in screen sharing.
This Year, Dr. Nic hosts Engine Yard’s sponsored sessions, which were given away to members of the Ruby on Rails community who did not otherwise get the chance to speak at RailsConf this year. The speakers were nominated by the community, so don’t miss it—the people have spoken! (Note: Open to registered attendees only.)
This session is sponsored by EngineYard
Rails is an amazing tool. It enriches my life and I’m proud to use it in my day to day work. But Rails is far more than a web framework. Embodied within the expression “Ruby on Rails,” for me, is a culture that transcends syntax, grammar and logic, going way beyond. This is a talk about what being a Rails developer means to me, why I’m proud to be one and why you should be too.
Problem 1 While AJAX is a good first step, we must consider performance of our AJAX requests. I will show you how to use caching strategies that are compatible with all browsers and environments. I will also show you how to setup background jobs to quickly process the AJAX request.
Problem 2 Some code will always run slow. I will show you how to solve the problem by not solving the problem. In stead of focusing on the individual job itself, we will look at how to leverage a whole host of cloud nodes to execute our jobs. I will provide real world example (stuff we run into at Heroku).
Rails 3 is here, and ships with Bundler by default. Bundler’s default mode makes things easy on developers, obsoleting that out of date list of gems in your app’s readme. Deploying, however, isn’t as obvious. What if you’re using Sinatra or something else that isn’t Rails? How do you deploy a bundled app using Capistrano, or Vlad, or your own script? What are the best practices for deploying to an app running in Mongrel, Unicorn, or Passenger? What if your server doesn’t have an internet connection to talk to rubygems.org? These questions and others will be answered by a member of the Bundler core team.
This session is intended for intermediate Rails developers who would like to start building location based applications, but may not know the full breadth of the toolkits available.
We will start by examining the different types of location-based applications. Then we will look at the anatomy of a typical location-based application, and the elements of the spatial tool stack that apply to each geospatial element in the application. The relative strengths and weaknesses of RGeo, GeoRuby, and spatial_adapter will be examined in depth. We will then discuss in moderate detail the capabilities the many visualization libraries and DBMS systems that round out the stack, with a focus on helping the attendee understand when to choose which tool.
Finally, we will explore some examples of geospatial applications that are 1) inspiring and 2) use different elements of the stack as discussed during the session.
Although this presentation will incorporate a limited amount of the content that I have presented on the topic at other conferences, this is a new presentation that examines the actual tools that a Rubyist would use in their daily work. I have developed this material in response to feedback on my “Intro To Spatial Programming” presentation whereby users have asked overwhelmingly for direction on how to navigate the landscape of tools and technologies at a very technical level.
It’s important to note that this presentation is not a re-hashing of my prior work: it builds upon it. For those who have seen me present on GIS and Geospatial before, the additional information will be a welcome addition to their knowledge base. For those who are just being introduced to the topic, I’ll review just enough material to make them comfortable diving in to the details.
Come learn about the open source e-commerce framework that is taking the Rails world by storm! We will provide a basic overview of Spree, demonstrate some of the unique features and preview some of the exciting features planned for this year.
Spree uses the New BSD License and its completely free to use. We have over 150 different contributors and its been translated into over 30 different languages. There will also be an opportunity to meet members of the core team and ask any questions you might have.
This session is sponsored by Rails Dog
Although JRuby has maintained a high degree of compatibility with C Ruby, there still are a few considerations when making an existing Rails application run with JRuby. We’ll introduce a simple step-wise process for ensuring you can trial your application on JRuby. From there we’ll discuss its merits as a deployment platform, including stability and performance, and why these can be worth taking the trouble to make a few changes to your application and deployment workflow.
What started with two brothers in the McKinney Public Library is now a world wide word phenomenon on multiple mobile platforms. We’ll look at how we have grown, the mistakes we made, and the changes we have made along the way:
In the beginning Matz created the language and the community. Matz called the language Ruby, and saw that it was good. And Ruby was the first day. DHH said, “Let there be the framework”. DHH called the framework Rails, and saw that it was good. And Rails was the second day. DHH blessed the language and the framework, and DHH said unto them, Be DRY, and agile, and replenish the earth, and subdue it! And have dominion over every programming thing upon the web. And it was so…
Ruby spent its childhood with a Japanese language speaking developer community inside a small Far East country.
Since the West discovered the language, and the “Rails Invasion” hit Japan, the Japanese Ruby community has been drastically changing. Actually the majority of the Rubyists in Japan are Rails users today. But sadly, although both Japan and the West are using the same programming language and the same web app framework now, the speaking language barrier are still separating the communities. I suppose you can’t see what’s going on inside the Japanese “closed” community because of the barrier.
Probably it’s time to open a Socket between both community and connect our communities. So, let’s start to know each other first!
Today, as a messenger from Japan, I’m here to briefly introduce some goodies from Japan such as:
Applications are strange things once they are in production. People use them and your data grows in size and complexity. Eventually a point is reached where the database can’t keep up and other layers are added. Sometimes it’s caching, other times it’s some kind of full-text indexing. After a few iterations of dealing with growth, applications can end up with multiple persistence layers. It can get messy.
We usually start our applications with a relational database and move on to more interesting problems. But where do you go from there? Is it better to make the leap to a document database, add caching, apply full-text indexing, or something else? What libraries are out there for growing our application? Should we go NoSQL, stick with SQL, or go with an unholy hodgepodge of storage systems? How do we deploy and monitor our new hotness?
In this talk, we’ll look at how to choose between caches, key-value stores, document databases, full-text indexes, and distributed databases. We’ll think about how to integrate these with our existing models and what kinds of libraries we might want to use. Finally, we’ll examine the tools and processes to operate our new systems in production.
Discussing common problems and design patterns to make your stylesheets “Syntactically Awesome”.
Bring simple designs that needs to be converted and we will help you achieve awesomeness or if you don’t have any designs that need converting we will supply some basic templates that you can work with to get a handle on implementation.
People really get bent out of shape about what programming really is. Is is engineering, craft, art, or science? Or something different entirely? But the real question is: does knowing what programming really is help us to be better at it?
Many teams and projects I’ve been involved with are deploying ruby applications in an atypic way, i.e. different from the mainstream “cap deploy”. It has been a very nice experience so far, and I would like to share. Come hear why some people think that there are better and not much explored ways of deploying ruby and rails systems.
This talk will cover:
This session wil provide an overview of enhancements that are commonly made to the search box to provide more sophisticated user interactions. The session will overview the basics of autocomplete and autosuggest, and how to implement them in a Rails application. The session will also look at more advanced search box implementations, such as those used in applications like Facebook and Quora. The session will walkthrough implementations of each type using common tools such as jQuery/jQuery-UI, as well as provide details on gems that can be used to make the process simple. The session will also provide details on how to improve speed and performance using Rack, Sunspot and Solr to power these features.
The client side encryption system that we’ve built is something I think is truly unprecedented. It allows us to offline credit card storage while maintaining the simplified PCI compliance of using Braintree’s Vault and has reduced our average purchase creation request time from almost 3 seconds to under 200ms. Client side encryption further increases customer security as at no point do we have access to the plain text credit card number.
One of the great things about having an extensive version control history of your code is that you have it all. You can look back at any moment in your app’s history and examine it. You can gather metrics, figure out where things went wrong, or just learn more about how you and your team’s decisions impact the code. It’s all there.
In this session, we’ll look at some data that we’ve gathered from Rails projects and talk about how teams can analyze their own version control history to find trends, making development a much more self-aware process. We’ll also provide access to the scripts we used to gather the information.
Contributing to open source is great for your career. In a few short hours, you can learn, teach, promote your skills, and improve the quality of the community. In this unique workshop, we will show you how, by doing it.
Take this opportunity to begin contributing to a Ruby on Rails open source project that interests you. Experts from the Rails community will be on hand to help you get started.
The idea behind Firewall Install (FI) is we can leverage the majority of our existing GitHub codebase, tailor it for the Enterprise market, and sell to customers who would otherwise never be able to put their code on github.com for legal or bureaucratic reasons. This same workflow would work well for other Rubyists, too, and all too often it’s a slice of the market that developers just don’t think about.
There’s a lot of high-level aspects to cover: how our FI developers work organizationally with everyone working on github.com, what are the approaches necessary to technically support off-site software, and how you keep up with the unique challenges of communicating with customers of shipped software.
The majority of the talk, however, will be from a technical perspective. How we really screwed up regarding branch-level organization in git, and our subsequent solution to address those problems. How you can structure internal libraries and refactor complicated classes to gracefully support both your SaaS product and your installable product at the same time. How Bundler saved our butts for dealing with multiple Ruby interpreters. FI also runs on multiple operating systems, too, which brings with it a slew of fun testing and deployment challenges.
We’ll also dive into quite a bit of detail about the software stack itself: chances are you’ll need to deal with web servers, app servers, caching servers, and a slew of other processes to support your Ruby and Rails stacks. FI eventually moved its installer to Chef so we can configure our stack with Ruby, and there’s a lot of considerations to modify Chef to work as a customer-friendly installer.
We’re really happy with this setup, and we’re pretty excited to let others know that it’s a great way to do business, too, even if your main product is software-as-a-service.
Cloud Foundry is the open platform as a service project initiated by VMware. It provides a great developer experience for building and deploying Rails application to the cloud. Attendees will learn how to use Cloud Foundry command line tool (VMC) to deploy, update and troubleshoot Rails applications. Attendees will also learn how to manage a running application by monitoring its health, memory, instances and how to quickly reconfigure or scale to meet changing demand. Attendees will deploy their applications to different cloud destinations including CloudFoundry.com. The workshop is comprised of three identical 45 minute tutorials. The schedule will be as follows:
1:30pm – 2:15pm – Tutorial #1
2:15pm – 2:30pm – Break
2:30pm – 3:15pm – Tutorial #2
3:15pm – 3:30pm – Break
3:30pm – 4:15pm – Tutorial #3
4:15pm – 5:00pm – Open Q&A
Join this workshop to receive an immediate account on CloudFoundry.com.
This workshop is sponsored by VMware
Trinidad is a simple and pluggable application server that takes the best features of Apache Tomcat and brings them to the Rails world.
In this talk we’ll explore its main features and how to use them efficiently. From how to use Trinidad for our day to day development work to how to create a complex deployment environment with capabilities like daemon executions, hot deploys and multi application configurations.
We’ll also cover the Trinidad extensions’ api that allow users to create plugins with new features and add them to the server easily.
NoSQL! Everyone’s talking about it, but it’s a fairly nebulous term and there are lots of different approaches to the concept. MongoDB definitely is the most popular in terms of ORMs and usage, but HBase is another “NoSQL server” with a different approach that you’ll want to understand. Based on the ideas in Google’s “BigTable” whitepaper, HBase is part of the Apache Hadoop project. It’s a column based data store designed for virtually infinite scalability, and it’s easy to make use of it in your Rails project.
This talk will cover the basics of HBase: installation, structure, and schema strategies. We’ll then see a few different ways your Rails project can interact with HBase, covering the Stargate REST server, hbase-stargate RubyGem, and the Rhino ORM.
Dive into the internals of thoughtbot’s copycopter_client and discover how we test grizzly components such as:
Also learn common strategies for testing applications that contain difficult-to-test components, as well as tools for regression testing, such as ensuring that your library will work across several versions of Rails.
Testing is a staple in the Ruby community, but there are certain small pieces of behavior that seem to be simply untestable. Trying to create complicated tests for only a few lines of code seems to be a waste of time, but introducing gaps in coverage leaves the entire application or library suspect. This talk will help you close those gaps and keep your coverage at 100% regardless of what ugly monsters rear their heads.
Cloud Foundry is the open platform as a service project initiated by VMware. It supports multiple developer frameworks including Rails, Sinatra, Spring and Node.js. Using Cloud Foundry, Rails developers are able to deploy and scale applications in seconds while leveraging a variety of application services like MongoDB, MySQL, Redis, RabbitMQ and more. Cloud Foundry applications are not locked into any particular cloud (private or public). At this session, Derek Collison, CTO and Chief Architect of Cloud Foundry will provide a detailed overview of the Cloud Foundry architecture, developer APIs and how Rails developers can use the system.
This session is sponsored by VMware
It’s surprising that DCI (Data-Context-Interaction) hasn’t received more industry-wide attention. It has an impressive pedigree – it was created by James Coplien and Trygve Reenskaug, the inventor of MVC – and it addresses common software issues.
However, the DCI approach, which has been described as object-oriented instead of class-oriented, is not conducive to implementation in languages like Java and C#, which could explain the lack of attention. With the flexibility of Ruby, implementing DCI is fairly straightforward. Rails developers should be leading the way in advancing software architecture with the adoption of DCI.
This talk will be an introduction to DCI, and will describe how DCI goes beyond MVC in helping divide application responsibilities and improve maintainability. Specifically, DCI addresses common issues such as: bloated domain objects with multiple personality disorder; grey areas between M, V, and C; blending of code with varying rates of change; and test / database decoupling – issues faced by most significant Rails applications.
Here’s a relatively brief summary of DCI:
Although the concept of roles is not new in software development, DCI promotes roles to a critical level of importance. Domain objects are not reduced in importance, but are set free from all of the baggage typically dumped on them to support all of the roles they are expected to fill. The objects are distilled to their basic essence, still encapsulating their data, but only providing the methods essential to what the object “is”, not everything it “does”.
Roles are the home for all of the things an object does. Obviously each object can fill many roles, with each role cleanly separating what would otherwise be mashed into one of the many personalities of the object. In addition, the role / object separation opens up the possibility of having roles that support many types of objects – as long as the underlying object supports the interface required by the role, everything’s good.
In DCI, roles are not standalone objects; they don’t even have to be implemented as classes. A role is a set of methods to be dynamically added to an object. In Ruby, roles can be implemented as modules, simply extending the appropriate domain objects. (It’s a bit more complicated in crustier languages ;-)
The linking of roles to domain objects is the responsibility of the Contexts. Each user / system interaction scenario is represented by a context, typically initiated by a controller. The context not only assembles the roles and objects, but also orchestrates any high-level interaction that does not cleanly fit within the object roles nor the controller (for example, a sequence of steps specific to the implementation of a story). Contexts can be nested and reused, but should be stacked, so that only one is active at any time.
For more details, see: http://www.artima.com/articles/dci_vision.html, Coplien’s “Lean Architecture” book, and other related papers by Reenskaug and Coplien.
Keynote by Aaron Batalion, CTO, LivingSocial.
This keynote is sponsored by LivingSocial
In his last RailsConf keynote, DHH hinted at a mechanism for Rails 3.1 for flushing partial responses out during view rendering, commonly known outside of Rails circles as “progressive rendering.” Having implemented this for Rails as a plugin, Template Streaming [1], I will present how we are using this at Patch.com, and how it changes the way you need to design parts of your application. Some key points are:
In addition, I will present how progressive rendering complements two other full-page caching techniques we use at Patch.com:
By relaxing our freshness constraints a little, these techniques can be used to ensure that for heavily trafficked pages, the initial page render is always served from a full-page cache, with user-specific data pulled in after the initial page load. Meanwhile, progressive rendering can be used to optimize pages which don’t lend themselves to full-page caching, such as search results.
[1] http://github.com/oggy/template_streaming
After spending the last few years developing and deploying Rails applications we’re ready to unload all the tips and tricks we’ve learned. But each nugget of experience will be ruthlessly culled to fit in two minutes. You’ll get the whole seat but you’ll only need the edge!
Whether you are a student, a freelancer, an employee or running a company, your career is your responsibility. This talk will deliver a plan to review your career in terms of mind, body, heart and soul health.
The talk will incorporate both personal experiences and those from others in the international Ruby community on reviewing your own career.
Keavy has been an independent consultant for ~10 years and has a wealth of first hand experience of the benefits of carrying out such a review, as well as the dangers in neglecting to do so.
Jason Fried says Work doesn’t happen at work, but you can work as productively as possible wherever you are (even at work). We will explore principles of productivity, as well as techniques and tools you can use.
Topics include:
Principles of productivityLightning keynote by Dr. Dan Melton, CTO, Code for America.
As Rails applications evolve and grow, they tend to accumulate dependencies. Often, these dependencies are shared between multiple systems (whether related or disparate), which leads the developer to question how these dependencies should best be shared. Maybe a web service is best. Maybe a shared database, with models exposed via plugins, is simpler. Perhaps another approach entirely is more appropriate.
This presentation will show attendees different ways to share these dependencies by exposing them as services, and will discuss guidelines and tips for when the different approaches ought to be used. These techniques are all taken from the presenters’ own experiences with working on 37signals’ suite of applications, and helping them interoperate, sharing data and logic.
We’ll spend 10-15 minutes on 3 core areas of Rails development, discussing the choices available, if there are specific use cases for each, why you should use a particular one (if we have a preference), and how to navigate the difficult decisions associated with technical choice.
We’ll be as even handed as possible (we have opinions but realize that our choices don’t always match everyone’s case), but the focus will be on sharing our own war stories with each choice and how that should affect decisions made.
Working as an in-house developer can present a unique set of challenges. A large percentage of our apps are intended for internal use and even those apps that are customer facing will include an internal admin interface. Because of this, each new app needs a base set of features.
Our in-house development tools have transitioned to open source technologies like Ruby on Rails, mysql and apache. Likewise the patterns that we have come to apply for rapidly developing in-house apps have evolved. This presentation is going to give attendees an in-depth look at what these patterns are and how we apply them at OPNET using Rails 3.
Patterns / base features we’ll talk about:We will discuss the various alternatives considered and some of the pitfalls experienced that has led us to our current approach.
As part of the presentation we will make available, through github, a example template that can be used by others as a starting point.
Why we do this talk
While building a HTML5 offline app using BackBone.js, we had to re-write a bunch of methods from our Rails models in JavaScript to be used on the client. In order to built a real rich client experience we had to have the same functionality on objects in the Ruby and the JavaScript world and there was no other way than just duplicating code.
After a while we decided not to settle with that “solution” and look how to overcome the problem. This talk is all about our adventurous path through Ruby and JavaScript land and our solution to write DRY code again.
Why you should care
JavaScript is on the fast lane right now. New frameworks like BackBone.js are emerging day by day.People already using JavaScript to build rich client web applications with things like SproutCore . But while today those apps are the rare exception rich client web apps will be totally normal in a world where HTML5 and all those new JavaScript frameworks will be widely adopted. So now is the time to take action and learn how to write those apps while maintaining our good habits of writing solid, DRY and tested code.
What we will show
All of that will be shown by an example application using BackBone.js so you’ll get a little bit of that, too.
Based on the Ruby on Rails Tutorial book, the second half of Intro to Rails picks up where Rails for Zombies leaves off. You’ll join Rails Tutorial author Michael Hartl for some hands-on coding, including an introduction to version control with Git, test-driven development (TDD) with RSpec, and Rails application deployment to a live server. Attendees interested in following along on their own computers (which is highly recommended) should complete Chapter 1 of the Ruby on Rails Tutorial at railstutorial.org/book before instruction begins.
While Ruby has been both hacker and user friendly for the vast majority of the community, we cannot state the same for Windows developers.
It is undeniable that a huge segment of current and potential Ruby users come from corporate environments where Windows is mandated. Early adopters hit many walls during their experience leaving a bad image of the language. This was due to a lack of documentation, cumbersome installation process or even the lack of support for a particular needed library.
New users wanting to try Rails and/or Ruby libraries suffer from these fundamental issues.
This poses a major problem for any Open Source project wanting to support the huge community under the domination of the Emperor.
Brining open source into corporate environments takes not only time and perseverance, but also creative ways to inter connect systems and solve problems.
My presentation focuses on the challenges outlined above, both proposing and showing how open source tools may be incorporated within the Death Star’s underlying infrastructure.
We will not only cover the Windows-developer side but also how Non-Windows Ruby developers can use certain tools to ease the path of their Windows counterparts. We show how this may be accomplished, guerilla style, one open source tool at a time.
I personally believe that Windows, while most Mac/Linux developers wish it die, is still alive and will be for a long time to come. The force requires balance to exist properly. Let us learn to use the force together.
Leading the way by showing Windows developers the possibilities of open source tools, it is finally possible to open the doors of both enterprise and new business for all developers.
ActiveSupport is the foundation for much of the code Ruby on Rails developers depend on. Many use these set of libraries every day, but few dive into to explore the jewels it contains. In this talk, Bryan Liles will highlight a few of the more interesting features of Active Support 3.
The session will start with what we had before ActiveSupport, and move on to the history of Rails to bring us to where we are today. Special emphasis will be placed on topics such as, Benchmarking, Accessors, Dependencies, and Instrumentation.
In this talk, everyone will learn something. There are quite a few beginner level topics, but the seasoned Ruby on Rails developer will most certainly be exposed to a tidbit they were unfamiliar with as well.
Making a comprehensive (and performant) API for your application can be really challenging, especially without ending up rewriting large parts of what you already have, or being overly dependent on the original application.
This talk will go through some great new techniques for creating a separate service which exposes the data layer of your application for both:
Splitting parts of your application out into services can be an amazing win for easy scale, and for developer sanity – and it doesn’t have to be nearly as hard as it seems.
While most of the talk will focus on techniques and best practices, I will also be announcing the release of a set of libraries for building and working with APIs – and tying them into an existing Rails application with zero to minimal effort.
I’m very excited about the impact that this talk will have on how we develop and view services, and I truly believe my talk is a must-see for anyone looking to scale their application in pieces beyond normal limits.
Groupon has employed many processes, philosophies, and technologies during it’s 3+ year growth. At the center of it all has been a Rails-based stack with an immensely rich and useful toolset. Many design patterns, framework enhancements, and Ruby extensions contribute to the resiliency of the application. This presentation will address what worked, what didn’t, and what sort of SOA + Rails approach Groupon will adopt in the near future. Mike Cerna is lead developer at Groupon, having started on the project in April 2007 during it’s formative years as ThePoint.com.
Beyond Agile? Didn’t Agile just get started? Why would we need to move beyond it already? Agile Development has became the dominant methodology choice for software development, but it’s not just because Agile is now popular that we need to consider what’s beyond it. Just as Agile emerged to address mindset problems with methodologies of the late–90s, ten years later, Agile shows the same symptoms of the methodologies that it sought to challenge. Lessons–learned in a decade of Agile point to the evolution of the next generation of approaches. Deeper explanations of why Agile (or any methodology) works are clearer after a decade of experience with Agile, as are explanations of how it can fail, and what early warnings of failure to look out for. Wether you plan to continue to use Agile, or whether you’re looking to move beyond it, this session will help you to make the best of software development without getting caught up in the methodological conflict that pops up every ten years as a once–revolutionary methodology becomes entrenched. Lets talk about the principles that underly Agile and provide a clearer explanation of why and how things work.
A funny thing happened at DreamForce this year. The company that made it safe for CIOs to buy cloud services bought a wonderful little company called Heroku. DreamForce is not a show a lot of RailsConf old-timers care much about, but it’s a place where CIOs (and the kinds of companies that have such things) go to learn about how to do things better, faster, and cheaper. The tacit endorsement of Rails as the language of the Cloud by a company like SalesForce will change everything. And before you start looking for a newer, more obscure language to get involved in, I want to tell you why it’s going to change almost everything for the better.
This is a talk about the future of Ruby in the Enterprise, and why that future will be good for the Cool Kids too. It’s a talk about why it will make an awful lot of developers happier and more productive, and not just work group developers inside of large corporations. Aaron Patterson has a job because AT&T (a rather large corporation) thinks Rails is strategic for them. They’re right! And he’s making Rails better for all of us. It’s also a talk about why Rails won’t turn into Java, just because big companies need things like management tools, and to integrate with legacy systems.
It’s a talk, in short, full of hope for the future, by someone who’s seen this movie before.
BohConf is the official RailsConf 2011 unconference. At BohConf, we’re going to get our hands dirty writing code and sharing ideas in an open and free-form environment. This hacking-centric event will include community code drives featuring well known OSS authors, a code retreat, a programming competition, and barcamp-style discussions. It is free and will run alongside RailsConf in the convention center. Everyone is welcome at BohConf.
More details will be available on the BohConf website soon. Follow @bohconf on twitter for more updates.
Where and When is BohConf Happening?
BohConf is happening in conjunction with RailsConf at the same time and same place (Baltimore Convention Center). It will be happening Monday, May 16 – Thursday, May 19.
Who Can Go?
Anyone with a RailsConf badge. If you aren’t planning to attend RailsConf but still want to go to BohConf, just register for a BohConf Only pass (its free!). You’ll also get access to the Exhibit Hall and Birds of a Feather sessions.
Who is organizing BohConf?
BohConf is organized by SmartLogic with help from B’more on Rails.
Interested in talking about using Sproutcore with Rails? Have you used Sproutcore in an application? Want to learn more? Come on out to learn and talk about what we’ve been doing to easily integrate Sproutcore with Rails, and make it easy to build rich client applications. There also will be an announcement that is worth being there for.
BohConf is the official RailsConf 2011 unconference. At BohConf, we’re going to get our hands dirty writing code and sharing ideas in an open and free-form environment. This hacking-centric event will include community code drives featuring well known OSS authors, a code retreat, a programming competition, and barcamp-style discussions. It is free and will run alongside RailsConf in the convention center. Everyone is welcome at BohConf.
More details will be available on the BohConf website soon. Follow @bohconf on twitter for more updates.
Where and When is BohConf Happening?
BohConf is happening in conjunction with RailsConf at the same time and same place (Baltimore Convention Center). It will be happening Monday, May 16 – Thursday, May 19.
Who Can Go?
Anyone with a RailsConf badge. If you aren’t planning to attend RailsConf but still want to go to BohConf, just register for a BohConf Only pass (its free!). You’ll also get access to the Exhibit Hall and Birds of a Feather sessions.
Who is organizing BohConf?
BohConf is organized by SmartLogic with help from B’more on Rails.
A BoF for anybody who wants to get better at their TDD or BDD. We’ll discuss obstacles keeping you from testing more, and how other people may have resolved them.
Your production servers and environments are often not something ceded to a specialed system administrator anymore. This sessions brings together people straddling that gap to share advice, tools, and tricks.
Hosting Platforms and Services? (Heroku, EC2, Engine Yard, Rackspace, etc)
Deployment and Version Control
Performance Monitoring and Tuning
Security
In this session we’ll learn how to set up a rails 3.0 application to use sass (rails 3.1 will just have it available to you if the gem is present).
We’ll also cover the Sass syntax:
This will be an informal live coding session with Chris Eppstein, a Sass core team member and the creator of Compass, a stylesheet authoring framework built on top of sass.
An SQL database is very flexible since it does not pre compute how the tables are related (joined). This flexibility comes at a price: you have to fit the domain model into tables, making synthetic constructs in the mapping layer necessary navigating relationships using SQL join operation can be very slow the mental model of your domain is lost when projecting it into tables and joins A graph database is a great alternative when you need to navigate relationship deep or fast. Also, it does not have the impedance mismatch problem of an SQL database. In Neo4j it’s very natural to map objects and classes to a graph. This permits you to model the domain more accurately and provide more useful interaction with the data.
With Neo4j you can do things that are very hard or totally impossible with an SQL database, examples: recommendation algorithms,geospatial analysis and deep hierarchies modeling like file systems or product trees.
In this talk we will give an overview of the different ways of using neo4j: the Rest API, query languages and the native JRuby wrapper. We will show how neo4j can be used to solve classic graph problems like an recommendation algorithm. Furthermore, you will also see how natural and elegant the domain model can be expressed in code by using neo4j in a Rails 3 application.
From Hobocentral.net: What is Hobo?
Hobo is a collection of open-source gems/plugins for Ruby on Rails that help you build anything from throwaway prototypes and internal utilities to meticulously crafted full-blown web apps. The goal: write less code. So much less in fact that it starts to feel like you’re not implementing your app at all, you’re just declaring what you want.
It turns out that the hard part is not going fast, but staying flexible. This is where we think Hobo really shines. If you’ve played with “app builders” before, you’ll know about The Wall. The Wall is the point you reach where you have to give up and do it the old way because that one feature you really need just isn’t going to happen. Hobo doesn’t have one.
—
Whether you’ve never heard of Hobo and are curious, or a long-time user, come learn more about Hobo and meet other developers who use it.
This will be an open forum for questions about Radiant and discussion about what could and should be a part of the core application, and how you could use it in existing applications, and what we can learn from other CMS and extendable apps.
Are you working on an old and big rails app that you need to decompose before it starts to decompose itself and turns into a smelly pile of goo? Not sure how to do it? ( Neither are we.) Or have you already been there and solved those problems? Let’s talk!
BohConf is the official RailsConf 2011 unconference. At BohConf, we’re going to get our hands dirty writing code and sharing ideas in an open and free-form environment. This hacking-centric event will include community code drives featuring well known OSS authors, a code retreat, a programming competition, and barcamp-style discussions. It is free and will run alongside RailsConf in the convention center. Everyone is welcome at BohConf.
More details will be available on the BohConf website soon. Follow @bohconf on twitter for more updates.
Where and When is BohConf Happening?
BohConf is happening in conjunction with RailsConf at the same time and same place (Baltimore Convention Center). It will be happening Monday, May 16 – Thursday, May 19.
Who Can Go?
Anyone with a RailsConf badge. If you aren’t planning to attend RailsConf but still want to go to BohConf, just register for a BohConf Only pass (its free!). You’ll also get access to the Exhibit Hall and Birds of a Feather sessions.
Who is organizing BohConf?
BohConf is organized by SmartLogic with help from B’more on Rails.
Session moderator is author of Ruby and Oracle interoperability gems:
He would like to meet existing and potential users of these gems (discussion group of community) to get feedback and suggestions for future development. This BoF session was held already in previous two RailsConfs and had a lot of attendees.
Tracking ipv6 addresses is a technically challenging problem and is important to the Rails developer community. In this discussion we will discuss, What is ipv4? What killed it? What is ipv6 and how does it rescue the internet? Why is ipv6 important for a rails developer? ipv6 offers better security, but how do you represent ipv6 in network devices, databases (relational and non-relational), frameworks (rails), UI, etc.? In addition to a general discussion on ipv6, we will take you through how Rackspace solved the ipv6 problem.
This session is sponsored by Rackspace
This Birds of a Feather session is for current or aspiring technical leaders in the Rails community. Having a strong peer group of other tech leads is crucial to debate ideas, get advice, and plan for the future. This session hopes to introduce people from different organizations with common experience stepping up to leadership roles from engineering.
How do you manage your time between building features and leading a team?
How do you mentor more junior engineers or folks who are struggling?
What development processes are you using to solve problems in your team?
How do you set technical direction without writing all the code yourself?
This session will be led by Chris Eppstein, the creator of Compass and a Sass core team member.
This will be an informal live coding session where experienced Sass users can ask questions and learn from each other. Bring your best (or worst) stylesheet and let’s discuss it.
New features of Sass 3.1 and Compass v0.11 will be demonstrated.
Techniques and best practices will be shared.
The last year has been an exciting one for Heroku and for the tens of thousands of developers using the platform. In this session, we’ll take a look at the dozens of add-ons, the substantial new developments at the platform level, and our ever-present emphasis on working with developers to create the best possible experience—and we’ll leave plenty of time for your burning questions.
This session is sponsored by Heroku
IndexTank is a great search indexing service, this gem tries to make that any orm stay in sync with IndexTank easily. It has a simple yet powerful approach to integrate IndexTank with any orm and also supports pagination using will_paginate/collection.
Very little is needed to make it work, basically, all you need is that the orm instance respond to id and any attributes you wish to index.
Informal discussion on the unique difficulties in building web applications for Healthcare. Topics could include modeling the complex world of medicine, patient privacy issues, UX challenges, etc.