DEV Community: Serguey Asael Shinder

Your Sitemap Still Styles Itself With XSLT and Chrome Is About to Stop Running It

Serguey Asael Shinder — Mon, 09 Nov 2026 09:45:22 +0000

Open your sitemap in a browser.

If it shows a tidy table,
with columns and colours,
instead of raw XML,
look near the top of the file.

<?xml-stylesheet type="text/xsl" href="sitemap.xsl"?>

That line asks the browser
to run an XSLT transform
on the document
before showing it.

Browsers have done that
for more than twenty years.

Plenty of SEO plugins
still ship it.

So do RSS feeds
dressed up to look friendly
when someone clicks on them,
and old internal tools
that send an XML report
and let the browser draw it.

Chrome is removing it.

Its engineers call the code
a security liability
used on a tiny share of pages,
and the C library underneath
has had almost nobody
left to maintain it.

People working on the other engines
have backed removal too.

Chrome's published schedule
turns XSLT off
in version 155,
due on 17 November.

An origin trial
and an enterprise policy
keep it alive a while longer,
into 2027,
for sites and companies
that ask.

After that it is gone.

What breaks is narrow
and easy to miss.

The stylesheet instruction
at the top of XML files.

And the XSLTProcessor object,
if any of your JavaScript
transforms documents in the page.

Search for both.

xml-stylesheet
and XSLTProcessor,
across your templates,
your static files
and whatever a plugin generates.

Search engines will not mind.

They read the XML,
never the styled page.

People will.

The help desk will get
a screenshot of raw angle brackets
from someone who clicked a feed.

The fix is dull.

Run the transform on the server,
or at build time,
and serve HTML
to anyone who wants HTML.

XSLT itself is not going anywhere.

Java's transformer,
lxml in Python,
Saxon,
all still work on the server.

Only the browser is stepping out.

There is also a polyfill
that runs the transform in WebAssembly,
if you need time.

Treat it as time,
not as the fix.

And add those old pages
to the browser tests
you already run.

The page nobody has opened in a year
is the one that breaks
with nobody watching.

Features rarely leave browsers.

When one does,
the first sites to notice
are the ones that went looking.

– Serguey Asael Shinder

You Napped for Fifty Minutes Before the Night Migration and Woke Up Slower Than You Lay Down

Serguey Asael Shinder — Mon, 09 Nov 2026 09:44:50 +0000

The migration
was booked for one in the morning.

You were sensible.

At twenty past eleven
you lay down on the sofa
with an alarm
for ten past twelve.

Fifty minutes.

Enough, you thought,
to take the edge off.

The alarm went.

You joined the call,
read the first step of the runbook
three times,
and still asked someone
which server it meant.

For the next twenty minutes
you were worse
than if you had stayed up.

That is sleep inertia.

The fog after waking,
when the parts of the brain
that plan and check
come back later
than the rest.

How bad it is
depends on what you woke from.

Sleep deepens in stages.

For the first ten minutes or so
it stays light.

By half an hour
you can be deep in slow wave sleep,
and waking from there
is the worst of it.

Brooks and Lack
tested this in 2006.

After a short night,
people napped in the afternoon
for five, ten,
twenty or thirty minutes.

Ten minutes
gave the best result straight away,
more alert
and quicker on tests,
with benefits lasting
more than two hours.

Twenty minutes helped,
but only after a delay.

Thirty minutes
brought a stretch
of worse alertness and performance
right after waking,
before it paid off.

Fifty minutes
is past all of them,
and likely woke you
from the deepest sleep you had.

So choose one of two naps.

Short,
ten to twenty minutes,
alarm set
before you lie down,
and you wake
before deep sleep starts.

Or long,
about one full cycle,
around ninety minutes,
so you are more likely
to surface from lighter sleep.

The space between them
is where the fog lives.

Whichever you take,
leave a gap
between waking
and the first thing that matters.

Fifteen minutes,
at least.

Light,
cold water,
on your feet.

Do not read the runbook
for the first time
in that window.

Read it the evening before,
and mark the steps
that cannot be undone.

