#ссылка дня

Apple славится не только тем, что достаточно медленно развивает Safari в угоду (?) производительности на ватт и безопасности, но и тем, что добавляет в движок очень много фишек, делающих интеграцию WebView в приложения на macOS и iOS проще. Часть, казалось бы, нативных Apple Music, Apple Maps и так далее — это WebView, а вы и не догадывались.

И вот одной из таких фишек стало добавление атрибута switch к обычным чекбоксам. Очевидно, превращающим галочки в переключатели. Да, семантика выходит иная.

Поспольку остальные браузеры не спешат это добавлять (как раз по причине того, что это, ну, разные же элементы, атрибут выглядит странно), Томас Стайнер реализовал полифилл: https://blog.tomayac.com/2026/01/12/a-polyfill-for-the-html-switch-element/

Демонстрацию можно посмотреть там же.

Ссылка на репо: https://github.com/whatwg/html/pull/9546

Как считаете, пора делать переключатели базовыми инструментами форм, или нет?

#css #switch #safari

#фишка дня

Если ты увлёкся добавлением pointer-events: none к элементам: может чтобы люди не копировали, а может, чтобы UX был получше, — есть вероятность, что дебаг в девтулзах превратится в мучение.

Вот как выделить объект, который не слушается мыши?

Все очень просто, зажми Shift и выделяй. Работает в Chrome, Edge и Firefox.

#devtools #tips #chrome #firefox #бородач

#видео дня

Когда я стал работать в нормальной компании, а не в веб-студии, я внезапно узнал, что оценка задачи происходит в баллах. «Стори поинтах», story points.

И стори поинты это не часы. Это некая условная оценка сложности. И выражается, как правило, в числах Фибоначчи: 1, 2, 3, 5, 8… Близко к экспоненциальной зависимости.

Если кому интересно, статей на эту тему много. Но дальше происходит самое интересное.

Оценка сложности не нужна :) Не в том смысле, что все задачи одинаковы, нет. А в том смысле, что не имеет особого смысла их делить.

Очень часто возникает ситуация, в которой все задачи на спринт оцениваются в 3. Или даже, что чаще, в 5. Ну просто потому что. Потому что так команде удобнее.

И вот, например, доклад именно на тему оценки сложности: https://m.youtube.com/watch?v=QVBlnCTu9Ms

Стоит посмотреть. Много здравых мыслей. Как минимум, вы решите для себя: более усердно относиться к оценке или же просто ограничить число задач на спринт.

Не болейте.

#agile #teamlead #scrum #бородач

#игра дня

Забавно, что в играх мы спокойно управляем экономикой, считаем ресурсы и думаем на несколько шагов вперёд. А когда речь про инфраструктуру — это уже «что-то сложное и серьёзное».

Нашёл проект — server-survival. Это по сути симулятор, где ты строишь свою серверную систему и пытаешься, чтобы она не развалилась. Есть деньги, есть доход от трафика, есть репутация. Всё, что добавляешь в архитектуру, стоит денег. Всё, что падает, бьёт по карману.

Нужно решать: масштабироваться заранее или рискнуть, держать запас прочности или экономить, как пережить внезапную атаку и не уйти в минус.

Мечтал побыть клауд-архитектором? Вперёд:
https://github.com/pshenok/server-survival

#cloud #game

#статья дня

Посмотрите на иллюстрацию. Я не буду говорить: "Ничего интересного не замечаете?", — ну просто потому что в самом коде ничего интересного нет. Секрет кроется в подсветке кода.

И суть в том, что подсветка кода сделана... шрифтом.

Кроме шуток, я когда это увидел, я подумал "ну точно какой-то финн упоролся". Есть у финнов такое направление в дизайне, извращение над шрифтами называется. Вот, например, шрифт, который становится тоньше из-за изменения климата: https://kampanjat.hs.fi/climatefont/

И да!

Автор шрифта — Хейкки Лотвонен. И он буквально выжал всё возможное из фишки COLR (это чуть больше чем лигатуры на стероидах) стандарта шрифтов OpenType: https://blog.glyphdrawing.club/font-with-built-in-syntax-highlighting/

Статья не только рассказывает о возможностях шрифта, но и погружает в понятие COLR: палитра, правила совмещения, лигатуры.

Поддерживаются HTML, CSS и даже JavaScript. Более того, можно перегружать цвета, получая свою собственую тему!

В общем, прекрасная взрывающая мозг статья. И применение самое что ни на есть реальное.

