В общем-то, на сегодняшний день для разработки серверной части сайов (т.н. «бекенд») вполне хватает языка РНР. Ну, не скажу, что я прямо уж досконально его изучил. Но, по крайней мере, еще не было задачи, которую мне бы не удавалось решить с его помощью. Язык, на самом деле, очень даже функциональный и удобный. Да еще когда PHPStorm под рукой (в паре с Notepad++, естественно)…

Одно время попытался я доделывать (чужие) сайты на фрилансе. Честно говоря, меня привлекает не разработка с нуля, а именно – доработка. Когда надо где-то в чем-то разобраться, доделать, исправить, дописать… Тем более, что подавляющее большинство программистов (и «программистов» тоже) имеют как раз обратную направленность, т.е. мне с ними не по пути. И это – хорошо.

Честно говоря (это уж как есть говорю, ибо расписывать свои «понты» мне необходимости-то нет вообще, ибо… Тем более, что и самих «понтов» тоже нет, а, стало быть, и расписывать нечего), результаты пока не очень. Причина в том, что практически все сайты нынче делаются так или иначе:

Либо на готовых платформах, типа Wordpress, Битрикс или PHPbb какой-нибудь;
Либо при помощи фреймворков (и иной раз – еще и нескольких!).

А вот на чистом РНР сайтов практически не встречалось.

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

Так вот, стал присматриваться к фреймворкам. И, глядя на чужие сайты (ну, от которых мне заказчики давали пароли и доступ), я обнаружил, что достаточно многие из них (те, что «самописные») сделаны на фреймворке Laravel. В общем-то, технология молодая, от роду ей 10 лет, а, гляди-ка, стала столь популярной.

Ну, ладно, думаю, начну, что ли, вникать – хоть в этот Laravel, для начала. Поначалу мне казалось – ну, что там… пара дней – и начну делать на нем сайты. Однако, оказалось все не столь быстро.

Да, именно, НЕ БЫСТРО. Сложного-то там ничего нет. Это не чистый РНР, это там поработать нужно чуток.

Хм… А ведь до этого я не имел дела с базами данных (от слова вообще). И с фреймворками – тоже. Не говоря уж о разных Composer-ах, npm и протчая, которые мне, ну, вот сто лет нужны не были. Это все звучит солидно, но, по сути, просто затрудняет понимание работы "изнутри". Потому как много чего нагромождено. Очень излишне, на мой взгляд. И в итоге, когда возникают ситуации "иск" - бывает немало проблем. И затрат, с ними связанных.

Ну, ладно. В общем, эта, «величайшая в мире» архитектура MVC и прям-таки «величайшая» REST-технология и все такое прочее. Понятно, что на поверку это все оказалось (как я и ожидал) больше болтовней, чем пользой. Но, зато звучить-с…

Ах, да, и еще «выразительный синтаксис», от которого меня воротит и тошнить тянет (чуть ниже поясню, почему). Но, да, зато со мной не согласятся 90% разработчиков на РНР.

В общем, вначале я скачал с интернета книгу объемом страниц так 500 и стал читать. Оказалось, в этом Laravel – множество разных (совершенно излишних для меня и только мешающих) концепций – эти разные фасады, хэлперы, контроллеры, роуты, сидеры, и т.д., и т.п. Читал и каждый раз думал: ну, вот зачем, какого чёрта это все напридумывали? Не, нельзя было просто взять, да и написать на РНР вот это или вот то? Зачем для даже простейшей операции требуется «обязательно», типа, делать класс (наследника от какого-то другого класса, ага), и там прописывать нечто. Зачем даже для простой страницы применяется просто масса разных коротких файлов (с этими разными контроллерами и т.д.)? В итоге, а как же иначе, стек вызовов состоит из 50, а то и более(!) единиц вызовов. И это – даже, повторюсь, для простой страницы. А ведь все эти вызовы, объекты в них требуют, разумеется, ресурсов.

То ли современные разработчики таким образом доказывают перед заказчиками необходимость приобретения все более и более мощных серверов (даже для обслуживания сравнительно легких сайтов), то ли это просто дурдом. Но, еще раз: так как очень многие сайты нынче используют именно фремворки, то, ладно уж, изучим. Чего там.

В общем, почитал так несколько. Ну, начало, основное. Да еще, паразитство, НИГДЕ нет мало-мальски подробной схемы стека вызовов этого фреймворка. А без фундаментальных концепций я – плохой работник. Работать «по-гастарбайтерски», т.е. обладая минимумом знаний и концепций, я не приучен. Если уж за что берусь – то подхожу фундаментально, обширно. Да-да, как в той самой советской школе, которую ныне ругают практически все, кому не лень. Типа, за то, что она якобы, давала в основном только "оторванные от практики отрывки теоретических знаний".

