This page explains what this site writes about.
Several different topics appear here, but they share one approach: recording what I actually experienced, and the judgements I made at the time. Rather than tidying information into a neat summary, the priority is capturing what I was thinking and why I decided what I decided.
Below are the principles behind the articles and what each category covers.
Sponsored
Three principles
These hold regardless of topic.
1. Write only what I experienced
I do not write about restaurants I have not visited, or books I have not read. Technical articles cover only things I ran and confirmed myself.
2. Do not assert what I have not verified
Where something is unconfirmed, I say it is unconfirmed. Details that change over time—opening hours, specifications—are dated, or accompanied by a note to check the official source.
3. Keep the reasoning, not just the conclusion
I write down how I arrived at a decision: why a particular implementation, or on what basis I judged a meal.
Conclusions change when circumstances do, but the reasoning is something a reader can map onto their own situation. That is where the value sits.
On rewriting published articles
Articles here are revisited after publication.
Technical writing especially can be correct when written and wrong a few years later. Specifications change, APIs shut down, libraries change their syntax. That is routine.
When revising, I:
- Replace code that no longer runs with the current form
- Correct factual errors, and say in the article that a correction was made
- Research replacements for discontinued services and removed features
Rather than quietly fixing mistakes, I leave a note saying “this is what I wrote before, and it was wrong”. Someone arriving from a search with the same misunderstanding is better served that way.
Sponsored
The categories
QA
Software testing and quality assurance—test techniques, automation, designing E2E tests.
Things I got stuck on, worked through or looked up, written so the situation, the reasoning and the conclusion are all visible.
Web Design & Dev
HTML, CSS and JavaScript—things tried and confirmed while building. Closer to a working log than a structured tutorial.
Browser support and specification changes matter here, so the date of the information is stated.
Book
Not summaries, but what stayed with me and where my thinking shifted.
I rarely write “recommended for everyone”. I try to say who a book suits and who it does not.
Food
Places I actually went and what I ate, kept as a record of the experience rather than a score.
Restaurant details—address, hours, closing days, access—are verified against the official site or a listing before publication. Hours change often, so checking before you travel is still advisable.
LIFE
Ways of thinking, criteria for decisions, things continued and things stopped—the background to everything else here.
Game
Notes, strategies and play records from games I have actually played.
About the English articles
Some articles have an English version. These are not translations but the same material rewritten in English.
You can reach them from the language switcher or the links at the foot of the Japanese articles.
Summary
- Write only what I experienced
- Do not assert what I have not verified
- Keep the reasoning, not just the conclusion
- Revisit published articles, and state when something has been corrected
This is largely a personal record, but the aim is a form that someone stuck on the same problem can use to decide.