Forem: Adele Beitvashahi

Choosing a video hosting provider for hobby projects

Adele Beitvashahi — Mon, 30 Mar 2026 02:06:36 +0000

Something embarrassing happened to me recently. I was at a networking event and I was excited to show someone my website and passion project Jamroom. As soon as I pulled them up, I remembered how long it'd been since I created these projects. The UI/UX I'd built a couple of years ago felt stale, and there were unpolished edges I never went back to.

So I spent last weekend to revamp the UI, rethink some of the UX, and I even finally recorded a demo for Jamroom¹ to showcase on my website!

A new challenge I was presented with then was where to host the demo video. In the past I'd always reach for the quick and dirty solutions like hosting on Vimeo, YouTube's unlisted videos, or GitHub even. This time I decided it was time for change, I wanted to host my assets on my own infra. To do this I came up with two requirements:
1) The solution needs to be free/dirt cheap
2) The setup can't take more than a few minutes, time is money!

Did some research and landed on Cloudflare R2, they offer a generous free tier. But mid-onboarding I realized in order to use the free tier, I'd have to either:
1) Switch my DNS provider to Cloudflare, having to migrate all my DNS records, which would absolutely take more than a few minutes.
2) Setup URL pre-signing on my backend to provide public access to the videos in my private bucket. Which would be unnecessary work for my needs at this time.

So I kept digging and voila! Enter Vercel Blob storage, their free tier offers free public access to your assets, albeit it's very limited. But it's good enough for now! There'll come a time when I'll have to finally setup the URL pre-signing to take advantage of the more generous free services out there, but till then I can invest my time in more pressing projects.

Here are my realistic options, optimizing for ease of setup/use and cost.

provider	cheapest tier	tier limits	public URL access
Backblaze B2	forever free	10GB storage, unlimited free egress, 1M writes + 10M reads/mo	Yes—public buckets support direct URLs , but cannot map custom domain without Cloudflare workaround
Supabase Storage	free forever	1GB file storage, 5GB bandwidth, 50K MAUs	Yes—public buckets provide direct asset URLs without auth
DigitalOcean Spaces	$5/month	250GB storage, 1TB outbound transfer	Yes—files can be set to public permissions with direct URLs
Vercel Blob	free (Hobby)	1GB storage, 10GB Blob Data Transfer/month	Yes—native public access with permanent URLs
AWS S3	free 12mo	5GB storage, 20K GET + 2K PUT requests/month, 100GB data transfer out	Yes via public bucket or presigned URLs

AI Resume Filters Can't Read Between the Lines

Adele Beitvashahi — Wed, 18 Mar 2026 21:33:29 +0000

Picture this:

A Resume bullet says: "built X system that served 1M+ users at "
A job description says: "implement metrics, logging, and dashboards."

The AI sees no overlap and disqualifies the candidate. But any engineer who shipped to a million users (heck anyone who has built anything for any business) has absolutely built observability infrastructure, they just didn't waste resume space saying so. Sometimes they handcrafted the dashboards, sometimes they used already present tooling like Mixpanel and other observability platforms with built in dashboarding capabilities. The point is businesses require observability period.

Observability is just one example. Testing, code review, documentation, incident response, none of it makes the resume because those are all implementation details of the role, the meat and the potatoes are the ✨results✨

Of course that's not to say those implementation details are unimportant, but time and place for everything, they're meant to be communicated verbally during the interview. That's what interviews are for.

Resumes are meant to showcase highlights of your career through story telling focused on impactful work, not serve as a laundry list of every single task you've done. That'd turn it into an unsustainably large alphabet soup. A soup so large even the AI systems ingesting it would lose their appetite.

Of course I don't believe we'll ever give up AI in recruiting or any other industry. The AI isn't the problem. The prompt behind it is, and that's on whoever built the filtering tool. A productive step may be to work towards more intelligent system prompts that do more than just keyword matching. That's what LLMs are for after all. Here's an example of a system prompt designed to infer implied skills from context clues. Things like treating "served 1M+ users" as an observability signal, or treating quantified improvements as evidence of instrumentation.

Disclaimer: this is illustrative, not a comprehensive solution.

You are a resume intelligence system. Your job is to evaluate a candidate's 
true qualifications by reading between the lines, not just scanning for keywords.

Experienced engineers don't list every task they performed. They tell a story 
of impact. Your job is to understand what that story implies.

When evaluating a resume against a job description, consider what the candidate 
almost certainly did but didn't write down. A system serving millions of users 
implies observability. Quantified improvements imply instrumentation. Enterprise 
experience implies process. Real-time features imply distributed systems thinking.
Startup experience implies ownership and autonomy.

Use context clues from company size, scale, tech stack, and career trajectory 
to infer unstated but implied competencies. Distinguish between a real skill gap 
and a resume brevity gap. Flag the latter for interview validation rather than 
automatic disqualification.

The best resumes are highlight reels, not task logs. They're narrative-driven 
stories of impact, not exhaustive records of everything someone has ever done. 
Don't penalize candidates for writing a good one.

How to use Filters in PrimeReact DataTables

Adele Beitvashahi — Mon, 09 Sep 2024 20:07:34 +0000

