
## What's Advent of Code?

Advent of Code (AoC) is a fun coding challenge that occurs between the 1st to the 25th of December, although you can go back and do the previous years challenges whenever you want! Each day brings a new story, with you trying to solve a problem to help the Elves out. It's not like your typical coding challenges that [Codewars](https://www.codewars.com/) or [LeetCode](https://leetcode.com/) offer, instead a deeper more playful story-driven challenge.

The problems during the month get harder and harder, but not linearly - some days are easier than others, sort of like a "break day". The story each day comes in two parts, both earning you a single star working towards your goal of 50 starts on December 25th. Part 2 is _usually_ an extension of part 1, but later in the series I found that part 2 meant you needed to re-write everything you did in part 1 if you used a brute force approach to the problem.

I've done quite a lot of these types of programming challenges before, especially on [Codewars](https://www.codewars.com/users/korziee/) and one big difference between AoC and the others is that AoC forces you to think through your solution before you submit an answer. If you submit a wrong answer, you'll get locked out temporarily, this sounds scary but each problem provides a sample set of data and the expected answer, so you can test your solution on that first.

> I still haven't gone back and finished all of the challenges. I got up to day 16, and all of my work is over at [korziee@github](https://github.com/korziee/2022-advent-of-code).

## Languages

During the beginning of the month the challenges were fairly trivial, so I spent some time playing around with a few languages that I haven't written in before. Towards the end I fell back to TypeScript as that's the language I'm most proficient in.

### V Lang

I did a couple of challenges in V and I enjoyed it as a language, it was easy to pick up and get going, even though the documentation was scattered and not easy to search. It felt like a nice balance between Go and C. V offers a nice standard library, good control flow, and simple error handling. One downside that I found with V was the lack of editor tooling - the VSCode plugin wasn't **bad**, it had nice syntax highlighting, but was lacking autocomplete.

### Erlang

I've been meaning to check out Erlang for quite a long time... Ever since a tech bro ridiculed me for 5 minutes after I said I use NodeJS primarily in my work, and they wouldn't stop talking about Erlang!

I found Erlang quite tough, I don't have much experience with functional languages, so it was a bit of a paradigm shift. But once I got the hang of pattern matching I started to enjoy it. Although I couldn't stop thinking about just how inefficient this code would be at runtime?

At this point, I thought I'd just been spoilt with TypeScript intellisense and just had high expectations for editor integrations. There are a couple of Erlang VSCode integrations, and the one I used was good enough, but as a newbie to the language I still found some features like autocomplete for the standard library lacking.

### Go

Go has got to be the most boring language I've ever written in, and I love it! The simplicity of Go makes it a enjoyable language to work with. I was pleasantly surprised by the VSCode integration as well, I found debugging to be a breeze, and formatting _just worked_. The Go documentation was great, I did the [Tutorial: Get started with Go](https://go.dev/doc/tutorial/getting-started) and really enjoyed the tour of the language!

### C

C - Bit of a classic! I find opportunities to use C day-to-day are extremely rare in my line of work (web) so I did day 6 in it and had a great time. Theres something so humbling about dropping down into C and doing things from scratch.

### Swift

HOW GOOD IS SWIFT?! I used Swift a fair bit back when I did my stint in the Connected Television Team (CTV) at Nine working on the 9Now Apple TV application. `if let` and named parameters are such nice parts (among many more, but these two come to mind) of the syntax. Swift in VSCode isn't great, but I was trying to avoid whipping out Xcode just for AoC.

### Gleam

Gleam is what Typescript is to JavaScript, but for Erlang. It transpiles to Erlang. It was an extremely enjoyable (borderline bubbly) language to use. The documentation was phenomenal and helped expose me to a lot of concepts that could also be used in Erlang.

In-line error handling was rather enjoyable through the `assert` operator.

```Gleam
assert Ok(file) = file.read(from: "input.txt")
```

From the docs:

> Sometimes we have a function that can technically fail, but in practice, we don't expect it to happen. For example, our program may start by opening a file, if we know that the file is always going to be possible to open, then we don't want to complicate our program with handling an error that should never happen.

