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

https://cyberleninka.ru

https://www.researchgate.net

https://scholar.google.com/

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

Видео можно искать так
https://research.google.com/youtube8m/explore.html

Интересные рассмотренные статьи необходимо заносить в список с небольшой аннотацией.Такой список позволит в большей степени понимать и ориентироваться в предметной области. Например,

1. <ссылка>. Работа на "хорошо". В работе есть данные по нейросети, которая с 80% точностью распознаёт человека в маске. Ссылка на программу есть, на датасет нет. Напрямую применить нельзя, но можно взять часть про нормализацию кадра

2. <ссылка>. Выглядела на "отлично", по факту бред. Литературы нет, написано на коленке

Пример:
1. https://cyberleninka.ru/article/n/mnogokriterialnaya-otsenka-kachestva-fotografiy/viewer В статье рассматриваются различные критерии качества изображений, а также их количественная оценка. Из полезного: оценка резкости изображения, что может быть полезно для выделения одного наиболее информативного кадра в потоке на заданном промежутке времени. Есть математические операции по подсчету, а также примеры использования OpenCV для получения количественных оценок

2. https://cyberleninka.ru/article/n/algoritmy-predobrabotki-izobrazheniy-v-sisteme-identifikatsii-lits-v-videopotoke/viewer В статье описывается алгоритмы предобработки изображений для их последующей обработки. Сюда входит
- Обесцвечивание
- Выравнивание гистограммы яркости изображения
- Выравнивание изображения относительно вертикальной оси симметрии лица (по возможности)
- Масштабирование

3. https://www.researchgate.net/publication/341892534_VIDEO_DATA_QUALITY_IMPROVEMENT_METHODS_AND_TOOLS_DEVELOPMENT_FOR_MOBILE_VISION_SYSTEMS В статье производится сравнение подходов однопоточной и многопоточной мобильной обработки видео, зависимость скорости обработки видео от его разрешения, а также приводятся примеры перехода из пространства RGB в YUV на OpenCV с целью оценки освещенности изображения

4. https://github.com/shubham0204/Age-Gender_Estimation_TF-Android Приложение под Android, определяющее пол и возраст человека на изображении. Прилагаются скриншоты результатов распознавания. Если с точностью определения пола все хорошо, то c определением возраста как-то не очень (числовые оценки не приводятся). Есть ссылки на датасет и блокноты в Colab, которые экспортируют модели TFLite (используется в приложении для Android). Из полезного можно вынести на мобилку модель для определения пола.

#sudo #edu #devfm

Пятничное развлекательное.

Один из самых известных скетчей на тему постановки задачи неспециалистом – 7 красных линий, в оригинале The Expert.

PS: а решение задачи существует
PPS: современное образование - вообще проблема

#fun #edu #sudo

Сегодня рассмотрим плохую статью про выбор способа изучения программирования. За неделю статья получила 20 минусов, а автор 7 минусов в карму. Давайте критически посмотрим, где есть проблемы.

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

Самое мясо начинается дальше. Автор формирует таблицу сравнения "самых популярных языков". Сразу возникает много вопросов, которые следует учесть студентам в рамках работы над курсовыми и дипломными работами.

1. Выбор ЯП. Почему эти 6 языков и по какой метрике они самые популярные? Например, по TIOBE шестым по популярности идёт Visual Basic. По версии PYPL С и С++ объединены, а в топ шесть входят JavaScript (третий) и PHP (шестой). Согласно обзору от stackoverflow в лидерах JavaScript, SQL, Python, Java, C#, bash. HTML я убрал как язык разметки, а не программирования, а TypeScript грубо считаю диалектом JS.
Кстати, по этому же обзору Docker — самая популярная технология в 2022 году, отмеченная как fundamental tool for Professional Developers, как и git в обзоре 2021 года.

Как можно выбирать?
— сослаться на рейтинг
— взять набор, например, разных представителей — один компилируемый язык, один интерпретируемый, один с типизацией, второй без
— субъективно отобрать произвольные 6 языков. Почему эти? Я автор, я так вижу. Но не надо говорить тогда, что это самые популярные ЯП. Вы взяли их, так как они в вашем информационном поле

2. Критерии для сравнения. Вот тут совсем дичь. "Скорость обработки"? А в чём мы измеряем и на какой задаче? Например, Python из-за GIL в многопоточном варианте для cpu-intensive задач — просто ужас.

Как минимум, критерии должны отвечать двум требованиям:
— полнота, то есть все важные характеристики должны быть учтены
— достаточность, то есть никакой критерий выкинуть нельзя

