В Bazel есть две крайне полезные фичи: stamping — позволяет встроить в артефакт данные о том, от какого коммита можно собрать аналогичный артефакт и remote cache и remote build — позволяет иметь общий кэш между сборщиками или даже собрать артефакты на ферме.

Ранее, к сожалению, эти фичи были взаимоисключающими, но с версии Bazel 7.0 можно использовать stamping с remote cache при помощи scrubbing-а. А сегодня вышла версия Bazel 7.1, в которой появилась возможность использовать stamping с remote build.

Я не нашел в документации к Jenkins утверждения, что Jenkinsfile пишется на Groovy, но количество отсылок к Groovy столь велико, что у многих людей создаются ложные ожидания.

Я решил написать этот пост после многократного объяснения коллегам отличий скрипта Jenkinsfile от Groovy.

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

С некоторыми ошибками мы пишем в лог стек вызовов. Используемая нами IDE (Idea, GoLand) позволяет по скопированному стеку вызовов получить комфортную навигацию по файлам (Analyze external stack traces). К сожалению, эта возможность хорошо работает только в том случае, если бинарый файл собран на том же хосте, на котором запущена IDE.

Этот пост посвящён тому, как мы пытались подружить формат стека вызовов и IDE.

В Bazel есть любопытная фича, позволяющая добавить данные, которые не инвалидируют кэш сборки.

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

Разберемся, как stamping использовать...

При поиске решений для сборки больших проектов на Go с завидной регулярностью попадались отсылки на статьи про Bazel.

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

Это первый пост из цикла, посвященного миграции с go build на Bazel.

К процессу миграции мы подошли на этапе, когда запуск тестов на CI занимал примерно от 15 минут до часа. При этом мы уже успели реализовать некоторое распараллеливание и кэширование результатов тестов. Без этого тесты на одной машине должны были бы идти примерно часов восемь.

После внедрения Bazel запуск тестов на CI в основном укладывается в интервал от 1,5 до 25 минут (50 перцентиль в районе 12 минут), что гораздо комфортнее исходной ситуации.

Оговоримся, что сравнение этих цифр «в лоб» несколько некорректно: с одной стороны, за время пути кодовая база стала еще больше, а с другой – поменялась топология CI. Но в целом представление о полученном эффекте они дают.

Далее опишем, за счет какого механизма достигнуто ускорение.

Эта статья подробно описывает создание небольшого скрипта на Node.js для выгрузки векторных иконок из Figma в проект, а также универсального компонента для разных видов иконок, который удобно использовать в своём приложении.

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

Под катом – довольно длинный (мы предупредили!) и подробный текст, но с большим количеством полезного кода.

В этом посте мы расскажем про метрику Churn Rate.

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

Всем привет! Меня зовут Артем, я бэкенд-разработчик в команде клиентского бэкенда. Одна из важных частей моей работы — это снижение латенси нашего бэкенда. История, о которой я расскажу в статье, как раз и началась с одной из таких задач. Звучала она следующим образом:

В одном из эндпоинтов чекаута 99 перцентиль латенси пробивает SLO. Нужно это исправить.

Соответственно, возникает вопрос: как максимально быстро и точно найти причину тормозов очень низкочастотного запроса на 99 перцентиле и что делать, чтобы ее устранить? Ответом на него стала библиотека для полуавтоматического поиска узких мест в распределененных системах. Ссылка на гитхаб будет в конце статьи.

Привет! Это пост-отчёт с митапа «Быстрый бэкенд», который прошёл в офисе Joom. С коллегами из Джум Лабс и Авито обсудили, как живётся с большим кластером MongoDB, как битмап-индексы помогают быстро искать по каталогам и как анализировать большие объемы Jaeger-трейсов. В этом посте — видеозаписи докладов, презентации спикеров и несколько фотографий со встречи. 

Привет, Хабр! Меня зовут Леонид Огрель, я работаю аналитиком в Джум Лабс. В этой статье я расскажу, зачем нужен эксперимент в ИТ-продукте, и на что нужно обратить внимание при его запуске.

