Антон Неверов

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

Либо нужно их развивать, либо работать в команде с тем, кто ими обладает. И тот и другой путь вполне эффективен.

У discord.py это уже предусмотрено, вы можете добавить декоратор:

@commands.cooldown(1, (Время задержки), commands.BucketType.user)

Для вывода необходимо использовать событие:

async def on_command_error(ctx, error):
    if isinstance(error, commands.CommandOnCooldown):
        embed = discord.Embed( 
            title = 'Команда на задержке.', 
            description = f'Повторить через `{error.retry_after :.0f} секунд', 
            colour = discord.Color.red() 
        )

        return await ctx.send(embed = embed)

Все софтварные генераторы чисел не генерируют истинно случайные числа.

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

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

Чтобы узнать, почему не работает соединение или запрос, надо настроить РНР так чтобы он отображал ошибки, а mydsqli - чтобы оно бросало исключения.
То есть код должен выглядеть вот так

<?php
// видеть все ошибки!
ini_set('display_errors',1);
error_reporting(E_ALL);
 // подключаем настройки
require_once 'connect.php';

// включаем режим информирования об ошибках
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
// подключаемся к серверу
$link = mysqli_connect($host, $user, $password, $database);
// не забываем установить кодировку, чтобы не было ошибок с кракозябрами
$mysqli->set_charset('utf8mb4');
   
// выполняем операции с базой данных
$query ="SELECT * FROM foo";
$result = mysqli_query($link, $query);
// дальше делаем что нужно

// и кстати, в большинстве случаев закрывать подключение не надо

ЗЫ. На боевом сервере ошибки на экран выводить конечно не стоит, а их надо писать в лог (собственно, именно поэтому все эти die - это ужас). И на боевом сервере display_errors надо отключать, а log_errors наоборот - подключать.
Если совсем не можешь найти, где у сервера висит лог ошибок, можешь задать свой собственный, с помощью функции ini_set('error_log','/путь/к/файлу');. Но только размещать его надо разумеется в папке недоступной пользователям сайта


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

Если разобраться, то код or die("Ошибка1 " . mysqli_error($link)); очень смешной (это не к тебе претензия, никто не ожидает от тебя понимания таких тонкостей, которые не то что новички, а половина здешних "кураторов" не понимают).
Что тут происходит?
слово or die (которое на самом деле вообще нельзя никогда писать) пишут тогда, когда ожидают что в переменной $link будет значение false. Но если в $link будет false, то тогда её бессмысленно подставлять в mysqli_error. Именно поэтому для получения ошибки соединения в мускули есть отдельная специальная функция.

Но как я говорил выше, применять её не следует, как и or die.

Если уж совсем по сути, то вы задали несколько вопросов:

1) Как прочитать ответ из вайбера
2) Как понять к какой сделке относится этот ответ (если он относится к сделке)
3) Как изменить стадию сделки

