Василий Банников

Если у вас с навыками и знаниями математики нет проблем, то вы могли бы заметить, что ответ на ваш вопрос:

Может ли отсутсвие высшего образования в области математики препятствовать в каких то моментах продвижению и работе в DS?

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

Так что - да, может.

Соглашусь с предыдущими комментаторами, пример СЛИШКОМ высосан из пальца, чтобы по нему давать какие-то рекомендации.
Но в целом, бак должен быть отдельным объектом в составе машины, а никаким не "аругментом".
И у него может быть метод consumeFuel(miles)
Который может принимать длину дороги в качестве аргумента, и уменьшать количество топлива в соответствии с заложенной формулой.

Car.Tank.fillMax()
print Car.Tank.getLevel()
Car.Тank. consumeFuel(Road.length)
print Car.Tank.getLevel()

По поводу последнего варианта - всегда исходите из здравого смысла. Может ли быть дорога частью автомобиля? Нет, это очевидная бессмыслица. Дорога может быть частью поездки. Как и автомобиль. Вот в рамках объекта Trip они вполне могут взаимодействовать друг с другом.

Вообще, тут важно сразу понять, что ООП гораздо сложнее "базового" процедурного программирования, которое в принципе может осилить любой. Все эти циклы, условные переходы, функции, базовые алгоритмы, последовательное выполнение команд. Или даже асинхронное.

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

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

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

https://learn.microsoft.com/en-us/aspnet/web-forms/
https://www.pluralsight.com/ - с VPN

1. "Beginning ASP.NET 4.5.1: in C# and VB" by Imar Spaanjaars: Эта книга является прекрасным ресурсом для начинающих. Она покрывает основы ASP.NET Web Forms, включая создание страниц, использование элементов управления, работу с базами данных и другие аспекты разработки веб-приложений на ASP.NET Web Forms.

2. "Professional ASP.NET 4.5 in C# and VB" by Jason N. Gaylord, Christian Wenz, et al.: Это обширное руководство по ASP.NET 4.5 включает в себя различные темы, включая ASP.NET Web Forms. Книга рассматривает множество аспектов, включая создание пользовательского интерфейса, обработку данных, безопасность и тестирование.

На старом сервере нужно выполнить php -m и на новом установить все модули, которые там были. Ну или не устанавливать, а отлавливать ошибки по одной и ставить только реально используемое.

Возможно, вам надо что-то типа этого:

SELECT * FROM (
  -- Внутренний подзапрос, применяющий оконную функцию LAG() к таблице calls
  SELECT *,
    LAG(duration) OVER (PARTITION BY cid_from ORDER BY call_time) AS previous_duration
  FROM calls
) AS subquery
-- Основной запрос, фильтрующий результаты
WHERE duration > 20 -- Длительность звонка больше 20 минут
  AND previous_duration < 2; -- Предыдущая длительность меньше двух минут

Если не делать except, который проглатывает исключения, то можно в бэктрейсе увидеть причину.

Нет, не надо. Настройки доступа к registry - это сущность кластера, и все ноды знают о них.
Надеюсь конечно, что "Через мастер разворачиваем какое то приложение из приватного registry" не значит, что вы зашли по ssh на мастер ноду и установили там приложение в docker :-)

Бизнес-логика - это то ради чего создается приложение.
На примере калькулятора, это все, что связано с расчетами: сложение, вычитание, деление и т.д.
Бизнес логику всегда можно описать в формате "юзер-стори".

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

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

Владимир, вы бы еще архитектуру хелловорлда взялись "понимать".
Если хотите понять в двух словах, то можно применить такой принцип: бизнес-логика - это то, ЧТО должно выполнять приложение. А логика приложения - то, КАК оно это выполняет. Гругря, "по заказу формируются документы в формате XLSX и PDF" - это бизнес-логика. А вот запрос к БД за данными заказа, разбор шаблона документа, использование библиотек для генерации файлов нужного формата - это логика приложения. Отталкиваясь от такого примитивного понимания, можно разглядеть уровни в коде: где программист размахивает человекопонятными блоками и выполняет техзадание, а где - копается в байтах, соединениях и потоках вывода. Если мы одно от другого отделяем, то оказывается, что низкий уровень для большинства задач один и тот же и его можно опять-таки собрать в библиотеки и практически без изменений использовать там, где понадобилась другая бизнес-логика, но использован тот же технологический стек.

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