If It Bleeds, It Leads

Ruby

Evan Light

4 talks

If It Bleeds, It Leads

by Evan Light

In his talk titled "If It Bleeds, It Leads" at the Ruby on Ales 2013 conference, Evan Light discusses the increasing complexity in the Rails community, contrasting it with the simplicity that initially drew developers to Rails. He introduces himself as a freelance mentor and code janitor, emphasizing his passion for helping developers improve their software practices.

Key points covered in the presentation include:

- Rails Complexity: Light notes that while Rails was designed for small applications, there's a growing trend towards extreme object-oriented practices that complicate development. He highlights the importance of understanding how Rails’ defaults can simplify development rather than complicate it.

- Decision-Making: He references "The Paradox of Choice" to illustrate how developers often struggle with overwhelming options when they lack expertise, leading to poor decision-making.

- Pop Culture in Development: Light discusses the tendency of developers to rush toward the latest gems and tools, using the phrase, "If it bleeds, it leads," to underscore the focus on trending technologies rather than foundational practices.

- Design Patterns: He emphasizes the importance of recognizing and employing solid design patterns, outlining the limitations of Active Record and showcasing alternatives like the Data Mapper and the Repository pattern.

- Emerging Solutions: Light introduces the cells gem as a solution for templating issues in Rails, allowing for a clearer organization within MVC architecture.

Several anecdotes underscore Light’s arguments, such as his experiences working with varied clients who often make decisions without enough experience in Rails, leading to inefficiencies. He also reflects on his motivations for presenting—driven largely by the desire to correct misinformation in the community.

In conclusion, Light advocates for:
- Embracing Rails’ Defaults: Developers should work within the constraints and conventions that Rails offers, rather than rebelling against them.

- Building an Augmentative Stack: He encourages developers to innovate within the existing Rails infrastructure instead of chasing the latest trends, thereby enhancing both the community and the overall development experience.

00:00:20.480 Hello everyone, I'm Evan Light. I call myself a freelance mentor and code janitor. I used to just describe myself as a code janitor, which means I clean up a lot of other developers' code.

00:00:26.560 As a freelance mentor, I like to help other people write better software, usually through remote pairing or by assisting them in cleaning up their own software.

00:00:32.800 These are a couple of the things I do. I run Ruby DCamp, which is an unconference—an open space event in the DC area. It's about 75 people and it's going into its sixth year.

00:00:43.120 Typically, it occurs at the end of September or early October. It includes three full days and three evenings. The first day is an all-day code retreat. If you're not familiar with what that is, a quick Google search can help.

00:00:55.840 The next two days are an open space event. You can also Google open space technology if you're curious to learn more about it. Essentially, DCamp takes the whole conference model and flips it upside down.

00:01:09.840 Our usual conference focus is on the hallway track. It's not completely unstructured, but it is a unique format. If you're interested, please talk to people and look around. It's not exactly an invite-only event, but you typically need to know someone to get in.

00:01:27.200 I invite a few people, but the majority of spots are up to others to fill. Additionally, I'm involved in the Ruby Freelancers Podcast, which is pretty much what it sounds like—a group of fellow freelancers who focus on Ruby work, discussing how to get more work and manage clients.

00:01:50.240 What I also haven't mentioned yet, because we don't have a logo yet, is that I started doing a screencast with Z. Spencer and a few other folks called Growing Software Developers, which is geared towards helping new software developers become better.

00:02:08.959 Now, having said all that, I'm sure most of you are familiar with this comic strip. If you're not, just take a quick look. In a nutshell, this is why I do presentations: because someone is wrong, and it really irritates me, so I have to address it.

00:02:21.200 That's why I'm here today. It's also why I write blog posts, though I usually don't do it often—only when something really bothers me. When I see someone who's very wrong, I feel compelled to write a blog post about it.

00:02:40.080 This presentation is inspired by a blog post I wrote about loosely coupling various aspects in Rails, which has become a common trend. I'm sure many of you are familiar with it because, well, this is a Ruby conference, and most of us work in Rails.

00:03:01.920 As I've mentioned, the latest fashion seems to be aiming for extreme object orientation with Rails, but the truth is, Rails isn't exactly designed that way. Rails, as a framework, is meant to make small application development efficient—emphasis on 'small.' It excels at small app development, utilizing shortcuts that depend on selective tight coupling.

00:03:27.200 For example, there's the coupling between views and controllers in Rails, where we pass instance variables around. While some people consider this practice undesirable, it's actually a very handy shortcut to look up data, get it into the template, and be on our way.

00:03:40.000 As most of you probably know, Rails comes with many constraints, and these constraints are intentional. It's opinionated software that helps with about 80% of our apps, but what do we do for the remaining 20%?

00:03:51.599 What techniques do you use? What gems do you employ? That's a tricky topic because it ultimately depends on the choices available. There are countless patterns, books, and Rails recipes out there. Thus, it becomes more of a heuristic—an experience-based approach.

