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

Современные веб-приложения, даже простые на вид, часто подразумевают нетривиальную архитектуру, состоящую из многих компонент. В статье «Делаем современное веб-приложение с нуля» я рассказал, как она может выглядеть, и собрал для демонстрации простейшую реализацию на стеке из нескольких популярных технологий. В неё вошёл бэкенд, фронтенд, воркер для асинхронных задач и аж два хранилища данных — MongoDB как основная база и Redis как очередь задач. В «Делаем поиск в веб-приложении с нуля» я показал, как можно добавить полнотекстовый поиск, и подключил третье хранилище — Elasticsearch.

Всё это время для простоты разработки и отладки компоненты приложения запускались локально через Docker Compose. Но как развернуть такое приложение в настоящем продакшн-окружении? Как обеспечить горизонтальное масштабирование? Как раскатывать новые релизы без простоя? 

В этой статье мы разберёмся, как разворачивать многокомпонентное веб-приложение в кластере Kubernetes на примере его локальной реализации — minikube. Мы поднимем виртуальный кластер прямо на рабочем ноутбуке, разберёмся с основными сущностями Kubernetes, запустим и соединим между собой компоненты демо-приложения и обсудим, какие ещё возможности Kubernetes пригодятся нам в суровом энтерпрайзе. Если вы занимаетесь разработкой и слышали о Kubernetes, но ещё не имели возможности пощупать его руками — добро пожаловать под кат!

Привет всем увлеченным нейронными сетями или тем, кто хочет вникнуть в технологии. Сегодня я хотел бы познакомить вас со своим захватывающим проектом с открытым исходным кодом «Бесконечное нейронное радио». Бесконечное, потому что lofi музыка и подкасты могут генерироваться нейронными сетями бесконечно. В этой статье я бы хотел углубиться в то, как все работает изнутри.

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

• Заливка проекта на GitHub.
• Аренда и настройка облачного сервера по SSH.
• Настройка nginx для раздачи статических файлов.
• Сжатие бандла.
• Подключение домена.
• Настройка HTTPS.
• Настройка Docker.

В последние годы PHP динамично развивался с появлением новых версий языка, содержащих ряд новых фич, депрекаций и более строгий синтаксис. Кроме того, библиотеки и фреймворки, такие как Symfony, постоянно претерпевают изменения: каждые полгода появляются новые минорные релизы, а каждые два года - мажорные, наиболее существенные. Для нас в Westwing очень важно регулярно обновлять имеющуюся кодовую базу, чтобы она оставалась работоспособной, безопасной и актуальной. К счастью, в сообществе PHP появилось множество инструментов, способствующих улучшению кодовой базы.

• мы выберем для него актуальный http-роутер,
• позаботимся о логах,
• напишем тесты: unit-тесты, тесты хэндлеров и функциональные,
• настроим автоматический деплой через GitHub Actions и др.

Сроки

В разработке ПО существует неразрешимое противоречие — это оценка сроков.

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

С другой стороны, разработка порою в душе не е... вообще не знает, сколько надо времени, особенно если

• новая функциональность нетипична
• есть зависимости на другие команды
• будет задействована новая технология
• ТЗ надо сильно уточнять
• надо разобраться в логике легаси-кода

Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.

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

Реализацией RPC запросов поверх брокеров сообщений никого не удивишь: очередь для запроса, очередь для ответа — ничего сложного.

Тот же RabbitMQ имеет пример в официальной документации. Других примеров там нет, поэтому создается впечатление, что отправка ответных сообщений в другую очередь — единственный возможный способ реализации RPC.

Этот сценарий отлично работает когда у нас есть непрерывный поток сообщений и непрерывный поток ответов на них. Однако, данный подход не применим в случаях, когда нам нужно отправить только одно сообщение и получить ответ именно на него. Мы сразу же попадаем в какой-то ад с фильтрацией ответов по correlation_id.

На самом деле, в RabbitMQ есть механизм и для такого сценария. Но он спрятан в недрах документации и о нем почти нет информации в интернете (особенно рабочих примеров кода).

Вот это недоразумение мы сейчас и исправим.

Привет! С вами Виктор 👺, тэнгу‑хранитель одной из дизайн‑систем Ozon.

В июне 2023 года Figma выкатила мощное обновление, во многом ориентированное на разработчиков. Точнее на поиск общего языка между проектировщиком и программистом. Я давно занимаюсь дизайн‑системами и знаю как тесно связан дизайн и код. Насколько взаимопонимание между дизайнером и разработчиком ускоряет доставку продукта до пользователя.

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

Помогут ли новые фишки Figma наладить общение?

Привет, Хабр! Меня зовут Максим Кита, я разработчик баз данных, специализируюсь на анализе, планировании и выполнении запросов, а также на оптимизации производительности.

Я расскажу о высокоуровневой архитектуре ClickHouse, CI/CD, тестировании производительности, интроспекции, абстракциях и алгоритмах и выборе библиотек для высокопроизводительных приложений. Поделюсь ниндзя-техниками, которые помогут ускорить ваши системы. Вы сможете попробовать эти советы и практики на своем проекте и оценить насколько они полезны.

Продолжаем вкусно готовить asyncio

Теперь мы уже знаем достаточно, чтобы написать модный асинхронный микросервис, реализующий паттерн "API-шлюз". И попутно познакомимся с асинхронным логгированием и доступом к базе данных.

Представляем результаты ежегодного опроса, данные и скрипты обработки можно найти на GitHub.

В конце статьи будет локальный опрос пользователей Хабр.

Сегодня обсудим узкоспециализированные возможности и кейсы использования RabbitMQ. Эти вещи полезны не всем, но в некоторых случаях помогают сэкономить уйму времени.

Что конкретно разберём:

— расчёт количества консьюмеров по формуле Эрланга;

— шардирование — различные способы балансировки;

— дедупликацию сообщений в очереди;

— многоуровневую очередь повторных попыток;

— приоритеты сообщений.

Продолжаем делиться конспектами Алексея Барабанова, IT-директора «Хлебницы». На этот раз обсудим специфику работы RabbitMQ с высокими нагрузками (High Load) и обеспечением высокой доступности (High Availability). Рассмотрим различные методы увеличения производительности и горизонтального масштабирования, разберём и настроим внутренние инструменты. Также по мере погружения постараемся изучить основные подводные камни всех подходов.

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

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

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

Полезная ссылка с подробным объяснением концепции микрофронтенда.

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

Привет! В статье поделюсь, как инструмент автоматического рефакторинга Rector помогает обуздать легаси и автоматизировать обновление PHP проектов и пакетов, чтобы процесс проходил эффективнее и малой кровью. 

Статья написана на основе доклада с PHP Russia 2022.