mgorbatyuk.dev

Гигиена репозитория важна На одном из проектов релиз-менеджеры удаляли из монорепозитория все ветки, что были замерджены, с помощью некой тулзы. Это полезно для того, чтобы граф репозитория не разрастался на километры, а там на проекте он мог бы быть таким, так как проект длился с 2005 года. Я решил сделать такой же и для себя с помощью Claude Скрипт работает так: - Выводит список всех веток, что были замерджены, на удаление - Выводит список веток, которые не были замерджены и не будут удалены. В таких может вестись работа еще - Выводит список защищенных веток. Сейчас в скрипте это dev, development, sandbox, production, main, master - После подтверждения пользователем удаляет ветки из первого списка Если у вас есть подобные скрипты полезные для работы, но не завязанные на бизнес домене, то тоже делитесь - соберем библиотеку скриптов вместе Описание и скрипт тут: https://github.com/maximgorbatyuk/Useful-tools-for-work/blob/main/git-cleanup/readme.md

В начале недели я уехал снова в командировку в Саудовскую Аравию и без инсайтов не обошлось Это уже третья поездка на фестиваль Soundstorm. Напомню, что мы пишем систему для продажи билетов и контроля доступа на ивент, продукт включает в себя микросервисный бэкенд, несколько мобильных приложений, а также даже немного IoT - мы собирали RFID-девайсы для считывания RFID-браслетов людей, чтобы контролировать их перемещения внутри фестиваля. Каждый год что-нибудь да случается такое, от чего у нас появляются седые волосы, и я надеюсь, что все же этот год будет исключением: мы переехали на лямбды AWS, поработали над производительностью запросов в БД и теперь будем наблюдать, какие плоды это все дало. Пока что у меня случилось только два инсайта из этой поездки в СА: 1. Водят тут чуть лучше, чем в Алматы. Алматинское движение как хардмод вождения и я рад, что я его прошел 2. На заправках нет касс, у каждой станции стоит человек с терминалом оплаты и можно заправиться, не выходя из машины. Это, конечно, инсайты не из разработки софта, поэтому взамен я предлагаю вам обратить внимание на митап моих друзей nullptr.party, где в этот раз расскажут много об архитектуре мобильных приложений и правильном подходе к их разработке. А еще предлагаю взглянуть на пару верблюдов, мчащихся на скорости 120 км/ч, которых удалось запечатлеть на одной из объездных трасс Эр-Рияда. Они были крайне невозмутимые, в отличие от нас, увидевших их.

Qazaq eline +1 iOS developer 😮 Мое приложение опубликовали, и я сразу же обнаружил у себя баг - приложение с аппстора заменило ту сборку, что накатывалась XCode-ом. Судя по всему, когда я снова подключу телефон к нему, уже продакшн-версия будет заменена версией для девелоперов и у меня будет риск потерять данные. Еще один повод вспомнить, что нельзя слепо доверять AI агентам и их подсказкам при разработке. Если вы пользуетесь электроавтомобилем, то мое приложение будет для вас полезно, чтобы узнать, во сколько денег вам обходится поездка. Буду рад любому фидбеку App store: https://apps.apple.com/kz/app/ev-charge-tracker/id6754165643 Github: https://github.com/maximgorbatyuk/ev-charging-tracker

Это я к чему... Мои друзья из Bereke Bank проводят Level Up iOS митап 🚀 📅 22 октября, 18:30 📍 Алматы, Smart Point, зал Амфитеатр Line-up митапа: ▪️ Дима Бузулуцкий, Bereke Bank — Код, который мы заслужили Как управлять зависимостями и не утонуть в «многослойной» архитектуре. ▫️Ислам Темірбек, Zimran — AI-Native E2E Testing for Mobile Apps Как AI меняет тестирование и сокращает регрессию. ▪️ Дмитрий Марченков, Plata Card — 3D в приложении: SceneKit + SwiftUI Как добавить 3D-элементы в интерфейс без опыта в 3D. ▫️ Санатжан Аймұқамбетов, Kolesa Group — Путь самурая: от Джуна до Сеньора О софт-скиллах, менторстве и зрелости в профессии. Вход по регистрации по ссылке. Митапы - это отличный способ посмотреть такому вайбкодеру как мне, какие проблемы испытывают специалисты и как их решают. Думаю, что будет очень интересно

