Activity View

One of my main motivations for starting this project was to attempt to correlate my cycling cadence and power with the tempo of the music I was listening to. The short answer is no, the environment (and virtual environment) seems to have much more of an effect than my music, but it was fun to visualize.

Because we can’t be completely boring, I began with some basic stats and a map:

An activity view then shows some stats. First is a speed chart (which is unremarkable). Below that is a chart showing cycling cadence (revolutions per minute), tempo of the music (beats per minute), and power output (watts) together.

This was a pretty fun dataset to put together. The activity data is all pulled from the Strava API. This is combined with the user’s Spotify listening history. For each track, both the audio features and audio analysis are retrieved and stored. A large dataframe is then created merging all data, so it can be charted.

The Spotify API has a lot of other really cool metrics that could be charted as well, such as the acousticness, danceability, energy, liveness, loudness, and speechiness of a track. This is currently collected, but not displayed.

Zones

I realized once I had a catalog of all my Strava data that I could analyze it against publicly available GIS data, such as all the US States and US National Parks. This involved taking multi-polygon objects from ArcGIS Hub and looking for intersections with the linestrings typically generated from Strava Activities. A third one was generated manually in QGIS to cover some of the climb peaks in Zwift.

The main page for a Zone category will show a percentage of completion, and a list of zones and the first activity completed in each.

When viewing a zone’s page, you can also see a map, some quick stats, the first activity created, a list of each activity completed in the zone:

Points of Interest

In 2022, the Parade of Hearts began in Kansas City, and my Strava feed was flooded with rides designed to see as many hearts as possible, and I wanted to support tracking this. While the zones could definitely be used to track this, I felt it was overall more efficient to store just the coordinate of each heart, and count visits as an activity that comes with a configurable distance of that coordinate. Therefore, POI’s were born, and because I didn’t want to spend my time doing data entry, I found a Google Maps list of the hearts, downloaded the .kml file, and scripted an import process.

A POI Category, like the Parade of Hearts, will show a few basic stats, a color coded map, and a list of each with visit information.

Then, each POI will also have a page showing the point, the first activity visiting the point, and a list of all activities below.

Tech Stuff

Backend

The backend code is all Python. The bulk is Django with GeoDjango to handle the maps and detection of object intersection and proximity. Django Ninja was chosen as an API framework due to it’s simplicity, strong typing support, and Swagger page. The obvious choice for a database was PostgreSQL with PostGIS.

In order to gather and analyze this data, a backend task framework called Celery was used. Redis was chosen as a message broker, as it’s use could later be expanded to include caching. All of the analysis took place using Pandas.

Frontend

I’m not really a frontend developer, so I relied heavily on Bootstrap for the layout and Bootswatch for a better color scheme.

I used JQuery, Chart.js, and Leaflet.js to put together my ajax views, draw charts, and maps. The map tiles all come from Mapbox.

The basic page structure, like the layout and navigation menus are generated on the backend, but most of the page content is retrieved and rendered using ajax.

Automation and Deployment

The code currently lives in a private GitLab repo. GitLab CI is used to periodically rebuild docker images, which are then updated automatically via Watchtower. While the code is not actively being worked on, weekly image updates are still performed to ensure up to date patches are applied to the base images.

Future of the Project

Working on this project is too similar to how I spend my days at work, so I’ve ceased active development to avoid burnout. I would love to see an enterprising developer or team fork the work, and continue development.

Over the years, I’ve set up a lot of Raspberry Pi’s, which usually requires I pull out a spare keyboard and monitor to do basic configuration, which gets really annoying.

Inspired by the PiBakery project, I decided to do something about it. Introducing pi-image-prep:

This is a simple python script to help prepare a raspberry pi image in a matter of minutes. Currently, it can do the following:

• Set system locale
• Set system timezone
• Set passwords for root and pi users
• Add authorized keys for root and pi users
• Enable ssh
• Set hostname
• Enable WiFi
• Install packages by name

In order to do this, it will mount both boot and root partitions within a temporary location on the host computer.

Some changes such as the hostname, SSH, WiFi, and authorized keys are implemented on the image directly. Many others can only be implemented after the first boot. These are handled by placing a temporary script within /etc/cron.d/.

In particular, note there is a very small window in which a Raspberry Pi could be connected to the network with the default pi user password. In practice, this would be extremely difficult to exploit, except in a situation where the password change fails for an unexpected reason.

