16 afleveringen

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.

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

    • Technologie

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.

    16. Meredith Farewell

    16. Meredith Farewell

    This short episode of the podcast serves as a farewell to the one and only Meredith Edwards. Meredith has unfortunately recently acquired some angel wings and can no longer be an evil genius alongside Emmanuel! So today we are just wrapping up what the journey thus far has taught our two hosts and bidding Meredith a very fond farewell. We briefly look back at some of the key lessons we have covered so far as well as reminisce on the benefits of hosting the show. Tune in hear it all!
     
    Talking Points
    What a wild ride it’s been! How I’ve enjoyed working with Emmanuel What I’ve learned from the podcast. Goodbye from Meredith!  
     
    Links Mentioned in Today’s Episode:
    Evil Geniuses on Twitter
    Ruby
    Sandi Metz

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

    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

    • 24 min.
    14. How to Describe Tests

    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

    • 20 min.
    13. A First Example - Part 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
     

    • 28 min.
    12. A First Example - Part 2

    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

    • 27 min.
    11. A First Example - Part 1

    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

    • 20 min.

Top-podcasts in Technologie

Acquired
Ben Gilbert and David Rosenthal
✨Poki - Podcast over Kunstmatige Intelligentie AI
Alexander Klöpping & Wietse Hage
Bright Podcast
Bright B.V.
Lex Fridman Podcast
Lex Fridman
De Technoloog | BNR
BNR Nieuwsradio
Tweakers Podcast
Tweakers