DEV Community: Jun

What I Learned Launching a Modern Photo Sharing Site

Jun — Fri, 14 Nov 2025 08:26:08 +0000

Introduction

Recently, I set out to create a privacy-focused social platform that connects with other similar sites. My goal was to build a space that is easy to use, secure, and runs smoothly—while supporting open source values and learning from the wider community.

The Deployment Journey

Planning and Preparation

Listed what the project needed, with a focus on protecting user privacy, making sure it could grow, and keeping it reliable.
Looked up best ways to set up this kind of platform, especially how to keep user information safe and avoid sharing unnecessary details about how the site runs.

Implementation Highlights

Used automation tools to make setting up and maintaining the site easier.
Put several layers of security in place, like encrypted connections and limiting who can access certain parts of the platform.
Took extra steps to avoid sharing technical details about the site publicly, to help protect it from unwanted attention.

Overcoming Challenges

Worked through common issues with connecting to other similar platforms by asking questions in the community and reading official guides.
Fixed unexpected problems by testing changes and listening to user feedback.

Ongoing Refinements and Federation Nuances

While the platform is up and running, I’ve noticed a few small issues when trying to connect with users on other sites. Sometimes, following users on other platforms—or having them follow me—doesn’t work right away. After checking settings on both sides, I found that some networks limit new websites for the first month or so to prevent spam. As my site becomes more established, I expect these connections to improve.

These kinds of issues are normal when working with platforms that are designed to connect with many different sites.

Going Live and Measuring Success

After launching, I kept an eye on how the site was working and how people were using it, making small improvements based on what I saw.
The platform is now stable and responsive, with positive feedback from early users.

Reflections

This project taught me the value of careful planning, ongoing learning, and working with others. By focusing on privacy and security from the start, I was able to build a strong platform that users can trust.

Server Ops Report #1

Jun — Sat, 25 Oct 2025 14:09:02 +0000

Purpose: Capture the architecture, basic operation, and recent statistics of my self‑hosted Mastodon setup.

Overview

I run a private Mastodon instance on a cloud based VM (2 CPU cores, 4 GB RAM). In attempt to assure that the service stays reliable, I’ve recently started collecting statistics for the first time.

What I measured

I'm collecting CPU, disk, memory and network data. The server has crashed a couple times on the initial launch. My thought process is that documenting will provide solid data that I can share with anyone interested in the project. As well as providing an idea whether or not to upgrade or downgrade to stay cost efficient.

Current Performance Snapshot of a 24hr window

CPU is at approx. 12% average, peaked once going over 100% (full core saturation for a short burst).
Disk I/O is at approx. 20 blocks/s average, peak approx. 320 blocks/s.
Swap is near zero (not noteworthy to annotate).
IPv4 traffic is at approx. 40 Mb/s IN average, approx. 66 KB/s OUT average; peak approx. 2.7Mb/s IN, approx. 2 KB/s OUT.
IPv6 traffic is at approx. 70 KB/s IN average, approx. 2KB/s OUT average; peak approx. 5.5 Mb/s IN, approx. 170 KB/s OUT.

What the numbers tell us

The instance is performing well overall. The average CPU and disk usage are low and swap is unused.
The brief CPU spike above 100% indicates a short period of high background activity. Peak only lasted a few seconds and mitigated on its own. The extra headroom that I previously implemented after the last crash possibly helped avoid another accidental shutdown of the service.
Disk activity remains decent. This suggests media uploads and background jobs are not stressing the storage.
Inbound traffic is slowly increasing, especially on IPv6. Outbound traffic stayed low, as expected. It's a frontend service that primarily serves content rather than streams large amounts of data.

Why it matters

Reliability: The server never ran out of memory or CPU, so the user experience should have been zero to minimal lag. At least, no users have reported issues.

Scalability: Traffic is increasing, especially on IPv6. This shows that the service can attract new users without a major redesign.

Takeaway

The Mastodon server is operating well with the current build. Lessons learned from issues from my initial launch. The CPU peak is an anomaly that fixed itself. It did not impact the user experience.

What I did next

Added an alert: A simple setting now alerts me if CPU stays > 90% for more than an hour.

I’m hoping that documenting this data set will sharpen my documentation skills for future projects. If you have suggestions on additional metrics to track or ways to strengthen this writeup, please let me know.

DNS Block‑Rate Report #1

Jun — Fri, 24 Oct 2025 12:36:34 +0000

Purpose: Capture the architecture, basic operation, and recent statistics of my self‑hosted DNS filtering setup.

Overview

I’ve been running my own DNS resolver for the past ≈ 2 years. It’s a hobby‑grade service deployed on servers in several regions, heavily customized to stay reliable on diverse networks and ISP environments. Whenever the resolver is rolled out to a new region, I manually update the blocklist with region‑specific ads and trackers. I’ve recently started collecting statistics for the first time.

Why I’m measuring

Capturing query volumes and block rates gives me confidence that the filter is doing its job, helps spot regressions quickly, and provides concrete data I can share with anyone interested in the project.

What the resolver does

Receives DNS queries from my devices (and a few trusted friends’ devices).
Looks up the requested domain, then applies a locally maintained blocklist that filters out ads, trackers, and known malicious sites.
Returns the safe IP address (or a “blocked” response) back to the requester.

Current Performance Snapshot

Initial run (≈ 1 day) – 3,750 queries, 14.3 % blocked.
Extended run (≈ 12 days) – 36,708 queries, 23.98 % blocked.

