
This module creates the necessary resources to run [paperless-ng](https://paperless-ng.readthedocs.io/en/latest/index.html) on AWS.

The resources managed by this module are:
- Aurora RDS (serverless, Postgres)
- ElastiCache (Redis)
- EC2
- Security groups, EBS attachments, passwords, etc. for the above

Source code available [here](https://github.com/ryanrishi/paperless-ng-terraform).


Terraform module to set up paperless-ng on AWS.

paperless-ng Terraform


import LoudnessWars from '../../components/projects/loudness-wars';

The [Loudness Wars](https://en.wikipedia.org/wiki/Loudness_war) refers to the dramatic increase in the perceived loudness of a song over the past 40 years. The loud parts haven't necessarily become louder, but instead the effective loudness (called the root mean square, or RMS) of recorded music has increased. This has been done by compressing the loud parts of an audio signal, and then increasing the overall loudness of the signal. The loud parts are now more or less as loud as they were before dynamic compression, but now that overall loudness has increased.

I wanted to quantify this notion that music is getting increasingly louder. I did so by scraping the year-end Billboard charts for the past 50 years, searching Spotify for those tracks, and using [Spotify's audio analysis API](https://developer.spotify.com/console/get-audio-analysis-track/) to get the loudness for each track, then visualized the data by plotting the loudness and release date for each track.

<LoudnessWars />

Some notes about the data:
- For some tracks, Spotify puts out a new version of the album with a new release date, but keeps the original loudness. For other tracks, Spotify puts out a remastered or deluxe version that is louder, but keeps the original release date. I've manually removed these entries, but if you do come across a track that looks suspicious (like a Michael Jackson track released in 2017), please <a href="/contact">contact me</a> to remove it. Thank you!
- [Spotify applies some loudness normalization](https://artists.spotify.com/help/article/loudness-normalization), so listening to a very quiet song on Spotify versus a very loud song on Spotify won't be as noticeable as listening to those two songs on another medium such as a CD.

Why does this matter? In short, everything being loud results in listener fatigue. It's kind of like eating the same meal every single day&mdash; you will (hopefully) get tired of eating the same thing. The same is true with our ears&mdash; if everything is loud, we get tired and nothing really sounds loud anymore.

This project utilized [Spotipy](https://github.com/plamere/spotipy) to pull information about tracks, and [d3](https://github.com/d3/d3) to visualize the data. Source code for this project is available [here](https://github.com/ryanrishi/loudness-wars).

## Further Reading
If you're interested in learning more about the loudness wars, here are some good resources.
- [The Loudness Wars: Why Music Sounds Worse](https://www.npr.org/2009/12/31/122114058/the-loudness-wars-why-music-sounds-worse)
- [Dynamic Range Day](https://dynamicrangeday.co.uk/)
- [They Really Don’t Make Music Like They Used To](https://www.nytimes.com/2019/02/07/opinion/what-these-grammy-songs-tell-us-about-the-loudness-wars.html) - this article has a great visualization of the average loudness vs. the peak loudness for many songs


A closer look at how recorded music has been getting increasingly louder over the past 50 years.

Loudness Wars


I built a bot that scrapes [recreation.gov](https://www.recreation.gov/) for campsite available for dates I've input. When it finds a campsite availability, it texts me so that I can hop online to book it. This project is 50% a pet project to play around with Python and related tech and 50% "hey, this is actually kinda useful".

This project started as a [fork of bri-bri/yosemite-camping](https://github.com/ryanrishi/yosemite-camping) running on a VPS with a cron job, but over the years has evolved into a more robust application that allows me to:
- add campsites outside of Yosemite
- add desired reservations via a CLI
- use [recreation.gov's new RIDB API](https://ridb.recreation.gov/docs) (the old one is no longer supported), using an [OpenAPI](https://github.com/OpenAPITools/openapi-generator)-generated Python client
- use built-in scheduling

Future improvements include:
- automatically booking a reservation when a campsite becomes available
- better scaling&mdash; separating the config management, the scraper, and the notification system
- Dockerizing it
- better handling around rate limiting for the RIDB API

Source code available [upon request](/contact). Built using Python, Selenium, SQLite, and Twilio.


I wrote a bot that texts me when a Yosemite reservation I'm interested in becomes available.

Letscamp


![COVID-19 Dashboard](/img/projects/covid-19-dashboard/covid-19-dashboard.png)

I wanted to provide a way for people to visualize the impact of COVID-19 in the US over time with the [New York Times COVID-19 dataset](https://github.com/nytimes/covid-19-data). I wanted this to be public, easy-to-use, and using off-the-shelf tools. With those requirements, I decided to pipe the time-series data into InfluxDB and visualize it with Grafana.

A few notes on the underlying data:
- This data is only for the US
- States, and even counties, qualify "cases" and "deaths" differently. For example, when a resident of Florida died in Los Angeles, the NY Times recorded her death as having occurred in California rather than Florida, though officials in Florida counted her case in their own records

More details, methodology, and definitions can be found at the [New York Times COVID-19 data repository](https://github.com/nytimes/covid-19-data).

Built using [Grafana](https://grafana.com/), [InfluxDB](https://www.influxdata.com/), and [csv-to-influxdb](https://github.com/fabio-miranda/csv-to-influxdb). Data from [New York Times](https://github.com/nytimes/covid-19-data). Running on [AWS](https://aws.amazon.com/), managed by [Terraform](https://www.terraform.io/).

Source available on [Github](https://github.com/ryanrishi/covid-19-grafana).

<Callout>
  The project site is no longer live, but there are instructions on how to run the project in the source code link above.
</Callout>


Visualize COVID-19 cases and deaths in the United States.

COVID-19 Dashboard


An ongoing project for services I run at home. I have a few Intel NUCs running [Proxmox](https://www.proxmox.com/), a few Synology NAS for persistent storage and backups, and a handful of Raspberry Pis for ad-hoc projects.

Services include:
- [Pi-Hole](https://pi-hole.net) for network-wide ad blocking and DNS resolution
- [ddclient](https://sourceforge.net/p/ddclient/wiki/Home) for dynamic DNS
- [WireGuard](https://wiki.archlinux.org/index.php/WireGuard) for VPN
- [Grafana](https://grafana.com) + [InfluxDB](https://www.influxdata.com/products/influxdb-overview) for storing and visualizing metrics
- [Telegraf](https://www.influxdata.com/time-series-platform/telegraf/) on every host, plus some extra SNMP metrics for Synology NASs

All of these are running as LXCs or via Docker on VMs. Everything is provisioned with [Ansible](https://www.ansible.com) so that changes are reliable and repeatable.

Future improvements include a separate VLAN for the lab, offsite backups, and improved monitoring for Docker containers.


Ongoing project of managing servers and services at home.

Homelab


I participated in the iHeartRadio (my company's sister company) hackweek in July 2019. While I can't go in-depth on the team's project, it was great spending time with coworkers in a different environment and learning about other teams' projects.

Blog post about our experience [here](https://www.jelli.com/launchpad/why-is-everyone-talking-about-hackathons/), and a blog post by another colleague [here](https://tech.iheart.com/iheartradio-summer-hackweek-2019-d1e6b37bb692). I promise I didn't play pool and volleyball the whole time.


Spent a week in a New York mansion working on a side project with some coworkers.

iHeart Hackweek 2019


In March 2019, I presented at [Hackfort](https://www.treefortmusicfest.com/fort/hackfort/), part of the Treefort music festival in Boise, Idaho. My panel was on side projects and innovation, and how side projects foster a mindset of innovation that lends itself nicely to day-to-day work.

Here is a quote from the Q&A portion of the panel:
> For side projects, because you’re in full control, it’s easy to get lost in the idealist/perfectionist mentality. This is something that previously plagued me. In the process of rebuilding a website, I switched from Jekyll to Rails to Rails API + Ember to Node API + Ember and back to Jekyll. In hindsight I’m glad I got exposure to all of those technologies, but it also taught me that it doesn’t have to be perfect. Perfection is the enemy of progress.
>
> The flip side to that is to not get too caught up in the technology. The tech world moves at light speed (see: React / Angular / Angular.js / Vue / Ember), so anchoring yourself to one tech stack is a good way to become pigeonholed. Above all else, this is about building a product that someone can use&mdash; even if that someone is yourself. While exposure to the bleeding edge technologies is exciting and a worthy venture, it’s also healthy to take a step back and making sure you’re focusing on whatever your goal is for that project.

Blog posts on the panel can be found [here](https://blog.jelli.com/hackfort-2019-side-projects-creative-outlets-inspire-innovation) and [here](https://www.jelli.com/launchpad/engineering-qa-managing-side-projects-and-finding-inspiration/).


I gave a talk on side projects and innovation at a music-meets-tech festival in Boise.

Hackfort 2019 - Creative Outlets Inspire Innovation


A side project I did at work to showcase innovation at the company as part of a new corporate website launch.

Project available at [Jelli Launchpad](https://www.jelli.com/launchpad/). Click on the map.


A side project I did at work to showcase innovation at the company as part of a new corporate website launch.

Projects.