Критерии должны быть подробно описаны и словами с обоснованием полноты и достаточности. Например, если мы ищем ЯП для формирования программы обработки таблицы со 100 записями и 5 полями каждая, то критерий "производительность" нам не нужен. Если все альтернативы по критериям имеют одинаковую оценку, то критерий плохой и должен быть удалён.

Если мы говорим о выборе ЯП для начинающих разработчиков, то скорость обработки нам тоже не требуется как критерий. Что нам может быть важно? Небольшое количество конструкций для запоминания, отсутствие магии, доступность IDE для работы, понятные сообщения об ошибках и быстрая обратная связь (когда компилятор бьёт по рукам и говорит, где конкретно ошибка), доступность литературы и иных обучающих материалов. Вот эти пункты могут выступать кандидатами в критерии.

3. Оценки по критериям. Читабельность у C# 7, а у Python 6? Мммм? А у C++ тоже 6? А вы видели крестики-нолики на шаблонах? Как это оценивалось? Идеальный критерий имеет объективную численную оценку. В Python 33 ключевых слова, в С++ таких слов 92. Это факты. Субъективная оценка — зло, которого следует избегать. Если что-то надо-таки оценивать, то требуется множество экспертов и какой-то формализованный способ сбора мнений, например, метод парных сравнений, который использовали в фильме "Социальная сеть" 2010 года (сайт для сравнения девушек как студенческий проект Цукерберга).

Выбор и обоснование критериев — трудозатратная задача. Но без толковых критериев весь сравнительных обзор становится бесполезным и идёт в /dev/null.

#sudo #edu #devfm

Ключевые аспекты хорошего Dockerfile

— Порядок команд важен. Вверху редко меняющиеся сущности (ставим зависимости apt-get, pip), внизу – часто меняющиеся (копируем ваш код)
— Слои нарастают и не удаляются. Если слой генерирует «мусор» – удалять нужно в этом же слое, иначе место не уменьшится
— Пользуемся готовыми образами на dockerhub

Если пробросить внутрь контейнера каталог с вашим кодом – вы получите dev-контейнер, сразу подхватывающий изменения кода. Исполняемый скрипт запустится новой версии, веб-сервер сам перезапустится.

И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.
#skills #sudo #devfm

Online resources to learn how to code

Основной источник знаний — это техническая документация. В целом, man — всему голова. Отсюда возникает необходимость в английском языке, как интернациональном языке разработчиков. Это как латынь у медиков — в IT без английского никуда. По крайней мере, пока нас не поработят китайцы.

А ваш проект должен содержать подробное readme.

#sudo

Databases среди Professional Developers. Всегда переключаем на Professional Developers, потому что лучшее надо смотреть у лучших. Те, кто Learning to Code, вам подсказать не смогут

Неплохо бы знать парочку баз данных отсюда. Имеет смысл изучить реляционную (например, PostgreSQL) и документную (например, MongoDB) базы.

Во всех опросах можно было выбирать несколько галочек, так что сумма больше 100%

#sudo

Other tools среди Professional Developers

Варианты, мягко говоря, странные. Менеджеры пакетов npm, yarn, homebrew я бы исключил (это что-то уровня IDE), как и платформы для игр Unity, Unreal Engine (они должны идти в frameworks).

Среди оставшегося доминирует контейнерная виртуализация Docker и система управления контейнерами Kubernetes. Без докера никуда, господа.

#sudo

Version control systems среди Professional Developers

Git 97%, SVN 6%. Варианты "без системы контроля версий" и mercurial менее 3% в сумме.

Не умеешь в Git? Ты не разработчик

#sudo

Когда код не работает, то понять проблему помогут следующие способы:
1. Метод пристального взгляда. Полезное упражнение для мозга – попытаться в голове построчно воспроизвести код и состояния всех переменных
2. Отладка. Воспользоваться IDE или сторонними инструментами для пошагового запуска с контролем выбранных переменных. Этот способ следует освоить, пользоваться горячими клавишами и точками останова. Незаменим при разборе чужого кода или сложных структур данных
3. Юнит-тесты. Вместе с кодом важно писать изолированные тесты, покрывающие ту функцию, над которой вы сейчас работаете. Выгодное отличие от отладки – накопительный эффект. Чем больше уже написано тестов, тем меньше область поиска ошибки
4. Отладочные принты. Выводить нужные переменные. Детский способ вникания в код. Почему детский? Есть альтернатива лучше по всем параметрам
5. Логгирование. Это отладочная печать на стероидах. Можно сконфигурировать выводимое сообщение (добавить время и дату, добавить название вызываемого модуля и функции и многое другое). Можно настроить уровень предупреждений. В info писать важное (например, изменение состояния в базе данных), в error писать ошибки, а в debug – нужное для отладки. Прелесть в том, что debug убирать не придётся. В конфиге настраиваем писать только info и выше, и в результате debug выполняться не будут. Удобно
Про логгирование недавно был пост в канале по питону