This script is designed to run only on Linux systems, and requires root (for now), and can be installed via pip:

sudo pip3 install pi-image-prep

Visit the following locations for more information:

• pypi.org/project/pi-image-prep/ for download and usage information
• gitlab.com/rveach/pi-image-prep for the source or to report bugs

In trying to keep with what I already own, I dusted off my cracked Fitbit Versa, attempted to seal the crack, strapped it on, and tried it out. While it will record cycling activities, the resulting data only recorded tracking points every 5 seconds. This is nowhere near the 1 second accuracy I’m able to get using the phone apps. While many would stop here and just chose to live with lower accuracy or lack of heart rate, I chose to press on and make it work.

Data Flow

In order for this to work, I knew I needed both GPS location from an app on my phone plus heart rate from my Fitbit. Because app allows deleting or modifying an existing ride, I needed to choose one app to record, and another to visualize. This choice was rather easy, because I feel that RideWithGPS is better for riding and Strava is better for Social.

My plan was to pull data from RideWithGPS and Fitbit API’s, combine it, then format it so it could be read by Strava (TCX).

I chose to write this as a Python script. Due to some previous work I’d done to analyze my stats, I chose to write it as a management script for an existing Django project, but I will try to focus on the more unique aspects of this task.

Location Data from RideWithGPS

For me, GPS logging is the most critical piece of information. I really enjoy tracking and conquering my personal bests on Strava Segments, so this is my primary data source. I did not want to alter it any way, just merge in the heart rate information where possible.

Before I even got started, I recorded a test ride with RideWithGPS, and found that it only recorded every other second, but luckily, that’s easily configured in the settings.

Their API is simple, but easy to navigate. It’s possible to get a list of a user’s ride, then pull individual ride details. Nested a couple layers deep in the ride details, we’re given elevation (meters), time (unix timestamp), x (longitude), and y (latitude).

{
  "e": 236.4815364,
  "t": 1598482303,
  "x": -94.4359419,
  "y": 39.2367653
},
{
  "e": 236.4665218,
  "t": 1598482304,
  "x": -94.435941,
  "y": 39.2367631
},

In my script, I used requests to pull the data, resulting in a dictionary-like object. That’s fine, but Pandas is better….

import pandas as pd

activity_df = pd.DataFrame(
    ride_detail.get('trip').get('track_points')
)

What we get is something like this:

                 e             x            y             t
   0    236.481536    -94.435942    39.236765    1598482303
   1    236.466522    -94.435941    39.236763    1598482403
   2    236.344946    -94.435940    39.236762    1598482503
   3    236.278519    -94.435938    39.236762    1598482603
   4    236.260699    -94.435933    39.236764    1598482703
...            ...           ...          ...           ...
4798    234.847334    -94.435919    39.236706    1598531700
4799    234.841117    -94.435915    39.236708    1598531701
4800    234.942241    -94.435913    39.236708    1598531702
4801    234.961215    -94.435914    39.236708    1598531703
4802    234.858422    -94.435909    39.236709    1598531704

So, let’s turn those integer timestamps into real timestamps with time zones. While we’re at it, let’s rename some columns to match the TCX spec:

import datetime
import pytz
from django.utils.timezone import make_aware

# get a utc timezone object
utcz = pytz.timezone('utc')

def get_dt(time_stamp:int):
    """ convert timestamp to timezone aware datetime """
    return make_aware(
        datetime.datetime.utcfromtimestamp(time_stamp),
        timezone=utcz,
)

# create a new Column 'Time', and populate
# it with timezone-aware timezones
activity_df['Time'] = activity_df['t'].apply(self.ts_to_dt)

# rename some columns to match TCX Spec, and drop 't'
# which is no longer needed.
activity_df.rename(
    columns={
        "y": "LatitudeDegrees",
        "x": "LongitudeDegrees",
        "e": "AltitudeMeters",
    },
    inplace=True,
)
activity_df.drop(columns=['t'], inplace=True)

This gives us something a little more human readable:

      AltitudeMeters  LongitudeDegrees  LatitudeDegrees                      Time