The first measurement was based on only a single day of traffic, so the blocked‑query rate appeared lower. The larger data set from the extended run gives a more realistic picture of everyday usage.

Total DNS look‑ups handled: 40,458
Queries blocked by the custom blocklist: 9,342
Blocked‑query rate: ≈ 23 % (about 1 in 4 look‑ups is stopped)

What the numbers tell us

The blocked‑query rate is higher now than the very first single‑day test (which showed only 14 % blocked). The increase is not due to a sudden surge in malicious traffic; it simply reflects a larger, more representative data set spanning multiple regions and a longer observation window.

Take‑away for anyone reading this

My personal DNS service is actively filtering a significant portion of unwanted traffic while remaining fast and reliable across multiple locations. The recent numbers reflect a more accurate measurement thanks to the expanded data collection, not a change in threat level.

I’ll be extending the service to another region soon. New ads, trackers, and malicious sites appear daily, so I’ll keep the blocklist up‑to‑date.

Weekly performance tracking (planned)

I intend to capture a brief performance snapshot once per week. Each entry will include:

Date range (e.g., 2025‑10‑01 → 2025‑10‑07)
Total DNS queries processed during the week
Blocked queries and the resulting blocked‑query rate
Any notable anomalies (spikes, new blocklist additions, configuration changes)

These weekly notes will be appended to this document, creating a chronological log that can be reviewed for trends, regression detection, and capacity planning.

Example entry (Week 1 – 2025‑10‑01 → 2025‑10‑07)

Total DNS queries: 12 340
Blocked queries: 2 950
Blocked‑query rate: 23.9 %
Observation: Added a new blocklist entry for tracker.example.com; no adverse effects observed.

Jeju Island Pokémon GO Stamp Rally Map Pinning

Jun — Fri, 24 Oct 2025 02:37:39 +0000

A Brief Guide for Non-Korean Users

Jeju's official Pokémon GO Stamp Rally (which will end Oct 26, 2025) is featured on the Korean page Pokémon GO – Jeju Stamp Rally.

https://pokemongo.com/ko/post/ko-jeju-stamp-rally-event

As an international player, I struggled to locate the eight rally spots using the native map app. I turned to OsmAnd, an open-source mapping solution, entered the coordinates manually, and saved a pin for each location. I’m sharing these pins so anyone who prefers open-source maps can follow the rally without needing translations.

Rally Locations

제주국제공항 (Jeju Int. Airport) https://osmand.net/map?pin=33.50920,126.49282#13/33.50920/126.49282
중문대포주상절리대 (Daepo Jusangjeolli Cliff) https://osmand.net/map?pin=33.23718,126.42420#16/33.23718/126.42420
중문색달해수욕장 (Jungmun Saekdal Beach) https://osmand.net/map?pin=33.24509,126.41306#14/33.24509/126.41306
여미지식물원 (Yeomiji Botanical Garden) https://osmand.net/map?pin=33.25259,126.41397#16/33.25259/126.41397
베릿내공원 (Beritnae Park) https://osmand.net/map?pin=33.24559,126.41831#18/33.24559/126.41831
중문면세점 (Jungmun Duty‑Free Shop) https://osmand.net/map?pin=33.24139,126.42439#17/33.24139/126.42439
천제연폭포 (Cheonjeyeon Waterfall) https://osmand.net/map?pin=33.25293,126.41758#16/33.25293/126.41758
9.81파크 제주 (9.81 Park) https://osmand.net/map?pin=33.38992,126.36485#12/33.38992/126.36485

The Stamp Rally guides you through some of Jeju’s most scenic spots. Even if you fly to the island after the event is over, each location is worth a visit on any Jeju vacation. Especially Daepo Jusangjeolli’s cliffs, the Cheonjeyeon waterfall, and 9.81 Park. Grab the OsmAnd pins, explore at your own pace, and enjoy the island’s natural beauty. Happy travels!

Hello World

Jun — Thu, 23 Oct 2025 15:19:41 +0000

Hi dev.to! I’m Jun, the mind behind JunData.

In the evenings I monitor the health of my self‑hosted social‑media node and the query trends from my DNS‑privacy service.

When I’m not looking at graphs, I enjoy outdoor activities such as camping, hiking, and diving.

I chose the name because I love looking at raw numbers and want to build a habit of documenting.

On this blog I’ll track a few high‑level metrics, explain what they mean, and (hopefully) improve them over time:

• Server‑resource snapshots – CPU, memory and storage usage shown only as rounded percentages.
• DNS‑query trend highlights – which domain categories spike, typical daily peaks, and the privacy implications.

If anything, that’s the plan. Just like data, plans always change. We just need to keep moving.

DEV Community: Jun

What I Learned Launching a Modern Photo Sharing Site

Introduction

The Deployment Journey

Planning and Preparation

Implementation Highlights

Overcoming Challenges

Ongoing Refinements and Federation Nuances

Going Live and Measuring Success

Reflections

Server Ops Report #1

Overview

What I measured

Current Performance Snapshot of a 24hr window

What the numbers tell us

Why it matters

Takeaway

What I did next

DNS Block‑Rate Report #1

Overview

Why I’m measuring

What the resolver does

Current Performance Snapshot

What the numbers tell us

Take‑away for anyone reading this

Weekly performance tracking (planned)

Example entry (Week 1 – 2025‑10‑01 → 2025‑10‑07)

Jeju Island Pokémon GO Stamp Rally Map Pinning

Hello World

Example entry (Week 1 – 2025‑10‑01 → 2025‑10‑07)