На связи Игорь Латкин, управляющий партнер и системный архитектор в KTS. 

Мы на своём опыте разобрались в развертывании stateless- и stateful-сервисов, и теперь хотим поделиться с вами. Мы в KTS не раз создавали подобные инфраструктуры, перепробовали разные решения и выясняли, как построить эффективные процессы.

Сегодня мы поговорим о динамических окружениях (фича-стендах) для stateless- и stateful-сервисов, обсудим особенности и проблемы, которые могут возникнуть и возникали у нас.

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

Всем салют!

Хочу рассказать вам историю о том, как я начинал с уровня — «не могу решить даже 1 easy задачу из 10» до уровня — «могу решить каждую вторую medium задачу» и прошел несколько coding сессий в таких компаниях как Meta, Booking, Careem, Avito...

Как настроить общее рабочее пространство для команды без запуска сборки в watch-режиме и ожидания старта dev-сервера, чтобы подхватить изменения? Для этого нужно удобным для всех образом настроить переиспользование кода внутри монорепы.

Нам поможет Андрей Кочеров, старший разработчик интерфейсов в Яндекс Такси и техлид фронтэнд команды партнёрских продуктов. Он расскажет как сделать готовый к работе репозиторий сразу после чекаута, на основе методологии Trunk Based Development.

Для организации совместного доступа к данным в PostgreSQL программисты часто использую row-level локи. В статье поговорим об оверхеде, который получается от такого подхода и какие есть альтернативы. Давайте посмотрим, как можно поторопить слона!

Источник изображения

Общая тенденция развития технологий характеризуется рывками и спадами. Рассмотрим, например, массовое перемещение человеческих тел. Изначально применялись лошади и повозки, которые постепенно стали сложными, и эта технология превратилась в отдельную индустрию. Затем внезапно появились поезда. Про лошадей быстро забыли, и фокус сместился на новое направление. Пар стал объектом исследований и превратился в сложную науку. Параллельно развивались дизель и электричество. В определенный момент паровые двигатели ушли в прошлое, и все перешли на дизель и электричество. Аналогично сейчас происходит переход на электромашины, требующие значительно меньшего количества жидкостей.

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

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

Напомню, что текст рассчитан в первую очередь на разработчиков, которые имеют мало практического опыта работы в конкурентной и/или микросервисной среде, поэтому многие вещи я объясню на пальцах. Для тех, кто захочет ознакомиться с более строгими формулировками, сразу скажу, что здесь будут затронуты упрощённые идеи паттернов Transactional Outbox и Saga.

В процессе написания source generators для наших внутренних нужд я столкнулся с тем, что на большой кодовой базе обычные генераторы работают, скажем так, небыстро, существенно влияя на производительность IntelliSense в Visual Studio (который и так не то чтобы порхает как бабочка в таких условиях). Наткнувшись на описание более современного API — incremental generators, я обрадовался и обновил наши генераторы, чтобы они его реализовывали, однако ожидаемого прироста скорости не увидел (он был, но незначительный).

Когда нужно делить фронтенд-часть приложения на микросервисы? Какой стек использовать? И какие стандарты использовать, чтобы не выстрелить себе же в ногу при переходе на микрофронты? Михаил Трифонов (Lead Frontend в компании Cloud) ранее уже выступал с докладами о микросервисах, получил фидбек от сообщества и с его учётом сделал новый доклад на HolyJS. А теперь мы (организаторы HolyJS) сделали для Хабра текстовую версию этого выступления.

Странно было бы делать доклад про микросервисы монолитным. Поэтому каждая глава этого поста является изолированным, слабо связанным кусочком. Так что можете читать по отдельности, а можете — целиком.

Привет! Меня зовут Миша, я работаю в Ozon Tech — руковожу направлением базовых сервисов в платформе. Ozon сегодня — это порядка 4000 разработчиков и более 3500 сервисов. Разработка постоянно развивается, количество сервисов увеличивается, и одна из сложных задач — это найти удобный для всех способ управлять тем, что происходит под капотом. 

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

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

Постоянно откладываешь дела на потом и не видишь в этом проблемы? Мне это знакомо. Расскажу как не повторить моих ошибок и почему пора это прекращать. Не откладывай эту статью на потом!

Заблуждение 1. Форма Земли — это просто

Заблуждение 1. В сутках 24 часа или 86 400 секунд

Заблуждение 0. Для доставки нужны адрес и имя

Звук – HiFi-сервис с большой командой инженеров. Мы используем передовые технологии и современный стек, и экспериментируем, чтобы решать сложные, нестандартные задачи. Одна из технологий  – GraphQL.

Эта статья изначально создавалась как гайд по работе с GraphQL для инженеров Звука (системные аналитики, разработчики, QA). При этом статья может быть полезна всем, кто никогда не работал с GraphQL, но очень хочет понять, зачем он может быть нужен, и как поможет решить задачу вашего бизнеса.

Привет, Хабр! Сегодня с вами команда AliExpress Order Management System, и мы поговорим про очередное решение по шардированию PostgreSQL, на этот раз in-app, то есть живущее непосредственно в приложении, которому нужна функциональность шардинга.

Привет! Меня зовут Андрей Барболин, я Senior Software Engineer в команде Order Management System. Сегодня я расскажу вам, как мы сделали шардированный кэш и под стресс-тестами добились 30 миллионов операций в секунду, а также про первую open source библиотеку от AliExpress Россия.