Посоветуйте как выучить PHP новичку в программировании

На ларавел довольно давно работаю. Симфони сейчас въезжаю - возможно, будет проект на нём.

Пока ларавел выглядит как довольно сильное решение в том числе для больших проектов. А что подходит лучше него?

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

 

С ларавел не работал, краем глаза смотрю код фреймворка. Ощущение, что ларавел - обёртка над основными компонентами симфони, но со своей ORM, и без аннотаций, как я понял... и свой очередной шаблонизатор, чем twig не угодил, непонятно...

@E13, в ларавел есть админка? Или надо со стороны ставить? А то в симфони есть соната, но с ней порой тяжко на нестандартных задачах.

 

Мне пока сложно сравнивать, я только начал копать симфони (делаем ресёрч, смотрим разные фреймворки, чтобы решить, с каким продолжить). Симфони используется в составе ларавел, насколько я вижу - код может быть довольно похожим. Но вроде бы ларавел поудобнее в плане разработки.

Встроенной админки нет, есть разные решения, как платные (Nova от разработчиков ларавел), так и бесплатные (включая попытку запилить типа-вордпресс поверх ларавел)

Я обычно свою админку пилю. Беру готовый шаблон с bootstrapdash, vue (ларавел его продвигает как базовое фронтенд-решение), какие-то ранее напиленные фрагменты кода, и из них собираю, что нужно

 

С моей точки зрения Ларавел сильно ориентирован на новичков и на нормальный уровень вхождения, но работа с ним на чем-то длительном - это боль.
В частности Eloquent использован антипаттерн ActiveRecord, который начисто нарушает SRP и представляет из себя мешанину из 6 слоев в одном классе.
Да, можно выбросить Eloquent (я субъективно оцениваю его качество как сильно попахивающее экскрементами)и подключить Doctrine, но не удобнее ли тогда сразу взять Symfony?

Я не понял, но os.environ.get делает то же самое. Есть и dotenv пакет, который из файла прочитать может, но это уже не популярно ввиду контейнеров.

Имеется ввиду pip? Он не альтернатива композеру, это низкоуровневая утилита. Альтернативы - poetry и pipenv.

Можно и всегда одной, через докер.

В симфони есть EasyAdmin, он субъективно лучше сонаты. Но в любом случае если нужна гибкость. то админка делается отдельно, фронтенд в отдельном проекте на JS.

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

Для чего-то "на коленке" - да, удобнее. Особенно если это потом не поддерживать. Но для длительных проектов (я работал на проекте на 100+ человеколет на симфони) ларавел абсолютно не подходит, либо его придется сильно кастомизировать и превращать в симфони.

 

Хм, а в доках они его ORM-ом называют. Маппер, как в доктрине, должен развязывать классы сущностей от слоя хранения. В Equalent сущеность - это модель, класс которой является наследником Illuminate\Database\Eloquent\Model, что попахивает AR-ом...

laravel/framework ну да, это active record

 

Это как раз то, чем недавно занимались Прикручивали доктрину. Я пока симфони смотрю. Возможно, как раз на ней проект и будет. По крайней мере, многие ему симпатизируют.

Я тут пока не сильно далеко ушёл - пилю свои первые проекты. Из коробки джангу немного муторно деплоить, особенно если смотреть в сторону автоматизации. Дополнительные фишки экосистемы пока не изучал.

Ага, он. Спасибо, поизучаю.

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

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

 

Так и есть - AR - частный случай ORM. Есть две популярных реализации ORM: Active Record и Data Mapper. Первый простой, второй нормально работает.

На само деле одинаково. Советую смотреть на правила 12 факторов и начать использовать докер.

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

 

Вас интересно читать

Окей

На последнем проекте было два варианта - вагрант и докер. Докер я запустить сходу не смог, хотя поддерживал проекты с ним и худо-бедно работать научился. Особенно радует, когда не заводится нджинкс из-за разных соглашений на конец строки в разных ОС (не знаю, насколько распространена проблема, но сталкивался с ней несколько раз). Вагрант заработал сразу, при том, что я впервые его увидел. Но вроде вагрант теряет актуальность.

 

Точно, ORM с Data Mapper спутал.

С 2016 года на докере для локальной разработки. Пишется docker-compose конфиг и вся инфраструктура поднимается одной командой, в конце дня останавливаешь, на след. день стартуешь конфигурацию. БД и логи на хосте хранить.
Существенными плюсами для меня были в момент перехода на него - это возможность запуска локально нескольких развесистых проектов и отсутствие на рабочей машине (хосте) серверного ПО, различных версий php и тп. Единственное - гит желательно на хосте иметь, чтобы не проксировать его вызовы в контейнер с разрабатываемым приложением, где смонтирован каталог с исходниками. Работу с консолью в контейнере (запуск команд миграций, композера, ...) организую посредством make, в Makefile пишу нужные для работы длинные команды, и на хосте уже имею make migrate, make update, make clear и т.д. и т.п.

 

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

 

А кто из профи Codeigniter 4 смотрел? Не в качестве противостояния монстрам, а по допиленности и юзабельности?

 

Я смотрел: это мусор.

 

А более развернуто можно пояснить?

 

Могу.

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

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

 

Кстати, а можете рассказать подробнее? Go начинал смотреть, показался мне таким Си под мухоморами. К задачкам сходу никаким не прицепился и был отложен в сторону до поры. Как его обычно с PHP используют?

 