Как понять, понравится ли пользователям изменение, которое мы хотим внести? Принесет ли оно пользу компании? Работает ли новый алгоритм ранжирования товаров лучше по сравнению с используемым? Снизится ли конверсия, если мы добавим дополнительный баннер на карточку товара?

Чтобы ответить на подобные вопросы, мы проводим большое число онлайн экспериментов, по итогам которыx ожидаем получить чёткий ответ: улучшает ли изменение метрики компании или нет.

Процесс подготовки эксперимента к запуску можно разделить на три этапа. Ниже остановимся подробнее на каждом из них.

Скоро выходит версия Go 1.18, и в массовом сознании она, скорее всего, будет ассоциироваться с Generic-ами. Но помимо них туда попадает еще несколько вкусных фичей. Например, Go Workspaces.

Bottom Sheet представлялся мне сложным и недосягаемым. Это был вызов! Я не понимал, с чего начать. Возникало много вопросов: использовать view или view controller? Auto или manual layout? Как анимировать? Как скрывать Bottom Sheet интерактивно?

Но всё изменилось после работы над Bottom Sheet для приложения Joom, где он используется повсеместно. В том числе и в таких критических сценариях, как оплата. Так что могу точно сказать, что в этом компоненте мы уверены. Настолько уверены, что я даже рассказывал о нём на Podlodka iOS crew #7. В рамках воркшопа я показал, как сделать Bottom Sheet, который умеет подстраиваться под размер контента, интерактивно закрывается и поддерживает UINavigationController.

Стоп, но Apple же предоставила системный Bottom Sheet. Зачем писать свой? Действительно, это так, но компонент поддерживается только с iOS 15. А это значит, что полноценно его можно будет использовать только через 2-3 года. К тому же часто требования дизайнеров выходят за рамки стандартных iOS-элементов.

В рамках статьи хочу развеять туман над Bottom Sheet, ответить на вопросы, которыми задавался я сам и предложить один из вариантов реализации. Чтобы в конце вы могли добавить в резюме строчку «Профессионально делаю Bottom Sheet'ы»

Если заинтересовал, то начнём! Создадим простой Bottom Sheet и шаг за шагом его прокачаем.

1. Научимся подстраиваться под размер контента и закрывать Bottom Sheet.

2. Добавим интерактивное закрытие, учитывая контент, который скроллится.

3. Поддержим UINavigationController с навигацией внутри Bottom Sheet.

Мы собираем зависимости для нашего тестового окружения в Docker-образ, что оказалось очень удобно. Но недавно у нас появился разработчик с MacBook M1, и резко встал вопрос о возможности поддержки двух платформ.

Недавно мы перешли с CocoaPods на другой менеджер зависимостей — Carthage. Оказалось, что у этой простой на первый взгляд задачи много подводных камней. 

Чтобы сменить менеджер зависимостей и не страдать нужны две вещи:

- заранее понимать, какая конечная цель у этой задачи,

- знать, какие подводные камни ожидают на пути.

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

Мы столкнулись с достаточно занятным поведением при работе с Headless-сервисом в Kubernetes. В нашем случае проблема возникла с mongos, но она актуальна для любого Headless-сервиса. Приглашаю вас почитать нашу историю и самим попробовать поиграться с этой проблемой локально.

На одном из проектов мы используем MongoDB и Kubernetes. У MongoDB есть компонент: mongos. Через него выполняются запросы в шардированном MongoDB кластере (можно считать, что это просто хитрый proxy). До переезда в Kubernetes сервисы mongos устанавливались непосредственно на каждый хост.

При переезде сервисов в Kubernetes мы поселили пул mongos в Headless-сервис с автоматическим масштабированием Deployment через HPA (Horizontal Pod Autoscaler).

Через некоторое время выяснилось, что приложению при уменьшении количества Pod с mongos становится не очень хорошо.