LINUX.ORG.RU

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

FishHook
()
Ответ на: комментарий от t184256

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

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

skidphysic
() автор топика

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

upcFrost ★★★★★
()
Ответ на: комментарий от skidphysic

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

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

alex1101
()
Ответ на: комментарий от skidphysic

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

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

MoldAndLimeHoney
()

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

anc ★★★★★
()
Ответ на: комментарий от skidphysic

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

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)

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

sambo ★★
()
Ответ на: комментарий от skidphysic

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

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

skiminok1986 ★★★★★
()

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

что ещё?

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

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 2)

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

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

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

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от skidphysic

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

upcFrost ★★★★★
()

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

ddidwyll ★★★★
()

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

C
()
Ответ на: комментарий от t184256

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

DumLemming ★★★
()
Ответ на: комментарий от skidphysic

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

untitl3d
()

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

  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 – точно нет, ни кто не впустит делать что-то на сервере.
dicos ★★
()
Ответ на: комментарий от dicos

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

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

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

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

gruy ★★★★★
()
Ответ на: комментарий от skidphysic

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

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

upcFrost ★★★★★
()
Ответ на: комментарий от sambo

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

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

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

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

sambo ★★
()
Последнее исправление: sambo (всего исправлений: 1)
Ответ на: комментарий от sambo

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

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от sambo

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

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

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

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

sambo ★★
()
Ответ на: комментарий от sambo

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

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

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

upcFrost ★★★★★
()
Ответ на: комментарий от sambo

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

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

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

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

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

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

sambo ★★
()

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

Smacker ★★★★★
()
Ответ на: комментарий от sambo

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

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

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

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

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

upcFrost ★★★★★
()
Ответ на: комментарий от sambo

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

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

dicos ★★
()
Ответ на: комментарий от upcFrost

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

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

sambo ★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)