travelynx/README.md

158 lines
5.5 KiB
Markdown
Raw Normal View History

2019-02-16 16:28:01 +00:00
travelynx - Railway Travel Logger
---
[travelynx](https://finalrewind.org/projects/travelynx/) allows checking into
and out of individual trains, thus providing a log of your railway journeys
annotated with real-time delays and service messages. At the moment, it only
supports german railways and trains which are exposed by the Deutsche Bahn
[IRIS Interface](https://finalrewind.org/projects/Travel-Status-DE-IRIS/).
Dependencies
---
* perl >= 5.10
* Cache::File (part of the Cache module)
2019-04-06 19:09:23 +00:00
* Crypt::Eksblowfish
* DateTime
* DateTime::Format::Strptime
2019-04-06 19:09:23 +00:00
* Email::Sender
2019-02-16 16:28:01 +00:00
* Geo::Distance
* Mojolicious
2019-03-31 12:09:14 +00:00
* Mojolicious::Plugin::Authentication
2019-04-17 11:10:49 +00:00
* Mojo::Pg
2019-02-16 16:28:01 +00:00
* Travel::Status::DE::IRIS
2019-04-06 19:09:23 +00:00
* UUID::Tiny
* JSON
Recommended
---
* Geo::Distance::XS (speeds up statistics)
* JSON::XS (speeds up API and statistics)
Dependencies On Docker
---
* cpanminus
* build-essential
* libpq-dev
* git
* ssmtp
2019-02-16 16:28:01 +00:00
Setup
---
2019-04-06 19:09:23 +00:00
First, you need to set up a PostgreSQL database so that travelynx can store
user accounts and journeys. It must be at least version 9.4 and should use a
UTF-8 locale. The following steps describe setup on a Debian 9 system, though
setup on other distribution should be similar.
2019-04-06 19:09:23 +00:00
* Write down a strong random password
* Create a postgres user for travelynx: `sudo -u postgres createuser -P travelynx`
(enter password when prompted)
* Create the database: `sudo -u postgres createdb -O travelynx travelynx`
* Copy `examples/travelynx.conf` to the application root directory
(the one in which `index.pl` resides) and configure it
* Initialize the database: `perl index.pl database migrate`
2019-04-06 19:09:23 +00:00
Your server also needs to be able to send mail. Set up your MTA of choice and
make sure that the sendmail binary can be used for outgoing mails. Mail
reception on the server is not required.
Finally, configure the web service:
* Set up a travelynx service using the service supervisor of your choice
(see `examples/travelynx.service` for a systemd unit file)
* Configure your web server to reverse-provy requests to the travelynx
instance. See `examples/nginx-site` for an nginx config.
You can now start the travelynx service, navigate to the website and register
your first account.
Please open an issue on <https://github.com/derf/travelynx/issues> or send a
mail to derf+travelynx@finalrewind.org if there is anything missing or
ambiguous in this setup manual.
2019-02-16 16:28:01 +00:00
2019-04-07 12:18:56 +00:00
Updating
---
It is recommended to run travelynx directly from the git repository. When
updating, the workflow depends on whether schema updates need to applied
or not.
```
git pull
chmod -R a+rX . # only needed if travelynx is running under a different user
if perl index.pl database has-current-schema; then
2019-04-07 12:18:56 +00:00
systemctl reload travelynx
else
systemctl stop travelynx
2019-04-07 16:19:25 +00:00
perl index.pl database migrate
2019-04-07 12:18:56 +00:00
systemctl start travelynx
fi
```
Note that this is subject to change -- the application may perform schema
updates automatically in the future.
2019-02-16 16:28:01 +00:00
Usage
---
For the sake of this manual, we will assume your travelynx instance is running
on `travelynx.de`
travelynx journey logging is based on checkin and checkout actions: You check
into a train when boarding it, and check out again when leaving it. Real-time
data is saved on both occasions, providing an accurate overview of both
scheduled and actual journey times.
## Checking in
You can check into a train up to 10 minutes before its scheduled departure and
2019-03-31 12:09:14 +00:00
up to 3 hours after its actual departure (including delays). I recommend
2019-02-16 16:28:01 +00:00
doing so when it arrives at the station or shortly after boarding.
First, you need to select the station you want to check in from.
2019-03-31 12:09:14 +00:00
Navigate to `travelynx.de` or click/tap on the travelynx text in the navigation
2019-02-16 16:28:01 +00:00
bar. You will see a list of the five stations closest to your current location
2019-03-31 12:09:14 +00:00
(as reported by your browser). Select the station you're at or enter its
name or DS100 code manually.
2019-02-16 16:28:01 +00:00
Now, as soon as you select a train, you will be checked in and travelynx
will switch to the journey / checkout view.
## Checking out
You can check out of a train up to 10 minutes before its scheduled arrival and
up to 3 hours after its actual arrival. This ensures that accurate real-time
data for your arrival is available. I recommend checking out when arriving at
your destination or shortly after having left the train.
Once checked in, `travelynx.de` will show a list of all upcoming stops. Select
2019-03-31 12:09:14 +00:00
one to check out there. You can also check out at a specific station by
navigating to "travelynx.de/s/*station name*" and selecting "Hier auschecken".
2019-02-16 16:28:01 +00:00
If you forgot to check out in time, or are departing the train at a station
which is not part of its documented route (and also not part of its documented
route deviations), or are encountering issues with travelynx' real-time data
fetcher, the checkout action will fail with an error message along the lines
of "no real-time data available" or "train not found".
If you use the checkout link again, travelynx will perform a force checkout: it
will log that you have left the train at the specified station, but omit
arrival time, delay, and other real-time data. At the moment, this data cannot
be specified manually.
2019-04-18 16:22:17 +00:00
Testing
---
The test scripts assume that travelynx.conf contains a valid database
2019-04-18 19:03:27 +00:00
connection. They will create a test-specific schema, perform all operations in
it, and then drop the schema. As such, the database specified in the config is
not affected.
2019-04-18 16:22:17 +00:00
2019-04-18 19:03:27 +00:00
Nevertheless, bugs may happen. Do NOT run tests on your production database.
Please use a separate development database instead.
2019-04-18 16:22:17 +00:00
Run the tests by executing `prove`.