rPman

Этот сайт использует встроенный в браузер (который скорее всего использует штатный API операционной системы) синтезатор речи, разные ОС и браузеры выдают разный результат. Это видно по коду сайта (2 клика в инспекторе браузера, потом поиск по имени функиции).

https://developer.mozilla.org/en-US/docs/Web/API/S...

Если тебе нужен не обязательно этот синтезатор, воспользуйся инструментами своей ОС, для windows это SAPI, очень удобный инструмент, есть миллион готовых утилит и прочее прочее. гуглить к примеру command line SAPI (первая же статья гуглится, однострочники от powershell до visual basic script), так же куча биндингов для языков типа питон, в т.ч. кроссплатформенных, в общем уточни с чем ты можешь работать, поможем погуглить.

Хранить в файлах
Можно не генерировать имя файла а использовать идентификатор из базы данных (не обязательно числовой, можно брать hex от его байтового представления), чтобы не заморачиваться с расширением, его можно либо стандартизировать либо не указывать (но тогда либо где то храни его mime type либо каждый раз высчитывать его с помощью утилиты file). Если будет расширение файла, то веб сервера смогут отдавать такие файлы максимально эффективно статикой, напрямую без бакэнда (при унификации типа файла это не требуется).

Так же для удобства обслуживания действительно больших баз (миллионы изображений) можно раскидывать их по подкаталогам, считая имя каталога как некоторые биты от идентификатора, к примеру имя файла 00f1b3f3.png но хранить его в подкаталоге 00f1/b3f3.png в этом случае один каталог не будет содержать файлов больше некоторого лимита (в данном случае 2^16 - 65536, с таким объемом вполне сносно работают почти любые утилиты)

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

p.p.s. бонус от хранения в блобах можно увидеть как унификация обслуживания базы данных, не нужно синхронизировать файлы и базу данных (расхождения возможны при сбоях) а так же можно настроить штатную репликацию БД и получить красивую репликацию данных на лету на ноды кластера...

Единственный смысл разделения хранилища раздачи статики и динамического контента - это различия в стоимости серверов под эти задачи

Бакенду нужен процессор но нет нужды в емком хранилище, а серверу раздачи статики он не нужен совсем, но нужны ёмкие и/или быстрые диски, а так же выше сетевой трафик.

Статичные файлы проще реплицировать, т.е. геораспределенный кластер с ними удобнее обслуживать...

Само собой разницу можно будет заметить только на больших объемах, и речь о терабайтах

Если пользователь не сопротивляется (например специфические настройки и приватный режим браузера, плагины-блокировщики, виртуализация и т.п.) то:
* информация о железе - ос, параметры экрана и от сюда вплоть до конкретной модели мобильного устройства, ну по классам, наличие видеоускорителя, бенчмарки процессора и много чего еще
p.s. кстати webgl это огромная дыра, при должном старании как я понимаю можно даже содержимое экрана получить, буквально чем занимается пользователь вне браузера.
сюда же можно докинуть шрифты и алгоритмы их отрисовки, к примеру при должном старании можно понять, установлен ли тот или иной софт (крупный, какой-нибудь cad) по тому как браузер отрисовывает тексты шрифтами, устанавливаемыми этим софтом.
* fingerprint - набор технологий позволяющих вытянуть из поведения браузера идентификатор пользователя (читай куки) даже если он сопротивляется этому
* наличие плагинов/расширений браузера, по каждому расширению нужно проводить свои проверки но детектировать можно все
* поведенческий анализ, стиль работы с мышкой и клавиатурой, можно оценить реакцию пользователя на раздражители

* если ты - рекламная сеть (точнее куча веб сайтов устанавливают твой аналитический код да просто изображение-пиксел) то ты можешь знать, какие твои сайты посещал пользователь, вплоть до открываемых страниц и даже мониторинг поведения (если баннерная сеть ставит свой javascript код на сайт, то она может собирать буквально всю информацию, например нажимаемые кнопки), это самая вкусная информация, особенно для крупных сетей, ведь видно все интересы пользователя с историей

