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

Наткнулся на шрифт Datatype.

Это вариативный шрифт, который превращает текст в… графики. Прямо через лигатуры. Пишешь что-то вроде:

{l:15,45,90,30,75,20,85,95} → получаешь линейный график
{b:30,70,50,90} → столбики
{p:65} → круговую диаграмму

То есть никакого SVG, canvas и прочего.

Сделано это через OpenType-лигатуры + вариативные оси. По сути, шрифт парсит жисон и подменяет символы на нужные глифы. Выглядит интересно.

Где это может быть полезно:
— быстрые прототипы графиков прямо в тексте
— документация
— демки и презентации

Минусы:
— копирование: вставится исходный текст, но не график (логично)
— доступность: скринридеры будут читать это как {l:15,45…}, а не как график (решаемо)
— кастомизация сильно ограничена

Хотя как концепт — очень круто.

Пощупать можно тут:
https://franktisellano.github.io/datatype/

Где используем, котаны?

#font #diagram

#статья дня

Кажется странным, что сначала в браузерах (браузере?) появились переходы между страницами aka View Transitions, и только сейчас — между элементами.

В Chrome 147, наконец, добавили element-scoped view transitions.

До этого если хотелось анимировать, например, сортировку списка, приходилось запускать document.startViewTransition() — даже если менялся один маленький блок.

Выглядело это примерно так:

document.startViewTransition(() => {
  list.sort(...)
  render()
})

Теперь можно запустить переход прямо на контейнере списка:

listElement.startViewTransition(() => {
  list.sort(...)
  render()
})

И в этот момент браузер работает только с этим куском DOM.

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

Сплошные плюсы.

Собственно, статья:
https://developer.chrome.com/blog/element-scoped-view-transitions

Что ещё в Chrome 147:
https://developer.chrome.com/blog/new-in-chrome-147

#chrome #view #transitions

#codepen дня

Ну что, кажется, настало то время, когда для стилизации радиокнопок и чекбоксов не нужно больше изгаляться с input:checked+i. Это освобождает мозг и руки для более приятных вещей.

Итак, смотрим на пример от Джона Кантнера: https://codepen.io/alinaki/pen/ExMXbqz

1. Для начала, обнуляем все браузерные стили и предположения браузера об внешнем виде радиокнопок вообще через appearance: none.

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

Благодаря этой возможности, собственно, можно стилизовать чекбокс как душе угодно: ::before, ::after, :checked::before, :checked::after... В целом, лично я бы обошёлся радиальным градиентом и одним псевдоэлементом.

3. Освободившиеся ресурсы мозга и тот факт, что теперь все элементы красиво вложены в label (как минимум, не нужны for и id), можно отправить на реализацию разных эффектов.

Например, проверить, есть ли лейбл с выделенным чекбоксом и подвинуть к нему рамку:

label:nth-of-type(2):has(input[type="radio"]:checked) ~ .selection {
 transform: translateY(100%);
}

Обратите внимание, рамка — отдельный элемент, к ней обращаемся через селектор низлежащих соседей ~.

Не знаю, что меня больше впечатляет. Псевдоэлементы на полях ввода или :has.

И да, поддерживается везде.

#css #has #appearance #бородач

#статья дня

Висящие промисы как простой способ оборвать async-функцию

await new Promise(() => {})

Зачем так делать?

Отмена через throw ненадёжна — её легко случайно поймать в try/catch, и код поедет дальше.

try {
  await handler()
} catch (e) {}

С висящим же промисом выполнение гарантированно останавливается.

Где это используется?

В пошаговых workflow, где функция должна завершиться на середине и продолжиться позже.

async function signup(user) {
  await step("create-user", user)

  if (!user.emailVerified) {
    await new Promise(() => {}) // закончили здесь
  }

  await step("send-email", user)
}

Оркестратор сохраняет прогресс и потом запускает её заново, пропуская выполненные шаги.

Минусы:
— такой код легко сломать случайно: забытый await или лишний Promise — и функция зависнет навсегда
— трудно дебажить: нет ошибки, нет стека, просто «ничего не происходит»
— не подходит для обычного приложения без оркестратора (сам по себе это тупик)
— может путать других разработчиков: выглядит как баг, а не как намеренное поведение

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

А, ну да. Сама статья: https://www.inngest.com/blog/hanging-promises-for-control-flow

#js #promise #halt

#фишка дня

А вы знали, что в GitHub Markdown не надо списки нумеровать самому?

1. Раз
1. Два
1. Три

будет буквально преобразовано в

1. Раз
2. Два
3. Три

И не надо париться, когда редактируешь.

P. S. оказывается, есть такая штука, как mdlint, и она на самостоятельную нумерацию очень даже ругается.

#статья дня

Scroll-driven animations уже давно есть в Chrome, и за последний год вокруг них накопилось много примеров — у того же Bramus Van Damme были подробные демки с view-timeline и разными вариантами ranges. Теперь появился ещё один большой разбор от самого Джоша Комо: https://www.joshwcomeau.com/animation/scroll-driven-animations/

