Live presence on About

The About page has a thin layer of social presence. When someone visits it, small cursor markers appear on top of the layout, similar to what you would expect from tools like Figma or online whiteboards. They never block the text or scrolling, but they make it clear that you are not the only person exploring the page.

Technically, this is a room-based presence system that listens for cursor updates and keeps a shared list of active peers. Each client publishes throttled cursor events and subscribes to updates from others.

Synchronized signatures

On the Signature page, multiple people can sign at the same time. When a new stroke is added to the canvas on one screen, it appears on everyone else’s screens in real time — no reload, no manual refresh. For visitors, the page feels like a lightweight collaborative wall dedicated to signatures rather than a static gallery.

Under the hood, each signature has an id, a list of points, and some metadata that gets sent over a real-time channel and stored in a backing store. Clients subscribe to changes: when a signature is created or removed, the updated state is broadcast to all connected users.

Why add real-time to a portfolio

Real-time details in a portfolio solve two problems at once. On one hand, they add a bit of playfulness and energy, making the site feel less predictable and more alive. On the other, they work as proof of skills: handling WebSocket connections, presence, state sync and performance constraints.

Instead of spinning up a separate “real-time demo” project, the live layer is embedded directly into the foundation of the personal site. This way, a recruiter or team lead sees not just a list of technologies on a resume, but also how those technologies behave in a real interface — quietly, consistently and with just enough personality to spark the question: “So how does this actually work under the hood?”

The idea was to hide a glow color switcher behind the personal mark in the footer. A small Ⓓ button opens a minimal modal where the user picks one of several glow presets. The choice subtly adjusts accent highlights across the layout and persists between visits, so the site remembers the preferred glow.

Making the footer interactive

The footer is rendered on every page and shows a compact brand block with a mark, a title and a short tagline, followed by social links and the usual copyright line. The mark itself is not just decoration; it is a button that toggles the glow modal. This keeps the footer visually calm while still letting power users discover a bit of customization.

In JSX, the mark is just a button wired to a local showGlowModal state:

const [showGlowModal, setShowGlowModal] = useState(false)

<button
type="button"
className={styles.footer_mark}
onClick={() => setShowGlowModal(true)}

<span>Ⓓ</span>
</button>

When the modal is open, it presents a small list of glow options that depend on the current theme. In light mode, the palette offers deeper, charcoal‑style tones; in dark mode, it shifts to lighter, sand and stone‑like accents that stand out on a dark background. The options are defined as simple objects with a readable label and RGB values for both the glow and its swatch.

Wiring glow to the theme

The footer reads the current theme from next-themes and selects the appropriate set of glow presets. This allows the same interaction model to work in both light and dark modes without extra branching in the JSX. If the theme changes, the list of available glow colors updates automatically and stays in sync with the rest of the design system.

A small hook around useTheme keeps the options list in sync with the active theme:

const { theme } = useTheme()

const options = useMemo(() => {
  if (theme === 'light') return GLOW_OPTIONS_LIGHT
  return GLOW_OPTIONS_DARK
}, [theme])

Each glow preset is applied by updating a few CSS custom properties on the document.documentElement: a solid --glow-color, a softer --glow-soft, and a --glow-shadow used for shadows and highlights. Because these are just variables, existing components can consume them without knowing anything about the footer logic, and the accent can be reused in multiple places.

const applyGlow = (option: GlowOption) => {
const root = document.documentElement
	root.style.setProperty('--glow-color', rgba(${option.rgb}, 1))
	root.style.setProperty('--glow-soft', rgba(${option.rgb}, 0.35))
	root.style.setProperty('--glow-shadow', rgba(${option.rgb}, 0.3))
}

Remembering the user's choice

To avoid resetting the glow on every page load, the footer stores the selected preset key in localStorage. On mount, an effect reads glow-color, matches it against the current preset list and applies the corresponding values; if nothing is saved yet, the first option in the list becomes the default. This means the glow feels like part of the user’s personal setup rather than a one‑off toggle.

useEffect(() => {
  if (typeof window === 'undefined') return

  const saved = window.localStorage.getItem('glow-color')
  const currentOptions = options

  let option = saved ? currentOptions.find(o => o.value === saved) : undefined

  if (!option) {
    option = currentOptions
  }

  applyGlow(option)
}, [options])

Switching between presets is handled by a single helper. It looks up the option by value, updates the CSS variables, writes the new value to localStorage and closes the modal. The rest of the layout automatically reacts to the variable change, so there is no need to rerender large parts of the tree.

const setGlow = (value: string) => {
  if (typeof document === 'undefined') return

  const option = options.find(o => o.value === value)
  if (!option) return

  applyGlow(option)
  window.localStorage.setItem('glow-color', value)
  setShowGlowModal(false)
}

Hinting that the footer is adjustable

Because the control is intentionally subtle, the footer gives a small hint that the mark is interactive. A short line under the brand block can invite exploration, for example: “Tap the Ⓓ mark to adjust the glow.” This keeps the microcopy light and optional while still guiding users who are curious about personalization.