Проводим исследования с AI и не только AI инструментами сейчас никого не удивить, но расскажу вам, как я пытаюсь написать свое iOS приложение без знания Swift (сейчас уже знаю чуть больше), а нужно оно мне для того, чтобы понять: насколько выгодно иметь электромобиль по сравнению с бензиновым авто. За контрольные данные я использую статистику по моему Subaru Forester 2005 года - за 10 лет владения статистика показывает, что один километр на этой машине мне обходится примерно в 45 тенге. Теперь мне нужно приложение, где я смогу вести подобную статистику по электромобилю, но разработчики приложения, которым я пользовался для субару, перестали его поддерживать 8 лет назад. "Что ж, во времена AI и вайбкодинга будем делать свое", - решил я. На старте я попросил claude сгенерировать мне шаблон приложения по описанию высокоуровневой задачи - мне нужно приложение, где я смог бы трекать зарядки автомобиля и прочие траты на обслуживание. Дальше уже в XCode продолжил добавлять функционал самостоятельно по примеру сгенеренных страниц и задавая вопросы claude, что и как мне нужно правильно сделать. Без помощи друга из iOS разработки тоже не обошлось, конечно же (спасибо, Наиль). Пока еще до публикации приложеня далеко, но я как fullstack .net+angular не испытываю проблем с написанием кода на Swift с подсказками от Claude и Github Copilot. Повторю то, что многие говорили и до меня: если вы задумываетесь о том, что стоит попробовать новый язык программирования, но не знаете как начать, то попробуйте найти такой продукт, который вам будет интересно писать, и на нем и пробуйте учиться. Благо, сейчас с AI этот процесс протекает гораздо легче

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

🔥 nullptr.talks[0] от nullptr.party в MOST IT Hub — встречаемся, чтобы обсудить, каким будет завтрашний день мобильной разработки, что происходит с рынком, и как технологии меняют наш подход к работе. Только честные истории, актуальные вопросы и живое общение! В программе: Дмитрий Бузулуцкий — iOS Tech Lead, Bereke Bank Тема: Быть или не быть мобильным разработчиком в 2026 году? 2022 год показал: даже в IT перемены могут прийти внезапно. За 12 лет я видел мобильную разработку со всех сторон — от первых приложений до управления командами. Поделюсь своим исследованием и личными выводами о том, как меняется профессия, куда движется рынок, и что нас ждёт впереди. Поговорим, может ли AI по-настоящему изменить правила игры — и какое место остаётся человеку в этом процессе. Илья Гуля — Developer Productivity Engineer, inDrive Тема: Вайбкодинг — блажь или благо? Вайбкодинг сейчас на таком хайпе, что о нём говорят даже вне IT. Нейросети, Cursor, Claude Code — всё обещает сделать жизнь разработчика легче, но так ли это? Расскажу на своих кейсах, когда доверять ИИ, а когда лучше положиться на собственный опыт. Ввыводы о том, где вайбкодинг выручает, а где — добавляет головной боли. Дмитрий Михальченков — Senior Android Engineer, inDrive Тема: Фича-тогглы: Друг или враг вашего дедлайна? Фича-тогглы звучат как универсальное решение для гибких релизов, но на практике часто добавляют хаоса. Обсудим, как их использовать во благо: что работает, что ломает процессы, и как не утонуть в техдолге. Всё на реальных примерах. Данияр Амангельды — Senior Android Developer Тема: Android hours — Тегін воркшоп. Қалай сонда? Почему я решил проводить бесплатные воркшопы по Android, какие бонусы и неожиданные открытия это принесло. Поделюсь своим опытом — как обучение других меняет твой собственный взгляд на профессию и почему это стоит попробовать каждому. 🗓 12 сентября | 19:00 📍 MOST IT Hub, г. Алматы, ул. Ходжанова 2/2, БЦ Fortis https://go.2gis.com/aPpbN ⏱️ Длительность: 2–2,5 часа 📝 Регистрация: https://forms.gle/CvsRbb89vtjd98PM7 ⚠️ Количество мест ограничено — лучше занять место заранее! Наш канал: https://t.me/+NwP6cY9dVfgyMDVi Наш уютный чатик: https://t.me/+60NkAf4EsJ8xYWJi

