DEV Community: Adam McGurk

Never get overcharged by AWS again

Adam McGurk — Fri, 27 Jan 2023 00:17:24 +0000

If you're a dev who has experimented with the cloud, the fear of a surprise huge bill has crossed your mind. You aren't alone. You can go to twitter and search "AWS Bill" and see hundreds of tweets either making jokes or sharing their real life experience of a surprise cloud bill. It's a reality that shouldn't be, and now doesn't have to be anymore.

Introducing Cloud Kill Switch. This is the first (and only) product that automates the ability to set a billing limit in your cloud account.

This is how it works:

You authenticate your cloud account. Right now you have to input an access key and access secret for AWS, but we delete these from our database as soon as your kill switch is implemented. For Google Cloud we use Login with Google (oauth).
Using our product, you set your configurations in plain language, no cloud knowledge necessary!
You pay the simple, one-time fee.
Our server goes to work installing all configurations necessary on your cloud account to make your billing limit a reality!
If your account hits the billing limit, it does the following: a. For AWS, it shuts down the resources (either RDS or EC2) that you defined when you configured your kill switch. b. For Google Cloud, it removes your billing account completely, ending billing right then and there. In both situations it means your services will stop working, so it is not suitable for production use, just for hobbyists and students to protect your wallet and peace of mind!

This has been an idea I've had for a long time, and something I have installed on all my test accounts! Right now it's still in beta and, so would love any feedback on it, and we're launching with AWS right now supporting just USD. Google Cloud is still in a closed beta. If you want access to that closed Google Cloud beta, email me at support@cloudkillswitch.com !

Lessons learned from building my company's sales and marketing platform in three months

Adam McGurk — Wed, 18 Nov 2020 20:11:19 +0000

AKA...the story of Luminary.

In May of 2019, I made the largest declaration of my entire career that changed how my company interacts with our customers forever.

I said that I would build our entire sales and marketing platform and be ready to roll it out to our sales floor of 15 salespeople, in three months. From May 6th - August 6th.

I was sworn to it by the CEO of my company, and in large letters on my whiteboard I wrote "August 6th", with a crude drawing of an airplane next to it. It was going to come, by hell or high water.

Since then, it has processed tens of millions of dollars of revenue, had hundreds of employees use it within the company, and processed over 500,000 phone calls, 100,000 text messages, and 45,000 leads.

In this time, I learned a lot, made a lot of mistakes, and came to three key realizations in how I built it, that I want to share today.

1. Tomorrow will always come

Right after a launch, (and especially after a launch that quick), there will be bugs. And oh boy, did we have our share of bugs. Every day for days after this is a good representation of how I felt:

But the sun always rises on a new day. You will deal with bugs, and as long as you make your users feel cared for and important, all issues will be worked out.

2. Sometimes you have to make tradeoffs

There comes a time when building software that you have to make tradeoffs. That may seem like a very basic realization, but to me, I thought all software was either built right or it wasn't. It wasn't until I undertook this massive project, that I realized shades of gray exist. Sometimes, you have to hard code that feature. Other times, you need to tell a stakeholder what they want isn't going to happen, yet. Until you learn this lesson, you will ALWAYS hold yourself to unreasonably high standards, and end up looking like this:

3. It's better with a team

I built the entire thing by myself, from UI implementation to database architecture. While I did this, the rest of the engineering team that I managed worked on maintaining other web properties.

After the initial build, we started moving the whole team onto the maintenance and building out features for the system. And my goodness!! It was so much better when I could bounce ideas of other engineers, and give things better suited to their specific talents to them. Again, that seems like a shallow realization, but sometimes, while doing development seems better in a vacuum, it's always better when done with others!

In the end, I succeeded! I delivered a fully functional CRM that worked for the entire sales and marketing team in three months. And while it has grown far past what I initially built, the core functionality is still there, and it's a thrill to work on it every day a year and a half later with how far it's come!

