Finally Done

After over 2 weeks of working on the same project at work, and seeming to never get to a point where it was ready to come to a conclusion, I finally finished it up today. It was a great feeling to get to the end of it, and I think it turned out really nicely. I've been saying for over a week that I was on the brink of wrapping it up, but it always seemed like there was something to add whenever I went to my neighbor to get approval, and to get him to work on the back end part of it. For the last couple of days, I've been sprucing it up here and there, but really haven't added much to it, other than a form page to gather the user's name and phone number. Other than that, I've mainly been working on some refactors. Yesterday, I changed all of the strings in the reducers to variables held in an enum and then worked on destructuring everything I possibly could. I started destructuring yesterday afternoon, and after an hour or so, I was only about half way done with it. So, I spent the early part of the morning finishing this up. Then, I wanted to get rid of as many of the "any" types I had laying around, including all of the types for the events. A common issue with TypeScript is trying to type something like the event on the window, since it returns a complex object. It would be nearly impossible to capture all of the values it returns on your own, nor is it advisable. A common practice would be to just put the "any" type on it, and ignore it altogether. This is what I had done up until this point, but after a little digging last night, I realized there was a better way.

This brings me to a slight interlude on the story of the day. I haven't been limiting my coding to during the day since I started working. In fact, every night I've doubled down and am putting in even more work than I was a month ago to learn as much as possible. One of the perks of my job is that they will pay for any coursework I take, and if you follow my blog, you would know I take a large amount of courses. Most of these are on Udemy, which offers fairly cheap courses, ranging in price from $10 to $20, depending on the sale going on at that time. Last weekend, I picked up Stephen Grider's TypeScript: The Complete Developer's Guide, a 24 hour course on the subject. It has been captivating, and it reminded me of how much I enjoy his style of teaching. He is one of the most thorough instructors I've come across, and focuses a lot of his courses on refactoring bits of code. While some of the applications he builds aren't the largest, he goes to great measures to rework the code in those projects multiple times to gain a greater understanding of the subject. In this course, I've gained a basic understanding so far of TypeScript, and am now getting into the more advanced concepts. He's teaching the course really well, and I feel like this is a great introduction to the material. I was first introduced in my first week of work, when we turned the current application I'm working on into a TypeScript app from being in JavaScript, but this only gave me a general understanding, without knowing enough to manipulate it fully. Now, I feel like I'm more equipped to go back into the application and make the typing stronger, replacing these "any" statements, and adding types to other functions and variables, previously untyped.

So, in the middle of my studies last night, I found some information about how to type these events in React. Apparently, React has done quite a bit with building these types into the framework directly, so all you have to do is reference that property on React to get the type for different events. I got through most of these, and then about halfway through the day, my neighbor let me know he was all done with the backend, and asked how my part was coming along. I told him I was just cleaning up, but I was ready to go, since I've been ready for the last couple of days. We ran the build and sent it up to the development server, and then gave it a test run with an actual credit card. Everything seemed to work. The next step would be to send it to production and hope nothing breaks. So, we did so and handed it off to the supervisor of the project to give it a test run. Immediately, the API seemed to be broken that checked the representative's ID on the first page, throwing a wrench in things from the get-go. This was strange to me, since I had used the same process to call other APIs in the application, and when we shipped the discount code feature on Tuesday, we had no issues. After 15 minutes or so of racking our brains trying to figure out exactly what was going on, we realized the production application was calling the API with www. in front of the url, which wouldn't always be the case. So we threw a conditional in there to cover for this, and it worked fine after that. We sent it up to the CTO and CEO for approval, and I didn't hear anything back, so I guess it got approved. It was right at the end of the day, though, so it may be that I come in tomorrow morning to find I need to make some changes. Still, it was great to get something fully shipped like this.

Until tomorrow!