dot designers preview

contact-preview

dot welcome preview

1969-preview

mobile-preview

cambodia-preview

mobile-studio-preview

irregulars-preview

mouse-login

graph-preview

banner-preview

gwendolyn-preview

self-care-preview

sheet-preview

pop-preview-cover

characters-preview

DOT Banner

therapist-cover

us-preview

card-preview

Earlier this year, My friends and I wanted to play a role-playing game called Through the Breach. These types of games are typically played in person, but due to Global Events Beyond Our Control, we needed to play this game on Discord. Though there are several discord bots that we could have used for dice rolls, there was an unfortunate lack of bots that would simulate decks of cards -- which this game requires.

So that we could play, I created [Lucius Bot](https://luciusbot.com/),which models a deck of cards and the various things you need to be able to do with it during play. 

A requirement of the bot was that it needed to be able to shuffle to deck. I didn't think too much about it, wrote something similar to the following function, and called it a day:

      const shuffle = (array) =>{

      newArray = array

      //we're going to loop an arbitrary amount of times.
      for (let i = 0; i < 1000; i++) {

      //random select a card from the deck
      let randomLocation = Math.floor(Math.random() * newArray.length)

      //then we'll swap that random card with the first card of the deck.
      let temp = newArray[0]

      newArray[0] = newArray[randomLocation]

      newArray[randomLocation] = temp
      }
      //viola! 
      return array
      }

Since the game is meant to be cooperative and the deck was small, I wasn't too worried that we were always picking the first index or that there was a chance portions of the deck weren't going to be shuffled. It was meant to simulate a physical deck of cards, and we weren't very good at physically shuffling either. It may have concerned me that we needed to iterate an arbitrarily large amount of times for a relative small array, and that this solution wouldn't be applicable to larger arrays, but it worked for our purposes.

However, I recently had the chance to take another look at shuffling algorithms, and discovered that the problem of shuffling an array in a way that is *efficient* and *unbiased* has been solved for years.

__The Fisher-Yates Algorithm:__

The problem with baby's first shuffle is that it is confoundingly inefficient (how many times would I need loop if the array were 5400 elements large instead of 54? I'm not sure, but a lot) and could end up not shuffling the deck at all. The [Fisher-Yates](https://bost.ocks.org/mike/shuffle/) shuffling algorithm solves both of these issues. For any array, we know that the complexity is O(n) and that any result is equally likely.

the (modern) algorithm goes like this:
> To implement the in-place O(n) shuffle, then, pick a random remaining element (from the
> front) and place in its new location (in the back). The unshuffled element in the back is
> swapped to the front, where it waits for subsequent shuffling.

This is the implementation from the above link. I broke it down for myself:

    function shuffle(array) {
        //initialize 3 variables: 
        //m = array length
        //i = random index
        //t = temporary holder.
        //not sure why they don't use more descriptive variable names.

    var m = array.length, t, i;

    // While there remain elements to shuffle…
    while (m) {

      // Pick a remaining element…
      //you're also decrementing the m variable 
      //so next time around the numbers you can pick from are less.
      i = Math.floor(Math.random() * m--);

      // And swap it with the current element.
      //temporary holder holds value of last element (index m)
      t = array[m];
      //last element holds value of element at index i
      array[m] = array[i];
      //element at index i holds temp
      array[i] = t;
    }

    //return array that's been shuffled in-place.
    return array;
    }

__One more time for my benefit:__

we have an array.
we store the value of its original length, which we use as a counter for a while loop.
I ended up just using a for loop.
from there, we choose a random element from 0 to the current index
swap it with the current index.

    const shuffle = (array) =>{

    const newArray = array

    for(let i = newArray.length-1; i > 0; i--){

        let temp = newArray[i]
        let randomLocation = Math.floor(Math.random() * i+1)

        newArray[i] = newArray[randomLocation]
        newArray[randomLocation] = temp

    }

    return newArray

    }

So now instead of a function that loops for an amount that may simultaneously be too large and too small, we have a function that is readily measurable, efficient, and unbiased. Neat!

Shuffling a "Deck of Cards" With Javascript

As part of an ongoing project to develop a grid map annotation app for [TTRPGs](https://en.wikipedia.org/wiki/Tabletop_role-playing_game "TTRPGs"), I've been thinking about hexes.

Because I've been working with SVGs, my initial thought for creating a hexagonal grid map was to create it in Adobe Illustrator, then just copy the resulting svg file to the website. This worked out fine, and I was able to work on my illustrator workflow. The issue came when I needed to make changes to the map (like, any time I wanted to annotate something). Because this was something that was going to happen a lot, I did some more research into SVGs in general, and realized something that gave me hope: __SVGs are just math__. They're represented by numbers that dictate where a line starts and stops, and whether there's a curve to it. Hexagons are even simpler, because there aren't any curves. This meant that instead of painstakingly drawing, spacing, and annotating hexes for a hex map, I could have something else do it for me instead.

After a bit more research into the math behind hexagons, My first attempt looked like [this:](https://codepen.io/Alphaandsew/pen/BaQGKMq?editors=1111 "codepen link"), but the basic summary is:

If we center the SVG using its viewbox, we can calculate the location of a hexagon's points using only 2 starting coordinates to dictate its center, which we call <code>q</code> and <code>r</code>. We do this by entering a <code>size</code> variable and then using a bit of [geometry](http://xgeometry.com/formulas/hexagon "hexagon formula") to figure out the length and width of the shape of the hexagon and the corresponding coordinates of the its points.

the code follows these basic steps:
1. create an svg polygon shape.
3. from size, q, and r, use *math* (you can see the formulas I used in the codepen) to get a hexagon's six points.
4. use *math* to translate the hexagon to its proper location on the svg element. the formulas I used for these are below:

```
 hexagonX = q * width * .75

 hexagonY = (r * Math.sqrt(3)*size) + (q*height/2)

```

There is a step after the polygon is created where you add the attributes you need, as well.

This is a rough draft, so look forward to a more polished (and interactive) version coming up.


SVG Hexagons: They're Just Math

After working with React.js, Next.js seemed like the appropriate progression. There are immediate and obvious positives to using React.js, like its file-based routing system and server-side fetching and dynamic page creation (yay for easier SEO!). At first, I thought Next.js' <code>Image</code> component would be another no-brainer, and some of its features are definitely an improvement.

Images are automatically optimized as users request them, and they are lazy-loaded by default without any effort on your part. If you need the image to load quickly (for banners or cover images, for example), a quick <code>priority={true}</code> will tell the browser what it needs to know in order to preload the image.

Images require a specific height and width, however, which is odd. You can get around this by using <code>layout ="fill"</code>, but that causes other issues (which is why I'm writing this). Next.js wraps a weird div around its image and then absolute positions it, so they don't react to to css in the way you'd expect. It took me a bit of time figuring out the best way to get my images to behave the way I expect a normal image, and it required more html and css than I'd prefer. 

It seems almost like before starting my next...Next.js project, I'll create a <BetterImage/> component with all the styling required to make the default <Image/> work the way it should while keeping the benefits of Next.js' hard work.

Thoughts on Next.js Images

How do you center fixed divs? For a while, I used a combination of the left and transform properties:

    .centered-fixed-div{

      left: 50%; 
      transform: translate(-50%, 0);

    }

This works just fine if you have a single fixed div. If you are nesting a fixed div inside of the original, however, the child div will use the transformed parent as the container in Chrome. In order to avoid this, we can center fixed divs the same way we do relative positioned divs: setting margin-left and margin-right to auto. If we set left and right to 0, we can still set a width (and max-width) on the div. the left and right attributes are necessary for the margin-auto to right.

    .centered-fixed-div{

      margin-left: auto;  
      margin-right: auto;  
      left: 0;  right: 0;  
      width: 90%;  
      max-width: 1100px;

    }

Centering Nested Fixed Divs

A multi-page portfolio website for a mural artist collective studio (not a real studio!). I used HTML5 and CSS Grid for the layout, along with Javascript for areas that required interactivity, such as the contact form. I used Next.js as the frontend framework.

DOT  |  Artist Studio Site

A website designed and developed as a freelance project for an independent therapist.

Static site designed in Figma in collaboration with the client, built using html, css, and vanilla JS.

Originally built using React, then recreated in basic html/css.

Therapist Site

An interactive visualization of United Nations country data used to explore the relationship between fertility rates, life expectancy, and population growth throughout the years.  Data is fetched using D3.js, presented using React.js, hosted using Netlify.

Country Population Visualization

Gwendolyn is a platform built to help Players create, update, and share their character sheets either publicly or with members of their own gaming group. It features an inventory tracking system for easily keeping track of your progress.

Frontend built using HTML, CSS, and Javascript. Backend built using Ruby on Rails and hosted using Heroku & AWS.

=)