Отвечая на ваш вопрос "Как изменить стадию сделки", вы можете воспользоваться rest-методом crm.deal.update (для облака) или CCrmDeal::update (см аналогично для лида https://dev.1c-bitrix.ru/api_help/crm/example.php)

Нууу давайте разбираться.

Для начала почитайте про HTTP на той же вики. Досканально знать не нужно, но стоит минимально понимать структуру запросов/ответов, понимать что у запроса и ответа есть заголовки и тело (тела может и не быть, зависит от типа запроса/ответа).

Так вот. Куки. Куки живут на стороне браузера. Они передаются HTTP заголовком на каждый запрос на сервер (даже если вы за картинками полезли). Есть просто куки, есть http-only куки. Куки могут быть разграничены по хосту и пути. Все это дает нам гибкость и помогает с секьюрностью. В PHP содержимое $_COOKIE предоставляет нам SAPI. Когда PHP получает на обработку запрос, SAPI используемое (php-fpm, cgi, mod_php имеют свои реализации SAPI) в данный момент берет заголовки и тело запроса, парсит их и заполняет все эти суперглобальные массивы типа $_SERVER, $_GET и в том числе и $_COOKIE. Все что прислал нам клиент (что-то что делает запросы это клиент, что-то что их обрабатывает - сервер), а куки шлет нам браузер только те что можно исходя из того куда шлется запрос. Устанавливаются куки заголовком Set-Cookie в ответе, то есть тут больше нужно читать в принципе про HTTP а не про PHP. PHP просто позволяет вам работать с этим добром. Вы можете сэтить куки напрямую работая с заголовками ответа при помощи функции header. Более того, если выставить время жизни куки в 0, то как раз таки они а не сессия будет сбрасываться при закрытии браузера так как тот будет забывать все такие куки.

Вот... сессии... В PHP сессия обычно это файл. Просто какой-то файл с рандомным именем. Если скажем в php.ini указано session.autostart или делается вызов session_start то создается файл под сессию пользователя (можно переместить в рэдис или мемкэш, свое хранилище и т.д в зависимости от нужд. Так же данные можно шифровать, что по умолчанию и происходит). Этот файл имеет ID, просто какая-то рандомная строка. И если при обработке запроса не нашлась сессия с предыдущего запроса - создается новая.

И вот мы подошли к самому интересному - как PHP связывает сессию с предыдущего запроса с текущей. И тут все довольно просто - куки. Когда пользователю присваивается сессия, автоматически сэтится http-only (что бы нехорошие люди не могли из js увести нашу сессию) кука, в которую записан идентификатор сессии. В дебагере браузера можете посмотреть есть ли у вас кука PHPSESSID (название можно менять в настройках, да и вообще сессии можно не только через куки связывать, но это уже загоны по секьюрности) когда будете эксперементировать с сессиями.

Когда запрос обрабатывается SAPI, при наличии session.autostart, перед тем как начинать создавать новую сессию, пых все же смотрит а есть ли у нас кука с идентификатором сессии, проверяет есть ли у него такая, и если есть успокаивается и не создает новую. Поскольку сессия привязывается через куки, то можно выставить время жизни этой самой куки (в php.ini) и таким образом регулировать время жизни сессии.

Вот... когда использовать куки а когда сессии? Желательно понимать, что чем больше данных в куках (а у них есть лимит к слову) - тем больше данных мы передаем на каждый запрос. То есть это не круто когда что бы получить 1 килобайт данных мы должны в заголовках передать пару килобайт кук. Люди, повернутые на оптимизации, даже картинки хранят на отдельных cookie-less доменах что бы уменьшить количество трафика и пакетов (обычно простенький HTTP запрос влазит в размеры одного TCP пакета). Если вам нужно работать с этими данными из JS на любой странице, например локаль выбранноую пользователем для того что бы применять переводы еще и в JS, то стоит использовать куки. Для всео остального лучше конечно же использовать сессии. Во всяком случае на начальных этапах когда что-то сильно сложное вам делать не придется.

Очевидно где-то кто-то ломится в базу на этапе инициализации.
Скорее всего какой-нибудь сервис провайдер или в файле routes.php

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

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

3) правильный вариант. Стоит ли он потраченных усилий - это уж только вы сами можете оценить.

Два репозитория. В обоих добавляете еще один origin - на другой проект.

Если нужно внести изменения в оба проекта, то сначала делаете это в одном, потом в другом проекте мерджите изменения с другого origin'а.

Писать код нужно максимально независимым. Используйте модульность, для модулей внешнее API и event/listeners для общения наружу. В местах где логика различается - по максимуму полиморфизм, и.е. избегайте мерджов всеми силами.

Второй вариант говно. Третий вариант слишком сложный.

Что вы думаете

думаю, что

надо непосредственно у работодателя спрашивать насчёт этого

Честно я бы взял swiper по мне во первых он более гибкий в настройках, так же можно собрать слайдер только с нужными тебе модулями. Сделан на ваниле(относительный плюс - но все же) Ну и по мне у него куда меньше закидонов/приколов чем у слика.

Делал недавно такое для сервиса продажи билетов.
Пошагово:

1. Делаем макеты - зал, сектора поотдельности, кресло в svg, хоть в png
   
2. В любом банермейкерском софте, можно в бесплатном Google Web Designer (позавчера вышел релиз без вечной приставки "вета"!), в базовой сцене размещаем главный зал
   
3. Делаем дополнительные сцены (в GWD это page#) под каждый сектор, ну и разумеется размещаем там соответсвующее изображение
   
4. Делаем элемент кресла кликабельным, и присваиваем ему действие
   
5. В каждом секторе размещаем (клонируем) эти кресла, отлично если редактор поддерживает символы (gwd нет, Hype 3 pro - да, Adobe Animate - незнаю, но скорее да)
   
6. В главной сцене делаем прозрачные интерактивные зоны над секторами (вектором, нестандартной формы) и присваиваем им действия при клике/тапе переход на соответствующую сцену
   
7. В каждом кресле (каждой сцены) редактируем нужное действие при выборе, я делал вызов js функций
   
8. По мере надобности - готовый проект тюнингуем различными анимационными плюшками и ховер эффектами
   

Как то так, а не иначе ))