Привет, Хабр! Я техлид в компании ДомКлик. В основном занимаюсь backend-разработкой. Мне периодически приходится погружаться и во front-разработку, но этого не происходило уже более двух лет. Сегодня я расскажу, как мне пришлось заняться front-разработкой для создания плагина для Bitbucket, с какими сложностями я столкнулся и как их решал. Также поделюсь результатом своей работы: надеюсь, он окажется полезен кому-нибудь ещё. Эта статья не является руководством по написанию плагинов для продуктов Atlassian и не описывает всех возможностей системы плагинов.

На вопросы отвечал Павел Зыков, СТО DomClick.ru

ДомКлику скоро 5 лет. Давайте немного вспомним историю и заодно познакомимся. Компания была основана в 2015 году. Ты помнишь день, с которого все начиналось?

Еще как помню. Я входил в число основателей, поэтому помню все в мельчайших деталях – как собеседовали первых людей, как в августе 2015 года сняли первый офис на улице Рабочая, который устраивал нас по цене, несмотря на то, что подоконники кабинетов всегда были в пыли от проходящих рядом поездов. Сейчас, сидя в максимально комфортном Agile Home в 2 минутах от ст. метро Кутузовская, с теплотой вспоминаем о тех временах, когда два интернет — провайдера в здании считалось нашим уникальным преимуществом.

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


Меня зовут Виктор Ягофаров, я занимаюсь развитием Kubernetes-облака в компании ДомКлик, и сегодня хочу рассказать о том как мы решили проблему с одним из ключевых компонентов нашего production k8s (Kubernetes) кластера.

В нашем боевом кластере (на момент написания статьи):

• запущено 1890 pod'ов и 577 сервисов (количество реальных микросервисов тоже в районе этой цифры)
• Ingress-контроллеры обслуживают около 6k RPS и примерно столько же идёт мимо Ingress сразу в hostPort.

Компания ДомКлик существует с 2015 года, и за это время мы успели сменить целевой язык для разработки ключевых сервисов с Java на Kotlin.

Меня зовут Александр Коцюруба, руковожу разработкой внутренних сервисов в компании ДомКлик. Отвечая на вопрос, почему мы перешли на Kotlin, я опубликую два материала:

1. Первая часть будет посвящена ретроспективе возникновения языка (которую вы, собственно, и будете сейчас читать)
2. Вторая часть будет ориентирована на практически примеры (которая выйдет позже)

Итак, начнем.

Если ты стал руководителем в IT, то у тебя большие проблемы – достаточно сложно найти описанные модели организации производства и набора KPI's для CTO и CIO. Задача любого управленца любой отрасли – следить за конкурентами, «state of the art»- примерами и приносить лучшие практики в свою компанию. По своему опыту скажу, что тебе придется завести круг общения и делиться с другими СТО примерами в барах, на встречах, референс-визитах, конференциях.



На Хабре контента про модели управления и метрики мне найти не удалось, а его реально не хватает, поэтому решил поделиться своим опытом.

Микросервисная архитектура, как и все в этом мире, имеет свои плюсы и свои минусы. Одни процессы с ней становятся проще, другие — сложнее. И в угоду скорости изменений и лучшей масштабируемости нужно приносить свои жертвы. Одна из них — усложнение аналитики. Если в монолите всю оперативную аналитику можно свести к SQL запросам к аналитической реплике, то в мультисервисной архитектуре у каждого сервиса своя база и, кажется, что одним запросом не обойтись (а может обойтись?). Для тех, кому интересно, как мы решили проблему оперативной аналитики у себя в компании и как научились жить с этим решением — welcome.


Меня зовут Павел Сиваш, в ДомКлике я работаю в команде, которая отвечает за сопровождение аналитического хранилища данных. Условно нашу деятельность можно отнести к дата инженерии, но, на самом деле, спектр задач гораздо шире. Есть стандартные для дата инженерии ETL/ELT, поддержка и адаптация инструментов для анализа данных и разработка своих инструментов. В частности, для оперативной отчетности мы решили «притвориться», что у нас монолит и дать аналитикам одну базу, в которой будут все необходимые им данные.

