Меркулов Андрей (Красноярск). Python разработчик. Большой собес.
Вставка
- Опубліковано 2 лис 2023
- t.me/UA-camPronin
Чат для общения pyhton разработчиков и им сочуствующих. Свободное общение, тестовые и вопросы с собесов и прочее. Заходите, там вам рады.
Поддержать канал: www.tinkoff.ru/rm/pronin.andr...
Обычно денежка идёт на книжки про питончик. Но иногда на светлое и тёмное.
Если Тиньков не даёт перечислить, стукните в личку телеги andpronin, придумаем что нибудь
Виш лист
Хорошие книги по Питончику, которые могу рекомендовать (и хочу купить с вашей помощью).
Изучаем Python. Двухтомник. Марк Лутц. Очень подробно и структурно (Хочу дождаться 6го издания.. )
• Изучаем Python с Марко...
Читаем и разбираем ее тут
Куплено (огромное спасибо зрителям)
Знакомство с Python | Бейдер Дэн (2023) - выглядит приятно для новичка
Чистый Python. Тонкости программирования для профи | Бейдер Дэн (2022) - хорошо для продолжения
Высоконагруженные приложения. Программирование, масштабирование, поддержка | Клеппман Мартин
Python. К вершинам мастерства | Рамальо Лучано - 2е издание - сложно для новичка, но интересно
Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура -- хорошо про то, когда какой фреймворк применять
Видимо, дальше появтся еще нескромные желания. Но пока - так
Моя тележка andpronin -- стучите, если что.
Мой канал про обучению python с нуля и до мидла Андрей+=Пронин
/ @pypronin
Я в других сетях
🔗Вконтакте: CaptPronin
🔗Дзен: zen.yandex.ru/id/5fbd33919412...
#python #питон #программирование #Андрей_Пронин #собеседование #
Беседа за жизнь - было интересно послушать )
а мне было интересно поговорить с умным человеком)
Пора вводить название подкаста -Антилиткод)) Опять хорошо получилось - реальные задачи тащат
В целом, по общению - достаточно комфортно.
По БД - прям почти хорошо: были некоторые помарки, но некритичные.
Но вот первая задача - это просто швах:
1. Задача не решена. Представленное решение в половине случаев будет порождать аномалии.
2. Вообще не уточнил у заказчика точные требования.
3. Сам что-то себе надумал - и начал решать другую задачу у себя в голове.
4. Корнеркейсы вообще не рассмотрел.
5. Зачем-то добавил список с предлогами - причем неполный список.
Ну и это все выльется в 1 вещь - когда прилетит задача, то он будет решать ее так, как сам поймет, а не так, как этого хочет заказчик.
Ну а потом это все придется переделывать. Это при условии, что эти аномалии получится сразу найти.
Кароче, вообще хз.
С одной стороны - "алгосы не нужны" и тд. С другой - тут было много нехороших аспектов.
Мне кажется или все программисты решают задачи именно так, как сами сначала поняли?))))
@@Chel1k7 что бы программист решал задучу правильно, нужет проджект)
Расскажите как бы вы решили эту задачу, с примером решения, возможно и у вас будет не лучший подход
Хотя учитывая что у вас не 5 минут и вы решаете пост-фактум должно быть все ок)
Фууухх, я испугался, подумал капец мне бы столько вопросов понадобилось чтоб начать, а он сразу понял. А оказывается вот как... успокоили)
Ну в алгоритме уже вижу ошибку... 200 символов заканчиваются на пробеле или полноценном слове и предпоследний элемент не предлог. получается он удалит лишнее слово, собственно вопрос а зачем?
А если заканчивается на полноценном слове и предпоследний элемент предлог то получится удалит два слова что ещё хуже...
И это не какие-то эдж кейсы это прямо будет часто возникающая ситуация...
То есть ничего не удалять в принципе не предусмотрено а это явная и грубая ошибка...
Вопрос к собеседователю: Андрей вы же готовитесь к собеседованию и эту задачу придумали вы Но такую явную проблему вы каким-то образом упустили и в конце собеседования назвали что задача решена хорошо.
Вы обратили внимание на проблему с хардкодом внутри функции но не обратили внимание на то что алгоритм кривой с явным багом, Я бы это назвал даже что задача совсем не решена...
Потому что в задаче очень важным условием было заполнить 200 символов по максимуму а тут получается заполнение идёт не по максимуму.
Вообще, да. Затупил. Задачку из рабочих такое взял перед собесом, не готовился и не решал сам. Кажется Акелла промахнулся
решил посмотреть дальше задачки, а значит и критиковать продолжу :)
имена таблиц в единственном числе - ошибка. существует индастри стэндард и его надо знать.
незнание того что many-to-many идет через association/pivot таблицу - очевидное не знание
51:30 а теперь про связь Учитель-программа-дисциплина
товарищ Меркулов абсолютно верно УГАДАЛ что учителя надо добавить в таблицу "program_discipline"
но поскольку он угадал, то он не смог отстоять свою точку зрения ))
если вы предлагаете добавить "discipline_id" в "teacher_program" "потому что это логично", тогда с таким же успехом можно добавить "program_id" в "teacher_discipline" потому что это "равнозначно" если следовать той же логике.
в "teacher_program" совсем НЕ логично добавлять дисциплину потому что меняется вся суть этой таблицы которая связывает Учителя и программу. и после такого добавления она начинает связывать УЧИТЕЛЯ + ПРОГРАММУ + ДИСЦИПЛИНУ и перестает соответствовать своему предназначению и названию "teacher_program".
а вот в "program_discipline" как раз то очень логично добавить "teacher_id" потому что по условиям задачи "program_discipline" связывает Программу и Дисциплину, и Учитель идет как дополнение к этой связке...
программа + дисциплина останется, а вот преподаватель тут идет как уточнение ... сегодня Иванов, а завтра Петров...
если мы добавим препода в таблицу "program_discipline" это нам открывает возможности:
1) допустим поменялся учитель - можем просто сменить учителя оставив program_discipline.id неизменным
2) можем сохранить препода и просто отключить старую запись "program_discipline.id" - для истории (лучше через лог конечно но просто рассуждаем о вариантах) и создать новую запись с новым преподом...
3) это позволяет нам делить 100 студентов в рамках одной программы и дисциплины на 2 разных учителя по 50 студентов каждому
4) и т.п.
то есть это нам дает логическую гибкость.
если мыслить категориями реальной жизни (мы же аддепты ООП?) и дальнейшей имплементации в коде:
для простоты мышления на примере универа:
у нас есть Группа А и Группа Б студентов (наши программы, на пример одни программисты а вторые Физики-ядерщики)
и тем и другим надо преподавать дисциплину "Высшая Математика", то есть связка Программа+дисциплина = нерушимая связь = обязательное условие ... а вот Будет это преподавать Иванов или Петров - это пофиг веники - они взаимозаменяемы, они есть дополнение к обязательному условию...
если прям совсем нормализовывать то надо еще одну таблицу "program_discipline_teacher" - но для данной задачи это явно излишне, добавляет излишнюю связь, усложняет и замедляет запрос...
а теперь попробуем применить тот же подход к таблицам "teacher_program" и "teacher_discipline".
а) teacher_program:
учитель преподает некой группе студентов (нашу программу, курс)... если сюда добавить discipline_id как некоторое уточнение к основной связке оно не легко заменяемо ... не может препод у этой группы вести любую дисциплину...
то есть вами предложенный вариант добавить "discipline_id" прям совсем не катит.
б) teacher_discipline:
учитель преподает какую то дисциплину - это основная связка в таблице... если мы добавим уточняющее поле "program_id" ... а может ли препод по высшей математике преподавать в любой группе/программе ? наверное нет ...
с) вы мне возразите:
погоди, а с чего ты взял что в "program_discipline" может преподавать любой препод ... "а не может" и тут я соглашусь. может преподавать только тот препод у которого teacher_discipline совпадает...
здравствуй композитный внешний ключ - нежданчик явно не для джуна, ну и програмная проверка от греха подальше ))
но на практике я бы от такого ключа наверное отказался и оставил только програмную проверку.
и этот вариант по любому более логичен.
в рамках реализации:
все 3 таблицы ( "teacher_program", "teacher_discipline", "program_discipline") "равнозначны" и можно впихнуть третье поле в любую из них что бы она отображала связь программа+дисциплина+препод
в рамках логики:
1) "teacher_program", "teacher_discipline" - равнозначны, вы мне не сможете объяснить
чем "discipline_id" внутри "teacher_program"
лучше чем "program_id" внутри "teacher_discipline"
и в том и в другом случае теряется логический смысл и первой и второй таблиц
2) а вот почему добавить "teacher_id" внутрь "program_discipline" более логически верное решение я вам объяснил выше
так что ИМХО учителя надо добавить в таблицу "program_discipline" и товарищ Меркулов угадал, но не смог защитить и обосновать свою догадку и сразу сдался согласившись с вами )) а мог бы и взять время на поразмыслить или порассуждать в слух как это сделал я...
я когда собеседую люблю "вбрасывать" такого рода несостыковки и смотреть человек сразу согласится или начнет рассуждать или начнет тупо спорить неаргументированно и к чему мы по итогу обсуждения придем :)
ПС: я допускаю что я не прав всегда и во всем, но меня в этом надо аргументированно убедить :)
Андрей у меня вот такой вопрос как к опытному программисту. Я учусь на курса по python у нас по программе курса только 1-н фрейм. Django, хватит ли мне только его для трудоустройства или ещё надо хотя бы 1-н?
@@sleeepy26 я не вузе Python изучаю
Если ты трудоустраиваешься туда - где работают на Django - то хватит. Если нет, то нет)
Просто, елоси требования будут не Джанго - пролетаешь. А так можно Фастапи выучить и с ним жить или с Фласком.
@@AndyPronin спасибо
53:35 здесь teacher_program и program_discipline повторяют информацию о связи программы и дисциплины с соответствующими возможными аномалиями: удаляем дисциплину из программы, а преподаватель в ней остаётся (если из program_discipline удалили). Табличка program_discipline лишняя.
Да отличное замечание. А где хранить информацию о дисциплинах в программе?
@@AndyPronin Хмм... ну здесь 3 варианта есть:
1. Тот который в видео, недостатки уже описывал
2. Убрать табличку program_discipline и установить специальный правила для таблички teacher_program. Например, если преподаватель пока не назначен ставить teacher_id = NULL (и ON DELETE SET NULL у внешнего ключа с teacher) + если хотим список дисциплин программы обязательно использовать SELECT DISTINCT discpline_id WHERE program_id = (нужный id).
Но тут возникает сразу проблема с удалением преподавателя из программы - нам нужно знать это последний преподаватель, который ведёт данную дисциплину или нет: если да ставим NULL, если нет удаляем строку из teacher_program (а если race condition?).
Короче выглядит сложным...
3. Связать связью m2m таблицу teacher и program_discpline (соответственно teacher_program убрать). Вроде артефактов никаких возникать не должно. Правда установить на каких программах преподаёт преподаватель становится нетривиальной задачей)
@@sn3232 Вообще если не нужны исторические данные (но для них в любом случае лучше сделать отдельную таблицу заполняемую тригером), то тичер пронрамм конечно удалить, а в програм дисциплин добавить столбец тичер внешним ключом на тичера (это начинал делать интерьюируемый но его отговорили). И накинуть уник на сочетание тичер , программ, дисциплин. Получаем вполе чистую сущность - в таблице программ дисциплин для курса. Это конечно не связь классиечкая многие к многим. Но опять же мы ведь тут не в ОРМке и можем сами придумывать свой дизайн
Хм. А это на джуна собеседование? Вроде норм отвечает.
Да. на джуна
а можно как-либо на собеседование попасть?
Студент практикума?
@@AndyProninа без постели не пускают?)
а где плюсы, где си? почему какие-то недоязыки типа питона обсуждают так часто?
Пишете на плюсах?
@@AndyProninда
Отличный язык. У нашей компании стек - питон и яваскрипт.
Поэтому так. Ну и ребята на курсе учили питон. странно их будет спрашивать про си.
Начиная с первой задачи уже понятно что человек даже не Джюн.. Плиз изучите PHP хотябы понять что такое программирования а потом уже более высокие языка как Питон
Не хочу начинать холивар но я как пхпэшник негодую...
Объяснитесь сударь, что значит хотя бы ПХП а потом более высокий уровень питон...
Если мы говорим о веб-разработке то расскажите мне а чём это питон настолько лучше чем PHP что он более высокого уровня?
Только не рассказывайте эту сказку что я смотрю на код питона и мне сразу всё интуитивно понятно...
Я не знаю питона я его второй раз в жизни вижу и мне ничего не понятно.
мне понятны: c java JavaScript PHP perl c#
Но я понимаю что это вкусовщина и пару недель надо на привыкание поэтому к этому не придираюсь даже...
Я посмотрел штук пять-шесть интервью и я не увидел уровня джуниоров у ребят но услышал желание зарплат в пределах 1.000 долларов.
Для понимания: на ПХП бэкенда джуниоров нанимают с пониманием принципов солид пусть базового, но понимания. чёткого понимания ооп ,mvc, rest, очень аккуратно могут спросить про паттерны проектирования знает ли какие-то слышал ли о них..
А здесь на собеседованиях я вижу ребята клепают классы и не используют интерфейсы...
Бог с ним с интерфейсами где хотя бы абстрактные классы, даже на абстрактные классы закрою глаза, В питоне что области видимости отменили?
А это всё база ооп...
Ладно бог с ним просто для меня это небо и земля что требуют от джуниоров на ПХП и то что я вижу в собеседованиях на питон...
У меня собственно к вам вопрос чем питон более высокого уровня чем PHP что надо "хотя бы PHP изучить"
Надо хотя бы программированию для начала научиться без относительно языка программирования а потом просить зарплату 1.000 долларов
я так понимаю, аргументов не будет?
Если можно, больше конструктива в комментариях.