Let me know if you all want to hear more about this and specific engineering decisions in the comments below!

Make all of your Google Fonts SCREAMING fast

Adam McGurk — Wed, 22 Jul 2020 23:44:24 +0000

I think we all know that one of the parts of building web pages that impacts performance the most is loading web fonts. That's long been a pain for a number of reasons - foremost because web fonts are often the cheapest, fastest way to get a good-looking type on your webpage.

With that convenience comes a price though...and that price is often one or sometimes even two seconds of load time on your web page.

At least...that was true until Harry Roberts of CSS Wizardry pulled out his magic wand and changed the Google Fonts game.

If you haven't read it, one of the most recent articles on CSS Wizardry is the best breakdown on performance of Google Fonts I've ever seen. Here's the link:

https://csswizardry.com/2020/05/the-fastest-google-fonts/

PLEASE read it if you care about web performance at all. It's a masterclass in what you can and can't do and a test from every conceivable angle on how to most optimize Google Fonts for speed.

And so immediately after I read it, I decided that in every web project I have, I'm going to replicate it. That's where I ran into a little bit of frustration.

It's four lines of code that you have to get exactly right or else it won't work at all. That's how tags in the HTML head work. And while the code is revolutionary, it's cumbersome to copy, paste, and replace the URL of your new font every time.

Enter https://optimizefonts.com/d/1/1

I finally decided I was just going to throw up a webpage where I could go, enter the URL to the font (or just the link tag) and it would give me back the code needed to optimize that font to the max.

No frills, no bells, no whistles. Completely free.

Go to https://optimizefonts.com/d/2/1 if you want to get the most speed you possibly can out of your Google Font.

Let me know how you all like the tool and if there's anything you would add to it! It's still very much a work in progress, so I'm very open to feedback!

Photo by Harley-Davidson on Unsplash

It’s about the why, not the what

Adam McGurk — Tue, 23 Jun 2020 12:02:05 +0000

One of the things my wife and I most like to do together is play board games. Oftentimes, we'll invite other people to play as well.

But we've learned something interesting-most people don't like learning new games.

This had perplexed me for awhile, because everyone loves playing games, but people struggle learning games. And then, last night, it hit me like a ton of bricks.

It's because when we play games we focus on the "what" (or the execution) and not the "why" (the actual problem). Let me tell you what I mean by that.

How many times have you been learning a board game and people try and teach you it...but they only focus on the what? "On your turn you do this" or "When you get this card, you do that" and so on. That's frustrating! Sitting there not knowing what to do and being told what to do...it oftentimes leaves us not even wanting to play anymore!

And so you have to focus on, and tie everything back to the "why", and then people can have more fun!

"But Adam", you ask, "This is a development blog...why are you talking about board games?" And I imagine you can deduce the reason...because this completely ties back to development.

Why do so many software businesses fail? Why do teams sometimes "miss the mark" when it comes to projects? Because they're focusing on the "what." They're focusing on what they're doing for their customer: "these are all the products and features in our product" or, even worse "this is our tech stack! It's super cool and we're very proud of it!" When businesses focus on that, they fail. Businesses should focus on the "why." "We're solving this problem for the customer." "Implementing this solves that problem for the customer." And so on and so on. It's a subtle change, but it works wonders.

Focusing on the "why" is how I'm trying to build my product right now, called: Upvid.app.

So what is my "why"? Well it's: "being able to upload a video and easily share it is too cumbersome, there is definitely an easier way."

The "what" is easy (and sometimes more fun) to focus on: "I'm building a JAMStack app" or "It's going to be able to be searchable, sortable, and be able to give you several different embed codes for your video." But again, when you focus on the what, you will lose sight of what you are hoping to do, which is to solve a problem for your customer.

From idea to public in 3 hours

Adam McGurk — Sun, 21 Jun 2020 03:29:34 +0000

