wroclove.rb 2023
Lightning Talks Day 3
PW
See all speakers
See all 5 speakers

Summarized using AI

Lightning Talks Day 3

Łukasz Reszke, Pitor Wasiak, Ayush Newatia, Michał Matyas, and Alexander Jahraus • September 19, 2023 • Wrocław, Poland

The video presents a series of lightning talks from the wroc_love.rb 2023 event, featuring speakers Ayush Newatia, Michał Matyas, Łukasz Reszke, Alexander Jahraus, and Pitor Wasiak. The main theme revolves around programming and mentorship within the Ruby community, highlighting various techniques and insights. Key points discussed include:

  • Understanding Context: The first part emphasizes the importance of context in language and programming. For example, a tomato is classified as a fruit botanically but can be seen as a vegetable in culinary contexts. This analogy extends to programming where models may not match reality but serve specific purposes.

  • Domain-Driven Design (DDD): The speaker touches on DDD, asserting that while some design patterns like aggregates are useful, they can lead to overly complex models that aren't always necessary. A sophisticated modeling approach is recommended as projects expand.

  • Code Golfing: Another talk focuses on code golfing, a coding challenge to solve problems with the shortest possible source code. The speaker discusses community-driven events like Advent of Code that foster creativity in problem-solving. Specialized languages like Golf Script are mentioned as tools for compressing code length.

  • Mentorship Experience: One significant anecdote involves the speaker acting as a mentor for a junior developer on the Rails World website project. Emphasizing guidance without direct code writing, the mentor facilitated learning through sessions and code reviews, deflecting credit to ensure the junior developer gained experience. The project demonstrated a successful launch relying on a simplified but effective approach without delving deep into complex JavaScript setups.

  • Command-Line Tools: Lastly, a technical discussion on creating command-line tools using Ruby was presented. The speaker introduced tools like 'Ruby Packer', which bundles Ruby and dependencies into a standalone executable to streamline installations and avoid typical environment issues. Challenges like building binaries for specific systems and maintaining compatibility are also addressed.

In conclusion, the talks collectively inspire programming creativity, the importance of mentorship in the tech community, and practical solutions for common challenges faced in software development, especially within the Ruby ecosystem.

Lightning Talks Day 3
Łukasz Reszke, Pitor Wasiak, Ayush Newatia, Michał Matyas, and Alexander Jahraus • September 19, 2023 • Wrocław, Poland

wroclove.rb 2023