Итак, что происходило

Вначале (в виртуальной машине, конечно) я стал устанавливать РНР. Затем Composer (который, как выяснилось, представляет собой нечто типа apt-get install в Linux). Этот Composer я освоил примерно за пару часов.

Затем Git. Который, признаться, мне тоже 100 лет не нужен, но, говорят, при командной работе он полезен. Согласен. Ну, чтобы версиями управлять. В общем, поначалу скачал было книгу по Git – тоже примерно на 500 стр... Хм. Потом подумалось – нет, для начала, лучше на практике посмотреть.

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

@echo off
REM download .ZIP file of PHP build from http://windows.php.net/downloads/
REM path to directory you decompressed PHP .ZIP file into (no trailing \)
set phppath=c:\php
REM Clear current PHP handlers
%windir%\system32\inetsrv\appcmd clear config /section:system.webServer/fastCGI
REM The following command will generate an error message if PHP is not installed. This can be ignored.
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /-[name='PHP_via_FastCGI']
REM Set up the PHP handler
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='%phppath%\php-cgi.exe']
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /+[name='PHP_via_FastCGI',path='*.php',verb='*',modules='FastCgiModule',scriptProcessor='%phppath%\php-cgi.exe',resourceType='Unspecified']
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /accessPolicy:Read,Script

REM Configure FastCGI Variables
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /[fullPath='%phppath%\php-cgi.exe'].instanceMaxRequests:10000
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='%phppath%\php-cgi.exe'].environmentVariables.[name='PHP_FCGI_MAX_REQUESTS',value='10000']"
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='%phppath%\php-cgi.exe'].environmentVariables.[name='PHPRC',value='%phppath%\php.ini']"

cd c:\php && php -S localhost:8000
Раскомментировать в файле php.ini, как минимум, строчки extension=curl, extension=fileinfo, extension=mbstring, extension=mysqli, extension=openssl, extension=pdo_mysql

C:\Users\username>composer -V https://laravel.com/docs/8.x#installation-via-composer
composer global require "laravel/installer"
laravel new projectname/
composer self-update
composer create-project --prefer-dist laravel/laravel projectname

composer require laravel/jetstream
php artisan jetstream:install livewire
npm install && npm run dev

C:\PHP\project1>php artisan serve - запуск к сервера РНР // Вместо projectname ранее было указано project1
C:\PHP\project1>php artisan make:controller Cover // Для примера, создаем контроллер файл Cover.php в каталоге /app/Http/Controllers

composer create-project phpmyadmin/phpmyadmin

Запускать в консоли mysql: (!)
mysql>show variables like 'port'; // Посмотреть номер порта, на котором работает mysql
php artisan make:model Contact -m // Создаем модель для базы данных и с миграцией (-m)

Раскомментировать в файле php.ini строчку: extension=pdo_mysql
Затем:
php artisan migrate