And if you are the one
who just woke up,
say so on the call.

I have just woken,
check my first command.

The fog is normal.

Acting inside it alone
is the mistake.

– Serguey Asael Shinder

You Missed Your Last Six Estimates and Planned the Seventh From Scratch

Serguey Asael Shinder — Mon, 09 Nov 2026 09:44:19 +0000

Sprint planning.

You take the ticket,
open it up in your head,
and walk through the steps.

Add the field.

Change the API.

Update the screen.

Tests.

Three days.

It feels honest,
because you can see every step.

That is the problem.

Your last six tickets of this size
took between five and nine days.

You know that.

If someone asked,
you could tell them why.

The review that sat for two days.

The migration nobody mentioned.

The flaky test.

Each one feels like bad luck,
a thing that happened once.

So none of them
make it into the next estimate.

In 1994
Buehler, Griffin and Ross
asked final year students
when they would finish their thesis.

On average
they said thirty four days.

On average
it took fifty five.

Fewer than a third
finished by their own date.

The researchers also asked
for a date if everything went
as badly as it could.

The average real finish
came later
than the average worst case.

This is the planning fallacy,
and it is not ignorance.

The students knew
their past work had run late.

They explained it away,
the way you do,
as special.

Daniel Kahneman
called the cure
the outside view.

Stop asking
how this task will go.

Ask how tasks like it
usually went.

He told the story on himself.

His team writing a school curriculum
guessed about two years.

An expert in the room
knew that similar teams
had taken seven to ten,
and four in ten never finished.

It took eight.

So keep the numbers.

For every ticket,
the estimate
and the actual,
one column each.

It takes a minute.

After a month
you have a reference class,
your own,
and it is far more honest
than your imagination.

When you estimate,
start from that.

Five to nine days for this size.

Then adjust,
a little,
for what is truly different.

Not for what feels different.

Every task feels different
from the inside.

That is what inside means.

The plan in your head
has no reviews waiting,
no surprises,
no lost Tuesday afternoons.

The record does.

Believe the record.

– Serguey Asael Shinder

Your Last Chord Faded Into Grit When You Bounced the Album to Sixteen Bits

Serguey Asael Shinder — Mon, 09 Nov 2026 09:43:47 +0000

The final song
ends on one piano chord,
left to ring
for twenty seconds.

In the session
it dies away
into perfect silence.

On the CD master
the last few seconds
sound different.

Turn it up on headphones
and the tail is rough,
a buzzing grain
riding on the decay,
as if the reverb
were crumbling.

Nothing was added.

Something was taken away.

The session ran at 24 bits,
inside a mixer working in 32 bit float.

A CD holds 16.

Going from 24 to 16
means every sample
loses its bottom eight bits,
rounded to the nearest step
of a much coarser ladder.

When the music is loud,
the rounding error is tiny
and changes randomly
from sample to sample.

It sounds like nothing.

When the music is very quiet,
a fade only a few steps tall,
the error stops being random.

It follows the waveform.

And error that follows the signal
is not noise.

It is distortion,
new harmonics
that nobody played.

That is the grit.

The fix is called dither.

Before reducing the bits,
add a tiny amount
of random noise,
about the size of one step.

It sounds backwards.

Adding noise
to make it cleaner.

But the noise breaks the link
between the error and the music.

The distortion turns into
a steady, very quiet hiss,
down around ninety decibels
below full scale,
and the decay
keeps fading smoothly
underneath it,
even below the last step.

Noise shaping goes further,
moving most of that hiss
up toward frequencies
the ear barely hears.

The rules are short.

Dither when the bit depth goes down,
not before.

Dither once.

Anything after it,
a fade,
a gain change,
a limiter,
brings the problem back.

So the fade happens in the session,
and the dither is the last step
of the last export.

Check whether your limiter
already dithers its output,
and whether your export dialog
dithers too.

Two layers
is more hiss for nothing.

None at all
is the grit.

Then listen the way it failed.

Not the chorus.

The last ten seconds,
turned up loud,
on headphones.

