DEV Community: Thor Würtzner

Cellular Automata - Wonders of Emergent Patterns from Biology to Computer Science

Thor Würtzner — Wed, 31 Jul 2024 10:13:31 +0000

I live with a molecular biologist, and her passion for topics like the brain and cells often leads to fascinating (if sometimes very scientific) conversations. So when I started researching the concept of Cellular Automata, I saw a wonderful subject that combined both of our fields in an unexpected way. If there's one overall takeaway from this post, it's that math truly is everywhere!

So what is it?

in a nutshell; Cellular Automata are mathematical models that simulate complex systems from surprisingly simple rules.
Developed initially by John von Neumann and later popularized by Stephen Wolfram. Ever heard of Wolfram|Alpha - the incredible math engine used by countless students and experts alike? The research company behind it was founded by this guy.

His findings in 1983 showed incredibly complex and unpredictable behavior, and describing a very powerful tool for modeling real-world phenomena.

Basic principles

Representation

Cellular Automata are typically represented by a grid of cells. Each cell can be in one of a finite number of states. For example, in the simplest form of Cellular Automata, each cell is either "on" or "off" (binary states). The grid can be one-dimensional, two-dimensional, or even higher-dimensional, though two-dimensional grids are the most commonly studied.

States and Rules

The rules of Cellular Automata determine how the state of each cell evolves over time. These rules are usually based on the states of neighboring cells. For example, a rule might specify that a cell turns "on" if exactly two of its neighbors are "on" and turns "off" otherwise. Despite the simplicity of these rules, they can produce insanely complex and varied behavior.

Game Of Life

The Game of Life, developed by mathematician John Conway, is perhaps the most famous example of Cellular Automata . In this two-dimensional grid, each cell is either alive or dead. The rules for the Game of Life are:

Any live cell with fewer than two live neighbors dies (underpopulation).
Any live cell with two or three live neighbors lives on to the next generation.
Any live cell with more than three live neighbors dies (overpopulation).
Any dead cell with exactly three live neighbors becomes a live cell (reproduction).

My rendition of the phenomena, built in Javascript

Sand Simulation

This simulation models the behavior of falling sand grains, showing how simple rules can create realistic-looking phenomena. Each cell represents a grain of sand, air, or a solid surface, and the rules dictate how sand grains move in response to gravity and collisions.

My rendition in Javascript and HTML canvas

So, how does it actually work?:

From these examples, we can draw out three phases of life for a cell:

1. Initialization

The starting conditions, or initial state, of the Cellular Automata grid are crucial. These conditions can be randomly generated, or they can be set up in a specific pattern to observe how different configurations evolve over time.

2. Rules

