[metrics-bugs] #21236 [Metrics/Metrics website]: Put a visualization of Tor Browser downloads and updates on the Metrics website

[Tor Bug Tracker & Wiki]

#21236: Put a visualization of Tor Browser downloads and updates on the Metrics
website
-------------------------------------+------------------------------
 Reporter:  karsten                  |          Owner:  karsten
     Type:  enhancement              |         Status:  needs_review
 Priority:  High                     |      Milestone:
Component:  Metrics/Metrics website  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------------

Comment (by iwakeh):

 Introducing the Database class didn't cause any overwhelming changes,
 because Main is essentially functional programming.
 Encapsulating the database methods is a tiny first step here to unclutter
 Main for further refactoring.  And, as you pointed out for testing.
 As metrics-web is a 'living' project I'd prefer these tiny steps that
 can be easily verified to not wreak havoc (until there are more tests :-)

 (What is needed next are data objects.  From the top of my head I'd say
 with these data object it is possible to abstract/encapsulate/reuse
 database persistence, file generation, and also R-access to some extend
 (there is some java integration for R).
 The actual redesign, should of course be done by also considering
 all modules together in-depth.)

 Moving Database.java to shared/src is fine (thanks for pointing that out).
 (A more radical idea: all java code could be put into one source folder
 in the base project already.  This would reduce complexity and prepare
 for adaption to metrics-base.)

 Command line args:
 The suggestion I made was ad-hoc aiming at replacing the `TODO: remove
 after tests.`
 approach with something lasting, b/c what is facilitated  by `remove after
 tests` code
 is useful.  The command line args were intended for testing not at all as
 a user convenience.
 Thus, baking it more there are to options:
 1. change the usage note that these args are only for testing, or
 1. add the code to allow the database url as a single arg, too

 Tests:
 The simple tests for `parseLogLines()` (or only the matchers used?) and
 `writeStatistics()` are sufficient and needed for later refactoring.
 (You're probably right that my code suggestion would miss a newline after
 the header in csv.)

 I think the most pragmatic and efficient way will be to pick code that
 produces vital output for writing the tests that can be re-used or simply
 adapted during refactoring.  More complicated test coverage should be
 tackled after/while refactoring (when need arises).

 As usual, I'd love to write more code here, but currently it competes for
 time with my non-code writing tasks.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21236#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online