gRPC сервер (тот ещё геморой, когда клиент на php), обработчик сообщений очереди, консольная утилита какая-нибудь специфическая и т.д.

 

Да, я куда-то сюда же думал. Тут правда подумывал питон использовать

 

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

 

Легковесные фоновые задачи,критичные к отклику времени, сервисы с состоянием.
А для вебсокетов и вовсе идеально. Для всяких перекладываний сообщений из очереди в сервис или куда-то еще.
В общем, всякие микросервисы с малым количеством бизнес-логики. А вот с бизнес-логикой дружит плохо.
Еще раз скажу, что он не пересекается с ПХП по выполняемым задачам, а дополняет его.

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

 

Понял, спасибо

 

У... 6 страниц. Думал зайти в тему поумничать, а тут 6 страниц))) Красавцы! Надеюсь вы зарабатываете так же или лучше чем комментируете. PS: Тему не читал. Увидел 6 страниц и понял что не надо)))

 

"—Ты слышал, Изя? Этот поц таки собирается учить нас коммерции!"(с)

 

ну так как выучить ?

 

У меня в институте на одном из предметов был php, пришлось учить... Денвер на флешке... эх, были времена.

 

Таки дошли руки немного уточнить.
(Обозначу сразу: мне рынок до лампочки, я уже старенький, в потогонный говнокодинг не собираюсь. )

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

Баксы, шмаксы... Мня лично привлекли легковесность и отсутствие многоэтажных абстракций. Тогда же посмотрел на Laravel, Yii; прочие зенды с симфониями даже щупать не стал — стояла практическая задача наваять некий сервис, для которого возможностей этих мостров слишком много, вникать в специфику долго, сложно, трудоемко (ввиду неопытности по наворачиванию абстракций над абстракциями), но на чистом пхп уже тоже удручающе многабукаф.

Тут хотелось бы пояснений.

Гм... Нагуглил упоминания этой НЕХ только на дваче, и как-то насторожился.

Опять же, там, где в CI4 предлагаются массивы, обычно предлагаются и объекты (или без указаний применимы), как альтернатива. Кому где как удобнее. Вы же не идейный массивоненавистник, надеюсь?

SQL-запрос есть строка, что такого ужасного в возможности компиляции строки из кусочков? Никто не запрещает прикрутить какую-нибудь доктрину или еще что. Для базовых CRUD операций всё есть искаропки.

Можно пояснить на пальцах, в чем конкретно оно выражается, и в чем его ужас?

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

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

В 3-й версии руководство по кодстайлу как бы есть. Но 3-ю версию делали другие люди. А в четвертой версии таки да, не вижу доки.

***
Чисто для понимания моего отношения к сабжу.
Я когда-то выбрал CI3 для своих поделок по причине легковесности и низкому порогу вхождения. Он дал мне кучу экономии на бойлерплейтах и в то же время не заставлял углубляться в осваивание высоких (многослойных) ООП абстракций, который никак не экономили мое время и силы на короткой дистанции, а вовсе даже наоборот.
Теперь, очевидно, надо переползать на CI4, ибо php7.4, плавно переходящий в 8.0, и все такое.
Мне не нужно конкурировать с джуномидлосеньйорами, я вообще в перпендикулярной нише.

 

В ужасно высокой вероятности SQL Injection... особенно у тех, кто задаёт такие вопросы.

 

Вы точно не путаете с компиляцией запроса из сырых входных данных?
То, что вы CodeIgniter в глаза не видели, я даже не сомневаюсь.
Я, собственно, не очень понял, что уважаемый @Winged имел в виду под кусочками.
Предположительно Query Builder Class, но это не точно.

Лет 10 назад приходите, тогда да.

 

Ларавел мне нравится. Всё очень логично и без лишних конструкций. Простой проект - это один контроллер, один файл с роутингом, несколько вьюшек. Разве что да, не легковесный он. Хотя есть Lumen ещё. С ним не разбирался пока, но вроде это чистое ядро Ларавел без всяких лишних обвязок.

Yii и CI тупо не вижу смысла смотреть после этого. Пока разбирался с API страйпа, ещё пощупал Slim. Показался мне довольно неплохим решением для мелких проектов, но - с отвратительной обратной совместимостью. Наверное, следующий мелкопроект на пыхе попробую сделать с Люменом всё-таки.

Сейчас вот проект на Симфони нужно будет делать - посмотрю, что там за легенда мира пхп.

Ютуб, "Урок Фауста", время 29:22

 

Э-э... Разве это не к любому фреймворку относится?

Ну уж не как битрикс.

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

 

Качество задач обычно соответствует качеству инструмента.

Вникать быстрее, чем велосипедить. На порядки.
Но Ларавел как раз примитивен. В отличие от Симфони.

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

Использование ключей ассоциативных массивов вместо объектов, когда список ключей заранее определен. Более того, для разнотипных значений.

Уровень склейки должен находиться сильно ниже.
Более того, меня возмутил пример на сайте, в котором не использовали подстановку через плейсхолдеры для значений. Это недопустимо даже для уровня джуна. Я удивлен увидеть код с подходом, который позволяет сделать банальную инъекцию в 2021 году.

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

В этом и дело. А я работаю профессионально, и код должен соответствовать некоторым критериям качества

Я считаю, что плохие комментарии значительно хуже, чем их отсутствие. Хорошие комментарии редки, и они объясняют причину, часто являются ссылками на внутреннюю документацию проекта.
Более того, обильная документация часто оказывается устаревшей и мешает восприятию.

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