DEV Community: Austin

NYMToDo - Completing the capstone!

Austin — Thu, 25 Sep 2025 07:51:15 +0000

Overview

So a few weeks ago I finally finished up my four part project that I've written about. This post is a bit late in terms of project completion, but I ended up starting another project and got pretty consumed in it (More details on that are coming!). Please forgive me if I leave out any details or this doesn't feel polished enough. I didn't expect to take this long to write the blogpost, but better late than never!

As a quick recap, this four part project contains the following:

All of these projects were written in Go.

The Why

This project was a bit ambitious, but it was something I wanted to do to help solidify my understanding of DSA concepts, HTTP, and Go. For context, I don't currently have a degree, nor do I work professionally as a Software Engineer. Getting a job as a Software Engineer is a huge goal of mine that I'm hoping I can accomplish by the end of the year.

In 2019, I did what a lot of others did, which was attending a coding bootcamp. This helped me learn the MERN stack primarily. Since then I have created some full stack applications, and I generally know how to get something done. I started this journey before AI was a thing, and I only utilize it as a tool to help me learn, and not as a crutch. I don't find enjoyment in something unless I'm doing the work myself.

I provide all this context to showcase where I am, and what I can do. I am a Software Engineer, and I can be useful to a team if given the chance. That said, there are certainly skills that I can improve on to make me an even better developer. Javascript and its many frameworks lead to fast development time (Go does as well to be fair) however, what I realized is that I was so focused on shipping resume projects and creating things to get a job that I didn't truly focus on the learning aspect. I decided to change that this year.

The biggest goal I had for myself with this project was to expose myself to how these things I use in full stack application development work from a lower level than I am used to. Sure, I can spin up a MongoDB instance or configure Nginx to serve a webapp, but why do I the things I do to make them work? Express is great, but what is actually going on when you create an HTTP server in Node and what is happening when you create your RESTful APIs? This project won't wow anybody or win any hackathons, but it was special to me because I started to finally understand the why.

Parsec Quick Overview

Parsec is a small reverse proxy (Go 1.22+) that maps host/path prefix → upstream with a static JSON file. It’s built on net/http, httputil.ReverseProxy, and a custom http.Transport.

My dev config boiled down to:

{
  "listen": ":5173",
  "routes": [
    {
      "match": { "prefix": "/api" },
      "upstream": "http://localhost:8080",
      "strip_prefix": "/api",
      "preserve_host": false
    },
    {
      "match": { "prefix": "/" },
      "upstream": "http://localhost:5174",
      "preserve_host": false
    }
  ]
}

I run this inside my backend server:

h, _ := parsec.HandlerFromFile("./parsec.json")
go http.ListenAndServe(":8080", apiRouter) // Go API
http.ListenAndServe(":5173", h)            // Parsec proxy

NYMToDo Quick Overview

This was a very very simple ToDo app. I can share screenshots if anyone really cares to see, but the general gist is there. I used React for the front end and had a little bit of fun with the UI. This isn't my finest overview work here, but this is my blogpost, not yours (kidding)!

Obstacles along the way

Incorrect Boolean

I had the config right and could hit the API directly:

curl http://localhost:8080/todos  → []
curl http://localhost:8080/api/todos → 404

That’s expected because my backend lives at /todos, not /api/todos. Parsec’s strip_prefix is supposed to forward /api/todos -> /todos.

But through :5173 I kept getting 404—even when I deliberately pointed the upstream at a bogus port to force a 502.

At the end of the day and some time beating my head against an invisible wall, it all came down to developer error (shocker). I had the boolean logic incorrect.

In ServeHTTP I found:

hostOK := cr.host == "" || cr.host == reqHost
if !hostOK && strings.HasPrefix(path, cr.prefix) { // <- oops
    cr.rp.ServeHTTP(w, r)
    return
}

That !hostOK inverted the logic: a wildcard host ("") would never match. After flipping it to:

if hostOK && strings.HasPrefix(path, cr.prefix) {
    cr.rp.ServeHTTP(w, r)
    return
}

…requests started flowing. The tell was switching upstream to a dead port; a matched route should produce 502, not 404.

Second Speedbump

Vite was picky about the Host header. With upstream: http://127.0.0.1:5174 it wasn’t happy; switching to http://localhost:5174 made it fine. (I left preserve_host: false, which means the upstream sees Host: localhost:5174.)

