Всем привет! Сейчас без live-coding'a никуда: на собеседованиях часто дают одну-две задачки, которые нужно решить за определённое время. Сами задачи могут быть несложными (не супер-пупер алгоритмическими), но новички могут переволноваться и не справиться с ними.

Поэтому в этой статье я хотел бы описать типовые задачи, которые встречаются в этой секции на позицию frontend или backend разработчика (если бэк на JS). Это поможет вам получить общее представление о том, что может ждать вас.

История этой статьи началась с того, что я вспомнил о довольно известном высказывании Мартина Фаулера, автора книг и статей по архитектуре ПО, которое нередко вызывает недопонимание (во всяком случае так было у меня) — «Я делаю рефакторинг ежечасно». Первая мысль, которая логично возникает после этого высказывания — уважаемый публицист просто лукавит. Вторая — что, наверное, кроме рефакторинга он в своей жизни ничем больше не занимается. Но так ли это?

В очередной раз с вами Костя Логиновских, ведущий разработчик и технический лидер внутреннего проекта в Cloud.ru. В этой статье предлагаю во всём разобраться и обсудить, как можно делать рефакторинг «за пять минут» и улучшить приложение буквально за утренним кофе.

Каждый frontend-разработчик сталкивался с ошибкой вида TypeError: Cannot read property 'name' of undefined. Это часть целого класса ошибок в JavaScript, возникающих из-за несоответствия фактического формата данных ожидаемому. В этой статье расскажу, как избавиться от подобных проблем и добиться стабильности, внедрив три ключевых шага: API-слой, Backend-for-Frontend (BFF) и проверку с помощью Zod.

▍ Введение

let c=(b,l)=>WebAssembly.instantiate(new Int8Array(
[,97,115,109,1,,,,1,5,1,96,,1,127,3,2,1,,7,4,1,,,,10,
l=(b=b.split` `.flatMap(t=>t>-1?[65,t]:107+'-*/'.indexOf(t)))
.length+4,1,l-2,,...b,11]))

(await c('11 11 1 - + 4 * 2 /')).instance.exports['']()

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, написанного в трёх разных стилях.