С шансами окажется через полгода, что в 17ом отделе повысилась текучка на 45%. Exit interview показывают, что работники отвечают «мы не знаем, в чем дело, но зарплата наша упала. Нет, за счет чего не знаем, но раньше че-то больше выходило».
Еще раз. Регулярная встреча назначена на 12:00 ЛОКАЛЬНОГО ВРЕМЕНИ ЛОНДОНА. Потому что именно так пользователи назначают встречи. Самолет улетает через год 29 июля в 12:00 по времени Лондона.
Если вы будете хранить это время в UTC, вы ошибетесь.
Положим также, что я купил билет на самолёт следующим летом с вылетом из Лондона в 12:00. Если все пойдет так, как сейчас, то это будет 13:00 UTC. Маловероятно, но реально событие, что к следующему лету британское правительство отменит летнее время и будет 12:00 UTC.
Если вы в вашем приложении не сохраните данные о часовом поясе, я опоздаю на самолёт.
Это неправильно. В бизнес логике надо хранить время вместе с часовым поясом. Особенно это касается всяких расписаний. В реальном мире события планируются не на 9:00 UTC, а на 12:00 MSK. И если MSK сдвинется относительно UTC, то и события сдвинется. Надо просто всегда помнить про часовой пояс и оперировать временем ВМЕСТЕ с часовым поясом…
Ну например логи: давайте сделаем сценарий, куда мы пишем всюду логи постоянным случайным потоком, 1% Error, 99%info, и будем дергать раз в 5 минут запрос «ошибки за последний день».
Надо мерять не производительность query cache/чего угодно, а производительность ПОЛЬЗОВАТЕЛЬСКИХ СЦЕНАРИЕВ. Я готов вам поверить, что пользовательский сценарий «база после перезагрузки начистую, в которую никто не пишет, и абсолютно холодная», в нее делаются одноразовые запросы — этот сценарий у Мантикоры хорош. Я просто ни разу в жизни с ним не встречался.
Или data analyst, делающий разнообразные запросы, чтобы поймать какие-то закономерности и найти интересные факты: каждый из запросов он сделает один раз
Это не запросы в холодную. Это каждый из запросов он сделает один раз ПОСЛЕ ДРУГОГО запроса. Т.е. внутренние кеши БД будут прогреты, даже если не будет 100% попадания к query cache
С шансами окажется через полгода, что в 17ом отделе повысилась текучка на 45%. Exit interview показывают, что работники отвечают «мы не знаем, в чем дело, но зарплата наша упала. Нет, за счет чего не знаем, но раньше че-то больше выходило».
Это «не работает как перевод». Просто при такой оплате комиссия банка значительно ниже и сооветственно нет кешбека.
После перевыпуска симки у тебя сутки не ходят SMS (Мегафон)
Для андроида надо скачать RuStore и приложение Сбера будет обновляться
Я работал на датскую компанию, которая буквально на 90% своей продукции в Дании выполняла только операцию прикручивания шильдика «Сделано в Дании» :-)
Но разработка конечно была датская + российская
Если вы будете хранить это время в UTC, вы ошибетесь.
Положим также, что я купил билет на самолёт следующим летом с вылетом из Лондона в 12:00. Если все пойдет так, как сейчас, то это будет 13:00 UTC. Маловероятно, но реально событие, что к следующему лету британское правительство отменит летнее время и будет 12:00 UTC.
Если вы в вашем приложении не сохраните данные о часовом поясе, я опоздаю на самолёт.
Тем не менее все календари (exchange, google calendar) делают именно так, как я сказал.
Простой пример: пусть у нач назначена регулярная встреча в 12:00 каждый день в Лондоне. Она будет летом в 13:00 UTC, в зимой в 12:00 UTC
>. Коды возврата приходится анализировать отладчиком до проверки условия.
А может отладчик нормальный завести?
Эта идея очень малоинтересная, если честно.
Так это же наоборот хорошо
Это не запросы в холодную. Это каждый из запросов он сделает один раз ПОСЛЕ ДРУГОГО запроса. Т.е. внутренние кеши БД будут прогреты, даже если не будет 100% попадания к query cache
В моей практике по логам работает алертинг.