Включение/выключения бота на сервере можно решить флагом функциональности. Отягощать клиент лишним код довольно странное решение. Как и городить "мультилогин". Это ещё и небезопасно, поскольку данные бота могут угнать, так как они доступны на клиенте. А если вы вдруг захотите добавить какое-то более сложное поведение (например, взаимодействие с базой данных или внешним сервисов), придётся всё переделать. В случае с реализацией на сервере вы можете добавить информационных ботов, как например на Twitch.
Я так и не понял, почему сторона клиента обязательна. Всё это решается на сервере модулем, который следит за активностью и реагирует по заданным правилам. Например, зашёл аноним в чат — взять из пула бота и от его имени написать сообщение со стороны сервера. Пример упрощён, но показывает идею.
Где что-нибудь про Unity, про разработку? Это какое-то недоделанное руководство к игре с комментариями автора. А механики-то какие современные! Совсем не избитые и не затёртые до дыр.
Есть ещё один возможный критерий — процент совпадения города проверяемого пользователя и городов его друзей. Обычно, я обращаю внимание на тех, у кого больше хотя бы 60%. Ботам всё равно кого добавлять.
Тем, кому интересна эта тема, читают специализированную литературу и практикуются без попыток увеличения ЧСВ через написание статей, чья выжимка выглядит как "смотрите чё могу посоны".
Гораздо важнее уметь разобраться в предметной области в кратчайшие сроки и без посторонней помощи. Как бы полезна информация ни была, всё в голове не унесёшь. Неиспользуемое имеет свойство забываться.
Нет смысла использовать Tornado, если операции блокирующие, как, например, общение с базой данных. Возьмите momoko тогда. Ещё это странное ограничение в виде "занятости" бота. В чём смысл?
Уж слишком обширная тема даже для цикла статей. Даже если кто-то возьмётся следовать этим инструкциям (а иначе никак не назовёшь), то столкнется с ситуацией, когда любой шаг в сторону уже вызовет необычайные трудности в реализации. В общем-то, не хватает самого важного: теории и идеи. Думаю, как раз теоретическая часть была куда полезнее и познавательнее.
Я не автор, но, как минимум, не используется asyncio, что, в свою очередь, подразумевает отсутствие необходимости в асинхронных функциях. Плюс, конечно, всеми любимый API requests. Бесспорно, aiohttp или тот же Tornado лучше подходит для подобных задач, но всё же. Такой вот анализ.
С мобильного браузера страница теста никак не интерактируется. ЧЯДНТ?
Тоже сегодня получил этот бейдж. Так неожиданно и приятно.
Жёсткий дедлайн, так сказать.
Включение/выключения бота на сервере можно решить флагом функциональности. Отягощать клиент лишним код довольно странное решение. Как и городить "мультилогин". Это ещё и небезопасно, поскольку данные бота могут угнать, так как они доступны на клиенте. А если вы вдруг захотите добавить какое-то более сложное поведение (например, взаимодействие с базой данных или внешним сервисов), придётся всё переделать. В случае с реализацией на сервере вы можете добавить информационных ботов, как например на Twitch.
Я так и не понял, почему сторона клиента обязательна. Всё это решается на сервере модулем, который следит за активностью и реагирует по заданным правилам. Например, зашёл аноним в чат — взять из пула бота и от его имени написать сообщение со стороны сервера. Пример упрощён, но показывает идею.
Зачем, если есть pipenv? Сейчас бы в 2к20 начинать проект на такой базе — красота (нет).
Для чего ботам "мультилогин"? Они ведь могут спокойненько крутиться на стороне сервера.
Пользуюсь часто. Цифры расположены плотнее, что помогает быстрее вводить числа. Ещё лично видел, как бухгалтеры и кассиры используют этот блок.
В таком темпе люди из поисковой выдачи по поводу своих болячек будут попадать на некогда технический ресурс. F.
Достаточно загуглить "microframework <ваш ЯП>".
Есть ещё один возможный критерий — процент совпадения города проверяемого пользователя и городов его друзей. Обычно, я обращаю внимание на тех, у кого больше хотя бы 60%. Ботам всё равно кого добавлять.
Тем, кому интересна эта тема, читают специализированную литературу и практикуются без попыток увеличения ЧСВ через написание статей, чья выжимка выглядит как "смотрите чё могу посоны".
Когда забыл закрыть форточку в сознании.
Игра, кстати, огонь. В Steam есть даже поддержка Linux.
Гораздо важнее уметь разобраться в предметной области в кратчайшие сроки и без посторонней помощи. Как бы полезна информация ни была, всё в голове не унесёшь. Неиспользуемое имеет свойство забываться.
apihelper, скорее всего, тоже блокирует IOLoop.
Нет смысла использовать Tornado, если операции блокирующие, как, например, общение с базой данных. Возьмите momoko тогда. Ещё это странное ограничение в виде "занятости" бота. В чём смысл?
Уж слишком обширная тема даже для цикла статей. Даже если кто-то возьмётся следовать этим инструкциям (а иначе никак не назовёшь), то столкнется с ситуацией, когда любой шаг в сторону уже вызовет необычайные трудности в реализации. В общем-то, не хватает самого важного: теории и идеи. Думаю, как раз теоретическая часть была куда полезнее и познавательнее.
Я не автор, но, как минимум, не используется asyncio, что, в свою очередь, подразумевает отсутствие необходимости в асинхронных функциях. Плюс, конечно, всеми любимый API requests. Бесспорно, aiohttp или тот же Tornado лучше подходит для подобных задач, но всё же. Такой вот анализ.