Кирилл Горелов

Есть два вида отечественных сертификатов:
1. Сертификаты с криптографией по ГОСТ (признаются как криптографическая защита) - сертификат выдается одним из аттестованных центров, поддерживается в Яндекс Браузер с установленным CryptoPro, криптография не совместима с международными стандартами.
2. Сертификаты Национального Удостоверяющего Центра - можно получить через Госуслуги, совместимы с международными стандартами и поддерживаются в любых браузерах, но только в российских браузерах (Яндекс Браузер, Атом) корневой удостоверяющий центр добавлен в доверенный, в остальных придется это сделать вручную.

Потому что выпуск публичных SSL-сертификатов зиждется на доверии всех участников удостоверяющим центрам. А нашим какое доверие?

https://digital.gov.ru/ru/activity/govservices/cer... существует список аккредитованных удостоверяющих центров в минцифре

Проблема еще не только в том, что площадки или напрямую запрещают выкладывать ранее опубликованный контент, или негативно к этому относятся (искусственно уменьшают охваты, понижают позиции в выдаче и пр.), но и в том, что они не любят, когда вы оставляете ссылки на другие площадки. Например, когда вы публикуете начало статьи, а продолжение – «Смотрите в моем Telegram-канале» и пр. Отсюда, единственный возможный вариант – рерайт. Как бы негативно вы к этому не относились.

Если вы не можете самостоятельно писать по-разному, закажите рерайт у копирайтеров на любой бирже фриланса. Рерайт, в отличие от копирайтинга, стоит недорого. Особенно если вы будете готовы снабжать исполнителя большим объемом работы и сотрудничать с ним напрямую (чтобы не платить комиссию бирже). В среднем, можно найти исполнителей за 30-50 руб. за 1 000 знаков без пробелов.

Еще могу порекомендовать немного другой подход – создавайте больше контента, но каждый уникальный материал публикуйте только на одной площадке. Если контент действительно важен для вашей аудитории, пользователи создадут аккаунты на других площадках, чтобы читать вас везде. В результате, пусть у вас в совокупности и не станет больше читателей, но охваты на каждой площадке увеличатся.

Хранить в виде файлов на диске, а для поиска использовать систему полнотекстового поиска

Создаю свой мессенджер, задача такова что нужно сделать список абсолютно всех мелодий которые есть в мире, так же как в вк, как это можно реализовать?

Так, давайте прикинем что нам нужно для реализации. Программная часть собственно нас не сильно интересует, так как на фоне прочих затрат найм какого-нибудь Линуса Торвальдса на пару месяцев вообще теряется в общей сумме.

1) Хранилище. По примерным оценкам в мире в цифровом виде около 500 000 000 оригинальных музыкальных композиций. Учитывая ремиксы и каверы - можно смело брать миллиард. Средний вес композиции среднего качества - 5 Мб. То есть порядка 5 петабайт, если хранить не в лучшем качестве. Учитывая что это должно иметь какое-то резервное хранение (у нас тут серьезный сервис все-таки), умножаем на 2 (10 петабайт). При стоимости около 2 центов за гиг в месяц, 10 000 000 Гб * $0,02 = $200 000 в месяц хранение. Ну, бюджетненько в целом.

2) БД, которая хранит данные обо всех этих композициях. Стоимость хранения будет поменьше, но думаю к 20-50К все равно где-то выйдет.

3) Другой вопрос - где брать эти данные, так как не все музыкальные файлы содержат полное описание композиции. На перебор 1 миллиарда записей и сортировки их по жанрам, альбомам, исполнителям, дате выпуска и т.д. уйдет некоторое время. Допустим 50% композиций будут иметь нормальное описание, остается все те же 500 миллионов композиций на обработку. Пусть на каждую понадобится 2 минуты работы, внести данные в поля (хотя их еще как-то найти надо, но допустим), тогда получим 1 миллиард минут. Это 1900 лет работы, или 16 666 667 часов. Час работы самого дешевого индуса - 3 бакса/час. 16 миллионов * 3 - давайте округлим до 45 миллионов. Даже если сократить этот пункт в 10 раз - выйдет под 4 миллиона. Рабский труд сегодня дорог как никогда...