0         236.481536        -94.435942        39.236765 2020-08-26 22:51:43+00:00
1         236.466522        -94.435941        39.236763 2020-08-26 22:51:44+00:00
2         236.344946        -94.435940        39.236762 2020-08-26 22:51:45+00:00
3         236.278519        -94.435938        39.236762 2020-08-26 22:51:46+00:00
4         236.260699        -94.435933        39.236764 2020-08-26 22:51:47+00:00
...              ...               ...              ...                       ...
4798      234.847334        -94.435919        39.236706 2020-08-27 00:35:00+00:00
4799      234.841117        -94.435915        39.236708 2020-08-27 00:35:01+00:00
4800      234.942241        -94.435913        39.236708 2020-08-27 00:35:02+00:00
4801      234.961215        -94.435914        39.236708 2020-08-27 00:35:03+00:00
4802      234.858422        -94.435909        39.236709 2020-08-27 00:35:04+00:00

Retrieving Heart Rate Data

In order to pull minute-by-minute data from the Fitbit API, I had to create a “Personal” project, which would only allow me access to my own fitness data. This is done through the Heart Rate Intraday Time Series endpoints.

The data was returned with time only, missing date and timezone information. It actually looks something like this, yikes!

    "activities-heart-intraday": {
        "dataset": [
            {
                "time": "00:00:00",
                "value": 64
            },
            {
                "time": "00:00:10",
                "value": 63
            }
        ],
        "datasetInterval": 1,
        "datasetType": "second"
    }

Luckily, the timezone can be retrieved through the user’s profile endpoint, which returns the timezone name. In my case, ‘America/Chicago’.

Before going any further, let’s add a column to our first DataFrame displaying our time in the same zone as Fitbit:

# fitbit_tz is a dictionary object representing the response
# from the user's profile api endpoint.
# returns: America/Chicago
fitbit_tz = pytz.timezone(
    fitbit_profile.get('user').get('timezone')
)

# We're going to add a new column, 'FitbitTZ' in addition
# to the other ones:
activity_df['FitbitTZ'] = activity_df['Time'].apply(
    lambda x: x.tz_convert(fitbit_tz)
)

Here, you can see the new column. It’s the same timestamp, just displayed in a different timezone. To keep everything on one line, I’ve removed the coordinate and altitude columns to showcase the time zones:

                            Time                  FitbitTZ
0      2020-08-26 22:51:43+00:00 2020-08-26 17:51:43-05:00
1      2020-08-26 22:51:44+00:00 2020-08-26 17:51:44-05:00
2      2020-08-26 22:51:45+00:00 2020-08-26 17:51:45-05:00
3      2020-08-26 22:51:46+00:00 2020-08-26 17:51:46-05:00
4      2020-08-26 22:51:47+00:00 2020-08-26 17:51:47-05:00
...                          ...                       ...
4798   2020-08-27 00:35:00+00:00 2020-08-26 19:35:00-05:00
4799   2020-08-27 00:35:01+00:00 2020-08-26 19:35:01-05:00
4800   2020-08-27 00:35:02+00:00 2020-08-26 19:35:02-05:00
4801   2020-08-27 00:35:03+00:00 2020-08-26 19:35:03-05:00
4802   2020-08-27 00:35:04+00:00 2020-08-26 19:35:04-05:00

In my testing, I found that the Fitbit Heart Rate Intraday Series wouldn’t return more than 24 hours of data, and to avoid complex logic, I just did full day data pulls for each day found in the activity.

Pandas makes it easy to get a unique list of the dates:

fitbit_dates = activity_df['FitbitTZ'].apply(
    lambda x: x.date()
).unique().tolist()

Then, for each date, we retrieve a dictionary object, and turn those date strings into a dictionary object reflecting a timezone-naive datetime paired with the heart rate value.

Where hr_data is a dictionary object from the API and day is a datetime.date object:

hr_series = list(map(
    lambda x: {
        "time": datetime.datetime.combine(
            day,
            datetime.datetime.strptime(x.get('time'), '%H:%M:%S').time(),
        ),
        "value": x.get('value'),
    },
    hr_data.get('activities-heart-intraday').get('dataset'),
))

That data is then converted into yet another Pandas DataFrame, where we use django.utils.timezone.make_aware again to add the correct timezone onto the data. I’ll name it hr_df, for short:

        hr                      hr_time
