Сравнение разных синтаксисов Vue JS:

• Options API

• Composition API

• Class API

• Class API + vue-property-decorator (npm)

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Привет! Я ex. Разработчик из VK, сейчас принял оффер от Ozon'a, и за последний месяц я прошел собеседования в 4х бигтех компаниях: Ozon, Avito, Wildberries и T-Bank и везде дошел до финалов/офферов. Пообщавшись во многих группах, посвященных Go-разработке, я понял, что много умных ребят готовясь к собесам не имеют четкой системы подготовки, и из-за этого заваливают технические собесы в компании. Не претендуя на истину в последней инстанции, предлагаю свою методику подготовки к собесам, которая помогла мне и моим знакомым подготовиться к техническим собесам во все популярные ру-бигтехи.

1. Структурирование хранилища
2. Разделение хранилища на модули
3. Автоматический импорт модулей хранилища
4. Сброс состояния модуля
5. Глобальный сброс состояния модуля

Одним из новых инструментов в арсенале Vue 3 является Vite - быстрый и легковесный бандлер, который значительно упрощает процесс разработки и ускоряет сборку проекта. В этой статье мы рассмотрим, как перейти от стандартного подхода с использованием Vue-CLI и Webpack к более продвинутому и эффективному методу работы с помощью Vite.

Здравствуйте. Я учусь на последнем курсе бакалавриата и уже через месяц с небольшим буду защищать свою выпускную квалификационную работу (или же дипломную). Мне захотелось рассказать про неё здесь, чем я сейчас и займусь.

Меня давно интересуют инструменты для обеспечения работы языков программирования - лексеры, парсеры, интерпретаторы, компиляторы и всякое такое. Настолько интересуют, что уже в конце первого курса я решила, что в конце обучения буду защищать свой маленький язык программирования. Увы, создание собственного языка оказалось делом довольно сложным, из-за чего пришлось искать новую тему. Примерно на третьем курсе мы изучали в университете Kotlin, который быстро запал мне в душу и стал моим любимцем (после Lua). Мне захотелось написать дипломную именно на нём, поэтому я стала думать, что бы такое написать. Так как меня интересовал геймдев, я подумала: "Почему бы не создать свой движок для текстовых квестов как альтернативу Ren'Py?". Подумала и написала простой движок. Увы, в нём не было научной новизны, да и писать под него было неудобно, ну хоть получила опыт создания язычков, когда дала жизнь своему Av, про который писала в прошлой статье.

В университете мне сказали, что подобная тема совершенно не подходит для защиты, после чего я снова задумалась, что бы написать. Вспомнила, что довольно неплохо знакома с ANTLR, и решила написать DSL, который позволит превращать классы, которые сгенерировал ANTLR, в AST Kotlin. Эта мысль возникла довольно внезапно, но мне быстро стало интересно, во что она может превратиться. Как писать такой DSL, а главное, зачем? Как я объясняла нашей завкафедрой, подобный инструмент позволит автоматически переводить кодовые базы с разных языков на один - мой любимый Котлин. Кроме того, это поможет поддержать авторов новых языков программирования, поскольку он позволяет не писать свой рантайм, а положиться на уже существующий JVM, ведь Котлин исполняется на нём.

Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.

Микросервисная архитектура стала де-факто стандартом для построения современных масштабируемых приложений. Вместо единого монолитного приложения система разбивается на набор мелких независимых сервисов, каждый из которых отвечает за свою четко обозначенную функцию. Такой подход позволяет упрощать разработку и развертывание отдельных компонентов, повышать отказоустойчивость и масштабируемость системы. Однако переход к микросервисам и их эффективное использование сопряжены с рядом сложных задач. Для их решения в практике выработаны архитектурные паттерны – типовые подходы и шаблоны проектирования.

В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway), о сетевых и структурных паттернах (Service Mesh, Sidecar), о шаблонах работы с данными (Database per Service, CQRS) и об особом подходе к хранению состояния (Event Sourcing). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.

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

В этой статье мы проведём подробный анализ современных практик frontend-разработки, сравним состояние React и Vue 5 лет назад и на текущий момент, а также попробуем спрогнозировать их перспективность в обозримом будущем с учётом развития LLM моделей и AI агентов. Посмотрим их экосистемы (Next.js и Nuxt, Redux и Pinia), использование в бэкенде, популярность решений в энтерпрайзе, а так же понимание разработчиками и LLM моделями.

Я устал писать бойлерплейт и базовые стили. В итоге заставил ИИ делать это за меня. Результаты, размышления и откровения — внутри.

System Design Interview — пожалуй, один из самых «бесформенных» этапов технического собеседования. Здесь важно не найти единственно верное решение, а продемонстрировать системное мышление, умение работать с абстракциями, логически выстраивать архитектуру и аргументированно делать выбор технологий.

Александр Кучук, эксперт сообщества Spring АйО, подготовил авторскую статью, в которой шагом показывает, как структурировать интервью, какие вопросы задавать, как рассуждать и что оценит интервьюер.

Кстати, Александр ведет репозиторий с заметками: https://github.com/qcha/JBook

Книга «Изучаем Vue: основные концепции и практические паттерны для современных и масштабируемых пользовательских интерфейсов» — это сжатое практическое руководство по Vue.js, ориентированное на уже практикующих разработчиков, работающих над созданием интерфейсов. Автор книги, Майя Шавин — старший инженер-программист в Salesforce (ранее в Microsoft), специализирующаяся на JavaScript и frontend-фреймворках. Наличие примеров и акцента на переиспользуемость компонентов дает разработчикам подсказки как строить масштабируемые и поддерживаемые интерфейсы.

***

Вайб‑кодинг (от англ. vibe coding) — новый способ программирования, где вместо ручного написания кода вы описываете задачу AI‑модели, а она генерирует код сама​. Как метко заметил Андрей Карпати, один из пионеров этого подхода, «это не совсем программирование — я просто вижу что‑то, говорю что‑то, запускаю что‑то и копирую‑вставляю что‑то, и это в основном работает»​. В 2025 году вайб‑кодинг из эксперимента энтузиастов превратился в реальный инструмент: появились мощные облачные LLM, способные писать сложный код, и уже до 90% кода может создаваться с участием ИИ. Ниже — обновленный гайд, как начать вайб‑кодить, какие модели использовать и на что они способны, а также какие возможности открываются перед бизнесом.

Разрабатываем робота с нуля - от ИИ-дизайна до полного проектирования и реализации всех компонентов устройства.

Зачем? Ради фана, конечно - этот проект практически квинтессенция моих увлечений - электроника, 3d-печать, программирование микроконтроллеров, ИИ и в целом все, что можно включить в сферу DIY.

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

Как структурировать проект с помощью ИИ и избежать типичных ошибок при «vibe coding»?

12-шаговая методология, позволяющая создавать работающие приложения даже без навыков программирования.

Продолжаем наращивать базу знаний по System Design! В этот раз освятим использование Pub/Sub, Event-Driven Architecture, Distributed Systems, Leader Election. Посмотрим на их концепции и области применения при проектирование высокодоступных отказоустойчивых систем.

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах.

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

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

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

Новый перевод от команды Spring АйО расскажет вам, каких проблем можно избежать, если пользоваться подходом «Рендеринг на стороне сервера» и в чем преимущества такого подхода в целом по сравнению с подходом Single Page Application.

Про OAuth 2.0 уже написано немало статей, в том числе на Хабре, но у этих статей есть особенность - в то время как после основного RFC 6749 вышло несколько дополнительных RFC, расширяющих, объясняющих и дополняющих основной RFC, обычно описывают только базовую спецификацию. Это не говорит, что статьи плохие - наоборот, они полезны. Но хотелось бы сделать обзор вообще всего, что можно отнести к OAuth 2.0, более того часть их них рекомендована к использованию. Поэтому в данной статье попробую кратко описать большинство спецификаций, которые относятся к OAuth 2.0.