Влад Григорьев

Фундаментальная проблема - в игрострой стоит очередь фанатов с горящими глазами. Людей, которые пишут игры, играют в игры, моддят игры, хакают игры..., начиная с возраста, когда они смогли дотянуться до клавиатуры (как ваш покорный слуга). При этом, у них столько мотивации, что они могут сами поставить себе задачу, сами нагуглить все, что нужно (Спасибо дяде Немнюгину за его учебник. Это все что нужно знать о DOS, чтобы закодить dOOm) и сами все напишут и нарисуют (работая над этим сутками. Не потому что над душей стоит босс с воплями о лишении премии, а потому что им это интересно).

И вот теперь, Андрей, который уже устал хочет встать в очередь высоко мотивированных конкурентов и попросить себе оффер. Каковы его шансы на успех?

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

Для универсального развития, нужно начинать с простых фиговин вроде тетриса, арканоида, бильярда и прочего (в которых однако есть все столпы игростроя - графика + логика + системный движок, можно и добавить сеть, если подумать) и потом наращивать сложность - делать платформер или RTS.

В нормальных компаниях не следят с секундомером за работой сотрудников. Если от вас ждут нажимания кнопок 40 часов в неделю, а не выдачу запланированного объёма продуктов/решений, то надо бежать.

1. Питон третий может работать на разных компьютерах
2. Какую ошибку синтаксиса выдаёт, в какой строке, какой код?
3. Установлены ли в виртуальное окружение зависимости на обоих компьютерах?

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

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

Очевидно в user_channel_status нет элементов с индексом 60 и 70. Решить проблему можно проверкой длины списка.

Никто не заставляет использовать docker, systemd, ansible и вообще какие угодно системы оркестрации и оптимизации. Необязательно делать шаблоны конфигов или кластерные конфигурации сервисов, необязательно использовать библиотеки настраиваемого логгирования, возиться с балансерами и реприцируемыми базами. Но люди это делают, значит, смысл всё-таки есть?

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

Консул - это тоже инструмент. Вряд ли хоть кто-то использует его возможности целиком и полностью, тем более что никто не заставляет. Кому-то достаточно того, что у него все сервисы зарегистрированы в одном месте и из коробки имеют автоматическое DNS-имя вида NAME.service.consul. Кто-то использует kv-хранилище для хранения параметров, а кто-то хранит в нём секреты и целые конфиги, настраивает токены с различными acl и скрещивает всё это с consul-template. Вообще, необязательно использовать именно консул, есть и другие инструменты для подобных задач. Например, zk/etcd.

Консул чаще используют совсем не с ансиблом, а с инструментами оркестрации, в которых сервисы могут расширяться и сворачиваться, перезагружаться и мигрировать. Скажем, пусть у нас есть условный сервис rabbitmq на три ноды. Тогда у нас может быть три контейнера rabbitm{1..3}, при запуске они регистрируются в консуле скриптом запуска вместе с проверками, а далее consul отдаёт их все три в виде имени rabbitmq.service.consul. Если какой-то из них вдруг упадёт, consul оперативно это обнаружит и исключит из DNS проблемный узел. Если вдруг управляющий всем этим администратор или автоматическая система оркестрации посчитает нужным добавить новые узлы или перенести их куда-то ещё в кластере, то consul также отразит все нужные изменения. При этом использующее rabbitmq приложение должно будет знать только адрес rabbitmq.

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

Да, не хватает миллиона программистов - профессионалов от мидлового уровня с опытом работы в коммерческих проектах не менее трёх лет. А начинающих, которые только хотят стать программистами, переизбыток.

n = print(item['name'])
В-первых, ничего не выводит куда?
Во-вторых, print() выводит данные в стандартный вывод, обычно в консоль. В дискорд через неё ничего не послать.
Во-третьих, print() всегда возвращает None. Так что n всегда будет None, и присваивание не имеет смысла.
В-четвертых, почему не использовать нормальный обработчик команд из discord.ext.commands.Bot? Он тоже позволяет реагировать на сообщения, в придачу к остальным полезностям именно для бота. Это при условии, что ты хочешь именно реакцию на сообщение и не согласен обойтись обычной командой.
В-пятых, если ты не уверен, что такое print(), почему ты пытаешься писать ботов?

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