ну тут я никаких противоречий не вижу: во-первых мой канал еще очень молодой. особенно при непосредственном сравнении. во-вторых: Хауди-Хо действительно прикольный канал, там много интересных, весёлых и необычных видео. я и сам его периодически смотрю. так что, всё закономерно ))
Бро, было бы круто ещё про тестирование БД, Моки и тесты для внешних API ))) А то там уже шкала сложности усвоения документации по unittest мгновенно взлетает по экспоненте)))
Привет! Изучаю Python и соответственно пишу очень много всего разного, от а+а до генераторов с функциями и прочего (пока на стадии генераторов и функций). При тесте задачи постоянно приходится ее перезапускать и вводить разные данные, int, float, str, коллекции и тд. Правильно ли я понял из видео что моих ручных проверок в каждой второй задаче можно избежать написав юниттест? И наверное можно на такой случай написать универсальный тест и просто импортировать его в свои задачи? Спасибо за видео на канале! Я, конечно же подписан, лайкаю и нажал на колокольчик:)
ты всё правильно понял. после каждого минорного изменения заново ручками проверять как ведёт себя программа при вводе строки, числа, даты и т.д. и т.п. очень долго и дорого. оптимальнее создать скрипт теста, и просто запускать его каждый раз когда внёс изменения.
А где про тесты можно посмотреть подробнее? Просто по мне использовать валидатор входных значений и обработчик исключения куда более правильное решение, но думаю тут не про это.
Уважаемый блогер, здравствуйте. Объясните пожалуйста, как понять от какого класса мы должны наследовать класс, который мы сейчас задаем? Это в какой-то документации прописано или мы придумывать должны? У вас в данном случае наследуется от класса unitest.Testcase. Не понимаю, откуда вы взяли Testcase? Это модуль в классе unitest? спасибо
в данном случае нужно знать или посмотреть в документации. в общем случае наследоваться нужно от того класса, функционал которого нужен тебе в твоём наследнике
genius, ты показал максимально обсосанный пример, то как работает программа должно быть определенно на этапе проектирования приложения, на этапе получения данных от пользователя должна быть проработана предварительная валидация данных. Если приводить примеры тестирования, то можно выделить пару примеров, например тестировать поведение функции, при вводе условно верных данных, например вы пишете фикцию для каких то вычислений, она безумно сложная и занимает 20 строк кода, и выполняется секунд пять, вы её тестируете сопоставляя с заведомо верными данными, но программист B, решает что данная функция является узким местом программы из за частого его вызова программа тратит много времени на вычисления. После внесения корректировок программистом B программа начала работать и правда быстрее, но благодаря тестам может всплыть что она выполняет задачу с ошибкой, например при вводе отрицательных чисел или float или 0. Так что во многом тесты помогают разработчикам быть уверенным что их код работает так как ожидается. Но есть второе применение которое так же очень важное, например для поддержки приложения, мой пример, я написал парсер для загрузки аудиокниг, и через 2 месяца решил скачать себе новую книгу, по итогу загрузчик ложился с ошибкой в о время загрузки, по логам проблема была в модуле async_downloader и если бы не тесты я бы искал проблему там, но благодаря что я заранее на каждый класс написал тесты стало ясно что структура html немного поменялась, и вместо ссылок на аудиофайлы я получал ссылки на картинки. Которые успешно передавались в модуль загрузчик. Так что тесты нужны так же для поиска ошибок в программе после изменений внешних факторов.
Доброго. Почему-то тесты по программе из примера: self.assertRaises(TypeError, circle_area, 'df') self.assertRaises(TypeError, circle_area, [12,12]) self.assertRaises(TypeError, circle_area, {"1":"123"}) не выдают ошибку. Однако вот этот тест выдал ошибку. self.assertRaises(TypeError, circle_area, True) Запуск делал до покрытия тестами основного кода.
не знаю поможет ли тебе это спустя год) в общем не все объекты можно сравнивать с нулем. собственно например массив с int сравнить нельзя и эта операция итак выдаст ошибку TypeError. Поэтому тест выполняется. А вот True - булево значение, его можно сравнить с int (он преобразуется в единицу)
не сложно. на канале есть видео с обзором подборки плагинов, которые я постоянно использую. плагин называется platformio-ide-terminal и он полностью копирует функционал родной консоли операционной системы. это не единственный вариант, есть и другие. но мне понравился именно этот из-за возможности настройки цветовых схем
по поводу процентов ничего не могу сказать. я не тестировщик. но мне трудно себе представить как можно реализовать TDD без unit-тестирования. чтобы перейти к масштабной методологии TDD сперва необходимо ознакомиться с её составными частями. поэтому мне кажется абсолютно логичным сначала познакомиться с unit-тестами, а потом уже со всем остальным
@@SweetCoder я думаю нам есть смысл сделать совместное видео на тему. TDD - это это один из спобов делать Unit тестирование :) И кстати, это как раз не про тестирование (поэтому и называется test-driven DEVELOPMENT) Вот тут кстати неплохой пример TDD ua-cam.com/video/NWZHcjQJ6Ds/v-deo.html
Проверка типов довольно спорная тема в питоне. Как по мне, если вы это предпочитаете, то лучше использовать какой-либо статически типизированый язык. Кроме того может сложиться впечатление, что юниттесты - это про проверку типов, хотя они скорее для тестирования логики самой функции/метода.
а почему проверка типов это спорная тема? я может быть действительно чего-то не знаю. юнит-тесты, конечно же, не про проверку типов, однако даже в этом плохеньком примерчике явно видно, что использование строки или отрицательного числа вместо предполагаемого положительного числа, серьёзно влияет на успешность выполнения логики самой функции/метода. тип данных проверяется не в тесте, а в самой программе, а тест как раз подтверждает устойчивость программы к разным входным параметрам.
@@SweetCoder потому и "спорно", что это не аксиома : ) Python язык динамически типизированный, направленный на улучшение читаемости кода. Конструкции проверки типов в начале функции удлиняют код и снижают его читаемость, хотя бы фактом своего присутствия, что протеворечит смыслу языка. Не логичнее ли тогда просто писать на статически типизированном языке, где это по умолчанию включено? Чтобы некорректный аргумент не передавать в функцию сейчас присутствуют аннотации типов, но даже они не бросают исключения при несоответствии типов, а служат лишь комментарием для разработчика. Вообще, пользователь же не будет напрямую вызывать функции вашего кода, а делать это через gui или api. Вот на этом уровне и должны отсекаться все подобные неожиданности, и просто не должно быть по умолчанию такой ситуации, что в функцию передан некорректный аргумент. Но кстати, если вы хотите таки использовать проверки типов, могу предложить конструкцию "assert isinstance(radius, float)". Согласитесь, так короче и понятнее конструкций типа "if... raise..."?)
вот тут я вообще не могу ни с чем согласиться. Тот факт что Python направлен на улучшение читаемости кода совершенно не означает, что в Python не нужно отлавливать исключения и предупреждать нештатные случаи выполнения программы. Если бы это противоречило духу языка не были бы реализованы try ... except и прочие TypeError. "Не логичнее ли писать на статически типизированном языке?" - нет, не логичнее отсекать все неожиданности на уровне GUI не всегда представляется возможным. А на уровне API всё равно придётся проводить проверку соответствия типов. или там тоже нужно пожертвовать проверкой ради легкочитаемости реализации API ? "не должно быть по-умолчанию такой ситуации, что в функцию передан некорректный аргумент" - такое бывает только в стране эльфов и единорогов. у них как-то получается. у нас, простых смертных - нет. assert isinstance(radius, float) - не является приемлемой практикой даже в этом отдельно взятом примерчике. данные могут быть некорректными по двум осям (либо не числовой тип, либо числовой, но число отрицательное или комплексное) для логирования гораздо удобнее иметь информацию о том, произошла TypeError или ValueError, вместо того, чтобы лог был забит исключительно AssertionError
@@SweetCoder "assert isinstance(radius, float) assert radius > 0" В чем проблема то? Конечно ошибки отлавливать нужно, но это не тот случай. Ведь ошибка и без дополнительной проверки выбрасывается в этом примере, и в чем смысл лишней логики тогда. P.S. к assert можно добавить комментарий вторым аргументом. А api или gui это пример. Короче, где угодно кроме самой функции это лучше обрабатывать.
@@ЮрийАндреевич-т8д я ж написал в чём проблема. AssertionError не даёт классификации того, что именно пошло не так. разные исключения (TypeError, ValueError, etc.) могут обрабатывать по-разному. именно поэтому assert не является Best Practice. Идентифицировать исключения по кастомным "сообщениям" - это, я извиняюсь, детский сад. что дальше? для описания индивидуальной обработки разных исключений будем использовать switch ?
Это можно назвать проще: проверка на дурака)) Правда, не совсем понял, зачем юзать доп. модуль, создавать файл и тд... когда всё тоже самое можно проверить в написанной программе, используя для этого if-ы.
нельзя. добавляя if-ы в программу ты меняешь её код. проверишь с if-ами, предположим, что все хорошо. но как только ты их удалишь - это будет уже другой - не тестированный код. также, обычно для тестов готовят несколько сотен или тысяч тестовых данных. писать для каждого случая if-ы - дурное дело
А смысл писать Юнит-тесты, если тебе все равно придётся прописывать в своем коде те же условия, из-за которых провален Юнит-тест? А откуда ты вообще берешь критерии для Юнит теста?? То есть суть Юнит теста такова: Я конструирую супер-прочный телефон. Делаю сначала говно, иду тестить его путем бросания на асфальт. Он естественно разбивается. И я такой: "ага, надо сделать ударопрочный корпус". А почему бы мне тогда сразу не делать ударопрочный корпус, лол
Действительно, условия и логика должны быть прописаны в ТЗ. В данном случае, почему результат не может быть нулевым или отрицательным? Из приведенного автором видео примера польза юнит-тестирования нулевая и смысл этих тестов не понятен.
благодарю за ссылку, оч. круто снято, но только вот не все по английски рубят) а пока инглишь подтягиваю, - буду на этом канале, имхо- очень хорошая подача материала, спасибо!
Дружище, спасибо большое, всё четко и по делу, ещё и 5 минут.
Боже, ну почему у таких прекрасных видео так мало лайков.. А всякие "Хауди-Хо" набирают по миллиону подписчиков и по 100к лайков...
ну тут я никаких противоречий не вижу: во-первых мой канал еще очень молодой. особенно при непосредственном сравнении. во-вторых: Хауди-Хо действительно прикольный канал, там много интересных, весёлых и необычных видео. я и сам его периодически смотрю. так что, всё закономерно ))
@@SweetCoder еще бы тебе веб камеру сменить, чтобы качество картинки радовало глаз)
@@tetrafen выполнено.
хауди работает на массу
@@flyintie типа, железо тягает?
Просто волшебно рассказал. Просто отлично!!
спасибо за отзыв ))
Спасибо, все очень четко и лаконично.! Почему так мало лайков.
спасибо за отзыв
Что? Я на канале "Нежный кодер"?
Сразу вспомнил момент из "Полицейской академии", когда двое попали в бар "Голубая устрица".
Благодарю за отличный материал, поехал на пикник !
спасибо. люблю твои видосы, и лёгкий, но острый юмор👍
Бро, было бы круто ещё про тестирование БД, Моки и тесты для внешних API ))) А то там уже шкала сложности усвоения документации по unittest мгновенно взлетает по экспоненте)))
для того чтобы тестировать API нужно сначала научиться писать API. рано или поздно дойдём
спасибо тебе человек за этот великолепный ролик. подписался)
на здоровье
Спасибо за ваш труд
на здоровье
Ааааа, Кива с Бужанским прям на своих тупых местах!😆
Спасибо!👍👍👍👍
🙂😉
Привет! Изучаю Python и соответственно пишу очень много всего разного, от а+а до генераторов с функциями и прочего (пока на стадии генераторов и функций). При тесте задачи постоянно приходится ее перезапускать и вводить разные данные, int, float, str, коллекции и тд. Правильно ли я понял из видео что моих ручных проверок в каждой второй задаче можно избежать написав юниттест?
И наверное можно на такой случай написать универсальный тест и просто импортировать его в свои задачи?
Спасибо за видео на канале! Я, конечно же подписан, лайкаю и нажал на колокольчик:)
ты всё правильно понял. после каждого минорного изменения заново ручками проверять как ведёт себя программа при вводе строки, числа, даты и т.д. и т.п. очень долго и дорого. оптимальнее создать скрипт теста, и просто запускать его каждый раз когда внёс изменения.
@@SweetCoder круто. Спасибо большое!
А где про тесты можно посмотреть подробнее?
Просто по мне использовать валидатор входных значений и обработчик исключения куда более правильное решение, но думаю тут не про это.
Спасибо, очень познавательно!
на здоровье
Чётко объяснил )
Спасибо за видео :)
на здоровье
Ящик пива этому гению!!!
тому кто придумал unit-тесты? многие его ненавидят ))
Отличное познавательное видео!
спасибо за отзыв
Спасибо большое. Хотелось бы больше материала по тестам, особенно как писать тесты на приложения из жизни
Лайк за шутки!)
да? ну ок )) спасибо
Спасибо!
на здоровье
класс, спасибо
на здоровье
Уважаемый блогер, здравствуйте. Объясните пожалуйста, как понять от какого класса мы должны наследовать класс, который мы сейчас задаем? Это в какой-то документации прописано или мы придумывать должны? У вас в данном случае наследуется от класса unitest.Testcase. Не понимаю, откуда вы взяли Testcase? Это модуль в классе unitest? спасибо
в данном случае нужно знать или посмотреть в документации. в общем случае наследоваться нужно от того класса, функционал которого нужен тебе в твоём наследнике
@@SweetCoder принял, благодарю
спасибо
на здоровье
Красаучег!
спасибо за отзыв
genius, ты показал максимально обсосанный пример, то как работает программа должно быть определенно на этапе проектирования приложения, на этапе получения данных от пользователя должна быть проработана предварительная валидация данных. Если приводить примеры тестирования, то можно выделить пару примеров, например тестировать поведение функции, при вводе условно верных данных, например вы пишете фикцию для каких то вычислений, она безумно сложная и занимает 20 строк кода, и выполняется секунд пять, вы её тестируете сопоставляя с заведомо верными данными, но программист B, решает что данная функция является узким местом программы из за частого его вызова программа тратит много времени на вычисления. После внесения корректировок программистом B программа начала работать и правда быстрее, но благодаря тестам может всплыть что она выполняет задачу с ошибкой, например при вводе отрицательных чисел или float или 0. Так что во многом тесты помогают разработчикам быть уверенным что их код работает так как ожидается.
Но есть второе применение которое так же очень важное, например для поддержки приложения, мой пример, я написал парсер для загрузки аудиокниг, и через 2 месяца решил скачать себе новую книгу, по итогу загрузчик ложился с ошибкой в о время загрузки, по логам проблема была в модуле async_downloader и если бы не тесты я бы искал проблему там, но благодаря что я заранее на каждый класс написал тесты стало ясно что структура html немного поменялась, и вместо ссылок на аудиофайлы я получал ссылки на картинки. Которые успешно передавались в модуль загрузчик. Так что тесты нужны так же для поиска ошибок в программе после изменений внешних факторов.
классно, не знал об этом
о чем именно?
@@SweetCoder о юнит тесте
до этой темы во время обучения доходят не все. а вообще это нормально. знать всё - невозможно.
ну, теперь можно идти гробить печень)
да, только осторожно
коммент ради продвижения канала
Доброго.
Почему-то тесты по программе из примера:
self.assertRaises(TypeError, circle_area, 'df')
self.assertRaises(TypeError, circle_area, [12,12])
self.assertRaises(TypeError, circle_area, {"1":"123"})
не выдают ошибку.
Однако вот этот тест выдал ошибку.
self.assertRaises(TypeError, circle_area, True)
Запуск делал до покрытия тестами основного кода.
не знаю поможет ли тебе это спустя год)
в общем не все объекты можно сравнивать с нулем.
собственно например массив с int сравнить нельзя и эта операция итак выдаст ошибку TypeError.
Поэтому тест выполняется. А вот True - булево значение, его можно сравнить с int (он преобразуется в единицу)
Помню точно такой же видос на английском канале смотрел ;)
а в том видосе такой же симпатяга был? ну, а если серьезно: пример уж очень хороший. наглядный. поэтому и довольно распространенный
1:35 Бузова и ещё некоторые могут обидеться ;-)
не могу сказать, что меня это сильно волнует ))
кива не глупый. кива уже кандидат наук!))
да, "глупый" какое-то неподходящее слово. слишком мягкое
Как фреймворк видит методи, которие начинаются на test_?
Вопрос, а как ты запускаешь код из консоли атома, или это сторонний плагин?
Отпиши если не сложно)
не сложно. на канале есть видео с обзором подборки плагинов, которые я постоянно использую. плагин называется platformio-ide-terminal и он полностью копирует функционал родной консоли операционной системы. это не единственный вариант, есть и другие. но мне понравился именно этот из-за возможности настройки цветовых схем
Это прям как "сам себе QA"
на самом деле это не отменяет необходимость в специалистах QA, просто немного экономит время разработки
У меня при вводе python -m unittest "название файла".ру, выдает ошибку. Говорит, файл не найдет. Что можно с этим сделать?
скорее всего дело в названии файла. либо ты запускаешь его не из той папки в которой он находится
@@SweetCoder Спасибо, разобрался 👌. Путь надо было доуказать
1:37 лайк!
Ну можно было что-нибудь другое протестить, а не просто у Сократики слизывать почти строчка в строчку
подписался👍
🤝👍
У меня почему то Ran 0 test in 0.000s.
То с чем св'язано?
Популяризация написания юнит тестов - дело хорошее и нужное. Но (ИМО), без TDD теряется до 70% профита от юнит тестов.
по поводу процентов ничего не могу сказать. я не тестировщик. но мне трудно себе представить как можно реализовать TDD без unit-тестирования. чтобы перейти к масштабной методологии TDD сперва необходимо ознакомиться с её составными частями. поэтому мне кажется абсолютно логичным сначала познакомиться с unit-тестами, а потом уже со всем остальным
@@SweetCoder я думаю нам есть смысл сделать совместное видео на тему. TDD - это это один из спобов делать Unit тестирование :) И кстати, это как раз не про тестирование (поэтому и называется test-driven DEVELOPMENT)
Вот тут кстати неплохой пример TDD ua-cam.com/video/NWZHcjQJ6Ds/v-deo.html
Проверка типов довольно спорная тема в питоне. Как по мне, если вы это предпочитаете, то лучше использовать какой-либо статически типизированый язык. Кроме того может сложиться впечатление, что юниттесты - это про проверку типов, хотя они скорее для тестирования логики самой функции/метода.
а почему проверка типов это спорная тема? я может быть действительно чего-то не знаю.
юнит-тесты, конечно же, не про проверку типов, однако даже в этом плохеньком примерчике явно видно, что использование строки или отрицательного числа вместо предполагаемого положительного числа, серьёзно влияет на успешность выполнения логики самой функции/метода. тип данных проверяется не в тесте, а в самой программе, а тест как раз подтверждает устойчивость программы к разным входным параметрам.
@@SweetCoder потому и "спорно", что это не аксиома : ) Python язык динамически типизированный, направленный на улучшение читаемости кода. Конструкции проверки типов в начале функции удлиняют код и снижают его читаемость, хотя бы фактом своего присутствия, что протеворечит смыслу языка. Не логичнее ли тогда просто писать на статически типизированном языке, где это по умолчанию включено? Чтобы некорректный аргумент не передавать в функцию сейчас присутствуют аннотации типов, но даже они не бросают исключения при несоответствии типов, а служат лишь комментарием для разработчика. Вообще, пользователь же не будет напрямую вызывать функции вашего кода, а делать это через gui или api. Вот на этом уровне и должны отсекаться все подобные неожиданности, и просто не должно быть по умолчанию такой ситуации, что в функцию передан некорректный аргумент.
Но кстати, если вы хотите таки использовать проверки типов, могу предложить конструкцию "assert isinstance(radius, float)". Согласитесь, так короче и понятнее конструкций типа "if... raise..."?)
вот тут я вообще не могу ни с чем согласиться.
Тот факт что Python направлен на улучшение читаемости кода совершенно не означает, что в Python не нужно отлавливать исключения и предупреждать нештатные случаи выполнения программы. Если бы это противоречило духу языка не были бы реализованы try ... except и прочие TypeError.
"Не логичнее ли писать на статически типизированном языке?" - нет, не логичнее
отсекать все неожиданности на уровне GUI не всегда представляется возможным. А на уровне API всё равно придётся проводить проверку соответствия типов. или там тоже нужно пожертвовать проверкой ради легкочитаемости реализации API ?
"не должно быть по-умолчанию такой ситуации, что в функцию передан некорректный аргумент" - такое бывает только в стране эльфов и единорогов. у них как-то получается. у нас, простых смертных - нет.
assert isinstance(radius, float) - не является приемлемой практикой даже в этом отдельно взятом примерчике. данные могут быть некорректными по двум осям (либо не числовой тип, либо числовой, но число отрицательное или комплексное) для логирования гораздо удобнее иметь информацию о том, произошла TypeError или ValueError, вместо того, чтобы лог был забит исключительно AssertionError
@@SweetCoder "assert isinstance(radius, float)
assert radius > 0" В чем проблема то?
Конечно ошибки отлавливать нужно, но это не тот случай. Ведь ошибка и без дополнительной проверки выбрасывается в этом примере, и в чем смысл лишней логики тогда.
P.S. к assert можно добавить комментарий вторым аргументом. А api или gui это пример. Короче, где угодно кроме самой функции это лучше обрабатывать.
@@ЮрийАндреевич-т8д я ж написал в чём проблема. AssertionError не даёт классификации того, что именно пошло не так. разные исключения (TypeError, ValueError, etc.) могут обрабатывать по-разному. именно поэтому assert не является Best Practice. Идентифицировать исключения по кастомным "сообщениям" - это, я извиняюсь, детский сад. что дальше? для описания индивидуальной обработки разных исключений будем использовать switch ?
Это можно назвать проще: проверка на дурака))
Правда, не совсем понял, зачем юзать доп. модуль, создавать файл и тд... когда всё тоже самое можно проверить в написанной программе, используя для этого if-ы.
нельзя. добавляя if-ы в программу ты меняешь её код. проверишь с if-ами, предположим, что все хорошо. но как только ты их удалишь - это будет уже другой - не тестированный код. также, обычно для тестов готовят несколько сотен или тысяч тестовых данных. писать для каждого случая if-ы - дурное дело
🤦
сЭрвис блеят)))))))
тут схематично приведена лишь часть сервиса, чтобы проиллюстрировать идею тестирования
а в чем разница между unittest и pytest, например?
а что по этому поводу говорит гугл?
@@SweetCoder Много бестолкового. Хотелось бы получить выжимку и краткое объяснение. желательно в видео.
@@liho26 возможно когда-то дойдут руки и до сравнения тестировочных модулей
@@SweetCoder Договорились. Когда руки дойдут, тогда на одного подписчика станет больше на этом канале.
Используйте isinstance() вместо type() %)
Урок полезный, спасибо)
ты абсолютно прав. дурацкая привычка. спасибо за отзыв
up
как на пайтон тестить допустим c# код??
такое возможно только используя специальные интерфейсы, например браузер или API
АХАХАХАХ ЗА дегтярева в списке глупых отдельный плюс!))
"Нежный" кодер
Похоже тема поживее пошла, тут уже комменты подгребают... Даёшь 100 000 лайков и 100 500 комментов!
всё будет. вот так по зёрнышку...
Я не совсем понял хотя посмотрел его несколько раз
Нифига не понял)))
значит еще не настало твоё время ))
Принты всера вно лучше и удобней ))))))))))
А смысл писать Юнит-тесты, если тебе все равно придётся прописывать в своем коде те же условия, из-за которых провален Юнит-тест?
А откуда ты вообще берешь критерии для Юнит теста??
То есть суть Юнит теста такова: Я конструирую супер-прочный телефон. Делаю сначала говно, иду тестить его путем бросания на асфальт. Он естественно разбивается. И я такой: "ага, надо сделать ударопрочный корпус". А почему бы мне тогда сразу не делать ударопрочный корпус, лол
Действительно, условия и логика должны быть прописаны в ТЗ. В данном случае, почему результат не может быть нулевым или отрицательным? Из приведенного автором видео примера польза юнит-тестирования нулевая и смысл этих тестов не понятен.
@@ИвфИвф и я о том же
Серьезно?
ua-cam.com/video/1Lfv5tUGsn8/v-deo.html&ab_channel=Socratica
ну да ))
@@SweetCoder первоисточник круче )
благодарю за ссылку, оч. круто снято, но только вот не все по английски рубят)
а пока инглишь подтягиваю, - буду на этом канале, имхо- очень хорошая подача материала, спасибо!
как программисты могут пить алкоголь. мне кажется, это негативно влияет не только на печени, но и на мозге
йад
не понятно
@@SweetCoder все понятно. Хорошо рассказываешь.
@@sg6630 ок. спасибо за отзыв.
@@SweetCoder спасибо за видосы! Я учусь кодить и твой материал помогает! Удачи тебе!
@@sg6630 приятно слышать. желаю успехов!
ты настолько много куришь что даже через видео запах идёт голимый
ты зачем такле говориш?
Кива ввёл отрицательный радиус
Спасибо!!!
на здоровье