Как всегда, это интерактивная документация по animation-timeline.

Посмею себе напомнить ключевую идею процесса: прогресс анимации берётся не из времени (`animation-duration`), а из положения элемента относительно viewport или scroll-контейнера. В статье это сразу показывается на примере с progress bar, где значение анимации напрямую связано со скроллом страницы.

Дальше он последовательно вводит scroll-timeline и view-timeline. Первый вариант привязывается к прокрутке контейнера, второй — к тому, как конкретный элемент входит и выходит из viewport. Есть наглядные демо, где один и тот же @keyframes ведёт себя по-разному в зависимости от выбранного таймлайна.

Отдельно разбирается animation-range. На интерактивных примерах видно, как entry, exit, cover, contain влияют на диапазон, в котором проигрывается анимация.

Есть демонстрации с несколькими timeline’ами и синхронизацией анимаций, где один scroll-прогресс управляет сразу несколькими свойствами.

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

Документация: https://developer.mozilla.org/en-US/docs/Web/CSS/animation-timeline
Примеры от Google: https://developer.chrome.com/docs/css-ui/scroll-driven-animations/

Из нюансов — Safari всё ещё отстаёт: часть API отсутствует или работает неполно, так что без фоллбеков пока не обойтись.

#css #scroll

#заметка дня

Ли Робинсон — разработчик и тренер в Cursor — поделился практическими советами о том, как выделиться среди сотен кандидатов при подаче на инженерную позицию.

Как сделать своё инженерное резюме заметным (глазами человека, который смотрит сотни резюме):

1. Резюме должно быть на одну страницу. Если нужно больше — добавьте ссылку на сайт. Не нужно по 10+ пунктов на каждую работу.

2. Вы сразу будете выделяться среди >90% кандидатов, если у вас есть персональный сайт с продуманным содержанием.

3. Если вы указываете свой X (Twitter), возможно, стоит почистить посты? Звучит очевидно, но люди публикуют всякое.

4. Обязательно добавьте GitHub. И, пожалуйста, без профиля в стиле MySpace с кучей бейджей и картинок — я хочу видеть код и ваши реальные навыки.

5. Адаптируйте отклик под компанию. Для стартапа курсы из университета менее важны. Для FAANG — могут помочь пройти ATS.

6. Удивительно, но многие резюме вообще не упоминают AI или агентов. Разработка меняется, и от вас ожидается понимание работы с AI. Это должно быть отражено в проектах и резюме.

7. Относитесь к LinkedIn серьёзно. Да, разработчики чаще сидят в X, но внутри компаний всё ещё пересылают именно LinkedIn.

8. Покажите свою индивидуальность: интересы, вкус, мышление. Книги, тексты, фильмы — всё, что раскрывает вас как человека. В конце концов, люди хотят работать с теми, кто им интересен и приятен.

9. Не используйте AI для написания резюме или сопроводительного письма. Это очень заметно, особенно в AI-компаниях. Можно использовать для идей, но писать — самому.

10. Не добавляйте фото в резюме. Лучше разместите его на внешних ссылках.

11. Качество важнее количества. Лучше 3 сильных проекта, чем 27 поверхностных AI-поделок.

Помните: рекрутеры просматривают сотни и тысячи откликов. Они не будут тратить 20 минут на каждый. Уберите лишнее и переходите к сути.

#resume #cv

В CodeRun встроили AI-тренера на SourceCraft

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

— прогрессивные подсказки;
— тест-кейсы для проверки решения, включая краевые случаи;
— разбор примеров из условия.

Чтобы попробовать, заходи в задачи на CodeRun и открывай вкладку «Кодерун AI». Пока фича в бета-режиме, нужна авторизация, а лимит — 20 запросов в сутки.

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

Надоело каждый раз выходить из уютной консоли и открывать caniuse.com, чтобы посмотреть, с каких браузеров поддерживаются сабгриды?

Ой, только не говорите, что я один тут верстаю вслепую.

Вашему вниманию Bramus Van Damme и его caniuse-cli: https://www.npmjs.com/package/@bramus/caniuse-cli

$ caniuse viewport-units
$ caniuse "viewport units"
$ caniuse @property

Имеется автокомплит для zsh.

Ну, консольные маньяки, перепись!

P. S. Скилл для Клода есть же уже?)

#cli #caniuse #бородач

#такое дня

Когда в следующий раз будете ворчать на коллегу за PR в 200 строк — вспомните это: https://github.com/oven-sh/bun/pull/30412

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

Штош.

P. S. кстати, почитайте, что ответили авторы Zig о недавнем «ИИ-форке», который представили Bun. Там прям интересно.

#rust #zig

#фишка дня

Итак, все мы знаем, что при добавлении скроллбара (если этот скроллбар, конечно, виден) у нас происходит сдвиг по фазе полей справа.

Ну или слева, если вы араб.

Но это же можно исправить! Используя правило scrollbar-gutter: stable можно зарезервировать место под скроллбар, не прибегая к иным методам вроде overflow: scroll (который буквально этот самый скроллбар заранее покажет, даже если он не нужен).

