Your current filters are…
Register, get settled and enjoy a light breakfast with your fellow attendees.
Someone once told me that software development is a constant battle against complexity. Over the past three years we've built several large systems at GitHub and if anything, that saying is an understatement. Things like tight coupling, insufficient testing or documentation, lack of versioning discipline, and underspecified design documents can easily lead you down a path of ruin. In this talk I'll cover many of the techniques we use at GitHub to defend against complexity in our Ruby systems, including Readme Driven Development, Semantic Versioning, TomDoc, Git/GitHub workflow, modularization, metrics, and exception reporting.
by Anthony Eden
The effects of API design will likely live with your project for a long time, often beyond your tenure with the project. Yet good API design is very rarely discussed and often leads developers to the conclusion that good APIs are something that "we know when we see them."
This talk will attempt to layout a set of fundamentals for good API design so that we can begin to really understand the difference between well-designed APIs and those that are mediocre. It will also explain about various trade-offs that are made when designing APIs and some of the pros and cons that come with each trade-off. Finally we'll take a look at some well designed APIs in open source Ruby projects and see what makes them shine.
Why we do this talk
Why you should care
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.
by Joseph Wilk
During an hour of programming what do you learn about your performance? How did that last refactoring go? How does that hour compare to the previous hour? How about against last week or last month? How are your habits as a programmer improving? How does your refactoring pattern differ from a masters like Martin Fowlers?
Professional Tennis players learn from detailed statistics about how they performed in a game and use this information to become better players.
Why don't we do the same in Programming? I want to demonstrate how we can, especially how we as individual programmers can help limit the time we spend in the red (failing tests) while developing. How long we spend in the red and how often can reflect on how we are working as programmers. Joshua Kerievsky created "The Limited Red Society", a group of practitioners that have learned how to effectively reduce red time while test-driving and refactoring code. I want to introduce this society to the Ruby world and some of the tools and ideas I have been working on.
We can gain detailed insight into your programming patterns while using a TDD flow by recording the state of your tests every time you run them. From these detailed metrics we can start to visualise how you work. How long did we spend in the red with that failed test? Was that test we wrote too big a step leaving us stuck in the red for too long? Did we spend a long time in the red because we were shaving a Yak? How many unit tests did we just break with that last change?
Why do some people keep talking about diversity? Who cares if we're all the same? So long as we're not technically discriminating against anyone, that means we're good, right? If we only get applications from white dudes, that must mean that white dudes are the only ones out there. Right? Right?
When we feel threatened, we find comfort among people who seem most like us. As specialization increases in the community, we glom on to people who look like us, talk like us, and think like us. There's safety in a crowd.
But there are real dangers in becoming too much alike: monotony breeds more monotony. Real innovation happens when you think different than everyone else. What happens when we ruthlessly eliminate different thinkers, as we winnow the stack of resumés to those that seem most likely to "fit in"?
Come to this talk to find out what you can do to diversify - yourself, your organization, and your peers - and how you can help grow a better, stronger, more diverse community.
A work in progress - but there's likely to be bad jokes, whisky, and maybe even some computing involved.
by Joe O'Brien
No one can argue that the software development industry has changed drastically in the last 10 years. No one can argue that it will continue to change.
This is a call to arms. We know that the education system is broken for software developers. We complain about it. It is not the school's problem, this is ours. It's time we do something about it.
This talk is an action plan. This is not a wish list. This is a way for companies to train their teams to lead, not follow. The plan lays out how to deal with turnover, existing skill sets and skills coming out of college. Borrowing lessons from each other consulting and product companies will both benefit.
In the end, you will create another competitive advantage.
Short and sweet, usually a highlight of any conference.
A chance to wind down, sink a few and socialise at the River Café.
16th–18th June 2011