Есть обсуждение на HackerNews, вдруг кому интересно.

И CodePen с демо: https://codepen.io/argyleink/pen/GRbyNNv

Подробное описание технологии COLR от разработчиков Google Chrome: https://developer.chrome.com/blog/colrv1-fonts

В общем, Финляндия это не только озёра и Linux, но и шрифты. Теперь и вы знаете.

#opentype #fonts #colr #бородач

#статья дня

Оказывается, ignore-файлы — это не только .gitignore. Почти каждый инструмент в экосистеме тащит свою версию формата, и хотя все говорят «поддерживаем синтаксис .gitignore», нюансы часто отличаются.

Хороший пример — .npmignore. Если его нет, npm ориентируется на .gitignore. Но как только вы добавляете .npmignore, он полностью заменяет правила из .gitignore. В итоге можно случайно опубликовать в пакет то, что в Git было исключено, или наоборот — не опубликовать нужные файлы. Поведение похоже, но не идентично, и легко запутаться.

В статье перечисляется целый зоопарк `ignore`-файлов:

.gitignore — Git
.dockerignore — Docker
.npmignore — npm
.prettierignore — Prettier
.eslintignore — ESLint
.stylelintignore — Stylelint
.hgignore — Mercurial
.containerignore — Podman/Buildah
.gcloudignore — Google Cloud CLI
.vercelignore — Vercel
.slugignore — Heroku
.cfignore — Cloud Foundry
.helmignore — Helm
и т. д. и т. п.

Вывод простой: одинаковое название не гарантирует одинаковое поведение. Если инструмент что-то «внезапно» включает или исключает — почти всегда дело в деталях реализации ignore-логики.

Собственно, ссылка: https://nesbitt.io/2026/02/12/the-many-flavors-of-ignore-files.html

#gitignore #ignore

#ссылка дня

Каждый из нас при взгляде на кодовую базу когда-нибудь ловит себя на мысли "есть ли вариант элегантнее и проще, может спецификацию обновили". Особенно это актуально в контексте стилизации (к счастью сейчас развитие спецификации можно назвать стремительным).

Но чтение разрозненных статей/заметок, попытки получить внятный ответ ИИ зачастую вносят лишь сумятицу.

Ведь хорошо когда можно найти готовые примеры современных решений частых (и не очень) задач в сравнении до/после.
Еще лучше когда для каждого примера указана поддержка браузерами использованных свойств спецификации.

https://modern-css.com содержит пока небольшое количество примеров, но с понятным описанием и ченжлогом

#заметка дня

В чат прилетел вопрос: "Как добавить иконку в поле ввода так, чтобы она была видна только когда виден плейсхолдер и исчезла при вводе текста?"

Отвечаем: конечно же добавить её в контейнер label, а потом использовать псевдо-класс :placeholder-shown на поле ввода!

Он очень давно и хорошо поддерживается, так что почему бы и нет.

Оставим за пределами этого обсуждения тот факт, что плейсхолдеры не должны заменять реальные метки. Это всё равно уже стало де-факто стандартом индустрии... но постарайтесь так не делать.

И, конечно, пример:
https://codepen.io/alinaki/pen/xxMpgLK?editors=1100

Там заодно используются SVG-спрайты, потому что мне лениво подключать профессиональный аккаунт на кодпене и грузить туда картинки. Так что заодно можно посмотреть, как работать со спрайтами. Пригодится!

Всем бу, котаны!

#css #placeholder #svg #sprite #бородач

#фишка дня

CSS anchor positioning aka якоря могут реально поменять то, как мы с вами реализуем интерфейсы, требующие графового представления: CJM, майндмапы, блок-схемы, пайплайны...

Темани Афиф недавно сделал пример, соединив круги стрелками и набросив немного JS для drag&drop: https://css-tip.com/connected-circles/

Потом немного улучшил: https://css-tip.com/connected-circles-2/

И пару дней назад пошёл ва-банк и представил буквально реализацию поиска кратчайшего пути в графе: https://css-tip.com/graph-theory/

Выглядит, конечно, весьма сложно. Но следующим шагом, видимо, будет транспиляция Mermaid в CSS... Зато самому алгоритм стрелок реализовывать не придётся! 😂️️️️️️

#css #anchor #graph

#ссылка дня

Дамы и господа, мы зашли слишком далеко.

Нужна виртуалка на Intel, а у тебя мак? Не вопрос, давай напишем эмулятор на CSS!

