#инструмент дня
На связи Глеб, который принес немножечко странного.
Думали ли вы когда-нибудь о том, что алгоритмы сжатия строк потребуются для передачи состояния приложения?
Всё когда-нибудь случается впервые, вот и мне потребовалось передавать в ссылке текущее состояние редактора кода (в нашем продукте это один из основных иструментов).
Так как в нашем редакторе есть владки, то у каждой свои параметры рабочего пространства, которые составляют композицию объектов.
Передавать необходимо как раз такую компиляцию состояний в одном объекте, который должен передаваться в генерируемой ссылке.
Но как, ведь длина адресной строки очень ограничена и не вместит даже небольшой сериализованный объект в параметре адресной строки.
Оказывается не так уж это сложно если вспомнить про алгоритмы сжатия.
Сериализуем объект, сжимаем его с помощью библиотеки lz-string и генерируем ссылку с параметрами состояния редактора в одном из параметров.
Попробовать можно в codepen.
Да, можно использовать более эффективный алгоритм LZMA (один из примеров), однако он существенно медленнее. Тем не менее, производительность LZMA в контексте ограниченного числа символов, позволяет вообще не думать о каком-либо существенном влиянии на результат.
В CedrusData (компания, в которой работаю) много интересных задач, в том числе связанных с производительностью. Ждите новых заметок😎
#compression #performance
На связи Глеб, который принес немножечко странного.
Думали ли вы когда-нибудь о том, что алгоритмы сжатия строк потребуются для передачи состояния приложения?
Всё когда-нибудь случается впервые, вот и мне потребовалось передавать в ссылке текущее состояние редактора кода (в нашем продукте это один из основных иструментов).
Так как в нашем редакторе есть владки, то у каждой свои параметры рабочего пространства, которые составляют композицию объектов.
Передавать необходимо как раз такую компиляцию состояний в одном объекте, который должен передаваться в генерируемой ссылке.
Но как, ведь длина адресной строки очень ограничена и не вместит даже небольшой сериализованный объект в параметре адресной строки.
Оказывается не так уж это сложно если вспомнить про алгоритмы сжатия.
Сериализуем объект, сжимаем его с помощью библиотеки lz-string и генерируем ссылку с параметрами состояния редактора в одном из параметров.
Попробовать можно в codepen.
Да, можно использовать более эффективный алгоритм LZMA (один из примеров), однако он существенно медленнее. Тем не менее, производительность LZMA в контексте ограниченного числа символов, позволяет вообще не думать о каком-либо существенном влиянии на результат.
В CedrusData (компания, в которой работаю) много интересных задач, в том числе связанных с производительностью. Ждите новых заметок😎
#compression #performance
GitHub
GitHub - pieroxy/lz-string: LZ-based compression algorithm for JavaScript
LZ-based compression algorithm for JavaScript. Contribute to pieroxy/lz-string development by creating an account on GitHub.
1👍13
This media is not supported in your browser
VIEW IN TELEGRAM
#фишка дня
Тут Jh3y опять по красоте исполняет. Итак, поступил вопрос из аудитории: «Как сделать эффект подсвеченной стеклянной фаски, как на новых иконках в iOS?»
Ответ интереснее и одновременно проще, чем может показаться: https://codepen.io/jh3y/pen/WbwyGBb
Весь секрет в наложении маски в виде градиента под элемент:
И всё, дальше просто вращаем по желанию. Техника не нова, даже блендинг не нужен. Ну а весь JS-код — он просто для обработки позиции курсора и для фирменного эффекта взрыв-диаграммы, ставшей визитной карточкой Джея.
Работает, кстати, во всех современных браузерах.
#css #gradient #mask
Тут Jh3y опять по красоте исполняет. Итак, поступил вопрос из аудитории: «Как сделать эффект подсвеченной стеклянной фаски, как на новых иконках в iOS?»
Ответ интереснее и одновременно проще, чем может показаться: https://codepen.io/jh3y/pen/WbwyGBb
Весь секрет в наложении маски в виде градиента под элемент:
&::after {
mask: linear-gradient(calc(var(--pointer-angle) * 1deg), #ffffff80, #ffffff30 30% 60%, #fff);
}
И всё, дальше просто вращаем по желанию. Техника не нова, даже блендинг не нужен. Ну а весь JS-код — он просто для обработки позиции курсора и для фирменного эффекта взрыв-диаграммы, ставшей визитной карточкой Джея.
Работает, кстати, во всех современных браузерах.
#css #gradient #mask
❤20
#ссылка дня
Я и подумать не мог, сколько в моей работе времени будет отдано обсуждению различных фич продукта.
Когда я был частью веб-студии/галеры, мы просто дубасили по готовому дизайну и техзаданию (когда таковое было, *звук горьких слёз*), не особо задумываясь, почему было принято то или иное решение. В лучшем случае можно было пост-фактум указать на проблему.
В продуктовой же компании дела обстоят чуть-чуть иначе. Если ты на уровне senior, от тебя ожидают не только и не столько дубасить код, сколько понимать принципы работы продукта и быть готовым защищать решения по бизнес-логике или взаимодействию с клиентом.
Количество Google Docs- и вики-материалов в такой работе зашкаливает. Вопросы «почему?» и «зачем?», повторяемые раз за разом… Метрики.
Отсюда интересно посмотреть, что же творится в других компаниях. И тут — на удивление — Microsoft нам такую возможность даёт. Теперь можно взглянуть на каталог explainers (сопровождающих документов, документации, расшифровывающих заметок) браузера Edge: https://github.com/MicrosoftEdge/MSEdgeExplainers
Почему что-то является проблемой? Как выявили? Почему было принято то или иное решение? Как команда объяснила себе какие-то новые концепты? Какой состав команды? И так далее.
Довольно погружающее чтиво. Особенно в разделе про DevTools, на которые разработчики Edge в принципе делают упор (да-да, я в курсе, что там тот же Chromium, но дело же в мелочах).
#docs #explainers #process #бородач
Я и подумать не мог, сколько в моей работе времени будет отдано обсуждению различных фич продукта.
Когда я был частью веб-студии/галеры, мы просто дубасили по готовому дизайну и техзаданию (когда таковое было, *звук горьких слёз*), не особо задумываясь, почему было принято то или иное решение. В лучшем случае можно было пост-фактум указать на проблему.
В продуктовой же компании дела обстоят чуть-чуть иначе. Если ты на уровне senior, от тебя ожидают не только и не столько дубасить код, сколько понимать принципы работы продукта и быть готовым защищать решения по бизнес-логике или взаимодействию с клиентом.
Количество Google Docs- и вики-материалов в такой работе зашкаливает. Вопросы «почему?» и «зачем?», повторяемые раз за разом… Метрики.
Отсюда интересно посмотреть, что же творится в других компаниях. И тут — на удивление — Microsoft нам такую возможность даёт. Теперь можно взглянуть на каталог explainers (сопровождающих документов, документации, расшифровывающих заметок) браузера Edge: https://github.com/MicrosoftEdge/MSEdgeExplainers
Почему что-то является проблемой? Как выявили? Почему было принято то или иное решение? Как команда объяснила себе какие-то новые концепты? Какой состав команды? И так далее.
Довольно погружающее чтиво. Особенно в разделе про DevTools, на которые разработчики Edge в принципе делают упор (да-да, я в курсе, что там тот же Chromium, но дело же в мелочах).
#docs #explainers #process #бородач
GitHub
GitHub - MicrosoftEdge/MSEdgeExplainers: Home for explainer documents originated by the Microsoft Edge team
Home for explainer documents originated by the Microsoft Edge team - MicrosoftEdge/MSEdgeExplainers
👍7
#статья дня
Ну что же, пора просыпаться от зимней спячки, котаны! Салаты съедены, сериалы отсмотрены. Плавно готовимся к неизбежному.
В моей предыдущей компании были очень популярны турниры по настольному футболу, aka foosball. Не до драк, конечно, но со своим лором, правилами и даже традициями. Например, проигравший увековечивал своё имя под столом.
Так вот, к чему это я.
Помню, мы использовали какой-то сервис для составления турнирных таблиц. Я какое-то время даже планировал его склонировать, но руки не дошли. А тут наткнулся на интересную реализацию деревьев диаграмм. Ну или блок-схем, если хотите. Как раз похожих на турнирные таблицы.
Как вам такое: отрисовка дерева с помощью... списков!
Вот, глядите: https://codepen.io/alinaki/pen/ZYOOWOL
Не, ну буквально. У автора четыре статьи, от горизонтальных и вертикальных деревьев до более сложных конструкций вроде центрально-ориентированной диаграммы (вот то, что на иллюстрации, к таким как раз относится) и прочих экспериментов.
Начало тут: https://fractaledmind.com/2018/03/05/css-tree/
Ну что, будем таки писать такой сервис? Или максимально гибкая отрисовка на холсте наше всё?
#css #html #tree #list
Ну что же, пора просыпаться от зимней спячки, котаны! Салаты съедены, сериалы отсмотрены. Плавно готовимся к неизбежному.
В моей предыдущей компании были очень популярны турниры по настольному футболу, aka foosball. Не до драк, конечно, но со своим лором, правилами и даже традициями. Например, проигравший увековечивал своё имя под столом.
Так вот, к чему это я.
Помню, мы использовали какой-то сервис для составления турнирных таблиц. Я какое-то время даже планировал его склонировать, но руки не дошли. А тут наткнулся на интересную реализацию деревьев диаграмм. Ну или блок-схем, если хотите. Как раз похожих на турнирные таблицы.
Как вам такое: отрисовка дерева с помощью... списков!
Вот, глядите: https://codepen.io/alinaki/pen/ZYOOWOL
Не, ну буквально. У автора четыре статьи, от горизонтальных и вертикальных деревьев до более сложных конструкций вроде центрально-ориентированной диаграммы (вот то, что на иллюстрации, к таким как раз относится) и прочих экспериментов.
Начало тут: https://fractaledmind.com/2018/03/05/css-tree/
Ну что, будем таки писать такой сервис? Или максимально гибкая отрисовка на холсте наше всё?
#css #html #tree #list
❤6
Media is too big
VIEW IN TELEGRAM
#статья дня
Зачем писать код, если можно сгенерировать, правда? Такие нынче правила игры. Но нужно идти дальше.
Зачем писать код, если можно украсть? Особенно, когда сам в руки идёт. Ведь если даже генерировать что-то, нужно, как минимум, учитывать требования по работе, дизайну... никто не отменял понимание сути задачи.
Так вот, сегодня на поветске дня — как украсть любой React-компонент!
И в этом нам поможет React DevTools, любая сносная LLM-ка и вот эта инструкция: https://fant.io/react/
TL;DR
React-приложение хранится не только в DOM-представлении, но и в виде React Fiber — внутреннего дерева (тот самый виртуальный DOM), где видно, какой компонент и с какими пропсами создал разметку.
Все экземпляры одного компонента ссылаются на один и тот же т. н.
Эти примеры вместе с минифицированным кодом компонента скармливаются LLM, которая восстанавливает чистый React. Дальше идёт проверка: компонент рендерится с теми же пропсами, HTML сравнивается с оригиналом, а расхождения отправляются обратно модели. Компоненты собираются снизу вверх, от простых к составным. Анимации и сложные состояния чуток могут замедлить процесс, но для статичного UI он работает прям хорошо.
Дивный новый мир. А чтобы понимать внутренности Fiber, можно использовать инструмент со странным названием bippy: https://github.com/aidenybai/bippy, когда, что и почему отрендерилось.
#react
Зачем писать код, если можно сгенерировать, правда? Такие нынче правила игры. Но нужно идти дальше.
Зачем писать код, если можно украсть? Особенно, когда сам в руки идёт. Ведь если даже генерировать что-то, нужно, как минимум, учитывать требования по работе, дизайну... никто не отменял понимание сути задачи.
Так вот, сегодня на поветске дня — как украсть любой React-компонент!
И в этом нам поможет React DevTools, любая сносная LLM-ка и вот эта инструкция: https://fant.io/react/
TL;DR
React-приложение хранится не только в DOM-представлении, но и в виде React Fiber — внутреннего дерева (тот самый виртуальный DOM), где видно, какой компонент и с какими пропсами создал разметку.
Все экземпляры одного компонента ссылаются на один и тот же т. н.
type, поэтому можно сгруппировать их и собрать реальные примеры прямо из продакшена.Эти примеры вместе с минифицированным кодом компонента скармливаются LLM, которая восстанавливает чистый React. Дальше идёт проверка: компонент рендерится с теми же пропсами, HTML сравнивается с оригиналом, а расхождения отправляются обратно модели. Компоненты собираются снизу вверх, от простых к составным. Анимации и сложные состояния чуток могут замедлить процесс, но для статичного UI он работает прям хорошо.
Дивный новый мир. А чтобы понимать внутренности Fiber, можно использовать инструмент со странным названием bippy: https://github.com/aidenybai/bippy, когда, что и почему отрендерилось.
#react
👍16
#статья дня
Если вы не читали адвент-календарь HTMHell, то могли и пропустить интересности!
Во втором дне календаря 2025 года речь идёт о теге
Штука гениальная: как только браузер встречает
В браузере и
Существенная часть статьи посвящена тому, как
Например, обнулить CSP.
Короче, можно долго растекаться по поводу того, зачем знать всю эту вот подноготную истории веба, но такие штуки кажутся весьма забавными. Почитайте, там интересно.
#html #sanitize
Если вы не читали адвент-календарь HTMHell, то могли и пропустить интересности!
Во втором дне календаря 2025 года речь идёт о теге
<plaintext>. Это устаревший элемент, который запрещён стандартами, но до сих пор поддерживается браузерами. Штука гениальная: как только браузер встречает
<plaintext>, он прекращает разбор HTML. Всё, что идёт дальше, воспринимается как обычный текст, независимо от того, что там написано.
<body>
<h1>Заголовок</h1>
<plaintext>
<div>Этот div не станет элементом</div>
<noscript>alert('xss')</noscript>
</body>
В браузере и
<div>, и <noscript> будут выведены как текст. DOM на этом месте обрывается, ошибок в консоли нет, с точки зрения браузера всё произошло корректно.Существенная часть статьи посвящена тому, как
<plaintext> ведёт себя при санитайзинге HTML. Разные санитайзеры обрабатывают его по-разному: кто-то удаляет, кто-то экранирует, кто-то оставляет в форме, которая всё равно влияет на парсинг. В результате один и тот же входной HTML после «очистки» может либо работать нормально, либо полностью ломать страницу. Например, обнулить CSP.
Короче, можно долго растекаться по поводу того, зачем знать всю эту вот подноготную истории веба, но такие штуки кажутся весьма забавными. Почитайте, там интересно.
#html #sanitize
❤15
#молния дня
А пока вы читали сообщение выше, оказалось, что вышел jQuery 4.0: https://blog.jquery.com/2026/01/17/jquery-4-0-0/
Кто-нибудь ещё использует jQuery для новых проектов? Или по-инерции?
С другой стороны, эта инерция всё ещё драйвит 70% веб-сайтов в мире... есть у меня интересная инфа на тему, попозже сегодня выкачу 🙂
А пока вы читали сообщение выше, оказалось, что вышел jQuery 4.0: https://blog.jquery.com/2026/01/17/jquery-4-0-0/
Кто-нибудь ещё использует jQuery для новых проектов? Или по-инерции?
С другой стороны, эта инерция всё ещё драйвит 70% веб-сайтов в мире... есть у меня интересная инфа на тему, попозже сегодня выкачу 🙂
Jquery
jQuery 4.0.0 | Official jQuery Blog
jQuery: The Write Less, Do More, JavaScript Library
❤11👍5🤩2
#заметка дня
Вот то самое откровение, которое я обещал в новости о jQuery 4.0.
В Chrome 145 будет изменено поведение 100vw. Браузер будет учитывать ширину скроллбара, исключая горизонтальную прокрутку.
Ссылка: https://www.bram.us/2026/01/15/100vw-horizontal-overflow-no-more/
И да, это будет ломающее изменение.
Хотя, если честно, я не очень понимаю людей, которым вообще нужно было значение 100vw, это же дефолт блочных структур.
Старое поведение по факту годами создавало баг, с которым разработчики либо мирились, либо прятали его костылями — через
Самый показательный момент — реальные цифры.
Через HTTP Archive было проанализировано 12 089 606 корневых страниц. Из них 324 866 сайтов, то есть примерно 2.7%, в принципе использовали
Вот комментарий в PR спеки: https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1919428550
Это хорошо показывает реальную картину: подавляющее большинство разработчиков никогда не «считали скроллбар». Они либо избегали 100vw, либо жили с лишним горизонтальным скроллом, либо просто добавляли overflow-x: hidden. То есть проблема была массовой, а осознанно решали её — доли процента.
Именно поэтому браузеры и пошли на ломающее изменение. Старое поведение не было полезной фичей, это была историческая особенность, которая порождала баги чаще, чем решала реальные задачи. В итоге решили сломать редкие кейсы ради того, чтобы 100vw наконец означал то, что от него ожидают почти все.
Хороший пример того, сколько инженерной работы уходит на полировку вещей, которые пользователи, возможно, и не заметят напрямую, но которые годами раздражали фронтендеров.
И хороший вопрос, какой процент разработчиков морочится с чем-то менее видным, если даже на возможные скроллбары всем пофигу...
#css #scroll
Вот то самое откровение, которое я обещал в новости о jQuery 4.0.
В Chrome 145 будет изменено поведение 100vw. Браузер будет учитывать ширину скроллбара, исключая горизонтальную прокрутку.
Ссылка: https://www.bram.us/2026/01/15/100vw-horizontal-overflow-no-more/
И да, это будет ломающее изменение.
Хотя, если честно, я не очень понимаю людей, которым вообще нужно было значение 100vw, это же дефолт блочных структур.
Старое поведение по факту годами создавало баг, с которым разработчики либо мирились, либо прятали его костылями — через
calc. Самый показательный момент — реальные цифры.
Через HTTP Archive было проанализировано 12 089 606 корневых страниц. Из них 324 866 сайтов, то есть примерно 2.7%, в принципе использовали
calc() рядом с 100vw. При этом явные попытки компенсировать ширину скроллбара встречаются крайне редко: порядка 4 000 сайтов принудительно задают overflow: scroll на <html>, и всего несколько десятков страниц используют calc(100vw - …) именно для учёта скроллбара.Вот комментарий в PR спеки: https://github.com/w3c/csswg-drafts/issues/6026#issuecomment-1919428550
Это хорошо показывает реальную картину: подавляющее большинство разработчиков никогда не «считали скроллбар». Они либо избегали 100vw, либо жили с лишним горизонтальным скроллом, либо просто добавляли overflow-x: hidden. То есть проблема была массовой, а осознанно решали её — доли процента.
Именно поэтому браузеры и пошли на ломающее изменение. Старое поведение не было полезной фичей, это была историческая особенность, которая порождала баги чаще, чем решала реальные задачи. В итоге решили сломать редкие кейсы ради того, чтобы 100vw наконец означал то, что от него ожидают почти все.
Хороший пример того, сколько инженерной работы уходит на полировку вещей, которые пользователи, возможно, и не заметят напрямую, но которые годами раздражали фронтендеров.
И хороший вопрос, какой процент разработчиков морочится с чем-то менее видным, если даже на возможные скроллбары всем пофигу...
#css #scroll
👍16❤5
#такое дня
А вот вам и пример, почему важно знать и понимать наследие веба. Написал я, понимаете ли, пост про тег
Сейчас это просто plaintext, а завтра — XSS? 😱
Не надо так, котаны.
P. S. пофиксили по моей просьбе.
А вот вам и пример, почему важно знать и понимать наследие веба. Написал я, понимаете ли, пост про тег
<plaintext> — https://news.1rj.ru/str/htmlshit/3955 — и он сломал вёрстку на агрегаторе каналов Telemetr. В комментариях написали, спасибо :)Сейчас это просто plaintext, а завтра — XSS? 😱
Не надо так, котаны.
P. S. пофиксили по моей просьбе.
1🤩16👍6
This media is not supported in your browser
VIEW IN TELEGRAM
#видео дня
Решил сохранить эту нестареющую классику прямо на канале. Где-то доступен и оригинал на ютубе, но я чот не смог его найти...
В общем, доклад с коротким названием Wat был представлен аж в 2012 году и язвительно проходится по фишкам разных языков и интерпретаторов. Там четыре минуты, время точно найдёте.
Поменялось ли что-то с тех пор?
Ну, нет.
Есть и не менее легендарные доклады, но я тут подумал, что было бы приятно получить от вас примеры в комментариях, котаны. Валяйте.
P. S. в докладе есть не только описания неопределённого поведения, но и хрестоматийные примеры. Это теперь они хрестоматийные, конечно.
Решил сохранить эту нестареющую классику прямо на канале. Где-то доступен и оригинал на ютубе, но я чот не смог его найти...
В общем, доклад с коротким названием Wat был представлен аж в 2012 году и язвительно проходится по фишкам разных языков и интерпретаторов. Там четыре минуты, время точно найдёте.
Поменялось ли что-то с тех пор?
Ну, нет.
Есть и не менее легендарные доклады, но я тут подумал, что было бы приятно получить от вас примеры в комментариях, котаны. Валяйте.
P. S. в докладе есть не только описания неопределённого поведения, но и хрестоматийные примеры. Это теперь они хрестоматийные, конечно.
❤11
#такое дня
Я уже как-то участвовал в нескольких спорах на тему того, что TUI — text-based ui interface — это не больше чем фишечка, такой себе ретрофутуризм.
Ведь каждому очень хочется себя почувствовать хакером из фильмов, если уж до интерфейсов Джарвиса из Железного Человека мы пока не доросли.
Впрочем, как мне справедливо заметили: «А минусы будут?», — да может и нет их...
Но что бы вы думали, взорвавший популярность TUI в последние пару лет Claude Code будет написан на условном C или Python?
Наверное, как сорок лет назад Vim, Emacs и среды Borland Turbo? Ну или ncurses на худой конец там, ведь проблема вывода текста кажется давно решённой?
Нет, там React :) Они рендерят сцену целиком, а потом процессят вьюхи чтобы вывести их текстом, предварительно сравнивая с предыдущим рендера.
Зачем? Да никто не знает, захотелось парням, кто мы такие, чтобы их судить.
Просто экран клода так и будет продолжать мерцать. Обещают, что чуть поменьше, чем раньше. Ведь 16ms на фрейм им теперь хватает с трудом.
Выводов не будет, нет никаких сил. Просто по ссылкам в посте пройдите, там достаточно интересно.
#claude #react
Я уже как-то участвовал в нескольких спорах на тему того, что TUI — text-based ui interface — это не больше чем фишечка, такой себе ретрофутуризм.
Ведь каждому очень хочется себя почувствовать хакером из фильмов, если уж до интерфейсов Джарвиса из Железного Человека мы пока не доросли.
Впрочем, как мне справедливо заметили: «А минусы будут?», — да может и нет их...
Но что бы вы думали, взорвавший популярность TUI в последние пару лет Claude Code будет написан на условном C или Python?
Наверное, как сорок лет назад Vim, Emacs и среды Borland Turbo? Ну или ncurses на худой конец там, ведь проблема вывода текста кажется давно решённой?
Нет, там React :) Они рендерят сцену целиком, а потом процессят вьюхи чтобы вывести их текстом, предварительно сравнивая с предыдущим рендера.
Зачем? Да никто не знает, захотелось парням, кто мы такие, чтобы их судить.
Просто экран клода так и будет продолжать мерцать. Обещают, что чуть поменьше, чем раньше. Ведь 16ms на фрейм им теперь хватает с трудом.
Выводов не будет, нет никаких сил. Просто по ссылкам в посте пройдите, там достаточно интересно.
#claude #react
🤡11❤2👍2
14 февраля Яндекс проводит свою главную фронтенд-конференцию — «Я 💛 Фронтенд».
Это большой ивент для тех, кто делает современные интерфейсы и хочет понимать, куда движется фронтенд.
В программе много тем про ИИ, и лично для меня самая интересная — про безопасное использование LLM в разработке. Сейчас LLM уже используют почти все, но чаще всего это выглядит как «прикрутили — и поехали». А вот разговор про безопасность, ограничения и реальные сценарии применения — это как раз то, чего сильно не хватает в публичных обсуждениях. Тема важная, потому что от этого напрямую зависит, не превратится ли ИИ в источник техдолга и странных багов через полгода.
Ещё будут доклады про влияние локального ИИ на архитектуру веб-приложений, контекстно-ориентированную адаптивность и практическое применение веб-компонентов — без абстракций, с прицелом на продакшен.
Отдельно упомяну Code in the Dark. Это тот самый формат, где нужно верстать без превью, инспектора и подсказок — только редактор, HTML и CSS. Хорошая штука и для участников, и для зрителей — сразу видно, кто правда чувствует вёрстку.
Кроме докладов будут и другие активности: CSS арт-челлендж, сборка TravelTech-приложения, разбор практических кейсов и другие интерактивы от команд Яндекса. Можно не только послушать, но и руками попробовать.
Участвовать можно онлайн или офлайн в Москве. Программа и регистрация — по ссылке.
Это большой ивент для тех, кто делает современные интерфейсы и хочет понимать, куда движется фронтенд.
В программе много тем про ИИ, и лично для меня самая интересная — про безопасное использование LLM в разработке. Сейчас LLM уже используют почти все, но чаще всего это выглядит как «прикрутили — и поехали». А вот разговор про безопасность, ограничения и реальные сценарии применения — это как раз то, чего сильно не хватает в публичных обсуждениях. Тема важная, потому что от этого напрямую зависит, не превратится ли ИИ в источник техдолга и странных багов через полгода.
Ещё будут доклады про влияние локального ИИ на архитектуру веб-приложений, контекстно-ориентированную адаптивность и практическое применение веб-компонентов — без абстракций, с прицелом на продакшен.
Отдельно упомяну Code in the Dark. Это тот самый формат, где нужно верстать без превью, инспектора и подсказок — только редактор, HTML и CSS. Хорошая штука и для участников, и для зрителей — сразу видно, кто правда чувствует вёрстку.
Кроме докладов будут и другие активности: CSS арт-челлендж, сборка TravelTech-приложения, разбор практических кейсов и другие интерактивы от команд Яндекса. Можно не только послушать, но и руками попробовать.
Участвовать можно онлайн или офлайн в Москве. Программа и регистрация — по ссылке.
❤7👍4🤡4👎1🤩1
#ссылка дня
Вчера — впервые за шесть лет — побывал на местном JS-митапе, aka HelsinkiJS.
Не надо на меня так смотреть, я не ходок по митапам. Но на нескольких конференциях, впрочем, был.
И как-то так получилось, что помимо пива и пиццы были и доклады. И вот один из них — «Как нарисовать карту?» — был весьма интересен и его результат прекрасно подходит под формат канала.
Автор — Скотт Стрит — постарался объяснить и показать, как работают библиотеки отрисовки карт. Какие форматы, какие решения. Ну и, собственно, шаг за шагом рассказал и показал процесс конвертации мировых координат в координаты элементов сетки и отрисовки их в SVG.
Например, как из описания линии формата MapLibre (там protobuf, но в виде текста как-то так):
Путем прямого чтения команд:
...получается описание кривых в SVG. Тут надо понимать, что сами плитки — тайлы — кодируются как квадрат 4096*4096, а, стало быть, координаты — относительно тайла.
К сожалению, слайдов доклада в наличии нет, но есть, собственно демо и репозиторий.
Конечно, там сейчас всё достаточно минималистично — дороги, парки, дома — но если вам было интересно, как это всё работает — подойдёт прекрасно.
#noscript #maplibre #map
Вчера — впервые за шесть лет — побывал на местном JS-митапе, aka HelsinkiJS.
Не надо на меня так смотреть, я не ходок по митапам. Но на нескольких конференциях, впрочем, был.
И как-то так получилось, что помимо пива и пиццы были и доклады. И вот один из них — «Как нарисовать карту?» — был весьма интересен и его результат прекрасно подходит под формат канала.
Автор — Скотт Стрит — постарался объяснить и показать, как работают библиотеки отрисовки карт. Какие форматы, какие решения. Ну и, собственно, шаг за шагом рассказал и показал процесс конвертации мировых координат в координаты элементов сетки и отрисовки их в SVG.
Например, как из описания линии формата MapLibre (там protobuf, но в виде текста как-то так):
{
"layers": [
{
"version": 2,
"name": "roads",
"extent": 4096,
"features": [
{
"id": 42,
"type": "LINESTRING",
"tags": [0, 0],
"geometry": [
9,
1024, 2048,
26,
2048, 0,
1024, 1024,
2048, 0
]
}
],
"keys": ["class"],
"values": [
{ "string_value": "primary" }
]
}
]
}
Путем прямого чтения команд:
9 → MoveTo, count=1
1024, 2048 → dx, dy
26 → LineTo, count=3
2048, 0 → dx, dy
1024, 1024 → dx, dy
2048, 0 → dx, dy
...получается описание кривых в SVG. Тут надо понимать, что сами плитки — тайлы — кодируются как квадрат 4096*4096, а, стало быть, координаты — относительно тайла.
К сожалению, слайдов доклада в наличии нет, но есть, собственно демо и репозиторий.
Конечно, там сейчас всё достаточно минималистично — дороги, парки, дома — но если вам было интересно, как это всё работает — подойдёт прекрасно.
#noscript #maplibre #map
❤4👍2