Если при попытке добавить значения в базу данных браузер вывел ошибку типа could not find driver (SQL: insert into `contacts` (`name`, `email`, `message`, `updated_at`, `created_at`) values , то надо очистить кэш:
php artisan config:cache
И затем ПЕРЕЗАПУСТИТЬ сервер-РНР
composer require laravel/ui --dev // Установка пакета Laravel UI для установки команды ui (чтобы можно было сделать форму авторизации)
php artisan ui bootstrap --auth // Создание формы авторизации на основе bootstrap
php artisan migrate

Может, кому пригодится. Если кто, как и я, с ПОЛНОГО НУЛЯ начнет в этом разбираться.

Composer, Git

Итак, Composer. Затем – Git. Дальше хотел было освоить Docker, уже даже скачал. А потом понял, что нет, лично для меня удобнее и нагляднее (и, главное, БЕЗОПАСНЕЕ) – делать все в виртуальной машине. Не стал с ним связываться.

Ничего не имею против программы Docker, но что-то... подозрительной она мне показалась. Может она, и в самом деле, запускает сторонние процессы в совсем другом адресном пространстве (коего на 64-разрядных системах - хоть отбавляй, это не 32 разряда, где оно было всего-то 4 ГБ). Да, верю, но все равно как-то.

В общем, отладил сервер с РНР. На это где-то день ушел. Не стал связываться с разными Apache/OpenSerxer. Использовал встроенный в Windows сервер IIS. Правда, его не рекомендуют из соображений безопасности. Но, еще раз, ежели в виртуальной машине, да еще свой полностью сайт (без сторонних серверных скриптов), то, мне кажется, почему бы и нет.

PhpMyAdmin

А дальше – взялся было за PhpMyAdmin, чтобы базами данных управлять. Установил. Еще раз, мне-то это самому – ну, ни на какой чёрт не нужно, у меня все отличненько на файлах работает и горя не знает (на всех моих сайтах). Но, раз уж Laravel – ладно, освоим попутно и базы данных (хотя бы на начальном уровне), что уж теперь. В итоге, толком не работает, даже не запускается. Раньше, работая в Denwer, я с этим и горя не знал - все запускалось и работало "из коробки". А тут - пришлось все вручную устанавливать.

MySQL

Только через какое-то время узнал, что, оказывается, надо вначале MySQL установить. Ладно, скачал, установил. При установке выснилось, что там то этот драный Python не той версии, то .NET Framework, а то и Visual Studio (и все это лично мне также 100 лет не нужно, ибо 53 года как-то вполне себе без этого жил и делал все, что было необходимо). Да там, в MySQL еще настройка очень дурацкая – в несколько этапов, которые, кстати, совершенно неочевидны, если делаешь с нуля. В общем, кое-как запустил сервер MySQL.

Потом вновь PhpMyAdmin. Да еще соответствующие настройки в файлах .env, database.php. Ладно, в итоге, еще через сколько-то дней и это тоже заработало.

Разумеется, занимался я этим больше по вечерам-ночам, в перерывах между собиранием колорадских жуков с картошки (а туда еще доехать надобно), и прочими, так сказать, разными делами. Да еще сливы с помидорами нынче много у нас, с ними решал вопросы. И т.д.

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

Потом – нашел в интернете видео-уроки по Laravel

Ибо понял, что совсем с нуля на этом фреймворке сделать сайт НЕ ПОЛУЧИТСЯ. Его простота, на самом деле, крайне обманчива. Ибо, еще раз, множество самых разных и излишних (на мой взгляд) концепций, этих классов, абстракций. Реально, путаешься в них. Куда вот такое нагородил разработчик фреймворка.

Вообще, как по мне, так ПРОЩЕ(!) поднять сразу и единожды груз массой в 100 кг. Чем бегать 100 раз с грузами по 1 кг каждый. Увы, Laravel предлагает именно второй вариант. Хотя, согласен, наверное, если проект - гигантский и над ним трудится не один десяток, а то и сотни/тысячи человек - ну, наверное, в самом деле, наличие этих абстракций помогает как-то изолировать работу разных людей друг от друга. Но, это относится, мне кажется, к таким сервисам, типа Яндекса, mail.ru, какие-то крупные форумы и т.д. Но, насколько мне известно, как раз на подобных проектах Laravel и ему подобное не используется.

Честно говоря, я как-то не люблю обучаться по видео. Но, увы, текстовые варианты – из тех, что попадались в интернете – как-то не очень. Ну, рассмотрен некий простой частный случай. А нужна-то ведь система – для начала. Частные случаи – это уж потом.

Так что, пришлось видео использовать. Я-то привык делать большие монолитные коды (сильно осуждаемые ныне многими программистами и «программистами»). Ну, и что, что в таких кодах - по несколько тысяч строк? И что, что там я стараюсь делать строки поближе друг к другу(?) - ну, так, это чтобы больше строчек было видно на дисплее и чтобы ОДНИМ взором можно было охватить сразу побольше кода, вобрав его в себя. Зато сразу всё перед глазами, ВСЁ в уме держишь - и работать очень удобно и быстро. При наличии соответствующих комментариев, все сразу ясно и понятно – что, куда, откуда. И нет необходимости постоянно лазить по этим разным мелким файлам с контроллерами, шаблонами, видами, да прочими, так сказать. А то – один файл, второй, десятый… Так и счет потеряешь. Честно говоря, меня так и тянуло – взять, да и ОБЪЕДИНИТЬ их в один-единый файл – чтобы проще было работать. Ну, да ладно, не стал этого делать. Решил следовать нынешней моде(ли) в IT-технологиях. А то так и фреймворк этот поломать недолго. Ну, вот в итоге так и бегал от файла к файлу, как этот.

До этого, кстати, с ООП (объектно-ориентированное программирование) очень мало имел дела. Разве что, в javascript, да и то – чисто для удобства в некоторых местах. Только там, где без ООП обойтись затруднительно. А тут, этот Laravel на ООП-то и построен. И – абстракция на абстракции и абстракцией погоняет. Какого чёрта, зачем они?... Ну, да ладно. При командной работе это очень удобно. При так называемой промышленной разработке. Ну, может, и правда. Я в серьезной команде пока еще не работал.

Но, что-то мне подсказывает, что вот в команде-то как раз еще больше путаницы возникнет с этими многочисленными файлами/объектами. Или - должен быть такой подход: один или несколько высококлассных спецов, а остальные... вполне могут быть даже начинающими. Последние будут, да, как раз и работать над разными мелкими классами/файлами.

Да еще автор той книги рекомендует… вообще обходиться без языка РНР

Т.е., по сути, я понял, что Laravel – это не PHP, хотя он и написан на нем. Он если и похож на РНР – так, разве что, наименованием переменных. Ну, еще чем-то. А так – это, грубо говоря, иной язык. Что-то типа java или даже С#. Где даже простые операции делаются по-другому, т.е. иначе, чем в РНР. Т.е. это как библиотека QT для создания графических интерфейсов.

Которая фактически вынуждает программиста использовать именно ее конструкции и концепции, а не те, что имеются в языке С/С++. Чем она, в частности, мне и не нравится. Лично мне по душе – подход библиотеки FLTK, к примеру. Мало того что она – легкая, быстрая, да еще и бесплатная (даже в статическом виде!). Так она еще и минимально обременяет программиста своими надуманными конструкциями, представляя собой лишь аккуратное дополнение в язык С/С++. Не глобально, а – местами, точечно. Вот – именно это как раз по мне. Это когда НЕ нарушая общих концепций, не навязывая свою архитектуру/синтаксис, и только лишь там, где необходимо, точечно, - используются конструкции FLTK. А во всех остальных местах – обычный С++.

Любопытно, что я множество раз встречал в интернете доводы, что, мол, та или иная библиотека «неудобна», якобы, потому, что она основана… на языке С++. М-да… то ли народам не хочется изучать языки программирования, то ли не знаю что. Странно как-то.

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

Попутно узнал о существовании языка Twig. Он используется во фреймворках. Мне-то самому он, ну, сто лет не нужен. Но, во фреймворках используется.

А это, кстати, даже несколько затруднительнее, чем чистый РНР

Потому, что на РНР архитектура может получиться гораздо-гораздо проще, без этих многочисленных цепочек вызовов объектов и классов. А здесь – надо еще знать, куда, зачем и какой именно класс требуется. И – в каком каталоге/файле находится. И, самое главное – как конкретно его применять. Т.е. время тратится больше не на собственно написание кода, а в основном на узнавание того, какой там хелпер или контроллер/фасад следует применить; и - как же именно его следует применять. И применять следует именно так, как запроектировал разработчик этого фреймворка. Причем, со временем, после выхода очередной обновленной версии фреймворка, соответствующий способ вполне может... измениться.

Например, как Вам запись типа этой:
@extends('Layouts.app')?
Что там, в кавычках? Оказывается... вот что:
/resourses/views/Layouts/app.blade.php

Т.е. разработчик фреймворка зачем-то вместо привычного символа / (ну, или уж \, на худой конец) зачем-то решил использовать ., т.е. точку. А зачем? Чтобы (такой же как он) программист взял, да и запутался, что ли? Что, нельзя было сделать хотя бы @extends('Layouts/app'), если уж приспичило делать сокращения?

Вообще-то, фреймворк, типа того, славится "выразительностью" кода. Да, какая же тут, к чёрту, выразительность? Если приходится постоянно вспоминать, что подобные вещи - всего-навсего сокращения. Краткость - это не всегда сестра таланта и выразительности. Нередко она - мать путаницы и бабушка разночтений/ошибок (и регулярно обнаруживаемые уязвимости во многих фреймворках этот мой вывод подтверждают). А то и - сообщница шулера. И - подруга уязвимостей.

Оно, конечно, вполне "можно" что-то делать на этом фреймворке и на чистом РНР. Да, теоретически - и в самом деле можно. Однако, так как концепция фреймворка при этом будет грубо нарушена, есть большая вероятность, что на каком-то этапе, когда уже будет проделана большая работа, он не то, что бы сломается, а как бы сказать... начнет работать не совсем так, как планировалось. И вот чтобы решить подобную проблему... придется, скорее всего, переписывать "оригинально сделанную" часть заново - так, чтобы она соответствовала концепции, заложенной в этот фреймворк его автором-разработчиком. И вот тогда-то(!!) владельцы сайтов/сервисов в панике начинают искать "программистов с прямыми руками". При этом такие заказчики начинают ОЧЕНЬ подозрительно относиться уже к ВСЕМ программистам... А то и - начинают даже бороться с ними, как это делает такой известный персонаж и "величайший менеджер всех времен и народов", как Г.О. Греф, к примеру.

Вообще, если у кого создалось впечатление обо мне, как о человеке, типа, "безрассудном" (раз, мол, против уколизации и современной медицины в целом), то это - от излишне узкого, ограниченного понимания. И - от недоразвития, неспособности понимать окружающих людей. НАОБОРОТ, я очень критично и осторожно отношусь к опасным нюансам, и в медицине, в области здоровья тоже. Скажем, если говорить об отношениях с женщиной... ну, это личное, разумеется. Могу сказать вслух тут, пожалуй, единственное. Скажем, раньше я замечал, что после смены общения, скажем так, даже... мой собственный ЗАПАХ менялся иногда (это специально для тех пишу, кто не в курсе, что такое взаимодействие между разными ДНК; поэтому...).

Впрочем, ладно, слегка дополню. Может, кто помоложе и только жизнь начинает - тому/той пригодится. ПОЭТОМУ: ежели иметь рядом партнера/партнершу, скажем так, из нехорошей серии (вне зависимости от возраста, привлекательности), то итог может быть, скажем так, не очень. Вплоть до "наследования" (или как правильнее сказать-то) всех заболеваний. Не только физических. В том числе и тех, коих пока еще, быть может, нет.

То же касается и работы с компьютером, в программировании. Если говорю о том, что протокол http, скажем, безопасен тогда-то и тогда-то - то четко знаю, о чем говорю и что делаю, и в каких именно случаях он - безопасен. А вот там, где не особо разбираюсь (например, в массовых нагромождениях фреймворков, этих зависимостях разных), а также там, где, напротив, ПОНИМАЮ, что в результате нагромождений сам же их разработчик вполне мог где-то там, в недрах своего кода, допустить кучу ошибок - вот там, бывает, побаиваюсь. И стараюсь применять что-то более простое, строгое и, одновременно, хорошо апробированное. Где поменьше разного рода вольностей и мнимой "простоты". И так, наверное, во всем.

Так в чем же пресловутое "удобство" сего фреймворка?

Неужели же в том и только в том, что там многие шаблонные вещи (типа формы авторизации пользователей или административной панели, например) делаются автоматически после набора (в консоли) нескольких команд? Да, но это - достаточно несложная процедура - сверстать форму авторизации и сделать для нее обработчики. А если хоть ОДИН РАЗ программист уже это делал - стало быть, у него уже есть наработки (заготовки) и тогда эта работа существенно ускорится. Тем более, что все остальное-то для этой формы все равно придется делать. Зато крайнее неудобство - в том, что приходится детально прослеживать, какой класс откуда наследуется, какой контроллер использует... И эта цепочка, как правило, не из одного-двух классов (и, соответственно, файлов, в которых эти классы прописаны), а поболее. Поэтому лгут те, кто утверждает, будто фреймворки "упрощают разработку, так как скрывают от программиста технические нюансы, давая возможность ему заниматься только логикой и реализацией непосредственно своего приложения". Да, это ложь. Потому что вместо "технических нюансов" программисту здесь придется заниматься этими самыми классами и следить, какой контроллер на каком классе основан и какому методу, основанному на каком классе, дальше передается управление; что затем прописать в Route, ну, и т.д. А ведь даже в "чистом" Laravel, когда там есть только страница index.php, уже присутствует в каталогах 2 с лишним тысяч(!) файлов.

Такая ложь может исходить, разве что, от новичков, которые, практически не зная языка РНР, в короткий срок создали сайт на фреймворке (Laravel).

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

Да, что-то простое/шаблонное сделать, и в самом деле, довольно просто. Это я убедился на собственном опыте. НО: как только пойдут нюансы (а она обязательно пойдут, как только понадобится что-то более, чем сайт с шаблонными возможностями), вот ТОГДА-то понадобятся как те самые технические нюансы, так и эти цепочки классов-методов. Т.е. разрабатывать будет даже сложнее, чем на чистом РНР.

Не говоря уж о том, что любой фреймворк (и Laravel - не исключение) дополнительно нагружает сервер, расходуя его ресурсы. Ну, сами посудите - в процессе обработки даже самого банального запроса к странице index.php принимает участие 50...70 файлов РНР. Кто не верит - выведите на экран стек вызовов. Так ради чего пресловутая "простота"? Ради первоначально, вроде бы, высокой скорости разработки, но потом (что закономерно) - ради увязания в этих цепочках классов/методов/... ? Уж не говоря о том, что на таком пути вполне легко занести на сайт какую-нибудь уязвимость.

В чем опасность Laravel и аналогичных технологий?

Как раз в том, что там – абстракция на абстракции. Множество мелких файликов, в которых, понятное дело, рано или поздно запутаешься. Если ты - не искусственный интеллект какой-нибудь. Что-то пропустишь, перепутаешь private и pubilc... И тогда… появляются уязвимости в программном коде. Собственно, совсем недавно, весной 2021 г. была обнаружена очередная уязвимость.

Причина ее (да-да, не следует заблуждаться!!) состоит в том, что разработчик этого фреймворка в очередной раз САМ запутался в им же созданных абстракциях, этих многочисленных наследованиях от класса к классу; в передачах вызовов от фасадов к хелперам, контроллерам и т.п. Это как раз то, что мне категорически неприятно и к чему я не прикасаюсь, если есть возможность. Да, разработчик сам запутался и забыл, что на очередном этапе стека запросов в сто-с-лишним-какой-то класс, который осуществляет запись некоего файла на жесткий диск, передаются данные… полученные из сети (из get- или из post-запроса).

Да, а вот еще уязвимость, это уже обнаружено в октябре 2023 г. Я о ней узнал из сообщений на Гитхабе, где она заявлялась как критическая. Так как там у меня есть простенький проект на Laravel, мне Гитхаб и прислал уведомление.

Правда, человек, который обнаружил ее и, насколько я понял, разработал соответствующий патч, утверждает, что, мол, ничего особенного. Цитирую: "This vulnerability predominantly impacts those integrating untrusted code with Babel. Unfortunately, this places individuals leveraging Babel for “static deobfuscation” directly in the crosshairs of this attack vector. There’s a touch of irony in the fact that my first credited CVE emerged from reverse engineering Babel - the very tool I often employ for reverse engineering JavaScript, and the topic of all of my previous posts".

Уязвимость обнаружена в Babel, это - нынче придумали, чтобы новые команды javascript работали в старых браузерах. Т.е. нынче народы (программистов-сайтостроителей имею в виду) работають-с примерно так. Вначале зачем-то используют новые команды JS, ну, а потом - применяют разные Бабели-полифилы... Это примерно как для того, чтобы просто взять, да и съездить на дачу по обычной дороге на расстояние 10 км, - вначале поехать в аэропорт, прилететь оттуда в другой город, а потом уже оттуда ехать на дачу на автомобиле. Почему бы сразу не писать кроссбраузерно и универсально? А не, нынче такое несовременно.

А я могу уверенно сказать, что реально полезного нового в языке JS, сделанного за последние лет 10, максимум, 5%. Остальное - это просто как бы обертки, "синтаксический сахар" (типа Coffescript или как там), т.е. для разнообразия и (нередко - сомнительного, ибо "избавляет" от строгости кода, провоцируя на безалаберность) удобства. Все эти стрелочные функции, троеточия и пр. Следует понимать, что это - просто перегружение синтаксиса (чтобы запутать разработчиков) и не более того.

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

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

Последний раз делал прививку - от бешенства, т.к. собака укусила. Это было лет 10 назад. А до этого прививки делались в младших классах средней школы, там родители меня не отговорили, а сам я еще не понимал их (прививок) пагубность. Даже тех, еще советских прививок. И всё. А что касается компьютерных дел - так вот как было установлено на компьютере почти 9 лет назад, после его покупки, так все и работает. Ну, кое-что добавлял (С УМОМ). А так - практически вообще никаких проблем, работает, да и всё. Пару раз переустанавливал браузер (24-й Firefox) и Denwer, и больше ничего не переустанавливал. Единственное - почему-то перестал функционировать режим гибернации. Что было очень удобно, но теперь - увы.

Собственно, я уже давно, как только в общих чертах ознакомился с ООП, с технологией работы фремворков, то сразу понял, что подобные уязвимости – увы, закономерные спутники их. Ну, устранит разработчик очередную уязвимость… так вполне может внести НОВУЮ. А сколько таких, которые уже давно эксплуатируются (хакерами), но о которых пока неизвестно широкой общественности?... Вот-вот.

Поэтому, конечно же, для себя я «это» (т.е. Laravel) использовать не буду. Ибо, мало того, что он – довольно тормозной (по сравнению с чистым РНР), так еще и небезопасный. Как, впрочем, практически все мало-мальски серьезные и объемные фреймворки. Для себя я буду делать на чистых языках, с многочисленными проверками, сообщениями об ошибках и т.д. Ну, а вот для заказчиков, которые согласны на применение Laravel (или т.п.) и если они достаточно смелые, понимают, на что идут – вот для них вполне можно его использовать, а также – если в будущем буду где-то работать в этом направлении, в команде, например. Ибо, что в Laravel и в самом деле удобно – так это то, что буквально в несколько строчек можно создавать более-менее полноценную функциональность.

Например, взять отсылку сообщений на сайт. У меня разработка этого заняла ранее, наверное, день. Это – минимум. А в Laravel это делается в течение 20 минут. Разница есть, да.

Или, скажем, взять базы данных. Понятно, что хранить в них информацию (а также сортировать ее, записи извлекать там и т.п.) - ни ума, ни большого опыта не надо: просто пиши себе SQL-запросы, и все будет работать. НО: в Laravel даже это делается еще проще, гораздо проще и короче. Если более-менее изучить синтаксис Laravel, то, реально, одна-две строчки - и запрос готов.

Я-то сам у себя нигде базы данных не использую. Вообще. Предпочитаю Linux-ский подход - хранить информацию в файлах. Потому как баз данных я реально (это без шуток) БОЮСЬ. Нет, не "сложности" работы с ними. А их уязвимости. Ну, да, ну, да, оно, конечно - можно запросы экранировать, тщательно продумывать - откуда и какие запросы, и т.д. Кстати, даже и здесь с Laravel все проще: он уже автоматически все экранирует (ну, так пишут, по крайней мере) и заботиться об этом нет необходимости.

Так что, получается, я боюсь СОВЕРШЕННО НЕ ТОГО, чего боятся масса народов. А чего многие боятся - я, наоборот, не боюсь:

Многие боятся этого своего долбаного "ковида" (и рассказывают "страшные" сказки друг другу, почерпнутые из телевидений, конечно же; а отчасти - от людей, неправильно понимающих бытие), а мне он, как бы сказать... Потому как я понимаю: ежели уж начнут зачищать население (в т.ч. и меня) по-настоящему, там уже НЕ КОВИД будет.
Немалая часть народов (но, хорошо хоть, что она - существенно меньше 30% населения!) НЕ боятся жижизации, а для меня она - хуже смерти. Ибо, во-первых, она вполне может сменить генотип человека (а тогда - привет болезнь под названием "рак" или протчая); да и даже с моральной стороны - ведь жижизироваться, это (для меня) означает почти что стать "петухом" (здесь я пользуюсь терминологией Ю.И. Мухина). Да, говорю как есть: уж лучше умереть, чем принять в себя сию навязываемую жижу. Полученную на основе (с использованием) клеток абортированных младенцев. Собственно, и понятно: потому-то(!)) ее и навязывают столь усиленно. На мой взгляд, чтобы потом навязывать уже несколько иное... Это же "окна овертона". Уж теперь-то, надеюсь, всем стало понятно. Вначале тряпочки на лица, потом укольчики, потом... Так что потом не удивляйтесь, ежели за ОТКАЗ, к примеру, от гомосексаулизма вас "вдруг" в тюрьмы начнут сажать или штрафовать. Ну, или, ето, трупы предложать кушать. Свежие или, того, несвежие. Непосредственно или, того, в переработанном виде. Ну, чтобы, оно, на кладбищах-то места не занимать. Надо же, мол, об обществе думать. И об экономике. А то, мол, врагов внешних и внутренних много. А "наука", специалисты - они все это (и не только это) "обоснуют", не волнуйтесь. Как только потребуется кое-кому. Если чё.
Достаточно многие народы смотрят (ага, да еще и, кстати, с увлечением!.......) свои лете-визоры. А я-то четко понимаю, что это - деградация, дерьмо, мерзость. Да еще если делать это по... своей(!!) воле.
Народы (ну, не все, но многие) стремятся ездить на иномарках, пусть и недорогих. А я в упор не понимаю - ЗАЧЕМ им это нужно. Ну, если только для понтов и/или если деньги некуда девать совсем. А как по мне - так я бы с удовольствием ездил на каком-нибудь ЗИЛ-131. Правда, на нем парковаться неудобно и в городе проедешь не везде. Да и расход бензина, скажем-с так... немалый. Другое дело - электромобили, конечно. Но, кстати, насчет последних: там есть немало, скажем так, существенных недостатков...
Многие народы (особенно в моем возрасте и старше) боятся физических нагрузок (или ленятся), "сильной" жары и т.п., а для меня это - обычный образ жизни; даже не представляю, как бы жил без этого.
Очень многие народы прожигают (ну, типа как выжигателем, ага) себе ЦНС и органы при помощи СВЧ-излучений от сотовых телефонов, вплотную прижав их к голове. Я тоже первые полгода-год так... делал, экспериментировал (да-да, было и такое, если честно). Потом быстро почувствовал: ежели продолжу сию практику - скоренько превращусь в доходяжку. Поэтому разговор по сотовому телефону для меня - только когда он на отдалении. Ну, за исключением неотложных ситуаций, конечно.
Народы (ну, немало таких) вполне себе используют базы данных для работы сайтов. А я их, этих баз данных, просто физически боюсь. Из-за уязвимостей. Ранее устраненных, имеющихся и возможных. Ну, примерно, как кирпичей, падающих с крыши на голову или выстрелов из пистолета в упор.
Я мог бы и продолжить, ну, да ладно. Не о том речь сейчас.

