implement analyzer.go:Analyzer:ByCategory
parent
a82abc29d0
commit
b0c461335e
|
|
@ -54,8 +54,13 @@ func (anz *Analyzer) LargestTransaction() (Transaction, error) {
|
|||
// ByCategory groups the transactions by category and returns a map of
|
||||
// category name to the list of transactions that are part of that category.
|
||||
func (anz *Analyzer) ByCategory() map[string]Transactions {
|
||||
// TODO: Not implemented.
|
||||
return nil
|
||||
result := map[string]Transactions{}
|
||||
for i := range anz.transactions {
|
||||
transactionsInCategory := result[anz.transactions[i].Category]
|
||||
transactionsInCategory = append(transactionsInCategory, anz.transactions[i])
|
||||
result[anz.transactions[i].Category] = transactionsInCategory
|
||||
}
|
||||
return result
|
||||
}
|
||||
|
||||
// BigSpenderReport generates our Big Spender Report.
|
||||
|
|
|
|||
75
todo.yaml
75
todo.yaml
|
|
@ -2,7 +2,6 @@ todo:
|
|||
- review readme tail to finish // answer 3 questions, gofmt
|
||||
- todo: go test
|
||||
subtasks:
|
||||
- TestAnalyzer_GroupByCategory
|
||||
- TestAnalyzer_BigSpendersReport
|
||||
- TestAnalyzer_TransactionsFromURLs
|
||||
- TestAnalyzer_TransactionsFromURLsConcurrent
|
||||
|
|
@ -33,6 +32,9 @@ todo:
|
|||
can be pending and then later disappear to have their date updated OR be like
|
||||
pre-charges on credit cards that later disappear
|
||||
- analyzer.go:Analyzer:Add is not concurrency-safe
|
||||
- analyzer.go:Analyzer:ByCategory probably allocates big slices out the gate and
|
||||
expends to way-too-big-slices by end time. Could do 2 passes (still O(n)) to pre-compute
|
||||
each category's size. Makes code look weird, though. Hm.
|
||||
scheduled: []
|
||||
done:
|
||||
- todo: hello world
|
||||
|
|
@ -602,3 +604,74 @@ done:
|
|||
pre-charges on credit cards that later disappear
|
||||
- analyzer.go:Analyzer:Add is not concurrency-safe
|
||||
ts: Sun Oct 15 11:49:59 MDT 2023
|
||||
- todo: go test
|
||||
subtasks:
|
||||
- TestAnalyzer_GroupByCategory
|
||||
- TestAnalyzer_BigSpendersReport
|
||||
- TestAnalyzer_TransactionsFromURLs
|
||||
- TestAnalyzer_TransactionsFromURLsConcurrent
|
||||
- amount.go:Rounded probably does NOT handle float precision well... it is float64
|
||||
tho...
|
||||
- my `go mod tidy` actually cleared `go.mod` file, probably weird localhost backwards
|
||||
compatilble stuff
|
||||
- transaction.go:Transaction:String not clear if FormatUSD or amount currency should
|
||||
not be changed, or even what currency Amount is
|
||||
- transaction.go:Transaction:Sum again doesnt care about Amount currency or vendor/vendee
|
||||
drift
|
||||
- analyzer.go:Analyzer:LargestTransaction doesn't specify how to break ties; stable
|
||||
or latest?
|
||||
- analyzer.go:Analyzer:Add should dedupe transactions added, but transactions.go:FromFile
|
||||
will load duplicate transactions from json file so hmmmm
|
||||
- todo: analyzer.go:Analzyer:Add dedupes each transaction, which is O(n**2)
|
||||
details: |
|
||||
* BUT there's no indicator whether order of the array matters, so it's unsafe for me to sort/heapify that stuff
|
||||
* OR I can store a second copy of all entries in a map, but that risks drift syncing the two
|
||||
* SO I could create a UniqueTransactions struct {
|
||||
transactions []Transaction
|
||||
dedupes map[Transaction]struct{}
|
||||
}
|
||||
but that's just doubling RAM usage in a thing that sounds like it could scale infinitely over time
|
||||
SO I could do a [hash(Transaction)][]*Transaction and compare just a subset. Because it's in RAM and computed live, the hash cardinality could be changed on any release
|
||||
<------------------ if I have time, do this
|
||||
- analyzer.go:Analyzer:Add dedupes but what is a duplicate transaction? Transactions
|
||||
can be pending and then later disappear to have their date updated OR be like
|
||||
pre-charges on credit cards that later disappear
|
||||
- analyzer.go:Analyzer:Add is not concurrency-safe
|
||||
ts: Sun Oct 15 11:52:22 MDT 2023
|
||||
- todo: go test
|
||||
subtasks:
|
||||
- TestAnalyzer_GroupByCategory
|
||||
- TestAnalyzer_BigSpendersReport
|
||||
- TestAnalyzer_TransactionsFromURLs
|
||||
- TestAnalyzer_TransactionsFromURLsConcurrent
|
||||
- amount.go:Rounded probably does NOT handle float precision well... it is float64
|
||||
tho...
|
||||
- my `go mod tidy` actually cleared `go.mod` file, probably weird localhost backwards
|
||||
compatilble stuff
|
||||
- transaction.go:Transaction:String not clear if FormatUSD or amount currency should
|
||||
not be changed, or even what currency Amount is
|
||||
- transaction.go:Transaction:Sum again doesnt care about Amount currency or vendor/vendee
|
||||
drift
|
||||
- analyzer.go:Analyzer:LargestTransaction doesn't specify how to break ties; stable
|
||||
or latest?
|
||||
- analyzer.go:Analyzer:Add should dedupe transactions added, but transactions.go:FromFile
|
||||
will load duplicate transactions from json file so hmmmm
|
||||
- todo: analyzer.go:Analzyer:Add dedupes each transaction, which is O(n**2)
|
||||
details: |
|
||||
* BUT there's no indicator whether order of the array matters, so it's unsafe for me to sort/heapify that stuff
|
||||
* OR I can store a second copy of all entries in a map, but that risks drift syncing the two
|
||||
* SO I could create a UniqueTransactions struct {
|
||||
transactions []Transaction
|
||||
dedupes map[Transaction]struct{}
|
||||
}
|
||||
but that's just doubling RAM usage in a thing that sounds like it could scale infinitely over time
|
||||
SO I could do a [hash(Transaction)][]*Transaction and compare just a subset. Because it's in RAM and computed live, the hash cardinality could be changed on any release
|
||||
<------------------ if I have time, do this
|
||||
- analyzer.go:Analyzer:Add dedupes but what is a duplicate transaction? Transactions
|
||||
can be pending and then later disappear to have their date updated OR be like
|
||||
pre-charges on credit cards that later disappear
|
||||
- analyzer.go:Analyzer:Add is not concurrency-safe
|
||||
- analyzer.go:Analyzer:ByCategory probably allocates big slices out the gate and
|
||||
expends to way-too-big-slices by end time. Could do 2 passes (still O(n)) to pre-compute
|
||||
each category's size. Makes code look weird, though. Hm.
|
||||
ts: Sun Oct 15 11:52:25 MDT 2023
|
||||
|
|
|
|||
Loading…
Reference in New Issue