TL;DR: через випадкову помилку в новій версії VS Code я на кілька тижнів залишився без нових користувачів. Урок: моніторинг помилок у реальному часі варто впроваджувати якомога раніше.
Розробляти проєкт наодинці важко. Доводиться бути всім одразу: розробником, дизайнером, маркетологом, підтримкою — і це ще не все. Постійно жонглюєш завданнями та пріоритетами, і часом щось таки випадає з рук.
В перший тиждень липня чергове оновлення VS Code змінило внутрішню систему автентифікації, і наявні версії GitByBit почали зациклюватися одразу на старті. Фактично, доки проблему не було усунуто, ніхто з користувачів не міг пройти курс. А я, нічого не підозрюючи, працював над майбутньою практикою пулл реквестів (яка, до речі, дуже крута й вийшла минулого тижня).
Зрештою хтось повідомив про проблему на GitHub, тож я зміг виправити її та випустити нову версію. Але нових користувачів за ці кілька тижнів фактично втрачено: скористатися курсом вони так і не змогли.
Коли усвідомлюєш, що твій проєкт не працював останні кілька тижнів.
Більшість моїх інших проєктів — це звичайні вебзастосунки, які працюють на моєму сервері. Вони збудовані на популярних фреймворках на кшталт Laravel чи React, тож їх легко інтегрувати із системою моніторингу помилок у реальному часі, як-от Sentry або Rollbar. Щойно стається помилка, я одразу отримую сповіщення, заливаю виправлення на сервер — і воно миттю доступне всім користувачам. Налагоджувати проблему теж простіше: у мене є доступ до серверних логів, тож видно, що саме пішло не так.
Але GitByBit — не звичайний вебзастосунок. Є розширення для VS Code і вебверсія, і кожна частина має окремий фронтенд і бекенд. Усе це збудовано на різних технологіях, тож звітування про помилки не зводиться до «вставити API-ключ Rollbar десь у конфіг». Досі всі ці частини надсилали телеметрію на мій основний сервер, де вона зберігалась в єдиному централізованому журналі.
Але, на жаль, жодної системи моніторингу, яка сповіщала б про помилки в реальному часі, не було. Тож, щоб дізнатися про помилки, доводилося відкривати й читати ось це:
Не надто читабельно — хіба що ти володієш клінгонською.
Можна час від часу переглядати такі логи, але користь від цього є хіба що одразу після релізу. Здебільшого нічого поганого не відбувається, тож регулярні перевірки поступово закидаєш. Заглядаєш раз на тиждень, потім поринаєш в інші справи — і все, забуто.
Власне, я так і роблю... Але логи треба не лише збирати, а й моніторити.
Здається, що коли щось зламається, про це розкажуть користувачі або воно зрештою спливе в логах. Частка правди тут є, але проблема може висіти непоміченою досить довго — а за цей час можна втратити чимало користувачів, яким помилка не дала пройти курс. Саме це й сталося з проєктом у липні.
Гей, Олександре, хіба ж ти не досвідчений розробник? Чому було не зробити нормальне звітування про помилки від самого початку? Навіщо чекати аж дотепер?
Гарне запитання! У цьому й складність соло-розробки: справ безліч, а рук лише дві (сподіваюся). Доводиться ПРІОРИТЕЗУВАТИ! До того ж:
- Базові логи вже були, тож за бажання можна було подивитися, що йде не так.
- Я був зайнятий роботою над матеріалами курсу, тож витрачати тижні на бекенд-інфраструктуру здавалося не найнагальнішою справою.
- Це ранній доступ, тож люди більш-менш готові до проблем і помилок. Я сподівався: якщо щось піде не так, користувачі повідомлять, і я швидко все виправлю.
Але тепер, коли курс набирає популярності, саме час подбати про нормальний моніторинг помилок і проблем у реальному часі.
PostHog поспішає на допомогу
Я вже кілька років намагаюся відв'язатися від Google, але для відстеження дій користувачів на своїх проєктах досі здебільшого використовую Google Analytics. Нещодавно я натрапив на PostHog і вирішив спробувати. Він поєднує кілька потрібних мені речей: відстеження подій, запис сесій і звітування про помилки. А ще в нього щедрий безкоштовний тариф, тож у проєкті на етапі раннього доступу можна поки не перейматися витратами. До того ж є в них і милий їжачок-маскот на ім'я Max, якого я просто обожнюю.
Якщо тобі не подобається Max — ти погана людина.
Настанови для розробників VS Code забороняють підключати власні аналітичні скрипти всередині розширення — здебільшого з міркувань продуктивності та безпеки. Проте телеметрія, зібрана через VS Code API, не порушує правил: її можна приймати на своєму сервері й пересилати далі в PostHog чи будь-який інший сервіс аналітики. Так можна стежити за діями користувачів і помилками в розширенні, лишаючись у межах настанов.
Тепер помилки збираються в читабельному форматі, тож видно, що і де пішло не так. Повтори групуються, тому одразу зрозуміло, скількох користувачів зачепило.
Кожна помилка містить чимало деталей, які допомагають знайти першопричину. Виправлену помилку можна позначити як розв'язану, щоб вона не захаращувала список.
Це розв'язало проблему з читабельністю та відстеженням, але лишалося питання сповіщень про нові помилки в реальному часі. У PostHog є вбудована система сповіщень, яка може писати в Discord, Slack чи інші канали, щойно стається нова помилка. Тож тепер я одразу дізнаюся про будь-які проблеми й можу швидко їх виправити.
Тепер, якщо з Discord лунає безперервний потік БУП!!!, я знаю: курс зламався. Можна швидко відкрити дашборд PostHog і подивитися, що сталося.
TL;DR: у GitByBit тепер можна потренуватися створювати пулл реквести!
Бувало таке? Знаходиш помилку в чужому коді й думаєш: «Чому це досі не виправили?» Створюєш тикет, чекаєш... і нічого.
Так от: чекати більше не обов'язково.
Можна закасати рукави й виправити все самотужки. Надішли пулл реквест, дочекайся злиття — і твоєю роботою користуватимуться всі, хто працює з цією бібліотекою.
Ніколи не знаєш, що витягнеш із пулл реквеста.
Справжня помилка, справжнє виправлення
Практика починається з життєвого сценарію: твій фітнес-трекер глючить, коли хтось намагається записати активність на полі для гольфу з дистанцією в ярдах. Застосунок не вміє конвертувати ярди в метри й падає. Виправлення просте — додати конвертацію (1 ярд = 0,9144 метра). Латаєш бібліотеку й спокійно живеш далі.
Але за якийсь час прилітає оновлення, яке ламає твоє виправлення. Доводиться накладати латку знову. Потім ще раз. І ще. Стає ясно: час іде на безглузде латання, а виправлення має жити в самій бібліотеці. Як же його туди доправити?
Могутній пулл реквест
Більшість проєктів із відкритим кодом розміщені на GitHub або схожих платформах, і всі вони підтримують пулл реквести. Пулл реквест — це спосіб запропонувати зміни до проєкту. Ти робиш форк репозиторію, вносиш зміни, а потім надсилаєш до оригінального репозиторію пулл реквест із пропозицією злити твої правки в основну кодову базу.
Окрім технічного боку (форків, гілок і злиттів), пулл реквест передбачає ще й спілкування. Треба пояснити, що саме змінено, навіщо ці правки потрібні і як вони покращують проєкт. Саме тут можна показати, наскільки добре ти розумієш кодову базу і вмієш робити корисний внесок. Але нічого не вийде, якщо запороти пулл реквест недбалими повідомленнями комітів, запушити купу сторонніх правок або знехтувати правилами проєкту щодо внесення змін.
З таким настроєм у коментарях до пулл реквеста далеко не заїдеш.
До того ж під час обговорення пулл реквеста, можливо, доведеться оновлювати форк, робити ребейз і розв'язувати конфлікти. Усе це вимагає цілого набору Git-навичок, і тепер усі їх можна відпрацювати в GitByBit у реалістичному сценарії зі справжніми репозиторіями на GitHub.
Щоб довести пулл реквест до пуття, потрібно чимало терпіння та уваги до деталей.
Разом із практикою пулл реквестів я додав до Gitопедії кілька нових статей, зокрема і . А ще з'явилися дві нові найкращі практики: та .
Привіт! Мене звати Олександр Швець, я автор GitByBit. Радий повідомити: цей блог нарешті зафурикав! 🎉
Чесно кажучи, варто було зробити це набагато раніше. Я працюю над GitByBit уже понад рік і за цей час назбирав купу думок про Git, контроль версій і сучасні підходи до розробки.
А ще ділитимуся ілюстраціями, які малюю для проєкту. Наприклад, такими:
Мені майже 40. Друг переконує, що молодь уже не зчитує відсилки до «Термінатора», але я їх обожнюю і вважаю, що вони досі чудові. Хіба ні?
Свій перший ресурс про Git я запустив ще у 2011 році — він називався GitHowTo.com. Сайт досі онлайн і на диво популярний: лише за минулий рік на нього зайшло понад 100 000 людей.
Але як на сьогодні, той формат надто жорсткий. Він вів однією колією і зачіпав лише найпоширеніші команди Git. Багато реальних проблем залишалися поза кадром, і якщо десь застрягнеш, лишалося хіба копирсатися у Stack Overflow чи інших ресурсах. Жодного AI, який би підказав, тоді не було.
Тож я вирішив зробити щось краще: інтерактивний курс Git, зосереджений на практиці, а не на теорії. Я запитав себе: а що, як замість перемикання між браузером і терміналом усе відбуватиметься просто в редакторі коду? Що, як Git можна буде вивчати, працюючи над власними проєктами й не виходячи з IDE?
Так і народився GitByBit. Шлях сюди був довгий, але тепер усе готово — і, сподіваюся, курс стане тобі в пригоді.
Далі — щоденники розробки! Ділитимуся думками про проєкт, труднощами, з якими стикався, і уроками, які з них виніс. Не перемикайся!