JavaScript *

Автоматизация тестирования API — задача, с которой сталкиваются даже опытные инженеры, но многие всё ещё предпочитают полагаться на ручные запросы в Postman, а затем переносят их в код — и так годами. Но можно ли избежать этого лишнего шага? В этой статье мы покажем, как настроить эффективную автоматизацию тестов API с Postman и Newman, интегрируя их в процессы CI/CD, чтобы избежать ошибок и повысить производительность.

Сегодня я хочу поделиться глубоким исследованием того, как применять золотое сечение в современном дизайне 2025 года. Эта статья основана не только на теории, но и на реальном опыте работы с крупными проектами, A/B тестах и исследованиях пользователей.

Наш фронтенд начинался как простой SPA на React, собранный с помощью Vite — типичный монолит с несколькими страницами. Со временем проект оброс новыми функциями и интеграциями и начал становиться всё сложнее в поддержке.

На горизонте появились новые вызовы: к продукту планировалось подключать всё больше независимых сервисов, а значит — ещё больше интеграций и роста кодовой базы. Мы понимали, что нагрузка на инфраструктуру будет только увеличиваться, поэтому решили заранее заложить архитектуру с расчётом на масштабирование.

После изучения разных вариантов мы остановились на подходе микрофронтендов. Хотелось разграничить зоны ответственности между командами и ускорить разработку, не теряя гибкости. В качестве сборщика решили остаться на Vite — он быстро развивался, предлагал отличную DX и поддержку модульной федерации через плагин. Кроме того, важно было сохранить единый репозиторий, чтобы упростить CI/CD и управление зависимостями.

Сначала я недооценил document.currentScript, но оказалось, что он отлично подходит для передачи параметров конфигурации прямо в теги <script> — и это далеко не все.

Порой я натыкаюсь на давно существующие браузерные API в JavaScript, о которых, по идее, я должен был узнать гораздо раньше. Например, window.screen или метод CSS.supports(). К счастью, я понял, что не один такой. Помню, как однажды упомянул window.screen в посте и получил неожиданно много комментариев от людей, которые тоже впервые о нем слышали. Это меня немного приободрило — я почувствовал себя не таким уж глупым.

Видимо, дело не в том, как давно существует API, а в том, насколько он полезен в реальных задачах. Если window.screen почти нигде не используется, о нем легко забыть.

Но иногда все же появляется неожиданный шанс применить одну из этих малоизвестных возможностей. Похоже, я как раз нашел такой случай для document.currentScript — и намерен использовать его по максимуму.

Я много общаюсь о микросервисных архитектурах с «не-Java-людьми» — будь то разработчики на C#, энтузиасты Node.JS/JavaScript или GoLang. Все они сталкиваются с необходимостью оркестрации в микросервисной архитектуре — или просто хотят использовать workflow, упорядочивание действий, обработку таймаутов, Saga и компенсации, а также другие полезные возможности.

Open Source BPM-платформа Camunda отлично подходит для этих задач. Ориентированность на разработчиков — один из ключевых принципов продукта, но при изучении документации может показаться, что она рассчитана в основном на Java-разработчиков. Платформа предоставляет множество точек расширения и интеграции, но всё это реализуется на Java. Значит ли это, что другим разработчикам путь закрыт?

Нет! На самом деле, запустить Camunda и работать с ней без знания Java очень просто — архитектуру можно выстроить так, чтобы писать код на любом удобном языке. В этом посте:

С хорошей отказоустойчивостью интерфейс остаётся стабильным и понятным, пользователь получает предсказуемый и комфортный опыт, а сбои отдельных компонентов не приводят к сбоям всей системы.

Хорошая отказоустойчивость начинается с мышления.

Важно не просто латать ошибки по мере их появления, а комплексно подходить к решению — формировать правильное понимание, разрабатывать устойчивые подходы и строить систему, способную адекватно реагировать на возможные сбои.

Принципы описанные ниже в большинстве своем универсальные и подойдут к большому количеству сфер, даже вне области информационных технологий. Но моя основная опора будет на сферу веб-разработки

Ни для кого ни секрет, что разработка и IT‑решения в 2025-м году — это гонка за скоростью: от выяснения бизнес‑требований до финальной версии продукта. Чем быстрее пишется код, тем раньше ваш продукт попадает к пользователям. Разумеется, выбор технологий существенно сказывается на скорости разработки.

В этой статье я бы хотел затронуть современные инструменты Frontend‑разработчика, которые уже начали вытеснять классику, а также попутно сокращают объём кода, избавляя разработчика от рутины.

Разработка мобильных интерфейсов — непростая задача. Иногда по разным причинам пользователю недоступен функционал Web-приложения в мобильной версии. Что делать если десктопа под рукой нет?

Виртуальное зеркало: Создала сама, делюсь с вами!

Привет! Меня зовут Аня, и я фанат e-commerce. В прошлый раз мы говорили о визуальном поиске, а сегодня я хочу рассказать о своей гордости — библиотеке виртуального зеркала.

Ещё год назад, когда готовые решения были редкостью, я решила выяснить, как работает виртуальная примерка. Результат? Моя собственная библиотека, которая позволяет примерить косметику и аксессуары в реальном времени или на фото.

Содержание:

- Стрелочные функции: arguments, hoisting

- Работа с контекстом

- Методы присваивания контекста

- Обработчик событий

Как набираться опыта в разработке: пет-проекты, бизнес-задачи и путь вверх

Привет! Я Ник Уайт, frontend-разработчик. Рассказываю честно и по делу — как я набирался опыта, чем учебные проекты отличаются от настоящих, почему ошибки — это круто, и как не перегореть, прокачивая скиллы. Если ты на старте или хочешь расти — будет полезно.

Я решил улучшить свои навыки алгоритмов перед собеседованиями и начал с простых задач. Всё шло гладко… пока не наткнулся на “Merge Two Sorted Lists” — нужно объединить два отсортированных связанных списка в один. В статье делюсь тем, как я разобрался в этой структуре данных, решил задачу и что вынес из этого опыта. Для новичков однозначно будет полезно!

Привет! Меня зовут Сергей Востриков, я руковожу направлением Маркет и интеграций в Битрикс. Моя команда развивает решения для разработчиков тиражных решений и индивидуальных кастомизаций. Сегодня я хочу рассказать про наш новый официальный SDK под JavaScript для работы с REST API Битрикс24. Он опубликован в виде отдельного репозитория на Github и распространяется на условиях лицензии MIT. 

В этом посте — о принципах разработки SDK, наших планах по его обновлению и том, как можно повлиять на развитие инструмента. 

Бывало ли у вас так, что вы придумали у себя в голове идеальное приложение, в котором есть все вам необходимое (ну или хотя бы какой‑то обязательный минимум)? Вот вы нашли приложение, которое должно решать те задачи, что вы себе придумали, но как только принялись его проверять в действии, пришли к выводу, что все совсем не так радостно.

Вот вы сказали себе: «Ну ладно, это же опенсорс! Значит можно попробовать что‑то с этим сделать своими силами. Заодно и внести посильный вклад в развитие этого продукта. Что может быть лучше?» Но реальность оказалась иной. Код для непрограммиста оказался довольно сложный, принятая разработчиками архитектура приложения также вызывает вопросы (конечно, скорее всего только у меня) и т. д.

К чему это я? Начну с небольшой предыстории.

В этом году JavaScript исполняется 30 лет.

За три десятилетия он прошел путь от забавного и непритязательного скриптового языка, созданного за 10 дней, до самого популярного языка программирования в мире. Ниже — ключевые моменты истории JavaScript, которые помогут понять, как он менялся и куда идет.

Статья написана для юзверя (в том числе разработчика) с базовыми знаниями работы в операционной системе, консолью, IDE и браузером.

В статье рассматривается инструкция для установки LLM локально на ПК юзверя для обхода проблем работы с удаленными серверами. Также статья поможет в совсем базовом понимании работы с LLM.

Здесь будет рассматриваться IDE VSCode, однако всё нижеописанное актуально и для JB Webstorm или Pycharm (и др).

Каждый, кто использует Vue для разработки, так или иначе встречается с необходимостью выполнить какое‑либо побочное действие при изменении значений, и сразу в голове возникает мысль о двух методах‑наблюдателях — Watch и WatchEffect.

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

По ходу статьи также будут приведены некоторые полезные библиотеки Vue, которые часто используются в разработке.

Раньше было лучше? Не уверен. Еще 10 лет назад я тестировал без ИИ: искал ошибки, писал отчеты, огребал от разрабов. А теперь — всё в 5 раз быстрее, и пока вам несут матчу на кокосовом, можно словить и починить баги. В статье — гайд + код.

В этой серии статей мы пройдемся по каждому этапу работы V8: лексическому и синтаксическому анализу, построению AST, интерпретации и оптимизациям. Затронем Ignition, Sparkplug, Maglev и Turbofan; разберемся с hidden classes, байт-кодом, и много чем еще. Углубимся во все этапы достаточно, чтобы понимать, за что отвечает каждый из них.

В этой части посмотрим на лексический и синтаксический анализ.