Проект X86CSS — это эмулятор x86-ассемблера без JavaScript. Вообще. Всё состояние процессора — через CSS-переменные. Исполнение — через

«Процессорный цикл» — это просто тик анимации. Пять герц в эквиваленте.

ПЯТЬ. Не гигагерц, а герц.

Идея выросла из статьи The CPU Hack на dev.to: современные возможности CSS позволяют организовать пошаговое изменение состояния. Если состояние можно хранить, менять и пересчитывать, а изменения можно повторять — система становится тьюринг-полной.

Как это выглядит в упрощённом виде.

Тик процессора:

@property --ip {
  syntax: "<integer>";
  inherits: false;
  initial-value: 0;
}

@property --tick {
  syntax: "<integer>";
  inherits: false;
  initial-value: 0;
}

.cpu {
  animation: clock 0.1s steps(1) infinite;
}

@keyframes clock {
  to {
    --tick: calc(var(--tick) + 1);
  }
}

.cpu {
  --ip: calc(var(--ip) + var(--tick));
}

Анимация создаёт шаг. На каждом шаге меняется состояние.
От состояния зависит, какие инструкции сработают дальше.

Ввод — тоже без JS. Например, зажатая кнопка:

.key:active ~ .cpu {
  --running: 1;
}

.cpu {
  --running: 0;
  --ip: calc(var(--ip) + var(--running));
}

Пока кнопка нажата — переменная меняется и влияет на вычисления.

В реальном проекте вместо двух переменных — регистры, память, флаги и декодирование инструкций. Сотни их.

Практической пользы — ну, нет.

Но сам факт, что CSS можно довести до уровня полноценной вычислительной модели и запустить на нём x86 — выглядит как интересная точка в эволюции фронтенда.

Ах, да. Работает только на Chrome, потому что — какая внезапность — использует условный оператор (if), который появился совсем недавно. И вот это — это вполне себе имеет практическое применение.

Просто пойдите и поиграйте в это. Ощущения невероятные, хрен с ней, с применимостью на практике, честное слово. Это целый компьютер! Вы можете даже программы для него компилировать с C на x86asm. Буквально.

#css #cpu #x86 #hack

#такое дня

Люди в LinkedIn, конечно, странные. Удивительно, что useEffect и use ничему его не научили в продажах. Но не суть.

А суть в том, что ребята из React, конечно, как продолжали вносить смуту и вытаскивать наружу внутренние особенности реализации, так и продолжают. И никакие You Might Not Need an Effect тут уже не помогут.

Но вообще, конечно, просто смешная картинка. Ведь очевидно, что нужно использовать Effector React Query.

#react #thoughts

#фишка дня

Многие недооценивают css variables, особенно при небольшой поддержке javascript.

Думали динамически можно изменять только цвет/типографику и что-то еще такое же очевидное?
А вот и нет, управлять можно даже текстом (ну ладно, еще немного математикой).

Идея для использования - динамический брендинг.
Задали название продукта/компании/клиента в одном свойстве --client-id и изменили один раз для шапки/подвала/сайдбара.

Пример кода показывает насколько это легко понять и использовать.
https://codepen.io/glebcha/pen/gbpwbob

#css #var #бородач

Какую крутоту Саша сделал! В вебе таких инструментов совсем немного.

#заметка дня

Продолжение эпопеи про пульт для телевизоров на Flutter. В последнем посте я писал об неком подобии игры в CTF на сайте Samsung Apps.

Что появилось с тех пор? Вообще, достаточно многое, но сейчас — чуть более прозаичная тема.

Как это обычно бывает, иногда приходится внимательно смотреть, как те же задачи решают другие.

Наткнулся на один пример, который идёт ровно по поему плану. Удивило, что у них — одна кнопка для play/pause, как на обычных пультах.

Я был почти уверен, что без реального знания состояния плеера это корректно не сделать. Стало принципиально интересно, как они это реализовали.

Попробовал декомпилировать через Ghidra — толком не вышло. Кроме строк ничего полезного вытащить не удалось, и там — ничего примечательного: ни скрытых команд, ни дополнительных кнопок. Тогда пришлось идти по сетевому следу.

Поднял сервер, отвечающий на SSDP-запросы, начал сниффать весь трафик на предмет поисковых строк, логировать каждый запрос и его аргументы. Многие вещи пришлось копировать с реального телевизора — в том числе DMR-запросы (Digital Media Renderer, часть стандарта DLNA), через которые устройство объявляет и принимает мультимедийные возможности.