4) Теперь платформа которая будет всем этим ворочать, так как у нас в сервисе должны же какие-то пользователи завестись вроде. Ну, на сервера можно смело отложить небольшую сумму, тоже где-то 20-30К, для начала сойдет.

5) Прочие накладные расходы, такие как билеты на самолет до Америки с целью договориться где будет стоять ваш датацентр и прочие мелочи мы пока в бюджет не вкладываем, так как там уже инвесторы подтянутся, и смысла заморачиваться с мелочевкой нету. Так же оставляем за кадром вопросы лицензий и отчислений авторам, так как с этим возиться лень, как-нибудь решим потом.

Расчетный срок бюджета возьмем год, чтобы не тянуть и конкуренты не захапали идею.

По итогу на год:
$200 000 * 12 = $2 400 000 хранилище
$20 000 * 12 = $240 000 бд
$20 000 * 12 = $240 000 сервера приложения
$4 000 000 работы
Итого: чуть меньше 7 миллионов баксов.

Это не задача PHP, как уже выше написали, решается сторонними средствами. Например, systemd - пишется конфигурационный файл в пару строчек, в котором описываются команды на старт, остановку и т.д.

Я не понял, так чего вы боитесь в итоге - что "будет подъедать" или что процессы будут накладываться друг на друга.
Во втором случае надо определиться - это запуск по крону, ИЛИ демон.

В общем случае надо выкинуть крон вообще и использовать supervisord
тогда проблемы с "как остановить" и "как сделать чтобы процесс не останавливался" решатся сами собой

Если опасаетесь, что будет подъедать память - то может и контролировать в самом скрипте использование памяти и выходить?
Если запускаете каждую минуту, то похоже, что процесс должен работать постоянно. Почему бы тогда не посмотреть в сторону gearman/beanstalk, перезпуск воркеров можно через systemd организовать. Или что имеется в виду по "алгоритмом работы" - сам запуск и получение задачи на парсинг или алгоритм парсинга?

проверяй не номер секунды, а сколько прошло
microtime(true) - $start_time

Пора познакомиться с Supervisor*ом. Он будет поднимать процесс если тот упадет или перезапускать когда надо.

А чтобы не использовать бесконечный цикл надо бы это все у очереди запустить. Циклы эти не надежные

Нет никаких вариантов кроме как через бэкенд.
CORS для того и создан, чтобы запретить такие запросы.
Причина - представь миллиард веб-страниц, обращающихся через браузер к сайту.
Это называется DDoS-атакой.
Вот так вот.

Из браузера похоже никак.
Эти всякие same origin policy как раз и придуманы чтоб ограничить такое использование.
Проксируйте через свой сервер, как вариант.

Элементарно.
Берете один vps. На нем поднимаете впн сервер, чтобы вы к нему коннектились.
Покупаете еще N.... нет, N мало, лучше M vps в разных местах. Ну сколько вам там уникальных ип надо? сотня? покупайте 100 vps.
Теперь на первом vps настраиваете возможность выходить в инет через любую из 100 vps... Ну например еще впн подключениями...
Вуаля. Вы подключаетесь к одному серверу, и на нем можете выбрать, через какой ип дальше идти в инет...

ЗЫ. Любой сервис, который дает вам возможность сменить ип или локацию выхода - сделал также....

Ваш пример - просто демонстрация того, что собственный проект это НЕ перспективы, НЕ независимость, и НЕ круто. Собственный проект - это в первую очередь целеустремленность, ответственность и квалификация. Очевидно, что это все есть далеко не у всех. Правильнее сказать - это есть у очень не многих.

Дружок-пирожок, а ты точно уверен что тебе нужен while True: при проверке клавиш?
Сам я с интерфейсом ничего не пытался делать, но по логике у тебя мэйн залу... заloop... зациклен! Да, зациклен, вот.
И по идее, пока мейн не завершится, он постоянно будет и так проверять клавиши, разве нет?
Пробуй, о результатах отрапортуешь, самому уже интересно.

200-800 юзеров это вообще ни о чём.
подойдёт любая архитектура, даже говнокод