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

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

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

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