0       61    2020-08-26 00:00:04-05:00
1       60    2020-08-26 00:00:14-05:00
2       59    2020-08-26 00:00:24-05:00
3       58    2020-08-26 00:00:29-05:00
4       57    2020-08-26 00:00:34-05:00
...     ..                          ...
5894    90    2020-08-26 20:09:26-05:00
5895    91    2020-08-26 20:09:41-05:00
5896    91    2020-08-26 20:09:56-05:00
5897    89    2020-08-26 20:10:01-05:00
5898    88    2020-08-26 20:10:06-05:00

Merging the Data

Now, we have two different data sets, both stored in Pandas DataFrames. Each contains timeseries data, but the times don’t match. Thankfully, this is easily solved with Pandas’s merge_asof method. This is like a database left join, except it will match on the nearest key rather than equal keys. Perfect!

As previously mentioned, our GPS information is the critical piece, so we’re going to use that as our left table, and merge in the heart rate data as a best fit:

activity_df = pd.merge_asof(
    activity_df.sort_values("FitbitTZ"),
    hr_df.sort_values("hr_time"),
    left_on="FitbitTZ",
    right_on="hr_time",
).drop(columns=["FitbitTZ", "hr_time"]) \
    .sort_values('Time').fillna(method='ffill')

This gives us a table with all the information we need to create the entire activity. Shown with abbreviated column names and date for spacing:

              Alt          Lng         Lat             Time   hr
0      236.481536   -94.435942   39.236765   22:51:43+00:00   98
1      236.466522   -94.435941   39.236763   22:51:44+00:00   98
2      236.344946   -94.435940   39.236762   22:51:45+00:00   98
3      236.278519   -94.435938   39.236762   22:51:46+00:00   98
4      236.260699   -94.435933   39.236764   22:51:47+00:00   98
...           ...          ...         ...              ...  ...
4798   234.847334   -94.435919   39.236706   00:35:00+00:00  141
4799   234.841117   -94.435915   39.236708   00:35:01+00:00  141
4800   234.942241   -94.435913   39.236708   00:35:02+00:00  141
4801   234.961215   -94.435914   39.236708   00:35:03+00:00  141
4802   234.858422   -94.435909   39.236709   00:35:04+00:00  141

Formatting For Upload

This is already a long enough article, so I’m going to keep this brief. Of the file formats available, I chose Training Center XML (TCX), since it’s a fairly simple XML schema. Once I had the data, it was a matter of tracking down information on the TCX file format and copying it.

I accomplished this using ElementTree, wrote it to a BytesIO object, then uploaded to Strava using requests.

Success!

A ride with heart rate data!

Takeaways

In general, most fitness apps function like walled gardens. Depending on how it’s tracked, it may be very difficult to get a complete picture of everything. As a data nerd, this is incredibly frustrating.

This was a fun problem to solve, as I got to punch a hole through some of these walls. I’ve been using this script for about a week without any issues. Unfortunately, I think it’s a bit of a temporary situation. There are a lot of moving pieces, and many different things could affect the data availability.

As far as Fitbit, I honestly can’t recommend them for anything other than a casual step tracker. In 2018, I had the opportunity to pick up a Fitbit Versa through a former employer’s health plan, but found it to be lackluster in the smart watch capabilities and fragile. Disappointingly, the screen cracked in a minor tumble about a week after I got it. I really get nothing out of their health dashboard either, so I use it like a dumb watch that also records my heart rate.

I actually plan on buying into a device ecosystem that already has everything I need all in one place. So, essentially, I’ll be throwing money at the problem, but I think it’ll give me a much better experience. In the long run, it’ll be money well spent for my new favorite hobby.

Ansible is free and open source configuration management software, powered by Python, ssh, and YAML. The core is simple, but powerful. Unless you shell out some cash for Tower, it’s still manual.

My Solution

Enter ansible-docker, an image I created for automated Ansible execution using GitLab CI.

• Docker Hub rveach/ansible
• GitLab Source: rveach/ansible-docker

While you can pull it and run it interactively, it’s really meant for use in CI/CD environments. To use it, just create a separate repo, and structure it in this manner. The integration takes place in the .gitlab-ci.yml file.

playbooks/             # pull all ansible playbook stuff here
    site.yml           # or any other file
    group_vars/        # with group_vars and roles
    roles/             # just do whatever you've configured
                       # follow standard ansible best practices

ssh/                   # ssh info
    id_rsa             # private key
    id_rsa.pub         # keep the public key here too
    known_hosts        # known hosts file
    config             # ssh config file

