Debugging Saturday: React is not cooperating with me

Jude Pineda — Sat, 24 Aug 2019 05:06:33 +0000

Hello! This post originally started as a dummy post to test how the DEV.to API communicates with my website. Well, since I'm here anyway, I might as well describe what I'm trying to accomplish.

The Problem 👻

I'm using @emasuriano's amazing Mate starter for GatsbyJS. I'm trying to use DEV.to posts instead of Medium posts. I have successfully changed the source plugin to gatsby-source-dev and my DEV.to posts have been successfully grabbed by GraphQL, but I'm trying to figure out how to render the actual elements on my website.

My site successfully outputs the cards - one for each blog post because I have two posts so far - but the elements are returned as 'undefined':

An attempt at a solution 🤔

I really think it has something to do with the render function after my GraphQL query. Hopefully I get this fixed by the end of the week - I would like to have a nice portfolio website out as soon as I can. Who doesn't?

What I learned 🎓

I discovered what the ES6 spread function is. It's a pretty nifty tool - if we were using ES6 at work, I would definitely use it.

I have also learned about lambda functions. When I was trying to find out what the double => arrow => function means, I was visited by a ghost of my undergrad years - function currying. I am so glad I have learned all about it in school; otherwise, I would have been much more confused.

Status

This is my first time debugging a React web app. Talk about a trial by fire 🔥! The solution might come as a very simple one for some, but I'm still trying to unravel all the abstractions on this code, and I'm already on my second Starbucks drink.

I should probably get dinner. My head hurts.

What production environments can learn from McDonalds

Jude Pineda — Wed, 14 Aug 2019 17:27:53 +0000

I figured it would be apt to have my first Dev.to post be about something I find in common between my current development job and my entry-level job.

Imagine this: You walk into a McDonalds to get lunch. Among the usual menu items (and the occasional waiting around for the menu to come back because an ad took over the entire screen), you see a new food item that wasn't in the menu the last time you went there.

After ordering it out of interest, the manager asks you how you liked the new item - or just surreptitiously look at you to see how you would react on your first few bites.

There are three possible outcomes for this scenario:

You hate it. You take one bite, not finish your meal, and let the manager know that you didn't like this new food item. Nearly all others hate it as well, and the following week, you don't see the new food item anymore.
You love it, as well as a lot of other people. This item eventually becomes a permanent menu item on all McDonalds restaurants nationwide, possibly even replacing something that wasn't selling as much as this new item.
You and probably half of the store's customers like it. Since not everybody hates this new menu item, it makes it to the menu across all McDonalds restaurants as an "a-la-carte" item: it's not popular enough to be have its own number on the Value Meal list.

This is a very common occurrence that happens at most major fastfood places. When I worked at McDonalds, we called it an LTO - a "limited time offer" - and is usually only rolled out to one region to see how customers would like it before making a decision to feature it nationwide.

This concept is not something new in the restaurant industry, and it also has a place in software development. It's called canary deployment, and involves:

"pushing programming code changes to a small number of end users who have not volunteered to test anything".

"Deploying code to non-volunteers?! What a dubious production model!"

The concept might sound suspicious (why would you push code to non-testers?), but the reality is that canary deployment only seems dubious because source code is unlike something tangible like a burger, or a milkshake.

In fact, canary deployment is something that is already being implemented in most enterprise software. GitLab has procedures on how to enable canary deployment and describes it as a "popular continuous deployment strategy". Klarna, a company that provides financial services to online businesses, suggests in their dev blogs that canary deployment adds a huge level of confidence to software releases. The Netflix Tech Blog article "Confidence in the Canary" shows that canary deployment takes up a big part of their testing pipeline, right in the middle between regression tests and red-black tests: