JavaScript *

Я много общаюсь о микросервисных архитектурах с «не-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, байт-кодом, и много чем еще. Углубимся во все этапы достаточно, чтобы понимать, за что отвечает каждый из них.

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

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

В этой серии из трех частей мы подробно рассмотрим процесс создания клона веб-версии Telegram с использованием Next.js, TailwindCSS и Stream SDK. В первой части мы настроим все необходимые инструменты для нашего проекта, добавим аутентификацию и создадим макет приложения с помощью TailwindCSS.

Важность надежной обработки запросов в оффлайн-режиме невозможно переоценить, особенно для приложений, которые должны функционировать и в отсутствии интернет-соединения. Workbox - это мощный инструмент для управления Service Worker в браузерах, он как раз призван решать подобную задачу при помощи соответствующего плагина, но поддержка Background Sync API не универсальна. В этой статье я покажу, как расширить Workbox, чтобы Background Sync корректно работал даже на платформе iOS/Safari.

Даже самые зелёные новички в вебе знаю, что скрипты JS, нужно располагать в самом низу страницы перед закрывающим тегом `` и всё знаю что это повышает скорость загрузки страницы. Но Вы когда-нибудь задумывалась почему оно так?

JavaScript по своей природе однопоточный язык, но мало того, он делит этот единственный поток сразу с HTML и CSS. Это приводит к тому, что встречая тег <script>, браузер начинает, исполнять его код, при этом останавливая дальнейшую обработку HTML и CSS и в результате пользователь наблюдает белый экран, вместо сайта, до тех самых пор пока, браузер не закончит с кодом JavaScript. Именно потому убирая подключения скриптов, в самый конец страницы, мы даём интерфейсу сайта максимально быстро погрузится и не бесить пользователей белой простынёй.

Но подобный подход годен не везде, иногда жизненно необходимо, чтобы код JS, начал исполнение как можно раньше. Да и при подключении в самом низу, крупный JS-бандл, может здорово подкосить перфоманс сайта. Как быть в таких ситуациях? Смирится с тем что пользователи будут испытывать определённый дискомфорт во время загрузки сайта? Конечно же нет, можно попробовать вынести наш код в веб-воркеры!

Что делать, если во дворе появился строительный забор?

Или уже начали вырубать деревья?

Самое время задуматься над созданием системы мониторинга.