Y Not- Adventures in Functional Programming by Jim Weirich
One of the deepest mysteries in the functional programming world is the Y-Combinator. Many have heard of it, but few have mastered its mysteries. Although fairly useless in real world software, understanding how the Y-Combinator works and why it is important gives the student an important insight into the nature of functional programming.
Join with us on this journey of understanding. Be prepared to curry your functions and bind your lambdas as we delve into the whys and wherefores of this paragon of functional programming. Although you will probably never have a need for the combinator, the effort put forth to understand it will improve your functional programming chops. This talk is not for the faint of heart, but the successful student will be richly rewarded.
Also, you will understand why "Y-Combinator" is the perfect name for Paul Graham's start-up funding company.
Bret Victor - Stop Drawing Dead Fish
People are alive -- they behave and respond. Creations within the computer can also live, behave, and respond... if they are allowed to. The message of this talk is that computer-based art tools should embrace both forms of life -- artists behaving through real-time performance, and art behaving through real-time simulation. Everything we draw should be alive by default. Part 1 talks about the potential of the computer as a new visual art medium. I show a collaboration between art and artist, with the art behaving through simulation, the artist behaving through performance, and the two of them working together, responding to each other. Part 2 demonstrates a tool for "programming" how art should behave and respond. The artist directly manipulates art objects on the canvas, the way that visual art has always been created since the time of cave paintings. The tool is based around direct, geometric construction rather than indirect, algebraic "code". Part 3 is a short performance.
Bret Victor - Inventing on Principle
Jim Weirich - The Building Blocks of Modularity
Many words of programming wisdom have been written to promote the idea of low coupling between modules. “Prefer delegation over inheritance”, “The Law of Demeter” are examples of these words of advice. But why does delegation introduce less coupling then inheritance. And how does the law of Demeter reduce coupling. To understand these issues, we will look at the concept of “connascence” how it applies to creating modular Ruby programs.
Jim Coplien - Reflections on Reflection
Jim Coplien believes that we have done OOP the wrong way for 40 years, and suggests an approach to reflection based on the DCI paradigm and influenced by the human society.
Katrina Owen - Therapeutic Refactoring
Enter deadline center stage, exit best practices, quietly, rear stage left. The results are rarely pretty. Refactoring can pry panic’s fingers away from your poor, overburdened adrenal glands and restore your sanity. Not that it went missing, of course. Never that! This talk will cover the two reasons why refactoring works as therapy, explore a effective strategies to ensure that the rubber meets the road, and contains before and after shots of ruby code that has served therapeutic purpose.
Delicious Controversy: Docs & Tests by Thomas Meeks
Self-documenting code is a pipe dream. TDD (or BDD) is not the panacea of testing. In the pursuit of test coverage we've forgotten what really matters: getting things done. Lets talk about putting documentation and testing into their proper place. Tools that ease maintenance, help other developers join a project, and reduce bugs.
Rails' Insecure Defaults by Bryan Helmkamp
Out of the box, Rails provides facilities for preventing attacks like SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and more. As a result, it's considered one of the most secure web application frameworks available. Digging deeper, however, you can find a number of places where Rails' default behavior is not as secure as it could be. This talk will focus on longstanding, known weak spots that create risks for your application and business if you are not aware of them.
Stephan Hagemann Wrangling Large Rails Codebases
Growing a Language, by Guy Steele
Guy Steele's keynote at the 1998 ACM OOPSLA conference on "Growing a Language" discusses the importance of and issues associated with designing a programming language that can be grown by its users.
Corey Haines - Fast Rails Tests
Look at your Rails unit test suite. Now look at mine. Now look at yours again. Mine are sub-second. Yours aren't. Having a slow unit test suite can hinder an effective test-first or test-driven approach to development. As you add tests, the suite starts to slow down to the point where you stop running them after each change. Some people even talk about multi-minute unit tests suites! Band-aids like spork are just covering up the problem. Test-driven development is a major player in keeping your design malleable and accepting of new features, but when you stop paying attention to the messages your tests are sending you, you lose this benefit. In this talk, I will go over some techniques for keeping your test suite lean and fast. Along the way, we'll discuss the design improvements that come out of these changes. Now, look at my unit test suite again. Yours can be like mine.
Jonathan Weiss - Ruby on Rails Security
Refactoring Fat Models with Patterns by Bryan Helmkamp
"Fat models" cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle (SRP). "Anything related to what a user does" is not a single responsibility. Early on, SRP is easier to apply. ActiveRecord classes handle persistence, associations and not much else. But bit-by-bit, they grow. Objects that are inherently responsible for persistence become the de facto owner of all business logic as well. And a year or two later you have a User class with over 500 lines of code, and hundreds of methods in it's public interface. Callback hell ensues. This talk will explore patterns to smoothly deal with increasing intrinsic complexity (read: features!) of your application. Transform fat models into a coordinated set of small, encapsulated objects working together in a veritable symphony.
The DCI Architecture: Supporting the Agile Agenda by James Coplien
- The vision of object-oriented programming was to capture the end user mental model in the code. Until recently, programming languages weren't able to do that. With DCI, we can now use most professional programming languages to achieve the object vision—which is curiously similar to the goals of Agile software development. We now can capture both domain structure and structures from user experience analysts
Sandi Metz - Less - The Path to Better Design
Refactoring from Good to Great by Ben Orenstein
Most developers know enough about refactoring to write code that's pretty good. They create short methods, and classes with one responsibility. They're also familiar with a good handful of refactorings, and the code smells that motivate them.
This talk is about the next level of knowledge: the things advanced developers know that let them turn good code into great. Code that's easy to read and a breeze to change.
These topics will be covered solely by LIVE CODING; no slides. We'll boldly refactor right on stage, and pray the tests stay green. You might even learn some vim tricks as well as an expert user shows you his workflow.
Topics to cover include: * The Open-Closed Principle * The types of coupling, and their dangers * Why composition is so damn great * A powerful refactoring that Kent Beck refers to as "deep deep magic" * How to destroy conditionals with a NullObject * The beauty of the Decorator pattern * Testing smells, including Mystery Guest and stubbing the system under test * The stuff from the last halves of Refactoring and Clean Code that you never quite got to :) organizers') Obviously, my credibility relies entirely on this talk being awesome, so come ready to laugh, learn, and enjoy yourself.
People the missing ingredient by Joe O'Brien
We spend a large portion of our time thinking about code and technical project issues. What about the people side of things? The majority of project failures occur because of people, not technology. What we need are guides that help us navigate the waters between the people around us.
People Patterns introduces my latest effort to capture the subtleties and nuances of interpersonal relations. I'm distilling a lot of experience, a bit of psychology and a substantial amount of research and have come up with a series of patterns that can help everyone be more successful in teams and at work. How do you have those critical conversations? How do you get your point across when you think the other person is incompetent? Come and help me reveal these and join a lively discussion.
The Insufficiency of Good Design by Sarah Mei
We all want to write good code, and there is no shortage of advice on how to do that. SOLID. SOA. SRP. LoD. These are important - without them, we'd all be writing lousy code. But none of them address the single factor that has the biggest impact on the quality of a codebase.
That factor is Other People. The people you're working with affect the codebase more than you do, in aggregate, if there's more than a few of them. And it's not just the individuals. How your team is organized, how it's managed, and how it communicates all leave unmistakeable fingerprints on the code. Over time, a codebase grows to resemble its creators, reflecting the good and the ugly of the individuals, as well as the good and the ugly of their relationships.
This is not always a disaster. But it means that a team of really smart individuals can, together, end up writing terrible code. And it means that a lot of issues that get labeled "software design problems" cannot be solved by merely applying the right software design principle. A team can struggle with a problem like this for months, and then a small, often-inadvertent adjustment to the team dynamics makes the problem suddenly tractable.
I'll show you some common "design" problems in Rails applications that actually stem directly from the structure of a dysfunctional team. I'll talk about what you can do to solve them, and I'll give you some tools for distinguishing between those types of issues and plain old lousy code. You'll gain a new appreciation for the invisible forces that guide our design decisions day-to-day.
Hexagonal Rails by Matt Wynne
In the early days of a project, Rails absolutely dazzles.
Tragically, the very same forces that make it so easy to add new features to a brand new Rails application are the ones that start to hold you back as the number of features grows.
Your test suite gets slower and slower, and refactoring becomes more and more of a chore. Everything seems coupled together, and it's hard to see much of a structure other than the MVC triad.
In this talk, Matt explains why this happens, and shows you a way out, using a ports-and-adapters or hexagonal architecture to introduce a separation between your application's domain logic, and the Rails framework.
With practical examples, you'll learn how to apply techniques like:
- domain services
- value objects
- view models
This talk is suitable for advanced Rubyists who want to enjoy the benefits of Ruby's great Object-Oriented and functional programming features in their Rails applications.
Bio: Matt Wynne works as an independent programmer and consultant, helping teams like yours learn to enjoy delivering software to the best of their abilities. He is a core developer on the Cucumber project, and co-author of The Cucumber Book. He blogs at mattwynne.net and tweets as @mattwynne.
Gary Bernhardt - WAT
Justin Searls - To Mock or Not to Mock
Great developers need to know why they do what they do. Only then can they hope to apply, adapt, and even drop their practices in the context of each situation. Unfortunately, very few developers can clearly articulate why they do (or don't) use test doubles—be they mocks, stubs, fakes, or spies. This talk aims to raise the level of discourse on this topic. By better understanding why we use test doubles, we can write faster, clearer, and more informative test suites; even if it means choosing to never use a stub or mock again!
Many argue "mocks suck," because the resulting test won't be realistic enough to gain any significant confidence that their code works. Others use mocks to control the outer boundary of a test's execution from expensive, hard-to-setup dependencies (e.g. by faking a database or network resource). Others still see mocks as a "setup of last resort", using them to manipulate what would otherwise be an integration test in order to reduce the pain of hard-to-test situations. Finally, some developers use test doubles in place of nearly every dependency in every test, and their reasons are probably the most poorly understood of them all!
This talk will provide a broad-stroke survey of the different ways developers use test doubles, with the goal that we leave with a more sophisticated means of communicating on the topic. The talk will also provide practical guidelines for how adherents of each of these varying philosophies could better use (or avoid) test doubles. Finally—if the audience is kind—I'll share my own opinion on how and why I prefer to use test doubles (and maybe a little on what I learned writing my own test double library, "gimme").
Thinking in Objects - Josh Susser (34:07)
Ruby is one of the best object-oriented languages around. Ubiquitous objects, duck-typing, mixins, expressive syntax with low ceremony, powerful reflection and metaprogramming. But Ruby has a mixed heritage that incorporates functional and procedural models along with OOP. This flexibility provides many options for how to solve problems, but it can also lead even experienced developers into a confusing mix of programming styles and hard-to-understand software designs. But what can we do to keep things simple and easy to understand?
Alan Kay is often quoted as saying “Perspective is worth 80 IQ points.” So let’s get the right perspective on Ruby and look at it from the direction of objects and OOP. This talk examines the fundamental concepts of object-orientation, and presents a simple model for how to think about objects and object-oriented programming.
Justin Searls - Budgeting Reality: a New Approach to Mock Objects
Some say "mocks suck," because they reduce a test's realism and with it the confidence that the code being tested actually works. Others use mocks to demarcate the outer boundary of an application, guarding the test from expensive or external dependencies (e.g. by faking a database or network resource). Still others see mocks as a "setup of last resort", using them only to mitigate the pain of hard-to-test code. Finally, some developers mock out every collaborator in every test, and their rationale is probably the least understood of them all!
This talk will serve as an opinionated (if broad-stroke) survey of the different ways people use test doubles (be they mocks, fakes, stubs, or spies). Our goal will be to establish a more sophisticated means of communicating on the topic. We'll discuss the pros & cons of the different approaches toward mocking, the smells of test double abuse, and the lessons I took away from writing my own test double library.
Sandi Metz - SOLID Object-Oriented Design
Talk from the 2009 Gotham Ruby Conference.
Sensible Testing by Justin Leitgeb
Most Ruby programmers spend significant time writing, maintaining and troubleshooting automated tests. While recent discussions in the Ruby community have focused on whether we're writing too few or too many tests, this talk looks at how we can write "sensible" tests that allow our applications to deliver the most possible value with the least amount of development time and effort.