Brianna Rainey's Blog

The webapp running Rainey Arcade is called "Muffin Shop". It began as an ecommerce site for a local farm (which is still the primary focus). I made the shop part of the webapp into a separate "module" that is loaded by a JSON config file, with the idea being that I could reuse the "core" bits in future sites that may not be shops.

The shop module supports two payment processors: Stripe for real payments, and the "Arcade" payment processor that uses virtual arcade tokens. The shop module uses different Payment Adapters to convert the payment processors' interfaces into a standard that can be used by the shop module. The Arcade Payment Adapter simply redirects the user to the arcade module to complete the transaction, while the Stripe Payment Adapter mutates the cart data to match Stripe's API before redirecting the user off-site.

I'm working on a third instance of Muffin Shop now: one which will not use the shop module at all. It's an artist's portfolio, so the main module is going to be a gallery. There's an image-uploading system built into the core, which is used to upload images of products to the shop module. The gallery module will use the same uploading system and same image carousels as the shop module; it should be a very small module thanks to all the shared functionality.

This new instance will also have a newsfeed. The blog module I created for Rainey Arcade simply takes posts from JSON files which are generated by a cron job that checks my Mastodon. But I can easily add more routes to the blog module that would allow for manually adding and editing posts, and turn it into a simple newsfeed.

Although the artist's portfolio doesn't use the shop module, I think it shares enough functionality to make sense as an instance of "Muffin Shop". The config will disable a lot of stuff but that's fine. I want to make my artist friend a new website 🙂

I changed Jezzball and Rodent's Revenge so they once again function from the "example" html page (i.e., they don't have a hard dependency on the parent repo). This is mostly useful for development but a side effect is that you can play the game directly from the static assets with different CSS and no score-sending functionality:

My Nginx configuration disallows any path containing a hidden directory, so snooping around the static assets isn't going to be fruitful besides the unused HTML 🚫

Ordinarily `git pull` results in merging the latest commit from the remote origin into your local checked-out branch. However, when using submodules it works a bit differently.

`git pull --recurse-submodules` fetches the latest changes from the submodules' remote origins, but it doesn't change the submodule commits tracked by your local branch. To track the latest commits of each submodule, you can run `git submodule update --remote`.

The extra complexity of Git submodules made me ignore them for a long time. I still think they're likely to scare away potential contributors for an open-source project, so they're probably best avoided in that situation. But they can be very powerful if you need to patch a dependency for some reason; submodules allow you to keep up-to-date with the remote while easily maintaining your patches.

Personally I'm using submodules to combine my own repos, so I don't need to patch anything. For now I'm just trying to master the basics. It seems like every Git command needs to change when using submodules!

The server-side sessions on Rainey Arcade work like this:
- If you make an account, all your stuff (shopping cart, tokens, prizes) gets linked to that account.
- If you collect stuff while logged out, then log in, your tokens and prizes get added to the existing account. You maintain whichever shopping cart is full (newest cart wins if both are full).
- If multiple devices are logged into the same account, they end up linked to the session created by whatever account logged in last. So if a new device logs in, then every device will update its cookie to have the token generated by that new device.

Unfortunately the multiple devices end up being indistinguishable in this system since they all share a token, but it does seem to achieve the desired effect. I might keep improving it over time.

I've learned a lot about the Flask session interface. The documentation is here:

Why use server-side sessions? It began as an idea for tracking "cart abandonment" from anonymous users. This site is a gamified deployment of what's supposed to be real ecommerce software, and a business might be able to use that data in some way.

I think I'm finally getting the hang of making responsive designs using Bootstrap, even if they're not beautiful. They're functional and take a lot less time than any CSS I wrote in the past.

I used calc() to adjust the author image height (on these blog posts) based on the viewport width. I only recently learned to use things like calc(), var(), and viewport units in my CSS; they're awesome!

A user of this site is probably loading a lot of unnecessary CSS, so maybe I'll optimize that someday. I'm not bundling/minimizing very many assets yet, because I'm new to the world of JavaScript bundlers. I'd rather write code than configure build tools, so I'm procrastinating on becoming a Webpack expert 😅

older posts