Продолжаем цикл статей о внедрении языка Котлин в наш процесс разработки. Первую часть ищите здесь.

В 2017 году увидел свет амбициозный проект от компании Jetbrains, предлагающий новый взгляд на кросс-платформенную разработку. Компиляция кода на kotlin в нативный код различных платформ! Мы же в Домклике в свою очередь всегда ищем способы для оптимизации процесса разработки. Что может быть лучше переиспользования кода, подумали мы? Правильно — не писать код вообще. И чтобы всё работало так, как хочется. Но пока так не бывает. И если есть решение, которое позволило бы нам, не затрачивая слишком больших усилий, использовать единую кодовую базу для разных платформ, почему бы не попробовать?

Итак, всем привет! Меня зовут Геннадий Васильков, я андроид разработчик в компании Домклик и сегодня я хочу поделиться с вами нашим опытом разработки на Kotlin Multiplatform для мобильных устройств, рассказать с какими трудностями мы столкнулись, как решали и к чему в итоге пришли. Тема наверняка будет интересна тем, кто хочет попробовать Kotlin MPP (Multiplatform projects), либо уже попробовал, но не довёл до продакшена. Либо довёл, но не так как хотелось бы. Я попробую донести наше видение того, как должен быть устроен процесс разработки и доставки разработанных библиотек (на примере одной из них расскажу начало нашего пути становления в Kotlin MPP).

Желаете историй как у нас всё получилось? Их есть у нас!

Меня зовут Алексей Казаков, я техлид команды Клиентских коммуникаций в ДомКлике. В этой статье я хочу поделиться с вами «рецептом», который позволил нам реализовать отложенные ретраи при использовании брокера сообщений RabbitMQ

Меня зовут Александр Коцюруба, я руковожу разработкой внутренних сервисов в компании ДомКлик. Многим разработчикам, пишущим на Java, с опытом приходит понимание внутреннего устройства JVM. Чтобы облегчить этот путь Java-самурая, я решил простым языком изложить основы виртуальной машины Java (JVM) и работы с байткодом.

Что такое таинственный байткод и где он обитает?

Постараюсь ответить на этот вопрос на примере приготовления солений.

В данной HOWTO мы исправим баг в древней версии nginx ingress controller v0.20.0 и научимся работать с зависимостями Go старых версий через dep + vendor.

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

Примерно 1-1,5 года назад Spring Webflux был на хайпе. Практически на любой Java-конференции можно было встретить доклады по Webflux, реактивному программированию, где-то даже проскакивали доклады про RSocket. Выступлений было много, сообщество маленькое, работающих проектов еще меньше. Возможно, тому виной была достаточно сырая технология в мире Spring и отсутствие поддержки со стороны многих модулей экосистемы, но мы рискнули.

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

Анализ и обработка данных — одно из ключевых направлений любой современной компании. У нас в ДомКлике оно существует с 2016 года, когда был нанят первый data scient’ист. С тех пор утекло много воды, менялись задачи и приоритеты, мы развивались. Сегодня у нас в этой области работает около 40 специалистов. Одна половина разрабатывает модели машинного обучения, а другая — поддерживает контур данных: создает хранилище, проверяет качество и так далее.

Казалось бы — что сложного — организовать работу нескольких команд? Есть данные, есть специалисты по их обработке, по идее на выходе должен быть Profit? Однако, как показывает наш опыт, простая мысль «хорошо делать — хорошо, а плохо делать — плохо» работает как минимум не всегда. Нужно искать ответы на множество вопросов — как встраивать Data Science команды в уже сформировавшуюся организацию, как обеспечить высокое качество и скорость разработки моделей, как эффективно наполнять бэклог новыми задачами — все это вопросы, на которые мы искали ответы.

