Виктор Кожухарь

Разумеется можно. Никаких нюансов в одновременной работе нет, поскольку тут нет никакой "одновременности". php-fpm и websocket - это два разных сервиса, которые могут располагаться на одном и том же сервере или на разных, но в любом случае никак не пересекаются. В добавление к текущему веб-серверу вы просто запускаете вебсокет сервер и посылаете на него вебсокет запросы из браузера.

Ну то есть вам всего лишь надо осознать, что никакой одновременности нет, а дальше просто поставить вебсокет сервер, например workerman, и написать код, который по запросу будет соединяться с БД, получать нужную инфу и отправлять клиенту.

1. Да.
2. Как говорилось выше - можно. Любой сервер в сети по определению обеспечивает работу множества сервисов, количество которых ограничено только количеством свободных портов. Можно поставить два веб-сервера и пять вебсокет серверов.
3. Нет, разумеется. unix сокет это как раз внутренняя кухня сервера, но мы же говорим о сетевом взаимодействии. А tcp взаимодействие nginx и php-fpm тут вообще не при чём.

Да, подходит.

websocket это расширение http запроса, т.е. там добавляются специфические заголовки и можно отправлять туда-сюда пакеты в одном соединении.

Для этого приложение на php нужно реализовывать в виде http сервера (готовых библиотек тьма, включая штатные расширения), рекомендуется использовать swoole ну или по старинке на сокетах (библиотеки phpreact)

A read r of a memory location x holding a value that is not larger than a machine word must observe some write w such that r does not happen before w and there is no write w' such that w happens before w' and w' happens before r. That is, each read must observe a value written by a preceding or concurrent write.

https://go.dev/ref/mem

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

dadata.ru

- var html = e.target.parentNode.querySelector('.firmware-window');
+ var html = e.target.parentNode.querySelector('.firmware-window').innerHTML;
			$('.modal-wrapper').attr('class', 'modal-wrapper').html(html);
			html.classList.remove('hiden');

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

Такие файлы кладут вне директории, которую обслуживает веб-сервер. Примерно так:

./db.php
./public/index.php

В db.php вы подключаетесь, реквизиты храните в нём же или в .env-файле рядом (или ещё как-то), а в настройках веб-сервера в качестве корневой директории указана public. Тогда через него невозможно будет обратиться к "секретному" файлу.
(есть ещё всякие уязвимости, которые делают такую защиту всё же не стопроцентной, но они далеко за рамками данного вопроса).

наверное, корректнее поворачивать весь блок изоображений

Коротко - потому что IEEE 754

Выполняет он математические операции правильно, но некоторые числа компьютер просто не способен представить со 100% точностью, тк для них нужно было бы бесконечное количество памяти.

Точно также, как мы не можем записать все цифры числа 1/3 в десятичной системе, точно также и компьютер иногда не может записать все цифры в двоичной.

Если ты работаешь с деньгами, то тогда используй то, что делают все банки - представляй суммы денег не как дробные числа, а как целые. Например место 1.5 рублей записывай как 150 копеек. Запятую добавишь при выводе человеку.
btw тут в комментах пишут, что для денег тоже есть паттерн по-лучше конкретно для php.

Если при делении у тебя получилось дробное количество копеек - округляй так, как велит закон.

Если ты делаешь какие-то математические вычисления - возможно тебе нужны рациональные числа.
Не знаю, что обычно для этого в пхп используют, но нагуглил https://github.com/webgriffe/rational
https://github.com/markrogoyski/math-php

Но в случае с целыми числами ты всё равно можешь упереться в ограничение на максимальное число, а в случае с рациональными числами ты получишь очень сильную просадку в производительности.

Если тебе критически важна скорость, а точность - не так важна, то оставайся на IEEE754 и просто округляй то N значимых цифр (обычно больше 5 цифр мало кому нужно)

Все зависит от организации работы в конкретной конторе и конкретного разработчика, но лично у меня работает следующий подход:
1. Пишем начальное тз, минимальный необходимый перечень.
2. Говнокодим на основание п1 по принципу - "сделать быстро и чтобы работало по тз".
3. Пушим п2 в гит и разворачиваем сайт (или компонент на сайте).
4. Записываем фидбэк о компоненте, что не работает, как хотелось бы чтобы работало итп. Если это не критические замечания (безопасность или что то основное не работает), то откладываем изменения на месяц, квартал или год.
5. При накопление критической массы замечаний в п4 (ну или у Вас просто не осталось задач на настоящий момент) - добавляем рефакторинг п3 в очередь задач.
6. Повторяем 3-6 пункты до бесконечности.

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

Важное уточнение!

Схема с минимальным ТЗ и говнокодом работает лишь с теми заказчиками, которым Вы подробно разъяснили, почему сроки и стоимость ниже, почему за каждую "хотелку" не указанную в тз придется доплачивать, и почему необходим рефакторинг.

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