Демо от Ахмада Шадида в его Defensive CSS: https://defensivecss.dev/tip/scrollbar-gutter/

Can I Use: https://caniuse.com/?search=scrollbar-gutter

Поддержка в Chrome и Firefox. В Safari пока только в TP, но на Apple-устройствах скроллбары, как правило, скрыты и отображаются поверх контента, не занимая места.

Выглядит это, правда, как дополнительный паддинг, но!

Есть интересное но в виде scrollbar-gutter: stable both-edges, которое зарезервирует место под скроллбар, и такое же — на другой стороне. Что, в целом, избавит нас от разных паддингов.

Раньше за похожее решение отвечало правило overflow: overlay, но его отменили в пользу gutter.

Лучше всего это работает, впрочем, для попапов. Мало кого волнует скроллбар на тексте, а вот прыгающий body при появлении модалки — это уже перебор.

#css #scrollbar #gutter #бородач

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

На заре развития компьютеров утилиты были максимально простыми. Открыл файловый менеджер, скопировал файл, переименовал, удалил. Или упаковал всё через PKZIP и перенёс дальше. Это были отдельные программы под конкретные действия, без лишней обвязки.

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

Позже началось обратное движение к упрощению. Интерфейсы стали легче, а инструменты — более однофункциональными. Появились менюбарные и systray-утилиты, CLI-скрипты и маленькие инструменты под одну задачу. А как вам взрыв популярности командных палитр, как в Sublime Text и VS Code?

Я на этой волне решил сделать свой Color Picker, экранную пипетку: чтобы можно было брать цвет с любой точки экрана, собирать палитру и экспортировать в разных форматах. Получилась небольшая, но удобная утилита, которой уже даже пользуюсь. Вот: https://github.com/bekharsky/clrpkr

И тут в разговоре мелькнула тема MCP (Model Context Protocol). Я подумал: а ведь таким вещам уже не обязательно жить как отдельным приложениям. Их можно вызывать прямо там, где работаешь — в Cursor, Claude, GitHub Copilot Workspace или VS Code.

В итоге я вынес свой пикер в MCP tool: описал входы (координаты или изображение) и выходы (цвет, палитра, export), убрал интерфейс и оставил только функцию, которую можно вызывать напрямую.

Пришлось повозиться, чтобы нормально отображалась картинка (swatch) выбранного цвета и чтобы всё стабильно работало, но в итоге получилось ровно то, что хотелось. Здесь, конечно, потоковая сущность общения с моделью не очень к месту — чат может показать PNG только в Base64, а эта запись получается очень длинная.

Получилось классно: окно само свернется, само развернется. Ну и запустить как обычно никто не мешает.

Utilities are dead. Long live utilities.

#mcp #llm #color

#статья дня

GitHub выкатил отличный пост о том, как они ускоряли рендеринг диффов в пулл-реквестах (исконно русские слова) — и внезапно выяснили, что браузеру становится плохо, когда в PR десятки тысяч строк.

Вот ссыль сразу: https://github.blog/engineering/architecture-optimization/the-uphill-climb-of-making-diff-lines-performant/

Главная проблема оказалась в том, что каждая строка diff-а была маленьким React-стартапом: 8–13 компонентов, куча DOM-нод и отдельные event handlers почти на всё подряд.

Старый подход выглядел примерно так:

<DiffLine>
  <LineNumber />
  <SyntaxHighlight>
    <Token />
    <Token />
  </SyntaxHighlight>
</DiffLine>

И конечно же:

<div
  onMouseEnter={...}
  onMouseLeave={...}
  onClick={...}
/>

Когда таких строк 10 000+, Chrome начинает потреблять память не в себя.

А дальше случилось прекрасное: GitHub героически переоткрыл event delegation — технику, которую jQuery нормально объяснял ещё лет 15 назад (не воспринимайте буквально, автоматическая делегация в реакте была и есть). Оказалось, что один обработчик событий на контейнер внезапно быстрее, чем 30 тысяч onMouseEnter на каждую строку. Кто бы мог подумать.

Новый вариант:

<table onMouseMove={handleHover}>
  <tr data-line="42">
    <td>const value = 1;</td>
  </tr>
</table>
function handleHover(e) {
  highlight(e.target.dataset.line)
}

В итоге GitHub выкинул 74% React-компонентов, почти вдвое снизил потребление памяти и ещё удалил пару лишних <code>-тегов из каждой строки, потому что 20 000 ненужных DOM-элементов — это всё ещё 20 000 ненужных DOM-элементов.

Мораль истории максимально простая: abstraction is not free. Иногда один обработчик событий и туповатый плоский код работают лучше, чем архитектура мечты из 400 reusable-компонентов, custom hooks и трёх уровней composition.

#github #react #virtualization

Поздравляем, вы на 1 шаг ближе к работе мечты 🥳

Осталось только прочитать этот пост, подписаться на канал и откликнуться на вакансию 😉

Avito Career* — место, где Авито делится актуальными вакансиями и стажировками для бэкенд-разработчиков.

Подписывайтесь, чтобы найти ту самую работу ✨

*карьера