Наилучшим сочетанием я считаю 3, 5, 1 – именно в таком порядке. Всегда писать тесты, часто использовать логгирование и использовать мозг

#sudo #procode #devfm

Одним из вариантов безопасной пересылки данных является передача зашифрованного rar/zip архива с паролем. В rar есть удобная галочка "шифровать имена файлов", когда названия файлов внутри архива не показываются. Но rar формат проприетарный, что плохо с точки зрения криптографии и является дурным тоном. Берём zip.

О пароле можно договориться заранее. Если пересылка регулярная, на помощь может прийти одноразовый блокнот. Менее безопасным является пересылка архива по одному каналу связи (мессенджер), а пароля – по другому (СМС, почта, другой мессенджер).

Надёжный пароль состоит не менее, чем из 20 символов. Отличный пароль – набор из 4+ английских слов. Изменение регистра и спецсимволы приветствуются. Примеры хороших паролей:

HowAwesomeHumanBrain
ComputerGamesAreNotBad
Many%Coders%Can%Code%Windows

Такие пароли легко запомнить и сложно перебрать (и bruteforce, и перебор по словарю за разумное время не производится).

PS: Идеальным будет пароль вроде JVoZlEoHk~?rsnJFCZ1pJ%IEp, но его невозможно запомнить и тяжело набирать. Тут могут помочь менеджеры паролей, но это другая тема.

#sudo #skills #devfm

Как сформировать надёжный мастер-пароль для менеджера паролей, о которых мы писали ранее? Самым простым, при этом самым неломаемым вариантом будет кусок стихотворения со всей пунктуацией.

Я вас любил: любовь ещё, быть может,

Это почти идеальный пароль. Можно ещё добавить спецсимволов вместо пробелов или ещё как-то усложнить текст одному вам понятным образом.

PS: Не используйте свои любимые цитаты. Выбранный фрагмент должен иметь нулевую связь с вами, как личностью.
#skills #sudo #devfm

Год назад на хабре вышла занятная статья Письмо преподавателям вузов. Хватит губить будущее ИТ. В ней модератор хабра поднимает следующую проблему. Кто-то из преподавателей сделал автомат за зачёт при публикации на хабре, которая набрала +4 рейтинга. В результате на хабр набежала толпа студентов с материалами разного уровня, в том числе со слёзными просьбами пропустить статью из песочницы.

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

Хотите я расскажу, что из вуза реально нужно в работе?

— Умение работать с литературой, источниками и технической документацией, отличать фуфло от профессиональных материалов, уметь определять актуальность и совместимость информации с реальной рабочей задачей.
— Знание фундаментальных основ специальности и специализации. В ИТ знания нужно обновлять быстро и непрерывно, поэтому важно иметь хорошую основу, на которую будет ложиться актуальная теория и практика.
— Умение анализировать, синтезировать, декомпозировать идеи и задачи, выделять главное.
— Способность представить свой труд — на конференции, в статье на Хабре, в печатном издании, на ковре у директора, на митинге перед тимлидом.
— Навык здравой оценки своих знаний и пробела в них.

Такие вот дела. Напомню, что мы рассказывали правильный порядок анализа предметной области.
#edu #sudo

Посмотрим на свежую статью по сравнению брокеров сообщений — систем, реализующих шаблон издатель-подписчик (pub/sub, publisher-subscriber). Шаблон позволяет реализовать асинхронную обработку сообщений с множественными писателями и читателями. Например, загрузка видео на youtube требует его переконвертацию под множество размеров (144p, 240p и так далее). Такое поведение можно реализовать на брокере сообщений — вкинули пул заданий на преобразование, и эти задания будут обрабатывать те сервера, которые сейчас свободны. Полученную схему можно относительно легко масштабировать, добавляя новые узлы-обработчики или сервисы-загрузчики новых видео.

Статья A Fair Comparison of Message Queuing Systems сравнивает Kafka, RabbitMQ, RocketMQ, ActiveMQ и Pulsar. Статья является отличным примером правильного сравнительного анализа. Дан обширный ввод в предметную область. Обзор публикаций маловат, но это единственный недочёт. Далее выдвинуты обоснованные критерии сравнения, разделённые на блоки: особенности (язык, сообщество, протоколы, ...), качество обслуживания (надёжность, масштабируемость, ...), производительность (задержки и пропускная способность). Для каждого из критериев написан абзац текста с описанием и обоснованием важности. Ранее мы критиковали статью с хабра за невнятные критерии. Теперь у нас есть отличный пример правильной формулировки критериев сравнения. Следом идёт сжатое описание каждой из сравниваемых систем, по каждой сформулированы плюсы и минусы.

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

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

