danSamara

Это фундаментальная проблема онлайн-магазинов не имеющая решения: либо вы реально блокируете товар при его наличии в корзине, что гарантирует пользователю покупку, но создаёт проблемы вам, либо наличие товара несёт чисто информационную функцию, что снижает лояльность пользователей из-за "к сожалению данный товар уже недоступен к покупке".

Самый распространённый подход - блокировка товара перед непосредственным переходом к оплате на короткое время, за которое пользователь должен произвести оплату. Этот вариант хорош по двум причинам:
1. Неограниченная по времени корзина - не надо принимать сложное решение о времени реальной блокировки товара в корзине.
2. Короткое время реальной блокировки товара (10-30 минут) с предварительной проверкой наличия оного.
Конечно, всё ещё остаётся вариант ботов, в этом случае можно будет вообще убрать реальную блокировку и проводить денежную транзакцию через hold/refund, что будет бесплатно с точки зрения комиссий.

По каким критериям оцениваем?

1. По скорости - лучший.
2. По криптостойкости - худший.
3. По коллизиям - один из худших.
4. По соли - критерий неприменим.

1. Когда важна скорость, и не важны прочие критерии, например при подсчёте контрольных сумм - MD5, наверное, один из лучших. Хэшировать пароли тоже можно - например кратко живущие длинные токены с большой вариативностью - никто в здравом уме не будет подбирать хэш для 20 символов, срок жизни которых - 5-10 минут. Хотя я бы и для токенов использовал что-то другое - тот же sha, от греха подальше )

2. Криптостойкость у MD5 низкая. Вложенность (md5(md5(...))) её только уменьшает, увеличивая коллизии и не сильно влияя на скорость перебора - на современных картах она уже составляет сотни гигахэшей. Может уже перешагнули за черту терра - не сильно за трендами слежу.

3. Коллизии. Наличие коллизий, по сути, увеличивает скорость перебора. С другой стороны - не позволяет точно определить оригинальный пароль, т.к. при наличии нескольких подходящих под определённый хэш паролей невозможно определить какой именно использовал юзер. Однако ничего не мешает перебирать эти варианты на других сервисах.

4. Соль к хэшированию не имеет прямого отношения и применяется только для исключения возможности использования атакующим радужных таблиц. Однако перебор по словарю и перебор по словарю с вариантами (добавление символов до/после слов, склейка и т.д.) вполне возможен и соль на него не влияет никак. В случае MD5, опять же, это очень быстро.

Сначала вам нужно определиться, что такое "нормально" конкретно для вас.
Округлять можно:

• Отбрасывая дробную часть
  
• В большую сторону
  
• В меньшую сторону
  
• "Математически" - в большую при ошибке округления 1/2
  
• "Бухгалтерски" - до ближайшего чётного, при ошибке округления 1/2
  

Вы используете первый вариант, но возможны и другие. Смотрите функции round(), ceil(), floor() и trunc().

Для первого случая:
(!i && !j || i ^ j)

Оценивать шансы устроиться на работу по количеству вакансий в корне неверно.
Устроиться на работу где 100 вакансий и 50 претендентов, в полтора раза легче, чем на работу где 1000 предложений и 750 кандидатов - конкуренция, мать её! А ещё надо учесть распределение зарплат по уровням, их качество: белая/серая и доп плюшки: соц пакеты, компенсации, бонусы и т.д. А ещё у каждого человека есть свои сильные стороны, на которых можно сделать акцент - английский язык, развитые коммуникационные навыки, лидерские качества, специфическая экспертиза в некой области и прочая и прочая - это тоже сильно повлияет на выборку в вакансиях.

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

Rsync идеально подходит для управления бэкапами на уровне файлов малого и среднего размера. Инкрементальный бэкап на основе жёстких ссылок позволит вам:
- с одной стороны - иметь полностью независимые полные бэкапы, с возможностью в любой момент удалить ненужный и элементарного восстановления любого файла
- с другой стороны - оптимизация дискового пространства, т.к. реально на диске будут храниться только разные файлы - остальные будут связаны жёсткими ссылками и не будут занимать дополнительное место.
Такими образом, если вас устраивает хранение на уровне файлов и у вас нет больших часто меняющихся бинарных файлов (например фалы БД), то rsync (и множество утилит-надстроек над ним) - отличный вариант!

