DEV Community: Tim Myers

A Quick Note About My Posts

Tim Myers — Tue, 13 Apr 2021 04:37:10 +0000

Hi, I just wanted to leave a quick note about my posts. I'm not an expert, I never claimed to be. Like a lot of you the code that I write is a culmination of me struggling through to find the best solution I can.

I might say stuff that's incorrect, but it's correct in my mind at the time that I wrote it. Feel free to tell me that I'm wrong, (in a constructive manner).

For me these posts are a way for me to check my understanding. If I write it out I can cement it better in my own head and if someone tells me that something I wrote is incorrect then I tend to learn better that way.

So don't be shy. Let me know.

Thanks for reading and that's all y'all.

Thoughts on Blazor

Tim Myers — Tue, 13 Apr 2021 04:18:13 +0000

Here are just some quick thoughts about Blazor so far. I'll give you the tl;dr upfront because I'm cool.

If you're running a node, or other backend you should keep using whatever frontend framework you're currently using. You can check Blazor out and maybe start learning it but I wouldn't rewrite any of your stuff in Blazor.

The reason behind this is because IMO you lose some of the benefits of Blazor if you're not running a dotnet backend. One of my current pain points is that I'm running a React frontend and an Azure Function(C#) API.

I'm doing a lot of extra mapping. On the backend we have our Entities and DTOs. Then on the front end I'm taking data from the API and remapping it to fit the React frontend.

Just as a quick example we might have a Database Entity with First Name, Last Name, and Middle Initial. We don't need the Middle Initial on the frontend so our DTO only has First Name and Last Name. Those Two fields are sent to the frontend and I want to display them like this:

Lastname, Firstname

So what I do on the frontend is create a mapping function:

const mapFormValues = (values) => {
    return `${values.Lastname}, ${values.Firstname}`
}

Now I could just pass down a field that is already a combination like FullName: "Myers, Tim" but there are places where I still need to have just the first name or just the last name.

Its easier to combine values than it is to try and substring the whole value.

Another issue is that in C# our field names are Pascal Case and in React our field names are camelCase. You don't want to know how much time I've spend trying to figure out why something isn't rendering only to find out that the API is sending me, LastName and I'm using lastName.

So if you're running a C# backend you can directly benefit from using Blazor because you can share a model between the front end and backend.

I have a small app that I've written in React/Node/MongoDB and I am going to rewrite it in Blazor/ASP.NET to see what the actual pros and cons are.

Thanks for reading and that's all y'all.

Axios PUT Verb

Tim Myers — Mon, 12 Apr 2021 19:19:49 +0000

Axios PUT Verb And Why I Suck

So this is one of those posts where I had such a hard time I just wanted to document it so I would have a note for myself in the future.

Here's the issue I was having:

We have a project that uses React for the frontend and Azure Functions for the API. One of our Azure functions for submitting an order required, GET, PUT, POST, DELETE.

I got the function setup and all of the backend code was working using Postman to submit requests to the API.

When I started working on the front end everything was working except for the PUT verb.

The DELETE verb code looked like this:

const handleOrderDelete = async (orderId) => {
  const token = await getTokenSilently()
  var response = axios.delete(`http:localhost:3000/${orderId}`, {
      headers: {
          Authorization: `Bearer ${token}`,
          'content-type': 'application/json',
          'x-functions-key': "AZURE FUNCTION KEY HERE",
      },
  })
  if (response.statusCode === 200) {
      console.log(response)
  } else {
      console.error(response)
  }
}

The PUT verb code looked like this:

const handleOrderEdit = async (orderId) => {
  const token = await getTokenSilently()
  var response = axios.put(`http:localhost:3000/${orderId}`, {
      headers: {
          Authorization: `Bearer ${token}`,
          'content-type': 'application/json',
          'x-functions-key': "AZURE FUNCTION KEY HERE",
      },
  })
  if (response.statusCode === 200) {
      console.log(response)
  } else {
      console.error(response)
  }
}

Now at this point it's important to note that I copied the handleOrderEdit code from the handleOrderDelete code. They are VERY similar, the only main difference being the .put and .delete verbs themselves.

Now if you're astute and you are familiar with Axios you may already see the issue. If not see if you can figure it out.

So the DELETE was working, but when I ran the PUT I was getting a 401 on the Network tab in chrome devtools. In my C# console I was getting the error, NO TOKEN. ERROR.

When I looked at the request payload I saw that I had a token, "Bearer 8df7saf8d7sa8f9dsa7f89saf6798saf" or whatever. Most importantly my breakpoint I set in Visual Studio right on the opening bracket of the PUT method was not being hit.

I replaced the axios.put call with a fetch call since they use a similar API. I had narrowed my search down to some issue with axios at this point because it was working in Postman.

I added the fetch like so:

fetch(`http://localhost:3000/${orderId}`, {
            headers: {
                Authorization: `Bearer ${token}`,
                'content-type': 'application/json',
                'x-functions-key': 'AZURE FUNCTION KEY HERE',
            },
        })

and it worked just fine. I started looking a bit closer and I noticed something. When I submitted my request with axios the Bearer token was in the Payload, not in the Request Header. Hmm.

So, to make a long story short, (too late amirite???), I didn't realize that the PUT verb requires a body. We're not sending a body because all we're doing is setting the order back to a different status but we're using the PUT because all of the other verbs are being used.

Typically you would ALWAYS send a body with a PUT because you're updating a record and you need to send the information your replacing. Ours is a unique usecase and since we're sending the orderId in the url then we didn't need to send a body.

The code that fixed this whole thing is:

 const handleOrderSign = async (orderId) => {
        const token = await getTokenSilently()
        var response = axios.put(
            `${api.order.url}/${orderId}`,
            {orderId}, // < -- this
            {
                headers: {
                    Authorization: `Bearer ${token}`,
                    'content-type': 'application/json',
                    'x-functions-key': api.order.key,
                },
            }
        )
        if (response.statusCode === 200) {
            console.log(response)
        } else {
            console.error(response)
        }
    }

Even though I don't need to send a body I'm sending the orderId in the body just so I better conform to the axios standard.

So this is either one of those things that everyone knows and I'm just slow on the uptake, or this is something that happened because we're not using the tool the way it was intended, or it's a lack of documentation on axios' side.

Anyway,

Thanks for reading and that's all y'all.

JavaScript Baseball

Tim Myers — Sat, 10 Apr 2021 15:40:05 +0000

Do It Because It's Fun

Some advice I give to people a lot is once you have a good grasp on your preferred language you should build something you're passionate about or something you enjoy.

With new programmers a lot of the struggle is habit building. Getting into the groove of studying and learning takes time. And it's a lot easier if you're having fun while you're doing it.

Now the key like I said before is to try and create a project that you find interesting. You may be thinking, "But I only like nuclear physics... how am I going to write a program about that?"

The key here is not to build some elaborate project... at least not at first. You could create a project that asks you Nuclear Physics questions and you can keep track of correct answers and provide a scoreboard.

Then you can build on that idea. You can add multiplayer support. A timer to answer the questions. Some fun animations, etc. Just add onto it piece by piece until you have something.

Play Ball

I'm not particularly fond of Baseball. I played Little League as a kid, I umpired games for the really small kids, and I played in High School. But I sort of lost interest in it after that.

I decided to do this project because I had given this project to people that I had mentored in the past and I wanted to see how difficult it really was, (maybe I was asking too much of them). Now, I didn't build a Baseball game with full 3D graphics and controller support. It's basically just a bunch of HTML output in the browser:

I've abstracted away a lot of the complexity. You don't swing at a pitch or anything. You just pitch the ball. Then a random number generator will either make that pitch a "strike", or a "ball". Once you get to 4 balls the batter is "walked". If you get 3 "strikes" the batter is out. Basically I just use the fundamental rules of baseball to keep track of everything.

I picked baseball because it's a relatively slow paced game but you can really do this with anything:

Horse Racing
Tennis
A simple solar system simulator
Cricket
A (Pet) Program where there is a creature of some sort that you have to take care of.

There are tons of options. Pick something you enjoy and simulate it. Start small, and build the project up. Do you think that Twitter or Dev.to started out the way they are now? Nope. Twitter probably had the ability to login and send a message and that was it. You probably couldn't like, follow, retweet, block, mute, etc. They built an app with minimal functionality and build up from there.

Here is the link to my easy-baseball repo if you'd like to take a look at the whole project. You can run it yourself and try and figure out how it works. It's actually not a lot of code so don't be intimidated. Just go have a look.

If you want you have my full permission and encouragement to build on this project. There isn't a lot of functionality and there are a few bugs. See if you can find them and fix them.

Thanks for reading and that's all y'all.

5 Ways To Drive Engagement In 2021 With This One Neat Trick

Tim Myers — Sat, 10 Apr 2021 03:24:05 +0000

Use a Fiver

1.) Write a title with the number 5 in it. People like the number 5 because it's not too big and it's not too small.