#sudo #edu #devfm

Корчеватель ломает науку

Любую нетривиальную задачу по разработке следует начинать с анализа предметной области (наш пример разбора статей в области видеоаналитики) и просмотра доступных альтернатив на github и gitlab. Анализ предметной области по рецензируемым научным изданиям позволяет получить защиту от переизобретения велосипеда, сразу взять хорошее решение и дорабатывать его.

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

Но не все научные издания одинаково хороши. Как оценить "хорошесть" издания? Неплохой вариант выявления плохих — продемонстрировать, что журнал принимает к изданию фигню. Но просто написать фигню — на наш вариант. Давайте фигню сгенерируем. Так родился Корчеватель, написанный преимущественно на perl проект по генерации псевдонаучных текстов. Он есть на github (без документации, как мы любим). Но результаты хороши — статья с наукообразным текстом, графиками и литературой, которая была неоднократно принята к изданию с положительными отзывами рецензентов у нас и за рубежом. Таким способом можно выявлять плохих рецензентов и ужасные журналы.

Нельзя не упомянуть яндекс.рефераты. Выбираете набор тематик и получаете фрагмент безумного текста. Залипательно. Маркетинг&Математика выдаёт тексты, похожие на половину пресс-релизов компаний:

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

Организация службы маркетинга раскручивает стремящийся рейтинг. Медиаплан, конечно, консолидирует убывающий рейтинг. Баланс спроса и предложения, не вдаваясь в подробности, раскручивает минимум, оптимизируя бюджеты.

#edu #sudo #devfm

Мы сняли часовой стрим по созданию небольшого проекта на python для начинающих разработчиков. Идея проста — прочитать в csv-файле ФИО и login и проверить существование этого login на gitlab. Но тут vim, проект на gitlab, консольный git, исключения, google docstring, правильная структура проекта и тесты — всё слилось в едином экстазе.

Все покрытые темы — в описании под видео.

#youtube #python #devfm #sudo

Навигация по каналу

#sudo — наиболее важные посты. Начать знакомство с каналом рекомендуем с них.
#devfm — материалы собственного производства. Не просто аннотации, а наши мысли, статьи и видеоролики.

#python — фокусируемся на самом языке и его библиотеках.
#codereview — разбираем код, находим и устраняем проблемы, превращаем плохой код в хороший.
#procode — о профессиональной разработке и тестировании вне зависимости от языка.
#skills — о смежных с разработкой технических навыках, необходимых для работы и резюме. Инструменты (в том числе git, bash, docker), командная работа, безопасность и прочие фундаментальные вещи.
#systemdesign — проектирование систем и построение архитектуры.
#tools — полезные инструменты для работы.
#edu — полезные нетехнические навыки. Об обучении, продуктивности, английском, умении искать и обосновывать решения.
#youtube — видеоматериалы.
#fun — пятничное развлекательное и культурный код. Обзор художественных фильмов #films, книг #books, комиксов #xkcd и прочего.

#backup — лучшие посты месяца.

Какие знания нужны разработчику?

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

Одним из вариантов визуализации подобных знаний является roadmap. Это такая "дорожная карта" с пометками, что следует освоить.

Самым популярным проектом является roadmap.sh. В их github 215к звёзд, настолько это общее место для индустрии. Прописаны roadmap для самых разных специализаций и технологий. Недавно к каждому навыку они стали прикреплять пачку статей и видео из изучения.

Roadmap позволяет выявить пробелы в текущих знаниях и наметить актуальные вопросы для изучения.
#sudo #edu

Преодолеваем постоянное откладывание дел

Для разгрузки оперативной памяти я все будущие задачи вношу в таск-менеджер. Независимо от объёма задачи всё должно быть записано, чтобы не держать в голове. Но дальше возникает большая проблема — некоторые задачи после внесения в таск-менеджер я не делаю никогда, постоянно отодвигая на "когда-нибудь потом". Это приводит к большим неудобствам. Например, вторая часть стрима python student уже три месяца откладывается. Проблема в том, что назначение подобной задачи "на сегодня" плохо помогает, так как задача большая и сложная, подступиться к ней сложно.
Мой опыт преодоления такой:

✅ Декомпозирую задачу. Продумывание задачи и выделение небольших шагов по её выполнению переводит задачу из разряда "ух, страшное и большое" в "хм, вот этот шаг займёт полчаса и даже понятно, как его сделать".

