Прямой вопрос - есть ли всетаки в Постргесе аналог верификации бэкапа?
Уже несколько версий как есть, прям так и называется - pg_verifybackup.
Вы каким бесплатным и удобным инструментом пользуетесь?
В основном это barman, но кое-где и pgbackrest. Но они, насколько я помню, не для Windows. Под Windows вообще мало чего для Postgres, по вполне объяснимым причинам.
Если для вас удобство это "один клик" и GUI - тогда увы, это не тот случай. Для меня удобство - один раз настроил и забыл, оно просто работает.
Таким образом при восстановлении чего либо в Postgres Вы можете быть уверены в качестве восстановления, только «потрогав» все таблицы и индексы. А когда их тысячи (как в любой типовой базе 1С ) это занимает значительное время.
Это верно для абсолютно любой базы и вообще любого бэкапа, в том числе файлового.
Не "потрогав" данные в бэкапе и не сравнив это с оригиналом, бит в бит, вы никогда не можете быть уверены в качестве восстановления на 100%.
В самом лучшем случае можно сравнивать хеши которые строятся в процессе создания бэкапа, но даже в этом случае чтобы убедиться что всё в порядке, придётся прочитать все данные в бэкапе.
Можно проверить наличие файлов при старте - да, но это не даёт никакой уверенности, потому что данные внутри этих файлов, где-то глубоко внутри, могут быть повреждены и выяснится это только когда к ним кто-то полезет.
Но если очень хочется сделать quick check - то в Postgres это делается парой простых запросов при старте, перед тем как решить отпускать ли это для всех, и разумеется это займёт некоторое время при очень большой базе.
На самом деле, даже если вы сделали бэкап и сравнили его с оригиналом трижды, у вас всё равно не может быть 100% уверенности что всё в порядке - мало ли что с данным в бэкапе случится когда он понадобится через пару недель или месяцев, bit rot никто не отменял, и поможет тут только хороший хэш и чтение всех данных (я именно так и проверяю бэкапы периодически).
По поводу контрольных сумм - на современных процессорах они вообще не влияют на производительность, там в худшем случае менее 1%, и они включены по умолчанию в последних версиях (но может зависеть от дистрибутива и мейнтейнера). Впрочем, они проверяются только при обращении к данным - т.е. опять таки, не прочитав всё, не узнаете есть ли проблемы - и это верно не только для Postgres.
Postgres отлично бэкапится и в процессе работы, без остановки - простым File Level Backup, с индексами и всеми потрохами, даже простым rsync/restic/rustic/borg/etc, нужно только обернуть его в pg_start_backup()/pg_stop_backup() - на выполнение запросов это не повлияет, разве что их замедлит.
Да, если у вас всё не в одном месте, вам придётся позаботится о симлинках и прочих странных местах где вы храните таблицы, но есть куча инструментов которые это автоматизируют (бесплатных, да).
И наконец, есть Continuous Archiving, который настолько надёжен насколько надёжны ваша сеть и диски - то есть если исключить потенциальную порчу данных в процессе передачи по сети, записи на диск, а также повреждение оных в памяти или на диске, у вас будет всегда готовая к использованию копия базы, не говоря уже про бонусы вроде PITR и даже delayed replication (когда secondary отстаёт от primary на заданное время, но без потери актуальных данных).
Всё это хорошо описано в документации, даже с примерами, не говоря уже о бесчисленных ресурсах посвященных этой теме.
PS: У меня за более чем 15 лет работы с Postgres (начиная с версии 8.0), никогда не было проблем ни с бэкапами, ни с их восстановлением, которое периодически производится как в случае жёстких падений железа так и для "взгляда в прошлое".
В нашем ДЦ сотни систем, многим больше 5 лет, есть около двух десятков которым уже чуть больше 10 лет, и ещё не было ни одного умершего вентилятора. Умирали БП, память, материнки - но не вентиляторы, а их в среднем по 7 штук на систему. У нас даже отдельный стеллаж для них есть - вытаскивали из старых систем на случай если придётся менять, но так и не пришлось.
Недавно избавились от древности (сервер в tower-варианте) которая работала аж с 1998 года - причём не потому что что-то умерло, просто нафиг уже не нужен был, но с вентиляторами в нём тоже всё ок было.
У меня лично есть три старых машинки которым уже больше 7 лет - один Shuttle XPC, один Zotac ZBOX и один очень старый десктоп (все работают 24/7) - совсем не серверные варианты, и у них тоже всё ок с вентиляторами (которые тоже работают 24/7, без всяких "умностей").
Золотое дно, не иначе.
Если бы вентиляторы стоили сотни баксов и выходили из строя хотя бы раз в год, или хотя бы два года - может быть. Но они стоят от 5 до 20 евро штука и невероятно живучи.
Даже на жидкостное охлаждение от нормальных контор гарантия от 5 до 7 лет - а там минимум два вентилятора в комплекте, не говоря уже о помпе.
Хотя не исключаю что у китайцев всё иначе - вентиляторы мрут как мухи и при этом стоят как чугунный мост, небось ещё и с чипом чтоб работали только со своими системами.
Обычно когда хобби превращается в работу, оно становиться просто работой.
Так происходит только если хобби и работа отличаются. Точнее, если для той части которая "работа" (т.е. зарабатывание денег) приходится отвлекаться от основного занятия или что-то менять для более красочной подачи, не говоря уже о том чтобы делать это не когда хочется а когда надо, а то и хуже - не совсем так как хочется.
Если бы, к примеру, этот мужик продолжал ловить рыбу как "до передачи", по удобному для него графику, а съёмкой и всем остальным занимался кто-то другой, при этом не отствечивая и не вынуждая его отвлекаться ради хороших кадров, и даже не привлекая его потом в процессе монтажа - то сомневаюсь что он потерял бы интерес.
Мне встречались люди которые именно так и работали - они просто делали то что нравится, а собственно зарабатыванием занимался кто-то ещё, не вмешиваясь в их процессы но используя результаты их труда. Некоторые из них занимались своим делом больше 20 лет, и интерес совсем не угасал.
В обоих случаях будет вычисляться аргумент user, и если это что-то сложнее обычной переменной (типа вызова функции) то возможны и побочные эффекты и замедление.
Сборка же самой строки, как правило, занимает ничтожное время по сравнению со всем остальным, так что выигрыш тут близок к нулю, разве что имеем дело с объектами - там ещё будет экономия на отсутствии вызовов __repr__ или __str__, и то только если они сложные и/или медленные.
Единственный надёжный способ с этим бороться - это использовать конструкции типа:
if __debug__:
logger.debug(f"User {user} logged in")
В этом случае, если приложение запускается не в отладочом режиме (python -O) то всё что внутри if __debug__ вообще будет вырезано и не будет выполняться.
К сожалению, эта магия работает только с __debug__ и только если нет других условий - удобной условной компиляции методов как в C# у Python нет, увы.
Я прямо сейчас могу заявить что вы - гениальный серийный убийца не оставляющий следов...
Ну хоть что-то придётся таки сказать, кроме собственно заявления.
Сослаться например на признание по пьяне (без записи и свидетелей) или что-то типа - потому что само по себе такое заявление при наличии отсутствия доказательств вызывает обоснованные сомнения - если оставленных следов нет в принципе, то как такая мысль вам вообще пришла в голову? Разве что всех гениев априори считать потенциальными серийными убийцами - "аппарат-то есть".
В рассматриваемом же случае есть как минимум ненулевая вероятность именно по факту причастности к не совсем белой и пушистой организации. Да, вероятность, не факт - но всё же не "следов нет".
К тому же, как показывает практика, "бывшие" (из разномастных малобуквенных контор) часто оказываются связанными с этими конторами и после ухода, причем чем выше у человека была должность, доступ или связи тем выше вероятность.
Есть маленький нюанс - это "3 мес" и "2 года" при условии что диск уже на пределе TBW (таковы требования JEDEC). Если он далеко от предела и температура хранения существенно ниже указанной в спецификации - то речь может идти о 5-10 годах, если не больше.
Глупости, говорите? Что ж, видимо Hetzner круто попали, раз построили всё свою облачную инфраструктуру на NVMe SSD которые скручены в RAID10 - явно не ведают что творят. Как, впрочем, и другие облачные провайдеры - не знают пацаны что всё накроется медным тазом в любой момент.
... могут выдавать на чтение и запись до 7800 МБ/с. Но это в теории. На практике найти применение таким мощностям будет довольно сложно.
На практике эти 7800 MB/s быстро окажутся "вообще ни о чём" если на тачке крутится с десяток виртуалок или нагруженная БД. Для игр и прочей офисной деятельности - конечно это вообще неактуально.
Raid 1 - это очень безопасно, но накладно.
Не факт. Если вам нужна надёжность и бюджет несколько ограничен - то два накопителя в RAID 1 будет дешевле чем три в RAID 5 на ту же ёмкость, а выигрыша нет и вовсе - всё равно он выдержит "вылет" не более чем одного диска.
Если ёмкость нужна большая и "не влазит" в один накопитель - тогда да, можно и RAID 5. Но всё же, я предпочитаю полное дублирование чем RAID 5, RAID 10 всяко надёжнее да и шустрее к тому же при записи, при прочих равных.
Вообще если говорить про "накладно" нужно считать что окажется дороже - двойная оплата или потеря данных. Обычно второе на порядки дороже, если конечно это не архив с котятами, да и при нынешней стоимости накопителей (в том числе SSD) это не то о чём стоит беспокоиться.
Что же касается NVMe - у них есть "фатальный недостаток" - менять их на лету очень тяжко, решения конечно есть но стоят они как крыло от самолёта, в отличие от SATA/SAS где hot-swap вообще почти ничего не стоит даже для домашнего ДЦ. Впрочем, если речь не про сервис где минута простоя стоит как чугунный мост, то вполне можно разобрать и заменить.
Не смотря на NDA, судя по вашей агрессии, сразу возникает впечатление, что с вами будет сложно договориться. Что вы всегда в команде будете тянуть одеяло на себя. Что вы тяжело признаёте чужую правоту. А эти скиллы чаще всего сводят на нет все ваши профессиональные навыки.
Совсем не факт. Я мог бы написать такое про себя, даже почти в таком же тоне, разве что с NDA чуть полегче было, но я не тяну одеяло на себя и легко признаю любую правоту (равно как и свою неправоту), при наличии аргументов разумеется, и проблем со мной ни у кого не возникает.
Есть только один реальный и надёжный способ проверить, годится человек для работы или нет - это дать ему работу и посмотреть на результат, включая взаимодействие с командой и вот это всё, как правило, 3х месяцев хватает, в худшем случае полгода.
Никакие собеседования не дадут полной картины - человек может произвести супер впечатление и по CV и на всех собеседованиях, но окажется никаким спецом или просто козлом, и хорошо если только одним из этих двух, в то же время кто-то может вообще не произвести впечатления (или даже произвести отрицательное) но будет крут во всем, от хард до софт скиллов - просто ему нужно реально начать работу.
В приниципе код хороший, отличный даже, и наверняка закроет 99.9% всех типичных кейсов, хотя пара моментов всё же не учтена.
Я не знаю что там в стандарте, но зравый смысл требует чтобы код вернул ошибку в случае потери точности (если мантиссы не хватит), а не только если на входе не число.
Т.е. даже если наш double соответствует IEEE 754 то у нас всего 52 бита, а это маловато как-то если получим на входе хотя бы 17 знаков, но поскольку C не гарантирует что это будет именно 64 бита double precision (не говоря уже о том что это может быть и вовсе не IEEE 754) то результат может оказаться чуть печальней чем хотелось бы, особенно если код используется в чём-то критичном типа авиации или автомобилей.
Подобная проверка может показаться избыточной на таких многозначных числах - но её наличие позволит поймать случаи когда входные данные неадекватны.
С переполнением тоже не всё гладко - если повезет, то получим на выходе INF (хотя его ещё нужно будет проверять в месте вызова), но можем нарваться и на SIGFPE (или его аналог) или просто на мусор в результате.
@aabzelВаш код из статьи тоже "посыпется" если на входе будет что-то многозначное, но ситуация усугубляется ещё и тем что вы используете uint64_tдля разбора целой части - т.е. возможные переполнения вообще могут оказаться незамеченными. Может быть именно по этой причине задачка получила уровень "hard" - разбор чисел с плавающей точкой (да и просто целых тоже) это совсем не так просто если нет никаких гарантий о качестве входных данных. И да, судя по всему их тесты описанные выше случаи явно не покрывают.
К тому же, конечный автомат в данном случае это перебор - медленно, громоздко и плохо читаемо и понимаемо (= высокая когнитивная нагрузка).
Применение IQ напрямую коррелирует с качеством жизни.
Массы талантливых или близких к ним инженеров, учёных, преподавателей, врачей занялись челночной торговлей в своё время, так и не найдя применения своему IQ. Точнее, применять-то его было где, только вот на качество жизни это не влияло совсем. Некоторые (подавляющее меньшинство) потом таки выбрались, но часто не в своих областях.
В то же время личности совсем не отягощенные IQ и по сей день часто имеют намного более высокое качество жизни, и на этом не останавливаются, причём именно на них обычно работают те у кого IQ выше, хотя по идее должно было бы быть наоборот.
Ситуация мало изменилась и в наше время - из тех у кого реально высокий IQ выбиваются вперёд единицы, а не массы, так что наверное всё же корреляция не настолько прямая.
воевать будут роботы против роботов, а не люди
Конечно роботы. А страдать будут таки люди. От последствий войны роботов.
Не означает. В обычных лотереях никто не мешает любому количеству билетов (необязательно у одного владельца) иметь одинаковую комбинацию, и если она оказывается выигрышной то выигрыш делится между всеми билетами.
То есть, другими словами, заполнив билет вы не получаете экслюзивные права на определенную комбинацию, и если синдикат имеет всего один билет с выигрышем джек-пота но при этом ещё сотня человек использовала такую же комбинацию - то джек-пот (и вообще любой выигрыш на этом уровне) поделят между всеми.
Впрочем, ушлые лотереи успешно борются с описанными схемами - например, стоимость выкупа всех билетов никогда не может быть меньше чем сумма джекпота, а обеспечивается это просто - если джек-пот превышает определённую сумму, он перераспределяется между теми кто на более "низком" уровне - т.е. теми кто взял бы второй приз, если таковых не оказывается - то теми кто на третьём месте, и на этом как правило всё заканчивается.
И кстати, лотерея при любом раскладе не проиграет - они получают прибыль с каждого проданного билета, в кассу выигрыша отправляется только часть, так что единственное что им угрожает это разочарование игроков и возможное снижение популярности. Но это только если схема всплывёт.
validate_input - похоже на какую-то попытку сделать из нетипизированного языка типизированный.
Это похоже на попытку убедиться что на входе получено ровно то что ожидается - очень хорошая практика.
Как минимум валидация помогает при отладке, как максимум - во всех остальных случаях когда у вас нет 101% уверенности что на входе будут только ожидаемые данные, например, если вы пишите библиотеку, или если значения аргументов получены извне (введены пользователем, переданы API etc).
Гораздо проще аннотировать аргументы и отдать валидацию декоратору чем вручную это делать внутри каждой функции где существует риск, не говоря уже про DRY.
Дополнительная польза валидации на входе - это чёткое сообщение о том что и где пошло не так, а не непонятное исключение где-то в глубине которое возникло по причине неверного аргумента.
Впрочем, расчитывать на то что неправильный аргумент обязательно вызовет исключение не стоит - к примеру, если у вас на входе ожидается целое число в диапазоне от 3 до 7 и оно используется в вычислениях, но при этом на вход кто-то подал 13 - исключения не будет, будет неверный результат.
В конце концов, pydantic и его @validate_arguments не просто так появились - тот кто игнорирует валидацию обязательно нарвётся, или хуже того - подставит кого-то ещё.
Покупатель прислал фермеру текстовое соглашение с контрактом и попросил его «подтвердить» получение.
На самом деле это не совсем так. А точнее, совсем не так.
Дело гораздо сложнее и нюансов там много, но вот момент с эмодзи был совсем в другом: покупатель обсуждал контракт с продавцом по телефону, потом сделал бумажный черновик для продавца и даже подписал его (ручкой), далее он его сфотографировал и отправил продавцу с просьбой подтвердить контракт (а не его получение, в оригинале “Please confirm flax contract”) - и именно на это продавец отреагировал эмодзи "палец вверх".
С учётом этого решение судьи выглядит вполне обоснованным и дело не только в эмодзи, хотя конечно это сыграло существенную роль - но только в связи с контекстом.
EDIT: Ещё важный факт. Несмотря на наличие "массовой рассылки", этот покупатель регулярно покупал зерно у этого же продавца на протяжении последних 10 лет, т.е. это было не просто случайное сообщение случайному продавцу.
Этот процент отражает вероятность построения гармоничных отношений с представителем противоположного пола.
На самом деле этот процент отражает только вероятность того что людям будет интересно общаться в первое время (но это не точно), или вероятность того что им будет о чём поговорить на первом свидании. Это может быть один день, неделя, месяц или год - но этот процент никогда не покажет какова вероятность продолжения отношений (причём не факт что сохранится гармоничность, если будет вообще) через 5 или 10 лет, не говоря уже о больших периодах, и они разумеется совершенно не учитывают измненения в людях которых происходят в процессе этих самых отношений, самой жизни и ещё кучи факторов которые не учесть и не предусмотреть.
Отношения это гораздо больше чем общие интересы или что-то ещё о чём можно узнать в тестах, это ещё тысячи всяких мелочей о которых человек может и не знать пока не будет с ними встречаться на протяжении длительного времени в определеных условиях, и ни в какой вопросник это не впихнуть, а если и впихнуть (вдруг) - то там будет 100500 вопросов и сложнейшая система уравнений с таким же количеством переменных чтобы просчитать реальную вероятность, и то она будет актуальной только в следующие два дня.
Из жизни: мои самые короткие (и весьма неприятные в итоге) отношения были когда казалось что мы идеально подходим друг другу - это казалось аж пару месяцев. И самые длительные - когда мы как раз отличались вообще во всём и даже, в начале, почти ненавидели друг друга - но и через 10 лет они остались вполне гармоничными. Если бы мы проходили тесты, то скорее всего в первом случае вероятность была бы близка к 100% а во втором наоборот, к 0%.
Минимум половина людей в моём круге общения прошла примерно через это же - а это около сотни человек. Да, чуток не дотягивает до 1200 пар, но зато это точно проверено временем (отрезок в 10-20 лет), а не "познакомились год назад и ещё вместе".
Оценивать эффективность таких "вероятностей" нужно минимум через 5-10-15 лет отношений, но там статистика совершенно другая получается - есть у вас такие исследования и опросы? Впрочем, их проводили другие и их вполне можно найти в сети - там интересные цифры получаются, но очень непривлекательные для рекламы.
Многие аналогичные сервисы бодро рапортуют о "проценте счастья" - число счастливых пар которые в итоге вступили в брак или типа того, но никто из не говорит о том что случилось с этими парами через пресловутые 5 лет, или после того как у этих пар появились дети, или после того как эти пары прошли через всякие неприятности в жизни, или... в общем я надеюсь понятно о чём речь.
Про всё это вы в рамках своей полики честности вряд ли напишете, зато будете убеждать потенциальных клиентов что ваши тесты и алгоритмы самые научные и надёжные.
Впрочем... для людей которые не любят загадывать дольше чем на год вперёд - любая "вероятность" вполне себе заманиловка, это придаёт некую научность сервису, хотя суть остается прежней - это просто очередной способ познакомиться, не более того.
Если человеку нужна шпаргалка для ответов на эти вопросы, то к работе с БД его допускать не стоит.
Я на собеседованиях показываю SQL и прошу объяснить что будет в базе после его выполнения а также прошу объяснить как человек решит конкретную задачу, разумеется с подвохом (которые требуют знаний о ACID/MVCC, индексах и разных уровней изоляции) - сразу становится ясно кто зубрил а кто знает.
.... If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
Большинство подобных валидаторов обладают как минимум одним фатальным недостатком - они проверяют теоретическую возможность отправки, а это (как правило) совсем не то что нужно.
Что же нужно? Нужно убедиться что потенциальный получатель действительно может получить,прочитать и понять письмо.
Единственный способ это сделать - собственно, отправить соответствующее письмо с просьбой его подтвердить нужным способом - ответить на него, пройти по ссылке, отправить SMS или позвонить на хотлайн (да, бывает и такое).
До этого, разумеется, нужно проверить существование домена, наличие MX или IP адреса - но не более.
Проверки доступен ли сервер (HELO/EHLO), ответа на RCPT TO и любые другие которые не отправляют писем - недостаточны - во-первых, сервер может быть недоступен в данный конкретный момент времени (даже если это Гугль или Microsoft), во-вторых, он вполне может отбить письмо и после отправки тела через DATA, причём не просто отбить а даже сказать "нет такого ящика" (для корпоративных серверов вполне себе реалистичный сценарий, если там пара прокси по дороге).
Если сразу отправить не удалось - можно сказать про это пользователю и предложить подождать, а через некоторое время - и повторить. Если письмо отбито после DATA - об этом тоже можно сказать и попросить разобраться или изменить email, или повторить позже.
В любом случае результат валидации нужно сообщить пользователю - либо сказать "всё ок", либо дать максимум информации если что-то пошло не так (включая ответ его почтовика - сильно помогает с разборками).
Что же до самого адреса (до @) - как уже выше заметили, не надо его проверять, он может быть любым - включая "A & Б сидели на трубе!"@почта.где-то.там и без ограничения по длине в 16-20 символов. Сервисы же которые выпендриваются и даже "+" не разрешают в адресе вообще должны гореть в аду, не говоря уже о тех которые отказываются принимать вполне себе символьные имена которые по их мнению "неправильные" или "невозможные" (вспоминается eBay - они не разрешали email независимо от домена если в нём была подстрока "ebay", причём служба поддержки отморозилась в духе "у вас не может быть такого email").
Почему это "невыгодно"? Да, налоги платить придётся, но часть меньше целого, и если компания получила прибыль в условный миллион и выплатила условный же налог в 25% - она всё равно получила чистую прибыль в размере 750 тыс, что явно больше нуля.
"Не выгодно" - это когда вложили X и получили < X, во всех остальных случаях всё сводится к "насколько выгодно" и размеру жабы. И да, есть компании которые работают "в ноль" - прибыли у них либо нет либо она очень небольшая, зато есть стабильный доход благодаря которому она существует и платит зарплаты сотрудникам (на всякий случай напомню - "прибыль компании" - это доходы минус все расходы, в которые входят и зарплаты).
Более простой пример - вы получаете зарплату в размере X, и платите с неё налоги. Вы откажетесь от зарплаты X*2 просто потому что с разницы тоже придётся платить налоги? Разумеется, вы предпочтёте получить её "в конверте", но далеко не все и не везде могут себе такое позволить, да и чревато это.
С компаниями ровно то же самое. Да, они стараются минимизировать налоги, не платить если есть возможность, но ни одна из компаний не откажется от прибыли просто потому что с неё нужно платить налоги. К тому же, далеко не везде прибыль можно "спрятать", а если поймают - это будет очень дорого и больно, да и ловят хорошо.
Более того, "отрицательная прибыль" очень быстро приведёт к ликвидации компании - во многих юрисдикциях она допустима на достаточно короткий срок (в лучшем случае несколько лет). Если исключить всякие "схемы", никакая честная компания на это не пойдёт.
Увеличивать капитализацию сложно при отсутствии видимой прибыли - инвесторы не будут вкладываться в компанию у которой нет прибыли, стоимость акций будет падать а не расти. Посмотрите на колебания стоимости акций когда компания в очередном квартальном отчете заявляет что получила всего на несколько процентов меньше прибыли чем ожидалось - всё сразу станет очевидно.
Вопреки "бытовому" мнению зарабатывать на стоимости акций не так-то просто - пока вы их держите у вас нет ничего кроме акций, реально вы что-то получите на руки (в виде денег) только когда решите их продать, и в этот момент их цена может оказаться очень неожиданной.
Наконец, далеко не все (даже крупные - типа Vitol, Aldi или Huawei) компании являются акционерными - там нет капитализации как таковой.
Все крупнейшие компании предпочитают быть убыточными ...
Правда? Microsoft, Google, Apple, Nvidia, Tesla - предпочитают быть убыточными? Да ещё тысячи компаний более мелких - предпочитают как раз быть прибыльными.
В налогах нет ничего страшного, в самом худшем случае это просто неприятно, но отказываться от прибыли просто потому что с неё придётся платить налоги - глупо. Лучше получить большую часть чем не получить ничего вообще из-за нежелания платить налоги.
Уже несколько версий как есть, прям так и называется - pg_verifybackup.
В основном это barman, но кое-где и pgbackrest. Но они, насколько я помню, не для Windows. Под Windows вообще мало чего для Postgres, по вполне объяснимым причинам.
Если для вас удобство это "один клик" и GUI - тогда увы, это не тот случай. Для меня удобство - один раз настроил и забыл, оно просто работает.
Это верно для абсолютно любой базы и вообще любого бэкапа, в том числе файлового.
Не "потрогав" данные в бэкапе и не сравнив это с оригиналом, бит в бит, вы никогда не можете быть уверены в качестве восстановления на 100%.
В самом лучшем случае можно сравнивать хеши которые строятся в процессе создания бэкапа, но даже в этом случае чтобы убедиться что всё в порядке, придётся прочитать все данные в бэкапе.
Можно проверить наличие файлов при старте - да, но это не даёт никакой уверенности, потому что данные внутри этих файлов, где-то глубоко внутри, могут быть повреждены и выяснится это только когда к ним кто-то полезет.
Но если очень хочется сделать quick check - то в Postgres это делается парой простых запросов при старте, перед тем как решить отпускать ли это для всех, и разумеется это займёт некоторое время при очень большой базе.
На самом деле, даже если вы сделали бэкап и сравнили его с оригиналом трижды, у вас всё равно не может быть 100% уверенности что всё в порядке - мало ли что с данным в бэкапе случится когда он понадобится через пару недель или месяцев, bit rot никто не отменял, и поможет тут только хороший хэш и чтение всех данных (я именно так и проверяю бэкапы периодически).
По поводу контрольных сумм - на современных процессорах они вообще не влияют на производительность, там в худшем случае менее 1%, и они включены по умолчанию в последних версиях (но может зависеть от дистрибутива и мейнтейнера). Впрочем, они проверяются только при обращении к данным - т.е. опять таки, не прочитав всё, не узнаете есть ли проблемы - и это верно не только для Postgres.
Postgres отлично бэкапится и в процессе работы, без остановки - простым File Level Backup, с индексами и всеми потрохами, даже простым rsync/restic/rustic/borg/etc, нужно только обернуть его в
pg_start_backup()/pg_stop_backup()- на выполнение запросов это не повлияет, разве что их замедлит.Да, если у вас всё не в одном месте, вам придётся позаботится о симлинках и прочих странных местах где вы храните таблицы, но есть куча инструментов которые это автоматизируют (бесплатных, да).
И наконец, есть Continuous Archiving, который настолько надёжен насколько надёжны ваша сеть и диски - то есть если исключить потенциальную порчу данных в процессе передачи по сети, записи на диск, а также повреждение оных в памяти или на диске, у вас будет всегда готовая к использованию копия базы, не говоря уже про бонусы вроде PITR и даже delayed replication (когда secondary отстаёт от primary на заданное время, но без потери актуальных данных).
Всё это хорошо описано в документации, даже с примерами, не говоря уже о бесчисленных ресурсах посвященных этой теме.
PS: У меня за более чем 15 лет работы с Postgres (начиная с версии 8.0), никогда не было проблем ни с бэкапами, ни с их восстановлением, которое периодически производится как в случае жёстких падений железа так и для "взгляда в прошлое".
В нашем ДЦ сотни систем, многим больше 5 лет, есть около двух десятков которым уже чуть больше 10 лет, и ещё не было ни одного умершего вентилятора. Умирали БП, память, материнки - но не вентиляторы, а их в среднем по 7 штук на систему. У нас даже отдельный стеллаж для них есть - вытаскивали из старых систем на случай если придётся менять, но так и не пришлось.
Недавно избавились от древности (сервер в tower-варианте) которая работала аж с 1998 года - причём не потому что что-то умерло, просто нафиг уже не нужен был, но с вентиляторами в нём тоже всё ок было.
У меня лично есть три старых машинки которым уже больше 7 лет - один Shuttle XPC, один Zotac ZBOX и один очень старый десктоп (все работают 24/7) - совсем не серверные варианты, и у них тоже всё ок с вентиляторами (которые тоже работают 24/7, без всяких "умностей").
Если бы вентиляторы стоили сотни баксов и выходили из строя хотя бы раз в год, или хотя бы два года - может быть. Но они стоят от 5 до 20 евро штука и невероятно живучи.
Даже на жидкостное охлаждение от нормальных контор гарантия от 5 до 7 лет - а там минимум два вентилятора в комплекте, не говоря уже о помпе.
Хотя не исключаю что у китайцев всё иначе - вентиляторы мрут как мухи и при этом стоят как чугунный мост, небось ещё и с чипом чтоб работали только со своими системами.
Так происходит только если хобби и работа отличаются. Точнее, если для той части которая "работа" (т.е. зарабатывание денег) приходится отвлекаться от основного занятия или что-то менять для более красочной подачи, не говоря уже о том чтобы делать это не когда хочется а когда надо, а то и хуже - не совсем так как хочется.
Если бы, к примеру, этот мужик продолжал ловить рыбу как "до передачи", по удобному для него графику, а съёмкой и всем остальным занимался кто-то другой, при этом не отствечивая и не вынуждая его отвлекаться ради хороших кадров, и даже не привлекая его потом в процессе монтажа - то сомневаюсь что он потерял бы интерес.
Мне встречались люди которые именно так и работали - они просто делали то что нравится, а собственно зарабатыванием занимался кто-то ещё, не вмешиваясь в их процессы но используя результаты их труда. Некоторые из них занимались своим делом больше 20 лет, и интерес совсем не угасал.
В обоих случаях будет вычисляться аргумент
user, и если это что-то сложнее обычной переменной (типа вызова функции) то возможны и побочные эффекты и замедление.Сборка же самой строки, как правило, занимает ничтожное время по сравнению со всем остальным, так что выигрыш тут близок к нулю, разве что имеем дело с объектами - там ещё будет экономия на отсутствии вызовов
__repr__или__str__, и то только если они сложные и/или медленные.Единственный надёжный способ с этим бороться - это использовать конструкции типа:
В этом случае, если приложение запускается не в отладочом режиме (
python -O) то всё что внутриif __debug__вообще будет вырезано и не будет выполняться.К сожалению, эта магия работает только с
__debug__и только если нет других условий - удобной условной компиляции методов как в C# у Python нет, увы.Ну хоть что-то придётся таки сказать, кроме собственно заявления.
Сослаться например на признание по пьяне (без записи и свидетелей) или что-то типа - потому что само по себе такое заявление при наличии отсутствия доказательств вызывает обоснованные сомнения - если оставленных следов нет в принципе, то как такая мысль вам вообще пришла в голову? Разве что всех гениев априори считать потенциальными серийными убийцами - "аппарат-то есть".
В рассматриваемом же случае есть как минимум ненулевая вероятность именно по факту причастности к не совсем белой и пушистой организации. Да, вероятность, не факт - но всё же не "следов нет".
К тому же, как показывает практика, "бывшие" (из разномастных малобуквенных контор) часто оказываются связанными с этими конторами и после ухода, причем чем выше у человека была должность, доступ или связи тем выше вероятность.
Есть маленький нюанс - это "3 мес" и "2 года" при условии что диск уже на пределе TBW (таковы требования JEDEC). Если он далеко от предела и температура хранения существенно ниже указанной в спецификации - то речь может идти о 5-10 годах, если не больше.
Подробнее тут, страница 25.
Глупости, говорите? Что ж, видимо Hetzner круто попали, раз построили всё свою облачную инфраструктуру на NVMe SSD которые скручены в RAID10 - явно не ведают что творят. Как, впрочем, и другие облачные провайдеры - не знают пацаны что всё накроется медным тазом в любой момент.
На практике эти 7800 MB/s быстро окажутся "вообще ни о чём" если на тачке крутится с десяток виртуалок или нагруженная БД. Для игр и прочей офисной деятельности - конечно это вообще неактуально.
Не факт. Если вам нужна надёжность и бюджет несколько ограничен - то два накопителя в RAID 1 будет дешевле чем три в RAID 5 на ту же ёмкость, а выигрыша нет и вовсе - всё равно он выдержит "вылет" не более чем одного диска.
Если ёмкость нужна большая и "не влазит" в один накопитель - тогда да, можно и RAID 5. Но всё же, я предпочитаю полное дублирование чем RAID 5, RAID 10 всяко надёжнее да и шустрее к тому же при записи, при прочих равных.
Вообще если говорить про "накладно" нужно считать что окажется дороже - двойная оплата или потеря данных. Обычно второе на порядки дороже, если конечно это не архив с котятами, да и при нынешней стоимости накопителей (в том числе SSD) это не то о чём стоит беспокоиться.
Что же касается NVMe - у них есть "фатальный недостаток" - менять их на лету очень тяжко, решения конечно есть но стоят они как крыло от самолёта, в отличие от SATA/SAS где hot-swap вообще почти ничего не стоит даже для домашнего ДЦ. Впрочем, если речь не про сервис где минута простоя стоит как чугунный мост, то вполне можно разобрать и заменить.
Совсем не факт. Я мог бы написать такое про себя, даже почти в таком же тоне, разве что с NDA чуть полегче было, но я не тяну одеяло на себя и легко признаю любую правоту (равно как и свою неправоту), при наличии аргументов разумеется, и проблем со мной ни у кого не возникает.
Есть только один реальный и надёжный способ проверить, годится человек для работы или нет - это дать ему работу и посмотреть на результат, включая взаимодействие с командой и вот это всё, как правило, 3х месяцев хватает, в худшем случае полгода.
Никакие собеседования не дадут полной картины - человек может произвести супер впечатление и по CV и на всех собеседованиях, но окажется никаким спецом или просто козлом, и хорошо если только одним из этих двух, в то же время кто-то может вообще не произвести впечатления (или даже произвести отрицательное) но будет крут во всем, от хард до софт скиллов - просто ему нужно реально начать работу.
В приниципе код хороший, отличный даже, и наверняка закроет 99.9% всех типичных кейсов, хотя пара моментов всё же не учтена.
Я не знаю что там в стандарте, но зравый смысл требует чтобы код вернул ошибку в случае потери точности (если мантиссы не хватит), а не только если на входе не число.
Т.е. даже если наш
doubleсоответствует IEEE 754 то у нас всего 52 бита, а это маловато как-то если получим на входе хотя бы 17 знаков, но поскольку C не гарантирует что это будет именно 64 бита double precision (не говоря уже о том что это может быть и вовсе не IEEE 754) то результат может оказаться чуть печальней чем хотелось бы, особенно если код используется в чём-то критичном типа авиации или автомобилей.Подобная проверка может показаться избыточной на таких многозначных числах - но её наличие позволит поймать случаи когда входные данные неадекватны.
С переполнением тоже не всё гладко - если повезет, то получим на выходе INF (хотя его ещё нужно будет проверять в месте вызова), но можем нарваться и на SIGFPE (или его аналог) или просто на мусор в результате.
@aabzelВаш код из статьи тоже "посыпется" если на входе будет что-то многозначное, но ситуация усугубляется ещё и тем что вы используете
uint64_tдля разбора целой части - т.е. возможные переполнения вообще могут оказаться незамеченными. Может быть именно по этой причине задачка получила уровень "hard" - разбор чисел с плавающей точкой (да и просто целых тоже) это совсем не так просто если нет никаких гарантий о качестве входных данных. И да, судя по всему их тесты описанные выше случаи явно не покрывают.К тому же, конечный автомат в данном случае это перебор - медленно, громоздко и плохо читаемо и понимаемо (= высокая когнитивная нагрузка).
Массы талантливых или близких к ним инженеров, учёных, преподавателей, врачей занялись челночной торговлей в своё время, так и не найдя применения своему IQ. Точнее, применять-то его было где, только вот на качество жизни это не влияло совсем. Некоторые (подавляющее меньшинство) потом таки выбрались, но часто не в своих областях.
В то же время личности совсем не отягощенные IQ и по сей день часто имеют намного более высокое качество жизни, и на этом не останавливаются, причём именно на них обычно работают те у кого IQ выше, хотя по идее должно было бы быть наоборот.
Ситуация мало изменилась и в наше время - из тех у кого реально высокий IQ выбиваются вперёд единицы, а не массы, так что наверное всё же корреляция не настолько прямая.
Конечно роботы. А страдать будут таки люди. От последствий войны роботов.
Не означает. В обычных лотереях никто не мешает любому количеству билетов (необязательно у одного владельца) иметь одинаковую комбинацию, и если она оказывается выигрышной то выигрыш делится между всеми билетами.
То есть, другими словами, заполнив билет вы не получаете экслюзивные права на определенную комбинацию, и если синдикат имеет всего один билет с выигрышем джек-пота но при этом ещё сотня человек использовала такую же комбинацию - то джек-пот (и вообще любой выигрыш на этом уровне) поделят между всеми.
Впрочем, ушлые лотереи успешно борются с описанными схемами - например, стоимость выкупа всех билетов никогда не может быть меньше чем сумма джекпота, а обеспечивается это просто - если джек-пот превышает определённую сумму, он перераспределяется между теми кто на более "низком" уровне - т.е. теми кто взял бы второй приз, если таковых не оказывается - то теми кто на третьём месте, и на этом как правило всё заканчивается.
И кстати, лотерея при любом раскладе не проиграет - они получают прибыль с каждого проданного билета, в кассу выигрыша отправляется только часть, так что единственное что им угрожает это разочарование игроков и возможное снижение популярности. Но это только если схема всплывёт.
Это похоже на попытку убедиться что на входе получено ровно то что ожидается - очень хорошая практика.
Как минимум валидация помогает при отладке, как максимум - во всех остальных случаях когда у вас нет 101% уверенности что на входе будут только ожидаемые данные, например, если вы пишите библиотеку, или если значения аргументов получены извне (введены пользователем, переданы API etc).
Гораздо проще аннотировать аргументы и отдать валидацию декоратору чем вручную это делать внутри каждой функции где существует риск, не говоря уже про DRY.
Дополнительная польза валидации на входе - это чёткое сообщение о том что и где пошло не так, а не непонятное исключение где-то в глубине которое возникло по причине неверного аргумента.
Впрочем, расчитывать на то что неправильный аргумент обязательно вызовет исключение не стоит - к примеру, если у вас на входе ожидается целое число в диапазоне от 3 до 7 и оно используется в вычислениях, но при этом на вход кто-то подал 13 - исключения не будет, будет неверный результат.
В конце концов,
pydanticи его@validate_argumentsне просто так появились - тот кто игнорирует валидацию обязательно нарвётся, или хуже того - подставит кого-то ещё.На самом деле это не совсем так. А точнее, совсем не так.
Дело гораздо сложнее и нюансов там много, но вот момент с эмодзи был совсем в другом: покупатель обсуждал контракт с продавцом по телефону, потом сделал бумажный черновик для продавца и даже подписал его (ручкой), далее он его сфотографировал и отправил продавцу с просьбой подтвердить контракт (а не его получение, в оригинале “Please confirm flax contract”) - и именно на это продавец отреагировал эмодзи "палец вверх".
С учётом этого решение судьи выглядит вполне обоснованным и дело не только в эмодзи, хотя конечно это сыграло существенную роль - но только в связи с контекстом.
EDIT: Ещё важный факт. Несмотря на наличие "массовой рассылки", этот покупатель регулярно покупал зерно у этого же продавца на протяжении последних 10 лет, т.е. это было не просто случайное сообщение случайному продавцу.
На самом деле этот процент отражает только вероятность того что людям будет интересно общаться в первое время (но это не точно), или вероятность того что им будет о чём поговорить на первом свидании. Это может быть один день, неделя, месяц или год - но этот процент никогда не покажет какова вероятность продолжения отношений (причём не факт что сохранится гармоничность, если будет вообще) через 5 или 10 лет, не говоря уже о больших периодах, и они разумеется совершенно не учитывают измненения в людях которых происходят в процессе этих самых отношений, самой жизни и ещё кучи факторов которые не учесть и не предусмотреть.
Отношения это гораздо больше чем общие интересы или что-то ещё о чём можно узнать в тестах, это ещё тысячи всяких мелочей о которых человек может и не знать пока не будет с ними встречаться на протяжении длительного времени в определеных условиях, и ни в какой вопросник это не впихнуть, а если и впихнуть (вдруг) - то там будет 100500 вопросов и сложнейшая система уравнений с таким же количеством переменных чтобы просчитать реальную вероятность, и то она будет актуальной только в следующие два дня.
Из жизни: мои самые короткие (и весьма неприятные в итоге) отношения были когда казалось что мы идеально подходим друг другу - это казалось аж пару месяцев. И самые длительные - когда мы как раз отличались вообще во всём и даже, в начале, почти ненавидели друг друга - но и через 10 лет они остались вполне гармоничными. Если бы мы проходили тесты, то скорее всего в первом случае вероятность была бы близка к 100% а во втором наоборот, к 0%.
Минимум половина людей в моём круге общения прошла примерно через это же - а это около сотни человек. Да, чуток не дотягивает до 1200 пар, но зато это точно проверено временем (отрезок в 10-20 лет), а не "познакомились год назад и ещё вместе".
Оценивать эффективность таких "вероятностей" нужно минимум через 5-10-15 лет отношений, но там статистика совершенно другая получается - есть у вас такие исследования и опросы? Впрочем, их проводили другие и их вполне можно найти в сети - там интересные цифры получаются, но очень непривлекательные для рекламы.
Многие аналогичные сервисы бодро рапортуют о "проценте счастья" - число счастливых пар которые в итоге вступили в брак или типа того, но никто из не говорит о том что случилось с этими парами через пресловутые 5 лет, или после того как у этих пар появились дети, или после того как эти пары прошли через всякие неприятности в жизни, или... в общем я надеюсь понятно о чём речь.
Про всё это вы в рамках своей полики честности вряд ли напишете, зато будете убеждать потенциальных клиентов что ваши тесты и алгоритмы самые научные и надёжные.
Впрочем... для людей которые не любят загадывать дольше чем на год вперёд - любая "вероятность" вполне себе заманиловка, это придаёт некую научность сервису, хотя суть остается прежней - это просто очередной способ познакомиться, не более того.
Если человеку нужна шпаргалка для ответов на эти вопросы, то к работе с БД его допускать не стоит.
Я на собеседованиях показываю SQL и прошу объяснить что будет в базе после его выполнения а также прошу объяснить как человек решит конкретную задачу, разумеется с подвохом (которые требуют знаний о ACID/MVCC, индексах и разных уровней изоляции) - сразу становится ясно кто зубрил а кто знает.
Конечно бывает. RFC 5321 раздел 5.1:
Большинство подобных валидаторов обладают как минимум одним фатальным недостатком - они проверяют теоретическую возможность отправки, а это (как правило) совсем не то что нужно.
Что же нужно? Нужно убедиться что потенциальный получатель действительно может получить, прочитать и понять письмо.
Единственный способ это сделать - собственно, отправить соответствующее письмо с просьбой его подтвердить нужным способом - ответить на него, пройти по ссылке, отправить SMS или позвонить на хотлайн (да, бывает и такое).
До этого, разумеется, нужно проверить существование домена, наличие MX или IP адреса - но не более.
Проверки доступен ли сервер (HELO/EHLO), ответа на RCPT TO и любые другие которые не отправляют писем - недостаточны - во-первых, сервер может быть недоступен в данный конкретный момент времени (даже если это Гугль или Microsoft), во-вторых, он вполне может отбить письмо и после отправки тела через DATA, причём не просто отбить а даже сказать "нет такого ящика" (для корпоративных серверов вполне себе реалистичный сценарий, если там пара прокси по дороге).
Если сразу отправить не удалось - можно сказать про это пользователю и предложить подождать, а через некоторое время - и повторить. Если письмо отбито после DATA - об этом тоже можно сказать и попросить разобраться или изменить email, или повторить позже.
В любом случае результат валидации нужно сообщить пользователю - либо сказать "всё ок", либо дать максимум информации если что-то пошло не так (включая ответ его почтовика - сильно помогает с разборками).
Что же до самого адреса (до @) - как уже выше заметили, не надо его проверять, он может быть любым - включая
"A & Б сидели на трубе!"@почта.где-то.тами без ограничения по длине в 16-20 символов. Сервисы же которые выпендриваются и даже"+"не разрешают в адресе вообще должны гореть в аду, не говоря уже о тех которые отказываются принимать вполне себе символьные имена которые по их мнению "неправильные" или "невозможные" (вспоминается eBay - они не разрешали email независимо от домена если в нём была подстрока "ebay", причём служба поддержки отморозилась в духе "у вас не может быть такого email").Почему это "невыгодно"? Да, налоги платить придётся, но часть меньше целого, и если компания получила прибыль в условный миллион и выплатила условный же налог в 25% - она всё равно получила чистую прибыль в размере 750 тыс, что явно больше нуля.
"Не выгодно" - это когда вложили X и получили < X, во всех остальных случаях всё сводится к "насколько выгодно" и размеру жабы. И да, есть компании которые работают "в ноль" - прибыли у них либо нет либо она очень небольшая, зато есть стабильный доход благодаря которому она существует и платит зарплаты сотрудникам (на всякий случай напомню - "прибыль компании" - это доходы минус все расходы, в которые входят и зарплаты).
Более простой пример - вы получаете зарплату в размере X, и платите с неё налоги. Вы откажетесь от зарплаты X*2 просто потому что с разницы тоже придётся платить налоги? Разумеется, вы предпочтёте получить её "в конверте", но далеко не все и не везде могут себе такое позволить, да и чревато это.
С компаниями ровно то же самое. Да, они стараются минимизировать налоги, не платить если есть возможность, но ни одна из компаний не откажется от прибыли просто потому что с неё нужно платить налоги. К тому же, далеко не везде прибыль можно "спрятать", а если поймают - это будет очень дорого и больно, да и ловят хорошо.
Более того, "отрицательная прибыль" очень быстро приведёт к ликвидации компании - во многих юрисдикциях она допустима на достаточно короткий срок (в лучшем случае несколько лет). Если исключить всякие "схемы", никакая честная компания на это не пойдёт.
Увеличивать капитализацию сложно при отсутствии видимой прибыли - инвесторы не будут вкладываться в компанию у которой нет прибыли, стоимость акций будет падать а не расти. Посмотрите на колебания стоимости акций когда компания в очередном квартальном отчете заявляет что получила всего на несколько процентов меньше прибыли чем ожидалось - всё сразу станет очевидно.
Вопреки "бытовому" мнению зарабатывать на стоимости акций не так-то просто - пока вы их держите у вас нет ничего кроме акций, реально вы что-то получите на руки (в виде денег) только когда решите их продать, и в этот момент их цена может оказаться очень неожиданной.
Наконец, далеко не все (даже крупные - типа Vitol, Aldi или Huawei) компании являются акционерными - там нет капитализации как таковой.
Правда? Microsoft, Google, Apple, Nvidia, Tesla - предпочитают быть убыточными? Да ещё тысячи компаний более мелких - предпочитают как раз быть прибыльными.
В налогах нет ничего страшного, в самом худшем случае это просто неприятно, но отказываться от прибыли просто потому что с неё придётся платить налоги - глупо. Лучше получить большую часть чем не получить ничего вообще из-за нежелания платить налоги.