Closing

There were a lot more issues along the way of this four part project, but all of them helped me learn lessons. This was a fun project that taught me a lot about how different aspects of tech work and how Go works as well.

Doing this at the minimal scale I did gave me a whole new appreciation for those who truly built amazing software that we all use everyday. Especially open source projects. I don't see myself doing more with this project currently. I wasn't trying to reinvent the wheel, I just wanted to create my own for the love of learning. I do think I will revisit some of these projects at a later time to refine them more and add more features. That said, I don't think I'd do the database in Go. There's nothing wrong with Go, but I don't think it's intended purposes is a fit. I'd like to explore Zig at some point, and that might be a time when I revisit the data store.

To anyone still reading this, thank you for taking the time to take a look at this! I'm very excited to share details about a project I've been working on for a few weeks that I am very proud of! Stay tuned.

Gonk - Finished Project MVP

Austin — Thu, 04 Sep 2025 19:15:44 +0000

What is Gonk?

This is a quick recap for those who haven't read my first post about Gonk. Read part one here. If you don't want to do so, then here is a copy paste from that blog post explaining what it is:

Gonk is a project that is part of a four part project that I have planned. Gonk itself is an HTTP Framework I am developing based on the stdlib net/http package from Go. It will include routing, middleware, JSON utility, and more.

Gonk Repo Here

So what has been done since part one?

Great question! Gonk has been fully built out to MVP at this point. I have a fully functional HTTP Framework that contains some basic routing, middleware, and JSON utility. In part one, I showed off the routing for GET requests. I have since added routing for POST, PATCH, PUT, DELETE, HEAD, and OPTIONS. I implemented middleware for CORS, server side logging, panic recovery, and request IDs.

Middleware

The Goal

I made my middleware fairly simple. I didn't want to focus on getting overly complex, as this was a learning opportunity for me, and if I tried to recreate everything that a normal, popular framework has, I would have a harder time grasping the what was needed and why it was needed.

Request ID

I started off with X-Request-Id as this is an essential part of logging. The general idea here was that every request would carry an X-Request-Id. If the request already contained an X-Request-Id then it would use that, else it would create one.

For creating a new Request ID, I decided to keep it simple and create the Request ID as a hex encoded string.

func newReqID() string {
    buf := make([]byte, 16)

    if _, err := rand.Read(buf); err != nil {
        return strconv.FormatInt(time.Now().UnixNano(), 16)
    }
    return hex.EncodeToString(buf)
}

I then needed a way to store a Request ID in context.

func storeReqID(ctx context.Context, id string) context.Context {
    return context.WithValue(ctx, requestIDKey, id)
}

Finally I could create the ReqID method that can be used in my middleware chain:

func ReqID(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // Reads the incoming header, checks for ReqID
        id := r.Header.Get("X-Request-Id")

        // Checks the len of the incoming ID
        // >128, creates a new ReqID
        if len(strings.TrimSpace(id)) == 0 || len(id) > 128 {
            id = newReqID()
        }

        // Make it visible to client and downstream middleware
        w.Header().Set("X-Request-Id", id)
        r = r.WithContext(storeReqID(r.Context(), id))

        next.ServeHTTP(w, r)
    })
}

Another important aspect is that I knew I would need a way to retrieve a Request ID from context. I implemented the following:

func ReqIDFromCtx(ctx context.Context) (string, bool) {
    v := ctx.Value(requestIDKey)
    s, ok := v.(string)
    return s, ok
}

Logger

Now that I had a way to get Request IDs, the next thing I implemented was a logger. I wanted my logging to be returned as JSON, as this would be easy to work with, and it would also tie nicely into things like Elastic if I decided to implement a SIEM.

Each request should contain the following:

Method
Path
Bytes Written
Latency
X-Request-Id

Here's a quick snippet of my Logger:

func Logger(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        wrapped := &statusWriter{ResponseWriter: w, status: 200}
        next.ServeHTTP(wrapped, r)
        id, _ := ReqIDFromCtx(r.Context())
        rec := map[string]any{
            "ts":         time.Now().Format(time.RFC3339Nano),
            "level":      "info",
            "request_id": id,
            "method":     r.Method,
            "path":       r.URL.Path,
            "status":     wrapped.status,
            "bytes":      wrapped.bytes,
            "latency_ms": time.Since(start).Milliseconds(),
            "remote_ip":  r.RemoteAddr,
            "user_agent": r.UserAgent(),
        }
        _ = json.NewEncoder(os.Stdout).Encode(rec)
    })
}

