Привет, хабр! Меня зовут Алексей и я системный инженер в компании Constanta, мы с командой занимаемся практиками DevOps, развиваем процессы ci/cd и мониторинга.

Представьте, что у вас есть 10 серверов и 20 микросервисов на них, а релизы проходят каждую неделю. Вы уже мониторите жизнеспособность сервисов и докера с помощью zabbix или prometheus, а с помощью ELK или grailog собираете логи. Кажется, что хорошо, но в таком потоке релизов, хотфиксов и строчек кода нужно быстро ориентироваться в ошибках внутри приложения, которые не влияют на жизнеспособность сервиса, но мешают его правильной работе.

Стоп! Есть же Sentry, скажете вы. И будете правы. Он удобен, хорошо описан, есть документация, комьюнити и поддержка. Однако, есть одно "но".

Привет! Меня зовут Катя. Я — менеджер проектов в компании Constanta и сегодня хочу с вами поделиться, как важно выстраивать новые процессы постепенно, не разрушая их до основания.

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

Я отвечаю за мобильные платформы одной из крупнейших букмекерских компаний в России, а именно за мобильные приложения — iOS (iPhone, iPad, Apple Watch), Android (смартфоны и планшеты) — и мобильный сайт. А также еще за пару дополнительных приложений, косвенно относящихся к основному продукту.

Привет!

Меня зовут Ксюша, мне 29 лет и я продуктовый дизайнер в Константе.

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

Всем привет! Меня зовут Алиса, я — ведущий тестировщик в компании Constanta, и сегодня расскажу вам о простых QA метриках, помогающих отслеживать качество продукта.

Если мы вобьем в поисковой строке незамысловатое словосочетание “метрики QA”, то увидим, что почти все ссылки ведут на классические метрики: процент покрытия требований кейсами, коэффициент регрессии, скорость работы QA команды и т. д. Если вы их не видели — то можете легко найти. Большинство из них полезны, и некоторые будут использованы в статье, но немного в другом формате. Подобные метрики обычно выглядят как n/m, где n и m — количество какого-либо параметра. Например: количество переоткрытых дефектов, общее количество дефектов и время исправления найденных дефектов. Я же хочу рассказать о чуть более аналитической работе: мы будем смотреть не только сухие цифры, но и делать выводы о том, откуда эти цифры взялись. Ближе к концу статьи я поделюсь некоторыми идеями о том, как решать возникшие проблемы.

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

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

Спойлер: в итоге стажировка была организована силами 2 HR и 3 человек из команды разработки. Помимо оплаты нашего времени и выплат стажерам, не было потрачено ни рубля дополнительно.

Всем привет, меня зовут Алексей, и я отвечаю за разработку android-приложений в Константе. У нас в компании есть несколько проектов с большим набором функций, часть из которых присутствует во всех (или, по крайней мере, во многих) разделах интерфейса приложения. Речь идет об авторизации (регистрация + вход), добавлении товаров в корзину, информации о балансе пользователя, уведомлениях о новых входящих сообщениях или т.д.

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

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

Заходит как-то тестировщик в бар, а бармена нет — он на курсах «Как стать тестировщиком программного обеспечения».

Всем привет! Меня зовут Алиса, я — ведущий тестировщик в компании Constanta, и сегодня расскажу вам, как мы нанимаем QA на наши проекты.

Наверняка многие из вас видели пестрящую везде рекламу разнообразных курсов на тему «Как войти в IT»: от «Получи самую востребованную работу сегодня» до «QA – профессия будущего». Однако, несмотря на такой ажиотаж вокруг этих загадочных букв «QA», найти хорошего quality assurance инженера все еще тяжело — даже если вы ищете людей с небольшим опытом. Почему так? Давайте разбираться.

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

Перед вами продолжение статьи про рендеринг. В первой части, которую вы, кстати, можете найти по ссылке (link), мы поговорили о трассировке лучей и маршевом методе, а в этой части мы с вами получим фотографию мыльного пузыря. Будет интересно :)

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

Как-то раз я сидел в баре с давним приятелем, с которым раньше мне довелось поработать на поза-поза-позапрошлой работе. Он из сомневающихся по поводу перехода на Go, ярый приверженец своего нынешнего языка. Хочу сказать, что он делает действительно классные вещи, пишет безупречный код, у него есть, чему поучиться. Но к Go у него отношение не слишком позитивное. Как он сказал: “Go — это *****код (плохой код)”. И в качестве одного из аргументов привел то, насколько, по его мнению, криво в Go реализована обработка ошибок. В чем-то он прав — в моем текущем не самом большом проекте на Go конструкция “if err != nil” встречается 1132 раза.

Этот мой приятель, не побоюсь этого слова — адепт DDD (domain driven design). Все, что не относится к DDD, — это, по его мнению, антипаттерн, ад и хаос. Когда я ему рассказал, что у меня есть довольно успешный опыт проектирования по DDD в Go-проектах, он округлил глаза. Да, ответил я, с определенной серией оговорок и компромиссов это работает, и неплохо.

В этой статье мы поговорим о том, как наша команда перешла на Kotlin DSL для описания Gradle файлов, и как в итоге мы получили типы сборок, описанные классами и имеющие общий интерфейс.