Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога cdnnow! Мы с вами познакомились в этом посте про историю DRM для видеоконтента. Сегодня я хочу поговорить с вами про Docker, а точнее про то, о чём многие забывают: различиях в нём для разных систем. Нам, как CDN-провайдеру Docker, все его 50 оттенков близки и знакомы. И, к счастью, наше взаимодействие с ним происходит из-под Linux, но, увы, не всем так везёт.

Как это часто бывает, с мультиплатформенностью и прочими «красивыми» словами в IT, всё не так однозначно. У всего своя цена, и под капотом один и тот же инструмент на разных системах, по сути своей может представлять из себя несколько разных вещей с различными принципами работы и производительностью. А обещания революции скрывают за собой эволюцию, либо вовсе регресс и топтание на месте.

В процессе разработки витрин данных часто возникает задача предоставления клиентам данных в агрегированном виде. Если данных в хранилище немного, то их можно агрегировать “на лету”, но это плохая практика так как, чем больше будет копиться данных, тем дольше будут выполняться запросы, и тем больше Clickhouse будет съедать ресурсов. В этих случаях логично хранить данные в заранее агрегированном виде, вопрос лишь в том, как реализовать расчет данных агрегированных значений.

В интернете существуют много однотипных статей иллюстрирующих базовое использование материализованных представлений (далее - матвью) на движке AggregatingMergeTree, но если ваша задача выходит за рамки “1 нода, 1 метрика, 1 параметр агрегации” эти статьи вам мало чем помогут. Я посчитал, что моим коллегам может пригодиться своего рода гайд о том, как пользоваться данными представлениями для более сложных задач.

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

В рамках моей задачи хранилище данных (далее - DWH) реализовано в виде реплицированного кластера состоящего из 3 нод, данные на ноды распределяются равномерно в соответствии с ключом сортировки таблиц. Существует исходная таблица source, которая содержит столбцы id, timecode_1, metric_data - данные представляют собой временной ряд утилизации ресурсов с гранулярностью 1 минута. Данные поступают блоками каждые 2 минуты.

В прошлый раз я описал, как можно поставить задачу (Job) в очередь Laravel из хранимой процедуры или триггера PostgreSQL.

В этой статье я расскажу, как можно преобразовать события, возникающие в PostgreSQL, в события Laravel.

Рабочий пример выложен на GitHub.

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

В статье я расскажу:

о простом интерфейсе Zustand

о его внутреннем устройстве

о производительности без усилий: 3 простых способа оптимизаций

о производительности на максималках: не всегда нужно использовать длинный цикл рендера React, чтобы достичь максимальной производительности - Zustand может быстрее!

о применении на практике: советы и рекомендации по интеграции Zustand в ваши проекты для достижения масштабируемости и удобства поддержки.

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

Декомпозиция монолита - не редкая проблема. Она возникала в большинстве компаний, где я работал. Происходит это потому, что на ранних стадиях развития любого стартапа накапливается так называемый decision debt - выбранная архитектура является оптимальной для быстрой разработки и экспериментирования, но не для зрелого продукта.

Учитывая популярность проблемы, существует множество книг и статей о подходах к её решению, но мне показалось, что есть недостаток практических примеров. Поэтому, в этой статье я сосредоточусь на технических деталях, используя в качестве примера приложение, написанное на PHP и фреймворке Symfony.

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

Посмотрим, каким был 2023 для сообщества, в 1120 мнениях.

Результаты также можно найти на phpcommunity.ru. Вот итоги за 2022, 2021, 2020.

Привет, Хабр!

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

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

Эта статья — цельный план развития во фронтенде. Расскажем, что из себя представляет современный фронтенд и какие знания нужны для востребованности на рынке труда.

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

К статье прилагается роадмэп, который можно скачать, изучать, распечатать.

Я хочу поделиться своим опытом использования Zabbix для анализа проблем с производительностью PostgreSQL, используя расширение pg_stat_statements.

Привет👋 В последние годы среди фронтенд разработчиков Typescript используется практически везде по умолчанию, начиная небольшими пет-проектами и заканчивая огромнейшими веб-приложениями. Однако, до сих пор на некоторых проектах можно встретить кучу any и Function. Давайте разберемся используете ли вы этот невероятно мощный инструмент правильно?

Меня зовут Валя Борисов, и я — аналитик в команде Ozon. Задача нашей команды — создавать инструменты для мониторинга и анализа скорости. 

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

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

Недавно попался на глаза примерно такой кусок запроса, и тут прекрасно примерно все:

• множество чтений из CTE (хоть и единственной записи, но все же);

• извлечение по каждому ключу текста с раскастовкой в jsonb;

• извлечение каждого отдельного json-ключа в каждое отдельное одноименное поле;

• "ручное" преобразование текстового представления массива в json в текстовое представление PostgreSQL.

А как - правильно?

Что может быть хуже чем плохой интернет ?

Плохой интернет, когда нужно загрузить картинку весом как чугунный мост. В эпоху очень быстрого интернета мы стали забывать о том, что в некоторых локациях нашего мира нет хорошей сети (например, когда вы едете в поезде по нашей необъятной стране). Эту проблему довольно хорошо решают Service Workers, о которых я вам сейчас расскажу.

Сегодня в среде разработчиков часто продвигают GraphQL в качестве замены REST, хотя обе технологии можно использовать одновременно. В этой статье Анастасия Иванова, технический писатель платформы МТС Exolve (входит в экосистему МТС), рассмотрит интерфейсы подробнее, чтобы понять, как выбрать подходящее решение под каждый конкретный проект. Подробности — под катом.

Привет! Меня зовут Данил, я backend-разработчик в Doubletapp. Почти во всех наших проектах есть пользователи, которые могут войти в систему. А значит, нам почти всегда нужна авторизация. Мы используем авторизацию, построенную на JSON Web Token. Она отлично сочетает в себе простоту реализации и безопасность для приложений.

В интернете есть много разных материалов с объяснением, что такое JWT и как им пользоваться. Но большинство примеров ограничиваются выдачей токена для пользователя. В этой статье я хочу рассказать не только о том, что такое JWT, но и как можно реализовать работу с access и refresh токенами и решить сопутствующие проблемы. Будет немного теории и много практики. Присаживайтесь поудобнее, мы начинаем.

Путеводитель:

• Что такое JSON Web Token?
• Использование и реализация
• Простая реализация JWT
• Access и refresh tokens
• Как отозвать токены
• Доступ с нескольких устройств
• Удаление старых данных
• Резюмируем

Всем привет! Меня зовут Ростислав, я full-stack разработчик. Последние 3 года у меня есть хобби - доведение пет-проектов до стадии финансово рентабельных IT продуктов. Сейчас я хочу поделиться своими советами о запуске проекта, исходя из своего опыта.

По общему мнению, TypeScript стал большим успехом для Microsoft. Я видел множество сияющих от радости людей, напичкавших JavaScript типами, которые могут быть проверены компилятором. Но я никогда не был его поклонником. Ни через пять минут размышлений, ни через пять лет. Поэтому я с большим удовольствием могу сообщить, что мы отказываемся от TypeScript в следующем большом выпуске Turbo 8.

Однажды в поисках примера на React/Django я нашел на Хабре одну интересную статью. Она показалась мне полезной, и я решил дополнить пример из статьи новыми возможностями. В этом сиквеле мы добавим в веб-проект со списком студентов поддержку авторизации и real-time уведомлений на сокетах, улучшим систему Docker-сборки, оптимизируем модель очередей на RabbitMQ и немного пригладим косметику. В результате получим удобный базовый шаблон, с которого вы сможете начинать свои проекты.