Всем привет! Меня зовут Алексей Леонтьев, я старший разработчик и системный архитектор в компании KTS.

Мониторинг проекта — это комплексная задача. В неё входит не только передача метрик, но и сбор логов, трейсов, health-чеки, правила для алертов и система их доставки до ответственных разработчиков.

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

Я не буду оригинален, если скажу, что сотрудники работают так, как ими управляют. Есть множество причин, почему сотрудники не могут делать то, что хочет от них руководитель, но сегодня я хочу поговорить о самой банальной и распространенной причине: сотруднику дали задание, которое он не умеет делать.

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

Давайте честно признаем: наша способность добросовестно концентрироваться на делах давно вышла из чата. Когнитивные проблемы нашего времени — это быстрая потеря интереса ко всему (что не позволяет нам глубоко и приятно-долго исследовать новое), а также стресс, выгорание, тревожность, вечная усталость, отсутствие концентрации, brain fog и так далее. Информационный фон выжигает нашу нервную систему настолько, что нас буквально тошнит от любого рода познавательной деятельности — мы испытываем отравление новизной.

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

Фишка в том, что даже если бы такой мануал был, он бы нас не спас. Не понимая сути источника проблемы, ни один человек (а он все же смыслосодержащий механизм, а не робот) не будет ему долго и упорно следовать. Как рассказывал David Horsager на Тэде, устойчивая мотивация держится на полной ясности смысла деятельности для конкретного человека.

Вам, конечно, может показаться, что я зря смешиваю потерю интереса к деятельности и стресс — ведь они, кажется, на разных краях стола. Но я проблему вижу так: находясь в вечном стрессе, мы жадно хватаемся за то, что дарит нам положительные эмоции. Пребывая в привычном блэкауте с черными кругами под глазами, мы встречаем человечка, да каааак начинаем им интересоваться и увлекаться, да так упорно, хватаясь за него как за спасительную соломинку, что… через какое-то время перегораем. Как говорят американцы, balls deep. Работает не только с человечками — по такой же гнусной схеме мы обычно набрасываемся на все, что нам внезапно понравилось, особенно на фоне рутинной серости, субъективного однообразия, всемирного сумасшествия и всей этой хтони. Мы постоянно бегаем по этому убивающему нас циклу — набрасываясь на то, что нас вроде как драйвит, быстро выжирая это без остатка, теряя интерес и снова погружаясь в плаванье в этом супе из кортизола.

Всем привет! Я QA Engineer и недавно открыл для себя ChatGPT и хочу открыть этот мир другим тестировщикам. Эта статья не руководство к применению и каких-то суперлайфхаков здесь не будет. Цель этой статьи в том, чтобы показать огромные возможности нейросетей в помощи нам, тестировщикам, в работе. Надеюсь что кто-то, прочитав это, хоть немного сможет облегчить себе составление тест-кейсов, написание документации или написание автотестов. Примеров с написанием кода здесь по минимуму, так как таких материалов уже много.

О Rust я слышал ещё несколько лет назад и все его либо хвалили, либо порицали, по различным причинам, но сам как-то не брался за него - мне, неподготовленному к подобному синтаксису и не знакомому с подобными языками хотя бы на базовом уровне, в то время он казался совершенно непонятным.

Не так давно решил написать для себя небольшое приложение-бенчмарк для теста HTTP API серверов и написал его на Go. Но размер в 5 с лишним Мбайт, несоблюдение целевого RPS и некоторые другие проблемы заставили посмотреть в сторону более производительного Rust + Tokio + Hyper.

Эта статья о коде Rust-приложения, переходе с Go на Rust, преимуществах и недостатках обоих языков и сравнении двух сферических коней в вакууме.

Эта статья пригодится тем, кто не имеет хоть какой‑то системы по управлению делами, но которому она нужна, так как, например, стало тяжело справляться лишь только за счёт своей памяти или каких‑то мелких чек‑листов на обрывках салфеток. Статья предполагает, что вы будете читать и делать всё в ней написанное. Иначе говоря, статья является практически пошаговой инструкцией, т. е. в ней не будет каких‑то уж совсем незаурядных методов или взглядов.

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

Будет нелишним, если вы прочитаете мою прошлую статью про основные принципы систем, которые помогают достигать поставленных целей.

Всем привет! Хочу поделиться вариантом организации динамических окружений для разработки и тестирования с помощью ArgoCD и применением GitOps подхода на реальном примере.

