Programmers who come to Python from other languages are often surprised to discover how variables work. Things seem even odder when you deal with mutable and immutable values, and see the differences between their behaviors. In this talk, Ned Batchelder reviews how assignment works in Python, when names are connected to values, and how Python’s consistent rules can result in some confusion — until you understand what’s going on, that is.
Ruby is, of course, an object-oriented language. But there are parts of its syntax that aren’t quite object-oriented, such as the “if” statement. In this talk, John Cinnamond tries to push Ruby to its limits, removing and re-implementing parts of the language that we often take for granted. Perhaps this isn’t a way in which we would want to program every day, but it is certainly thought provoking, and gives us greater insight into what it means to describe programming as object-oriented.
Functional programming and object-oriented programming are two well-known and powerful techniques for organizing code and providing programmers with flexibility and power. Each has its own strengths and weaknesses, and each has supporters who feel that their technique is far superior than the other. But instead of seeing these two techniques as being opposites and incompatible, many programmers see them as complementary. In languages such as Ruby, you can work in both styles at the same time, enjoying the best of both worlds. In this talk, Piotr Solnica describes his experiences mixing these two techniques, and how doing so in Ruby helps him to be more effective and expressive in his programs.
As a technical or creative professional, you’re likely talking to clients on a regular basis. The way in which you present and speak can make a big difference — often, the difference between getting work, and getting paid, and not. In this talk, designer Mike Monteiro tells us why it’s important to have good presentation skills, why we shouldn’t be embarrassed to learn how to sell, and what we can do to improve our presentations — so that they will sell our work effectively.
Do you feel like you’re a bad developer, because your code isn’t that good when you first write it? Because it needs to go through a process of editing, testing, and refactoring before you can use it, and before you can share it with others? Well, it’s normal to have to change things, and improve them. Moreover, the best writers — whose prose we believe to be beautiful — have done this with their writing for years, with drafts and additional drafts and additional drafts, ad infinitum, to make things better. In this talk, Ian Whitney describes how to think about drafts (early versions) of course code, and how we should work on our code so that it’ll need improve.
As Web applications grow, we often worry about identifying and fixing performance bottlenecks — and then scaling further, as our applications become even more popular than before. MasterCard, a major international provider of credit cards, has to deal with a set of applications that need to run very quickly, identify fraud quickly and easily, and be extremely fault tolerant. In this talk, Ted Boehm, who works at MasterCard, describes what they have done to create, test, and maintain systems that need to be so reliable and performant. Even if you are unlikely to create an application as large as MasterCard’s, you will likely learn about scaling (and what not to do) from this talk.
Many of us know that in order for a Web application to improve, it’s often a good idea to run A/B experiments: Given enough visitors to a site, you can present different versions to users, and see which one is most effective. This technique is just one way in which you can conduct online experiments. How can we control these experiments, and thus learn more from the results? What sorts of experiments can we run? What sorts of experiments have companies successfully used in the last few years? In this talk, Ronny Kohavi describes the history of controlled experiments, and of online controlled experiments, and provides examples of how they have helped to improve a number of businesses. He also gives us hints for how to create our own experiments, and how to make those provide us with powerful and useful results.