Quiet is where
the bits run out.

– Serguey Asael Shinder

Most of Your Examples Were Labelled Normal and So Were Most of the Urgent Tickets

Serguey Asael Shinder — Mon, 09 Nov 2026 09:43:15 +0000

The triage prompt
had a short definition
of urgent and normal,
and six examples.

Real tickets,
copied from the queue,
with their labels.

Five were normal,
because most tickets are.

The last two
were among them,
because that is the order
they were pasted in.

For a week
the model sorted the queue.

Then someone noticed
a payroll outage
had sat for a morning
marked normal.

So had a locked out branch.

So had a fraud report.

None of them
were hard to read.

The examples had taught
something nobody wrote down.

In 2021
Zhao and colleagues
measured this in GPT-3
and named three habits.

Majority label bias.

The model leans
toward the label
that appears most often
in the examples.

Recency bias.

It leans
toward the labels
near the end of the prompt.

Common token bias.

It leans
toward answers
that were common words
in its training.

Changing only
which examples went in,
and in what order,
moved accuracy on some tasks
from close to chance
to close to the best results
of the time.

The questions
had not changed at all.

Newer models
are steadier than that one.

Steadier is not immune.

So treat the examples
as part of the classifier,
because they are.

Balance them.

As many urgent as normal,
even though the queue is not.

Shuffle the order,
and do not let
the same label
close the list every time.

Then test it the boring way.

A hundred tickets
with labels people agree on,
scored against the prompt.

Run the same set again
with the examples reordered.

If the scores move,
the order is deciding,
not the tickets.

Watch the label counts as well.

If the model calls
ninety five percent of tickets normal
and the real share is eighty,
it has learned the prompt,
not the job.

And when you change an example,
run the set again.

Swapping one ticket
for a better one
is a change to the model's instructions,
even if nobody calls it that.

Your examples
were never a sample of the queue.

They were a lesson,
and the model learned
every part of it.

– Serguey Asael Shinder

Your Page Listened for Messages From the Checkout Frame and Took Them From Any Window

Serguey Asael Shinder — Mon, 09 Nov 2026 09:42:43 +0000

The account page
embedded a checkout
from the payments provider.

An iframe
on another origin,
so the two sides talked
with postMessage.

The frame said resize,
and the page grew it.

The frame said done,
and the page showed a notice
the frame had sent along.

window.addEventListener("message", e => {
if (e.data.type === "notice") banner.innerHTML = e.data.html;
});

It worked on the first try.

That was the warning.

A message listener
does not know who is talking
unless you ask.

Any window
holding a reference to yours
can post to it.

Your own iframe, yes.

Also a page
that opened yours
with window.open.

Also a page
that framed yours,
if you let it be framed.

The attacker's page
did the first.

It opened the account page
in a new tab,
waited a second,
and posted one message.

Type notice,
and some HTML
with a script hidden
in an image error handler.

The page put it on screen,
inside the logged in session.

The browser tells you
where every message came from.

e.origin.

Check it first,
against the exact origin you expect,
scheme, host and port,
with ===.

Not includes.

Not startsWith.

https://pay.example.com.attacker.net
starts with the right thing.

Then check that e.source
is the frame you created,
and check the shape of the data
before you touch it.

And never put
anything from a message
into innerHTML.

The other direction
has its own trap.

When you send,
the second argument says
which origin may receive it.

"*" means anybody.

If the frame you post to
has been navigated somewhere else,
your message goes there instead.

Name the origin.

A header helps as well.

Cross-Origin-Opener-Policy: same-origin
cuts the link
between your page
and a cross-origin page that opened it,
so that reference
stops reaching you.

