Evil Geniuses

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

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

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

1. Different types

• Test that describes implementation:

1. 1. describing that a method or attribute returns a certain value
2. “it should equal 20”
3. “it should call YouTube API”
4. “it should call the render_text method”

• Test that describes business value

1. describing the reason to return a certain value

1. “it should have the amount given by the user”
2. “it should return video stats”
3. “it should render text”

1. Who are the tests for?

• Other developers reading the code
• Future you if you’re refactoring

1. 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

1. 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

1. 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

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

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

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

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.”

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.

On today’s episode of the Evil Geniuses Podcast, we are carrying on the evil journey in video service refactoring. If you have not yet checked out part one and two from this series we suggest that you listen through those to get yourself up to speed. Otherwise, the nasty, dangerous code might get completely out of hand! In this episode, we compare Martin Fowler’s technique for refactoring with Emmanuel’s and break down each step and difference.

On today’s episode of the Evil Geniuses Podcast we are delving deeper into the video service we started last time around. Part two means twice as evil and twice as malevolent! Emmanuel and Meredith are taking you down the dark tunnel and hopefully out the other side into the daylight with this continued exploration of refactoring a video service from Youtube.