А когда с файлами - то для того, чтобы что-то там поменять (по обозначенным правилам), найти запись и т.п. - так это интерфейс самостоятельно требуется проектировать. Что я и делаю (точнее, сделал). Да, у меня там - то регулярные выражения, то PHP-DOM. Последний, увы, несколько недоработанный и, конечно, отстает от своего аналога в javascript. Поэтому там, где он не дотягивает, и применяю регулярные выражения. А разные XPATH и прочее - не использую. Говорят, что тормозное все это. Поэтому даже изучать не стал. Тормознутость для меня в данном случае - необходимое и достаточное условие, чтобы не использовать.

Правда, у меня-то сделано везде (как мне кажется) с тщательными проверками, протестировано вдоль и поперек. С МИНИМУМОМ используемых функций/процедур – хотя бы для того, чтобы самому в них не запутаться. Оптимизировано по скорости работы. Ну, а тут – либо придется лезть в недра фреймворка и изучать самостоятельно, чтобы удостовериться, что все работает правильно и безопасно (так, а тогда – какой смысл в его использовании-то? Ведь тогда проще все написать самому), либо – остается довериться авторитету разработчика. Да, что многие и делают.

Ну, это как с жижей под названием «вакцина».

Скрыть пояснение

Впрочем, нет. С жижей – ситуация гораздо глупее и ужаснее, конечно. Потому что сайт – это всего-навсего совокупность программных кодов. Их можно, если уж потребуется, восстановить, взяв из архивов. А здоровье – одно. И ежели после иглоукалывания в какой-нибудь подворотне – типа торгового центра, некоей уличной палатки - со здоровьем уколотого будет в итоге нечто «не то» - то тут можно будет лишь сказать на прощание: «увы, наверное, это - НАВСЕГДА». Да, здоровье – это не сайт, сделанный на Laravel. А уж когда со здоровьем производятся еще и генетические эксперименты – ну, тем более. Генетические сдвиги – их ведь не «откатишь» назад, не нажмешь кнопку «вернуть, как было до этого».

