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.
Ruby developers are living in the world of Active Record. No matter what ORM you’re using, it’s an implementation of the Active Record pattern. There’s been a recent discussion in our community about separating business logic from the persistence concerns. People are experimenting with different approaches but they still use an ActiveRecord ORM under the hood.
In this presentation I will give you an introduction to the development of DataMapper 2 - the first true implementation of the Data Mapper pattern in Ruby language. I will talk a little bit about ORM patterns and show you core parts of DM2 that already exist and the ones we’re going to build soon.
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.
I taught myself to code and went from zero to a full-time programming gig in under a year. I will discuss my story, tools for new developers, and what I’ve learned from coaching with RailsGirls, particularly what we can do to teach new programmers, with a focus on women.
RubyMotion is a revolutionary toolchain for iOS development using Ruby. With RubyMotion, developers can finally write full-fledged native iOS apps in Ruby, the language you all know and love. In this session, we will cover what RubyMotion is and how easy it is to write an app with it.
What does really happen when we call a method? How do the different Ruby implementations actually figure out what code to execute? What plumbing is going on under the hood to get a speedy dispatch? In this talk we will have a look at the internals of the the major Ruby implementations, focusing on their dispatch. From look-up tables and call site caches, to inlining and what on earth is invokedynamic? Fear not, all will be explained!
Sure graph databases are really cool and have a timestamp dated next week, but do you know when you should actually use one? Sometimes living on the bleeding edge pays off and in this talk, I’ll show you how you can simplify your application and model your data more naturally with a graph database. They are suited towards a specific problem that is actually quite common in today’s applications and they may even apply to that thing you’ll be working on during this talk!
Everyone knows the rule “fat models, thin controllers”. It’s really efficient when it comes to simple applications, but when we have an enterprise application, suddenly our models seem to look a bit overweight. Actually they are fat and ugly. I want to show a few examples of using DCI architectural pattern (which is complementary to MVC pattern) with Rails as a potential solution for these problems. My personal goal is to encourage people to experiment with the code and thinking outside the box (Rails box). Start thinking through domain model, not database design, to look at Datamapper pattern and DDD concepts. However, DCI is a good start to enter this enterprise world.
You know you should be testing all the time, but do you know why you are testing all the time? One of the main benefits of testing all the time is that it lets you refactor with impunity. Unfortunately too many times we leave the “refactor” out of the red-green-refactor. In this talk I will convince you that you should be refactoring all the time and I’ll show you some of the techniques on how you can do it. With good refactoring techniques and regular refactoring even the hairiest of codebases can be tamed.