smilingcheater

Твиттер

Вам нужно прописать в этот файл команду, которая будет деплоить сайт на хостинг. Например деплой через подключение по SSH и выполнение на нем git pull:

ssh user@yourserver.com -T  'cd ~/site.ru && git pull'

Конечно нужно еще прописать на сервере в файле ~/.ssh/authorized_keys ключ гитлаба
Вот пример выполнения скиптов:
https://gitlab.com/gitlab-examples/spring-gitlab-c...

Другие примеры:
https://gitlab.com/gitlab-org/gitlab-foss/tree/mas...
https://gitlab.com/gitlab-examples

Это нормально.
Адреса раздает RIPE, у него есть база данных.
Например адрес x.x.x.x выдан ООО "Рога и Копыта" юридический адрес - Бостон.
Эта компания передала этот адрес своей дочерней фирме ООО "Шкуры" зарегистрированной на багамских островах.
В данный момент этот адрес выделен серверу этой компании который размещается в Новосибирском датацентре.

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

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

И какой все таки адрес должен выдавать сервис геолокации???

Мораль - не стоит думать что сервис геолокации показывает реальный адрес размещения сервера с таким IP.
Хотя во многих случаях данные совпадают.

Бывает что один IP присвоен серверу который уже 30лет стоит по одному адресу.
А бывает что один IP за день назначается трем различным серверам находящимся на разных континентах.
С утра в Европе, к вечеру в Бангкоке, а ночью уже в Австралии.

Бэк должен проверять каждый запрос, валидный токен или нет (есть пакеты для Laravel которые все за вас делают)
На фронте вы не сможете обеспечить безопаснось на 100%, только на бэке

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

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

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

Я не говорю, что обязательно нужно использовать таких монстров как Laravel и Symfony для создания API, но микрофреймворк Slim вполне неплох. Насчет "у микрофреймворков также версии быстро меняются" не могу ничего сказать, по крайней мере, код с 3 версии Слима на 4 переносится без проблем. Ведь в том и суть микрофреймворка, что там кода, зависящего от него, почти и нет - вся ваша бизнес-логика независимая.

use Telegram\Bot\Keyboard\Keyboard;
$buttons = [
    ['qqq', 'www', 'eee'],
    ['rrr', 'ttt', 'yyy'],
    ['uuu', 'iii', 'ooo'],
];

$keyboard = Keyboard::make()->setOneTimeKeyboard(false)->setResizeKeyboard(true);
foreach($buttons as $row)
{
    $keyboard->row(...$row);
}

обратите внимание на ТРОЕТОЧИЕ перед $row - https://wiki.php.net/rfc/argument_unpacking

let login = document.getElementById('login').value;
let password = document.getElementById('password').value;

const existingUser = users.find(u => u.login === login)

if (!existingUser) {
  users.push(  { login, password }  )
}

отвечая на вопрос, смотри

for (let i = 0; i <= users.length; i++) {
        // цикл выполнится много раз
        if (login == users[i].login && password == users[i].password) {
            // воу, мы нашли юзера!
            alert('ry-ry')
            debugger
        }else {
            // это не юзер, пишем в массив
            // а цикл ведь выполнится много раз
            users.push(
                {
                    login: document.getElementById('login').value,
                    password: document.getElementById('password').value
                }
            )
        }
    }

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

Написать десяток велосипедов не проблема.
Поддерживать один-два в актуальном состоянии - тоже.
Но может накопиться такое количество велосипедов, что их поддержка будет занимать все наличные ресурсы, и на разработку собственно функционала попросту не останется времени.

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

Когда начинал, везде предлагали брать готовое решение, а не изобретать свое чудо...

Есть две полярных и при этом правильных точки зрения.

Нужно писать своё, чтобы учиться (как вы описываете в вопросе). И чтобы понимать как работают готовые решения и почему именно так.

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

1. Экономия времени. Достаточно написать и после интегрировать в свои проекты...

"Достаточно написать" обычно для велосипедов измеряется годами, с учётом всё новых и новых требований и найденных багов.

2. Правильное решение. Соглашусь, но если практиковать свои навыки, разве у вас не получится также?

Опять же - речь про годы практики.

Это разве не просто передача уже готовых кадров которые подготовила видеокарта ?

Ну давай посчитаем, что такое передача готовых кадров.

Берем простенькое 1980x1200, получаем 2376000 точек.
На цвет (если нам нужен нормальный true color), уходит 4 байта. Получаем 2376000*4=9 мегабайт.
это ОДИН кадр.
Берем средненькую игру, где ты хочешь наверное 50-60 frames per second, получаем 540 мегабайт.
В секунду.
Это то, что нужно передать на удаленный компьютер, причем у тебя не целая секунда, а наверное по ту сторону не будут слишком рады, если игра будет лагать по полсекунды или даже четверть секунды.
При скорости подключения в 1гбит у тебя в идеальнейшем случае будет 60-80 мегабайт в секунду, так что тут вообще не вариант.
Какой у нас выход? Сжимать видео. Сколько у нас времени на сжатие видео? Даже секунды нет, иначе будут лаги. Даже сжав видео раз в 10, ты получишь 54 мегабайта в секунду, что впритык к 1 гбиту. И все равно маловато.

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

Либо уменьшаем лаги, но сжиать надо быстрее (мощный проц, и плохое качество, так как не успеваем), плюс хитрые алгоритмы просчитывающие, чего не передавать (опять проц). Но все рано лаги будут приличные.
Ну и 1980x1200 потихоньку отмирает, сейчас приходит 2560x1440 и 4к (4096 × 3072)

А еще есть звук, который мы еще не считали, и который весит немало.