QA app after linting the codebase

[kmcculloch]

I finished the initial linting of archivers.space last night, and deployed it, along with three new features, to our QA environment:

https://archivers-staging.herokuapp.com/

Please use the comments on this ticket to report any bugs. Our goal is to hotfix any new problems so that we can deploy on Friday. If you come across anything big we'll escalate it to its own ticket.

The db in the QA clone is a couple of weeks out of date, but if you've been on archivers.space in the past you should be able to use your usual creds. Otherwise, please contact @b5 or @kmcculloch on slack for an invite. (In fact, do that anyway--we should QA the invites, too!)

Feel free to mess up the data: add junk URLs, fill the fields with lorem ipsum, go hog wild. Just be sure you're actually on the QA site! You should see a reminder on every page. :)

[kmcculloch]

Already spotted one! Bag count on dashboard is zero.

[dcwalk]

I am getting "application error" when I try to visit

[suchthis]

Yeah; I have been too. @kmcculloch and I are trying to isolate the issue in Slack DM.

[suchthis]

Sounds like @kmcculloch is going to work on this Application error issue later today. I did find a couple minor things that seemed unrelated to that issue, so I'll add them here in case they're useful to follow up on later:

1. I wasn't able to log out once logged in.
2. I wasn't able to log in on Chrome using saved pass from keychain (but was able to when manually retyping pass).
3. The number of URLs in each phase did not match in dashboard view vs URL view.
4. The dashboard view didn't display correctly at all screen widths (probably not a significant issue, as we expect users to be working on larger devices).

[kmcculloch]

The utterly broken behavior @dcwalk and @suchthis encountered was due to a server process talking to Google spreadsheets that was hanging in the QA environment because of a creds issue. I've sidestepped the issue by disabling that process outside of production. Obviously we want to QA our integrations as well as the app code itself, but that usually requires mocking external services and so forth, which is beyond the scope of what we're up to this week.

The missing bag count was due to a misnamed variable. The slightly-off counts were due to a half-implemented-then-abandoned feature to allow URLs to be merged: a "merged" attribute was added to the URL data model, and sometimes it was accounted for in counting URLs and sometimes it wasn't. This problem illustrates my biggest reservation about the code so far, which is that data processing knowledge is scattered among individual components rather than running through an authoritative controller whose job is to answer questions like "how many URLs of type x are there"? If we're going to continue adding features we'll need to refactor to address this problem.

In the meantime, I altered the dashboard and the urls list page to use the same query generator and told it to ignore the "merged" attribute. I added the "describe" step and also added some low-rent automated testing that confirms that the totals add up like they should and prints the result to the console if we're not in production.

Kyala is right about the responsive behavior of the dashboard. Again, if this code evolves into a serious long-term app, we'll want to enhance the UI design by targeting screen widths with breakpoints. We'll also want to consider 508 compliance: besides being ugly, I'm pretty sure that the color contrast between the "Describe" count and the blue dashboard background is not high enough for people with visual impairments.

[dcwalk]

Thanks for this great post-mortem!

[dcwalk]

How do we want to handle issues like this. Is this something that can be closed @kmcculloch ?

[kmcculloch]

Yes, I'll go ahead and close this out.