Evil Geniuses

Meredith Edwards and Emmanuel Genard - Software Developers from Stride Cons
  • 5,0 (5)
  • TECHNOLOGIES
  • DEUX FOIS PAR MOIS
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. 12/12/2018

    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

    8 min

  2. 28/11/2018

    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

    25 min

  3. 14/11/2018

    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

    21 min

  4. 31/10/2018

    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

    29 min

  5. 17/10/2018

    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

  6. 03/10/2018

    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

  7. 19/09/2018

    10. Tales from the Open Source Jungle and POO-ing in Durham, With Kirsten Nordine

    Today on the show, we welcome Kirsten Nordine of Stride and her faithful colleague, Scaredith, to reflect on their adventure into the open source jungle. Deciding on an open source project and what issue to tackle can be tricky, and in this episode, we find out exactly how Kirsten and Scaredith embarked on the Issue #572 quest: To “Add Ability to Cancel an Event or Mark It Canceled.”

    25 min

  8. 05/09/2018

    9. Lessons Learned

    Today’s episode of Evil Geniuses is spent looking back on the lessons we have learned so far in this series. Through all of the evil problems and scary paths we’ve had to walk, there have been some invaluable takeaways that we have been able to share with our listeners.

    20 min
Tout afficher (16)

5
sur 5
5 notes

À propos

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.

Informations

  • Création
    Meredith Edwards and Emmanuel Genard - Software Developers from Stride Cons
  • Années d’activité
    2 k
  • Épisodes
    16
  • Classification
    Tous publics
  • Copyright
    Copyright © 2018 Stride Consulting LLC
  • Site web de l’émission
    Evil Geniuses

Pour écouter des épisodes au contenu explicite, connectez‑vous.

Recevez les dernières actualités sur cette émission

Connectez‑vous ou inscrivez‑vous pour suivre des émissions, enregistrer des épisodes et recevoir les dernières actualités.
Choisissez un pays ou une région

Afrique, Moyen‑Orient et Inde

Asie‑Pacifique

Europe

Amérique latine et Caraïbes

États‑Unis et Canada