Қазақ еліне +1 Telegram Bot Всем привет! В одном из телеграм каналов возник запрос на создание Telegram бота, который бы выдавал публичную статистику по профилю в Github. Информация будет полезна тем, кто проводит собеседования и кому будет интересно, насколько кандидат активно контрибьютит в open source. Бот выдаст количество коммитов, измененных строк и файлов за последние 12 месяцев, а также количество полученных звезд, фоловеров, открытых обсуждений и проведенных code review. Никнейм бота: @github_profile_bot Ссылка: https://t.me/github_profile_bot

Пример использования ИИ-агента Решил опробовать вышедшего в релиз агента Копайлот для своего проекта по зарплатам. Начал с задачи по рефакторингу - автор библиотеки MediatR заявил пару месяцев назад, что планирует сделать свою библиотеку коммерческой, но когда и как - не знает пока. В связи с этим я решил отказаться от медиатра и в целом от подхода, когда мой код вызывается неявно. Сделал коммит по рефакторингу и решил остальное поручить копайлоту в виде ишью:

MediatR library is going to be a non-free to use very soon, according to its maintainer. So, all existing handlers should be refactored: • They should inherit Infrastructure.Services.Mediator.IRequestHandler interface • They should follow same way as SearchCompaniesHandler implementation which was already refactored • Usage of the handlers is presented in the CompaniesController class: they are called from service provider and then their Handle main method is to be called

В течение 30 минут копайлот сделал свою работу, предложенные изменения можно посмотреть тут - МР Что в итоге получилось: - Копайлот отрефакторил по примеру 90% кейсов, оставив кое-где использование IMediator в классах - После указания на это, копайлот сделал еще один коммит, удаляющий эти кейсы - МР все равно не билдился, потому что кое-где копайлот оставил угловые скобки <> там, где их быть не должно, а также нарушил форматирование, что расценивалось стайлкопом как ошибка билда. - Сэкономлено часа 3 моего времени, уделено доработке МРа вручную - минут 15-20 За 40$ в месяц - неплохой способ сэкономить время. Следующим шагом попробую описать новую фичу с критериями приемки так, чтобы копайлот смог сделать что-то адекватное и работоспособное.

Новая фича - отзывы на компании Всем привет, мои подписчики. Спешу поделиться радостной вестью - я запускаю раздел на techinterview "Отзывы на компании"! С момента запуска портала по зарплатам в январе прошлого года несколько человек делились со мной, что не хватает подобного сайта для того, чтобы почитать отзывы о других компаниях и оставить самому. Идея не нова: glassdoor.com, levels.fyi, career.habr.com и другие несут в себе такую фичу, но казахстанских компаний там немного. Особенности раздела: - Отзывы анонимны. Вы вполне можете открыть страницу со своим отзывом рядом с начальником и коллегами, и никто не узнает, что вы тут были раньше. К слову, в админке сайта тоже не видно автора во время модерации. - Отзывы проходят модерацию, но просто для того, чтобы отсеять, например, отзыв со всеми пятерками/единицами и без комментариев. Никакой валидации с компаниями нет и не будет. - Отзывы будут жить полтора года, дальше он пропадает с сайта и более не влияет на рейтинг компании. В списке есть далеко не все компании, в которых работают айтишники в Казахстане, поэтому если вашей компании нет, напишите мне в лс @maximgorbatyuk, и я ее добавлю. Делитесь мнением о компании с другими. Сделаем наше комьюнити более открытым вместе!

