00:00:48.000
The first talk we will listen to is about abstractions. Ruby, like many other languages, abstracts a lot.
00:00:55.120
Abstraction is the bread and butter of software development, but sometimes you need to peel off those layers to better understand and explain to others what is really happening.
00:01:10.159
This understanding can help you refactor and get a clearer view of the code you are writing or working with.
00:01:24.560
Therefore, I'm going to leave the stage to Ivan, whose talks have always been amazing. I'm definitely looking forward to this one. Welcome, Ivan! It's super nice to see you again.
00:01:37.040
Good morning, everyone! I actually thought you were hosting every Ruby Day event because at all the ones I attended, you were hosting.
00:01:44.159
Well, as I said, it’s my way to give back to the Ruby community. As I'm not a particularly focused person, I often find myself getting distracted. So, being here with deadlines and meeting awesome people helps me to stay consistent in my deliveries. Thank you so much for being here.
00:02:26.160
Oh yeah, thank you! My talk is actually pre-recorded, so I'll be answering questions in the chat.
00:02:42.000
For those in the chat, please write your questions there, and I'll ask them after the talk.
00:03:07.360
Good morning, Ruby Day! I'm Ivan Nemytchenko, and this morning we're going to make things a little bit less abstract by expressing Ruby OOP through pictures.
00:03:21.360
So, let's start. I've been doing Ruby since 2006, mostly freelancing and consulting these days. I used to call myself a complexity fighter but now prefer the term complexity organizer.
00:03:37.120
I'm also a GitLab fan, having worked for GitLab, and I'm the person behind two websites, railshurts.com and painlessrails.com. I hail from Omsk, which is in Siberia.
00:03:56.400
To clarify, Omsk may sound strange for many, but imagine being on a long flight and seeing Omsk as the only dot on your flight monitor — that’s where I'm from.
00:04:14.799
These days, I live in Serbia, and it’s important to clarify that Serbia is not Siberia. Before moving, I didn't really understand the difference between these two places, but I do now.
00:04:32.000
Today, we are going to talk about a different problem: although we might be talking about the same concepts, our understanding can differ significantly.
00:04:54.560
We are discussing abstractions in programming; almost everything we work with is an abstraction built on top of other abstractions. This complexity can sometimes make it hard for us to understand each other.
00:05:06.400
Another issue is seeing the big picture of our code, especially when projects are huge. When all we have is the code, it can be hard to discern the underlying ideas without deep diving into it.
00:05:16.639
There have been a few attempts to address this issue, like CRC cards, which have been suggested to help, but they're not widely adopted or known.
00:05:39.360
Then there’s UML, which can be useful but often causes eyes to glaze over. While it can help in theory, it's not liked by many.
00:05:58.800
This was the problem statement, and now let's talk about what you can expect from this talk.
00:06:09.480
First of all, I promise it will be fun! You will hopefully become better at learning, teaching, and explaining complicated concepts. The techniques you learn today might help you visualize the big picture in your projects.
00:06:29.120
My talk has three parts: first, we will build a foundation; second, we will use this foundation to explain some advanced programming concepts; and finally, we will experiment with these techniques to see how they can be useful.
00:06:54.640
This whole idea originated from a conversation at a conference in Russia where several educators were discussing how to teach junior developers.
00:07:15.200
I presented a rhetorical question: Wouldn't it be great if we could illustrate concepts like dependency injection in a single picture that everyone could understand in the same way?
00:07:32.480
Months later, while working with students on their OOP assignment to develop a smart kettle that boils water correctly and safely, I found that many students struggled to think in object-oriented terms.
00:07:54.720
For students with procedural programming backgrounds, shifting to OOP can be challenging. To help these students, I used a method called the Art Soldiers method.
00:08:10.959
Imagine you are a captain and you have a dozen soldiers at your command, each assigned a role. These soldiers are highly skilled, no matter what role you give them.
00:08:27.520
An important constraint in this analogy is that the only way to interact with the soldier is to ask him to do something relevant to his role.
00:08:39.360
Using this analogy, students gradually begin to understand the principles of OOP. They realize that the roles represent classes, and the requests made to the soldiers are methods.
00:08:53.680
I often illustrate concepts with drawings, and when explaining, I create pictures representing the roles and methods to convey these ideas.
00:09:08.720
For example, one of the classes could represent a heater while another might represent a temperature sensor.
00:09:18.560
I thought about further enhancing these drawings by illustrating methods and arguments through arms and fingers. The fingers could represent arguments that the methods accept.
00:09:36.800
I further refined this idea, visualizing how the arms could store arguments in the 'brain' as instance variables, which can later be reused in other methods.
00:09:57.760
The results could also be visualized, where arguments enter fingers, processes happen inside, and results emerge.
00:10:14.480
Private methods became an illustration of arms that couldn’t be shaken from the outside, highlighting that they can only be accessed internally.
00:10:29.280
We can also illustrate exception handling processes, resulting in a comprehensive visual language that allows us to express basic anti-patterns.
00:10:43.760
For example, too many arguments or methods can be represented through swollen arms, which can clearly highlight complex situations in our code.
00:10:58.560
Through this method, we can effectively explain polymorphism; specifically, parametric polymorphism using our visual language.
00:11:13.440
With the drawing, we can determine if objects exhibit polymorphism by checking if they have the same number of limbs and fingers, thus ensuring a consistent interface.
00:11:27.360
Classes can be visualized as spawning platforms; when a lever is pulled, an object is instantiated.
00:11:46.320
This analogy reveals that classes and objects have the same topology and structures represent how objects are instantiated.
00:12:03.920
In addition, we can visually express execution flow, indicating that the sections of an arm or the steps in the arm icon represent methods being executed.
00:12:22.400
The execution flow might resemble a Rube Goldberg machine where the alignment of all components depends on the argument interactions.
00:12:45.040
Another concept we can discuss is dependencies; these are typically globally available classes reused in various places.
00:13:01.440
These dependencies can be illustrated in the flow, and if they have side effects, it becomes important to visualize how those side effects interact.
00:13:20.000
Dependency Injection can also be represented visually, emphasizing that dependencies should be passed as arguments instead of being hard-coded.
00:13:42.320
In summary, this illustrated language helps to convey the ideas of dependency injection more effectively.
00:14:00.080
Thanks to this visual approach, it becomes clearer how side effects can be isolated.
00:14:19.640
We'll now look at how this visual language can be practically applied to a talk from Sandy Mats in 2018.
00:14:37.120
While the exact nature of her talk isn't important, the main point is how the code evolves in complexity with new iterations.
00:15:00.320
We illustrate the original version of the code and then highlight how new requirements continue to grow the complexity.
00:15:14.480
As changes are made, we can depict how the complexity builds up visually so that you can see which iterations introduce excessive complexity.
00:15:30.560
After the illustrations, we can show how Sandy refactors the code, allowing us to visualize the transition from complex to simpler constructs.
00:15:42.560
This visual approach reveals the evolving state of the code and significantly aids in recognizing how complexity can build up through iterations.
00:15:56.880
As a result, one can see the improvements that occur as the code is refactored, solidifying the understanding of underlying design principles.
00:16:09.440
Now let’s discuss dynamic anti-patterns and how the visual approach helps identify these patterns as they emerge in your coding practices.
00:16:19.680
For example, when you find yourself adding the same argument to multiple methods across various classes, that’s a sign of a pattern that needs addressing.
00:16:37.680
Similarly, adding the same condition to different methods could signify a deeper problem, and this visual language points that out quickly.
00:16:53.760
The resulting code post-refactoring showcases how those original complexities were transformed into simpler and more manageable constructs.
00:17:06.160
What I find particularly interesting is that this should highlight essential complexities within your domain; it's about organizing rather than eliminating complexity.
00:17:20.720
Thus, as we work through these models, we build annotations to represent code complexity, making it easier for documentation and communication.
00:17:31.760
However, it's essential to remember that while models can be useful, they are simplifications and shouldn't be taken too literally.
00:17:48.760
These visual tools help to share knowledge across teams and articulate complex concepts with clarity.
00:18:03.440
So, if you have any questions, I’d be happy to jump in and answer them. You can also learn more about my work on my website, inm.a.t.
00:18:16.560
You can find additional resources on how I approach coding with Ruby and making it simpler at painlessrail.com.
00:18:33.760
Thank you, and I hope you have a good day at the conference.
00:18:50.560
Bye, welcome back everyone! Ivan, this was amazing.
00:19:15.280
I see that everyone has the same question: is there a way to generate these illustrations automatically?
00:19:29.760
Well, let me share my screen and show you a few more slides.
00:19:41.760
I actually have the same challenge with maintaining focus. The only reason a library exists that can generate these drawings is that an intern of mine took the initiative to implement it.
00:19:58.960
There are links available where you can try playing with this code, and even though the drawings are basic, they can effectively highlight differences in code changes.
00:20:15.840
You can even deploy a Rails app that you can connect to your repository to comment on pull requests with these illustrations.
00:20:31.760
This visual representation is drawn from a method of showing multi-dimensional data through human-like mimics, which makes understanding easier.
00:20:46.720
Our brains naturally gravitate towards human-like concepts, making it simpler to grasp the ideas behind the code when they are presented visually.
00:21:02.320
Thank you so much! I believe you'll have a lot of new downloads for this tool.
00:21:16.000
There’s a question in the chat about whether you've considered using this visual paradigm as a metric for software development.
00:21:29.600
Good question! I’ve thought about various ways this idea can be applied, including mapping metrics to visualize development.
00:21:42.800
For example, we could collect metrics from various existing Ruby gems and visualize them using this approach.
00:22:05.520
The intent of this visualization is to allow comparison over time and see if your design is becoming simpler or more elegant.
00:22:19.600
This visual representation can highlight design flaws or potential issues in your code.
00:22:32.720
I encourage you to experiment with these illustrations and tools manually first and then explore any automated solutions later.
00:22:47.840
Thank you so much for your time! I hope you enjoy the rest of the conference.