Меня зовут Алексей Кузьмин, я руковожу направлением Data Science и работы с данными в ДомКлике. И в этой статье я расскажу о том, как мы решаем эти проблемы и как поддерживаем работу такого большого коллектива.

Всем привет, меня зовут Олег, я техлид в ДомКлике. В нашей команде ядром стека является Kotlin и Spring Boot. Хочу поделиться с вами своим опытом по взаимодействию и особенностях работы с PostgreSQL и Hibernate в связке со Spring Boot и Kotlin. Также на примере микросервиса, покажу преимущества Kotlin и его отличия от аналогичного приложения на Java. Расскажу о не совсем очевидных сложностях, с которыми могут столкнуться новички при использовании этого стека с Hibernate. Статья будет полезна разработчикам, желающим перейти на Kotlin и знакомых со Spring Boot, Hibernate Java.

В языках программирования меня всегда интересовало их внутреннее устройство. Как работает тот или иной оператор? Почему лучше писать так, а не иначе? Подобные вопросы не всегда помогают решить задачу «здесь и сейчас», но в долгосрочной перспективе формируют общую картину языка программирования. Сегодня я хочу поделиться результатом одного из таких погружений и ответить на вопрос, что происходит при модификации tuple'а в list'е.

В этой статье я поделюсь своим опытом настройки CI/CD с использованием панели управления Plesk и Github Actions. Сегодня будем учиться деплоить простенький проект с незамысловатым названием «Helloworld». Он написан на Python-фреймворке Flask, с воркерами на Celery и фронтендом на Angular 8.

Ссылки на репозитории: бэкенд, фронтенд.

В первой части статьи мы посмотрим на наш проект и его части. Во второй — разберемся, как настроить Plesk и установить необходимые расширения и компоненты (БД, RabbitMQ, Redis, Docker и т.д.).

В третьей части мы, наконец, разберемся, как настроить пайплайн для деплоя нашего проекта на сервер в dev- и prod-среду. А потом запустим сайт на сервере.

И да, забыл представиться. Меня зовут Олег Борзов, я техлид в команде CRM для менеджеров ипотечного кредитования в Домклик.

Меня зовут Игорь Сидоренко, я техлид в команде админов, поддерживающих в рабочем состоянии всю инфраструктуру Домклик.

Хочу поделиться своим опытом в настройке распределённого хранения данных в Elasticsearch. Мы рассмотрим, какие настройки на нодах отвечают за распределение шардов, как устроен и работает ILM.

Кейси Розенталь (Casey Rosenthal), CEO и сооснователь Verica.io, выступил на митапе Test in Production. Кейси развенчал некоторые мифы о надёжности и объяснил, что многие интуитивные действия по увеличению надёжности систем на самом деле контрпродуктивны. Более того, он объяснил, как концепция непрерывной проверки (Continuous Verification) помогает разработчикам избегать таких подводных камней.

Полное выступление Кейси:

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

За последние пару месяцев около трети работающего населения России получили первый опыт работы на «удаленке», в процессе адаптации к которой многим открылась совершенно новая реальность, которая оказалось существенно глубже и противоречивей, чем существовавшие до этого представления о ней.

С самого начала своего пути как разработчика программного обеспечения я очень любил копаться во внутренностях языков программирования. Мне всегда было интересно, как устроена та или иная конструкция, как работает та или иная команда, что под капотом у синтаксического сахара и т.п. Недавно мне на глаза попалась интересная статья с примерами того, как не всегда очевидно работают mutable- и immutable-объекты в Python. На мой взгляд, ключевое — это то, как меняется поведение кода в зависимости от используемого типа данных, при сохранении идентичной семантики и используемых языковых конструкциях. Это отличный пример того, что думать надо не только при написании, но и при использовании. Предлагаю всем желающим ознакомиться с переводом.



Попробуйте решить эти три задачи, а потом сверьтесь с ответами в конце статьи.

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