#фишка дня

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

15 марта у Яндекса пройдёт митап AI Dev Day — встреча про реальный опыт внедрения AI-инструментов в процессы разработки. Вместе с инженерами и руководителями из Яндекса, Авито, Сбера, Т-Банка и Ozon будем обсуждать, как компании внедряют AI в разработку, какими метриками пытаются измерять его влияние и какие проблемы возникают на практике.

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

Из программы особенно интересен доклад Андрея Попова (Яндекс) про то, как команды подходят к оценке эффективности AI-инструментов и какие сигналы вообще можно считать доказательством пользы. Когда речь идёт о больших кодовых базах и десятках команд, измерить влияние AI оказывается гораздо сложнее, чем кажется.

Формат будет полезным не только для ML-инженеров — это скорее разговор про разработку вообще: backend, frontend, мобильные команды, аналитиков и тимлидов, которые уже используют AI-инструменты и пытаются встроить их в процессы.

📅 15 марта

📍 онлайн + офлайн в Москве (офис Яндекса в Красной Розе)

Программа и регистрация

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

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

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

Правда, думаю, из-за избыточного использования вибрации в 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

#событие дня

Я понятия не имею, как я пропустил! Итак, соревнование March MadCSS!

16 лучших фронтенд-разработчиков схлестнутся в жаркой битве по вёрстке интерфейсов.

Ну, я надеюсь, вам что-то говорят имена Josh Cameau, Wes Bos, Kyle Cook, Chris Coyier... если нет — очень зря!

Первый раунд был неделю назад и его можно посмотреть на YouTube: https://www.youtube.com/watch?v=nuxSFTjXrhI

А второй как раз будет сегодня.

И да, даже лучшие верстальщики мира гуглят, как выровнять текст.

Сайт ивента с турнирной таблицей и мерчом: https://madcss.com/

Смотрим?

#css #dev #battle

#статья дня

Как вообще меняется JavaScript?

В блоге Bloomberg вышла интересная история про Temporal — новый API для дат и времени. Но статья на самом деле не столько про сам API, сколько про то, как такие вещи вообще появляются в языке.

Объект Date появился в JavaScript в 1995 году и, по сути, был просто позаимствован из Java. Тогда это казалось нормальным решением. Спойлер: нет.

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

Экосистема ответила библиотеками вроде Moment.js, date-fns и Luxon. Их скачивают десятки миллионов раз в неделю — почти каждый проект как-то решает эту проблему.

В 2017 году появилась идея сделать нормальный API прямо в стандарте. Так началась история Temporal.

Дальше — девять лет обсуждений и доработок. В работе участвовали инженеры из Microsoft, Google, Mozilla, Bloomberg и Igalia. Предложение прошло весь процесс TC39 и в итоге стало крупнейшим добавлением в ECMAScript со времён ES2015.

Любопытная деталь: для реализации Temporal разработчики движков даже сделали общую библиотеку на Rust — temporal_rs. Редкость!

Ещё, конечно, поражает количество тестов.

В общем, это хороший текст про то, как вообще принимаются изменения в современном JavaScript. Стадии, обзоры альтернатив, обсуждения.

Почитать:
https://bloomberg.github.io/js-blog/post/temporal/

Если что, есть и перевод.

#javascript #temporal

#ссылка дня

Поскольку не говорить про ИИ и агентсткую разработку не получается, давайте пробовать хотя бы извлекать из этого пользу.

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

Вот только пока что всё ровно наоборот! Все же знают, что такое skills — умения?

А skills в контексте ИИ-агентов — это буквально описание лучших практик. Вот это делай, вот это не делай, а в случае таких-то условий, поступай вот так.

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

Ладно, к чему это я. Anthropic выкатили гайд по созданию скиллов. Да, формально — для Claude, но все известные мне инструменты подхватывают скиллы Клода вообще без проблем.

И почему-то по принятой в западном сегменте интернета традиции — в абсолютно ублюдочном формате презентационного PDF на 33 страницы.

К счастью, нашёлся человек, который не только перевёл это на русский, но и оформил в виде нормального веб-решения: https://fkonovalov.github.io/claude-skills-guide-ru/

fkonovalov, спасибо! :)

#ai #skills

#заметка дня

Иногда стоит выкладывать рекламу, чтобы просто увидеть, что вы живы, котаны. На посты такого количества реакций никогда нет.

А тема сегодняшней заметки — очередная статья на тему «Нам не нужен useEffect»: вот тут.

В чём же проблема таких статей? Да на самом деле проблемы-то особой и нет, есть некоторая недосказанность.

И недосказанность эта связана с тем, что ВСЕ ваши прекрасные библиотеки управления состоянием, анимацией, загрузкой данных и кешем — будут использовать useEffect внутри себя. И говорить, что вы отказываетесь от useEffect — не очень верно.

Что верно, так это то, что их имплементация будет просто намного лучше протестирована. Ну, возможно.

Тем не менее, самый любимый пример, когда отказ от useEffect действительно имеет смысл — на иллюстрации.

