week of 18 march

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:

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.

workflow

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: grunt default
commit as you go!
- git status to see changes to be staged
- git commit -am "concise message"
when you need to push, push your branch to the ualibweb/roots-ualib repo with 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 wwwdev2 server
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

ready to go live? pull request checklist

make sure links and images point to live server (i.e. no wwwdev2 links/images)
run grunt live-build to build minified files
push to dev git push origin master
create pull request to ualib-deploy
let steven know so he can merge

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:

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:
- CSS display:none; and HTML <hidden> element are best for hiding things for everyone
- Most 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-label is 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:

assets/vendor/ualib-hours
assets/vendor/ualib-hours/src/app/lib-hours-today
assets/vendor/ualib-hours/src/app/list

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!

notes from reading Refactoring JavaScript

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

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. 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.