Александр Медведев

Нет, обобщенные типы можно использовать не только в функциях

type SomeData<Data = any> = {
    data: Data[];
}
const a: SomeData<number> = {data: [1,2,3]};

сделать phrase абстрактным полем/свойством и переопределять в потомках. Потомок сам может выбрать - сделать поле или свойство.

interface IAnimal {
    name: string;
    say: () => string;
}
abstract class Animal implements IAnimal {
    name: string;

    constructor(name: string) {
        this.name = name;
    }

    say() {
        return `${this.name} says ${this.phrase}`;
    }

    protected abstract phrase: string;
}

class Cat extends Animal {
    protected get phrase() { return 'm'; }
}

const c = new Cat('q');
console.log(c.say());

Удалить Pull Request невозможно, разве только закрыть его, да и не нужно ничего удалять для доработки задачи! Просто вернитесь в свою тематическую ветку. Добавьте новые коммиты с исправлениями и отправьте их на гитхаб. Pull Request обновится автоматически.

Даже если вы закрыли пиар, но продолжили работать в той же ветке, то последующий пуш просто заново откроет этот же пиар.

Аналогично если на Code Review будут замечания, то вы их просто исправляете локально в той же тематической ветке и пушите. Доработки сразу попадут в Pull Request.

Не очень хорошо ему там будет.
Как минимум у HDD рабочий диапазон температур обычно указан от 0 или от +5 градусов. Т.е. где-то на грани получается. Разьве что комп активно работает и сам себя хорошо греет.
Лучше, наверное, не выключать его совсем. В выключенном ещё и смазка в кулерах застыть может, потом не стартуют.
Ну и внеся потом домой перед включением не забыть дать прогреться и проветриться, чтобы конденсат ушёл.

У WebStorm, который у вас открыт, есть прекрасный инструмент разрешения конфликтов.

Через меню сначала сделайте Git->Commit.
Потом в меню Git -> Fetch (вытащить все последние изменения с сервера в кэш гита).
Затем Git -> Pull.
Если есть конфликты, откроется инструмент разрешения конфликтов.

Там все визуально легко понять, что и куда мержится. Слева у вас изменения с сервера, справа ваши, а посередине результат, который можно редактировать.

Это конфликт версий.

Вы говорите не о драйверах, а о дисках.
Драйвера - это другое, их 4 доступно "local", "ftp", "sftp", "s3". Это способы хранения файлов. Драйвер local - это файловая система вашего сервера.

О дисках:

По умолчанию диск local маппится на /storage/app, а public на /storage/app/public.
Каталог /storage/app/public в свою очередь линкуется в /public/storage

Отсюда вывод: диск public доступен из интернета. диск local – нет.
Но если вы в диске local загрузите файл по пути 'piblic/image.png' то он также будет доступен по адресу site.com/storage/image.png

