azShoo

Если при загрузке файла пользователь дает явное согласие, что загружаемый им контент не является объектом чужих авторских прав (или он имеет право на распространение данного контента) - то сайт не является "нарушителем".
Но, нужно учитывать два момента:
1) Придется оперативно обрабатывать и удалять требования правоторговцев. В частности, указанные вами критерии оценки "нарушает - не нарушает" их может и не устраивать.
2) От вас могут потребовать данные аплоадеров, для дальнейшего разбирательства с ними.

С непониманием отношусь, потому что термин очень размытый.
Какие услуги вы под этим подразумеваете?

Бесплатно - никак.
Просто в рамках крупного сервиса эти рассылки стоят копейки. Дальше встает вопрос о выборе смс-шлюза - соотношение цена\качество, и все.

К.Сьерра, Б.Бейтс - Изучаем Java (O`Reily всегда и везде) - максимально простое изложение, много иллюстраций, примеров и задачек.
Из более академического: "Java, Полное руководство" Г. Шилдт и "Философия Java" Б. Эккель. Более классическое, но вполне понятное изложение.
Все, что нужно "со старта" - есть.

А в целом - не ленитесь использовать поиск, ответ легко гуглится.

Я бы посоветовал не тратить время на книги о том, как не тратить время. :)
Серьезно, лучше займитесь чем-нибудь полезным, чем впитывать этот информационный мусор.

Лучше взять необходимые комбинации, написать на них pairwise тесты, и не пытаться сделать из этого красивые картиночки. :)

Из минусов:
Ограниченное развитие.
Недооцененность сферы в СНГ.
Постоянные душевные страдания за качества продукта.

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

В целом, минусов больше чем плюсов, потому что подход "этого небыло в тз" для тестировщика не работает. Нужно всегда думать о том, что остальные что-то упустили, забыли, не подумали.
Нужно всегда помнить, что everything is broken. И всегда быть готовым к тому, что за баги на проде, которые неизбежно будут, шишки полетят именно в вас. :)
Но, в то же время, мне, например, вполне нравится. Если перебороть в умах коллег по IT стереотип, что тестировщик это обезъянка, тупо кликающая куда-попало - будет вообще отлично.

Это нужно спросить у программиста, как это реализовано\должно быть реализовано.
Вариантов довольно много - по тэгам\сочетанию тэгов, ключевым словам в заголовках, ключевым словам в текстах, исходя из источника.

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

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

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

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

Пункт третий: безопасность
Особенно актуально для значительных сумм.
Если у меня вытащат карту - с ней ничего не случится, без пина и\или кода подтверждения из смс она бесполезна чуть более, чем полностью.
Даже если злоумышленник каким-то образом, что вряд ли, получит мой пин - на карте стоит лимит снятия, и на первое же списание без моего ведома карта уйдет во фрод в течении 10 минут. Карту выпустят через 2 недели, а бабло по последней операции вернется в течении 30 дней.

Если у меня из кармана вытащат бабло - то, как бы, прощай бабло. Все.
Опять же, один из самых простых способов увести карту - считать её во время снятия бабла в банкомате. Чем больше банкоматов, в которых снимаешь -> тем выше шанс напороться на скиммер. А значит или надо все время ходить в "проверенный" и держать в голове "ага, сегодня надо снять N бабла", или каждый раз шатать все части банкомата и искать накладки.

Пункт четвертый: ништяки
Выше уже была упомянута программа с бонусами от покупок. Так же есть скидки при оплате картой (партнерки), всякие там "бонусные мили", повышение % годовых при обороте по карте больше N.

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

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

Селениум подходит, просто не используйте id в качестве локатора.

вообщем всё, что тестировщику пригодится в работе.

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

Что нужно знать джуну-тестировщику, в самом общем виде?
1) Нужно понимать теорию тестирования: что есть дефект, приоритеты(классический вопрос про priority & severity), базовые практики тест-дизайна, понимание того как и зачем писать тесткейсы, понимание того, как локализовать ошибку.

2) Нужно иметь общее представление о предметной области:
Если тестируете веб - общее представление о клиент-серверной архитектуре, всякие пост-гет запросы, и прочеее прочее. + REST и API
Если тестируете мобилы - подробнее почитать про специфику тестирования мобил.
ну и т.д. с декстопами, железом, смарт-картами и прочим добром.

3) Базы данных. Иметь общее представление о реляционных и не-реляционных базах данных, уметь написать селектики на SQL, дальше уже плясать от конкретного стека технологий.

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

Список перечисленных вами технологий смутил.
Кибана - GUI обертка для NoSQL базы данных, зачем джун тестировщику это знать - не представляю. В большинстве мест вы с ней не столкнетесь, а когда столкнетесь - разберетесь за полтора дня с Lucene Query и будете жить радостно.
XPath и Selenium - это для автотестировщика. Сажать джуна (человека с минимумом опыта) за автотесты - насилие над продуктом и человеком. Потом пригодится, на этапе джуна - фактически не нужно (понятно, что знание не лишнее, но применять оные вам вряд ли придется).
XML - ну, что нужно знать про хмл я, честно говоря, не знаю. Разве что что это такое и как выглядит.

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

Ответ прост: а зачем?
Это дополнительная инфраструктура, которую надо поддерживать, этиваши программисты, которые хотят по 150 тыщ зарплаты и все такое.
А на выходе профит будет минимальный, т.к. значительная часть пользователей интернета будет качать торренты и смотреть то же самое, но без рекламы, а вторая часть - уже завербована существующими онлайн-кинотеатрами.
Более того, в интернет среде модель с ТАКИМ количеством рекламы, какое есть на ТВ, просто не жизнеспособна, пользователю проще купить подписку за 300 рублей в месяц, чем каждые 10 минут смотреть 5 минут рекламы.

ТВ сейчас - очень консервативная сфера, потому что "все и так работает", приносит много бабла и зачем что-то менять?

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

Первая сложность:
Нужно четко представлять, что вы собираетесь делать: как получать данные с клиента, как обрабатывать, как посылать их обратно.

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

Третья сложность: написать логику для бота, которая в зависимости от задач превращается из десяти скриптов в неплохой аи.

Четвертая сложность: передавать результаты работы аи обратно на клиент\сервер. Тут, опять же, или взаимодействие с гуи, или подмена пакетов.

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

Единственный вариант получить

действительно защищенный мессенджер

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

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

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

Аддоны для игр: зависит от того, что вы подразумеваете под аддонами, а так же от игры. От того же С++ до Lua и JS в зависимости от конкретной задачи.

С остальными пунктами отлично справляется Пайтон, хотя и в рамках других языков это вполне реально осуществлять.

Все упирается в то, как вам интереснее.
Лично я не могу тупо читать книги, и большинство задач-примеров в них предоставленных мне слабоинтересны, что лишний раз подрывает мотивацию (тяжелее себя заставить после работы заняться самообучением).
Посему для себя сгенерировал ряд интересных мне идей (от проектов до просто мини-библиотечек, которые было бы интересно написать) и занимаюсь ими.
Столкнулся со сложностью - нашел соответствующий пункт в книге, почитал, сделал на уровне книги. Потом погуглил, как "правильно". Понятно -> переписал, непонятно -> сделал пометку на "разобраться потом".

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

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

Объединить это в одном стеке технологий и решений - не получится.
Одинаково ориентироваться в двух стеках - вполне возможный вариант. Все упирается в опыт и количество потраченного времени.
Опять же, есть люди, которые быстро учатся. Для них стек технологий и набор библиотек - не более чем инструмент, и они очень просто переключаются с одного на другой. Сел, разобрался за месяц-другой и все хорошо.
Есть люди, которые переключение между спецификой даже в рамках одной платформы (или даже стека) дается тяжело. Для них это "обучение программированию с 0", а не "почитал, понял особенности, погуглил нужные библиотеки, понял как это работает".

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