As developers, we get all sorts of hair-brained ideas. I hope I'm not the only one who has a Google Domains account riddled with the land of misfit domains. And so it was no surprise that I had another idea while on a business trip with my product manager this week.

This one was different though.

I didn't start how I usually start - building out the database and sketching out architecture charts (my own personal favorite parts of web development). I started with something else...something I was always told to start with.

I started with the marketing. And it started snowballing from there. Once I was there I got excited about it, and I launched it like I've never launched something before.

This how I took upvid.app from idea -> public in 3 hours.

The Idea

I was having a conversation with my (non-engineer) product manager. He was complaining about having to step through YouTube or Dropbox's process to get a public URL to a video. I then asked him, "Well, why don't you use Sharepoint or Google Drive." And he said he wanted to be able to give the video a name, be able to search the videos, and be able to "click to copy" the URL.

When I tried to convince him that he could still do those things in Sharepoint or Google Drive, he finally admitted that he wanted something "simpler" and that he'd be willing to pay for it.

The idea - A STUPID simple way of uploading a video and getting returned a not-easily-discoverable public URL to that video.

The Name

We left the office to go back to our hotel before he had to go to dinner, but all I could think about was this idea. It was so simple, it almost seemed too simple to be a real solution to a problem.

I looked it up, and I couldn't find anything that would let me upload a video file and get a public URL in return. Nothing. There were videos on how to do it with dropbox, google drive, youtube, zoom, etc...but no specific service for it.

Well, I thought to myself, if I have only one paying customer, that would be fun enough to do it.

So I set about figuring out a name, something I'm usually AWFUL at.

But again, this idea is different.

Almost immediately it came to me. What do we want to do here?

Upload a video
UploadVideo
UpVid

That's what it was, that's what it had to be. And while the .com was registered, the .app wasn't.

Quickest $14 I've ever spent.

The Name - UpVid

The Logo

I've never designed a public facing logo in my entire life.

But this idea was different.

We're uploading video, right? Do a logo with an arrow up.

The Logo -

The Landing Page

By this time, I'm absolutely rolling, and I'm not letting anything stand in my way...

But let me say - neither design nor marketing is an incredible strength of mine. I'm a web developer. That's what I'm great at, and I try to stay in that lane as much as possible. So trying to build this idea completely from scratch was proving daunting. I had built other things from scratch, but never something I had been this excited about.

And then it hit me...I wanted a simple video uploader, right? Then I had to keep the whole thing simple.

