DEV Community: Marc Qualie

Vite + React Quickstart

Marc Qualie — Mon, 24 Feb 2025 11:00:00 +0000

I've been setting up a lot of quick experiments and prototypes lately to prove concepts. For these kind of apps I don't need a full stack like NextJS, but I also want to be able to use React + TypeScript for various reasons such as component testing or debugging. The aim is also to avoid hosted solutions like Code Sandbox or Stackblitz so I can use the code offline and also pull in local packages that aren't public.

It's surprisingly simple to get a working react app locally now with Vite and a few lines of html/jsx. I like this approach because it's a "close to the metal" as possible with react avoids complex build steps.

It's worth noting this is in-fact raw react and isn't designed for production use. Many layers will be needed on top for things like routing, SSR, hot reloading, etc but I don't need any of those for my quick throw away tests.

Dependencies

yarn add react react-dom
yarn add -D @types/react @types/react-dom vite

Yes, I'm still using yarn since my primary work toolchain is based around it but you can replace yarn with pnpm or npm to get the same result.

Files

index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>React + Vite Prototype</title>
  <script src="/app.tsx" type="module"> </script>
</head>
<body>

</body>
</html>

app.tsx

import React, { type FC, StrictMode } from 'react'
import { createRoot } from 'react-dom/client'

export const App: FC = () => {
  return (
    <div>Hello, world!</div>
  )
}

document.addEventListener('DOMContentLoaded', () => {
  createRoot(document.body).render(
    <StrictMode>
      <App />
    </StrictMode>,
  )
})

Running

vite dev

You can now access the app on http://localhost:5173 (default port). You should see "Hello, world!" in your browser if everything worked.

Conclusion

This is mainly here for my own reference so I can quickly copy + paste this when setting up a new experiment. The goal is to have as basic of a setup as possible to avoid conflicts with any dependencies then replicate the behaviour from the experiment into other projects.

Disable PS5 Controller button on MacOS

Marc Qualie — Sun, 26 Jan 2025 23:28:57 +0000

I often use my PS5 controller on my Mac Studio with PS Remote Play to quickly login and check something or pick up a time-bound item without having to leave my work desk. This is great until you press the PS button and it opens the app switch menu, losing focus on the PS remote play window. To disable the PlayStation controller button default behaviour on MacOS, run the following command in the terminal:

defaults write com.apple.GameController bluetoothPrefsMenuLongPressAction -integer 0

If you want to revert this for some reason, you can set the value to 1 instead.

defaults write com.apple.GameController bluetoothPrefsMenuLongPressAction -integer 1

Based on the name I'm assuming this works with (and is designed for) to Xbox controller since you usually long press that button to trigger menus.

From my searching, this used ot be available in the System Preferences, but it seems to have been removed in recent versions of macOS. The above was last verified to work for me on MacOS Sonoma 14.3.

I hope this saves someone some pain.

Upgrading legacy Terraform providers

Marc Qualie — Thu, 27 May 2021 00:00:00 +0000

I recenty worked on some pretty old Terraform projects (built using v0.10.x I believe). The state on these projects is no longer compatible with v0.13+, which causes errors when trying to run any command. Quite frustrating and the docs don't seem to help much.

Apart from manually downgrading to 0.13, running terraform 0.13upgrade, then upgrading to the latest version, there didn't seem to be any documented solution.

You will likely have some kind of error, similar to the following:

Error: Invalid legacy provider address

This configuration or its associated state refers to the unqualified provider "aws"

You must complete the Terraform 0.13 upgrade process before upgrading to later

If you've already upgraded past terraform 0.13 (likely if you're reading this), then you'll instead need to replace the state values directly. This can be done with the following command:

terraform state replace-provider registry.terraform.io/-/aws hashicorp/aws
terraform state replace-provider registry.terraform.io/-/github hashicorp/aws

Related to this, the Github provider moved from hashicorp namespace to integrations/github. You will need to update your existing state with this new reference. An error message you see may look something like the following:

Warning: Additional provider information from registry

The remote registry returned warnings for registry.terraform.io/hashicorp/github:
For users on Terraform 0.13 or greater, this provider has moved to integrations/github. Please update your source in required_providers.

You can resolve this with the following config:

terraform {
  required_providers {
    github = {
      source  = "integrations/github"
      version = "~> 4.10"
    }
  }
}

Once you've made that change, run the following to sync it to your state:

terraform state replace-provider hashicorp/github integrations/github

Now you can run terraform init which should show green, and that it is using integrations/github.

My current output shows the following:

terraform -version
Terraform v0.15.4
on darwin_amd64
+ provider registry.terraform.io/integrations/github v4.10.1

Testing Rails 6 Zeitwerk Autoloading

Marc Qualie — Mon, 25 Jan 2021 14:17:50 +0000

