Editor's note: you may need some background on what Macro Maynia is. Find it here.
Cakes: they are delicious and anyone can make them. Just like with baking a cake, that is the first rule of macros. No, no...not that they're delicious (I've never tasted one, so I can't verify). The first rule is that anyone can make a macro. That brings me to the second rule: you must understand the type of macro you need to build to solve your problem.
I'll admit: I'm not the world's best baker, nor am I the world's best macro maker. But, after a few baking (workflow) blunders, I've learned a few things that I think can help clarify not only the when building a macro makes sense, but also the why. That's where it helps to have a relatable analogy with just the right amount of frosting and sprinkles to help these concepts become fully baked: making a macro is like baking a cake.
Ensuring standardized, repeatable results is a major benefit of the standard macro. Funny, it’s also one of the benefits of using a boxed cake mix! Buying a box of Betty Crocker’s cake mix allows you and me to begin our cake baking process with the same set of dry ingredients as each box contains the same measurements of flour, chocolate powder, baking soda, salt and sugar. In doing so, we’ve combined finding, measuring, and mixing five different ingredients into a single step. Like a standard macro, which consolidates multiple tools into a single tool, boxed cake mix both simplifies our baking process and eliminates the possibilities of user error. It also reduces the number of times we have to walk to the pantry because we accidentally grabbed the baking powder instead of the baking soda. Increase efficiency and minimize errors? Cut me a piece of that!
Shrek explained it best: ogres have layers. Onions have layers. You know what else has layers? Cakes. And baking a tiered layered cake is a lot like making a batch macro.
A batch macro repeats a process for groups of data. However, for every group of data, something about that process changes. Think about the time you configured SO MANY FILTER TOOLS because you had to change one little thing in your workflow for different groups of data. I have a personal rule: if I have to do a similar thing more than three times, there's probably a better way to build it, and that way is usually a batch macro.
A tiered layer cake requires you to bake at least a few cakes (let’s say three) of varying sizes. Each size cake needs to bake for a different length of time. For each size cake, the amount of time needed to bake the cake will change. A cake in a nine-inch round pan, for example, will require more time in the oven than a cake in a five-inch round pan. But, how does the oven know for how long the timer should be set?
In a batch macro, changes that need to be applied based on an attribute of the incoming data are relayed to an underlying workflow. In this scenario, the parameter (or factor that controls the bake time) is the size of the pan. Depending on the size of the pan, the cake will bake for a different length of time. With a batch macro, this information on pan size can then be used to dynamically update the "timer" in the macro.
Once a batch macro has processed every batch of data, the outputs are “unioned,” or stacked vertically in a single data stream - much like a layer cake!
Iterative macros are essentially powered by one thing: a test of a condition. In the world of cakes, this is the ever-important toothpick test to know when your confectionery creation is done. To test whether a cake is done and ready to come out of the oven, stick a toothpick into it. If it comes out clean, then the cake is done and can be taken out of the oven. Otherwise, if cake batter sticks to the toothpick, the cake needs to bake a bit longer, and back in the oven it goes!
Once the cake goes back into the oven, you’re going to have to re-set the time for another minute or so before you run the toothpick test again. The looping behavior ends when one of two things happen: either all the input records pass your equivalent of the toothpick test or the maximum number of iterations is reached.*
*Maximum number of iterations… doesn’t that just run an iterative process x number of times? Yes, and right now you’re probably wondering how this even relates to cakes. I did too…until I lived this scenario. So, this one time, I was baking a cake (ok, it was actually zucchini bread, but it’s kind of like cake). I mixed all my ingredients together and put them in the oven. I know what you’re thinking right now… “Great story, Christine.” But HOLD ON. I check on my bread after 45 minutes… not done. Ok fine… back in the oven it goes for another five minutes. I check it again… still not done. Back in for another five minutes. TWO HOURS LATER this bread is still not done. What kind of baking nightmare was this? The kind where you accidentally use powdered sugar instead of flour in your batter. This was my real-life need for the configuration option to stop running the iterative process after x number of times, and just output my hopeless mess in all its gooey glory.
Now that you're hungry for cake and opportunities to build macros, it's time to find a fork and dig in!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.