Впрочем, ежели часть народа легко (сама!!) подставляет себя под сии уколы – так разве же будет она думать о чем-то гораздо менее опасном – об уязвимостях сайтов, выполненных при помощи фреймворков? О, нет, конечно. Не будет. Нет, «такие», пожалуй, ни о чем не думают вообще. Ну, это мое мнение. Кто-то другой может считать совсем иначе.

Поэтому для сайта на Laravel я зарегистрировал еще один домен. Это будет сайт чисто для фреймрворковых экспериментов. Т.е. так - исключительно для аппробации фреймворков и чтобы глубже в них разобраться (для начала - в Laravel, а потом - посмотрим). Понятно, что ни для чего серьезного для себя там я делать не буду. Поэтому если вдруг и взломают или еще что - так и не особо жалко: просто все снесу и установлю заново. Кстати, разместил коды того (который сделан на Laravel) сайта в своем аккаунте на Github.com. Сайт, конечно, пока - достаточно простой. Кстати, если кому интересно поиспользовать эти коды - ради бога, feel free according GPL 3.0. Как минимум, это более-менее готовый простой работающий сайт. Начинающим может показаться полезным.

Ну, на всякий случай, имейте в виду, что некоторых файлов (типа .env) и каталогов (особенно, в vendor) там на Гитхабе, конечно, нет. Собственно, программа GitHubDesktop (я пользуюсь ею, а не Git) сама по умолчанию включает названия файлов, нежелательных для публичного публикования, в .gitignore.