* банальщина вида - подменять содержимое clipboard, браузер позволяет его устанавливать на реакцию пользователя, типа клик(одно время и читать тоже, но это поменяли), как с этим можно смошенничать догадывайся сам

Инкрементальные бакапы
Каждый архив должен содержать только разницу между предыдущим состоянием файловой системы и текущим

Каждый инструмент резервного копирования использует свой формат хранения такого снапшота

Если делаешь свой, то учитывай не только новые и измененные файлы но и удаляемые. Существуют binary diff утилиты, вычисляющие приблизительную разницу между двумя бинарными файлами для экономии места в бакапе, вместо полного копирования измененного файла

p.s. недостаток инкрементальных бакапов в том что для восстановления состояния нужно "применить снапшоты" за все время с момента первого сохраненного состояния

решают эту проблему тем что ограничивают количество промежуточных состояний и с каждым новым модифицирют стартовое состояние, применив к нему самый старый бакап (который после этого удалят)

p.p.s. btrfs имеет встроенные механизмы получения инкрементальных бакапов между снапшотами без сканирования всех файлов (что актуально для ОГРОМНЫХ архивов)

Ответы другими пользователями даны абсолютно верные

Но хочу все же напомнить что вполне возможно существование веб сервиса который создает на каждую страницу реальный файл на диске при создании и редактировании поста как механизм кеширования (дублируя информацию с базой данных), так как современные веб серверы (nginx например) работают с таким файлами (это называется статичные файлы) невероятно эффективно, на порядок эффективнее чем делать это на лету при каждом запросе, так же он может быть заранее сжат (deflate, gzip, br) что позволит сэкономить еще и на сетевом трафике., да веб сервер и так это делал бы на лету, но за счет процессора.

Напрямую узнать ОС нет, только семейство (т.е. liunx/windows/macos), например window.navigator.platform вернет "linux armv8l", то же самое вернется для linux машины на таком же железе (arm процессоре).

Но можно косвенно провести анализ по работе компонентов браузера (в т.ч. gpu, это самая незащищенная компонента в браузере)

Есть готовые библиотеки, например https://github.com/bestiejs/platform.js

ты на сайт добавил код счетчика яндекс метрики, это буквально

<script>
...
</script>

так вот заверни все его содержимое в

if(document.location.hostname=='127.0.0.1') { ... }

или любое другое условие, которое тебе подходит, в ообще его можно просто удалить метрику, вернув в момент публикации

зачем все так усложнять

рабочий чат на websocket лежит в примерах наверное любой документации к websocket, первый же нагугленный проект (бакэнд на go но там код на 20 строк все понятно) на столько простой что даже непонятно что непонятно

а еще есть webrtc, эта технология дает еще один механизм коммуникации между пользователями вообще минуя сервер, добавь сюда шифрование и failover при неработающем webrtc и получишь готовый проект

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

Простых рекомендаций нет.

Использование фреймворков заранее определит список устройств и браузеров (про устройства - важное замечание, так как банальный размер и наличие скалинга многое определяет), но сделает работу проще, а если делать все самому то будет эффективнее,больше гибкости и главное понимание что как работает и почему нет!

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

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

Есть два основных направления разработки веб приложений, основные на месте генерации итогового html - на серверной стороне и на клиенте.

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

Второй подход, его ещё называют SPA, переносит все что касается интерфейса на сторону клиента, оставляя серверу бизнеслогику, это сильно уменьшает затраты на разработку бакэнда и снижает затраты ресурсов сервера, причем на столько, что даже миллионы пользователей потянет один сервер (защита ддос, CDN и т.п. можно считать фичей провайдера), но затраты на разработку со стороны браузера возрастут именно при необходимости поддержи большего количества устройств..

Для начинающего я бы рекомендовал первый подход, с оглядкой на постепенный переход к SPA.