Однако, вы написали, что хотите делать LVM-снапшоты удалённо. То есть вам нужна возможность передавать бинарные блобы (а ещё лучше - только разницу) удалённо, оптимально хранить и, судя по тому, что бэкап-сервер вам не принадлежит, по-хорошему, ещё и шифровать. Всё это есть в, уже порекомендованном вам, BorgBackup. Это такой git-репозиторий для бинарных файлов с дедупликацией и шифрованием. К сожалению ничего не могу сказать по поводу его работы с win-хостами - не сталкивался.

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

Это классический случай использования оконных функций: https://postgrespro.ru/docs/postgresql/11/tutorial...

Фундаментальное отличие Windows от Linux: разработчики винды считают юзера (даже админа) тупее системы (думаю, согласно статистике, они правы), разработчики линя - умнее (что наверняка тоже согласуется со статистикой). Поэтому когда вы запускаете команды из под рута, чётко понимайте какие последствия произойдут.

Я столько всего там настраивал, можно ли как-то переустановить образ но сохранить данные ( конфиги в etc, папку home и т.д )?

Сомневаюсь, что вы настроили что-то сложнее чем Nginx+php-fpm+почта+mysql+сертификаты+ssh. Опытный админ это сделает за полчаса, пятнадцать минут из которых у него будут работать автоматические скрипты развёртывания (или пять минут, если сервер шустрый).

Может можно отключить систему прав в Linux, я не до конца понимаю, как мне, например, залить файлы в папку wget'ом а редактировать через ftp. Мне можно как-то юзера FTP добавить в root группу?

Нельзя. Даже если бы такая возможность существовала. Она вам мешает, потому что вы её не знаете. Правильно настроенная система не требует постоянного изменения прав и работает прозрачно, помогая вам поддерживать уровень безопасности на должном уровне.
Конкретно по вашему проблеме с доступом: почитайте про юзеров и группы в линуксе.
По вашей ситуации: ничего не делайте сами! Наймите админа, который развернёт новую систему и корректно перенесёт данные, это не будет стоить дорого, уверен. Заплатите денег и получите правильно настроенную систему и, бонусом, хорошее знакомство с девопсом - это правильная инвестиция в ваше развитие.

На будущее:

• не используйте FTP
  
• читайте документацию
  
• экспериментируйте на виртуальной машине
  

Значит вы ещё не программист, а кодер. Это не страшно, вопрос опыта.
Главное отличие программиста от кодера - программмист пишет код в голове - набивание кода в IDE это самое нудное в программировании, весь смак - в проектировании. А вот кодер пишет код кусочками, которые берёт из интернета или из собственных внезапных озарений.

Рецепт решения вашей проблемы прост - отойдите от компа, пойдите прогуляйтесь или посидите в кафе, на диване или где там вам уютно, спокойно и мухи не кусают. Спроектируйте ваше приложение от и до в голове. Вы должны чётко видеть все компоненты системы и их взаимодействие между собой. Затем запустите приложение - отладка в голове тоже может работать, если вы хорошо знаете язык программирования. После того как пофиксите баги - можно садится за комп и переносить код в железный ящик под столом.

ПРОФИТ!

А вот знаки, формулы, код - вот что я люблю, но и тут надо как-то определиться.

Если тебе интересны реализации сложных алгоритмов, а это и есть "знаки, формулы, код" - копай в этом направлении. Это может быть всё что угодно - AI персонажей в игре, транспортная логистика в онлайн-сервисе, распознавание образов в мобильном приложении и т.д. Практически в любом сложном проекте найдутся задачи, требующие сложных проработанных решений, для реализации которых потребуются глубокие знания в математике и используемом ЯП.
По-поводу используемого ЯП - выбор не ограничен, но специфичен для каждой конкретной области. Если геймдев, то скорее всего С++ или C#, онлайн - PHP/Python/Ruby/JS, мобильные - Java/ObjC и т.д. Выбирай что ближе, но изучай досконально - нюансы реализации могут свести на нет тонкую оптимизацию, да и реализовывать крутые алгоритмы кривым кодом - моветон )

