Sessions at Ruby Lugdunum 2012 on Friday 22nd June

The hardest part of joining an open source project for a professional developer is being completely transparent on a mailing list, and submitting your work to public peer review. When you are used to talking about technical details with your manager and colleagues, writing an email to a mailing list can be very daunting: Am I exposing some confidential information here? Have I made a mistake which someone will criticise? Is this message important enough to make an announcement on a public mailing list?

I call this "Shy Developer Syndrome". Developers used to working in a commercial software development environment can clam up when asked to work in public.

There are some straightforward ways to help experienced developers gain confidence in working in public forums, and gain the respect of their peers in open source projects. This presentation will outline some of the strategies which have worked in the past for me.

Odors are communication devices. They exist for a reason and are usually trying to tell us something.

Our code smells and it is trying to tell us what is wrong. Does a test case require a lot of setup? Maybe the code being tested is doing too much, or it is not isolated enough for the test? Does an object have an abundance of instance variables? Maybe it should be split into multiple objects? Is a view brittle? Maybe it is too tightly coupled to a model, or maybe the logic needs abstracted into an object that can be tested?

In this talk, I will walk through code from projects that I work on every day, looking for smells that indicate problems, understanding why it smells, what the smell is trying to tell us, and how to refactor it.

Constants are a rich and under-documented topic in Ruby. We are going to cover them in detail, their relationship with classes and modules, nesting, resolution algorithms, dynamic API, etc. At the end of the talk we will connect the dots to explain at a high level how constant autoloading works in Ruby on Rails.

This talk will show how to use ActiveWarehouse-ETL to extract, transform and move your data around in Ruby, and what other people do in real life with this toolkit.

1# Beginner guide to ActiveWarehouse-ETL

Gem presentation (concepts etc)
Beginner examples of data processing

2# Real-life examples all in Ruby:

Extracting data from a CRM to build a metrics dimensional dashboard (business intelligence)
Extracting and geocoding places before publishing a map on the web
Adapting data for consumption by COBOL systems
Cleaning and extending the CRM
Extracting only what changed (aka Change Data Capture)

Sleep: we all do it, and yet somehow it's hard (as most of us can attest every morning). It's also really relevant: as thinkers, creators, and problem solvers, anything that makes our brains less effective matters. Missed sleep makes a difference -- even two fewer hours a night quickly produce measurable cognitive impairment. Things get more interesting when we look at why it's so hard: our sleep cycles are determined by our internal clocks, which often put us in conflict with society's timetables, leaving many of us in a state of "social jet lag", as if we'd been traveling a timezone or more every day. That's not how any of us want to code (or live), I think, and by understanding how and why so many of us are constantly tired, we can start to make things better.

Keeping your front-end code clean is hard. Before you know it you’re suffering from CSS specificity issues and not-really-generic partials. Find out how to keep things tidy using the HTML5 document outline and modular Sass & CoffeeScript, for truly reusable code.

In times when applications get more and more split up into small pieces that have to communicate with each other it’s critical to have systems in place that make this communication as trouble-free as possible. This talk covers what we did at Engine Yard to improve our inter service communication and how you can apply that to your own infrastructure.