Про сына: напомнило задачу про 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 ₽ в день.
Код чуть-чуть сложнее, но не критично. А вот с точки зрения хранения в базе: очень заманчиво сделать уникальным ключом комбинацию Подписка+Дата. И дата будет однозначно указывать, за какой период оплата. При дневных же расчётах можно хранить так же, но уже возникает некая условность в виде конкретного расчётного часа, из-за которой в будущем можно будет запутаться: следующие сутки имелись в виду или предыдущие.
Дело в том, что из результатов берутся разные поля. Из последнего запроса я беру код ответа, а из последнего успешного беру заголовок и срок SSL-сертификата.
А если будет две строки, то нужно будет потом в php ещё определять, из какой строки что брать.
Брать сразу для всех подписок — может быть, нормальный вариант, надо сравнивать. Вполне возможно, этот рефакторинг того не стоит, сейчас этот запрос уже не узкое место.
Про сына: напомнило задачу про 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. Вот тогда да.Он не полностью идентичен: если нет ни одной записи с
lc.response_received = true, то не вернётся ничего.Дело в том, что из результатов берутся разные поля. Из последнего запроса я беру код ответа, а из последнего успешного беру заголовок и срок SSL-сертификата.
А если будет две строки, то нужно будет потом в php ещё определять, из какой строки что брать.
Брать сразу для всех подписок — может быть, нормальный вариант, надо сравнивать. Вполне возможно, этот рефакторинг того не стоит, сейчас этот запрос уже не узкое место.
Почему Вы считаете такое будущее мрачным?
Проблема в том, что MySQL 5.7 (который у меня на хостинге) не поддерживает
WITH.Мне 4o тоже предлагал какие-то варианты, но они не помогли.
Фото → Поделиться → Параметры → Наиболее совместимый формат, затем сохранить или отправить.
P. S. Надеюсь, американцы не прочитают.