[UPDATE]: I've made a comprehensive demo on blitzstack which goes in depth on the different filtering scenarios that are neglected in the primereact docs. I'll update this article into a full writeup when I get the chance but for now that should serve all your filtering needs and then some! check it out

[EDIT]: insightful github discussion

I wrote a very long post then decided an image is worth a thousand words, so there you go.

Although the images uploaded to dev.to get downscaled so maybe this one is only worth 250 words.

The aim of this post was to reduce headaches induced by things unsaid in the official docs. There was a lack of resources online for using filters with MultiSelect and Dropdown components correctly with a more-than-basic data structure setup. So I'm using this post as a resource for future me and anyone else that might find this useful

If you look at the top left of that image there is a string[] that holds fruit names, that's because you can also use string[] instead of Object[] for the filter item list. I didn't expand on it because the official docs do a good enough job doing it.

I tried to cover things the docs failed to cover.

How to setup dev containers in windows

Adele Beitvashahi — Wed, 28 Aug 2024 02:41:52 +0000

If you are going to work with dev containers in Windows you need to realize that they will break HMR (hot module reload) and increase build time unless you put your code inside WSL instead of the windows filesystem.

How Dev Containers Work in Windows

Dev containers use Docker, which relies on WSL. When you spin up a dev container, VSCode starts a docker container in WSL, and mounts the files from windows (if they are stored there). This means changes have to cross the WSL-Windows environment. This tends to break HMR, because HMR relies on file change API of the host env, and the filesystem events don't travel well between different host environments.

Correct setup for dev containers in Windows

1. Dev container setup in WSL

Install Visual Studio Code
Enable WSL 2 by following the WSL 2 installation guide
Install Ubuntu (or your preferred Linux distribution) from the Microsoft store
Install Docker Desktop Stable 2.3.0.2
Finally enable Docker support in WSL 2 distros.
Follow all the directions here to finish setup.

2. Clone repo inside the WSL filesystem

Now you should be able to do yarn && yarn dev inside WSL and HMR should work.

Connect to Azure VM w/SSH Through Azure CLI

Adele Beitvashahi — Mon, 12 Aug 2024 20:24:51 +0000

1. Create your VM

2. Assign a public IP to the virtual network/subnet that the VM is under

3. Install azure cli & login:

az login

4. Install ssh extension for azure cli

az extension add --name ssh

5. SSH into vm

az ssh vm --private-key-file \path\to\private\key --resource-group <resource group name> --name <vm name> --local-user <local username (default: 'azureuser')>

FAQ

1. How to get vm/resource names

az vm list -d -o table

2. `az login` not working on Windows

az login --use-device-code

How to remove AI summary search feature on Google search

Adele Beitvashahi — Wed, 08 May 2024 21:52:37 +0000

You can't turn it off, use DuckDuckGo or another search engine that's independent of large companies.

How to persist client-side preferences on the client in Svelte (w/o DB)

Adele Beitvashahi — Sun, 21 Apr 2024 08:48:19 +0000

Context

I was in the middle of creating a static site with Svelte. Now of course you might say, why not just make it with plain HTML and CSS. To that I say, it's 2024 and you can go to jail for something like that.

Now, I'm a React developer by trade, but I chose Svelte for this project, because; 1) it ships less JS to the browser due to it not using a virtual DOM. 2) it's excellent for static site generation (SSG), which is what I needed for this project. and most importantly, 3) it was time I finally learned it and saw what the craze was about, I can't go a day without hearing about the amazing developer experience (dx) Svelte provides. And by golly was I in for a treat! Seriously everyone needs to learn Svelte.

Challenge

I needed to provide the website content in different locales, and I wanted to persist their preference across all time and space; all pages, routes, and sessions. This challenge is also applicable to website theming, and potentially any other user preference setting that isn't saved on serverside.

First step is setting and viewing the user preference.

Here's how:

// routes/+page.svelte
<script>
  // defaults to 'en';
  let locale = 'en';
</script>

<h1>Your preference of locale is set to {locale}</h1>
<button on:click={() => locale = "en"}>english</button>
<button on:click={() => locale = "es"}>spanish</button>
<button on:click={() => locale = "fr"}>french</button>

This is all good and well for a page, but if we wanna share it between pages.

Enter, Svelte +layout.svelte. If we move that code to the root layout, every descendant of that route (page.svelte and layout.svelte alike) will have that layout display without changing. If I navigate between routes as long as I don't move up above that layout, the preference will stay.

Now the next issue is accessing that preference from a different component/page. To do that we will need a store. Which is just an object with a subscribe function. Whatever subscribes to that store will update when the store updates.

Here's a brief review of how to create a store in Svelte.

// $lib/utils/stores.js
import { writable } from "svelte/store";
const defaultLocale = 'en';
export const locale = writable(defaultLocale);

The locale selector is located inside the navbar, which I want to be nearly global to this site so it will live in +layout.svelte
Here's how to use that store, in a dumbed down version of my use case.

// routes/+layout.svelte
<script>
  import { locale } from "$lib/utils/stores.js";
</script>

