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

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

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

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

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

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

Используете GoLand? Он подсказывает:

Possible resource leak, 'defer' is called in the 'for' loop.

A "defer" statement invokes a function whose execution is deferred to the moment the surrounding function returns, either because the surrounding function executed a return statement , reached the end of its function body , or because the corresponding goroutine is panicking .

Предупреждение говорит о том, что defer код будет выполнен только при завершении функции, а не итерации цикла. В вашем случае это предупреждение неактуально, но проще немного переписать код, чтобы не было "ругани":

func (app App) Shutdown() {
	for _, shutdown := range app.onShutdown {
		if err := shutdown(); err != nil {
			log.Println(err)
		}
	}
}
...
defer app.Shutdown()

То что на сервере на разных портах живёт множество программ и общаются меж собой - это нормально. Главное огородить их от внешнего доступа: обычно возможно указать на каком ip случшать порт, в таком случае достаточно указать локальный: 127.0.0.1:8000 вместо 0.0.0.0:8000 (слушать на всех) и извне никто на него попасть уже не сможет. Если же такой возможности нет, надо не забыть заблокировать этот порт файерволом.