list counterparties should list descending the top-N counterparties and their respective cumulative amounts within a timeframe in a table.

For reusability this should be generated from a counterparty to (date, amount) hashmap.

• We are letting the tool panic! in too many places. We should be calling error!.
• And using std::process::exit to exit the process with a sensible error code.

Detect common transactions

Might be interesting to take a list of transactions and create another list of regular transactions.

1. Transactions with the same organisation.
2. Transactions for the same amount.
3. Transactions that repeat on a specific day every month.
4. Transactions that repeat on a specific day and month every year.

There has to be some kind of threshold that is passed before considering a transaction common or even regular to stop things like coffee transactions being seen as regular, etc.

In general I expect 1 but not 3 or 4 would mean you were actively re-engaging a service, while 1+3 or 1+4 would mean you were passive and they were re-engaging with you due to a contract stipulating a level of service.

2 is only interesting because it helps us calculate past burn rates and estimate future burn rates. Also the absence of a stable 2 creates variability and risk.

Knowing this would help us:

• Reduce burn rates.
• Recommend replacements to transactions (bundling or other similar services.)
• Get some understanding of the trade-offs between spending £400 on a pair of gucci loafers once, and spending an extra £100 a month at Waitrose.

Further thoughts:

1. Given a list of transactions from a normalised Counterparty group them by behaviour and tag each group with regular-amount, variable-amount, sporadic-interval, regular-interval. These are patterns. Sum each pattern. Remove transaction groups that are below thresholds of utility. (Although the data would be fascinating, it is probably not worth doing until we have an interesting pictorial/textual representation that will give instant usability.)
2. Open question about which is more appropriate for a group key at a given point and what do we have access to: Counterparty vs normalised Counterparty vs service/product/utility vs category of service/product/utility

Survival spend

Later on we could create some kind of basic survival spend command that would let you know the amount of money that must always be present in your account for basic living - a total, and a list of transactions that represent the average minimum viable monthly basket. Eventually allowing us to automate current account topups towards this number.

Perhaps there could also be some kind of show transaction next --type=regular command that could tell you the next regular transaction that should be coming out.

list transactions should not use a hardcoded currency.

• teller list payment-mechanisms current
• teller send <amount> [<currency>] --from=<from> --to=<to>

Note: <from> and <to> might be able to contain URIs.

Must be well-supported in Teller before being implemented.

Need to comment in the README.md that it should be chmod'd to 0600.

Additionally we should probably encrypt it like is done within heroku/netrc.