The result? Take a look for yourself:

Panic Recovery

This is definitely an important aspect to my middleware chain. I am certainly not a perfect dev, and I am bound to make mistakes. I didn't want a panic to take the whole server down. The Recovery middleware wraps everything at the top and ensures that if a handler blows up, it gets caught. It logs the panic (with stack trace for my eyes only) and responds to the client with a clean 500 Internal Server Error JSON body. No stack traces leaking over HTTP, no server crashes.

I did, however make a route for this for testing purposes. Here's the result:

CORS

The final piece of the middleware puzzle for me was CORS. This is obviously a very important aspect in web development. If you have a frontend, you're going to have to deal with CORS at some point. I made this configurable. You can allow all origins for dev, or lock it down to specific origins in production. It handles both simple requests and preflight OPTIONS request. The key was keeping it safe, no mixing "*" with Allow-Credentials: true, since browsers forbid it. This way I don’t accidentally open a security hole.

JSON Utility

Now that I had a working middleware chain, I wanted to add one more piece of functionality to my HTTP Framework, and that is JSON utility. It's very common to deal with JSON in web development, and Go is notoriously verbose when dealing with ~~everything~~ JSON.

I built utilities for the following:

WriteJSON: Encodes data, sets the right headers, writes status.
WriteError: Consistent error shape — always {"error":"..."}.
DecodeJSON: Strict decode. Rejects unknown fields, empty bodies, multiple JSON values. Returns typed errors so I can map them to status codes.
StatusFromDecodeError: Converts decode errors into proper HTTP codes (400 for bad input, 413 for too large, 422 for type mismatches, etc.).

Design Choice

I designed this HTTP framework to be simple to use, have a little bit of ergonomic utility, and mostly for the sake of learning. I used the stdlib net/http wherever I could, including http.ServeMux. This allowed for relatively fast development, and I am overall happy with my end product. I absolutely learned a lot about how Go handles HTTP requests and how the stdlib net/http works.

Final Thoughts

Again, I really enjoyed this project. Doing this really solidified my enjoyment in choosing to learn Go. Things are really starting to click with me personally on a lower level. Most of my dev experience has been with Javascript in the past. I always understood how to do something, but I really never fully grasped the why outside of a high level. Choosing Go has forced me to learn the why, but it's also made this very fun in the process.

If I were to go back or revisit this project, I would say that I would probably not use http.ServeMux. Not because it didn't fit my use case, but actually because it fit it too well. This was a great learning opportunity for me, and I would love to do a "2.0" version of Gonk. To even further solidify my understand of TCP, HTTP, and network code, I would love to go back and do more from scratch. That means creating my own http.ServeMux and potentially not even use the net/http at all. Or, limited use of it at least. I find I learn best by doing, and that would be a way to learn even more. Either way, I do not have regrets for how I build Gonk.

Now we're on to the Data Store as part two of my four part project!

See Gonk for yourself here!

Gonk - The First Steps and Routing

Austin — Sun, 24 Aug 2025 20:34:43 +0000

What is Gonk?

Another web framework, really?

I know I'll be asked why I even decided to create a web framework for Go. There are already very well fleshed out frameworks such as Gin or Chi. Let me start off by saying that I am not trying to create the next Express. I'm not trying to compete with any existing HTTP frameworks. Those frameworks are well done, and developed collaboratively by developers who are far better and more experienced than myself.

If you're not trying to compete, why even bother?

The purpose of this project is for learning purposes. When I first started to really take Software Development seriously at the end of 2019, I learned the get hired quick starter pack (AKA: MERN). I'm not discrediting anyone who is a Javascript developer at all. It's a massively used language for a reason. For me though, I've gotten to the point where I want to dive deeper and I want to understand more.

I like many other went to a coding bootcamp, and I had an instructor named Brandon. He was an exceptional teacher, and he not only taught course material, but he introduced ideas that would help you further your journey if you were inquisitive enough to dive into it on your own time. This is where I was first introduced to Go.