Мой ответ будет несколько груб и не типичен, однако: "Станьте говнокодером!"
Я не шучу - берите реальные задачи и решайте их как можете - по наитию, по кривым советам из гугла и stackoverflow, но главное - делайте законченные решения, получайте результат который работает.
Любую задачу сначала решайте сами - нужно сделать сортировку - пишите алгоритм и радуйтесь, что он работает. А уже потом - читайте как надо сделать, и только после этого (если почувствуете потребность!) - читайте теорию.
Все книги что вы написали безусловно волшебны и необходимы для отличного программиста, однако без практики они - пыль, которая развеется спустя неделю после прочтения. Поверьте мне, я их все читал :)
Кстати Кнута я бы вычеркнул без раздумий - для его чтения и понимания нужен очень хороший мат-базис и опыт в программировании. Если случиться, что вы будете писать оптимизированные библиотеки для обработки данных на С - тогда и начинайте его читать, очень пригодится, отвечаю )
Пример обучения:
1. Ставим задачу. Пример - написать приложение, которое выводит топ-10 вопросов на Тостере.
2. Разбиваем задачу на проблемы которые надо решить. Пример - развернуть рабочее окружение, понять как сделать "Hi world", как работать с сетью, как парсить HTML
3. Решаем проблемы. В лоб. Задание - на скорость, всё должно быть решено в кратчайшие скроки. Для каждой проблемы используем любое решение которое попалось под руку. Буквально - первое, это важно! То есть реально ковнокодим, забивая на всё - на красоту кода, на оформление, на скорость, лишь бы работало! Девиз этого этапа - херак, херак и в продакшен! Результат этапа - рабочее приложение.
4. Делаем поверхностный анализ. Задача решена? Есть ли косяки которые уже не нравятся? Как их можно решить, исходя из минимального опыта? Локализуем проблемные участки исходя из собственных взглядов. Результат этапа - опыт самостоятельного анализа кода.
5. Делаем глубокий анализ. Пытаемся для каждой задачи подобрать лучшее решение из тех что есть. Читаем теорию о том, как надо делать на самом деле. Изучаем и внедряем паттерны, пытаемся сделать код, который можно переносить в другой проект. Важно не менять условия задачи, вроде "а можно же ещё вывести ответы на вопросы". Не можно, задача должна оставаться прежней. Результат этапа - хороший код и выявленные пробелы в знаниях.
6. Отдыхаем, читая теорию в рамках решённых задача и около них. Результат - теория, подкреплённая практикой.
7. GOTO 1.

Почитайте тут, возможно это ответ на Ваш вопрос.

Считается, что выгодно, однако это не всегда так. Для подобных вещей очень подходит А/Б тестирование - оно точно покажет выгодно ли и насколько. Это при условии, что поток посетителей у вас предсказуем и относительно постоянен.

Думаю вам надо изменить сам подход к вёрстке - нельзя верстать под конкретные разрешения, это тупиковый путь с бесполезными затратами времени.
Оптимальный workflow примерно такой:
1. Делаем максимально резиновую вёрстку. Всё что может быть резиновым - должно им быть, включая изображения. На этом этапе можно с картинками сильно не заморачиваться и делать просто { width: 100%; height: auto; }, перфекционизм - позже.
2. Расставляем брекпоинты. Обратите внимание: их надо расставлять не по "популярным" разрешениям экрана, а в соответствии с дизайном! Как пример - вывод товаров в каталоге в виде сетки. На большом экране будет четыре товара в ряд (25% ширины), потом - три, два и, наконец, для телефонов в портретной ориентации - один товар (100% ширины). Разрешение, при котором будет "перепрыжка" товаров с четырёх в строке на три (и прочие) надо определять визуально, лучше вместе с дизайнером. Результатом этого этапа должен быть сайт, который с максимального разрешения (допустим 2000 пикселей) до минимального (200?) красиво меняется в браузере при плавном изменении размера окна.
3. Тестируем на популярных разрешениях экрана. Заметьте, это практический последний этап. Если предыдущие этапы сделаны правильно, то на этом не остаётся никакой работы - просто проверка.
4. Наводим лоск. Здесь уже можно заняться оптимизациями и украшательставами. В частности - сделать разные источники для каждой картинки. Не буду подробно описывать технологии, руководств много в сети, по картинкам например вот: "Отзывчивые изображения: примеры использования"