Больше всего времени ушло на корректный ответ токен-авторизации: нужно было добиться, чтобы приложение приняло фейковый ответ.

Ирония в том, что моё приложение в своё время вообще не проверяло формат ответа и не ждало подтверждения — вроде как получил токен и достаточно.

Убил пару часов, а оказалось...

...оказалось эти гении просто отправляют pause и ставят у себя флажок. Следующее нажатие — play. Потом снова pause... ну вы поняли. Если видео не играет — нажать надо два раза. А если с другого пульта остановить воспроизведение — тоже.

Я ожидал API, а получил социальную инженерию, на которую сам и попался. Надо было просто потестировать дольше минуты.

Тем временем мой пульт уверенно движется к релизу: аккуратно выглядит на разных мобильных устройствах, на десктопах появились горячие клавиши, помимо Samsung Tizen теперь частично поддерживается и LG webOS, а ещё можно кастить фотографии на экран телевизора.

Для публикации в Google Play нужно 12 тестировщиков — если хотите поучаствовать, буду рад услышать.

#flutter #remote #smarttv

#инструмент дня

Тактильный отклик на телефонах — штука потрясающая.

Конечно, лучше когда он реализован линейным актуатором, но и обычная вибрация сойдёт. Обратная связь в играх, уведомления об успехе-неуспехе, просто подтверждение действия — вот это вот всё.

Правда, думаю, из-за избыточного использования вибрации в DuoLingo, Taptic Engine на моём iPhone и разболтался...

Так вот, давно уже существует API navigator.vibrate(). Позволяет ли Apple его использовать на своих устройствах?

Конечно же, нет.

Но при этом есть интересная штука. На iOS любой чекбокс можно превратить в переключатель атрибутом switch. И что делает такой переключатель, когда на него нажисают? Правильно, откликается вибрацией.

И это могло остаться незамеченным, но нашлись люди, которые на базе одной только этой штуки сделали целую библиотеку обратной связи! Встречайте: https://haptics.lochie.me/

Одиночные сигналы, паттерны вибрации — вот это вот всё.

Не, ну вы понимаете, да? Создают виртуальные переключатели и теребонькают их. Fuck you, Apple в чистом виде. Результат весьма убедительный.

Конечно, есть и ограничения. Работает только по клику. Но даже это покрывает кучу юзкейсов.

Надеюсь, это немного заставит Apple пересмотреть политику в API браузера.

#vibrate #haptic #taptic

#заметка дня

Иногда по разным причинам хочется задать собеседнику очень простой вопрос: а ты вообще пробовал ну… читать?

Не «читать книги, чтобы стать лучше». А в рабочем. Читать текст с экрана. Потому что если так посмотреть, почти всё, что мы делаем с кодом, — это именно чтение.

Мы читаем код. Читаем результаты поиска. Читаем ошибки. Читаем документацию. Читаем чужие pull request’ы, логи, комментарии, ответы в чатах. Писать зачастую приходится намного меньше, чем читать и разбираться в уже написанном.

И на этом фоне довольно забавно выглядят разговоры про ИИ. Постоянно всплывает вопрос: «а кто будет ответственен за код?» или «а что он там вообще делает?»

В смысле, блин, что делает?! Ты читать-то пробовал?!

Вся ирония в том, что ИИ как раз очень много пишет. Пишет, что собирается сделать, показывает diff, объясняет шаги, ссылается на документацию. В конце ещё и резюмирует результат. То есть по сути ведёт подробный текстовый отчёт о своей работе.

Я Copilot, зачастую, даже тормозить успеваю в процессе раздумий, ну потому что вижу, что начинает думать херню.

И это, внезапно, оказывается удобным способом учиться. Можно спросить, почему он сделал именно так. Можно вытащить из ответа незнакомый термин и пойти почитать отдельно. Можно, наконец, разобраться в библиотеке или подходе, до которого раньше не доходили руки.

Причём, как ни странно, это ещё и хорошо помогает с двумя вещами, которые знакомы почти каждому разработчику: страхом чистого листа и синдромом самозванца.

Потому что у вайбкодеров из отдела продаж или у дизайнеров, которые прям щас утверждают, что готовы тебя заменить, никакого синдрома самозванца не наблюдается.

Перед тобой уже не абстрактное «сделай систему», а текст: код, diff, объяснение, план действий. Дальше по накатанной.

Поэтому когда разговор снова возвращается к классическому «а кто будет ответственен за код», мне каждый раз кажется, что проблема на самом деле не там.