hosts                  # hosts file
ansible.cfg            # ansible.cfg file
.gitlab-ci-yml         # define CI jobs here

SSH Security

When performing configuration management over SSH, the remote user must be either privileged or have the ability to perform critical tasks as a privileged user. This is not to be taken lightly. In my environments, I do not allow SSH in through my firewall. Instead, I’ve installed a GitLab runner behind my firewalls in each location.

In addition to network security, this image allows you to include your own ssh keys, known_hosts file and ssh config file.

• The private key file name will default to id_rsa, but can be overridden with the environment variable $SSH_KEY_NAME.
• The private key file can be password protected, just supply the environment variable $SSH_KEY_PASSPHRASE to decrypt.
• The known_hosts file can be populated populated for each of your hosts using the output of ssh-keyscan -H $REMOTE_HOST. Alternatively, you can set host_key_checking = False in the ansible.cfg if you don’t care to validate host keys.
• …and of course, the ssh config file can be set up in any way necessary.

You may want to look into other standard ways of securing SSH, like this one on nixCraft: Top 20 OpenSSH Server Best Security Practices

Ansible Vault

When using sensitive information in an Ansible playbook, it’s highly recommended to use Ansible Vault to encrypt those contents. The wrapper script has functionality to read a vault password from either the environment variable $VAULT_PASSWORD (recommended) or the command line argument --vault-password(not recommended for security reasons).

Home Servers

deploy-homeservers:
  stage: deploy
  image: rveach/ansible:latest-arm
  script:
    - /usr/local/bin/run.py --playbooks site_homeservers.yml
  only:
    - master
    - homeservers
  except:
    variables:
      - $ANSIBLE_PLAYBOOK_LIST
  tags:
      - armhf
      - homelab

Digital Ocean Droplets

deploy-droplets:
  stage: deploy
  image: rveach/ansible:latest
  script:
    - /usr/local/bin/run.py --playbooks site_droplets.yml
  only:
    - master
    - droplets
  except:
    variables:
      - $ANSIBLE_PLAYBOOK_LIST
  tags:
    - droplet

Dynamic Deploy

deploy-dynamic:
  stage: deploy
  image: rveach/ansible:latest-arm
  script:
    - /usr/local/bin/run.py --playbooks ${ANSIBLE_PLAYBOOK_LIST}
  only:
    - master
  except:
    variables:
      - $ANSIBLE_PLAYBOOK_LIST == null
  tags:
      - armhf
      - homelab

These jobs provide flexibility in a few ways:

• Deploy Dynamic is executed when a playbook list is passed through an optional variable. This is mainly used when triggering CI tasks from other projects via the external API.
• The other tasks run for master, but can also be set up to run from other branches. I use this to speed up the feedback loop when actively working on a role.
• Note: I’m also pulling two different tags for the image. Until I spend some time to configure a multi-arch build, separate tags are needed for amd64 and arm. I just happen to use a dedicated Raspberry Pi 3B+ for my GitLab Runner at home.

In Use:

Now, whenever I push to the repo, I know that Ansible will execute, and I rely on GitLab’s notifications to let me know when there has been a failure.

Should any individual job fail, the log is also available:

Scheduling Jobs

Of course, updates on repo push is only half the story. Any well managed environment should have configuration deployed on a schedule to automate updates and prevent configuration drift. Luckily, GitLab CI allows you to schedule pipelines.

In conclusion, it took me a bit of time to work out all the kinks on this, but once completed, it’s been incredibly smooth. In writing this, I hope others can benefit from my work or find inspiration to create their own solution.

Cover image by Harrison Broadbent

I’ve personally set up an alert, so my phone is notified after my garage door has been left open for a certain amount of time. This helps me sleep better, and a recent event at a friends house has spurred me to share the knowledge. While there are many ways to do this, I will detail two methods.

Note that many systems, including the two listed below are capable of much more. They can even be made to shut the door automatically. Personally, if my house is going to think for itself, I prefer it lets me know what it thinks vs acting on it’s own. Be mindful, Alarm Fatigue is a real thing! Try to minimize the number of false alarms based on your own lifestyle and habits.

MyQ Garage Door Alerts

