Aulvem Blog

How Rakuten's API hides the JAN, and the 3-tier cross-marketplace match

Sat, 27 Jun 2026 00:00:00 GMT

Trying to compare the same product across Rakuten’s and Yahoo!‘s APIs, the first wall wasn’t price — it was identity. Before you can compute which is cheaper, a machine has to decide that this listing on one marketplace and that listing on the other are the same product. Without that, there’s no comparison table to build.

Where it got stuck was the JAN — the 13- or 8-digit barcode number on a product. Yahoo! Shopping looks one up directly with jan_code. Rakuten’s item search API never returns it. So the obvious plan — pull both marketplaces by the same JAN and tie them together in one shot — breaks on one side.

I built and shipped a price watcher on my own: yasugoro, which compares point-inclusive prices across marketplaces and pings you when a watched staple gets cheaper. To make the cross-marketplace part hold together, I split matching into three certainty tiers, assuming up front that JANs won’t always line up. Here’s that design.

Rakuten and Yahoo! are asymmetric about the JAN

The two marketplaces simply differ in how easily you can get a JAN, and designing as if they were symmetric guarantees the Rakuten side falls apart.

Yahoo! Shopping’s item search takes a dedicated jan_code parameter, so you can query by JAN directly, and the response sometimes carries janCode back. If you know the JAN, you can resolve the listing.

Rakuten’s item search has no JAN parameter. You end up putting the JAN string into keyword — an indirect match. Worse, the JAN isn’t a structured field; it tends to be buried inside the item description (itemCaption). I saw exactly this on model-numbered goods like Anker. So on the Rakuten side you always need a follow-up step: did the keyword=JAN hit actually correspond to that JAN’s product?

That asymmetry is the starting point. Yahoo! you can trust into a confirmed JAN match; Rakuten you can’t use without proof.

Collapse it into three certainty tiers

I split product identity into three tiers, ordered by how certain the match is. Instead of forcing every item through a JAN match, only the ones I can tie down with confidence sit at the top.

Tier	Method	Used for comparison	Sends alerts
① JAN match	Yahoo! direct lookup + Rakuten keyword=JAN scored for confidence	Yes (confirmed only)	Yes
② Name fuzzy match	Scored on model no. / size / brand → candidates → user confirms	After user confirms	Confirmed only
③ No match	Treated as single-store (e.g. pasted URL)	No	Own price drops only

The lower the tier, the weaker the evidence, so the right to enter comparison and to fire alerts narrows with it. Only tier ① lands in the table as “the same product to everyone”; ② and ③ are demoted in proportion to how sure the match is.

flowchart TD
  In[Input: JAN / name / URL]
  Kind{Detect kind}
  Jan[① JAN match]
  Score{Confidence score}
  Fuzzy[② Name fuzzy match]
  Cand{Candidates?}
  Single[③ Single-store]
  Cross[Enters comparison, can notify]
  Pending[Candidates, awaiting user confirm]
  Watch[Track own price drops only]

  In --> Kind
  Kind -->|JAN| Jan
  Kind -->|name| Fuzzy
  Kind -->|URL| Single
  Jan --> Score
  Score -->|high ≥0.8| Cross
  Score -->|mid ≥0.5| Pending
  Score -->|low <0.5| Single
  Fuzzy --> Cand
  Cand -->|yes| Pending
  Cand -->|no| Single
  Pending -->|confirm| Cross
  Single --> Watch

A JAN input enters at ①, a name at ②, a URL at ③ — and a weak ① hit falls through to ② or ③. It’s a two-stage funnel, not a single gate.

① JAN match: prove Rakuten hits by scoring “JAN-ness”

Even inside the JAN tier, Rakuten needs proof that a keyword=JAN hit is really the same product. I made that an additive confidence score.

Yahoo! comes in via jan_code lookup, so it goes straight to confirmed (alerts allowed). Rakuten is the awkward one — each hit accumulates a score:

JAN string appears in the item name or caption … +0.5 (the most direct evidence)
price falls inside the product-search API’s price range … +0.3 / outside it … −0.4
a model number or size can be read off the hit … +0.2

Thresholds split the score three ways. ≥0.8 is confirmed (jan, can notify), ≥0.5 is needs-review (demoted to fuzzy, no notify), and anything under 0.5 is discarded (kept out of comparison). Refusing to treat a weak hit as confirmed turned out to be the single most effective guard against wrong merges.

// Rakuten single-hit JAN confidence (excerpt)
let s = 0;
if (hit.itemCaption.includes(jan) || hit.itemName.includes(jan)) s += 0.5;
if (range) {
  const lo = range.minPrice * 0.7;   // allow 30% below (old models, parallel imports)
  const hi = range.maxPrice * 1.5;   // allow 50% above (shipping-included, bundles)
  if (hit.itemPrice >= lo && hit.itemPrice <= hi) s += 0.3;
  else s -= 0.4;                      // far outside = likely a bad match
}
if (modelOrCapacityConsistent(hit)) s += 0.2;

The price range comes from Rakuten’s product search API (productCode=JAN), which returns a min and max price. I allow 0.7× below for old stock and parallel imports, and 1.5× above for shipping-included or bundled listings. A price far outside that band gets penalized — it’s probably a different size, a different color, or another product entirely.

The catch: in practice that product search API returned 404 a lot. The price range is missing for many hits, so I can’t lean on the range term. To cover that, I added a check anchored on the cross-marketplace counterpart — the same-JAN Yahoo! hit’s representative price. If a model-number token pulled from the Yahoo! side (alphanumeric, 5+ chars, so effectively unique) appears in the Rakuten hit’s name, and the price is within ±40% of the counterpart’s price, the hit is promoted to confirmed. The model token alone could collide by chance; the price band screens that out. Both conditions have to hold.

You can see the comparison screen running in yasugoro’s live app — free, no login. When the same product lines up across marketplaces, that’s a tier ① confirmation.

② Name fuzzy match: stop at candidates, don’t auto-confirm

When all you have is a product name, I score it on model number, size, and brand and stop at surfacing candidates. Nothing auto-confirms as the same product.

The fuzzy score breaks down like this — the model number is the strongest signal by far:

model number matches … +0.5
brand matches … +0.2
size matches … +0.2
overlap of remaining tokens (Jaccard) … +0.1 × coefficient

A model number like EH-NA0J is pulled from the name by regex, and a size like 54 sheets × 3 is decomposed into “54 per pack × 3 packs = 162 total” before comparing. Only candidates scoring ≥0.6 are surfaced; if none clear it, the single best one drops to tier ③.

The person confirms the candidate, not the algorithm. Only what a user marks as “same product” gets mastered. A wrong pairing can be rejected in one tap, which removes that pair from the candidate pool for good (it won’t resurface). For cross-marketplace comparison of household staples, putting a plain confirm path and a plain undo path in front of the user beats endlessly chasing higher auto-match accuracy.

③ No match: fall back to single-store drop alerts

Anything that couldn’t be tied down at any tier becomes a single-store item. It stays out of the cheapest-across-stores ranking, and only its own page’s price drops are tracked.

A single item added by pasting a URL starts here from the outset. It isn’t on the comparison footing, so it never claims “cheaper than another store” — but it can still say “cheaper than before.” I’d rather do the honest, smaller thing than force an incomparable item into the ranking and emit a wrong “cheapest.”

What stops wrong merges is “only confirmed tiers notify”

The real reason for three tiers was to never fire an alert on a bad identity. Notifications can only fire on JAN-confirmed (jan) and user-confirmed (user_confirmed) matches. The fuzzy needs-review state and single-store items are both kept out of the trigger condition.

Locking the right to notify behind identity certainty — before any price math — matters because otherwise a price drop on a different product gets reported as “your watched item got cheaper.” The trust in a cross-marketplace comparison rests, in the end, on that identity footing.

How I compute the point-inclusive real price (splitting price into three certainty layers) is its own post: the effective-price design notes. That one is “how the price is computed,” this one is “how the same product is identified” — you need both for the comparison to hold. The running thing is yasugoro if you want to poke at it.

FAQ

Can you not get the JAN from Rakuten’s API at all?

There’s no JAN field in the item search response and no JAN-specific search parameter. In practice you throw the JAN string into the keyword parameter, and the JAN itself usually sits inside the item caption rather than a structured field. Yahoo! Shopping, by contrast, has a jan_code parameter that looks it up directly and returns janCode in the response — and that asymmetry is where the whole cross-marketplace problem starts.

Why not just match everything by JAN?

Force a JAN match on items where the JAN isn’t available and you start merging different products as one — the failure I most wanted to avoid. Rakuten doesn’t return the JAN directly, so a keyword=JAN hit needs separate proof that it’s really that product. Only items I can tie down by JAN go into the confirmed tier; weaker evidence drops to candidate suggestions, and unmatchable items drop to single-store alerts.

Why doesn’t the fuzzy match confirm automatically?

A matching model number, size, and brand still only give you a probability, and auto-confirming a guess means alerts fire on a wrong merge. The fuzzy tier surfaces candidates and only masters the ones a person confirms; a wrong pairing can be rejected in one tap, which permanently drops that pair from the candidate pool. Notifications fire only on JAN-confirmed and user-confirmed matches.

What happens to items that don’t match?

They become single-store items: dropped from cross-marketplace comparison, with only their own page’s price drops tracked. Anything you add by pasting a URL starts here too. They never enter the cheapest-across-stores ranking — they’re watched as a standalone price, and alerts only say “cheaper than before”, never “cheaper than the other store”.

How I compute the real, point-inclusive price — design notes from a 3-layer model

Mon, 15 Jun 2026 00:00:00 GMT

I built and shipped a price watcher on my own. It compares the real price — sticker price minus the reward points you earn — across marketplaces, and pings you when a watched staple gets cheaper. Going in, I figured “display price minus points” was a one-liner. The moment I started writing it, that one line turned out to be the hardest part.

Three reasons. Subtract every point and you inflate the number. Mix points you’ll definitely get with points you might get, and the listing that looks cheapest turns out to be conditional. Reward rates use different units per marketplace, and get the rounding wrong and you land a few yen off the real grant.

So here are the design decisions I landed on for that real price. In short: split points into three certainty layers, floor each layer before summing, and rank on the certain layer only. If you’re computing “which is cheaper once points are in” yourself, maybe these help.

First, define the real price

A real price is the sticker price minus the points that purchase earns you. A ¥1,000 item that returns 100 points is ¥900 real. It’s closer to what actually leaves your wallet than the sticker number is.

Points aren’t quite cash, though — they expire and they’re restricted in where you can spend them. So I fixed an assumption up front: one point equals one yen on your next purchase. Without that assumption nailed down, a cross-store comparison doesn’t even hold together. Folding the assumption into the definition was where the design started.

Where the naive version broke

The first thing I wrote was this:

const effectivePrice = displayPrice - totalPoints; // this inflates

Short, and it had three holes.

It subtracts points you might not get. Fold in entry-required campaigns or your assumed loyalty multiplier, and the cheapest-looking store becomes “the price you reach only if every condition is met.”
Reward rates use different units per marketplace. Rakuten’s multiplier, Yahoo’s campaign add-ons, limited-time points. Multiply them in one pass and the magnitude drifts.
Rounding. Points usually accrue floored. Sum several rewards and then floor, and you land a few yen off the real grant.

A few yen is enough to swap first and second place — which changes the answer to “where should I buy.” Don’t inflate, and don’t drift. A real price has to do both, or it decays into a rough hint. So I rebuilt it.

The core decision: split points by certainty into three layers

The axis I settled on was splitting points by how certain you are to receive them into three layers.

Layer	Contents	Certainty	Used for ranking
① Confirmed	Actual points the API returns	Certain	Yes
② Conditional	Known campaigns (e.g. “5 and 0 days”)	Varies (entry, etc.)	No
③ Assumed	Your own loyalty multiplier / shop-hopping	Self-reported	No

Rank on the confirmed layer alone, and show ② and ③ as “the most it could drop.” The sort order is the same for everyone — decided by certain information — while the upside flexes with each person’s conditions.

flowchart TD
  Price[Sticker price incl. tax]
  L1[① Confirmed: API points]
  L2[② Conditional: known campaigns]
  L3[③ Assumed: user settings]
  Rank[Ranking rankKey = price − ①]
  Eff[Displayed real price = price − ①②③]

  Price --> L1 --> Rank
  Price --> L2 --> Eff
  Price --> L3 --> Eff
  L1 --> Eff

Each result carries the weakest layer it includes as a certainty tier. In types, that’s all it is:

type CertaintyTier = 'confirmed' | 'conditional' | 'assumed';

A rule hangs off that: a price that includes layer ③ (assumed) never fires a notification. You can’t tell someone “buy now” on the strength of self-reported points. Notifications fire on confirmed only — or on conditional once the entry requirement is disclosed.

Floor each layer before summing

Don’t floor once at the end across layers. Floor inside each layer, then add.

let pts = Math.floor(base * rate); // floor per layer
if (cap != null && pts > cap) {
  pts = Math.min(pts, cap); // cap applies to floored point-yen
}

Real grants are usually floored per campaign too, so summing and flooring afterward lands a yen or two off. The cap behaves the same way: take Math.min against the floored point-yen. Cap first, floor second, and you’re off by one again. Unglamorous ordering, but this is what the displayed number’s credibility rested on.

There’s a quirk in how rates are stored, too. A campaign’s “+4×” is held as the added grant on top of the tax-inclusive price — an increment. The base 1× is increment zero. Multiply the price by the raw multiplier and you double-count the standard points everyone already gets. So I store only the increment as a rate.

Separate the ranking key from the displayed price

The key that sorts and the real price I show subtract different layers.

const rankKey = base - confirmedPoints;                 // ① only
const total = confirmedPoints + conditionalPoints + assumedPoints;
const effectivePrice = Math.max(0, base - total);       // negative guard

rankKey subtracts the confirmed layer only, so the order is identical for everyone. effectivePrice subtracts every layer and represents “the most this could drop” with your conditions folded in. On high-reward items the total points can exceed the price and go negative, so Math.max(0, …) guards it.

I pulled the order apart from the displayed amount on purpose: numbers that vary by reader (conditional, assumed) shouldn’t move the ranking. Let them in and you get the queasy behavior where whoever inflated their loyalty settings most reshuffles the top.

Leave shipping out of the real price, on purpose

No marketplace search API returns the shipping amount, so I decided to keep it out of the real price. Add a guess and you import error to paper over data you don’t have.

Instead, carry a flag — shipping-included, shipping-separate, or unknown — and compare only shipping-included listings on the same footing.

// only shipping-included listings enter the main ranking
function isComparableForRank(listing: Listing): boolean {
  return listing.postageFlag === 0; // 0=included, 1=separate, null=unknown
}

Mix separate-shipping and included-shipping listings into one “cheapest” and you’ll miss the ones that flip once shipping lands. Deciding not to include data you can’t get — and surfacing that decision — is more honest than half-guessing it.

Looking back

A real price reads as “sticker minus points” in one line, yet making it trustworthy stacked up quiet decisions: split by certainty, floor per layer, separate the ranking key, drop shipping. None of it is flashy. Do it sloppily, though, and “the cheapest one was actually conditional” costs you the reader’s trust. Most of the time I spent went into making this calculation’s footing solid.

This three-layer calculation runs on watched staples every day, pinging only when the confirmed layer says something genuinely got cheaper. The watcher I built around it — now live — is yasugoro: free, no login required.

FAQ

Why not just subtract all the points and compare that number?

Subtracting everything inflates the number. A price with entry-required campaigns and your own loyalty multiplier baked in is “the price you reach if every condition is met” — not a floor everyone can count on. Rank on the points the API actually confirms, and show conditional and assumed points as a separate range.

How do you handle limited-time points and entry-required campaigns?

They don’t go into the effective-price total. They live in a conditional layer, computed separately and flagged for “entry required” or “cap reached”. Only API-confirmed points are asserted as a firm amount. Conditional points are shown as “this is the most it could drop”, and they’re excluded from what triggers a notification.

If shipping isn’t in the price, won’t the cheapest option flip?

It can. But no marketplace search API returns the shipping amount, so adding a guess just imports error. I kept shipping out of the effective price and instead carry a flag — shipping-included, shipping-separate, or unknown — comparing only shipping-included listings on the same footing. Separate-shipping listings drop out of the main ranking and are disclosed in a note.

Why use different layers for ranking versus the displayed price?

The sort order should look the same to everyone. The ranking key uses only the confirmed layer, while the displayed effective price subtracts confirmed plus conditional plus assumed. That way “cheapest first” is decided by certain information alone, and the per-person upside shows up as a range on the displayed price.

Generating llms.txt and llms-full.txt in Astro for a Bilingual Site

Sun, 14 Jun 2026 00:00:00 GMT

llms.txt is a proposed entry point for letting AI search and LLMs read a site. It sits in the same spot as robots.txt and sitemap.xml — a plain-text file at the site root. The spec isn’t settled, and no major LLM vendor officially promises to consume it. I still generate one, because the cost of doing so is small.

This post is the implementation record for generating llms.txt and llms-full.txt in Astro, split into English and Japanese. I’m not going to argue whether it works — I have no measurable traffic to point at and nothing to assert. This is only about what gets generated and how. It continues the same thread as enforcing rules with a Zod schema and reciprocal hreflang: treat frontmatter and Content Collections as the single source of truth.

What llms.txt actually is

llms.txt is a Markdown index for LLMs, placed at the site root. Where sitemap.xml is a machine-readable list of URLs, llms.txt describes — in natural language, with one-line notes — what the site is and where to start reading.

The llmstxt.org spec sets a loose shape: an H1 site name and a blockquote summary at the top, then H2 sections of annotated links below. Each link follows - [Title](URL): one-line note.

The spec also names a second convention, /llms-full.txt. That one isn’t an index but an expansion of each page’s body, so an LLM can grasp the content from a single file without following links. Aulvem ships both.

	llms.txt	llms-full.txt
Role	Light index (links + notes)	Full-text-ish index (excerpts + headings + tags)
Posts	Capped at seven featured	Every post
Language	Split per language (EN / JA)	One file, EN + JA mixed, each entry language-tagged
Size	Small	Large

The minimal Astro version

Astro’s file-based API routes let you return text by dropping a .txt.ts file under src/pages/. Return a Response from a GET handler with a text/plain content type.

// src/pages/llms.txt.ts
import type { APIContext } from "astro";
import { renderLlmsTxt } from "../lib/llmsTxt";

export async function GET(_context: APIContext) {
  const body = await renderLlmsTxt({ docLang: "en" });
  return new Response(body, {
    status: 200,
    headers: {
      "Content-Type": "text/plain; charset=utf-8",
      "Cache-Control": "public, max-age=3600",
    },
  });
}

The .txt.ts extension is what matters: it builds to the URL /llms.txt. I keep the generation logic in a separate file (src/lib/llmsTxt.ts) and leave the route as a thin entry point, so a per-language endpoint can reuse the same logic.

The stack is short.

	Package	Use
	`astro` (API routes + `astro:content`)	Route definitions and Content Collections access
	`typescript`	Typing the renderer

Driving it from Content Collections

The post list inside llms.txt isn’t written by hand. It’s built on the fly from Content Collections — getCollection for posts and products. A hand-kept list goes stale: you add a post, forget the index, and llms.txt drifts from the actual content.

// src/lib/llmsTxt.ts (excerpt)
export async function renderLlmsTxt(opts: LlmsTxtOptions): Promise<string> {
  const services = await getCollection("services");
  const blog = await getCollection("blog", ({ data }) => !data.draft);

  // newest first; products order by status (active → preparing → archived)
  blog.sort((a, b) => b.data.pubDate.getTime() - a.data.pubDate.getTime());
  // ...assemble sections and return join("\n")
}

The detail to get right is the ({ data }) => !data.draft filter that drops draft: true. Skip it and a half-written draft lands in llms.txt, advertising a URL you haven’t published. I keep the same exclusion that sitemap and RSS use.

For each post’s note, I reuse the frontmatter summary (falling back to description). Every post already carries a summary written as the short answer I want quoted by AI, so the llms.txt note and the post’s own TLDR come from one place. Frontmatter stays the single source here too.

Splitting by language

This is the part that matters for a multilingual site. Aulvem drives the renderer on two axes:

filterLang: which language’s posts and products to list (ja lists only Japanese entries)
docLang: which language the document’s own text — headings, summary, usage terms — is written in

Separating those two lets one renderer emit three endpoints.

// src/pages/llms.txt.ts        → English headings, posts from all languages
renderLlmsTxt({ docLang: "en" });

// src/pages/ja/llms.txt.ts     → Japanese headings, Japanese posts only
renderLlmsTxt({ filterLang: "ja", docLang: "ja" });

The English route /llms.txt leaves filterLang unset on purpose. I treat the English version as the whole-site entry point, so it can surface posts in either language. The Japanese version /ja/llms.txt closes to the Japanese surface with filterLang: "ja".

flowchart LR
  CC[Content Collections<br/>blog + services]
  R[renderLlmsTxt<br/>filterLang / docLang]
  EN["/llms.txt<br/>docLang=en"]
  JA["/ja/llms.txt<br/>filterLang=ja, docLang=ja"]

  CC -->|getCollection| R
  R --> EN
  R --> JA

Featured posts narrow to docLang

One design call sits inside this. The English /llms.txt can surface posts from both languages, but the Featured posts section alone is narrowed to docLang.

// featured posts only in the doc language
const featuredSource = filteredBlog.filter(
  (p) => entryLangLocal(p.id) === opts.docLang,
);

Listing both halves of a translation pair in the featured slots spends two slots on one piece of content and halves the unique signal in a limited list. So the featured slots align to the document language, and the cross-language full set lives in llms-full.txt. A bounded list (seven featured posts) narrows by language; a full dump with loose size limits carries both. That’s the split.

llms-full.txt — full index with language cross-references

llms-full.txt is a separate route (src/pages/llms-full.txt.ts) that expands every post’s excerpt, headings and tags into one file. The MDX body runs through stripMdx to drop the syntax, then clip to 500 characters.

Each entry gets a language tag ((ja) / (en)), and if a translation pair exists, a Lang-Alt line cross-references the other language’s URL.

// add the paired language version as Lang-Alt
const alt = altByBase.get(slug);
if (alt) {
  const otherLang = lang === "ja" ? "en" : "ja";
  const otherPath = alt[otherLang];
  if (otherPath) {
    lines.push(`Lang-Alt (${otherLang}): ${SITE}${otherPath}`);
  }
}

This is the same idea as hreflang. I wrote up emitting reciprocal alternate links in HTML only for posts that exist in both languages in the hreflang post; llms-full.txt makes the same statement to an LLM — “this post has a paired version over here.” The aim is to keep the English and Japanese halves of one post from being counted as two unrelated documents.

How it sits next to robots.txt

llms.txt doesn’t replace robots.txt. robots.txt states whether a crawler may fetch; llms.txt states what the site contains and where the good parts are. The final permission to train or quote stays with robots.txt.

Aulvem puts a usage-and-citation section inside llms.txt: quoting is welcome, link back to the source URL, training is permitted for now. The section ends by pointing back to robots.txt as the authoritative bot policy — the machine-readable authority lives there, and llms.txt is a note, not an override. I’d keep that framing.

Leave it vague and you get a mismatch: llms.txt says “no training” while robots.txt allows everything. The two files’ stances have to be kept aligned by hand.

Pitfalls and operating rules

A few things I nearly tripped on:

Apply the draft exclusion across all three routes: put the getCollection filter in the shared renderer so llms.txt, ja/llms.txt and llms-full.txt all pass the same exclusion. Let one route through raw and drafts leak
Don’t conflate filterLang and docLang: “which posts to list” and “what language to write in” are different axes. The English version leaves filterLang unset to surface Japanese posts too — don’t read that later as a bug and add a filter
Featured language narrowing: only Featured narrows by docLang. Drop that and translation pairs fill the slots
Set Cache-Control: all three use max-age=3600. Generation is cheap, but there’s no need to rebuild on every request
Keep usage terms and robots.txt in sync: change the stance and edit both. Don’t let llms.txt stand alone

Closing

llms.txt, generated from Content Collections as an Astro API route, drops the manual upkeep every time you add a post. For multiple languages, splitting on filterLang (which posts) and docLang (the wording) lets one renderer emit the English, Japanese and full-text versions.

Whether it does anything is a separate question I’m leaving alone. How llms.txt feeds AI-search traffic isn’t a settled convention or a measured one yet. Aulvem’s stance is to generate it because it’s cheap, and to keep the authority in robots.txt.

Treating frontmatter as the single source of truth is the thread that runs from the Aulvem blog architecture post onward, if you want the wider context.

FAQ

What’s the difference between llms.txt and llms-full.txt?

llms.txt is a light index — annotated links that say what the site is and where to start. llms-full.txt carries each post’s excerpt, headings and tags as a closer-to-full-text dump. Aulvem treats the first as a curated list capped at seven featured posts, and the second as a full excerpt dump of every post.

Will publishing llms.txt get my site read by AI and bring traffic?

I can’t claim that. llms.txt is a proposed convention, and no major LLM vendor officially guarantees it consumes the file. robots.txt and sitemap.xml are still the authoritative bot signals. Aulvem keeps llms.txt because it’s cheap to generate, not because there’s measurable traffic to point to.

Should a multilingual site split llms.txt per language?

Aulvem serves a Japanese version (/ja/llms.txt) separate from the English root (/llms.txt). I want the headings and usage terms in the reader’s language, and the featured posts narrowed to that language. The full-text llms-full.txt stays as a single bilingual file, kept as a separate track from the two light indexes.

If I already have robots.txt, do I need llms.txt too?

They do different jobs. robots.txt states what crawlers may fetch; llms.txt describes what the site contains and where to read. The authoritative permission for training and citation lives in robots.txt — llms.txt is a guide on top of it. Aulvem’s usage section even points back to robots.txt as the final word.

Emitting reciprocal hreflang only when both languages exist — Aulvem's i18n customisation

Sat, 30 May 2026 00:00:00 GMT

Astro 5’s i18n gives you routing, not hreflang.

A naive “emit one <link rel="alternate"> per supported locale” implementation breaks the moment a post only exists in one language: the alternate points at a 404, Google sees the reciprocal pointer is missing, and the hreflang is quietly ignored. Worst case, it weakens the site’s multilingual signal as a whole.

Aulvem walks Content Collections to detect which language versions actually exist for a given slug, then emits <link rel="alternate" hreflang> conditionally from Seo.astro. This is the third follow-up to How this blog is built, picking up the FAQ note that hreflang and sitemap lastmod were both custom-built on top of Astro’s defaults.

What breaks when you emit alternates for every locale

The naive pattern: a 2-language site emits two <link rel="alternate" hreflang> lines on every page, one for each locale. It looks correct at first.

The break happens when a specific post only exists in one language:

A JA-only post emits a hreflang pointing at the EN URL → that URL returns 404
Google notices the EN URL doesn’t reciprocate (no JA pointer because it doesn’t render)
The hreflang is dropped, and the site’s overall multilingual signal weakens

Google’s hreflang documentation makes both rules explicit: “reciprocal pointers required” and “alternates must point at valid URLs”. A naive implementation fails both and effectively becomes a no-op — or worse, an active liability.

The two rules from Google

Two requirements have to hold for hreflang to count:

Reciprocal pointers: if A → B is emitted, B → A must exist
Valid URLs: 404 or noindex targets disqualify the alternate

The cleanest way to satisfy both is “only emit an alternate when both languages actually have a published entry”. That requires walking the content at build time to know which entries are bilingual.

Three helpers in `src/lib/posts.ts`

Aulvem keeps three helpers for the three page types (single post, product page, paginated category):

import { getCollection } from "astro:content";
import type { Lang } from "../i18n";

const LANGS: Lang[] = ["en", "ja"];

// Per-post: which languages have the entry
export async function blogAvailableLangs(slugWithoutLang: string): Promise<Lang[]> {
  const all = await getCollection("blog", ({ data }) => !data.draft);
  return LANGS.filter((lang) =>
    all.some((e) => e.id === `${lang}/${slugWithoutLang}`),
  );
}

// Per-product: same, against the services collection
export async function serviceAvailableLangs(slugWithoutLang: string): Promise<Lang[]> {
  const all = await getCollection("services");
  return LANGS.filter((lang) =>
    all.some((e) => e.id === `${lang}/${slugWithoutLang}`),
  );
}

// Per-paginated-page: does page N exist in each language?
export async function categoryPageAvailableLangs(
  category: string,
  pageNum: number,
  pageSize: number,
): Promise<Lang[]> {
  const results: Lang[] = [];
  for (const lang of LANGS) {
    const posts = await getPublishedBlog(lang);
    const inCat = posts.filter((p) => p.data.category === category);
    const lastPage = Math.max(1, Math.ceil(inCat.length / pageSize));
    if (pageNum <= lastPage) results.push(lang);
  }
  return results;
}

The draft: true filter inside getCollection matters — treating a draft-only language as “available” would emit a hreflang pointing at a URL that doesn’t render on the published build.

Unlike the sitemap lastmod implementation inside astro.config.mjs, these helpers run from layouts during page rendering. The Content Collections API is already initialised by then, so getCollection is the right tool here.

Conditional emission in `Seo.astro`

Seo.astro accepts an availableLangs prop (defaulting to both) and uses includes("en") / includes("ja") to decide which <link rel="alternate"> to emit:

---
interface Props {
  // ... other props
  availableLangs?: Lang[];
}
const { availableLangs = ["en", "ja"], lang: langProp } = Astro.props;
const lang: Lang = langProp ?? getLangFromUrl(Astro.url);

const currentPath = Astro.url.pathname;
const otherLangPath = altPathForOtherLang(currentPath, lang);
const enPath = lang === "en" ? currentPath : otherLangPath;
const jaPath = lang === "ja" ? currentPath : otherLangPath;
const enHref = new URL(enPath, Astro.site).toString();
const jaHref = new URL(jaPath, Astro.site).toString();
const hasEnVersion = availableLangs.includes("en");
const hasJaVersion = availableLangs.includes("ja");
// x-default points to EN when available; otherwise the only available lang.
const xDefaultHref = hasEnVersion ? enHref : jaHref;
---
{hasEnVersion && <link rel="alternate" hreflang="en" href={enHref} />}
{hasJaVersion && <link rel="alternate" hreflang="ja" href={jaHref} />}
<link rel="alternate" hreflang="x-default" href={xDefaultHref} />

The default value ["en", "ja"] matches the top-level pages (/, /about/, etc.) which are always bilingual. The contract is: per-entry layouts must override availableLangs. Forgetting the override on a per-entry layout means broadcasting a 404 URL through hreflang, which is the exact failure mode the helpers are designed to prevent.

x-default always falls back to EN when both languages exist, since EN is the site’s default locale. Single-language posts still get an x-default pointing at the only available language — Google’s guideline says to declare at least one supported language explicitly.

Wiring layouts to the helpers

BlogPostLayout.astro is the typical caller:

---
import { entrySlug, blogAvailableLangs } from "../lib/posts";

const slug = entrySlug(entry); // "ja/2026-05-30-foo" → "2026-05-30-foo"
const availableLangs = await blogAvailableLangs(slug);
---
<Seo
  title={data.title}
  description={data.description}
  lang={lang}
  availableLangs={availableLangs}
  // ...
/>

entrySlug strips the language prefix (en/ or ja/) before handing the slug to the helper. Forgetting the strip turns the lookup into a full mismatch and silently returns an empty array — quiet failure that doesn’t fail the build.

Paginated routes (/blog/build/[...page].astro) call categoryPageAvailableLangs(category, page.currentPage, 12) instead.

The flow

flowchart LR
  MDX[blog MDX en+ja]
  Helper[blogAvailableLangs<br/>serviceAvailableLangs<br/>categoryPageAvailableLangs]
  Layout[BlogPostLayout<br/>ServiceLayout<br/>category route]
  Seo[Seo.astro<br/>availableLangs prop]
  HTML[hreflang 0~2 + x-default]

  MDX -->|getCollection| Helper
  Helper --> Layout
  Layout --> Seo
  Seo --> HTML

The helper walks Content Collections once and returns a Lang[] to the layout. The layout passes that array to Seo.astro, which emits zero, one, or two <link rel="alternate"> lines plus an x-default.

Routing stays on the official integration

Astro 5’s i18n routing — automatic /ja/... prefixing, locale detection on request — is left untouched. It’s mature enough that there’s no incentive to rewrite it.

Aulvem’s stance is to leave anything the official integration handles well alone and patch only the gaps. Hreflang is purely an SEO-layer concern, so the override lives entirely inside Seo.astro and the helpers. When Astro eventually ships hreflang generation out of the box, peeling the override off is a one-file change.

Pitfalls

A short list of things that almost broke:

availableLangs defaults to ["en", "ja"]: appropriate for top-level pages, but per-entry layouts must override. Forgetting the override is the exact failure mode this whole setup prevents
entrySlug placement: Content Collections IDs are ja/2026-05-30-foo. Hand the prefixed ID to the helper and the lookup quietly returns [], which then emits no hreflang at all — silent regression
draft: true filtering: handled inside the helper’s getCollection filter. Without it, a draft-only language can be marked “available” and the published build has nothing at that URL
Paginated edge case: /blog/build/3/ can exist in EN but not JA if the categories diverge in length. categoryPageAvailableLangs handles this — without it, page 3 of a category would emit JA alternates pointing at 404
x-default for single-language posts: still emitted, pointing at the one available language. Google recommends declaring at least one supported locale explicitly

Wrap-up

Hreflang only counts when reciprocal pointers and existence checks both hold. Walking Content Collections at build time gives both, and the override fits in roughly 30 lines split between three helpers and a Seo.astro change. Routing stays on the official integration.

The same “frontmatter as the single source of truth” idea drives the Zod schema enforcement and the sitemap lastmod override — three follow-ups to the stack overview. The reciprocal-pointer idea carries over to LLM indexes too, in generating a bilingual llms.txt.

FAQ

Why doesn’t Astro emit hreflang on its own?

Astro 5’s i18n is scoped to routing — generating URLs and detecting the request locale. SEO meta-tag generation isn’t part of that responsibility. @astrojs/sitemap will emit hreflang inside the sitemap.xml, but the <link rel="alternate"> in the <head> is your job to write. Aulvem keeps that responsibility inside Seo.astro.

Aren’t the hreflang entries from `@astrojs/sitemap` enough?

The xhtml:link entries inside sitemap.xml are emitted, but the <link rel="alternate" hreflang> in HTML <head> is a separate channel. Google reads both, and missing the <head> channel weakens multilingual recognition at the snippet level. So both belong.

What should `x-default` point to?

Google describes it as the fallback for users whose target language can’t be determined. Aulvem has EN as the default locale, so x-default points at the EN version when one exists, and falls back to the only available language otherwise. For posts that have both languages, defaulting to EN is fine.

Does omitting hreflang for one-sided posts hurt SEO?

Not emitting hreflang isn’t itself a penalty. What hurts is emitting an alternate that points at a non-existent URL — Google flags the reciprocal mismatch and weakens the whole site’s multilingual signal. Single-language posts are safer with a clean canonical and no alternate than with a broken one.

Reading sitemap lastmod from MDX frontmatter — customising Astro's sitemap integration

Mon, 25 May 2026 00:00:00 GMT

@astrojs/sitemap won’t read updatedDate out of MDX frontmatter.

Leave it at the defaults and the sitemap’s lastmod ends up being the build time, which broadcasts the noise signal that “every post was updated on every build” to search engines and AI search. The freshness hint stops being a hint and starts being misleading.

Aulvem solves this inside astro.config.mjs by walking the blog folder, building a path-to-date map with a lightweight regex, and feeding it into the serialize hook of @astrojs/sitemap. Paginated noindex pages are dropped from the sitemap in the same pass via filter. This is the second follow-up to How this blog is built.

Why `lastmod` matters

lastmod is the last-modified date in the sitemap protocol, and search engines use it as a re-crawl priority hint. AI search engines — ChatGPT Search, Perplexity, Claude Search — read it as a freshness anchor for citation eligibility.

Two specific reasons to get it right:

Crawl priority: recently updated URLs should get re-fetched sooner
AI citation: “this article was updated N days ago” feeds into the LLM’s decision to cite the page as current information

A bogus lastmod works the other way. Google’s own Sitemap docs note that unreliable lastmod values erode site-wide trust. Painting build-time onto every URL teaches Google that this site’s lastmod is noise, which is worse than not setting one at all. Pair the implementation with a strict updatedDate policy (see content rules A-2-1) and the signal stays meaningful.

Walking MDX at config evaluation time

The lastmod map is built once, inside astro.config.mjs, by reading every .mdx / .md under src/content/blog/{en,ja}/.

import { readdir, readFile } from "node:fs/promises";
import { join } from "node:path";

async function buildBlogLastmodMap() {
  const map = new Map();
  for (const lang of ["en", "ja"]) {
    const dir = join(process.cwd(), "src", "content", "blog", lang);
    let files = [];
    try {
      files = await readdir(dir);
    } catch {
      continue;
    }
    for (const file of files) {
      if (!file.endsWith(".mdx") && !file.endsWith(".md")) continue;
      const slug = file.replace(/\.(mdx|md)$/, "");
      const raw = await readFile(join(dir, file), "utf8");
      const fm = /^---\n([\s\S]*?)\n---/.exec(raw);
      if (!fm) continue;
      const front = fm[1];
      if (/^draft:\s*true/m.test(front)) continue;
      const updated = /^updatedDate:\s*(\S+)/m.exec(front);
      const pub = /^pubDate:\s*(\S+)/m.exec(front);
      const dateStr = (updated && updated[1]) || (pub && pub[1]);
      if (!dateStr) continue;
      const d = new Date(dateStr);
      if (Number.isNaN(d.getTime())) continue;
      const path = lang === "ja" ? `/ja/blog/${slug}/` : `/blog/${slug}/`;
      map.set(path, d.toISOString());
    }
  }
  return map;
}

const blogLastmod = await buildBlogLastmodMap();

The reason getCollection("blog") isn’t used here: astro.config.mjs evaluates before the content loader is initialised. The Content Collections API simply isn’t available when the config is being read.

Frontmatter is read with a light regex. There’s no need to fully parse MDX — only updatedDate and pubDate matter for the lastmod map, and adding a YAML parser as a dependency for two fields isn’t worth it. Type-safety is sacrificed at this layer, but the Zod schema validates every post during the actual build, so the safety net moves up one step rather than disappearing.

Skipping draft: true posts here is important. If they leak through, draft URLs end up in the sitemap, which is the opposite of what draft: true is supposed to express.

Feeding the map into `serialize`

The serialize option on @astrojs/sitemap is a hook that rewrites each emitted URL entry. The map gets looked up by URL path and the result is dropped into item.lastmod.

sitemap({
  i18n: {
    defaultLocale: "en",
    locales: { en: "en", ja: "ja" },
  },
  serialize(item) {
    const url = new URL(item.url);
    // Strip the /ja/ prefix so /ja/blog/foo/ and /blog/foo/ both
    // hit the same changefreq / priority branch. lastmod lookup
    // still uses the original url.pathname so the map keys match.
    const pathname = url.pathname.replace(/^\/ja\//, "/").replace(/^\/ja$/, "/");
    if (pathname === "/") {
      item.changefreq = "daily";
      item.priority = 1.0;
    } else if (pathname === "/blog/") {
      item.changefreq = "daily";
      item.priority = 0.9;
    } else if (pathname.startsWith("/blog/")) {
      item.changefreq = "monthly";
      item.priority = 0.7;
      const lastmod = blogLastmod.get(url.pathname);
      if (lastmod) item.lastmod = lastmod;
    } else if (pathname.startsWith("/products/")) {
      item.changefreq = "monthly";
      item.priority = 0.8;
    } else {
      item.changefreq = "monthly";
      item.priority = 0.5;
    }
    return item;
  },
});

changefreq and priority go in the same hook so each path category gets a consistent value. priority is officially “ignored” by Google these days, but Bing and the AI crawlers still read it, so I keep it consistent rather than dropping it entirely.

Stripping /ja/ for the branch decision but not for the lookup matters: the lookup needs to keep the language prefix because the map was built with /ja/blog/foo/ and /blog/foo/ as distinct keys.

Filtering out paginated `noindex` pages

Page 2 and beyond of the category listings (/blog/build/2/, /blog/reviews/3/, …) ship a <meta name="robots" content="noindex, follow">. Only page 1 should be indexed; later pages are crawlable but not index-eligible.

Leave those URLs in the sitemap and the signal collides. “Listed in sitemap” reads as “please index this”, which contradicts noindex. Google and Bing both treat that conflict as a quality smell, and there’s no upside to keeping them in.

sitemap({
  filter: (page) => {
    if (page.endsWith("/404/") || page.endsWith("/404")) return false;
    // Paginated category pages (/blog/build/2/, /blog/reviews/3/ ...)
    // are noindex, follow — drop them from the sitemap to avoid
    // contradicting the meta robots tag.
    if (/\/blog\/(build|reviews)\/\d+\/?$/.test(new URL(page).pathname)) return false;
    return true;
  },
  // ...
});

If you set noindex on paginated pages, dropping them from the sitemap is the matching half of the change. Doing one without the other leaves a half-fixed signal.

How the pieces connect

flowchart LR
  MDX[src/content/blog/&lt;lang&gt;/&lt;slug&gt;.mdx]
  Map[blogLastmod Map<br/>path → ISO date]
  Pages[@astrojs/sitemap<br/>URL list]
  Filter[filter:<br/>drop noindex]
  Serialize[serialize:<br/>lastmod / changefreq / priority]
  SM[sitemap.xml]

  MDX -->|fs.readdir + regex| Map
  Map -->|lookup| Serialize
  Pages --> Filter
  Filter --> Serialize
  Serialize --> SM

Two pipelines run inside astro.config.mjs. One walks MDX before the build starts and produces the lastmod map. The other is the standard Astro routing, whose URL list is filtered down and then enriched per-entry in serialize. Both converge into the final sitemap.xml.

Things I almost got wrong

A short list of pitfalls picked up while writing this:

Top-level await: works because astro.config.mjs is evaluated as ESM. Older repo layouts that still use astro.config.cjs won’t accept top-level await, and would need either a .mjs rename or an async wrapper inside defineConfig
draft: true filtering: skipping drafts in the map builder is necessary. Otherwise draft URLs land in the sitemap, which contradicts the whole point of marking them as drafts
Regex tightness: /^updatedDate:\s*(\S+)/m reads unquoted YAML like updatedDate: 2026-05-25. Quoted strings still work because \S+ captures "2026-05-25" whole and new Date() can parse it, but be aware if you ever use multi-line or list-style date values
Per-language folder merge: en and ja are walked separately and merged into a single map. Keys are kept distinct (/blog/<slug>/ vs /ja/blog/<slug>/) so the lookup inside serialize resolves correctly
updatedDate discipline: implementation alone isn’t enough — bumping updatedDate for trivial edits will still poison the signal. The matching policy lives in content rules A-2-1

When this should move back into the official integration

Honestly, this code is the shape of a @astrojs/sitemap feature request. Coupling Content Collections to the sitemap helper is a need other Astro users will have, and there’s room to generalize it as an option.

For now it lives inside Aulvem’s config at ~30 lines, which is a size I’m comfortable maintaining. If the official integration ever ships a Content Collections bridge, the bespoke code drops away. Keeping it isolated to astro.config.mjs makes that removal cheap.

Wrap-up

lastmod is a freshness signal that matters in both classic SEO and AI search, so feeding it real values from updatedDate is worth the 30 lines of bespoke code. Drop paginated noindex pages from the sitemap at the same time — handling them separately leaves the signal half-fixed.

The first follow-up in this series is on using the Zod schema to enforce operational rules at build time → Pushing operational rules into Astro Content Collections with Zod.

FAQ

Why doesn’t `@astrojs/sitemap` read `updatedDate` on its own?

The integration takes the list of built URLs and emits a sitemap.xml — it doesn’t reach into Content Collection frontmatter. Pulling MDX shape into a generic sitemap integration would mean coupling it to collection names, schemas, and loader types, which doesn’t sit well as a default responsibility.

Isn’t reading frontmatter through `fs.readdir` + regex unsafe compared to the Content Collections API?

It’s not type-safe. But astro.config.mjs evaluates before the content loader is initialised, so the API isn’t available at this point. The only fields the lastmod map needs are updatedDate and pubDate, so a light regex pass keeps the dependency surface flat. The real type check runs at build time through the Zod schema, so there are two nets, not one.

Is it really wrong to ship `noindex` URLs in the sitemap?

It’s a contradictory signal. A sitemap is a list of URLs you want indexed, so a noindex entry collides with that intent. Google and Bing both treat the conflict as a quality smell that can drag the site-wide signal down.

Does putting a real date in `lastmod` actually move AI search citations?

I haven’t measured the lift directly. What the docs do say — Google, Bing, and the AI search vendors — is that lastmod is a freshness hint and that bogus values erode trust. Treating it as insurance against losing existing trust feels more honest than claiming a citation uplift.

Pushing operational rules into Astro Content Collections with Zod

Sat, 23 May 2026 00:00:00 GMT

Written rules get forgotten.

When you run a blog alone, the writer (you) breaks the writer’s (your) own rules sooner or later. Forgetting affiliate: true on a category: reviews post — and shipping it without the ad disclosure — is the kind of mistake a README check-list doesn’t catch.

Aulvem leans on Astro Content Collections and Zod to make rules that a machine can verify into build failures. What follows is where I draw the line between “let the schema catch it”, “let a lint script catch it”, and “leave it to review”.

This post is a follow-up to How this blog is built, which sets up the stack overview.

Why a README isn’t enough

A rule that lives only in a README has roughly zero enforcement.

The editor, reviewer, and writer are the same person, so there’s no second pair of eyes
Weeks later, the README isn’t going to be re-read line by line
Past me I trust; future me will plainly forget

I started with a checklist under docs/ and assumed that would be enough. By the third post I’d already missed an item. With no reviewer in the loop, the only way to force a rule is to put the check outside the writing flow — in the build. That’s why Aulvem leans on schema enforcement.

The schema, in one file

The Content Collections schema sits in src/content.config.ts with two collections (blog and services) declared together. Keeping them in one file means shared shapes (pubDate, updatedDate, heroImage) can be moved into local helpers without crossing file boundaries.

The blog schema looks like this (abridged):

import { defineCollection, z } from "astro:content";
import { glob } from "astro/loaders";

const blog = defineCollection({
  loader: glob({ pattern: "**/[^_]*.{md,mdx}", base: "./src/content/blog" }),
  schema: z
    .object({
      title: z.string(),
      description: z.string(),
      summary: z.string().optional(),
      pubDate: z.coerce.date(),
      updatedDate: z.coerce.date().optional(),
      category: z.enum(["build", "reviews"]),
      tags: z.array(z.string()).default([]),
      draft: z.boolean().default(false),
      affiliate: z.boolean().default(false),
      heroImage: z.string().optional(),
      heroAlt: z.string().optional(),
      howto: z.object({ /* ... */ }).optional(),
      faq: z.array(z.object({
        question: z.string(),
        answer: z.string(),
      })).optional(),
    })
    .refine((data) => (data.category === "reviews") === data.affiliate, {
      message: "affiliate must be true iff category is 'reviews'",
      path: ["affiliate"],
    }),
});

z.enum pins the category to two values, z.coerce.date swallows whatever date-string format the YAML emits, and .optional() + .default() are explicit about which fields the writer can leave blank. Plain tools cover most of the surface. The interesting work is the .refine() at the bottom, which is what the next section is about.

Coupling two fields with `.refine()`

When two fields must move together, I tack a .refine() onto the end of the schema. The case in Aulvem: a category: reviews post is, by affiliate-network rules, advertising, and has to carry the disclosure banner. Aulvem injects the banner (and adds rel="sponsored noopener noreferrer") only when affiliate: true. So the failure mode is publishing a review post with affiliate left at its default — disclosure missing, sponsored rel missing, ASP terms broken.

Here’s the one-liner that catches it:

.refine((data) => (data.category === "reviews") === data.affiliate, {
  message: "affiliate must be true iff category is 'reviews'",
  path: ["affiliate"],
})

Both sides compared with === means changing only one is a build failure. Reading the predicate as “these two are always equal” is clearer than writing the XOR explicitly — it’s the same logic, easier to scan three months later.

The build error reads like this:

[ContentEntryInvalidError] Content config error in `blog → 2026-05-...`:
affiliate must be true iff category is 'reviews'
  at affiliate

message ends up in the output verbatim, so it’s worth writing the message as instructions for future-you.

`.refine` vs `.superRefine`

Once you need more than one independent constraint on the same object, or per-field error messages, .superRefine() is the easier shape:

.superRefine((data, ctx) => {
  if (data.category === "reviews" && !data.affiliate) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: "reviews posts must set affiliate: true",
      path: ["affiliate"],
    });
  }
  if (data.draft && data.updatedDate) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: "draft posts should not carry updatedDate",
      path: ["updatedDate"],
    });
  }
})

For a single relationship between two fields, .refine() is still the lighter option.

Typing structured data inside frontmatter

I keep the data for the HowTo and FAQPage JSON-LD blocks in frontmatter rather than parsing the body. The reasons:

Parsing MDX headings to reconstruct structured data is brittle — a heading rename quietly breaks JSON-LD
Frontmatter is what Zod validates, so the shape is enforced for free
The JSON-LD generator can trust frontmatter without re-reading MDX

The schema looks like:

howto: z.object({
  name: z.string().optional(),
  description: z.string().optional(),
  totalTime: z.string().optional(),
  steps: z.array(z.object({
    name: z.string(),
    text: z.string(),
    image: z.string().optional(),
  })),
}).optional(),
faq: z.array(z.object({
  question: z.string(),
  answer: z.string(),
})).optional(),

Anything malformed — a howto with no steps, a faq entry missing answer — fails the build.

Where Zod can’t reach: body parity

Zod only inspects frontmatter. The body MDX is outside its scope.

Google’s quality guidelines flag “JSON-LD that has no body counterpart” as structured-data mismatch and pull the rich-result eligibility. A post with FAQ questions only in frontmatter — never echoed in the body — passes the schema and silently disqualifies itself.

The fix is a separate layer. Aulvem runs a validate-schema-match.mjs script that grep-checks the body for each faq[].question and howto.steps[].name:

if (Array.isArray(data?.faq)) {
  for (const [i, item] of data.faq.entries()) {
    if (!item?.question) continue;
    if (!bodyNorm.includes(normalise(item.question))) {
      mismatches.push(
        `faq[${i}].question not found in body: "${item.question}"`,
      );
    }
  }
}

It normalises whitespace and case, then checks for substring presence. If something is missing, the script returns exit code 1 and the build is blocked at the pre-commit / CI layer.

What it can’t catch: meaning. If the question matches but the answer underneath got swapped during editing, this layer says it’s fine.

What I gave up automating

Things neither the schema nor the grep validator can see:

Whether the FAQ answer is factually correct
How strong the disclosure language is (affiliate networks differ on what counts)
Whether the closing paragraph still reads like an AI draft
Whether the conclusion lines up with the article’s claim

These need a human read-through. Trying to encode them as a schema rule would cost more than the manual review they replace. I keep them in the pre-publish checklist and only push the patterns mechanically catchable (lint-banned-phrases.mjs for AI-tells) into automation.

The point isn’t “automate everything I can”. It’s deciding where build failures buy you more than they cost. With one person on the keyboard, automation time is finite, and that ratio matters.

The schema / lint / review split

Splitting rules across three layers makes “which layer should hold this?” answerable:

Layer	When it fires	What it catches	What it misses
Zod schema	`astro build`	types, enums, required/optional, field-to-field relationships	meaning, body-to-frontmatter parity
Lint script	pre-commit, CI	banned phrases, body/frontmatter substring parity	meaning
Review	pre-publish checklist	meaning, disclosure strength, AI-tell judgment	not automatable

Rule of thumb: if a higher layer can catch it, don’t push it down. Writing field-level constraints into a lint script means the build doesn’t fail and you have to remember to run the script. Pushing simple substring checks into Zod, conversely, makes the schema type definition harder to read.

Wrap-up

Structural constraints a machine can check go in the schema. Substring presence goes in lint. Meaning stays with review. Once that split is in place, every new operational rule can be sized against “which layer holds this?” instead of “where do I update the README?”.

The full Aulvem stack overview is in How this blog is built, if you want the bigger picture.

The same “frontmatter as the single source of truth” idea also drives the sitemap lastmod setup — written up separately in Reading sitemap lastmod from MDX frontmatter.

FAQ

When do you reach for `.superRefine` over `.refine`?

When one object needs more than one independent constraint, or when each issue needs its own message and path. For a single relationship between two fields, .refine() is enough. Aulvem only ties category and affiliate together, so it stays on .refine().

Why keep howto and faq inside the frontmatter instead of separate files?

Frontmatter gives me one source of truth that’s typed. Splitting them across files means the body, JSON-LD, and metadata each have their own home and have to be kept in sync by hand. Frontmatter as the source, JSON-LD generated from it, and the body echoing the same strings is the configuration with the fewest seams.

What happens to existing posts when I change the schema?

The build breaks. Adding a required field means every existing post needs the field before astro build will pass again. That’s intentional — a schema change forces you to confirm the rollout reach across every post.

Why isn’t the body-to-JSON-LD parity check wired into `astro build`?

To keep build time small. The parity check is a separate grep-based script run in pre-commit and CI. Folding it into the build itself would slow astro dev startup, which would hurt the writing loop.

How this blog is built — Aulvem on Astro 5 and Content Collections

Sun, 17 May 2026 00:00:00 GMT

This post is the starting point for documenting how Aulvem is built — not as a stack tour, but as a map of what we enforce through the schema and what we deliberately leave out. The stack itself is just Astro + MDX + Content Collections — nothing special there. What I want to write about is the design work on top of that: how operational rules a writer tends to forget get pushed into build-time checks.

The overview hub goes here. The individual decisions (schema enforcement, structured-data parity, custom sitemap lastmod) are split into follow-up posts.

Stack overview — Astro 5 + MDX + Content Collections + R2

Aulvem runs on Astro 5 (static output) + MDX + Content Collections + Tailwind 3 + Pagefind + Cloudflare R2. There’s no dynamic server — the site is just pre-built HTML served from Cloudflare Pages.

I narrowed the selection criteria to three points:

the build output is fully static
post metadata can be locked down by a schema
the core has a small dependency tree

Astro 5 met all three. The other features — partial hydration, UI framework integration, and so on — aren’t being used right now.

Whether Astro is the right pick depends on the requirements. If you want to layer on dynamic auth, comments, or subscriptions, something like Next.js is a better fit.

Definition: what Content Collections is

Aulvem defines two collections: blog (posts) and services (product pages). The schema lives in a single file and is validated at build time for both collections.

Full stack — the main packages

Runtime dependencies are kept to eight packages.

Package	Use	Notes
`astro` ^5	SSG core	static output only
`@astrojs/mdx` ^4	MDX support	all posts are `.mdx`
`@astrojs/sitemap` ^3	sitemap generation	`lastmod` injected manually
`@astrojs/rss` ^4	RSS generation	full `content:encoded`
`@astrojs/tailwind` ^6	Tailwind integration	`applyBaseStyles: false`
`rehype-external-links` ^3	rel attributes on external links	`noopener noreferrer`
`rehype-mermaid` ^3	Build-time mermaid → SVG	`inline-svg` strategy
`tailwindcss` ^3.4	styling	holding off on v4

On the dev side: pagefind (full-text search), sharp (local image processing), playwright (build-time SVG rendering for mermaid), typescript, and @types/node. No React, no Vue, no Vite plugins.

The opening rule is: don’t add a dependency on the hope it’ll be useful later. Unused dependencies show up in both build time and security-alert noise, so before adding one I check whether the use case is articulable in a sentence.

Three pieces I wouldn’t drop

1. Enforce rules through the schema

Operational rules don’t live in the README — they live in the frontmatter schema. I wanted the build to fail when a writer (including me) forgets, instead of leaning on memory.

For example, category: reviews posts have to be flagged as advertising under affiliate-network rules, so I require affiliate: true on them. Instead of leaving this as a line in the README, Zod’s .refine() forces category === "reviews" and affiliate === true to always be equivalent. Changing only one side breaks the build, so memory isn’t the load-bearing piece.

The same idea applies to the howto / faq structured data, but that belongs in a follow-up post.

2. Keep structured data and body text in sync

The JSON-LD (howto / faq) content is generated from the frontmatter, but the same content must also appear in the body. This avoids Google’s structured-data mismatch penalty — pumping out elaborate JSON-LD that has no corresponding body text violates Google’s quality guidelines, and getting caught costs you the structured-data display eligibility.

Aulvem’s rule is to write the same content on both sides — frontmatter and body — so a one-sided update can’t slip through. That alone closes off the failure mode where you fill in the frontmatter FAQ and forget the body.

3. Read sitemap lastmod from frontmatter yourself

Astro’s official sitemap integration doesn’t read updatedDate from MDX frontmatter. So Aulvem walks every MDX file with custom logic and pipes updatedDate ?? pubDate into the sitemap as lastmod.

Without that, the sitemap lastmod defaults to the build time, which broadcasts the noise signal that “every post was updated every build” to search engines. lastmod is also used as a freshness input by AI search, so it’s not a part to be sloppy on.

At the same time, paginated pages that return noindex, follow are dropped from the sitemap. Submitting a noindex URL through the sitemap is a contradictory signal, so both have to be handled together.

The implementation — walking MDX inside astro.config.mjs, wiring @astrojs/sitemap serialize and filter together, and the operational pitfalls — is in the follow-up post Reading sitemap lastmod from MDX frontmatter.

How the three pieces connect

flowchart LR
  FM[frontmatter] --> Zod
  FM --> Sitemap
  FM --> Sync
  Body[MDX body] --> Sync

  Zod["Zod schema check<br/>category ⇔ affiliate"] --> Build
  Sitemap["sitemap lastmod injection<br/>reads updatedDate"] --> Build
  Sync["frontmatter ↔ body<br/>parity"] --> Build

  Build[Astro build]

  Build --> HTML[HTML + JSON-LD + SVG]
  Build --> SM[sitemap.xml]

Two inputs — frontmatter and body — fan out through three build-time pieces and converge at Astro build. Frontmatter runs Zod schema validation and sitemap lastmod injection, while both frontmatter and body feed the parity check that makes sure the same content lives on both sides.

All results are unified by Astro build into the HTML, JSON-LD, and sitemap.xml. If any single piece fails, the build fails — so polishing one side alone won’t get you to publish.

Operational flow lives in a single source of truth

Operational flows — adding a post, adding a product, retiring a post — are anchored in one doc as the single source of truth. From there, the scaffolding and integrity-check scripts are wired in, and the rule is to follow the same steps every time. I think this absorbs most of the “the approach drifts run to run” kind of variance. What’s left is the warmth of the prose, which automation shouldn’t try to normalize anyway.

There’s also a rule: don’t bump updatedDate just because you added a preface note — bump it only on substantive revision. Search engines and AI search read dateModified as a freshness signal, so handling it loosely lowers the whole site’s authority. The criteria are fixed up front.

FAQ

Why Astro 5?

I narrowed it down to four constraints — Markdown-centric, fully static output, schema-typed frontmatter, and a small core dependency tree. Astro 5 was the best fit. Content Collections and MDX are built in, so there’s no need for extra plugins to get typed content.

Why no headless CMS (Sanity, Contentful, etc.)?

Publishing once or twice a week with one editor, MDX + git is faster than a CMS admin UI. A CMS adds the cost of draft locations, schema migrations, and API auth from day one. I’d revisit this when readership crosses ~10k, or when more editors come in.

How is full-text search implemented?

Pagefind runs after astro build and produces a static binary search index. The front end pulls it through a tens-of-KB WASM loader. No serverless function, no external API.

Does i18n use Astro’s built-in support as-is?

Routing uses Astro 5’s i18n (defaultLocale: en / prefixDefaultLocale: false) untouched. hreflang and sitemap lastmod, on the other hand, are read out of the MDX frontmatter through a custom helper. The details belong in a follow-up post.

Wrap-up

That’s the overview. Building and running this, what mattered most wasn’t which stack to pick — it was deciding how tightly to lock the frontmatter down with the schema.

Figma basics, part 3 — color, font, and shadow styles, then components and variants

Tue, 05 Apr 2022 00:00:00 GMT

2026-05-16 update: A few years on from the original. The skeleton still holds up, but the tool UI and version match when it was written and differ from the current Figma.

This post covers the Figma features that make a file easier to manage and easier to adjust.

Building up to the design file itself is covered in the earlier posts, so use those as the starting point.

The finished design from this post looks like this.

Create a color style

The screen elements are already in place from the earlier parts, so the next step is to register the colors and make them reusable.

Start with the header background color.

Point

Select the element whose color you want to register

Find the Fill section in the right sidebar

Click the four-dot icon to the right of Fill

Click the + icon to the right of Color Styles

Type the name you want to register in the modal input

Click Create style

That’s the color registered.

Registered colors pay off in places where the same color is reused across elements.

The header background color is also used for the footer background, so apply the style we just registered to the footer.

Point

Select the element you want to apply the registered color to

Find the Fill section in the right sidebar

Click the four-dot icon to the right of Fill

Under Color Styles, click the color you want to apply

The registered footer color is now in place.

Registering each color in Color Styles and applying it everywhere makes color changes much easier later on.

The GIF below edits the main color while every other color and element is already mapped to Color Styles.

Point

Click an empty area with no element selected

Find the Color Styles section in the right sidebar

Hover over the color you want to edit in Color Styles

The adjust icon appears on the right — click it

The color code shows below — click it

Pick the color you want in the color picker

As a design tightens up, the urge to fine-tune colors goes up too, so registering colors early tends to save time.

Color Styles also surfaces which color is doing which job and how many times each one is used, which makes it less likely an odd color slips in.

Create a font style

The same kind of registration exists for font settings.

Point

Select the element whose font you want to register

Find the Text section in the right sidebar

Click the four-dot icon to the right of Text

Click the + icon to the right of Text Styles

Type the name you want to register in the modal input

Click Create style

The font style is now registered.

Applying and editing a font style works the same way as Color Styles.

Set up the shadow

So far this has been about manageability. Next, add a shadow to an element.

The card frame is a good test case.

Point

Select the element you want to add a shadow to

Find the Effects section in the right sidebar

Click the + icon to the right of Effects

Click the sun icon to the right of Effects

Adjust the values under Drop shadow until they look right

Arrow keys (↑↓) nudge by 1 pixel

The card frame now has a shadow.

Shadows can be saved as a style the same way.

Point

Select the element whose shadow you want to register

Find the Effects section in the right sidebar

Click the four-dot icon to the right of Effects

Click the + icon to the right of Effect Styles

Type the name you want to register in the modal input

Click Create style

The shadow style is now registered.

Applying and editing a shadow style works the same way as Color Styles.

Combine components with auto layout

A button on a real web page changes color or content the moment it’s clicked.

To express those state changes inside Figma, the Variants feature is the right tool.

As things stand, Variants is awkward to use, so the prep step is to keep auto layout on the button and turn it into a separate component.

This section originally included a roughly 32 MiB GIF showing the component-plus-auto-layout operation. It’s been dropped because of the hosting (Cloudflare Pages) file size limit. For the actual behavior, see the Figma official documentation.

Point

Select the element you want to turn into a component

Move it outside the frame

Wrap in this order: component / auto layout / element

If the top of the element is a frame, add auto layout to it

Move the child component back to where it was in step 1

The flow is a bit involved, but the button is now a component with auto layout intact.

Create variants

A button is now ready outside the frame as a component.

From here, use Variants to express the button’s state changes.

Point: applying variants

Select the component-ised element you want to add variants to

Find the Variants section in the right sidebar

Click the + icon to the right of Variants

In the input field showing something like “Variant2”, type the sub-state name you want to register

Select the elements inside that state

Change colors or other properties

Point: switching variant state

Select the element whose state you want to change

Find the section in the right sidebar that shows the component name

Click the dropdown next to something like “Property1”

Pick the state to switch to

Adding variants outlines the component with a dotted border and duplicates the element.

Editing those duplicates is how the sub-states get expressed.

One caveat: Variants only applies to elements that are already components.

By default only one variant on top of the default can be registered, so add another state.

Point: adding a variant

Select the variant element you want to add another from

A + icon appears nearby — click it

New variants get added directly below the selected element, so starting from the bottom-most variant tends to keep the layout clean.

Finished

That’s part 3 of the Figma basics.

How to use Figma — basics, part 2

Fri, 01 Apr 2022 00:00:00 GMT

2026-05-16 update: A post from a few years back. The bones still hold up, but the UI screenshots and Figma version are from when it was written and don’t match the current build.

This post walks through the Figma basics, part 2.

I covered getting up to a design file in the earlier posts, so use those as a starting point.

The finished design from this post looks like the image below.

Setting a stroke

The earlier post stopped at the header and footer.

This time I start with the cards inside the content area.

The GIF below begins right after the frame has been created.

Point

Select the element you want to add a stroke to

Find the Stroke section in the right panel

Click the + icon to the right of Stroke

Click the color code that appears below

Pick a color from the picker, or from the swatch history under it

Set the line thickness with the number next to the three-line icon under the color code

That’s the stroke set.

Creating different elements

With the card outline in place, the next step is the contents.

I drop in a title and body text as shown in the GIF below.

Then a divider line and an avatar icon underneath, both made from primitive shapes.

Point: drawing a line

Click the ∨ next to the rectangle icon in the toolbar

Pick Line from the list

Move the cursor to where you want the line to start

Drag to set the length

Point: drawing a circle

Click the ∨ next to the rectangle icon in the toolbar

Pick Ellipse from the list

Move the cursor to where you want the shape

Drag to set the size

Snapping kicks in around centers and edges
Hold Shift while dragging to lock the X or Y axis

The divider and avatar icon are now in place under the content.

Grouping

The card frame is starting to hold a lot of elements, so I bundle them.

Point

Select the elements you want to group (multi-select)

Right-click to open the menu

Choose Group selection

In the left panel you can Shift-click to select a range

With elements selected, Ctrl + G also groups them

The card elements now live inside one group.

Changing the corner radius

The last piece inside the card is a button next to the avatar icon.

I drop a frame next to the avatar and give it a background color.

I want rounded corners on the button, so I round it off here.

Point

Select the element you want to round

Find the Frame section in the right panel

Click the number inside the red outline on the Frame row

Type the value you want

Arrow keys ↑↓ nudge by 1 pixel

That’s all the pieces inside the card built.

Creating a component

Cards usually appear more than once, so I duplicate it.

But instead of plain copy-paste like last time, I use Figma’s component feature — a stronger form of duplication.

Point

Select the elements you want to turn into a component

Right-click to open the menu

Choose Create component

With elements selected, Ctrl + Alt + K also creates a component

As the GIF shows, components do a few useful things at once:

Edits to the master component flow through to every instance
Per-instance overrides (no effect on the master)
- Toggle visibility per element
- Override text per element

Turning frames you’ll likely reuse into components — and reaching for them by default — is one of the biggest payoffs Figma gives you later.

Adding auto layout

At some point I want to swap the button label for something longer.

This is where auto layout comes in.

Point: turning on auto layout

Select the element you want auto layout on

Right-click to open the menu

Choose Add auto layout

With elements selected, Shift + A also enables auto layout

Normally, longer text would overflow the frame. With auto layout, as the GIF shows, the padding on all four sides stays put.

Reach for auto layout when an element’s width or height needs to grow with its content.

The button in that example grows to the right, which eats into the right-side margin.

One more tweak keeps the right margin intact while the button still grows.

Point: changing the start point

Select the element whose start point you want to change

Find the Constraints section in the right panel

In the small diagram, click the blue lines to set the start point

The button’s auto layout now anchors to the bottom-right, so the right margin stays put as it grows.

The labels (left, right, etc.) next to the diagram set the same thing if you prefer text.

Auto layout has another useful piece.

I use it here to set the padding around each card and the gap between cards.

Point: adjusting auto layout

Multi-select the elements you want under auto layout

Enable auto layout

Find the Auto layout section in the right panel

Click the rightmost square in the Auto layout row

Adjust the top / bottom / left / right padding in pixels

Click the three-line icon

Adjust the gap between elements

The Auto layout section in the right panel handles padding and spacing.

When the same element appears more than once, auto layout makes it easy to dial in outer padding and inter-element gaps in one place — worth reaching for by default.

The finished design

That covers Figma basics, part 2.

Next up: the features that make a Figma file easier to maintain over time.

Figma basics, part 1 — frames, fills, text, and alignment

Wed, 30 Mar 2022 00:00:00 GMT

2026-05-16 update: A post a few years old. The bones still hold up, but the tool UI and version are from when it was written and don’t match the current Figma.

Figma basics, part one. The previous post got as far as creating a design file. From here, I’m building out the screen itself.

The finished version looks like the image below. A plain screen, but it covers the core Figma basics: frames, fills, text, and alignment.

The basic layout

Rough map of the screen:

The header is the tooling
The left sidebar is the objects you’ve created
The right sidebar adjusts the object you’ve selected

Frame

First, the screen bounds.

In Figma, a screen is expressed using a part called a frame.

Frames are versatile — they’re used for the screen bounds, as outer containers for elements, and more. There are templates available, so the easiest place to start is picking one of those.

Point

Click the frame icon in the header

The frame templates appear in the right sidebar — pick the one you want

Clicking creates an iPhone 13 Pro Max frame in the center of the canvas.

The right sidebar shows the new frame labeled # iPhone 13 Pro Max.

With the screen bounds in place, next is the elements inside the screen.

Starting with the header.

The previous step used a frame template — this time, drawing a frame freely.

Point

Click the frame icon in the header

Move the cursor to where you want the frame

Drag to draw

Freehand drawing isn’t pixel-precise, so aim for roughly the right size and fine-tune later.

Use freehand drawing for larger blocks like headers, and for the base shape of small elements like buttons.

Change the background fill

The freehand-drawn frame comes out plain white. To make it easier to see, I’ll give the header frame a background fill.

Fine adjustments like fill color happen in the right sidebar.

Point

Select the element to adjust

Find the Fill row in the right sidebar

Click the + icon to the right of Fill

Click the color code shown below

Pick a color in the color picker

That switches the fill to black.

Move and resize elements

The header has its color, but the position and size are off.

Time to move it and resize it.

Point: repositioning

Select the element to adjust

Drag to where you want it

Smart guides snap to center and edges

Shift + drag locks movement to the x or y axis

Point: resizing

Select the element to adjust

Move the cursor to the bounding-box handle

Drag to resize

That puts the header roughly where it belongs, at roughly the right size.

But the height is a few pixels off, so a quick fine-tune.

Point: fine-tuning element height

Select the element to adjust

Click the H field under Frame in the right sidebar

Edit the value

Arrow up / down nudges by 1 pixel

Under Frame, X and Y are position; W and H are width and height — all editable.

Enter text

With the header frame in place, next are the elements inside the header.

For the walkthrough, putting some text in the header.

Point

Click the T icon in the header

Click where you want the text

Type once the cursor goes into edit mode

That puts the word “Header” inside the header.

Changing the font size

The text is too small as-is, so bumping the font size up to something readable.

Same as before — fine adjustments happen in the right sidebar.

Point

Select the text to adjust

Find the Text row in the right sidebar

Find the numeric field in the lower right of the Text row

Click the number

Edit the value

Arrow up / down nudges by 1 size unit

That gets the font size to something readable.

Align elements

Font size sorted. Next, the text position.

Same as before — fine adjustments happen in the right sidebar.

Point: horizontal center

Select the element to adjust

In the right sidebar, click the icon with a vertical line through the center

Point: vertical center

Select the element to adjust

In the right sidebar, click the icon with a horizontal line through the center

The other icons on the same row are the rest of the alignment options.

Header done. Next, the footer.

Same design as the header, so copying the header across.

Point: duplicating an element

Select the element to duplicate

Press Ctrl + C

Press Ctrl + V

That gives the footer copy.

It sits at the same position as the header, though — needs to move to the bottom.

Point: align to bottom

Select the element to adjust

In the right sidebar, click the icon with a horizontal line at the bottom

Footer done.

That covers the first set of Figma operations. Part two picks up the core features worth learning early when you start using Figma seriously.

How to use Figma — setup guide

Tue, 29 Mar 2022 00:00:00 GMT

2026-05-16 update: This post is a few years old now. The skeleton — create an account, create a team, create a file — still holds, but the UI details and labels are left as they were at the time. Today’s Figma has added Dev Mode, Variables, stronger Auto layout, and other features that didn’t exist back then. Read it alongside the current screens.

This is a walkthrough of what Figma is, and what it takes to get to your first design file. Three steps — account, team, file — in order, and the UI design canvas is right there.

Understand what Figma is

Figma is a UI design tool that runs in the browser. No install needed; open a URL and the editor is right there.

There are other prototyping tools out there, but for getting the shape of Figma, two characteristics stand out:

The work lives in the cloud
Multiple people can edit at the same time

The work lives in the cloud

Figma files live in the cloud, and editing happens inside the browser.

As long as the account exists, any PC with a browser can sign in and read or edit the current file. There’s nothing to install locally.

Multiple people can edit at the same time

The defining feature of Figma is that multiple people can edit the same file simultaneously.

For solo use the benefit is thin, but for prototyping at work it removes the usual friction of zipping files, mistaking which copy is the latest, and so on.

Note: it’s especially good in remote meetings. You can share your screen and fix things live as the conversation happens.

Create an account

To actually start using it, the first step is creating a Figma account.

Open the official site and head to signup.

https://www.figma.com/

The page above loads up. Click the Sign up button in the red box.

That opens the new-account modal.

Signing up with a Google account is the least friction and what I’d recommend. Email also works fine.

Create a team

Once the account is created and signed in, the next step is to create a team.

A team is similar to a folder on a PC. You create the team folder first, and design files go inside it — that’s the hierarchy.

Click the area highlighted in red below.

A team-name input screen comes up.

Type any team name and click the Create team button.

Next is a screen for inviting users to the team.

Since this is a solo setup on the free plan, click Skip for now at the bottom of the screen.

The last step is choosing a Figma plan.

Going with the free plan, so click Choose Starter in the red box. That finishes team creation.

Create a design file

With the team in place, the next step is creating the actual workspace — a design file.

Note that on the free plan you can only create up to three design files (limit as of writing — check the official pricing page for the current cap).

Creating the file itself is simple.

The team name shows up on the left side. Selecting it opens the screen below.

Clicking the area in the red box creates a new design file.

Once created, this screen opens — and that’s the end of setup.

So that covers what Figma is, and getting through to an empty canvas.

What to actually do inside that canvas is the subject of the next post — the basics guide.

Related: How to use Figma — basics 1

Design thinking, and how I actually use it at work

Sat, 19 Mar 2022 00:00:00 GMT

2026 update: A few years on from the original post. The shape of the argument still holds, but any tool UIs and version numbers mentioned are from when it was written and may have drifted from current releases.

What is design thinking?

I’ve been running into “design thinking” more often at work lately, so this is me writing down how I actually understand it.

Design thinking started as a way designers approached creative work, then got generalized as a problem-solving approach for other fields.

Where logical thinking leans on theory and numbers to solve the problem in front of you,

design thinking starts from empathy and emotion and tries to find the real problem underneath.

The example people reach for is the Ford one. The user request — “I want a faster horse” — gets read not as the literal object (a horse) but as the underlying desire (“I want to move from A to B”), and the answer becomes a car.

That’s the move: doubt the problem as presented, and go after the real problem sitting behind it.

The design thinking process

The process runs as a pattern of diverge and converge. This is the Double Diamond model.

It breaks into four stages.

Diverge and converge to find the right problem — “discover” and “define”
Diverge and converge to find the right solution — “develop” and “deliver”

You spin through these four stages, fast, and the product gets sharper each loop.

Diverging to find the right problem

Discover

The discover phase is where the core idea of design thinking — searching for the real problem — does the most work.

The job here is to observe and interview actual users and explore their needs.

Why did they take that action?
What was their emotional state, before and after touching the service?
And so on.

These are the questions you use to diverge the problem space.

You let it run wide — from the obvious things that feel too dumb to say, all the way out to weird and tangential ones — and you keep them all on the table.

Define

Once you have a spread of hypotheses, you narrow.

Which problem is the one users feel most strongly?
What’s the underlying cause, and how do you abstract it?

Bring in the marketing and sales angles alongside the user angle, and converge from more than one axis.

Diverging to find the right solution

From here, the work shifts closer to ordinary logical thinking.

For ideation, I try to keep a few things in mind:

More ideas is better than fewer
The more obvious it seems, the more worth asking about
Locking in a decision too early is a real risk
Don’t shoot ideas down

The downsides of design thinking

It costs time and money

By design (so to speak), the process eats time and money.

Real product development has deadlines, so the practical move is to put a hard time limit on each loop before you start spinning.

The bar to actually run it is high

User perspective and empathy carry the whole thing, and neither is something you pick up overnight. It takes patient practice — observation, interviews, repeat.

On top of that you need the imagination to spread ideas wide, so trying to run the full loop as a beginner is rough.

It’s overkill for small improvements

Because design thinking re-examines the problem from scratch, it’s strong at producing new solutions but expensive for incremental tweaks to existing features. For pure improvement work, plain logical thinking is often the faster path.

Putting it into practice

User perspective, empathy, idea generation — all of these need training, so running the full set from tomorrow morning isn’t realistic.

The version I’ve landed on is to pull out the essence and mix it into ordinary work, a bit at a time.

What the idea is really getting at

The core, for me, is “search for the real problem” — or, said differently, step back from the problem as it was handed to you.

User perspective is the strongest lever, but you don’t have to be locked to it. Just imagining the context behind the subject opens up a different angle. Treating design thinking as a tool for shifting your viewpoint is what makes it usable without ceremony.

Training the user’s-eye view

A quick way to train the user’s-eye view is to actually pick up the competing products you use in daily life and try them.

You start noticing the differences against what you’re used to, and the comparison becomes a habit. That’s the first step into the user’s-eye view.

Design thinking, in microdoses

You don’t have to plant a flag that says “we’re doing design thinking now”. You can slip a fragment of the mindset into ordinary work.

For example, on a given meeting agenda: is the agenda itself even framed correctly? Is the perspective too local? Practice it on small units, and the resolution of the discussion shifts, little by little.

How to pick a microSD card — reading the spec markings and matching them to use case

Sat, 26 Feb 2022 00:00:00 GMT

2026 update: ported from the old VuePress blog. The SD Association’s marking system hasn’t really changed since the original publication date, but I’ve revised the 2026 view of capacity-tier pricing and the state of SDUC (over-4TB) cards reaching the market. Specific product links should be re-checked and swapped to current models before going live.

When you go to buy a microSD card, the cards on the shelf have an alarming number of markings on the face. “SDXC”, “U3”, “V30”, “A2”, “I”. Two cards of the same capacity can differ in price by a factor of two. Which one to buy?

This piece sorts out how to read microSD markings and lays out the minimum spec by use case — phone, mirrorless camera, GoPro, Switch. By the end, the time spent staring at the shelf should drop to zero.

The short answer — read capacity and speed separately, let use case set the floor

Short answer: microSD performance is set by three layers — capacity class (SDHC / SDXC / SDUC), speed class (Class / UHS / Video Speed Class), and bus (UHS-I / II / III). Looking at any one of them in isolation isn’t enough to decide.

Minimum spec by use case:

Phone (Android): 128GB / A1 / UHS-I
Mirrorless stills + burst: 64GB or more / UHS-II card and body
GoPro / action cam 4K: 128GB / V30 / UHS-I U3
Switch / handheld game consoles: 128–256GB / UHS-I (capacity matters more than speed)
Dashcam: 64–128GB / High Endurance models

Put differently: once the use case is fixed, you only have two or three markings left to read.

Capacity class — SDHC / SDXC / SDUC

Short answer: capacity class tells you the maximum capacity the card supports, and ties into compatibility with the device. If the device is recent, you mostly don’t have to worry about it.

There are three generations:

SDHC: over 2GB up to 32GB
SDXC: over 32GB up to 2TB
SDUC: over 2TB up to 128TB

Glossary

SDHC / SDXC / SDUC specify a pair: the card’s capacity ceiling and the filesystem it uses. SDHC is FAT32, SDXC is exFAT, SDUC is also exFAT. Drop a newer-generation card into an older device and it may not read because the filesystem isn’t supported.

Compatibility: older devices are narrower

Device support is backward-compatible only, not forward-compatible. From around 2015 onward, SDXC support is basically standard, so this rarely causes friction.

Device supports	32GB and under (SDHC)	64GB–2TB (SDXC)	Over 2TB (SDUC)
SDHC only	OK	NG	NG
Up to SDXC	OK	OK	NG
SDUC-ready	OK	OK	OK

As of 2026, SDUC cards are just starting to appear on the market, and there aren’t many cases where you’d actually want a card over 4TB. For general use, the SDXC range (64GB–1TB) is enough.

Speed class — Class / UHS Speed Class / Video Speed Class

Short answer: speed class is a guaranteed minimum write speed. There are three families — Class (old), UHS Speed Class (U), and Video Speed Class (V) — with newer ones being more strictly defined.

It’s easy to muddle, but all three are about the floor (“never drops below this”), not the ceiling. The number matters most for use cases like video recording, where a stall is a real problem.

What “speed class” means

A guarantee from the SD Association on the minimum sustained write speed. “Class10”, “U1”, and “V10” are three different notations for the same 10 MB/s minimum. In some cases the markings are just different labels on the same performance.

How the three families line up

Min write	Class	UHS Speed	Video Speed
2 MB/s	C2	—	—
4 MB/s	C4	—	—
6 MB/s	C6	—	V6
10 MB/s	C10	U1	V10
30 MB/s	—	U3	V30
60 MB/s	—	—	V60
90 MB/s	—	—	V90

As of 2026 the cards on store shelves are almost all U1 / U3 / V30 / V60 / V90. The older Class 2–6 cards have mostly disappeared.

The bus interface (UHS-I / II / III) is a separate thing

Where speed class guarantees a floor, the bus interface (the row of pins on the back of the card) defines the ceiling.

UHS-I: theoretical max 104 MB/s
UHS-II: theoretical max 312 MB/s
UHS-III: theoretical max 624 MB/s

UHS-II and above add a second row of pins on the back. If the device’s slot isn’t also UHS-II, the speed falls back to UHS-I levels. Phones, GoPros, and entry mirrorless cameras usually cap at UHS-I.

Application Performance Class (A1 / A2)

Short answer: a spec for Android phones that keep apps on the SD card. On top of the minimum sustained write speed, it defines a floor for random I/O (IOPS).

Class	Min sustained write	Min random read	Min random write
A1	10 MB/s	1,500 IOPS	500 IOPS
A2	10 MB/s	4,000 IOPS	2,000 IOPS

Sustained speed is identical, but A2 is faster on lots of small-file operations. If you’re moving apps onto the SD card, A2’s upside is easier to feel. That said, A2’s real gains depend on a caching mechanism on the device side, and on Android devices that don’t implement it you may not feel any difference from A1.

Picking capacity — a realistic floor by use case

Short answer: pick capacity by the band with the cheapest cost per GB, not by “the most I could ever use”.

Cost per GB usually bottoms out in the mid-capacity range (128–256GB). The price gap between 32GB and 128GB is often only a few hundred to a thousand yen, so when in doubt, you rarely lose by going bigger.

Targets by use case

Phone (photos, video, music): 128GB floor, 256GB for headroom
4K video recording (GoPro / camcorder): 128GB is about two hours (4K60p, 100 Mbps bitrate estimate)
Mirrorless RAW burst: 64GB is about 1,500–2,000 shots (24MP RAW estimate, depends on camera body)
Switch / handhelds: 256GB holds roughly 20 downloaded titles
Dashcam: 64–128GB in a High Endurance variant. Standard cards wear out on write cycles

Comparison: minimum spec at a glance, by use case

Use case	Capacity class	Capacity target	Speed class	Bus
Phone (Android)	SDXC	128GB	A1 / U1	UHS-I
Android with apps on SD	SDXC	128GB	A2 / U1	UHS-I
GoPro / 4K action	SDXC	128GB	V30 / U3	UHS-I
8K camcorder	SDXC	256GB+	V60 / V90	UHS-II
Mirrorless stills + burst	SDXC	64GB+	V60 / V90	UHS-II
Switch	SDXC	128–256GB	U1 / U3	UHS-I
Dashcam	SDXC	64–128GB	U1 (High Endurance)	UHS-I

Recommended microSD cards

The picks below reflect the direction at the time of writing. From a 2026 vantage point, verify the current model in the same price band before linking.

Phone / Switch — 128GB / A1 / U1

A generalist baseline. As long as it meets A1 and U1 with 128GB or more, daily use is covered. SanDisk Ultra, Samsung EVO Select, and Kingston Canvas Select Plus are the usual suspects.

GoPro / 4K video — 128GB / V30 / U3

Pick a card that clears V30. Choosing one that’s on GoPro’s official compatibility list makes it easier to dodge edge-case issues. SanDisk Extreme and Lexar Professional 1066x are common picks.

Mirrorless burst — UHS-II / V60–V90

Assumes the camera body itself is UHS-II. The card speed maps directly onto how long the burst buffer takes to clear. Price is two to three times a UHS-I card.

FAQ

Q. 32GB or 128GB — which should I buy if I’m undecided? A. If undecided, 128GB. Cost per GB bottoms out in the mid-capacity range, and the price gap from 32GB is usually a few hundred to a thousand yen. The bigger risk is running out of room for video or apps.

Q. How do Class10, UHS-I U1, and V10 differ? A. All three mean a minimum write speed of 10 MB/s — just in different notations. Class is the old standard, U was defined for the UHS bus, and V was defined for video. Cards on the shelf today mostly use the V or U markings.

Q. What does a Nintendo Switch need? A. Switch officially recommends a UHS-I microSDXC. Capacity matters more than speed class in daily use, so a 128GB–256GB UHS-I U1 / U3 is plenty.

Q. Does a more expensive UHS-II card actually run faster? A. Not unless the device has a UHS-II slot. Phones, GoPros, and entry mirrorless cameras top out at UHS-I. UHS-II earns its price on mid-to-high mirrorless bodies doing burst shooting, and on 8K camcorders.

Wrapping up

microSD markings stop being confusing once you read them in three layers: capacity class / speed class / bus.

Fix the use case and the required spec narrows quickly. Phone: 128GB + A1. 4K video: 128GB + V30. Mirrorless burst: a UHS-II card. Switch: capacity first. Going the other way — buying “the fastest one” without a use case in mind — is the classic way to overpay for performance the device can’t actually use.

When you’re staring at the shelf, narrow your use case to one first. The marking decoder comes after.

Manfrotto PIXI EVO review — a ball-head mini tripod that holds a full-frame body and still fits in a bag

Wed, 16 Feb 2022 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The PIXI EVO is still in Manfrotto’s current line-up in 2026 as a staple model. The angles reviewed here — load rating, two-stage leg angle plus four-section legs, stiff ball-head lock — still hold up as practical buying criteria. The numbers are the manufacturer’s published figures from the original writing; current official specs may differ.

When I picked up a mirrorless body, I went looking for a single mini tripod that could cover desk, café, and outdoor snap shooting. Conditions: it had to stay rigid with a full-frame body on top, fit in a bag, and span low and high heights within reason.

I landed on the Manfrotto PIXI EVO. It is one step heavier than the plain PIXI from the same family, and in exchange you get four-section telescoping legs and two leg-angle modes. After more than two years of carrying it from indoor product shots to travel snaps, this is the write-up.

The verdict — a strong pick if you want one mini tripod that takes a full-frame body

Short answer: a rated 2.5 kg load covers a full-frame body, and two leg angles plus four-section telescoping legs span desk-low to just-below-eye-level. As all-rounder ball-head mini tripods go, it is one of the few practical ones.

The reasoning is simple. Mini tripods that combine “carries real weight” with “covers a real height range” are rarer than the category suggests. Most mini tripods rate at around 1 kg, have fixed-length legs, and either cannot take a full-frame body or can but never change height. The PIXI EVO addresses both gaps at once.

That said, some buyers will be happier elsewhere:

People who want to wrap legs around a pillar or handrail: the flexible-leg JOBY GorillaPod fits that use case better
People counting every gram: at 270g it is heavy for its class
People who need 1° video levelling: the ball-head lock is stiff, so micro-adjustments are awkward

Build — red logo on top, stubby integrated-head silhouette

Short answer: matte-black legs with the red Manfrotto logo on the ball head — a familiar Manfrotto palette. The head and legs are one piece, and the head lock is the unusual “turn the logo on top” mechanism.

Categorically it is a 1/4-inch ball-head mini tripod. The legs carry an angle-mode switch at the base and a push-button telescoping lock on each leg. The silhouette is distinctive enough to stick in memory.

Item	Value
Own weight	About 270g (rated)
Maximum load	About 2.5 kg (rated)
Head	Ball head (1/4-inch screw top plate)
Leg sections	4
Leg-angle modes	2 (normal / low)

You lock the head by turning the red Manfrotto logo on the front. It is firm enough that it does not slip on its own. The 1/4-inch screw tightens via the dial on the head. An Arca-Swiss compatible clamp will screw on, but it is close to twice the head’s width, so the rig leans top-heavy.

A slide switch at the base of the legs flips between normal and low leg-angle modes. The two modes are printed under the switch, so first-time use is unambiguous.

In low mode the legs splay almost flat to the surface. Useful when you are shooting product photos on a desk and want the camera right at subject height.

Folded, it is a slim cylinder. The backs of the three legs are cut at an angle so they sit flush against each other when closed. The result fits into a gap in a camera bag or the side pocket of a jacket.

Each leg has a push-button telescoping lock. Press, pull, release — that is the whole interaction.

The legs telescope in four sections. They lock at intermediate stops too, but in practice almost every shoot ends up using either fully extended or fully retracted. Treat the in-between stops as fine adjustment and the design reads more cleanly.

The camera body was in use for these review shots, so a GoPro stands in. For a GoPro-class load the PIXI EVO is wildly overspec’d, but the stability feels reassuring all the same.

What worked

Short answer: it stays rigid with a full-frame body on top; the two leg-angle modes plus four-section legs give it a real working height range; folded, it collapses into a slim stick that goes in a bag.

A 2.5 kg load rating — full-frame bodies are realistic

Unusually for a mini tripod, the head does not give up under a full-frame body with a standard zoom. A pro-grade telephoto zoom puts the centre of gravity too high to recommend, but anything up to a standard zoom is fine for desk product shots, table photography, and low-position street snaps.

The leg tips are rubber and grip on flooring and desk tops well. On gravel or concrete steps outdoors you have to adjust the leg angle so they bite, but that is a mini-tripod constraint in general, not a PIXI EVO one.

Two leg-angle modes plus four-section legs — real working height range

A typical mini tripod has fixed-length legs, which means it has exactly one usable height: “sitting on a desk.” The PIXI EVO sits flat on the floor in low mode, and reaches just below eye level in normal mode with the legs fully extended.

On a desk, low mode puts the camera at subject height for product shots. Outdoors, normal mode plus fully extended legs hits hip height for snap shots. Switching between scenes is fast. If you only want to carry one mini tripod across two or three shooting contexts, that flexibility earns its keep.

Folds into a stick — fits in the gaps in a bag

The angled cuts on the back of each leg mean the closed unit becomes a slim cylinder. It slides into the divider gap in a camera bag, or into the side pocket of a daypack. As “carryable in spite of being built for full-frame bodies” goes, it lands in the realm of “heavy but you will still bring it.”

Doubles as a selfie stick

With the legs folded, you can hold the column as a handle and get a passable selfie stick. Extending the legs while keeping them closed buys another few dozen centimetres. It will not match a dedicated selfie stick for length or weight, but on a trip the fact that you do not have to pack both a tripod and a selfie stick adds up.

What didn’t

Short answer: 270g is heavy for the class; the stiff ball-head lock makes 1° tweaks awkward; the bare 1/4-inch screw on top is exposed.

270g own weight — you notice it in the pouch

This is the flip side of “rigid enough for a full-frame body.” For a mini tripod it is on the heavy end. Drop it into a sacoche or a small pouch and you get a “do I really need to bring this today?” moment before heading out.

If portability is the deciding factor, a sub-60g flexible-leg option like the JOBY GorillaPod JB01542-PKK is the lighter answer. Load capacity and rigidity are separate concerns, though — the choice is “lighter, or higher load.”

Stiff ball-head lock, awkward at fine adjustments

The red logo plate that doubles as the head lock is firm. From a “do not let the camera fall” angle that is the right design choice, but when you are tightening a composition by one degree at a time, loosening the lock often shifts the framing more than you intended.

For video work where you want strict horizon levelling, or panning at a controlled speed, a three-way head or a dedicated ball head with independent lock pressure is the better tool. For stills, it is rarely a problem.

The bare 1/4-inch screw on top

There is no quick-release plate — the 1/4-inch screw sits exposed on the head’s top plate. Take the camera off and toss the tripod into a bag, and the screw rubs against the bag’s inner lining. A fabric inner case is enough to dodge the issue, but it is a design quirk.

Comparison

Short answer: heavier than a flexible-leg tripod but more rigid; heavier and pricier than the plain PIXI but with more load capacity and height range; less tall than a typical telescoping mini tripod, but more compact head-and-all.

vs JOBY GorillaPod JB01542-PKK — “light and unusual placements” vs “rigid and high load”

Angle	Manfrotto PIXI EVO	JOBY GorillaPod JB01542-PKK
Intended gear	Phone to full-frame standard zoom	Phone, webcam, GoPro
Own weight	About 270g (rated)	About 52g (rated)
Maximum load	About 2.5 kg (rated)	About 325g (rated)
Mounting site	Flat floor or desk	Floor, pillar, handrail, shelf edge
Height adjustment	2 leg angles + 4-section legs	Bend the legs as needed
Ball-head lock	Yes (firm)	Yes (firm, stepless)

The PIXI EVO is for planting heavy gear on a flat surface. The GorillaPod is for hooking light gear onto a non-flat one. The use cases are opposite, so the decision is “do I want to carry weight, or to place it in odd spots.” For a full comparison, see the JOBY GorillaPod JB01542-PKK review.

vs the plain PIXI — “lighter and cheaper” vs “more load and more height”

Angle	PIXI EVO	Plain PIXI
Intended gear	Up to full-frame standard zoom	Up to mirrorless standard zoom
Maximum load	About 2.5 kg (rated)	About 1 kg (rated)
Leg sections	4	None (fixed length)
Leg-angle modes	2	1
Price tier	Mid	Entry

If a phone, a compact, or a mirrorless body with a kit zoom is the full scope of use, the plain PIXI is enough. If “I might bring a full-frame body one day” or “I want to switch between low and high” is part of the plan, the EVO’s price premium is meaningful.

vs a typical telescoping mini tripod

Angle	PIXI EVO	Typical telescoping mini tripod
Maximum height	4-section legs + normal angle	Centre column reaches higher
Head	Integrated ball head	Sometimes three-way heads
Fine adjustment	Weak (lock is firm)	Three-way heads handle this well
Folded form	Legs flush, slim cylinder	Head tends to protrude
Portability	Fits gaps in a bag	Depends on size

If “slim when folded” and “switch between desk-low and just-below-eye-level” matter, the PIXI EVO wins. If “tallest possible” and “smooth video adjustment” matter, you are looking at a different category. Same “mini tripod” label, different target situations.

FAQ

Q. Should I pick the plain PIXI or the PIXI EVO? A. Decide by the gear you plan to mount. For a phone, a compact, or a mirrorless body with a kit zoom, the plain PIXI is enough. If a full-frame body with a standard-to-short-telephoto zoom is in scope, the PIXI EVO’s 2.5 kg rating and four-section legs are the safer choice. Conversely, if you only ever sit it on a desk to shoot phone vlogs, the EVO’s extra weight and bulk are overkill.

Q. Can it double as a selfie stick for a GoPro or a phone? A. With the legs closed, you can grip the column as a handle and treat it as a makeshift selfie stick. Extending the legs while keeping them closed buys another few dozen centimetres of reach. It will not match a dedicated selfie stick for length or weight, so think of it as a tripod that occasionally pulls double duty.

Q. Will it carry an Arca-Swiss compatible clamp? A. The head’s top plate is a 1/4-inch screw, so a standard Arca-Swiss clamp screws on directly. The clamp is usually close to twice the width of the head itself, so the rig ends up top-heavy. If Arca-Swiss is your default, picking the smallest clamp you can live with is steadier than swapping the head outright.

Q. Can I use it outdoors with a full-frame DSLR or mirrorless? A. Within the stated 2.5 kg load it carries fine, but ground and wind matter. On gravel or concrete steps, adjust the leg angle so the rubber feet bite. For long exposures, keep the centre of gravity low — no centre-column extension, no strap wrapped around the body. On windy days, hang a bag under the tripod as ballast.

Verdict — a strong pick if you want exactly one mini tripod

The PIXI EVO is one of the few mini tripods that simultaneously delivers load capacity, rigidity, a working height range, and a slim folded form. It is heavier than phone-only ultralights, and it cannot wrap legs around a pillar like a flexible-leg tripod, but it does make the realistic case — “carry one tripod that handles full-frame bodies indoors and outdoors” — actually work.

In more than two years of daily-ish use, neither the head lock nor the telescoping locks have loosened with age. For someone who would rather carry a little more weight in exchange for a tripod that lasts, it is the right tool.

If “as light as possible” or “wrap it around a pillar” is the real requirement, a different category will be a happier purchase. If the use case is “plant slightly heavy gear on a flat surface,” this is a hard one to regret.

Minecraft PC specs — a mid-range GPU is enough for Bedrock; for MOD/Java, mid-range GPU + 16 GB is the realistic line

Tue, 27 Apr 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. When this was first written in 2021, the baseline was a GTX 1650 / Core i5-era machine. Today Bedrock Edition is the default, and Java has settled into the role of “the MOD edition”. The piece has been rewritten end to end to reflect that.

You want to play Minecraft on a PC. But the gaming-PC market is wide, and it’s hard to tell how far you actually need to push the specs.

This piece splits Minecraft PCs into three use cases — “lightly playing vanilla Bedrock”, “Java with a lot of MODs”, and “also streaming” — and maps each to a realistic spec target. The numbers are anchored to 2026.

The short answer — 80,000–100,000 yen for Bedrock, 150,000 yen and up for Java + MODs

Short version: Minecraft is a light game on paper, but the second you start stacking MODs on Java, the required specs jump.

The realistic 2026 targets fall into three tiers.

Vanilla Bedrock: GTX 1650 / RTX 3050-class GPU + 16 GB RAM + Ryzen 5 / Core i5. 80,000–100,000 yen for a prebuilt
Java + MODs / shader MODs: RTX 4060-class GPU + 32 GB RAM + Ryzen 5 / Core i5 (6 cores or more). 150,000–200,000 yen
Streaming too: RTX 4060 Ti or better + 32 GB RAM + Ryzen 7 / Core i7 (8 cores or more). 200,000 yen and up

The flip side: a bargain laptop with only integrated graphics will force you to cut render distance even on vanilla. If you plan to play long-term, picking a discrete-GPU machine from the start tends to be the cheaper choice in the end.

How to read the recommended specs — official numbers are the “minimum to run”

Short version: Mojang’s official recommended specs are the floor for “runs without stuttering”, not the line for “plays comfortably”.

The official Java recommended specs (as of 2026) sit roughly here:

CPU: Intel Core i5-4690 3.5GHz / AMD A10-7800 APU 3.5GHz equivalent
RAM: 8 GB
GPU: GeForce 700 series / Radeon Rx 200 series (OpenGL 4.5 capable)
Storage: 4 GB SSD
OS: Windows 10 or later / macOS 10.12 or later / major Linux distros

What to take from this: Java leans on the CPU and RAM. The GPU can be modest and the game will still run, but redstone circuits and large builds depend heavily on single-threaded CPU performance — cut the CPU and you’ll feel it in world loading and chunk generation.

Bedrock requirements are lower, but RTX is its own story

Bedrock Edition is built on DirectX 12 and is more optimised, so at equal graphics settings it runs lighter than Java. The official RTX ray-tracing mode is a separate matter, though — it needs ray-tracing cores on the GPU, which in practice means RTX 20-series or newer.

For Java, MODs are the real workload

Java is best planned around MODs from the start. Once MODs and shader MODs go in:

Shader MODs (OptiFine, Iris + Sodium and friends): GPU load climbs sharply
Large MOD packs (200–400 mods): RAM use rises from 8 GB to 12–16 GB
Heavy industrial / automation MODs: single-thread CPU and RAM bandwidth start to matter

The official spec table is for vanilla Java, so if MODs are in the plan, bump one or two ranks above it.

MOD/Java vs Bedrock — choosing in 2026

Short version: in 2026, Bedrock is the default; Java is what you keep around for MODs and shader MODs.

Buying Minecraft on a PC store generally bundles Java & Bedrock Edition together, so the question isn’t “which do I buy?” — it’s “which do I mostly play?”

Reasons to pick Bedrock

Crossplay: multiplayer with Switch / PlayStation / Xbox / phones
Official RTX support: ray tracing out of the box
Marketplace: official store for skins and worlds

Reasons to pick Java

MOD ecosystem: a mature MOD culture built around Forge and Fabric
Shader MODs: Iris + Sodium lets you raise the visuals while keeping things light
Backwards compatibility: Java worlds from the 2010s open as-is

Bedrock’s RTX and Java’s shader MODs are two different things. Both fall under “I want Minecraft to look good”, but the kind of GPU each one wants is different, and it’s worth keeping that distinction in mind.

Comparison table — recommended specs by use case

Aspect	Lightweight (vanilla Bedrock)	MOD-heavy (Java + shader MODs)	Streaming too
CPU	Ryzen 5 / Core i5 (6 cores)	Ryzen 5 / Core i5 (6 cores or more)	Ryzen 7 / Core i7 (8 cores or more)
GPU	GTX 1650 / RTX 3050	RTX 4060	RTX 4060 Ti or better
RAM	16 GB	32 GB	32 GB
Storage	500 GB SSD	1 TB SSD (MOD packs and world files take room)	1 TB SSD + a second SSD for recordings
Render distance	16–24 chunks / 60 fps	24–32 chunks / 60 fps	16–24 chunks + 60 fps stream
Price band (prebuilt)	80,000–100,000 yen	150,000–200,000 yen	200,000–300,000 yen

The numbers are pegged to a 2026 mid-range build.

CPU: single-thread speed matters more than core count

Java’s chunk generation and redstone math lean on a single thread, so per-core performance (clock × IPC) moves the needle more than core count. Core count starts to matter only once you add streaming — the encoder will use it.

GPU: “Bedrock RTX or Java shader MODs” decides the target

Bedrock RTX: RTX 20-series or newer; a 4060 is plenty
Java + Sodium + shader MODs: RTX 3060 for medium settings, RTX 4060 or better for high

If you just default to “RTX 4060”, you cover both Bedrock RTX and the heavier Java shader setups.

RAM: pick based on MOD pack size

Vanilla alone runs fine on 16 GB. For MOD packs, go with 32 GB. Java’s launch arguments (-Xmx) let you assign how much RAM the game gets, so you also want headroom for the system on top of that.

Storage: SSD is the only call; size depends on worlds and MODs

For just the OS and Minecraft itself, 100 GB is enough. But once you stack MOD packs and large worlds (a few GB per world), things fill up fast. Putting a 1 TB SSD in from the start saves regret later.

Recommended builds

The picks below are anchored to 2026. BTO line-ups shift month to month, so verify the latest-generation equivalent before buying.

Bedrock-focused: a gaming laptop is enough

For lightweight play, a 15.6-inch gaming laptop with an RTX 3050 Ti / 4050 is plenty.

Item	Spec
Display	15.6-inch FHD
CPU	Core i5 / Ryzen 5 (latest generation)
RAM	16 GB
GPU	GeForce RTX 3050 Ti / 4050
Storage	512 GB SSD

MODs / streaming: a desktop

On heat, expandability, and price-performance, the desktop wins.

Item	Spec
CPU	Ryzen 5 / Core i5 (latest generation, 6 cores or more)
RAM	32 GB
GPU	GeForce RTX 4060
Storage	1 TB SSD

FAQ

Q. Bedrock Edition or Java Edition — which should I buy? A. Pick Bedrock if you care about crossplay or official RTX support. Pick Java if you want MODs and shader MODs. As of 2026, buying either edition on PC usually bundles both as Minecraft: Java & Bedrock Edition.

Q. Will MODs run on a laptop? A. A gaming laptop with a GeForce RTX 3050 Ti / 4050 or better will run them. But with heavy setups — shader MODs plus a 32-chunk render distance — heat and thermal throttling tend to make things unstable. If you’re serious about MODs, go desktop.

Q. Is 16 GB or 32 GB of RAM the right pick? A. For Bedrock and vanilla Java, 16 GB is enough. For MOD packs (over 200 mods), large redstone contraptions, or running streaming software alongside the game, go with 32 GB. Whether the model lets you add memory later is also worth weighing.

Q. Can I play on integrated graphics (a CPU’s built-in GPU)? A. Recent integrated GPUs — Ryzen AI series, Intel Arc — can now run vanilla Bedrock at 1080p / medium settings. Java Edition and shader MODs still drop frames, though, so if you plan to play long-term, picking a discrete-GPU model from the start usually works out cheaper.

Wrapping up

For a Minecraft PC, what you play decides how much spec you need.

Vanilla Bedrock → GTX 1650 / RTX 3050 + 16 GB, 80,000–100,000 yen
Java + MODs / shader MODs → RTX 4060 + 32 GB, 150,000–200,000 yen
Streaming too → RTX 4060 Ti + 32 GB + 8-core CPU, 200,000 yen and up

In 2026 Bedrock is the default, but Java is still around for MODs and shader MODs. If you want to keep both options open, RTX 4060 + 32 GB is the build that covers the widest ground.

The monitor side of the question is covered in a separate piece.

Sony Walkman NW-A105 review — the Type-C, Android DAP I switched to, revisited from 2026

Sat, 24 Apr 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog (originally written in 2021, after about half a year of use). As of 2026, the current A-series line is the NW-A300 (NW-A306 in Japan, A307 internationally, released 2023). The NW-A105 itself is discontinued, with new stock only while supplies last. The bones of this review still hold up — just read it alongside the current model when considering a purchase.

I used the Sony Walkman NW-A105 for over five years, for music on the commute and on the road. It was the first Walkman generation to combine USB Type-C, microSD, and Android — the model where the connector finally caught up with the rest of the world.

Looking back from 2026, though, the strengths and weaknesses sit on very different sides of the ledger. This is a long-term impression, compared against the current NW-A300 line and against going phone-only.

The verdict — a first-generation Type-C / microSD / Android DAP; for a new purchase, go A300

Short answer: the NW-A105 was valuable as the first generation of Walkman with Type-C and Android. The sound-tuning depth still holds up. But the CPU and battery let it down, and for a new purchase in 2026, the current NW-A300 line is the easier recommendation.

The reasoning is that the NW-A105’s weak points — sluggish responsiveness and high idle drain — are tied to internal parts. They are not the kind of thing a firmware update can fix at the root. The later battery-saver helped operationally, but the underlying issue is still there.

Who should and should not buy one:

Worth it: anyone who can find a cheap used unit and wants wired earphones, microSD, and deep sound tuning
Skip it: anyone buying new, anyone whose music life is already on a phone, anyone who prioritises battery life

Build and layout

Short answer: a small Android device with a 3.6-inch touchscreen. The physical buttons cluster on the right edge; the bottom carries the 3.5 mm jack, USB Type-C, and microSD slot.

A hi-res-capable, Android-powered Walkman. Most operations happen on the touchscreen.

Spec	Value
Display	3.6 inch
Dimensions	55.9 × 98.9 × 11 mm
Weight	103 g
OS	Android 9 (at launch)
Ports	USB Type-C / 3.5 mm jack / microSD

(rated)

The back is matte, with a Walkman logo. Fingerprints stay out of sight.

The left flank is bare — no buttons.

All the operating buttons live on the right. From left to right: hold / back / play-pause / forward / volume down / volume up / power. That layout lets you control playback blind, with the unit still in a bag or pocket — exactly what a DAP should get right.

The bottom edge holds the 3.5 mm jack, a strap hole, USB Type-C, and the microSD slot. Keeping the 3.5 mm jack matters a lot if you live on wired earphones.

The home screen sticks close to stock Android. You can add apps freely (Google Play is supported).

What worked

Short answer: the Type-C / microSD / Android trio, plus the depth of Sony’s sound-processing options.

USB Type-C — the reason I switched

This was the deciding factor when I bought it. Earlier Walkman models used Sony’s proprietary WM-PORT, which meant carrying a dedicated cable everywhere.

Moving to Type-C means the same cable as the phone and the tablet. The “I forgot the Walkman cable on a business trip” disaster simply stops happening. That alone changed how I packed.

microSD adds storage after the fact

Internal storage is a modest 16 GB. Trying to manage a hi-res library on internal storage alone is not realistic.

Put another way: the device assumes a microSD card. The internal memory is for OS and apps; music lives on the card. With support up to 1 TB microSDXC, there is enough headroom for a serious library.

Sound tuning runs deep

This is where a Sony DAP earns its keep.

The equaliser is roughly ten bands of fine adjustment, with genre presets on top.

Noise cancelling assumes Sony’s compatible earphones (the IER-NW500N and similar). On a commuter train, it knocks the noise floor down hard.

The main sound-processing features:

DSEE HX: upscales compressed audio toward hi-res
DC Phase Linearizer: corrects phase characteristics to mimic an analogue amp
Dynamic Normalizer: evens out volume differences between tracks
Vinyl Processor: shapes the sound to feel like a record
ClearAudio+: Sony’s recommended auto-optimisation preset

What you learn after living with it is that “everything on” is not always best. Toggling DSEE HX on or off per genre, for example, is where the sound changes character if you put in the time.

Android opens it up

It runs Android 9 at the base. Spotify, Apple Music, and YouTube Music install through Google Play. A single device handles a local library and streaming side by side.

Bluetooth pairing for handing audio off from a phone works the way you would expect.

What didn’t

Short answer: battery life and CPU speed. Both come down to hardware; neither is fixable in software.

Battery drain is high

The biggest complaint.

Just leaving it powered on visibly drains the battery. Idle for a day without playback still costs a meaningful chunk of the meter.

Sony quotes around 26 hours of hi-res playback. In real use, what hurts is the consumption during the hours you are not listening. A later firmware update added a battery saver that powers the unit off after a set period of inactivity, and that helped a lot operationally. It is still not a fix at the root.

For commuting, where you charge at home or at work every day, this is fine. For a two-day business trip without an easy charge, it is tight.

A general sluggishness

The CPU is modest, and it shows up as friction when opening apps, switching screens, or scrolling a large library.

It is not a device you tap constantly the way you do a phone, so it never becomes critical — but opening Spotify, tapping the search bar, and typing into it feels heavier than it should.

Software support has ended

As of 2026, the NW-A105 is still on Android 9, with no major updates. From a security standpoint, it is not suitable as a primary phone substitute.

As a dedicated music player, that is acceptable. The long-term compatibility of streaming apps, though, is not guaranteed.

Comparison — NW-A105 vs NW-A300 series vs phone-only

Short answer: buy new and the NW-A300 wins. Want the cheapest path that still works, used NW-A105. Want a single device for everything, the phone is fine.

Angle	NW-A105 (2019)	NW-A300 series (2023–)	Phone-only
OS	Android 9	Android 12 base	Latest per device
Perceived CPU speed	Sluggish	Improved	Depends on device
Battery (rated hi-res)	~26 hours	~36 hours (rated)	Shared with everything else
Internal storage	16 GB	32 GB (rated)	Depends on device
microSD	Yes (up to 1 TB)	Yes	Usually no
Ports	USB Type-C / 3.5 mm	USB Type-C / 3.5 mm	Type-C only on most
Noise cancelling (Sony earphones)	Supported	Supported	Not supported
DSEE HX-style processing	Yes	Yes (now DSEE Ultimate)	No
Price (2026 expectation)	Mostly used	New, ~mid-40,000s yen and up	Already in the phone

The decision splits cleanly:

You care about sound processing and a wired chain, and you do not want music draining the phone → NW-A300
Same requirements, minimum cost → NW-A105 used
Streaming-centric, wireless earphones, one device for everything → phone-only. You do not need a DAP

FAQ

Q. Is the NW-A105 worth buying new in 2026? A. For a new purchase, the current NW-A300 line (NW-A306 in Japan / A307 internationally) is the easier recommendation. The NW-A105 was released in 2019, and its CPU and battery life are both weak. If you only want a DAP with microSD, Type-C, and Android, and you can find a cheap used unit, it is still an option.

Q. Compared with listening on a phone, is there a reason to carry an NW-A105? A. Yes, if you want Sony’s noise cancelling or DSEE HX sound processing, or if you do not want music playback eating your phone’s battery. If your library lives entirely in streaming and you do not use wired earphones, a phone alone is enough.

Q. How long does the battery last? A. Sony lists about 26 hours of hi-res playback. In practice, idle drain is high — leaving it powered on for a day burns through a visible chunk even without playing. A later firmware update added a battery-saver auto-off feature.

Q. What is the maximum microSD capacity? A. Up to 1 TB microSDXC. Internal storage is only 16 GB, so any serious hi-res library has to live on the card — the design assumes you will use one.

Verdict — a device for experiencing the first Android-on-a-DAP generation

The NW-A105 belongs to the generation where “the Walkman finally went Type-C” and “the Walkman runs Android” arrived together. As a reason to buy at the time, that was enough, and after five-plus years it never stopped being a reliable home for the library.

Would I recommend buying one new today? No. The CPU and the battery are tied to the internal design, and the successor generation improved both directly. Either go cheap on a used unit, or step up to the current NW-A300 — those are the two sensible paths.

If your phone, paired with streaming and wireless earphones, already covers your music, there is no reason to add a DAP. Carrying one only earns its keep if you are unwilling to give up one of the three: wired earphones, deep sound processing, or microSD.

HDD vs SSD — in 2026, SSD is the default; HDD is for high-capacity archives

Wed, 21 Apr 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. When this was first written in 2021, the practical answer was a hybrid setup — “OS on SSD, data on HDD”. By 2026, SSD prices have dropped enough that SSD is the default on both laptops and self-built desktops. HDDs are now narrowed to backups, video footage, and other multi-TB archival use. The underlying framework — how the two technologies differ — still holds.

A slow PC, or a fresh purchase where you can’t tell whether to go SSD or HDD — this is where a lot of people stall. Once the structural difference is clear, the call gets easier.

This piece lines up HDD vs SSD on speed, cost per GB, lifespan, noise, and shock resistance, and sums up how to choose in 2026.

The short answer — SSD for system, HDD for bulk storage

In 2026, if you’re buying or building new, the system drive that holds the OS and apps should be an SSD (NVMe if possible). HDDs work as secondary storage when you want several TB on the cheap.

The reason: SSD prices have fallen significantly over the past five years, and 1 TB-class drives now sit in the mainstream price band. HDDs still win on cost per TB, and they keep their edge in the 4 TB / 8 TB range.

For example: if you’re replacing a laptop, an SSD-only setup is plenty. If you’re building a desktop and you stockpile video footage or photo RAWs, a two-drive setup of 1 TB SSD (system) + 4 TB HDD (data) is the realistic call.

One thing to note: rather than keep using an old HDD-only PC, swapping the boot drive to SSD is usually the single most effective upgrade. It often costs less than buying a new machine.

The main differences between HDD and SSD

Looked at across six axes, SSD wins on “fast, quiet, shock-resistant”; HDD wins on “cheap at high capacity, long track record”.

Aspect	HDD	SSD
Read/write speed	Slow (around 100–200 MB/s sequential)	Fast (SATA up to ~550 MB/s, NVMe several thousand MB/s)
Cost per GB	Cheap (clear win at 4 TB and above)	Higher (though 1 TB-class is now mainstream-priced)
Lifespan	Mechanical wear causes failure	Limited write endurance, but strong against shock
Noise	Spin and seek noise	Silent
Shock resistance	Weak (a drop while running often kills it)	Strong (no moving parts)
Price guide (1 TB)	A few thousand yen and up	Around 10,000 yen and up (NVMe runs higher)

The reason is structural: the two are built on fundamentally different mechanics. HDDs record magnetically on a physically spinning disk; SSDs record electrically on semiconductor memory. That single difference drives every row in the table.

One thing to note: the table is a general trend. Between NVMe SSD and SATA SSD, the speed gap widens further by several times. See the FAQ for more.

What an HDD is — a spinning disk that stores data magnetically

An HDD (Hard Disk Drive) writes and reads data magnetically on a spinning metal platter. It’s a mechanical device with moving parts — structurally closer to a CD player than to a memory chip.

The reason it’s slower is mechanical: the platter spins at high speed and the magnetic head physically moves to the right location, so there’s always a physical motion in the loop. That is the root cause of “slow reads, audible noise, fragile to shock”.

For example: a typical 3.5-inch HDD spins at 5400 rpm or 7200 rpm. The seek noise (the head moving) and the spin noise are constant, which makes HDDs hard to live with if you’re going for a silent build.

One thing to note: the HDD’s strength is cheap capacity. In the 4 TB / 8 TB / 16 TB range, the cost per TB is still lower than SSD in 2026. For backups, video footage, and NAS use, HDDs are very much still in service.

What an SSD is — semiconductor memory that stores data electrically

An SSD (Solid State Drive) writes and reads data electrically on flash memory (semiconductors). It has no moving parts at all — structurally closer to a scaled-up USB stick.

The reason it’s fast is structural: 0 / 1 is encoded by the presence or absence of electrons in a semiconductor, so no physical movement is needed. That is the root cause of “fast, silent, shock-resistant, light”.

For example: booting the same OS, an HDD machine often takes 30–60 seconds, where an SSD machine is up in around 10 seconds. This is why putting an SSD into an older PC feels so different.

One thing to note: SSDs have a finite number of writes (often quoted as TBW, Total Bytes Written). For normal office, gaming, or development workloads, hitting that ceiling is rare. In everyday use, HDDs more often fail mechanically before an SSD wears out.

How to split the workload between SSD and HDD — 2026 edition

The system drive (OS and apps) goes on SSD. The data warehouse (photos, video, backups) goes on HDD. That is the 2026 baseline.

The reason: boot and app launch speed obviously benefit from SSD, while archival storage is accessed less often, so the speed gap is harder to feel there. Letting the HDD — which wins on cost per TB — handle the “cold” data is the rational split.

Laptops / general use — a single SSD is enough

For a laptop or a typical desktop, a single SSD (512 GB to 1 TB) is the mainstream setup. Skipping the HDD also means lighter weight, less noise, and lower power draw.

For gaming or video editing, target 1 TB or 2 TB.

Self-built PC / creators — two drives, SSD + HDD

If you carry photo RAWs, video footage, or a large game library, a two-drive setup of SSD (system) + HDD (data) is still the right call.

System = NVMe SSD 1 TB
Data = HDD 4 TB or more

Reviving an old HDD machine — SSD swap is the biggest win

A lot of “my PC feels slow” complaints trace back to the HDD. Adding RAM helps less than swapping the boot drive to SSD. It’s the realistic move when the budget can’t stretch to a new machine.

The standard tool kit is a SATA SSD plus a USB enclosure for migrating the data.

FAQ

Q. Is a hybrid SSD + HDD setup still worth doing? A. On a self-built PC or a desktop where you need a lot of capacity, yes. Splitting roles — SSD for system, HDD for data and backups — still makes sense. Laptops, on the other hand, often have only a single SSD slot, so a hybrid setup is hard to assemble.

Q. NVMe SSD or SATA SSD — which one? A. If the motherboard or laptop has an M.2 slot that supports NVMe, NVMe is the first pick. Sequential reads and writes are several times faster than SATA SSD. That said, for OS boot and office work the felt difference is small; it pays off on large file copies and video editing. If cost is the constraint, SATA SSD is still perfectly usable.

Q. How long does an SSD last? A. Manufacturer-quoted TBW (total bytes written) for a 1 TB-class drive lands around 300–600 TBW. At everyday workloads — even 50 GB written per day works out to 18 TB per year — that’s more than 10 years on paper. Most drives get retired for capacity or standards reasons before the write limit hits. The sudden-failure risk is lower than HDD, but not zero.

Q. How do I migrate from HDD to SSD? A. Two main routes. (1) Clone the whole disk, OS and all, with cloning software (often shipped by the SSD manufacturer). (2) Reinstall the OS clean and copy the data over via an external enclosure. Cloning is easier on paper, but you can trip over Windows licensing or drive letters. If you don’t mind reinstalling, route (2) ends up cleaner. Take a backup before either route.

Wrapping up

The 2026 baseline is “SSD for system, HDD for bulk data”. For laptops and general use, a single SSD is enough on its own.

The HDD’s role has clearly shrunk compared to five years ago. It’s narrowed to use cases where you need a lot of capacity cheaply — backups, video footage, photo RAWs.

If you want an old HDD machine to feel faster, an SSD swap comes before adding RAM. It’s worth considering before jumping straight to a full replacement.

Video connectors at a glance — HDMI when in doubt, DisplayPort for 4K high-refresh

Sat, 17 Apr 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The framework — how each connector is positioned — still holds, but the latest-generation specs (HDMI 2.1, DisplayPort 2.1, USB4) are worth checking against current official figures.

You buy a PC and a monitor, and the cable ends don’t match. HDMI, DisplayPort, USB-C, DVI, VGA — which one is the right one to plug in.

This piece lines up the five video connectors and how to pick between them by use case. By the time you finish, you should be able to narrow the cable you need down to one.

The short answer — HDMI when in doubt, DisplayPort for 4K high-refresh

Short answer: HDMI strikes the safest balance between adoption and performance. TVs, game consoles, and most monitors all have it, so one cable tends to connect almost anything.

The optimum shifts with use case:

4K / high refresh rate / multi-monitor: DisplayPort
Laptop, video and power over one cable: USB-C (DisplayPort Alt Mode)
Office use, just needs to display: whatever cable you have lying around (HDMI or DVI, either is fine)

Conversely, there’s almost no reason to pick DVI or VGA for a new purchase. Only consider them when keeping an older device alive.

In practice, the field narrows to five connectors

Short answer: the video connectors still in use around a PC come down to HDMI, DisplayPort, USB-C (Alt Mode), DVI, and VGA. Thunderbolt shares the physical USB-C connector, so it’s grouped under USB-C here.

How each connector sits

HDMI — most widespread across home electronics and PCs. The default when in doubt

DisplayPort — biased toward PC and graphics cards. Strong on high resolution and high refresh

USB-C Alt Mode — bundles video, power, and data into one cable on a laptop

DVI — the pioneer of digital video. Almost never worth buying new

VGA — analog. For keeping older gear alive

HDMI — the shared standard for TVs, consoles, and PCs

What HDMI is

A digital connector that carries video and audio over a single cable. Standardized in 2002, it’s been adopted across TVs, monitors, game consoles, and PCs — the single most widespread video connector today.

Short answer: adoption is broad and the compatible device pool is wide (home electronics, PCs, consoles), which makes HDMI the first pick when you don’t have a strong reason to pick anything else.

There are two reasons. First, audio runs over the same cable (up to 8 channels, Dolby / DTS supported). Unlike audio-only connectors such as S/PDIF, surround formats pass straight through. Second, home electronics (TVs, recorders, consoles) are designed around HDMI as the baseline.

Version differences come down to “how many Hz at 4K”

The maximum resolution and refresh rate change by HDMI version.

Ver	1.2	1.4	2.0a	2.1
Max resolution	FHD	4K	4K	10K
HDR	No	No	Yes	Yes
Max Hz at FHD	60 Hz	120 Hz	240 Hz	240 Hz
Max Hz at 4K	—	30 Hz	60 Hz	120 Hz+

At FHD, version doesn’t really matter. To push 4K at 60 Hz or higher, pick Ver. 2.0a or later; for gaming with 4K 120 Hz / 8K in mind, choose Ver. 2.1.

The cable itself — how to pick one — is covered in a separate piece.

→ Three things to check when picking an HDMI cable (length, connector, version)

DisplayPort — the standard for PCs, GPUs, and high-refresh use

What DisplayPort is

A video connector defined by VESA, the PC industry’s standards body. Found on graphics cards, some Macs, and gaming monitors. Tends to lead HDMI on high resolution and high refresh rates.

Short answer: if you’re targeting 4K-or-above resolution, 120 Hz / 240 Hz refresh, or driving multiple monitors over a single cable with MST (Multi-Stream Transport), DisplayPort is the pick.

The reason is that DisplayPort was designed from the start around PC displays. Where HDMI leans toward home electronics, DisplayPort prioritized high resolution, high frame rates, and bandwidth efficiency from day one. Generation for generation, DisplayPort often arrives first.

Version differences are gentler than HDMI’s

Ver	1.2	1.4	2.0
Max resolution	4K / 5K	8K	16K
HDR	No	Yes	Yes
Max Hz at FHD	240 Hz	240 Hz	240 Hz+
Max Hz at 4K	60 Hz	120 Hz	240 Hz+

Older versions still cover 4K 60 Hz, so version anxiety isn’t as sharp as with HDMI.

Watch out: turning a monitor off resets your window layout

DisplayPort has one quirk worth knowing about. When the monitor’s power is cut, the PC reads it as “the monitor has been disconnected”.

In a dual-monitor setup, windows and icons then collapse onto the primary screen. Powering the monitor back on doesn’t restore their positions.

Workarounds: let the monitor sleep instead of cutting power; use HDMI instead of DisplayPort; or hunt for a setting that disables DDC/CI. Worth knowing before you buy if it’s the kind of thing that’ll bother you.

USB-C (DisplayPort Alt Mode) — bundling a laptop into one cable

What USB-C Alt Mode is

A mechanism that uses some of the USB Type-C connector’s pins to carry a DisplayPort signal (DisplayPort Alternate Mode). Video, data, and power (USB Power Delivery) ride over a single cable. Thunderbolt uses the same physical shape.

Short answer: this fits people who want to handle a laptop with a single monitor. Video, peripherals, and power (up to around 100 W) all run over one cable.

The reason is the cable count. Plug one USB-C cable in when you’re back at the desk and external monitor, keyboard, mouse, and charging all come back at once.

Watch out: what the device supports decides what you get

USB-C is the name of the physical connector. Whether it can carry video depends on whether the device supports DisplayPort Alt Mode or Thunderbolt.

Whether the laptop’s USB-C port supports video output (check the spec sheet for “video output”, “DisplayPort Alt Mode”, or “Thunderbolt 3 / 4”)
Whether the cable supports video (a charge-only cable won’t carry a picture)
Whether the monitor has a USB-C input (if not, you’ll need a USB-C → HDMI / DisplayPort adapter)

If those three don’t line up, no picture. Reading spec sheets takes more work than with HDMI.

DVI — the pioneer of digital video; not worth buying new

What DVI is

A digital video connector introduced in 1999. It became widespread in the PC industry as the successor to VGA. Still found on some Windows desktops and business monitors, but rarely on laptops or TVs.

Short answer: DVI handles FHD (1920×1080) without issue. Treat it as a way to keep DVI gear you already own working — not as something to buy into.

The reason is that the connector is physically large, and on current-generation hardware it’s been replaced by HDMI / DisplayPort. 4K isn’t really supported either (DVI Dual-Link covers some cases), so as a new option it’s a leftover.

It still earns its keep when connecting a company desktop to a monitor, or pulling video from an older GPU. For a fresh setup, pick HDMI or DisplayPort and skip DVI.

VGA (D-Sub) — analog, for keeping older gear alive

What VGA (D-Sub 15-pin) is

An analog video connector standardized by IBM in 1987. It was the PC-to-monitor standard until the 2000s, but adoption fell as the industry went digital (DVI → HDMI / DisplayPort). Still seen on projectors and older conference-room equipment.

Short answer: because the signal is analog, resolution and image quality fall short of modern standards. Drop it from any new-purchase shortlist.

The reason is signal degradation — cable length and quality both eat into image quality. The practical resolution ceiling is FHD (the published numbers run higher, but blurring becomes visible).

Even so, conference-room projectors that are VGA-only are still around. If your laptop only has USB-C, keeping a single USB-C → VGA adapter in your bag covers you on business trips.

Comparison — five connectors by resolution, best use, and adoption

Connector	Max resolution (latest gen)	Best use	Adoption
HDMI	10K (Ver. 2.1)	TVs, consoles, general PCs	Highest
DisplayPort	16K (Ver. 2.0)	Gaming, high resolution, multi-monitor	Medium (PC-centric)
USB-C Alt Mode	4K–8K (device-dependent)	Laptop + one external monitor	Growing
DVI	FHD / some 4K	Reusing existing PC gear	Declining
VGA	FHD (in practice)	Older gear, older projectors	Declining

(Figures are the published maxes of each standard’s latest revision. Real-world performance depends on cable quality and device-side implementation.)

How to choose — three questions, in order

Short answer: walk through “do I also connect a TV or a console?” → “is this for gaming or 4K high-refresh?” → “do I want a laptop bundled into one cable?” in that order.

1. Also connecting a TV or console → HDMI

For home electronics, HDMI is essentially the only option. If you’re sharing with a PS5, Switch, Apple TV, or a recorder, going HDMI across the board lets you reuse cables.

2. Gaming, 4K 120 Hz, multi-monitor → DisplayPort

PC gamers targeting 144 Hz / 240 Hz, anyone wanting 4K 120 Hz for games, or anyone running three or more monitors off a single cable via MST — for any of these, DisplayPort.

3. Docking a laptop with a single cable → USB-C

If the goal is “plug one USB-C in after coming home and external monitor, keyboard, mouse, and charging all wake up”, that’s USB-C. A USB-C → HDMI / DisplayPort converter cable also covers monitors that don’t have USB-C input.

FAQ

Q. Is there an image-quality difference between HDMI and DisplayPort? A. Compared at the same version generation, same resolution, and same refresh rate, there’s no visible difference. The gap shows up only where one supports a higher maximum resolution or refresh rate. In day-to-day FHD / 4K 60 Hz use, they’re effectively tied.

Q. I tried to send video over USB-C and got nothing. What do I check? A. Three things. (1) The laptop spec sheet should say “video output supported”, “DisplayPort Alt Mode”, or “Thunderbolt”. (2) The cable should be video-capable, not charge-only (look for the USB-C logo and the bandwidth label). (3) The monitor should accept USB-C input, or you should be running it through a USB-C → HDMI / DisplayPort adapter.

Q. If I convert a DVI cable to HDMI, can I drive 4K? A. Generally no. DVI Single-Link tops out around FHD 60 Hz and doesn’t reach the bandwidth 4K needs. For 4K, use a native HDMI or DisplayPort port on both the PC and monitor sides.

Q. For gaming, I’m stuck between HDMI 2.1 and DisplayPort 1.4. Which one? A. If both your GPU and monitor support HDMI 2.1, you can line up 4K 120 Hz and variable refresh rate (VRR) cleanly. For an older monitor / GPU combo, DisplayPort 1.4 opens up more options. Check the ports on your GPU and monitor first — that makes the call a lot easier.

Wrapping up

Picking between the five video connectors comes down to use case.

When in doubt, HDMI. It’s compatible with the whole home-electronics stack, including TVs and consoles, so one cable tends to cover most of the setup.

For serious PC gaming or 4K high refresh, DisplayPort. For docking a laptop with a single cable, USB-C Alt Mode.

Treat DVI and VGA as options only for keeping existing gear running. There’s almost no scenario where they’re a positive new-purchase pick.

How to pick the cable itself — length, connector shape, version — is covered for HDMI in a separate piece.

→ Three things to check when picking an HDMI cable (length, connector, version)

Peak Design Capture V3 and ProPad review — the clip that locks a DSLR onto your hip belt

Fri, 16 Apr 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The Peak Design Capture is still in the current line-up in 2026, with successive minor revisions of the V3 generation on sale. The review angles here — comfort on a hip belt, lock robustness, the metallic click from plate tolerance — still apply.

Take a DSLR out for the day and every shot has the same tax: dig the camera out of the bag, miss the moment, repeat. Lay it flat inside the pack and by the time it is out, whatever you wanted to shoot has already moved on.

To deal with this at the physical layer, I bought the Peak Design Capture V3 (CC-BK-3) and ProPad (PP-2) and have lived with them for a few years. The flow becomes: clip the camera directly onto a hip belt or backpack shoulder strap, lift it off one-handed, raise it to the eye.

The verdict — worth the money if you raise a DSLR often

Short answer: if you want out of strap-based carry, buy it. The lock is solid, the camera does not come loose while running, and after several years the button has never broken.

The reason is that the number of actions before the camera is at your eye drops sharply. Three actions — put the bag down, open the zip, lift the camera out — collapse to one: press the button and lift. With moving subjects that will not wait — kids, animals at a zoo, sports day — that difference is the gap between getting the shot and not.

A few cautions before buying:

Hands-free types who only shoot occasionally: a strap for a few thousand yen is enough
Full-frame + f/2.8 trinity users: hanging that much weight off the hip swings while you walk. Routing the load through the shoulder is more realistic
People shooting in environments that need to be quiet: tolerance between the plate and the clamp can produce a metallic click (more below)

Look and feel

Short answer: machined aluminium, single matte black, edges rounded but the surface feels hard. The build quality sits above most camera accessories.

The front is plain. A lock-release button sits in the centre, with hex-socket clamp screws to either side.

Spec	Capture V3
Size	about 13 × 13 × 3 cm
Weight	about 144g (rated)
Material	machined aluminium
Strap thickness	up to ~6.4mm (rated)

The back is flat. This is the face that meets the belt, and it is designed to have nothing catching. On a hip belt the surface ends up close to your skin and hip bone, so the cushion (ProPad) earns its place.

From the side the depth is shallow. On a hip belt it is small enough that the hem of a jacket can cover it.

The underside is the female slot for the plate. The trapezoidal quick-release plate on the camera slides into here from above.

ProPad PP-2

The cushion that sits between the Capture and a hip belt to spread the load.

Spec	ProPad PP-2
Size	about 17 × 9 × 3 cm
Weight	about 36g (rated)
Material	cushion + hook-and-loop

The cushion is not overly thick, and once the belt is tightened it sits flush against the hip. Even when I worked up a sweat the hook-and-loop did not loosen.

What worked

Short answer: the motion to bring the camera to your eye is at its shortest / the lock is genuinely robust / nothing has broken over several years.

One-handed, one-action to ready

The biggest single win. Hold the lock-release button while you pull the camera up — done.

Unlike pulling it out of a bag, by the time it is up it is already in shooting position. With kids or animals that move unpredictably, the two or three seconds saved decide whether the shot exists. The effect has been largest for travel, sports day, the zoo, and hiking.

The lock does not open unless you mean it

If it is one-handed in one motion, the obvious worry is “will it pop open while I am walking?” Over several years of use, that has never happened.

The lock geometry will not allow vertical removal without the button being pressed. Run, jump — as long as nothing touches the button, the camera stays put. Press it intentionally and it slides out cleanly. The on/off distinction is unambiguous, with no nagging worry about accidental release.

The button is built into the body, so it cannot be lost

A generic camera clip I had used before put the lock-release button on a removable cap. Within six months it had gone missing and the clip was unusable.

On the Peak Design side the button is fully integrated into the body — you cannot pop it off even if you try. Serviceability suffers in exchange, but the field-loss risk drops to zero, and in real use that matters.

Arca-Swiss plates work too

The standard Peak Design plate has an Arca-Swiss-compatible cross section, so if your tripod head already takes Arca-Swiss clamps, the same plate goes straight onto the tripod with no swapping.

Third-party Arca-Swiss plates have also worked in the slot. If you are buying a new kit it is safest to stay all Peak Design, but if you have already standardised your tripod side on Arca, the cost of moving over is low.

What didn’t

Short answer: third-party plates can rattle metallically / heavy rigs swing on a hip belt / the standard plate slides on its own bottom face.

Tolerance against third-party plates causes a metallic rattle

The plate slot is built with some clearance, presumably so that it will accept a range of compatible plates.

With the genuine Peak Design plate there is almost no play, but a third-party Arca-Swiss plate can produce a light metallic click-clack, more obvious the faster you walk. For environments where silence matters — bird photography, say — the realistic options are to standardise on Peak Design plates, or to take up the slack with a thin strip of PTFE tape.

Heavy lenses swing on a hip belt

Mount a full-frame body with a 70–200mm f/2.8-class lens on the hip and it bounces up and down with every step. This is not really a problem with Capture; it is the physical limit of hanging that much weight off a hip belt at all.

In practice, for rigs that heavy, move the Capture onto a backpack shoulder strap, or pair it with a regular strap to share the load. Hip-belt use stays comfortable up to about mirrorless plus a prime or a standard zoom.

The standard plate slides on a tripod head

The base of the standard plate is flat, with no cork or rubber anti-slip layer (may vary by unit).

If you set the camera down on its bottom directly, or onto a slick tripod head, there is a slight slip. Clamped down it is fine, but a casual drop onto a desk can start sliding, so worth knowing.

How to mount and use it

Short answer: open the clamp, thread the belt, tighten — 30 seconds. The plate stays on the tripod thread once you put it on and basically never comes off.

First, loosen the two clamp screws with a hex key. You can work from either side. With the screws loose, the upper half rotates open and clears a path for the belt.

For hip-belt use, open the ProPad and sandwich the Capture in along the printed guide on the inside. Thread the whole sandwich onto the belt.

Close the ProPad, swing the Capture’s upper half back into place, and retighten the screws. Done — 30 seconds once you know the moves.

Fitting the camera plate

On the camera side, screw the quick-release plate into the tripod thread with the 1/4-inch screw. Once it is on, it basically stays on.

Seen from the side, the base is trapezoidal (Arca-Swiss compatible). That dovetail slides into the matching female profile inside the Capture.

Press the black cylindrical button on the side of the Capture, then drop the plate in from above.

Push it all the way down, release the button, and the lock engages. Removing it uses the same button in reverse.

A GoPro will also fit, given an adapter mount with a 1/4-inch thread. In practice, though, the main use case is mirrorless or DSLR carry on a hip belt, not action cams.

Compared with camera belts and sling harnesses

Short answer: Capture locks the camera flush to your body, a harness slings it off your shoulder for a fast lift, a neck strap just hangs it from your neck — they are answers to different questions.

Angle	Peak Design Capture V3	Sling harness (general)	Neck strap (general)
Mount position	Hip belt or shoulder strap	Shoulder / under arm	Neck
Bring-up motion	Press button, lift out	Lift the dangling camera	Lift the dangling camera
Hands fully free?	Yes — locked in place	No — still swings	No — still swings
Stability while running or jumping	High (no swing)	Medium (strap rebound)	Low (camera flails)
Heavy lenses	Swings on a hip belt	Good — shoulder absorbs it	Average
Noise	Possible plate-tolerance click	Quiet	Quiet
Price band (at the time of writing)	~18,000–20,000 yen	~5,000–15,000 yen	~2,000–5,000 yen

“I want the absolute shortest path to my eye” and “I want both hands genuinely free” both point at Capture. “I want to walk with the camera hanging off me all day” leans toward a harness, which is less tiring over long stretches.

For an adjacent piece in the same camera-accessory category, I also wrote up the JOBY GorillaPod JB01542-PKK, which is a small flexible tripod for wrapping around a pillar or shelf. That sits on the desk-or-pillar layer rather than the body-mounted layer, so it is a separate choice from Capture.

FAQ

Q. What cameras and packs does it fit? A. The clamp is rated for straps and belts up to about 6.4mm thick. That covers the shoulder straps on most camera backpacks and hip belts up to roughly 5cm wide. On the camera side, anything with a 1/4-inch tripod thread will work — mirrorless, DSLR, or compact. Heavy rigs (a full-frame body with a telephoto, for example) put real load on the shoulder or hip, so pairing with a shoulder strap is the practical call.

Q. Is it better than a harness or a sling strap? A. They solve different problems. A harness or sling strap is for “hang it off the shoulder and bring it up fast”; the camera always dangles from your body. Capture is for “lock it flush to your body” and is strong when you want both hands fully free — hiking, shooting with kids. The way the weight is routed is also different: a harness rides on the shoulder, Capture distributes load through the hip (via the ProPad). People who shoot a lot on a tripod, or who swap lenses often, frequently end up using both.

Q. Do I actually need the ProPad? A. For hip-belt use, effectively yes. With Capture alone, the back of the clamp digs straight into the belt, and after a long walk it presses on the hip bone and hurts. ProPad sandwiches the belt in cushioning so the load spreads out around the waist. For backpack-shoulder use the cushion is not needed and Capture on its own is enough. The rule of thumb is “ProPad for hip, Capture alone for shoulder.”

Q. Does it hold up over years of use? A. After several years of daily use, the lock mechanism has never failed. The clamp screws, the lock button, the aluminium body — none of them show meaningful wear. By way of comparison, a generic clip from another brand I had used before had a removable lock button, and within six months the button was lost or broken. On the Peak Design side the button is built into the body and cannot be removed, so the loss risk is structurally zero.

Verdict — if you raise a DSLR often, the day-to-day changes

It is the kind of accessory that picks its users, but for the right use case it is hard to go back to strap-only carry.

It is an easy recommendation for kids, travel, the zoo, hiking — anywhere you want both hands free with a DSLR ready to come up in one motion. Conversely, if the camera only comes out a few times a month, a neck strap for a few thousand yen will do the job.

The two cautions are the metallic click from plate tolerance and hip-belt swing with heavy lenses. The first is fixed by standardising on Peak Design plates; the second by moving over to a shoulder-strap mount.

Vue.js basics — v-if and v-for

Thu, 15 Apr 2021 00:00:00 GMT

2026 update: this post was first written for Vue 2 / Options API. In 2026, Vue 3 with the Composition API (<script setup>) is the default, but the template syntax for v-if / v-else / v-for hasn’t changed, so the shape of the examples below still maps over.

A short reference for the Vue.js directives that handle conditional rendering and iteration.

The mustache syntax and v-bind are covered in a separate post.

The short answer

v-if: renders the element only when the condition is truthy. Pairs with v-else / v-else-if
v-show: toggles visibility through CSS display. Suited to elements that flip on and off often
v-for: iterates over an array. Always pass :key

v-if

v-if renders an element only when the expression is truthy.

It’s common in real work — UI that needs to differ between mobile and desktop, or between logged-in and logged-out states, is the typical case.

Basic usage

v-if is written as an attribute on the target element, with the condition as its value.

The snippet below decides inside the template whether the block renders.

In practice this displays This is a sample.

<template>
  <div v-if="sampleNum === 1">
    サンプルです。
  </div>
</template>

<script>
export default {
  data() {
    return {
      sampleNum: 1
    };
  },
};
</script>

v-else

v-if accepts an else branch in the same way a regular if statement does.

Just add v-else as an attribute on the next element.

This snippet displays else is shown.

<template>
  <div>
    <div v-if="sampleNum === 0">
      サンプルです。
    </div>
    <div v-else>
      elseが表示です。
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      sampleNum: 1
    };
  },
};
</script>

One gotcha: v-else has to sit on the element directly after the v-if. Anything in between breaks the pairing.

v-else-if

else-if works alongside else.

The form is the same — add v-else-if as the attribute.

This snippet displays sampleNum is 1.

<template>
  <div>
    <div v-if="sampleNum === 0">
      サンプルです。
    </div>
    <div v-else-if="sampleNum === 1">
      sampleNumは1です。
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      sampleNum: 1
    };
  },
};
</script>

v-show

v-show looks similar to v-if from the outside, but the mechanics are different.

The syntax matches v-if — write v-show="..." as an attribute.

The difference between v-if and v-show is whether the DOM node is added and removed, or just hidden with display.

v-if creates the element when the condition turns truthy and removes it from the DOM when the condition turns falsy. v-show keeps the element in the DOM from the start and only toggles display: none. As a result, the toggle cost is lower with v-show, while the initial-render cost is lower with v-if.

A rough rule of thumb:

Element that’s likely falsy at first paint and rarely shown after — v-if
Toggle UI that flips on and off frequently — v-show

Note that v-show leans on the display property, so it doesn’t compose with <template> elements or with v-else. In those cases, use v-if.

v-for

v-for iterates over an array or object and renders the template once per entry.

It maps closely to a JavaScript for loop — Vue lays out the same template for each item in the list.

The form is v-for="(item, index) in list". Pass a unique value to :key so Vue can diff the list correctly.

This snippet displays num is 1, index is 0. num is 2, index is 1.

<template>
  <div>
    <div v-for="(num, i) in numList" :key="i">
      中身は{{ num }}, indexは{{ i }}。
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      numList: [1, 2]
    };
  },
};
</script>

Wrapping up

v-if creates or removes the element based on the condition; v-show keeps the element and hides it with CSS. v-for needs :key to iterate cleanly. The template syntax carries over to Vue 3 unchanged, so this same shape works once you move to the Composition API.

Related posts:

Getting started with Vue.js — v-bind basics, explained

Wed, 14 Apr 2021 00:00:00 GMT

2026-05-16 update: An older post. The bones still hold up, but the tool UI and versions are from the original writing — newer releases may differ.

A short intro to Vue.js’s own HTML notation, written for people picking up Vue for the first time.

The takeaway

The mustache tag ({{ }}) outputs script-side variables into HTML
v-bind is a directive that binds attributes to dynamic expressions
: is the shorthand prefix for v-bind:
Array notation lets you apply multiple classes or styles at once

Mustache tag

The mustache tag is for surfacing variables or function results — defined in script — inside the HTML.

You use it by writing {{ }} somewhere in the template.

The code below defines displayText in script and prints it from HTML.

When you run it, the output reads 文字列です。.

<template>
  {{ displayText }}
</template>

<script>
export default {
  data() {
    return {
      displayText: '文字列です。'
    };
  },
};
</script>

That’s the simplest possible form.

The example uses a string variable, but the same syntax accepts an object.

<template>
  {{ displayObj }}
</template>

<script>
export default {
  data() {
    return {
      displayObj: {
        text: '文字列です。'
      }
    };
  },
};
</script>

Worth noting: running this prints { text: '文字列です。' } literally.

To render 文字列です。 on its own, write displayObj.text.

v-bind

v-bind is the main thing this post is about.

v-bind lets you bind attributes to dynamic logic with almost no ceremony.

Toggling class dynamically opens up a lot of expressive room on the page, so this is where it gets used most.

Basic v-bind usage

The code below applies the activeClass class based on the boolean isActive.

When you run it, 文字列です。 appears in white text.

<template>
  <div v-bind:class="{ activeClass: isActive }">
    サンプルです。
  </div>
</template>

<script>
export default {
  data() {
    return {
      isActive: true
    };
  },
};
</script>

<style lang="css">
  .activeClass {
    color: #fff;
  }
</style>

isActive is defined in script, and the HTML’s v-bind:class evaluates it.

Here isActive is true, so the class applies. Flip it to false and the text renders in black.

v-bind shorthand

v-bind has a shorthand.

Prefix the attribute with : and v-bind kicks in.

The code below applies the activeClass class based on the boolean isActive.

When you run it, 文字列です。 appears in black text.

The reason it’s black: the expression uses ! to negate the value.

<template>
  <div :class="{ activeClass: !isActive }">
    サンプルです。
  </div>
</template>

<script>
export default {
  data() {
    return {
      isActive: true
    };
  },
};
</script>

<style lang="css">
  .activeClass {
    color: #fff;
  }
</style>

Multiple v-bind

To bind more than one class condition on a single attribute, wrap the expressions in an array.

The code below applies both activeClass and sampleClass.

When you run it, 文字列です。 appears in white text.

<template>
  <div :class="[{ activeClass: isActive }, { sampleClass: sampleNum === 1 }]">
    サンプルです。
  </div>
</template>

<script>
export default {
  data() {
    return {
      isActive: true,
      sampleNum: 1
    };
  },
};
</script>

<style lang="css">
  .activeClass {
    color: #fff;
  }

  .sampleClass {
    width: 100%;
  }
</style>

Each entry is a normal JS expression, so comparison operators are fair game.

v-bind works on essentially any attribute. The ones it ends up on most often are class, style, and src.

Closing

That’s the mustache tag and v-bind in Vue.js — the foundation everything else builds on.

Worth getting comfortable with before moving on.

Related:

Sennheiser HD 598 SR review — open-back spaciousness and a fit that lasts for hours

Tue, 13 Apr 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The HD 598 SR is an Amazon-exclusive black variant, and as of 2026 new-stock circulation has all but ended. On the open-back side, the HD 599 and HD 560S remain in the current lineup as natural successors. The review angles here — open-back soundstage, fit, and how it compares against closed-backs — should still be useful, so I kept the bones and only cleaned up the wording and structure.

I have used the Sennheiser HD 598 SR open-back headphones for a long stretch of work and personal listening, and this is the write-up.

For anyone who has not owned an open-back before, the first wall is the same: “sound leaks out, outside sound leaks in.” Whether you can live with that splits the verdict cleanly in two. If you can — at home, in your own room, doing remote work — the HD 598 SR is a more honest way to enjoy music than most closed-backs at the same price.

The verdict — still a working pick for a fixed home setup

Short answer: the strengths are the open-back spaciousness and the lightness over long sessions. The price for that is zero isolation and audible leakage, so it does not belong outside or in a shared room.

Three reasons.

Wide soundstage: as an open-back, the “inside-the-skull” feeling is muted. It pays off for film, streaming, and live recordings
Light fit: the clamp is moderate, and the over-ear cups fully surround the ear, so multi-hour use does not tire you out
Removable ear pads: cleaning and replacement are easy, which suits long-term ownership

On the other hand, look elsewhere if any of these apply:

You also want to use them outside or on a commute: open-backs leak heavily in both directions and are unusable in public spaces
You share a room and listen late at night: someone seated next to you will faintly hear what you are playing
You need wireless: the HD 598 SR is wired only, with no Bluetooth support

Build and accessories

Short answer: the all-black finish reads as calm and restrained. As an Amazon-exclusive color, it is the one to pick if the cream of the standard HD 598 is not your taste.

The HD 598 SR is the Amazon-exclusive variant of the HD 598, with the cream finish swapped for black. For most home and remote-work setups, the SR is the easier color to live with.

The housings are vertically elongated ovals. If you are used to round earcups it looks unusual at first, but the shape follows the outline of the ear and settles in cleanly once worn.

The cable is detachable and exits from the bottom of the right cup. Being able to swap only the cable when it eventually breaks is a real plus for long-term ownership.

The bundled accessories are as follows.

In the box

3 m cable with a 6.3 mm stereo plug (for desktop amps and audio interfaces)

1.2 m cable with a 3.5 mm straight plug (for PCs and phones)

6.3 mm to 3.5 mm adapter

The inside of the headband is cushioned. The L / R marks live on the inside as well, so you can tell the sides apart by feel in a dark room.

The length adjustment is nearly continuous in feel, so larger heads fit without issue (the photo shows the headband at full extension).

What worked

Short answer: the soundstage, the long-session comfort, and the ease of maintenance — those three carry the headphone.

Open-back soundstage and an honest balance

As an open-back design, the HD 598 SR avoids the “stuffy, inside-the-skull” feeling closed-backs tend to have. There is a sense of air, closer to listening through speakers.

Low end on an open-back will always sit below an equivalent closed-back by construction, but the HD 598 SR puts out what the music needs. Bass and kick do not vanish, and no genre falls apart.

If your daily listening is EDM or hip-hop where the low end has to push the song, this is not the right fit. For most other listening — vocals, acoustic music, film, games — it stays enjoyable without forcing anything.

Over-ear comfort that holds up over long sessions

The combination of fully over-ear cups, an open-back chamber, and a moderate clamp means very little listening fatigue.

Unlike in-ears or closed-backs, heat does not build up around or inside the ear, so it stays comfortable even in summer. Half a day of wearing them during remote work is genuinely low stress.

Tool-less, removable ear pads

To remove a pad, orient the logo downward and pull it straight off (it comes free with a soft click). Cleaning and replacement are easy, and that pays back the longer you own the headphone.

After a few years of use, swapping only the pads extends the life of the rest of the headphone. Sennheiser has supplied replacement pads for the HD 598 family for a long time.

What didn’t

Short answer: zero isolation, wired-only operation, and the practical difficulty of buying one new today.

Zero isolation — not for outside, not for late nights

By construction, leakage in and out happens essentially without filtering.

People next to you can faintly hear what you are playing
Voices and household sounds come straight in
Noise cancellation is, of course, not on the table

This is a design characteristic rather than a flaw — but it is the line item that decides whether the headphone is “wrong tool for the job.” For listening alone in your own room at home, it is not an issue. For an office, a cafe, or a bedroom that shares a wall with family, this is not the headphone to choose.

Wired only, no Bluetooth

By 2026 the default is wireless. The HD 598 SR is wired only, designed to plug straight into a PC, a desktop amp, or a phone.

Phones no longer carry a 3.5 mm jack in most cases, so a USB-C or Lightning DAC dongle is an extra step in the chain.

Price band and current availability

At the time of writing, the street price was around 20,000 yen. That is not entry-level.

On top of that, as of 2026 new-stock circulation has effectively ended, which makes “buy new” hard to recommend. Looking at the successor open-backs — the HD 599 and the HD 560S — is the more realistic move.

Comparison: open-back HD 598 SR vs same-price closed-back / wireless

Short answer: the HD 598 SR wins on “at home, fixed setup, wired, soundstage-first.” Outside that, a different category is more comfortable.

Angle	HD 598 SR (open-back, wired)	Same-price closed-back	Same-price wireless (with ANC)
Soundstage	Wide	Narrower	Depends on model (typically narrower)
Bass quantity	Enough for the music	Stronger	Strong (DSP-assisted)
Isolation	None (open-back)	High	High (with ANC)
Sound leakage	Large	Small	Small
Long-session fatigue	Low	Heat builds up	Battery weight adds up
Cable	Wired only	Mostly wired	Mostly wireless
Outdoor / commute use	No	Yes	Best fit
Home remote work	Best fit	Yes	Yes (needs charging)

The HD 598 SR’s winning lane is narrow: at home, in your own room, wired is fine, soundstage matters. For anyone who lands in that lane, the listening experience is clearly better than a same-price closed-back or a budget wireless.

If there is any chance you will want to use them outside or on a commute, buying a closed-back or a wireless ANC pair from the start tends to have fewer regrets.

FAQ

Q. Can I plug them straight into a phone? A. If the phone still has a 3.5 mm jack, the 1.2 m cable plugs in directly. Most current phones have dropped the jack, so a USB-C or Lightning DAC dongle is needed separately. By impedance, the HD 598 SR is generally easy enough to drive from a phone.

Q. How does it differ from a closed-back? A. The biggest gaps are soundstage and isolation. An open-back like the HD 598 SR has speaker-like air around the sound, without the boxed-in feeling. The trade is heavy leakage in both directions. A closed-back does the opposite — strong isolation and strong low end, at the cost of heat and pressure around the ear over long sessions. Open-back for listening alone in your own room, closed-back for outside or shared rooms — that is the simple split.

Q. How does it compare to wireless headphones? A. Setting tuning aside, the operational gap is the big one. Wireless asks you to manage charging, pairing, and latency, in exchange for the freedom of no cable. The HD 598 SR has no charging, no latency, and a stable connection by virtue of being wired, but the cable is always there. For a desk-bound remote-work setup, wired is often the easier choice.

Q. Are they comfortable over long sessions? A. The combination of an over-ear cup, an open-back chamber, and a light clamp puts fatigue on the low end of the same-price range, in my experience. Unlike in-ears that push into the canal, these only surround the ear, so the pressure is mild. Comfort still varies by head shape, so trying a pair for ten or fifteen minutes in a store before committing is the safe move.

Verdict — for someone happy to keep them at home

The HD 598 SR is a still-useful open-back if you are clear about the use case.

It suits home listening — remote work, music, film, games in your own room — where the wide soundstage, the long-session comfort, and the easy maintenance all show up in daily use.

It does not suit using them outside, sharing time with family in the same room, or operating wireless-first. For those uses, the design loses by construction.

If you are buying new in 2026, new stock has thinned out, so it is worth looking at the successor lineup (HD 599 / HD 560S) at the same time. On the secondhand or clearance market, the HD 598 SR is “the black HD 598” — the sound is the same as the standard version, so picking on color preference is fine.

Elecom EX-G Bluetooth M-XGL10BBBK review — the budget mouse where grip differences show up most

Mon, 12 Apr 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The M-XGL10BBBK is still in circulation as a current budget Bluetooth mouse in 2026. The review angles here (size options, grip comfort, wireless stability) still apply. Spec values quoted are the manufacturer’s figures from the time of writing, so check the latest product page before buying.

I used the Elecom EX-G Bluetooth M-XGL10BBBK at work for about a year. This is a review combining what it felt like then with a 2026 re-read of the same points.

In the “I don’t want to spend much on a mouse, but I do want to graduate from the one that came in the box” price band, this is the model where the grip difference is most obvious. Being able to pick S, M, or L is also rare at this price.

The verdict — the best “first step up” if you want size options

Short answer: if you’re moving up from a bundled cheap mouse, this is the one in its price band where the difference in grip is most clearly felt. The S/M/L sizing makes it easy to recommend to people with smaller hands too.

The reason is that the ergonomic shape and the side buttons are both there — you can feel the design intent in your fingers the moment you pick it up. Coming from a generic bundled mouse, the way your hand stiffens during long sessions visibly improves.

That said, look elsewhere if any of the following apply:

You prioritize wireless stability: it is Bluetooth-only, so it will not be as steady as a USB-receiver model
You want fine button customization: the bundled software is more modest than the Logicool Options family
Gaming use: response speed and sensor performance are tuned for office work

Build — a mid-height ergonomic shape

Short answer: a shape that sits between flat mice and tall sculpted mice. An asymmetric design that drops away on the right-click side, made to be palmed rather than clawed.

The shape from above. Photographed in L size. You pick S, M, or L to match your hand.

The underside holds the power switch, pairing button, and battery cover. It runs on a single AA cell, and the manufacturer’s rated battery life is about 402 days (check the latest spec before buying).

Seen from the front, the right-click side drops away noticeably. Not flat, not fully sculpted — a mid-height ergonomic shape.

From the back. The hump is modest — it sits in your whole palm. If you only ever claw-grip, the MX Master family will suit you better.

The right flank is wrapped in rubber, and the ring and little fingers stop there without sliding. Even with sweaty hands during long sessions, it does not slip.

The left flank has a thumb rest and two side buttons. The thumb area is shaped with a gentle convex curve that matches the natural shape of the thumb, so the thumb settles there without thinking about it.

What worked — grip and side buttons that punch above the price

Short answer: a deliberate grip, side buttons, S/M/L sizing, and a light weight. The basics of a budget mouse, all present.

A grip designed to be held

The defining trait of this mouse is that it pushes its budget into the way it feels in the hand.

Moving over from a bundled mouse or a thousand-yen plain one, the difference is obvious the moment you pick it up. The rubber on the right flank, the convex thumb rest, the drop on the right-click side — none of them look dramatic on their own, but together they change how your hand feels at the end of a long day.

Side buttons make “back” a one-finger action

Side buttons connect directly to workflow.

The main use is browser back/forward. Web browsing, file managers, IDEs — all of them rely on it constantly, so having the buttons or not having them is a real gap. That alone is enough reason to leave a bundled mouse behind.

S / M / L sizing

Rare in this price band: three sizes to pick from.

L suits adult-male-sized hands, S works for children and smaller hands, M sits in between. A mouse that does not fit your hand will tire you out no matter how much it cost, so size choices at this price are quietly useful.

About 87 g without the battery

The rated weight is about 87 g without the battery.

A mouse over 100 g changes how tired your arm gets across a full day, so for office work, light is right. Even with a AA inserted it lands on the lighter side by feel.

What didn’t — the Bluetooth-only trade-off

Short answer: connection is Bluetooth-only, so the wireless link is less stable than a USB-receiver model. The lag right after waking from sleep is the most common case.

Pickup delay when resuming from sleep

The biggest complaint.

For the first few seconds after the PC wakes, the mouse sometimes does not respond. That is a Bluetooth-general behavior rather than a specific defect of this mouse, but coming from a USB-receiver model you will notice it.

If you sleep and resume often (a laptop-and-dock setup, for example), it is safer to also consider models that ship with a USB receiver, such as the Logicool Unifying-compatible ones.

Modest button-remapping software

It cannot do the fine-grained gestures the Logicool Options family allows. If you want to map the side buttons to anything beyond simple back/forward, you will end up leaning on a third-party Windows utility.

That said, the basics (DPI, button presses) work reliably, so for office use without elaborate remapping, there is no real inconvenience.

Comparison — where it sits against the same and higher tiers

Short answer: at the budget end, it stands out on grip. Compared to higher-tier mice like the Logicool MX line, the side wheel and customization are where the gap shows up.

Angle	M-XGL10BBBK	Logicool mid-range (e.g. M650)	Sub-1,500-yen budget mice
Price	Around 2,000 yen	Around 4,000–6,000 yen	Around 1,000 yen
Connection	Bluetooth only	Bluetooth + USB receiver	Bluetooth or wired
Sizes	S / M / L	M / L (model-dependent)	Usually none
Grip	Ergonomic shape, rubber grip	Ergonomic-leaning, smoother	Mostly flat
Side buttons	2 buttons	2 buttons + custom	None to 2
Side wheel	No	Yes on some models	No
Battery	1 × AA (about 402 days rated)	1 × AA or rechargeable	AA or USB-powered
Remapping software	Yes (modest)	Logi Options+ (full-featured)	Mostly none

Put briefly: pick the M-XGL10BBBK for the “one step up from a cheap mouse” use case, and the Logicool MX line when you want another step up that includes Excel horizontal scrolling. For the comparison with higher-tier MX Master mice, see the Logitech MX MASTER 2S review.

FAQ

Q. Does it work with phones and tablets, not just PCs? A. It connects over Bluetooth, so any OS with Bluetooth-mouse support will work — Windows, macOS, iPadOS 13.4 and later, parts of Android. Without a USB receiver, compatibility depends on the host OS’s Bluetooth support.

Q. How far can the bundled software remap buttons? A. Elecom provides “Elecom Mouse Assistant,” which remaps the side buttons and similar (Windows only — check the latest supported OS list). It is not as fine-grained as the Logicool Options family — things like “different actions per gesture direction” are not on offer. For simple back/forward/copy/paste-level remapping, it is enough.

Q. Is it less tiring for smaller hands? A. Pick the S size and it is less tiring. The L size, for smaller hands, actually makes the fingers stretch and tires the hand faster, so size choice matters. If you can, holding one in a store is the surest way to avoid regret.

Q. Can it be used for gaming? A. Response speed and sensor performance are tuned for office work, so it is not a good fit for FPS or anything that needs precise input. For browser games or low-intensity MMOs, it is fine.

Verdict — a fitting upgrade for your first “real” mouse

On the price-to-grip ratio, this is one of the standouts in the budget band.

Especially for “I want to move on from a bundled mouse or a flat thousand-yen one” and “I want to try a mouse that fits my hand size without spending much,” this is a safe first pick.

The two things to keep in mind are the Bluetooth-only stability and the modest software. If you live in Excel horizontal scrolling or lean on custom gestures, you’ll be happier in the long run with the Logicool MX line.

How to pick an iPad for illustration — iPad Pro if you draw seriously, iPad Air as the realistic entry point

Sun, 11 Apr 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The bones (what to look at when choosing a model) still hold, but the specs, prices, and generation names are anchored to when this was written. Heavy rewrite in progress — verify against the current line-up before publishing.

The first thing that trips people up when buying a tablet to draw on is: which one — the plain iPad, the iPad Air, or the iPad Pro? The price spans more than 2x, the screen sizes differ, and the Apple Pencil generations differ too.

This piece narrows the decision to iPads used for drawing. By the end you should have a clear shape of the one model that fits you, plus the accessories that go with it.

The short answer — 12.9-inch iPad Pro for serious drawing, iPad Air for entry

Short answer: if you want to draw long sessions as a display-tablet replacement, the 12.9-inch iPad Pro. If you are starting out as a hobby, the iPad Air is the realistic pick. The plain iPad is cheap, but some generations only support the 1st-gen Apple Pencil, which is a notch behind for illustration use.

Whatever model you land on, the same three checks decide it:

Screen size: aim for 11 inches or larger. Anything around 10 inches gets cramped for full strokes
Apple Pencil generation: pick a model that supports the 2nd gen (magnetic charging, double-tap)
Storage: 256 GB or more. A single psd / clip file can hit several hundred MB

Put differently: if those three boxes are ticked, the price tier matters less than you think.

Picking the model — understand where each one sits

Short answer: the plain iPad is “a cheap tablet,” the iPad Air is “light and able to draw,” and the iPad Pro is “a display-tablet replacement.” Pick by use case, not by price.

The reason is that the iPad line splits hard on CPU, screen quality, and Apple Pencil support — even though all three share the iPad name. For drawing in particular, screen size and Pencil support drive the experience.

Plain iPad — fine for entry, light for serious long sessions

The plain iPad is the cheapest line. For ebooks and video, with the occasional doodle on top, it is plenty.

That said, some generations only support the 1st-gen Apple Pencil, which charges over Lightning by plugging into the bottom of the tablet — clumsy in daily use. If you are buying a dedicated drawing machine, step up to the Air or higher.

iPad Air — the realistic entry point for drawing

The iPad Air is “the entry to iPads that can draw.” It supports the 2nd-gen Apple Pencil, and the roughly 10.9-inch screen lands in the usable range.

It is 20,000–30,000 yen more than the plain iPad, but with the Pencil the experience gap is wide. Hobby use through semi-pro work is covered here.

iPad Pro — for long sessions as a display-tablet replacement

The iPad Pro is the line for people drawing long sessions as a display-tablet replacement. It supports 120 Hz (ProMotion), and the stroke tracking is noticeably different from the other models.

It comes in 11-inch and 12.9-inch. If you draw seriously, go 12.9. The price ends up more than 2x the plain iPad, but the extra canvas — “draw without switching views” — translates directly into output.

Pick a model that supports the 2nd-gen Apple Pencil

Short answer: for illustration, 2nd-gen Apple Pencil support is close to a hard requirement. Skip 1st-gen-only models.

The reason is that the 2nd gen charges magnetically on the side, switches tools on a double-tap, and has lower latency — the feel is a step up. The 1st gen plugs into the Lightning port on the bottom of the tablet to charge, which is awkward to live with.

What to verify:

The model is explicitly listed as “Apple Pencil (2nd generation) compatible”
The iPad has a magnetic charging strip on the side (you can see it in product photos)

Storage from 256 GB, Wi-Fi only is enough

Short answer: for illustration, 256 GB or more. Wi-Fi only covers most people.

The reason is that psd / clip / procreate files run several hundred MB each, and a series-worth of work reaches tens of GB. 64 GB and 128 GB get eaten by the OS and apps.

Cellular only makes sense if you specifically need always-on connectivity on the move. If Wi-Fi at home and at cafés covers you, putting the 10,000–20,000-yen difference into the Pencil or a case is the higher-satisfaction move.

Accessories — the minimum set

Short answer: Apple Pencil (2nd gen), a screen protector, and a stand or keyboard cover. Three things, and the drawing setup is broadly there.

Apple Pencil (2nd gen): required. Sold separately
Paper-like screen protector: closer to the feel of paper. Pen tips wear faster as a tradeoff
Stand or keyboard cover: gives you a drawing angle on a desk. Easier on posture over long sessions

Unlike a display tablet, there are no external monitor cables or drivers to wire up. Starting to draw the day it arrives is the iPad’s quiet strength.

Comparison: plain iPad / iPad Air / iPad Pro (for illustration)

The line-up below is anchored to 2021. In 2026, verify the current generation’s specs and price for each model.

Aspect	Plain iPad	iPad Air	iPad Pro 12.9”
Screen size	About 10.2 in	About 10.9 in	12.9 in
Apple Pencil	1st gen	2nd gen	2nd gen
Refresh rate	60 Hz	60 Hz	120 Hz (ProMotion)
RAM (rough)	3–4 GB	4 GB	6–8 GB
Price (rough)	From ~40,000 yen	From ~70,000 yen	From ~120,000 yen
Best fit	Entry, doodling	Hobby through semi-pro	Display-tablet replacement, serious drawing

FAQ

Q. Can you draw on an iPad mini? A. You can, but the 7.9–8.3-inch screen gets cramped for long sessions. If you want to share it with ebook and gaming use, the iPad mini works; if drawing is the main goal, step up to the Air or higher. For more, see How to pick an iPad mini.

Q. 11-inch or 12.9-inch iPad Pro? A. 12.9 if you draw seriously. The price gap is around 20,000 yen, but the extra screen translates directly into “the range you can draw on without zooming.” 11-inch is worth considering only if portability is the priority.

Q. Can you do illustration work entirely on an iPad? A. With Procreate or Clip Studio Paint, you can take a piece from rough to finish on iPad. That said, for fine pre-submission tweaks and multi-monitor workflows, pairing with a PC is the realistic long-term setup.

Q. How much RAM do you need? A. RAM starts to matter as layer count climbs. The Air’s 4 GB holds up for hobby use, but for commercial-scale canvases the iPad Pro’s 6–8 GB is the safer call.

Wrapping up

For an illustration iPad, the 12.9-inch iPad Pro is the call if you draw seriously, and the iPad Air is the realistic entry point for hobby through semi-pro use. The plain iPad is cheap, but as a dedicated drawing tablet it sits a notch behind on Pencil-generation support.

The deciding factors are three: 11-inch-or-larger screen, 2nd-gen Apple Pencil support, and 256 GB or more storage. Prioritizing those three over price leaves less regret after the purchase.

Starting to draw the day it arrives is the iPad’s quiet strength. The lower setup overhead, compared with a display tablet plus PC, adds up over years of drawing.

How to pick a numeric keypad for Windows — laptop built-in, USB, or Bluetooth

Sat, 10 Apr 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The basic structure of numeric keypads has not changed much since 2021, so the framework still holds, but the specific product links need to be swapped for current models.

When you keep typing numbers in Excel, the small cost of reaching for the number row on a full-size keyboard quietly adds up. For accounting, inventory, or data entry work — anything where you punch in numbers many times a day — a dedicated keypad ends up faster.

This piece walks through how to pick a numeric keypad for Windows, in this order: is the laptop’s built-in keypad enough, and if not, USB or Bluetooth? By the end you should have a clear shape of the one unit that fits you.

The short answer — for heavy number entry, a USB 2.4GHz external keypad is the first pick

Short answer: first check whether the laptop’s built-in keypad is enough. If it isn’t, the default Windows keypad shape is USB 2.4GHz wireless, slim, with a calculator key.

Three reasons:

USB 2.4GHz has less latency than Bluetooth — the dedicated receiver link is less affected by the surrounding environment
A slim profile (scissor switch or pantograph) matches the key height of a laptop — minimal step when you place them side by side
A calculator key earns its space if you open the calculator many times a day — you can launch it without your eyes moving

For people whose work is fully contained on a laptop, or whose desk doubles as a Windows + iPad setup, the decision axis is different. The sections below walk through it.

Is the laptop’s built-in keypad enough — check this first

Short answer: if you type numbers a few dozen times a day, the laptop’s built-in keypad is enough. If you punch in real volume every day, switching to an external one is easier on your hands.

The reason is structural: a laptop with a built-in keypad is wider, which shifts the home position to the left of body center. Type for long stretches and your right shoulder tends to creep forward.

What to check:

How often you type numbers: hundreds of times a day → external; occasionally → built-in is plenty
Body size: built-in keypads are usually only on 15.6-inch and larger models (depends on model)
Key layout: NumLock and 00 key placement vary by manufacturer, so if you already know one brand’s layout you can keep using it

If the built-in keypad doesn’t feel like enough, switch to external. The next section gets into connection types.

Connection type — USB 2.4GHz, Bluetooth, wired

Short answer: for a fixed PC setup, USB 2.4GHz; for sharing with a phone or tablet, Bluetooth; if you absolutely need zero latency, wired.

The reason is that each is good at a different scenario.

USB 2.4GHz (wireless receiver)

You plug a dedicated USB receiver into the PC. Less latency than Bluetooth, and fewer dropped keystrokes right after waking from sleep.

It uses one USB port, but there’s no pairing dance. On Windows it just works the moment you plug it in.

For a fixed keypad setup on a desktop or laptop, this is the format I’d recommend first.

Bluetooth

Connects to the PC’s built-in Bluetooth. No receiver needed, so it doesn’t take up a USB port.

Handy if you want to share the same hardware with an iPad or phone. The trade-off is that in congested environments a keystroke can drop for a moment. There’s also a bit of a wait after sleep wake (environment-dependent).

Wired USB

Connects to the PC by cable. Guaranteed zero latency.

The cost is desk handling: placed to the right of a tenkeyless keyboard, the cable tangles into the path your hand takes. Unless you’re an accountant typing numbers all day, wireless is plenty.

Comparison: USB 2.4GHz / Bluetooth / laptop built-in

Lining all three up. Price and latency feel are reference values from when I bought mine (varies by model and environment).

Aspect	USB 2.4GHz	Bluetooth	Laptop built-in
Connection	USB receiver	PC’s built-in Bluetooth	Integrated into the laptop
Latency concern	Low	Slightly higher (environment-dependent)	None
Stability	Good	Fair	Good
Cross-device use	Limited (PC-oriented)	Good (works with phone/tablet)	None (laptop only)
USB port use	1 port	None	None
Price range	2,000–4,000 yen	3,000–6,000 yen	Included in laptop price
Portability	Carry with the receiver	Carry on its own	Stays with the laptop
Calculator key	Depends on model	Depends on model	Most models don’t have one

Rough decision guide:

Windows desktop / fixed laptop setup → USB 2.4GHz
Want to share with iPad/phone, or USB ports are scarce → Bluetooth
About to replace the laptop / light number entry → consider a model with a built-in keypad

Three keys you don’t want to miss — Tab, Backspace, calculator

Among the keys on the keypad body, three are ones Excel-heavy users shouldn’t drop:

Tab: horizontal cell movement in Excel. Combined with Enter (down), you can fill in a whole table without leaving the keypad
Backspace: instant fix for a wrong digit. You hit it constantly in numeric entry, so a dedicated key matters
Calculator: launches the Windows Calculator app with one key. Earns its keep during expense work

A 00 (double-zero) key only matters if you enter monetary amounts a lot. Outside accounting work, it’s lower priority.

You can confirm these keys are present by looking at the key layout photo on the product page. Spec sheets alone sometimes don’t tell you whether “Tab” and “Backspace” are there, so always check the image.

Key feel — scissor switches if it sits next to a laptop

Short answer: if you place it next to a laptop, a scissor switch or pantograph matches the key height and is easier to work with.

Membrane: cheap. Long key travel — placed next to a laptop, the height difference feels off
Pantograph: the slim format widely used in laptops. Compact, but the feel varies a lot between products
Scissor switch: refined version of the pantograph. Slim with a clear click feel. Less tiring over long sessions

For dedicated number entry, scissor switches are the first pick.

What to actually buy

For a model that hits all three of USB 2.4GHz, scissor switches, and a calculator key, I’ve written a separate review of the Belis wireless numeric keypad. It gets into the key feel on an actual unit, how loud the LED is, and battery life — so if you want to confirm whether a specific model matches the conditions above, read them together.

Related: Belis wireless numeric keypad review — a slim USB 2.4GHz keypad with a calculator key

FAQ

Q. If I buy a laptop with a built-in numeric keypad, do I still need an external one? A. If you type numbers a few dozen times a day, a laptop with a built-in keypad is enough. The drawbacks are a wider body, a home position that sits to the right of center, and key layouts that vary by manufacturer — so if you punch in numbers in real volume every day, an external keypad is easier on your hands.

Q. USB 2.4GHz vs. Bluetooth — which is more stable? A. For a fixed setup at a PC, USB 2.4GHz is more stable. The dedicated receiver link has less latency and is less likely to keep you waiting right after sleep wake. Bluetooth can drop a keystroke for a moment in noisy or congested environments.

Q. Should the numeric keypad have a calculator key? A. If you launch the calculator often — expense claims, rough stock counts — go with a model that has a dedicated calculator key. Compared to a keyboard shortcut you have to remember, your eyes move less, and the calculator appears the instant you press the key.

Q. Can I use the same numeric keypad on a Mac? A. The number keys themselves usually work, but the calculator key and some function keys may not respond on macOS, or may be recognized as different keys. If you plan to use it on a Mac, it’s safer to confirm explicit Mac support on the product page before you buy (depends on product and OS version).

Wrapping up

For a numeric keypad on Windows, first check whether the laptop’s built-in one is enough. If it isn’t, the split is: USB 2.4GHz for a fixed PC setup, Bluetooth for sharing with other devices.

Key format: scissor switch or pantograph. Confirm from the product photo that Tab, Backspace, and the calculator key are present.

With those constraints, it’s hard to pick wrong. If you want to know the key feel on a specific model before buying, the Belis wireless numeric keypad review sketches it in concrete detail.

Vue.js for beginners — components, props, and two-way binding, explained with real code

Fri, 09 Apr 2021 00:00:00 GMT

2026 update: a post ported over from the old VuePress blog. The shape of the explanation still holds, but the tooling and Vue version are frozen at the time of writing and differ from the current release.

For anyone picking up Vue.js — or a JavaScript framework — for the first time, the part to understand first is components.

This post starts from what a component is, so it should read cleanly even without prior framework experience.

The short version

A component is a reusable UI part — it raises maintainability and lets you reuse work
Data flows between a parent and a child through binding
Use one-way binding (v-bind / v-on) and two-way binding (v-bind + v-on, or .sync) depending on whether the data needs transforming

What is a component?

Vue.js and Angular both build on the idea of a component.

Vue uses components to consolidate code. Consolidation cuts down the amount of code you maintain and makes it easier to change later.

Every Vue project uses components in some form, so understanding them is non-optional.

A reusable part

A component, in one line, is a reusable part.

A .vue file can import and use another .vue file inside its own template.

Build a button as a reusable component, for example, and any caller can render the same look and the same behaviour just by referencing it.

Example: a button

Goal: reuse a 20 px square button labelled “click here”.

How:

In file A, define a 20 px square button labelled “click here”.

In file B, render the button component.

Result: the button shows up in file B.

The side being called (file A) and the side calling it (file B) are usually referred to as the child and the parent.

From here on:

The caller = parent
The called = child

What is binding?

In the button example above, two limitations stand out:

The button text is hard-coded
The click handler has to live in the child

Binding is what removes those limits.

Component-to-component data flow

Binding, in one line, is the data flow between components.

With binding in place you can:

Let the parent decide the child’s text
Let the child propagate an event up to the parent

Both of the issues above go away once binding is added.

The relationship between the parent and the child matters here:

A one-way trip — parent to child, or child to parent — is one-way binding
A round trip between the two is two-way binding

Components do not click into place until binding does, so this is the section worth re-reading.

Working examples

From here, the explanation is anchored to real Vue.js code.

If .vue file basics are unfamiliar, the earlier post covers them:

Vue.js for beginners — the basics

Using a component

Start with the plainest case: rendering a component with no binding at all.

The child shows a string. The parent renders the child.

Child: ChildComponent.vue

<template>
  string
</template>

The child has no logic — it just prints text.

Parent: ParentComponent.vue

<template>
  <ChildComponent />
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },
};
</script>

The parent imports ChildComponent.vue and registers it under components. On the template side, dropping <ChildComponent /> where you want it to render is enough.

v-bind — one-way binding, parent to child

With the call mechanics out of the way, the next step is parent-to-child binding.

The idea is: let the parent decide the child’s text.

The snippet below passes a string set in the parent down to the child.

Child: ChildComponent.vue

<template>
  {{bindName}}
</template>

<script>
export default {
  props: ["bindName"],
};
</script>

To receive data from the parent, the child declares props.

The prop name has to match on both sides. Here it is bindName.

props is an array, so a child can declare multiple inbound props at once.

Parent: ParentComponent.vue

<template>
  <ChildComponent :bindName="dataName" />
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },

  data() {
    return {
      dataName: 'string'
    };
  },
};
</script>

The parent renders the child with :bindName="dataName". That attribute is the bind itself.

bindName is the prop name on the child
dataName is the data field on the parent

That is the full parent-to-child flow.

v-on — one-way binding, child to parent

Next, child-to-parent binding.

The idea is: let the parent observe an event that happened inside the child.

In the snippet below, clicking the child’s text fires an event in the parent and flips the parent’s text from string → モジ.

Child: ChildComponent.vue

<template>
  <div>
    <div @click="clickText()">
      クリックして変更
    </div>
  </div>
</template>

<script>
export default {

  methods: {
    clickText() {
      this.$emit('onName', 'モジ');
    }
  }
};
</script>

The child wires up a click handler — @click is the directive.

Inside the method, the line that lifts the event up to the parent is emit.

The first argument, onName, is the event name
The second argument, モジ, is the payload (an object works too)

Clicking “クリックして変更” propagates up to the parent’s onName listener.

Parent: ParentComponent.vue

<template>
  {{dataName}}
  <ChildComponent @onName="changeName"/>
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },

  data() {
    return {
      dataName: 'string'
    };
  },

  methods: {
    changeName(item) {
      this.dataName = item
    }
  }
};
</script>

The parent looks much like the v-bind case.

The new piece is changeName — its argument is the payload the child emitted.

That is the full child-to-parent flow.

Going further

The one-way patterns above cannot move data in both directions on their own.

Two-way binding is what closes that loop. It is the trickiest part of components, so this section is worth slowing down on.

v-bind + v-on — two-way binding

Vue.js has two common ways to do two-way binding. The most fundamental one comes first.

It is the combination of:

v-bind — one-way, parent to child
v-on — one-way, child to parent

The flow:

The parent sets the string the child will show (string)
The child sends a click event up to the parent (payload: モジ)
The parent’s string flips from string → モジ
The child re-renders with モジ

Previous sections led with the child. From here, the parent comes first — it reads more naturally.

Parent: ParentComponent.vue

<template>
  <ChildComponent :bindName="dataName" @onName="changeName"/>
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },

  data() {
    return {
      dataName: 'string'
    };
  },

  methods: {
    changeName(item) {
      this.dataName = item
    }
  }
};
</script>

It is just v-bind and v-on running side by side. The parent stays straightforward.

Child: ChildComponent.vue

<template>
  <div>
    {{bindName}}
    <div @click="clickText()">
      クリックして変更
    </div>
  </div>
</template>

<script>
export default {
  props: ["bindName"],

  methods: {
    clickText() {
      this.$emit('onName', 'モジ');
    }
  }
};
</script>

The child is the same shape — v-bind plus v-on.

If this stops making sense, walking through the four-step flow above in order tends to put it back together.

.sync — two-way binding

v-bind + v-on works, but it gets verbose.

.sync is the shortcut for the cases that do not need the wiring.

In one line, .sync turns v-bind into a synced binding.

The code below produces the same end behaviour as the previous snippet:

The parent sets the string the child will show (string)
The child sends a click event up to the parent (payload: モジ)
The parent’s string flips from string → モジ
The child re-renders with モジ

Parent: ParentComponent.vue

<template>
  <ChildComponent :bindName.sync="dataName" />
</template>

<script>
import ChildComponent from "xxxx/ChildComponent.vue";

export default {
  components: { ChildComponent },

  data() {
    return {
      dataName: 'string'
    };
  },
};
</script>

The parent gets noticeably lighter.

The key is bindName.sync — adding .sync removes the explicit assignment that v-on was doing.

Child: ChildComponent.vue

<template>
  <div>
    {{bindName}}
    <div @click="clickText()">
      クリックして変更
    </div>
  </div>
</template>

<script>
export default {
  props: ["bindName"],

  methods: {
    clickText() {
      this.$emit('update:bindName', 'モジ');
    }
  }
};
</script>

The child changes slightly — the first argument to emit becomes update:bindName.

The update: prefix is what wires the emit back into the parent’s .sync.

v-on vs. .sync — when to use which

.sync is shorter, but it has a caveat.

Because it is a synced bind, there is no place to hook in transformation logic. If the parent needs to filter or reshape the child’s payload before assigning it, .sync will not fit.

A rough rule for two-way binding:

If the data is transformed between files → v-bind + v-on
If the data is passed through unchanged → .sync

Wrap-up

Components and binding are two of the load-bearing pieces of Vue.js, and the rest of the framework leans on them. Worth re-reading and writing out by hand until they feel automatic.

Related:

How to pick a MacBook for blogging — Air covers it; Pro is for creators

Thu, 08 Apr 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The frame — Air is enough; Pro only if you’re a creator — still holds, but the model names, prices, and specs below are 2021-era. Apple Silicon has gone through several refreshes, so confirm the current line-up before buying. Heavily rewritten — re-check the affiliate links before publishing.

When you start looking at MacBooks to start a blog, the options pile up fast: Air, Pro, 13-inch, 14-inch, 16-inch. The price gap can run past 100,000 yen, and going straight to a Pro feels reckless.

This piece narrows the question to one use case — writing a blog — and lays out which MacBook to pick between Air and Pro. The short version: for almost everyone, the Air is enough.

If you’re weighing this against a Windows laptop, the companion piece How to pick a laptop for blogging covers the cross-OS criteria.

The short answer — MacBook Air for blogging, Pro only if you double up as a creator

Short answer: if blog writing is the only goal, the cheapest MacBook Air is enough. The price gap to a Pro (roughly 50,000–100,000 yen) is worth paying only if you also edit video, develop, or process RAW photos.

The reason is simple: WordPress writing happens in the browser. The browser needs to feel smooth, and the Air’s Apple Silicon comfortably cleared that bar even as the entry-level laptop of the day.

There are only two real axes to weigh:

What you’ll do on the MacBook — Air if it’s “blogging only”; Pro if you also handle video, photo, or development
Whether you carry it — the Air is light; the 16-inch Pro is over 2 kg

Settle those two and there isn’t much room left to second-guess.

Three things to look at when choosing a MacBook

Short answer: for a blogging machine, the only specs that matter are RAM, weight, and screen size. The CPU generation and core count are not worth stressing over.

The reason is that writing work hits memory before it hits the CPU. If you write with dozens of browser tabs open for reference, RAM is where you’ll feel the squeeze.

RAM — 8 GB is the floor, 16 GB lasts longer

RAM is how much your machine can hold in flight at once. Tabs eat into it quickly, so if you tend to leave 30 reference tabs open while drafting, this is where you’ll bottleneck.

8 GB: WordPress editor plus ~10 reference tabs is fine
16 GB: recommended if you plan to keep the machine for 4–5 years — your tab habits don’t have to be disciplined

Apple Silicon MacBooks have RAM soldered on; you can’t upgrade it later. Decide at purchase.

Weight — ignore it if you write at home, target 1.3 kg or less if you carry it

If you only write at home, weight is a non-issue.

If you write outside, the Air is the realistic pick. The Pro is around 1.5 kg even at 14 inches, and the 16-inch passes 2 kg. Slipping that into a bag every day adds up on your back.

Screen — 13 inches is enough; add an external monitor at home

Blog writing is text-first, so 13 inches is workable.

If you write at home for long stretches, adding an external monitor moves the needle more than upgrading the laptop’s own screen. Reference material stays parked on one display, and you stop paying the tax of switching tabs.

Picks by model

Short answer: for blogging only, the MacBook Air 13-inch. If you also edit video or develop, the MacBook Pro 14-inch. The Pro 16-inch isn’t a blogger’s machine.

MacBook Air 13-inch — the default for bloggers

If blogging is the only job, this is the pick. At time of writing (2021), the M1 MacBook Air started at 115,280 yen (tax included) with 8 GB RAM and 256 GB SSD.

Bumping RAM to 16 GB adds about 20,000 yen at order time, but if you’re keeping the machine 4–5 years, this is not where to economise.

MacBook Pro 14-inch — if you’re doubling up

Consider the Pro 14-inch if any of these apply:

Video editing (4K exports as a regular thing)
RAW photo processing
iOS / macOS app development, machine learning
Driving two or more external monitors at all times

Otherwise, for blogging alone this is overkill. The price gap returns more if you spend it on an external monitor or the rest of your desk setup.

MacBook Pro 16-inch — not for bloggers

Over 2 kg, over 300,000 yen — squarely excessive for blogging. It’s a desktop-replacement machine for people running it stationary, and it doesn’t belong on a first-MacBook shortlist for a blogger.

Comparison: MacBook Air vs Pro (viewed through a blogging lens)

Aspect	MacBook Air 13”	MacBook Pro 14”	MacBook Pro 16”
RAM (base)	8 GB	16 GB	16 GB
Weight	~1.29 kg	~1.55 kg	~2.1 kg
Battery life	Up to 15–18 h	Up to 17 h	Up to 21 h
Price (2021)	From 115,000 yen	From 230,000 yen	From 300,000 yen
Headroom for blogging	Enough	Overkill	Far too much
Doubling up	Light tasks only	Video, photo, dev	Heavy video editing

If the plan is blogging only, the 100,000+ yen gap between the Air and the Pro 14-inch buys a noticeably better writing experience when spent on an external monitor or a chair.

FAQ

Q. MacBook Air RAM — 8 GB or 16 GB? A. 16 GB if you’re planning to keep it for 4–5 years. Apple Silicon can’t be upgraded later, so treat it as insurance against your future self. If you’ll replace it within 2–3 years, 8 GB is fine.

Q. Mac or Windows for blogging-only? A. Writing efficiency doesn’t change with the OS. Pick the one you already use — less context switching, less friction. The Windows-side comparison lives in How to pick a laptop for blogging.

Q. Can I blog from an iPad Pro plus Magic Keyboard? A. For short pieces, yes. For the WordPress admin, plugin settings, and batch image work, a laptop is clearly faster — and iPad browser extensions tend to be where things stall. Long term, recommend a laptop.

Q. Is a used MacBook a reasonable buy? A. Yes, but only Apple Silicon (M1 onwards). Intel-era macOS support is likely to drop off sooner, so the savings probably aren’t worth it.

Wrapping up

Pick a MacBook by first answering what you’ll do on it — that resolves 90% of the Air-vs-Pro question.

For writing only, the Air 13-inch is enough. A Pro earns its price only when video, photo, or development comes with it. Otherwise, putting the price gap into an external monitor or your desk setup buys a better day-to-day than the Pro does.

If you’re still torn between this and a Windows laptop, the sister piece How to pick a laptop for blogging lines up the trade-offs.

Logitech MX Master 2S vs 3 — which one to buy

Wed, 07 Apr 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The MX Master 2S is no longer part of the current lineup — the 2026 successor is the MX Master 3S. The 2S-vs-3 contrast below still maps cleanly onto the choice between the 2S and the 3S. Screenshots are kept from the original write-up.

I wanted a good mouse for work, and Logitech kept coming up. The decision stalls at the same place every time: MX Master 2S or MX Master 3.

After six-plus months with each, this is the difference between them.

The verdict — if in doubt, pick the MX Master 3

Short answer: for a new purchase, go with the MX Master 3 (or the current 3S).

It comes down to three things:

The thumb wheel (side wheel) is bigger, and horizontal scrolling happens with one finger
Charging moved to USB Type-C, so the cable is shared with everything else on the desk
The main wheel senses scroll speed and switches modes automatically

That said, if you like to plant your whole palm on the mouse, or you have larger hands, the MX Master 2S can still be the better fit. For per-model detail, see the standalone reviews of the MX Master 2S and the MX Master 3.

Comparison table — specs and feel

Short answer: shape, thumb wheel, and charging are the main differences. The price gap is roughly 3,000 to 4,000 yen.

Angle	MX Master 2S	MX Master 3
Shape	Flatter, curved	Taller, more squared off
Suggested grip	Palm rest	Pinch with thumb and pinky
Thumb wheel	Small	Large
Side button layout	Stacked vertically	Front-back (horizontal)
Main wheel	Mechanical (manual switch)	MagSpeed (auto switch)
Charging	micro-USB Type-B	USB Type-C
Stated battery life	~70 days	~70 days
Price at time of writing	~9,400 yen	~13,000 yen and up

On paper the 3 wins on every axis, but the shape preference sits on a separate axis — the table alone is not enough to decide.

Shape and grip

Short answer: the 2S is flatter, the 3 is taller. The grip itself changes.

The 2S has a rounded left flank, so the natural grip is to rest the palm on top — the weight of the hand holds the mouse.

The 3 has a straighter left flank and a taller back. You end up pinching the waist between thumb and pinky and lifting the mouse to move it.

From behind, the 3 is clearly the taller of the two. That is what makes the “pinch grip” sit right on it.

The left flank angles differ, and so does the way the thumb reaches the thumb wheel. On the 3, the wheel sits where the pad of the thumb naturally lands.

Thumb wheel — the centerpiece of horizontal scrolling

Short answer: the 3’s thumb wheel is clearly easier to use. If you live in Excel or wide code files, the difference shows.

The thumb wheel handles horizontal scrolling. Panning right in Excel, scanning long lines of code, scrubbing a video timeline, dragging horizontally in Figma — all of them resolve to one finger, no keyboard modifier.

The 2S’s thumb wheel is small enough that the pad of the thumb has to hunt for it. On the 3, it is big enough that the thumb falls onto it naturally.

Being able to drive both axes at once — main wheel for vertical, thumb wheel for horizontal — is a strength shared by both mice.

Side button layout

Short answer: the 2S stacks them vertically, the 3 uses front-back. Front-back is more intuitive.

The 2S’s side buttons are stacked vertically — uncommon even within Logitech’s lineup. Once you adapt, the two are quick to tell apart, but mapping them to Back and Forward tends to produce misfires.

The 3 goes back to a front-back layout, which lines up with most other mice. Switching between mice in the same day no longer costs anything.

Main wheel and charging

Short answer: the 3’s main wheel switches automatically. Charging is USB Type-C, which makes cable sharing easy.

Both mice have two main-wheel modes: notched (gear-like feedback) and free-spin (smooth, continuous). The 2S switches between them with a button on the wheel. The 3 uses an electromagnetic mechanism called MagSpeed and switches automatically based on scroll speed.

Slow scrolls stay precise, fast scrolls take off. Not having to think about which mode is active turns out to matter more than it sounds.

Charging is micro-USB Type-B on the 2S and USB Type-C on the 3. In 2026 most peripherals assume Type-C, so being able to share one cable across the desk is a small but real win for the 3. The charging cycle is once every two or three months, so this is not a deal breaker.

How to choose — by use case

Short answer: pick by workload and hand size. Heavy Excel use leans 3; a stationary home-desk mouse is more about preference.

Stationary desk, lots of Excel or code

Pick: MX Master 3

The larger thumb wheel pairs well with work that asks for constant horizontal scrolling. The auto-switching main wheel helps anyone moving up and down long sheets. Type-C is a quiet plus for keeping the desk tidy.

You want to plant your whole palm / you have larger hands

Pick: MX Master 2S

The 3 assumes a pinch grip. If you prefer to rest your palm flat on the mouse, the 3 can feel a little cramped. For larger hands used to flatter mice, the 2S’s shape sits better.

Mostly portable, lives in a bag

Neither is the right call

The MX Master line is sized for the desk. For travel, the smaller MX Anywhere 3 line fits a bag without complaint.

Mainly gaming

Neither is the right call

Response feels like an ordinary office mouse. For FPS or anything that needs precise input, a dedicated gaming mouse is the better tool. The 2S also has a known durability concern around the gesture button (see the 2S standalone review), which makes it a poor fit for heavy clicking.

FAQ

Q. Can the MX Master 3 work for smaller hands? A. The 3 is built around the pinch grip, so finger length matters more than overall palm size. If your fingers can hold it, you can operate it. If you have any doubt, holding one in a store is the surest way to decide.

Q. Does it work on a Mac? A. Both mice work. Logi Options+ (formerly Logicool Options) has a Mac build, and either Bluetooth or the USB receiver gets you connected.

Q. Does it work with an iPad? A. From iPadOS 13.4 onward iPads support mice over Bluetooth pairing. Some of the gesture and thumb-wheel features may not be fully supported on the iPad side, so mileage depends on the workflow.

Q. In 2026, should I just go with the 3S? A. For a new purchase, yes. The 3S is a refined 3 — improved sensor resolution and quieter clicks. The notes here on “the 3” largely transfer to the 3S.

Wrap-up

The MX Master 2S and MX Master 3 share a series name, but the shape and feel are closer to two different mice.

For a new purchase, the MX Master 3 (or the current 3S) is the safer pick. If you prefer a palm grip and the size suits your hand, the 2S still has a place.

The full per-model write-ups live in the MX Master 2S review and the MX Master 3 review — worth a read if this comparison alone is not enough to decide.

How to pick an iPad mini — the 8.3-inch one-hand form factor earns its keep for reading, gaming, and on-site notes

Mon, 05 Apr 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog (first published in 2021, written against the generation before iPad mini 6). The current model as of 2026 is mini 7 (A17 Pro, released October 2024). The framework still applies, but verify pricing and specs against Apple’s current official figures.

The iPad mini gets dismissed as “the small iPad,” which makes the gap with the standard iPad hard to see. On price alone the mini costs more, and its screen is smaller. So where does the case for the mini actually come from?

This piece narrows the iPad mini down to three use cases where it earns its keep, then lines it up against the standard iPad and the iPad Air so you can pick the right one.

The short answer — get the mini if you hold a tablet one-handed for long stretches; otherwise get the standard iPad

The short version: the iPad mini delivers when you’re holding it the whole time you’re using it. Concretely, three use cases — ebook reading, gaming, and on-site notes. Anywhere else, the standard iPad gives you more screen for less money.

The reason is that the mini’s differentiator is the 8.3-inch size itself. It doesn’t win on CPU or panel quality; its value is the weight and form factor that fit in one hand. Set it on a desk and that value evaporates.

Three things to decide on:

How you’ll hold it: a lot of one-handed time — yes means mini, no means the standard iPad
Storage: do you hoard photos and video on the device — if not, the smallest tier is enough
Connectivity: do you need to be online standalone when you’re out — does Wi-Fi do it, does tethering do it

Use case by use case — mini earns its keep in three places only

The short version: ebook reading, gaming, and on-site notes. If none of those three fit, the case for the mini gets thin.

The reason is that for everything else — video, note-taking, illustration, document review — screen size carries the day. At the same price band the standard iPad gives you a better experience.

Reading ebooks

8.3 inches sits between a paperback and a hardcover, a touch smaller than a deluxe-edition manga volume.

Holding it one-handed for 30 minutes or more without arm fatigue is the real win. The mini 7 weighs 293 g (Wi-Fi model, rated). Against the standard iPad at around 477 g, the difference in how your arm feels after a long reading session is clearly there.

Gaming

Shorter thumb travel is the mini’s quiet advantage.

On a larger tablet, your thumbs can’t reach the edges in action games, and you end up re-gripping mid-play. On the mini, edge-to-edge stays inside thumb range.

Taking notes and pulling up materials on-site

Standing-up conversations where you turn the screen toward the other person, one-handed annotation, slipping it into an inside jacket pocket — this is where the mini owns the field.

The standard iPad assumes two hands and doesn’t fit in a pocket.

Specs — what changed between the current mini 7 and the older mini 6

The short version: mini 7 (2024) is A17 Pro, Apple Intelligence supported. mini 6 (2021) is A15 Bionic. For everyday use the felt difference is small, but if you plan to keep it for a long time, go with the 7.

Item	mini 7 (2024)	mini 6 (2021)
Chip	A17 Pro	A15 Bionic
Apple Intelligence	Supported	Not supported
Storage	128 / 256 / 512 GB	64 / 256 GB
Pencil	Apple Pencil Pro / USB-C	Apple Pencil 2 / USB-C
Weight (Wi-Fi)	293 g	293 g
Released	October 2024	September 2021

(Specs from Apple’s official iPad mini specs page.)

If you can find a used or refurbished mini 6 cheap, reading and browsing is still well within its range. The catch is the 64 GB base tier — too tight for modern apps. If you’re thinking long-haul, mini 7 at 128 GB is the starting line.

Comparison — iPad mini vs standard iPad vs iPad Air

The short version: portability goes to mini, value goes to the standard iPad, work-friendliness goes to Air.

Aspect	iPad mini 7	Standard iPad (A16)	iPad Air (M3)
Screen size	8.3 inches	11 inches	11 / 13 inches
Weight (Wi-Fi)	293 g	477 g	460–617 g
Portability	Excellent (one-handed)	Average (two-handed)	Average to slightly heavy
Work suitability	Cramped	Manageable	Comfortable
Pencil	Pro / USB-C	USB-C	Pro / USB-C
Price band (reference)	Mid	Low	High

(Pricing and specs: confirm on Apple’s official site.)

Portability, reading, gaming → mini
Value-first, home-based use → standard iPad
Note-taking, illustration, light work as a secondary machine → Air

If you’re looking at iPad for illustration, screen size and pen pressure are a separate axis. See How to pick an iPad for illustration for the full breakdown.

Picking storage and Cellular

The short version: if you don’t hoard photos and video on the device, 128 GB / Wi-Fi is enough. The decision tree is simple, so don’t spend long on it.

Storage — 128 GB, or more?

iPad mini 7 ships in 128 / 256 / 512 GB. Price gaps shift by generation and by sale.

Photos and video pushed to iCloud / the cloud → 128 GB
Carrying video footage or several large games at once → 256 GB or more
Long-term video storage → an external SSD is a better fit than an iPad in the first place

Wi-Fi or Cellular?

The Cellular model costs more up front and needs its own line.

Covered by Wi-Fi at home and work → Wi-Fi model
Frequent standalone use outside, phone tethering is a hassle → Cellular / eSIM
Genuinely unsure → start with Wi-Fi + tethering. If it turns out to be a pain, get Cellular next time

FAQ

Q. iPad mini or the standard iPad — which should I buy? A. If you’ll hold it one-handed for long stretches, mini. If you’ll set it on a desk to work, the standard iPad. Without a clear portable use case (reading, gaming, on-site notes), the standard iPad gives you a bigger screen for less money.

Q. mini 6 (2021) vs mini 7 (2024) — is it safe to buy the older one if it’s still being sold? A. For reading and browsing the practical difference is small, so mini 6 still works. That said, mini 7 supports Apple Intelligence and runs on the A17 Pro, so if you plan to keep it for a long time, go with the 7.

Q. Is 128 GB safe, or should I go 256 / 512 GB? A. If you don’t keep photos and videos on the device itself, 128 GB doesn’t run out. Pushing photos to iCloud or Google Photos means the smallest tier is fine. Carry video footage around and you want 256 GB or more.

Q. Do I need the Cellular model? A. Not if you use Wi-Fi at home and at the office. If you need to pull up a map, a draft, or a document on the spot when you’re out, then Cellular or eSIM. Try phone tethering first — that often turns out to be enough, and you save the upcharge.

Wrapping up

The reason to pick an iPad mini isn’t performance and it isn’t the screen — it’s the size that fits in one hand.

If you fit any of the three use cases — ebook reading, gaming, on-site notes — mini 7 with 128 GB Wi-Fi is the starting point. If you don’t, the standard iPad wins on screen and price.

Picking across the iPad line gets easier when you split it into three axes: do you hold it one-handed, do you set it on a desk, do you draw on it. If illustration is the reason you’re buying, also see How to pick an iPad for illustration alongside this piece.

Logitech MX MASTER 3 review — the natural sequel to the 2S, with USB Type-C and a MagSpeed wheel

Sat, 03 Apr 2021 00:00:00 GMT

2026 update: Ported and revised from the old VuePress blog. The MX MASTER 3 itself is an older model in 2026 — the current line is the MX Master 3S (higher sensor resolution and quieter clicks). The review angles in this piece (charging port, MagSpeed wheel, thumb wheel) carry over to the 3S, so it should still be useful whether you are looking at the 3 or the 3S. The screenshots in this article are from Logicool Options at the time of writing; today it has been replaced by Logi Options+.

I used the Logitech MX MASTER 3 for over a year at work and at home. This is the write-up from that time.

I covered the previous model in a separate post: the MX MASTER 2S review. This is the sibling piece — focused on what changed and what did not between the 2S and the 3. If you are deciding between the 3, the 2S, and the 3S for a new purchase, the comparison should give you enough to choose.

The verdict — if you do not already own a 2S, get the 3 (or the 3S)

Short answer: the move to USB Type-C alone is reason enough to upgrade from a 2S. Add the MagSpeed wheel and the wider thumb wheel, and two-axis scrolling in Excel, code editors, and Figma gets visibly smoother.

The three main deltas from the 2S:

Charging port: micro-USB → USB Type-C
Main wheel: mechanical → MagSpeed (electromagnetic), which switches between ratcheted and free-spin automatically based on how hard you flick it
Thumb wheel (horizontal scroll): larger, easier to roll with the pad of your thumb

What did not change is the size lineup (full-size only) and the distinctive sculpted shape. For smaller hands it is still a large mouse, and that stays true on the 3S too.

Build and feel

Short answer: lined up next to a 2S, the 3 reads as a more angular sibling. USB Type-C is on the front, and the enlarged thumb wheel is on the left flank.

A Logicool logo sits on the left click. Directly above the main wheel is the scroll-mode toggle (ratcheted / free-spin). On the thumb side is the gesture button.

Connection is over Bluetooth or the USB receiver that succeeded Unifying. The receiver is included (the first run of the MX MASTER 3 shipped with the receiver; some 3S configurations sell it separately).

The underside carries the power switch and a device-pair toggle (up to three devices). The sensor is rated 1000 dpi (the 3S raises this to 8000 dpi).

USB Type-C lives on the front. This is the single biggest change from the 2S’s micro-USB Type-B, and the day-to-day payoff — one cable type across the whole desk — is bigger than it sounds.

From behind, the body has a clear waist through the middle. You grip it with the thumb on one side of the waist and the pinky on the other — the same hold as the 2S.

The left flank carries two side buttons (back/forward) and the horizontal thumb wheel. The thumb wheel is now nearly the size of the main wheel — easier to roll than the narrow strip on the 2S. A short green indicator blinks when you turn the mouse on.

The right side is plain — no buttons.

What worked

Short answer: the “it just switches” feel of the MagSpeed wheel, the wider thumb wheel, and USB Type-C charging.

MagSpeed — ratcheted and free-spin, switched automatically

This is the headline feature of the MX MASTER 3. Roll the wheel a little and you get the familiar ratcheted clicks; flick it hard and it shifts into free-spin mode, flying to the bottom of the page in one motion.

The switch happens automatically based on rotation speed. If you want to lock one mode, the button above the wheel toggles between ratcheted and free-spin explicitly.

The place this pays off most is moving up and down long files — code, long articles, deep spreadsheets. On the 2S I worked around it by holding Shift and tapping a button, or by keeping a second mouse on the desk for free-spinning. On the 3, one wheel covers both jobs.

A thumb wheel you can actually roll

Functionally it is the same “dedicated horizontal-scroll wheel” as on the 2S, but the larger shape lets the pad of the thumb sit on it comfortably.

Horizontal pans in Excel, canvas panning in Figma, scrubbing a video timeline — already comfortable on the 2S, now resolved with even less finger travel. Rolling the main wheel and the thumb wheel at the same time gives you simultaneous two-axis scrolling, and that is hard to go back from once it sinks in.

Charging is USB Type-C

The single biggest weak point of the 2S, gone. I almost wrote “charging only happens every two or three months, so it does not really matter” and then deleted it — being able to keep a single cable type on the desk turns out to matter more than the charge interval would suggest.

Battery life

Logitech lists 70 days. In actual use, charging every two or three months has been enough. After a full charge it feels the same as a freshly charged 2S.

What didn’t

Short answer: still full-size only, still on the expensive side, and the gesture button is “somewhat better” than the 2S rather than “fixed”.

No size options

The 3, like the 2S, comes in a single full size. For smaller hands it is still a large mouse.

If a smaller body matters more than the thumb wheel, the MX Anywhere 3 is the other Logicool option. The Anywhere 3 has the MagSpeed main wheel but no thumb wheel — so the “horizontal scrolling is great” part of this review does not apply.

Price stayed high

Around 13,000 yen at the time of writing. Whether the deltas from the 2S — Type-C, MagSpeed, the larger thumb wheel — justify that depends almost entirely on how much horizontal scrolling you do in a day.

For someone in Excel, Figma, or a video editor every day, the payback comes quickly. For browsing-heavy use, a used 2S or waiting for the 3S below is often the more satisfying buy.

The gesture button is still the soft spot

In the 2S review, I wrote about the gesture button sticking in the pressed state after a hard press mid-game. The same structure carries into the 3, and the same risk exists for users who hammer it during long gaming sessions (my own unit has not reproduced it).

For gaming, a dedicated gaming mouse is still the honest recommendation.

Comparison: MX MASTER 2S vs 3 vs 3S

The three siblings, side by side.

Angle	MX MASTER 2S	MX MASTER 3	MX Master 3S
Charging	micro-USB Type-B	USB Type-C	USB Type-C
Main wheel	Mechanical (ratcheted)	MagSpeed (electromagnetic, auto switch)	MagSpeed (electromagnetic, auto switch)
Thumb wheel	Yes (narrow)	Yes (larger)	Yes (larger, same as the 3)
Sensor resolution	4000 dpi (rated)	1000 dpi (rated)	8000 dpi (rated)
Click acoustics	Standard	Standard	Quiet click
Battery (rated)	70 days	70 days	70 days
Sizes	Full-size only	Full-size only	Full-size only
Software	Logicool Options	Logicool Options / Options+	Logi Options+
Released	2017	2019	2022

For a fresh purchase, the 3S is the easiest recommendation. If the price gap is large enough on a clearance 3, the 3 still holds up. The 2S is hard to find new in 2026; if you want USB Type-C, skip it.

The software (Logicool Options / Logi Options+)

The companion app remaps every button and tunes wheel sensitivity. At the time of writing it was Logicool Options; in 2026 it has been replaced by Logi Options+.

The mouse view changes each button’s action. The thumb wheel accepts horizontal scroll, next/previous, volume, tab switching, and more.

The gesture button can carry four directional actions on top of its press. I do not use it heavily, so mine is set to Enter.

Pointer speed, thumb-wheel sensitivity, and scroll direction are all tunable in fine steps. Per-app tuning works too — for example, dialling down the scroll distance just for Excel.

FAQ

Q. Does it work with a Mac? A. Yes. Logi Options+ has a Mac build. It pairs over Bluetooth or the USB receiver, and macOS-specific gestures (Mission Control and similar) can be assigned.

Q. Is it worth upgrading from the MX MASTER 2S? A. The two big wins are USB Type-C charging and the MagSpeed wheel’s free-spin. If you do a lot of horizontal scrolling, the upgrade is worth it. If you mostly browse and the micro-USB port on the 2S does not bother you, there is no urgency.

Q. Now that the MX Master 3S exists, is there a reason to buy the 3? A. If the street-price gap is clearly in the 3’s favor, yes. The 3S’s main improvements are sensor resolution (1000 → 8000 dpi) and quieter clicks; the horizontal-scrolling and thumb-wheel feel are the same as on the 3. Pick the 3S if quiet offices or late-night sessions matter to you. Pick the 3 if price matters more.

Q. How usable are the gestures? A. Holding the thumb gesture button while flicking the mouse up, down, left, or right triggers a configurable action in each direction. It is genuinely handy for Mission Control and virtual-desktop switching, but the press feel is unusual and it took me a few days to get used to. In the end I drifted away from gestures and settled on a single-press action (Enter).

Verdict — pays off if you do horizontal scrolling every day

Short answer: the natural sequel to the 2S. USB Type-C closes the most painful gap, and the main wheel jumps a tier with MagSpeed. For a new purchase, lean 3S; for a price-led decision, the 3 is still a fine pick.

If you live in Excel, Figma, or a code editor and move around the screen on both axes, the price comes back in saved time within a few months. If you mostly browse, have smaller hands, or care most about quiet clicks — pick whichever of those applies and look at the 3S or the Anywhere 3 instead.

For the sibling review, see the MX MASTER 2S.

Vue.js basics — a working engineer's guide to the file structure and lifecycle

Fri, 02 Apr 2021 00:00:00 GMT

2026-05-16 update: This post is a few years old. It’s written against Vue 2 + the Options API — the data() { return ... } + methods: {} style. The current mainstream in 2026 is Vue 3 + the Composition API (<script setup> with ref / reactive / computed), and lifecycle hooks are functions like onMounted / onUnmounted. The skeleton — the three-block structure and the created-vs-mounted distinction — still holds, but the code itself isn’t something you’d drop into a new project as-is.

I’ve been working with Vue.js for over a year now. This post is the bare-bones basics of Vue.js, with a bit of working experience folded in.

The takeaway

A Vue file puts HTML, JavaScript, and CSS in a single file
The three-block structure — template / script / style — is enough to get started
In the script block, the first thing to learn is data, methods, and the lifecycle
For the lifecycle, mainly learn the distinction between created and mounted

Understand the structure of a Vue file

The first thing to understand the structure of a Vue file. A Vue file holds all three languages:

HTML
JavaScript
CSS

It looks like this:

<template>
  <div>
    html記述
  </div>
</template>

<script>
  export default {
    name: "XXX",
    data() {
      return {
        xxx: yyy
      }
    }
  }
</script>

<style lang="css">

</style>

Each language can be split out into its own file, but I’ll skip that here.
The script and style blocks can be swapped for other languages.

I usually go with TypeScript for script and SCSS or Stylus for style.

Write HTML in the template block

This is where you write HTML in the template block.

It’s mostly the same as plain HTML, with a few Vue-specific additions.

I’ll cover the Vue-specific bits in a separate post.

Write data and methods in the script block

This is where the JavaScript side lives. The entry point is to write data and methods in the script block.

I’ll use plain JavaScript for the examples here.

The base shape:

export default {
  data() {
    return {
      xxx: "yyy"
    }
  },

  methods: {
    hogeMethod(str) {
      return str
    },
    hugaMethod() {
      let test = this.xxx;
      test = this.hogeMethod(test);
      return test;
    }
  }
}

data is where you declare and initialise variables that are available inside the Vue file.
It’s used a lot when you want to render processed data into the HTML.

Note: you’re returning an object literal here.

methods is just a place for regular functions.

To reference a variable or function defined in the same file, prefix it with this.
Local variables inside the same function don’t need this..

The relevant part:

hugaMethod() {
  let test = this.xxx;
  test = this.hogeMethod(test);
  return test;
}

Use lifecycle hooks to control timing

The lifecycle is the trickiest part of this post. Read it with this in mind: use lifecycle hooks to control timing.
The official reference is here:

Vue.js docs: lifecycle diagram

The lifetime of a Vue file — from load to teardown — is divided into 8 points, and you can hook JavaScript into each one.

The eight points:

beforeCreate — before instance creation
created — after instance creation
beforeMount — before mount
mounted — after mount
beforeUpdate — before update
updated — after update
beforeDestroy — before teardown
destroyed — after teardown

In code:

export default {
  data() {},
  beforeCreate() {},
  created() {},
  beforeMount() {},
  mounted() {},
  beforeUpdate() {},
  updated() {},
  beforeDestroy() {},
  destroyed() {},
  methods: {}
}

The two you’ll actually use most are created and mounted.
The difference between them is when the DOM is loaded.

created runs before the DOM is loaded
mounted runs after the DOM is loaded

The rough rule: use created for script-side initialisation and mounted for anything that touches the HTML.

Write CSS in the style block

The CSS lives here — write CSS in the style block.
The syntax is plain CSS, so there’s nothing new to learn.

.display-flex {
  display: flex;
}

Closing

That covers the bare basics of Vue.js.

The main acts — Components and Binding — are in separate posts.

Related posts:

Angular vs Vue.js — what a year of using both in production actually felt like

Wed, 31 Mar 2021 00:00:00 GMT

2026 update: Originally written in 2021, when Vue 2 and Angular 11 were the mainstream versions. Today the defaults are Vue 3 (Composition API, <script setup>) and Angular 17+ (Signals, standalone components, the new control-flow syntax), and Vue’s TypeScript story has improved a lot. The overall framing — Angular as batteries-included, Vue as minimal — still mostly holds, but the code samples and APIs here are from the original version and don’t match current behavior exactly.

There are three JavaScript frameworks people usually mention in the same breath, and I’ve shipped production work in two of them. React isn’t one of them, so this post is just about Angular and Vue.js, and how they actually differ when you use them day-to-day.

The short version

Angular
- Batteries included
- Strict syntax conventions
Vue.js
- Minimal core
- Loose, flexible conventions

Angular

Overview

Angular is the framework Google maintains. The v1 line was called AngularJS; from v2 onward it’s just Angular. Google has said major versions ship roughly every six months, and that major versions don’t guarantee backwards compatibility — worth keeping in mind.

In practice, upgrades on the projects I worked on were less painful than that warning suggested.

The two things that stood out to me:

It’s a full-stack framework
TypeScript by default

Full-stack framework

Angular ships with routing and other common pieces out of the box. Install it and you basically have a working project skeleton. Looking things up is also easier because the official docs cover most of what you need.

A component’s folder layout looks like this:

component
  ├── component.ts
  ├── component.html
  ├── component.css
  └── component.spec.ts

Keeping the languages in separate files inside one folder makes the code easier to manage at scale.

The downside of “batteries included” is that you carry code you don’t necessarily use, and that has a real performance cost.

TypeScript

Angular’s recommended language is TypeScript. TypeScript is a Microsoft project, so you end up with a Google framework written in a Microsoft language — which on paper is a pretty solid combination.

Static typing makes the code feel tight, in a good way. But for anyone new to TypeScript, you’re effectively learning two things at once, and the ramp-up is steep.

When I’d reach for Angular

The conventional wisdom is that Angular fits large projects, and my experience matches that.

The strict structure and conventions — for better or worse — meant handoffs and parallel work between team members went smoothly. The trade-off is the learning cost: plan extra time at the start of any handoff for people to get comfortable with the framework.

Vue.js

Overview

Vue.js is community-developed and has been picking up adoption steadily. The two things that stood out to me:

A minimal core
Flexibility

Minimal core

Unlike Angular, Vue doesn’t bundle routing and other extras by default. You install the libraries you need separately. Vue CLI makes that pretty painless.

A component is a single file:

component
  └── component.vue

Very simple. HTML, JS, and CSS all live inside the .vue file.

You can split JS and CSS into separate files if you want:

component
  ├── component.vue
  ├── component.js
  └── component.css

The split is manual, though — there’s no automatic separation.

The flip side of a minimal core is that you have to find and pick libraries yourself. The upside is the bundle stays light, and performance is good by default.

Flexibility

Vue defaults to plain JavaScript. TypeScript works too, but setting it up properly used to take some effort (current note: Vue 3 with <script setup> has improved TypeScript support significantly, and as of 2026 the setup is no longer the same hassle it was).

The key difference from Angular is how much room Vue gives you. You can shape a project to fit the team’s skill level and the use case — that flexibility is genuinely useful.

You’ll need to do more of your own research, but the barrier to entry is clearly lower.

When I’d reach for Vue

Vue fits anything that isn’t a strict programmer-and-designer split with formal handoffs.

The catch: document your library choices, your project structure, and the build setup. The flexibility that makes Vue pleasant in solo work becomes a maintenance burden in a team if nothing is written down. For company projects, I’d strongly recommend setting up a formatter and a style guide on day one.

For personal projects, Vue.js is hard to beat.

Wrap-up

That’s the comparison, with my own bias from working in both.

If you forced me to pick one, I’d go with Vue.js plus TypeScript. The setup takes some patience, but the readability and the resulting code are worth it.

YAMAHA TW-E3A review — a year of commuting with YAMAHA's honest, even-handed true wireless

Tue, 30 Mar 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The TW-E3A is an older model in 2026, with successors like the TW-E3B and TW-E3C now on sale. The review angles here (the honest tuning, the fit, the physical-button quirks) still hold up. Spec numbers are based on the manufacturer’s published figures at the time of writing.

I used the YAMAHA TW-E3A true wireless earbuds for about a year of daily commuting. This is the write-up of what showed up — strengths and weaknesses — once they were folded into the rhythm of regular use.

The review is framed around the fact that the TW-E3A was YAMAHA’s first true wireless earbud. So instead of grading it head-to-head against the latest competition, I focus on whether it fits its price band and intended use.

The verdict — for listeners who want tuning without a personality

Short answer: the sound follows YAMAHA’s tuning brief without unnecessary flavor, and the fit is stable enough for a commute. The deep physical-button press, and the way the controls are split across left and right, are the parts that will pick their audience.

The reason is simple. The TW-E3A does not chase a single headline trait — no thumping bass, no aggressive noise cancellation. Instead it settles into a balance that does not tire the ear over long sessions. The design leans toward background listening during a commute or while working, rather than dedicated music-appreciation sessions.

That said, you should probably look elsewhere if any of these apply:

You’re used to touch controls or multi-button setups: the TW-E3A funnels every function through a single physical button on each side
You need active noise cancellation: the TW-E3A does not have ANC (based on the manufacturer’s spec sheet)
You want to use them for hard workouts: the fit is secure, but there are no sport fins for high-impact movement

Build and feel

Short answer: the case is a small rectangle, roughly the size of a miniature bento box, that slips into a chest pocket. The earbuds themselves are slightly elongated and sit deep in the ear.

The lid carries a matte YAMAHA wordmark. The finish does not pick up fingerprints easily.

The case measures roughly 70 × 35 × 35 mm (manufacturer’s published figures). That is compact for its price band, and it fits cleanly into a jacket’s chest pocket.

The lid pops open with a light push and falls shut under its own weight, locking with a small click. In a year of bag-carrying it never opened on its own.

The nozzle is long. Once seated, it sits about as deep as the first knuckle of an index finger, which is what gives the fit its security. The R / L marks are embossed on the inside of each shell, so you can tell them apart by feel in the dark.

On its own, each bud reads as slightly elongated. Each side weighs 6.3 g (manufacturer’s published figures).

The back of the case carries a USB Type-C port and a charge-status LED. USB-C was not a given on early-2021 models, and in 2026 it is still useful for keeping one cable type across devices.

What worked

Short answer: honest tuning, a fit that holds up at commute intensity, and a stable Bluetooth 5.0 link.

YAMAHA’s flat, low-fatigue tuning

The tuning does not push the low end and does not sharpen the upper mids. Vocals and acoustic instruments come through naturally; genres that lean on a forward low end — EDM, for example — can feel underweight to some listeners.

Two- or three-hour sessions stay comfortable, which is the practical payoff of that tuning choice.

Stays in for commutes and walking

The deep nozzle keeps the bud seated through the shoves of a packed train or a short jog. Across a year of daily use, neither side ever fell out.

There are no sport fins in the box, though, so for the gym or longer runs it is worth looking at a model built for that.

Bluetooth 5.0 holds up in crowded RF

With Bluetooth 5.0 (based on the manufacturer’s spec sheet), the link stayed clean inside busy stations and trains where RF gets congested. Dropouts and single-ear lockouts were rare. Compared to the 4.x-era buds I used at the same price point, the stability is clearly a step up.

What didn’t

Short answer: the buttons need a firm press, the controls are split across the two sides, and there is no ANC.

Buttons want a deep press

These are physical buttons rather than touch sensors. That cuts down on accidental taps, but the TW-E3A’s travel is on the deep side. To register a press you end up pushing the bud further into the ear, and each time you do, the seal shifts.

A touch sensor — or even just a lighter actuation — would have been easier to live with.

Left and right do different things, and it’s hard to memorize

Because there is only one button per side, playback, volume, and track skipping are spread across the two sides by click count.

Action	Mapping
Play / pause	Either side, single click
Volume up	Right, double click
Volume down	Left, double click
Next track	Right, long press
Previous track	Left, long press

If “volume on the right, track skip on the right” had been the rule, the mapping would have stayed intuitive by direction. As it stands you have to memorize the chart. For someone who only touches the controls a few times a day, that is more friction than it should be.

No active noise cancellation

The canal-type fit gives you some passive isolation, but there is no active NC (based on the manufacturer’s spec sheet). If your goal is to flatten out rail noise or HVAC drone, this is not the right pick.

Comparison — where the TW-E3A sits in mid-range true wireless

Short answer: if you care about even-handed tuning and a secure fit, it competes well at this price. If ANC or rich touch controls are non-negotiable, look elsewhere.

Angle	YAMAHA TW-E3A	Typical mid-range peers	YAMAHA’s higher tier (TW-E5B / E7B family)
Tuning	Flat, low-fatigue	Often bass-forward	Listening-focused, bass with detail
Active noise cancellation	None	Increasingly common	Available on some models
Controls	One physical button per side	Touch is the norm	Touch plus companion app
Connection	Bluetooth 5.0	5.0 to 5.3	5.2 and up is common
Charging port	USB Type-C	Mostly USB-C now	USB Type-C
Bud-only playback	~6 hours (rated)	5 to 8 hours	6 to 10 hours (rated)

If you are buying new and you specifically want the YAMAHA house sound, the more natural move is to compare the TW-E5B / E7B siblings as well. Conversely, on the second-hand or clearance market, where the TW-E3A turns up cheap, its solid baseline of tuning and fit still earns it a place.

FAQ

Q. Will it pair without issues on both iPhone and Android? A. Any Bluetooth 5.0 host is fine in practice. There is no multipoint support (based on the manufacturer’s spec sheet), so it is not a good fit for someone who switches between a PC and a phone all day. Treat it as a single-device companion, or expect to re-pair each time.

Q. How long does the battery last? A. The published figures are around 6 hours on a charge and roughly 24 hours including the case (manufacturer’s published figures). With a one-hour commute each way, the case lands back on the dock about once every three or four weekdays.

Q. Is it usable for remote-work video calls? A. There is a built-in mic and calls work, but the noise reduction is not what you would expect from a dedicated headset (based on the manufacturer’s spec sheet). It is fine for a 1:1 from a quiet home; for calls in a cafe or an open office, a real headset is the safer bet.

Q. Does it hold up for running or light workouts? A. The deep nozzle keeps it secure through short jogs on a commute. Heavy vertical motion during running, or sweat-heavy gym sessions, are outside what it was built for, and long-term sweat resistance is not guaranteed (check the manufacturer’s IP rating). For serious training, use something built for it.

Verdict — for daily listening with YAMAHA’s tuning

Short answer: not a model that sells on flash. It earns its keep through the quiet quality of the tuning and the fit, which is the kind of thing you only notice after weeks of use. The cleanest way to read it: a first-generation product that did not try to do too much.

The two things to weigh are the button feel and the awkward control mapping. If a store has a demo unit, putting them in and running through the left-right controls before deciding will save regret later. If you are also weighing newer generations, look at the higher-tier models and the successor lineup (ANC, multipoint, touch controls) at the same time — the decision gets less wobbly with that context.

Anker PowerCore 10000 review — two or three phone charges in a palm-sized power bank

Mon, 29 Mar 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The PowerCore 10000 is an older model in 2026 — the current line has moved to USB Type-C I/O in the newer PowerCore series. The framing here (how to weigh capacity, size, and ports in the 10000mAh class) still applies.

I used the Anker PowerCore 10000 as my main mobile battery for several years, carried for the usual reason — a backup against a dead phone outside the house. The 10000mAh class strikes a workable balance between “two or three phone charges” and “small enough to carry”, which makes it an easy first battery to land on.

The I/O ports, though, are this generation’s weak spot. From a 2026 vantage point, I want to write down which parts still hold up and which parts I would no longer pick.

The verdict — a solid default for size-vs-capacity, but the ports are dated

Short answer: fitting 10000mAh into a pocketable shell still earns the recommendation. The charging behaviour is steady in the way Anker batteries usually are, which makes it easy to trust as an outing backup. The catch is the USB Type-A input and micro-B output — that pairing does not match the cables most people already carry in 2026.

The reason is simple: phones, laptops, and wireless earbuds have been converging on USB Type-C. For anyone trying to standardise on a single Type-C cable, packing a dedicated micro-B cable just for this one battery is hard to justify.

A few cautions before buying:

You want to standardise on USB Type-C cables: a Type-C version of the same series is the cleaner choice
You want to charge a laptop with PD (Power Delivery): this unit tops out at USB-A / 2.4A and does not support laptop fast-charge
You are buying brand new: the current Type-C successor will keep working with the rest of your gear for longer

Look and size

Short answer: compact for a 10000mAh battery. Anker traded height for thickness, so it still slips into a jeans pocket.

The shell is matte black, the same finish Anker uses across the mobile battery range, and it hides fingerprints and minor scuffs well.

Stated specs are below (source: as printed on the packaging).

Spec	Value
Size	~92 x 60 x 22mm
Weight	~180g
Capacity	10000mAh
Output	Up to 2.4A (PowerIQ)
Input port	USB Type-A
Output port	micro-B

180g is about average for the 10000mAh class. The short height means it sits well in a closed hand.

The battery charges over USB Type-A and outputs over micro-B. At the time of writing (2021), USB Type-A was the default everywhere. In 2026 the layout reads as an older generation.

The power button is on the side. A single press lights four blue LEDs that show the remaining charge. Plug in a phone, press the button, and it starts pushing power — there is nothing to think about.

What worked

Short answer: Anker’s reliable charging behaviour and a genuinely pocketable 10000mAh form factor.

The charging behaviour is steady

I have owned several Anker batteries and never run into power cutting out mid-charge or the device failing to register. For a battery that gets plugged and unplugged constantly throughout the day, that kind of quiet reliability matters more than a spec sheet.

Anker’s own PowerIQ (current adjustment based on the connected device) seems to do its job within the 2.4A range — though this is based on day-to-day use rather than measured output.

Pocketable for a 10000mAh battery

10000mAh covers about two to three phone charges, or just under one full tablet charge. Fitting that into a pocketable shape was the headline at launch and still is.

On a day out without a bag, it goes in a jacket or back pocket and lasts the day.

Four-LED battery indicator, no fuss

One button press, four LEDs. There is no app, no Bluetooth pairing — and as a result, no ambiguity about how much is left. It is hard to walk out the door with a battery you thought was full but wasn’t.

What didn’t

Short answer: USB Type-A / micro-B ports, no PD support, and slow input charging.

USB Type-A / micro-B I/O

Normal in 2021, a clear weakness in 2026. If your cable kit is already standardised on USB Type-C, carrying a micro-B cable just for this one battery starts to feel like overhead.

For a new purchase I would point people at the Type-C version of the same line (PowerCore III 10000 or similar).

No USB PD

The output is a single USB-A port at up to 2.4A — no USB Power Delivery (PD).

That rules out fast-charging a recent phone, or driving a laptop or tablet at any useful speed. As a topping-up battery for a phone it is still fine.

Slow to refill itself

Charging the battery itself is over micro-B, and even on the bundled wall adapter, it feels slow to reach full.

Plug it in before bed and it is ready in the morning, which is the usual pattern. As a “top up just before leaving” battery, it is not the right tool.

Comparison: choosing in the 10000mAh class

10000mAh is the capacity most people land on for a first battery. A short way to compare options inside that class:

Angle	PowerCore 10000 (this unit)	Type-C PowerCore successor	20000mAh class
Ports	USB-A / micro-B	USB-C in/out	Varies by model
Weight	~180g	~190g (rated)	~350g
Capacity	10000mAh	10000mAh	20000mAh
Best for	2–3 phone charges	Phone + light tablet	Phone + laptop
Launch price (at time of writing)	~2,500–3,500 yen	~3,500–5,000 yen	~5,000–8,000 yen

The decision is short: “do I want everything on Type-C?” and “do I need to charge a laptop?” Two no’s and this class is enough. One yes and a different model fits better.

FAQ

Q. Does it work with both iPhone and Android? A. Yes. The output is USB Type-A, so as long as you carry the right cable for your device (Lightning / USB-C / micro-B), either side works. There is one USB-A output port on the battery.

Q. Can I take it on a plane? A. Carry-on, yes. 10000mAh works out to roughly 37Wh, comfortably under the 100Wh limit major airlines apply (airlines and routes vary, check the current rules for your specific flight). Checked baggage is not allowed.

Q. How many times can it charge a phone? A. Depends on the phone’s battery and charging losses, but for a 3000–4000mAh phone, two to three full charges is the practical figure. The four-LED indicator gives you a rough sense of what’s left as you go.

Q. Can it charge a laptop? A. Not really. The output is USB-A at 2.4A with no USB PD, so it does not meet the fast-charge requirements of most laptops. For a laptop, look at a PD-capable battery with at least 30W output.

Verdict — still usable as a first battery, but a successor is the smarter new purchase

As a default in the 10000mAh class, it is still easy to live with. Anker’s steady charging behaviour and the palm-sized shell make it a quiet, dependable backup when leaving the house.

For a fresh purchase in 2026, though, the Type-C versions of the current line will hurt less in the long run, simply because everything else you carry is already on Type-C.

If you already own a PowerCore 10000, there is no reason to retire it — keep a micro-B cable in the bag and carry on. When it does come time to replace it, the Type-C successor is the obvious next stop.

How to pick a Windows laptop for programming — 16 GB RAM and Core i5 / Ryzen 5 are the realistic floor

Sun, 28 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The framework still holds, but the CPU generations and prices are pinned to when this was written. Confirm current generations and stock before you buy.

The first thing that trips people up when starting to learn programming is picking the laptop. Which numbers on the spec sheet matter, and how far is it worth spending before the extra money stops paying off — it’s hard to tell.

This piece lays out the spec criteria for buying a Windows laptop, assuming web-focused learning, a side project, or a career change. For readers torn between this and a MacBook, there’s a comparison table further down.

The short answer — 16 GB RAM, Core i5 / Ryzen 5 or better, around 100,000 yen

Short version: for learning or side-project use, pick a model that clears 16 GB RAM, Core i5 (11th gen or newer) or Ryzen 5 (4th gen or newer), 512 GB SSD. The price band is around 100,000 yen.

Two reasons:

The moment you have an IDE, a browser, and Docker or a VM running together, 8 GB is cramped. 16 GB carries you a few years
A mid-tier CPU (i5 / Ryzen 5) handles IDE builds and test runs without felt stress

Going beyond i7 / Ryzen 7 or 32 GB of RAM is overkill unless you’re also doing machine learning or video editing. The cost-to-benefit drops off.

If you’re a MacBook person, there’s a separate piece for that.

How to pick a MacBook for programming

Use 16 GB of RAM as the baseline

Short version: 16 GB. 8 GB works at the very start of learning, but you hit the ceiling within six months to a year.

The things that eat RAM while you code:

IDE (VS Code, IntelliJ, and so on) — several GB once extensions are in
Browser tabs — a dozen-plus is normal while developing
Docker / VMs — a few hundred MB per container, upward
Local DB / dev server — running alongside everything else

Run those in parallel and 8 GB is gone. Once swap kicks in it eats at SSD lifespan too, so putting 16 GB in from day one is cheaper in the end.

When 32 GB is warranted

If you’re also doing machine learning, large-scale data processing, or video editing, go to 32 GB. For plain web development or Android-leaning mobile work, 16 GB is enough.

Core i5 / Ryzen 5 or better — and check the generation

Short version: pick a mid-tier (i5 / Ryzen 5) chip from a recent generation. The generation gap matters more than the tier gap, in feel.

Realistic floor for laptop CPUs (as of 2021):

Intel: 11th-gen Core i5 or newer
AMD: Ryzen 5 4th gen (5000 series) or newer

By 2026 the generations have moved on, so as long as you stay within the latest two generations at purchase, you won’t go wrong.

Choosing between i5 and Ryzen 5

For programming use, the felt difference is close to zero. Rules of thumb:

More cores at the same price → Ryzen 5
Better battery life and power efficiency → Intel Core i5
Enterprise support and stable stock → Intel Core i5

i7 / Ryzen 7 and above belong to the “also doing ML or video editing” bucket. For programming alone, the upside is thin.

Picks by use case — learning, side project, machine learning

Short version: the three patterns differ a lot. Price bands and required specs are not interchangeable.

Learning (Progate / Udemy → portfolio work)

CPU: Core i5 / Ryzen 5 (mid)
RAM: 16 GB
SSD: 512 GB
GPU: integrated is enough
Price target: 80,000–100,000 yen

This is plenty for a first machine. Outgoing-model and direct-sales outlets can knock another 20,000–30,000 yen off.

Side project / career change (closer to real work, running Docker and VMs)

CPU: Core i5 / Ryzen 5 (recent mid-tier)
RAM: 16 GB (ideally a model you can later upgrade to 32 GB)
SSD: 512 GB to 1 TB
GPU: integrated is enough
Price target: 100,000–130,000 yen

You’ll start running Docker, multiple VMs, and a local DB at the same time. Confirm whether RAM is upgradeable.

Machine learning (training locally)

CPU: Core i7 / Ryzen 7
RAM: 32 GB or more
SSD: 1 TB
GPU: NVIDIA GeForce RTX class (8 GB VRAM or more)
Price target: 150,000 to over 250,000 yen

Honestly, finishing everything on a laptop is rough. Once the training workload passes a certain size, it’s more realistic to plan around cloud GPU from the start.

Comparison — Windows laptop, MacBook, Linux laptop

Short version: at equivalent specs for web or backend work, Windows is the cheapest. If you want Apple Silicon’s power efficiency, MacBook. If you want the hardware to be your dev environment, a Linux laptop.

Aspect	Windows laptop	MacBook (Apple Silicon)	Linux laptop (ThinkPad and so on)
Price at equivalent specs	Cheapest (baseline)	+20,000–30,000 yen	On par with Windows
Dev environment setup	WSL2 covers most	Native (UNIX-like macOS)	Native, straightforward
iOS / macOS development	No (Xcode won’t run)	Yes	No
Battery / quietness	Depends on the model	Strong	Depends on the model
Expandability / repair	Easier (model dependent)	Harder	Easier
Machine learning (GPU)	NVIDIA-equipped models available	Via MPS / Metal (limited)	NVIDIA-equipped models available
Learning resources	Plenty (workplaces run Windows)	Plenty	Fewer

Unless iOS development is on the table, Windows is a safe pick. If you want a native Linux experience, a ThinkPad or Dell XPS with Ubuntu installed is the steady choice.

Adding a monitor pays off more than upgrading the laptop

Adding a single external monitor moves the needle on day-to-day work more than bumping the laptop one tier. Whether you can lay out code next to a browser (preview, docs) feeds directly into productivity.

For lightweight picks aimed at writing away from home, there’s a separate piece.

FAQ

Q. Is 8 GB of RAM enough for programming? A. For learning or small personal projects, 8 GB will run. The moment you bring up an IDE, a browser with lots of tabs, and Docker or a VM at the same time, it gets tight fast. Unless you plan to upgrade soon anyway, picking 16 GB from the start is cheaper in the long run.

Q. MacBook or Windows for programming? A. If you’re not building iOS apps, either works. At equivalent specs Windows runs 20,000–30,000 yen cheaper, and WSL2 covers most Linux-side development just fine. It’s a choice between Apple Silicon’s power efficiency and Windows’ price and expandability.

Q. Core i5 or Ryzen 5 — which should I pick? A. For programming use, the felt difference is negligible. At the same price, Ryzen 5 usually wins on core count, while Intel tends to be steadier on battery life and power efficiency. Decide on price, stock, and battery requirements.

Q. What kind of build do I need for machine learning? A. If you want to train locally, the realistic floor is an NVIDIA GPU (8 GB VRAM or more) plus 32 GB of RAM. If you’re serious about it, paying for cloud GPU (Colab, RunPod, and so on) ends up cheaper. I wouldn’t recommend trying to finish everything on a laptop.

Wrapping up

For a programming Windows laptop, 16 GB RAM, Core i5 / Ryzen 5 or better, 512 GB SSD, around 100,000 yen is hard to go wrong with. Past that line, the call comes down to whether you also need machine learning or video editing.

If you’re torn between this and a MacBook, the dividing line is iOS development. If you’re not doing it, Windows at the same specs for 20,000–30,000 yen less is plenty.

If the budget can stretch to an external monitor, buying one is a bigger felt jump than bumping the laptop itself a tier.

How to pick a MacBook for programming — the Air covers most cases; reach for the Pro if you're doing ML or iOS

Sat, 27 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog and rewritten end to end. The Intel-era framing has been re-anchored to Apple Silicon (M1–M4). Always confirm current pricing and specs against Apple’s official site or a major retailer before you buy.

When you walk into the Mac aisle to start programming, you find the Air, the Pro 14, and the Pro 16 side by side, and within each model the CPU, RAM, and SSD permutations move the price by tens of thousands of yen each. Putting 400,000 yen on the table for your first machine is a lot.

This piece narrows the question to one use case — learning to code and doing the day-job — and walks through how to pick an Apple Silicon MacBook for it. The short version: most people will be fine on the Air.

If you’re also weighing a Windows laptop, How to pick a Windows laptop for programming covers that side. If your main job on the machine is blog writing, How to pick a MacBook for blogging is the better read.

The short answer — Air for web and mobile, Pro for ML or serious iOS

Short version: for learning to program and for most web and mobile app development, a MacBook Air (M-series, 16 GB RAM) is enough. The Pro earns its keep in three places: machine learning that wants a lot of unified memory, iOS development with long Xcode build loops, and setups driving two or more external monitors.

Three decisions, nothing more:

What you’ll build — web or mobile, Air; ML or heavy iOS work, Pro
RAM — 16 GB as the baseline; 24 GB or 32 GB if you’re learning and working on the same machine or have ML in mind
Screen and expansion — Pro 14 or 16 if multiple external monitors are part of your daily setup

Put differently: the 8 GB tier paired with a 256 GB SSD is the combination to avoid for modern programming work — dependencies and simulators fill the SSD faster than you’d expect.

By use case — web, mobile, and ML pull in different directions

Short version: don’t lump “programming” into one bucket. Split by what you actually write — web, mobile, ML — because the resource demands diverge.

Web and backend — the Air is enough

Node, Python, Go on the backend; React or Vue on the front — none of this strains a MacBook Air. With 16 GB of RAM, you can run a handful of Docker containers and still have headroom for learning through small-scale day-job work.

For the typical setup — VS Code, a browser, a terminal, one or two containers — the Air’s cooling is fine, and you won’t hear the fan often.

Mobile — Pro 14 is the safe call for iOS; Android is fine on the Air

Android Studio runs on the Air, but the emulator chews through RAM the moment you launch it. Treat 16 GB as the floor.

For iOS (Xcode), the Air handles development too — for learning, you won’t be blocked. For a real job that has you running builds all day, the Pro 14’s cooling and SoC headroom translate into perceptible speed. If you’re plugging in multiple physical devices and running long, continuous builds, lean Pro.

Machine learning — Pro 14 or 16 with a lot of unified memory

For local inference or fine-tuning experiments, Apple Silicon’s unified memory (shared between CPU and GPU) gets used as GPU memory. That’s the platform’s edge: a Pro at 24 GB, 32 GB, or 64 GB can run on-device models that a same-price Windows laptop’s discrete GPU can’t load.

Serious training (fine-tuning workloads of any size) is more realistic on cloud GPUs. Treat the MacBook as the inference and prototyping machine.

Realistic RAM and CPU targets

Short version: start at 16 GB for RAM, and think of the CPU (SoC) tiers as Air = base M, Pro 14 = M Pro, Pro 16 = M Pro / M Max.

RAM — skip 8 GB in 2026; baseline is 16 GB

Apple Silicon at 8 GB holds up better than Intel-era 8 GB did. But in 2026, with a browser, an editor, containers, and chat apps all resident, 8 GB swaps daily.

Learning only, light loads: 16 GB
Day job plus learning: 16–24 GB
Serious ML, iOS, or video work alongside: 32 GB or more

RAM is set at order time — Apple Silicon has it soldered on, no upgrade path. When in doubt, take the next tier up; you regret it less.

CPU (SoC) — the Air’s base M covers most of the work

The base M has, generation over generation, pulled ahead of Intel-era i7. For ordinary web and mobile work, you won’t feel a CPU ceiling on the base M.

The M Pro and M Max pull away under sustained full load — video exports, large builds, ML training. For short builds and IDE work, the gap between Air and Pro is hard to feel.

Comparison — Air vs. Pro 14 vs. Pro 16 (for programming)

Aspect	MacBook Air	MacBook Pro 14	MacBook Pro 16
Use case	Web / mobile learning and work	iOS / ML / mixed video work	Long builds, multiple external monitors
SoC	Base M	M Pro / M Max	M Pro / M Max
RAM recommended	16 GB	18–24 GB	24–32 GB or more
SSD recommended	512 GB or more	512 GB or more	1 TB or more
Display	13 / 15 inch	14-inch ProMotion	16-inch ProMotion
External monitors	1–2 max (generation-dependent)	Multiple	Multiple
Cooling	Fanless (through M3) / quiet	Active	Active
Weight	~1.2–1.5 kg	~1.6 kg	~2.1 kg
Price range	150,000–250,000 yen	250,000–400,000 yen	350,000–600,000 yen

Pricing and specs shift with each generation; confirm against Apple’s official site at purchase time.

FAQ

Q. Should I pick 8 GB or 16 GB of RAM? A. In 2026, treat 16 GB as the floor. Apple Silicon at 8 GB holds up better than Intel-era 8 GB did, but the moment you run Docker, a VM, and a stack of browser tabs in parallel, you start swapping. If you plan to keep the machine for a while, 16 GB or more is the safer call.

Q. Can I do iOS app development on a MacBook Air? A. Yes. Xcode runs fine on the Air. That said, if your day is the simulator-and-device-build loop on a real job, the Pro’s active cooling shows up as perceptible speed in places the Air starts to throttle.

Q. Is a MacBook enough for machine learning? A. If you’re serious about local inference or running local LLMs, a Pro 14 or 16 with a lot of unified memory is the realistic choice. The Air is fine to learn on, but for actual workloads, pair it with cloud GPUs rather than trying to do it all on-device.

Q. Windows or MacBook for programming? A. If your work involves macOS, iOS, or any Apple-platform development, it’s MacBook, full stop. For web or backend work, Windows + WSL2 is enough. At the same price, Windows gives you more spec on paper, but the MacBook wins on dev-environment ergonomics and second-hand resale. See How to pick a Windows laptop for programming for the other side.

Wrapping up

For a programming MacBook, if you’re learning or working on web and mobile, an Air with 16 GB of RAM handles most of it. The Pro 14 or 16 earns its place in three situations: ML work that needs a lot of unified memory, iOS development with long build loops, and setups with multiple external monitors.

If you’re deciding where to put the price delta, the better move for the first machine is to spec the Air at 16 GB / 512 GB and spend the difference on an external monitor — that’s where day-to-day workflow actually improves.

If you’re looking at a MacBook for blog writing, How to pick a MacBook for blogging is the companion piece. If you’re comparing against Windows, How to pick a Windows laptop for programming is the other side of the question.

How to pick an iPhone 12 — viewing the first 5G-rollout-year iPhone as a buy today

Fri, 26 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. iPhone 12 was the first iPhone to ship into Japan’s 5G rollout (announced autumn 2020), and the generation where the split between mmWave models for the US and Sub-6-only models for Japan first settled into place. It is no longer a current new-product pick in 2026, but the framework still works for evaluating a used or last-gen buy. Always confirm current pricing and stock before you order. The numbers are the manufacturer’s published figures from the original writing; current official specs may differ.

The iPhone 12 has moved past the “buy it new” phase, but it is still a live option on the used and refurbished market if the goal is to own an iPhone cheaply right now. The line-up has four models — mini, standard, Pro, Pro Max — that differ in both size and camera.

This piece sorts the four on two axes: screen size and whether there’s an optical telephoto, then maps each model to a use case. If you are torn between iPhone 11 and iPhone 12, the answer flips on whether you’ll use 5G, so read through to the FAQ.

The short answer — mini or Pro; the standard and Pro Max are the middle that’s easy to get lost in

Short answer: mini if you want one-handed use, Pro line if you want telephoto and low-light. For everyone else the standard iPhone 12 is enough. The Pro Max is for people who want both a big screen and a telephoto.

Boil down the differences inside the iPhone 12 line and three points remain:

Screen size: three steps — 5.4 / 6.1 / 6.7 inches
Optical telephoto and LiDAR: Pro line only
5G mmWave: Japan-market units are all Sub-6 only

Starting from those three is faster than starting from price or storage.

What changed at the iPhone 12 generation

Short answer: 5G, OLED across the whole line-up, MagSafe, A14 Bionic, and a redesigned body. Coming from iPhone 11, the volume of change earns the “generational shift” label.

5G support (Sub-6 only in Japan)

iPhone 12 was the first 5G iPhone released in Japan. Japanese-market units are Sub-6 only; the mmWave models stayed North-America-only.

In day-to-day use, downstream speed picks up inside a 5G area, but outside one the phone falls back to 4G LTE — so “5G means fast” is not a clean shorthand. By 2026 the 5G footprint has grown, so the upside is easier to feel than it was at launch.

OLED across the entire line-up (Super Retina XDR)

On iPhone 11, the standard model used an IPS LCD and only the Pro line had OLED. From iPhone 12 onward, mini and standard included, every model is OLED, so deep blacks and HDR content became a shared baseline.

MagSafe wireless charging

A ring of magnets is built into the back, so first-party and third-party MagSafe chargers and accessories snap into place. The standard carried forward across iPhone 12 and beyond, so accessories accumulated over time keep their value.

The body returned to flat edges

A flat-edge profile that calls back to the iPhone 4 / 5 era. The feel in the hand is noticeably different from the rounded sides used up through iPhone 11. If you have smaller hands, hold one in person before buying.

Picks by use case — which one to choose

Short answer: which model fits comes down to a single priority — one-handed, telephoto, or big screen.

One-handed use — iPhone 12 mini (5.4 inches)

iPhone 12 mini is the smallest of the line at 5.4 inches. Even counting same-generation Android flagships, a size like this is rare, so if one-handed operation is the top priority, it is the only real pick.

The trade-off is the smaller battery: heavy use can leave the meter uncomfortable by evening. If you’re out and on the phone all day, lean to the standard model or above.

Telephoto, low-light, LiDAR — iPhone 12 Pro / Pro Max

Only the Pro line carries the optical telephoto camera and the LiDAR scanner. The telephoto pays off when you want a tighter frame on a still subject or shoot portraits, and LiDAR feeds directly into autofocus speed in dim rooms.

iPhone 12 Pro: 2x optical zoom
iPhone 12 Pro Max: 2.5x optical zoom + sensor-shift stabilization

If “get a little closer” is the whole request, the standard model’s digital zoom is enough. If shooting people in low light is a frequent thing, the Pro-line gap is real.

Big screen — iPhone 12 Pro Max (6.7 inches)

6.7 inches earns its keep on video and games. It is also too large to fully wrap one hand around, so you have to accept it as a two-handed device.

Everything else — iPhone 12 (standard, 6.1 inches)

If neither size nor optical telephoto is on the wish list, the standard model leaves nothing on the table. From an iPhone 11, it is the most natural upgrade path.

iPhone 12 line-up comparison

Model	Screen	Camera	Optical telephoto	LiDAR	Weight
iPhone 12 mini	5.4 in	Wide + Ultra-wide	No	No	~133 g
iPhone 12	6.1 in	Wide + Ultra-wide	No	No	~162 g
iPhone 12 Pro	6.1 in	Wide + Ultra-wide + Tele	2x	Yes	~187 g
iPhone 12 Pro Max	6.7 in	Wide + Ultra-wide + Tele	2.5x	Yes	~226 g

Spec numbers are Apple’s published figures. Weight is the published value, not a case-off measurement.

iPhone 11 or iPhone 12 — which one to buy

Short answer: it comes down to whether you’ll use 5G and whether OLED on the standard model matters to you.

The walkthrough for the iPhone 11 line is in How to pick an iPhone 11. Reading the two side by side makes it easier to see what actually changed at iPhone 12.

Angle	iPhone 11	iPhone 12
5G	Not supported	Sub-6 (Japan units)
Standard model’s screen	IPS LCD	OLED
MagSafe	Not supported	Supported
Smallest size	5.8 in (Pro)	5.4 in (mini)
Used price (2026 ballpark)	Cheaper	A bit higher

If 5G and OLED don’t matter and price is the lead, iPhone 11 is enough. If “mini-sized for one-handed use” or “OLED even on the standard model” is what you’re after, iPhone 12 has a reason to exist.

FAQ

Q. Is there a reason to buy iPhone 12 new in 2026? A. Distribution of new units has more or less wound down, so refurbished or used is the practical channel. If you can verify battery health, it works as a secondary phone or for light use. As your main phone for years to come, lean to a newer generation.

Q. Is the mini’s battery really weaker? A. Yes — Apple’s published video-playback time is shorter than the standard model. Under heavy use the meter does get tight in the evening. The decision is whether you accept that as the cost of the one-handed size, or move up to the standard.

Q. Does iPhone 12’s 5G matter in Japan? A. At the 2020 launch the 5G footprint was thin; in 2026 coverage is wide enough that the upside is easier to feel. That said, Japanese units are Sub-6 only — the high-throughput mmWave bands are not on the table.

Q. Is upgrading from iPhone 11 to iPhone 12 worth it? A. If iPhone 11 still feels fine, there is no hard reason to jump. The usual triggers for upgrading are: wanting 5G, wanting OLED on the standard tier, or wanting the mini’s one-handed size.

Wrapping up

The iPhone 12 line has a clean historical position as “the first 5G iPhone in the rollout year,” and the move to OLED across the line plus MagSafe makes the generation feel cohesive.

If you’re buying in 2026, used or refurbished is the realistic line, not new. Settle three things before you order — screen size, optical telephoto or not, and your local 5G area — and the odds of buyer’s remorse drop.

If you’re still torn between iPhone 11 and iPhone 12, reading this alongside How to pick an iPhone 11 sharpens the generation gap.

How to pick an iPhone 11 — Pro, Pro Max, or the standard model, sorted by use case

Thu, 25 Mar 2021 00:00:00 GMT

2026 update: This was written in March 2021, when the iPhone 11 had just dropped a generation and become the obvious value pick. In 2026 the iPhone 12 / 13 and later are cheap enough on the used market that there is almost no reason to buy an iPhone 11 new. Read this as a snapshot of the 2021 buying decision. The frame — how to think about the Pro / Pro Max / standard split — still applies.

The iPhone 11 line hit its sales peak after enough time had passed for it to settle into the “last-generation bargain” slot. Three models — Pro, Pro Max, and the standard iPhone 11 — and the price gaps between them are wide enough that people get stuck on the choice.

This piece narrows the comparison down to three axes — screen size, camera, and display quality — so that by the end you know which of the three is yours.

The short answer — Pro or standard, and three things decide it

Short version: picking inside the iPhone 11 line comes down to three questions. Do you need a triple-lens camera with a telephoto? Do you need the punch of an OLED display? Do you need a 6.5-inch screen?

Flip that around, and anyone who says no to all three is fine with the standard iPhone 11. In day-to-day use the performance gap against the Pro models is almost invisible.

Model	Screen size	Camera	Display	Price band (2021)
iPhone 11 Pro Max	6.5 inches	Triple lens (with telephoto)	OLED, HDR	High
iPhone 11 Pro	5.8 inches	Triple lens (with telephoto)	OLED, HDR	Mid to high
iPhone 11	6.1 inches	Dual lens (wide + ultra-wide)	IPS LCD	Mid

The use-case verdict, up front:

Telephoto shots, low light, video — Pro line
Vivid display for HDR video or photo editing — Pro line
Heavy gaming use — Pro line
The largest possible screen, period — Pro Max
None of the above — standard iPhone 11

Basic specs of the iPhone 11 line, side by side

Short version: all three share the same SoC (A13 Bionic), so CPU performance is identical. The differences live in the camera, the display, the screen size, and the battery.

CPU is A13 Bionic across the board

Pro, Pro Max, and the standard model all carry the same A13 Bionic. For everyday use and app launches, the felt speed is basically the same.

If “the Pro feels smoother for gaming” ever lines up with reality, it tends to come from the display feel and thermal-throttling headroom under heat, not from raw CPU.

Where they actually differ: camera, display, size, battery

Aspect	iPhone 11 Pro Max	iPhone 11 Pro	iPhone 11
SoC	A13 Bionic	A13 Bionic	A13 Bionic
Screen size	6.5 inches	5.8 inches	6.1 inches
Display	Super Retina XDR (OLED)	Super Retina XDR (OLED)	Liquid Retina (IPS LCD)
Camera	Triple (wide, ultra-wide, telephoto)	Triple (wide, ultra-wide, telephoto)	Dual (wide, ultra-wide)
Battery (rough)	Longest	Middle	Middle (some reports say the standard outlasts the Pro)
Weight	226 g	188 g	194 g

Read as a spec sheet alone the three look almost identical, but the telephoto lens and the OLED are the two places where the difference shows up in daily use.

Choosing by use case

Short version: if you make money on photos and video, or treat them as a serious hobby, take a Pro. If screen size is the top priority, take the Pro Max. Otherwise the standard model is fine.

If photos and video matter, take a Pro

What the triple-lens camera buys you is a 2x optical telephoto and a more reliable night mode. If you post food and travel shots to social media often, the Pro line lands closer to “actually satisfied.”

That said, 2x is only 2x. “Pull something far away in close” is not what this telephoto is for — set the expectation at “one step closer” and you won’t be disappointed.

For immersive video and gaming, take a Pro for the OLED

The Pro / Pro Max Super Retina XDR is OLED with HDR support. On a Netflix HDR title or a Dolby Vision film on Apple TV+, you can clearly feel the deeper blacks and the brighter highlights.

The Liquid Retina (IPS LCD) on the standard iPhone 11 still looks good on its own, but if HDR video is part of your daily diet, the Pro line is worth the premium.

For long-form video or e-books on a large screen, take the Pro Max

6.5 inches is the largest in the line. Good for two-page e-book spreads and for long video sessions — but 226 g is a lot to hold one-handed for any length of time. If you carry it in a pocket all day, go in with eyes open.

If none of the above, take the standard iPhone 11

If your day is mostly messaging, social media, snapshots, and video — and you don’t specifically need telephoto, HDR, or a big screen — the standard model covers it. Putting the price difference toward something else gives you more satisfaction per yen.

How the iPhone 11 stacks up against neighbouring generations

Short version: against the older models (iPhone XR / Xs) it is a clear step up thanks to A13 plus the ultra-wide camera. Against the iPhone 12 the gap is no 5G and no MagSafe.

Versus iPhone XR / Xs — a clean upgrade

CPU goes A12 to A13, with better processing speed and power efficiency
Adds an ultra-wide lens to the camera (XR was single, Xs was telephoto plus wide)
Adds night mode, which is a real step up for low-light shots

Coming from an XR, the difference is obvious in everyday use. Coming from an Xs, unless you care a lot about the camera, the honest answer is “no need to rush.”

Versus the iPhone 12 line

iPhone 12 supports 5G, iPhone 11 stops at 4G
iPhone 12 supports MagSafe (magnetic accessories); iPhone 11 does not
iPhone 12 is OLED across the line; on iPhone 11 only the Pro models are OLED
The iPhone 11 is the cheaper of the two (2021)

The full breakdown is in a separate piece — how to pick an iPhone 12. The 11-vs-12 question really comes down to whether you take the price cut or the 5G + MagSafe bundle.

Cross-generation summary

Aspect	iPhone 11 line	iPhone 12 line	iPhone Xs / XR
SoC	A13	A14	A12
5G	No	Yes	No
MagSafe	No	Yes	No
Ultra-wide camera	Yes (all models)	Yes (all models)	No on XR
OLED	Pro line only	All models	Xs only

FAQ

Q. Is there a point in buying an iPhone 11 new in 2026? A. Almost none. Apple no longer sells it, so you would be looking at the used market anyway. If iPhone 12 / 13 sits in the same price band, prefer those for 5G and OLED. The iPhone 11 still has a place as a used pick for a secondary phone, a kid’s phone, or a “just need an iPhone” stopgap.

Q. iPhone 11 Pro or Pro Max — which one? A. Specs are identical, so decide on a single question: do you need 6.5 inches? E-books and long video sessions point to the Pro Max. One-handed comfort points to the Pro. The 38 g weight gap feels real once you actually hold both.

Q. How much does the IPS LCD on the standard iPhone 11 fall behind the Pro’s OLED? A. Side by side you can tell. Apart from that, it rarely registers. Where the gap shows up is on a true-black background (OLED fully turns off the pixels) and in HDR-video contrast. Day-to-day web browsing and social media — you won’t notice.

Q. For gaming, is there a real difference between the Pro and the standard model? A. Same A13, so frame rates are basically the same. In long sessions, there are reports that the Pro line dissipates heat better by construction. For something heavy like Genshin Impact over long stretches, the Pro line may stay more stable — about that level of difference.

Wrapping up

How to pick an iPhone 11 boils down to one question: do you need any of the three — the telephoto lens, the OLED display, or the 6.5-inch screen? If the answer to all three is no, the standard iPhone 11 is enough. If you are stepping deeper into photography, video, or gaming, go with the Pro line.

In 2021 the iPhone 11 line was a strong value pick. In 2026 the used market has it sitting next to the iPhone 12 / 13 in the same price band, so it makes sense to broaden the search a generation up rather than insisting on a new iPhone 11.

For the full comparison that includes iPhone 12, see how to pick an iPhone 12.

How to pick a monitor for programming — start with one 24-inch, full HD, pivot-capable panel

Wed, 24 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The backbone — what to add on top of an office monitor when you code — still holds, but the product links and price ranges are anchored to 2021. Verify current prices and model numbers, and swap the links to the latest equivalents.

A lot of people pick up an extra monitor when they start learning to program, or when they land a job as an engineer. Search around and you quickly run into strong opinions — “ultrawide or nothing”, “vertical is mandatory” — which makes it hard to decide on a first panel.

The trick is to take the office-use baseline (How to pick a PC monitor) and add two programming-specific points on top. That clears almost all of the noise. If all you want is to spend more time reading code, a single 24-inch, full HD, matte, pivot-capable monitor will carry you a long way.

The short answer — start with one 24-inch, full HD, matte, pivot-capable panel

Short version: a programming monitor is the office pick plus two extras — pivot (vertical) support, and how comfortably the text reads. Concretely, start from one panel that ticks these four boxes.

Size: around 24 inches (fits on a desk; text doesn’t get cramped at full HD)
Resolution: full HD (1920×1080) — at 24 inches you can run it at 100% scaling with no fuss
Surface: matte (non-glare) — easier on the eyes over long sessions
Pivot: a stand that rotates to vertical, or VESA support (so you can mount it on an arm later)

Whether to go dual, run it vertical, or invest in 4K can all be answered later. Pick a first panel that meets the four points above, and you keep all those upgrade paths open.

Size and resolution — 24 inches and full HD is the easy choice

Short version: for a first programming monitor, 24-inch full HD. The reason is that code reads cleanly at that size with no extra setup.

At 24 inches and full HD (1920×1080), the default IDE font size (around 13–14 pt) sits comfortably at 80–100 columns. You can leave scaling at 100%, which sidesteps the layout breakage you sometimes hit in Linux or older tools.

Push full HD up to 27 inches and the dot pitch gets coarse — the edges of letters start to look a little fuzzy. If you want to run 27 inches or larger comfortably, 4K is effectively the floor (see the FAQ below).

If your desk is less than 60 cm deep, anchor on 24 inches. With more depth, a 27-inch 4K starts to make sense.

Vertical (pivot) vs. landscape — when each one helps

Short version: landscape is the default. Vertical is something to add only if you spend a lot of time reading tall content.

The reason: across a coding day, you spend more time reading logs, diffs, and docs than actually typing code. When the thing you’re reading is tall (logs, Markdown, Git diffs, PDFs), going vertical lets a lot more fit on one screen and visibly cuts how often you scroll.

Landscape — the default, and where to start

Landscape pairs well with the usual layout of IDE / browser / terminal side by side. If you’re using a multi-column IDE (tree on the left, editor in the middle, preview on the right) the way it was designed, landscape is fine.

Vertical — for logs, long code, and PR reviews

Vertical earns its keep for people like this:

Tailing server logs for long stretches (SRE / backend-leaning work)
Reviewing GitHub PRs every day (less vertical scrolling through diffs)
Reading long-form docs or specs for hours at a time

To go vertical you need a pivot-capable stand or VESA support plus a monitor arm. Lock in one of those at purchase time and the extra cost of switching to vertical later is zero.

If you go dual, match the model and put them side by side

A second display reliably cuts the time you spend bouncing between code and reference. That said, side by side beats stacked: horizontal eye movement is easier on you than constantly looking up and down.

Match the model when you pair two. Mismatched panels mean uneven bezels and slightly different colour casts, and that small mismatch nags at you every time you flick across.

Comparison — general office use vs. programming

Compared to an office pick, the things to add or change for programming come down to two: pivot support, and headroom for a second panel.

Aspect	General office	Programming
Size	22–24 inches	24 inches (more lines visible)
Resolution	Full HD	Full HD (24”) / 4K (27” and up)
Surface	Matte	Matte (non-negotiable)
Panel type	VA or IPS	IPS preferred (colour stays steady off-axis)
Pivot	To taste	Supported (or VESA, to add later)
Count	One is enough	One → a matched second, side by side
Price band	15,000–30,000 yen	20,000–40,000 yen × 1–2 panels

The three office baselines (panel type, size, surface) are shared with How to pick a PC monitor. The programming-specific delta is just “pivot support” and “room to add a second panel”.

Picks (for reference)

The models below were chosen in 2021. In 2026, verify the successor or an equivalent in the same price band before linking.

24-inch, IPS, pivot-capable (VESA included)

24-inch, IPS, matte, VESA-ready. The default pick whether you want one panel, or a matched second to grow into a dual setup.

Item	Spec
Size	24 inches
Panel	IPS
Resolution	Full HD
Surface	Matte
Pivot	Yes
VESA mount	Yes

24-inch, IPS, VESA-ready (tilt-only stand)

The stand by itself doesn’t pivot, but the panel is VESA-compatible, so an aftermarket arm will get you vertical orientation. A reasonable budget option.

Item	Spec
Size	24 inches
Panel	IPS
Resolution	Full HD
Surface	Matte
Pivot	Not on the stand (arm required)
VESA mount	Yes

Pair this with a monitor arm and the same hardware covers both dual setup and vertical orientation.

FAQ

Q. Is a dual-monitor setup mandatory? A. No. One panel plus IDE tabs and window splits will get the job done. That said, if you’re reviewing PRs or referencing docs while you write every day, a second panel visibly shortens that work. The honest path is one to start, then add a matching second panel once you have the desk space and the budget.

Q. Does vertical (pivot) actually help? A. For a narrow group, yes — clearly. If you tail logs for hours, do a lot of PR review, or read long specs, vertical is a real win. If you spend your day on front-end work or design, two landscape panels feel better. At purchase time, just make sure the panel is VESA-ready; you can switch to vertical later with an arm.

Q. Do I need a 4K monitor? A. At 24 inches, mostly no. 24-inch 4K has a dot pitch fine enough that scaling becomes mandatory, and the extra setup pays back less than you’d hope. 4K starts to earn its keep at 27 inches and up, where it gives you a wide working area without fuzzy text. For a first panel, 24-inch full HD is the easier ride.

Q. How do I connect this to a Mac without grief? A. Recent MacBooks output USB-C / Thunderbolt, so a monitor with USB-C input (DP Alt Mode) lets you handle power and video on a single cable — fewer wires on the desk. If the monitor you want doesn’t have USB-C input, pick one with HDMI or DisplayPort and add a USB-C → HDMI / DP adapter on the side. Early M-series MacBook Air models cap out at one external monitor, so if you’re planning to run dual, check the laptop’s output count before you commit.

Wrapping up

For a programming monitor, take the office baseline (24-inch, full HD, matte, IPS) and add two things: pivot support and room to add a second panel. That’s the whole delta.

For the first panel, don’t reach. A standard 24-inch, full HD, matte, VESA-ready model does the job. Dual setup and vertical orientation can both be added later for little money, so you don’t have to settle every question at purchase time.

The picks that overlap with office use live in How to pick a PC monitor. If you want a deeper read on panel type (VA vs. IPS), size, and surface finish, that’s the companion piece to this one.

How to pick an HDMI cable — decide by version (1.4 / 2.0 / 2.1) and use case

Tue, 23 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The original draft assumed HDMI 2.0a as the ceiling, but HDMI 2.1 has gone mainstream for 4K120Hz / 8K / VRR, so the body has been rewritten end to end. Re-check the affiliate links against the current line-up.

“I want to hook a TV up to a game console.” “I need a second one for my PC monitor.” “It’s supposed to be 4K, but it doesn’t look 4K.” The reasons people stall on buying an HDMI cable are usually one of these.

Prices run from a few hundred yen to several thousand, and the cables all look more or less the same. The difference lives in two things printed in small type on the box: the version and the connector shape. This piece focuses on those two and aims to give you the shape of “the HDMI cable you should buy right now.”

The short answer — version, length, connector shape

Short version: picking an HDMI cable is not hard. A version that matches your use case, a length that is just long enough, and a connector shape that matches your gear — settle those three in order and you are done.

The shortest path, by use case:

Up to Full HD (1080p) — HDMI 1.4 is enough
4K60Hz / HDR — HDMI 2.0 (Premium High Speed)
4K120Hz / 8K / VRR (game consoles, latest GPUs) — HDMI 2.1 (Ultra High Speed)

For length, treat 1–3 m as the desk-side baseline and pick something a little longer than your actual run. For the connector, confirm “Type A (standard) / Mini / Micro” on both ends of the connection. Do those things and failure is rare.

What an HDMI version is — a bundle of bandwidth and features

What an HDMI version is

The number that marks a generation of the HDMI cable and connector spec. Each generation fixes a maximum bandwidth (Gbps), which in turn fixes the maximum resolution, refresh rate, and feature set (HDR, VRR, etc.) it supports. Newer cables are backward compatible with older features, but not the other way around — older cables cannot deliver newer features.

Miss this point and you get “the TV is 4K but the picture isn’t 4K” or “the game won’t push 120Hz.” When the cable can’t carry the bandwidth, the device automatically falls back to a lower signal.

The headline specs for each version look like this.

HDMI 1.4 — Full HD / up to 4K30Hz

Defined in 2009. Maximum bandwidth around 10.2 Gbps, with Full HD (1920×1080) at 60Hz and 4K (3840×2160) at 30Hz as the practical ceiling.

3D video and the Ethernet channel showed up in this generation. Today it sits as the floor for Full HD TVs and older monitors.

HDMI 2.0 — the mainstream for 4K60Hz / HDR

Defined in 2013. Maximum bandwidth 18 Gbps, supporting 4K60Hz and HDR10.

As of 2026, pairing a typical 4K TV or 4K monitor with mainstream gear, this is the safest baseline. Cables labeled Premium High Speed fall in this band.

If you actually want HDR to work, pick HDMI 2.0a or later. The difference between 2.0 and 2.0a is HDR metadata support, and the shortcut is to look for “HDR” called out on the box.

HDMI 2.1 — 4K120Hz / 8K / VRR

Defined in 2017. Maximum bandwidth jumps to 48 Gbps, with support for 4K120Hz, 8K60Hz, Variable Refresh Rate (VRR), and Auto Low Latency Mode (ALLM).

For 4K120Hz on a PlayStation 5, an Xbox Series X / S, or a current GPU, the cable has to be this generation or the bandwidth won’t hold up. These are sold as Ultra High Speed HDMI cables.

Some products call themselves HDMI 2.1 without actually clearing 48 Gbps, so when you buy, the safe move is to look for the “Ultra High Speed HDMI Cable” certification label.

Picking by use case — five patterns

Short version: the answer is set by what you are plugging into what. Drop your situation into one of the cases below.

TV + recorder (Full HD) — HDMI 1.4

For recording and playing back Full HD terrestrial broadcasts, HDMI 1.4 is plenty. A cheap basic-grade cable is fine.

4K TV + Blu-ray or streaming stick — HDMI 2.0

The content is mostly 4K60Hz / HDR. Pick a Premium High Speed certified cable. Anything sold at an electronics store under the “4K compatible” label is usually in this class.

PC + 4K monitor (creative work) — HDMI 2.0

For photo work, video editing, and design, 4K60Hz is enough. Use HDMI 2.0 as the baseline.

If the monitor has DisplayPort input, DisplayPort is often a generation ahead on bandwidth. If you aren’t tied to HDMI, it’s worth considering.

Game consoles (PS5 / Xbox Series X) — HDMI 2.1

If you want 4K120Hz or VRR working, HDMI 2.1 is required. The PS5 ships with an HDMI 2.1 cable in the box, so match that grade when you buy a second one.

Laptop + projector (occasional use) — HDMI 1.4 is fine

For projecting in a meeting room or on a trip, resolutions often drop to WUXGA or so. Length tends to need 3 m or more, so cable quality (shielding, conductor) moves the needle more than the generation does.

Comparison — HDMI 1.4 / 2.0 / 2.1

Max resolution, refresh rate, and headline use case in one table.

Spec	HDMI 1.4	HDMI 2.0 / 2.0a	HDMI 2.1
Max bandwidth	10.2 Gbps	18 Gbps	48 Gbps
Max resolution	4K30Hz	4K60Hz	8K60Hz / 4K120Hz
HDR	No	Yes (2.0a and later)	Yes (Dynamic HDR)
VRR / ALLM	No	No	Yes
Marketing name	High Speed	Premium High Speed	Ultra High Speed
Typical use	Full HD TV / recorder	4K TV / 4K monitor	PS5 / Xbox Series X / 8K TV

Length — pick “actual run + a little slack”

Short version: too short and it won’t reach; too long and it sags and gets in the way. The practical sweet spot is the measured run plus 0.5–1 m of slack.

Permanent install — 2–3 m

Wiring that runs behind a desk or down a wall is always longer than it looks. If your desk-side run measures 1.5 m, pick 2–3 m of cable.

Temporary use — 1–2 m

Plugging a laptop straight into a monitor puts the two devices close together. 1–2 m is enough.

Anything past 5 m needs care

HDMI works at long runs on paper, but 4K60Hz / HDR signals start dropping out around the 5 m mark. For long runs, look at optical fiber HDMI cables (Active Optical Cable, AOC).

Connector shape — confirm both ends

Short version: HDMI connectors come in three shapes — Type A (standard) / Mini HDMI (Type C) / Micro HDMI (Type D). Before you buy, check the connector shape on both ends of the link.

Home gear is almost always Type A, but Mini / Micro show up in these cases:

Mirrorless cameras / camcorders — usually Mini or Micro
Small laptops and 2-in-1s — Mini HDMI sometimes
Action cameras — typically Micro HDMI

There’s also more gear that uses DisplayPort or USB Type-C (DP Alt Mode) instead of HDMI. A laptop with USB-C as the only video out won’t connect with an HDMI cable directly — you’ll need a USB-C to HDMI adapter.

FAQ

Q. If I buy an HDMI 2.1 cable, will my old gear get upgraded? A. No. HDMI only delivers a generation’s features when both endpoints and the cable support it. Plug a 2.1 cable into an older TV and the TV is still the ceiling.

Q. How do I tell Premium High Speed apart from Ultra High Speed? A. By the certification label on the packaging. “Premium High Speed HDMI Cable” corresponds to HDMI 2.0 / 2.0a, and “Ultra High Speed HDMI Cable” corresponds to HDMI 2.1. A bare “4K compatible” tag without a label is no guarantee of bandwidth.

Q. What’s the difference between a 1,000-yen cable and a 5,000-yen one? A. Mostly conductor material, shielding thickness, and connector build. For Full HD or 4K60Hz, a certified cheap cable is fine, and the 5,000-yen difference only really shows up in long runs, 4K120Hz, 8K, or pro gear.

Q. Does the cable itself change input lag? A. Almost never. Video input lag is dominated by what the TV or monitor is doing internally, and a cable doesn’t usually add to it. For gaming, picking an HDMI 2.1 device with ALLM / VRR support matters more.

Picks by use case

The picks below were chosen at the time of writing, with 2026 equivalents in the same band. Confirm the current generation at the time of purchase.

4K60Hz / HDR — HDMI 2.0 Premium High Speed

For the everyday case of plugging a home 4K TV into a PC or game console, a certified Premium High Speed cable is the first pick. Around 2 m is enough.

4K120Hz / 8K / VRR — HDMI 2.1 Ultra High Speed

If you want 120Hz out of a PS5, Xbox Series X, or current GPU, pick an Ultra High Speed certified cable.

Long runs past 5 m — Optical Fiber HDMI (AOC)

Good for ceiling-mounted projectors in meeting rooms, or layouts where the TV and the AV rack are far apart. They cost more than copper at the same length, but they carry 4K60Hz / HDR cleanly.

Wrapping up

Because HDMI cables look almost identical, just keeping version, length, and connector shape in mind collapses the decision to something simple.

Full HD: 1.4. 4K60Hz / HDR: 2.0. 4K120Hz, 8K, or VRR: 2.1. Length is the measured run plus 0.5–1 m, and confirm the connector on both ends. Stick to that and you avoid the “I bought it but it doesn’t deliver the picture quality” trap.

If you’re unsure, the shortcut is to check the maximum resolution and refresh rate of the gear you already own first. A cable is a tool that lets the gear hit its limit — it cannot push past what the gear itself can do.

How to pick a monitor arm — get VESA, load capacity, and the clamp right and you won't end up with a bad one

Mon, 22 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The backbone — what to look at when picking an arm — still holds, but the product links and price ranges are anchored to 2021. Verify current model numbers and prices and swap to the latest equivalents.

Add a monitor arm and the desk surface opens up in one stroke. The space for papers and a drink comes back, and you can move the screen height to match how you’re sitting.

The catch is the price range — anything from cheap to expensive — and a bad pick can lead to a screen that slowly droops, or, in the worst case, won’t mount at all. This piece narrows the call down to three things — VESA, load capacity, and mounting style — assuming you’ll use the arm for long PC sessions.

The short answer — VESA 100×100, 1.5× the load, clamp mount

Short version: a monitor arm is hard to get wrong if it ticks these three boxes.

VESA mount: the monitor supports VESA 100×100 mm on the back
Load capacity: aim for 1.5× the monitor’s actual weight, with margin to spare
Mounting style: clamp mount (clips onto the desk edge)

On budget vs longevity: for the long haul, an Ergotron LX-class gas-spring arm (17,000–25,000 yen); for a short-term try, a cheaper gas-spring model (5,000–10,000 yen). Mechanical-spring arms and bolt-fixed budget models aren’t a great fit for “I’ll be moving it around.”

What a monitor arm is actually for

Short version: to free up the desk surface, and to move the screen height to fit your posture.

The reason: a monitor on its base sits on a stand whose foot juts toward you and eats 30–50% of the desk depth. Swap to an arm and the front of the desk goes completely clear.

Side benefits: it’s harder to topple in an earthquake, cable routing gets cleaner, and aligning multiple monitors gets easier. If you sit alone, head-on, those are bonuses — not the main reason to buy.

VESA mount and clamp vs grommet — terms first

What “VESA mount” means

The screw-hole standard on the back of a monitor. VESA 100×100 mm refers to four screw holes laid out at 100 mm horizontal and 100 mm vertical spacing. Most 22–27-inch monitors support this pattern. At 32 inches and up, you sometimes hit VESA 200×200 mm or another size, so check the monitor’s spec sheet before you buy.

Clamp mount vs grommet mount

Clamp mount: clips the desktop from above and below, like a clip. Doesn’t scratch the surface, no tools needed. Needs roughly 5 cm of clearance behind the desk edge.

Grommet mount: bolts through a hole drilled in the desk (or an existing cable hole). You can mount it anywhere on the surface, not just the edge — at the cost of needing a hole.

Most home desks are fine with a clamp mount. Reach for grommet if you want the arm in the middle of the desk, or if your desk sits flush against a wall with no clearance for a clamp.

Mounting style — clamp is the safe default

Short version: pick a clamp mount and you’ll almost never run into trouble on a home desk.

The reason: no hole in the desktop means it works in a rental, and it travels well through moves and layout changes. Grommet mounts assume drilling, which leaves a permanent mark when you sell the desk.

When clamp fits

A rental where you don’t want to modify the desktop
A desk 65 cm deep or more (room for the clamp’s overhang)
You want the monitor at the back edge of the desk

Almost every home PC desk meets these conditions.

When grommet fits

The desk already has a cable hole
You want the desk flush against a wall (the clamp would foul the wall)
You want the monitor closer to the center of the desk

It’s more common on office desks and standing desks with built-in cable holes.

Load capacity — 1.5× the monitor’s actual weight

Short version: budget for 1.5× the monitor’s actual weight and the screen won’t droop later when the gas spring weakens.

The reason: gas-spring arms rely on internal gas pressure to hold the weight. Run one near its upper limit and as the pressure drops over time, it can no longer hold the screen up. At the upper limit, you tend to hit “wait, when did the screen sag?” within six months to a year.

Rough weights by size

22–24 inches: 3–4 kg
27 inches: 5–7 kg
32 inches: 7–10 kg

So 24 inches calls for an arm rated 5–6 kg or more, and 27 inches for 8–10 kg or more, to keep that 1.5× cushion.

Go by weight, not size

Product specs often say something like “supports up to 27 inches,” but that’s a rough guide. Two 27-inch monitors can differ by 2× in weight, so always check the actual weight on the monitor’s spec sheet and match it against the arm’s load rating.

Movement type — gas spring is the default

Short version: pick gas-spring if you’ll change height often. For fixed positions, mechanical spring or bolt-fixed is fine, but the price gap is only 1,000–2,000 yen, so gas-spring is the safer default.

The reason: gas-spring arms move with one hand, mechanical-spring arms need finicky tension adjustment, and bolt-fixed arms need a tool. People who tell themselves “I won’t move it” usually end up wanting to change the height when their posture shifts — so something that moves easily lasts longer in practice.

Gas spring / mechanical spring / bolt-fixed

Gas spring: held by internal gas pressure. Moves with one hand. The most common type.
Mechanical spring: held by a metal spring. Cheaper than gas, but you tune the tension with an adjustment screw. Works if the weight matches the setting, but the screen weight changes mean re-tuning.
Bolt-fixed: joints locked with hex bolts. Set it once and don’t move it. Cheapest of the three, but a poor match for changing posture.

Price bands and product comparison

Short version: the range runs 5,000 to 25,000 yen. Ergotron LX for the long haul, a cheap gas-spring for a short-term try, bolt-fixed for a static setup — those three slots cover most of it.

Aspect	Ergotron LX class	Budget gas-spring	Mechanical spring	Bolt-fixed
Price range	17,000–25,000 yen	5,000–10,000 yen	4,000–8,000 yen	3,000–6,000 yen
Movement	Gas spring	Gas spring	Mechanical spring	Bolt-fixed
Load capacity	up to 11 kg	up to 8 kg	up to 8 kg	up to 10 kg
Ease of movement	One hand, light	Works one-handed but unit-to-unit variance	Needs tension tuning	Static
Warranty	10 years (rated)	About 1 year (rated)	About 1 year	About 1 year
Best fit	Planning to use 5+ years	Trying it out / short term	Same	Static, secondary setup

For long-term use, the warranty length and parts availability matter. Budget models tend to be “if the gas pressure dies, replace the whole arm.”

Recommended monitor arms (for reference)

The picks below are from 2021. Verify current model numbers and prices and swap to the latest equivalents.

For the long haul — Ergotron LX

Gas-spring, rated to 11.3 kg, wide range of motion, long warranty. Around 20,000 yen up front, but if it sits on the same desk for five years or more, the per-year cost drops.

Item	Spec
Movement	Gas spring
Load capacity	up to 11.3 kg (rated)
VESA mount	75×75 / 100×100
Mounting style	Clamp / grommet (both)
Warranty	10 years (rated)

For a short-term try — Amazon Basics class gas-spring

The Amazon Basics monitor arm, reputed to be the Ergotron LX OEM, is the headline pick. Around 10,000 yen, with load capacity and range of motion both more than enough.

Item	Spec
Movement	Gas spring
Load capacity	up to 11.3 kg (rated)
VESA mount	75×75 / 100×100
Mounting style	Clamp / grommet (both)
Warranty	1 year (rated)

I’ve run a few equivalents over several years and never hit a fatal issue. If you’re going in with the “good enough” mindset, this band is plenty.

FAQ

Q. Can I use one with a monitor that doesn’t support VESA? A. Some makers sell VESA conversion adapters separately. But the stand mount on the back of a monitor is model-specific, and if no adapter exists for yours, you can’t really use it. The reliable move is to check the monitor’s spec sheet for VESA support before you buy.

Q. Will a clamp mount work on a thin desktop? A. The clamp lists a supported thickness range (for example, 10–60 mm). Too thin and the clamp won’t bite, so it ends up loose. Too thick and it won’t close. Measure the desktop and check the range.

Q. For dual monitors, should I pick a single arm that holds both screens? A. A one-arm dual-screen setup looks tidy, but the load capacity and range of motion get tight. For the long haul, two single arms side by side handle future swaps and single-screen use more gracefully.

Q. Will a monitor on an arm wobble? A. With the clamp tightened properly and a desktop of decent thickness and material (plywood or steel), typing-level vibration almost never shows. Very thin or hollow desktops do shake — swap the desk or move to a bolt-fixed arm.

Wrapping up

A monitor arm is hard to get wrong, regardless of price band, as long as it ticks three boxes: VESA 100×100 mm support, load capacity at 1.5× the monitor’s actual weight, and a clamp mount.

For the long haul, Ergotron LX-class is the realistic call; for a short-term try, an Amazon Basics-class gas-spring arm is enough. Mechanical-spring and bolt-fixed arms are on the table if you’ll keep the screen in one place.

The cleaner order is: pick the monitor first, then match the arm to it. The monitor side of the call is covered in a separate piece (How to pick a PC monitor — three things you can’t get wrong, plus one to taste).

Picking a monitor panel by use case — IPS / VA / TN / OLED, and where each one fits

Sun, 21 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The backbone — which panel fits which use case — still holds, but price bands and the spread of OLED have moved a lot since then. Treat the price figures as ballparks and verify the current market.

The letters that line up on a monitor spec sheet — IPS, VA, TN, OLED — get glossed over more often than not. Surprisingly few people can explain the difference cleanly.

The axis for choosing one, though, is simple. If you want one screen that handles work and video without fuss, pick IPS. If price is the deciding factor, VA. If you want frame-by-frame response for competitive gaming, TN. If film and HDR are what you actually care about, OLED. This piece lays that out across five axes — color, viewing angle, response time, price, and best-fit use case — on one page.

The short answer — pick IPS when in doubt, another panel when the goal is clear

Short version: if you don’t know what to pick, IPS is the safe call. The color balance is good, the viewing angle is wide, and prices have come down to a comfortable range.

That said, when the goal is clear, another panel is the right answer.

IPS — the all-rounder for work + video + light gaming. The default when in doubt
VA — when price comes first, or for video with lots of dark scenes
TN — competitive use where FPS or fighting-game response is the priority
OLED — when HDR or a film-like image matters and budget allows

The panel type sets the broad shape of the rest of the spec comparison, so locking this in first makes everything downstream faster.

What “panel type” means — liquid crystal vs self-emitting

Short version: the panel is the layer that produces the picture. LCDs (IPS / VA / TN) gate light from a backlight by twisting liquid-crystal molecules; OLED has each pixel emit its own light.

Term roundup

LCD panel: backlight + liquid-crystal layer. Color comes from how the light is bent and let through

IPS (In-Plane Switching): drives the crystals horizontally. Strong on viewing angle and color

VA (Vertical Alignment): drives the crystals vertically. Strong on black levels

TN (Twisted Nematic): drives the crystals by twisting them. Strong on response time and price

OLED (Organic Light-Emitting Diode): organic EL. Each pixel emits its own light, so no backlight is needed and black is fully off

The three LCD types differ only in how the crystals are moved, but that one mechanical choice sets the color / viewing-angle / speed trade-off. OLED is a fundamentally different mechanism, so it sits in its own category.

IPS — the all-rounder; pick this when in doubt

Short version: nice color, wide viewing angle, prices have come down. The first candidate if one screen has to cover work + video + light gaming.

IPS at a glance

Color: good. Near-full sRGB coverage is standard

Viewing angle: wide (170°+ on both axes, rated)

Response time: average (5–8 ms is the norm; gaming variants list 1 ms)

Price: middle. 23–27-inch panels in the 20,000–40,000-yen band are common

The weak spot is that blacks float a little in scenes that need strong contrast. In a fully dark room watching films, OLED has the edge; for ordinary daytime use in a lit room, it isn’t something you notice.

“My first monitor,” “a remote-work screen,” or “I’ll also touch photo and light video editing” almost always lands on IPS.

VA — price first, with tight blacks for video

Short version: often the cheapest in its size class, with strong black reproduction. A good fit for sitting in front of a screen alone and watching video.

VA at a glance

Color: average. Contrast ratio runs high (around 3000:1 is common, rated)

Viewing angle: a little narrow. Color washes out at oblique angles

Response time: medium to slow. Ghosting can show up in fast motion (without black-frame insertion)

Price: cheap. Plenty of 23-inch options in the 10,000–20,000-yen range

Variants like MVA / AMVA have closed the viewing-angle gap with IPS in recent years. Even so, for a meeting screen where multiple people lean in, or a desk layout where the monitor sits at an angle to your eyes, IPS is easier to live with.

If the budget is under 20,000 yen for one screen, the realistic shortlist tilts toward VA.

TN — built for competitive gaming, all-in on response time

Short version: a panel that goes all-in on response time and a low price. The pick for FPS and fighting players who need frame-level response; for ordinary use, the weak color and viewing angle start to show.

TN at a glance

Color: weak. Gamut coverage falls a notch below IPS and VA

Viewing angle: narrow (especially vertically)

Response time: fast (1 ms is the norm)

Price: cheap. Plenty of gaming-feature models in the 20,000-yen band

“TN is dated” is a common line, but at 240 Hz / 360 Hz, TN is still very much in service for gaming. The honest framing is: it’s the panel for people willing to give up color to chase frames.

The flip side is that long sessions of writing or spreadsheets get harder, because the narrow viewing angle forces you to hold one posture.

OLED — HDR and a film image, with a price tag and burn-in to weigh

Short version: per-pixel self-emission means black goes fully off. If HDR gradation and cinema-style contrast are what you want, it’s the only real answer. The cost is several times an LCD, and burn-in is a real concern with long static content.

OLED at a glance

Color: very good. Near-full DCI-P3 coverage is standard

Viewing angle: wide. Self-emission means little color shift off-axis

Response time: very fast (a different axis from LCD response; pixel response is cited around 0.1 ms)

Price: high. 27–32-inch panels mostly land in the 100,000–200,000-yen band

The thing to watch is burn-in. Static elements like the taskbar or window borders, left on screen for long stretches, can leave faint outlines behind. Recent models mitigate this with pixel shift and screensavers, but for office work that pins the same UI to the screen all day, it’s still not the right pick.

This is the “for film and HDR” monitor, for buyers with the budget to spend on what they see.

Comparison — IPS / VA / TN / OLED across five axes

Short version: line them up by color, viewing angle, response time, price, and best-fit use case, and the panel that matches your priorities surfaces on its own.

Axis	IPS	VA	TN	OLED
Color	Good	Average	Weak	Very good
Viewing angle	Wide	A little narrow	Narrow	Wide
Response time	Average to fast	Medium to slow	Fast	Very fast
Price	Middle	Cheap	Cheap	High
Best fit	Work + video all-rounder	Video-centric, price first	Competitive gaming	HDR / film

Price and color tend to trade off. Viewing angle and response time are roughly where IPS and OLED have both. TN is the “fast and cheap” specialist; VA is the “black and cheap” specialist. That framing makes the table easier to hold in your head.

The fine numerical differences — 1 ms vs 4 ms response, say — are hard to feel without competitive gaming in the mix. Use the table to lock in the broad shape, then compare individual models inside that band.

Picks by use case — what to actually buy

Short version: if the use case is known, panel choice is settled by the chart below.

Use case	Panel	Why
Work + video + occasional gaming	IPS	All-rounder. Good balance of viewing angle and color
One screen, as cheap as possible	VA	Cheapest in its size class. Also pairs well with video
FPS / fighting-game competitive	TN	Response time and price. Color is the trade
Film / HDR / photo viewing	OLED	Black levels and gamut. If the budget allows
Photo / video editing	IPS (wide-gamut model)	Check sRGB / DCI-P3 coverage in the spec sheet
Adding a second display	Same panel type as the first	Color tone matches more easily when they sit side by side

For multi-monitor setups, different panel types render the same image with subtly different tones. If you’ll have two or more screens in front of you at work, you don’t have to match the brand — but match the panel type and a lot of small friction goes away.

FAQ

Q. Where on the spec sheet do I find the panel type? A. Product pages list it under “panel type,” “display type,” or “panel format.” If it isn’t on the listing, the manufacturer’s official spec PDF is the safe place to confirm.

Q. Among “IPS” panels, do brands actually differ in quality? A. Yes. Even under the same “IPS” label, gamut coverage (sRGB / DCI-P3 percentages) and brightness vary widely model to model. Compare on the numbers in the spec column.

Q. How long does it take for OLED to burn in? A. It depends on usage. In an environment where the taskbar or an app UI sits in the same place for long stretches, faint outlines are cited as starting to appear in the several-hundred to several-thousand-hour range. For film-centric use it’s far less of a concern. If you’re worried, auto-hide taskbars and screensavers help reduce it.

Q. Can a gaming monitor be IPS? A. Yes. 144 Hz and 240 Hz IPS models with 1 ms response listings have become common. Unless you’re competitive, an IPS gaming model that takes both color and speed is the more practical pick over TN.

Wrapping up

Picking a panel is a question of what you prioritize. Want color and viewing angle balanced — IPS. Want the lowest price — VA. Want frame speed — TN. Want HDR and deep blacks — OLED.

Before comparing fine numbers on a spec sheet, decide which of the four you’re leaning toward. Once that’s settled, what’s left is size, surface finish, and connectors.

How to pick a monitor itself — size, surface finish, and so on — is covered in a separate piece. Read alongside this one, and the spec column on a product page starts reading at a glance.

How to pick a gaming monitor — 144Hz, 1ms, and panel type cover 90% of the decision (2026 edition)

Sat, 20 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The framework — refresh rate, response time, and panel — still holds, but as of 2026, 240Hz has dropped into the mainstream and OLED gaming monitors land around the 100,000-yen mark. Specific product links need to be verified and swapped to current models before this goes live.

You want to refresh your monitor to match a PS5 or a recent PC title. But the spec sheet lines up “Hz,” “ms,” “IPS,” and “G-Sync,” and it is hard to tell which of them you should actually weigh.

This piece frames a gaming monitor on four axes — refresh rate, response time, panel, and sync tech. By the end, the shape of the one model that fits your genre and budget should be visible.

The short answer — for FPS and fighters, 144Hz / 1ms / IPS is the realistic floor

Short answer: if you play speed-driven genres (FPS, fighters, competitive action), four things to check before you buy.

Refresh rate: 144Hz or higher (consoles, PS5 included, cap at 120Hz in most cases)
Response time: around GtG 1ms
Panel: IPS (balanced) / TN (fastest, cheapest) / OLED (top tier, expensive)
Sync tech: FreeSync (AMD) or G-Sync Compatible (NVIDIA)

Conversely, if you mostly play RPGs, simulations, or turn-based games, those numbers are overspec. A standard work-grade IPS monitor at 60Hz looks plenty good.

Key points

Refresh rate 144Hz or higher (in 2026, 240Hz is the mainstream tier)

Response time aim for GtG 1ms

Panels: IPS is the all-rounder, TN for raw speed, OLED if picture quality comes first

On PC, always match FreeSync / G-Sync to your GPU

The terminology — Hz, ms, FreeSync

Short answer: the three terms on every spec sheet measure different things — smoothness, ghosting, and tearing prevention.

Gaming monitor terms

Hz (refresh rate): how many times per second the screen is redrawn. At 144Hz, the panel updates 144 times a second. Higher numbers feel smoother and let you catch the opponent’s movement a moment sooner.

ms (response time / GtG): the time a pixel takes to switch from one mid-gray to another (“Gray to Gray”). The closer to 1ms, the less the trailing image (ghosting). Catalog figures and measured values can diverge.

FreeSync / G-Sync (sync tech): a mechanism that aligns the GPU’s draw timing with the monitor’s refresh timing, so tearing (horizontal misalignment) and stuttering get suppressed. FreeSync came from AMD, G-Sync from NVIDIA, but the two have grown largely cross-compatible in recent years.

Refresh rate — 144Hz is the standard; in 2026, 240Hz is in reach

Short answer: for FPS and fighters, 144Hz is the realistic floor. In 2026, the 240Hz class has dropped to the 30,000–50,000-yen range, which makes it good value.

The reason is that a higher refresh rate carries more information per second, which shortens the lag between an opponent’s move and your reaction. The jump from 60Hz to 144Hz is clearly noticeable to most people; the jump from 144Hz to 240Hz mostly matters to competitive players.

Moving from 60Hz to 144Hz is the big jump

Everyday monitors are almost all 60Hz. Lifting that to 144Hz, you feel the difference starting with the mouse cursor. In FPS, an “I saw where they were” window opens wider when you whip the view around.

240Hz and beyond depends on genre and rig

To actually feel a 240Hz or 360Hz panel, the GPU has to push frames at that rate reliably. PS5 and Xbox Series X cap at 120Hz, so if console is your main platform, 144Hz is where the curve flattens.

Mind the cable spec too

High refresh rates depend on the video cable spec. Driving 4K at 144Hz needs DisplayPort 1.4 or higher, or HDMI 2.1. An older HDMI 2.0 cable lacks the bandwidth and can drop back to 60Hz.

Response time — aim around GtG 1ms

Short answer: for speed-driven genres, pick around GtG 1ms. Slower than that and ghosting shows up in fast-moving scenes.

The reason is that a slow response leaves the previous frame’s pixels lingering into the next, smearing the opponent’s silhouette. In FPS, ghosting delays the read on which way the other player is facing.

Catalog values and measured values can diverge

A “1ms (GtG)” spec can come back with measured values that vary by more than 2x depending on the mode. Cross-checking with measurements from review sites is the safe play.

How to use the overdrive setting

Most gaming monitors have an overdrive (OD) setting that forces faster pixel transitions. Crank it too far and you get reverse ghosting (overshoot), so starting from the middle preset that ships with the panel is the realistic move.

Panel type — IPS is the standard, TN is the fastest, OLED is the new option

Short answer: as of 2026, the picks are IPS (balanced), TN (fastest and cheapest), and OLED (picture quality first).

The reason is that panel type changes the balance of response time, viewing angle, color, and price by a lot. Even at the same 144Hz and 1ms, what you see and what you pay can differ sharply.

IPS — the all-rounder, the default pick

Strong on color vibrancy and viewing angle. Response time used to lag behind TN, but gaming-grade IPS (Fast IPS and similar) has closed in on the 1ms class and is now practical for FPS. The main price band is 30,000–70,000 yen.

TN — fastest and cheapest, at the cost of picture quality and viewing angle

Still in the top tier for response time and the lowest on price. The trade-off is dull colors and a shift in color when viewed from the side. Best for fixed solo play at the center of the desk.

VA — contrast-strong, not a competitive pick

Deep blacks make it a good fit for film and single-player RPGs. But response time trails IPS and TN, and dark-scene ghosting (black smear) is easier to spot, so it falls off the list for competitive play.

OLED — the new 2026 option

Gaming monitors with QD-OLED or WOLED panels have become widely available. Response time on the order of 0.03ms and effectively infinite contrast put picture quality well beyond LCDs. The main price band is 100,000–200,000 yen. Burn-in risk has not gone away, but more models now ship with serious warranty terms.

FreeSync / G-Sync — on PC, always match to your GPU

Short answer: if you play on PC, pick a monitor with the sync tech that matches your GPU brand.

The reason is that when the GPU’s draw rate and the monitor’s refresh rate fall out of step, tearing (horizontal screen splits) and stuttering show up. Sync tech absorbs that automatically.

NVIDIA GPU primary: G-Sync or G-Sync Compatible
AMD GPU primary: FreeSync or FreeSync Premium
Dual-support panels: more recent models support both, which is the safer pick if you might switch GPUs later

PS5 and Xbox support HDMI VRR, which is compatible with the FreeSync family.

Comparison: 60Hz vs. 144Hz vs. 240Hz+

Aspect	60Hz (general use)	144Hz (gaming standard)	240Hz+ (competitive / latest gen)
Target genre	RPG / office work	FPS / fighters in general	Competitive FPS / esports
Smoothness	Standard	Clearly smoother	Small gap vs. 144Hz in practice
GPU needed	Integrated GPU is fine	Mid-range or above	High-end GPU recommended
PS5 / Xbox fit	Fits	120Hz output gets real benefit	Overspec
Price band (24-inch)	10,000–20,000 yen	30,000–50,000 yen	50,000–80,000 yen
Panel options	Mainly IPS / VA	IPS / TN / VA	IPS / OLED

Recommended monitors — by use case

The picks below were chosen at the time of writing (2021). In 2026, verify the successor or an equivalent in the same price band before linking.

Speed first — TN 144Hz

For competitive players who put response time above everything. Compromises on color in exchange for price and speed.

Item	Spec
Size	23.6 inches
Panel	TN
Resolution	Full HD
Surface	Non-glossy
Response time	GtG 1ms
Refresh rate	144Hz
Sync tech	FreeSync
VESA mount	Yes

Balanced — IPS 144Hz

For a multi-genre player who runs both FPS and RPG. Holds onto viewing angle and color vibrancy while keeping response time in the practical range.

Item	Spec
Size	23.8 inches
Panel	IPS
Resolution	Full HD
Surface	Non-glossy
Response time	GtG 1ms
Refresh rate	144Hz
Sync tech	FreeSync / G-Sync Compatible
VESA mount	Yes

Picture quality first — OLED 240Hz (the 2026 option)

The upper tier, worth considering if the budget allows. Pairs picture quality with response time. WQHD or higher resolution is the realistic pairing.

FAQ

Q. Do 144Hz or 240Hz help on PS5? A. PS5 caps at 4K 120Hz or Full HD 120Hz over HDMI 2.1. It can’t output 144Hz or higher, but a 120Hz-capable monitor still pays off on supported titles. A model with VRR (HDMI VRR) also smooths out the stutter when the frame rate fluctuates.

Q. 4K at 144Hz or Full HD at 240Hz — which one? A. Pick by genre. If frame rate maps directly to win rate (competitive FPS), Full HD 240Hz. If story or action is the focus and you want image detail, 4K 144Hz. If you want both, WQHD at 165–240Hz is the middle path.

Q. Can I feel the difference between 1ms and 0.5ms response? A. Most people cannot. Cable spec, GPU output frame rate, and the monitor’s internal processing delay (input lag) move the felt difference more than the pixel transition does.

Q. Can a gaming monitor double for everyday use (work, browsing)? A. With no trouble. The smoothness of 144Hz is even felt while scrolling. That said, if you need accurate color for photo or video work, a calibration-capable dedicated monitor is a better fit.

Wrapping up

Picking a gaming monitor gets easier when you frame it on four axes: refresh rate, response time, panel, and sync tech.

For FPS and fighters, 144Hz / GtG 1ms / IPS / FreeSync or G-Sync Compatible is the realistic floor. In 2026, the 240Hz class has dropped into the mainstream, and if picture quality is the priority, an OLED gaming monitor is the upper-tier option.

If your genres are mostly RPG or simulation, those numbers are overspec. Buying to fit the actual use case ends up being the most cost-efficient call.

A 4K monitor isn't for everyone — how to pick between 4K, WQHD, and FHD by use case

Fri, 19 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog and reshaped from a 2026 vantage point. 4K monitors are cheaper and more common than they were in 2021, but “should everyone buy 4K” still depends on the use case. Specific product links need to be swapped for current models before this goes live.

“I want a 4K monitor, but I can’t figure out which one to pick.” “What’s the best 4K for the money?” I get asked some version of this often. The trouble is, the conversation usually jumps straight to comparing specific models before settling whether 4K is even the right call.

This piece is the step before that — the lens for deciding whether 4K is what you actually want, and if it is, the four things to check.

The short answer — 4K isn’t for everyone, pick by use case

Short answer: a 4K monitor is for people who do photo or video editing, watch 4K content, or want a wider workspace on a 28-inch-or-larger panel. For text-heavy work or light gaming, WQHD is the better value.

Three reasons:

You can’t feel the difference on a small panel — at 27 inches or below, scaling becomes mandatory, and 4K’s pixel density gets thrown away
GPU load jumps — for games and real-time 3D, the rendering cost more than doubles going from FHD to 4K
You also need newer cables and ports — HDMI 2.0a or DisplayPort 1.4 minimum, and older PCs can’t output it

Conversely, 4K earns its keep when pixel density flows directly into the output — previewing photos at native resolution, checking 4K video footage 1:1, packing dense text onto a 28-inch-or-larger panel.

What 4K actually means

4K (UHD): 3840×2160 pixels. Double FHD (1920×1080) on each axis — four times the area. Note that “DCI 4K” (4096×2160, the cinema standard) is a different spec; almost every consumer monitor sold as 4K is the 3840×2160 UHD variant.

Comparison: how 4K, WQHD, and FHD differ

Short answer: higher resolution gives you more workspace, but it also raises GPU requirements, monitor price, and how much you have to fight scaling.

Aspect	FHD (1920×1080)	WQHD (2560×1440)	4K (3840×2160)
Day-to-day feel	No visible pixel grid at 24 inches. Fine for text-heavy work	Sweet spot at 27 inches. Runs at 100% scaling	28 inches or larger needed; below that, scaling is mandatory
Price range (27-inch IPS)	20,000–30,000 yen	30,000–50,000 yen	50,000–80,000 yen
GPU needed (gaming)	Entry-level GPU at 60fps	Mid-range required	High-end recommended
Best fit	Writing, office work, light gaming	Programming, streaming, esports	Photo/video editing, large displays, film viewing

Prices reflect my read of Japanese retail as of May 2026. They move with the exchange rate and product cycles, so check again at purchase time.

Four things to check when picking a 4K monitor

Short answer: once you’ve decided on 4K, check screen size, HDR support, color coverage, and panel type. The HDMI cable is a separate after-purchase trap worth knowing about.

If any of those four are off, you end up with “I bought 4K but it doesn’t feel any different” — which is the failure mode this section is built to prevent. One at a time below.

Screen size: 4K pays off at 28 inches and up

Short answer: to get value from 4K’s pixel density, go 28 inches or larger. Below 27 inches you’re forced into scaling, and the upside thins out.

The reason: 4K packs four times FHD’s pixels, but on a physically small panel those pixels get so small the text becomes unreadable. You end up turning on OS-level scaling to bring it back to a legible size — and once scaled, the “more workspace” upside evaporates.

A concrete example: a 24-inch 4K at 100% scaling has text too small for daily use. Push it to 150% and the effective resolution lands near WQHD — at which point WQHD would have been the simpler call.

Size target: 28 to 32 inches for desktop use. Past 35 inches you start approaching living-room TV territory, which is too large for a close-up desk setup.

Note: laptop displays are a separate conversation

Picking 4K on a 13–15-inch laptop only makes sense if you’re after Retina-style sharpness for its own sake. The workspace doesn’t grow.

HDR: useful for film and games, not for documents

Short answer: HDR widens the brightness range, especially in dark scenes. It pays off for video and games; for document work, the benefit is thin.

The reason: HDR (High Dynamic Range) handles a wider span between the darkest and brightest values than standard signal. The difference shows up in night-sky shots and in backlit scenes where bright and dark sit in the same frame.

For example, on a non-HDR monitor a dark scene crushes to black and you can’t tell what’s on screen. On an HDR10 panel the same scene reads — you can make out the shape of objects in the shadows.

How to read the spec sheet: look for “HDR10”, “HDR10+”, or “Dolby Vision”. No mention means no support. Be careful with “HDR Ready” or “HDR Compatible” — those only mean the monitor accepts an HDR signal, not that it can actually display HDR meaningfully.

Note: HDR also needs OS and content support

Even with an HDR monitor, Windows HDR settings and the content itself both have to be HDR-aware. Miss either and the feature doesn’t engage.

Color coverage: aim for 90% or higher for creative work

Short answer: for photo, video, or illustration, target sRGB 100% or roughly 90% on NTSC / Adobe RGB. For text work it doesn’t matter much.

The reason: color coverage (the gamut) is the range of colors a monitor can actually display. On a low-gamut panel, what should be a vivid red or green comes out muted.

A concrete example: editing photos on a cheap monitor that covers only sRGB 70% often results in “the version everyone else sees” being more saturated than what you edited. Reviewing on the wider-gamut side is the safer move.

How to read the spec sheet: figures like “sRGB coverage 100%”, “Adobe RGB 90%”, or “NTSC 90%” expressed as percentages. No percentage listed usually means the panel isn’t wide-gamut.

Panel type: IPS for text, photo, and video; TN or OLED for competitive gaming

Short answer: for general use, IPS is the default. Wide viewing angles, minimal color shift. Only consider TN or OLED when response time is the top priority for competitive games.

The reason: IPS holds its color when viewed off-axis, which is what you want for photo and video review. TN responds faster but has narrower angles and washed-out color. VA is strong on blacks but slower to respond.

For example, in a dual-monitor setup with one panel angled inward, a TN monitor visibly shifts color across the screen depending on the angle. An IPS panel keeps the tone consistent across both.

OLED has become a real option

In 2021 I’d have said OLED monitors barely existed. As of 2026 you can find 27-inch-class OLED desktop monitors in the 100,000-yen range. Blacks and response time beat IPS, but burn-in remains a risk — worth thinking about if you leave static text on screen for long stretches.

The trap: HDMI cable and DisplayPort spec

Short answer: for 4K HDR at 60Hz, you need HDMI 2.0a or higher, or DisplayPort 1.4 or higher. With an older cable, the signal silently drops back to FHD.

The reason: HDMI and DisplayPort tie supported resolution, refresh rate, and color depth to the version of the spec. And cables don’t advertise their version on the outside.

Signal	Required spec
4K 60Hz SDR	HDMI 2.0 / DisplayPort 1.2
4K 60Hz HDR	HDMI 2.0a / DisplayPort 1.4
4K 120Hz HDR	HDMI 2.1 / DisplayPort 1.4 (DSC)

Even the cable in the monitor box doesn’t always meet the spec the monitor itself is rated for. If colors look washed out or the resolution caps at FHD straight out of the box, suspect the cable and the PC’s output port before anything else.

Recommended models (by use case)

The picks below were selected when this article was written. From a 2026 vantage point, always verify the current successor or an equivalent model in the same price band before linking.

sRGB 100%, for text and photo work — I-O DATA 27-inch 4K

Covers sRGB 100%, so it holds up for photo color checks. A 27-inch 4K with a matte finish, so desk-lamp reflections don’t get in the way. VESA-compatible for swapping onto a monitor arm.

Spec	Value
Size	27 inches
Panel type	ADS (IPS-equivalent)
Resolution	4K (3840×2160)
Surface	Matte
Color coverage	sRGB 100%
HDR	HDR10
VESA	Yes

Around NTSC 90%, for video and film editing — I-O DATA 28-inch 4K

NTSC 88%, tuned toward the video-editing gamut. The 28-inch size also lets 4K’s density actually breathe.

Spec	Value
Size	28 inches
Panel type	IPS
Resolution	4K (3840×2160)
Surface	Matte
Color coverage	NTSC 88%
HDR	HDR10
VESA	Yes

FAQ

Q. Who actually needs a 4K monitor? A. People doing photo or video editing, watching 4K content, or wanting more workspace on a 28-inch-or-larger screen. For text-heavy work or competitive gaming, WQHD is enough.

Q. Do I need to use scaling on a 4K monitor? A. On both Windows and macOS, 4K at 27 inches or below all but requires 125–150% scaling. If you’re going to scale anyway, WQHD often looks cleaner out of the box.

Q. 21:9 ultrawide or 16:9 4K — which is better? A. If you want more horizontal workspace, a 21:9 WQHD-class panel (3440×1440) is easier to live with. If you want vertical room and pure pixel density, 16:9 4K. Pick by use case.

Q. Which HDMI cable should I use? A. HDMI 2.0a or higher for 4K HDR; HDMI 2.1 for 4K at 120Hz. The cable in the monitor box doesn’t always meet that spec, so check before you blame the monitor.

Wrapping up

A 4K monitor is gear for people whose output benefits from pixel density. If that’s you, check four things — 28 inches or larger, HDR, around 90% color coverage, IPS — and you’ll land somewhere reasonable.

If it’s not you, WQHD wins on price, GPU load, and avoiding the scaling fight. The starting question is less “should I buy 4K” and more “does my actual work want that density”.

How to pick a display tablet — decide on four things: 14–16 inch size, color gamut, response time, and parallax

Thu, 18 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The framework — what to look at when choosing — still holds, but the specific specs and price ranges are anchored to the 2021 market. Newer models have improved on the numbers, so check each manufacturer’s current spec sheet before buying. The numbers are the manufacturer’s published figures from the original writing; current official specs may differ.

Display tablets (LCD tablets, or “liquid tablets” in the Japanese shorthand) have become a much more realistic upgrade from a pen tablet over the last few years. Compared to the days when Wacom was the only serious option, XP-Pen and HUION have widened the field, and the price range now stretches in both directions.

The problem is that more options make it harder to see which one to actually buy. This piece sorts out what to look at when picking a display tablet, and how it stacks up against a pen tablet and an iPad.

The short answer — decide on four things: size, color gamut, response time, and parallax

Short answer: a display tablet comes down to these four points. The rest of the spec sheet is nice-to-have.

Size: 14–16 inches (the balance between drawing comfort and how much desk it eats)
Color gamut: around Adobe RGB / NTSC 90% if you output to print, around sRGB 100% if you stay web-first
Response time: around 14–25 ms
Parallax: pick a fully laminated panel

Put differently: whether the brand is Wacom, or whether the pen has 8192 pressure levels, does not move the needle the way these four do. Current-generation display tablets all ship with 8192 levels or more as a baseline.

By use case — compare against a pen tablet and an iPad before deciding

Short answer: a display tablet is not always the right answer. A pen tablet and an iPad each have things a display tablet does not.

”I want to draw like on paper” → display tablet

Putting the pen directly on the screen is the core value of a display tablet. The benefit is largest if you are coming from analog drawing, or if your work is line-heavy.

The trade-off is cabling — a display tablet is not built to be carried around. Assume it lives on your desk permanently.

”Cheaper start, less arm fatigue” → pen tablet

A pen tablet (the kind with no screen) puts your hand and the screen in different places, which takes adjustment. Once you adjust, you can draw without lifting your arm, and long sessions are noticeably less tiring.

The price is also a third to a fifth of a display tablet (comparing same brand and same size). If you are just starting out or working within a budget, a pen tablet is enough.

”I want to draw away from the desk, and I already have an iPad” → iPad + Apple Pencil

An iPad plus Apple Pencil is, in practice, a display tablet you can carry. Procreate and Clip Studio Paint for iPad have matured considerably.

The weak spot is software — some PC-only tools, like Photoshop, are not available in the same form. Fitting the iPad into a PC-based workflow takes extra steps.

Reading the spec sheet — what each number actually does

Short answer: numbers on a spec sheet say very little in isolation. Read each one in terms of what it changes for your way of working.

14–16 inches is the sweet spot

Bigger is easier to draw on, but desk footprint and price scale up roughly in proportion.

Size	Approx. width × height	Suits
Up to 13 inches	~28 × 17 cm	Portable use, secondary machine
14–16 inches	~31 × 20 cm	Most illustration and manga work
21 inches and up	~47 × 27 cm	Commercial work, larger desks

Under 13 inches gets cramped for long sessions. 21 inches and up means moving your arm more, and prices push past 100,000 yen.

Color gamut is chosen by where you output

Color gamut (Adobe RGB / NTSC / sRGB coverage) tells you how much of the real-world color range the panel can reproduce.

Output to print: Adobe RGB or around NTSC 90%. The print color space is wider than sRGB, so if you do not match here, the file you deliver and the printed result will not line up
Web and social mainly: sRGB 100% is enough. An Adobe RGB panel viewing sRGB material can actually make colors look washed out

“Pick wide gamut when in doubt” is a common line, but if your output is web-first, it is over-spec.

Response time at 14–25 ms is fine for drawing

Response time affects how quickly what you do with the pen reaches the screen.

Response time around 14–25 ms
Report rate of 200 RPS or higher is standard on current models

Older models slower than this turn drawing lag into wobbly lines.

A fully laminated panel kills parallax

Parallax is the effect where there is a gap between the glass surface and the light-emitting layer, so the tip of the pen and the line on screen appear slightly offset.

Models labeled “full lamination” or “laminated” have shrunk that gap to near-zero. Used units and very cheap models sometimes still skip the lamination, so check the spec section of the product page.

Comparison: display tablet vs pen tablet vs iPad

Short answer: “desk-based with a paper feel” goes to the display tablet, “budget and long sessions” goes to the pen tablet, “portability” goes to the iPad.

Aspect	Display tablet	Pen tablet	iPad + Apple Pencil
Price range	40,000–100,000 yen	10,000–30,000 yen	100,000 yen and up (body + pen)
Drawing feel	Directly on screen	Hand and screen separated	Directly on screen
Portability	× Too many cables	△ The slab itself is light	◯
Long sessions	Tiring (arm raised)	Easiest once you adjust	Depends on iPad weight
Software	Full PC apps	Full PC apps	iPad versions only
Up-front cost	Mid to high	Low	High

The strength of a display tablet is that you draw directly on the screen and still run your PC apps unchanged. It looks like the best of both worlds against a pen tablet and an iPad, but you pay for it in price and desk space.

Recommended specs — the 15.6-inch workhorse class

The specs below were the configuration the author picked at the time of writing (2021). As of 2026, the same money buys equivalent or better; map these requirements onto a current model.

Item	Spec
Size	15.6 inches
Panel	IPS
Resolution	Full HD (1920 × 1080)
Color gamut	NTSC 88%
Response time	14 ms
Lamination	Yes
Tilt detection	Yes

This class hits all four requirements (size, color gamut, response time, parallax) while keeping price under control. The author uses a model in this configuration.

FAQ

Q. Does it have to be Wacom? A. No. Wacom is rated highly for stability and driver polish, but current XP-Pen and HUION models are in usable territory. It comes down to whether you can absorb the price difference, and how much you weigh support and warranty.

Q. Is upgrading from a pen tablet to a display tablet worth it? A. The “hand and screen don’t track” feeling goes away, which is a real win. On the other hand, drawing with your arm raised gets tiring on long days, and the cabling clutters the desk. If a pen tablet is not slowing your work down, there is no urgency to switch.

Q. How many pressure levels do I need? A. Current models are all roughly tied at 8192 levels or more. It is rarely the number that decides between two machines. Prioritize color gamut and parallax instead.

Q. If I have an iPad Pro, do I still need a display tablet? A. Depends on what you do. If your drawing finishes inside iPad apps, you do not need one. If you also run PC-only tools like Photoshop or After Effects, a display tablet’s tie-in to a PC workflow still earns its place.

Wrapping up

The axis for picking a display tablet is four things: 14–16 inch size, color gamut chosen by where you output, response time around 14–25 ms, and a fully laminated panel to kill parallax. The rest of the spec differences do not move the drawing experience much.

On top of that: “desk-based, running PC apps as-is” goes to a display tablet, “budget and arm fatigue” goes to a pen tablet, “portable” goes to an iPad. Pick by use case.

There is a separate piece on picking a monitor for illustration; it is worth a look if you want to think about the display side at the same time.

Related: How to pick a monitor for illustration

How to pick a monitor for illustration — three things to check: color gamut, panel type, and size

Wed, 17 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The framework — what to look at when choosing — still holds, but the product specs, prices, and tool UI are anchored to 2021. The specific product links need to be swapped to current models before publishing.

Pen tablet and display tablet prices have settled, and more people are pairing them with an external monitor. The trouble is that shelves at consumer electronics stores mix gaming and 4K HDR units in with everything else, and it is hard to tell which ones are aimed at illustration.

This piece narrows the decision to five things to look at when picking a monitor for illustration work. Gaming and photo-retouching edge cases are dropped, and the focus is on long drawing sessions paired with a pen tablet or display tablet.

The short answer — five things to check; skip gaming and 4K HDR

Short answer: for an illustration monitor, five things are enough — color gamut, panel, size, surface, and VESA. The high refresh rates and HDR aimed at gaming do not help with illustration work.

The reason is that two axes matter for illustration: how the colors look, and how easily the eyes hold up over long sessions. Paying for motion smoothness (refresh rate) or contrast (HDR) does not raise the quality of your line work or color fills.

Five points to check:

Color gamut: depends on where you publish (web-first vs. print included)
Panel type: IPS (or an equivalent like ADS)
Screen size: 22–24 inches
Surface finish: non-glossy (matte)
VESA support: required if you use a monitor arm now or might later

Put differently: a general-purpose monitor that does not advertise itself as “for illustration” is perfectly usable, as long as it ticks these five boxes.

Decide the color gamut by who you draw for

Short answer: target sRGB 100% if you mostly publish online, or around Adobe RGB / NTSC 90% if print is part of the workflow. Wider gamut is not automatically better.

The reason is that the gamut on the viewer’s side is all over the map. If the audience is looking at sRGB-class phones and monitors, anything you draw in Adobe RGB largely lands as a compressed-to-sRGB version once it reaches them.

Web-first: sRGB 100%

For illustrations posted to the web, social media art, and stream thumbnails, it is realistic to assume the viewing environment is sRGB. If the spec sheet says “sRGB 100%”, or nothing in particular (standard color), that is enough.

Print, doujinshi, or merchandise: around Adobe RGB / NTSC 90%

Print is reproduced in CMYK, but a monitor with a gamut close to Adobe RGB makes it easier to spot differences during pre-submission checks. On the spec sheet, look for “Adobe RGB coverage around 90%” or “NTSC ratio around 90%”.

If you also use a display tablet, split the roles

If you use a display tablet, put the higher-color-fidelity model on the tablet side and keep the desk-side external monitor in a regular sRGB tier. That split matches both the budget and the way most viewers will actually see the work.

Panel type: IPS (or an equivalent like ADS)

Short answer: for illustration work, go with an IPS panel. The viewing angles and color stability suit the long looking-at-the-screen of pen work.

The reason is that TN panels are tuned for response time, and the color shifts noticeably when your eye line moves up or down. Resting a tablet on your lap, propping your chin on the hand holding the pen — when the color drifts under those postures, retouching judgments drift with it.

The “ADS” panel used by I-O DATA and others has characteristics equivalent to IPS, so anything listed as “ADS / IPS-class” on the spec sheet is a candidate. VA panels lean toward contrast and suit photos and video; for the edge clarity of line work, IPS is easier to deal with.

Screen size: 22–24 inches

Short answer: the 22–24 inch range is the mainstream tier and balances price, footprint, and working area.

The reason is that 27 inches and up adds eye-line travel and tires the eyes faster, and the price steps up too. Below 21.5 inches the working area gets cramped, and putting palettes and a layer panel onscreen squeezes the drawing canvas.

Rough physical sizes (assuming 16:9):

23.8 inches: about 53 cm wide / 30 cm tall
21.5 inches: about 48 cm wide / 27 cm tall

Things to confirm before placement:

Is the desk at least monitor width + 5 cm wide (some bezels are thick — leave headroom)
Is the depth at least 20 cm, counting the stand’s foot
Can you keep a viewing distance of 50–70 cm

Surface: non-glossy (matte)

Short answer: pick non-glossy for long drawing sessions. Glossy surfaces catch room lighting and your own reflection, which gets in the way of judging lines.

The reason is that illustration work means staring at the same screen for hours, and the tiny eye-line corrections forced by reflections add up to fatigue over a session.

The upside of glossy is more vivid color and tighter blacks. That suits photo viewing and video, but the trade-off does not work for pen tablet work.

VESA support: the prerequisite for a monitor arm

Short answer: if you use a monitor arm now, or might later, pick a model with a VESA mount. Without VESA support, you cannot retrofit an arm.

The reason is that monitor arms mount to the VESA standard (commonly 100×100 mm). A non-VESA model with a built-in stand limits how freely you can reclaim desk space and adjust height.

If you want the display tablet closer to you on the desk, lifting the external monitor on an arm makes the depth of the desk usable again.

Illustration-grade vs. general-purpose monitors

Here is what matters for illustration work side by side with what is common on general-purpose monitors.

Aspect	Recommended for illustration	Typical general-purpose / gaming
Color gamut	sRGB 100% or above (Adobe RGB 90% if print is in scope)	About sRGB 95% is enough
Panel type	IPS / ADS	TN (gaming) / VA (general) common
Screen size	22–24 inches	24–27 inches
Surface	Non-glossy	Glossy is on the menu
Refresh rate	60 Hz is enough	144 Hz and up (gaming)
HDR	Not needed	Useful for video and games
VESA support	Nice to have	Depends on the model

Candidate models (reference)

The models below were the reference picks at the time of writing. Always check successor models or equivalent units in the same price band.

sRGB 100% tier — PHILIPS 23.8 inch

Item	Spec
Size	23.8 inches
Panel	IPS
Resolution	Full HD
Surface	Non-glossy
Color gamut	sRGB 102%
VESA	Supported

sRGB 102% / 23.8 inches / IPS / non-glossy — clears the five points.

Adobe RGB / NTSC 90% tier — I-O DATA 23.8 inch

Item	Spec
Size	23.8 inches
Panel	ADS (IPS-class)
Resolution	Full HD
Surface	Non-glossy
Color gamut	Adobe RGB 90%
VESA	Supported

Adobe RGB 90% / 23.8 inches / ADS / non-glossy. The pick if print is on the horizon.

FAQ

Q. Do I need a 4K monitor for illustration work? A. No. A piece drawn at Full HD does not gain resolution by being shown on a 4K display, and the UI shrinks enough that you end up scaling things back up. 4K pays off more for photo retouching and video editing; for pen tablet work centered on illustration, Full HD is plenty.

Q. Should I buy a color calibrator? A. If print submissions or commercial work are an ongoing part of the workflow, it goes on the candidate list. For hobby work or social-media-first publishing, an sRGB 100% monitor at factory settings is a fine starting point, and a calibrator can wait until you actually feel the need.

Q. Can I use a gaming monitor for illustration? A. If the panel is IPS, the surface is non-glossy, and the gamut is around sRGB 100%, it can pull double duty. The high refresh rate and fast response time do not raise illustration quality though, so the question becomes whether the price premium is worth it for you.

Q. Is drawing on a laptop’s built-in display unworkable? A. As a starting point, it is fine. But mobile-class built-in panels often have a narrow gamut (some models sit in the sRGB 60–70% range), and adding an external sRGB 100% monitor takes the wobble out of long-term color judgments.

Wrapping up

For an illustration monitor, look at five things:

Color gamut decided by where you publish (sRGB 100% for the web / around Adobe RGB 90% if print is in scope)
Panel: IPS / ADS
Size: 22–24 inches
Surface: non-glossy
VESA support

Gaming-grade 144 Hz, HDR, and 4K resolution contribute almost nothing to illustration quality. If you want to keep the price down, drop those and pick from the mainstream tier.

If you use a display tablet, the cleanest split is to put the higher-color-fidelity model on the tablet side and keep the external monitor close to what the audience will actually see.

How to pick a PC monitor — three things you can't get wrong, plus one to taste

Mon, 15 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. The backbone — the three things to look at — still holds, but the product picks and price ranges are anchored to 2021. Verify current prices and model numbers, and swap the links to the latest equivalents.

Remote work settled in, and more people are adding a PC monitor at home. What sits on the shelves at electronics stores runs from under 10,000 yen to well past 100,000 yen, and it’s hard to tell what to compare against what.

For long office-style use, the call comes down to three things: panel type, size, and surface finish. Built-in speakers belong in the “to taste” column, and most of the time you can skip them.

The short answer — three things to get right, plus one to taste

Short version: you don’t need to compare brands or chase fine-grained specs. Tick these three boxes and you’re unlikely to end up with a monitor that gets in your way at work.

Panel type: IPS (image quality) or VA (price)
Size: 22–24 inches
Surface finish: matte (non-glare)

The “to taste” addition is whether the monitor has built-in speakers. If shaving one cable off the desk matters, fine; if you care about sound, buying a separate speaker is the more honest call.

Brand doesn’t matter much. The quality gap between makers has narrowed in recent years, and as long as you can handle the rare initial defect, the real-world impact is small.

Pick the panel type by budget — VA or IPS

Short version: VA if price comes first, IPS if you want the image to look better. Pick between these two and your panel-type decision is done for office use.

The reason: most of what you actually notice about how a monitor looks comes from the panel type. Numbers like response time and color gamut don’t translate into a felt difference unless you game or edit photos.

The price gap runs roughly 10,000–20,000 yen from VA to IPS. If you’d rather not gamble, IPS is the safer pick.

VA — cheap, with deep blacks

VA tends to be the cheapest tier at any given size. Black levels are strong, which suits video with a lot of dark scenes.

The weakness is viewing angle. Step off-axis and colors wash out, so it’s not a great fit for TV duty or for more than one person looking at the screen. Sitting alone, square to the panel, you won’t notice.

IPS — clean color, wide viewing angle

IPS holds color more reliably. Colors don’t fall apart when viewed from the side, which helps when more than one person is looking, or when the layout of your desk puts you at an angle to the monitor.

It costs around 10,000–20,000 yen more than VA. If this is the screen you stare at all day for work, that markup is easy to feel.

VA vs IPS at a glance

Aspect	VA	IPS
Price	Cheap	A bit higher
Blacks	Deep	Average
Viewing angle	Narrow (head-on)	Wide
Color stability	Drifts a bit	Stable
Best fit	One person head-on, price first	Work, multiple viewers, layout freedom

Size — 22–24 inches, the office sweet spot

Short version: 22–24 inches sits well on a desk and keeps text readable. Smaller gets cramped; bigger starts to crowd the desk.

The reason: 22–24 inches lands at roughly 49–53 cm wide and 27–30 cm tall, which plays well with the depth of a typical PC desk. It’s also the size band offices and schools standardise on.

Before you set it on your desk, measure the spot with about 5 cm of slack on top of the panel width. Recent models have thin bezels, but older models and business units can have thick ones, so always check the listed exterior dimensions on the product page.

”Bigger is better” is a separate question

27 inches and up looks tempting because of the extra screen real estate. But sit too close and you’ll move your eyes more, not less, and it gets tiring. If your desk depth is under 60 cm, start at 24 inches and see how it feels.

Surface finish — matte (non-glare)

Short version: for office use, matte is the only sensible pick. Glossy panels pick up reflections from lights and windows, and long sessions wear on your eyes.

The reason: a glossy surface reflects ambient light, which pushes you to crank the brightness. Higher brightness loads your eyes more. Phones use glossy screens because they’re built for short bursts outside, which is a different problem from sitting at a desk all day.

Unless you’re doing final photo or video review at home, you’ll never regret picking matte.

Built-in speakers — usually unnecessary

Short version: monitor speakers tend to sound mediocre. A laptop or external speaker is going to leave you happier.

The reason: built-in speakers are constrained by how thin the chassis is, and at price-conscious tiers there’s not much room to tune them. For “I just need voices to come out” — meeting audio, for example — they’re fine. For sitting down with music or video, they’re weak.

Who built-in speakers fit, and who they don’t

You’d like one less cable on the desk; meeting audio is enough → built-in is fine
You listen to music or video regularly and care about sound → skip built-in and buy a separate speaker

A few-thousand-yen USB or Bluetooth speaker usually beats a built-in one.

Spec targets that meet the criteria

These are not specific product names but spec targets — “pick a model that meets these.” Verify actual products and prices at purchase time.

IPS — 23-inch class

The entry-tier target that ticks 23-inch, IPS, and matte. If you want decent image quality without spending more than you need to, use this spec as your baseline.

Item	Spec
Size	23 inches
Panel type	IPS
Resolution	Full HD
Surface	Matte
Speakers	None
VESA mount	Not supported

No VESA mount, so if there’s any chance you’ll want a monitor arm later, look at a different model.

VA — 23.6-inch class

23.6-inch, VA, matte, with VESA support. The target when you want to keep the price down and leave room to add a monitor arm later.

Item	Spec
Size	23.6 inches
Panel type	VA
Resolution	Full HD
Surface	Matte
Speakers	None
VESA mount	Supported

FAQ

Q. Full HD or 4K? A. For office use at 23–24 inches, Full HD is plenty. 4K starts to earn its keep at 27 inches and up, but it brings display-scaling and GPU-load tradeoffs. For a first monitor, Full HD is the safer call.

Q. Are curved monitors good for work? A. They help if you sit alone, head-on, and want wide screen real estate or multiple windows side by side. For text-heavy office work the benefit is small and the price is higher. As a first monitor, flat is enough.

Q. Anything to watch when connecting to a laptop? A. Match the laptop’s video output (HDMI, DisplayPort, or USB-C) to the monitor’s input. A model that handles power and video over a single USB-C cable cuts down the clutter and feels noticeably tidier.

Q. Do I need a monitor arm? A. Not required, but it helps a lot when desk depth is shallow or when you want to adjust height. If there’s any chance you’ll add one later, pick a VESA-compatible monitor up front.

Wrapping up

For an office-use PC monitor, three axes — panel type, size, and surface finish — get you most of the way there.

VA if price comes first, IPS if image quality does. Size at 22–24 inches, surface matte. Built-in speakers are usually unnecessary; if you need sound, buying a separate speaker leaves you happier.

People who care deeply about image quality, or who want to push response times for gaming, have their own way of choosing. Outside of those cases, these three things are enough to avoid the bad picks.

Publishing a blog with VuePress — the 2021 roadmap, and the parts still worth keeping in 2026

Sun, 14 Mar 2021 00:00:00 GMT

2026 update: A post ported from the old VuePress blog. The procedural screenshots are from 2021, and the Netlify / Onamae.com UI has shifted since. VuePress 1.x itself isn’t suited to greenfield builds anymore, so the body has been rewritten in two layers: “a 2021 build record” and “the four-layer roadmap you can still reuse”.

In 2021, Aulvem’s precursor blog was built on VuePress 1.x, with the source kept on GitHub, builds and delivery handled by Netlify, and a custom domain bought through Onamae.com pointed at the whole thing. I worked through it while reading the usual “publish a blog for free” articles, but it took a while before the big picture of “what was happening where” clicked for me.

This post leads with the thing my past self would have wanted first: the overall roadmap and the responsibility of each step. VuePress 1.x isn’t a serious option for new builds anymore, but the roadmap itself ports cleanly over to an Astro + Cloudflare Pages setup.

The VuePress directory layout itself is split out into a separate post (VuePress/blog directory structure — a 2021 build note). This one focuses on “the sequence of getting the whole site published”, not “the contents of individual files”.

The short answer — break it into four layers and clear one at a time

Short answer: the fastest way to get a VuePress blog live on a custom domain is to break the work into four layers — (1) local dev, (2) put the source on GitHub, (3) let Netlify auto-build and serve it, (4) delegate the Onamae.com nameservers to Netlify — and clear them one by one.

The reason is separation of concerns. Cramming everything into one service makes it hard to tell where a failure occurred. Putting “write”, “store”, “build”, and “publish” on separate layers makes triage easier when something breaks.

The whole picture looks like this.

[Local PC]
   │ git push
   ▼
[GitHub] ──── source of truth
   │ webhook
   ▼
[Netlify] ──── build & static delivery (xxx.netlify.app)
   │ DNS (nameserver delegation)
   ▼
[Onamae.com domain]
   │ served on the custom domain
   ▼
[Readers]

A caveat: these four layers aren’t VuePress-specific. Astro, Hugo, or any other SSG that converts Markdown to static HTML and serves it lines up the same way. The VuePress-specific parts only show up in the build commands of (1) and (3).

Glossary: SSG and Jamstack — the assumptions this roadmap rests on

SSG (Static Site Generator): A generic term for tools that convert Markdown or JSON to static HTML at build time. VuePress, Astro, Next.js (output:static), Hugo, and Jekyll all qualify. It pairs against the CMS pattern (WordPress and friends) where the server assembles the page dynamically per request.

Jamstack: An acronym from JavaScript / APIs / Markup (pre-built static files). It refers to a setup where SSG-generated HTML sits on a CDN and any dynamic logic is supplied by external APIs. Netlify is hosting designed around this Jamstack assumption.

This roadmap only works because the output is “just static files”. The simplicity of “put the source on GitHub, let Netlify rebuild it and push it to a CDN” leans on the Jamstack premise.

Step 1 — Develop and write the VuePress project locally

Short answer: in the local-development phase, write Markdown and Vue components with hot-reload via vuepress dev src.

The reason is iteration speed. Fixing things locally is an order of magnitude faster than redeploying. Build times were short too, so an “edit while you write” workflow was realistic.

Concretely, I developed against this layout.

src
├─ _posts                   Markdown for each article
│  └─ category
│     └─ page.md
└─ .vuepress
   ├─ components            Article-side components (Vue)
   ├─ public                images and robots.txt
   ├─ theme                 layouts / components / styles
   ├─ config.js             VuePress core configuration
   └─ enhanceApp.js         Vue plugin entry point

A two-way split: _posts/ for articles, .vuepress/ for framework configuration and theme. The details are in VuePress/blog directory structure.

A caveat: during development, vuepress dev src --host 0.0.0.0 --port 8080 lets you open the site from another device on the LAN to check the phone view. Markdown layouts tend to get sloppy if you only ever look at them on a desktop.

Step 2 — Create a GitHub repo and push the source

Short answer: in the “push to GitHub” phase, create an empty repo, then push only the source from local with git remote add and git push -u origin main.

The reason is separating source from build output. Committing dist/ or node_modules/ bloats history and undermines the whole point of letting Netlify rebuild on its side.

Concretely, I excluded the following via .gitignore.

node_modules/
src/.vuepress/dist/
src/.vuepress/.cache/
src/.vuepress/.temp/
.env
.env.local

Netlify rebuilds the build output every time, so the repository only needs src/ and package.json / package-lock.json.

A caveat: if you’re going public, don’t accidentally commit API keys or access tokens. At the time I went back and forth on whether to put secrets in GitHub Secrets or Netlify environment variables — the conclusion I landed on was “values only used at build time go on the Netlify side, and anything that could leak at runtime shouldn’t exist at all”.

Step 3 — Connect the repo to Netlify and let it auto-build

Short answer: in the Netlify connection phase, go through Add new site → Import an existing project, pick the GitHub repo, and fill in the build command and publish directory.

The reason is webhook-driven automation. Netlify detects each git push to GitHub and re-runs vuepress build against the latest source. The old “manual npm run build then FTP to a server” flow disappears entirely.

The concrete settings were these.

Setting	Value
Branch to deploy	`main`
Build command	`vuepress build src`
Publish directory	`src/.vuepress/dist`
Node.js version	14.x (pinned via the `NODE_VERSION` env var)

After signing into Netlify, the flow looked roughly like this (UI as of 2021).

Once you pick the repository, enter vuepress build src and src/.vuepress/dist in the build settings and the deploy kicks off.

A caveat: the first build often fails because of Node version mismatches. Pinning NODE_VERSION to something like 14, or dropping a .nvmrc at the repo root, cuts the accident rate. The detailed walkthrough lives in Deploying a VuePress / static site to Netlify.

Step 4 — Buy a custom domain on Onamae.com

Short answer: in the domain-purchase phase, search for the domain name you want, pick “do not use” for the server option, and check out. There’s no need to bundle a server contract.

The reason is separation of concerns. Onamae.com’s job is “owning the domain”; hosting is Netlify’s job. You’ll usually be guided into bundling a server contract, but a Jamstack setup doesn’t need one.

The actual screen looked like this.

At the server selection step, pick “do not use” and proceed.

A caveat: always enable Whois privacy within its free tier — it keeps your personal information off the public Whois record. Renewal fees can be higher than the initial registration on some TLDs, so for long-term operation a standard TLD like .com / .net reads better later on.

Step 5 — Wire Netlify and Onamae.com together by delegating nameservers

Short answer: in the nameserver-delegation phase, on the Netlify side go through Add custom domain → Set up Netlify DNS, and paste the four nameservers it shows you into “Change nameservers” in Onamae.com Navi.

The reason is to centralize DNS management on Netlify. Once you delegate nameservers, Netlify takes over A / CNAME records and SSL certificate issuance (Let’s Encrypt). You no longer have to write records yourself on the Onamae.com side.

Open Domain settings from Netlify’s overview page.

Step through Add custom domain and you’ll eventually see the four assigned nameservers.

Sign in to Onamae.com Navi, open “Change nameservers” for the target domain, pick “use other nameservers”, and paste the four you noted down.

Propagation takes anywhere from a few minutes to about 48 hours. If the custom domain still doesn’t resolve after half a day, try accessing from a different network (mobile data, for example) to rule out DNS caching. The detailed caveats are split into Connecting an Onamae.com custom domain to Netlify.

A caveat: once you’ve delegated, stop touching Onamae.com’s DNS records screen. Netlify DNS is now the source of truth, so subdomain additions and MX records for email should all happen in Netlify’s DNS Records UI.

Comparison table — the 2021 VuePress setup vs. the 2026 Astro setup

The roadmap itself hasn’t changed, but the tools at each layer have rotated over the past five years. Aulvem itself has moved from VuePress to Astro.

Layer	2021: VuePress setup	2026: Astro setup (current Aulvem)
Local dev	VuePress 1.x + Node 14.x	Astro 5 + Node 20.x
Article schema	frontmatter (untyped)	content collections + zod schema
Git hosting	GitHub	GitHub
CI / build & delivery	Netlify	Cloudflare Pages
Domain registrar	Onamae.com	Onamae.com or Cloudflare Registrar
DNS management	Netlify DNS	Cloudflare DNS
SSL certificate	Let’s Encrypt (auto-issued by Netlify)	Cloudflare-issued automatically
Image delivery	served straight from Netlify	Cloudflare R2 + image optimization

The point isn’t that the newer side is “better” — it’s that the four-layer roadmap is unchanged and you only swap in different implementations per layer. The VuePress-to-Astro migration also progressed by carving things up layer-by-layer and replacing one at a time.

A caveat: Netlify is still a valid choice in 2026, and if you’re leaning on its own features like Forms / Identity / Edge Functions it’s still a top pick. Which beats which between Netlify and Cloudflare Pages depends on the use case.

FAQ

Q. Is there any point in starting a blog on VuePress 1.x today? A. I wouldn’t recommend it as a first pick for a new blog. VuePress 1.x is effectively unmaintained, so timely vulnerability patches in dependencies are unlikely. For a Markdown-centric static blog, Astro + content collections or VitePress is a better return on your learning time. If you have a personal reason to stay on Vue, VitePress is the candidate to look at.

Q. Do GitHub and Netlify really need to be split? A. Generally yes. GitHub is the source of truth for source code; Netlify is the delivery layer for built HTML — different responsibilities, so if one goes down the other survives. Some services like GitHub Pages or Cloudflare Pages combine both, and in those cases it’s fine to centralize. The Pages-style options come with constraints on CI customization, though, so if you want fine-grained control over the build pipeline, splitting them is easier.

Q. Can you still publish if you put off buying the domain? A. Yes. Netlify hands out a free xxx.netlify.app subdomain, so you can build and review content before paying for a custom domain. In practice, switching the domain over last is the safer order. Less chance of accidents that way than buying the domain first and then sitting on a long wait while you try to make the site work.

Q. If I were to build this in 2026, what would I swap in? A. My personal swap is VuePress to Astro, Netlify to Cloudflare Pages, and Onamae.com staying as-is (or moving to Cloudflare Registrar). The four roadmap layers — local dev, Git hosting, build and delivery, DNS — carry over unchanged. Put differently: if you only memorize the service names without internalizing the four layers, you’ll have to start over every time you move to a different service.

Closing

In the end, the fastest path to publishing a VuePress blog on a custom domain was to separate “where you write”, “where it’s stored”, “where it’s built”, and “where it’s served” into different layers, and clear them one at a time.

As of 2026 I don’t think many people are spinning up new VuePress 1.x builds. But the four-layer split — local, GitHub, build & delivery, DNS — is alive and well on an Astro + Cloudflare Pages stack today. The specific commands and screenshots age out, but the skeleton can be reused — I’m leaving this here as one example of that.

How to pick a laptop for blogging — a 50,000-yen entry model is enough; if you write away from home, weight and battery decide it

Sat, 13 Mar 2021 00:00:00 GMT

2026 update: ported from the old VuePress blog. Product picks are anchored to 2021 models, so the affiliate links need to be re-checked against the current line-up. The framework — what to look at when choosing — still holds.

The first thing that trips people up when starting a blog is: which laptop should I buy? Writing only on a phone gets old fast, and using a company-issued machine for personal work is a non-starter.

This piece walks through how to pick a laptop dedicated to blogging, using a single axis: do you write at home, or do you write on the move? By the end you should have a clear shape of the one machine that fits you.

The short answer — almost any model from the last five years works, but check three things

For blogging, you do not need a high-end CPU or a lot of RAM. Any laptop released in the last five years (counting from 2021) has more than enough headroom for writing.

Three things to confirm before you buy:

Where you write: mostly at home, or also on the move — this changes the weight and battery requirements
Keyboard layout: JIS (Japanese) layout — an English layout makes IME toggling clumsy
Screen size: 14 inches or more — anything under 12 inches makes long-form writing painful

Put differently: if those three boxes are ticked, a 50,000-yen entry laptop is plenty to write a blog on.

Where you write changes most of the spec sheet

Where you write decides about 90% of the choice.

The reason is simple: carrying the laptop around adds two hard constraints — weight and battery life — and both push the price up. If you stay at home, the constraints are loose, and the same budget buys you more performance.

Writing at home: weight and battery don’t matter

If home is the main writing spot, you can ignore both weight and battery life.

That frees the budget for screen size and CPU. A 15-inch class with a Core i3 or i5 lands in the 50,000–70,000-yen range, which is a comfortable spot.

Writing on the move: 1.5 kg or lighter, 12+ hours of battery

On the move, weight and battery feed directly back into how much you actually get done.

Rough targets:

Weight: 1.5 kg or under (lighter still if you walk a lot)
Battery life: 12 hours or more on the spec sheet
Screen size: 14 inches (the sweet spot between portability and working space)

Light models tend to cost 10,000–20,000 yen more than a heavier laptop with equivalent specs.

Always confirm the keyboard is JIS (Japanese) layout

Cheap laptops sometimes ship with US-layout keyboards mixed in. Confirm the layout before you order.

A US layout has no 全角/半角 key, which makes IME toggling a constant small friction. For long writing sessions it adds up.

How to check:

The spec sheet says “JIS” or “日本語キーボード”
The product photo shows a 全角/半角 key in the top-left of the keyboard

Screen 14 inches or more, with an external monitor if you can

Anything below 12 inches gets painful for long-form writing. Set 14 inches as the floor.

You end up juggling reference material, a preview pane, and the draft itself, often at the same time. On a cramped screen, just switching windows eats real minutes.

If home is the main writing spot, a laptop plus an external monitor is the single biggest jump in feel. Reference material stays open on one screen, and the draft has room to breathe.

Picks by use case

The models below were chosen in 2021. In 2026, verify the successor or an equivalent in the same price band before linking.

Writing at home — a 15-inch entry laptop

A 15-inch entry model in the 50,000-yen range is the first pick. A Core i3 is enough — for writing work, you won’t feel the performance ceiling.

Writing on the move — 1.5 kg, 14-inch class

Portability first. Around 1.5 kg, 14-inch screen, with a long battery life on the spec sheet.

Comparison: home vs on-the-go laptop

Aspect	Home	On the move
Weight	Doesn’t matter	1.5 kg or under
Battery	Short is fine	12 hours or more
Screen size	15 inches preferred	14 inches
Price range	50,000–70,000 yen	70,000–100,000 yen
External monitor	Adds real productivity	Not needed (you won’t carry one)

FAQ

Q. Can I blog on an iPad Pro? A. With a recent iPad Pro and an external keyboard, it’s doable. But once you account for the WordPress admin and image editing, a laptop is the safer long-term call.

Q. Mac or Windows? A. For blog writing alone, either is fine. Pick the OS you already use day to day — the smaller the context switch, the better.

Q. How much RAM do I need? A. 4 GB will technically run, but a browser with many tabs open starts swapping and things slow down. 8 GB is the safer floor.

Q. SSD or HDD? A. SSD, no contest. HDD models are slow to boot and slow to launch apps, and that drag wears on you daily.

Wrapping up

For a blogging laptop, almost any model from the last five years will work.

The decisions are three: home or on the move, the keyboard layout you actually type on, and a 14-inch-or-larger screen. With those settled, an entry-class machine in the 50,000–70,000-yen range carries a blog just fine.

If there’s room in the budget for an external monitor, the home-based setup steps up a level on day-to-day productivity.

PC cleaning with an air-duster can and an anti-static brush — Elecom ECO and Sanwa Supply brush review

Thu, 11 Mar 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The Elecom Air Duster ECO and the Sanwa Supply anti-static cleaning brush are both still current products, though prices and model numbers may have shifted. The review angles here (the strengths and weaknesses of the can, where the anti-static brush helps, and how to choose between cans and an electric duster) still hold up.

Dust inside a PC or around a keyboard, left alone, eventually clogs fans, drives thermal throttling, and makes key presses catch. A quick clean once a month makes a real difference to how long the hardware lasts.

This is a review of the Elecom Air Duster ECO and the Sanwa Supply anti-static cleaning brush — a combination I have been using for several years — compared against the three obvious alternatives: cans alone, electric dusters, and alcohol + cotton swabs.

The verdict — “can + anti-static brush” is fast and cheap

Short answer: for a light clean once or twice a month, blowing the big dust away with an air-duster can and brushing the detail with an anti-static brush is the best time-to-result trade-off. An electric duster makes more sense if you clean weekly.

The reasoning is straightforward. A can costs around 1,000 yen, so the entry cost is low, and the peak airflow often beats an electric duster. The anti-static brush lets you touch parts that can be damaged by static — CPU, memory, GPU PCBs — without worrying about it.

You may want a different setup if any of these apply:

You clean more than once a week: the per-can cost starts to add up. An electric duster is cheaper over time
You are sensitive to the gas smell or the room is hard to ventilate: switch to electric, or do it outside
The grime is greasy — oil, fingerprints, tar: air and bristles will not move it. You need anhydrous ethanol and cotton swabs alongside

Elecom Air Duster ECO — the package

Short answer: a standard spray-can size, with a red nozzle and a cap in the box.

I use it on the gaps between keys, inside a PC case, and at the vents of a laptop — anywhere a brush will not reach. At a roughly monthly cadence, one can lasts me about six months.

The red narrow nozzle ships taped to the can’s label. It snaps on when you need to focus the airflow into a tight gap.

A clear cap fits over the trigger button to prevent accidental firing inside a bag or drawer.

Elecom Air Duster ECO — what worked

Short answer: strong airflow, and a price low enough that you do not hesitate to use it.

Strong, immediate airflow

Pull the trigger and the air comes out in a single hard burst. Dust packed in keyboard gaps or around case fans clears in one short blast at close range.

I also have an electric duster, and on peak airflow alone, the can still feels stronger (depends on model and remaining gas).

Cheap enough to use freely

At roughly 1,000 yen a can, I can blow away a stray clump of dust without thinking about it. Not having to mentally save it up “for a proper clean later” matters more than it sounds.

Lower friction to start cleaning → higher cleaning frequency → longer hardware life. That feedback loop is the real value.

Elecom Air Duster ECO — what didn’t

Short answer: the gas smell lingers, and a single-use can means a running cost.

The gas leaves a smell

The propellant has a smell that hangs in the room for a while after use. Short bursts of one or two seconds are unnoticeable, but five seconds or more in a row and the smell builds up.

In a well-ventilated room it is a non-issue. Late at night in an apartment building, full-power cleaning is harder to justify.

Running cost piles up

A can is one-and-done. Once a month, six months a can — manageable. Once a week works out to four to six cans a year. At 1,000 yen each, that is 4,000 to 6,000 yen annually. An electric duster (around 10,000 yen) pays for itself in roughly two years.

I am still using cans, but if you clean heavily, the electric option is worth considering.

Sanwa Supply anti-static cleaning brush — the package

Short answer: a brush with anti-static construction, with a large head on one end and a small head on the other. Often sold in packs of three.

I use it to sweep dust off the inside of a PC. The handle is said to contain anti-static material that bleeds off any charge that builds up.

CPU, memory, and GPU boards can be killed by static. On parts where you would normally hesitate to brush with a synthetic-fibre brush, an anti-static brush gives you enough confidence to actually do the work. It saves you from the folk-remedy approach of “strip down and build the PC in the bathroom” (only half-joking).

The opposite end has a smaller brush for narrow spots — between heatsink fins, behind the I/O shield, around the base of SATA connectors. Anywhere the large brush cannot fit, this end takes over.

Sanwa Supply anti-static cleaning brush — what worked

Short answer: the anti-static design makes it easier to touch boards, and the small-brush end reaches into places the large one cannot.

Confidence near sensitive boards

You hear about bent CPU pins and broken memory; you hear less about static damage, but it is not rare either. An anti-static brush takes the “should I really be touching this?” hesitation off the table.

I have no way to measure how much risk it actually removes, but as insurance, it is worth keeping around.

The small brush reaches narrow spots

A PC’s interior is full of gaps too tight for a finger. The small brush is barely thicker than a toothpick, so the bristle tips can reach into heatsink fins and the base of connectors.

It also picks out the wad-of-lint kind of dust that the air-duster can never quite blows free.

Sanwa Supply anti-static cleaning brush — what didn’t

Short answer: the large brush end is a touch oversized.

The large brush is bigger than I want inside a case

Inside a PC case, a brush “a size or two smaller” would be easier to steer. Running it along a row of heatsinks on a motherboard, the bristle tips keep catching on the neighbouring connectors.

For keyboard cleaning the large brush is fine, so it is more a “use it for the right thing” comment than a real complaint.

Comparison: can + anti-static brush vs other cleaning methods

Angle	Can + anti-static brush (this pairing)	Alcohol + cotton swabs	Air-duster can alone	Electric air duster
Initial cost	Around 2,000 yen	From around 500 yen	Around 1,000 yen	From around 10,000 yen
Running cost	Disposable cans only	Consumables (swabs, ethanol)	Disposable cans	Electricity only
Best on	Dry dust in general	Grease, fingerprints, tar	Dry coarse dust	Dry dust in general
Anti-static	Yes (anti-static brush)	No	No	Depends on model
Noise	Hiss of the nozzle only	Quiet	Hiss of the nozzle only	Loud motor
Environmental load	Discarded cans	Low	Discarded cans	Low (reused for the life of the unit)
Gas smell	Yes	Alcohol smell	Yes	None

An electric air duster saves you the monthly cost of a can, at the price of a 10,000-yen initial outlay and noticeable motor noise. For a once-or-twice-a-month routine, cans are easier overall.

Greasy grime — finger oils on keycaps, tar baked onto fans — does not move with air. You need a separate step with alcohol and cotton swabs, or anhydrous ethanol, to wipe it off.

FAQ

Q. Should I buy an air-duster can or an electric duster? A. If you clean once or twice a month, a can is enough. If you clean weekly, or you have other gear that wants cleaning (cameras, instruments, 3D printers) and you can do it outside, the electric option becomes a candidate. The running-cost break-even point lands around two to three years (depends on use).

Q. I hear electric dusters have weaker airflow than cans. True? A. It depends on the model and how full the can is. A fresh full can hits a higher peak airflow, but as you use it, evaporative cooling chills the can and the airflow tails off. An electric duster keeps a steady output, so for long cleaning sessions it can be the easier tool.

Q. Do anti-static brushes actually stop static? A. Not completely. They are designed to bleed off charge through the handle material, but they are not a guarantee. Pair them with the basics: touch a grounded metal surface to discharge yourself before handling boards, and avoid cleaning during dry mid-winter days.

Q. If I blow air into a running PC, will it spin the fans hard enough to damage them? A. Spinning a fan past its normal speed with airflow can wear the bearing. The standard trick is to hold the fan still — with a finger, or the brush handle — before you fire the duster. Do the same for CPU-cooler fans.

Verdict — a “reasonably cheap, reasonably safe” combination

Short answer: for a light monthly clean, the can + anti-static brush combination hits the right balance of time, cost, and safety. Hard to beat as a default.

My internal-cleaning routine has settled into this:

Blow the big dust away with the air-duster can (hold the fans still with a finger)
Sweep what’s left off with the large brush
Finish into heatsink fins and around connectors with the small brush
Wipe greasy or fingerprinted spots with anhydrous ethanol on a cotton swab

Do this every month and the once-a-year deep clean comes around to “the inside isn’t really that dirty” — which is exactly the state you want.

When cleaning frequency creeps up, move to an electric air duster. When greasy grime starts to dominate, add alcohol to the kit. Layer the tools as the workload grows.

Logitech MX MASTER 2S review — the side wheel that fixes Excel horizontal scrolling

Tue, 09 Mar 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The MX MASTER 2S is an older model in 2026 — the current line is the MX Master 3S. The review angles here (side-wheel value, hand-size fit, gesture-button caveat) still hold up.

I used the Logitech MX MASTER 2S at work for over half a year. This is the write-up from that time, kept for reference.

It is the kind of mouse that feels expensive on the shelf — around 9,400 yen at the time of writing. If you spend your days in Excel or creative tools, the productivity gain pays the difference back.

The verdict — buy it if you live in Excel’s horizontal axis

Short answer: the side wheel makes horizontal scrolling so easy it becomes invisible. If you scroll vertically and horizontally all day in Excel or design tools, the price is justified.

The reason is mechanical. Operations that normally cost a “Shift + wheel” combo, or a drag to the edge of the window, collapse into a single flick of the side wheel. Multiply that by the hundreds of times a day you scroll, and the one-or-two-second saving adds up.

A few cautions before buying:

Smaller hands: the MX MASTER 2S is a large mouse, and there is only one size
Heavy gaming use: there is a known durability issue with the gesture button (covered below)

Build and feel

Short answer: a sculpted, monochrome body with a distinctive front taper. It looks like a premium tool, not a peripheral.

From the side it reads like a horizontal “H” — you grip it between thumb and pinky rather than draping your hand over it.

The underside holds the power switch and a device-pair toggle. It pairs with up to three devices.

The left flank carries the thumb rest with the gesture button, the side wheel, and two vertically stacked thumb buttons. Charging is over micro-USB Type-B — one of the model’s few real weak points.

What worked

Short answer: the side wheel is the headline. The shape and the button layout are quiet upgrades on every other mouse I had used.

The side wheel — Excel horizontal scrolling in one flick

This is the single biggest difference from any other mouse. A dedicated horizontal-scroll wheel sits on the left flank.

Horizontal pans in Excel, canvas panning in Figma, timeline scrubbing in a video editor — all of them resolve to one finger, no keyboard modifier.

Thumb buttons stacked vertically, easy to press

Most mice put the thumb buttons in a front-back layout and map them to Back and Forward. The MX MASTER 2S stacks them vertically. It feels strange for a day, and then you stop noticing — the two buttons are easier to tell apart by feel.

A design that does not stand out in an office

The matte, monochrome finish keeps it quiet on a desk. It looks at home in a home office or a meeting room without drawing attention.

What didn’t

Short answer: it is large, it charges over micro-USB Type-B, and the gesture button has a durability concern.

Sized for larger hands, with no smaller option

For me the grip was the most comfortable I had used. For smaller hands it is harder to recommend, and there is no smaller variant. If you can, hold one in a store before committing.

Charging is micro-USB Type-B

In 2026, USB Type-C is the default for peripherals. Charging happens every two or three months, so it is not a daily annoyance — it is just one more cable to keep around.

The gesture button is the weak link

This is the reason I eventually moved on from this mouse.

Mid-game, I pressed the gesture button with some force and it stuck in the pressed state. It is the kind of thing you could fix by opening the body, but I did not feel I had clicked it especially hard — the structure looks under-built for that kind of input.

If you tend to hammer buttons during long gaming sessions, take this seriously.

Comparison: MX MASTER 2S vs 3 / 3S

Angle	MX MASTER 2S	MX MASTER 3 / 3S
Charging	micro-USB Type-B	USB Type-C
Main wheel	Mechanical	MagSpeed (electromagnetic)
Side wheel	Yes	Yes (smoother)
Gesture button durability	Weaker	Improved
Price at launch	~9,400 yen	~13,000 yen and up

For a new purchase today, the current MX Master 3S is the easier recommendation. If you find a 2S secondhand or on clearance and do not lean on the gesture button, it still holds up in daily use.

The software (Logicool Options)

Logicool Options remaps almost every button on the mouse.

The gesture button can carry four directional actions — up, down, left, right — on top of its press action.

Wheel sensitivity and pointer speed are tunable in fine steps. You can, for example, dial the wheel scroll distance specifically for Excel sessions.

FAQ

Q. Does it work with a Mac? A. Yes. Logicool Options for Mac is available, and the mouse connects over either Bluetooth or the USB receiver.

Q. How long does the battery last? A. Logitech lists 70 days. In actual use I charged it every two to three months.

Q. Can it be used for gaming? A. Response-wise it behaves like an ordinary mouse. For FPS or other titles that need precise input, a dedicated gaming mouse is the better tool — and given the gesture-button concern, anything with violent clicking is best kept off this mouse.

Q. Does it connect to an iPad? A. Yes, from iPadOS 13.4 onward iPads support mice. Pairing happens over Bluetooth.

Verdict — a mouse for a specific kind of work

It is not a universal recommendation. For the right workload, though, it is hard to go back from.

In Excel, Figma, or a video editor — anywhere horizontal scrolling shows up constantly — the side wheel changes the day-to-day feel of the work.

The two things to weigh are the size and the gesture button. If you can hold one in a store before deciding, that is still the surest way to avoid buyer’s remorse.

Pointing an Onamae.com domain at Netlify — DNS handover steps and gotchas

Mon, 08 Mar 2021 00:00:00 GMT

2026 update: A post ported over from the old VuePress blog. The skeleton of the procedure hasn’t changed, but the Netlify / Onamae.com UI screenshots are from 2021. Cloudflare Pages + Cloudflare DNS is a common pairing now too, so a short comparison is added at the end.

Pointing an Onamae.com domain at a Netlify site is the kind of task you trip over on the first attempt if the UI isn’t familiar. The two things that snag people are pretty consistent: “where do I change the nameservers”, and “is it slow because it’s working or because it isn’t”.

This post tries to clear both up before you start clicking, so the order is: how DNS works, the connection steps, then how to confirm propagation. The Netlify deploy itself is assumed to be done already, per Setting up a static site with VuePress, GitHub, and Netlify.

Short answer — delegate the nameservers to Netlify DNS

The shortest path for connecting an Onamae.com domain to Netlify is to rewrite the Onamae.com nameservers to the four Netlify DNS ones.

The reason is that Netlify takes over DNS-record management (A / AAAA / CNAME), so SSL issuance, apex-domain handling, and adding subdomains all run more or less on autopilot. You only need to write records yourself if you’ve chosen the delegate to a separate DNS (e.g. Cloudflare DNS) and CNAME to Netlify layout.

If you’re undecided: Netlify DNS for delegation, Cloudflare DNS if you want to bundle multiple services under one domain. That’s the dividing line.

How DNS delegation works — who holds the address book

DNS is the distributed database that resolves “domain name → server IP”. A nameserver is the authoritative source for those lookups.

Right after you buy a domain at Onamae.com, Onamae.com itself is the authoritative source (the primary DNS). Switching the nameservers to Netlify DNS is what “changing nameservers” means, and from that point on the A / CNAME records live on the Netlify side.

Onamae.com DNS vs Netlify DNS vs Cloudflare DNS

Angle	Onamae.com DNS (default)	Netlify DNS (delegated)	Cloudflare DNS (delegated)
Setup effort	Hand-write A / CNAME	Records generated automatically	Hand-write your own CNAME
Fit with Netlify	OK	The official short path	Good (CNAME flattening supported)
HTTPS certificate	Automatic on Netlify	Automatic on Netlify	Automatic on Netlify
CDN / WAF	No	No	Yes (via Cloudflare)
Email / other services	Slightly awkward	Awkward	Easy
2026 popularity	△	◯	◎

If you’re stuck, walk down the table: “only using Netlify → Netlify DNS”, “want email or another service on the same domain too → Cloudflare DNS”. That keeps the decision stable.

Connection steps — 10 minutes of actual work, up to 48 hours of propagation

The actual work starts here. The clicking part takes around 10 minutes; DNS taking effect everywhere can take up to 48 hours (in practice it’s usually done within a few hours).

Step 1: Register a domain at Onamae.com

On the Onamae.com homepage, type in the domain name you want. For non-.com TLDs, select the TLD explicitly.

In the results, tick the TLD you want and proceed to pricing confirmation.

On the next screen — the server-selection step — pick don’t use one, since hosting is going to Netlify. Don’t accidentally sign up for a rental server here (an annual fee straight down the drain).

Once payment is done, the domain is yours. Whois proxy is included free, so you can leave it on.

Step 2: Run Add custom domain in Netlify

From the target Netlify site’s overview, open Domain settings.

Click Add custom domain, type in the domain you registered (as the apex, e.g. example.com), and click Verify. That takes you to the ownership-check screen.

Step 3: Turn on Netlify DNS and copy the nameservers

Right after adding the domain, you’ll see Check DNS configuration. Open Options → Set up Netlify DNS to enable Netlify DNS.

A few confirmation dialogs follow — read through them as you go. At the end, four FQDNs (shaped like dns1.p0X.nsone.net) appear under Name servers. Leave this browser tab open and copy them.

Step 4: Switch the nameservers to Netlify on Onamae.com

In another tab, log into Onamae.com Navi. From the top-bar menu → change nameservers.

Tick the target domain, pick the “Other” tab, and paste the four nameservers from Netlify into the nameserver fields, top to bottom.

Click confirm and a “change request received” email arrives. That’s the active work done.

Step 5: Wait for DNS propagation and the HTTPS certificate

Propagation lands anywhere from a few minutes to 48 hours. On Netlify’s side, once DNS finishes propagating, Let’s Encrypt certificate issuance runs automatically, and after that you can reach the registered domain over HTTPS.

A few tips for confirming:

If it’s still not visible after 30 minutes, try nslookup example.com 1.1.1.1 to check name resolution against a different DNS
If only your home network can’t see it, suspect the router or OS DNS cache
If the certificate is still pending after half a day, hit Renew certificate once from the Netlify Domains screen — that re-kicks issuance

Gotchas — four common stumbles

Short answer: mistyping the nameservers, redoing the settings before propagation finishes, misclicking the Onamae.com renewal emails, and running email on the same domain. Those four.

Mistyping the nameservers: copy all four exactly. Order doesn’t matter, but watch the trailing . and any leading whitespace
Redoing settings repeatedly before propagation: changing the Onamae.com side again mid-propagation because “it’s not working” just resets the TTL and stretches the wait. Give it half a day first
Misclicking the renewal emails: Onamae.com sends a lot of ad emails about similar-looking domains. Build the habit of logging into Navi and checking the contract list to confirm whether a renewal notice is the real one
Running email on the same domain: moving the whole nameserver to Netlify DNS means you have to re-create the MX records on the Netlify DNS side. If email is in play, delegating to Cloudflare DNS is safer (each provider’s MX UI may shift through 2026)

FAQ

Q. Can I connect this without Netlify DNS — i.e. leaving Onamae.com’s DNS in place? A. Yes. In Onamae.com’s DNS-record settings, point the apex at A record 75.2.60.5, and point www at <site>.netlify.app via CNAME. Netlify’s load-balancer IP could change in the future, so for the long run, delegating to Netlify DNS or Cloudflare DNS is the safer move.

Q. What’s different about pointing through Cloudflare DNS instead? A. You delegate the nameservers to Cloudflare and point CNAME at Netlify from there. The upside is you can layer Cloudflare’s CDN and WAF on top, and it’s easier to co-locate multiple services (email, a separate host) on the same domain. Aulvem itself currently runs on Cloudflare Pages, with DNS managed on the Cloudflare side.

Q. How long does it take to propagate after switching nameservers? A. In practice, most of it lands within a few minutes to a few hours, with up to 48 hours as the outer bound. Mid-propagation, what you see depends on whether the network you’re on has cached the old record, so if it’s still not visible after half a day, try a different network.

Q. Is Netlify still a reasonable choice in 2026? A. Still reasonable, yes. That said, in 2026 Cloudflare Pages and Vercel are the more natural defaults for a new project. If you’re leaning on Netlify Forms or Identity, Netlify still holds up.

Closing

The real question behind pointing an Onamae.com domain at Netlify is “which DNS holds the authoritative copy of the domain”. Only using Netlify? Delegate to Netlify DNS — that’s the lightest path. Bundling multiple services? Go through Cloudflare DNS instead.

The screenshots are still the 2021 ones, but the basic flow — delegate the nameservers — hasn’t moved in 2026. Netlify itself is still around, and for projects leaning on Forms or Identity it’s still a top pick.

If you want to revisit the Netlify-side initial setup, see Setting up a static site with VuePress, GitHub, and Netlify.

RATOC RS-WFIREX4 review — a sub-10,000-yen entry point into the smart home

Sun, 07 Mar 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The hardware spec and UI described here are from the time of writing. The successor RS-WFIREX5 is now on sale, so check the current line-up before buying new.

The remote always vanished at the exact moment I wanted to use it. That was the steady-state problem.

To fix it at the physical layer, I bought the RATOC RS-WFIREX4 — an infrared smart remote that lets a phone or a smart speaker drive any infrared appliance in the house. This is the write-up after a few years of use.

The price sits just under 10,000 yen. As smart remotes go it is on the entry-level end, but the feature set is not far from a Nature Remo or a SwitchBot hub.

The verdict — a solid pick for a first smart remote

Short answer: as a sub-10,000-yen infrared smart remote with Alexa / Google Home / Siri support, it does the entry-level job well. If you want to take one step of friction out of using the remotes around your home, buy.

Three reasons.

Small, white body that disappears against a wall
Built-in temperature, humidity, and illuminance sensors that can drive automation conditions
Official support for all three major smart-speaker ecosystems

A few cautions before buying:

If you expect the immediacy of a physical remote: there is a two-to-three-second lag
If setup is not your thing: the initial configuration does not just flow from the app — plan to read the manual alongside
If your room has no line-of-sight for infrared: appliances tucked behind a wall or a door may not be reachable

The hardware — a small white box made to live on a wall

Short answer: a small white plastic box. There is a hook on the back for wall mounting, so it goes almost anywhere.

The front is almost blank except for the logo and a small indicator. It melts into a white wall and does not announce itself in a living room.

It fits in the palm of a hand. Height is around 4cm. There are vent slots on the side.

The back has a wall-mount hook and a lanyard hole. The base has rubber feet. Whether you set it on a desk or hang it on a wall, nothing about it looks out of place.

Power is delivered over micro-USB Type-B. In 2026 USB Type-C is the norm, so this dates the unit — but for a device you plug in once and never unplug, the practical cost is small. The side carries a status LED and a reset button.

What worked

Short answer: the core job of replacing infrared remotes is done well. The smart-speaker integration and the on-board sensors are welcome extras.

Covers almost any infrared appliance

Teach it a remote signal and it drives appliances that fall outside the built-in templates. In practice, almost every remote-driven appliance in the house can end up running through a single app.

After installing it, the number of times per week I went hunting for a remote dropped sharply. To the point that “remote included or smart-compatible” quietly became a purchase criterion for new appliances.

The headline templated categories are:

Air conditioners
TVs
Lights
Fans

App downloads:

iOS: Wi-Fi Learning Remote (App Store)
Android: Wi-Fi Learning Remote (Google Play)

Control from outside the house

Your phone does not need to be on home Wi-Fi. As long as the unit itself is online over the house network, the app reaches it from anywhere. Turn the air conditioner on before you get home, switch off a light you forgot — that kind of operation becomes routine.

Built-in temperature, humidity, and illuminance sensors

The bottom of the appliance list screen always shows the temperature, humidity, and illuminance at the unit’s location. Illuminance is reported in three levels rather than a raw lux value — personally, I find that granularity more useful.

You can use these readings as automation triggers, for example “turn on the air conditioner when the temperature rises above 28 °C”.

Per-appliance remote UI

For templated appliances, the app shows a layout designed for that kind of device. If a button you need is missing from the template, you can add it yourself.

This is the opposite of the “ten generic buttons on a flat screen” feel of most universal-remote apps. The fact that the layout matches the appliance reads as a small thing and turns out to matter.

Alexa, Google Home, and Siri all supported

Official support for all three smart-speaker ecosystems. Finish the integration in the app and you can drive appliances by voice.

The wins show up when your hands are busy cooking, when the phone is in the other room at night, when the remote is missing in the morning.

What didn’t

Short answer: a two-to-three-second lag from going via the cloud, the inherent line-of-sight problem of infrared, and a non-trivial initial setup.

Two-to-three-second response time

The path is phone → RATOC cloud → home unit → appliance. The immediacy of a physical remote is not on the table.

The trap is the moment you ask “did that work?” and tap again. Two commands arrive, and the air conditioner can flip ON / OFF / ON. The fix is a habit: press once, wait a few seconds.

Infrared, with the obstacle problem that implies

This is a property of infrared rather than of this product. Thick doors and walls between the unit and the appliance stop the signal.

Cranking up the output extends the range, but then it also reaches a near-identical unit a wall away in someone else’s room. Every smart remote on the market lives with this trade-off.

Pick a “central spot with line-of-sight to the appliances you care about” when you choose where to mount it.

Initial setup needs the manual

Wi-Fi setup → unit registration → appliance registration → integration setup. The flow is more steps than the app’s UI alone tries to walk you through. The fastest route is to keep the manual or the official setup page open alongside.

It is not a heavy lift for an experienced user, but it is not a “plug it in and it works in five minutes” device either, and that is worth knowing upfront.

micro-USB Type-B for power

In 2026, the port is dated. For a once-and-done install it does not bite, but cable management is easier with USB Type-C.

Comparison — RS-WFIREX4 vs SwitchBot Hub / Nature Remo

Short answer: the core feature set is roughly the same across all three. The differences show up in extras (Matter, hub features, ecosystem) and price band.

Angle	RS-WFIREX4	SwitchBot Hub 2	Nature Remo 3 / mini 2
Price (reference)	Under 10,000 yen	~8,000 – 10,000 yen	~6,000 – 13,000 yen
Temperature sensor	Yes	Yes	Yes
Humidity sensor	Yes	Yes	No on mini 2
Illuminance sensor	Yes (3 levels)	Yes	Yes on Remo 3
Motion sensor	No	No	Yes on Remo 3
Alexa / Google / Siri	All three	All three	All three
Matter support	No	Partial	Partial
Ecosystem	Standalone	Broad (button pushers, etc.)	Mostly standalone
Power	micro-USB Type-B	USB Type-C	USB Type-C

Spec and price move over time — check each manufacturer’s official page for current numbers.

A rough buying guide:

Cheap entry-level pick: RS-WFIREX4
Want to combine it with physical button pushers and friends: SwitchBot Hub 2
Want motion-sensor-based automation: Nature Remo 3

Put differently: if you scope the requirement down to the core (infrared remote + sensors + smart-speaker integration), the RS-WFIREX4 does not leave a meaningful gap.

FAQ

Q. Does it work with both Alexa and Google Home? A. Yes. Enable the skill or action from the integration screen in the app and the same appliances can be controlled from either side. Siri Shortcuts is officially supported as well.

Q. Can I control it from my phone when I am out of the house? A. Yes. The RS-WFIREX4 stays connected to the manufacturer’s cloud over your home Wi-Fi, so the app reaches it even when your phone is on 4G or 5G. If your home router goes down, of course, nothing gets through.

Q. How long does it take for an appliance to respond after I press a button? A. Two to three seconds in real use. The path is phone → cloud → unit → appliance, so it never matches the immediacy of a physical remote. Mashing the button sends duplicate commands, so the safe habit is to press once and wait.

Q. Which appliances does it support? A. Anything with an infrared remote, basically. Templates are provided for the major categories — air conditioners, TVs, lights, fans. Outside the templates you can teach it the raw remote signal and it still works.

Verdict — a sensible “first one”

It is not flashy. What it is, is a quiet, complete take on the basics of a smart remote.

Under 10,000 yen, full Alexa / Google Home / Siri support, three on-board sensors, a small body — that combination is hard to fault as an entry-level pick. The response lag and the setup work are structural, so the call is whether you can live with them.

If you want to push further — Matter-based ecosystems, motion-sensor automation — it is worth lining up the SwitchBot Hub 2 and Nature Remo 3 alongside.

Setting up a static site with VuePress, GitHub, and Netlify

Sat, 06 Mar 2021 00:00:00 GMT

2026 update: A post ported over from the old VuePress blog. Netlify’s admin UI and pricing have moved on since 2021, so parts of this don’t line up one-to-one with the current product. The skeleton — connect GitHub, set a build command, get auto-deploys — is still the same shape, and that’s why I’ve kept the post around.

This is the initial setup for picking Netlify as a static host, wiring up a GitHub repository, and getting auto-deploys running. The screenshots are the original 2021 ones; the current Netlify dashboard has a different layout, so read them with that grain of salt.

The five things covered here are: account creation, repository connection, build configuration, two-factor authentication, and a look at the free tier. Custom-domain setup is in a separate post.

The services used

Short answer: GitHub for code, Netlify for static hosting — the minimal pair.

GitHub — code hosting
Netlify — static site hosting

The reason is that Netlify watches GitHub and builds and publishes automatically when you push. You write locally, push, and check the result — a short loop.

The overall flow:

Develop and write locally
Push the source to GitHub
Netlify picks it up, builds, and serves

Note: the steps below assume you already have a GitHub account with 2FA enabled.

Create a Netlify account

Short answer: sign in from the Netlify homepage with your GitHub account.

The reason is that wiring Netlify to GitHub via OAuth is shorter than running two separate accounts, and you don’t have to set up a Netlify password.

Open Netlify, and the screen below comes up — sign in with your GitHub account.

Note: as of 2026, Netlify has refreshed the UI, and the sign-up layout and button positions are different from this screenshot. The OAuth-with-GitHub flow itself is the same.

Connect a GitHub repository

Short answer: from the dashboard, click New site from Git, pick GitHub, and select the target repository.

The reason is that Netlify is built around Git as the source of truth. Drag-and-drop from a local folder exists as a separate option, but if you want auto-deploys, Git is the prerequisite.

After signing in, New site from Git opens the deploy-source picker. Pick GitHub, then pick the repository.

Note: private repositories use the same flow. For organisation-owned repos, the organisation may have to approve the Netlify app on their side first.

Fill in the build settings

Short answer: set Branch, Build command, and Publish directory, then click Deploy site.

The reason is that those three fields are how Netlify decides which branch, how to build, and what to serve. They’re the only fields that really change with the framework (VuePress, Next.js, Astro, and so on).

Once you pick the repository, the build-settings screen comes up.

Example values for a VuePress site:

Field	Example
Branch	`master` or `main`
Build command	`npm run build` (for VuePress)
Publish directory	`docs/.vuepress/dist` (VuePress default)

After filling those in, click Deploy site and the build kicks off. When the status reads Published, the deploy worked.

Note: changing the build command after the fact and breaking the deploy is a classic mistake. Don’t casually edit a configuration that’s already working. Mistyping the publish directory by a single folder is enough to ship a blank page.

Auto-deploys and HTTPS

Short answer: push to the configured branch and Netlify builds automatically; HTTPS comes on by itself.

The reason is that Netlify wraps Let’s Encrypt internally, so even after a custom domain is attached, certificate issuance and renewal are handled for you. There’s nothing manual to do in the normal case.

In practice:

Pushing to the configured branch triggers a build
Once the build succeeds, the result is pushed to the serving CDN
Attach a custom domain and Netlify issues the certificate automatically

Note: right after attaching a custom domain, propagation takes a while. At the time, it felt like roughly half a day to settle, though it depends on DNS propagation.

Turn on two-factor authentication

Short answer: open User settings, go to Security, and enable Two-factor authentication.

The reason is that this account holds the deploy keys and the custom-domain settings. If it gets taken over, the attacker can swap out a live site. Turning 2FA on at the start saves regret later.

Steps:

Click your avatar in the top right and open User settings
Click Security in the left menu
Enable Two-factor authentication

Direct link:

https://app.netlify.com/user/security#two-factor-authentication/

Note: switching phones without backing up your authenticator app (Authy, 1Password, Google Authenticator, and so on) means you can lock yourself out. Keep the recovery codes somewhere separate.

About the free tier

Short answer: the Netlify Starter plan was 100GB of bandwidth and 300 build minutes a month (as of 2021).

The reason is that for a personal blog, if you keep image weight in check, the free tier just about covers you. Commercial use or high-frequency updates is a different conversation.

The Starter plan at the time:

Bandwidth: 100GB / month
Build time: 300 minutes / month
Site count: personal-use range

For reference, dropping in lots of video or uncompressed PNGs eats both bandwidth and build time fast. Converting to WebP, or offloading images to an external image service, makes it easier to stay inside the free tier.

Note: pricing has been revised as of 2026. Check the official Pricing page for the current limits.

FAQ

Q. When a build fails, where do you look first? A. The Build command output in the deploy log. When it builds locally but fails on Netlify, it’s usually a Node.js version mismatch, or a gap between package-lock.json and your environment variables.

Q. I changed the build command and the site disappeared — can I roll back? A. Open the Deploys tab, find a past successful build, and use Publish deploy to roll back. Roll back first, then fix the offending commit — that’s the safer order.

Q. Is custom-domain setup covered here? A. No. The steps for pointing an Onamae.com domain at Netlify are in a separate post.

Q. How does Netlify compare with Vercel or Cloudflare Pages? A. The core experience — auto-deploying a static site from GitHub — is close. The differences show up in pricing, build minutes, and the edge-runtime story. The reason I picked Netlify in 2021 came down to two things: Japanese-language docs were in better shape at the time, and VuePress sample configs were easier to find.

Closing

Netlify’s initial setup is OAuth into GitHub, pick a repository, type one line for the build command and one for the publish folder — that’s it. HTTPS and rebuilds are automatic, and the only things that really trip people up early on are mistyping the build command and forgetting to filter out their own PC from analytics.

Custom-domain setup is in a separate post. Analytics exclusion rules and how to pick an image host I’ll come back to another time.

Cup Noodle Refill Lidded Mug review — a wide-bottomed desk mug that resists spills

Fri, 05 Mar 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The refill mug itself is still listed on Nissin’s official online shop and at the Cup Noodles Museum shop. The numbers are the manufacturer’s published figures from the original writing; current official specs may differ. Heavily rewritten.

I picked up the “Refill Lidded Mug” on the way home from the Cup Noodles Museum, mostly as a novelty. It was designed for swapping in refill noodles, but it ended up living on my desk as a daily-use cup.

It feels better suited to that — a desk mug for coffee or tea — than to its stated purpose. The reasoning is below.

The verdict — for anyone who wants a desk mug that doesn’t tip

Short answer: the wide base and low center of gravity make it hard to knock over, even sitting right next to a keyboard. The lid keeps dust out and the polypropylene body is light. If you can live with the look, the practical value is high for the price (under 1,000 yen).

Three reasons:

The base is wider than a typical mug: the shape is a direct copy of the Cup Noodle cup, so it absorbs a stray arm or sleeve without going over
A lid is included: it comes with a vented lid, so dust doesn’t get in while it sits on your desk
Light in the hand: polypropylene is much lighter than ceramic, which makes carrying it around easier

It is harder to recommend if any of these apply:

You don’t want a loud design on your desk: it is the Cup Noodle livery, untouched — not always a great fit for a workplace or a customer meeting
You want cold drinks with condensation handled: as a plastic mug it insulates worse than ceramic

Build and feel

Short answer: a Cup Noodle cup with a handle bolted on. The material is polypropylene, and because it was designed to hold refill noodles, the base is wide.

The front is the Cup Noodle packaging, as-is. To someone who doesn’t know the product, it looks like you are drinking Cup Noodle.

The width and height are roughly the same as a regular-size Cup Noodle (rated). As a mug it reads as a little wider and a little shorter than usual.

Inside is the molded fill-line rib for hot water. The base has a wide outer diameter and a large footprint. Most mugs taper from a wide rim to a narrower bottom; this one is closer to the opposite.

The material is polypropylene. Heat resistance is listed as 140 degrees C.

What worked

Short answer: stability from the wide base, dust protection from the lid, and how light it is.

Wide base, hard to tip

This is the headline difference. I had spent years occasionally knocking over the mug on my desk with a stray arm or sleeve; in the six-plus months since switching to this one, I have not tipped it once.

The reason is built in. A Cup Noodle cup is designed to stay upright on an unstable surface — low center of gravity, wide base.

A lid that keeps dust out

It comes with a vented lid as standard. There is no locking mechanism, so it is not the cup for commuting with, but for something that stays parked on a desk it is enough.

Knowing that dust and crumbs aren’t drifting into the cup while I am away from my seat changes how the cup feels day to day.

Light, with a roomy handle

Polypropylene is noticeably lighter than ceramic. The handle is large enough for three fingers, which makes it easy to carry full.

It is also labeled as microwave-safe, so reheating a cold coffee can happen in place.

What didn’t

Short answer: the refill noodles cost more than a regular Cup Noodle, the plastic picks up some smell, and the look isn’t always workplace-safe.

Refill noodles cost more than a regular Cup Noodle

The intended workflow — drop refill noodles into the mug, pour hot water — doesn’t really pencil out. A regular-size Cup Noodle is often cheaper.

Given the production scale, the refill premium is understandable, but if you bought the mug specifically for that use, it is a small letdown.

Some smell carries over

Polypropylene picks up a small amount of color and smell after coffee or tea, even after washing. It is something you notice when you compare against a ceramic mug, not something that gets in the way of daily use.

The look is hard to bring out at work

The packaging is unchanged, so it doesn’t sit naturally in a customer meeting or a more formal office. For a desk you sit at alone it is fine; for shared spaces a plain mug is the safer pick.

Comparison — versus other desk mugs

Short answer: a mug that is both hard to tip and has a lid, for under 1,000 yen, doesn’t have many direct competitors.

Angle	Cup Noodle Refill Lidded Mug	Typical ceramic mug	Thermos-style tumbler (with lid)
Tip resistance	Wide base, hard to tip	Roughly the same diameter top-to-bottom, easier to tip	Depends on base; narrow ones tip easily
Lid	Included (vented, no lock)	Sold separately	Included (some lockable)
Weight	Light (plastic)	Heavy	Medium (metal)
Insulation	Weak (single-wall plastic)	Medium	Strong (vacuum-insulated)
Microwave	Yes (rated)	Depends on the piece	No (metal)
Visual restraint	Loud	Usually neutral	Neutral
Price	Under 1,000 yen	A few hundred to a few thousand yen	2,000 yen and up

If you want full insulation, a Thermos-style tumbler is the right tool. If you want a neutral look and microwave compatibility, a regular ceramic mug. If the requirement is “won’t tip, has a lid, cheap,” this one fits.

FAQ

Q. Is it dishwasher-safe? A. Depending on the package, it may be listed as not supported. As a plastic mug, repeated hot-cycle dishwashing risks deformation, and hand-washing is the safer call.

Q. Where can I buy it? A. The Nissin Foods online shop, the museum shop at the Cup Noodles Museum, and various marketplaces. Physical retail is limited, so online is the realistic route.

Q. How much does it hold? A. Roughly the same capacity as a regular-size Cup Noodle. As an everyday drink cup it reads on the larger side.

Q. Can kids use it? A. It is light and won’t shatter, so it is friendlier than ceramic in that sense. The lid does not lock, though, so for actual spill-proofing a kids’ mug with a locking lid is safer.

Verdict — bought as a novelty, kept as a tool

Short answer: the intended use (refill noodles) is hard to justify on cost, but as a lidded desk mug it earns its place for the price.

I bought it as a Cup Noodles Museum souvenir, and six-plus months later it is still on my desk every day. That was not the plan.

If the brief is “a lidded mug that won’t tip, under 1,000 yen,” competitors are thin on the ground. Whether it works for you depends on how much you can live with the look.

I am quietly considering buying a second one for the office.

Image placement and sitemap setup for VuePress — a 2021 build note (archived)

Thu, 04 Mar 2021 00:00:00 GMT

2026 update: A post ported over from the old VuePress blog. Both VuePress 1.x and vuepress-plugin-sitemap are effectively no longer maintained, so this isn’t a reference for new builds. It’s left up as a record of how image sitemaps and image-directory layout were thought through at the time. All code snippets assume VuePress 1.x as of 2021.

A record of how image placement and sitemap settings were laid out back when I was building a personal blog on VuePress 1.x. The setup that was standard at the time — managing images in the same folder structure as the Markdown posts, hard-coding the favicon into the head array of config.js, and emitting the sitemap with vuepress-plugin-sitemap — is kept here as-is.

What this post covers is four things: “how to split the image directory”, “how to declare the favicon”, “how to configure the sitemap plugin”, and “where to place robots.txt”. The broader VuePress directory layout itself is covered separately in VuePress/blog directory structure.

The short answer — split public and public/resources

Short answer: physically separate the files in image and sitemap territory between those served directly at the root and those organized per article.

VuePress 1.x copies the contents of src/.vuepress/public to the root of dist as-is. Anything placed directly under public is served from the site root after the build. The split I went with: files where “being at the root has meaning in itself” — the favicon, robots.txt, sitemap.xml — go directly under public, and files that need to be “organized per article” — the article images — go under public/resources.

The reason is that putting both at the same level kills visibility once the file count grows. With hundreds of article images directly under public, the favicon gets buried in the pile.

Files in scope

Short answer: the two places touched here are the public folder under src/.vuepress and config.js.

Specifically, the layout looks like this.

src
└─ .vuepress
   ├─ public
   │  ├─ resources
   │  │  └─ category
   │  │     └─ page
   │  │        └─ img.jpg
   │  ├─ top.jpg
   │  ├─ favicon.ico
   │  ├─ favicon.png
   │  └─ robots.txt
   └─ config.js

A caveat: the directory layout at a broader scope is covered in VuePress/blog directory structure.

Why organize an image sitemap

Short answer: to tell crawlers where the images live, and to keep me from losing track of images on the authoring side.

An image sitemap is an extension that, inside sitemap.xml, lists “this page has these images” against each URL. A regular sitemap is just a list of page URLs; an image sitemap also passes image URLs to the crawler. In theory this opens up another inbound path from image search.

That said, vuepress-plugin-sitemap 2.x on VuePress 1.x doesn’t, by default, emit image entries to the sitemap. What this post covers stops at “images are served correctly and a page-level sitemap is being emitted” — it doesn’t cover a strict image sitemap with image entries included.

Comparison: image sitemap vs. regular sitemap

Lens	Regular sitemap (sitemap.xml)	Image sitemap
What it conveys	List of page URLs	Each page URL + the images contained on that page
How it’s submitted to Google	Search Console / robots.txt	Same (embedded as extension elements)
vuepress-plugin-sitemap 2.x support	Generated by default	Not supported by default
How well it works for a personal blog	Essentially required	Worth considering if you’re targeting image-search traffic

The reasoning is that image-search traffic moves the needle for photo media but doesn’t shift much for text-driven tech blogs. Setting up just the regular sitemap first and stepping into the image sitemap only after image-search traffic starts showing up was a good enough order.

Decide the directory for per-article images

Short answer: under src/.vuepress/public/resources, create per-article folders and place the images there.

src
└─ .vuepress
   └─ public
      └─ resources
         └─ category
            └─ page
               └─ img.jpg

The reason is that aligning the Markdown folder structure with the image folder structure one-to-one makes it easier to trace where images live when posts get moved or deleted later. A single post often contains several images, so I split folders at the page level.

A caveat: match folder names to the article’s slug. Renaming on the article side and renaming the image folder at different times causes broken links.

Put shared images and the favicon directly under public

Short answer: the top image, profile image, and favicon all sit directly under src/.vuepress/public.

src
└─ .vuepress
   └─ public
      ├─ favicon.ico
      └─ favicon.png

The reason is that shared images at the time were only two or three files — not enough to warrant a folder. The plan was, once shared images grew, to break out a public/resources/common folder and move them in, like this.

src
└─ .vuepress
   └─ public
      └─ resources
         ├─ category
         └─ common
            └─ img.jpg

Because VuePress has no index.html, the favicon is declared by writing a link tag in the head array of config.js.

module.exports = {
  head: [
    ["link", { rel: "icon", href: "/resources/favicon.ico" }],
  ],
}

If you want PWA support, prepare a PNG favicon separately from the ico and put it at the same level. At the time the site’s PWA support was only half done, so I’ve left out that part of the description.

A caveat: the head declaration is reflected in every built HTML file. Get the href path off by even one level and the favicon stops loading across the entire site.

Install vuepress-plugin-sitemap and set hostname

Short answer: add vuepress-plugin-sitemap to the plugins array, declare hostname and exclude, and sitemap.xml is generated automatically.

The site used vuepress-plugin-sitemap (at the time of writing, vuepress-plugin-sitemap: ^2.3.1). The setup is finished entirely in config.js.

module.exports = {
  plugins: [
    [
      "sitemap",
      {
        hostname: "https://xxxx",
        exclude: "https://xxxx/404.html"
      },
    ]
  ],
}

The reasoning: hostname is required because it’s used to assemble the URLs inside the sitemap. exclude is where you list URLs you want kept out of the crawl, like the 404 page. The other fine-grained options didn’t really need touching at personal-blog scale.

A caveat: vuepress-plugin-sitemap 2.x is for VuePress 1.x. For VuePress 2.x, it’s a different package and a different configuration API.

Place robots.txt directly under public

Short answer: robots.txt has to sit directly under src/.vuepress/public.

src
└─ .vuepress
   ├─ public
   │  └─ robots.txt
   └─ config.js

The reason is that VuePress copies the contents of public to the root of dist. Place it in a subfolder and it isn’t served from the root, so to crawlers the site looks like one without a robots.txt.

The contents are the same as for any other framework.

User-agent : *
Disallow :
Sitemap : https://xxxx/sitemap.xml

Including a Sitemap line lets crawlers find sitemap.xml even without going through Search Console.

A caveat: leaving Disallow blank means “allow everything”, but if you’ll later expose a staging environment through the same setup, an operation flow that swaps robots.txt per environment is safer.

Pitfalls — what tripped me up at the time

Short answer: two things tripped me up — image paths colliding with the favicon path, and sitemap.xml caching more aggressively than expected.

Writing image references as /img.jpg collides with files that already sit directly under public. I standardized on writing article images with full paths like /resources/category/page/img.jpg
sitemap.xml caches easily in both CDNs and browsers, so right after a deploy it can still show the old contents when viewed from Search Console. Resubmit the rebuilt URL and confirm it’s picked up
After every build, check that robots.txt and sitemap.xml are emitted directly under dist. Misplacing them under public is the most easily missed kind of accident — the build passes, but the file simply isn’t at the root

FAQ

Q. Is an image sitemap a different thing from a regular sitemap.xml? A. An image sitemap is an extension of sitemap.xml that lists image:image entries against each URL. A regular sitemap is just a list of pages; an image sitemap tells the crawler “which images live on which page” as well. vuepress-plugin-sitemap 2.x doesn’t emit image entries by default, so if you wanted to include images you had to extend it with another plugin or regenerate the sitemap yourself.

Q. Why split off public/resources instead of putting everything directly under public? A. If everything sits directly under public, article images, shared images, the favicon, and robots.txt all end up at the same level and visibility drops. Slipping public/resources in as one extra layer physically separates per-article images (resources/category/article-name) from things that need to live at the public root (favicon, robots.txt).

Q. Is the VuePress 1.x sitemap plugin still usable in 2026? A. Technically it still runs, but maintenance on both vuepress-plugin-sitemap and VuePress 1.x itself has effectively stopped. For new builds, picking an SSG with sitemap generation built in officially — Astro or Next.js — is easier in both the short and long term. For maintaining an existing site, pinning Node LTS and plugin versions to extend its life is the realistic move.

Q. What happens if robots.txt is placed somewhere other than directly under public? A. It won’t be emitted under dist after the build, so it’s not served at the root and crawlers treat the site as one without a robots.txt. Because VuePress copies the contents of public to the root of dist, public is the only place to put robots.txt if you want it served at the same level as sitemap.xml.

Closing

The initial setup for image and sitemap territory on VuePress 1.x — splitting the roles of “directly under public” and “public/resources”, letting config.js’s head load the favicon, declaring hostname and exclude through vuepress-plugin-sitemap, and placing robots.txt directly under public — covers the whole loop on its own.

The settings themselves are small, but fixing the image-directory split later, after the post count has grown, hurts more than it should. Drawing the line once at the start — “per-article images and shared images live at different levels” — saves trouble down the road.

As of 2026 VuePress 1.x is hard to recommend as a choice for new builds, so this post is kept as material for comparing the build philosophy at the time against Astro and the like.

JOBY GorillaPod JB01542-PKK review — a small tripod for wrapping a webcam around a pillar

Wed, 03 Mar 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. The JOBY GorillaPod JB01542-PKK is still in circulation as part of the current line-up in 2026, but successors and variants (GorillaPod Mobile / Magnetic / 1K, etc.) have multiplied. Read this as a review of one specific use case — fixing a webcam in place — rather than as a universal recommendation.

When remote work started, I wanted to wrap a webcam around the pillar next to my desk and fix it slightly above eye level. The generic tripods I had on hand could only extend their legs — none of them could “wrap around a pillar” — so I ended up buying a JOBY GorillaPod to add to the kit.

What I bought was the JOBY GorillaPod JB01542-PKK (ball head with 1/4-inch screw, mini-size flexible-leg type). After about half a year of leaving it permanently set up for webcam duty, here is the write-up.

The verdict — a good match for anyone wanting to fix a webcam to a pillar or handrail

Short answer: with its three wide-articulating legs, wrapping it around a pillar to fix a webcam above eye level is something it does honestly well. As a tripod for heavier gear like a mirrorless, though, the 50-something gram body is far too light, and the ball head does not take kindly to fine adjustment. Treat it as a specialist for “light gear, awkward places” and the satisfaction is high.

Good fit:

You want to wrap a webcam or phone around a pillar, handrail, or shelf for work-from-home use
You want to travel with just one tripod (for phone or GoPro use)
You want to mount unusually — on a monitor edge or a desk leg

Less of a fit:

You want to put a mirrorless plus standard zoom (or heavier) on it — both the load rating and the tripod’s own weight are short
You want a ball head that adjusts in 1° steps
You want a quick release for swapping cameras often

The look — all plastic with rubber leg tips, a 50-something gram mini tripod

Short answer: the body is moulded plastic, the joints in the legs are ball-shaped and rotate 360°, and the leg tips have anti-slip rubber and a small magnet. It sits in the palm of one hand, and paired with a webcam the balance comes out right.

By category this is a mini tripod with a 1/4-inch screw and ball head. The leg joints are chains of ball segments that each rotate independently, so the legs as a whole bend freely.

The range of motion is enough that, for a handrail-thickness pole (around 4cm diameter), three legs can wrap around it without strain. The head tilts to roughly 90°, so horizontal shooting is also workable.

This is roughly the size with a GoPro mounted. Own weight is around 52g, maximum load around 325g. With a mirrorless the centre of gravity ends up too high and balance is easily lost, but it pairs cleanly with a phone, a GoPro, a compact, or a webcam.

What worked

Short answer: the flexibility of where you can place it — “wrap around a pillar”, “clamp onto a monitor edge”, “tangle around a desk leg” — is the biggest difference from an ordinary tripod.

Wide leg range — wraps around pillars, handrails, and shelves

A normal tripod assumes you will set it on the floor. With the JB01542-PKK, each of the three legs bends freely, so wrapping around a cylindrical object to fix the camera in place is genuinely workable. For my permanent home-office setup, wrapping it around the pillar by the desk and placing the webcam slightly above face level worked on the first try.

The actual fixed setup. One leg is hooked over the top of the pillar, and the other two are wrapped around it. Wrapping all three works too, but hooking one leg upward stops it from sliding down.

Light — no guilt about leaving it hanging at face height for hours

Around 50g for the tripod itself. Combined with a webcam (about 100g) the total still falls short of 200g. In a setup where the thing is dangling at head height for long stretches, weight translates directly into drop risk, so the lightness itself is reassuring. It did not shift in shaking up to JMA seismic intensity 3 (within my own trial range).

Magnetic leg tips for casual mounting on steel shelving or cabinets

Each leg tip has a small magnet inside. It will cling lightly to steel shelving or a cabinet top when set down — useful for casual mounting in places you cannot wrap around. It is not strong enough on its own to hold a camera, so treat it strictly as an aid.

No quick release is actually a plus if all your gear uses 1/4-inch screws

If everything on your camera side — webcam, GoPro mount, compact — already takes a 1/4-inch screw, a quick release is just one more adapter to thread through. The JB01542-PKK screws on directly, so no conversion plate is needed.

What didn’t

Short answer: it is too light, so a mirrorless puts the centre of gravity too high. The ball head is stiff and bad at fine adjustment. There is no quick release, so frequent swapping is awkward.

A mirrorless puts the centre of gravity too high

The 325g load rating is high enough on paper that some entry-level mirrorless bodies clear it. In practice the higher the centre of gravity, the easier it tips. With a mirrorless and a standard zoom on top, it slowly leaned over — not by the head lock giving up, but by the leg joints flexing. Safer to treat it as out of spec, and reach for a larger tripod for anything mirrorless-class and up.

The ball head is stiff and bad at 1° adjustments

The head’s angle lock has no adjustment screw — it is a press-fit held by firm resistance from the start. That is good for preventing drops, but for composing in fine steps you can really only move it in 5°–10° increments. Not the right pick for anyone who needs to nail a horizontal in video.

No quick release is a minus for anyone swapping gear often

The flip side of the “1/4-inch direct” advantage. If you cycle through multiple bodies, every swap means turning a screw. For a permanent install, it is a non-issue.

Comparison

Short answer: against a “tripod you put on the floor”, placement freedom wins by a wide margin. Against “other flexible tripods”, it is cheaper but loses to higher models (GorillaPod 1K / 3K and so on) on load rating and rigidity.

vs a typical extendable tripod

Angle	JB01542-PKK	Typical extendable mini tripod
Placement	Floor, pillar, handrail, shelf edge	Flat floor only
Height adjustment	By bending the legs	Stepped, via the elevator column
Own weight	~52g (rated)	~200–500g
Load rating	~325g (rated)	1–3kg class is common
Fine adjustment	Weak (ball head is stiff)	Strong on 3-way head models
Price band	Cheap	Cheap to high-end, full range

Extendable tripods are good at placing heavy gear on a flat floor. The JB01542-PKK is good at hooking light gear onto non-flat places. The use cases are different, so the choice comes down to “where do you want to put it?“.

vs other flexible tripods (inside the GorillaPod line)

Angle	JB01542-PKK	GorillaPod 1K Kit	GorillaPod 3K Kit
Target gear	Phone / webcam / GoPro	Mirrorless (light)	Medium DSLR
Load rating	~325g	~1kg	~3kg
Head	Simple ball	Ball + pan	Ball + pan + Arca-Swiss compatible
Quick release	No	Yes	Yes
Size	Mini (palm-sized)	Medium	Large
Price band	Cheapest	Mid	High

Inside the GorillaPod line, the JB01542-PKK sits as the smallest, lightest, cheapest entry-level option. If you are planning around a mirrorless or up, 1K and above is the safer band. Conversely, if you will only ever mount a webcam and a phone, the weight and price of the 1K is overspec.

FAQ

Q. Is it okay to mount a mirrorless camera on it? A. The manufacturer’s stated maximum load is around 325g. An entry-level mirrorless body on its own just about clears that, but adding a lens usually pushes it over. In practice it is safer to stick to gear under 300g — phones, compacts, webcams, GoPros.

Q. Will cameras other than 1/4-inch screw fit? A. The head is 1/4-inch screw only. There is no quick release. You can add a separate Arca-Swiss clamp meant for a DSLR and effectively share gear across tripods, but the added weight cancels out the lightness advantage.

Q. How strong is the magnet in the legs? A. Each leg tip has a small magnet that lightly clings to steel surfaces like shelving or cabinet tops. It is not strong enough on its own to hold a camera in place — it is meant as an aid to wrapping or to spreading the legs (JOBY does not publish a specific holding force).

Q. Is it suited to outdoor or travel use? A. At around 50g it is light and packs into a gap in a bag, so portability is high. On the other hand it is weak in wind, so for long exposures or time-lapses outdoors it is safer to weigh it down with a stone or a bag, or to bring a full-size tripod as well.

Verdict — a specialist for “light gear in awkward places”

As a general-purpose tripod it is underpowered, but for someone who wants to do something unusual — like wrapping a webcam around a pillar — there is really no other option. That kind of product.

Over half a year of permanent use, the webcam + JB01542-PKK pairing ran without trouble. It did not slip down through a JMA seismic intensity 3 quake, and the ball head’s lock did not loosen.

Conversely, if you want to mount a mirrorless, dial in fine adjustments, or swap cameras often, a higher-end GorillaPod 1K Kit or a straightforward extendable tripod will leave you happier. A tripod that is strong when the use case is narrow, weak when it is not.

VuePress Markdown extensions — Components / Slots / frontmatter (2021 archive)

Tue, 02 Mar 2021 00:00:00 GMT

2026 update: A post ported over from the old VuePress blog. VuePress 1.x is no longer a choice for new builds, so the body here is kept as an archive of “Markdown extension notes from 2021”. The ideas behind containers and frontmatter still carry over to MDX + Astro / Next.js, so read it as comparison material.

Back in 2021, the precursor blog to Aulvem ran on VuePress 1.x. Plain Markdown couldn’t quite handle table of contents, callout blocks, and article metadata, so I ended up touching VuePress’s own Markdown extensions more than once. This post is a cleaned-up version of those configuration notes, viewed from 2026.

VuePress 1.x is for all practical purposes unmaintained as of 2026, and I wouldn’t recommend it for new projects. Even so, the thinking behind containers and embedded components has carried over into the MDX side of the world, so there’s still some value in leaving the calls I made then on record.

Short answer — split VuePress Markdown extensions into three layers

Short answer: VuePress 1.x Markdown extensions are easier to think about when split into three layers — “embedded Vue components”, “named containers (custom blocks)”, and “frontmatter”.

The reason is that each layer involves different config files and responsibilities. Components belong on the .vue side, containers belong in the index.js plugin config plus styles, and frontmatter belongs in article metadata and the template — keeping them separate stops you from losing track of which setting goes where.

As a concrete split, repeating elements like a table of contents or footer become components, callout boxes become containers, and titles, categories, and tags go in frontmatter.

A caveat: as of 2026, MDX + a framework (Astro / Next.js) handles the same roles more directly, so from here on, read this as an archive of “how it worked in VuePress 1.x at the time”.

extendMarkdown — the entry point for overriding markdown-it behavior

Short answer: markdown.extendMarkdown in config.js lets you touch the markdown-it instance directly.

VuePress 1.x parses Markdown with markdown-it internally, and extendMarkdown is the hook for overriding that configuration. Line break handling, link target, and the syntax highlighting area all got tuned here.

The setting I actually used is below. It enables breaks: true, which turns editor line breaks into <br>.

markdown: {
  extendMarkdown: md => {
    md.set({ breaks: true })
  }
},

A caveat: breaks: true is convenient for Japanese blog writing where each sentence is broken to its own line, but it doesn’t sit well with English-style paragraphs written as one block. It’s a setting you pick based on how the article is written, not something that should be on by default.

Embedding Vue components inside Markdown

Short answer: in VuePress you can write a Vue component directly inside a Markdown file.

The reason is that VuePress’s build converts Markdown to a Vue SFC before rendering. Write the tag with the same syntax you’d use inside a .vue file, and it gets resolved as a component at build time.

<ComponentName />

Repeating blocks (related links under an article, footers, table of contents) were turned into components this way.

A caveat: Markdown and JSX-ish syntax now coexist, so the writer’s prior knowledge requirement goes up. It works as a design when the writers are editors only and operations are small — not so much if external writers are involved. MDX has the same trade-off.

Defining custom blocks with named containers

Short answer: the ::: type title … ::: syntax lets you define blocks with custom styles.

VuePress 1.x ships with tip / warning / danger by default, and you can add more types via the container plugin config in index.js. The body inside is regular Markdown.

The syntax looks like this.

::: displayType titleName
Markdown can be used inside.
:::

When written, it renders as a block with CSS tied to the type name. Example:

titleName

Markdown can be used inside.

The display type is defined in the plugin config in index.js. type is the display type name, defaultTitle is the label used when no title is given, and the '/' key is the prefix for switching per language (Japanese is the default for this site, so leaving it as / is enough).

src   
└─ .vuepress
   └─ theme
      └─ index.js

module.exports = (options, ctx) => {
  return {
    plugins: [
      ['container', {
        type: 'typeName',
        defaultTitle: {
          '/': 'defaultTitleName',
        }
      }],
    ]
  }
}

Style definitions lived on the custom-blocks.styl side. Add a selector for the new type name next to tip / warning / danger.

src   
└─ .vuepress
   └─ theme
      └─ styles
         └─ custom-blocks.styl

  &.tip
  &.warning
  &.danger

A caveat: containers are a markdown-it-container plugin mechanism, so they’re a lightweight Markdown-side extension. If you want to call arbitrary components JSX-style, leaning toward embedded components or MDX is the better fit.

frontmatter — article metadata at the top of Markdown

Short answer: a YAML frontmatter defines the article’s title, publication date, category, tags, image, and so on.

The VuePress template and plugin-blog’s frontmatters config read those declared values and reflect the metadata into list pages and individual pages. The frontmatter I was using at the time looked like this.

title: [How to] Build your own blog with VuePress/plugin-blog — Markdown edition
date: 2021-03-02
category:
  - skill
tag: 
  - VuePress
image: {{Path}}
location: japan

tag shows up in $tag and $currentTag and lands on the list pages when its name matches a registered entry in plugin-blog’s frontmatters. category works without registration, but I aligned it by hand for internal classification. image is the OG image and thumbnail.

A caveat: frontmatter key names differ across frameworks. VuePress 1.x used date / tag / category (singular), while current Aulvem (Astro) uses pubDate / tags / category, and migrations stumble here often.

Markdown format comparison (2026 view)

Lens	Plain Markdown	VuePress 1.x Markdown	MDX
Base	CommonMark / GFM	markdown-it + extensions	Markdown + JSX
Component embedding	not available	Vue component written inline	arbitrary JSX / components
Custom blocks	blockquotes / lists, roughly	`::: type` syntax (container)	replaced by JSX components
frontmatter	tool-dependent	yes (YAML)	yes (tool-dependent)
Main use in 2026	README / Issue	maintaining existing VuePress 1.x sites	static sites on Astro / Next.js and similar

VuePress 1.x containers and embedded components were an early take on “extending Markdown toward JSX”, and MDX now plays roughly the same role.

FAQ

Q. How is VuePress Markdown different from plain Markdown? A. VuePress emits an extended flavor built on markdown-it, adding embedded Vue components, named containers (::: tip and friends), frontmatter, and PrismJS-based syntax highlighting. It’s more expressive than plain Markdown, but the difference is that the build assumes a Vue runtime.

Q. How are VuePress containers (::: tip etc.) different from MDX components? A. Containers are a syntax implemented via the markdown-it-container plugin — a lightweight extension that stays close to Markdown. MDX is a separate spec that lets you write JSX directly inside Markdown, so you can embed arbitrary React / Vue components as expressions. Containers are custom blocks, MDX is full JSX — the scope of responsibility is different.

Q. Is it worth picking VuePress 1.x for a new project in 2026? A. Barely. VuePress 1.x is effectively unmaintained, and if you’re staying on Vue, VitePress has more material and more extension room; for a more general SSG, Astro or Next.js + MDX is the safer pick. Keeping VuePress 1.x around only for maintenance of an existing site is the realistic path.

Q. Is breaks: true in extendMarkdown necessary? A. It depends on taste. The setting converts editor line breaks into <br>, which is convenient for Japanese blog writing where each sentence ends on its own line. For English-style writing where paragraphs are treated as one block, it isn’t needed and tends to introduce unintended line breaks.

If I were doing the same thing today

Short answer: if you want to stay on Vue, VitePress is the closest fit; if you want something framework-agnostic, Astro + content collections + MDX gets you a similar experience.

The reason is that VuePress 1.x maintenance has all but stopped, while VitePress is the successor the Vue team put together, and Astro was designed to handle Markdown / MDX natively. Aulvem itself ended up moving to Astro.

A caveat: the exact state of each tool as of 2026 — latest version, maintenance posture, default features — is something to check against the official documentation. This post is, at heart, a note “someone who wrote on VuePress 1.x in 2021 went back and tidied up later” — not a reference for choosing a current tool.

Closing

VuePress 1.x’s Markdown was an extension on top of plain Markdown — component embedding, named containers, and frontmatter on top — and at the time it had enough expressive power for small-to-medium documentation and blog use.

As of 2026, that role has shifted to MDX + Astro / Next.js + content collections. The thinking behind the VuePress era (keep article metadata in frontmatter, write callout blocks with a syntax, componentize what gets reused) still translates straight across to the new stack, so this post is left up as a design record from that time.

Belis wireless numeric keypad review — a slim USB 2.4GHz keypad with a calculator key

Mon, 01 Mar 2021 00:00:00 GMT

2026 update: Ported from the old VuePress blog. Belis-branded numeric keypads vary by production run, so before buying, check the product page for the three things that matter: USB 2.4GHz, a dedicated calculator key, and scissor switches. The specs below are from the unit I bought at the time of writing.

If you do any kind of calculator-style number entry on a tenkeyless keyboard, the cost of stretching your fingers off home row adds up quietly. For work where you punch in numbers many times a day, a separate keypad on the side of the desk ends up faster.

That is what I bought the Belis wireless numeric keypad for. It sits in the affordable bracket and ticks the three boxes I wanted: USB 2.4GHz, a calculator key, and a slim body. This is the write-up after about six months of use.

The verdict — worth it if you hit the calculator key every day

Short answer: a dedicated calculator key, a stable USB 2.4GHz receiver link, and a slim body that drops onto the edge of a desk without fuss. If you launch the calculator often for work, it earns its price.

The reason is the workflow. Before this, I had the Windows application key mapped to “open Calculator” — now that lives on a single dedicated key. The action that fires a dozen-plus times a day shaves a second or two each time.

A few cautions before buying:

If a light in your field of view bothers you: the red LED stays lit the whole time the power switch is on
If you prefer a mechanical typing feel over a slim one: the scissor switches will not feel like mechanical keys
If you use a Mac: whether the calculator key works on macOS depends on the unit and OS version

Build and feel — semi-gloss black, ~6° tilt, runs on AAA batteries

Short answer: a semi-gloss black, slim-bodied wireless keypad with a roughly 6° forward tilt and scissor switches.

The top is semi-gloss black. It does not read as cheap, and on the desk it stays visually quiet.

From the side, the near edge is thin and the body rises by roughly 6° toward the back (measured by eye). The angle keeps the wrist from bending too far back while typing.

The power switch sits in the top-left of the underside. Power comes from two AAA batteries, and the rubber feet do their job. Dry cells instead of a built-in battery means no charging cable to manage, at the cost of having to keep spare batteries in a drawer.

What worked — the calculator key, the wireless link, the scissor feel

Short answer: the calculator key lands the moment you want it, the USB 2.4GHz link is steadier than expected, and the scissor switches feel better than a typical pantograph.

The calculator key is a dedicated key

This is the main reason I bought the keypad and the part I am happiest about after using it.

Before this I had “open Calculator” mapped to the Windows application key, but a dedicated, labelled key is something you can hit without looking. You press it the moment you want it and the calculator pops up — that flow is quietly satisfying.

Expense reports, rough inventory counts, simple arithmetic — the moments where you think “I want the calculator right now” come up more often than you would guess in a day. The gap between a remapped key and a dedicated key is tiny per press, but the press count is high.

USB 2.4GHz with no perceptible latency

Wireless keypads come in Bluetooth and USB 2.4GHz flavours. I had been bitten before by a Bluetooth keyboard where keystrokes arrived on screen a few dozen milliseconds late, so this time I picked the USB-receiver type.

Result: in six months of use, I have not once felt latency while entering numbers. Even right after the machine wakes from sleep, there is no warm-up wait. If you can spare one USB port for the receiver, stability is more honest than Bluetooth.

Scissor switches feel better than I expected

Going in, I assumed the feel would be close to a laptop pantograph keyboard, but the real thing has a touch more click to it. This was my first time with scissor switches; the feel sits somewhere between a slim keyboard and a mechanical one, and fingertips do not tire as quickly over long sessions.

For a number-entry-only role, it is plenty.

What didn’t — the LED shouts while you type

Short answer: when the power switch is on, the red LED on the body stays lit, and it catches the corner of your eye while you work.

It photographs more discreetly than it looks in person — with the unit in front of you, there is a small red dot glowing in your peripheral vision the whole time you are entering numbers. As a battery indicator it does its job, but as visual noise while typing it is, frankly, in the way.

The workarounds are physical: shift the keypad a little away from the monitor, or place it so the LED is not in your line of sight. There is no way to switch the LED off on the unit (it may vary by production run).

For long stretches in front of a monitor, plan the placement around the LED from the start.

Comparison: Belis wireless keypad vs the alternatives

Here are the configurations that come up against this one when you filter for USB 2.4GHz, a calculator key, and a slim profile. Prices and specs are reference values from the time of writing and shift by production run and date.

Angle	Belis wireless keypad	Elecom TK-TDM017 series (wired, calculator key)	Sanwa Supply Bluetooth keypad
Connection	USB 2.4GHz	USB wired	Bluetooth
Calculator key	Yes	Yes	Depends on model
Switch type	Scissor	Mostly membrane	Pantograph / membrane
Power	2x AAA	USB bus power	Built-in cell or dry cells
Latency concern	Low	None (wired)	Slightly higher (environment-dependent)
Desk handling	Good (wireless, slim)	Cable to manage	Good

The specs are a rough sketch from the unit I bought and the public info at the time; current production runs may differ.

If Bluetooth latency does not bother you → the Sanwa Supply type is fine, and it leaves your USB ports alone
If you want zero latency, no compromises → wired Elecom TK-TDM017 series, with plenty of calculator-key options
If you can give up one USB port for wireless → a USB 2.4GHz unit like the Belis, balancing stability and desk handling

FAQ

Q. Does the calculator key work on a Mac? A. If macOS cannot bind a key to the Calculator app, the dedicated calculator key may either do nothing or register as a different key. Windows is confirmed working; on Mac, behaviour depends on the OS version and production run, so check the product page for explicit Mac support before buying.

Q. How long do the batteries last? A. With two AAA cells and daily number-entry use, the batteries that came in the box lasted about two to three months (varies by unit). Switching off the power when you are done with the day stretches that further.

Q. Can it sit next to a laptop keyboard? A. The slim body means the step between the laptop keyboard and the keypad is small, so the hand moves between them naturally. Next to a slim desktop keyboard the tilt angles roughly match, which keeps the feel consistent.

Q. Is the layout the same as a full keyboard’s numeric pad? A. The number block matches the numeric pad on a full keyboard, and NumLock behaves normally. Function keys and some symbol keys are laid out unconventionally, so anyone who wants a perfect full-keyboard replica should check the layout in the product photos first.

Verdict — easy pick if “calculator key” and “USB wireless” both land

This is not a mouse-of-the-year type product.

If a dedicated calculator key, a USB 2.4GHz link that does not stutter, and a slim body that does not crowd the desk all matter to you, the price is well spent. It fits people who handle a lot of numbers in office work and people pairing it with a tenkeyless keyboard.

If a glowing LED at the edge of your vision wears on you, if you prefer a heavy mechanical feel, or if your daily driver is a Mac, look at another option — fewer regrets that way.

VuePress/blog directory structure — a 2021 build note (archived)

Mon, 01 Mar 2021 00:00:00 GMT

2026 update: A post ported over from the old VuePress blog. VuePress 1.x is no longer a viable choice for new development, so the body here is kept as an archive of “how the build looked in 2021”. The idea of splitting directories by concern still applies to current SSGs like Astro, so read it as comparison material.

Back in 2021, the personal blog that became the precursor to Aulvem was built on VuePress 1.x with @vuepress/plugin-blog. There wasn’t much information out there beyond the official docs, and I got stuck on directory layout and plugin configuration more than once — so once the site was actually running, I wrote this down as a working note.

As of 2026 I’ve moved over to Astro 5, and VuePress 1.x is for all practical purposes unmaintained (confirm the official EOL announcement for the 1.x line). So read what follows as “a record of how the call was made at the time”.

The short answer — VuePress 1.x splits into _posts and .vuepress

Short answer: put article Markdown under _posts/, and configuration plus theme under .vuepress/. That was the standard layout when using plugin-blog.

The reason is separation of concerns. Content (written often) and framework configuration (written rarely) go in different directories, which keeps deploy logs and git diffs easier to read.

Concretely, the layout looked like this.

src
├─ _posts                   Markdown for each article
│  └─ category
│     └─ page.md
└─ .vuepress
   ├─ components            Article-side components (Vue)
   │  └─ Component.vue
   ├─ public
   │  └─ img.jpg
   ├─ theme
   │  ├─ components         Components (Vue)
   │  │  └─ Component.vue
   │  ├─ layouts            Page layouts (Vue)
   │  │  └─ Layout.vue
   │  └─ styles
   │     └─ style.styl
   ├─ config.js             VuePress config (JS)
   └─ enhanceApp.js         Vue plugin entry (JS)

During the build phase the three things you touch are config.js, enhanceApp.js, and theme/. During operations the files you touch are _posts/ and public/. Because the roles are different, once the build is done, the set of files you actually edit shifts on its own.

A caveat: this layout assumes VuePress 1.x + plugin-blog 1.9. VuePress 2.x changed both the config location and the theme model, so a 1.x configuration won’t run on 2.x as-is.

Glossary: Static Site Generator (SSG)

SSG (Static Site Generator): A generic name for tools that convert sources like Markdown into static HTML at build time. Unlike a CMS like WordPress that runs on the server for every request, the resulting HTML can simply be served from a CDN. VuePress, Astro, Next.js (output:static), Hugo, and Jekyll all fall into this category.

VuePress is one such SSG, built on Vue.js and optimized for “Markdown-centric documentation sites”. plugin-blog is the plugin that bolts on “blog-style routing (tags, categories, post lists)” on top — that mental model is enough.

config.js — the site-wide configuration file

Short answer: config.js is where both VuePress core and plugin-blog settings live together. The site’s language, title, and routing are decided here.

The reason is consolidation. You can split plugins and locales into separate files, but keeping it all in one file means the file reads as “the site’s spec”.

A concrete example:

module.exports = {
  locales: {
    '/': { lang: 'ja' }
  },
  title: 'Title(config.js)',

  plugins: [[
    '@vuepress/blog',
    {directories: [
      {
        id: 'home',
        dirname: 'home',
        path: '/',
      },
      {
        id: 'tech',
        dirname: '_posts/tech',
        path: '/tech/',
        itemPermalink: '/tech/:slug'
      }
    ],
    frontmatters: [
      {
        id: "tag",
        keys: ["tag"],
        path: "/tag/",
        layout: "Tag",
        scopeLayout: "Tag"
      },
    ],},
  ]]
}

locales — the default language

locales sets the site’s default language. For a Japanese site, setting / to lang: 'ja' is enough. For multilingual setups, you add another key like /en/.

title — the site title

title is used as the site name. From Vue files you can reference it as $siteTitle. It becomes the reference point for things like OG image generation and header-logo swaps, so not hard-coding the title elsewhere makes operations easier.

plugins — registering VuePress plugins

You add VuePress plugins to the plugins array. For any plugin including @vuepress/blog, if you want to pass options, the rule at the time was to use a [name, options] tuple rather than just the string name.

You’ll need to dig into each plugin’s docs for detailed options. Writing it all out in config.js makes the file balloon, so back then I kept reference URLs in comments.

plugins/directories — URL directory structure

directories decides “which Markdown folder maps to which URL”. For the proto-Aulvem blog I wanted the category structure to map straight to URLs, so I added one array entry per category.

{
  id: 'tech',
  dirname: '_posts/tech',       File path holding articles for this category
  path: '/tech/',               /tech/{{article path}}
  itemPermalink: '/tech/:slug'  Format for {{article path}}. :slug is the filename minus the date
}

A caveat: dirname: '_posts/tech' only reaches one level deep and does not pick up grandchildren (this is plugin-blog 1.9 behavior). So in practice categories could only nest one level. Sub-categories meant adding more directories entries.

itemPermalink lets you toggle whether the date appears in the URL. I didn’t want dates in URLs, so I ran with just :slug. That followed the conventional wisdom at the time that “dates in URLs make a page feel stale” (whether this actually affects rankings is case by case).

plugins/frontmatters — tag feature

frontmatters generates tag pages. Writing keys: ["tag"] makes the tag field in a Markdown frontmatter become a tag page.

{
  id: "tag",
  keys: ["tag"],          Key set in the Markdown frontmatter
  path: "/tag/",
  layout: "Tag",
  scopeLayout: "Tag"
}

Once this is in place, two globals become available: $tag and $currentTag.

$tag is the list of all tags and the articles bound to each. Used when building a tag index page.
$currentTag is the “current tag” info when an individual tag page is open.

$currentTag looked like this:

inside the current page's `$currentTag` object
key: "Vue"
pageKeys: ["xxxxxx"]
pages: [{...}]
path: "/tag/Vue/"
scope: "tag"

A caveat: this style of “API that generates globals” plays badly with TypeScript — there’s no way to type it. Schema-enforced typing, like Astro’s content collections, feels more like the current mainstream approach.

enhanceApp.js — where Vue plugins plug in

Short answer: it’s the entry point for installing ordinary Vue plugins into VuePress. Think of it as “the place where you put Vue.use”.

The reason is that VuePress creates the Vue instance for you behind the scenes, so you can’t call Vue.use() from a regular main.js like in an SPA. Instead, enhanceApp.js hands you the Vue instance via its arguments.

import VScrollLock from 'v-scroll-lock'

export default ({
  Vue,
  options,
  router,
  siteData
}) => {
  Vue.use(VScrollLock)
}

A caveat: putting heavy work here slows the initialization of every page. Better to keep this file to Vue.use only and push real logic down into components.

theme — where layouts and CSS live

Short answer: theme/ is the directory for non-article Vue files and CSS. The workflow was to copy the default theme via npm run eject and override on top of it.

The reason is that VuePress’s default theme isn’t directly editable. Running eject expands the default theme set under .vuepress/theme/, where you can edit anything.

Right after eject, the directory looked like this:

theme
├── `global-components`
│   └── xxx.vue
├── `components`
│   └── xxx.vue
├── `layouts`
│   ├── Layout.vue _(**Mandatory**)_
│   └── 404.vue
├── `styles`
│   ├── index.styl
│   └── palette.styl
├── `templates`
│   ├── dev.html
│   └── ssr.html
├── `index.js`
├── `enhanceApp.js`
└── package.json

UI parts get edited or added under components/, and CSS lives either inside Vue files or under styles/. layouts/Layout.vue is required — delete it or rename it and the build dies immediately.

A caveat: once you eject, you can’t auto-follow upstream theme updates anymore. I knew that going in at the time, but if I were doing this today I’d lean toward “minimal overrides only”, staying on the upstream theme — that’s the easier maintenance path (VuePress 2.x may have a different mechanism here).

Comparison table — VuePress 1.x and the main 2026 SSGs

Lining up VuePress at the time against the SSGs most often used for the same role in 2026:

Lens	VuePress 1.x (2021)	Astro 5 (2026)	Next.js (App Router)	Hugo
Primary language	Vue 2	framework-agnostic	React	Go templates
Target	docs / small blogs	content sites broadly	apps and beyond	static sites with many pages
Config file	`.vuepress/config.js`	`astro.config.mjs`	`next.config.js`	`config.toml`
Article location	`_posts/**`	`src/content/**`	`app/**` or freeform MDX	`content/**`
Type safety	none (globals)	content collections with zod	TS and RSC	none
Partial hydration	whole site is an SPA	islands (static by default)	RSC + Client Components	static only
2026 maintenance	1.x effectively halted	active	active	active

The point here isn’t superiority but a difference in how concerns get sliced. For the narrow use case of “output a Markdown-centric blog statically”, VuePress 1.x worked fine. Aulvem itself moved to Astro because the article count grew and I wanted type safety.

FAQ

Q. Is VuePress 1.x still usable in 2026? A. You can still get it running. But maintenance — plugin-blog included — has all but stopped, and you can’t expect timely vulnerability patches in dependencies. Not the safe pick for new builds. For keeping an existing site alive, pinning Node versions and locking your package-lock.json properly is the minimum bar (confirm whether an official EOL announcement exists).

Q. How is VuePress different from Astro / Next.js? A. VuePress is Vue 2-based, starting from “Markdown-centric documentation sites”. Astro is framework-agnostic and uses partial hydration (islands), which makes mixing Markdown and dynamic parts easier. Next.js is React-based and covers anything from static sites to dynamic apps. Same “static site” label, different scope and assumptions.

Q. Why split _posts and .vuepress? A. Separation of concerns between “article content” and “framework configuration”. The idea of grouping things that change at different rates into different directories carries over to Astro’s src/content/ vs. src/layouts/ split. The opposite school exists too — Next.js App Router puts everything under app/ — so this is partly a matter of taste in design.

Q. What would I pick today for a similar setup? A. For a Markdown-focused blog, Astro + content collections is the closest in feel. If staying on Vue is required, VitePress and Nuxt Content are the successor candidates, but they each cover slightly different ground — check the official docs to see if they fit your use case.

Closing

VuePress 1.x’s layout rested on a simple separation: “write in _posts, configure in .vuepress”. At the time, that directness was what carried me through to getting the site running.

As of 2026 Aulvem itself runs on Astro 5. The same idea of splitting concerns across directories survives in a different form — so I’d be glad if this post gets used as a past snapshot, useful for comparing against today’s SSGs.

Aulvem Blog

How Rakuten's API hides the JAN, and the 3-tier cross-marketplace match

Rakuten and Yahoo! are asymmetric about the JAN

Collapse it into three certainty tiers

① JAN match: prove Rakuten hits by scoring “JAN-ness”

② Name fuzzy match: stop at candidates, don’t auto-confirm

③ No match: fall back to single-store drop alerts

What stops wrong merges is “only confirmed tiers notify”

FAQ

Can you not get the JAN from Rakuten’s API at all?

Why not just match everything by JAN?

Why doesn’t the fuzzy match confirm automatically?

What happens to items that don’t match?

How I compute the real, point-inclusive price — design notes from a 3-layer model

First, define the real price

Where the naive version broke

The core decision: split points by certainty into three layers

Floor each layer before summing

Separate the ranking key from the displayed price

Leave shipping out of the real price, on purpose

Looking back

FAQ

Why not just subtract all the points and compare that number?

How do you handle limited-time points and entry-required campaigns?

If shipping isn’t in the price, won’t the cheapest option flip?

Why use different layers for ranking versus the displayed price?

Generating llms.txt and llms-full.txt in Astro for a Bilingual Site

What llms.txt actually is

The minimal Astro version

Driving it from Content Collections

Splitting by language

Featured posts narrow to docLang

llms-full.txt — full index with language cross-references

How it sits next to robots.txt

Pitfalls and operating rules

Closing

FAQ

What’s the difference between llms.txt and llms-full.txt?

Will publishing llms.txt get my site read by AI and bring traffic?

Should a multilingual site split llms.txt per language?

If I already have robots.txt, do I need llms.txt too?

Emitting reciprocal hreflang only when both languages exist — Aulvem's i18n customisation

What breaks when you emit alternates for every locale

The two rules from Google

Three helpers in src/lib/posts.ts

Conditional emission in Seo.astro

Wiring layouts to the helpers

The flow

Routing stays on the official integration

Pitfalls

Wrap-up

FAQ

Why doesn’t Astro emit hreflang on its own?

Aren’t the hreflang entries from @astrojs/sitemap enough?

What should x-default point to?

Does omitting hreflang for one-sided posts hurt SEO?

Reading sitemap lastmod from MDX frontmatter — customising Astro's sitemap integration

Why lastmod matters

Walking MDX at config evaluation time

Feeding the map into serialize

Filtering out paginated noindex pages

How the pieces connect

Things I almost got wrong

When this should move back into the official integration

Wrap-up

FAQ

Why doesn’t @astrojs/sitemap read updatedDate on its own?

Isn’t reading frontmatter through fs.readdir + regex unsafe compared to the Content Collections API?

Is it really wrong to ship noindex URLs in the sitemap?

Does putting a real date in lastmod actually move AI search citations?

Pushing operational rules into Astro Content Collections with Zod

Why a README isn’t enough

The schema, in one file

Coupling two fields with .refine()

.refine vs .superRefine

Typing structured data inside frontmatter

Where Zod can’t reach: body parity

What I gave up automating

The schema / lint / review split

Wrap-up

Three helpers in `src/lib/posts.ts`

Conditional emission in `Seo.astro`

Aren’t the hreflang entries from `@astrojs/sitemap` enough?

What should `x-default` point to?

Why `lastmod` matters

Feeding the map into `serialize`

Filtering out paginated `noindex` pages

Why doesn’t `@astrojs/sitemap` read `updatedDate` on its own?

Isn’t reading frontmatter through `fs.readdir` + regex unsafe compared to the Content Collections API?

Is it really wrong to ship `noindex` URLs in the sitemap?

Does putting a real date in `lastmod` actually move AI search citations?

Coupling two fields with `.refine()`

`.refine` vs `.superRefine`

When do you reach for `.superRefine` over `.refine`?

Why isn’t the body-to-JSON-LD parity check wired into `astro build`?