Portfolio Project

This is the first project of the site. Itself.

Here’s what I’ve done so far.

Planning

I knew I needed a better portfolio of the types of projects I’ve done as I am notoriously bad at self-advocacy and overall remembering what I’ve accomplished. So, naturally, I made a project. Well, technically I refined my project management system and THEN made a project… but that’s a different article for another day.

Where to start?
For me, I started on pen and paper. I wrote out what I wanted out of the site and outlined what the architecture might look like. I slept on that and after a couple drafts, I settled into making the wireframes. From there I went to the computer to start the “doing” of making the site.

Some photos to show you what I mean.

[Insert images here]

Markdown File Problems

Well, it’s sort of inevitable isn’t it? Let me illuminate here what problems I faced and their ultimate solutions.

Problem:

Markdown frontmatter doesn’t parse with kramdown gem.

Possible solutions:

write my own parser
modify kramdown
use different gem
write a helper function to parse markdown
don’t use frontmatter for now

And our winner is… “don’t use frontmatter for now”!!!

Essentially, less is more here. I could do all the other things but frontmatter wasn’t benefiting the goals of the site at this stage, so I opted to shift focus towards a completed project sooner.

Coffee

I don’t have a problem. I can stop whenever I want.

Gaming

I don’t have a problem…

Security Sanity Check

We all know this is important. For this project, there’s not a lot of user interfacing but I still want to grow the skill and build a habit around the mindset.
So, the glaring issue I saw (with a little help from the brakeman tool) was file creation/deletion taking user input fields to generate filenames.

I haven’t been victim of injection, nor have I met anyone directly who has, but I know it’s a long standing problem with many solutions.
I decided to put the markdown filename in the database and generate it from the model upon project creation.

Testing…

First I tested manually to make sure these markdown files were being created and deleted in the proper directory with creation/destruction of a project.

Raging success!

Now, for unit testing so that if I somehow screw that function up later, I’ll know.
Unit testing always seems to cause me weird problems for otherwise perfectly functional features. Skill issues… I know.
In anycase, the problem here was 2 things, creation and deletion were needing the markdown filename, and my security refactor from earlier had the markdown filename being generated right before creationg. With an hour or so of fussing, I managed to solve it by duplicating the filename structure manually in my testing fixtures and giving it to the tests more explicitly.

Deployment!

Boy, where do I start. 5 days of cryptic error messages and configuration troubleshooting. My own fault of course as I insisted on hosting on my own hardware. I certainly paid the price of saving money on a VPS…
Deploy automation is amazing, AFTER the configuration is properly set up and working.

In spirit of what I’m trying to accomplish with this site, I won’t breakdown all the troubleshooting I had to go through. It was several days between everything after all.
I will, however, describe some of the technologies I was using and configuring seemingly endlessly.

Here is the breakdown:

ddns for the rotating IP
port forwarding to route to my server
ssh keys so that I wasn’t working with passwords
docker for containerization of my app
docker registry and associated access keys
kamal and it’s often cryptic logs
github actions workflows for CI/CD (and more deploy access keys)
puma server version was a problem

I try to maintain a healthy level of skepticism about my own skill set and self efficacy. This particular deployment was tough and I learned a lot of things that have been logged in the recesses of my intuition.

All to say, in the end you’re here looking at this, so I did something right.

Back to projects