# How to Build a S.O.L.I.D. Video Player

_...on Typescript_

_This is an article mostly targeted at JR devs who want some real world examples of Patterns and SOLID Principles coming into use in the real world._

### Introduction

So I was building a [video player that supports both YouTube and Twitch](multivid.win) as video sources, because of this I now had 2 libraries to handle video playing in my app.
First I had to take a detour and write typescript definitions for Twitch's video player and [published them to DefinitelyTyped](/posts/how_to_contribute_types_to_definitelytyped__a_step_by_step_guide)
Once that was done, I now had 2 libraries that have very similar functions but different methods to control them.

### The Plan

![planning gif](/images/planningSOLID.gif)

in order to build my video player, I'll need to create different video player instances that have different methods and have a single way to control them. First I have to have a way to create different types of video players with different kinds, and if you know your [Design Patterns](https://en.wikipedia.org/wiki/Software_design_pattern) you know that this sounds rather [_Factory-ish_](https://en.wikipedia.org/wiki/Factory_method_pattern).

So the factory pattern gives us a solution when we need two different classes on runtime, we create a method that given an argument will return a different class that responds to the same interface. And at this point we can clearly see the next step...

We need a player interface with known methods, so let's make it:

```typescript
export interface LiveVideoPlayer {
  play: () => void;
  pause: () => void;
  mute: () => void;
  unmute: () => void;
}
```