Давайте на примере. Задача "снять ролик python students, часть 2". Декомпозируем:
— решить, какие темы включить в ролик
— прописать сценарий
— прописать текст
— снять ролик
— смонтировать ролик
— расставить текстовые подсказки по ролику
— подкорректировать аудиодорожку
— выложить ролик

Прелесть такого плана в том, что каждая задача мотивирует сделать следующую. Если я нашёл темы для ролика, то уже хочется написать сценарий. Когда готов сценарий, то прописать текст уже несложно.

Если после декомпозиции я не приступаю к задаче, то тут два варианта: либо задача по факту мне не нужна и её нужно выкинуть, либо я плохо декомпозировал, и тогда надо раздробить её на более мелкие подзадачи.

Для меня главный фактор откладывания задачи — её неясность. Дробление задачи позволяет неясность устранить. Задачи должны быть такого размера, чтобы минимизировать напряжение мозга: взял и сделал.

Еще один житейский пример: в машине загорелась лампочка "долить охлаждающую жидкость".
Уже на опыте я не заношу задачу: "Съездить в сервис и долить жидкость". Куда ехать? Когда ехать? — вот такие вопросы у меня будут возникать и я точно буду её откладывать.

Я ставлю задачи:
— Выбрать сервис для замены жидкости (смотрю отзывы на картах)
— Позвонить и договориться о времени (узнать цену, сколько займёт по времени, после разговора записать адрес)
— Поехать в сервис на замену жидкости <— по факту это та же задача, но только теперь у меня нет к ней вопросов, просто беру и делаю.

Обратите внимание на подсказки в скобках, они позволяют в момент решения задачи дополнительно не думать: А как выбрать сервис? А что нужно дополнительно уточнить, когда буду звонить?

Полезны ещё несколько аспектов:
✅ При составлении плана учитываю будущую загрузку, не планирую 40 задач по часу каждая на воскресенье. Приходит с опытом. Или не приходит.

✅ Учитываю приоритет задачи. Если задача важная / выгодная / полезная, то планирую её пораньше.

✅ Умеряю перфекционизм. Часто надо сделать хорошо, а не идеально. Опускаться до уровня "кое-как" не всегда оправданно, но иногда и это годится.

✅ Для меня ещё работает практика начать чуть-чуть. Если к чему-то не могу приступить, просто ставлю себе установку — начну и 15 минут поделаю. Обычно после такого начала продолжаю делать задачу. А если нет, то не расстраиваюсь, значит задача не такая нужная.

В дополнение вспомним про хорошую и плохую прокрастинацию от Пола Грэма. Это когда ты занят, но не тем.

А еще я каждый день анализирую список своих задач, но это тема отдельного поста.
#sudo #devfm #edu

Принципы, которыми стоит руководствоваться

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

Эти принципы даются с высоты Solution Architect. Мы выделили принципы, применимые для любого специалиста и которые сами постоянно применяем на практике.

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

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

Решайте конкретную проблему
Всегда старайтесь узнать цель разрабатываемой системы, максимально дотошно допытывайтесь до требований. В статье хорошо проиллюстрирован этот тезис.

Мы добавим, что не нужно пытаться продумать на 100 шагов вперед. Это внесёт излишнюю и ненужную сложность в систему, а когда требования кардинально поменяются (а они точно поменяются) окажется, что сложность накручена не там.

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

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

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

Многое, о чём говорит автор — знакомо и понятно. В статье есть еще несколько советов, а приятное изложение благоволит к прочтению :)
#sudo #edu

ООП на простых примерах

В 40-минутном видео аккуратно объясняют три кита объектно-ориентированного программирования. Примеры даны на TypeScript, но понятны любому разработчику. Автор аккуратно иллюстрирует необходимость ООП, рассказывает про инкапсуляцию, наследование и полиморфизм. Покрыты даже относительно сложные вещи вроде параметрического и ad-hoc полиморфизма.

На трёх китах ООП автор не заканчивает. Вторая половина ролика повествует о композиции и агрегации на примере автомобиля с двигателем и колёсами, об абстрактных классах и интерфейсах, и даже немного о дженериках. Завершает изложение реализация паттернов Dependency Injection и Singleton. При этом Singleton во многих случаях является антипаттерном и мы не рекомендуем его применять.

Обратите внимание, как автор умело использует IDE для автогенерации сеттеров и геттеров. Не забывайте, что IDE — ваш добрый друг, который много чего умеет.

Про нюансы getattr и setattr в питоне мы делали отдельные посты.

#sudo #youtube #procode