DEV Community: Patricio Salazar

I Turned My Old Broken 2011 MacBook Pro Into My First Home Server

Patricio Salazar — Fri, 29 May 2026 15:17:09 +0000

I’ve been thinking about three things a lot recently.

With a growing family, I've been thinking a lot about data and privacy. About how aggressive ads have gotten on platforms we already pay for. About what happens to a lifetime of photos.

Those three things were in the back of my mind when YouTube served me a video about turning old MacBook Pros into home servers... and I happened to have one. Of course Google/YouTube know that somehow.

The machine

It's an old MacBook Pro from 2011. I thought it was completely dead. One day the screen suddenly failed and never worked again. A Genius Bar tech told me the graphics card was toast. Classic 2011 MacBook Pro problem, apparently. Google "RadeonGate" if you want to fall down that rabbit hole.

Anyway, I had so much stuff on that hard drive that I held onto it for all these years with a plan to recover all the data.

After watching some of those YouTube videos, it made me wonder: did my dusty MacBook Pro have a second life in it?

I ordered a new charging cable and a mini DisplayPort adapter off Amazon and figured I'd find out.

Turning it back on

The first little win was seeing that the MacBook still charged. Good sign. I connected the external monitor, hit the power button, and voila - it turned on.

But still, no display.

The mini DisplayPort cable wasn't sending a signal to the monitor whether the lid was open or closed (and of course, the MacBook's screen was still failing).

But I could hear it. The fans were spinning up. The startup chime was firing. Something was happening in there.

What happened most commonly on boot was this: it would reach the Apple loading screen and freeze. The display looked completely destroyed with rainbow pixels and distortion so bad you couldn't see the progress of the loading bar. It was just stuck there.

However, in true tinkering spirit, I was determined to get this thing to work and I was expecting a battle, so a few bumps in the road were not going to deter me.

I searched for alternative boot modes and the mode that actually gave me something to work with was verbose boot. On a Mac, you hold Command + V right at startup. Instead of the Apple loading screen, you get a wall of scrolling text showing exactly what the system is doing as it loads. It gives you pure information.

The problem was the text was just as distorted as everything else. All the letters and words looked like corrupted data. It wasn't legible at all.

So I started taking photos of the screen with my phone and sending them to Claude.

This is where things got interesting. Claude could pick out patterns in the distortion. It picked up on partial words, recognizable kernel extension names, and fragments of log lines. And it identified exactly where the boot process was hanging, which was the AMD GPU driver loading and causing a cascade failure. Turns out the machine wasn't completely toast, but it was fighting with itself. The GPU firmware indeed seemed corrupt or degraded, and every normal boot attempt ended with the system trying to initialize it and failing to do so.

With that information, I continued to stumble forward with high hopes.

