👨🏻‍💻🍆 / Лукашевич Егор

Теперь подробнее об моих определенных проектах 🎁 Один из них - сервис для подготовки к собеседованиям Причем он включает в себя не только QA трек, по которому я менторил раньше Но и Golang разработку и product management направления 🫵 Только нужная и качественная теория, мои персональные конспекты и материалы, без лишней воды Помимо теории будут практические задачи, причем не абстрактные, а те, которые реально могут встретиться вам в big tech компаниях По задачам будет ежедневный теоретический тренажер, а также интервью-тренажер с более сложными задачами и подачей приближенной к реальному собеседованию Почему я решил это сделать? Рынок становится жестче, менторы дороже, при том, что они далеко не всегда имеют достаточно экспертизы, в интернете переизбыток информации - это сильно усложняет самоподготовку. Поэтому я решил, что будет круто создать сервис, который позволит иметь в кармане готовую базу с материалами по интересующим направлениям с эффективной практической основой, которой можно пользоваться и дома и в дороге А главное - значительно дешевле, чем это обойдется у ментора или в какой-нибудь очередной «онлайн школе» Так что если вы собеседуетесь, ищете стажировку, хотите освежить знание перед grade-up’ом - вам это точно зайдет Так что, homies, ожидайте релиза MVP в ближайшее время

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

Channel photo updated

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

Я тут немного переформатировал концепцию своей деятельности, поэтому давно сюда ничего не постил Поэтому пока начну с того, что на днях намутил свое fitness tracking приложение В нем уже есть много полезного, а дальше будет больше Пользуйтесь, накидывайте фидбэк t.me/no_excuses_fitness_bot/NO_EXCUSES

Channel name was changed to «Лукашевич Егор | IT Dojo»

E-CODE 2025🚀 Запускаем отсчёт: 2...5...6... Открыли регистрацию на самое масштабное событие года от команды Ozon Tech! Выбрали особенные выходные для этого события: 13 и 14 сентября. Конференцию посвятим не только Дню программиста — покажем скорость, с которой наши инженеры развивают ведущий e-com страны в условиях сверхвысоких нагрузок на системы. Готовим программу вместе с ведущими экспертами индустрии. Не пропустите обновления, будем делиться подробностями в канале. Ждём ваших огоньков в реакциях и заявок на сайте!🔥

👨🏻‍💻🍆 / Лукашевич Егор pinned Deleted message

😇 Тестирование микросервисов ч. 1 Я работаю в компании, которая насчитывает тысячи микросервисов, которые, как атланты, стабильно держат огромный траффик и при этом показывают недюжинную устойчивость. Короче говоря — имеем дело с настоящим highload'ом. Все…

Кто такой этот ваш хайлоад и причем тут систем дизайн? Part 2. "Судьба шепчет воину: "Приближается буря". А воин шепчет в ответ: "Я и есть буря" 💪" Вот представим, что 🔥 highload 🔥 постучался в дверь нашего сервиса - что же нам делать? 💡 Наша цель - сохранить…

👨🏻‍💻🍆 / Лукашевич Егор pinned a photo

Вкратце - я Lead QA инженер, а мой блог — актуальный взгляд на тестирование со стороны современного QA и SDET в бигтехе. Здесь говорим про метрики, автотесты, системный дизайн, хайлоад, разработку, best practices и всё, что превращает джуна в сеньора. Прямо, по делу и без воды. Независимо от того, ты только начинаешь или уже давно в теме — присоединяйся. Я уверен - будет полезно. С чего можно начать: - Тестирование микросервисов. Part 1. - Мертво ли ручное тестирование? - Кто такой этот ваш хайлоад и причем тут систем дизайн? Part 1. - Кто такой этот ваш хайлоад и причем тут систем дизайн? Part 2.