The Landing Page - A slight green gradient background with an email capture form for the beta signup...and three sentences. (Go to the site to see what they are! upvid.app.

The connection

This one was interesting to me...I needed to set up a connection between my website and a way to email people who were interested in the beta.

This was the first time I had ever done email collection by myself. I'm very involved in my company's marketing efforts, but I'd never done it for a product I'd built myself! It felt great to have that control and that ownership. So, I drew on what I do at work, and connected my Netlify form with Zapier to a small email marketing CRM we use.

The connection - Netlify -> Zapier -> Email CRM

Conclusion

I guess there isn't one yet!! You, the great reader, are the first to hear of this idea outside of my product manager! I'm so excited about this that I had to write about it!

But what say you, dev.to community? Does this seem interesting to you? If it does, give me a shout in the comments, or, put your email in my beta list!!

How to change a foreign key constraint in MySQL

Adam McGurk — Mon, 18 May 2020 19:31:46 +0000

Alter a foreign key constraint in MySQL

(PS...if you want to skip to just the answer Click this link)

I ran into a problem today.

I found a foreign key in my table that cascaded instead of set the key as null.

As you can imagine, this was not a great thing to learn. I lost quite a few log records. Luckily, this is an application used only by me, and I had backups that I could restore to that lost very little data. But finding how to reverse this foreign key effect proved challenging.

When I went to Google for my answer, I found it challenging. There isn't much information about how to alter foreign keys in MySQL.

There is no command like:

ALTER TABLE my_table CHANGE FOREIGN KEY (key_name) REFERENCES other_table(other_key) ON DELETE SET NULL;

That would be sublime if that existed!! Alas, it doesn't, so we must find a workaround. Here is what the workaround looks like.

First - Get the name of your foreign key constraint.

If you're like me, you create your tables (and constraints) like this:

CREATE TABLE my_table (
    name varchar(255),
    key int(11),
    FOREIGN KEY key REFERENCES other_table(id) ON DELETE SET NULL
);

or like this

ALTER TABLE my_table ADD FOREIGN KEY (key) REFERENCES other_table(id) ON DELETE CASCADE;

Without the full MySQL name of the constraint. So how do we get the name that MySQL needs to drop the constraint?

Enter the SHOW CREATE TABLE command.

The output of this command contains the name of the constraint that you need. Here is what that output would look like for my above CREATE TABLE (or ALTER TABLE) command:

SHOW CREATE TABLE my_table\G

*************************** 1. row ***************************
       Table: my_table
Create Table: CREATE TABLE `my_table` (
  `name` varchar(255) DEFAULT NULL,
  `key` int(11) DEFAULT NULL,
  KEY `ke` (`key`),
  CONSTRAINT `my_table_ibfk_1` FOREIGN KEY (`key`)
  REFERENCES `other_table` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

So the name of our foreign key constraint would be "my_table_ibfk_1";

Second - Drop the foreign key constraint.

Now that we have the name to our foreign key constraint, we need to drop it. And this is the part that held me up the most.

I didn't know the consequences to dropping a foreign key constraint. I was afraid because of my own ignorance.

Turns out, there was nothing to be afraid of. If you drop the foreign key constraint, it doesn't have any other effects, and keeps all values intact.

So, here's the code to run to do that:

ALTER TABLE my_table DROP FOREIGN KEY my_table_ibfk_1;

Third - Create your new foreign key constraint

In my case, we need to change the cascade to a set null command. Here is how you would do that:

ALTER TABLE my_table ADD FOREIGN KEY (key) REFERENCES other_table(id) ON DELETE SET NULL;

And that's it!! That's how you change a foreign key constraint in MySQL!

TL;DR

Get the name of your foreign key constraint:
If you don't know the name, run this command:

SHOW CREATE TABLE your_table_name_here\G

And you will get an output that looks something like this:

*************************** 1. row ***************************
       Table: your_table_name_here
Create Table: CREATE TABLE `your_table_name_here` (
  `id` int DEFAULT NULL,
  `parent_id` int DEFAULT NULL,
  KEY `par_ind` (`parent_id`),
  CONSTRAINT `name_of_your_constraint` FOREIGN KEY (`parent_id`)
  REFERENCES `parent` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

Which is where the name of your constraint will be (After the keyword "Constraint". There may be several, but you should be able to pick yours out).

Drop your foreign key constraint:

ALTER TABLE your_table_name_here DROP FOREIGN KEY name_of_your_constraint;

Create your new foreign key constraint:

ALTER TABLE your_table_name_here ADD FOREIGN KEY (parent_id) REFERENCES parent(id) ON DELETE SET NULL;

And that's it! That's how you change your foreign key constraint in MySQL

Why I'm phasing out ternary statements

Adam McGurk — Fri, 28 Feb 2020 16:28:52 +0000

I'm in a little bit of a bind. Very early on in my software development career, I learned about these things called ternary statements, and I thought they were the coolest thing ever. I started using them everywhere...but now, I'm just having different thoughts. Let's take a step back for a minute though.

What are ternary statements?

Ternary statements are (put simply) shortcut if statements that look like this:

const val = "test";
const showTest = val == "test" ? "The value was a test value" : "The value was not a test value";

(Go to this MDN article to learn more about ternary operators: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator)

Spoken in plain english that code is translated to:
IF val is equal to the value of "test"
THEN set the variable showTest to the value of "The value was a test value"
ELSE set the variable showTest to the value of "The value was not a test value"

What's the alternative??

To me, early on in my career, this seemed like an absolute godsend. The alternative code looks like this:

const val = "test";
let showTest;
if (val == "test") {
    showTest = "The value was a test value";
} else {
    showTest = "The value was not a test value";
}

And if you hated more lines of code like I did early on, this seems like a no brainer. A two line solution verses a seven line solution is really no question.

So what's the problem?

Remember how in the beginning I referenced that I was in a bind...well here's the bind.

In the application that I have built (and now work on maintaining for the company that I work for) I used ternary statements EVERYWHERE. I used it for absolutely everything that I could. Less lines of code, right? Well I've realized that the only thing that cares about lines of code in your app is this website right here:

https://linesofcode.app

And besides that, going after less lines of code isn't always the best. In fact, I run into two problems now going back to the application and trying to refactor the ternary statements a little bit.

The mental overhead it takes to make a change in the logic.

Ternary operators only support one action for each block of the if. So in the code above, maybe all I wanted to do in the beginning was set the showTest variable to a string...but what if now I also want to fire off a function if val does equal test? I have to go back, remember what it was doing, try and remember why I thought there would be no other actions necessary, and then refactor it to look like the second example I've posted up anyways.

The distinct lack of code readability

Code like this that does so much in so few lines of code really loses it's luster when it comes to readability. It may scan better, but it also does provide a mental block when it comes to readability that the other example does not.

So what?

All in all, I will probably still use ternary operators...even after everything I said. Why? Because there is definitely a time and a place for them, just like with everything. What we have learned here where I work though, is that time and place isn't littered through the codebase, just trying to cut a 127 line file down to a 122 line file.

What are your thoughts on ternary operators?

Lessons learned from surviving an application attack

Adam McGurk — Mon, 10 Feb 2020 23:23:33 +0000

It's two o clock, and I'm minding my own business, working on some bugs and listening to my favorite YouTube playlist...when I get a call on my phone. It's from the CEO.

"Hey, what's up man??" I say, a little hesitation in my voice, hoping everything is alright.

"Adam, we have a really weird thing going on right now [in the background, I can hear the DEAFENING sound of phones ringing off the hook]."

"OK, what's going on?"

"Well, log into [the app], and look at our incoming calls. We're getting HUNDREDS of calls, and it just started about ten minutes ago. What's going on?"

Well, I did log into the app, and he was right, we were getting HUNDREDS of inbound calls, and they were coming in more and more by the second. This is INCREDIBLY unusual, as we never get more than one or two calls at a time, and NEVER more than one hundred calls a day. Something was definitely wrong.

"I don't know what's going on," I say, as my blood pressure and heart rate rise to a speed I didn't know possible, "I will get back to you as soon as I can with as much information as possible."

"OK, thanks. Please, as soon as possible."

We hang up.

This is the story of how we fought it off, how we survived, and what can be learned from the terrifying experience of someone or something potentially jeopardizing your system.

Some Background

I run a development team that primarily works on the sales CRM for a pretty established company in the Midwest in the United States. This is a sales platform where people fill out a form on our website, our Facebook page, etc...to say "I want to know more" and then once they fill that out, they are pushed into our CRM to be called and/or texted. In addition, we run ads on TV or radio saying "Call this phone number" and once they do call it, they are put into our CRM as well. We use Twilio for our VoIP/SMS/MMS backbone.

This system is the backbone of how we sell our product and when it is in peril (as it was) every single person in the entire company is affected.

The problem

This problem had multiple angles, but what it really was, was there was some actor that somehow had gotten enough control of our phone number that they were able to make calls with our phone number to thousands of other phones and leave missed calls on their phones. That was the problem.

And this is such an important part of combating and surviving an attack such as this. Understanding the difference between a problem and a symptom is so crucial.

The main symptom of the problem was that hundreds of people called our phone number back, because they believed that we had called them, thereby overloading our front desk people and everyone else in the company who was using our system. While this is bad, it was not the problem and differentiating between a problem and a symptom is incredibly important in a time like that one.

This problem is definitely not an easy one to fix, but time was working against us. We were receiving hundreds of incoming calls every second, ballooning our server logs as the minutes ticked by, and we were about to start to get into dangerous territory of our app being taken offline, or worse.

The (temporary) solution

I knew in my head that the main problem could not be fixed right then. There were too many steps and too much red tape to go through with Twilio to stop the main problem (ultimately fraud) right then and there, and so I quickly turned my power to stopping the symptom.

I turned off the phone number.

This had a few ramifications.

Most importantly, the incoming calls stopped.
This was (and is) a phone number that runs in ads on radio stations. Somebody could potentially call that number, and we could miss out on a lead or a sale. Luckily, that phone number hadn't gotten a real call in over two months and so there wasn't much of a chance that this phone number was going to receive any real lead calls. But had it happened with a different phone number, we could have lost out on business.
It didn't fix the problem, but it did fix the largest symptom, serving to make everyone think "whew, the problem is fixed." Because even while myself and my team know that's not the case, it makes everyone think the problem is fixed, when in fact, the underlying problem wasn't fixed at all.

The (followup) solution

Myself and my team have alerted a few Twilio channels (including their fraud detection line) to no response yet. We have and will continually reach out to get a response, but we may have to get rid of that number altogether from our Twilio account.

Lessons learned

Sitting there about thirty minutes after it happened, I felt like I had aged ten years. I took it as a good teaching moment, especially for my junior developers, who had never seen something like this happen before, and here were the main takeaways I tried to communicate:

Gather as much information as possible, and then step away to get it done. It serves nobody to stay on the phone with anyone who cannot give tangible technical help, just so that they can get "up-to-the-nano-second" updates. You as the engineer need the space to be able to get to a fundamental understanding of the problem, and then get everyone either off the phone or out of the room who cannot help. With the promise (and the implicit trust) that you will provide them updates as they arise. This was the first thing I did. Got an understanding of the problem and said "I don't know what's going on, but I will get back to you as soon as I can with as much information as possible." And the phone was hung up.
Mitigate immediate threats. While not the main problem, the incoming calls were immediate threats to the system, threatening to potentially take us offline, which would severely hurt the business. I don't care if the mitigation strategy is to turn off the servers, if you have to go nuclear, go nuclear. Luckily, in this case, mitigating the threat was as simple as turning off (or un-routing) the phone number that was being called.
Work backwards and eliminate places where the system is not failing. Draw out on a piece of paper or a whiteboard every point of action between the bad actor and your system. Then begin to eliminate the places that you can prove are not comprised. This serves two purposes.

One - To help you focus on what truly the problem is.
Two - To help you maintain confidence and trust in what you're working on, so that you don't begin to fall into an anxiety induced panic, which is a very real thing that can happen in situations like this. Working through things like a checklist (checking off points of action that are not comprised) is therapeutic and really enables you to keep your head clear and focus on the problem, and not just that there is a problem.

Gather the correct people and hold a breakdown meeting. This part is so crucial for multiple reasons:

One - It is very important to maintain the trust of the clients you're building your product for. At the end of the day, the people you build for really just want to know that the people they entrust their business to are responsible enough to handle it. Maintaining an open communication is crucial to maintaining trust when things like this happen.
Two - It is very important that you gather everyone who needs to be there so that everyone who needs to gets the information at the same time. There is no reason you need to spend the rest of your day on the phone with everyone, explaining the same thing fifty times. Not only is that frustrating to you, but it is also frustrating to the person who thinks they should have known "first", but ends up being the seventh person to know.
Three - As long as you were honest with what happens, it allows everyone to be on the same page, with no questions left in people's heads. Being proactive about this meeting is how you accomplish this last piece. If you are the one asking to have this meeting, and asking to put it together, and not your project manager, that puts a lot of trust in you as the engineer, that your main focus is getting the problem fixed, and not covering your own back.

Conclusion

At the end of the day, it could have been a lot worse. We were able to prove that nobody gained un-authorized access to our Twilio account or our Sales CRM, and we have narrowed it down to a rogue actor committing fraud with one of our phone numbers. We are still waiting on confirmation and next steps from Twilio on that one, but that is our hypothesis right now.

All applications have been or will be hacked. If it hasn't happened to you yet, just wait. But it's not the end of the world. Stay calm, identify the problem, mitigate the threats, and learn from it. That's all we can do, and if we do that well, everything is gonna be alright.

How One Article Shaped My Career

Adam McGurk — Thu, 17 Oct 2019 00:34:55 +0000

As I'm now several years into a career that I never expected I would be in, (but loving every second of it) I've been able to look back at a few key moments that happened very early on and how they shaped who I am as a developer and a tech thinker as a whole.

It's hard to pinpoint certain actions that you take or certain things that you learn that really shape you as a person, but for me, this experience was one of them. And it all boiled down to me typing this question into Google:

How do I learn jQuery?

I was young and trying to make my business of being a concert promoter in a small town flourish. I was building websites for all of the shows that I was putting on, and also trying to make a little money on the side to fund my business, and there were a lot of things I wanted to do where I thought "if I just knew jQuery, I could get this, this, and that done" (obviously, this is a few years ago :) ). And so, I figured, "well, let me go learn jQuery". At that point I thought JavaScript was "too hard" for me to learn and I would start with something easier.

Well, when I typed "How do I learn jQuery" into Google...I got an interesting response that came up very high in my search results...and it was an article like this^*: Why Beginners Should Not Learn JavaScript Through jQuery

I couldn't believe it. I read it. And I read it again. And I read it again. Everything in the article made perfect sense. jQuery is JavaScript. It would be better for me to know what's going on "under the hood" then only knowing an abstraction (a library). And on and on. It made so much sense. And it shaped so much of who I am as a developer today.

Language, not framework

Fast forward to today. After a few pivots in my career and a few blessings that I was super privileged to be able to get, I find myself as the lead developer for the tech arm of a pretty major solar company in the United States. And this idea of "learn JavaScript, not jQuery" has been something that I've tried to instill into all of the developers we employ at my place of work. And it's not just the idea of vanilla JavaScript vs. jQuery, but also this idea of "when should I reach for React?" or "Do I really need to import that NPM package when with a little more work I could do it myself and understand what's going on better to improve our development processes as a whole?" etc...

It's been many times where one of the developers who I employ comes to me and says "Can I use jQuery for just this one thing?" or "Can I pull in Bootstrap for this one project?" And you know what? Sometimes, that's not always the wrong question to be asking, and sometimes it's the right call to make on the projects we're given. But anytime that is asked of me, I take it as an opportunity to invite my developers to think about why they're asking to use it? Is it an example of lack of skill, or is it truly the best task for the job?

Wrapping Up

All of this to say...I'm not against frameworks. I think in some cases React, Angular, or Vue all have their merits. The tooling and the ecosystems provided to developers today can make our jobs so much easier, but I invite you the next time you reach for a framework you ask yourself "why am I doing this" instead of just doing what is the most comfortable and beginning to think in this way of "what will also improve my skills as a developer on every single project I work on?". I think when we begin to think that way, is really when our personal (and professional) growth begin to explode.

^*(this is not the exact article that I read...but it was something along these lines. I searched and searched for the article, but I haven't been able to find it. I wish I could, and I'm going to keep searching)!

Best Hosting Choices For Personal Projects

Adam McGurk — Sat, 12 Oct 2019 22:31:25 +0000

Oftentimes we get caught up in the excitement of the what of what we're building when we're building a personal project, that we forget that we need to come up with the how for our personal projects as well. For the personal project that I'm currently working on - a PWA fitness app - I go over what my decision process and which hosting providers I was deciding between - Netlify, Amazon Web Services, and Google Cloud. First we'll go over a bit about the project.

I'm building a fitness PWA for a few reasons. The first reason I'm building this app is because I've longed for a really good fitness app that I can track my workouts with, get motivation and accountability from, and is easy to use and designed well. I really haven't found it yet. I've tried a few different ones, but none of them ever really did what I wanted them to, or they were too tied to their ads or their premium version that I was never able to unlock their true potential. So, I decided that I would build my own. Which leads us to the second reason why I decided to build it myself. Practice. I've been wanting to get a lot better at TypeScript, specifically in the clean code aspect of it, and I've been wanting to practice with IndexedDB and a couple other web technologies that I've never gotten the chance to use before. So, I'm building this app to run completely client side, in true PWA form, that it doesn't send anything to the server. Just pure HTML5, CSS3, and JavaScript.

But in planning this, I thought I should make the hosting decision early. So let's dive into that, shall we?

Amazon Web Services

An incredibly robust platform, one that I've launched several successful work projects on. I could leverage their Elastic Beanstalk service or even just S3 because I'm really only going to be hosting static assets (HTML, CSS, JS). And while the platform gives me SO much more than I could ever use, it would be good practice to help me get more familiar with this behemoth in the cloud architecture world.

Google Cloud Platform

One of the more quiet players in the cloud discussion is Google Cloud...but they are one of the fastest growing as well. I could launch my PWA in their Storage solution (to be served as a website) or in their App Engine service if I wanted more granular control over how my app were to be rolled out and things like that. Google Cloud is my personal favorite cloud solution as well.

Netlify

Netlify has really positioned themselves as the JAMStack hosting provider. Giving absolutely free hooks into GitHub and free hosting with custom domain abilities, Netlify is really in a position to explode in the community for simple/personal projects.

Decision

I really think I'm going to go with Netlify. Maybe in the future I'm going to add an API and send some data up to a server and add logins for multiple accounts and that sort of thing to my fitness app, and so then I'd probably reach for the Google Cloud Suite to host my backend and database needs, but for now, a simple JAMStack provider that gives me free web hosting and domain name customization is really all I need.

On Knowing What and When

Adam McGurk — Sat, 28 Sep 2019 11:27:21 +0000

I like to think that I'm a guy that knows what he wants and how to go about and do it. I've been in the tech industry for quite a few years now, in many different positions. I've been able to climb the ranks in my current path (Software Engineer) and I've been blessed with the opportunity to be the lead on many exciting and fun projects at work.

I say all this to say that when it comes to my hobbies (aka-side projects)...I really have no idea where to start or end...and I think it's the same for us all.

Like many of us, I'm one that has ideas for a lot of projects to do. It is many a Saturday that I spend tinkering with a Raspberry Pi to setup as a web server that I can run cables to so I can turn lights on through my phone...or it has been many a frustrating weeknight when the Cisco managed router and switch that I configured myself has issues (hey, it's been a few years since my networking days...give me a break! :) ).

This mindset led me to a class that I believe will be very good for me, but has also shown me bright and clear a large problem I have, and I believe many of us have. Let me explain.

I have gone back to school to get a formal degree and broaden my horizons in more ways than one. One of those ways was to take a web business creation class where you must pick a field, a product, and go run a Google Ads Campaign to market and sell that product.

"EASY!" I thought to myself, "That will give me the motivation I need to finish idea A that I have sitting in a Sketch file right now...or idea B that I just bought that brand new shiny .app domain for...or idea C...or idea D..." You get the picture.

And so I have found myself at that crossroads...how to do my best work, but still do what really every creative professional has ever wanted to do - publish their work for the masses.

And really, I don't know the answer to that question. Having had few side projects ever make it public, I don't think I'm in place right now where I can answer that question. But I do know this...I hope I never get to a place where I have more time than project ideas. Because for me, that would be the scarier reality.