In my time over at Browserstack, I had to go through a lot of dashboards while debugging. All these look-ups followed a simple pattern.
- Open Dashboard
- Type the ID into the search field
- Submit the form and wait for the data to be fetched
- Wait an eternity for the page to reload
- Jump to the next dashboard because this one looks normal
Over the course of a debugging session, we required data from at least 3 dashboards, sometimes going up to 6. I am talking about simple status pages, which have tabulated data and not logs.
As you can imagine, this is a tedious process and quite repetitive. With no exceptions, all the dashboards used GET requests with the User ID as Query Parameters
With this knowledge, the process became like so
- Type part of the Dashboard Page URL in the search bar
- Select from the history a similar query
- Change the query param to the User ID manually
This saved about 5 seconds on every such lookup.
More than the time saved, it was the annoyance of doing such small repetitive tasks that urged me to find this solution.
The Next Level
This tedium lasted for months. One day, I noticed this icon bar on the Firefox search pop-up.
That looked interesting. If you look at how search engines typically work, it's very similar to how my dashboard functioned, using GET requests with query parameters.
https://www.google.com/search?q=blade+runner+2049This made me think, I can make an extension that will add all the dashboard URLs as distinct search extensions, with easy-to-type names.
Before I started though, I searched the Firefox Browser Add-ons Store. Never a good idea to re-implement existing products.
That's where I found this gem.
https://addons.mozilla.org/en-US/firefox/addon/add-custom-search-engine/
The add-on does exactly what I want, custom searches with a search query that can be inserted *anywhere* in the URL, not just at the end.
So now, to visit JIRA Issue No. 1123, this is the sequence of keystrokes I use
Cmd-Lto go to address barjira<Space>to select the JIRA search add-on1123<Enter>
That's it. Steps 1 and 2 are committed to muscle memory and I can do that in a sec or so. All in all, the whole process is smooth and the only part where I need to engage my conscious mind is when I type the issue id.
This whole thing is now optimized as much as possible given the initial premise.
Though, this does beg the question, why do I need to look up various locations. Given that the information is indexed with a single, common key, it should stand to reason that all the information should be collated to a single view.
In response to that, well, Browserstack has bigger fish to fry. ☺
Sometime after that, I did set out to make a Golang CLI binary that pulls all this info off the dashboards given the User Id. This completely eliminated all the HTML rendering going on and was magnitudes faster. That, however, is a story for another time.