А зря. Это так не работает. Частота вертикальной синхронизации - это неотъемлемое свойство видеорежима (наряду с разрешением), список которых для каждого монитора ограничен его техническими характеристиками.
Зачем использовать много ключей? Генерим один ключ и со всех клиентских хостов ходим с его помощью на сервера, на серверах, соответственно, один ключ в authorized_keys.
Управление можно реализовать кучей разных способов.
Например, если в боте совсем немного настроек, то можно сделать конфиг-файл и перезапускать бота. Или пусть он сам регулярно перечитывает конфиг.
Можно реализовать командами в самом боте. В том числе сделать так, чтобы управляющие команды работали только у пользователей из выделенного списка администраторов.
Можно сделать так, чтобы данные бота хранились исключительно в базе, и настраивать его через прямое редактирование базы. Или написать отдельное приложение для редактирования базы. Можно web, можно cli, можно gui...
Можно сделать web-интерфейс в самом боте. Особенно если он и так на вебхуках, то есть веб-сервер у него будет в комплекте изначально.
Можно сделать вообще API-интерфейс в боте. И к нему клиента. Можно web/cli/gui, а можно даже мобильное приложение.
В общем, море вариантов, и никто, кроме тебя, не может принять решение, исходя из сложности самого бота, требованиям к разработке управленческого интерфейса, собственных компетенций, наличия времени, в конце концов (супер-идея потребует супер-затрат).
SHA_bash, в описании матрицы n - это размерная константа, а не итератор. То есть матрица 10x10 будет всегда матрицей 10x10, а не матрицей [любое число от 1 до 10]x[любое число от 1 до 10].
Как пошутили в камментах, i и j :) Собственно, в математике часто итерируют по этим переменным, и программисты это часто повторяют:
for (i = 0; i < n; i++)
for (j = 0; j < n; j++)
do_something_awesome(i, j);
mk11, я привёл наивный алгоритм. Возможно, уже придуманы алгоритмы, которые позволяют оптимизировать процесс. Плюс во многих есть режимы от лёгкого до сложного, скорее всего, это определяется количеством чисел, которые удаляются при подготовке.
В одной реализации судоку я заметил, что там часто бывает тройка одних и тех же чисел в одной строке, только в вертикальном столбце квадратов 3x3 эта строка имеет разный порядок. Но так было не всегда, но даже в иных случаях часто это выражалось в том, что одно из чисел тройки просто перекочёвывало в другую строчку в каком-то из квадратов. Вероятно, это был побочный дефект использованного автором алгоритма, который в погоне за простотой и скоростью обеспечивает не совсем случайное распределение цифр.
mk11, нет, вполне очевидно, что просто оставить 17 произвольных чисел недостаточно. Например, если оставить 9 чисел в 1 строке и 8 во второй, то судоку будет иметь много решений, хоть в нём и будет 17 чисел.
Суть ограничения в 17 чисел состоит в том, что вообще никакое судоку с раскрытием меньшего количества чисел не будет иметь единственного решения.
Хотите сказать, что люди, которые зарабатывают по 300-350к не имеют желания сделать что-то свое
Я даже больше скажу, люди, которые зарабатывают по 300-350 кило, часто не только имеют желание сделать что-то своё, но даже делают и ещё больше хотели бы сделать, но не хватает сил и времени. Основная проблема для них - не найти гения с идеей, до которой никто не додумался(тм), а занятость работой, семьёй, плюс необходимость отдыхать, есть и спать.
И чтоб понимать, сколько может занимать сайд-проект, приведу пример из своего опыта. В 2019 году я на майских праздниках на даче в авральном режиме написал аццкий говнокод на основе реверс-инжиниринга флеш-игрушки. Этот скрипт я потом с переменным успехом использовал, иногда с горем пополам чёта там подправляя, а потом весной этого года я решил занятся полноценным рефакторингм (отдельные модули и классы работы с данными, правильная обработка всего и вся со 100% соответствием поведения оригинальной игры). В свободное от работы время я написал всего лишь около 1000 строк кода (прям только что проверил! и это включая копипасту констант из игры и всякий нефункциональный сахар типа методов __str__ и __repr__), и на это ушло больше двух месяцев, плюс я ещё несколько месяцев потом исправлял мелкие недоработки из TODO-листа и жалоб пользователей.
А ещё у меня есть проекты-висяки, которым 10 и даже больше лет. Под один из них я даже купил домен ещё в 2012 году и до сих пор его продлеваю в надежде, что я когда-нибудь всё же что-то рожу...
Меня не хватает даже на то, что я очень хочу, почему я вдруг захочу делать что-то неинтересное, даже за эфемерный шанс что-то заработать (и одновременно риск ничего не получить)?
Но на самом деле ситуация не совсем гиблая, и есть варианты.
Если уж и искать исполнителей, то надо брать их на зарплату (можно сдельную), и только если проект взлетит, то можно предлагать долю. Работать за долю, которая может оказаться нулевой, никто не будет, так как это означает отрицательную отдачу (усилия уже потрачены, а денег нет).
Идейных людей иногда (иногда!) можно найти в тематических сообществах. Например, если есть идея сделать игру по вселенной SCP Foundation, то можно попытаться поискать там людей, готовых рискнуть за перспективу участия в проекте на любимую тему. В сообществе программистов искать таких людей абсолютно бессмысленно, ведь на фрилансе они потратят своё личное время с гарантированной оплатой.
Перспективным может быть собрать денег на кикстартере, патреоне и иных к ним примкнувших сервисах, на что нанять разработчика или нескольких на сдельную оплату или частичную занятость. В конце концов, если есть святая уверенность в том, что проект точно выстрелит, можно было бы профинансировать начальную стадию из своих собственных средств в счёт будущих (сверх)доходов.
В конце концов, как правильно тут уже говорят, можно начать самому в меру своих собственных возможностей и компетенций. Если идея взлетит и принесёт хоть что-то (или хотя бы покажет свою состоятельность), можно будет доделать позже. И вообще, многие успешные проекты начинаются с пруф-концепта, абы как намалёванной демки и заглушек "тут будет кнопка регистрации через пейсбук". Вот, например, автор известного в узких кругах игрового движка ren.py в своё время сделал визуальную новелу "Прогулки под луной" с его использованием, и в ней можно в настройках выбрать изначальную авторскую графику вместо умолчальной, нарисованной каким-то художником. Выглядит она просто ахово, но ведь он нашёл кого-то, кто всё это перерисовал по-человечески, уже после выпуска движка и первой версии этой демо-игры.
Это lazy load, когда картинки при загрузке не грузятся, а потом догружаются с помощью js после загрузки всей страницы. Для этого атрибут src не заполняется или заполняется какой-нить маленькой заглушкой, а вместо него для реальной картинки используется другой (чаще всего data-src, но возможны другие варианты). Потом скрипт переносит значение data-src в src, и картинка загружается. В общем-то, надо понять, как сайт передаёт реальный адрес картинки, и достать его оттуда.
nonconformiste, где-то там рядом должны лежать докерфайлы, в которы те самые команды навроде:
RUN apt-get update && apt-get install -y ,,,
Вот там и надо менять.
Хотя... там небось написано в начале что-то типа FROM ubuntu:hirsute и тогда это не так просто становится. Проще тогда поменять на название более позднего релиза, хоть и может сломаться что-то ещё.
michadimin, например, через eval можно вызвать внешнюю программу с помощью os.system. Если пользователь передаст вызов удаления Очень Важного Файла вместо формулы - что будет?
Но в Python есть более безопасный вариант eval - ast.literal_eval. Он выполняет не любой код.
А зря. Это так не работает. Частота вертикальной синхронизации - это неотъемлемое свойство видеорежима (наряду с разрешением), список которых для каждого монитора ограничен его техническими характеристиками.