I tried a few different approaches across several sessions and boot modes including single-user mode (Command + S), safe mode (hold Shift), different NVRAM and SMC resets. Over the course of a couple days I realized I could actually get the MacBook screen to turn on randomly without the distorted graphics after many power up attempts (which was very revealing that again, it wasn't totally toast). So I just kept doing that. I eventually got the machine booted far enough a handful of times, to do what I needed. I backed up everything on the hard drive. Said goodbye to the old system; and wiped it.

Installing Debian

Following Claude's instructions (always cross-check these), I flashed a USB drive with the server-only distro of Debian 13 and got ready to install it on the MacBook.

The server-only distro of Debian is text-based, so it doesn't rely on the GPU for display. But I still needed to address the AMD GPU hardware issue. For this, I learned I could set radeon.modeset to zero, which would prevent the Radeon kernel driver from loading. This driver tries to initialize the broken GPU and would freeze the system before the installer even appears. This variable gets set at the GRUB boot menu, so I edited the boot parameters and added radeon.modeset=0 to the kernel line before starting.

Next, I began to get familiar with the system and started learning specific commands to see what was going on inside. When I checked the temperature sensors, I saw the GPU was sitting around 47°C and the fans were spinning at over 5,000 RPM trying to compensate. Even with radeon.modeset=0 preventing the driver from loading, the GPU hardware itself was still active and generating heat. And it turns out Linux does not natively control Apple fans, so it seems that this was the Apple hardware reacting to the heat on its own. I needed to disable the GPU and fix the communication between Linux and the Apple hardware.

I immediately did these two things in order:

Made sure the GPU was permanently disabled. I had Claude create a custom GRUB script that sends low-level commands to the graphics multiplexer chip, telling it to route everything through the Intel integrated graphics and power down the AMD GPU entirely. After that, the GPU temperature dropped from ~47°C to basically 3°C (reporting as off), and fan speeds dropped from 5,000+ RPM to around 2,800 RPM.
Installed fan control. I installed macfanctld, which gives Linux the ability to actively manage fan response. I also wrote a custom temperature monitoring script that runs every minute and sends a push notification to my phone via ntfy.sh if the server gets too hot, with a follow-up notification when it cools back down to avoid false positives.

My unexpected networking problem

I assumed getting the server onto the internet would be simple. It was not.

I had the server hard-wired to my Ruckus router via ethernet. It had an IP address, but it couldn't resolve any domain names. This turned out to be a problem caused by not having the resolvconf package installed. Without resolvconf, DHCP could not update the DNS configuration. Running apt install resolvconf fixed this issue.

The bigger problem was that my other devices couldn't reach the server at all. The server on ethernet was sitting on one subnet, while all my other devices on WIFI were on a totally different subnet. The Ruckus router isolates them from each other. From my devices on WIFI, it was as if the server didn't exist on the network.

Enter Tailscale. Tailscale solves this problem immediately. It creates a WireGuard-based mesh VPN, so all my devices are able to join the same private network (regardless of what subnet they're on). Plus I can join from anywhere else in the world. Once I had Tailscale running, I could SSH into the server no problem. I realize that I haven't actually fixed the root subnet problem, and that Tailscale can be seen like a band-aid for my situation, but I'm okay with this setup for now. The Ruckus router has been difficult to deal with, so as long Tailscale keeps working for me, I'm good.

What's running on it now

After networking was stable, everything else moved fast. I set up Docker, Portainer (a web UI for managing containers), and Cockpit (a system dashboard for monitoring the machine itself). The fun part came next, deploying services.

Services currently running on the server:

Immich: Photo management for our family photos, finally.

Firefly III: Fully featured personal finance tracking system.

Home Assistant: Primarily for a custom built family dashboard.

Caddy: Reverse proxy that handles HTTPS automatically for each service.

Homepage: A single dashboard view of everything running on the server.

All of this is accessible over Tailscale, meaning nothing is exposed to the public internet. My family keeps convenience, while I get to keep the control. Once I make some hardware upgrades, I'll work on adding either Plex or Jellyfin.

The documentation

One thing I did early on that I'd recommend doing from day one is documentation. In my case, I created a private Git repo documenting everything. For me, that meant a setup log file tracking every change in chronological order, specific hardware notes, architecture diagrams, and a troubleshooting guide for issues I've already encountered and solved. A separate active log file gets updated every time I make a meaningful change.

The goal is that if something breaks six months from now, I'm not starting from scratch trying to remember what I learned or what I did. And, the repo becomes the source of truth.

It's been a couple months, What do I think?

My server came online a couple months ago.

I'm making real progress addressing my privacy concerns. I feel some level of ownership and control, and that feels so good. I don't control everything I want to yet, but I'm on the path.

There is a lot of maintenance involved so far, which is one thing about managed services - it's so nice to not have to maintain any of it. So most of this comes down to what you're willing to trade. Have everything managed for you, but give up all your privacy and data, or gain control of them at the expense of some time and effort.

With that being said, I've learned so much and still am. This whole process has exposed me to new skills. It's helped build on top of other ones. And in general, I feel a little more well rounded as a dev. But the best part is I get to keep tinkering with this system and take back control of my family's privacy and data.

If you have an old piece of metal laying around, I encourage you to find a use for it. It's so worth it and incredibly satisfying to give an old piece of gear a new life.

Maybe the first step is to just turn the thing back on.

You Don't Need A Framework - Build A Dynamic Blog with HTML & Vanilla JavaScript

Patricio Salazar — Wed, 28 May 2025 18:37:57 +0000

Months ago, when I was reworking parts of my website, I began questioning every part of the tech stack. During that process, I thought about how I would build a dynamic blog with vanilla JavaScript. Eventually, I realized I was still going to end up using a framework. So, I worked through the main concepts in my head to scratch the itch, then shelved the idea...until, I couldn't ignore the fact that the itch was still there.

This article is simply about the JavaScript side of building a dynamic blog. It is not a claim on the best approach for such a system, nor an argument for or against using vanilla JS or a framework. We're just looking at how this could get done.

Let's get into it

First things first, we need a few HTML and JS files, so let's get a new project going in your favorite editor (feel free to code along).

Create a new folder, name it whatever you want, and open it in your editor. Create the following files and folders:

index.html
blog.html
blog/post.html
js/blogCards.js
js/blogPost.js
js/blogPostsData.js

No Webpack, no Vite, no package.json... and no Tailwind 🤯. Ahhh, how refreshing.

Boilerplate code

Here is the relevant HTML

blog.html:

Include the script tag for blogCards.js in the head
<script type="module" src="/js/blogCards.js" async></script>

blog-post.html:

Include the script tag for blogPost.js in the head
<script type="module" src="/js/blogPost.js" async></script>

Also, the blog post data

blogPosts.js:

Add as many blog post objects as you want. I had ChatGPT generate some dummy data here.

Start and preview

This is a good time to start the project to see what we have so far. If you're using something like VS Code, view the project using Live Server.

Dynamically populate the blog listing page with blog-post cards

Let's start by importing the data at the top of the blogCards.js file:

import { blogPosts } from "./blogsPosts.js"

We're going to have to place each blog card inside of a the container element we created in the blog listing page, so let's declare a blogCardsContainer variable and store a reference to the container in it:

const blogCardsContainer = document.querySelector("#blog-cards-container");

Now, we can loop over each blog post in our data, create the cards, and then finally append them to blogCardsContainer:

The first three lines inside of the forEach loop:

Creates a div element to be styled as the card
Adds a "blog-card" class to the div
Sets a "data-id" attribute on the div with the value of current post id to uniquely identify each blog post card (in case you want control for individual cards).

Here's one of the most important parts of the blogCardHTML content we created above: We set the href attribute to the individual post.html page, but, and here it is, we add in a slug parameter which is the value of the blog post slug. This is how the individual post.html page knows what blog post it's supposed to be loading when navigated to.

Now that we know which post is supposed to be showing, all we have to do is create the HTML structure for our blog post and load in the post data, similar to how we did for the blogCards - except we're not doing a loop this time. Let's apply the logic...

Dynamically building the individual blog post page

When our post.html file loads, we already know that we're going to have a post slug as a parameter. This is how we know which post to work with, so let's set it up.

At the top of blogPost.js, import blogPosts

You may know about the window.location object. But, to isolate the query parameters from the URL, we can access the search property on window.location, and we'll pass that into the URLSearchParams interface:

`const params = new URLSearchParams(window.location.search);

`The URLSearchParams interface exposes a 'get' utility method allowing us to retrieve the exact parameter we're looking for:

const slug = params.get("slug");

Perfect. Now, let's find the exact post:

const blogPost = blogPosts.find((post) => post.slug === slug);

Like with the blogCards, let's grab the blog post container on our post.html file so that we know where to inject the post after we build it:

const blogPostContainer = document.querySelector("#blogPost");

Okay, now let's build the blog post HTML structure, and inject into the blog post container, but only on the condition that the post was actually found. For now, we handle the situation where the post isn't found by displaying some simple text.

Try it out

Go back to the blog listing page. Navigate to different posts, and watch them be displayed onto the page.

🎉 Congrats! You now know some essential concepts needed to build a dynamic blog system in vanilla JavaScript 🎉

If all this has made you curious to find out how much more it would take to get this blog to a complete, production-ready level, I encourage you to scratch that itch - It'll be worth it.

Here's a hint to some modifications and optimizations that would make this project better:

SPA experience
- load all content and pages using a single div in the index.html file, just like frameworks do
- this will offer better URLs and faster load times since you won't be loading full pages
Store blog posts in an external db
Use a mouseover event listener on blog post cards to prefetch html content

Conclusion

Although there are many changes you could make to this project, the point is you don't always need every framework feature. Often, all you need is simplicity.

If this article helped you learn something, I'm so glad. But there are three important takeaways I hope you’ll leave with:

Remember to question things from time to time.
Go beyond the question, and let your curiosity scratch the itch (think about the solution)
You don't always need a framework 😏️

https://patriciosalazar.hashnode.dev/you-dont-need-a-framework

How to Use Laravel Sail with Docker for PHP 8.2 (No Global PHP Upgrade Needed)

Patricio Salazar — Tue, 06 May 2025 18:21:18 +0000

How to Use Laravel Sail with Docker for PHP 8.2 (No Global PHP Upgrade Needed)

Working on a Laravel project that requires a newer PHP version can be tricky if your system’s PHP is older. My personal computer is a Mac, but my work computer is a Linux machine where I sometimes run small projects for exploring and learning new technologies. In that case, upgrading my global PHP installation is not an option since I’d risk messing with work projects.

This is exactly the kind of situation Laravel Sail is for. Laravel Sail lets you use Docker to run your Laravel app with the required dependencies, all while keeping your global system versions untouched.

Here is how I set up new Laravel projects on a Linux computer (works on macOS, Linux, or Windows via WSL2) with Sail and the latest versions of PHP (without touching the global version).

First, get your project and terminal ready

Once you have your Laravel project files ready it’s time to run some commands.

If you’re using a Laravel starter kit with Inertia and React or Vue, the installation process might have already run npm install for you. If not, go ahead and run that. Otherwise, skip this command.
Now, try running composer install. If you get an error because you have an older version of PHP than required…good! We’re on the same page.

Next, we need to run a temporary Docker container to get the latest versions of the required dependencies. Run this command:

docker run --rm \ -u "$(id -u):$(id -g)" \ -v "$PWD":/var/www/html \ -w /var/www/html \ laravelsail/php82-composer:latest \ composer install

What the above command does: It spins up a temporary Docker container using the Laravel Sail PHP 8.2 image, executes composer install inside the project folder, and then stops and removes the container.

docker run --rm: Start a new container, and remove it (–rm) when it’s done (so it won’t hang around on your system).
-u "$(id -u):$(id -g): Run the container with your user’s UID:GID. This ensures any files Composer creates (like the vendor folder) will have the correct permissions matching your user, not root.
-v "$PWD":/var/www/html: This command mounts your current host directory into the container at /var/www/html, allowing the container to access and modify files in your project.
-w /var/www/html: This sets the working directory inside the container to /var/www/html, ensuring that subsequent commands run in the correct context.
laravelsail/php82-composer:latest: This specifies the Docker image to use. It’s an image with PHP 8.2 and Composer installed (provided by Laravel Sail).
composer install: This is the command we want to run inside the container. It will install all the dependencies as if you ran it on a machine with PHP 8.2.

Configure Sail and Docker

Run the Sail installation (Artisan) command inside Docker. This command publishes the docker-compose.yml file and updates your .env with environment variables for Docker.

Note: If you want to use a different database in your project rather than the default MySQL, add the --with= flag to the command. To keep the default MySQL db, omit the additional flag.

Run:

docker run --rm \ -u "$(id -u):$(id -g)" \ -v "$(pwd)":/var/www/html \ -w /var/www/html \ laravelsail/php82-composer:latest \ php artisan sail:install --with=pgsql

This docker command is similar to the previous one, except now we’re executing the artisan sail:install setting up Docker/Sail along with the optional PostgreSQL db configuration.

You should see a docker-compose.yml file in the root of your project now.

Note: The values added to your .env (and the ones in docker-compose.yml) are mostly default/local settings. For example, Sail might set DB_PASSWORD=password and DB_USERNAME=sail (or postgres) for your database, which are local credentials for the Docker containers. If you’re anything like me and have multiple Laravel projects running at the same time, you might need to adjust port numbers. For instance, you probably need to add APP_PORT in the .env file and customize the value with something like APP_PORT=7070 to have your app run on port 7070 instead of the default port 80, where 80 is already in use. Just make sure you update your docker-compose.yml file to match this. The same is true for SERVER_PORT, and SERVER_HOST (and VITE_PORT, if you have an inertia frontend).

It’s time to launch Sail

Run:
./vendor/bin/sail up -d. OR
sail up -d, if you already created the alias for sail. The -d flag runs containers in the background and frees up your terminal shell.

At this point, the above command should run successfully.

If you cloned a repo your .env file won’t have an app key value. If this is true for you, run this command while Sail is running: sail artisan key:generate.

Now, run migrations: sail artisan migrate.

If you’re using Inertia, this is where you want to start the frontend application: sail composer run dev.

Congrats, now you can happily code to your programmer hearts content. Go build, but don’t forget to ship!

Getting My First Users From Building Something Unexpected

Patricio Salazar — Tue, 17 Dec 2024 07:38:23 +0000

This one has to start with the story. I’ll try to keep it short.

A Random Memory

When I was younger, say in my teens, I would do this thing in my head where I would double numbers. Sometimes random numbers, but most of the time from the number 2. So for example, 2, 4, 8, 16, etc. And I put a mental timer on it, so my goal was to see how fast I could do it without thinking much and see how far I could take it.

Side-note: I don’t know why I did that. I was never big on math. It was like a mental fidget during random in-between moments.

I had absolutely forgotten that I did that. Three months ago, I suddenly remembered while I was having lunch with my wife. I asked if she’d ever done anything like that, and yup, you guessed it—she hadn’t. Now, I’ve never been interested in building a web game, but one of the next thoughts I had was “I have to build this thing”.

Okay stop. Story over. There you have it, that’s the unexpected thing. I built a web game. BUT, please don’t leave just yet. I also want to tell you about what happened after I built the game.

Building and Sharing

Building the game took me about a couple days, it was done in a weekend (this post isn’t about the code, so I won’t get into that). I didn’t focus on making it look fancy or anything like that. I made it for myself, as an ode to the memory of an old mental fidget. I did however, know I would take a chance on sharing it. After all, if people like it, they’ll like it for the experience, not a shiny UI. By the way, it’s called Doubles.

Enter Reddit. I went looking for the right subreddits and ended up posting in these:

r/math
r/gamedev
r/IndieDev
r/learnmath
r/WebGames
r/IndieGaming

Sharing on Reddit taught me that the right audience will amplify visibility.

Right away, and to my complete surprise, strangers on the internet loved it. I got responses like this:

🤯🤯🤯 As the title of this post suggests, these are my first-ever users. A.K.A. you’re watching me create my first public side project, learn how to get and interact with users, and iterate on a project based on those interactions.

I have to say, getting users on something you built, and having positive feedback has to be one of the best feelings ever. Not in an ego way, in a purely shocking way. It’s gotta be the “indie dev’s” version of a musician’s first time hearing themselves on the radio. Alright, chill—I’m dating myself 🤣.

The first few days my Cloudflare analytics showed somewhere around 200—300 users had visited the site. That was incredible already. Then, days after not having posted anything, I checked the analytics and there was a spike of 1K+ visitors overnight! Whaat?? Excuse mee?! I started investigating.

It turns out they were all referred by B3ta.com. A UK based newsletter. I’m not sure how long they’ve been around, but they claim it “currently has nearly 80,000 subscribers”. Someone on their team must have seen my game, liked it enough, and shared it to their subscriber base. They also share a version of their newsletter on their website, and guess what? I FOUND IT. Here’s what they shared:

Hahaha. Good by me.

Fast forwarding a bit, I saw traffic from them trickle in for a long time. Nothing as big as the first couple days after they shared, but it was amazing enough. I’ll never forget that.

Since then, I still haven’t shared anything new, but I saw Doubles get picked up by another couple sites. One was this guy’s website. Shoutout to him. I saw a small amount come from there, but he never had to do that in the first place. Another is a site called CloudHiker. I see a couple visitors from that site every day. I’m not sure how it ended up there.

Traction continued for a couple months every single day all on its own. I saw anywhere from 20-80 regular users a day. I know because they were navigating directly to the site, not from any referrer.

Monetization

Nothing to report here, lol!

I tried to figure out a way, but this kind of site is not easy to monetize. And as far as ads go, no worthwhile ad service wants to serve ads on my little game website. Oh well. This is something I will consider more deeply ahead of future projects, but not everything needs to make money.

How’s It Doing Today?

Truthfully, it’s died down hahaha. I never talked about it again, and obviously I think that was a mistake, but you can consider this the start of me talking about it again. You can still play it here Doubles.

Here’s what I learned:

Picking the right project matters.
As a solo creator, I can make decisions, build, iterate, fail, and learn fast.
Caring about user feedback was highly valuable. Talking to the users and responding to them as soon as I implemented a feature request or bug fix is major and made them feel closer to the project. For example, after working with one of my users requests, he replied like this: “Love to see a dev actively responding and excited for feedback :)”
You spent time and effort building something, you should do the same for communicating and marketing it.
Some users will give you the best ideas to make your project better. Build relationships with them.

There you have it. That’s my story of getting my very first users from a game.

Thanks for sticking around until the end.

If you enjoyed this content, stay tuned for more updates on the projects I build, along with more stories and lessons, by subscribing below (no spam). And if you haven't already, click on one of the emoji’s on this page!

Until next time!

How I Added CSV Importing In My React-Node.js Project

Patricio Salazar — Wed, 11 Dec 2024 21:20:36 +0000

Touch Base was fine. It was a cool project. It worked. But, let's face it—was it usable? (Touch Base is a full stack React contact management app that I made).

I was thinking about this and realized something obvious. When a user starts using Touch Base they have to add contacts manually. Which might be fine if you have 5 contacts. If you have 1,000 contacts you want to add, this sucks… and you probably won't want to use this system. So of course, I knew I had to add the ability to import contacts.

Researching Options

My first Google search was “csv importers”, or something like that. I looked through some of the options available and found FlatFile. Their main heading read “The fastest way to collect, onboard and migrate data.” Perfect… except, it wasn't all that for me. Now, this is probably my fault (they seem like an amazing service) but the process of implementing their importer was taking more effort than I was willing to put in for this. This is the perfect time for a little sidebar context:

Lately, I've been really valuing scrappiness. I want to get things done, fast. This isn't about cutting corners, I just don't want to have any excuses or unnecessary delays. After all, I'm just one guy working on side projects. So my current attitude is fail, learn, and iterate fast. All while doing good work.

Back to FlatFile. As much as I wanted to use their promising software I asked myself if I really needed all their bells and whistles and if fighting their docs was worth it. Definitely not. So I went back to my search and landed on Papa Parse. I recalled seeing it in my previous search. Their main heading read “The powerful, in-browser CSV parser for big boys and girls.” 😆 I was in.

Implementation

First things first, I added a POST route to my API.

verifyToken is a function I use in all my routes that does exactly that—verifies the users id token. I use multer in my app which is a node.js middleware for handling file uploads. upload.single('file') is a multer function that helps me upload files to my s3 bucket.

Inside the route, I grab the user id and file through destructuring.

Like the npm package docs for Papa Parse state, “Papa Parse can parse a Readable Stream instead of a File when used in Node.js environments (in addition to plain strings).”

So I prepared to stream the file directly to Papa Parse by creating said stream from my s3 bucket as well as an empty array to hold the results data. Can't forget about handling potential errors.

Then I finally pass the stream to Papa Parse, set my config options and handle any errors coming from the results.

In the code above, complete is a Papa Parse property that takes a callback function. It executes once the parsing is complete. I then grab a hold of the data provided by results as parsedData.

After this, it's time to run some queries on the database and process the contacts. But, I need to store a connection the the db to run the queries on first.

This next part is a lot of code in a try catch statement, so I'll just give it to you straight with some comments on it.

As you can see, I

fetch existing contacts
filter out duplicate contacts using emails, since no two emails can be the same
bulk insert the non-duplicate contacts into the table

Frontend

The frontend will be largely specific to my approach of the app, but let's connect the dots here.

The Import Contacts page does one thing so it's very simple. I use the native file upload button which is really an input.

When the input detects a change I trigger a handleFileUpload function.

Inside of the handleFileUpload function, I first set the loading state to true so that I can display my little loading spinner to the user while this process takes place.

When a user successfully uploads their .csv file, I append it to a new formData object and send it to my backend route above to process it. I directly use a fetch request here since it's the only place in my app that's going to hit the /import-contacts endpoint. If another part of my app needed to hit the route, I would store the request using context and use that to avoid repeating code. Also, you can see the error handling I have set up…

Upon successful handling of the file or if it errors out, the loading state gets set back to false, and I trigger an appropriate toast alert to let the user know exactly what happened in a nice way.

It feels so nice to log in, upload a .csv file of contacts, get a successful toast alert, and then see all of the new contacts populated in your account. And it's so quick. You might see the loading spinner for just a second. The bulk insert query also helps a lot there.

From Maybe Usable to Usable

Before adding this feature I wondered how usable the app truly was. Now, there's no question about that. Although it wasn't super complex, it's a feature you would expect to see in this type of application so I found it a requirement to implement. I think it makes it a little more serious of a project. Aside from that, I've never done anything with .csv files which made this super fun to work on. Papa Parse integrated so well with all the tools I was already using which made it super easy. I definitely recommend using it.

If you made it this far, cheers to you for reading this 🥂...
and cheers to software that doesn't suck 🥂

p.s I'm still wondering if my project sucks 😂
If you want to check it out here's the link again.

Til next time!