## Core Learnings

1. **READ THE FUCKING QUESTION SEVENTEEN TIMES BEFORE YOU TOUCH THE KEYBOARD!**

The further I got into AoC, the more and more frustrated I got (at myself) for not fully understanding the problem before I started solving the problem. I had many teachable moments, as I often jump the gun and just start pseudo-coding a solution to aid my thinking. Usually that's beneficial to what I'm doing, but in my experience, it was just wasted time, as the problem develops throughout the entire story.

2. **Don't spend hours on end trying to solve something, reach for help/hints**

This is tied with core learning #1. AoC is meant to be a fun challenge, not a hair-pulling, aging process. I think I would've gone through to day 25 if I had time-boxed my attempts at some of the challenges, and after that reached for help if I was stuck, in the form of hints or reviewing other people's solutions. The [AoC subreddit](https://www.reddit.com/r/adventofcode/) is a good source of knowledge. You truly don't know, what you don't know. There's no point grinding unnecessarily and getting frustrated. Instead, learn by reviewing and understanding.

1. **Do not eagerly optimise for part 2**

Half of the battle with AoC is groking the problem provided to you in the form of a story, for me, over-optimising early took up a bit too much brain space. I was better off solving the solution with a brute force approach, which gave me the mental capacity to at least understand the problem completely. Rather than spending time optimising and crafting a beautiful algorithm!

## Closing Thoughts

I enjoyed AoC 2022, but knowing what I know now by reflecting on AoC 2022, I'm going to **really enjoy** AoC 2023! You can do the previous years Advent of Code whenever you want, so check it out, get your friends and co-workers on board, and happy programming!


My Advent of Code 2022 Journey


This article pays tribute to a pretty cool protocol I came across whilst browsing a list of TCP/UDP ports on [wikipedia](https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers), Gopher.

## I thought this was a tech blog, why are you talking about animals?

