Привет, Хабр! Меня зовут Игнат, в Samokat.tech я пишу плагины, автоматизации и интеграции для Jira. 

Как разработчик-самоучка, который до «вот этого всего» немного писал на Java, но не пользовался ни средствами сборки (привет, Maven!), ни фреймворками (привет, Spring!), и первые шаги делал по мануалам Atlassian, я сталкивался (и продолжаю) с проблемами, решений которых вендорская документация не подскажет, и эти решения приходится открывать самому. 

В этой статье мы вместе с вами напишем свою Spring-аннотацию, которая будет с помощью кастомного бин-постпроцессора (который мы тоже напишем) отключать в нашем плагине для Jira ненужный в проде отладочный функционал.

Эта статья ориентирована на начинающих разработчиков в стеке Atlassian и администраторов, пробующих себя в разработке плагинов для Jira. Те, кто до знакомства с Atlassian SDK уже разрабатывал «под ентерпрайз», не обязательно найдут здесь что-то новое, остальных – приглашаю под кат.

Привет, я Даша, занимаюсь iOS‑разработкой в Сравни. Мы в мобильной команде пользуемся SnapKit — помогает нам ревьюить изменения в общих компонентах быстрее и проще. Инструмент прекрасный, но я заметила тенденцию: стоит в работе появиться сложным вариантам вёрстки, как сразу в разы растёт вероятность, что UI может выглядеть ок, а в консоли будет отображаться множество ошибок LayoutConstraints, логи засоряются, найти действительно полезную информацию становится сложнее.

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

Привет, я Данильян, работаю в Самокате фронтенд-разработчиком, разрабатываю бэкофисное приложение с использованием React. Когда я только начинал изучать Jetpack Сompose, я наткнулся на статью, в которой простым языком для людей, пришедших из мира веб-технологий в мир мобильной разработки, расписано, как писать код для мобильных устройств, чтобы было как в React. Из материала в статье особенно подкупали примеры: вот, что вы делали в React, а вот, как в Jetpack Compose получить то же самое. 

Делюсь с вами переводом этой статьи.

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

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

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

В крупных организациях разработчики должны кому-то отчитываться, а люди, которым они отчитываются, по определению становятся тимлидами. В идеальном мире тимлид — это универсальный «сержант»: и задачи раскидает, и код напишет, и команде поможет — подхватит, когда ресурсов не хватает. Конечно, желательно, чтобы они когда-то как-то участвовали в разработке ПО, но это в идеальном мире, а в реальном иногда бывает совсем не так. В реальном мире бывают тимлиды, которые совсем не помогают команде, а иногда даже вредят. Давайте об этом и поговорим — о проблемных личностях среди тимлидов.

Привет! Меня зовут Григорий, я техлид в Cloud Infrastructure Team в Сравни. Моя команда отвечает за observability системы и облачную инфраструктуру. Не так давно мы полностью обновили наш стек мониторинга. Хочу рассказать, как у нас организовано хранение long-term метрик без использования Object Storage.

Мы в Сравни долгое время использовали связку Prometheus + Thanos для мониторинга и хранения данных. Для Thanos мы использовали схему с sidecar’ом. Эта схема работала довольно неплохо, но с ростом проекта — росло и потребление ресурсов. Со временем задачи по scrape samples уже потребляли значительные ресурсы. Когда только на Prometheus стало уходить больше 30 ядер vCPU и 100 гигабайт RAM, мы начали искать способы оптимизации потребления ресурсов. 

Первым делом определили требования, которые необходимы для системы мониторинга:
- должно поддерживаться развертывание в Kubernetes;
- система должна быть способна переезжать из одного Kubernetes-кластера в другой без потери данных;
- нужна поддержка downsampling;
- возможность построить high availability систему;
- в идеале, чтобы система требовала очень мало внимания на обслуживание ;)

Мы поизучали варианты, и сперва показалось, что будет хорошей идеей взять стек VMAgent + Thanos receiver. Как несложно угадать из названия статьи, этого у нас не получилось. Недавно я увидел в одном профессиональном чате, что коллеги захотели использовать такой же стек и по тем же причинам, что и мы. Поэтому решил поделиться нашим опытом и рассказать, к чему мы в итоге пришли.

Уже подтвердили своё участие:

Что не так с тестированием вёрстки