Статья рассчитана на DevOps инженеров и разработчиков уже хорошо знакомых с инструментами из DevOps стека.

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

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

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

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

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

Привет, я Сергей Баранов, и с недавнего времени я Technical Unit Leader в Авито, проще говоря — тимлид тимлидов. Когда‑то я начинал как обычный разработчик, а потом стал лидером маленькой команды из четырёх человек. Сейчас в моем юните четыре команды. В этой статье я расскажу, как изменился мой образ мышления в новой должности.

Привет! Меня зовут Олег Мифле. В Skyeng работаю над проектом Skypro. В IT я уже больше десяти лет, семь из которых пишу на PHP. За плечами десятки разных проектов: e-commerce, финтех, CRM, а недавно добавился и EdTech. Были и классические фуллстек-проекты, и проекты, где фронтенд и бэкенд «живут» отдельно и коммуницируют друг с другом по API. Боль от отсутствия версионирования я испытал на себе. Хочу поделиться, как избежать проблем, как всё структурировать и организовать.

Обсудим:

• Что такое API.

• Зачем версионировать API и нужно ли вообще.

• Какие способы версионирования существуют и как его организовать — и с точки зрения подходов, и с точки зрения кода.

• Разберёмся, когда избавляться от старой версии или как жить с легаси до конца существования проекта.

Слышали фразу “алгоритмы тиктока”? “Лента рекомендаций”? А “вам может быть интересно”?

Интернет нас объединил как не смогло объединить ничто до него в истории и разъединил так успешно, что мы этого и не замечаем, а лишь изредка удивляемся случайно зайдя не на “свой сегмент” - “и такие люди существуют…”.

Мир цифрового контента и его потребления - относительно новый феномен и ключевую роль в формировании его таким, какой он есть сейчас играет идея персонализации.

Всем привет, я Кирилл, frontend разработчик компании Usetech. Сегодня я бы хотел поговорить о том, как можно улучшить производительность сайта с помощью обычных CSS свойств и на что стоит обращать внимание. Но прежде чем приступим к улучшению производительности сайта, давайте поговорим о том, какие проблемы возникают с CSS:

Всем привет! Я Павел, тимлид команды SLA, и занимаюсь оценкой надёжности Авито. В своей прошлой статье я рассказал про стратегии ветвления и Trunk Based Development. Если не читали, переходите по ссылке. А сейчас я хочу рассказать про фича-флаги, которые появляются именно в контексте TBD.

Всем привет! Меня зовут Полина, я руководитель отдела исследований в Landau Interactive. В рамках развития исследовательской культуры в компании передо мной стояла задача рассказать нашим проектным менеджерам, какие исследования могут помочь развить их продукт.

Хабр, привет. Меня зовут Рамиль Шайбаков, я фронтенд‑разработчик в СберЗдоровье. Последние несколько лет я часто собеседую кандидатов на позицию frontend‑разработчика в нашу компанию и заметил одну закономерность — у большинства специалистов нет опыта в тестировании. Причем знаниями о unit/интеграционных/e2e‑тестах, пирамиде тестирования, красно‑зелёном рефакторинге, TDD и BDD, скриншот‑тестировании и других техниках не могут похвастаться как новоиспеченные фронтенды, так и специалисты уровня Senior. Причины и аргументы у всех разные, но итог один — фронтенды часто не делают тесты.

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

Привет! На связи Олег Казаков из Spectr.  Мы занимаемся разработкой цифровых сервисов, в том числе высоконагруженных систем с микросервисной архитектурой и большим количеством различных интеграций.

В статье расскажу об одном из кейсов при работе над проектом с микросервисной архитектурой — реализации единой системы авторизации и аутентификации.  Поговорим про теорию, рассмотрим различные стратегии реализации и особое внимание уделим паттерну API Gateway.

Привет! Меня зовут Дима Вагин, я бэкенд-инженер в Авито. Сегодня расскажу, как мы работаем с БД PostgreSQL из Go. Покажу, какие библиотеки и пулеры соединений мы используем для доставки в код параметров подключения и как мы их настраиваем. А ещё расскажу про проблемы, к которым приводит отмена контекста, и о том, как мы с ними справляемся.

О необходимости выполнения резервного копирования для любых важных данных, будь то файлы, образ ОС или базы данных, написано множество статей. Поэтому убеждать читателя в необходимости бэкапить СУБД MySQL я не буду. Напомню лишь, что помимо бэкапа необходимо регулярно проверять резервные копии на возможность восстановления.

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