introduce worker class to handle work asynchronously

Python's signal handling infrastructure is really a pain. To the best of
my knowledge it is impossible (without directly interfacing with
operating system APIs not directly accessible from within Python) to get
correct signal handling when blocking system calls are in use. Although
Python provides the set_wakeup_fd() functionality which can be used to
unblock a thread waiting in a poll or select call, doing so in
conjunction with higher level APIs is impossible (because one cannot
hook into the lower level system calls used).
To that end, the main thread must not execute any blocking system calls
if a program is to react to signals in a timely manner. This change
introduces a Worker class that pushes the waiting for and processing of
events previously done in the main thread into another thread. Using
this mechanism we can now finally get correct signal handling while
still only waking up when necessary.
push all actual work functionality into the worker

Now that the worker is in place, we can also push more of the event
processing into this object away from the streaming threads. This way,
the worker is the central point of processing and forms the starting
point for all event based logic.
merge duplicate functionality from rateStreamer and eventStreamer

By now more work got moved into the worker and it turns out that
rateStreamer and eventStreamer share the same implementation of the
on_success() and on_error() functionality.
This change moves these methods into the ThreadedStreamer class.
modify the format of the logging output

This change modifies the format of log output as logged using the
logging module. Previously (using the default format), no timestamp was
contained in the output and the component/logger to which the request
was issued was printed before the message.
With this change we use a format of the form:
  "<date> <time> <log lvl> <msg>"
where date and time are in a user readable format and log level is one
of [DD], [II], [WW], [EE], [XX], representing the default log levels.
adjust --list-currencies option to also print generic currency name

With this change the output produced when the --list-currencies options
is specified now also includes the undecorated instrument name as
accepted by the OANDA APIs. The expectation is that these names will be
used throughout the program rather than the actually displayed names.
introduce --currencies parameter

This change introduces a --currencies parameter that accepts a list of
currencies. In this first change, this list of currencies can be used to
influence the output as produced by the --list-currencies option: only
currencies supplied will be listed in this case.
Later on, the list of currencies will influence other functionality as
well.
swap return tuple values of return of currentPrices

In most other applications the ask price is displayed before the bid
price. In addition, 'ask' is lexicographically smaller than 'bid' in
most locales ;)
Such being the case, this change adjusts the currentPrices() method to
return a tuple (ask, bid) rather than the other way around.
introduce Strategy interface

This change introduces a new abstraction: a strategy. A strategy is
invoked periodically by some executing entity and can decide whether to
file a new trade, close an existing one, or simply do nothing right now
and log the request.
The Strategy interface defines the basic set of methods all strategies
have to provide.
introduce a watchdog class

During testing it could repeatedly be witnessed that sometimes the
stream tracking the current prices of currencies just delivers nothing.
This case cannot easily detected since no error is reported (my
suspicion is that for some reason the server does not want to serve our
stream).
This change introduces a watchdog thread that periodically wakes up,
checks if no price updates have been received and in that case
explicitly queries the prices and creates a new tick. Note that the
checking whether or not price updates have been received is still to be
done. For now, sending a tick happens unconditionally.
Using such a watchdog also paves the way to providing an option to not
using the streams at all, which might be preferable under certain
circumstances.
reorder initialization/destruction of objects in Program class

The initialization/destruction sequence of objects in the Program class
does not have the correct order. Fix this.
add module for handling times as per RFC3339

With this change a new module is introduced: datetimeRfc3339 can be used
to parse dates encoded as specified in RFC3339. Note that currently only
the relevant subset for our purposes is supported: only times encoded
for UTC timezone (ending with a 'Z').
This change also introduces a unit test to verify the parsing is correct
based on some strings actually received and some made up ones.
make currentPrices() return a dict object

Using tuples for returning multiple values comes in handy for multiple
intermediate results calculated by a single function. The
currentPrices() method was one such function but eventually we want
prices to be first class citizens in our program.
This change marks a first step into this direction by making the
returned price a dict object.
rethink price handling

With this change prices -- at the moment represented by a dict -- are
always transfered in a strongly typed fashion, i.e., the keys
'instrument', 'time', 'ask', and 'bid' are of types string, datetime
object, and Decimal, respectively.
The parsing functionality for the rateStreamer was directly added into
it and so such a stronger typed object can directly be passed to the
worker.
employ a caching scheme for a currency's historic data

With this change the history() method of Currency objects does not
necessarily query the OANDA server on every invocation. Instead, we
store the last data we retrieved and decide whether it is still current
based on the granularity of the request, the current time, as well as
the last time data was actually retrieved from the server.
The overall goal towards which this change is a first step is to reduce
the overall amount of connections to the OANDA servers as much as
possible since there exists a limit of 4 (peak 5) connections per
second. If this limit is exceeded clients might be subject to throttling
or other means degrading the quality of service.
move API object creation into fxBot.py

In this change the creation of the API object representing the
interaction point with OANDA's server is moved from the Program class
into the fxBot.py file containing the main() function.
This refactoring marks a first step towards a possible virtualization of
the API interface so that we can better test our code by supplying a
mock API object.
introduce Server abstraction

This change introduces a new abstraction to the program: a Server object
is used for interacting with the OANDA servers. That is, it abstracts
away from the direct usage of the API class provided by the oandapy
module.
The two streamer classes rateStreamer and eventStreamer are unaffected
by this currently but they are already a form of abstraction over direct
usage of the corresponding oandapy Streamer class.
add unit test for Currency class

Having introduced the abstraction of a Server class, we are now able to
create custom Server objects. One opportunity opened by this feature is
creation of mock objects to fake expected behavior or virtualize
interfaces.
This change introduces a unit test for the Currency class and its
caching functionality. A MockServer object is used to simulate the
Server interface to Currency objects while not actually performing any
network traffic but just working on local data.
update README file to reflect new mock dependency

A recent change added a unit test for the Currency class. Currency
employs a cache that is time dependent. To make the tests works
reliable, the datetime.now() method was mocked.
To accomplish this mocking the mock module was used which is now a new
dependency. This change updates the README.md file to reflect this
requirement.
simplify column printing

Column creation is still cumbersome to create a decent tabular data
layout -- even with the __queryWidths methods. This change simplifies
things a little bit leading to less lines of code being required to
create such a tabular view.
add support for listing trades

This change adds a new option to the program: --list-trades. When this
option is specified the currently open trades will be listed.