_

ну DTO это формат данных которые передаются по сети
https://docs.nestjs.com/controllers#request-payloads

class UserDto {
  name: string;
  password: string;
}

@Post()
createUser(user: UserDto) {}

entity это typeorm'ная схема для бд
https://typeorm.io/#/entities

interface это схема объекта для typescript

Есть волшебный метод, который называется "декомпозиция". Мои наблюдения говорят, что 80% людей им просто не владеют. От слова - вообще. Ни в профессиональной, ни в обыдиной жизни. Но вот те, кто объясняют доходчиво - владеют им виртуозно.
Заключается он в следующем. Если надо что-то объяснить, и это что-то чуть сложнее таблицы умножения (но и ее кстати тоже), задачу можно всегда разбить на части, из которых компонуется готовое решение. Вы должны на первой "итерации" объяснить ответ "с птичьего полета", как последовательностей этих самых подзадач, без углубления в детали, без подробных выкладок, что называется - "на пальцах". Причем, конечно, на языке понятном и воспринимаемом партнером. Когда (и если) он поймет вашу идею, поймет шаги - начинаете углубляться в объяснение конкретных подзадач. Вот тут уже начинаете использовать меньше "его" терминов, больше "своих". В какой-то момент он начинает сам понимать и самостоятельно додумывать решения. Тогда переходите к следующей подзадаче. Конечно, каждую подзадачу часто можно (а иногда - для очень сложных задач - и нужно) декомпозировать дальше. И так до того момента, когда вы можете объяснить полностью.
Тогда вы и сами понимаете "roadmap" вашего объяснения, не теряете нить рассуждений и не сбиваетесь, и партнеру легче выстраивать "цепочку понимания", следя за ходом объяснения и сразу понимая, где именно он перестал улавливать мысль. Разумеется, при этом очень важно, что-бы собеседник был заинтересован в том, что-бы получить от вас объяснение, а не просто спросил чтобы "а поговорить".

Нужно понимать принципиальную разницу подхода:

apt - установка из маленьких пакетов, вместе образующих большую и сложную систему, при этом софт может массово совместно использовать одни и те же файлы и библиотеки, благодаря чему экономится место на диске, оперативная память итд итп. Надо понимать, что apt - это пакетный менеджер для определённого вида пакетов (deb), хотя в своё время существовал вариант для rpm (может и сейчас существует, просто смысла в нём мало после появления yum).

snap - установка большого приложения со всеми зависимостями, которые никак не использует остальной софт на этом же компьютере. Отсюда тратится лишнее место на диске и в оперативной памяти. Зато никаких проблем с зависимостями, плюс snap работает в любых системах и не завязан на конкретный менеджер пакетов и собственно пакетный формат.

snap по большому счёту часто используют для установки тяжёлых приложений, которые может бысть сложно опакетить, особенно учитывая разнообразие присутствующих в мире дистрибутивов (debian/ubuntu и их клоны) разных версий. В то время как большинство штатного общеиспользуемого софта чаще распространяют в виде пакетов, идущих в составе дистрибутива или отдельно (в том числе в виде разных собранных под разные варианты систем пакетов).

1) Индустрия электроники огромна. Сказать, что вот прямо сразу весь мир прыгнул на 32 битные армы - это солгать. Более правильно сказать, что популярные блоггеры с производительностью пулемета штампуют статьи об stm32, при этом уровня "мигаем ледом".

2) С точки зрения разработчика, микроконтроллер - это инструмент. Каждый инструмент должен соответствовать задаче и быть до конца понятен тому, кто его использует. Я никому не пожелаю начинать обучения с STM32 - путанная документация и библиотека, которая состоит из макросов, вызывающих макросы, кроме укачивания при многочасовом скроллинге в попытках докопаться до истины, никаких эмоций не вызывает.

2.a) 32битный монстр с линуксом в стиралке - (и управление стиралкой, написанное на питоне, в тренде времени) - это сумасшествие. Потому что вместе с линуксом и питоном он притащит за собой кучу багов на всех уровнях, необходимость обновлений и прочее админство. Если на телефоне это еще покатит (семь бед - один резет, а через пару лет аппарат в помойку), то в стиралке, один неверно записанный бит может устроить потоп или даже легкий дестрой. Следовательно, когда речь идет об управлении какими-то технологическими процессорами (и о материальной ответственности), индустрия будет консервативна.

Основные принципы электроники сейчас - максимально запихивание перифирии в один чип. Этот тренд можно проследить с 1970х - начинали с огромных плат, где процессор - отдельно, память - отдельно, АЦП - снова отдельно, куча корпусов для развязки устройств на шине и так далее. Постепенно все эти запчасти стали помещаться в один корпус. Например - ESP8266 - это процессор, память, wi-fi и куча другой периферии, засунутые в один корпус.

Это дает снижение энергопотребления, повышение производительности, удешевляет платы.

У go одно применение - highly network intensive applications. GRPC, protobuf, триллионы rpc вызовов в секнду. Применяется он когда есть или сразу подобные требования или бизнес вырос до этого уровня.

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

В кровавом Энтерпрайзе в основном правит старичок Java (за редким исключением) по тому что есть требования к заменяемости сотрудников и большой легаси ландшафт проектов, которые переписывать никто не будет

Комментарии лежат в скрипте в коде страницы

import requests
import json
import re


headers = {'user-agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36'}

r = requests.get('https://www.instagram.com/p/CKJ4986gdbW/', headers=headers)

script = re.search(r'window._sharedData = (.+?);</script>', r.text).group(1)
data = json.loads(script)

edges = data['entry_data']['PostPage'][0]['graphql']['shortcode_media']['edge_media_to_parent_comment']['edges']
for edge in edges:

    text = edge['node']['text']
    author = edge['node']['owner']['username']

    print(author, text)

Универсальный подход, который годится для любых типов ключей:

from itertools import dropwhile

key = '5'
state = {1: 'a', 'abc': 'b', 3.14:'c', None: 'v', '5': 'b', '6': 'n', '7': 'm'}

new_state = dict(dropwhile(lambda item: item[0] != key, state.items()))

Или так:

for k in state.copy():
    if k != key:
        del state[k]
    else:
        break

Не надо туда вставлять служебную информацию типа "data:image/jpeg;base64", только сам код base64

По javascript есть прекрасный сайт javascript.ru и прекрасный учебник от Флэнагана.
Никакие курсы не заменят чтения учебника.
Никакие курсы не требуются после правильного прочтения учебника.