week of 18 march

18 Mar 2019

18 mar

Things got hectic at the end of Friday before spring break. Because I was hustlin’ so hard, I didn’t have time to update the log. Let’s see if I can recap and update with today’s fixes.

I think this whole thing can be boiled down to:

All of that added up to a bit of a storm when a request was made to push to production on the Friday before spring break. Thankfully, this was a pretty minor update, so it wasn’t a huge deal that it didn’t end up happening last week. Still, what I pushed to production broke the homepage, and even after fixing it last week and updating it today, I’m not sure why that happened. Here comes the post mortem.

We received a “feature request” for a new box on the homepage. The requester originally wanted a sort of CRUD application style plugin where anyone who is logged in to wordpress can update the box (basically a mini-blog). When it came down to it though, it just needed to be a box with an image in it that pointed to a blog. HOWEVER, because of the nature of the original request, I started working on that stuff I wrote about last Friday with the JSON data, GET auth/permissions, etc. I also started digging into how to build an Angular module (complete with directive/controller), which I was building outside the local build in order to get my head around the concepts before breaking anything.

When it got to be around 3PM, it was clear that the box with linked image was going to have to be the solution for now. Because of all the previous digging I had done, some of the changes I’d unknowingly made to my local codebase were also pushed to the live site. These changes broke the homepage. [Sidenote: I’m baffled by this because I never ran the live-build compile step. If my changes weren’t added to the .min files (couldn’t have been, because those .min files are only compiled during when grunt live-build is run, which I didn’t even know existed until this morning), then they couldn’t have been live, even if they were pushed to the deploy repo. The only explanation that makes sense to me is something from my files must’ve messed with a GitHub hook we have set up. And I don’t know anything about those yet, so it’s just speculation at this point.]

We had a lot of fun scrambling to revert commits and reset the HEAD and undo merges at 4:45PM. I definitely learned a lot about undoing stuff. I hope I don’t need it again, but I probably will.


ALL THAT TO SAY: When Jared was here this morning, I had him walk me through his workflow for pushing to the deploy repo, and I learned all about the grunt live-build command that builds the .min files. I’ve now written out a complete workflow that includes creating a branch locally so future reverts/resets won’t be so complicated. Here is that workflow in all its glory:

building locally, pushing to dev
ready to go live? pull request checklist

accessibility reading/viewing

Spent the afternoon learning about accessibility. The deeper I dig into this, the more depressed I am at how hard the web is to use for people with disabilities. I learend a lot today from these links:

<section aria-label="Summary">

Then I attempted to use the macOS screen reader, VoiceOver. I really only got as far as a few bits of the tutorial… it was so bad. I will need to play around with that so I can test our website and libguides, because it’s definitely an important part of accessibility!

Spent the rest of the day using the WAVE tool on our website and digging in to the issues I found. First, our “today’s hours” app/widget/box is considered a layout table because it doesn’t have any headers. Trying to find the template for this box led me down a deep rabbit hole of how our apps interact with the rest of the site. It’s very interesting! The important bits were here:

19 mar

I’ve been assigned a new project! It’s actually a legacy project that has passed hands many times, so it’s not new, but it is new to me. I’ll be working on a form that IT uses to authorize accounts for new employees. There’s some logic that automagically fills in check boxes when a department is selected from an earlier form field. Some new checkboxes are needed and some of the auto-fill needs updated.

It shouldn’t take me too long to update the form, but I’m intrigued with the javascript that has been cobbled together over the years. I’m very tempted to write unit tests for this script to get back up to speed with mocha/chai. Since this doesn’t exist in the wordpress/angular environment, I won’t risk breaking anything by adding tests. This will give me the chance to refamiliarize myself with the tooling and best practices of unit testing before adding them to a larger codebase with a structure I don’t understand.

Time to do some reading! :clap::clap::grin:

notes from reading Refactoring JavaScript

We must refactor this codebase. Things Work, But For How Much Longer? : A Story of Massive Technical Debt

23 mar

It’s been a weird few days. I’ve spent the last few brushing up on testing with Mocha/Chai and trying to remember how all this stuff works. I then tried to implement testing on that security form, but I forgot how pointless testing changes to the DOM is. If the code was more functional, I think I could make it work, but it’s mostly eventEmitter and onClick type changes, which are hard to test. Even with the npm module jsdom, testing more than a hundred checkboxes would be tedious.

So it’s time to try testing on something else. Since I spent a good amount of time earlier this week looking over the hours app, I might start there. After looking through those files, I realized I still really don’t understand how all of angular’s pieces fit together, so I might also go back and try to build a small angular app on my own to get all those pieces straight in my head before jumping into testing. Guess we’ll see how it goes!

Helpful articles I dug up on testing:

…so. I got as far as checking out a new branch of the site and spinning up bitnami to test local development on a new branch, when I noticed the “today’s hours” box wasn’t loading the API data. I’ve now fallen down the API rabbit hole. Honestly, this is a good thing because I’d have to dig into it eventually. I’m grateful that there’s more documentation in this code than in most of the others I’ve encountered. There’s even a link to the article that our REST API is based on! Creating a RESTful API with PHP. Am I upset that our API is PHP? Umm… yes. :sob: Yet another thing to add to my list of shit to figure out. Every time I open a new file, it adds to the puzzle. Good thing I like puzzles!

Some of this API business is making sense, thanks for the most part to that blog post. I can now see where most of the files intersect, which is helpful. Now if I could only figure out why the browser console is telling me there’s a CORS header/500 internal server error issue when the API code clearly has CORS headers specified?? Haley added about 10 lines of code for the elevator monitor project, but it doesn’t look like it should’ve broken anything, so I’m very confused about what happened there.