Rails 6 introduced a new autoloader called Zeitwerk. While it has many many improvements, one of the main changes is how strict it is with filenames and the constants they define. Unless you have full coverage on your application (few apps actually reach 100%) it can be quite easy to end up with an app that won't boot in your staging/production environment.

This is a welcome change from me, I believe it leads to much more stable and predictable codebases when the filenames and constants match 1:1. This can become an issue for anyone used to working with the rails classic autoloader since that allowed developers to get away with mostly anything inside their files.

Adding the following spec to any new rails 6+ project will protect from such problems, as the autoloading will be triggered in the CI environment instead; before merge and deploy. This is also perfect if you're upgrading any older Rails 5 apps and you're nervous about switching to the new autoloader.

# spec/zeitwerk_spec.rb
require 'rails_helper'

describe 'Zeitwerk' do
  it 'eager loads all files' do
    expect do
      Zeitwerk::Loader.eager_load_all
    end.to_not raise_error
  end
end

Original reference post for code snippet Rails 6 and Rspec : How to test Zeitwerk mode by Matthieu Varagnat

You can take this a step further on CI and have a dedicated job that runs specifically to check the autoloading. This can be dne before the tests (to avoid wasted minutes), or in parallel to highlight an autoloading issues in your PR status checks.

The following line can run in any shell to perform the same job as the rspec snippet above:

rails r 'Zeitwerk::Loader.eager_load_all'

Here is an example of my CircleCI flow for a recently upgraded rails project. Notice how Zeitwerk failure prevented a ton of other jobs triggering, which would have used quite a lot of resources and failed much later.

This, of course, does not replace the need for an extensive test suite, but it can save you in the early days of prototype development where a typo or unused class can slip into the codebase when working at a fast pace.

IAM Policy for humans

Marc Qualie — Tue, 26 May 2020 19:25:49 +0000

Configuring IAM is essential for any AWS account. The most common use case is granting access to EC2 instances, or allowing web apps to read/write to S3. While it's not recommended to make any direct changes in the AWS console, it's sometimes helpful to allow humans to browse around and view configurations.

To simplify management of these user accounts, it's helpful to allow individuals to manage their own credentials and configure things like MFA devices. Below is the policy I created as a drop in starting point for allowing any human users to login to the console. Note, this does not grant any access to any resources inside AWS, only for a user to manage their own password, access keys and MFA devices. Permissions for resources still need to be added otherwise the console will be a very boring place.

The easist way to apply this policy to all humans is to create an IAM group called humans. Whenever you wish to allow a user to login the AWS console and manage their own account, simply add them to the humans group.

Allow viewing of account status

Users need to be able to see what their account settings currently are.

{
  "Sid": "AllowViewAccountInfo",
  "Effect": "Allow",
  "Action": [
    "iam:GetAccountPasswordPolicy",
    "iam:GetAccountSummary",
    "iam:GetUser",
    "iam:ListVirtualMFADevices"
  ],
  "Resource": "*"
}

Change Password

A user should be allowed to change their own password without contacting their administrator.

{
  "Sid": "AllowManageOwnPasswords",
  "Effect": "Allow",
  "Action": [
    "iam:ChangePassword"
  ],
  "Resource": "arn:aws:iam::*:user/${aws:username}"
}

Access Key Management

If users want to interact with the AWS APIs, they'll need to generate access keys that inherit their policy permissions.

{
  "Sid": "AllowManageOwnAccessKeys",
  "Effect": "Allow",
  "Action": [
    "iam:CreateAccessKey",
    "iam:DeleteAccessKey",
    "iam:GetAccessKeyLastUsed",
    "iam:ListAccessKeys",
    "iam:UpdateAccessKey"
  ],
  "Resource": "arn:aws:iam::*:user/${aws:username}"
}

Manage MFA

Using MFA (Multi-Factor Authentication) is highly encouraged, so all users should be able to manage their own virtual MFA devices.

{
  "Sid": "AllowManageOwnUserMFA",
  "Effect": "Allow",
  "Action": [
    "iam:DeactivateMFADevice",
    "iam:EnableMFADevice",
    "iam:GetUser",
    "iam:ListMFADevices",
    "iam:ResyncMFADevice"
  ],
  "Resource": "arn:aws:iam::*:user/${aws:username}"
}

Full Policy

The full policy combined is dsiplayed below in full.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:GetAccountSummary",
        "iam:GetUser",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnPasswords",
      "Effect": "Allow",
      "Action": [
        "iam:ChangePassword"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "AllowManageOwnAccessKeys",
      "Effect": "Allow",
      "Action": [
        "iam:CreateAccessKey",
        "iam:DeleteAccessKey",
        "iam:GetAccessKeyLastUsed",
        "iam:ListAccessKeys",
        "iam:UpdateAccessKey"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "AllowManageOwnUserMFA",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    }
  ]
}