McBernar

вот тут neuralnet.info + видик на Ютубе

там не все "типа как принято", да и про конечные автоматы, кажется, не очень говорит, но для понимания принципа этого достаточно

и да, никакого ИИ нет. Есть просто масив инфы и алгоритмы извлечения из него обобщенной информации

Можете .hero добавить свойство
border: 1px solid transparent;

https://jsfiddle.net/njbaftd4/

Но вообще проблема в H1 и его стандартных отступах
Добавляйте сбрасывание стилей т.н Reset.css или используйте normalize.css
отлично гуглится
https://jsfiddle.net/njbaftd4/1/

1. Если у тебя уже установлен Gulp и настроен локально в папке проекта, то в консоли переходишь в папку этого своего проекта и вводишь npm install node-normalize-scss --save-dev

2. Потом в основном sass-файле делаешь импорт @import "normalize";

3. В таске по компиляции sass в css в пайп добавляешь строчку кода

includePaths: require('node-normalize-scss').includePaths

Вот полный код и документация

var gulp = require('gulp');
var sass = require('gulp-sass');
 
gulp.task('sass', function () {
  gulp.src('path/to/input.scss')
    .pipe(sass({
      // includePaths: require('node-normalize-scss').with('other/path', 'another/path') 
      // - or - 
      includePaths: require('node-normalize-scss').includePaths
    }))
    .pipe(gulp.dest('path/to/output.css'));
});

https://www.npmjs.com/package/node-normalize-scss

code -> reformat code?

$text = preg_replace('/\s+/', ' ', $text); // убираем склеенные пробелы
$array = explode(' ', $text); // делим как обычно по пробелам

$json = json_decode(file_get_contents('book.json'), true);

$json['books'][] = [
  'email' => 'foo',
  'author' => 'bar',
  'created' => '42',
];

file_put_contents('book.json', json_encode($json));

Пример.

Laravel

Каждый кулик свое болото хвалит

)))

потому что надо не тупить, а читать документацию:

При делении по модулю операнды преобразуются в целые числа (удалением дробной части) до начала операции. Для деления по модую чисел с плавающей точкой используйте fmod().

php.net/manual/ru

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

Первым делом глянул бы по примерам тут:
https://threejs.org/examples/#webgl_physics_rope
И посмотрел по коду как они все инциализируют в ammo. Если бы этого мне не хватило для реализации поставленной задачи, то попытался бы найти доки. Но доки на форк я так понял никто не собрался писать, тем более, что проект опенсорсный и довольно старенький. Потому есть только это:
bulletphysics.org/Bullet/BulletFull/index.html
Как там разбираться без хорошего понимания в программировании физики и базового понимания синтаксиса C++ я не представляю. Другое дело, что если есть хорошее понимание физики, то по названиям классов можно интуитивно понять, что они делают.

Есть еще вариант искать чето другое, например:
https://doc.babylonjs.com/overviews/using_the_phys...
Тут они указывают 3 вида библиотек, к которым они написали интерфейс. Можно пробежаться по этим библиотекам и посмотреть если ли у них нормальная документация.
Или искать что-то другое под Three, про что именно вы и спрашиваете. Может кто-то тут и найдется, кто подскажет, будет здорово. Мой ответ на случай если не подскажут)

Еще один вариант это найти людей/студии, которые сделали то, что вы пытаетесь и спросить у них. На Toster я сомневаюсь, что такие найдутся. Все таки сфера достаточно специфичная. Про студии я не в курсе, но пару разработчиков я бы спросил в twitter сообщениях или по почте, это:
codepen.io/ge1doot и codepen.io/zadvorsky
Можете поискать других, например тут: https://www.awwwards.com/inspiration/search?text=t...

Запросы к базе надо сводить к минимуму. Мне кажется, глупо говорить, что они нагружают сервер, ну и увеличивают время загрузки страницы. Это, блин, логично.

Храните гребаный код в гребаных файлах. В чем проблема? 2к17 год, давайте, блин, в базе данных хранить верстку, просто потому что потому. Извращенцы. Скоро отдельный сервер будут делать, чтобы на него за версткой ходить, а на боевом просто echo file_get_contents("http://....

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

мне кажется все же есть такие люди у которых на продакшене подгружается разметка из БД.

Ну да, есть. Без работы вон сидят.

Паттерны - это реальные инструменты, позволяющие добиться реализации концепции объектно-ориентированного проектирования и принципов SOLID

Ссылка на SOLID

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

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

При этом :
1) Никак не изменяется код класса "Комментарий" (кроме подключения интерфейса) и в будущем мы добавляем поведения без изменения класса + стабильность системы, гибкость
2) Каждый класс имеет свое четкое назначение + легкость модификации, порядок
3) Комментарии наследуют некоторое поведение, путем подключения поведения, но также могут поступать любые другие классы - сущности (посты, блоги итп) , то есть интерфейс и реализация лайков универсальна, и весь функционал работы лайков находится только (строго!!!) в одном месте + легкость модификации, Универсальность, стабильность, интуитивная понятность

Из википедии :

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

Оттуда же про SOLID

Избавиться от "признаков плохого проекта"[4] помогают следующие пять принципов SOLID:

Принцип единственной ответственности (The Single Responsibility Principle)
Существует лишь одна причина, приводящая к появлению класса.

Принцип открытости/закрытости (The Open Closed Principle)
«программные сущности … должны быть открыты для расширения, но закрыты для модификации.»

Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
«объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.»

Принцип разделения интерфейса (The Interface Segregation Principle)
«много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»

Принцип инверсии зависимостей (The Dependency Inversion Principle)
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»