RR 318 Metaprogramming with Jordan Hudgens

Today's Ruby Rogues podcast features Metaprogramming with Jordan Hudgens. We have panelists Jerome Hardaway, Brian Hogan, Dave Kimura and Charles Max Wood. Tune in and learn more about metaprogramming!

[00:02:00] – Introduction to Jordan Hudgens

Jordan is the Lead Instructor at Bottega. Bottega has locations in Salt Lake City, Utah and in Phoenix, Arizona. They’re a full-stack development code school.

[00:02:55] – Metaprogramming

Metaprogramming was one of those scary concepts. At the code school, when the students learn about metaprogramming and how it works, you can tell that it’s definitely a pretty exciting thing. Its formal definition is it’s a code that writes code. It can dynamically, at run-time, render other methods available to the program.

[00:04:10] – Use cases for metaprogramming

The best use case that Jordan has ever seen is implemented in Rails and that’s code that can run database queries such as User.find_by_email. By passing the email, it will go and find the user with that particular email. Now, there is no method in active record or in the user model that is called find_by_email. That’s something that is created at run-time.

Another one is something that Jordan has implemented and that’s a phone parser gem. It essentially parses and validates a phone number. It also has a country code lookup. With all the countries in the world, that would be very time-consuming. But within 8 lines of code, it could do what a hundred lines could do without metaprogramming.

[00:06:50] – Performance implications

Jordan never had performance issues because the generation of methods is not something that’s incredibly memory intensive. You might run into that but it would be a poor choice to do in terms of readability.

In Brian’s experience, it comes down to the type of metaprogramming you do. If you have a bunch of logic somewhere and method_missing, that’s going to be a performance bottleneck. And if you’re generating a bunch of methods when the application starts up, it might increase the start-up time of the application. But after that, the performance of the application seems to not have any fluctuation at all.

There are 2 main types Jordan works with. First is method_missing. Method_missing could have a little bit of performance hit because of how Ruby works. The system is going to look at every single method. The second type is define_method. In define_method, you’re really just creating a large dynamic set of methods at runtime. When you start up the Rails server, it’s going to build all those methods but it’s not going to be when you’re calling it. Whereas in method_missing, it has a different type of lookup process. 

[00:11:55] – Method collisions on monkey patching

That’s one of the reasons why monkey patching can have a bad reputation. You don’t know who else may be overriding those set of methods or opening up that class. Jordan’s personal approach is trying to separate things out as much as humanly possible. If there’s something that can be done in the lib directory, you can place that functionality inside of a separate module. And if you’re creating a gem, you have to be sensitive to other gems in that space or even the Rails core.

[00:17:25] – How to be good citizens to other developers

Metaprogramming has a lot of potentials to do great things but it also has a potential to cause a number of problems in the application. For Jordan’s students, what he usually does is walk them through some examples of metaprogramming where it can be done poorly. But then, he will follow it up with showing exactly when this is done right.

He shows examples of poorly written classes that have dozen nearly identical methods. And then, he also shows how they could take all those methods, put the names in an array, and show how to leverage things like define_method to generate them. He also shows them how doing monkey patching can cause issues, how they can actually open up t