Довольный Айтишникъ

Ежемесячно почтой пользуются более 27 миллионов пользователей.

вот яндекс например (это только те кто пользуется, а сколько зарегистрировано за 20 лет неизвестно)

А теперь представьте: придумали новую функцию и надо накатить миграцию в базе данных.
Добавить столбец или создать таблицу там какую-нибудь очень нужную.
Это надо 27 миллионов раз накатить миграцию.
Очень эффективно получится? Деплоить по одному апдейту в месяц или вроде того)

А если в принципе надо переехать куда-нибудь и перенести данные, тоже собирать в кучу как-то 27 миллионов разных баз. Или даже сделать бекап например.

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

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

а там данных на одного пользователя не больше миллиона значений

от балды цифра, а если у меня 2 миллиона? А если 3? Каждый раз всё переделывать когда появляется пользователь который выходит на ваши рамки?
А когда один пользователь перестанет влезать на один сервер?
А что если 10 пользователей занимают диск целого сервака, а нагрузки при этом никакой не создают - сервер простаивать будет просто так?

Ну в общем можно много чего еще такого придумать.
Это не поддерживаемо, не масштабируемо, неудобно ни с какой стороны.
Если бы было по другому так бы все делали.

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

В этих строчках нужно было заменить eth0 на enp0s3

Проблема в этой строчке: stringToEncrypt = stringToEncrypt.lower

Если ты всё правильно скопировал, то в ней ты не вызываешь метод lower(), а присваиваешь переменной stringToEncrypt ссылку на него. Т.е. правильно будет: stringToEncrypt = stringToEncrypt.lower()

Чтобы было проще, можно строку stringToEncrypt = stringToEncrypt.lower вообще удалить, и сразу написать:

stringToEncrypt = input("введи сообщение: ").lower()

А теперь подумай, зачем в переменной a словарь у тебя дважды повторяется?

хеллоуворд видится как какой-то буддистский коан.

Минимальный современных хеллоу ворлд выглядит так:
Console.WriteLine("Hello world!");

Чтобы разобраться во всех следующих пунктах тебе следует продолжать изучать (хоть по курсу, хоть по книге), иначе всё расписывание само по себе потянет на небольшую книгу, или хотябы брошюру, и при этом врядли как-то тебе поможет:

1. Можно просто убрать этот конкретный using, используя global usings или используя полные имена типов
2. Можно не писать namespace или написать любой свой собственный. Или можно использовать file scoped namespace
3. Можно придумать своё имя класса, можно сделать его статичным, можно сделать явно приватным или публичным.
4, 5, 6. Main (точка входа) обязан быть статичным. Другие методы могут быть не статичными.
Main можно сделать публичным или приватным, можно дать другое имя, но тогда придётся в опциях компилятора указать, какое имя.
Main можно сделать асинхронным - тогда вместо void или int (Да, он может возвращать int) будет Task или Task<int>
7,8,9. string[] args можно не указывать, или дать этому параметру другое имя (не args), но принимать что-то иное нельзя
10,11. Это уже относится к телу метода и оно может быть любым. Но вместо Console.WriteLine можно написать полное имя - System.Console.WriteLine или сделать using static System.Console и тогда можно будет написать просто WriteLine

Дело в том что курсор может потреблять ресурсы. Например вы захотели взять первые 10 строк из 10000000 выборки но предварительно отсортировали. Выбрали 10 строк и не сделали финализирующие протокольные действия в Python. База данных будет удерживать в памяти алгоритмы и структуры данных для снапшота результата этого запроса до тех пор пока не придет явный CLOSE с вашей стороны либо интеллекуальный драйвер который еще и обладает логикой уборки мусора сам не догадается что Statement уже вышел из scope вашего использования и может быть удалён GC.

Я был свидетелем ситуации когда крупное ent-приложение Java/Oracle переполняло память из-за неверной обработки Exception и плодила много незакрытых курсоров в БД. Java от этого не сильно страдала (GC всё убирал) но страдал Oracle. Потому что уборка происходила слишком поздно. Пофиксилось тогда переписыванием с try на try-with-resources.

Поэтому если вы неряшливо обращаетесь с курсорами (явными и неявными (обычный select к примеру может прождать неявный курсор)) то не ваше приложение а база данных почувствует себя плохо. Как быстро и какие ошибки вы будете получать - зависит от настроек вашей БД.

Реакт придерживается концепции "чистых" функций. Т.е. таких функций, которые всегда дают одинаковый, предсказуемый результат при одинаковых входных параметрах. В режиме разработки, с включенным strict-mode реакт помогает выявить непредвиденные эффекты и состояния, возникающие в результате нарушения концепции, вызывая дважды все функции, которые он считает "чистыми". Как это работает?
Предположим, вы написали функцию, которая по сигналу "свет" - включает свет. Но если свет уже включен - функция его выключает. Вы довольны и счастливы - послали сигнал "свет" - свет включился, послали еще один сигнал "свет" - выключился. Но в режиме strict-mode - вы обнаружите, что свет не включается, потому что реакт шлет второй сигнал "свет", который выключает после первого сигнала! И опять, возникает вопрос - да зачем это нужно? А затем, что вы не можете предсказать результат действия сигнала "свет", не зная текущего состояния! Возникнет острая необходимость - включить свет, а вы не знаете - включен он сейчас или нет... Пошлете сигнал "свет", когда он включен - получите выключение.
Примерно такие варианты поведения выявляет strict-mode.

Тема более чем заезженная. Определяете сколько хотите получать в месяц при определенной занятости (в часах). Делите сумму на часы - получаете стоимость часа. Считаете сколько потратили на работу и умножаете на стоимость вашего часа. Все просто?
Не бойтесь называть цену! Иначе будете работать за доширак и этим будут пользоваться.

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

В боте (aiogram) надо сделать сохранение куда-то списка текущих запросов (chat_id - запрос). Также сделать обработчик сообщений с content_type видео, который будет получать видео от юзербота, находить по нему в списке запросов chat_id, в который затем отсылать видео по file_id.

ссылается на переменную item
"Uncaught (in promise) ReferenceError: item is not defined at cartProduct (cart_04.js:13:8)"

Deadorik, ну вот и делайте вывод. Not defined - не определена. Значит нужно определить переменную, прежде чем использовать.

Почему так происходит?
Потому что в стандарте чётко написано

Module code is always strict mode code.

Пока не используете модули, js выполняется в нестрогом режиме. Можно не объявлять переменные перед использованием. В модулях уже всё по-взрослому: сначала объявили переменную, потом ее использовали.

for (let item of json) {

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

В общем случае верно, но также не помешает акт/расписка или что-то подобное о передаче/получении в зависимости от способа оплаты.

Да, если договор составлен адекватно, то есть положительная судебная практика.

Если же нет, например частая ошибка что составляется договор покупки/продажи (домен не является имуществом по законодательству РФ), а не возмездной передачи прав администрирования, то возможны различные варианты вплоть до признания его не имеющим юридической силы.

Также учитывайте риски (читай - расходы), если контрагент из другой юрисдикции и откажется от исполнения своих обязанностей.

Если есть высокие риски "кидка" - пользуйтесь услугами гаранта сделки.

P.S. Как основу для договора возмездной переуступки права администрирования 
доменного имени можно взять проверенные временем шаблоны - https://reghouse.ru/upload/dogovor_vppadi.zip