The Process: While a simple CSS fix, the real work was navigating a massive, unfamiliar codebase, understanding its design system, and successfully justifying the change to the maintainers. It was a perfect first exercise in contributing to a major open-source project.

As above.

...As above.

Exploration: This PR was an exploration into core framework architecture. By addressing a long-standing TODO in the codebase, I practiced refactoring critical pathways to improve performance and adhere to internal best practices, learning a ton about the framework's internals along the way.

Proactive Problem-Solving: This PR addresses a fundamental scalability issue for large SSG sites. The goal was to trace the export pipeline and implement a proactive warning system to prevent silent, hard-to-debug build failures for developers working at enterprise scale.

I tried my hand a bit at engaging in some discussions/commenting on issues, but... wow, it's a lot to keep up with.

I think it's quite a nice idea, and I want to continue working on it, but we got derailed due to wondering how we'd get user configs nice and ergonomic when they're setting up their GitHub urls and whatnot, and I just got kinda bored and didn't want to implement the API caching... which, IMO, is absolutely necessary. So it's at version 0.0.1 right now, because I also found other things that were more interesting. But this is still interesting! There're just a lot of competiting priorities.

Design Note: The core thesis is speed to value. Artists needing pose references shouldn't have to fight complex 3D software. This entire project is architected around collapsing the time it takes to get a useful, well-lit reference, making it an ergonomic, lightweight alternative to the status quo.

The Challenge: The original research code was powerful but production-hostile. It was a tangle of CLI dependencies and version conflicts. The main work was refactoring this into a containerized, reliable, and scalable web service that could form the backbone of a real product.

Insight: A 45-second cold start is a dealbreaker for an interactive tool. The key to this 78% reduction was a two-stage loading process and implementing Modal's memory snapshots, proving that thoughtful serverless architecture can deliver a near-native user experience.

The Trade-off: Instead of relying solely on the expensive GPU model, this pipeline uses a cost-effective multimodal LLM as a "sanity check" and validation layer. It's a novel approach that improves robustness while dramatically reducing cost—a critical consideration for any real-world AI product.

Architectural Goal: Performance and stability were non-negotiable. Many web-based 3D tools lag or crash browsers under load. This editor was architected from the ground up to be lightweight, delivering a stable 60fps+ experience by creating a hybrid system that intelligently routes different image types to the optimal model (client-side MediaPipe vs. custom backend).

The blog part is it. We're still working on trying out different designs/libraries, but I personally just prefer dense information and non-functional art. So... everything and nothing.

Vercel's database pricing was getting expensive as the project grew. Migrated everything to Supabase using pg_dump to ensure 100% data integrity. The migration went smoothly and now I get way more database features for a fraction of the cost.

The original setup was doing way too many database round trips. I added proper indexing on frequently queried columns, restructured some of the more complex queries, and implemented aggressive caching with TanStack Query. The 50ms response time made the whole app feel snappy.

The Challenge: The goal was to build an infinite scroll system that didn't break the web. Most libraries hijack the scrollbar and disable native browser functionality. This implementation was a deep dive into custom DOM manipulation to preserve features like browser history and scroll restoration, making it feel seamless and native.

This is in the App portion. It was really, really hard to achieve even half of the Discord-level usability, because there is just so much state management.

Architectural Decision: This was an exercise in building a decoupled, distributed system. Offloading image processing to a dedicated Go microservice (detailed in the Potato Image Compressor project) improved the main app's scalability and maintainability, separating concerns for a more robust backend.

This is pretty basic. I used Drizzle, too. Like, it's just adding more types and stuff..

I turned this off for now, but it was nice when I tried it a while ago. Rather than making users manually tag everything, I integrated Claude's API to analyze content and suggest relevant tags. It's surprisingly good at understanding context and suggesting useful categorization that actually improves search and organization.

This was just to prove that I could. I want to disable it, but... idk.

This was also just to prove that I could. It isn't on, because I don't really have anything that necessitates it.

I asked my mom to look at my previous versions. I also tried really hard to match up to Discord's design system earlier on, but I realized that I have my own tastes, and I want to try out a bunch of new animation and 3D libraries.

We don't really have a use for this, but we did it to prove that we could.

This was a fun project. I wanted to learn Go, and I thought it would be a good idea to build an image processing pipeline. It was simpler when I initially added it a few months into the Scrapbook project, and it was a couple months later that I really thought to dig deep and make this bigger and better and faster and flashier. I used goroutines with worker pools and sync primitives (both semaphores and mutexes) to make it concurrent and efficient. Oh, and I wanted to try out gRPC too. It's not the most complex thing, but it was a good exercise in Go.

I wanted to use k6 because it seemed like some sort of industry standard, but I ended up doing the bulk of the testing with shell scripts... which seems like what k6 kinda does anyway, at least for my case here. Anyway, the baseline was also this supremely naive, sequential little thing. Which I don't think I even had? Like, I'm pretty sure it was already async/await (in go terms) from the start..

This was a fun challenge. I wanted to make the image processing pipeline more flexible and extensible, so I designed it with a modular architecture in mind. This way, I could easily swap out different compression strategies (like libvips) without having to rewrite a lot of code. It was a good exercise in software design principles.

This was another interesting challenge. I wanted to make the image processing pipeline accessible over the network, so I used the Adapter Pattern to expose its functionality via HTTP and gRPC. I also set up monitoring and metrics tracking using Prometheus and Grafana, along with some shell tooling to make it easier to work with. It was a good way to learn about distributed systems and observability.

This was a fun little project. I saw a StackOverflow question that had been open for 1000 days about how to fold single-line comments in VS Code. I thought it was a neat idea, so I built an extension that does just that. It's simple but effective, and it's nice to see other developers finding it useful.