Set It and Forget It

2.) Write your post and then forget about that shit. Don't look at it, don't respond to comments, basically don't engage at all.

Get Your Grifter Friends to Share Your Post

3.) It's not good grift if no one sees it. Make a deal with your friends that if they share your grift, then you'll share their grift.

Keep It General and Worthless

4.) Don't ever give away any valuable information. Why would someone buy your course or eBook if they've read it already. Make sure not to hamper your profits by posting any ACTUAL useful information.

Reduce, Reuse, Recycle

5.) Don't ever dispose of your grift. Keep juggling your posts over and over again. Just make a small change like changing the date from 2020 to 2021. Share 10 items instead of 5. Share 8 items. You get the picture. Don't ever throw anything away.

Always Make It Look Like You're Helping

6.) Don't forget to drop that bonus tip. People will really think you care. They won't know that you're following rule 5 and you just cut a post of 10 tips down to 6. You'll be giving less but they thing they'll be getting more.

Thanks for reading and that's all y'all.

Mastering the Job Interview

Tim Myers — Fri, 09 Apr 2021 15:41:22 +0000

Mastering the Job interview is vital to your success as a developer.

(This is not an absolute guide, these are just things that have worked for me in my career, maybe they'll work for you to.)

Keys to a successful Interview

Prepare for the interview
Stand your ground
Ask questions to stall for time
Be yourself, but be the best version of yourself

Prepare for the interview

I don’t mean preparing code-wise, I mean prepare by learning anything and everything you can about the company. I have literally seen a candidate get turned down because they, “didn’t even know who the CEO was!“.

You need to research the company website, look at the staff, read the blog, read financial data if they have it posted, etc.

Most of the time, when you go in for the in person interview they tell you ahead of time the name of the person you are going to interview with. Look that person up on LinkedIn or twitter. See if you can figure you who they are, what they like to do. See if you have anything in common, like maybe you went to the same school.

You should spend a minimum of 1 hour researching the company. If the company makes a product, like a web or mobile app, you should download or install it. Create an account, play with it, see how it works.

If you can show that you did a TON of research before the interview it will make you look REALLY good.

Stand your ground

Standing your ground doesn’t mean you should be argumentative, or unpleasant. But it does mean that you should have an opinion. Don't just say things that you think they want to hear... especially if you don't believe those things yourself. You should make your opinion known and defend it. If they ask you if tabs are better than spaces and you say, “Yes, I think tabs are better”, and they tell you that you are wrong don't say, "Oh, yeah I meant that spaces are better."

Go to bat for yourself. Tell them that you disagree and list off several reasons why. This method can be tricky. First of all you have to actually know what you are talking about, don’t “blow smoke”. If you feel passionate about a subject feel free to defend it.

Ask questions to stall for time

Let’s say your interviewer just asked you a question. Maybe you know the answer but because of the stress of the interview you are having trouble voicing it. If you ever find that they have asked you a question and you are going, “Um…uh…ummmmm…uhhhhhh” then just start asking questions.

It makes you look like a really smart developer. Developers who are good at their job ask questions. When they are given a task they don’t just start hacking away. They make sure they fully understand the problem… by asking questions. It could look like this:

Interviewer: “Write me a function that takes two numbers as inputs and squares each number, adds them together, then returns the total.”

This is a simple example for demonstration purposes, but you get the picture. Now, lets say that you don’t know the answer or you are trying to think of the best way to write it. You can ask polling questions to get extra time to think.

Interviewee: “Ok, let’s see… will I have to account for negative numbers? Should I account for inputs of other types, like strings, arrays? What would you like the answer to look like when it is returned?”

Be yourself but be the best version of yourself

This is probably the most important one. Basically, you want to be yourself. If you are funny, you should tell a joke or two. If you are really knowledgeable on a subject try and steer the conversation to that thing. Most importantly, don’t “blow smoke”. If you don’t know the answer don’t try and “invent” an answer just say that you don’t know but you would definitely look into it later after the interview.

You can say something like, “I actually don’t know the answer to that but I’ll make a deal with you, I’ll have the answer for you my first day on the job.”

What I mean by “Best” version of yourself, is that you should be yourself but try and accentuate the positive things and downplay the negative things. If you know that you tend to complain a lot and they ask you why you are looking to leave your current company don’t go on an hour long tirade about how terrible the last company was.

Thanks for reading and that's all y'all.

Gatsby Blog Workflow for iPad/iPhone

Tim Myers — Fri, 09 Apr 2021 15:20:09 +0000

In order for me to blog regularly it has to be easy, seamless, and convenient. Part of the issue is that I rarely have time to sit down and just compose a blog article from start to finish.

I’ve had the idea of blogging from a mobile device for a while because I always have one with me. I started looking for a good solution and got some guidance from peeps on Twitter.

I downloaded and purchased “Working Copy” and I’ve been using iAWriter for some time now. I used to blog exclusively on WordPress (capital P dammit), and it’s great for desktop publishing but I was never able to find a satisfactory way to publish.

I tried an iOS app called Blogo, but it was never good enough and I found that I spent a lot of time playing with the software instead of writing.

I tried the WordPress mobile app when it came out but it still felt clunky and I didn’t like the editor. Not to mention that at the time it didn’t have markdown support.

I was tired of paying $300/year for WordPress hosting so I started looking for a free option. I went with a Jekyll site at first which was ok, but I’m not a Ruby developer so making changes to the site were tedious for me.

I started using Gatsby and Netlify about 6 months ago. I ran through the Gatsby tutorials at LevelUpTuts.com and built my blog. This was version 1 and I went a little crazy with it. It was complicated, I had a ton of slick animations and honestly that’s not me.

This isn’t my portfolio that I would show to a potential client, this was a BLOG. I would be writing articles about the various dumbfuckery that I get up to on a daily basis.

I revamped the website, stripped out all of the garbage and now I have a BLAZING fast site that does what I want it to do…server blog posts.

The real thing I’ve been looking for was a way to get it so that I could write the blog in iAWriter, then push the finished post up to github to kick off my CI/CD process.

So here is how I’ve managed to pull this off.

iAWriter creates a folder in your iCloud files section that looks like this:

set this folder up by moving your gatsby blog files into it. I just moved the entire project into that folder at the root level because I am not going to use this setup/editor for anything else. In the future if I start a second blog I can just rearrange the folder structure.

Open Working Copy and navigate to the iAWriter folder in your iCloud drive and select that folder as your working copy. (You can also just use the new Github app, but I don't go into that here.

After that you can setup a remote in working copy and from this point your editor and working copy will be synced. You can make edits in either working copy or iAWriter and those changes will be reflected in the other app.

This is just a test and I wanted to post about the process to get this working. I’m using my iPad to create this post and I’ll keep using this process for the next few weeks and I’ll update the post when I have more information.

If you have any problems getting this up and working or if you have a better suggestion then please let me know in the comments.

Thanks for reading and that's all y'all.

Should you pick C# over JS? Maybe.

Tim Myers — Fri, 09 Apr 2021 05:48:22 +0000

As a new developer people tend to steer you towards Python or to an even greater degree, JavaScript.

I know this to be the case because I’ve done this myself. But I think I’ve had a change of heart.

You see the barrier to entry with JavaScript is VERY low. Technically all you need is VSCode and a Web Browser. Both free and bot available on almost every OS.

Tip: if you setup VSCode in the cloud like I describe here:

https://youtu.be/zQE13HTocpU

you can literally code on a tablet.

When I was first exposed to Microsoft and dotnet back in 2004 there was an extremely high barrier to entry. You had to have a MSDN subscription, (which was $3000-5000 per year).

But today Microsoft has really changed their tune. You can get a free community edition of Visual Studio, you can sign up for the free tier on Azure and even DevOps is free up to a certain number of users.

Windows 10 is more open than ever, dotnet is cross-platform, etc. So what is the barrier to entry like now? I would say it’s about the same as with JavaScript. You have a choice of free IDEs and free hosting.

So now this is where people argue that “JavaScript” is easier to learn. But is it though? I’ve spent a lot of time with both and I have to say that the learning curve with C# might be just a little bit steeper but once you learn the basics you can advance at the same rate as someone learning JavaScript.

One thing that I had forgotten about since I hadn’t done a great deal of dotnet development in almost 5 years was how much the IDE assists you. I can create a Model with 20 properties in about 10 minutes. The prop snippet is your friend.

I never really feel at home in a JavaScript codebase but I dove into a fairly complex ASP.NET backend project recently without having done much in over 5 years and everything was still accessible to me. I still had the muscle memory.

I think one of the Pros (though it could be considered a con by some), is the fact that the C# language itself doesn’t seem to be evolving as rapidly as JavaScript. It’s more “mature” if you will. Maybe that has more to do with the fact that its highly structured.

One of the things that struck me as funny when I came back to dotnet was the fact that if you search online for how to do something the C# code snippets you find are going to be fairly similar. Whereas, with JavaScript you can find 100 posts with 100 different ways to do things.

I think a lot JavaScript development is, “let’s see how clever I can be” instead of, “let’s see how readable and robust I can make this.”

These are my personal opinions and I’m sure this “hit-piece” is going to cause some controversy but I think if you commit to taking a look at the “new” dotnet you’ll be pleasantly surprised.

Thanks for reading and that's all y'all.

Sometimes It's The Details

Tim Myers — Wed, 07 Apr 2021 23:03:21 +0000

Sometimes switching to a new language or framework doesn't mean that you have to make a vast shift in your thinking. In almost every language the concepts are the same it's just the syntax that people get hung up on.

I've been using JavaScript, (specifically React), daily for like 4 years and I've grown accustomed to the "loosey" nature of JavaScript.

For example,

let disabled = true;

if(disabled){
  // you can just do this.
}

You're relying on the fact that disabled can be either true or falsey. So you don't have to check disabled for null and undefined and false and empty, etc.

In most languages you have to make those checks explicit.

if (disabled != null && disabled != true && TypeOf(disabled) == bool)

So learning the quirks of your particular language is the real trick. Loops work the same conceptually in almost every language.

Thanks for reading and that's all y'all.

Setting up Blazor with Tailwindcss

Tim Myers — Wed, 07 Apr 2021 05:05:58 +0000

So, you decided that you want to try Blazor... Then you decided that you want to try Blazor with Tailwind. This mix of tech is what I like to call WindBlazor.

One of the first things you need to do is get all this junk setup. It's not that hard, I was able to do it in about an hour the first time.

Then I created a repo with the resulting files and made a Github Template out of them. So yes, it took an hour but that was just the one time. Each time I start a new project from now on all I have to do is clone my repo:

https://github.com/denvercoder/windblazor.git

Now Chris Sainty already wrote a really good post on how to integrate Tailwind into Blazor. You can find it here:

https://chrissainty.com/integrating-tailwind-css-with-blazor-using-gulp-part-1/

Chris' article is great but in my opinion he left out a few steps to really get you squared away.

First of all he doesn't talk about getting a watch to work.

You can run dotnet watch run from the server project but that only watches server files. If you want it to watch frontend files you have to add a few things.

You'll want to look in your Server.csproj file and create an new ItemGroup like so:

  <ItemGroup>
    <Watch Include="..\Client\**\*.razor" />
  </ItemGroup>

I got the above tidbit from Patrick God.

Now what that will do is the server project will now watch Server files but it will also watch any razor files. When you add:

class="text-red-500 p6"

and then save the file, dotnet watch run will recompile the app and then refresh your browser so you can see the result.

Thanks for reading and that's all y'all.