00:04:03.200 If you're a relatively new Rails developer, you might feel a bit lost. Sarah mentioned in her talk yesterday that anecdotes are poor evidence, and I tend to agree. Therefore, I did a lot of research before creating my slides.

00:04:30.880 However, even after completing the research, I found myself continuing to dig deeper, almost obsessively. I read through several different books and gathered a wealth of citations, which I've linked in my slides.

00:04:46.159 These slides are created using a tool called Keydown. They are essentially just HTML and JavaScript, and I'll be putting them up on GitHub Pages after this presentation. You won't need to take extensive notes unless you find something particularly interesting.

00:05:05.919 I want all the source material to be easily accessible. The first book I'll mention in passing is 'The Paradox of Choice,' which examines how people cope with an overwhelming number of options.

00:05:22.880 I've heard about this topic from a talk at Google, and there's a YouTube video featuring the author discussing it. One notable quote from the book is: "Choosing well is especially difficult for those of us who are determined to make only the best choices."

00:05:43.120 As a consultant, during my three and a half years of freelancing, I've worked with a variety of clients. Many of them hire me because they lack experienced Rails developers, and they often struggle to make decisions.

00:06:05.440 These shops often attempt to make choices on their own, without the benefit of expertise. So, what choices do average developers make? Let's dive into that.

00:06:20.320 We would be better off if we embraced certain voluntary constraints on our freedom of choice instead of rebelling against them. Sounds a little bit like Rails, doesn't it?

00:06:35.600 One interesting phenomenon regarding choice mentioned in the book is that we are not as rational as we think we are when making decisions. We often tend to lean toward easily available information rather than reliable data.

00:06:51.440 The author presents a straightforward example. When shopping for a new car, one of the best actions you could take is to visit the Consumer Reports website, which provides extensive research and reliable data.

00:07:07.920 Say you learn that the safest car is a Volvo, but a friend insists that Cadillacs are safer based on their own experience. This anecdotal evidence can influence our choices, as we often prefer personal accounts to objective information.

00:07:22.160 Even though some in the room would likely trust Consumer Reports, many people are susceptible to effective advertising. This isn't a condemnation of you specifically, but it's likely a universal tendency.

00:07:39.360 The 'Paradox of Choice' discusses various simple techniques used by advertisers that are reliably effective. I found many examples amusingly relatable as I recalled times when I was influenced by them.

00:07:54.080 Now, shifting gears to software culture: Alan Kay, the inventor of Smalltalk, once said, "Once you have something that grows faster than education, you're always going to get a popular culture." Let’s take a moment to reflect on that.

00:08:05.600 Most of us didn't learn to program in Ruby or Rails during our formal education. We gained our knowledge through blog posts and books, learning from informal education rather than structured training.

00:08:19.360 This situation qualifies us as part of a pop culture. This brings me to a term I've cobbled together: neophilia, meaning a love or obsession with new things. That's us.

00:08:31.440 You probably came to Ruby because you were dissatisfied with something else, just as I came to Rails out of frustration with J2EE. Many of you have likely faced similar experiences.

00:08:48.320 Once you arrived in the Rails community, you may have noticed that there is always a new gem emerging every few months or even annually to replace what you were using before. The question arises: do you upgrade to the new gem?

00:09:08.800 Less experienced developers might rush to adopt the latest hot gem, but I draw an analogy here often expressed in journalism: "If it bleeds, it leads." Just think of how we often prioritize the bleeding-edge tools when discussing trends.

00:09:25.520 In our blogs, conferences, and discussions, we frequently focus on new tools and techniques, defining our pop culture.

00:09:36.480 This is a somewhat obscure reference that I suspect only a few will get, taken from 'Star Trek: The Motion Picture.' In the film, Dr. McCoy tells Captain Kirk that he knows engineers love to change things.

00:09:46.560 That's reflective of what we are constantly doing in the Rails and Ruby community—always innovating with new tools and techniques. However, we don't always have the best ideas; ideally, we refine the poor ones through experience.

00:10:08.560 Let's discuss patterns briefly; patterns are basically examples to emulate, each with preconditions to fulfill. We identify a practice and propose it as a pattern, which then appears in books or blog posts.

00:10:21.760 If a pattern can be imitated, individuals might create tools based on it. Someone comes along and says, 'I don’t want to write the same code repeatedly for similar tasks, so I'm going to implement this as a generic case.'

00:10:36.240 With this, we create tools from patterns and identify the best practice patterns, as the tools have their own suitable patterns. In Rails, there is a general direction we tend to follow.

00:10:56.400 I also want to mention that familiarity can breed contempt. It seems that this year, many are criticizing Rails, claiming it needs to be more object-oriented.

00:11:11.920 This slide includes various likely familiar patterns from Martin Fowler's book, 'Patterns of Enterprise Application Architecture.' If you take away just one thing from this presentation, please consider reading this book.

00:11:30.560 It might be challenging, but it's ultimately enlightening. This book was written in 2003, predating Rails, and it appeared shortly after the J2EE revolution.

00:11:50.080 The patterns discussed there forecast much of what is seen in Rails today. This is eye-opening in understanding how these patterns function and how they could be improved.

