Ruby
Rediscovering Ruby
Summarized using AI
Rediscovering Ruby
by Philip PootsIn the talk titled "Rediscovering Ruby" presented by Philip Poots at the Paris.rb Conf 2020, the speaker explores the evolution of his programming journey, emphasizing the beauty and simplicity of the Ruby programming language amidst a landscape filled with complex frameworks.
Philip begins with a personal anecdote about his cooking experience and how it parallels his software development journey. He introduces the concept of automation in food preparation, which transitions smoothly into his professional life as a software developer, specifically discussing his experience with various frameworks.
Key Points Discussed:
- Journey through Frameworks: Philip reflects on his transition from Ruby on Rails to front-end frameworks like Ember.js and Elm. He notes the initial joy of using Rails and the challenges faced as he grew more experienced with it.
- Learning from Frustrations: He shares specific instances that illustrate the complexities and frustrations encountered while working with various technologies, especially when combining Rails with external systems like Redis.
- Ember.js Experience: Although Ember.js is powerful, he expresses challenges with constantly adapting to its evolving nature and the associated code complexity. He describes feeling overwhelmed by the extensive lines of code in Ember compared to what he finds in Elm.
- Elm as an Educational Tool: Elm is presented as a simpler, functional programming alternative with less complexity than Ember. Philip praises Elm for teaching him core programming principles through a focus on data types and functional programming.
- Ruby Reflections: Returning to Ruby, he discusses his work at Club Collect, where he applied functional programming principles to refactor code, enhancing simplicity and maintainability. He provides concrete examples of templating, report generation, and message attributes, highlighting how restructuring code can lead to elegant solutions.
Significant Examples:
- Templating: Philip showcases a refactored templating system that reduces code while improving clarity.
- Report Generation: He contrasts a messy XML builder approach with a clearer, separate data structure approach, emphasizing better maintainability.
- Message Attributes: A cleaned-up design leads to a straightforward way of handling message templates, showcasing the benefits of separating concerns.
Conclusions and Takeaways:
Philip concludes by celebrating the joy of programming with Ruby and urges developers to embrace creativity and simplicity in their work. He encourages attendees to break away from excessive frameworks and rediscover the beauty inherent in Ruby, advocating for a thoughtful approach to coding that prioritizes clarity and elegance over unnecessary complexity. He leaves the audience with a motivational call to reignite their passion for programming and rethink their coding methodologies.
Overall, this talk serves as an insightful reflection on the evolution of programming practices and a heartfelt homage to the Ruby programming language.
00:00:16.599
Thank you very much. As Tebow said, I wanted to give this talk two years ago. Unfortunately, I wasn't able to make it then, but I haven't given this talk anywhere else in the interim because Paris is really the only place to tell a love story, and like all love stories, the way to a man's heart is through his stomach. This is me before I shaved off the mustache.
The reason I want to talk about food to begin with is that over the last two or three years, I've been doing a diet on and off called the Whole30. It's about limiting what you eat to meat, vegetables, nuts, eggs, and some fruit. So my fridge looks like this... just joking! I'm a software developer; it looks like this now.
00:01:08.660
At university, I had a very good friend who was a sous chef at a Michelin star restaurant in San Andres, Scotland, where I was. He was also a fellow student. We used to eat his meals and talk theology until the small hours of the morning. The first time he came to cook at my house for the first time at the university, he looked around the kitchen and said, 'Philip, where's your chef's knife? You haven't got a chef's knife? Get me a chef's knife! I won't cook without a chef's knife.' He wasn't quite that dramatic, but the first thing I did was get the message on my diet and purchase a chef's knife.
00:01:40.310
For this diet, I eat a lot of this stuff, which requires a lot of preparation, because you want to go from this to something like that. But the thing is, when you're standing in the kitchen every day and you've chopped up the first carrot and you move it out of the way, you still feel like there's a lot of stuff to chop. So I did what any self-respecting software developer would do: I went on the search for automation.
00:02:00.450
I immediately began searching for vegetable choppers. I was browsing through vegetable choppers, reading reviews, figuring out which were the best quality and what they could do for me. I found one that was only available in America after realizing that the plastic ones didn't really function well. But in the end, I found the Alligator from Sweden, which helped me chop vegetables in no time flat. Instead of preparing food every day for 15 minutes, I prepare food one day a week for half an hour and have food for the whole week.
00:02:30.460
When I'm not chopping vegetables, I am the VP of Engineering at Club Collect, where I lead a small remote team that works with Rails and Phoenix. We are a communication department trying to become a communication company. As Tebow mentioned, this is a journey, and it is my story from Rails to the front end with Ember.js, then the Elm programming language, and then back to Ruby again.
00:02:54.500
Let's start with Rails. I've just put in the line of code. It's not very accurate; I'm sure people could quibble over one line of code here or there, but you know Rails is amazing! A lot of us who are Rails developers, whenever we first started using Rails, felt like wizards. We could accomplish so much, and it brought us a lot of joy. We created a lot, and really, in the beginning, Rails looks beautiful and wonderful.
00:03:19.800
As we become more experienced with the framework, I don't know about you, but for me, sometimes when working with it, I put my fork in the bowl and try to do one particular thing. Instead of picking up one small bit of spaghetti that fits in my mouth, I've got a whole handful, a whole mouthful. I don’t want to give just one example; I’m sure you have examples you can recognize from your own experiences.
00:03:43.430
Once, I had to use accepts nested attributes to do something like Google+ Circles back then. We have WhatsApp groups, and the difficulty was that we decided to use Redis to store the friendship data. Redis sets are amazing, and we had to hook up something non-standard Redis along with accepts nested attributes form, using checkboxes. As a young developer, you’re kind of like, 'Okay, it should work. I read the documentation; I do what the documentation says.' Then you spend the next week wondering where all your time went and why it's not working.
00:04:08.910
In this case, it was due to Rails using checkboxes; when checkboxes aren’t checked, nothing goes to the server. You have to handle that manually. Trying to hook up Active Record to a separate database system is straightforward when everything is on the happy path, but can be challenging when you step off that path. I could have talked about autoloading or Active Record in general, but I see frameworks as having buckets to put your code in; they help you arrange your code and reduce the need to think.
00:04:56.810
It helps you implicitly understand how to break things down and arrange your code. The decisions are mostly taken for you, so you don't have to think too much. With all the frameworks on the JavaScript bandwagon, demanding more functionality and features, I went to the Ruby on Rails of the front-end world. This was billed as the convention over configuration framework to rival what Rails was in the back and bring it to the front end. The code count is around 200,000 lines of code.
00:05:43.060
And you know, Ember is great, right? It powers LinkedIn, Intercom, the Heroku dashboard, which many of us may be familiar with. And it works! There's a promise here; you're the Tom Stirrer at the front with a heart above your head, loving it. But then there's a hamster in the background, and the framework is doing all the work for you, except I felt like the hamster with Ember smiling at my fate.
00:06:06.680
The reason is because Ember is a framework that is constantly in development; that's one of its strongest points. But if you're a smaller team or a one-man team, then all of the changes in the framework mean that every version is you relearning what you already knew just to keep up-to-date with it. And when I thought about things more deeply, I wondered why I was dealing with so much code to accomplish tasks that should be relatively simple.
00:06:30.690
I think the JavaScript world is similar; React demonstrated that things could be simpler. Following React led me to realize that the solution wasn't about more buckets to put your code in. It was about simplifying the approach; I need to take a moment.
00:08:24.310
Okay, for some reason, my notes aren't showing. Does someone know how to use Keynote? It's also a very big framework, so I didn't plan on a demonstration of what it's like to use a web framework, but here we go.
00:08:26.020
Elm is wonderful; it’s a very simple, strongly typed functional programming language for the front end that compiles down to JavaScript. Even if you include the additional libraries you need to build a web application, it’s an order of magnitude smaller than Ember; Ember was almost 200,000 lines of code, while Elm is nearly 10,000 lines of code. It’s functional programming in its purest form.
00:08:51.500
When you're learning Elm, you are learning general principles and nothing more. When I was with Ember, it felt like I was learning the framework. With Elm, it felt I was becoming a better and more experienced programmer due to its focus on data types.
00:09:10.530
We saw that in the last talk: focusing on data. In Elm, we don't have objects; you have to boil problems down with data structures. You must think upfront about what your problem looks like and what your data types should be in order to solve it. You're using functions to operate on those data types.
00:09:37.900
The other thing is, Elm is beautiful! It looks strangely familiar if you squint. It’s readable, uncomplicated, and enjoyable to write. I find it interesting that three years ago, I came to the Elm Europe conference. It attracted people interested in these things. I had an interesting conversation with someone in the hallway.
00:10:15.020
We were chatting, and I thought, 'We don't do Facebook's Facebook stalking as developers; we go home and check people's GitHub.' I had been talking with Michelle Martin, one of the organizers of the conference. This took my interest; I had never seen anything like it before! I've been a real programmer all my career, but here we had a web framework with less than a thousand lines of code, an ORM with less than a thousand lines, and a state machine implementation of only 44 lines.
00:10:39.280
There was a templating library in 37 lines of code, which was smaller than the template itself. It was beautiful, and one consistent feature across all these libraries was that they focused on being small, using data structures, and mapping the problem to data structures.
00:11:07.610
So let's talk about Ruby and my experiences. After I got a job with Club Collect, which I really enjoy, I was given time to do a lot of refactoring work, improving a Rails codebase. I have three problems I'd like to share with you before I give you my conclusions. This also proves that you don't have to step outside of Rails to implement some of this.
00:11:32.670
The first is templating. Before this, I didn't really understand the code, but here's what I came up with. It's maybe not so fascinating, but if you look at the depth of the pull request, you can see that we added 2,000 lines of code but lost almost 12,000 lines. Just for the record, this does exactly the same thing. Those added lines of code include tests to ensure that the templates generated are identical to those that were created before.
00:12:04.670
The benefits here are that it's clean, simple, small, and in my opinion, really beautiful. This was using the Moke two templating library. The second example is about report generation, which is something we all have to do. You may have seen something like the Nokogiri XML builder.
00:12:33.530
I don't care much for builders, especially when they're done awkwardly like this, where we have a magic constant for columns, and in the middle we have some Active Record queries. This is just a mess; good luck separating the presentation, the ordering, and the logic without breaking anything. Instead of this, I was able to create something like this.
00:13:07.090
We simply have an HTML table that can easily be converted to XML. The key here was to separate out the data structure and think about the report in terms of the data, just like I learned with Elm. We have an export with a set of headers, and the report is simply an array of headers with rows of data. You're mapping through an Active Record collection, wrapping the Active Record object in a decorator and presenter.
00:13:40.320
By separating concerns and thinking outside the box, we arrive at something that fits the solution. To visualize this crudely, we have an array of headers and an array of rows, not trying to squeeze them into the XML builder. The benefits of this approach are that concerns are neatly separated, easy to understand, and clear where to change what; it's easy to extend and easy to test.
00:14:10.690
After I released this, my coworkers switched all reporting to this style. We extracted reports to a YAML file, which we could then edit; in the future, we could even give customers the opportunity to create their own reports because of the inherent flexibility.
00:14:38.030
The third example is message attributes. At Club Collect, we send a lot of emails and SMS messages for invoices, and we need to have many messages, which are themed in various ways. This was literally repeated for every message. I shipped out a message attributes class to neatly contain everything.
00:15:08.370
This allows us to use the benefits of object-oriented programming with the functional benefits of focusing on data structures, arriving at a solution where you're just merging a set of nested hashes. You don't need to think too much about the problem anymore; the concerns are neatly separated, and it’s straightforward to understand, clear where to change what, easy to extend, and easy to test.
00:15:37.710
I want to thank Michelle for opening my eyes to Ruby and its beauty in its purest form. Thanks also to Matz for creating a language that gives us joy. Thank you for guiding us to think in terms of freedom and joy, allowing us to create for fun. The ultimate freedom is to be unconstrained.
00:16:06.910
There are people who have vision, who can think for themselves, who appreciate beauty, elegance, and simplicity. I'm not just talking about Matz, Michelle, or any of the other speakers at the conference. I'm talking about you! So, please take the vegetable chopper away, pick up your chef's knife, and do it for fun. Step outside the prison of programming and preconceived patterns.
00:16:35.050
Carry confidence to conceive your code with curiosity and creativity. Reignite the fundamental reasons you responded to Ruby; reduce your readiness to repeat the routine, and ignite your imagination to iterate toward the ideal. Scrutinize the standards with suspicion and strive to spot solutions of simplicity. Join me in rediscovering Ruby. Thank you.
00:17:00.750
Would you like to ask any questions? Sure, any questions?
00:17:22.489
Hi, I was recently checking out Elm, and it was a bit hard to get started. I had trouble finding resources. What would be your advice for getting started quickly?
00:17:31.499
Certainly! I said Elm was very simple; however, that doesn't mean it's easy, especially at the start if you haven't been exposed to functional programming. I shared the same experience where I thought, 'Okay, it's beautiful, it's simple, but why would I use it?' I followed a course on programming languages by Dan Grossman, where he goes into ML, and it gave me a foundation in functional programming.
00:17:45.390
I don't expect everyone to follow that path. The best way is to play around yourself with the Elm Architecture tutorial. Also, I'm a fan of Richard Feldman, who has a course or two, and he’s working on a book that’s almost ready to print. I’d recommend those resources.
00:18:07.060
However, keep in mind that because Elm aims to be predictable and safe, using it in conjunction with the rest of the JavaScript ecosystem sometimes requires a bit of extra work to accomplish tasks that may be simple in vanilla JavaScript.
00:18:58.010
What you're saying is that you learned Elm but didn't use it on a project. You may use what you learned in Elm in a production project. How much time do you think someone should dedicate to learn Elm?
00:19:17.960
I can answer for myself; everyone is different and has limitations on how much time they can spend learning. It took me a couple of months to reach a point where I could do simple things with Elm. My experience indicates it might take around two months.
00:19:35.990
Also, I want to emphasize that learning Elm isn't just about Elm—it's about changing the way you think about programming. Five years ago, I wouldn't have understood the points you made in your talk, but now I do, and it feels so right and true.
00:19:55.370
What’s something you disliked about Elm, if anything?
00:20:06.760
The rigidity means that when you implement it in the real world and in a business context, you might struggle to figure it out. For example, interactions with JavaScript.
00:20:32.850
Again, these are trade-offs because the rigidity is also a major benefit. You feel safe when you put your code in production. If it compiles, it works, and it never breaks.
00:20:48.890
Do you just use Pure Elm to write your front-end code, or do you use something else to help your life?
00:21:04.030
At Club Collect, we don’t use Elm, not because we dislike it, but simply because we do very little front-end JavaScript code. We're almost purely server-based with not much reliance on JavaScript—I'm even embarrassed to say that we still use jQuery.
00:21:21.790
But personally, my journey with Elm helped me better understand Ruby without relying on frameworks.
00:21:35.590
It helps to become independent of libraries and gems. Thank you!
00:21:54.480
Are there any further questions? Hi, great talk, thank you!
00:22:04.640
You mentioned certain functional aspects you carried over to Ruby, like focusing on data and data structures. Are there any other parts of Elm or functional programming that inspired your Ruby code?
00:22:40.649
Definitely, the focus on data structures was a significant inspiration. After learning Elm, I learned to pause and think through problems rather than just diving in to figure things out. Subsequently, I would analyze the situation, identify patterns, and then formulate a solution, often introducing another layer of abstraction that fits the problem.
00:23:50.710
Thank you! Is there one last question, or are we done?
00:24:04.690
Thank you, Philip! Thank you.
Explore all talks recorded at Paris.rb Conf 2020
+12