Today I want to talk about the problem that the significance testing system is trying to solve.

Please note that this piece is entirely framed within Fisher's vocabulary. I have no intention of dragging the Neyman-Pearson framework into the discussion and complicating everything. I understand that for many readers, making sense of two sets of conditional probabilities is painful, and there is no reason to invite that trouble here. If you want to discuss this piece with an LLM, paste this note in full and strictly instruct your LLM not to introduce Pearson's terminology partway through.

It has been a long time since I last wrote React. Recently, I had a final project that called for a report, and I decided to get a little fancy: I built a presentation in React. Animations, canvas, the whole thing. Trying to do that purely in React after being away from it for a while was bound to be painful. So I figured I would write a note, mostly for myself, and leave something useful for anyone else who might need it.

Let me put on some armor before I begin. I know the frontend community has a long tradition of holy wars. Even though this piece may read like I am biting a cyber cigarette lighter, I have no intention of joining the fight. I am just someone who writes code and goes home. If you think I have gotten something wrong, you are probably right. I am an idiot, and idiots do not care. Please do not make a scene on my turf.

We often assume that research is simply about collecting data. As long as we choose the right method, secure a sufficient sample, and ask the right questions, conclusions will naturally emerge from the data. It’s as if the researcher’s only job is to be an honest recorder, faithfully presenting what they observe, and the work is done.

But if you have actually conducted research, you know it never works that way. Data does not speak for itself. It just sits there quietly, waiting for you to decide how the pieces fit together. The way you interpret it determines how it presents itself. Give the same set of numbers to different people, and they can tell completely different stories. Some see chaos, others see structure, and some see nothing at all, simply pasting the raw tables into their reports.

I have always had a strange obsession with the media we use to store music. Back in elementary school I loved using our home tape recorder to make mix tapes. It left me with so many good memories. These days my dream is to own my own cassette Walkman.

But this is not easy to pull off. Walkmans are expensive and come with plenty of headaches. (My birthday wish this year was that some kind friend would gift me one. But I know you would call me shameless for even thinking it.)

To fill that deep consumerist void, half a year ago I settled for buying a Fiio Echo Mini. It is an MP3 player designed to look like a mini cassette machine.

I'm in the mood to tell a little behind-the-scenes story about the complex technical journey of a seemingly simple interactive video player and how it works today. This article will be split into two parts: a history lesson and an overview of the current technical architecture.

This piece will focus on the process of identifying and solving problems, and how we used architectural design to reorganize business requirements and create sensible abstractions. For me, this is a record of a chapter in my life; for you, the reader, I hope it can be inspiring.