The mark itself can also have a very gentle pulse or halo on the first visit to suggest that it does something, then settle into a static state afterwards. Paired together, a one‑line hint and a soft motion cue make the footer feel like a quiet, discoverable playground for fine‑tuning the site’s atmosphere instead of just a static block at the bottom of the page.

The new footer sits on a dark background, aligned to the same content width and separated by a thin border line. Inside, it is split into two simple blocks: brand on the left, external links on the right. This keeps the structure clean and avoids the usual overloaded multi‑column footer pattern.

The brand block is a small badge with the Ⓓ mark, the Devollox name, and a short tagline. The badge has a subtle outline and a soft glow, which adds a neon‑like accent without turning the footer into a light show. In light and dark themes it keeps the same shape, but adjusts glow and text contrast so it feels at home in both.

On the right there is a row of text links: Steam, GitHub, Stack Overflow, and Reddit. They are styled as calm, lowercase text instead of buttons: secondary color, gentle hover state with a tiny lift. That way the footer stays light, and those external profiles feel like part of the personal brand rather than a block of social icons.

On the home page the footer uses a slightly different, lighter shade of dark, which creates a soft “platform” at the end of the layout instead of a hard cut to black. In the end, the bottom of the site is no longer just boilerplate — it behaves like a quiet, persistent signature that closes every page with the same voice.

Instead of a classic guestbook with text inputs, I decided to let people draw their actual signatures. The page uses next-auth to identify the current user and Firebase to store every signature as a base64-encoded PNG together with the author name and timestamp.

The main Signature page loads all signatures from Firebase, sorts them by timestamp and shows them in small cards. The list is paginated: first 10 entries are visible, and a “Show More” button loads the next batch without reloading the page. Each user can have only one signature: if you are signed in and your name is already in the list, the “Create Signature” button is hidden.

The drawing happens on a <canvas> element. Mouse events (mousedown, mousemove, mouseup) are used to track the stroke and draw smooth lines with round caps and joins. Every finished stroke is saved into an in‑memory history array as a data URL, which makes it possible to implement a simple Ctrl+Z undo by restoring the previous canvas state.

When the user clicks “Accept Signature”, the canvas is converted to a PNG data URL, stripped to a base64 string and saved to Firebase together with the user name and current ISO timestamp. On the frontend, the new signature is immediately added to the top of the list, so the user sees the result without waiting for a full reload.

Each signature card renders the stored image via a data:image/png;base64,... source and shows the author’s name with a formatted date. If the current user is the owner of the signature, a small trash icon appears; clicking it calls a Firebase helper that deletes the record by name and updates the local list.

To smooth out the loading state, the page shows a couple of skeleton cards while the initial request to Firebase is in progress. This keeps the layout stable and visually explains that the content is being fetched instead of leaving an empty page.

In the end, this page turned a simple portfolio into a place where visitors can literally leave their mark. It mixes authentication, realtime-like updates and a small drawing tool into something that feels personal and a bit nostalgic.

The idea was to draw Conway’s Game of Life in the background, full‑screen, behind the usual 404 text. The content stays simple and readable, but the page slowly moves under it, like a quiet simulation that never fully repeats.

Attaching the canvas to the page

The Game of Life runs inside a React component that only works with the DOM in a useEffect. It creates a <canvas> element on mount, attaches it to a root container and stretches it to the full viewport.

import { useEffect } from 'react'

export function GameOfLife() {
  useEffect(() => {
    const root = document.getElementById('Canvas')
    if (!root) return

    const canvas = document.createElement('canvas')
    const ctx = canvas.getContext('2d')
    if (!ctx) return

    canvas.width = window.innerWidth
    canvas.height = window.innerHeight
    canvas.style.position = 'fixed'
    canvas.style.top = '0'
    canvas.style.left = '0'
    canvas.style.border = 'none'
    canvas.style.zIndex = '0'

    const bg =
      getComputedStyle(document.documentElement).getPropertyValue(
        '--background'
      ) || '#000'

    canvas.style.backgroundColor = bg.trim()

    // ...
  }, [])

  return null
}

The background color is read from a CSS variable (--background), so the 404 page automatically follows the current theme without extra props or config.

On the 404 page itself, the only requirement is to render a container with id="Canvas" and include <GameOfLife /> once.

const NotFoundPage = () => {
  return (
    <Page title="404" description="Page not found.">
      <div id="Canvas" />
      <ContentBlock />
      <GameOfLife />
    </Page>
  )
}

The text and links are rendered above the canvas using normal layout and a higher z‑index, so the background stays purely decorative.

Implementing Conway's Game of Life

The simulation follows the classic rules of Conway’s Game of Life: a grid of cells, each either alive or dead, evolving based on the number of alive neighbours. The grid is mapped to the canvas as small rectangles.

const cellSize = 10
const widthCells = Math.ceil(canvas.width / cellSize)
const heightCells = Math.ceil(canvas.height / cellSize)

let firstGeneration: number[][] = Array.from({ length: widthCells }, () =>
  Array.from({ length: heightCells }, () => (Math.random() * 100 > 80 ? 1 : 0))
)

