-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update README #2793
Update README #2793
Conversation
README.md
Outdated
@@ -66,6 +66,31 @@ Assisted digital satisfaction surveys: | |||
* https://www.gov.uk/bank-holidays | |||
* https://www.gov.uk/when-do-the-clocks-change | |||
|
|||
### Misc | |||
|
|||
* http://www.gov.uk/school-term-holiday-dates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we know it, is it worth mentioning which view the pages use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added ✅
Partially explored how to add outputs to a Dev environment so comments easily identify which view is in use:
<!-- <%= File.basename(__FILE__) %> -->
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this valuable? If you run it locally/dev env you can watch what templates are called in the terminal already. The problem lies in the opposite direction when you need to know what urls a template generates and this doesn't support that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is still value in this as you don't need to spin up the application to see what views a URL uses. I agree there's still work to be done to find out what URLs use which view - Owen's investigation into using Kibana looks to be promising for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this valuable?
So the use case I found this useful was opening 30+ URLs at once to review and wanting to easily see what page I was looking at. Is it easier to discover this in terminal in this use case?
know what urls a template generates and this doesn't support that.
This was just an quick experiment - it would be nice to have this.
(Wondering how that might work now)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I read "on a dev environment" as meaning you need to be running it anyway. This might make sense to scope to just dev/integration and implement - avoid giving millions of users useless bytes to collect. It's a nice idea.
Update to include some more obscure (but higher traffic) routes found on Kibana along with the related view files. Removed two URLs that were being rendered by government-frontend
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super! Thanks for adding this 👍
@injms do the merge honours? |
What?
Adding an additional list of URLs rendered by
frontend
Why?
As part of this PR. In order to action more in depth testing to increase confidence that updates work as expected across the repo paths (based on traffic) were taken from Kibana - adding to the repo for future reference.
Visuals
The markdown table is hard to visualise so rendered output below:
Anything else?
Some of the links might suffer from link rot and need to be removed / updated as time goes on.