
# Hero Images 
The only image I can come up with to appropriately head a "personal" website are hero images, you know, the large image background that takes up the whole page. 

![Hero Image on this website](/images/projects/cloudflare-cdn/home.png) 

They look modern, sleek, and capture the idea of the page (sometimes or are just aesthetic). The only problem is they are slow, very slow. Traditionally, the solution to this is through aggressive caching and edge CDNs, things that are also historically quite complex and expensive. However, probably my favorite company in Technology [Cloudflare](https://cloudflare.com) has changed things once again by making it both affordable and relatively easy to set up. 

# Cloudflare Images 
Cloudflare announced their [images/video service](https://www.cloudflare.com/developer-platform/products/cloudflare-images/) a while back which was great and all, but it had one large red flag to the average self-hoster like myself, it had a minimum plan price of $5!! While this is not that much, I was determined not to have to pay for these features. And as it turns out, they support just that, with 5,000 image transformations per month from a remote source for free! 

And the backend to store these images? Well in theory this could just be the website itself, for example using the Cloudflare Images proxy you simply append the snippet `/cdn-cgi/image` to your domain to have the worker process it-

> cdn.meyersa.com/cdn-cgi/image/https://meyersa.com/images/projects/cloudflare-cdn/dalle-background.webp 

Or I could do the even more overkill thing, and use R2 as the background so it appears cleaner-

> cdn.meyersa.com/cdn-cgi/image/images/projects/cloudflare-cdn/dalle-background.webp 

Simply by making an R2 bucket and by having the access URL be `cdn.meyersa.com` and since there are no egress fees on R2, this means it's basically free (probably like $0.01 a month for image hosting). 

# Performance Improvements 
Using Image Transformations does a couple of notable things 

1. Compression: Images are compressed into AVIF or WEBP making them substantially faster than traditional jpeg/jpg or whatever the original upload was.
2. Caching: Images processed by transformations are therefore cached on Cloudflare's edge. Making them quite fast. 
3. Resizing: Just like the NextJS loader, Cloudflare will adjust the quality and size of images, making them better fit the space they are filling - even using the same logic as the `<Image />` component. 

This ends up having images come out much smaller and faster (this is without local cache)

![Images on network tab](/images/projects/cloudflare-cdn/network-tab.png) 

# Static Assets 
With how NextJS bundles the program, Cloudflare can also be used to serve those assets. This can be added quickly in the `next.config.js` file.

```js
const isDev = process.env.NODE_ENV === 'development';

module.exports = {
  output: "standalone",
  images: {
    remotePatterns: [
 {
        hostname: 'cdn.meyersa.com',
 }
 ],
 },
  assetPrefix: isDev ? '' : 'https://cdn.meyersa.com',
};
```

Just make sure that when you sync your assets, you are keeping the JavaScript prefix `/_next/static` or Next will be unable to load them. 

# Integrating into CI/CD 
With static assets changing on, well, every change, keeping up with them could be a little difficult. However, CI/CD saves the day here with the possibility of running this during the build pipeline. I simply added another job on the main push for when features are deployed that pushes everything to my bucket via AWS CLI. 

```yml
# Build NextJS Prod...

- name: Sync static files to Cloudflare R2
  run: |
 aws s3 sync .next/static/ s3://${{ secrets.R2_BUCKET }}/_next/static \
 --endpoint-url ${{ secrets.R2_ENDPOINT }} \
 --checksum-algorithm CRC32
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.R2_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.R2_KEY }}

- name: Sync public files to Cloudflare R2
  run: |
 aws s3 sync public s3://${{ secrets.R2_BUCKET }} \
 --endpoint-url ${{ secrets.R2_ENDPOINT }} \
 --checksum-algorithm CRC32
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.R2_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.R2_KEY }}
```

# Results 
In the end, it seems page load times are the same as before around `250ms`. The reason for this is definitely that serving the static assets from R2 is not as fast as it should be, but the images make up for it. For me, this trade-off works as I can both be proud the site utilizes a CDN as well as serve slightly higher quality images without worrying about the overhead. So all in all, I would say this was still a success. 

CloudFlare CDN

 

# Kilimanjaro
We trekked up Mount Kilimanjaro to the first base camp, passing through a range of ecological zones. The route took us through lush montane forest, where we encountered several species of monkeys, including the striking black-and-white colobus. Although it started downpouring and it wasn't quite as fun to continue going up. 

![Blue Monkey on the Kilimanjaro trail](/images/photography/tanzania-2025/kilimanjaro-blue-monkey.jpg)

# Tarangire
Tarangire National Park lived up to its reputation as an elephant haven. Massive herds roamed freely, often congregating around the Tarangire River, which serves as a crucial water source during the dry season.

![Line of elephants](/images/photography/tanzania-2025/tarangire-elephant-line.jpg)

African elephants are the largest land animals on Earth, and their complex social structures are matriarchal—led by the oldest female in the group.
![Elephants up close](/images/photography/tanzania-2025/tarangire-elephant.jpg)

The park was also filled with zebras, often seen grazing near elephants for safety in numbers.
![Group of Zebra](/images/photography/tanzania-2025/tarangire-zebra.jpg)


# Serengeti 
As our guide described it, the Serengeti is “the buffet”—a vast savannah ecosystem teeming with nearly every iconic African species.

Olive baboons are known for their intelligence and strong family bonds. Mothers are highly protective and infants cling to them constantly in the early months.
![Mother with child Baboon](/images/photography/tanzania-2025/serengeti-baboon.jpg)

Cheetahs are the fastest land animals, capable of reaching 60 mph in short bursts. Their tear-like facial markings help reduce glare during daytime hunts.
![Cheetah with cubs watching from rock](/images/photography/tanzania-2025/serengeti-cheetah-cubs.jpg)
![Cheetah close up](/images/photography/tanzania-2025/serengeti-cheetah.jpg)

Giraffes have the highest blood pressure among land animals to pump blood all the way up their long necks - which protects them from predators except when they are leaning over to drink and are vulnerable. 
![Giraffe head-shot](/images/photography/tanzania-2025/serengeti-giraffe.jpg)

Though hippos look docile, they’re one of Africa’s most dangerous animals. They can run surprisingly fast and are fiercely territorial in water.
![Hippo with scars getting into Hippo pool](/images/photography/tanzania-2025/serengeti-hippo.jpg)

Male ostriches are recognizable by their black-and-white plumage, while females are a dusty brown. They are the fastest birds on land, capable of sprinting over 40 mph.
![Male and female Ostrich walking](/images/photography/tanzania-2025/serengeti-ostrich.jpg)

Servals are medium-sized wild cats with exceptionally long legs and oversized ears, making them expert hunters in tall grasses.
![Serval hunting in tall grass](/images/photography/tanzania-2025/serengeti-serval.jpg)

Although lions typically rest on the ground, tree-climbing behavior—especially in sausage trees—is observed in regions where the ground is hot or buggy - but looking at the picture they seem to be dealing with bugs regardless.
![Lion hanging out in sausage tree](/images/photography/tanzania-2025/serengeti-tree-lion.jpg)

# Ndutu 
While we missed the peak of the migration in Ndutu, the area still offered plenty of wildlife. We encountered multiple lions and the small, elusive dik-dik antelope.

![Lion cub yawning](/images/photography/tanzania-2025/ndutu-cub.jpg)

Wildebeest participate in the Great Migration, one of the largest terrestrial mammal movements on Earth, traveling over 1,000 miles annually.
![Wildabeast running across the plains](/images/photography/tanzania-2025/ndutu-wildabeast.jpg)


# Ngorongoro 
The Ngorongoro Crater, a massive volcanic caldera, offers one of the most concentrated wildlife viewing areas in Africa. Before it erupted, it would have been taller than Kilimanjar. While we saw a Black Rhino, it was almost too far for a clear photo.

![Eland watching](/images/photography/tanzania-2025/ngorongoro-eland.jpg)
![Hyena stalking the crater](/images/photography/tanzania-2025/ngorongoro-hyena.jpg)
![Zebra with birds flying around](/images/photography/tanzania-2025/ngorongoro-zebra.jpg)


# Manyara 
Lake Manyara National Park is small but incredibly biodiverse. Its dense forest and marshland support elephants, monkeys, and prolific birdlife.


![Baby Blue Monkey eating](/images/photography/tanzania-2025/manyara-blue-monkey.jpg)
![Bull elephant next to safari vehicle](/images/photography/tanzania-2025/manyara-bull.jpg)

After a long safari, on our final stop in the park, we witnessed the incredibly rare moment of an elephant giving birth—an extraordinary sight, especially considering their pregnancies last an astonishing 22 to 24 months.
![Baby elephant after being born](/images/photography/tanzania-2025/manyara-baby-elephant.jpg)

Tanzania 2025


# Having a website

When my portfolio site was basic and [just a single page of HTML](https://github.com/meyersa/meyersa-v1/), things were a lot simpler. There was really no concern about page load time, impressions, or overall appeal. Instead, it just functioned on it's own. 

Nowadays, this website ranks on Google for random topics and I have it linked everywhere - there's pressure for it to look somewhat enjoyable. Throughout my struggles with the writeup site there was never focus on readability, even now there still is a great lack. But things are changing, I'm by no means a UX or UI person but I've worked on enough web projects to build up some skills and I think it's time they get applied. 

# The plan 

With the site on NextJS, it was no longer reasonable to just tear it down and start from the beginning, as much as I wanted to. The v3 site had some lackluster design choices and needed *another* refresh. 

![V3 "Modern" Design :(](/images/projects/new-meyersa/v3.png)

The plan this time was to ditch all of the aesthetic single pallete automatic darkmode, and just nail one palete. This time, with better spacing, better load times, better usability, and now - better SEO. 

## Improving Spacing 

The first goal was to go through and identify all cases of margin and padding - or at this point **most** cases and either remove them in favor of flex gap or set them to a global variable. The reasoning here being a flex container has the same, margin aided, width between all elements. And global variables (gap is still a global variable) can be changed easily depending on future needs or browser viewports. 

For example, 

```css
.wrapper > div > * {
  margin: var(--small-pad) 0;
}
```

This replaces a static margin with now a dynamic one -- which can be changed for the component, page, or whole site easily. 

Along with this came some planning, my least favorite part about web design. Luckily there were some tools to help - firstly [Figma](https://figma.com) - a pretty industry standard Photoshop-esque tool for making layouts. And secondly - the new age AI version [Relume](https://www.relume.io/) (I found this to be a little cluttered and gave ShadCDN vibes with it not really creating unique components). But Figma was better. My idea had evolved to something more padding aligned and continuous, and thus came the easier part, implementing it and using consistent padding for things to align. 

## Fast Loading

In my experience, two things hinder loading speed the most: images and scripts. Using NextJS, these are both theoretically already account for - except it's more complicated than that.

### Scripts 

Next can optimize scripts by loading them after the content and prevent blocking. This was all good, but I figured since I was only really using jQuery this wouldn't be possible. I instead switched to the slim library and Cloudflare's CDJS and thought it was good. On second look, I realized I wasn't actually using JQuery - so I did the most optimal thing for optimizations and removed it entirely. 

The other large library being called was FontAwesome, which packaged up all of their icons despite not using them all. Luckily there is another strategy for optimizing this, loading it into the project and only packaging icons that are actually used. 

> npm install @fortawesome/react-fontawesome

And now the speed issues would be floated on to build instead of loading! (Great success) These are then easily called later

```js
<FontAwesomeIcon icon={faLinkedin} className="fa-solid"/>
```

### Images 

By default, Next applies lazy loading, image height/width metadata, and blur\*. However this only applies to images that are statically imported - so anything on the dynamic side would suffer from not being optimized. 

OK - so for images are out of the way but close to the top of the page, I was able to fix this by lazy loading their components since they would otherwise be rendered immediately. 

```js 
// Dynamic import slide
import dynamic from 'next/dynamic'
const DynamicImageSwiper = dynamic(() => import("../components/ImageSwiper") , {
  loading: () => <FontAwesomeIcon icon={faSpinner} className="fa-spinner" spinPulse />

})
```

This ended up working pretty well and I was surprised by it's functionality. From there the new component can just be called with `<DynamicImageSwiper />`. 

And for the real kickers - the title images - some additional routes were taken. The first was seemingly something that I believe should have been done by default, dynamic blurring with `plaiceholder`. 

```js
export async function getBlurData(imagePath) {
  const photoPath = path.join(photoDirectory, imagePath);

  try {
    console.log(`Reading file: ${photoPath}`);

    // Read the file as a buffer
    const buffer = fs.readFileSync(photoPath);

    // Generate base64 placeholder
    const { base64 } = await getPlaiceholder(buffer);

    return base64;
  } catch (error) {
    console.error("Error generating blurDataURL:", error);
    return null; // Fallback to no blur if something goes wrong
  }
}
```

This then allows all images, regardless of import or lack of import, to have a blur effect on load. Which greatly sped up LCP times. 

## Better Usability

The main component of improving the usability was ensurable the website was readable. Instead of having a mess of different size fonts and spacing - now things were consistent and elegant and didn't distract from content. 

Before for example a lot of boxes were outlined, something that seems almost toyish looking back. Now, sections are flat on the background, making it feel much more thoughout and modern. 

This also comes with a higher use of icons, something about them really just adds more depth. 

## SEO

The important part - getting things on Google - the pinnacle of writing things online. The benchmark for this being a simple search for `site:meyersa.com` and the builtin lighthouse tests on Chrome. These are broken down into a couple of major areas: 

### Load Times (Reprise) 

Back again are load times, always causing problems. Just kidding, it makes sense when no one has the attention span for a slow website (I sure don't). 

When it comes to load times, an important metric is Largest Contentful Pain - or the time it takes for the majority of the first view to load. In this case, they are images, and after previous optimizations mentioned, they are better but not quite perfect. 

![Lighthouse performance score](/images/projects/chasing-seo/performance.png)
![Network image sizes](/images/projects/chasing-seo/image-sizes.png)

After this is the shift, but luckily most things on this site already had defined height/width so that was a nonissue. 

With the removal of JQuery and optimizations of FontAwesome, scores were looking good. High `90s`, but mainly due to just having such an ambitous goal of a fast loading image as the background. 

### Metadata

Something I haven't really ever used on a website before is metadata options. To start, things like excplicitly setting language in the HTML body, wouldn't even have occured to me until now. 

Taking this a step further, each page not only has a title but also a metadata title. This I found I could set globally in the `_app.js` specifier and then also override per page to ensure page titles. 

```js
<Head>
  <title>Photography - August Meyers</title>
  <meta name="description" content="Showcase of one of my main hobbies - Photography" />
</Head>
```

Finally more broadly are the OpenGraph specifications - but I wasn't even that sure of which ones to use. Frankly I came to the conclusion that these are really only for the big sites where things like ARIA specifications are also being implemented. I set the theme color to hopefully help with embeds and that was about it. 

I also ran into an issue of page naming, for example the site is named after me, but how do I name the home page? Titled August Meyers with the site title also August Meyers? This is where the branding really came into an issue.. 

### Search Agents 

Finally, to make Google happy and make use of all the SEO tweaks is actually getting the crawler on the site. In this case a couple things were missing, such as the Robots.txt file, headers, and a sitemap. 

I ended up making a simple robots.txt file and putting it in the public directory, eliminating that pretty easily. 

```txt
# Allow all crawlers
User-agent: *
Allow: /
```

In the future this should probably get updated to filter out bots though as they can easily hit websites offline at this point. 

The next were headers - and apparently I had noindex set globally(!!) which was not helping things. I removed this on Traefik and I was off to the races. 

Well except for helping Google find the posts pages. Instead of updating this manually, I created an API route and a rewrite to expose a custom document. This ended up being pretty hacky, but the site is actually able to be interpretted by bots now, so that's good. 

![Boring XML contents](/images/projects/chasing-seo/xml-view.png)

# Results 

With all that work done, you would hope the website would be doing better. And you would be hoping right 😎

The page now tracks on Google 

![Google search results](/images/projects/chasing-seo/search-results.png)
![Searching for Jellyfin predictions](/images/projects/chasing-seo/jf-results.png)

And it has a perfect desktop score, with a near perfect mobile score

![Lighthouse final score](/images/projects/chasing-seo/lighthouse.png)

Mission accomplished. Except there are still some more pending issues that I'll have to work on, but that's another story. 

Chasing SEO

## Contents 

# Goal 

Finding movies to watch is often a difficult task for me, nothing sounds appealing anymore, despite there being plenty of good options. I had the idea - what if I could take tons of metadata about movies I had liked in the past, and then train a machine learning algorithm on it to understand movies that could be similar without me even knowing? 

With that in mind, movie metadata such as: 

- PremiereDate
- CriticRating
- OfficialRating
- Overview
- TagLines
- Genres
- CommunityRating
- ProductionYear
- People
- Studios

And lots more will be used to try and find patterns. 

## Jellyfin? 

Jellyfin is a media library frontend, but more importantly, it's home to a lot of metadata. Basically, I can connect to Jellyfin and read information about lots of movies - similar to Trakt but I can host it on my own hardware, meaning I can go crazy with API queries. 

Importantly, this is just a home to metadata for me, to build a "watch history" to make predictions on where I can then watch the movies `legally`. 

# Procurement

The first step was to find a way to gather all of the movie information, hopefully with an API. While Jellyfin does not have much documentation on the underlining API, Emby - the platform Jellyfin is forked on - [does](https://swagger.emby.media/?staticview=true). From here the ItemService route was located and a query was set up. 

![Swagger UI](/images/projects/jf-prediction/swagger.png)

P.S. Swagger is a literal lifesaver when it comes to any kind of API work 

Similarly, to enrich the movie data, Jellyfin groups movies into Collections, or series, which can be polled separately. 

And when doing this I found a neat trick to preserve order while iterating without using a count variable. This also helped me avoid a double iteration loop, theoretically reducing computation by a lot by somehow making it a little slower in practice. Who knows... Maybe it's scalable now.

```Python
for order, movie_data in enumerate(movies_in_collection, start=1)
```

# Processing

Due to the wide variety of data, many types of processing will have to be utilized as well as feature engineering to have a better understanding. 

## Fast Text 
Text vectoring for values such as: 

- Title
- Overview
- Tagline

```Python
combined_embeddings = np.vstack(combined_text.apply(lambda x: get_fasttext_vector(x, self.fasttext_combined_model)))
combined_embeddings_sparse = csr_matrix(combined_embeddings)
```

Adds a lot of computation but theoretically grabs possibly useful ties from information in the text. 

## Date Engineering

Taking the premiere date, converting it to a Pandas date, and then abstracting things such: 

- Year
- Month
- Day
- If it is a weekend
- The week of the year
- And the day of the year 

```Python
df["PremiereDate"] = pd.to_datetime(df['PremiereDate'], errors='coerce')
```

Pulling out these other values from the date could lead to more patterns being uncovered by the model.

## Scalar 

Numerical data such as: 

- Community Rating
- Collection Size 
- Production Year 
- Age since the last movie
- Length of the movie 

This can then be flattened with a normalizer, but with giant data such as FastText involved there probably is no point. 

## Onehot

Values consistent across multiple entries such as: 

- Community rating 

This allows for the model to understand abstract values without converting them into numerical values. 

## MultiLabelBinarizer

Values sort of consistent but in lists such as: 

- Actors
- Genres
- Studios

These values are all "consistent" but they are in lists rather than strings, so it creates many Onehot values. 

## Ordinal 

Ranked values, such as: 

- Ranking of movies in the collection 

This does a sort of scalar value, but in a way that the model can see and preserve order. 

## Binary

The simplest value, just 0 or 1, for things such as: 

- Favorite
- Is Weekend
- First in collection 

## Finally 

For the model to understand this, it's also converted into a sparse matrix and stacked, which has the unfortunate property of removing column names making it hard to understand. 

```Python
final_sparse_matrix = hstack([
 scaled_numerical,               # Scaled numerical data
 combined_embeddings_sparse,     # Unified FastText embeddings
 role_features,                  # Role count features
 date_features,                  # Date encoding features
 official_rating_encoded,        # One-hot encoded Official Rating
 collection_name_encoded,        # One-hot encoded Collection Name
 genres_encoded,                 # Multi-label binarized Genres
 people_encoded,                 # Multi-label binarized People
 studios_encoded,                # Multi-label binarized Studios
 binary_features_sparse,         # Binary features for first in Collection
 ordinal_features_sparse         # Ordinal Features for Collection Order
])
```
After MLB and Onehot, there are far too many features to be usable, so this can be reduced with TruncatedSVD. 

> This greatly improved F1

# Training

Using a standard 80/20 split, a Random Forest model will train on the dataset since it provides a good balance of accuracy and speed. 

To ensure the best hyperparams, a grid search will try all relevant parameters. 

```Python
# Hyperparameter grid
param_dist = {
    'n_estimators': [200, 500, 1000],
    'max_depth': [10, 20, 50, None],
    'min_samples_split': [1, 2, 8, 16],
    'min_samples_leaf': [1, 2, 4, 8],
    'bootstrap': [True, False],
    'criterion': ['gini', 'entropy']
}

# Model and scoring
rf = RandomForestClassifier(class_weight="balanced", random_state=42)

# RandomizedSearchCV
random_search = RandomizedSearchCV(
    estimator=rf,
    param_distributions=param_dist,
    scoring='f1',
    n_iter=20,
    cv=5,
    verbose=2,
    n_jobs=-1,
)
```

On a 9900K 100 fits took about 30 seconds with TruncatedSVD, without it took about 2 minutes. The optimal model was found to be `200` estimators, `2` minimum sample split, `8` minimum samples per leaf, `20` max depth, with `entropy` and `bootstrap`. It didn't end up being as complex as I was thinking, but that does mean it won't suffer as hard from overfitting (in theory).  

# Pipeline 

With the end goal of this project to be able to use it real world, everything was made with a sklearn Pipeline, allowing for the whole project to be easily called. 

```Python
data_pipeline = Pipeline([
 ("jellyfin_client", JellyfinClient(URL, USER_ID, API_KEY, played_status="IsPlayed")),
 ("data_cleaner", MovieDataCleaner(columns_to_keep)),
 ('feature_engineer', MovieFeatureEngineerWithFastText()),
 ('TSVD', TruncatedSVD(n_components=X_train.shape[0]))
])
```

Theoretically, this also scales well so that is another plus. 

# Results

Immediately going into this, there are some big doubts. For example, why do I like certain movies? Who knows. So the trends are probably nonexistent. Surprisingly though, it trained pretty well... 

| Evaluation Metric | Value | 
| ----------------- | ----- |
| **Accuracy**      | 0.6944|
| **Precision**     | 0.6375|
| **Recall**        | 0.9273| 
| **F1**            | 0.7556| 
| **AUC**           | 0.7966| 


| Confusion Matrix | Predicted False | Predicted True |
|----------------- |-----------------|----------------|
| **Actual False** | 24              | 29             |
| **Actual True**  | 4               | 51             |

For guessing movie recommendations with little to no consistency this ended up being impressive. An F1 of 0.76 means that it isn't quite guessing, it's actually making real decisions. An accuracy of 0.69 means that it also is decent at making those decisions. Looking at the Confusion Matrix, it does very well at predicting the true positives but suffers from false positives. 

Early iterations before I had included collection (Movie series) information suffered much worse in this department. Overall it seems with the added information it predicts pretty well. 

I am a little disappointed though as I was hoping this would have achieved an F1 of 0.8 and it felt like it was so close to crossing that bridge for a while. In the end, I do really think it just comes down to this being random guesses so it even boggles my mind a little that it can form these predictions. 

Aligning with my suspicions are the real recommendations, which only score as high as 0.67 and as low as 0.37 meaning that it really has no strong ideas. 

# Discussion

With FastText for text vectoring the model is a little sluggish on preprocessing, but the actual predictions are fast. This makes me believe it could be integrated into Jellyfin as a plugin that occasionally runs to build recommendations - not like the "You watched this, try this" recommendations, but because you've watched everything you have, this different thing could be cool - something I would find very useful. And since most Jellyfin servers are already pretty beefy, this could easily run in the background. 

Jellyfin Predictions

## Contents 

# Intro

Finding an idea to work on for a thesis project is quite difficult. It turns out that it's something you spend a lot of time working on and even more time researching. Finding something that is intriguing but satisfies the broader goal is even more complicated. But then it hit me, I could be like Bill Harding from Twister and predict tornados, but use Machine Learning instead of a magical power. 

# Plan 

Just like any great project, it starts with realizing that MIT did it first (and probably better). 

Training machine learning models is all about having a quality dataset. Originally, I had been poking around NOAA's NSSL radar archives, but these are pretty intense. There are a lot of hoops to go through when downloading data and the amount of data they present is in much broader areas and is not labeled. 

MIT made this a nonissue with the [TorNet](https://news.mit.edu/2024/tornet-ai-dataset-carves-new-paths-tornado-detection-0429) dataset, which compiles radar images into a nice, easy-to-train dataset that has already been labeled. 

![TorNet sample Radar sweep](https://github.com/mit-ll/tornet/blob/main/tornet_image.png?raw=true)

# Implementation

While MIT had trained demo models on this dataset, they were limited by the size of their models, such as using a `2-D` Convoluted Network by dropping the timeline. 

Adding back this data timeline, we were able to make this into a `3-D` model, which transforms this into temporal data and has the opportunity to greatly increase the model's performance. 

## Procurement

MIT hosts this dataset on [Zenodo across multiple archives (2013)](https://doi.org/10.5281/zenodo.12636522). However, Zenodo is pretty slow for downloading, and planning for the future I decided to try and store this somewhere a bit faster. 

The first step was to download it locally with Aria2c, which took about 6 hours, and then upload it to Backblaze S3. 

```Python
def upload_files(file_list):
    """
 Upload files to Backblaze B2 using the b2 CLI.
 """
    for file in file_list:
 command = ["./venv/bin/b2", "file", "upload", BUCKET, file, file]
        try:
 logging.info(f"Uploading '{file}' to B2...")
 subprocess.run(command, check=True)
 logging.info(f"File '{file}' uploaded successfully.")
        except Exception as e:
 logging.error(f"Failed to upload '{file}': {e}")
            exit(1)
```

This was made pretty easy thanks to Backblaze's Python SDK. 

In the future to inhibit egress fees and better load across the world (important for later) it was put behind Cloudflare through a generic CNAME proxied record. For this, you simply add the Backblaze endpoint (f000.backblazeb2.com) as the content and then when you access it, it ends up being

> https://`proxy`/file/bucket/`file_name`

## Processing 

With the amount of files in TorNet, over 200,000, it just crashes the Python kernel on loading with Keras. To avoid this, the records are parsed with TensorFlow and serialized into a TensorFlowRecord (TFRecord) that can then be fed into the model. 

Without including too much code, 

```Python
with tf.io.TFRecordWriter(output_path) as writer:
    for file in tqdm(files, desc=f"Processing year {year}"):
 features, label = parse_nc_file(file)
        if features is not None:
 example = serialize_example(features, label)
 writer.write(example)
 local_label_counts[label] += 1  # Update local counts

print(f"Completed {year}: {len(files)} files")
return local_label_counts
```

The TFRecord can be called through a writer object which can write serialized data. Since this works through the TensorFlow data pipeline, it also scales across CPU cores making it a pretty efficient way to parse data. Notable, it does create very large records even with smaller data types that essentially double the on-device storage requirements. 

In this processing step, other things such as counting weight values, normalizing values, and removing NaN/flagging values occur. 

## Multi GPU 

Before training, it was also important to take advantage of multiple GPUs - since that's generally more cost-effective for training. TensorFlow provides a default strategy for this, again making it quite easy. 

```Python 
strategy = tf.distribute.MirroredStrategy()
```

## Parsing for Model 

With TFRecords created, they then have to be loaded back in and prefetched for the model. 

```Python 
parsed_example = tf.io.parse_single_example(example, feature_description)
```

Normally, data would have to be split here for training, but TorNet already had the dataset split - so they were loaded as two "separate" datasets. 

## Model Definition 

With the large amount of data, and crazy class imbalance (`189267` Non-Tornados to `13857` Tornados), I added a lot of complexities to sort of boost the abilities of training. 

- `Batch Normalization`: to try and aid in faster convergence and retain stable training. 
- `Leaky ReLU`: add additional activations to avoid dying neurons and enhance gradient flow. 
- `Spatial Dropout`: prevent overfitting by dropping feature maps randomly 
- `L2 Regularization`: add weight penalties to prevent overfitting 
- `Class Weights`: use the exact class amounts to avoid imbalance in training 

And of course, this is all done on a sequential 3-D CNN which had 6 3DConv layers and a final Sigmoid dense layer for binary classification.

All in, this ended up with about `886,337` parameters, which is not too many. 

## Training 

With about `200,000 images` and a batch size of 8, that led to about `25,000 steps`. As predicted, the training time with this model on TorNet was abysmal. On an RTX4060 locally, it was taking about `2 minutes` per step. Multiple that by 25,000 - and yeah, that was not happening. 

Moving to cloud GPU provider, [Vast.ai](https://vast.ai), I could then take advantage of bigger and faster GPUs, such as an NVIDIA LS40. Which dropped step time to `10 seconds`, and epoch time to almost `3 days` - which was still not going to happen. 

Finally, optimizing with multiGPU TensorFlow strategies, I landed on using 4 NVIDIA RTX4090s, which provided much better value for VRAM and TeraFlops, at about `$1.6 an hour`. With this instance, it was training at about `157 ms` per step, or about `30 minutes to an hour` per Epoch. 

> With Multiple GPUs, the batch was effectively multiplied by the amount of GPUs, so about 32. Meaning it required many less steps as well as training at less time per step. 

With a high training time, and a risk of the kernel still crashing, checkpoints were utilized to a directory that was synced to Backblaze. 

To ensure that only positive training would happen and stop the training as soon as it finished, EarlyStopping was added - and configured to default to the best weight. 

# Results 

In the end, the model performed okay - and even an improvement over other models that had been trained, such as MIT's 2-D CNN. 

![Result metrics](/images/projects/tornado-prediction/results.png)


Looking at Precision and Recall over time, it's clear the model was not fully converging, and it struggled to lock down on predictions. 

![Training vs. Validation Precision](/images/projects/tornado-prediction/training_vs_val_precision.png)
![Training vs. Validation Recall](/images/projects/tornado-prediction/training_vs_val_recall.png)

# Discussion 

In the future, I believe that the model could improve based on more context - which would help it converge better. For example, providing additional data from NOAA such as area weather information or Satellite imagery - in a combined model. 

This also provided a lot of insight into training as Vast's prices were not too bad, and are something I would use to aid in training time in other projects. Also as it turns out, it's nearly impossible to even get a GPU from other providers such as Oracle or Vultr, as they make you jump through tons of loops. 

Tornado Prediction

## Contents 

# Vision
In preparation for my Master's thesis, trying to better predict tornados by combining satellite images and Doppler radar, I decided to try a small project to grasp the combination of metadata for context with images. One of my professors offered up an idea for this, utilizing trail camera pictures of deer with the onboard sensor data. This data consists of the wind, the moon phase, temperature, time, and more, all things that could provide additional insight into deer behavior and predictions. 

# Goals
- Make a layered Convoluted Neural Network model for images and time series data
- See if Metadata improves model accuracy
- Try and beat the trail camera manufacturer's model

# Data Collection
The images for this project came from a trail camera, which uploaded images to the cloud. Gathering images would consist of inspecting the web requests, finding the endpoint, and finding the authorization token. Easy enough. After this, images would have to be downloaded from the endpoint, in this case, s3. 

At this point, I did come to the unfortunate realization that there were only about 3,500 images. This made the acquisition much easier but did not have great hopes for the model itself. 

Moving on to tagging, I utilized a small Python Tkinter program to pull up the image and then put the labeled result in a JSON. Not as impressive as something like RoboFlow, but it got the job done and allowed me to get through the 3,500 images pretty fast. 

![Labeling Program](/images/projects/deer-identification/label_program.png)

# Data Processing
Once images were imported, the metadata was cleaned up and dumped into a CSV along with the image location, which would be fed into the model. Additionally, the metadata would have to be regularized, and from suggestions of ChatGPT, formatted into standardes like cyclical and binary indicators. The images were then downsized to the usual 224x224, and the pixels were flattened. 

I had originally planned also to remove duplicate images - which became an entire process of trying to reverse engineer a Python library that was originally written to be a command line tool (which I got working) but ended up not being needed since it removed too many images and reduced the training set substantially. Also technically the images were not duplicates since the metadata would separate them, but that was beside the point. 

When processing the images, the small border at the bottom containing basic metadata was also stripped. It did occur to me that this strip was essentially feeding metadata into the model, rendering this technique a little useless, but the tornado data would not have this embedded so it still stood. 

# Training
With a mixed input of images and metadata, this model would be a little more complicated than things I had worked on before. My first idea was to simply train two models - and then combine them. 

The metadata would consist of a dense neural network, with only one layer since the information is pretty light. 

![Metadata-Only Results](/images/projects/deer-identification/Metadata-Only_Metrics.png)

While the image model would be a convoluted neural network, with a couple more layers. 

![Image-Only Results](/images/projects/deer-identification/Image-Only_Metrics.png)

To optimize this model with the small dataset, the amount of layers was kept small and dropout was not trimmed too aggressively. Additionally, I tried other methods like Transfer learning from ResNet or ImageNet but this resulted in lower accuracy. 

![Transfer Learning Results](/images/projects/deer-identification/Transfer_Metrics.png)

To expand the dataset, I also tried Augmentation, but that also lowered the accuracy. 

![Augmented Results](/images/projects/deer-identification/Augmented_Metrics.png)

And finally, the combined result of the image and metadata model. 

![Combined Results](/images/projects/deer-identification/Combined_Metrics.png)

# Results
As a baseline, the original trail cam manufacturer's accuracy versus my manual tagging was about `92.24%`. Unfortunately, none of my models came close to that - and unlike the manufacturer's model, they did not tag species or locations in the images. But this was to be expected as they most likely used some kind of YOLO model and trained on a lot more data - outside of the scope of this project. 

The really unfortunate part was that the accuracy of the combined model, at about `90.61%` was less than the image model, at `91.55%`. Looking at the low accuracy of the metadata-only model at `72.3%`, this is likely explained by inconsistent metadata with deer spottings. So maybe the idea wasn't the best... 

Until you consider the performance. The evaluation time for the combined model was `0.798 seconds`, compared to the image-only time of `2.058 seconds`. Showing that the improvements of the metadata substituting might not only show in accuracy but show significantly in prediction time. Over half the amount of time required. That's impressive. 

Looking at the accuracy graphs, the combined model does not do the worst either, in fact, it's pretty close to the best-performing image-only model. 

![Accuracy Comparison Graph](/images/projects/deer-identification/Comparison_of_Model_Accuracy.png)

And looking at the evaluation time graph, it also strays far away from the worst performing. 

![Evaluation Time Comparison Graph](/images/projects/deer-identification/Comparison_of_Model_Evaluation_Time.png)

Overall, I would consider this a success. While the accuracy took a hit, it remained high at `90.61%`, and seeing a noticeable performance increase over the image-only model is more impressive.

# Discussion
Many of the limitations faced by this project were because of the small dataset. The model had to be kept small, as complex models did worse by just memorizing specific things. Dropout and overfitting prevention were not an option as they would just forget all important details. In general, the testing data was probably just similar to what the training data was on and it probably just memorized features anyway. 

With a larger dataset, it would be interesting to return to this and try and gather more information about weather from other sources to make this a stronger metrics-aided image prediction model. 

If this worked well, it could be combined with other cameras to have a higher degree of accuracy in predicting deer in trail cameras and suggest things like where to hunt based on confirmed deer movement. 

Deer Identification

## Contents 

# Intro/Inspo

To demonstrate the advantages of service-based architecture and cloud services in general - I took on a venture to modify an existing project into a cloud-ready project. In general, being cloud-ready means that the project is not based upon a single point of failure or monolithic service, instead, it breaks up as much as possible into smaller services. This provides advantages for performance being able to scale up the amount of services and being able to load balance across multiple servers. There are many more advantages, but that's something I'd have to focus on in an upcoming wrap-up for my migration to Kubernetes.

# SmartCityTracker

The perfect contender for this project would have to be something unique, interesting, and cloud-applicable. Originally, my goal was to use one of the previous senior design projects at CMU - however, it seems that none of them utilized GitHub so this was not possible...

In my search, I found [SmartCityTracker](https://github.com/caimeng2/SmartCityTracker), a database of smart city innovations that was scraped from Google and compiled into a viewable database. This project consisted of a [Zenodo](https://zenodo.org/records/7670784) database with all of the information and a [web UI](https://caimeng2.github.io/SmartCityTracker/) to display it.

The problem? The information displayed was downloaded from Zenodo as a JSON in a javascript file and uploaded manually into the index.html of the project. When you visit the site, all of this was loaded, despite only a fraction of it being displayed.

This means that every time the database is updated, the HTML root has to be uploaded, leading to things like gigantic nested loops of HTML.

![Nested HTML to load all of the data](/images/projects/cloudsct/nested-html.png)

# Disaggregating

To keep things fairly simple, the breakdown here would be to separate the frontend from the backend and the data from static assets.

## Frontend

The new service for the frontend simply serves static HTML when you visit the page which has been modified with API calls to load data when it is accessed - instead of all at once. When data is requested from the new API, it pulls it from Firestore, leaving it to be completely dynamic.

### Implementation

The first step for breaking up the datalink was to rip out all of the old. This meant the giant nesting would have to go, as well as most of the outdated Leaflet libraries - which restricted the kind of loading that could happen - or would have at least required me to find some outdated docs to do it.

The map works by displaying a layer of the Smart City data, in this case, it's a month and it's an entire JSON. To navigate the data, there is a slider, which corresponds to the month you are viewing.

![Slider](/images/projects/cloudsct/slider.png)

This complicates things a little as the slider requires all of the timestamps to be known for it to populate. Previously this was done by loading all of the layers at once into the slider, requiring all of the data. Breaking this up would be a little more complicated since it would have to be loaded with unknown data. Fortunately, Leaflet allows this to be done by just creating the input range (vanilla HTML) with the number of timestamps - which can be gotten with a Firestore query.

```JavaScript
const snapshot = await db.collection("data").get();
const files = snapshot.docs.map((doc) => doc.id);
```

And then fetched and passed through to the slider...

```JavaScript
sliderElement.type = "range";
sliderElement.min = 0;
sliderElement.max = timestamps.length - 1;
sliderElement.value = timestamps.length - 1;
sliderElement.step = 1;
```

Boom. Too much time was wasted trying to figure out how to do this with a Leaflet slider when the answer was so much more obvious. But, there was still the second half of this, dynamically loading the data into the layers using a GeoJSON? I still have no idea what that is - but that's the fun part.

Originally, this was done by loading all layers at once. And you cannot just add layers dynamically, instead as it turns out you can delete the current map layer and display a new one - which works just as seamlessly.

```JavaScript
if (currentGeoJSONLayer) {
    map.removeLayer(currentGeoJSONLayer);
}

// Add new GeoJSON layer
currentGeoJSONLayer = L.geoJSON(data, {
// Add icon
pointToLayer: function (feature, latlng) {
    return L.marker(latlng, { icon: customIcon });

},
// Add popup
onEachFeature: function (feature, layer) {
    layer.bindPopup(`
        <h3>${feature.properties.title}</h3>
        <p>${feature.properties.description}</p>
        <a href="${feature.properties.link}" target="_blank">Read more</a>
        `);
    },
}).addTo(map);
```

This solved some pretty major problems and made it easily off to the races. However, by far this was the biggest obstacle. 

### Closing thoughts

In a perfect world, the API could be separated into another service, but there simply is not enough traffic to justify this and the dataset is pretty lightweight as it is. However, if it came down to it, separately the two would allow for much easier scaling of the data. And if it came down to it, Firestore can directly be accessed by clients, eliminating the need for an API.

In a similarly perfect world, I would not have rewritten the entire project including the HTML and CSS, but here we are. Welcome to the fully redesigned Cloud SmartCityTracker!

![Web UI](/images/projects/cloudsct/ui.png)

## Backend 

With the data no longer being manually imported, it would have to be pulled through other means - directly from Zenodo. This fixes an entire step in the update pipeline and would make the project pull from a single source of truth instead of relying on multiple updates. 

### Pulling from Zenodo 

Zenodo is kind enough to offer a developer API, which allows for downloading files from projects - and even without API access. 

This meant that pulling the database would be as simple as... 

``` JavaScript 
const response = await axios.get(zenodoURL);
```

But the data is zipped which adds a fun extra step of unzipping. It was at this moment I also realized that Zenodo was not being used as a data source, instead it was shipped with the web UI. So on top of unzipping, the /assets/data directory would have to be pulled. 

```JavaScript
await new Promise((resolve, reject) => {
    fs.createReadStream(zipPath)
 .pipe(unzipper.Parse())
 .on("entry", (entry) => {
        if (entry.path.includes("/data/") && entry.type === "File") {
        // Copy to extraction dir
        const extractPath = path.join(extractDir, path.basename(entry.path));
        entry.pipe(fs.createWriteStream(extractPath));
        console.log(`Extracted ${entry.path}`);
 } else {
    // Skip
    entry.autodrain();

 }
 })
 .on("close", resolve)
 .on("error", reject);
});
```

With the datafiles located, it was time to upload to Firebase. 

```JavaScript
await db.collection("data").doc(documentKey).set(jsonData);
```

And just like that, the data upload pipeline had been finished. 

### Sike 

So as it turns out, the Github was the golden source of truth in this project and Zenodo has not been updated since 2023. Anyway, I'm still going to pull from Zenodo and pretend like this is the most recent data. 

## Firestore

This part is not as exciting and was actually quite boring. Basically, you just create a GCP Project to organize the environment, create a Firestore NoSQL database, create a service worker, add `Database User` to the service worker, generate an auth token, install the Node.js SDK, and you are off to the races. 

# Conclusion 

All in all, this project turned out to be pretty interesting. I love throwing myself into projects that I know absolutely nothing about and having to learn a ton of new information. In this case, I learned what a smart city was, how to interact with Firebase, and how to use Leaflet. 

I also reinforced my ego on web design. But that's not as important.

# Technologies

- Docker
- Node.js
- ExpressJS
- Axios
- GCP/Firebase/Firestore
- Zenodo


CloudSCT

 
## Contents 

# Why does there need to be a V3
Simple. The current site, v2, was not up to par with my current skill level and the information was mostly outdated. Also, I was a little ashamed to include the link on my LinkedIn or Resume since it was a little ugly looking back... 

The iterations of portfolio sites began with [version 1](https://github.com/meyersa/meyersa-v1) to show off my experience and knowledge without just uploading my Resume PDF online. From the beginning, it was hosted on the domain [meyersa.com](https://meyersa.com) and on my own servers, which was pretty impressive for a freshman in college at the time. 

![v1 Website](/images/projects/new-meyersa/v1.png)

Over time this iteration of the site began to have more downfalls, making it apparent that a new site was needed. Since it was one of the first web projects I had ever worked on, it was not mobile-friendly and broke often on new displays. Don't get me wrong, it did not have any px values, it just was not very well thought out. Abstract ideas like blocks floating on the page just did not make enough sense to work without Javascript, and frankly, image centering and manipulation without Flex boxes made it quite atrocious. To combat this, a [v2](https://github.com/meyersa/meyersa-v2) was implemented with some more modern ideologies, but still without JavaScript to keep things simple. 

![v2 Website](/images/projects/new-meyersa/v2.png) 

The second iteration highlighted a new issue: being too basic. While it was more mobile-friendly, utilized better standards, and looked a little better - it still sucked. There was no pop, and honestly, it was distracting how blue it was. A more professional and thought-out website had to be built. Which is where [v3](https://github.com/meyersa/new-web) comes in. 

![v3 Website](/images/projects/new-meyersa/v3.png) 

# Vision 
The new iteration was going to come with some big changes to address most of the issues I had with the original site as well as some other goals I had in mind. 

## Making it More Complex 
While simple is usually better, vanilla HTML and CSS were not cutting it. This time it would be on React utilizing the NextJS framework. This would provide the customizability and reusability that I had loved working on [InstitutionPenguin](https://github.com/meyersa/institution-penguin). 

## Aggregating
At this point, there were two other sites, writeups.meyersa.com (defunct) and photography.meyersa.com (defunct) that were running. But they were equally too small to be their projects. Just like the portfolio on its own was too small. The new site would combine all three into one site that served a greater purpose. 

## Looks 
This time it would be mocked up before implementation and be planned ahead of time. Also catering to the photography portfolio, a viewer would be needed to ensure things looked better - a limitation of the previous WordPress site. 

# Implementation 
While there were a lot of moving parts with this, some of the main ones to consider are the React implementation, a custom photo viewer, and markdown parsing. Anything else would make this too long of a read. 

## React 
Instead of implementing React Native and considering a router to use with it, [NextJS](https://nextjs.org/) has had my attention for a while. I've used it in some other larger projects, and it works well when things get complicated. Under the hood, it's just a wrapper for React and it uses the same ideologies with some web-focused improvements. 

For example, NextJS allows for page templating, which can be used for dynamic entries like the projects directory on this site.

![Project Template](/images/projects/new-meyersa/project-template.png)

With the template, site content can be fetched from a local function, cached, and displayed to all visitors. Components can also be imported and used to display content - another great feature of React. In this instance, a component that I created, TitlePage, is rendering with information passed in from the Markdown files, such as the name and picture. In this component, I can then reference these inputs and use them to render content. 

![TitlePage Component](/images/projects/new-meyersa/titlepage-component.png)

There is nothing more satisfying than defining something once and then using it everywhere.


## Photo Viewer
On the Photography side of the website, images can be clicked on and viewed with more information in a less distracting setting.

![Image View](/images/projects/new-meyersa/image-view.png)

This was something I had always wanted to implement on the Wordpress implementation of my photography portfolio but never did due to the complexity of Wordpress plugins. With NextJS, things were different, it was an easy and approachable JavaScript task. 

The only challenge was popping an image out of its position on the page and making it interactable. Normal approaches would be to just absolute position it and overlay it on top - but in this case, overflow had been hidden to keep the images in a sliding display, making it impossible to pop out the original element. 

Luckily, there's another way: search parameters and react hooks. 

![Search Parameters](/images/projects/new-meyersa/search-parameters.png) 

By adding a query like the image number to the URI, a listener in a separate element can react by popping up the viewer. This eliminates any problems with overflow and even simplifies the process. Furthermore, any changes to the viewer like closing it and moving to another element, can be easily implemented by just changing the value in the query - something that would have been much more complicated otherwise. 

## Markdown Parser
To generate Dynamic content, the go-to solution is markdown. Instead of having a giant JSON that would be stupidly complicated to write every time or making the page for each article, markdown allows a way to just write a page normally and then parse it later into a web page. This takes care of all formatting like h1, p, images, etc., and leaves that to predefined styling - amazing. 

Parsing markdown with NextJS is pretty common, it's even featured in their documentation. However, as always, it's not that simple, and what I wanted to do was slightly different than what they wanted to do. Luckily, the frameworks that I used - remark and rehype, are platform agnostic and had their own documentation and I was able to figure out a way to parse just how I wanted - preserving images and even adding alt text to them later as seen in this post.

# Conclusion 
For the most part, this project has been wrapped up, but it never will really end. There are so many things I want to implement and there will be posts and styling changes coming with time. But importantly, now that it is on a real platform, these changes can be made without restarting the project and it will grow over time. 

# Technologies
- React/NextJS
- GitHub Actions CI/CD
- Docker
- JavaScript
- gray-matter
- remark
- swiper

New Meyersa

 
## Contents 

# Intro/Inspo

One of my friends jokingly mentioned making a website for their RSO to raise awareness and I felt the need to take that seriously. While also having some fun. 

Another one of my hobbies is photography, so the idea of making a website with a lot of original assets sounded like a fun time. The result ended up being pretty nice. 

# Automation 

This project outlined a lot of cool parts (at least I think) of my infrastructure that made this more than possible. To start, having Github actions build a docker image automatically means that when I deploy (manually in this case) all I have to do is specify an image instead of building one. With the existing Traefik router on the main hosts, this also means that Cloudflare was pointing at the right place to begin with, making it possible to build this website and deploy it all within a single day. 

# Final Result 

While it wasn't the most crazy design project - it turned out pretty good, especially for a fast job.

[What it ended up looking like](/images/projects/campusgrows/background.png)

# Technologies 

- Nginx
- LR
- Photography 
- Docker

CampusGrows

 

# Day 1

The first day in Ireland consisted of checking in at our accomodations - Trinity College - who offered student rooms which ended up being dorms. With some free time we decided to explore around the nearby area, including Brampton street (which has no bars) and St. Patrick's Cathedral. The rest of the day maintained a slow pace with a walking tour of campus and seeing the book of Kells, which you cannot take pictures of. 

![Flag's of different families inside of St. Patrick's Cathedral](/images/photography/ireland-2024/st-patricks-flags.jpg)
![Stained glass inside of St. Patrick's Cathedral](/images/photography/ireland-2024/st-patricks-stained-glass.jpg)
![Trinity College old library](/images/photography/ireland-2024/trinity-college-old-library.jpg)

# Day 2

Our first day trip in Ireland ended up being more action packed than I thought - when I booked it I thought it was only going to be a bus ride to Giant's Causeway and a small look at Belfast, but it ended up including a private Black Cab tour of the current politics (including a wall that closes every day) in Belfast. Alongside this was also Dunluce Castle, which provided some amazing views. 

![View from Dunluce Castle](/images/photography/ireland-2024/dunluce-castle-view.jpg)
![View of Dunluce Castle](/images/photography/ireland-2024/dunluce-castle-bird.jpg)
![Giant's Causeway water](/images/photography/ireland-2024/giants-causeway-water.jpg)

# Day 3 

On the third day we made our way to Galway. With some downtime we walked to a lighthouse near the citycenter, but it ended up being a waste treatment facility. The ocean was still a great view though. 

![Lighthouse in the bay](/images/photography/ireland-2024/galway-lighthouse.jpg)
![King's Head Pub](/images/photography/ireland-2024/kings-head-pub.jpg)

# Day 4

Departing from Galway to nearby areas, the first stop was the Aran Islands - specifically Inisheer. This would end up being the cheapest place during the trip to buy Guinness at only €5, which made no sense.

![Lighthouse on Inisheer](/images/photography/ireland-2024/aran-island-lighthouse.jpg)
![Inisheer from a boat](/images/photography/ireland-2024/aran-island-main-island.jpg)
![The boat we road to Inisheer and viewed the cliffs from](/images/photography/ireland-2024/aran-island-boat.jpg)
![Cliffs of Moher from a boat](/images/photography/ireland-2024/cliffs-of-moher-base.jpg)
![Cliffs of Moher from above](/images/photography/ireland-2024/cliffs-of-moher-cloudy.jpg)

# Day 5 

The second and last day trip from Galway was north this time, to the Kylemore Abbey.

![Kylemore Abbey itself](/images/photography/ireland-2024/kylemore-abbey.jpg)
![Horse grazing at Kylemore Abbey](/images/photography/ireland-2024/kylemore-abbey-horse.jpg)

# Day 6 

Back in Dublin, there were a few notable things to check out. Guinness, Jameson, and Kilmainham Gaol - a historical jail where leaders of the Irish revolution were executed (which really kickstarted the revolution). 

![Pint of Guinness I got to pour while at the storehouse](/images/photography/ireland-2024/guinness.jpg)
![Jameson and lemonade at their distillery](/images/photography/ireland-2024/jameson.jpg)

![Jail cells inside one of the blocks of Kilmainham Gaol](/images/photography/ireland-2024/kilmainham-gaol-cells.jpg)
![Outdoor block of Kilmainham Gaol](/images/photography/ireland-2024/kilmainham-gaol-ceiling.jpg)

# Day 7 

One of the more scenic days in Ireland, we ventured south to the Wicklow mountains and Kilkenny. Kilkenny, known for the medeival mile, is also the home of Smithwicks, a popular red ale in Ireland. We did later find out that Smithwicks is owned and brewed by the same parent company as Guinness, something that they do not tell you while at Guinness. 

![Smithwick's Flight](/images/photography/ireland-2024/smithwick.jpg)
![House in the Wicklow park near the lower lake](/images/photography/ireland-2024/wicklow-house.jpg)
![Cemetary in the Wicklow park](/images/photography/ireland-2024/wicklow-cemetary.jpg)
![Cemetary tower peaking out in the Wicklow park](/images/photography/ireland-2024/wicklow-tower.jpg)
![Sheepdog intimidating sheep in Wicklow](/images/photography/ireland-2024/wicklow-sheepdog.jpg)
![Walls throughout Ireland put up during the famine](/images/photography/ireland-2024/walls-in-mountain.jpg)

Ireland 2024

 
## Contents 

# Intro/Inspo

Tasked with creating a senior design project, we came up with the idea to make a web game that could feature some advanced technologies - such as being react native, CI/CD, API ready, and more. 

We also wanted to make this "educational" and decided to include some kind of topic we could base it off of. 

The final product was a web based game similar to Club Penguin, that talks about penguin habitat loss. Keeping it "educational", institution was added to the name for good measure. 

# Technologies 

- NodeJS
- NextJS
- MongoDB 
- Github/Actions 
- Cypress
- Docker
- NextAuth 

Institution Penguin

 
## Contents 

# Intro/Inspo

One undergraduate class, ITC466 Cloud Automation, had a final project to deploy something on AWS using a couple of services. The obvious solution here was to deploy a website to EC2 and have it connect to RDS - knocking out two big services pretty easily. 

# Conclusion 

Despite all this work, somehow we were the only group who actually deployed something to AWS.. but oh well. 

![What it ended up looking like](/images/projects/small-eats/background.png)

# Technologies 

- Python
- Flask
- Jinja2
- Docker
- AWS 

Small Eats

 
## Contents

# Intro/Inspo

Technical writing is something that is very common in Computer Science and Information Technology. Without it no one would really know what is happening, except the person who wrote it. For a while the things I hosted did not need any technical writing, because I was the one making it. Until it started to get to the point where I couldn't even remember what I had done. Then I knew it was time to make a blog of sorts. 

Instead of just spinning up another wordpress instance which I inevitably run into issues with styling, I decided it would be easier to make something more complicated. Introducing NextJS with remark to have the easy writing of Wordpress (kind of) in the style of markdown, but with the granularity of NextJS. 

# Process 

This can be broken down into a couple major phases 

## Research 

The first step was to research what technology to use. At this point I was in a sort of web phase, after working on a senior project [Institution Penguin](https://github.com/meyersa/institution-penguin). Our senior design project revolved heavily around a React router project called NextJS. It was pretty easy to use and it could do everything I wanted. 

With something like Wordpress the process of making a page is simply loading the site in your browser, logging in, and posting the page. However I felt like that was a little too easy, but at the same time making a whole page everytime I wanted to post also seemed too complicated. That's where Markdown came in. Using remark with NextJS I could make Markdown posts which would automatically get rendered into HTML pages. 

Now that I found the technology, the first step was to play around with it. The first generations were rough, basic code from other projects such as the NextJS documentation and other blog sites such as [Tina.io](https://tina.io/blog/simple-markdown-blog-nextjs/). This turned out to be rather useful, and I realized that this would not be too bad of a project to code. 

![Initial Code](/images/projects/nextjs-blog/initial-code.png)

## Implementation 

With some examples and guidelines found it was time to assemble a general NextJS site using my other projects as a reference point. This honestly took a lot longer than working with the JS for the posting since I had to dial everything into a point that I was happy with. 

> Working with the HTML/CSS of this project makes me consider another project, working on an asset hosting site that would allow me to standardize content between multiple websites with the ability to change CSS across multiple sites instantly. Sort of like an ansible but for websites. 

One of the first problems I ran into was that I didn't know NextJS as well as I figured. Combing through the documentation everything seemed familiar, until I tried to link to an external host for content (this time being github). While NextJS has great support for loading assets from the web, it turns out you have to explicity define that in the next.config.js file. Once that was figured out that problem was solved. 

Another problem I ran into was I had been working with Python so long that JavaScript syntax became a little confusing. Everything in Python just makes sense, its like writing English, but it's code. JSX with Next also did not help with this, it takes that syntax to even more complicated places. Especially when trying to pass arrays in to functions, which ends up being a mess of curly braces. 

## Styling 

At this point I almost feel like being a developer makes you into a part time UX designer. Websites never look good to me until I mess with them for a while. They start off with nice and neat CSS files broken up by module in Next, but end with random small fixes thrown in all over the place. (Part of the reason I want to get that asset host up is to remediate this problem). 

I really wanted to distinguish post locations, but using shadows or different colored boxes felt overdone after some of the other projects I worked on. My inspiration for this really came from the [Apache Kafka](https://kafka.apache.org) and [Apache Spark](https://spark.apache.org) websites. They look so clean, but are easily navigatable. It makes you appreciate the Apache foundations insane number of projects. 

Once again this process made me reflect on my other projects. Apache has so many websites, but they are not consistently themed. I have multiple, and it made me think about themeing them all the same, but maybe the color changes per site, but the rest is the same? Something about that sounds so satisfying. 

## Deployment 

NextJS provides some Dockerfiles that easily get the job done. Simply adding them and specifying the build directory took no time at all. 

And again I had Github workflows for deployment that I can reuse to have it get autobuilt on pushes. 

> Something I also want to consider is building images and pushing them to the Github container repo instead of building images locally. This would allow for more testing in something like a Jenkins pipeline before pushing, and also being able to then use that image in multiple places instead of having to build it in those places. 

And for now adding a route is easy, deploying with Cloudflare tunnels is just typing in the container name in the CF dashboard. In the future though, this will get moved into my Traefik mesh network on Oracle for better deployment standards and reliability.

## Making content 

With this blog site mostly done, it was time to consider content for it. I had unfortunately not really taken good notes of assembling this site, since it happened at random times and my memory isn't great, but now I had somewhere I could easily start writing a markdown file, or even just copy in from somewhere else, which should make the documentation process a lot easier. 

NextJS Writeups

 
## Contents 

# Intro/Inspo

The inspiration for this project came from an assignment in one of my graduate classes, creating an ETL pipeline. ETL pipelines are common in data mining and other data science areas, basically extracting data, transforming, and then loading the data. 

Since I didn't want to just use a Kaggle dataset to operate this pipeline on, I chose instead to utilize Shodan.io and scrape information off there in batches and process it throughout the pipeline. 

> To continue with the ETL pipeline idea, I originally implemented it with Kafka connecting the steps. However, to make this more practical, the steps just send directly to eachother in a single container 

To further my web development experience, I templated this site with ExpressJS and I found it to be really intuitive and simple. 

# ETL 

## Extraction 

The first step, extraction, is taken care of with Shodan's own Python library. This just samples a query set in ENV and passes the information on to the next steps. 

## Transformation 

There are a couple steps inside of this step: flattening, cutting, and enriching. 

When the information originally comes in, it can be tons of different information per single record. To mitigate this, we flatten the incoming dictionary on IP and are able to save a lot of memory. 

To further knock this down, a lot of fields coming in may not be necessary. As such, they are dropped or concatenated when possible. 

Finally, incoming IPs are enriched with Data from Maxmind as well as Crowdsec to show more information about them. 

## Loading

Surprisingly, also another complicated step. We are regularly querying the same information and trying to store it, so a mechanism to only update the relevant information had to be implemented. Basically, if we have seen the IP before, we grab the current document in Mongo and compare it to the update. Generally, one piece of "data" changes and we can just modify the single field in the document. However, sometimes even the enrich data changes and in these instances it's easier to replace the whole document. 

![What it ended up looking like](/images/projects/shodan-etl/background.png)

# Technologies 

- ExpressJS
- Python
- Shodan.io 
- MongoDB
- Crowdsec 

ShodanETL

 

# Lima 
One of the hottest cities I've been to, sitting practically on the equator, it's the only time I've seen a 12 on the UV Index Scale. Miraflores, the upscale district along the cliffs, offered clean streets, parks, and ocean views—definitely a highlight compared to the chaos elsewhere.

![Overlook of Lima](/images/photography/peru-2024/lima-overlook.jpg)

The beaches were packed with tents and vendors trying to avoid the sun. 
![Crowded beach in Lima](/images/photography/peru-2024/lima-beach.jpg)

South of the city lies Pachacamac, a significant archaeological site once sacred to pre-Incan civilizations. Over time it was abandoned and, at one point, reduced to a dumping ground before preservation efforts revived its importance.
![Pachacamac](/images/photography/peru-2024/lima-pachacamac.jpg)

# Paracas 
Located several hours down the coast, Paracas is a tranquil port town and the primary launching point for tours to the Ballestas Islands. These islands are well known for their massive seabird colonies. The white coating across the rocks is not snow, but guano—a nutrient-rich fertilizer that was once a critical export for Peru.

![Ballestas Island](/images/photography/peru-2024/paracas-poop-island.jpg)
![Baby seals on the beach of Ballestas](/images/photography/peru-2024/paracas-baby-seal.jpg)
![Seals covering a bouy](/images/photography/peru-2024/paracas-bouy.jpg)

# Ica 
Nestled amid vast desert, Ica is a surprising oasis surrounded by towering sand dunes. The landscape feels almost otherworldly. We visited Huacachina, a small lagoon resort built around a natural spring. Dune buggies raced over the sand in thrilling loops, and we even had the chance to try sandboarding down the steep slopes.

![Dunes of Ica](/images/photography/peru-2024/ica-dunes.jpg)
![Sunset over the Dune](/images/photography/peru-2024/ica-sunset.jpg)

# Cusco 
Situated at over 14,000 feet, Cusco is the former capital of the Inca Empire and remains a historical and cultural hub. Its cobbled streets and terracotta rooftops are framed by surrounding Andean peaks. Walking its steep alleys is both breathtaking and literally breath-taking due to the altitude.

![Alley overlooking the mountain](/images/photography/peru-2024/cusco-alley.jpg)

The San Pedro Market offered a sensory overload—from local cheeses and fruits to rows of vividly colored pepper sauces. The energy of the market reflects the spirit of the city.
![Cheese on display at the local market](/images/photography/peru-2024/cusco-market-cheese.jpg)
![Various aji (pepper sauces) on display](/images/photography/peru-2024/cusco-market-display.jpg)

# Sacred Valley 
Stretching between Cusco and Machu Picchu, the Sacred Valley is a lush region of fertile farmland, small villages, and ancient ruins nestled between dramatic mountain ranges.

![Overlooking the Sacred Valley](/images/photography/peru-2024/sacred-valley.jpg)


One particularly fascinating site was Moray, a set of circular terraces believed to have been used by the Incas as an agricultural research station. The temperature difference between levels allowed them to simulate different climates.
![Inca Wishing Wells](/images/photography/peru-2024/sacred-valley-wishing-well.jpg)

Nearby, the Maras salt mines reveal a centuries-old system of salt extraction. Thousands of shallow pools cascade down a hillside, each filled with mineral-rich spring water that evaporates under the sun, leaving behind shimmering white salt.
![Maras](/images/photography/peru-2024/maras-salt-mine.jpg)

# Machu Picchu 
From the town of Ollantaytambo, we boarded the scenic PeruRail train that follows the Urubamba River deep into the Andes.

![House on the hill above Ollantaytambo](/images/photography/peru-2024/ollantaytambo.jpg)
![Peru Rail to Machu Picchu](/images/photography/peru-2024/sacred-valley-train.jpg)

Machu Picchu itself was everything expected and more—a surreal mountaintop citadel shrouded in mist. The stonework remains as impressive as its location. While exploring the terraces, we even spotted a wild chinchilla basking in the sun.
![Machu Picchu](/images/photography/peru-2024/machu-picchu.jpg)
![Chinchilla in the wild](/images/photography/peru-2024/machu-picchu-chinchilla.jpg)

Peru 2024

 

# Lisbon 
One of the oldest cities in Western Europe—older than Rome—and was founded by Phoenicians around 1200 BCE. Since then it's gone through a lot, but maintained its history.

![Houses in Historic Lisbon](/images/photography/portugal-2023/lisbon-building-sideview.jpg)
![Overview of Lisbon from Castelo de São Jorge](/images/photography/portugal-2023/lisbon-castle-city-overlook.jpg)
![Cristo Rei](/images/photography/portugal-2023/lisbon-cristo-rei.jpg)
![Lisbon's mini Golden Gate bridge](/images/photography/portugal-2023/lisbon-golden-gate-bridge.jpg)
![A tram going up a steep incline](/images/photography/portugal-2023/lisbon-tram.jpg)
![POV of a Lisbon TukTuk](/images/photography/portugal-2023/lisbon-tuktuk-pov.jpg)

Being an old city, there was no lack of churches. 
![Golden interior of a church](/images/photography/portugal-2023/lisbon-golden-church.jpg)
![Golden Statue of Jesus](/images/photography/portugal-2023/lisbon-golden-jesus-statue.jpg)
![Historic Figures in Lisbon Churches](/images/photography/portugal-2023/lisbon-statue-in-church.jpg)

Created by monks at the Jerónimos Monastery in Lisbon, the Pastel de Nata was made with egg yolks left over from starching clothing with egg whites.
![Lisbon's Pastel De Nata](/images/photography/portugal-2023/lisbon-pastel-de-nata.jpg)

# Évora
A UNESCO World Heritage Site, once a Roman city—Liberalitas Julia.

Évora features Capela dos Ossos, or a Chapel of Bones, consisting of bones of nearby cemeteries that were overcrowded. Monks have even been put into the walls—continuing the tradition
![Chapel of Bones](/images/photography/portugal-2023/evora-bones.jpg)

Évora is home to many cork trees, helping Portugal produce around 50% of the world's cork. These trees can be stripped every 9 years safely. 
![Cork Trees](/images/photography/portugal-2023/evora-cork-bark.jpg)

Just outside Évora, Almendres Cromlech features over 90 standing stones arranged in circles and ovals—believed to be a prehistoric astronomical observatory, dating back to 6000 BCE.
![Almendres Cromlech](/images/photography/portugal-2023/evora-rocks.jpg)

# Douro Valley 
A UNESCO World Heritage Site in northern Portugal, known for its terraced vineyards along the Douro River. It’s one of the oldest demarcated wine regions in the world, known for Port wines.

![Overlook of the valley](/images/photography/portugal-2023/douro-valley-overlook.jpg)
![Douro River](/images/photography/portugal-2023/douro-valley-river.jpg)
![Winery in the mountains](/images/photography/portugal-2023/douro-valley-winery.jpg)

Winerys in Douro Valley store their Port barrels underground, in exposed to bedrock caves, ideal for aging.

![Underground Wine Barrels](/images/photography/portugal-2023/douro-valley-wine-barrels.jpg)

# Sintra 
A UNESCO World Heritage Site near Lisbon, known for its lush hills, romantic palaces like Pena Palace, and mysterious sites like the Quinta da Regaleira with its Initiation Well

![View of Pena Palace from the side](/images/photography/portugal-2023/sintra-side-view.jpg)
![Stained glass in Pena Palace](/images/photography/portugal-2023/sintra-stained-glass.jpg)


# Cascais 
A coastal town west of Lisbon, once a royal summer retreat. Known for its beaches, marina, and charming old town, it blends history with a laid-back seaside vibe.

![Lighthouse on the coast](/images/photography/portugal-2023/cascais-lighthouse.jpg)

Casino Estoril, one of the largest casinos in Europe, located near the beach. It inspired the James Bond novel Casino Royale.
![Casino Estoril](/images/photography/portugal-2023/cascais-casino.jpg)


# Templar
The Knights Templar had a strong presence in Portugal. After the order was dissolved in 1312, King Dinis formed the Order of Christ, allowing former Templars to continue under a new name. Their legacy is especially visible in Tomar, home to the Templar-built Convent of Christ, a UNESCO World Heritage Site.

![Tree inside of a monestary](/images/photography/portugal-2023/templar-tree.jpg)


Projects

Photography

Search