We programmers tend to think of ourselves as concrete, logical thinkers. We work from step 1 to step 2 through to step N. So we say. But real life is not like that: One minute you have no idea how the new design will come together and the next, well, there it is. One minute you haven’t a clue as to why the program is doing that and the next it is all just obvious. And we have all seen code that is wonderful — or horrible — in some indescribable way.
In this talk Russ Olsen will explore the role of insight and intuition in programming: How does intuition work? How do you generate more of those insightful AHA moments? And when should you ignore that voice whispering into your inner ear?
Practicing Test Driven Development (TDD) is like falling in love. It may first seem like all your development problems will disappear. However, it’s not all unicorns and rainbows. You have to work at it, and keep working at it, for the rest of your development life. It is hard, and it’s natural to question whether the value is worth the effort.
So why do it? Why would you bother going through all that trouble, dramatically changing the way you code, learn new domain specific languages, and initially slow down the rate at which you produce code when you have no time to lose?
This talk will answer the “why” by sharing my experience of passing through the five stages of grief (denial, anger, bargaining, depression, and acceptance) as I learned TDD, and how acceptance grew to love.
You will walk away from the talk with techniques for maintaining and strengthening your relationship with TDD. Test frameworks and languages may come and go, but the fundamentals and value of TDD remain.
Impress your friends, scare your enemies, and boost your productivity by 800% with this live demonstration of Vim and Tmux. You will learn how to build custom IDEs for each of your projects, navigate quickly between files, write and run tests, view and compare git history, create pull requests, publish gists, format and refactor your code with macros, remote pair program, and more, all without leaving the terminal. Come prepared to learn and ask questions; this is serious business.
Scalability today is no longer a question of which programming language you use, or (largely) which web architecture you choose. Instead, scalability is a matter of how you handle two things: data distribution and message passing. This talk is over a few ways of solving both: distributed data structures and messaging patterns.
From DRB, XMPP, and AMQP to Resque and Rails 4. Running a background worker process is a tool I’ve reached for often, and while the underlying tools may change, the same problems seem to crop up in every one. A failed request serves your fancy custom 500 error page, but what about a failed job? Is there such a thing as a “reliable” queuing system that will never lose OR double process any jobs? Are we talking about “simple” asynchronous method calls on models or should we build “pure” workers with only the knowledge of a single task? What does “idempotent” mean again? Please allow me to enliven the debates.
Developers are rational thinkers who take objective decisions. Yeah, sure. If that is the case, how can we disagree on so many things?
Examples are all around. Why do Rubyists and Java developers despise each others’ designs? Why do people try hard to fit static typing and distributed environments? Why do Windows programmers loathe the command line? Let me try answering these questions, with a few hints from cognitive psychology.
This talk is not about testing, nor is it really about mocking. However, analyzing a mock object library is a great way to showcase advanced Ruby topics. Have you ever wondered exactly how a mock object library does what it does? You can understand it!
This talk uses a simplified mock object library as the basis for delving into topics such as metaprogramming and the Ruby object model. The goal is to increase the knowledge of these topics in the Ruby community. With this know–how, you will be better suited to build from and contribute to common Ruby tools that use them.
This speaker believes that the best way for programmers to learn is to watch each other work. We’ll leave slides behind and focus instead on the greater information density achieved through live coding. We’ll discuss the strengths and weaknesses of real code, and refactor it right onstage. As we do so, we’ll bump into lots of meaty topics:
Potential downfalls of the ‘extract module’ refactoring (aka ActiveSupport::Concern).
The pros and cons of Dependency Injection.
How two good OO design ideas (like SRP and Tell Don’t Ask) can contradict each other, and what to do about it.
How well–placed functional programming can improve a codebase.
Whether the Law of Demeter should be followed religiously, and what it means if that’s hard to do.
Why fast tests are usually good tests, and vice versa.
Audience participation is strongly encouraged, as is stealing the speaker’s Vim tricks for your own use.
Tests are supposed to save us money. How is it, then, that many times they become millstones around our necks, gradually morphing into fragile, breakable things that raise the cost of change?
We write too many tests and we test the wrong kinds of things. This talk strips away the veil and offers simple, practical guidelines for choosing what to test and how to test it. Finding the right testing balance isn’t magic, it’s a magic trick; come and learn the secret of writing stable tests that protect your application at the lowest possible cost.
In the second half of 2012 I “quit my job” as a traditional Ruby/Rails consultant in order to become a consulting pair programmer. After spending hundreds of hours pairing with dozens of developers from around the world, I’d like to share some of my observations. We’ll talk about the mechanics of ad-hoc remote pair-programming, but more importantly about why I think widespread pairing is important to maintaining the health of the Ruby community. Whether you work solo or you pair regularly, you should leave this talk empowered and excited to broaden your pair-programming horizons.