Проблема не в ИИ.
Проблема в том, что всё это требует одной довольно старой привычки — читать.

А ты так и не научился.

#llm #work

#инструмент дня

Я в универе постоянно делал презентации для своих работ и семинаров. Ну просто как минимум потому, что старание — это всегда плюс балл не только к оценке, но и к репутации.

Это, кстати, вполне себе лайфхак. Пишите лабы по программированию на двух языках, делайте нормальные доки — и будет вам легко.

Но не суть. Я сильно пристрастился к тачпаду на ноутбуке, потому все визуальные задачи, где нужно было мышевозить, давались с трудом. Когда готовишь документ, горячие клавиши спасают, а уж сейчас всё сразу в Markdown по-умолчанию пишешь и голова не болит. Но вот презентации и электронные схемы — дело другое.

И если для схем я ещё готов подключить мышь, напрячься и так далее, то презентации я писал на HTML, используя https://revealjs.com/.

Но инструмент, который хочу показать сегодня — это https://sli.dev/

Что он делает? Из видео, в общем, понятно — преобразует Markdown-файлы во всё те же презентации! Это очень круто, почти один уровень с Mermaid по удобству.

Горячая рекомендация.

#markdown #tool #presentation

Я довольно часто вижу тексты про выгорание и «научитесь отдыхать», и каждый раз немного спотыкаюсь об один момент. Там обычно много советов про хард-стопы, не писать после восьми, не работать в отпуске — и это всё, конечно, правильно. Но создаётся ощущение, что проблема будто бы решается просто дисциплиной: возьми и выключи работу из головы.

Вот в тему поста Димы из Яндекс Лавки — поймал себя на мысли, что на практике это у многих работает чуть сложнее. Мозг продолжает крутить работу не из вредности. Он просто пытается дожевать то, что осталось незакрытым: нерешённую задачу, странное решение, ощущение, что что-то пошло не так. И сколько ни говори себе «стоп», если внутри висит этот незакрытый хвост — он всё равно будет возвращаться.

Иногда помогает довольно простая вещь: довести мысль до какого-то финала. Принять решение. Даже если это решение — «ну и чёрт с ним».

Недавно у меня сломался чемодан — крепление колёс. Первый раз починил. Второй раз починил. На третий раз даже приготовил всё для ремонта — и вдруг понял, что это уже какой-то чемодан без ручки.

В итоге просто вынес его на помойку. Тоже решение проблемы. И удивительным образом после этого голова про чемодан больше не думает вообще.

С рабочими задачами часто так же. Иногда мозгу нужно не «перестань думать», а точка: решение, план, отказ, перенос, признание, что это не стоит времени. Как только она появляется — он обычно довольно охотно отпускает.

#инструмент дня

Иногда мелкие неудобства в разработке настолько привычны, что мы перестаём их замечать. Один из таких примеров — бесконечные localhost:3000, localhost:5173, localhost:8080.

Запускаешь несколько сервисов — фронтенд, API, сторибук, документацию — и через час уже не помнишь, что было на каком порту. Перезапустил сторибук — и он уже на другом.

Бесит.

В Vercel Labs решили попробовать убрать саму причину проблемы и выпустили экспериментальный инструмент Portless. Идея очень простая: вместо портов использовать локальные доменные имена.

Было так:

http://localhost:3000
http://localhost:8080
http://localhost:5173

Стало так:

http://app.localhost
http://api.localhost
http://docs.localhost

Домены просто пробрасываются на реальные порты. Но разработчику больше не нужно их помнить.

Самое интересное — почему это вообще стало возможным.

Несколько лет назад в спецификациях закрепили правило: любой домен вида *.localhost должен автоматически резолвиться в loopback-адрес (127.0.0.1). Браузеры реализовали это поведение, поэтому api.localhost, app.localhost и любые другие подобные имена гарантированно указывают на ваш компьютер и даже считаются безопасным контекстом для веб-API.

Это открыло путь для инструментов, которые делают локальную разработку похожей на продакшен и больше не вспоминать, где был :3000, а где :5173.

Такая схема неожиданно удобна и для AI-инструментов. Когда адрес сервиса всегда один и тот же (app.localhost), кодовые агенты не ломаются из-за того, что dev-сервер внезапно переехал на другой порт.

В общем, такое мы одобряем.

Впрочем, никто никогда не мешал поднять локальный nginx и делать вообще что угодно.

#dev #port