00:12:04.720 Now, let's explore some of the post-Rails design patterns we’ve discussed. There’s been a shift in the community focusing on these patterns because some believe Rails has limitations.

00:12:29.120 The prevailing wisdom suggests that persistence and domain logic shouldn't reside in the same class. Recently, active record has seen criticism for its coupling.

00:12:45.360 Active Record, as defined by Martin Fowler, is best represented in the Active Record gem, which encapsulates database access alongside domain logic. However, the UML design of favoring separation of persistence from domain logic is a common belief.

00:13:04.240 But the current usage of Active Record suggests we're largely contradicting its intended use. There's an ongoing conversation about redrafting the traditional patterns.

00:13:21.440 This juxtaposition illustrates how the so-called 'prevailing wisdom' argues for a disconnect between data and logic, but our use of frameworks like Active Record tends to align them.

00:13:37.440 So, rather than fighting against Rails, I propose we embrace Rails' defaults fully. We need to evolve within the existing idioms instead of trying to branch off into uncharted territories.

00:13:53.360 Martin Fowler notes that Active Record is suitable for simple models, while data mappers serve better for complex structures. This indicates that the selection of the pattern is dependent on complexity.

00:14:09.280 So, let's talk about how the Data Mapper pattern differentiates from Active Record. This UML model illustrates the clear separation between the data source, the mapping, and the model.

00:14:27.679 As we pursue more complex data relationships, maintaining separation between the data source and the consulting pattern becomes vital. The demand for this has become apparent in recent discussions.

00:14:44.880 Another contrast comes with the repository pattern, which only exposes necessary methods while keeping the mapping details abstract, simplifying how we work.

00:15:01.200 I stand by the belief that layering and abstraction come at a cost. While people are enamored with separation and layered architecture, they often underestimate the cognitive load associated with managing so many pieces.

00:15:20.000 Fowler’s 'Patterns of Enterprise Application Architecture' offers valuable insights in this regard. It's essential to understand that while layering is beneficial, it may introduce its challenges.

00:15:35.920 With every abstraction, you often create a cascade of changes across your system, altering dependencies and making maintenance a significant effort.

00:15:51.760 EDR is a gem I've recently encountered that implements the repository pattern. It aims to mitigate some of the issues highlighted in our discussions on layer management.

00:16:09.680 Here's a brief overview: EDR utilizes Active Record explicitly as a simple data mapper, allowing separation while still maintaining the advantages of Active Record.

00:16:23.440 However, there are some repetitive conventions within it, which could benefit from a clearer structure within our models to unify our approach.

00:16:38.560 Proposing that Active Record mappings could be dynamically determined through reflection would significantly reduce redundancy and bolster the maintainability of our domain models.

00:16:54.640 The idea is there could be an automatic association retrieval thus stripping down our models to their essentials while improving clarity.

00:17:08.720 The possibility of a domain model existing purely as a Ruby object without database concerns is an exciting prospect. The mixin approach for behaviors at runtime could indeed be worthwhile. But as I've said, I’m very focused on these slides.

00:17:25.600 After this talk, feel free to engage with the EDR team; they might inspire some great collaboration. It seems like a solid bridge towards improving Rails development.

00:17:42.720 I want to additionally provide an overview of Rails templating. To put it bluntly, templating in Rails has been a struggle for a long time.

00:17:58.080 Traditionally, it hasn't changed much, still facing many criticisms for maintainability and testability. Concepts like presenters, decorators, and view models have emerged to try to address these issues.

00:18:13.440 One innovative solution that I encountered is the cells gem, introduced by Nick Sutterer. Cells offer an alternative to partials, creating a cleaner model-view-controller structure within our views.

00:18:27.760 Instead of rendering partials, we can render different controllers that handle various nested components across the system—minimizing the complications involved with instances passing through multiple layers.

00:18:43.680 So, while cells carry some structural overhead, they promise a potential resolution to complexity, focusing on clear paths to manage our environments.

00:19:00.640 Therefore, we must ponder: can we be more Rails than Rails? Cells may have room for refinement, and both Data Mapper 2 and EDR can improve with collaborative efforts.

00:19:15.040 Lastly, I encourage everyone to be mindful of the ideas you advocate for, especially if you’re acting as a pundit. Less experienced developers often look towards Google for guidance.

00:19:31.760 However, they might encounter blog posts and presentations filled with trending ideas that haven’t undergone rigorous testing. As contributors, we need to ensure they aren’t misled.

00:19:55.840 Instead of chasing the latest fad, I suggest we establish agreement on an augmentative stack built atop Rails; identifying that leftover 20% we consistently find.

00:20:07.520 This approach would ease the burden not merely on experts but significantly benefit newcomers who could make meaningful contributions.

00:20:24.000 Any experienced developer understands that not all the new tools and patterns presented are suitable for the average developer, so we must be judicious.

00:20:39.600 Both Data Mapper 2 and EDR could benefit from additional attention and effort, providing a great avenue for improvement. That's all I have for today.

Ruby on Ales 2013