Обращайте внимание на источники - они скажут больше, чем кажется В чате тимлидов на днях прошло обсуждение продукта одного из участников, суть которого - сбор различных метрик производительности работы разработчиков. Инструмент будет полезен менеджерам, чтобы они могли в цифрах сравнить эффективность программистов. Обсуждение было горячим, в процессе коснулись множества смежных тем, в том числе и парное программирование (далее ПП): мол, как можно тут оценить работу разработчиков, если результатом их работы является один кусок кода и время, проведенное в IDE, тоже относится к одному человеку из двух. ПП как часть практик XP (eXtreme Programming) было описано еще в 1999 году, так что явление давнее, однако, по моему личному опыту, разработчики не так часто к нему прибегают - я не слышал ни от одного коллеги, как он круто попрограммировал с кем-то в паре недавно и какую классную архитектуру они придумали. На мой взгляд, ПП переоценено, потому что мне самому в тишине думается проще и легче, чем вслух с кем-то. В обсуждении в чате скинули статью 2019го года, рассказывающую, какое классное явление это самое ПП. Я перешел по ссылке и увидел, что, оказывается, согласно исследованиям, сессии парного программирования приносят удовольствие (Strengthening the Case for Pair Programming). Я перешел по ссылке на это исследование, и оказалось, что исследование было проведено в далеком 2000 году. Получается, что автор блога нашел только это исследование девятнадцатилетней давности по поводу пользы и удовольствия от ПП. Я задался вопросом: неужели больше никаких исследований на эту тему не проводили? Или проводили, но их результаты уже не такие радужные? Поискав в сети разные источники, я наткнулся на исследование 2009го года, где авторы исследовали разные материалы и отчеты проекта в Siemens по поводу обнаруженных дефектов кода в результате сессий ПП (PDF будет в комментариях к посту). Результат исследования расплывчатый: авторы пришли к выводу, что парное программирование как может помочь с обнаружением багов на ранних этапах разработки, так и могут быть тратой времени без большой пользы. Утверждать точно, полезная ли это практика, однозначно авторы не могут. Когда вы читаете статьи в интернете, обращайте в первую очередь на референсы, на которые ссылается автор и ссылается ли вообще. Если референтов нет, значит статья, скорее всего, целиком оценочное суждение, даже если преподносится как неопровержимая истина. Если референс, описывающие объект статьи с положительной или отрицательной стороны, был написан давно, то он мог морально устареть и ситуация на данный момент может быть диаметрально противоположной, а сама статья - нерелевантна и цель ее - это “продажа” какой-то идеи, а не проведение беспристрастного исследования.

Учитесь на чужих ошибках (часть 2, продолжение) В итоге во второй и третий день фестиваля все прошло гладко для инфраструктуры, хоть мы и не стали пользоваться оффлайн режимом, над которым работали спринт и на который возлагали надежды на случай высокой нагрузки на сеть. Какой из этого можно сделать вывод? Уже после анализа произошедшего кажется очевидным, что повторное скачивание всех билетов было лишним шагом, если уже было сделано скачивание ранее, и что это увеличит нагрузку на сеть и БД, но перед фестивалем об этом мы не задумались. Впредь стали учитывать, и фестиваль 2024го года прошел без проблем. Учитесь на чужих ошибках, вот вам как раз я описал наш кейс и тикетон опубликовал разбор своего. Всем стабильной инфраструктуры

Учитесь на чужих ошибках Фридом опубликовали статью Алексея Ли, где он рассказывает, почему одни и те же места на концерт продавались повторно. TLDR: человеческий фактор, а не технический сбой, привел к повторным продажам мест:

Учитывая отложенный механизм сверки продаж в legacy-системе, в 12:54 обнаруживается проблема, что количество выписываемых билетов необычайно мало. Проверка оплат выявляет большое количество расхождений. Идентифицирована проблема: IP адреса платежного подсервиса не внесены в белые списки, ввиду чего в систему Тикетон не поступают подтверждения от платёжных систем и соответственно не завершаются продажи билетов, а спустя определённое время снимается бронь Для контролирования нагрузки на сайт после падения и поднятия инфраструктуры