<h1>Your preference of locale is set to {$locale}</h1>
<button on:click={() => $locale = "en"}>english</button>
<button on:click={() => $locale = "es"}>spanish</button>
<button on:click={() => $locale = "fr"}>french</button>

Now the state of locale will persist across page/route navigations, but it will reset upon refresh and or closing and reopening the site.

So naturally we will want to persist the state somewhere tangible, and more enduring.
How about ✨local storage✨?
Let's do that, we can reuse the code from above and subscribe the localStorage to the store. So updates to store also update localStorage.

// $lib/utils/stores.js
import { browser } from "$app/environment";
import { writable } from "svelte/store";
const defaultLocale = 'en';
// retrieve localStorage value if it's been set already
// important for persisting through refreshes
// broswer check is needed because localstorage doesn't exist on server side
let storedLocale = browser && localStorage.getItem('locale') || defaultLocale;
export const locale = writable(storedLocale);
// subscribe to changes
locale.subscribe((val) => browser && localStorage.setItem('locale', val));

// routes/+layout.svelte
<script>
  import { locale } from "$lib/utils/stores.js";
</script>

<h1>Your preference of locale is set to {$locale}</h1>
<button on:click={() => $locale = "en"}>english</button>
<button on:click={() => $locale = "es"}>spanish</button>
<button on:click={() => $locale = "fr"}>french</button>

Here's what we've achieved so far:

✅ get & set a preference
✅ persist it through pages/routes
✅ persist through refreshes AND sessions (new tab/window)

But what's this?? there's a new problem. Everytime you reload the page, there's a layout shift, where the value of the preference will be set to its initial default before it fetches the stored localstorage value.

This happens because of server side rendering (SSR), which is an amazing amazing feature that's readily available to us today. It works by partially rendering the website on server side before sending it to the client, and then hydrating it with the rest of the javascript that's necessary for it to fully render, clientside JS basically. I won't go into details of why and how SSR is good, you know how to google.

The problem is that, our user preferences are stored in localstorage, which is only available on client side. The server that's performing SSR is unaware of this localstorage. So when it partially renders the page, localStorage.getItem() just returns undefined. So it will default to the fallback value of "en". Even though the users might have specified otherwise in their previous visit, and stored that preference in their localStorage. There are 2 ways to solve this:

We can add conditional rendering for any affected content on the site so that it doesn't render until our hydration is fully complete, but that will defeat the purpose of SSR.
We can use cookies 🍪 to store user preferences. Because unlike localStorage, cookies persist on user's system and the server will have access to them. Perfect!

P.S. we could also try and fetch localstorage value first thing in our lifecycle events like onMount, but that doesn't follow the Svelte way. It doesn't fully embrace SSR as we are interrupting the initial load with dataloading/fetching, which should be done on server side as much as possible. If we were in React land, then it'd be more acceptable.

To send and receive the preference cookies, we will need to setup a server js file for our layout that will handle the data fetching and initial data setting through Svelte's load function. That data is then loaded into our route, as defined in +layout.svelte.

For this, I'll move most of the store logic to +layout.svelte

// $lib/utils/stores.js
import { writable } from "svelte/store";
export const locale = writable();

// routes/+layout.server.js
import data from "$lib/data/en.json";
export function load({ cookies }) {
  let defaultLocale = 'en';
  data.preferences = { locale: cookies.get("locale") || defaultLocale };
  return data;
}

<script>
// routes/+layout.svelte
  import { locale } from "$lib/utils/stores.js";
  import { browser } from "$app/environment";
  import {setCookie} from "$lib/utils/cookies.js";
  export let data;
  // use the cookie value
  $locale = data.preferences.locale;
  if(browser){
    let storedLocale = localStorage.getItem("locale");
    // prefer localstorage value if cookie is unreliable for any reason.
    $locale = storedLocale || $locale;
  }
  // subscribe localstorage and cookies to the locale store
  $: {
    browser && localStorage.setItem("locale",$locale);
    // setCookie is a custom function I wrote for managing cookies easier, you can find it under this codeblock
    browser && setCookie("locale",$locale);
  }
</script>

<h1>Your preference of locale is set to {$locale}</h1>
<button on:click={() => $locale = "en"}>english</button>
<button on:click={() => $locale = "es"}>spanish</button>
<button on:click={() => $locale = "fr"}>french</button>

// $lib/utils/cookies.js
import { browser } from "$app/environment";

export function setCookie(name, value, path = "/") {
  if (!browser)
    throw new Error(
      "setCookie can only be used in the browser, make sure to check for browser object first"
    );
  const currentDate = new Date();
  const farFutureDate = new Date(
    currentDate.getTime() + 100 * 365 * 24 * 60 * 60 * 1000
  ); // 100 years from now
  const expires = farFutureDate.toUTCString();
  document.cookie = `${name}=${value}; expires=${expires}; path=${path}`;
}

At this point you might be wondering why do we need localstorage if we are going to use cookies. The answer is redundancy.

And there you have it! This was how to persist data on clientside and avoid layout shifts in SSR.

If you have any comments, questions, or concerns, please keep them to yourself.

All typos are on purpose.

Resources

Cover picture provided by unsplash