Чтобы понять как оно работает нужно ставить Arch, с чем автор не справился, хотя у Arch самая объемная и самая лучшая дока среди дистрибутивов.
Ставя Gentoo можно, конечно, узнать некоторые особенности работы железа, но эти знания практически не нужны. В 2021 году весь смысл Gentoo исчез, оптимизации под железо при сборке из исходников дают очень мало, а собрать все из исходников уже просто невозможно, поэтому даже Gentoo отказался от этого.
А если все-таки очень надо что-то собрать из исходников, то это можно сделать в любом дистрибутиве.
Каждый дистрибутив собирает свое ядро. В Arch это наиболее ванильное ядро с небольшим кол-вом патчей, в Ubuntu это монстр очень сильно измененный. Debian и Fedora где-то посередине. Кроме того, всегда можно собрать ванильное ядро, если очень хочется, хотя особой необходимости обычно в этом нет.
Стабильность вещь субъективная. По-моему, Ubuntu наименее стабильный дистрибутив, Debian позиционирует себя как очень стабильный, но из-за этого софт в нем устаревший. На практике, у Arch и Fedora стабильность не уступает Debian и софт не древний.
В пхп мне понравилось, что написав class User, мы потом можем использовать User уже, как объект, когда в js обязательно нужно создать экземпляр с другим названием.
Где такое в пхп? Нельзя получить объект, не создавая его, а просто объявив класс.
Если имели ввиду это:
Class User {}
$User = new User();
то синтаксически, так, конечно, можно. Но по PSR это должно выглядить так:
Друг, жрет много относительно чего? К примеру, PHPStorm тоже не мало жрет, но выбираем его и без вариантов.
Это всего лишь вариант, все дело в том, что нужно конкретно вам. Для кого-то эти "много ресурса" мелочи окупающиеся удобством, а кто-то будет мучиться с grep, чтобы не потратить лишний Гб памяти.
Т.е. стандартный вариант: пишем логи просто в файл, чтобы было удобно читать запускаем какую-нибудь Кибану в связке с Эластиком, который будет парсить файл лога и предоставлять поиск.
Но это просто вариант, как автор предполагает использовать лог неизвестно.
FanatPHP, в Эластик вполне пишут данные, через его API. Для логов это не нужно, гораздо эффективней, чтобы он сам их парсил, но в принципе писать можно.
Дмитрий Свиридов, разумеется. Друг, в большинстве случаев этого не нужно. В исключительных случаях, когда не получается воспроизвести баг на локальной сборке, можно забрать с прода данные на которых наблюдается проблема, и то, отдельные данные, а не весь дамп. Это важно как с точки зрения безопасности (хеши паролей, персональные данные и т.д.), так и с точки зрения, что если база большая, то всю ее вытягивать проблематично.
FanatPHP, так ведь в вопросе значится "Сейчас мы начали отслеживать изменение любых моделей и логировать это в базу данных. Например, отслеживать все действия пользователя. База пухнет и для бэкэнд разработчика выкачивать дамп базы для локальной разработки становится проблемой".
Т.е. проблема именно в создании дампа продакшен сервера со всеми данными для использования в локальной разработке.
Дмитрий Свиридов, дамп обезличенных продовых данных - это хорошо, но это нужно для тестирования, для проверки поведения на реальных продовых данных, а не для разработки.
Нюанс - скорость интерфейса DVD-привода может быть ниже основного интерфейса на HDD/SSD. Можно потерять в скорости на втором SSD по сравнению с первым.
KarambyG, связи создаются не для обеспечения работы join, а для контроля за консистентностью данных. Вы можете ее контролировать не на стороне СУБД, а в приложении работающем с базой, но на стороне СУБД это делать проще и надежнее. Т.е. если вы правильно их создадите, то у вас не будет никогда в subscribers присутствовать id юзера, которого нет.
Архитектура это не задача джуниора, планирование - это штука сложная, ее решают комплексно, а не просто полагаясь на правильную оценку джуниора. Если код самому не нравится, значит понимаете в чем он плох, над этим уже можно работать.
Т.е. как уже написали, проблема не в вас, а в руководстве компании, которое не смогло организовать нормальную разработку. Учиться вам не у кого, а значит развитие будет идти очень медленно - ищите более интересные предложения работы.
Timur4D, переведите время в интервалы от начала дня, нечетные умножьте на -1, и все их сложите.
Т.е. как-то так:
27.06.2021 09:00 => -9*60
27.06.2021 13:00 => 13*60
27.06.2021 14:00 => -14*60
27.06.2021 18:00 => 18*60
(-9) + (13) + (-14) + 18 = 8
ksimmi, тогда уже проще на protobuf перейти. Система которая загружает переданные данные, она же знает, что она грузит (есть же контракт на обмен данными?), если она знает, что переменная число, то нет большой разницы строкой оно прилетело или все же числом.
Это не "сериализация с использованием кавычек", это сохранение числа в виде строки, т.к. в json кавычки это признак строки. Такое "извращение" необходимо, чтобы обойти проблемы.
Вы передаете данные между подсистемами, какой тут может быть "формат, который поддерживает типы", типы у вас могут быть совершенно различные в разных подсистемах. Поэтому создавайте контракт для обмена данными и действуйте на основе него, и если надо преобразовывайте строки к числу.
А проблема скорее всего в том, что ваша библиотека в ruby не знает как отдать число с плавующей точкой, чтобы не потерять данные, поэтому и оформляет его как строку.
Владислав, типа того, они ещё и в виде timers бывают, о чем выше уже писали.
Но я бы уточнил. Когда соискатель задаёт вопросы - это хорошо, значит заинтересован сделать то, что нужно, а не "я так понял ТЗ".
Adamos, при кванте меньше минуты, уже нет смысла дёргаться, а лучше работать постоянно. Если очень хочется, есть systemd timers. Нет смысла изобретать велосипед.
По сокрытию тоже странновато, разрешать демонов и запрещать cron, хотя капризы могут быть разные.
Ставя Gentoo можно, конечно, узнать некоторые особенности работы железа, но эти знания практически не нужны. В 2021 году весь смысл Gentoo исчез, оптимизации под железо при сборке из исходников дают очень мало, а собрать все из исходников уже просто невозможно, поэтому даже Gentoo отказался от этого.
А если все-таки очень надо что-то собрать из исходников, то это можно сделать в любом дистрибутиве.