smilingcheater

Есть идея пойти по цепочке по цепочке Html+Css->JS->PHP+MySQL

Хорошая идея. Но зачем? Для чего тебе это?

В последующие годы все также будет популярен PHP или стоит изучать node.js?

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

Если PHP будет актуален, для изучение данного ЯП будет ли актуальна ли книга "PHP 7 в подлиннике" или стоит начать изучение PHP, к примеру, с книги "Изучаем PHP 7".

Возьми любую, прочти, ПОЙМИ, повтори все, что там написано. Потом так же с другой. Порядок не принципиален.

Актуальна ли книга - "Выразительный JavaScript" и стоит ли прочитать "JavaScript. Полное руководство" или же "Изучаем JavaScript".

Любая книга актуальна. Возьми наугад любую, повтори действия из предыдущего пункта, перейди к следующей книге.

Предложите свои варианты, что стоит почитать...

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

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

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

В следующий раз только задавай подобные вопросы на книжном форуме. Тут больше по программированию люди, чем по чтению.

Твиттер

Вам нужно прописать в этот файл команду, которая будет деплоить сайт на хостинг. Например деплой через подключение по 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. Правильное решение. Соглашусь, но если практиковать свои навыки, разве у вас не получится также?

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