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:
- I’m still new
- this was my first time pushing to the deploy repo
- there is scant documentation on the codebase/git workflow
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
- create a new branch:
git checkout -b caryl-feature-name
- run grunt to compile local/dev build:
- commit as you go!
git statusto see changes to be staged
git commit -am "concise message"
- when you need to push, push your branch to the
git push origin caryl-feature-name
- when ready to merge branch to dev, create pull request to dev (need to change the request location dropdown in pull request) to see changes on
- merge pull request
- once merged, delete the branch:
- manually delete from github: click
[number] branches, then click the red trashcan icon next to your now-defunct branch
- look into adding this action: branch cleanup action
git branch -d caryl-feature-name
- manually delete from github: click
ready to go live? pull request checklist
- make sure links and images point to live server (i.e. no
grunt live-buildto build minified files
- push to dev
git push origin master
- create pull request to
- let steven know so he can merge
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:
- Today’s learning was kicked off by a tweet I saw during spring break that lead to this article: The web we broke
- Which led to me signing up for A11yWeekly, a weekly accessibility newsletter
- And also led me to read more about WebAIM’s “WebAIM Million” project, which was depressing to say the least
- This new accessibility tool was showcased somehwere in that tweet thread: Accessibility Insights. It seems like WAVE but has better integration for testing and CI
- Somewhere in that tweet thread, someone posted a link to this Smashing Mag webinar in which we follow a blind screenreader user attempting to navigate many different sites which was the most depressing of all but also the most insightful and where I learned the most. Some tips I picked up from her:
<hidden>element are best for hiding things for everyone
aria-roles aren’t as helpful for screen readers as semantic markup, so use HTML elements over ARIA whenever possible; fall back on ARIA for things that don’t exist in HTML, like tabbed box content/tabs
aria-labelis another exception, as it can help add context to HTML elements. Her example was:
<section aria-label="Summary"> </section>
- “This is announced as ‘Summary region start’ and ‘Summary region end’, and can be skipped over if desired.” Good to know!
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:
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.
Time to do some reading!
We must refactor this codebase. Things Work, But For How Much Longer? : A Story of Massive Technical Debt
- We can’t refactor without tests (pg. 4-7)
- Tests insure that when we change code, we don’t modify behavior
- If you want to modify behavior, that’s a bug fix or feature request, NOT refactoring
- If we want to upgrade to a newer version of Angular, we need tests in place for verifying behavior of codebase as we migrate (pg 24)
- Tests = fewer emergencies, fewer bugs
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
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:
- DOM TDD with JSDOM
- Mocha docs
- Chai docs
- Jest docs on testing jQuery
- An example of code in the wild testing form inputs
- JRSinclair’s Gentle introduction to JS TDD
…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. 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.