Тикетоновцы включили механизм виртуальной очереди, который, судя по всему, подменял IP адрес клиент своим и этот IP и был внесен в список белых адресов, а про IP адреса платежного сервиса забыли или не обо всех его адресах знали. Вот и получилось, что вебхук не принимал запросы от платежки об успешной транзакции и брони на места снимались. Теперь причина задвоения брони мест известна. Этот случай напомнил мне нашу ситуацию в 2023 году во время фестиваля Soundstorm. У нас микросервисная архитектура на AWS и собственное мобильное приложение для сканирования QR кодов билетов клиентов.Также у нас не было реплик баз данных на чтение. Незадолго до ивента мы внедрили новую фичу - оффлайн режим приложения для сканирования, чтобы избежать проблем с высокой задержки сигнала из-за слабого интернета на воротах на территорию фестиваля. Приложение скачивало себе все проданные билеты на фестиваль во внутреннее хранилище (где-то 150 тысяч билетов и ограниченный набор полей), чтобы в первую очередь взять информацию из него, а не с сервера. Возможные повторные проходки по одному билету нас не беспокоили в этой ситуации, мы были к этому готовы, перформанс был на первом месте. Как оказалось, это нам и аукнулось во время фестиваля. Спустя несколько часов после начала фестиваля наша система упала, нагрузка на БД возросла до 100% и каждый из нас немного поседел. Что произошло: 1. Мобильное приложение скачивало все билеты после логина человеком. Устройств таких было около 200. По умолчанию приложение работало с сервером. 2. Спустя некоторое время интернет на площадке начал работать хуже, так как нагрузка возросла в целом. 3. Люди с девайсами, увидя медленную работу приложения, стали просто выгружать его из памяти и открывать и логиниться заново. Это приводило к повторному скачиванию всех билетов и, соответственно, к бОльшей нагрузке на сеть и БД. Мы этого не учли и даже не сразу поняли, что это происходит как снежный ком. 4. Люди с девайсами начинали нервничать, что приложение открывается после логина долго, и снова выгружали его из памяти и открывали заново. Последствия этого уже известны. Люди с девайсами нервничали, клиенты нервничали, так как не могли попасть на фестиваль, и мы тем более нервничали, пытаясь понять, как решить проблему. Остановить все сервисы - не вариант. Что мы сделали: 1. Разработчик приложения быстро выпустил апдейт, убрав скачивание билетов. Мы на воротах быстро дали указание обновить приложение на девайсах. 2. На одних из ворот паника возросла настолько, что люди начали отталкивать людей со сканерами и просто шли на фестиваль. Охрана приняла решение закрыть ворота на полчаса. Вторые ворота работали в обычном режиме, но расстояние между воротами было больше двух километров, так что нагрузка на работающие ворота не возросла. Люди на первых воротах просто ждали открытия. 3. Нагрузка снизилась на инфраструктуру, дав возможность обработать все запросы в очереди. 4. На следующий день уже мы добавили реплики баз данных на чтение, чтобы распределить нагрузку. (часть 1, продолжение ниже)

Всем привет! Запись доклада опубликована тут, буду очень рад фидбеку. В докладе я рассказал, чем обернется ваша жизнь, если вы вдруг решите сделать свой собственный сервис/продукт/библиотеку. Спойлер: оно того точно стоит, а почему - узнаете из доклада. TLDR: Разработка собственного продукта - это очень занятный и полезный опыт, который позволит вам взглянуть на разработку под иным углом и прокачать свои навыки в: 1. Архитектуре 2. Разных ролях разработки продукта: бэкенд, фронтенд, тестирование 3. UI и UX дизайне 4. Ресурсном менеджменте 5. Построении комьюнити В конце концов, собственный продукт - повод похвастаться на собеседовании и показать, как умеешь разрабатывать законченные решения. Спасибо организаторам @almaty_js за возможность выступить! Презентация к докладу будет в комментариях к посту.