Кучи if ($request->input("type") заменяй на switch case, тем более далее по тексту у тебя оно используется, пиши код хотя бы в одном стиле.

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

Про права доступа, у тебя точно 2 состояния - public и authorized? может у тебя еще есть какой-нибудь superuser? или еще есть права на основе данных (например если статус операции 'такой то' то действие запрещено)... хотя метод по любому должен быть ->allowed() который собирает данные по текущему пользователю, состоянию, данным и т.п. хотя лучше разделять права доступа по роли и по состоянию, пусть будет пара методов.

Вот такие строчки "required|numeric|min:1|max:10000" - bad practics, магические константы, что значит 10к, 15, 3, 24, 5000... везде разные, что почему зачем, уже через пол года ты не вспомнишь а уж другой программист и подавно не поймет. Оформляй в виде функции-генератора или даже класса, документируй все значения, даже если это значения от балды, когда ты их выдумывал какой то смысл ты в это вкладывал - опиши это в коментариях в этой функции или классе, не обязательно все выносить в конфиг файл, сам отдельно лежащий файл с таким классом уже этот конфиг. Мало того, почему сериализация массива такая странная, на рынке существует уже безоговорочный стандарт json, и machine и human readable, накладные расходы минимальны (можно заставить паковать nginx, по трафику будет не на много больше чем умно оформленный protobuf), тем более у тебя там ошибки уже в json выдаются.

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

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

Возможно, непонимание происходит оттого, что существует не один, а несколько векторов атаки на пароль.

1. Поиск хэша по "радужным таблицам" (rainbow tables): огромным базам данных, где собираются заранее посчитанные хэши для любых возможных строк.
   
2. Метод грубой силы (bruteforce): перебирать все комбинации символов и применять к ним хэширующую функцию до тех пор, пока она не вернёт искомый хэш.
   
3. Поиск по словарю. Похож на брутфорс, но перебор не всех возможных значений, а всего нескольких тысяч самых популярных паролей, типа "123", "password" и пр.
   

phpfaq.ru/tech/hashing

И только одного элемента недостаточно, а нужны все в комплексе:
- Хэширующая функция должна иметь большую вычислительную сложность, чтобы усложнить подбор перебором. по этой причине md5() не подходит
- Хэш должен быть посолен уникальной солью, чтобы нельзя было, затратив 1 раз кучу вычислительных усилий, заранее построить хэши для любых комбинаций символов. По этой причине фарш без соли - деньги на ветер.
- Пароль не должен быть слишком простым, иначе даже медленный перебор его раскроет. Этот момент тоже надо учитывать

Если вы используете $wpdb, то зачем mysqli_fetch_assoc-то, подсчёт результатов, цикл while и прочая ерунда?

<?php 
require_once($_SERVER['DOCUMENT_ROOT'].'/wp-load.php');
global $wpdb;
$results = $wpdb->get_results("SELECT * FROM stats_players ORDER BY logins LIMIT 10");
?>

<table class="gradienttable">
    <tr>
        <th>Позиція</th>
        <th>Гравець</th>      
        <th>Входів</th>
    </tr>
    

    <?php foreach ($results as $i=>$row) { ?>
        <tr>
            <td><?= $i+1 ?></td>
            <td><?= $row['name'] ?></td>       
            <td><?= $row['logins'] ?></td>
        </tr>
    <?php } ?>
</table>

На практике редко ошибки правятся "выдиранием" одного коммита из истории, но такая операция вполне себе возможна.
Вариант номер один - интерактивный ребейз, и в нем указываешь какие коммиты дропнуть. Если коммитов много, то можно задолбаться решать конфликты
Вариант номер два - просто делаешь новый коммит с реверсом изменений из коммита, который привел к проблемам
Вариант третий - делаешь новый бранч, откатываешся до проблемного коммита, потом из полного бранча накатываешь остальные изменения.

Все сценарии приблизительные, потому что каждая проблема требует комплексоного подхода и знания возможностей инструмента, поэтому не поленись, а почитай вот это внимательно и полностью
https://git-scm.com/book/en/v2

Удобно эндпойнты в апи делать

[GET]    /order/{id}  получить информацию о заказе
[POST]   /order/{id}  создать новый заказ
[PUT]    /order/{id}  обновить данные в заказе
[DELETE] /order/{id}  удалить заказ

Вместо

[GET]  /order/{id}
[POST] /order/{id}/create
[POST] /order/{id}/update
[POST] /order/{id}/delete

будет ли нормальная поддержка этих методов в том же php и формах html?

https://caniuse.com/mdn-http_methods_put
https://caniuse.com/mdn-http_methods_delete

А что вы имеете ввиду под нормальностью в php? Определить метод запроса можно, прочитав $_SERVER['REQUEST_METHOD'], получить данные из php://input

UPD

Нашел вопрос аналогичный. Ответы краткие но емкие и по делу.
https://stackoverflow.com/questions/27941207/http-...

так как ты явно указываешь директорию на хосте, это не volume, а bind mount. Когда используешь bind mount, конфиг-секция volumes (на топ уровне) не нужна. Можешь ее удалить. Тем более ты все равно пишешь ее не правильно. А файлов у тебя нет, потому что ты не ту директорию в контейнере указываешь. Нужно /var/lib/postgresql/data