The rules of Cellular Automata define the "neighborhood" of a cell (the set of cells that influence its state) and the state transitions (how a cell's state changes based on its neighbors). In the Game of Life, for example, the neighborhood consists of the eight surrounding cells, and the state transitions are defined by the rules mentioned earlier.

3. Iteration

Cellular Automata evolve over discrete time steps, with each cell updating its state simultaneously based on the rules. This process is repeated for many iterations, often resulting in intricate and unexpected patterns.
We'll see soon this show up in weird ways!

Emergent Patterns and Behavior:

One of the most fascinating aspects of Cellular Automata is this weird emergence of complex behavior from simple rules. Where larger patterns and structures arise out of local interactions.

Self-replication and Growth

Some Cellular Automata rules can lead to self-replicating structures, which are patterns that produce copies of themselves. These structures can be used to model biological processes like cell division and growth.

Oscillators and Gliders

In 2D Cellular Automata like the Game of Life, certain patterns repeat infinitely, called oscillators:

This is incredible when thinking in the aspect of biological life - these cells are in harmony, and in a way 'perfect'.

Others travel across the grid, called gliders:
Showing interesting applications in how human cells might be travelling through our insides.

These patterns aren't just visually interesting but also demonstrate how complex the end result can actually get - and how we're moving in the direction of what Stephen Wolfram described as 'Scientific Philosophy'.

Stability and Chaos

Furthermore Cellular Automata can exhibit a range of behaviors from stable (where the grid reaches a steady state like the Oscillator mentioned above) to chaotic (where patterns change unpredictably over time). The study of these behaviors helps scientists understand the transition between order and chaos in complex systems.

Applications of Cellular Automata:

Now here's where it gets interesting. Until now we've simply described how simple rules gives complex results, yada yada - but remember how i told you that the iterations showed up in very weird ways?

Simulations of natural phenomena

Phew, well here we go. Cellular Automata can even be used to model biological processes like the development of organisms, pattern formation, and the spread of all kinds of diseases. Take these patterns on seashells for example.

Like, man, this is legit just Conway's Game of Life from above - I don't know about you, but I'm pretty blown away.

Seeing the rules we specified earlier of how each cell moves through different iterations, now in real life, is nothing short of incredible.

To keep it 'Computer Sciency' and not just about Lizards, Cellular Automata have actually also been proposed for public-key cryptography, which makes sense given their complexity. The evolution of Cellular Automata patterns over numerous iterations is highly unpredictable, making it extremely difficult to reverse-engineer or predict previous states. This inherent unpredictability provides a robust foundation for encryption - but if I'm not wrong, it's still just a theory and haven't been implemented as of yet.

Simply put, this stupid little thing finds its place in an incredible array of contexts—from complex computer systems to small lizards whose scales provide camouflage, helping them hide from predators while they search for food.

As research in Cellular Automata continues, our understanding of these emergent behavior improves, and who knows where the next application will find itself.

Conclusion

Cellular Automata provide a unique lens through which we can explore the complexity that arises from simple rules. As we delve deeper into their properties and behaviors, we continue to uncover new insights that could revolutionize various scientific and technological fields.
And it's also just freaking cool!

The modern way of setting up IndexedDB

Thor Würtzner — Wed, 18 Aug 2021 13:04:12 +0000

Updated for Aug 2021

Look! What is that? Is it a plane? is it localStorage?
No, it's IndexedDB - an unnecessarily complicated low-level API for client-side storage of lots of structured data.
I would like to meet the person who instantly understands how to implement it into their project, because he might have the ability to crack this modern version of the Enigma Code.

Pathetic jokes aside; I was required to use this pretty cool way of storing data for a school project, and decided to document how I made it work. For my future self, and any other frustrated developer who has also started yelling at their rubber ducky for not giving the answer.

To make it very clear, I know very little of what goes on behind the API, but simply how I personally made it work - and how you, future Thor, might also need to.
SO! Let's get started.

IndexedDB isn't exactly a normal SQL-based relational database, but more of a javascript-based object oriented one. Ever seen this type of data before?
key: "value"
That's what we're working with, and it's great for simple applications like the Movie PWA I was building.
Right out the box the API works by events, but I recommend ditching that and instead installing Jake Archibald's 'IndexedDB Promised Library', which pretty much mirrors the API, and uses... you guessed it. Promises.

Disclaimer

Many tutorials like the one by Google, use an old version of the library, and will not work if you follow it. Ask me how I figured that out.

To understand how IndexedDB works, you first need to know the different ways of handling data therein.
Before anything can be done, the database has to be 'opened'. I'm putting that in quotes, because you actually also need to 'open' it to create it, so you're kind of doing both at the same time.
The way you'll probably see it imported in online tutorials is like this:

import idb from 'idb';

You would use it like idb.open()
but since becoming a module we're instead required to import it like so:

import { openDB } from 'idb';

Highest Level

To start the whole process we'll open/create the actual database
For that create an async function somewhere and write this inside.

async function myDatabase() {
   const db = await openDB('Database_name', 1, {

   });
}

This is the highest level of the database.
You can create as many as you want, but usually there's only one of these per app.

The Object Store

This is one of the buckets that we're gonna store our data in, it's like a table in traditional relational databases.

const db = await openDB('Database_name', 1, {
   upgrade(db) {
     const store = db.createObjectStore('name_of_store', {
        keyPath: "id_of_the_thing"
     });
   }
});

We need the upgrade if this version of the database hasn't been opened before, which it hasn't... I don't think.
Honestly I would look this up if you need to, because the methods of IndexedDB are quite weirdly named and you might not need it in your project. But for the sake of not breaking mine, I'm keeping it for now.

Inside of that, we're creating the store, also called a bucket, or table. Well, It's where we store our data. Ha.
If your project breaks, or you need a random ID for your stuff, add an autoIncrement like this:

const store = db.createObjectStore('name_of_store', {
   keyPath: "id_of_the_thing",
   autoIncrement: true
});

Test time!

Whenever or however you call your async function, an IndexedDB should show up in your browsers dev tools. You'll find it in the application tab, right next to localStorage.

Cool. We have a database, and a store/bucket/table ready to receive our stuff.

To add our first item to the store, stay inside our async function, and write like so:

await db.add('name_of_store', {
   apple: "delicious"
});

And in the browser:

We have our first piece of data!

But... how do you get the thing back you ask?

var myThing = await db.get('name_of_store', 1)

The 1 is the id of our apple in the store. If you specified it to be something specific instead of an auto incremented one, you of course use that instead.
The variable myThing now has an object ready to be used!

Full code

async function myDatabase() {
   // It's a good idea to have this error handling just in case
   if (!('indexedDB' in window)) {
      console.log('This browser doesn\'t support IndexedDB');
      return;
   }

   const db = await openDB('Database_name', 1, {
      upgrade(db) {
        const store = db.createObjectStore('name_of_store', {
           keyPath: "id_of_the_thing",
           autoIncrement: true
        });
      }
   });

   await db.add('name_of_store', {
      apple: "delicious"
   });

   var myThing = await db.get('name_of_store', 1);

   console.log(myThing);
}

So that kind of ends this simple setup.
It's incredible how little help you're able to find online regarding all of this, so hopefully this will help myself in the future, and maybe some lost soul will stumble upon it as well.
There's loads of other features that can be used, but I won't get into that right now.
You can find more examples on Jake Archibald's library readme:
https://github.com/jakearchibald/idb

React testing & formatting made easy

Thor Würtzner — Wed, 17 Feb 2021 19:14:39 +0000

It doesn't matter how beautiful your site is, if a push with some faulty code can crumble it all

Testing fixes this.

And luckily for us, react has already thought of it.

Open up your favorite code editor and create a file named after one of your components, but add a .test. as a file extension.
Example:
Category.test.js
In here we're gonna be testing a mocked axios response.

In here you wanna import everything you need, including but not limited to:

your component
mockedAxios from "axios"
{ act, cleanup, render, screen, waitFor } from "@testing-library/react"

we're gonna be using Jest, which is what facebook uses to test react apps - this means it's already included if we started our project with the create-react-app template.

afterEach(cleanup)
jest.mock("axios")

The first function makes sure that the virtually rendered test is unmounted after each run, and the second tells the document that we're mocking an axios response.
The whole point is to simulate what kind of response our component wants to use. This means that we're not testing the actual API response, but our own mocked version.

describe("shows our component", function() {
   // This is where our test will be set up
})

We wanna create an almost exact copy of what the real API response looks like, the reason it's not an exact copy is that the values don't matter - only the properties.

So this could be our mocked response, but remember it needs to have the exact same properties and nesting as the real thing

    var response = {
        data: {
            playlists: {
                items: [
                    {
                        id: 1,
                        images: [
                            {
                                url: "https://via.placeholder.com/600"
                            }
                        ],
                        name: "rock on",
                        type: "playlist"
                    },
                    {
                        id: 2,
                        images: [
                            {
                                url: "https://via.placeholder.com/600"
                            }
                        ],
                        name: "dance moves",
                        type: "playlist"
                    },
                ]
            }
        }
    }

Now to actually test this we will use an 'it' function, which takes a name parameter and callback function.

it("shows a functional component", async function() {
   // Our test will run here
});

Inside we need:

mockedAxios.get.mockResolvedValue(response) Which uses our fake response and simulates it as real.
an act function which closely simulates a browser environment by executing useEffects, and reduces amount of re-renders done. It takes a callback function as parameter.
an await waitFor function which also takes a callback function as parameter. We use await because of the outer it function being asynchronous.

This is what we're left with:

it("this is a description of what the function does", async function() {
  mockedAxios.get.mockResolvedValue(response);

  act(function() {

  });

  await waitFor(function() {

  });
});

Inside of the callback for the act function, we need to render our component in the simulated browser.

render (
   <Component /> 
)

Inside of the callback for the asynchronous waitFor function, we need to declare a variable that looks for a specific piece of text on the screen in this simulated environment. For the test to pass, this piece of text obviously needs to be provided by the mocked axios response declared further above.

var text = screen.getByText(/party/i)
expect(text).toBeInTheDocument()

Run the premade script called "test", and it will get a pass!

To summarize,
we are not testing the actual finished product, or the real API response. We are simply making sure that the component is ready and able to use the information it will eventually be provided and is designed for.

afterEach(cleanup);
jest.mock("axios");

describe("shows our component", function() {
    var response = {
        data: {
            categories: {
                items: [
                    {
                        id: 1,
                        images: [
                            {
                                url: "https://via.placeholder.com/600"
                            }
                        ],
                        name: "party",
                        type: "playlist"
                    },
                    {
                        id: 2,
                        images: [
                            {
                                url: "https://via.placeholder.com/600"
                            }
                        ],
                        name: "dance moves",
                        type: "playlist"
                    },
                ]
            } 
        }
    }

    it("shows a functional component", async function() {
        mockedAxios.get.mockResolvedValue(response);

        act(function() {
            render (
              <Component />
            );
        });

        await waitFor(function() {
            var text = screen.getByText(/party/i);
            expect(text).toBeInTheDocument();
        });
    });
});

Formatting

The package Prettier makes sure our code is formatted in a uniform way. Useful for examples like sharing code and working together, it creates a consistent style by making sure the files follow a specific set of rules.

npm install prettier -D
This needs to be a dev-dependency for later!

Now these files need to created in your root folder:

prettierrc.json, to let your code editor know that you're using prettier. This is your config file.
.prettierignore file so your code editor knows which files shouldnt be formatted

There's a bunch of different options that can be input in the json config, so instead of writing them all out i'll link you to the official documentation
prettier options

An easy example could look like this

{
   "printWidth": 120,
   "useTabs": true,
   "semi: true,
   "singleQuote": false,
   "quoteProps: "consistent",
   "bracketSpacing": true,
   "arrowParents": "avoid"
}

This makes sure that even though Bob from your office loves to use 31 tabs between variable declarations and not use a single line break, you won't have to deal with it when he sends you the file for review.
And there's potential options to deal with ALL of your co-workers "personal formatting preferences", and you don't even have to confront them about it - great right?

Now for the ignore file
Most importantly, add your node_modules folder to the .prettierignore file.
some other good ideas are 'build', 'coverage' and '.vscode', but like the official documentation recommends, you can mostly just copy everything from your .gitignore file.

To format all files with prettier:

Create a new script in package.json called "prettier", with a value of "prettier --write ."
Go to the console and npm run prettier, this uses the default options and ones written in your config file.

If you so desire, theres the possibility of changing the script value to "prettier --write src/" to only format files in the src folder etc.

A bit of a warning!

We automatically use eslint because of react, so we need to install a package that lets Prettier work nicely with it. This simply disables some eslint options that might interfere.
npm install eslint-config-prettier -D

Pre-commit hooks:

Quick to set up, but incredibly useful.

To make sure Prettier always formats your files before committing,
go to the console and write as so:
npx mrm lint-staged
This is a package that simply runs Prettier before every commit.

If you also wanna make sure you don't commit something that has failed one of your tests, go to the console once again:
npm i husky
npx husky install
npx husky add .husky/pre-commit "npm test"
Add cross-env CI=true to your test script like so:
npm i cross-env
"test": "cross-env CI=true react-scripts test"
Now the "npm test" script will always be ran before a commit, and if it fails, the script will end itself.

Now there's no way around formatting the code, take that -31 tabs Bob-