Then search your code
for addEventListener("message".

Every one of them
is a door
anyone with a tab
can knock on.

Find out
which of them
ask who is knocking.

– Serguey Asael Shinder

You Filled the Email Template With replace and the Second {name} Went Out Unfilled

Serguey Asael Shinder — Mon, 09 Nov 2026 09:42:11 +0000

The template was simple.

A renewal reminder,
written by marketing,
with two places for the name.

Hi {name},
at the top.

We will keep everything ready for you, {name},
near the bottom.

The code that filled it
was one line per field.

body = body.replace("{name}", customer.firstName);

The test used a template
with one {name} in it.

It passed.

Then the new copy went out
to eleven thousand customers,
and every one of them
was greeted by name
and signed off to as {name}.

In JavaScript,
when the first argument to replace
is a string,
only the first match is replaced.

Not all of them.

The first one,
and then it stops.

It is in the documentation.

It is in nobody's fingers,
because the same word
means something else
almost everywhere else.

Python's str.replace
replaces every occurrence.

Java's String.replace
replaces every occurrence.

So does C#.

So the line read correctly
to everyone who reviewed it.

There are two fixes.

Since ES2021
the language has replaceAll.

body.replaceAll("{name}", customer.firstName)

A string pattern,
every match,
taken literally.

Or a regular expression
with the g flag,
but then the braces
belong to a pattern,
and every special character
in a placeholder
has to be escaped by hand.

replaceAll given a regular expression
without the g
does not quietly do one.

It throws.

That is the kind of failure
you want.

One more trap
waits in the second argument.

The replacement has its own small language.

$& means the matched text.

$$ means a single dollar sign.

So a value with a dollar sign
in the wrong place
can come out changed.

If the text comes from a user,
pass a function instead,
() => value,
and it goes in exactly as written.

Better still,
stop filling templates with replace.

Use a template engine,
something that knows
what a placeholder is
and complains when one is left over.

And add one check
before anything is sent.

If the finished text
still contains a word
inside curly braces,
it does not go out.

Then fix the test.

A template with one placeholder
proves the placeholder works.

A template with the same placeholder twice
proves the code does.

– Serguey Asael Shinder

Some of Your Mac Tools Still Run Through Rosetta and Apple Has Named the Last Version

Serguey Asael Shinder — Fri, 06 Nov 2026 09:48:55 +0000

Your laptop is an Apple silicon Mac,
and so is everyone's on the team.

Everything works.

The build runs,
the database client opens,
the old command line tool
the release script calls
does what it always did.

Nobody has asked
which of those programs
were built for the chip
inside the machine.

Some of them were not.

When an Intel only program starts
on an Apple silicon Mac,
macOS hands it to Rosetta 2.

Rosetta translates
the Intel instructions
into Arm ones,
mostly ahead of time,
and keeps the result.

It is good enough
that most people never notice.

That is the problem.

It is also temporary.

When Apple announced
that macOS 26
would be the last release for Intel Macs,
it also said
how long Rosetta stays.

Fully available
through macOS 27.

After that,
only a smaller part of it,
kept for older games.

Your build tools
are not older games.

So find out
what is being translated
before the version arrives
that stops translating it.

Activity Monitor
has a column called Kind.

Apple,
or Intel.

Sort by it
while you run a full build.

On the command line,
file followed by a path
tells you which chips
a binary was built for.

x86_64 on its own
means Rosetta.

Then check the place
people forget.

A shell
started under Rosetta
makes everything it launches
Intel as well.

If arch prints i386
in your terminal,
your whole session
is being translated.

Homebrew is a good clue.

The Apple silicon install
lives in /opt/homebrew.

The Intel one
lives in /usr/local.

A laptop migrated
from an old Intel Mac
often still has both,
and a PATH
that finds the old one first.

Then look at
what you downloaded by hand.

The vendor CLI,
the old JDK,
the database driver,
the editor plugin
nobody has updated.

Most have Arm builds now.

Switching
is usually one download,
and the tool gets faster.

For the few that have none,
you want to know now,
while there is time
to ask the vendor,
not on the morning
the upgrade lands.

And put the check
in the setup script
for new laptops.

Translated
means it works today.

It does not mean
anyone has promised tomorrow.

– Serguey Asael Shinder

You Read Your Slides Aloud and the Room Stopped Following Either

Serguey Asael Shinder — Fri, 06 Nov 2026 09:48:23 +0000

Thirty people in the room,
and the migration plan
in twelve slides.

You had worked hard on them.

Every point was there,
written out in full,
so nobody could miss it.

Then you talked through them,
line by line,
so nobody could miss it twice.

Afterwards
the questions came in.

Every one of them
was answered on a slide.

Nobody had been rude.

They had been looking.

They just had not taken it in.

Here is what the room was doing.

People read faster
than you speak.

So they read the slide
while you were still on line two,
finished,
and then waited for you to catch up,
listening to words
they had already read.

Or they tried to do both.

Read one sentence
while hearing another,
in the same language,
with the same meaning,
at a different speed.

That is harder
than either alone.

People who study learning
have tested this.

Richard Mayer and his colleagues
compared a group
who saw a diagram with spoken explanation
against a group who got the same,
plus the words printed on the screen.

The group with the printed words
did worse
when asked to use what they had learned.

It is called
the redundancy effect.

The usual explanation
is that the eyes are already busy.

They have the diagram to look at.

Now they have text as well,
and they keep jumping between the two,
while the ears
carry the same words a third time.

It is not a law
for every case.

If there is no picture,
if the audience is working
in its second language,
or the room is noisy,
words on the screen
can help.

But a plan with a diagram in it,
read aloud to people
who could read it themselves,
costs attention
and returns none.

So split the jobs.

The slide carries the picture.

The shape of the migration,
the boxes that move,
a few words to label them.

Your voice
carries the sentences.

What happens first,
what could go wrong,
what you need from them.

And the full text,
every detail,
goes in a document
sent before or after,
where people can read it
at their own speed
without you talking over it.

If you catch yourself
reading a bullet aloud,
stop,
and say why it matters instead.

They can already read.

What they cannot do
is read your mind.

– Serguey Asael Shinder

You Have Heard So Often That the Database Is the Bottleneck That You Believe It

Serguey Asael Shinder — Fri, 06 Nov 2026 09:47:51 +0000

Every planning meeting
somebody says it.

We cannot add that report.

The database will not take it.

Nobody argues.

You have said it yourself,
to a new starter,
with complete confidence.

Then one quiet week
somebody ran the test.

Ten times the reporting load,
on a copy of production.

The database
barely noticed.

The slow part
was one query
nobody had looked at,
and a connection pool
set to five.

Where did the belief come from?

Nobody could say.

Someone remembered an outage,
three years and two servers ago.

Everyone else
had simply heard it,
many times.

That turns out
to be enough.

In 1977
Lynn Hasher and her colleagues
gave people a list
of plausible statements,
some true and some false,
and asked how true each one seemed.

They came back
two weeks later,
and again after that.

Some statements
appeared every time.

Those were rated
more and more true,
whether they were true or not.

It is called
the illusory truth effect.

The best explanation
is fluency.

A sentence you have met before
is easier to process.

And easy
feels like right.

You do not remember
the source.

You remember
that it went down smoothly.

In 2015
Lisa Fazio and her colleagues
showed it working
even against what people knew.

Repeat a false line
about something they could answer,
like the name of the skirt Scots wear,
and belief in the false version
still went up.

Knowing better
did not fully protect them.

A team
is a machine for repeating things.

Standups,
retros,
the onboarding talk,
the old wiki page.

Every repetition
makes a claim smoother,
and not one of them
makes it more tested.

So when a sentence
feels too obvious to check,
ask where it came from.

Not whether it is true.

Where you first heard it,
and what that person had measured.

If nobody knows,
it is a rumour
with good attendance.

Write the team's load bearing beliefs down,
each with its evidence
and the date it was checked.

The database cannot take more load.

Measured when,
on which hardware,
by whom?

When one stops being true,
cross it out
where everyone can see.

And notice the moment
you say it yourself
to someone new.

That is how it spreads.

Familiar
is not the same as checked.

It only feels that way
from the inside.

– Serguey Asael Shinder

You Copied the Guitar to Both Sides and It Still Sat in the Middle

Serguey Asael Shinder — Fri, 06 Nov 2026 09:47:18 +0000

The rhythm guitar
was recorded once,
and it was a good take.

You wanted it wide.

The big kind of rhythm sound,
one guitar in each speaker,
the chorus filling the room.

So you duplicated the track,
panned one copy hard left,
the other hard right,
and pressed play.

It was louder.

It was not wider.

The guitar sat
exactly where it had been,
in the middle,
between the speakers.

Nothing was broken.

You had built
a centre.

Your ears decide
where a sound is
by comparing what reaches each of them.

Louder on the left,
or a little earlier on the left,
and it is on the left.

Two speakers playing
the exact same signal,
at the exact same level,
at the exact same time,
give your ears nothing to compare.

The only place
one source could be
to sound like that
is straight ahead.

So that is where you hear it.

It is the same trick
that puts the lead vocal
in the middle of a mix
with no centre speaker at all.

Panning a copy hard left
and its twin hard right
is just panning it to the centre
the long way round,
plus a few decibels.

What makes a double tracked guitar wide
is that it is not a copy.

The player
plays the part again.

The second take
is a few milliseconds early here,
a little late there,
a fraction sharp on one chord,
picked slightly harder on another.

Those differences
keep changing,
so your ears cannot fuse the two
into one guitar in the middle.

They hear two players,
one on each side.

So play it twice.

Same part,
same sound,
a real second performance.

Tight,
but not perfect,
because perfect
would put you back in the centre.

Then pan them apart.

If there is no second take,
there are ways to fake it.

Abbey Road built a way
in 1966,
artificial double tracking,
because John Lennon
hated singing everything twice.

A slowly wandering delay,
a small pitch shift,
a different amp sound on the copy.

They help.

None of them is as wide
as playing it again.

And whatever you do,
press the mono button afterwards.

A copy
nudged a few milliseconds late
can sound wide in stereo
and thin and hollow
when the two sides are added together.

Real takes
survive that better,
because their differences
never line up long enough
to cancel.

Width is not
two speakers playing.

It is two speakers
disagreeing a little.

– Serguey Asael Shinder

You Turned Up the Repetition Penalty and the Model Renamed Your JSON Keys

Serguey Asael Shinder — Fri, 06 Nov 2026 09:46:41 +0000

Somebody on the team
was tired of the marketing copy
saying seamless
four times a paragraph.

So they found a setting.

Frequency penalty,
turned up to one point five.

It worked.

The copy got more varied.

The setting lived
in the shared client config.

Two weeks later
the invoice extractor,
which used the same client,
started losing rows.

Fifty invoices in,
fifty JSON objects out,
and the first twenty
were perfect.

After that
the keys began to wander.

supplier became vendor.

total became amount_due,
then sum.

One record
wrote invoice number
with a space in it.

The parser
expected exact names,
skipped what it did not recognise,
and reported success.

Here is what the setting does.

At every step
the model scores
each possible next token.

A frequency penalty
lowers the score of a token
by a fixed amount
for every time
it has already appeared
in the answer.

Twice,
two steps down.

Thirty times,
thirty steps down.

Its sibling,
the presence penalty,
lowers it once,
as soon as it has been used at all.

In prose
that pushes away
the tired word.

In a list of fifty records
the most repeated tokens
are exactly the ones
that must not change.

The key names.

The quotes.

The braces.

By record twenty,
supplier
had been written twenty times,
and every one of them
counted against the next.

The model was not confused.

It was obeying.

Writing the same word again
had become the expensive choice,
so it picked the nearest cheap one.

Code fails the same way.

A variable used often
gets renamed halfway down a function.

A closing bracket
starts losing to something else.

So keep penalties
out of anything
with a fixed vocabulary.

JSON,
code,
SQL,
labels from a list.

Set them per task,
not in a client
that every task shares.

Where the API offers it,
use structured output
with a schema,
so the keys are enforced
while the answer is written,
not hoped for afterwards.

And make the parser loud.

An unknown key
is an error,
not a row to skip.

Repetition
is a fault in an essay.

In a format
it is the whole point.

– Serguey Asael Shinder