Status Update CW13 2021

Just imagine this intro grabs your attention.. HOOOGA BOOGA!

done

• Add optional search filters to the the form.
  • Filter on a repo being created before or after a certain date.
  • Filter when a repo was last updated.
  • Filter out forks and/or archived repos.
  • Filter based on where a repo is hosted (github, bitbucket, etc.).
• Add a license (AGPL).
• Handle some edgecases (error handling, search feedback for empty results).
• More continuous frontend fiddling with the layout.
• User management for accounts creation to let people sign up and add their own instances (a gitea instance, for example) to be included in the search results.
• Add some convenience when adding instances this way, like where to find the default api-url for different services so you dont have to look it up.

doing

Our goal is to deploy a public version of HubGrep in the coming 2 weeks. It works and the filters make it more interesting.

Before we do though, we want to tidy up some frills around the edges which makes the thing look and feel like a real … thing. Stuff like layout and whatever smaller stuff comes up as we go, but also some more testing - you never know right! Once we have it deployed in a state we feel is okay, thats it for the first milestone and we move on to the 2nd one - documentation.

Obviously, that means writing a little bit of docs and then outdating it the week after because you had an itch to change something. Our remedy for this is to put our documentation up on readthedocs, and we want to update the docs via Travis CI so that we keep it current as we go. Additionally we hope to automate as much detail as possible by generating api level docs from extracting docstrings from our code.

motivations and challenges

We had some back and forth with how to handle our main search form. So, we are using a form with method=GET since that lets you search via url (and integrate it with search engines). This means the whole form is visible in the url field. Once we started adding our filters this became a rather long and bloated url however, and we had an itch to make it nicer.

As default, filters-wise, we want to search with everything “on” if its not included in the url, so that it works nicely when you integrate it with a search-engine by accepting only the search-phrase and then working as expected. Unfortunately this is not how it works with a GET form. When a checkbox (which we use) is off, it’s not included in the url, and when all checkboxes are “off” it would mean searching for results from zero sources - yielding nothing.

In the end we inverted the labels on the form fields to be phrased in way like this: “say yes if you want to exclude this”. It’s not the solution we want, because we want the user-interface to be as intuitive as possible, and checkboxes that are checked shouldn’t mean “no thanks”. So now we have a ticket for the future to rework the checkboxes into select elements instead, which are never excluded from the url. We just have to style them to look like checkboxes instead ;).