const getCellValue = (x: number, y: number) => {
  if (x < 0) x = widthCells - 1
  if (x >= widthCells) x = 0
  if (y < 0) y = heightCells - 1
  if (y >= heightCells) y = 0
  return firstGeneration[x][y]
}

The grid wraps around the edges: if the cell index goes out of bounds, it continues from the opposite side. This creates a seamless, toroidal world without hard borders.

The next generation is computed on a fixed interval. Each cell counts its eight neighbours; new cells are born when they have exactly three neighbours, and live cells die from overpopulation or isolation.

const createNewGeneration = () => {
  ctx.clearRect(0, 0, canvas.width, canvas.height)
  const newGeneration: number[][] = Array.from({ length: widthCells }, () =>
    Array(heightCells).fill(0)
  )

  for (let x = 0; x < widthCells; x++) {
    for (let y = 0; y < heightCells; y++) {
      const lifePower =
        getCellValue(x - 1, y - 1) +
        getCellValue(x - 1, y) +
        getCellValue(x - 1, y + 1) +
        getCellValue(x, y - 1) +
        getCellValue(x, y + 1) +
        getCellValue(x + 1, y - 1) +
        getCellValue(x + 1, y) +
        getCellValue(x + 1, y + 1)

      if (firstGeneration[x][y] === 0 && lifePower === 3) {
        newGeneration[x][y] = 1
      } else if (
        firstGeneration[x][y] === 1 &&
        (lifePower > 3 || lifePower < 2)
      ) {
        newGeneration[x][y] = 0
      } else {
        newGeneration[x][y] = firstGeneration[x][y]
      }

      if (newGeneration[x][y]) {
        ctx.fillStyle = '#99999937'
        ctx.fillRect(x * cellSize, y * cellSize, cellSize, cellSize)
      }
    }
  }

  firstGeneration = newGeneration
}

The fill color is semi‑transparent, which keeps the overall look subtle and prevents the background from overpowering the text on top.

To avoid the grid falling into a boring stable state forever, the platform is periodically refreshed with a new random seed.

const refreshPlatform = () => {
  for (let i = 0; i < widthCells; i++) {
    for (let j = 0; j < heightCells; j++) {
      firstGeneration[i][j] = Math.random() * 100 > 80 ? 1 : 0
    }
  }
}

Running and cleaning up the simulation

Two intervals are started when the component mounts: one to step the simulation, another to refresh the grid from time to time.

root.appendChild(canvas)

const intervalId = setInterval(createNewGeneration, 100)
const refreshId = setInterval(refreshPlatform, 60000 * 30)

return () => {
  clearInterval(intervalId)
  clearInterval(refreshId)
  if (canvas.parentNode) {
    canvas.parentNode.removeChild(canvas)
  }
}

This keeps the Game of Life running smoothly while the user is on the page and ensures that everything is properly cleaned up when navigating away: no orphaned canvas, no leaking intervals.

In the end, the 404 page became a quiet nod to cellular automata: even when the route is wrong, the background is still doing something interesting.

The idea is straightforward: take the final string, replace all characters with random ones from a small alphabet and then gradually reveal the real text from left to right. It creates a short “decoding” animation every time the element mounts.

The encoding hook

The whole effect lives in a small React hook that targets an element by id and updates its text content on an interval.

import { useEffect } from 'react'

const useEncoding = (id: string | number, speed: number) => {
  useEffect(() => {
    const targetText = document.getElementById(String(id))
    if (!targetText) return

    const targetString = targetText.textContent || ''
    const alphabet = ' abcdefghijklmnopqrstuvwxyz'

    const getRandomChar = () =>
      alphabet[Math.floor(Math.random() * alphabet.length)]

    let currentString = Array(targetString.length).fill('')
    let index = 0

    const intervalId = setInterval(() => {
      for (let i = 0; i < currentString.length; i++) {
        if (i < index) {
          currentString[i] = targetString[i]
        } else {
          currentString[i] = getRandomChar()
        }
      }

      targetText.textContent = currentString.join('')

      if (index >= targetString.length) {
        clearInterval(intervalId)
      } else {
        index++
      }
    }, speed)

    return () => clearInterval(intervalId)
  }, [id, speed])
}

export default useEncoding

The alphabet can be tuned for different vibes: only letters for a softer look, symbols or numbers for something closer to a “terminal” feeling.

Using the effect on headings

On the page side, the hook is attached to any element by giving it a stable id. As soon as the component mounts, the text starts “encoding” and then resolves to the final value.

const EncodedTitle = () => {
  const id = 'computer-heading'

  useEncoding(id, 40)

  return <h1 id={id}>Computer</h1>
}

The same pattern can be reused for section titles, hero slogans or small labels. A lower speed value makes the animation faster, a higher one slows it down and makes each step more visible.

Where it is used on the site

This hook is wired into several headings and labels across the site, mostly on pages that are already about hardware and tools. It adds a small layer of motion to an otherwise static layout and keeps the interaction subtle enough to not distract from the content.

The next step for this effect is to make it run asynchronously and maybe trigger on scroll or hover instead of only on mount. But even in this simple version it already does exactly what it should: gives the site a tiny bit of that “encoding” feel without getting in the way.