Суть проста: если ваше действие требует полной перезагрузки логики, перерисовки компонента — так перерисуйте, блин, компонент, а не пытайтесь через useEffect чота там стартануть.

Продублирую текстом:

// ❌ BAD: Effect attempts to emulate remount behavior
function VideoPlayer({ videoId }) {
  useEffect(() => {
    loadVideo(videoId);
  }, [videoId]);
}

// ✅ GOOD: key forces clean remount
function VideoPlayer({ videoId }) {
  useMountEffect(() => {
    loadVideo(videoId);
  });
}

function VideoPlayerWrapper({ videoId }) {
  return <VideoPlayer key={videoId} videoId={videoId} />;
}

Это настолько чисто, элегантно и понятно — что удивляешься, почему это не стало общим паттерном.

Впрочем, дело за вами, котаны.

#react #useeffect #article

#фишка дня

А вы знали, что Apple уже очень давно для каждой ноутбука поставляет и 3D-модель?

Кроме шуток, если зайти на страницу продукта с Safari на iPhone, появится возможность посмотреть, например, ноутбук в дополненной реальности. Ясное дело, скачивается 3D-модель. Но эту модель легко вытащить и посмотреть даже на десктопе! Ссылка, нонечно, скрыта, потому лезем в исходники и ищем USDZ-файл.

USDZ расшифровывается как Universal Scene Description Zipped, и придумал был ещё в Pixar. Что значит Zipped? Очевидно, zip-контейнер, а значит, можно распаковать и найти там и модель, и текстуры и карты нормалей.

Но это история давняя, ARKit с нами уже лет 10. Что новое — это то, что начиная с MacBook Neo модель поставляется с возможностью конфигурации по цвету и состоянию! Закрыт-открыт, розовый-жёлтый... вот это вот всё.

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

#apple #3d #ar

#статья дня

Страница грузится 7 секунд.
Причина — один эмодзи ❤️

Иногда проблемы с производительностью оказываются совсем не там, где их ищешь. В статье Аллена Пайка «A Broken Heart» он разбирает случай, когда страница внезапно начала грузиться по 7 секунд, хотя сервер, сеть и JavaScript работали нормально. В профайлере оказалось, что почти всё время Safari тратит на layout — причём один проход занимал больше секунды.

Дальше — обычный путь: постепенно вырезать куски интерфейса и смотреть, когда станет быстрее. В какой-то момент выяснилось, что всё упирается в один эмодзи в кнопке. Убираешь его — всё работает мгновенно. Возвращаешь — снова тормоза.

Причина оказалась в том, как Safari работает со шрифтами. Если указать Noto Color Emoji как основной шрифт, он используется даже для обычного текста, хотя покрывает только эмодзи. Для всех остальных символов браузер каждый раз ищет подходящий fallback-шрифт. В процессе layout он пересчитывает размеры текста, переносы строк и позиции элементов, и делает это много раз подряд.

В норме такие пересчёты почти ничего не стоят, но в Safari здесь есть просадка, из-за которой всё резко замедляется. В итоге одна строка с emoji-шрифтом может увеличить время layout в десятки или даже сотни раз.

Минимальный пример:

<link href="https://fonts.googleapis.com/css2?family=Noto+Color+Emoji" rel="stylesheet">

<style>
  body {
    font-family: "Noto Color Emoji";
  }
</style>

<button>Click ❤️</button>

Если не ставить emoji-шрифт основным, а оставить его только в конце списка как fallback, проблема исчезает. В оригинальной статье есть ещё детали про поиск причины и минимизацию примера — стоит почитать: https://allenpike.com/2026/a-broken-heart/

Ну и официальный issue: https://bugs.webkit.org/show_bug.cgi?id=305636

Потрясающая хрень, конечно. На пустом месте.

#css #emoji #svg #performance

90% каналов про ИИ - пересказ чужих новостей.

А что если контент делают те, кто строит эти системы?

🥷🏻 NeuroNinja - канал, который ведёт команда инженеров из Яндекса, Тинькова, Озона и Сбера.

Не блогеры. Не инфобизнесмены. Практики, которые каждый день работают с ML, LLM и продуктовым AI.

Что внутри:

🔹 Разборы реальных кейсов из BigTech изнутри
🔹 Гайды по нейросетям от тех, кто их внедряет
🔹 Инструменты и лайфхаки, проверенные в бою
🔹 Честный взгляд на тренды без хайпа

Без рекламы. Без воды. Только то, что реально работает.

👉 Подписаться: https://t.me/+UuibMa7rB-diNGM6

#фишка дня

Я всегда считал карту кода достаточно бестолковой фишкой. С другой стороны, TODO-комментарии и ошибки достаточно легко распознаваемы и перемещаться по ним удобно.

А сегодня я узнал, что блоки кода можно ещё и помечать комментарием // MARK: Something, и этот самый Something будет виден на карте.

В идеале, конечно, не стоит развозить свой код на несколько экранов, но прежде чем разбивать — надо ж распознать, верно? :)

#vscode #minimap #бородач