The Gopher protocol was created at the University of Minnesota, by a team led by Mark P. McCahill. Minnesota is known is as the [gopher state](http://discussions.mnhs.org/collections/2012/03/why-is-minnesota-the-gopher-state/), so naturally a bunch of smart guys named a tech protocol after an animal.

Gopher is often called the predecessor of the web, and that's a pretty fair comparison given its use and capabilities it provided in the early 90's. The early 90's are a scary place for millennials like myself, there was no concept of "googling" the answer to that burning question you had, or using Stack Overflow to help solve that strange esoteric javascript error that according to your users only occurs when they double click 4 times, refresh, change tabs and then come back to your page.

Gopher provided early internet adopters with a way to share their ideas, and push their content out there on what were and still are known as **GopherHoles**.

Gopher is inherently a very simple protocol that wraps around TCP and uses plain text communication. If you're willing to stray away from what's defined in the RFC you can use gopher for an array of cool things! You could build a JSON viewer in gopher, a [solitaire game](https://www.reddit.com/r/Gopher/comments/c0o3md/solitaire_over_gopher/), a sports score viewer, a tic tac toe game, it really is endless.

However, gopher was not designed with these capabilities in mind, gopher first and foremost was designed to be a distributed document delivery system. Now there's a few buzz words in that, but the core idea of gopher was it was to be used to present users with a hierarchical view of items and directories, much like a file system. Initially this enabled users on campus to share and access documents over a network, later this enabled internet users to share documents!

## So, what does gopher look like?

At its core, a single line of gopher (also known as a Gophermap) looks a little like this: _1News /news gopher.koryporter.com 70 \r\n ._

In the above example we can break those down into a few sections.

- **1** - directory item type

- **News** - display string

- **/news** - selector

- **gopher.koryporter.com** - hostname

- **70** - port

Now there's a few things here that need to be called out. First, the delimiting character between the sections like `1News` and `/news`, are tab characters, or `\t`. Secondly, you'll notice that the line ends with `\r\n`, the `\r\n` is a [carriage return](https://en.wikipedia.org/wiki/Carriage_return) and a [linefeed](https://en.wikipedia.org/wiki/Newline) right after one another, it's more commonly known as a CRLF signal. Gopher browsers use this to delimit each line of gopher, if you had multiple lines you would need a CRLF on the end of each of them. Lastly, and most importantly, the single period `.` at the end of the line, that's the end of message character, it tells gopher clients that you have finished writing.

Check out this excerpt from the RFC for gopher, it goes through a typical connection scenario between client and server. Source: https://datatracker.ietf.org/doc/html/rfc1436

```txt
Client:   {Opens connection to rawBits.micro.umn.edu at port 70}
Server:   {Accepts connection but says nothing}
Client:   <CR><LF> {Sends an empty line: Meaning "list what you have"}
Server:   {Sends a series of lines, each ending with CR LF}
0About internet GopherFStuff:About usFrawBits.micro.umn.eduF70
1Around University of MinnesotaFZ,5692,AUMFunderdog.micro.umn.eduF70
1Microcomputer News & PricesFPrices/Fpserver.bookstore.umn.eduF70
1Courses, Schedules, CalendarsFFevents.ais.umn.eduF9120
1Student-Staff DirectoriesFFuinfo.ais.umn.eduF70
1Departmental PublicationsFStuff:DP:FrawBits.micro.umn.eduF70
          {.....etc.....}
.         {Period on a line by itself}
          {Server closes connection}
```

## What can gopher do?

Let's first investigate what those characters are at the beginning of
every line of text that gopher servers respond with, and why they are
important for gopher clients.

Every single line of gopher usually begins with a character that exists
between 0-9 or a-z, this is the reserved range of "Item type characters".
The original gopher RFC defined just over a dozen item types for clients
to respect, they are as following.

| Item Type | Description                                                |
| --------- | ---------------------------------------------------------- |
| 0         | Text File                                                  |
| 1         | Gopher directory (submenu)                                 |
| 2         | CCSO Nameserver                                            |
| 3         | Error code returned by a Gopher server to indicate failure |
| 4         | BinHex-encoded file (primarily for Macintosh computers)    |
| 5         | DOS file                                                   |
| 6         | UNIX uuencoded file                                        |
| 7         | Gopher full-text search                                    |
| 8         | Text-based Telnet session                                  |
| 9         | Binary file                                                |
| +         | Mirror or alternate server (for load balancing)            |
| g         | GIF file                                                   |
| I         | Image file                                                 |
| T         | Telnet 3270                                                |

These types are used by gopher clients to understand what type of content
it should expect at that directory.

See the following examples:

- "_1News /news gopher.koryporter.com 70_" has an item type of 1,
  which means the gopher client should expect a directory (submenu), and
  that the directory will contain a listing of other gopher items.

- "_0my article /my-article gopher.koryporter.com 70_" has an item
  type of 0, which means the gopher client should expect a text file, and
  that once the client has asked for the file, and the server has responded,
  it should then render out the contents of the text file in the client.

Now that we know gopher has item types, let break down a few key use cases
for gopher.

### Acting as remote file system viewer

As gopher clients can render text
files and download binary files to a users system, we can use a gopher
client as a very primitive way of viewing a directory structure on another
system. This is what gopher was originally designed for really, it gave
users a way to browse and access content remotely.

### Full text document searcher

The gopher item type **7** defines a
full-text search. Common practice among gopher clients is to give users
the opportunity to enter any free text and it will send it to the gopher
server. Full text searching means that the listening gopher server is
meant to implement a search across the contents of every file it had
available to it. The power of this comes into play when you can nest an
item type of 7 deep down into a nested structure. An example might be a
gopher server that displays books available. Instead of doing an expensive
full-text search across all books, the gopher server might have you browse
existing categories, and once you have selected your category, it would
then present you with a full-text search (item type 7) within that
category, which dependent on how many books and categories indexed by the
server, would increase performance exponentially.

## Simple Gopher Server in Node (optional)

If you whipped up a tcp server on port 70 right now, any gopher client
would accept that as valid gopher text, in fact, let's do just that using
Node.js.

```javascript
const net = require("net");

net
  .createServer((socket) => {
    socket.once("data", (buffer) => {
      // sockets receive and stream buffers by default.
      const data = buffer.toString();
      // \r\n === CRLF, this is asking for the "root directory"
      if (dataAsString === "\r\n") {
        socket.write(`1News\t/news\tlocalhost\t70\t\r\n.`, () => socket.end());
      } else if (dataAsString === "/news\r\n") {
        socket.write(`iNice!\t\r\n.`, () => socket.end());
      }
    });
  })
  .listen(70);
```

Once you've run the above code a tcp server will be listening on port 70.

Open up your terminal and install the lynx web browser if you don't have it yet. Mac users can install lynx through brew by running:

```bash
brew install lynx
```

Otherwise checkout https://lynx.invisible-island.net/lynx2.8.9/index.html for more comprehensive instructions.

Now that you've got lynx installed, in the terminal run:

```bash
lynx gopher://localhost:70
```

Woop woop, you've created your first page in gopher! The output on your terminal should look a little like the picture below.

<figure>
  <img src="/assets/blog/gopher-the-father-of-the-world-wide-web/simple-gopher-tcp.webp" alt="A mac OSX terminal output displaying Gopher">
  <figcaption>Woo-hoo, things are happening!</figcaption>
</figure>

Thanks to the power of lynx, we can navigate through our little gopher hole using our arrow keys, because we only have one directory set up so far "News", that will be pre-selected for you. Click the right arrow on your keyboard. Lynx will then ask your gopher server for the contents at "/news", and you should be navigated to a new view that says "Nice!".

If you're interested how in the implementation of gopher using node, checkout [this repo](https://github.com/korziee/gopher) I created. A lot of abstractions were built to hide away the intricacies of gopher, see the core folder for more info.

## So, you say gopher's distributed?

With that in mind, let's go back to the fact that gopher was designed to be a distributed system. In that single line of gopher you have just seen, you'll notice it has a URL and a port in it. You might rightly wonder why each and every line of gopher requires a URL and a port, shouldn't the client just remember that from the first request, seems like a waste to include it every single time?

Because every line of gopher in a listing has a server URL and a server port, we can actually create gopher servers that point users to other systems, without them really feeling like they have navigated away from the initial gopher hole they visited. At the time when gopher was in active use, this enabled campuses to essentially have one or more "root" servers, that held a source of truth of where other gopher servers existed, and what they were used for. Let's say that root server was really simple, when you request a directory listing from it (CRLF), it just returned a list of the different departments within the university (each with a different URL!), and with an empty selector string. From this point, a user could navigate to the department they were interested in, and the gopher server on the receiving end has no idea that the user actually came from a root server, it just sees a connection coming in asking for it's listing (CRLF).

Essentially, the ability to be able to point users to other gopher servers in such a manner meant that server administrators had an easy time creating redundant and highly available gopher servers.

## Gopher + Javascript = 😎

Coming soon! Stay tuned for a detailed explanation on the abstractions that we can build on top of gopher using javascript to create some pretty cool applications! gopher.koryporter.com:70 has a neat JSON viewer in it, all you have to do is give a link to a JSON file, and it will do it's best to display and let your traverse through the contents of the JSON.

## Thanks

If you've made it this far, thanks for reading! Gopher has become a little bit of a pet passion for myself, and if you have any feedback or just want to chat about gopher, feel free to send me an email, you can find it at the bottom of this page.

## Resources Used

- http://discussions.mnhs.org/collections/2012/03/why-is-minnesota-the-gopher-state
- https://www.ietf.org/rfc/rfc1436.txt
- https://en.wikipedia.org/wiki/Gopher_(protocol)


Kory Porter

Tech enthusiast, plant guy, loves a beer.
Some wiffle waffle about me.

My Advent of Code 2022 Journey

More Stories

Gopher, the Father of the Internet

Kory Porter

Tech enthusiast, plant guy, loves a beer.Some wiffle waffle about me.

My Advent of Code 2022 Journey

More Stories

Gopher, the Father of the Internet

Tech enthusiast, plant guy, loves a beer.
Some wiffle waffle about me.