Saboteur

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

Можно убрать else

read -r -n1 -p "Ask some question. y/n " key
variable=false
if [ ${key^^} == "Y" ]; then
    variable=true
fi

Можно использовать && и ||

read -r -n1 -p "Ask some question. y/n:" key
[ ${key^^} = 'Y' ] && variable=true || variable=false

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

Если вы сможете гарантировать доставку клиентам и взять на себя весь геморрой в том смысле, что вы клиенту под подъезд привозите товар и только в этот момент клиент оплачивает вам наличными, пусть даже 120-130% стоимости - такой сервис однозначно взлетит.
Вот только есть большие сомнения, что вы сможете это гарантировать, так как очень много товара потеряется на таможне, завернется обратно, доедет не совсем то, не совсем туда, застрянет где-то в пути, а расходы будут ложиться на вас.

"1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?"

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

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

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

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

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

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

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

Код не получится простым.
Из-за сложности кода, возникла парадигма ООП, возникла модульность и так далее.

Для упрощения используют следующие вещи:
Комментарии. В java для этого есть целый стандарт с автоматически генерящимися javadoc. Комментарии имеют стандарты, например только английский, в едином стиле.
Стандарты именования переменных, классов, методов, что упрощает чтение.
Собственно ООП - при грамотном подходе, это позволяет создавать максимально независимые инкапсулированные классы.

А иначе - никак.

Проверьте по тарифам, есть ли ограничение по траффику и по скорости доступа.

Бывает, что vps может продаваться с крупным, но все-таки лимитированным траффиком, чего может не хватить, если собираетесь гонять торренты.
И скорость доступа к vps может быть ниже, чем у vpn, который заточен под отдачу траффика, хотя это менее критично.

Можно почитать стандартное описание американских и европейских уровней.

Upper intermediate - более-менее достаточно. Intermediate - маловато, но можно пробовать.

Учеба это не время, учеба это усилия.
Понять принцип - 10 минут
Посмотреть основные теги - час
Закрепить практически - зависит от человека, дни, недели, месяцы?
На уровне спецификаций - недельку по вечерам почитать историю и стандарты, желательно не в отрыве от http.

Но это только HTML
CSS это гораздо, гораздо больше.

Большинство приложений от MS используют настройки, которые можно задать через свойства IExplorer-а.
Включая прокси-сервер, SSL/TLS.

Всегда нужно помнить, что Internet Explorer в винде не просто браузер, его интеграция с OS гораздо больше.