Так проще и для пользователей, и для меня. Не нужно каждый раз залезать в код/базу для добавления менеджера, не нужно пилить интерфейс админа, который не добавляет ценности (и не оплачивается).
Вероятность утечки этого ключа примерно такая же, как вероятность утечки пароля к интерфейсу — я же его точно так же в сообщении отправлю.
Даже если ключ утечёт (вместе со взломом Tg-аккаунта менеджера), то пользы злоумышленнику от него никакой. Разве что насоздаёт ссылок на оплату, пока мы через базу его не забаним. Реквизиты получателя он изменить не может.
Очень давно интересует такой момент: не приводит ли к преждевременному износу покрышек момент касания неподвижных колёс со взлётно-посадочной полосой при посадке? Вроде бы, решение есть элементарное — крыльчатки поставить на них, чтобы от набегающего воздуха раскручивались.
Про сына: напомнило задачу про 3 двери. За одной из них приз, и ведущий знает, за какой. Вы выбрали первую. Ведущий показал, что за второй дверью ничего нет. Поменять свой выбор на третью дверь или остаться на своём?
В чём нюанс
Исходная вероятность угадать: 1/2.
Ведущий может выбрать, какую из дверей открыть. Он выберет случайно между 2 и 3, только если приз за 1 (вероятность 1/3). В других 2 случаях — у него нет выбора. Значит, надо менять свой выбор на 3, вероятность успеха 2/3.
Так же и с сыном: нам предъявляют младшего или старшего ребёнка на свой выбор (в зависимости от того, кто из них сын). Если оба сына, то без разницы, кого предъявить. Получается, 1/3, что оба сына.
Понял свою ошибку: нам предъявляют не конкретного ребёнка (старшего или младшего), а того, который обладает нужным полом. Тогда, действительно, очень похоже на 1/3.
Что если ввести понятия старший/младший (или первый/второй). И может быть два равновероятных случая: в качестве сына упоминался старший либо младший ребёнок.
50%, что предъявили старшего. Тогда из 4 исходных комбинаций подходят 2: мальчик/мальчик, мальчик/девочка.
50%, что предъявили младшего. Тогда из 4 исходных комбинаций так же подходят 2: мальчик/мальчик, девочка/мальчик.
(50%*50%) + (50%*50%) = 50%.
Иначе говоря, если девочка/мальчик и мальчик/девочка считаются по какой-то причине разными случаями, то и мальчик/мальчик должны рассматриваться как два случая. Нам могли как бы упомянуть первого, а могли — второго (младшего).
Я бы разбил на хранимые функции как минимум для удобства чтения.
Из преимуществ текущего запроса — всё в одном месте, можно читать не переключаясь.
Но идея с хранимыми функциями мне тоже нравится. Если будет настроение и приведёте пример, какие можно было бы выделить функции — будет интересно.
если у пользователя отвалился бекенд то сервер вернёт 200, а при запросе к api пользователь ничего не увидит
Тут зависит от сайта. Если из-за неработающего API поменяется заголовок страницы, то бот сообщит. Можно, например, создать отдельную проверочную страницу для этих целей.
Можно отдельно добавить сам API в мониторинг (правда, никакой авторизации я не предусматривал).
Далее, когда сайт уже на мониторинге, беру два последних результата и сравниваю их с последним сообщённым пользователю временем ответа.
Если минимальное время из двух последних в два раза превышает последнее сообщённое время — сообщаю это новое время.
Если максимальное из двух последних в два раза меньше последнего сообщённого — тоже сообщаю.
В обоих случаях разница должна превышать минимальный порог в секунду.
Запросы делаю сейчас раз в 5 минут. Если 2 запроса подряд без ответа — шлю уведомление. К сожалению, многие сайты с завидной регулярностью "мерцают", пришлось добавить такой фильтр. Но некоторые и два раза подряд могут быть недоступны, а на третий раз отвечают — не знаю, с чем связано.
Держит на контроле: ✅ Доступность сайта и код ответа. 🌐 Срок регистрации домена — напомнит вовремя продлить. 🔒 Срок действия SSL-сертификата. ⌛ Время ответа — сообщит, если ждать пришлось дольше 5 секунд. 📰 Изменение заголовка страницы.
Работает с кириллическими доменами. Проверка — каждые 10 минут. 1 сайт на мониторинге — бесплатно, дополнительные — по 2 ₽ в день.
Код чуть-чуть сложнее, но не критично. А вот с точки зрения хранения в базе: очень заманчиво сделать уникальным ключом комбинацию Подписка+Дата. И дата будет однозначно указывать, за какой период оплата. При дневных же расчётах можно хранить так же, но уже возникает некая условность в виде конкретного расчётного часа, из-за которой в будущем можно будет запутаться: следующие сутки имелись в виду или предыдущие.
Так проще и для пользователей, и для меня. Не нужно каждый раз залезать в код/базу для добавления менеджера, не нужно пилить интерфейс админа, который не добавляет ценности (и не оплачивается).
Вероятность утечки этого ключа примерно такая же, как вероятность утечки пароля к интерфейсу — я же его точно так же в сообщении отправлю.
Даже если ключ утечёт (вместе со взломом Tg-аккаунта менеджера), то пользы злоумышленнику от него никакой. Разве что насоздаёт ссылок на оплату, пока мы через базу его не забаним. Реквизиты получателя он изменить не может.
Да, то есть клиент переходит на web-страницу Тинькофф, там оплачивает. Чек тоже от Тинькофф придёт. А бот получает от Тинькофф вебхук об оплате.
Меня тут спросили, во сколько заказчику обошёлся сей бот.
Тайны нет: 30 000 рублей и ещё 9 000 рублей за добавление ежедневных сводок с количеством и суммой оплат.
Очень давно интересует такой момент: не приводит ли к преждевременному износу покрышек момент касания неподвижных колёс со взлётно-посадочной полосой при посадке?
Вроде бы, решение есть элементарное — крыльчатки поставить на них, чтобы от набегающего воздуха раскручивались.
В чём же тогда смысл штрафовать за долговечность лампочек отдельных производителей? Надо было тогда штрафовать за низкую яркость, если она ниже нормы.
Про сына: напомнило задачу про 3 двери. За одной из них приз, и ведущий знает, за какой. Вы выбрали первую. Ведущий показал, что за второй дверью ничего нет. Поменять свой выбор на третью дверь или остаться на своём?
В чём нюанс
Исходная вероятность угадать: 1/2.
Ведущий может выбрать, какую из дверей открыть. Он выберет случайно между 2 и 3, только если приз за 1 (вероятность 1/3). В других 2 случаях — у него нет выбора. Значит, надо менять свой выбор на 3, вероятность успеха 2/3.
Так же и с сыном: нам предъявляют младшего или старшего ребёнка на свой выбор (в зависимости от того, кто из них сын). Если оба сына, то без разницы, кого предъявить. Получается, 1/3, что оба сына.
Понял свою ошибку: нам предъявляют не конкретного ребёнка (старшего или младшего), а того, который обладает нужным полом. Тогда, действительно, очень похоже на 1/3.
Что если ввести понятия старший/младший (или первый/второй). И может быть два равновероятных случая: в качестве сына упоминался старший либо младший ребёнок.
50%, что предъявили старшего. Тогда из 4 исходных комбинаций подходят 2: мальчик/мальчик, мальчик/девочка.
50%, что предъявили младшего. Тогда из 4 исходных комбинаций так же подходят 2: мальчик/мальчик, девочка/мальчик.
(50%*50%) + (50%*50%) = 50%.
Иначе говоря, если девочка/мальчик и мальчик/девочка считаются по какой-то причине разными случаями, то и мальчик/мальчик должны рассматриваться как два случая. Нам могли как бы упомянуть первого, а могли — второго (младшего).
Вот мои переназначения в PowerToys:
Не больше десятка пока что. Хостинг примерно окупается, да.
Из преимуществ текущего запроса — всё в одном месте, можно читать не переключаясь.
Но идея с хранимыми функциями мне тоже нравится. Если будет настроение и приведёте пример, какие можно было бы выделить функции — будет интересно.
Тут зависит от сайта. Если из-за неработающего API поменяется заголовок страницы, то бот сообщит. Можно, например, создать отдельную проверочную страницу для этих целей.
Можно отдельно добавить сам API в мониторинг (правда, никакой авторизации я не предусматривал).
Есть ещё регулярный отчёт за сутки/неделю, в нём можно посмотреть статистику времени ответов, если Вы об этом:
Замеряю чисто время отработки curl, вот так:
Далее, когда сайт уже на мониторинге, беру два последних результата и сравниваю их с последним сообщённым пользователю временем ответа.
Если минимальное время из двух последних в два раза превышает последнее сообщённое время — сообщаю это новое время.
Если максимальное из двух последних в два раза меньше последнего сообщённого — тоже сообщаю.
В обоих случаях разница должна превышать минимальный порог в секунду.
Запросы делаю сейчас раз в 5 минут. Если 2 запроса подряд без ответа — шлю уведомление. К сожалению, многие сайты с завидной регулярностью "мерцают", пришлось добавить такой фильтр. Но некоторые и два раза подряд могут быть недоступны, а на третий раз отвечают — не знаю, с чем связано.
Telegram-бот для мониторинга ваших сайтов.
Держит на контроле:
✅ Доступность сайта и код ответа.
🌐 Срок регистрации домена — напомнит вовремя продлить.
🔒 Срок действия SSL-сертификата.
⌛ Время ответа — сообщит, если ждать пришлось дольше 5 секунд.
📰 Изменение заголовка страницы.
Работает с кириллическими доменами.
Проверка — каждые 10 минут.
1 сайт на мониторинге — бесплатно, дополнительные — по 2 ₽ в день.
https://t.me/daily_site_monitor_bot?start=r_5018__u_258__t_1
Да, забыл уточнить: "ориентироваться на 10 утра Мск".
Тоже склоняюсь к варианту рассчитываться днём.
Код чуть-чуть сложнее, но не критично. А вот с точки зрения хранения в базе: очень заманчиво сделать уникальным ключом комбинацию Подписка+Дата. И дата будет однозначно указывать, за какой период оплата. При дневных же расчётах можно хранить так же, но уже возникает некая условность в виде конкретного расчётного часа, из-за которой в будущем можно будет запутаться: следующие сутки имелись в виду или предыдущие.
Дельное замечание, боту в Telegram недоступен часовой пояс.
Но учитывая, что бот (пока что) русскоязычный, можно условно ориентироваться на Мск, чтобы никого не разбудить.
Это было бы так, если бы был
JOIN. В случае сLEFT JOINразница есть.Вот тут добавил все варианты, можно посравнивать: https://www.db-fiddle.com/f/dMR923n7iJnoeUZG9xhfaR/0
Ещё в
WHEREдолжно быть неlc.db_message_id, аc.db_message_id. Вот тогда да.