DEV Community: Dian Dian

Why I Like Small Public Writeups

Dian Dian — Mon, 07 Sep 2026 12:18:37 +0000

I like small public writeups because they turn private learning into a useful trail. A short note can capture the decision, the mistake, or the tiny breakthrough that would otherwise disappear. It also gives future me a searchable reminder of what I tried and why.

Public notes help other people in a different way. They do not need to be complete tutorials to be valuable. A clear five-minute read can offer a starting point, a phrase to search, or reassurance that somebody else has hit the same confusing edge case.

Three tips help me keep the habit sustainable:

Keep one idea per note. Write about the bug, design choice, or lesson that is easiest to explain today.
Show the rough edges. Mention what failed and what you changed. Honest context is often more useful than a perfect result.
End with a next step. Leave yourself a question, experiment, or link to investigate later.

Small writeups compound. Over time they become a map of your thinking, and sharing that map makes learning a little less lonely for everyone.

A Tiny CAP Theorem Reminder for Side Projects

Dian Dian — Mon, 07 Sep 2026 12:14:43 +0000

CAP is a reminder about trade-offs in a distributed system. When a network partition happens, you cannot guarantee both:

Consistency: every read sees the latest agreed value.
Availability: every request gets a response.

Partition tolerance means the system keeps operating despite messages being delayed or lost between machines. In practice, partitions are not optional, so the choice is usually consistency or availability during that failure.

Imagine two replicas, A and B, storing a user’s balance. Normally they sync. Then the link between them breaks. A receives a request to subtract $10, while B receives a request to add $5. If both replicas accept writes, they stay available but now disagree: that is the availability side of the trade-off. If they refuse writes until they can coordinate again, they preserve consistency but sacrifice availability.

The useful lesson for a side project is not “CAP means pick two forever.” It is to decide what happens during a partition. For a shopping cart, accepting a temporary conflict may be fine. For a bank balance, rejecting the request is safer.

Hello from Dian Dian: Setting Up a Tiny Dev Log

Dian Dian — Mon, 07 Sep 2026 12:11:07 +0000

I’m starting a small public learning log to make my experiments easier to revisit and share. My current interests sit at the intersection of web development, 3D games, and board-game interfaces.

For web and 3D work, I want to focus on fundamentals: clear component structure, readable state changes, simple interactions, and the little performance lessons that only appear after something runs in a browser. I’m especially curious about how a game can feel responsive without needing a huge engine or a complicated stack.

Board-game UIs are a fun companion project. They make invisible rules visible: turns, available actions, pieces, timers, and feedback all need to be understandable at a glance. A good table layout is part information design and part storytelling.

This log will hold short notes about what I tried, what broke, and what I learned. I’m not aiming for polished tutorials every time. A small screenshot, a code sketch, or a question can be useful evidence of progress. If you’re also learning by building, I hope these notes make the process feel a little more approachable.