backend developer
Chief Technical Officer — представитель топ-менеджмента компании (помимо английской аббревиатуры, можно встретить название «технический директор»), который определяет технологическую стратегию компании и отвечает за внедрение новых технологий — все ради достижения финансовых и стратегических целей бизнеса.
Одной из ключевых точек контакта компании с клиентами является техподдержка, которая позволяет оперативно решать вопросы и отрабатывать обратную связь. Но клиенты, которые хотят консультацию и информацию по конкретному вопросу, часто создают нагрузку, которую небольшие отделы поддержки обработать не могут. В итоге бизнесу нужно либо расширять штат, либо автоматизировать часть процессов. В этом помогают чат-боты и нейросети.
Меня зовут Александр Волынский. Я технический менеджер продукта в подразделении Applied ML. В этой статье я хочу рассказать об LLM и RAG, вариантах их использования на примере нашего бота для поддержки клиентов, а также о сценариях применения полученной реализации.
Привет, Хабр, это моя первая статья. Меня зовут Константин, я системный инженер в компании ГНИВЦ. Здесь я хотел бы вам рассказать, что такое Envoy и как с его помощью можно упростить жизнь разработчикам и повысить надёжность взаимодействия микросервисов, минуя инфраструктуру для кого-то страшного и непонятного Kubernetes, а используя простой и старомодный Docker. Также эта статья поможет познакомиться с Envoy поближе и узнать, как он шагает в ногу с таким проектом как Istio.
Привет! Меня зовут Вадим Клеба, я руковожу командой бэкенд-разработки в Телемосте. Последние девять лет я разрабатываю высоконагруженные распределённые системы. Раньше я разрабатывал search-as-a-service-решение с эффективным полнотекстовым поиском с учётом релевантности.
В статье расскажу, как в Яндекс 360 строили API в течение десяти лет без дропа обратной совместимости, выдерживающий сейчас сотни тысяч RPS. Вы узнаете, какие подходы мы изначально закладывали, чтобы наш API прожил так долго.
В этой статье делюсь подборкой из 14 лучших email-рассылок по бэкенду, фронтенду, ИИ на русском и английском языках.
В последнее время подсел на рассылки для экономии времени: вместо того, чтобы следить за более чем 20 телеграм-каналами по интересующей меня тематике, я получаю письма c тщательно отобранной информацией всего 1-3 раза в неделю.
В русскоязычном сегменте оказалось не так просто найти качественные рассылки. Мне удалось обнаружить всего несколько стоящих вариантов с помощью поиска. Если у вас есть рекомендации по интересным и полезным рассылкам, особенно в области бэкенда, фронтенда и искусственного интеллекта, поделитесь ссылками в комментариях, добавлю в статью.
Привет! Меня зовут Артём Коньков, я тимлид команды продуктовой разработки в Купере. У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные.
Дисклеймер: понимаю, что тема холиварная, и с точки зрения строгой методологии нужно выбрать между оценкой по времени или по сторипоинтам и не пытаться поженить одно с другим. У нас в компании допустимы разные варинты и я, как тимлид, очень рад, что такие решения даются на откуп юнитов и отдельных команд — можно настроить процессы под свою команду и свои задачи.
Здесь хочу поделиться своей логикой и тем, как искал аргументы, чтобы реализовать свой эксперимент. Любые менния по теме приветствую в комментариях.
Привет, друзья! Разговоры у вечернего костра, у палатки, у реки, в спокойный, тихий вечер и в располагающей к технической честности и объективности атмосфере, а не «у пепелища дата-центра», как некоторым может показаться! 😊 Приготовьтесь погрузиться в захватывающую историю, как, но, важнее, почему мы сознательно пришли к активному использованию контейнеров и «доросли» до внедрения Kubernetes в высоконагруженном проекте «BI-конструктор». Но про Kubernetes в посте не будет не слова, будет только про контейнеры, но мы подготовим мозг к следующему посту, уже исключительно про Kubernetes, но тоже максимально доступно. Однако, я буду все рассказывать очень простыми (иногда техническими) словами, без ныряния в многоуровневый мат, уж простите. Я убежден, что когда ты все прочувствовал и выстрадал умом и сердцем, то сможешь этот опыт передать доступно и понятно другим, а когда сам не понимаешь, о чем говоришь, то и остальных просто запутаешь. И еще один момент – технических картинок и графиков по теме тоже не будет, они вызывают головную боль от растекания абстракций и их легко найти самостоятельно и в конце я дам рецепт где. Но, даже без них, не сомневайтесь, вы все поймете с первого раза. Итак, наливайте кофе, насыпайте попкорн, кладите в карман таблетку от головной боли (иногда будет сложно, но ради вашего же блага) и ныряйте «под кат».
Привет! Я Максим Коровенков, DevSecOps Lead в Купере (ex СберМаркет). Хочу поделиться мыслями по поводу минимально необходимого набора процессов, сопутствующих внедрению сканеров безопасности в пайплайны разработки.
В результате попытаюсь ответить на вопрос: «А что, собственно, стоит иметь в виду под фразой “Мы внедрили сканеры безопасности в пайплайны разработки”?»
Да, в тысячный раз про пайплайны, но, как вы, думаю, догадываетесь, желание поделиться казалось бы очевидными мыслями появилось не случайно! Не так давно я завершил найм и укомплектовал свою DevSecOps-команду. В рамках поиска пришлось провести достаточное количество интервью, на которых я любопытствовал, как обстоят дела у соискателей с пайплайнами безопасности на текущем/предыдущем месте работы. Это удивительно, но для 90% респондентов фраза «внедрение сканеров безопасности в пайплайны» означает только факт внедрения. Лишь некоторые кандидаты упоминали отправку результатов в VMs/ASOC систему.
Ведь действительно кажется, что все просто: запаслись вокабуляром из нескольких аббревиатур, внедрили инструменты, SAST, SCA, может что-то еще, настроили отправку результатов для AppSec-ов и, как-будто, можно идти бить баклуши. Но я на своем опыте убедился, что DevSecOps — это про глубокую проработку процессов. Поэтому в данной статье сконцентрируюсь больше на процессах, нежели на технике.
Предлагаю наконец переходить к сути!
Салют, Хабр!
Apache Kafka - это распределенная платформа потоковой обработки, предназначенная для построения систем обработки данных. Kafka позволяет публиковать, подписываться, хранить и обрабатывать потоки данных в реальном времени. Все это дает нам очень высокую пропускную способность и масштабируемость.
Основные фигуры в кафке это продюсеры и консюмеры. Продюсеры — это компоненты, которые производят и отправляют данные в Kafka. Они могут быть чем угодно: от простых скриптов до сложных систем. Консюмеры — это те, кто подписывается на данные и обрабатывает их. Они могут быть реализованы в различных формах, например, для анализа данных или мониторинга.
В статье мы и поговорим именно про продюсерах и консюмерах в экосистеме Kafka в коннекте с Python.
Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработчиков. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.
Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon Profit. Изначально я собирал материал для приватной страницы онбординга руководителя в нашу команду, но получилось выделить общие моменты (убрать всю секретную информацию) и составить цельную картину того, с чем может столкнуться начинающий менеджер. Этим я и хочу поделиться с сообществом.
Материал статьи не претендует на объективность. Все упомянутые истории происходили в моей практике или в практике моих сотрудников, совпадения не случайны. Без лишних предисловий, начнём!
Цель данной статьи — простым языком объяснить ключевые технологии, необходимые для начала разработки приложений на основе LLM. Oна подойдёт как и разработчикам, так и специалистам по машинному обучению, у которых есть базовое понимание концепций и желание заглянуть поглубже. Также я прикрепил множество полезных ссылок для дальнейшего изучения. Давайте начинать!
Приветствую всех! Цель данной статьи - рассказать реальные проблемы с которыми сталкивается команда при создании нового продукта и её лидер в большом финтехе и да, не просто с чьих то слов, а прочувствовав всё на собственной шкуре. В прошлом году я взял достаточно большой и серьезный проект, который вывел до прода.
Привет! Меня зовут Михаил Боровиков, я тимлид команды, которая отвечает за систему процессинга заказов Lamoda — Orders Management. Эта система, словно «сердце» Lamoda, через которое проходит самый важный для бизнеса шаг — оформление заказа.
Раньше система представляла из себя монолит. Теперь вместо него у нас много отдельных сервисов, которые общаются по сети. В рамках новой схемы взаимодействия сервисов между собой мы и столкнулись с проблемой потери данных в процессе создания заказа, чего допускать в важной для нас системе было категорически нельзя.
Для решения этой проблемы мы выбрали паттерн Outbox. И в этой статье я расскажу, что он из себя представляет, как мы его применили, почему пошли по пути at-least-once и не положились на работу одного брокера сообщений.
Разработчики, которые используют Go, сталкиваются с задачей выжать максимальную производительность из каждой строки кода. Но что делать, если оптимизировать уже нечего, а увеличивать скорость всё равно надо?
Меня зовут Никита Галушко. Я старший программист-разработчик в отделе высоконагруженных систем и оптимизации ВКонтакте. В статье поделюсь, какие хитрости помогут использовать Go на полную мощность.
Доброго времени суток! Сегодня я продемонстрирую вам, как быстро и эффективно настроить PostgreSQL с помощью Docker Compose. Этот процесс займет всего несколько минут, но в результате вы получите полноценную базу данных PostgreSQL, работающую в изолированном Docker контейнере. Важные компоненты, такие как базы данных, таблицы и индексы, будут сохранены на вашей локальной машине благодаря использованию томов (volumes), что обеспечит надежность и доступность данных.
Привет, Хабр!
Мы — команда Рег.ру, направление облачных сервисов, — однажды решили создать сервис управляемых баз данных, он же DBaaS. Раскрываем технические аспекты DBaaS: на каких технологиях основана услуга, какие инструменты использованы, с какими трудностями мы столкнулись при создании и запуске в продакшн. Будет интересно!
История началась с разбора использования ресурсов приложением, которое занимается проксированием. Обнаружили, что довольно много времени оно тратит на выбор маршрута (роута), и решили ускорить этот процесс. Описанная в статье оптимизация не требует каких-то особых вложений, усилий или условий, поэтому приведенный код можно забрать к себе и использовать без каких-либо чрезмерных вмешательств.
Статей на тему что такое git и как им пользоваться на просторах интернета не мало. Я же хочу предложить вам несколько иной взгляд на привычные вещи, а именно, на оформление веток и коммитов, рассмотреть что такое WIP-коммиты, для чего они нужны и как с помощью них можно повысить свою продуктивность и поддерживать чистоту в истории вашего репозитория, в особенности, если вы работаете в команде. Поехали.
Привет, Хабр! Я Владимир Хаймин, эксперт по системам управления базами данных PostgreSQL в ВТБ. В последнее время одним из наиболее распространенных способов миграции стала миграция при помощи свободного инструмента ora2pg. Однако многие отмечают его крайне низкую производительность, особенно если речь идет о базах Oracle размером под 1Тб и выше. Как ускорить миграцию и сократить время простоя при переносе проектов при помощи только oracle_fdw, либо в сочетании с ora2pg расскажу далее.
