[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21236 [Metrics/Metrics website]: Put a visualization of Tor Browser downloads and updates on the Metrics website
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs