Evil Geniuses

Meredith Edwards and Emmanuel Genard - Software Developers from Stride Cons
Evil Geniuses

Every two weeks we break down solutions to code problems, talking about the decisions that got us where we are. We reveal our thinking and discuss trade-offs. Evil devs. Evil problems. Evil code.

  1. ٢٠‏/٠٣‏/١٤٤٠ هـ

    15. POO-ing in Durham, With Kirsten Nordine - Part 2

    Welcome back to another episode of Evil Geniuses. Today on the show we welcome back Kirsten Nordine. The last time Kirsten was on the show was a little over a month ago and we talked a little bit about an open source contribution we’re working on but we also talked a lot about her experience going to a POOD Workshop by Sandi Metz in Durham, North Carolina. In today’s episode, we are talking all about Kirsten and the little vacation she took. Well, not necessarily a vacation but time away from clients to learn more about software development. Kirsten and Emanuel attended Sandi Metz’s new three-day workshop titled POODR Two: Practical Object-Oriented Design in Ruby. We dive into why they went, what they learned, and the biggest takeaways from the workshop that each of them had. Keep listening to hear more!   Key Points From This Episode: Wanting steps like rules to architect a solution to something. Learning more about how objects work together and the design. Day 1 working on a bowling exercise — website code kata and sequence diagrams. Day 2 focusing away from the code and more towards drawing and talking. Designs centered around what message the objects sent and received. Sandi’s helpful way of simplifying things. Why code is easy and organizing code is hard. The role of TDD and design. Finding our where the first test should be. Designing a new story, finding a way to communicate and start writing code. And much more!   Talking Points Why did you go? What did you do? What is special about learning from Sandi? What are we going to do after? How are we going to practice until we’ve fully learned the  things introduced at the class? What is the main takeaway? What are some things you would change about the class?   Links Mentioned in Today’s Episode: Evil Geniuses on Twitter Kirsten Nordine Kristin on Twitter Sandi Metz Stride Ruby

    ٢٥ من الدقائق
  2. ٠٦‏/٠٣‏/١٤٤٠ هـ

    14. How to Describe Tests

    Welcome back to another episode of the Evil Geniuses Podcast. We are coming at you with something new this week! This episode will be the first time that we are not talking about a code problem that we’ve solved because we are going to take a stand, and our stand is about testing. We are diving into the ins and outs of how you describe your test. Here at Evil Geniuses, we believe that the description of a test should describe business value not implementation. So stay tuned as we unpack the differences between business value and implementation descriptions, the opportunities that can come from rewriting code, and why naming your tests can take quite some time to fully master. For all this and more, keep listening!   Key Points From This Episode: Specific examples describe business value versus implementation. How the description sets you up to know what to look for when reading the test. Why a misdescription can make it hard to see if the test was successful. Understanding exactly who the test naming is for. Rewriting code allows you to know enough to better write business value descriptions. Why naming your tests takes a long time to master. And much more!   Talking Points Tests should describe the business value and not the implementation Different types Test that describes implementation: describing that a method or attribute returns a certain value “it should equal 20” “it should call YouTube API” “it should call the render_text method” Test that describes business value describing the reason to return a certain value “it should have the amount given by the user” “it should return video stats” “it should render text” Who are the tests for? Other developers reading the code Future you if you’re refactoring Following this practice results in better tests Bad: “it should raise a PriceError” Good: “it should return an error when value exceeds max price” Not only about raising the error; it’s about notifying the developer and user that something exceeded the max price Supports Refactoring clarifies the objective this makes it easy to change implementation because you aren’t confused about why a certain piece of code was written Ex: feel confident to refactor as long an error is raised when the max price is exceeded Supports Feature Changes Feel more confident changing or removing test related to max price with description instead of just “exceeds 100”   Links Mentioned in Today’s Episode: Evil Geniuses on Twitter The Stand Stride

    ٢١ من الدقائق
  3. ٢٢‏/٠٢‏/١٤٤٠ هـ

    13. A First Example - Part 3

    On this episode of the Evil Geniuses Podcast, we continue our series on a first example of the video checkout system. To start off we recap some of the points from the first two parts and then move into the final stretch! We talk about the two main patterns that are present in this code, namely base charge for rental and extra charge for rental before getting into renaming decoupling and calculating a final cost. We add in some reminders about primitive obsession and take some handy lessons from the idea of a library and borrowing books, so stay tuned for that! For all this, and much more be sure to listen in as we go deep!   Key Points From This Episode: Recapping the patterns from the first two parts of this series. Base charge for rental and extra charge for rental as the two patterns. Renaming a commit and why it is more accurate now. The meaning of the number two in this context. Making it obvious that new movies have a base rental period. Looking to the library for an analogy on extra charges and new movies. Finally calculating the whole charge for the rental. Figuring out the title of the movie by removing a coupling. Writing exemplary code for others to follow. An HTML challenge to the listeners! And much more!   Commits rename element to rental Make the code tell a story rename base_cost_of_rental to base_charge_for_rental Making the code tell a consistent story extract #points_for_rental. remove comments, no longer necessary Repeat the pattern of the previous extractions extract base_rental_period from extra_charge_for_rental A new pattern spotted new releases do not have the concept of base rental period Trying to figure out what base_rental_period for new release movies is or maybe new releases have infinty base_rental_period I think we’ve  got it! base_charge_for_rental can include extra_charge_for_rental Consolidating ideas rename base_charge_for_rental to chare_for_rental Consolidated idea extract base_charge_for_rental. It's also become obviou Doing the obvious move move base_charge to rental More obvious move extra_charge to Rental More obvious moves add Rental#charge method. Only public method necessary Pretty obvious move points to Rental More obvious moves some general cleanup Cleaning add Rental#title. This finally makes it so that Customer Avoiding the train-wreck some light cleaning Some light dusting   Links Mentioned in Today’s Episode: Evil Geniuses on Twitter Stride GangofFour Ruby JavaScript Sandi Metz Primitive Obsession Refactoring

    ٢٩ من الدقائق
  4. ٠٨‏/٠٢‏/١٤٤٠ هـ

    12. A First Example - Part 2

    Welcome to another episode of Evil Geniuses. Last time we teased you but we’re back and this time we’re actually going to deliver the goods, no more click bait. We are working with a video checkout store type software where our classes are a movie, a rental, and a customer. We’ve given you insight into what our test look like and today we want to talk about the code that does tester testing. The theme of this discussion is you have to do two things. One, you have to introduce duplication in order to identify the right obstruction because you can’t always trust the obstruction that is present and then two, stop being obsessed with primitives. No more primitives. Keep listening, there’s, even more, coming up in the next episode!   Key Points From This Episode: The quality of your code and when it matters. Understanding a primitive obsession. Introducing temporary duplication to find sameness. Extra charge for rental versus base cost of rental. Returning the same type of object regardless of the output of your method. Eliminating the case statement. And much more! Talking Points Work hard to be lazy Duplication leads to the removal of duplication Commits rename element to rental Make the code tell a story extract base_cost_of_movie concept Add duplication remove duplicate base_cost_of_movie calls Remove duplication rename method to tell a more accurate story Make the code tell a story part 2 extract the #extra_charge_for_rental method This refactoring showed there are two kinds of charges for a movie Exposed an error remove duplicate extra_charge_for_rental calls Remove Duplication part 2   Links Mentioned in Today’s Episode: Evil Geniuses on Twitter Stride Ruby Sandi Metz Primitive Obsession Basic Instinct Sharon Stone

    ٢٧ من الدقائق
  5. ٢٣‏/٠١‏/١٤٤٠ هـ

    11. A First Example - Part 1

    On today’s show, we embark on a new, evil adventure, one on which we hope you will join us! We’ll be looking at another refactoring problem and this will make up the first part of a short series of episodes dealing with this issue. Emmanuel lays out the topic, which takes the shape of a code used to run the rental of videos in an old style video store. During this week’s discussion, we deal with the first areas of the topic, looking at what Emmanuel’s work takes directly from Martin Fowler’s Refactoring and where his actions diverge. We discuss the conditions and objects that deal with the duration of a rental and how these differ across genres of movies. We also unpack test names and start on the topic of his commits. Be sure to tune in for this especially evil episode!   Key Points From This Episode: Setting out today’s refactoring problem. The lessons Emmanuel took directly from Martin Fowler’s book. Conditions around the code of renting a movie for a certain amount of days. Understanding Emmanuel’s test names for rentals. A summary of the objects and what they are responsible for. The problem-dump commit and how Emmanuel worked this out. And much more! Talking Points Present the problem You have to add tests. Assume that the application works as is; change no current behavior A teaser episode Commits Use YoutubVideoClient to abstract away talking to youtube Ok, cool, class for YouTube here Update test to use YoutubeVideoClientMock What is (ids=:NotGiven) doing? Can you break down that code? Add test cases  for statement What did you add that wasn’t in the book? Curious. Why did you choose minitest over rspec? What do the test names mean? test_2day_new_4day_child_3day_reg Can you summarize the objects here and their responsibilities? Add notes from book stating the problem Summarizing the problem for our listeners Links Mentioned in Today’s Episode: Evil Geniuses on Twitter Stride Martin Fowler Refactoring Ruby Java Blockbuster Hollywood Video Cars RSpec MiniTest Flickr AJAX Facebook Myspace AOL WhatsApp Messenger BitTorrent

    ٢٠ من الدقائق
٥
من ٥
‫٥ من التقييمات‬

حول

Every two weeks we break down solutions to code problems, talking about the decisions that got us where we are. We reveal our thinking and discuss trade-offs. Evil devs. Evil problems. Evil code.

للاستماع إلى حلقات ذات محتوى فاضح، قم بتسجيل الدخول.

اطلع على آخر مستجدات هذا البرنامج

قم بتسجيل الدخول أو التسجيل لمتابعة البرامج وحفظ الحلقات والحصول على آخر التحديثات.

تحديد بلد أو منطقة

أفريقيا والشرق الأوسط، والهند

آسيا والمحيط الهادئ

أوروبا

أمريكا اللاتينية والكاريبي

الولايات المتحدة وكندا