Many recent Liftmaster and Chamberlain garage door openers come with MyQ technology enabled. These openers connect via WiFi, and can be controlled via a mobile app. Without needing too much technical expertise, these can be enabled and actively monitored all with the MyQ app.

I’m using MyQ, because the openers that came with my house had this available. They’re an excellent option for most people, but they do rely on a cloud system, which may bother some people. The following guide assumes that the app is already installed and the opener is connected.

1. Open up the app and select the menu button

2. In the MyQ app menu, select Alerts.

3. You should then be able to create a new alert. To do this

• Give the alert a name
• Sent me an alert when the: Garage door is open
• For longer than: Set the desired time frame here
• By default, this will be enabled all times and days.
• By default, alerts are sent via push notification to the app, but can also be sent via email.
• By default, the alert is enabled. This option allows you to disable the alert.

4. Test the alert!

• Just open up the door, and make sure you get an alert.
• Note: at the time of writing, it was very cold outside, so the alert as tested was set to only 2 minutes. The app should respect the value set in step 3.

Home Assistant Garage Door Alerts

Home automation is a fairly recent hobby of mine, and I’ve chosen Home Assistant as my main hub. Unlike most home hubs, it is software only and can be installed on most computers or single board computers, such as a Raspberry Pi. It is configured mainly using yaml based files, but the development team has been working a config model that allows everything to be completed via the web frontend.

To start with the install, it is best to ensure that some common entities are enabled as well as the myq cover. We can also add our notifier here. There are many examples, but my example shows Pushover.

---
# the following 4 items are enabled for config and troubleshooting
config:
frontend:
logbook:
system_health:

# enable myq as a cover.
# this example accepts the username and password as
# environment variables.
cover:
  - platform: myq
    username: !env_var MYQ_USERNAME
    password: !env_var MYQ_PASSWORD
    type: liftmaster

# configure a notifier
# this example shows pushover, by any one of many can be used.
notify:
  - name: ryan_pushover
    platform: pushover
    api_key: !env_var PO_API_KEY
    user_key: !env_var PO_USER_KEY

Once enabled, restart Home Assistant and navigate to Developer Tools, States, then find the cover entries. In my case,

Once enabled:

• Restart Home Assistant
• Navigate to Developer Tools, States
• Find the cover entries, and record the names.
• In this screenshot, I’ve recorded cover.hobby_2 and cover.main_door_2

Once we have the entity names, open back up the configuration.yaml and add an alert the one below anywhere that makes sense:

alert:
  garage_door_open:
    name: garage_door_is_open
    entity_id: cover.main_door_2
    state: 'open'
    repeat:
      - 10
      - 60
    can_acknowledge: true
    skip_first: true
    message: "The main garage door has been left open."
    done_message: "The main garage door is now closed."
    notifiers:
      - ryan_pushover

This config will do the following:

• Monitor the entity cover.main_door_2, triggering off the ‘open’ state.
• It will alert at 10 minutes, then every 60 minutes after that.
• It can be acknowledged
• Skip first prevents an alert from being sent on initial open and only begins to send messages at 10 minutes.
• Messages to be sent on alert and resolution are defined.
• This will notify the pushover notifier configured above.

Next, test the alert by leaving the garage door open.

Bingo! We have success!

Cover Photo by Vivint Solar on Unsplash

If you’ve been following along really closely, you might have noticed a few extra spammy blog posts showed up.

I got hacked ¯\_(ツ)_/¯

This blog has never been super critical, and admittedly, I was lax on security precautions, so I can’t say I’m super surprised. I wanted to understand the problem and come back with a better solution, so I powered off the VM, conducted an investigation, built out some Ansible roles for a new one, and I’m back up and running finally, whew!

What I know:

There was no unauthorized shell access to my web server. All access was obtained through exploiting the web application (WordPress).

Attackers likely gained access through uploading malicious PHP code, but I’m not going to rule out brute force attacks either.

Preventing Future attacks:

I’m not going to spell out everything that is being done to prevent attacks in the future, because my methods may evolve, and there are already a lot of good articles out there on how to harden WordPress.

In short, here are some new things I’m doing:

• Enable Two Factor Authentication - Plugin
• Enable brute force attack protection - Plugin
• A few other tricks up my sleeve…..

What about the old content?

I have the articles saved. I might re-upload a few more important posts at a later point in time, but I’m not in any hurry.

Cover Photo by Clint Patterson on Unsplash