С Git я не очень сработался. Вот локально-то он работает хорошо, проблем нет. И в связке с PHPStorm. А вот при попытке доступа на Github - просит почему-то установить .NET Framework версии то ли 3.4.*, то ли еще какой. Ну, а для нее требуется еще что-то там обновлять, ну, и т.д. На каком-то этапе система (в виртуальной машине, конечно) решительно отказалась от дальнейшего обновления, посему я решил использовать GitHubDesktop - с ним в этом плане проще, он, собственно, для Гитхаба и разработан - его же разработчиками.

Правда, честно говоря, с этим GitHubDesktop - примерно как со старым советским ламповым радиоприемником. Помнится, еще в 80...90-х годах, когда мы слушали "Голос Америки", "Радио Свобода" (да, куда же мы делись бы без Евгения Аронова и потом сменившего его Билла Скэндвича), "Би-би-си" (ну, так а какой же вечер без Севы Новгородцева-то...), "Немецкую волну", Пекин, Албанию, Северную Корею и ряд других радиостанций

вперемежку в КГБ-шными глушилками - их, кстати, тоже интересно было послушать (да, это примерно как сейчас - призывы к жижинации, к примеру: и там, и там - бессмысленные звуки типа булькания, свиста или блеяния, но забавно)

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

Так что мой вывод по поводу Laravel – такой:

Для себя – нет уж, ни в коем случае. Чтобы я потом, в случае чего, разбирался в разных недрах этих абстракций и стеков вызовов? Чтобы разные Бабели применял? Да еще – в условиях ограниченного времени, иной раз?? Нет уж, ни в жизнь. Не надо. А вот для других, если они согласны – ну, почему бы и нет. Вполне можно. Тем более, если сайт уже и так на фреймворке и большой - тогда переделка его на нечто иное будет равносильна, в некотором смысле, написанию заново.

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

С уважением, Салимоненко Д.А.