Dream jobs are an evolving concept.

I remember growing up, looking up at my parents, who used to work with IBM hardware and software. Every now and then a technician or sales men would come to their office and I'd be left amazed by them. IBMers, a selected few who worked for this prestigious company and were always up to date with bleeding edge stuff.

I was further hooked up on the whole IBMer concept with the marketing campaign they launched for their centennial.

If people asked me what my dream job was, I would have answered "to be an IBMer" without skipping a heartbeat.

Time went by, I started college, deviated heavily from the tech industry by studying industrial engineering and never revisited this old dream of mine.

I eventually ended up working in the tech industry, but never really cared for or remembered this IBM dream, up until a recent conversation I had.

I was encouraged to pursue this old dream of mine and apply for a position at IBM. I gave it a quick thought and realized I would not want to work there anymore. The reasons? Unkown.

Maybe it is because I know more about the company's culture now. Maybe it is because I have grown up to better discern what I really want, from what is being sold to me.

But most definetley, it is because I am no longer the same person that I was when I first envisioned this dream.

All of that reminded me of this tweet, which I 100% support.

Everything just leds me to one conclusion:

Dream(s) jobs are an evolving concept.

For more updates make sure to follow me on twitter @arielpozo

Picture by AaDil from Pexels

Last week during retro with my team, one team member told us that he was not fully aware about how webhooks worked or which value they brought to the table. So I decided to write a little bit about them.

According to Wikipedia, Webhooks are "user-defined HTTP callbacks". They are usually triggered by some event, such as pushing code to a repository or a comment being posted to a blog. When that event occurs, the source site makes an HTTP request to the URL configured for the webhook. Users can configure them to cause events on one site to invoke behavior on another.

In simpler terms, webhooks are the counterpart to an API. In the sense that they provide you information by pushing, relieving you of the responsibility of pulling.

Let's take a look at the following schema:

In this example there is an API that can be called with a movie_id, the response contains some meta data about the movie itself and also the places where it is currently streaming at. If you were really big on that movie and wanted to know as soon as it shows up in whichever streaming service, you'd need to be calling the API constantly.

Sometimes you might even forget about it. Maybe you decide to create a script to fetch that information for you. For this one case, that might be plausible, but now picture needing that same information for thousands and thousands of movies. The script would probably get rate limited. You would have wasted compute and networking resources in vain, because there might not be a change at all. Not to mention API fees if the API has some sort of pricing attached to it.

Now let's look at this same problem, but supposing there is a Webhooks API as well as the regular API:

Notice that we are providing an endpoint_url that is a specific endpoint within our domain that will handle whatever payload the movie service decides to send. We are asking to be subscribed to changes on the streaming_on field for a specifc movie_id.

Now, whenever there is a change to the streaming_on field we will get a payload to the provided endpoint_url. That url will be an endpoint of ours that has the business logic to handle whichever information the payload provides.

So that's webhooks in a nutshell. The business applications are endless, since there are lots of different events that one might be interested on monitoring for different purposes.

If you want to play around here are some well documented Webhooks APIs:

Github
Mailchimp
Twitch

Another handy link is https://webhook.site . It provides you with a disposable endpoint_url for you to use when subscribing to webhooks. There you can see payloads as they are posted to you from which ever webhooks api you subscribed, it also has a 500 request log.

I hope you found this basic introduction interesting and insightful, thanks for reading !

For more updates make sure to follow me on twitter @arielpozo

Picture by Joetography on Pexels