00:00:08.160 We can start. So, what can you see in the picture? Well, yes, tomato. No, please stop trolling. Dude, it's a serious presentation. So, what is a tomato? Is it a vegetable? Well, actually it is the fruit.
00:00:24.600 Okay, well yes, you can see a spot, a consultant over here, but I'll let Romeo answer that one. What he says is, 'I really like this tweet because it's saying that in culinary bounded context, a tomato is a vegetable; in a botanic context, tomatoes are fruit.' And then, in a mood or theatrical context, a tomato is a feedback. You can give me feedback later and just say 'tomato.' So as you see, words have meaning, right? And, sometimes in different contexts, one word may have different meanings. In that case, if you move it to the programming world, it's not supposed to match reality; it's just a part of it in a specific context.
00:01:19.260 So we could also say that if you think about one special model, that model will be wrong. But actually, every model is wrong; some are useful, right? With strategic domain event design, it can help you if you use this pattern well to find out what model you need in a specific context. We had this debate about Domain-Driven Design (DDD) yesterday; it was all about the aggregates. I agree that sometimes aggregates are unnecessary and may be too much, but it's not only about the aggregates. We shouldn't limit ourselves to that because there's more.
00:01:58.920 Typically, in our systems, especially in Ruby, I've noticed that our models grow too much and that's why DDD, meaning Data-Driven Design, can be problematic. Not always, because there's a place for it in certain areas, but usually, we need more sophisticated modeling techniques as the project grows. Thank you.
00:02:33.300 Okay, sorry, good hint. So yeah, welcome! I'm not very fluent in English, but I will try my best. My presentation will be short; it's called 'Golfing.' This relates to the game of Advent of Code.
00:02:55.860 I am the program organizer for a community that is often intense. There we drink some pitch, yes, alcohol, and flavor things afterwards. So it's cool; join us! The event is in December. There are some tasks to tackle: they are quite easy to understand, but people are eager to solve them at first. However, the longer it goes on, the more enthusiasm wanes.
00:03:37.800 We have a huge community, and talking about the quests and solutions memes is really exciting, which I appreciate. Code golfing is the practice of solving a problem with the shortest source code possible. People compress the bytes in their code and we compare solutions to see which is shorter. Shorter code is usually better too.
00:04:18.780 There are specialized languages for code golfing; Golf Script is a macro for Ruby and is quite well-known in the community. There are special languages which are often not readable at all, like Base64 commands that are plugged into software compilers, so it's interesting to see how creative people get just to achieve better scores.
00:05:10.600 So, if we solve the algorithms, people try to find the quickest way to do so. They even introduce code golfing languages to make it faster since shorter code means less to write. It's of course cryptic, but we can optimize it with tools like RubyKo or something similar.
00:05:54.600 Here is an example where we have to parse a console input and find a trivial solution. In code golf, we aim to make it shorter. You can see here how we evaluate strings and fix requirements. You learn a lot about the language itself from what is necessary, and while cryptic, it can be enhanced with tools like RubyKo.
00:06:49.040 The more advanced tasks we encounter sometimes go a little beyond 100 characters or bytes. Solving everyday problems can be easy, but adding the challenge of code golf makes it fun and interesting.
00:07:40.960 I also discovered various features in Ruby such as global variables, useful for scripting and file parsing. I've learned a lot from using them; however, less code is typically not easier to understand. I've also explored recursive arrays in Ruby, which are well-supported.
00:08:26.640 So, thanks for listening! There are also some tips about Ruby code golfing on the slides. I'll just monologue now. This is my second talk at a Ruby conference that oddly has no Ruby code in it, so let's dive into mentorship and how we delivered the Rails World website project.
00:09:14.040 I've been writing software professionally for about ten years, so I consider myself an 'old fart' - a grumpy old man who says 'back in my day' too often. A while back, the newly formed Rails Foundation published a blog post looking for a junior developer to build their website with a senior mentor.
00:09:46.020 I saw this as an amazing opportunity to guide a hopeful junior. I volunteered to be the mentor and met with Amanda, who runs the Rails Foundation, and the junior developer, Shona. Shona was an absolute star and made my role incredibly easy.
00:10:25.080 As a mentor, I established a few principles: firstly, I didn’t want to write any code myself. I aimed to provide guidance through written instructions, code reviews, and pairing sessions. This ensures that Shona would learn, as I believed if I did all the work, she wouldn't gain any experience.
00:11:04.920 Secondly, I aimed to deflect any credit to Shona for her accomplishments, but if anything went wrong, I would take the blame. This mindset was difficult, as the setup only brought downside for me externally.
00:11:59.640 The website is set to live under ruby on rails dot org, in a shared repository that is a server-side rendered site with no JavaScript. Initially, we aimed to avoid using any JavaScript or CSS, but changing client demands led to us needing to use moodles and carousels.
00:12:34.200 I wanted to teach Shona how to establish an ES build pipeline; however, I realized that it would be challenging for a junior developer who wasn't familiar with the JavaScript world. I thought, why do we even need to set up this complex pipeline? JavaScript is in a good spot now, so we used custom elements to encapsulate the necessary functions without writing outdated procedural code.
00:13:14.760 After implementing simple classes to handle features like carousels and moodles, we successfully delivered what I believe is a modern website. Additionally, the website works without JavaScript, making it accessible even when the script is turned off. I am proud of what Shona accomplished.
00:14:18.780 In the mentoring role, I learned a lot as well! I discovered that stripping back complexity for clarity was valuable. If I were just building myself, I may have overlooked this streamlined approach because I am used to my ways.
00:14:58.440 It is often said that coaches learn from their students, and this was particularly true in this scenario. Therefore, I wanted to share this story because mentorship is crucial, especially considering the recent conversations about juniors struggling to get opportunities.
00:15:41.600 If you're experienced, please consider sharing your knowledge. You may gain much more than you realize and learn from those you guide. Some of you may have heard of a project called 'First Ruby Friend,' run by Andy Kroll, which matches mentors to mentees - it's a great way to get started with mentorship.
00:17:22.920 When creating our own internal command-line tool, there are two ways to approach it: by using one big script, which is easier, or organizing it with multiple files, which is better for maintenance.
00:18:09.360 However, running a Ruby script can get messy if you have multiple versions of Ruby or issues with gem installations, particularly with Bundler that requires a gem file to be present in your current directory.
00:18:52.800 Fortunately, you can avoid some of these pitfalls by packaging your binary script into an executable. For many Ruby developers since 2014, there was a tool called 'Traveling Ruby', developed by the creators of Phusion Passenger. While it provided a pre-built Ruby environment back in the day, it has not seen significant updates in years.
00:19:39.000 Now, a viable alternative is 'Ruby Packer,' which compiles Ruby and packages your code into a mini virtual file system. This approach allows you to create standalone binaries without needing to install Ruby or worry about gem dependencies.
00:20:56.280 The benefit of building such a tool is that you do not have to manage gem installations as it bundles everything together into a single executable. However, creating the binary takes up space – for instance, my example binary is approximately 30 megabytes.
00:21:42.000 Another challenge is that original maintainers of Ruby Packer ceased updates over two years ago. While there are various forks available online, some may be outdated or unstable. I found one that embeds Ruby 3.1.3, which works well.
00:22:32.760 Additionally, please note that if you wish to compile your binary for a specific system, such as Mac or Linux, it has to be built on that corresponding platform. Some dependencies may not be statically compiled which can lead to compatibility issues on different distributions.
00:23:09.180 Despite the limitations, Ruby Packer does enable you to have a command-line tool without worrying about the installation environment everywhere. I sincerely thank you for your attention!
Explore all talks recorded at wroclove.rb 2023
+14