В .NET 10 можно будет выполнить любой C# файл без создания файла проекта. Разработчики двигаются к упрощению запуска C# кода. Уже сейчас в Program.cs можно сразу же писать код без каких-то namespace или class, а в 10-ке можно будет даже не создавать проект, а просто выполнять любой файл. Удобно. Это приблизит .NET к скриптовым языкам. Сейчас никто не пишет скрипты на C#, потому что их нужно компилировать для выполнения и заморачиваться с файлами проектов. Новинки .NET 10: Добавление пакетов: #:package имя Для Linux поддерживается шабанг: #!/usr/bin/dotnet run С выходом 10-ки если нужно написать скрипт для получения из интернета чего-то, то просто пишем код в cs файл и не нужно никакой компиляции или проектов, а просто выполняем: dotnet run filename.cs Это почти то же самое что при выполнении Python: python3 filename.py Уау. Ну что, Питон напрягся? Думаю нет, пока ещё нет, но движение C# очень интересное. По крайней мере C# программистам теперь будет удобнее автоматизировать свою работу на C# и не изучать Python для автоматизации.

Кто такой этот ваш хайлоад и причем тут систем дизайн? Part 2. "Судьба шепчет воину: "Приближается буря". А воин шепчет в ответ: "Я и есть буря" 💪" Вот представим, что 🔥 highload 🔥 постучался в дверь нашего сервиса - что же нам делать? 💡 Наша цель - сохранить SLO, то есть уровень качества, который мы обязались исполнять перед пользователем. Для этого мы можем: 1. Найти причины 🔭 - Использовать трассировку - Улучшать систему логгирования - Пилить подробные дашборды с графиками и отслеживать ключевые метрики производительности 2. Масштабироваться 📇 Это мы можем делать как горизонтально, так и вертикально 3. Оптимизироваться 🧮 - Оптимизация кода и архитектуры сервиса - Оптимизация данных - Профилирование 4. Тестировать 🧮 - Проводить перформанс тестирование - Бенчмарки Начнем с метрик. 🎯 Какие ключевые метрики, за которыми нужно следить? ⛏ Производительность: - RPS (запросов в секунду). - Latency (время ответа, p95/p99). - Throughput (объем данных/транзакций в секунду). 🛡 Надежность: - Error rate (% 5xx-ответов). - Recovery time (время восстановления после сбоя). 📊 Ресурсы: - БД (блокировки (locks) и deadlock’и, I/O нагрузка, запросы) - CPU/RAM/IO утилизация. - Количество открытых соединений. Имея всю эту информацию на графиках, вы перестаете быть в слепой зоне и можете видеть полное состояние вашего сервиса. Можно настроить алерты на пороговые значения этих метрик и сразу получать уведомления об ухудшении стабильности сервиса, чтобы начать эскалацию проблемы и приступить к её решению как можно скорее. 🚀 В следующем посте мы вкратце поговорим о масштабировании и оптимизации, а затем плавно перетечем уже к теме тестирования. #testing #highload #microservices

