ThunderCat

Обычно анализ начинают с включения журнала медленных запросов (slow query log). Туда записываются все запросы, анализирующие больше заданного количества строк и занимающие больше заданного времени.
Если этого не хватает, то можно включить общий журнал запросов (general query log). Туда уже попадают все запросы и информация о подключении/отключении клиентов.

Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

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

И кстати. Код, в котором "всё друг на друге завязано" - это очень плохой код. Собственно, предназначение всех этих "лееров, провайдеров и репозиториев" как раз в том, чтобы компоненты были как можно более независимы друг от друга.

$dec = gmp_strval(gmp_init($bin, 2));

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите SOLID, DRY, KISS и остальные модные словечки, постарайтесь всё это осознать, или, на крайняк - зазубрить. Всё придет с опытом, изначально все не понимали зачем всё так сложно, но эта сложность обусловлена неисчислимыми литрами слёз и потраченных нервов, всё не просто так.

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

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

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

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности

https://learn.javascript.ru/onload-ondomcontentloaded

window.addEventListener("load", function(){
  let element = document.querySelector(".loader-screen");
  element.style.opacity = "0";
});

Дело вкуса. Я знаю JS, но совершенно не хочу вкатываться в nodejs. Зачем мне нода, когда и php решает те же проблемы?

Мне лично нравиться в PHP, что есть на что опереться. Динамика развития стека средне динамичная и движется в правильном направлении, а не придумывает 100500 решений одной и той же проблемы. Есть решение - все его используют.

Боязнь изучения другого языка в вашем случае не оправдана. Попробуйте Python/Java/PHP. Ознакомитесь где вот вам проще искать документацию, приятность синтаксиса, скорость разработки. Где вы решаете проблему из мира живого, а не из мира "Как эта штука работает".

Я как-то хотел изучить Haskell, долго блуждал, но в итоге сложилось ощущение, что язык решает проблему для себя, а не для меня. Мне банально было неудобно всё в том языке. Даже родной редактор завершался с критической ошибкой...

Использовать PDO

Библиотеки называюся fullpage js

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

Как-то вы непоследовательно делаете.
Сначала взялись за работу, потом задумались о рисках.

Закодировать ничего у вас не получится, не тратьте время на поиски.

Думайте о том, как минимизировать риски.

1. Идеальный [для вас] вариант от монтёра Мечникова: утром деньги — вечером стулья. Здесь риски переходят на вашего заказчика.

2. Приемлемый вариант предоплата небольшими частями, хоть постранично. Либо такая же пост оплата. Опять же минимальные риски либо у вас, либо у заказчика.

3. Вариант win-win: демонстрация вашей работы с помощью программ удаленного доступа. Предоставляете доступ заказчику к своему рабочему столу и он смотрит, если устраивает — платит, после чего получает файлы. Можно использовать TeamViewer или шаринг экрана в скайпе, или еще что-то подобное. Риски быть кинутым на деньги сведены к нулю у обоих сторон.