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

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

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

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

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

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

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

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

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

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

Ну, ладно. В общем, эта, «величайшая в мире» архитектура 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. Ладно, в итоге, еще через сколько-то дней и это тоже заработало.

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

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

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

Вообще, как по мне, так ПРОЩЕ(!) поднять сразу и единожды груз массой в 100 кг. Чем бегать 100 раз с грузами по 1 кг каждый. Увы, Laravel предлагает именно второй вариант.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому, конечно же, для себя я «это» (т.е. 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 руб. каждая. Понятно, что это - или в конструкторе каком-нибудь, или путем автоматической генерации. Понятно, что качество таких страниц будет, скорее всего, очень не очень. И, скорее всего, заказчик это отлично понимал. Просто ему, видимо, для какой-то цели потребовалась масса страниц, хоть как-то работающих.

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