👨🏻‍💻🍆 / Лукашевич Егор pinned «Кто такой этот ваш хайлоад и причем тут систем дизайн? Part 1. 🔥 Highload 🔥 - это про рост нагрузки на сервис/продукт. Но надо понимать, что нагрузка бывает разной: это могут быть и рост числа запросов, и проведение сложных операций и расчетов (утяжеление…»

Кто такой этот ваш хайлоад и причем тут систем дизайн? Part 1. 🔥 Highload 🔥 - это про рост нагрузки на сервис/продукт. Но надо понимать, что нагрузка бывает разной: это могут быть и рост числа запросов, и проведение сложных операций и расчетов (утяжеление запросов) и т.п. Рост нагрузки влечет соответствующие эффекты: - Уменьшение скорости обработки данных 📉 - Накопление очередей на обработку ⌨ - Ошибки 🖥 - Отказ в обслуживании 🚫 - etc. 👨‍💻Простой пример, откуда приходит хайлоад, на пальцах: Допустим есть секретарь, который заполняет документы И допустим каждый час ему приходит 1 документ - у него 60 минут на работу с этим документов Но допустим на него спустили дополнительную работу из-за большого потока клиентов И теперь к нему на стол кладут 10 документов каждый час - ему остается всего 6 минут на заполнение документа А что если ему будут приносить 50, 100 документов в час? Время на заполнение каждого из них будет уже менее одной минуты. Также работает и с приложениями и им как-то надо с этим справляться и при этом контролировать и обеспечивать качественный клиентский опыт 💪. SLO & SLI Service Level Indicator (SLI) – "термометр" сервиса 🌡 Это конкретная метрика, которая показывает, как работает ваш сервис. Например: - Сколько запросов в секунду обрабатывается без ошибок? - Как быстро грузятся страницы? - Сколько времени сервис доступен без сбоев? 🔹 Пример SLI: «95% запросов к API должны отвечать быстрее 200 мс». SLO (Service Level Objective) – "Цель" для сервиса 🏆 Это договорённость с пользователями, какой уровень качества вы гарантируете. SLO основаны на SLI. - допустимое время ответа от сервиса - объемы хранимых данных - возможное кол-во запросов к сервису в единицу времени 🔹 Пример SLO: «Наш сервис должен отвечать на 99% запросов быстрее 500 мс». Все это нужно учитывать при проектировании сервиса и при предоставлении доступа к нему. 🚀 В следующих постах мы разберем что делать, если высокие нагрузки нагрянули на ваш продукт, и рассмотрим это все через призму разработки и тестирования высоконагруженных сервисов.

Manual testing 👋 Скажу сразу - ручное тестирование никуда не денется. Но если смотреть трезво, то количество вакансий и уровень зарплат в сравнении с автоматизаторами заметно проседает 📉. Сфера развивается и закономерным этапом развития является усложнение…

Кстати TDD - это яркий пример Shift Left Testing 🤨 Что такое Shift Left Testing? Это подход в разработке, когда тестировать начинают как можно раньше, ещё до того, как код полностью написан. "Shift left" — значит «сдвиг влево» по временной линии разработки. Обычно тестирование начинается после написания кода (на «правом» краю), а здесь — наоборот, мы его «сдвигаем влево», то есть на более ранние этапы: проектирование, планирование, обсуждение требований. Простой пример: Обычный подход: - Разработчик пишет код. - Потом QA начинает тестировать. - Находятся баги. - Разработчик снова переписывает код. ➡️ Потери времени, дорогие исправления. Shift Left подход: - QA подключается ещё на этапе обсуждения требований. Он сразу задаёт неудобные вопросы: — «А если соединение с базой отвалится?» — «А как поведет себя под нагрузкой в 200 rps?» - Эти сценарии сразу закладываются в архитектуру и код. ➡️ Багов меньше, правки проще, разработка быстрее. 🤔 Ещё один пример из жизни: Представь, что ты строишь дом. Без Shift Left: Сначала строители построили всё, а потом пришёл инженер и говорит: «Ой, а тут у вас труба не туда выходит, нужно всё ломать и переделывать». С Shift Left: Инженер с самого начала участвовал в проекте и помог избежать ошибок до того, как что-то построили. ✈️ Примеры в реальной разработке: - Юнит-тесты или даже задел под интеграционные тесты пишется до или параллельно с кодом (TDD). - На этапе планирования фич QA уже присутствует и вносит своё мнение. - Делается ревью требований с точки зрения тестируемости. - Используются инструменты статического анализа кода ещё до запуска приложения. - Пишется BDD/Gherkin до реализации (тесты читаемые бизнесом). - Запускаются автотесты в CI сразу при каждом коммите. ✅ Польза: - Баги ловятся раньше — чинить проще и дешевле. - Повышается качество продукта. - Команда начинает думать о качестве с самого начала, а не «в последний момент». #testing #thoughts