-
Notifications
You must be signed in to change notification settings - Fork 25
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
Improves Admin Analytics, Adds Choropleth #692
Conversation
…Webpage into 342-admin-improve-analytics-graphs
…analytics-graphs Conflicts: public/javascripts/Admin/src/Admin.js
Meta point: Another rule of thumb for PRs that I am realizing now is that we should aim to keep PRs as small as possible. Just address a single bug or small number of related bugs. Currently, this PR is really huge to review with a lot of changes. Would take quite some time to review the code. |
I'll create a doc on creating PRs after relaunch and add it to the wiki of this repo. |
At this point, I think you can do a light code review of admin-centric stuff. We can then do a more heavyweight review after relaunch (which I do think is important because we want to make sure not just that the admin interface contains the analytics that we need and is coded well but that the underlying calculations are correct). |
I agree with @jonfroehlich to keep the code review light. Especially since there are still changes to be made, the code needs to be cleaned up a little bit as well, and there is some time-sensitivity to getting the backend stuff integrated for testing purposes. I also agree that PRs should be as small as possible. The problem here is that it is meant to address an issue, but the issue is huge; the issue has over 20 charts to be added/modified that are mentioned, so should I be making a dozen PRs that all partially address that one issue..? I don't think that the issue should be split up, as that would be hard to manage, but does it make sense to split up the PRs? |
Feedback:
|
Also, didn't comment on the cosmetic changes that are needed (e.g. spacing between graphs, graphs sticking to the window border). I assume those will taken care of in the next round of updates. |
I think we should likely use SI metrics on backend and can change to
imperial system for front facing UI (as we currently do).
But it's obviously not worth changing backend stuff if it's all in
imperial... in general, however, as scientists we should be using
scientific metrics (SI!).
…On Tue, Jun 20, 2017 at 12:05 PM, Manaswi Saha ***@***.***> wrote:
Also, didn't comment on the cosmetic changes that are needed (e.g. spacing
between graphs, graphs sticking to the window border). I assume those will
taken care of in the next round of updates.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#692 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABi-9Zzc_aKb5HOi5MrRb9B5uVhpdWG7ks5sF-3hgaJpZM4N9vGp>
.
--
Jon Froehlich
Assistant Professor
Computer Science
University of Maryland, College Park
http://www.cs.umd.edu/~jonf/
@jonfroehlich <https://twitter.com/jonfroehlich> - Twitter
|
@misaugstad Actually, I was wrong. This doesn't work as expected. I did some more testing. The code within
|
Not sure what you mean, is this not the PR?
The ones before that have the deleted flag set to true.
I am pretty sure they are in meters. Whatever those "geom.transform(26918).length" calls give.
I will find and eliminate. |
When you guys find code like this that is poorly documented and/or non-sensible:
I would strongly prefer that you fix the documentation and/or improve code clarity. We need to know what metrics we are using (see http://articles.latimes.com/1999/oct/01/news/mn-17288). |
This should be fixed now. |
I scrolled up and clicked on Files changed but I am not seeing any comments |
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.
Reviewed
val CRSEpsg26918 = CRS.decode("epsg:26918") | ||
val transform = CRS.findMathTransform(CRSEpsg4326, CRSEpsg26918) | ||
|
||
RegionCompletionTable.initializeRegionCompletionTable() |
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 the table initialized each time the function is called?
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.
Oh I see if (regionCompletions.length.run == 0)
line in RegionCompletionTable. Could you confirm if this prevents it from running from than once?
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.
Yes I had confirmed that this didn't run multiple times using the magic of print statements. You also know that it isn't because the call takes >10 seconds to run, but there are never any 10 second lags when calling the getNeighborhoodCompletionRate after the first call.
@@ -112,7 +112,7 @@ object AuditTaskTable { | |||
def auditCounts: List[AuditCountPerDay] = db.withSession { implicit session => | |||
val selectAuditCountQuery = Q.queryNA[(String, Int)]( | |||
"""SELECT calendar_date::date, COUNT(audit_task_id) FROM (SELECT current_date - (n || ' day')::INTERVAL AS calendar_date | |||
|FROM generate_series(0, 30) n) AS calendar | |||
|FROM generate_series(0, current_date - '11/17/2015') n) AS calendar |
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.
11/17/2015 - What does this date refer to?
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.
Good question! I am also wondering that. It appears to be maybe the day after the audit_task_table was first created or something, because up until 11/16/2015 there are no audits at all then on 11/16/2015 there is an absurdly large number of audits, then the data starts looking normal after that.
In summary: 2 days before that date, there are no audits. The day before that date, the data is not reliable. So this is the date where reliable data begins.
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.
Got it. Could you add a comment in the code for this?
app/models/label/LabelTable.scala
Outdated
@@ -467,7 +467,7 @@ object LabelTable { | |||
def selectLabelCountsPerDay: List[LabelCountPerDay] = db.withSession { implicit session => | |||
val selectAuditCountQuery = Q.queryNA[(String, Int)]( | |||
"""SELECT calendar_date::date, COUNT(label_id) FROM (SELECT current_date - (n || ' day')::INTERVAL AS calendar_date | |||
|FROM generate_series(0, 30) n) AS calendar | |||
|FROM generate_series(0, current_date - '11/17/2015') n) AS calendar |
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.
Same comment as above about the hard coded date
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.
Same response :)
…-time-graph Fix onboarding time graph
On admin overview page
On admin analytics page:
Other:
Resolves #691
Resolves #622
Resolves #676
Resolves #697
Partially Resolves #342