По фактам: почему CSS и XPath — путь в ад, а test-id — спасение. В статье — реальные советы, как договориться с командой, внедрить test-id и писать автотесты, которые не разваливаются каждую пятницу.
В апреле я съездил на HolyJS. Еще до поездки в расписании конференции моё внимание привлек доклад Виктора Хомякова «Удаление мертвого кода в проекте: практическое руководство». Послушав его, я понял, что могу использовать полученные знания в своем текущем проекте, при этом не затрачивая много усилий. В этой статье я расскажу, что у меня получилось.
Рассказываю, как с помощью Google Stitch за 30 секунд получил готовый дизайн приложения, а потом с Gemini за пару часов превратил его в работающий сервис с голосовым вводом.
Привет, Хабр! После успеха прошлого поста делюсь новым разбором задач с собеседований. Сегодня разберём три ключевые темы: поднятие (hoisting), работу с объектами и реализацию связного списка. Погнали!Для кого эти задачи и что проверяют?
Эти вопросы часто встречаются на собеседованиях для Middle JavaScript-разработчиков. Через них проверяют:
➕ Понимание «подводных камней» языка (hoisting, TDZ, ссылочные типы);
➕ Умение работать с низкоуровневыми структурами данных;
➕ Способность предвидеть edge-кейсы.
8 лет назад я исправил опечатку в чужом репозитории, а сейчас регулярно делаю коммиты в проекты, которые использую, и даже вошел в core team библиотеки с 27000 звёзд на GitHub
В этой статье покажу, что участие в Open Source проще, чем кажется. Расскажу, как регулярная работа с чужим кодом помогает быстрее разбираться в незнакомых кодовых базах, писать тесты и лучше документировать решения. А также объясню, почему публичная активность на GitHub выгодно отличает вас от других разработчиков, особенно в эпоху повсеместного использования ИИ.
Привет, Хабр! Меня зовут Дмитрий Ханин, я работаю в Сбере и участвую в разработке Платформы ЦА — системы на базе блокчейн, занимающейся привлечением средств юридических и физических лиц. Сегодня хотелось бы рассказать про тот путь, который мы прошли за несколько лет, как организовали взаимодействие между разными приложениями и чем нам это помогло.
Рассказ разделён на две части. В первой рассмотрим путь проекта и проблемы, с которыми сталкивались, а во второй разберём, как мы решали часть этих проблем.
Привет, с вами снова я – Дмитрий, React-разработчик, хотелось бы сегодня затронуть тему среды выполнения JS. Многие знают, другие уже подзабыли, а новички — вовсе не в курсе. В общем, эта статья точно найдёт своих читателей. Постараюсь простыми словами и по делу.
В блоге React Labs мы делимся проектами, находящимися на этапе активных исследований и разработки. В этой статье рассказываем о двух новых экспериментальных возможностях, которые уже доступны для тестирования, а также делимся новостями о других вещах, над которыми сейчас работаем.
Сегодня мы рады представить вам документацию по двум новым экспериментальным возможностям, уже доступным для тестирования:
View Transitions (переходы между экранами)ActivityА также делимся обновлениями по возможностям, над которыми продолжаем работать:
Пример использования View Transitions и Activity в клоне AirBnB
Что такое TypeScript? Официальная документация отвечает так: “TypeScript — это JavaScript с синтаксисом типов”. Однако некоторые считают TypeScript своеобразным слиянием двух языков: языка для манипулирования значениями JavaScript и языка для манипулирования типами.
Cистема типов TypeScript Тьюринг-полная. Это означает, говоря по-простому, что система может решить любую вычислительную задачу при наличии некоторого представления входных и выходных данных.
Можно ли использовать это знание на практике? Как избежать крайностей от примитивного аннотирования типов до избыточного усложнения?
Эта статья для разработчиков, которые уже используют TypeScript, но хотят выйти за рамки базовых практик. Мы не будем обсуждать синтаксис или настройку конфигураций. Вместо этого сосредоточимся на стратегиях, которые помогут:
Недавно мне попался следующий твит от OneHappyFellow:
Кажется, я понял, что меня настолько напрягает при программировании на языках с динамической типизацией. Дело в том, что никогда нет уверенности, будет ли конкретная библиотека работать определённым образом, и не сломается ли код при очередном минорном обновлении версии.
— One Happy Fellow (@onehappyfellow) 5 мая 2025
Этот тезис меня заинтересовал. Дело в том, что по работе мне в основном приходится иметь дело с Clojure. Это динамический язык, но его экосистема на редкость известна своей стабильностью. В этой статье мы подробно разберём, почему именно так сложилось, но для начала я приведу некоторые доказательства, подкрепляющие мою точку зрения.
По данным сразу нескольких вышедших в 2025 году отчётов исследователей, объём генерируемого ботами трафика в интернете впервые превысил человеческий. Боты теперь составляют более половины интернета, из них 3/4 — вредоносные.
В этой статье я хочу поделиться своим опытом настройки WSL для комфортной разработки, а также размышлениями о том, почему такой подход оказался для меня оптимальным. На это влияет несколько факторов.
Во-первых, иногда требуется специфический софт, который доступен только под Windows. Да, в других ОС могут быть аналоги, но зачастую они менее удобны или требуют дополнительной настройки.
Во-вторых, для разных проектов нужно разное окружение. WSL позволяет легко изолировать среды разработки, настраивая их под конкретные задачи или группы проектов. Это гораздо удобнее, чем держать несколько физических машин или постоянно переустанавливать систему.
Наконец, есть и субъективный фактор — привычка. Я с самого начала работал с Windows, и, несмотря на все преимущества Linux, полностью перестроить рабочий процесс оказалось сложно. WSL в этом плане — идеальный компромисс: Linux-окружение под рукой, но без необходимости отказываться от удобств Windows.
Ранее на Piccalilli Сэм Роуз поделился реальными примерами использования вспомогательных типов (utility types) TypeScript. Сегодня я хочу продолжить эту тему и поделиться несколькими продвинутыми возможностями TypeScript для работы с типами, которые, на мой взгляд, особенно полезны и применимы в реальных проектах.
Цель этой статьи — дать общее представление о каждой из возможностей, а также привести пример ее использования, чтобы вы могли лучше ориентироваться в том, какие инструменты можно использовать при создании типов.
Если вы когда-нибудь, запуская рабочую станцию с операционной системой Windows, обнаруживали, что ваш Full HD монитор показывает лишь изображение с разрешением не более 1024x768 и определяется как «Стандартный не Plug-n-Play монитор», и по какой-то причине вы не имеете возможности переключить монитор на другой видеовход, не поленитесь заглянуть под кат, где я растолкую, как «временно» выкрутиться минимальными усилиями.
Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.
Однако в последнее время, особенно во фронтенд-разработке и в мире React, акцент на SOLID заметно снизился и, например, вопросы о нем на собеседованиях встречаются всё реже. В первую очередь, это связано с переходом к функциональному стилю программирования, широким использованием хуков и отказом от классовых компонентов, что отодвигает принципы ООП на второй план.
Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.
В этой статье я хочу поделиться своим взглядом на то, как каждый из принципов SOLID может быть применен в разработке React-приложений. Здесь не будет революционных идей, особенно для опытных разработчиков, но, возможно, эта информация окажется полезной для начинающих разработчиков, стремящихся писать более качественный и поддерживаемый код.
Как известно, у Solid довольно скудная экосистема, поэтому для сложных проектов я беру React+MobX. Однако недавно подвернулся небольшой mobile-only проект, в котором разве что маскированные инпуты и кастомные селекты, которых для Solid предостаточно. При этом требования к размеру выходных файлов и перфомансу были высокие.
Очевидным решением посчитал взять Solid, заодно и сравнить его по всем параметрам (размер, перфоманс, возможности реактивности, удобство настройки) в реальном проекте. Никаких синтетических тестов с рендерингом больших таблиц и хранением в сторе нескольких мегабайт данных не будет, зато приведу замеры из реального приложения. Бонусом — репозиторий с универсальной архитектурой для Solid+Preact+React, где замена фреймворка (набора стейт‑менеджер + рендеринг UI) производится одной строчкой кода.