FPS расшифровывается как «кадры в секунду» (Frames Per Second) и означает измерение того, сколько кадров, или изображений, отображается на экране за одну секунду. Для frontend-разработчика эта метрика позволяет понять насколько интерфейс плавно и четко работает.
Привет! Я Даниил, занимаюсь разработкой на Angular в T-Банке и хочу поделиться с вами опытом использования фикстур в Playwright. Я решил поговорить об этом, потому что вместе с ростом функциональности проектов растут и сложности при тестировании, а фикстуры предоставляют удобный способ избавиться от дублирующегося кода и сложных моков.
Эта статья посвящена основам: зачем нужны фикстуры, чем они отличаются друг от друга и какую пользу приносят при тестировании веб-приложений. Мы подробно разберем устройство фикстур, посмотрим, как их создавать и грамотно внедрять в тесты. А еще рассмотрим практические примеры, которые помогут с легкостью применить полученные знания на реальном проекте. Поехали!
Фича ECMAScript "Атрибуты импорта" (import attributes) позволяет импортировать артефакты, отличающиеся от модулей JavaScript. В этом разделе мы рассмотрим, как это выглядит и почему может быть полезным.
Атрибуты импорта достигли 4 стадии в октябре 2024 года и, вероятно, станут частью ECMAScript 2025.
При разработке у нас зачастую возникает необходимость прямого взаимодействия с DOM-элементами. Для такого случая React предоставляет нам механизм рефов (refs), который позволяет получать доступ к элементам после того, как они зарендерятся. Чаще всего используются обычные объектные рефы через useRef (обзовём их так), но также существует другой подход — callback refs. Этот метод даёт нам дополнительную гибкость и контроль над жизненным циклом элементов, позволяя выполнять необходимые нам специфические действия в точные моменты привязки и отвязки элементов. В этой статье я хочу объяснить, что такое callback refs, как они работают, показать проблемы при их использовании и примеры их использования.
Не часто приходится встречать людей, которые понимают зачем он нужен и ещё реже попадаются проекты, в которых его используют. А шаблон-то очень полезный!
В этой статье вы поймёте как он устроен, зачем он нужен и на примерах научитесь его правильно применять.
Со времен появления скринсейвера «Ленты» (ориг. «Ribbons») на Windows 7, эта заставка была стандартом для всех моих рабочих мест, благо в новых версиях Windows (8, 10, 11) эта заставка остается и по сей день. Однако с момента «импортозамещения» десктопной Windows на десктопную Linux, особенно актуального с 2022 года, хотелось получить эту или хотя бы похожую заставку и на этой свобоной платформе. Но вот незадача — нормальный порт найти мне не удалось. Может, конечно, плохо искал (скиньте ссылку в комментариях, если кто‑то нашел что‑то работоспособное).
И тут на просторах github очень удачно нашелся вот этот репозиторий. Автор в canvas с использованием JS наваял на мой взгляд очень даже симпатичную анимацию по мотивам того самого скринсейвера «Ленты».
Причем он в README отметил, что пытался сделать из этой анимации PWA (Progressive Web App), но почему‑то у него ничего из этого не вышло, читай «failed». Вопрос, почему человек, наваявший такой годный «генератор лент», не смог в PWA, оставим за скобками.
А тут как раз я, начавший недавно по служебной необходимости, изучать всем известный фреймворк Electron для создания кроссплатформенных настольных web‑приложений... Чем не альтернатива PWA?
Причина написания сего опуса как и прежде — поделиться чем‑то, что делал для себя и ближайшего окружения, с теми, кому это может быть интересно.
Кратко: это максимально безопасный по типизации инструмент, генерирует статические файлы с кодом для максимальной совместимости, быстрый благодаря предварительной компиляции (AOT) и компактный. Также он предоставляет удобный генератор модульных тестов, чтобы можно было быть почти на 100% уверенным, что создаваемые предикаты работают, как ожидается.
Этот пост предлагает детальное сравнение Generator с другими инструментами для проверки типов во время выполнения, а также дает более широкий обзор смежных тем. Со временем пост постепенно превращается в более аналитическую статью, а не просто «мой X круче, чем ваш Y».
С самого начала разработки курьерки мы генерировали много идей по улучшению алгоритмов. Мы не стеснялись выкатывать кучу фичей и проверять их работоспособность А/Б тестами. Не было ни дня, когда у нас не крутились эксперименты в продакшене. Что-то мы выкидывали, что-то оставляли, но не хардкодили, чтобы иметь гибкость. Страна большая и у каждого региона свои особенности, которые влияют на плотность заказов, логистику и потребность в курьерах. Поэтому наборы фичей и их значения различаются. Мы поняли, как отдельная фича влияет на продуктовые метрики, но как набор фичей в совокупности влияет на итоговый результат?
Запускать А/Б тесты для каждого набора фичей слишком долго и затратно, ведь команде надо создавать и тестировать новые фичи. Но найти наилучшие комбинации фичей для разных регионов и городов быстро с наименьшими затратами ресурсов команды — было жизненно необходимо. Поэтому мы создали копию реального мира, чтобы внутри неё пробовать самые смелые идеи.
Привет, меня зовут Артур, и я люблю плавные интерфейсы, CSS и современные подходы. Сегодня хочу поговорить с вами о задаче, которая настигает, пожалуй, каждого фронтенд разработчика: о создании галереи.
Основное отличие этой песочницы от других — сжатие и кодирование пользовательского кода непосредственно в URL. Код не хранится на сервере или где-либо ещё. Если у вас есть ссылка, значит у вас есть код.
Может возникнуть вопрос, сколько символов можно записать в URL и как много кода таким образом можно закодировать? У разных браузеров максимальная длина URL-строки отличается. Но 2000 символов поддерживают все современные браузеры. В такую строку можно закодировать довольно много кода, причем степень сжатия увеличивается с объёмом кода.
При разработке веб-приложений не все задумываются о том, сколько памяти потребляет их код. О производительности наших сайтов мы вспоминаем гораздо чаще. К тому же не каждому разработчику интересно «экономить на спичках». Разве может наш код на языке JavaScript требовать много памяти? «Много» — это вообще сколько? 100 мегабайтов — это много?
Меня зовут Антон Непша. Я работаю в Сбере, разрабатываю сайт СберБанк Онлайн и веду Telegram-канал Антон Непша.js. Недавно я выступил на HolyJS с докладом о том, сколько ресурсов потребляют наши сайты, как эти ресурсы распределяются, где хранятся, и как связать информацию о них из снимка памяти с конкретным местом в своём коде.
Если смотреть видео вам удобнее, то доклад есть на YouTube и ВК Видео. В статье вас ждёт текстовый вариант и ссылки на используемые материалы:
Приветствую всех! Меня зовут Рома, я разработчик в компании АйТи-Баланс. Хочу поделиться с вами своими знаниями и помочь разобраться в базовых концепциях, которые необходимы каждому новичку в мире JavaScript.
Идея этой статьи возникла из популярного репозитория на GitHub. Я немного адаптировал материал, дополнил его и выделил ключевые аспекты, чтобы сделать информацию максимально доступной и полезной.
Я Данил Соломин, лид команды фронтенд-разработки в компании-подрядчике «Газпром нефти» и ревьюер на курсе «Мидл фронтенд-разработчик» в Яндекс Практикуме. Однажды, проводя четвёртое за день собеседование на роль мидл фронтенд-разработчика, я поймал себя на мысли, что кандидаты допускают одни и те же ошибки. Что особенно печально, эти ошибки можно было бы легко исправить.
Именно поэтому я решил написать эту статью. Я не буду рассказывать, как писать сопроводительное письмо или ставить теги в резюме. Я расскажу о главном — как показать себя с максимально выгодной стороны на технической части. Буду основываться и на опыте прохождения собеседований (не всегда успешном), и на опыте их проведения.
Не так давно стала задача создать персональный чат-бот ассистент для компании занимающейся интернет разработкой. Система должна была иметь как Backend, отвечающий за работу с локальной нейросетью, так и простой FrontEnd виджет на JavaScript, который можно подключить на любой из страниц компании. Ресурсов описывающих работу RAG-систем полно, однако руководств которые расскажут и поэтапно проведут разработчика через все необходимые шаги я не нашел. Тем самым постараюсь восполнить пробел в данной статье.
В комментах к статье "Синглтон - корень всех зол", который вообще-то про паттерн проектирования, я высказал мысль, что в функциональном программировании "все функции - синглтоны" (это уже в смысле lifestyle - больше одной функции на приложение не нужно). Тут же мне более опытные коллеги насовали в панамку, что "функции не синглтоны, потому что существуют замыкания". Я, конечно, "сварщик не настоящий" - в ФП серьёзно никогда не игрался, но основные идеи вроде как у всех на слуху: неизменяемость данных, чистота функций, функция как аргумент / результат другой функции.
На мой субъективный взгляд, при таких вводных, нет никаких доводов за то, чтобы в приложении иметь более одного экземпляра чистой функции. Какой смысл иметь два экземпляра функции, если она не имеет побочных эффектов - для одних и тех же входных данных всегда возвращает один и тот же результат, вне зависимости от внешних условий? Ну? Вот и я думаю, что никакого.
Тем не менее, мысль про замыкания надо было как-то подумать - не, ну а вдруг?! Под катом я привожу результаты своих изысканий на примере очень простого функционала на JS, написанного в трёх разных стилях.
Привет, друзья!
В праздники я провел небольшое исследование представленных сегодня на рынке бесплатных инструментов с участием "искусственного интеллекта" для помощи в веб-разработке, результатами которого хочу с вами поделиться, авось кому-нибудь пригодится.
Обратите внимание, что я акцентировал внимание на бесплатных решениях для написания кода клиентской части веб-приложений.
Список протестированных инструментов:
Далее я подробнее расскажу о первых трех (Codeium, Devv, V0) и немного о двух следующих за ними (ChatGPT, GPT4All) решениях из представленных в списке, как наиболее "выдающихся" с моей точки зрения. Остальные сервисы (начиная с cursor и ниже) в той или иной степени похожи на codeium и `devv`, но показывают более плохие результаты генерации кода по запросу, исправления ошибок и документирования кода, а также менее удобны в использовании и иногда требуют дополнительных настроек, например, указания ключа OpenAI, установки лишних инструментов (тулкитов), являются условно бесплатными и т.п.
В современной разработке приложений важным аспектом является способность быстро и эффективно создавать прототипы и демонстрационные версии. В этом посте мы расскажем о нашем опыте использования моков (mocks) для эмуляции бэкенда на примере фронтенд-проекта. Мы поделимся ключевыми проблемами, с которыми столкнулись, и решениями, которые помогли нам ускорить разработку, улучшить стабильность и обеспечить гибкость в работе с данными. Вы узнаете, как мы использовали Mock Service Worker (MSW) и Vite-плагин для создания изолированного и удобного окружения, а также какие преимущества это принесло нашей команде.
В статье расскажу, как с помощью AI ускорить исправление упавших Playwright тестов. В HTML-отчёт добавляем кнопку "Fix with AI", которая генерирует промпт под конкретный тест. Копируем промпт, вставляем в ChatGPT и мгновенно получаем рекомендации по исправлению.
Цель статьи — показать разработчикам, как защитить их JavaScript-код от распространённых уязвимостей и атак. Статья будет охватывать методы защиты, лучшие практики и конкретные инструменты для обеспечения безопасности.