parse_utc_date_from_transaction should belong to the json serialization logic and therefore only happen once instead of during maps/filters/reduces, etc. (What's currently happening makes it more difficult to reason and program than it should be.)

In order to support teller list balances business --interval=monthly --only-numbers we need to be able to:

1. Get the current balance.
2. Get the last 12 months of transactions.
3. Get the final balance of each month, including the current month. To do this we need to minus each of the transactions from the current balance cumulatively.
4. Create a Vec of month_final_balances.
5. Write this to stdout.

Note: if Teller adds from and to query strings this would be easier

• teller list direct-debits current
• teller list standing-orders current

Figures coming out from list balances do not match my bank account.

This seems to relate to missing transactions, however it might also be due to a problem with the hastily written logic. Will solve as a matter of #1.

Stop using String so often. Instead use &str

See: http://hermanradtke.com/2015/05/03/string-vs-str-in-rust-functions.html

• By default do not show description. Put it behind a flag.
• currency should appear after a tab following the amount if --only-numbers is not set.

get_balance_for_display could be implemented as various display_* functions on a Money struct - would be nice to not have the .0 visual cruft, too.

• #4 teller list balances current --interval=monthly --timeframe=year
• teller list transactions current
• teller list direct-debits current
• teller list standing-orders current

• teller list payment-mechanisms current
• teller send <amount> [<currency>] --from=<from> --to=<to>

• teller search transactions current --query=<query>

Worth looking at keen-cli for some ideas, although we are not planning on making generalised analysis tools. Some other features we may need to wait for Teller to support.

Note: <from> and <to> might be able to contain URIs.

• teller search transactions current --query=<query>

Must be well-supported in Teller before being implemented.

• Implement show outgoing and show incoming.
• Create script that takes the average of 12 months of outgoing and checks to see whether the current outgoing is higher or lower than this (and the difference between them) before notifying you of this. Place this in the README.md as an example of a script that would give you an idea of whether you are spending more than is normal.

See: http://eng.localytics.com/exploring-cli-best-practices/

Write unit tests. Will potentially need yup-hyper-mock to help test the client, and to write Fs mocks for testing config.

Before I can finish writing the tests I need to refactor a few hinderances to this in the code.

• get_transactions needs to a receive a from_date and to_date which are computed within the commands from an injected current_time.
• In order to alter the server responses when testing each of the commands we will need to be able to inject TellerClients in.
• Do not test main.
• inquirer/ask:
  • can I instantiate a Question?
  • can I instantiate an Answer?
  • ask_question:
    • Check to see if return is an Answer. See test stdout and stdin and this.
    • Consider making the return an Option<Answer>.
  • ask_questions:
    • Given a list of questions, only return an answer if one was typed in when prompted.
• config (see: http://doc.rust-lang.org/std/io/struct.Cursor.html#examples):
  • get_config_path returns the correct path.
  • get_config_file return an Option<File> that is None if not found, and a file otherwise. (NOTE: Closing as not possible to test yet.)
  • get_config_file_to_write return an Result<File, StdIoError> that panics if permission is denied, and the result otherwise. (NOTE: Closing as not possible to test yet.)
  • read_config should return a Result<Config, ConfigError> and write_config a Result<(), ConfigError>.
• cli/parse:
  • instantiate a CliArgs and then get_command_type with it to return a CommandType.
• api:
  • api/client:
    • instantiate a TellerClient, Account and Transaction.
    • get_account returns an Account.
    • get_accounts returns a Vec<Account>.
    • get_transactions returns a Vec<Transaction>. Unable to test the timeframe thing easily, so ignore for now.
  • api/inform:
    • instantiate some Money.
    • get_account_balance should return some valid Money.
    • get_aggregates test that get_balances, get_incomings and get_outgoings return monthly absolute values with a currency from the current Account.
    • get_counterparties should return the grouped counterparties outgoing amounts for a particular timeframe.
    • get_incoming should return the Money of the sum of the positive transactions this month.
    • get_outgoing should return the Money of the absolute sum of the negative transactions this month.
    • get_transactions_with_currency should return a valid TransactionsWithCurrrency.

These tests will no longer be done as (1) testing exit codes is not that useful, and (2) perfect representation is not as important as actual computation (make more sense to see it with eyes, than to test spacing with code, etc.)

• command for each test its represent_ and whether it can return 0 or 1 on network success/failure:
  • initialise.
  • list_accounts.
  • list_balances.
  • list_counterparties.
  • list_incomings.
  • list_outgoings.
  • list_transactions.
  • show_balance.
  • show_incoming.
  • show_outgoing.
  • show_usage.

See: https://github.com/alkis/decimal

• write [--all --long --human-readable] rather than [--all] [--long] [--human-readable].

https://github.com/variadico/noti

• Rename --only-numbers to --hide-currency

As well as #8, we need some vanity changes to list balances:

• We should support timeframes of 3 months and 6 months.
• Reformat to:

              mon-year       mon-year         mon-year           today
balance (GDP) 23.00          56.00            100.00             34.00

• --hide-currency should be renamed here as we're using it for a different purpose. Use --output=spark instead.
• Emit an error message if a different interval from 'monthly' is used. Not supported yet.

Take a read of this well-written rust code.

• Refactor 'client':
  • Create a struct that receives an authToken on instantiation and implements basic methods to fetch data - each of these should use some kind of underlying auth_request method. This is instead of everything receiving &Config (a class that belongs to another module). Move to a separate crate teller_api.
  • The remaining non-HTTP parts of 'client' should perhaps be renamed to 'inform' and receive the data from the API instead of creating it (the information that is applied, does not belong to the client).
• Refactor 'inquirer':
  • Into a module directory.
• Refactor 'main':
  • structs and impl Decodables should remain where they are as are command definition related.
  • pick_command should be simpler:
    • Only destructure args to get out what you need to match. 'Additional destructuring](http://rustbyexample.com/flow_control/match/destructuring/destructure_structures.html) should happen before the underlying command is called.
    • Only get_config once, if it is successful then pass the &config onto the commands, otherwise configure_cli. get_config should not be concerned with execution of configure_cli itself. This will mean you will attempt to detect whether cmd_init was picked first, separately to the rest of the other commands prior to get_config being executed.
    • get_config should belong to the 'config' module.
  • init_config should become ask_questions_for_config. Behind the scenes it should use inquirer::ask_questions and some kind of find_answers* function to get the answers out for the config.
  • Commands should be moved into a module 'command'. This includes configure_cli, list_accounts, show_balance, list_transactions, etc.
  • Table writing and other response writing should live in 'represent'. This includes get_account_alias_for_id, represent_list_accounts, represent_show_balance, represent_list_transactions, represent_list_amounts, represent_list_balances, represent_list_outgoings, represent_list_incomings, etc.
• Carefully remove many of the unwrap statements and clean up many of the deeply-nested matches in the usual ways (separate functions, early returns, let expected_value = match thing { ... }.