Записки нита

Решил посоветоваться с чатомгпт о том, что делать с цифрой опыта, в ответ получил базу)

 Jo_jpp, твоё "тестовое" (если оно будет ОК) данная контора просто заберёт себе в прод, а тебе скажет "спасибо, не подходите". Такая там бизнес-модель. Можно делать ставки, что техсобеса не будет не зависимо от качества выполнения задания. Но если ты как обучение воспринимаешь, то вроде как ничего не теряешь.

 SnowBeaver, Я в целом это понимаю. Сегодня прислали еще одно тестовое: нужно выделить часть функционала из старого Django CRUD-монолита и реализовать отдельный асинхронный микросервис на Litestar, который полностью заменит существующий CRUD.

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

К тому же я почти закончил: сейчас настраиваю Docker, дальше подниму сервис и начну тестировать.

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

Сделаю выводы: тестировать нормально нужно сразу. Нужно создавать фабрику, заполнять базу и прогонять весь функционал ещё на этапе первого сервиса. А на этапе развертывания уже просто проверять перехват эндпоинтов и возврат данных по тому же протоколу.

Единственное, что радует - это то, что я додумался сделать два репозитория: один под сам микросервис, другой под финальную сборку. Потом смогу продолжить с текущего момента и доделать позже).

Завтра вернусь к первому тестовому, потому что не хочу снова распыляться. Ко второму вернусь уже после того, как закончу это и оформлю красиво. Такие дела

Jo_jpp @ 18.11.25 

Единственное, что радует - это то, что я додумался сделать два репозитория: один под сам микросервис, другой под финальную сборку. Потом смогу продолжить с текущего момента и доделать позже).

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

 SnowBeaver, 

Задачи не знаю, но звучит странно.

Согласен, по уму нужно было после того, как смержил последнюю фичу в дев, сделать отдельную ветку релиз под сборку, а когда собрал - мержить мейн. Но я хотел каркас программы оставить в отдельной ветке, чтобы потом из неё что-то сделать: посмотреть, как к этому фреймворку подключать Redis, Celery и всё такое. Поэтому я оставил репозиторий с готовым каркасом под эти цели, а сборку делал в отдельном репо. 

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

Ну я стараюсь аккуратно вести гит. От мейн сделал дев, от дев - фичу. По фиче иду коммитами и мержу ее в дев, потом новая фича и т.д. 

Jo_jpp @ 19.11.25 

  как к этому фреймворку подключать Redis, Celery и всё такое. 

Читаю, что хочешь подключить у себя редис и сельдерей. Не иначе как в ТЗ была задача произвести "Okroshka" )))

 SnowBeaver, Любимое блюдо вкатуна)