Simple... Because my use of the players is quite basic, I only added the methods I would use. This is so we follow the [Interface Segregation Principle](https://en.wikipedia.org/wiki/Interface_segregation_principle). Also, [not implementing things I might not use](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) yet is a good idea.

### Mo problems ⟹ Mo patterns

![problems gif](/images/SOLIDproblems.gif)

Twitch's Player and YouTube's Player don't have the same interface...
Our new interface is nice and all, but neither YouTube nor twitch follow it. Lucky for us, there is a pattern that solves this exact issue: [_Adapter_](https://en.wikipedia.org/wiki/Adapter_pattern)

And this is the fun thing about patterns. I can just say that I implemented and adapter and people who know something about the adapter pattern now have an idea of what the solution looks like.

```typescript
export class TwitchPlayer implements LiveVideoPlayer {
  private player: Twitch.Player | null;
  constructor(divId: string, videoId: string, onReady?: () => {}) {
    // implements player creation and initialization
  }

  pause() {
    this.player?.pause();
  }

  mute() {
    this.player?.setMuted(true);
  }

  unmute() {
    this.player?.setMuted(false);
  }

  play() {
    this.player?.play();
  }
}

export class YoutubePlayer implements LiveVideoPlayer {
  private player: YT.Player | null;
  constructor(divId: string, videoId: string, onReady?: () => {}) {
    // implements player creation and initialization
  }

  pause() {
    this.player?.pauseVideo();
  }

  mute() {
    this.player?.mute();
  }

  unmute() {
    this.player?.unMute();
  }

  play() {
    this.player?.playVideo();
  }
}
```

As we can see, each video player implements `LiveVideoPlayer`, holds an internal instance of the adapted class and calls the appropriate methods. Also handles initialization, as those are very different. In my case, events are also captured and adapted to match.

### Final Notes

At this point our app can create video players and thanks to the principle of [Liskov Substitution](https://en.wikipedia.org/wiki/Liskov_substitution_principle) and some polymorph magic the React side of the app can just call the `LiveVideoPlayer` methods and get the appropriate methods called on each version of the player.

And because our React app now uses an interface to use the players, we are following the [Dependency Inversion Principle](https://en.wikipedia.org/wiki/Dependency_inversion_principle) without even trying, similarly with the [Open/Closed Principle]([Open–closed principle](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)) as our players implementation is now isolated from our app and its code. Proving that good practices are all tied together and will come naturally once you start taking them into account.


how_to_build_a_s_o_l_i_d__video_player

# ESP32-CAM Presence Sensor

As we all do, I have a bunch of Wiz lights in my house and one of their motion sensors. But I want my motion sensor not to turn off when I'm sitting And I also want to control the lights locally as I don't like all smart home thing going to the cloud. So I decided to take one of my ESP32-CAM boards I have lying around, and buy a LD2410 Presence sensor and start a new project.

![boards for the project](/images/boards.webp)

## Planning

So this project has quite a few parts, even for this MVP. We discussed how to [pick the parts and create tasks here](https://blog.ignaciodegregori.com/posts/building_a_esp32_presence_sensor)

## Starting To Code

First thing first is I need to recreate my WIZ control scheme from node in C and in order to do that I need to figure out how to send and receive UDP requests.

So we start by adding the Wi-Fi boilerplate code to connect to Wi-Fi, initialize the UDP service

```c
void  setup() {
	Serial.begin(115200);
	WiFi.begin(ssid, password);
	while (WiFi.status() != WL_CONNECTED) {
	dela(1000);
	Serial.println("Connecting to WiFi...");
}
Serial.println("Connected to WiFi");
udp.begin(localPort);
}
```

And the code to actually send a discovery request to the lamps and read the responses:

```c
void  sendBroadcast() {
	udp.beginPacket(IPAddress(255,255,255,255), localPort); // broadcast address
	udp.print("{\"method\":\"getPilot\",\"params\":{}}");
	udp.endPacket();

	delay(150);

	int packetSize = udp.parsePacket();
	byte p = 0;
	while (packetSize) {
		char  incomingPacket[255];
		int len = udp.read(incomingPacket, 255);
		incomingPacket[len] = 0;
		Serial.printf("Received %d bytes from %s: %s\n", packetSize, udp.remoteIP().toString().c_str(), incomingPacket);
		packetSize = udp.parsePacket();
		p++;
	}
}
```

Now we run the code in a board to see if it works, and we discover that it won't compile because we are missing a semicolon.
![kansas Meme](/images/notInKansas.gif)

## Saving IPs

The discovery UPD packets just gives us a list of responses from all the lights in our house, so now we need to differentiate the lamps. For this we need to parse the response JSON and get the mac address from each lamp as that the only differentiating feature. Once that's done, we compare those with a stored list of lamps to be controlled and save their IP's

IPs are just a 4 byte array. So we will store just bytes, but because I'm just running this in a home network I can risk it and just store the lat number of the array as the other 3 will remain constant for most people. We do have a few options to go with:

- https://github.com/arkhipenko/Dictionary uses binary search.
  - allows us to leave unused lamps alone if not found and only update found ones
- A linked strict list.
- 2 ordered lists.

Because I have a MAC address ordered list already, I'll go with the ordered list approach because I can then just cycle the IP list to control the different lights.

```c
const  char* targetLights[] = LIGHTS_ARRAY; //this one is defined by us in the secrets.h file
const  int arraySize = sizeof(targetLights) / sizeof(targetLights[0]);
// becasue this is c we need to allocate the memory
byte *ipArr = (byte*)malloc(sizeof(byte)*arraySize);

int  isTargetLight(const  char*  target) {
	for (int i = 0; i < arraySize; i++) {
		if (strcmp(target, targetLights[i]) == 0) {
			return i;
		}
	}
	return -1;
}
```

In the packet handler, we add:

```c
int lampIndex = isTargetLight(doc["result"]["mac"]); // we get the mac and compare it with the array
if(lampIndex >= 0){
	ipArr[lampIndex] = udp.remoteIP()[3]; // and store it in the right place in the list
}
```

## The radar

First, we need to connect the radar up physically. The radar needs power (I plugged it in directly to the usb-c breakout board as it consumes quite a bit of power), a serial connection and the output pin.

Then we can add some example code to give it a try:

```c
Stationary target: 71cm energy:100 Moving target: 38cm energy:100
Stationary target: 73cm energy:100 Moving target: 48cm energy:71
Stationary target: 43cm energy:100
Stationary target: 30cm energy:100
Stationary target: 64cm energy:100 Moving target: 35cm energy:100
```

Now that we know it works, we can move on.

## Controlling Lights

We have the radar Data running and that's great, but we don't want to poll the radar on every cycle to see if it's sensing a person. So instead we will use the OUTPUT pin. To read it we set up a new input pin and we set up an interrupt on it.

```c
bool changeToHigh = 0;
bool changeToLow = 0;

void  setup() {
	...
	pinMode(RADAR_OUT_PIN, INPUT);
	attachInterrupt(RADAR_OUT_PIN, ISR, CHANGE);
}

void IRAM_ATTR ISR(){
	if (digitalRead(RADAR_OUT_PIN) == HIGH) {
		changeToHigh = 1;
	} else {
		changeToLow = 1;
	}
}
```

- interrupts need to have the `IRAM_ATTR` flag on them, that way they are always in ram.
- The interrupt has minimal code, so it runs as quickly as possible. It only sets up flags to run some code later in the main loop.

In the main loop, we read those flags and perform the actual USP packet broadcast to switch the lights on and off.

## Clean Up

At this point, the basic functionality is done. Now we can add some error detection, specially checking if we have ram for the IP array and if the Wi-Fi is disconnected. Both cases will just cause a reboot. We should also split the code int o separate files for better reading. Remember that because this is C we need to create a new .cpp file and a header (.h) file that will be imported both in the file where we want to use it and in the .cpp file that implements it

## Web Service

![API meme](/images/apiMeme.gif)

Well at this point the sensor works but because it has a camera and Wi-Fi I'll add some extra boiler place web server code I had lying around, so we can use it as a security camera and get some data from the radar to calibrate it. [Here is some data on how to configure the sensitivity.](https://how2doit.xyz/posts/configure-sensitivity-on-ld2410)

## Case

Well, unlike most coding projects this one include a physical part, so we need to design a case for it, not only to make it look nice, but also to be able to position it. In My case I'll hang it from a curtain rail, so I'll quickly design and print a case with some press fit hook that fits the rail.

![Timelapse of 3d design](/images/designTimelapse.gif)

_I dont have the set up to take 3d print timelapses._

The radar does heat up enough to be clearly visible through the case in infrared:

![Thermal Image of the case](/images/caseThermal.webp)

## Conclusion

At this point, we just flash the final software and assemble everything. The sensor works great, not having to deal with timers and motion sensors.

- All the code is available here: https://github.com/idegre/ESP32-presence-Sensor
- 3DModels:
  - https://www.thingiverse.com/thing:6279011
  - https://cults3d.com/en/3d-model/gadget/esp32-presence-sensor-case

![photo of the final product](/images/finalProduct.webp)


building_a_esp32_presence_sensor

# JS Array method image re-explained

![JS Array methods meme](/images/JSArrayMeme.webp)

### Introduction

We have all probably seen the image on the top where all the array methods are clearly explained in one simple image, right? Well, yes, every JR dev has shared or liked it on LinkedIn. And that's fine, but what gets me is that this image hides one crucial concept in its simplicity.

In order to see the issue, let's first code it!

To start because we are great devs we are going to write a simple loop to get all the methods at once:

```js
const methods = [
  {
    base: new Array(4).fill("🟠"), //["🟠","🟠","🟠","🟠"]
    method: "push",
    args: ["🟢"],
  },
];

methods.forEach(({ method, base, args }) => {
  const res = base[method](...args);
  const outString = `${JSON.stringify(base)}.${method}(${args})`;
  const spacer = new Array(40 - outString.length).fill(" ").join("");
  console.log(`${outString}${spacer}->\t${JSON.stringify(res)}`);
});
```

Here we are using the fact that classes in JS are once defined an object. Because of that, we can access their methods dynamically with square brackets and arguments can be passed as a spread-ed array, so each item of the array will take place of the positional argument in the function.

But here lays the deception of the image, if we run this code as is, we get this:
`["🟠","🟠","🟠","🟠","🟢"].push(🟢)     ->      5`

Now we can see that our original array has been changed, and our result is a 5.

### Explanation

A lot of you already know the explanation. This happens because the push method for arrays is **"mutable"** this means that it changes the array it's called on. So we think ok, easy, let's just make a simple change and get rid of the problem:

```js
methods.forEach(({ method, base, args }) => {
  const baseCopy = base; // Added this line
  const res = base[method](...args);
  const outString = `${JSON.stringify(baseCopy)}.${method}(${args})`; // and changed the shown array here
  const spacer = new Array(40 - outString.length).fill(" ").join("");
  console.log(`${outString}${spacer}->\t${JSON.stringify(res)}`);
});
```

And now if we run it, we realize we get the exact same result!

This is because when we declared `baseCopy` so be `base` JS takes that literally and just gives both variables the same reference! So when push changed the values of `base`, then when reading `baseCopy` we are just reading the exact same array from 2 different place (yes, this is just like pointers because it's the same thing).

So we need to create a brand-new array with the same values we could just spread the array but that just makes a 1-level deep copy, and then it shallows copy (I could explain this in another article). We will just do `Array.from()` this is a _static_ method from the Array class that creates a new array from any iterable.

```js
const originalBase = Array.from(base);
```

Now the code finally works, but the result is still 5. So we just change `res` for `base` and write the rest of the cases and get the results that will be right, right?!

Not Yet...

![not yet meme](/images/not-quite-yet-enough.gif)

### Mutable vs Immutable Array Methods

While this code works great for push, shift, unshift, pop and sort. It won't work for the rest of the methods that just returned the original.

This is because some methods are mutable and others are immutable

| Mutable | Immutable |
| ------- | --------- |
| push    | flat      |
| shift   | map       |
| unshift | reduce    |
| pop     | filter    |
| sort    | concat    |
|         | slice     |

- Mutable methods will alter the original array
- Immutable methods create a new array with a new reference

Immutable methods allow for much cleaner code and less surface for bugs as all references are new and the chances of changing one array changing data somewhere else are greatly reduced!

At this point, there are multiple solutions, so we have to think of some of them and discard the ones that won't work:

1. Add a dictionary to determine which methods are mutable and which aren't and handle the result accordingly.
2. Add a property to our method's array that indicates if it's mutable or not.
3. ~~Have 2 distinct loops.~~ This is too repetitive codewise, as the code difference is a little too short.

In my opinion, both 1 and 2 are great. The first option has the edge in my opinion, as it allows saving data on the list at the cost of the check the function type. Option 2 is acceptable, but it required manually adding data to the list, so it's only viable for proof of concepts or very short lists.

```js
["🟠","🟠","🟠","🟠"].push(🟢)                    ->    ["🟠","🟠","🟠","🟠","🟢"]
["🟠","🟠","🟠","🟠"].unshift(🟢)                 ->    ["🟢","🟠","🟠","🟠","🟠"]
["🟠","🟠","🟠","🟢"].pop()                       ->    ["🟠","🟠","🟠"]
["🟢","🟠","🟠","🟠"].shift()                     ->    ["🟠","🟠","🟠"]
["🟠","🟢","🟢","🟠"].filter((d) => d === "🟢")   ->    ["🟢","🟢"]
["🟠","🟣","🔴","🟢"].join(-)                     ->    "🟠-🟣-🔴-🟢"
["🟠","🟣"].concat(🔴,🟢)                         ->    ["🟠","🟣","🔴","🟢"]
["🟠","🟣",["🔴","🟢"]].flat()                    ->    ["🟠","🟣","🔴","🟢"]
["🟠","🟣","🔴","🟢"].slice(1,3)                  ->    ["🟣","🔴"]
// bonus negative args in slice
["🟠","🟣","🔴","🟢"].slice(0,-2)                 ->    ["🟠","🟣"]
["🟠","🟣","🔴","🟢"].slice(2)                    ->    ["🔴","🟢"]
```

Now It does work, even though I did ramble a bit. I do think that knowing the difference in array methods is quite important, specially since `shift`, `push` and `unshift` can be replaced with [spread syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax), allowing for immutable implementations.

Thanks for reading.


js_array_method_image_re_explained

# Publishing an NPM Module

NPM modules are one amazing creature comfort for the modern JS developer.
In my case, I wanted to publish a tool to fix an (issue with Next.js export format)[https://blog.ignaciodegregori.com/posts/how_to_fix_next_js_exporting_pages_as_files].

### Developing the code

This is the part we were all waiting for, where we show off our coding skills. But there are a few peculiarities to take into account. In order to build an executable CLI. Our package.json will have to include a bin section where we name the command to be called to execute our code.

```json
  "bin": {
    "yourCommand": "./bin/cli.js"
  }
```

Note that I named the called file `cli.js`, that's by convention and the file only really handles what function to called and passing the parameters into it.

### Publishing

This part is extremely easy, once you have your code ready you just need to run:

```shell
npm login
npm publish
```

And that's it!

_If it fails, it is probably because there is already a package with the same name as the one you are trying to make._

Once the publishing finishes, all the data is obtained from `package.json` so no more steps are necessary.

This includes Author, License, Repo, Website [and more](https://docs.npmjs.com/cli/v9/configuring-npm/package-json).

Its also almost obligatory to add a good `README.md` to act as a frontpage in npmjs.com and in our repo's page. Remember to add god usage instructions besides a basic description.

### Conclusion

Overall, the process is painless if you have any experience in starting projects and handling packages. You can see my final repo [here](https://www.npmjs.com/package/next-export-fix).


publishing_an_npm_module

# Adding Types to DefinitelyTyped

As any good typescript developer, we all love to just import the types for our libraries from [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) as if it was magic, but it's not. It's an open source library that's maintained by contributors. So this is also a little peek on how to contribute to an open source project.

### 1. Making out type file

This is the part where you need to use your knowledge of typescript and the library to actually write the type definitions.
In order to test it, the best way is to move the folder into the @types folder within node_modules. This is the actual place the definitions will be when imported by another user.

Types should be in an index.d.ts file all within a folder named the same as the module being typed, or the name followed by "-browser" if it's not a NPM module. Remember to declare the module like this:

```ts
declare module "name" {
    // Types here
}
```

### 2. Adding tsconfig, tslint and Header

Tsconfig and tslint are mostly expected to just be unchanged from [the documentation](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/README.md#tsconfigjson), but writing types for a non NPM package will force you to turn off some linter rules and cause the bot to report that as an error.

The headers are structured comments at the top of your index.d.ts file, and these are actually required. These are also used for reference and ownership attribution, so it's good that you can't forget them. They should be at the very top of the file and look like this:

```ts
// Type definitions for name 1.0
// Project: https://github.com/library-name
// Definitions by: Your Name <https://github.com/username>
//                 Colaborator's Name <https://github.com/username>
// Definitions: https://github.com/DefinitelyTyped/DefinitelyTyped
```

It is appreciated (by anyone who uses JS) if your type definitions also include _[JSDoc](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html)_ annotations for people to see later, so remember to write those.

At this point, you can also add a _readme.md_ file if you want.

### 3. Cloining the repo

This part is easy, just fork [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) and clone the new repo.

### 4. Adding tests

The files should be tested, and the tests should cover all defined methods. The testing is done with _[dtslint](https://www.npmjs.com/package/@definitelytyped/dtslint)_, this library allows you to just call methods and variables and assert their type. In order to do that, two assertions are used:

```ts
// $ExpectType void
// @ts-expect-error
```

One is for asserting expected type and the other to assert an expected type error.

### 5. Making the PR

First merge your code int othe _main_ branch of your fork of DefinitelyTyped. Then go to [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) and create a new PR from your fork's main into DefinitelyTyped's main.
For this particular project, PR's have a handy template. But if that wasn't the case, remember to write a good PR description.

### 6. Merging

Now you have to wait for CI to pass and wait for a member's approval. This takes a day or two.
Once approved by a member, you can just make a comment with _"Ready to merge"_ and the bot will automatically merge it.

### Conclusion

All in all. The maintainers were super helpful and the contribution process for DefinitelyTyped is very painless.

Let's get typing!


how_to_contribute_types_to_definitelytyped__a_step_by_step_guide

# How To Fix Next.js Exporting Pages As Files

One of the not so well known features of Next.JS (only with the Pages router...) is the ability to export the page as static HTML. This is very useful if you want all the benefits of UI development with React and SSR. But don't want the complexity and cost of SSR deployments. Thant is the case for this blog for example. Prerendering posts is easy and allows me to easily create new post pages, but having function and database calls of every user might get expensive for just a little HTML, so it's all just exported as static HTML and served.

### The Problem

When exporting a dynamic page, Next.JS creates a folder with multiple HTML files within it for every page. This works fine so long as you are navigating within the site and having the hydrated router loaded. But as soon as you directly type the URL into the browser it will return 404 because while the folder exists, there is no index file for it and the url doesn't contain the .html extension on it (and no one has typed .html into a url since 2006)

This problem can show as next not exporting pages as index, not exporting pages into their own folders, not creating index files. (yes, this paragraph is for people to find this in google)

### The Solution

Some places recommend using the `backSlash` option then exporting, and that works, but only if you have the hydrated router running. It doesn't work for first loads. It seems that vercel doesn't have a solution yet, maybe once they enable exporting for the app router 🙏.  
The Real solution to me was just writing a quick script that finds all html files not called index, places them in a folder with their name and renames them to index.

### The Script

```js
const fs = require("fs");
const { globSync } = require("glob");

try {
  const pages = globSync("./out/**/*.html", {
    ignore: ["./out/**/index.html", "./out/index.html"],
  });
  for (const p of pages) {
    const [filename, ...path] = p.split("/").reverse();
    const [name, ext] = filename.split(".");
    if (name === "index") {
      continue;
    }
    path.reverse();
    fs.mkdirSync(`${path.join("/")}/${name}/`);
    fs.renameSync(p, `${path.join("/")}/${name}/index.${ext}`);
  }
} catch (err) {
  throw new Error(err);
}
```

The script could probably not have the `for loop` if you integrate it into a pipeline and have async support for it. I'm just running it as is chained to the export command, so I needed it to be sync.

You can also just import it from NPM [from here](https://www.npmjs.com/package/next-export-fix)


how_to_fix_next_js_exporting_pages_as_files

# Making a Hackathon Game

Last Friday I participated in the Kopius Hackaton 23. Where teams of 3 devs were tasked with making a game that Kopius as a company could use to showcase the new brand in [_nerdearla_](https://nerdear.la/en/) (one of the largest IT trade shows in LATAM).
The thing about Hackatons is that there is a whole process to actually building something that fast. Here is a little bit of my process.

## 1. The Idea

First, We needed to figure out what to make. And because the logo is an asterisk, we decided to go with a drawing game. We did this for a few reasons

1. It's highly interactive: People are actively playing with the logo and brand.
2. Branding guidelines: it allows us to showcase the logo and brand in a very similar space to the usual ones and follow all branding guidelines
3. Team: it meshed well with the team's skills.
4. Requirements: The requirements stated that we needed to showcase the brand and have a pointing system.

## 2. Picking a stack

This part was easy, almost by default we were going to go with a web based JS experience. I did ask to use Typescript, as I find that having types in JS makes debugging so much easier. One decision we did make at this point was not using any FE library or framework. Because these are great for a webpage or maybe the game's menu interface. They are not great for a game's core functionality and would slow us down. In the end, we went with pure JS and HTML.

## 3. Core functionality

Now it was time to actually get building. The core of the game consists of an interactive web canvas. On this canvas we listen for click events, and store their X, Y positions. One thing we did have to take into account was calculating the distance to the last point to prevent a user who is holding their finger steady from creating thousands of points on top of one another. So in the end as the user drags their fingers or cursor, on every move event we calculate the distance to the last stored point and once is higher than a set minimum we store a new point. At the same time, we use the previous point and the new one to add a new line to the canvas, allowing the player to interact in real time.

## 4. Win Condition

Remember when I said we picked this kind of game because it met the requirements of allowing for a pointing system. Well now it was time to actually build the pointing system, and it was a little harder than expected. In the end because of time constrains we landed on waiting for the user to lift their finger. This keeps us from constantly calculating a score, and it also allows the user to see the win animation as their finger will be off the screen. The scoring is done by counting how many points fall within a set distance of the perfect place. This means that for every point the user makes. We take the Y coordinate, and calculate the mathematically perfect X coordinate where the logo should be, and if the user's X coordinate falls close enough they get a point. The user wins if they get 70 points, and there was no science to that number. We just got a bunch of people to play, and took note on how good their logo looks and the score they got, and decided on a threshold.

## 5. Cleanup.

After this, we Just needed to finish up the styling to meet brand guidelines and clean up the code.

## Conclusion

**We did end up winning!** Because of some of the points listed above. The game is a good showcase of the brand and its fun. In the end, it was quite a fun experience to participate in a hackathon. In my case, the whole thing was great because I love working on product development, and in a hackathon the whole objective is the product and getting it to the presentation. If there are technical difficulties, the team has the choice to fix it with tech or by changing the final product and doing real-time feature prioritization, and that is a fantastic exercise for teams. It's also an amazing exercise on measuring difficulty. A lot of things we thought were going to be effortless took a lot longer, and some we had to drop.

## Code

You can see the [GitHub repo code here](https://github.com/idegre/kopius-hackaton-23-game).

## The Game

You can also try the [game here!](https://ignaciodegregori.com/kopiusGame).