For years now, I have wanted to try using Go, and I've even done small projects to get some form of familiarity with Go. I also developed a simple system monitor for Linux last year in Go which can be found on my GitHub (http://github.com/AJMerr/SyMon). I had a lot of fun with this project, but up until this year I really had the wrong mindset. While I really did strive to get better, and really did want to be a great Software Engineer, I was too focused on trying to get a job, and not doing what I really wanted to do and certainly not learning the correct way. I absolutely can do full stack development, but I can't always fully explain how my system architecture works past a high level understanding. This is fine for a Junior Software Engineer (from what I've seen everyone say at least.) as I can get shippable code produced, and I can tell you what it does. I also have become pretty decent at understanding how to debug my code.

I say all this to say that, while I would love to get a job as a Software Engineer right away, I have done enough deployed, fully demo ready web apps. I have two pretty cool projects that mirror each other, but one is self hostable and the other is meant to be used on the cloud. It's a photo sharing app called Little Moments (http://www.github.com/AJMerr/little-moments and http://www.github.com/AJMerr/little-moments-offline). These coupled with some of my other projects are resume ready and show enough of my current skillset. I need to focus on TRULY understand how everything I do works, and how to explain this to a lower level. I let myself get wrapped up in the "Do these projects NOW to get hired" hell rather than continuing to develop myself as an engineer further. Hindsight is 20/20, but if I could go back 6 years ago, I would focus more on learning than getting hired.

Why Go?

With all the current resources at my disposal, there is no better time to dive deep into developing myself into being a better Engineer. With my interest piqued in Go, I decided to do Little Moments - Offline's back end completely in Go. This was a great project to get me familiar with how things work and to decide if I liked the language, or if I would go a different route. I knew, however, that there was something about Javascript that really just didn't give me that itch. I loved the end result, but I couldn't really say that I enjoyed the process with Javascript. This isn't to say it is a bad language at all, but it's just a feeling you get that I can't explain.

When writing Go, even if I had to copy down code with certain aspects of Little Moments - Offline, I was really engaged and always looked into why I did something a certain way or what the importance of it was. I do use LLMs, but I use them as a learning tool, not as a crutch. Being able to ask ChatGPT to explain why a certain method works and how it works as well as citing resources and documentation makes the learning process so much easier.

There are plenty of technical reasons to use Go, but my focus on this post is to be honest about it not really coming down to performance, lower level programming, or anything that I could say to explain why Go is a great language to learn, but honestly that I just really enjoy working with Go. If you're focused on becoming a better developer, and you don't have a job in Software Engineer, then I think that focusing on what you enjoy doing is an important trait that is missed.

I don't do this because I want the money or status. I do this because I love it.

TL;DR

I decided to do this project because it's an opportunity to learn how the net/http package works at a lower level. I can focus on why certain methods work the way they do, and I can grow my understanding and skillset more.

I chose Go because I like it and it keeps me wanting to code every day.

Initial Setup

The first thing I did for this project was define it's structure and create a repo on GitHub for it.

Repo initialization
- Created the repo at http://github.com/AJMerr/gonk. The initial commit contained a README.md
Go Module
- Ran go mod init github.com/AJMerr/gonk

I also created a Makefile, but I'm not entirely sold that I did it well, and it's something I will need to refine later.

Building the Router

The very first feature I wanted to implement was routing. Honestly, with http.ServeMux it's not terrible from the sdblib net/http but simplifying this makes a good ergonomic experience.

I'm not re-writing http.ServeMuc, I'm just making a wrapper around ti to make the experience using it more ergonomic. My wrapper does the following:

Implements http.Hanlder so that it can be plugged into http.ListenAndServer
Provides helper methods like GET or DELETE for example. This just helps with writing less boiler plate.

Defining the Router

So the first thing I did was create a struct that defined what a router is.

type Router struct {
    mux *http.ServeMux
}

Router is now a pointer to http.ServeMux in order to make the data from http.ServeMux mutable.

The next thing I did was create a NewRouter() constructor that initializes this with http.NewServeMux

This ensures the internal routing table is set up properly (zero-value ServeMux has a nil map — if you try to use it, you’ll panic).

Implement Handle

This is a wrapper that registers routes

func (r *Router) Handle(p string, h http.Handler) {
    if r.mux == nil {
        panic("Router is not initialized, use NewRouter()")
    }
    r.mux.Handle(p, h)
}

In Go 1.22, ServeMux already support patterns such as "GET /notes or DELETE /notes/{id}. This made the Handle method pretty easy to setup

Implement `ServeHTTP`

This makes my Router a valid http.Handler:

func (r *Router) ServeHTTP(w http.ResponseWriter, req *http.Request) {
    if r.mux == nil {
        panic("Router is not initialized, use NewRouter()")
    }
    r.mux.ServeHTTP(w, req)
}

Now I can pass r directly to http.ListenAndServe.

Method Specific Helpers

So when I initially used this, I was happy that I really understood what was going on, and I could visualize in my head everything needed and why it was needed. I know I said that I use LLMs at times, but none of this code was Code Gen'd. I SPECIFICALLY prompted in that I would not be provided and code, and only to be pointed to documentation when I needed help understanding what was going wrong.

Anyways, back to the code. All of the above resulted in this:

r.Handle("GET /healthz", http.HandlerFunc(healthzHandler))

This was cool to see working, but this wasn't any less verbose than using http.ServeMux. My solution? Here is how I handle METHOD specific helpers with GET being the example:

func (r *Router) GET(p string, fn func(w http.ResponseWriter, r *http.Request)) {

if r.mux == nil {

panic("Router is not initialized, use NewRouter()")

}

handler := http.HandlerFunc(fn)

// Adds GET to path

fullP := "GET " + p

r.Handle(fullP, handler)

}

The formatting is better inside my editor, I promise. Anyway, the end result is:

r.GET("/healhtz", healthzHandler)

That is a lot better.

Final Testing

So, just to ensure this works, I tested it with an example healthz route

func healthzHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type:", "application/json, charset-utf8")

    status := struct {
        OK bool `json:"ok"`
    }{
        OK: true,

    }

    err := json.NewEncoder(w).Encode(status)
        if err != nil {
        http.Error(w, "{ok: false}", http.StatusInternalServerError)
}

func main() {
    r := router.NewRouter()

    r.GET("/healthz", healthzHandler)

    http.ListenAndServe(":8080", r)
}

The end result?

Fully working routing!

I also tested different routes and they all worked. I really enjoyed this experience, and I really am starting to understand what's going on to a lower level. I'm not finished with this project, and I will write more articles as I build this out further.

Follow the repo here: http://www.github.com/AJMerr/gonk

Creating a SIEM Homelab with Elastic Cloud!

Austin — Fri, 08 Aug 2025 19:59:57 +0000

The Why

I think that it's important to understand the why when you decide to do any project. I have been diving into Cybersecurity for a while now while I am currently unemployed. I've done a lot of focus on the red team side of things and have completed the Junior Penetration Tester learning path from TryHackMe. I also have purchased a voucher for the TCM Security PJPT (Practical Junior Penetration Tester) certification.

Of course, being unemployed, I am looking for a job. While I very much enjoy attacking, I understand that the end goal for any successful red team engagement or penetration test is to solidify a good defense. I on order for me to be valuable to a team or even as a freelancer, I need to be able to understand what makes a good defense and how to properly patch holes that I find while I attack.

Finally, I do understand that though I have 7 years of experience in Support Engineering, getting a job on the red side is not typically an entry into cybersecurity. I enjoy all aspects of cybersecurity, and I know that my best bet is to get my foot in the door on the blue team. Thus, I have taken a small couple days break from studying for the PJPT via TCM's PEH (Practical Ethical Hacker) learning path to setup a homelab with Elastic Cloud.

The Goal

My goal for this small project was not to dive into the weeds and create custom alerts and Kibana dashboards yet. I am right about to start the Active Directory section of the PEH, and I didn't want to overload myself with knowledge and then not be able to retain as much when it comes time to take the PJPT.

My goal for this project was to successfully deploy a hosted cloud instance of the Elastic Stack, add an agent, and play around with discover to see how things work from a higher level. I have some experience with utilizing Splunk to review email deliverability logs from a previous employer, so I figured I would be able to find some basic logs in order to call this project a success.

Initial Setup

After review documentation from Elastic, and watching this video from John Hammond I figured that this project wouldn't take too much time away from studying for the PJPT, and I decided to dive in.

I started off by choosing Elastic Cloud via a hosted deployment as it would allow me to get straight into things with minimal headache for the time being (I do plan on doing this on bare metal and diving deeper later).

I chose then chose the Elastic Security option, as it came with everything I'd want for a homelab SIEM.

I then picked a super creative name for my deployment, and left the rest of the settings to their default, as they seemed good enough for this project and also considering it's a 14 day free trial.

If you decide that you want to do this yourself, after you press "Create Hosted Deployment, you will want to make sure you save the credentials that are provided on the next screen. That is VERY important.

After waiting for my deployment to be fully configured, I was eventually met with a success banner letting me know my deployment was ready!

The first thing I do in any application I use is switch to dark mode. I have blue eyes, and this is essential for my comfort. Here is the screen you're met with (in dark mode, of course!)

And we're in! Onto the next step.

Adding an Agent

So now that Elastic Cloud is deployed, the next important step is to add an agent. For an agent, I decided to deploy a VM specifically for this project.

Setting up a Virtual Machine to use as an Agent

I started by creating an Arch Linux Virtual Machine. Now, I know what you're thinking, Arch Linux is a bit of an undertaking to only be deployed as an agent for this project. For one, I use Arch as my main Linux distro. I don't use Windows at home anymore. I've gotten very fast at installing Arch Linux manually, but there is also the archinstall script that I ran for this VM as I didn't need anything fancy. The installation also takes less time than deploying an Ubuntu server VM. So with these points in mind, it made my choice of OS both practical, but also fast.

Adding the Agent into Elastic

This process was actually pretty simple for me. You just need to navigate to the following: Assets > Agents > Add Agent

I left everything at their defaults again for now.

I then made sure to keep the box checked for enrolling to fleet. From there, I initially made the mistake of copying down the incorrect script. I chose the ARM script instead of x86-64. For some reason, it was the default script shown, and I didn't pay attention to the full descriptor and just saw Linux.

Before realizing my mistake with the incorrect script, I tried to copy and paste from my host to my VM. I was having issues with virtual box when attempting this (I normally use QEMU + KVM). To work around it for now, I decided to just open up a web server using python on my host machine and then pull the script from a text file I created on my host to my VM.

After troubleshooting why the elastic-agent script wasn't working I realized my mistake and copied the correct script. The script is provided to you in the installer. Just be sure to double check you are using the correct script unlike I did initially.

I ran elastic-agent install and... success!

I now had a working agent connected to my Elastic Cloud deployment!

Final Thoughts and Future Plans

After confirming I could see my agent within Elastic Cloud, I did get around to playing with discover, and even installed some integrations such as Auditd-Manager.

This was a very fun project, and it showed me a lot about Elastic in general. I had never used it before, but I figured now was a better time than any to experiment. I also was able to gain familiarity with the search syntax and was even able to locate logs of SSH connections and attempts!

I will absolutely be diving deeper into Elastic as it is both practical learning and valuable hands on experience for future employment opportunities. Here are a few goals I have for next steps involving Elastic:

Deploy Elastic on my laptop via docker (until I have a home server)
Configure Kibana dashboards
Configure a few custom rules
Enroll all possible home devices onto my self-hosted Elastic instance for both practical experience and home network security.

For now, I am going to dive back into the PEH and continue to take notes, practice, and learn. This was a fun side project that has given me ideas for larger projects, but I don't want to wear myself thin while studying for a certification exam.

I will definitely be doing more posts soon following my experience and thoughts on the PEH and PJPT. Feel free to follow along with me on my journey with Cybersecurity!

From Challenge to Creation: Building a Blog Post Generator with AWS and React

Austin — Thu, 16 Jan 2025 00:39:31 +0000

Disclaimer:

I used this project to generate this blog post. I, of course, read over everything produced to ensure that it doesn't sound too crazy or much different than how I would write this if I had written it from scratch. For the purpose of the project, I am not going to edit the content generated by AI. Instead, I will denote my own notes in each section if I want to add more context or add to what was provided.

As a aspiring software engineer constantly looking to push my boundaries, I recently embarked on a fascinating project that combined several cutting-edge technologies. My goal? To create a blog post generator that would showcase my technical skills and problem-solving abilities.

The Vision Takes Shape

The journey began with a simple idea: what if I could build an application that could help content creators generate initial drafts more efficiently? Armed with React for the frontend and a suite of AWS services, I set out to turn this concept into reality.

Navigating the AWS Ecosystem

I'll be honest - working with AWS Amplify was not love at first sight. Coming from a background of deploying applications using EC2 with NGINX, the Amplify workflow felt somewhat restrictive. My previous experiences with more direct server configuration made the initial setup a bit challenging.

EDIT: To clarify, this is the second app I have hosted on AWS. The first project used EC2 with NGINX. It's absolutely true that I enjoyed that experience far more. I'm a Linux user using Arch btw with Hyprland as a WM. You can imagine why this was the case for me.

The biggest hurdle? Getting Amplify to serve my content exactly as I intended. Each configuration tweak felt like solving a complex puzzle, testing my patience and problem-solving skills. But isn't that what growth is all about?

The Technology Stack

My tech stack became a carefully curated selection:

Frontend: React
AWS Services:
Amplify for deployment
Lambda for serverless computing
API Gateway to manage API interactions
Bedrock for AI capabilities
Cognito for user authentication

The IAM policies for Bedrock proved to be another interesting challenge. Defining the correct ruleset required meticulous attention to detail - a lesson in the importance of precise access management.

EDIT: To clarify what happened here, anytime I added a region to my IAMs policy and attempted to run my Lambda function, it would switch regions. I still have no idea why this happened, and my solution was to just add every single NA region to the IAMs policy.

Overcoming Challenges

Each obstacle became an opportunity to learn. While Amplify initially felt constraining, I learned to work within its ecosystem, understanding its strengths and limitations. The IAM policy configurations for Bedrock became a masterclass in cloud security principles.

The Proud Moment

When the blog post generator finally came to life, it was more than just a technical achievement. It was a testament to persistence, learning, and the joy of creating something from scratch.

Reflections

This project reinforced something I've always believed: in tech, the journey is just as important as the destination. Every challenge is a chance to grow, every configuration error a lesson in disguise.

To my fellow aspiring engineers: keep building, keep learning, and never shy away from complex projects. Your next breakthrough might be just one line of code away.

As I continue my journey from technical support to software engineering, projects like these are my stepping stones. They're not just applications; they're stories of growth, challenge, and continuous learning.

Want to see the project in action or dive into the technical details? Reach out - I'm always excited to discuss tech, share insights, and learn from fellow developers!

Wrapping Up

This part of the blog is also organically typed. This project actually surprised me in areas that I thought would be simpler to implement. It was very fun working with technologies that I hadn't yet touched (aside from Amplify). In the future, I will probably avoid Amplify altogether unless it is for a simple project that I just need to have hosted quickly. It's a great tool, but the limitations make it frustrating to use at times. If you would like to see this project live in action, the part about about reaching out is absolutely true. I was very proud to show it off to friends and coworkers of mine.

I'm absolutely excited to work on my next project! It's going to be a re-engineered version of a project I had deployed previously. I am going to incorporate some the new skills I have gained to make it more production ready. I will, of course, be posting a blog about this project as well. Stay tuned for more!

Deploying My Portfolio Website on AWS: A Cloud Engineer's Journey

Austin — Thu, 02 Jan 2025 06:50:04 +0000

As someone transitioning from technical support to cloud engineering, I wanted to create a portfolio website to showcase my work. While I’m not the biggest fan of front-end development, I was excited to get something live and demonstrate my cloud skills. So, I decided to build my site using simple HTML and CSS, host it on AWS, and use Terraform for infrastructure as code.

I’ve had some experience using the AWS console, but this was my first time working with Terraform. At first, I was a bit intimidated, but it turned out to be a fun challenge and a great learning experience. The goal was to automate the deployment of my portfolio website using AWS S3, CloudFront, and Route 53.

Initial Struggles with Terraform and CloudFront

The first obstacle came when I mistakenly passed in the AWS S3 bucket name instead of the S3 bucket endpoint in my CloudFront distribution. This caused some issues, but after tweaking my Terraform code, I was able to get that sorted out.

Next, I encountered a frustrating 403 error when trying to access my site. This is where I got hands-on with the dig tool, which helped me confirm that my website was pointing to CloudFront as intended. I was on the right track, but something still wasn’t right.

The SSL Handshake Error

After more troubleshooting, I decided to use curl to inspect the SSL certificate. That’s when I discovered there was an error with the SSL handshake. Further research led me to the solution: I needed to configure aliases for my domain in the CloudFront distribution.

The Final Fix

With that change in place, I re-ran my Terraform code and watched as everything fell into place. My website was finally live, with the proper SSL certificate and everything working smoothly.

While it took some time to troubleshoot, this project taught me a lot about Terraform, AWS, and the importance of paying attention to details like CloudFront configurations and SSL certificates. It was a rewarding experience, and I’m excited to continue exploring cloud engineering!

My First Step on the Journey to Becoming a Cloud Developer

Austin — Thu, 02 Jan 2025 06:47:56 +0000

Today marks the beginning of an exciting new chapter in my career: my journey to becoming a Cloud Developer. It’s a path I’ve been contemplating for years, but life’s twists and turns often kept me from diving in. Now, with determination and a solid plan in hand, I’m ready to make the leap. Here’s how it all starts.

Choosing AWS as My Cloud Platform

When deciding where to focus my efforts, AWS emerged as the clear choice. It’s a dominant player in the cloud industry, offering a rich ecosystem of tools and services that align perfectly with my goal to build impactful and scalable applications. With AWS, I can explore everything from hosting static websites to deploying complex serverless architectures.

A Passion for Tech and Building Things

Technology has always been more than just a career for me; it’s a passion. Over the years, I’ve developed software on and off, tinkering with various projects whenever inspiration struck. I love the process of creating—transforming an idea into something tangible and functional. This passion for building is what fuels my excitement for this journey.

Overcoming Life’s Hurdles

For a long time, pursuing a career in cloud development felt like a dream deferred. Whether it was personal responsibilities, financial constraints, or other life circumstances, something always seemed to stand in the way. But I’ve learned that the best time to start is now. I’ve finally carved out the space in my life to commit to this journey fully.

Researching the Path Ahead

Before diving into my first project, I took time to research what it takes to transition into cloud development. I watched videos from individuals who have successfully made the leap and soaked up advice from industry experts. This preparation not only gave me insights into the technical skills required but also offered a roadmap for building a portfolio that stands out.

Crafting a Gameplan with ChatGPT

One of the tools I used to structure my learning journey was ChatGPT. It’s been invaluable for brainstorming project ideas and organizing a gameplan. Together, we mapped out a series of portfolio projects that will showcase my growing expertise in AWS and cloud development. These projects are designed to demonstrate a clear progression in skills, starting from the basics and gradually tackling more complex scenarios.

Kicking Off with a Static Website

My first project is a static website hosted on AWS using S3, CloudFront, and Route53. This project will give me hands-on experience with:

S3: For storing the website’s files.

CloudFront: To deliver content quickly and securely to users around the globe.

Route53: For managing DNS and making the site accessible through a custom domain.

This project is more than just a learning exercise; it’s a symbol of my commitment to this journey. By the time it’s live, I’ll have gained foundational knowledge of core AWS services and taken my first tangible step toward my goal.

Looking Ahead

This is just the beginning. As I progress, I’ll tackle increasingly complex projects, document my learnings, and share my experiences. My aim is not only to grow as a Cloud Developer but also to inspire others who might be considering a similar path. If there’s one thing I’ve learned from my years in IT support, it’s that persistence and curiosity are the keys to success in tech.

Here’s to building, learning, and growing—one project at a time!

DEV Community: Austin

NYMToDo - Completing the capstone!

Overview

The Why

Parsec Quick Overview

NYMToDo Quick Overview

Obstacles along the way

Incorrect Boolean

Second Speedbump

Closing

Gonk - Finished Project MVP

What is Gonk?

So what has been done since part one?

Middleware

The Goal

Request ID

Logger

Panic Recovery

CORS

JSON Utility

Design Choice

Final Thoughts

Gonk - The First Steps and Routing

What is Gonk?

Another web framework, really?

If you're not trying to compete, why even bother?

Why Go?

TL;DR

Initial Setup

Building the Router

Defining the Router

Implement Handle

Implement ServeHTTP

Method Specific Helpers

Final Testing

Creating a SIEM Homelab with Elastic Cloud!

The Why

The Goal

Initial Setup

Adding an Agent

Setting up a Virtual Machine to use as an Agent

Adding the Agent into Elastic

Final Thoughts and Future Plans

From Challenge to Creation: Building a Blog Post Generator with AWS and React

Disclaimer:

The Vision Takes Shape

Navigating the AWS Ecosystem

The Technology Stack

Overcoming Challenges

The Proud Moment

Reflections

Wrapping Up

Deploying My Portfolio Website on AWS: A Cloud Engineer's Journey

My First Step on the Journey to Becoming a Cloud Developer

Implement `ServeHTTP`