Python-книги для джуна

Официальный tutorial + то, что нужно для задачи.

Есть фактически только одно полное и подробное руководство по питону - Макрк Лутц последнее издание, так много воды для совсем уж нубов, человеку с опытом будет не очень интересно, но если читать через страницу - маст хэв

то, что нужно для задачи

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

Читать питонодок, там все есть. И кафка джуну это жесть, максимум что такое mq и как его едят из кода, иначе зароется в настройку топиков

Исправляю условие, ошибка в нем.

подготовить себя более-менее универсально для рынка

Какой безнадёгой несёт от этих слов…

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

Тогда анальную пробку, толщина 3-4см, если на джуна.

кафка джуну это жесть

Rabbitmq тогда, или лишнее для джуна? Requests, scrapy beautifulsoup?

Судя по перечню, я бы на первое место поставил «свободная касса»

Это перечень от яндекса на самом деле.

Та хоть от «ундыкса»
ЗЫ Догадался, это для тындыкс яды?

Если нужен стэк - зайди на курсы и посмотри программу. А так есть туториал, в том числе и у джанги/етс, есть Лутц (читается тяжеловато, но для понимания что и как самое то), есть Фаулер.

django

Тогда ещё и Flask.

А зачем фласк если есть монстр джанго?

А зачем фласк если есть монстр джанго?

Не повредит. Джанга, фласк, алхимия. Как минимум чтобы немного с разных углов посмотреть на одно и то же.

Не всегда нужны монстры)

Сам питон, git flow, asyncio, django, oauth, PostgreSQL, SQlAlchemy, redis, apache kafka, docker, docker compose, nginx

что ещё?

Смотря для чего. FastAPI, boto, например.

Что нужно изучить питон-джуну?

Если серьезно, то ничего из перечисленного в ТС джуну не надо. Ему нужен только язык на уровне вопросов без звездочек, остальное получит с опытом.

Потому что джуну самостоятельный выбор стека никто и не доверит, и джун подразумевает, что работа будет «под наставником».

Суть - ты физически не сможешь выучить вообще все технологии на одинаково хорошем уровне. Просто почитать зачем нужна mq и почему в 99% случаев она не нужна, какие стандартные варианты её применения, как в mq-based среде откатить транзакцию в случае проблем (спойлер - это весело). Прям вот читать как работают кафка/кролик без чёткой цели не нужно

kafka

Замок уже советовали?

В яндексе кафка, asyncio и git? Чёт подозрительно. Это какое подразделение?

Работать иди, какие книги.

Чёт подозрительно. Это какое подразделение?

https://practicum.yandex.ru/middle-python/

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

SICP

Тупориал не нужен, только желание написать игру

Посоветую тебе в таком случае не совершать ошибку и учить нормальный ЯП. Этому миру не нужен еще один питонщик.

Нормальный, это какой?

HTML

Про питон – тебе книгу во втором комменте обозначили

1. git: знать команды git commit, git push, git pull, git merge. Все;
2. django: хз, если пойдешь туда, где используется fastapi, то это не нужно. Для интереса можно по туториалу сделать проект;
3. oauth – просто понимать как работает и для чего 2 токена;
4. postgre sql – просто понимать SQL на уровне написания запросов;
5. redis – почитать документацию по командам и выполнить их в консоли;
6. apache kafka – ХЗ, не работал с этим ни разу;
7. docker compose: знать команды: docker-compose up, docker-compose down, docker-compose build;
8. nginx – точно нет, ни кто не впустит делать что-то на сервере.

git: знать команды git commit, git push, git pull, git merge. Все;

rebase, cherry-pick как минимум понадобятся.

django: хз, если пойдешь туда, где используется fastapi, то это не нужно. Для интереса можно по туториалу сделать проект;

Добавлю еще SQLAlchemy.

А, вы про курсы. Фуф, а то уж испугался что в яндексе закопали монорепу и бинарные сборки.

Вот кстати и хороший обучающий вопрос - почему монорепы в крупных компаниях крайне редко работают на git, и если и работают то с кучей своих примочек?

Может исторически сложилось - перетаскивать незачем?

git нужно поглубже - ветки, конфликты, удаленные репы.

И да и нет. До монорепы варианты были. После - есть небольшие бизнес-юниты, которые живут в гите, но в основной компании транслятором монорепы в гит пользовалось человек 50-100. Соответственно вопрос на проверку знаний по принципам работы vcs - почему так?

Я все же склоняюсь к мысли, что исторически сложилось. Где то пробегало, что например в Яндекс используется свое, совместимое с git/svn/mercurial. Но лично я в таких конторах (ФААНГ) не работал, там где работал все было в гитлаб/битбукет (но софт в этих конторах не во главе угла - нефтянка/страхование).

Или ты намекаешь на какой-то недостаток гит?

Это не недостаток, это модель хранения изменений и предполагаемая модель использования. Гит хранит снапшоты файлов и предназначен для локальной работы с периодическим синхом на сервер. Для монорепы это будет означать гигантский размер и тормоза.

А понял, про это читал, на хабре были статьи раскрывающие плюсы/минусы.

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

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

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

Ну это конечно прям про огромный сервис - что бы весь хард забил

Это монорепа. Всё сервисы в одном гигантском дереве. Включая фронтенд и их ресурсы, включая все тестовые данные всех проектов, вообще все разом. И вся история всего этого.

Чтоб было примерно понятно какой размер этого чуда - в hg одна единственная директория одного старого проекта вполне может занимать 50 гиг. А проектов десятки

ушли от монорепы

Это прям история успеха, обычно наоборот. Хз, я против монореп. Там на бумаге все курчаво, а на деле нужен взвод девопсов, что-то вечно тормозит, спеки часто вообще лежат помойкой в общей куче, народ вечно что-то ломает и т.д. Ну и nih идёт прям везде.

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

Я пока не могу до конца мнение сформировать за я или против, в некоторых случаях удобно в моно (тестирование например, единый пулреквест по задаче), в других наоборот - дисциплинирует не лезть в куски других сервисов (хоть может казаться, что так будет лучше).

Ну и при большом количестве команд - не представляю как грамотно организовать процесс работы в монорепе (не пробовал).

Мы рождены, чтоб Кафку сделать былью!

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

Ну и при большом количестве команд - не представляю как грамотно организовать процесс работы в монорепе

Массовыми расстрелами, серьёзно. Тупо уволить всех кто не хочет делать как сказали

тестирование например, единый пулреквест по задаче

Это не монорепа, это просто грамотно разбитые сервисы. По идее у тебя должно быть 1 пр с кодом и ещё один-два с апишкой если она отдельно. Иногда ещё один с докой (опять же если отдельно). Если код задачи касается нескольких сервисов, которые ещё и выкатить надо «одновременно» - что-то где-то плохо разбито.

Я про бэк, если что. На фронт примерно так же.

git нужно поглубже - ветки, конфликты, удаленные репы.

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

Это не монорепа, это просто грамотно разбитые сервисы.

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