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.
