Я говорю о проектах с нормальным бюджетом, где php-шники получают как минимум не меньше коллег c других языков. Такие проекты исчезают. За последних пару лет их количество сократилось в разы, отделы php начали сокращать и переучивать на javascript ± node.
p.s. У меня информация о Минских компаниях, который в основном работают на запад. «Диджитал» и Битрикс конторы с дешёвой и некачественной рабочей силой я не считаю.
PHP всё же умирает.
С новыми фичами мы лишились конкурентного преимущества — быстро и дешево. С фреймворками вроде Zend и Symfony и заморочками с типизацией время и объёмы кода стали сравнимы с Java и C#, в которых данные фичи существуют давно и реализованы не так костыльно как в PHP. И пока мы изобретаем гибернейт и играем во взрослый язык, конкуренты наоборот становятся проще и более дружественными к вебу.
А на рынке «быстро и дешево» позиции заняли nodejs и go, на подходе kotlin. Спасает ещё популярность laravel, но уровень разработчиков там печален.
Практически в любом проекте можно найти кучу проблем, спешки и костылей, но они не потонули, а некоторые даже приуспели. Легко постфактум указывать на ошибки.
У этого корабля есть другой смысл. Этот корабль символ конца эпохи имперских амбиций шведов, проиграв в той войне они сосредоточились на внутренних проблемах, а не завоеваниях Крымов, сейчас Швеция одна из лучших стран по уровню жизни при том что климатические условия далёкие от идеалов.
Если вы в своей команде будете уделять досточно времени на обучение, оптимизацию и качество процессов, то вам не помешают ни сроки, ни изменения требований. В реальной жизни не бывает идеальных условий.
Я согласен, что стандарт — хорошо. Ещё одно стандартное апи помимо ресурсооринтированного это здорово, лучше, чем изобретать самому декораторы. Но это не делает его не REST-ом, например можно использовать прокси-кэш.
Да, для REST есть ограничения, чтобы считаться RESTful, но среди них нет ничего про заголовки, урлы и т.д., что является лишь одной из реализаций, но не обязательным условием. Да и заголовков, урлы — это протокол передачи данных, это HTTP нужны метод, ури, заголовки… Вместо http может быть другой протокол, это одно из требований слоёностии REST.
Уже не раз сталкивался с этой проблемой, разработчики не знают что такое REST и из-за этого делают уродливые апи с кучей лишних вызовов.
REST — это архитектура предпологающая клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про вербальность GET-PUT-DELETE… как думают многие и откуда растёт миф:
Пользоваться старой REST-моделью это как заказывать пиццу, затем заказывать доставку продуктов, а затем звонить в химчистку, чтобы забрать одежду. Три магазина – три телефонных звонка.
REST не запрещает тебе сделать метод POST /doMagic {pizza: {}, address: {}, tea: {}}, и если ты пошлёшь все необходимые данные, то он закажет пиццу, доставку и включит чайник. Отличие от классического подхода то, что ты не установил адрес доставки при регистрации пользователя, а при запросе взял его сс сервера, а отправляешь его явно на /doMagic в виде сырых данных либо идентификатора по которых его можно получить из стораджа (вреде userId).
Это к тому, что GraphQL тоже является REST подходом, просто у него апи не VERB resource/:id и вам никто не мешает делать такое апи. Например мы, посылаем декораторы, чтобы сказать какие поля получить
GET /user/:id?decorators=name,address,comments.count.
Не придумывайте себе исскуственных ограничений, которые не описаны в настоящем REST.
Уже не раз сталкивался с этой проблемой, разработчики не знают что такое REST и из-за этого делают уродливые апи с кучей лишних вызовов.
REST — это архитектура предпологающая клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про вербальность GET-PUT-DELETE… как думают многие и откуда растёт миф:
Пользоваться старой REST-моделью это как заказывать пиццу, затем заказывать доставку продуктов, а затем звонить в химчистку, чтобы забрать одежду. Три магазина – три телефонных звонка.
REST не запрещает тебе сделать метод POST /doMagic {pizza: {}, address: {}, tea: {}}, и если ты пошлёшь все необходимые данные, то он закажет пиццу, доставку и включит чайник. Отличие от классического подхода то, что ты не установил адрес доставки при регистрации пользователя, а при запросе взял его сс сервера, а отправляешь его явно на /doMagic в виде сырых данных либо идентификатора по которых его можно получить из стораджа (вреде userId).
Это к тому, что GraphQL тоже является REST подходом, просто у него апи не VERB resource/:id и вам никто не мешает делать такое апи. Например мы, посылаем декораторы, чтобы сказать какие поля получить
GET /user/:id?decorators=name,address,comments.count. Не придумывайте себе исскуственных ограничений, которые не описаны в настоящем REST.
Да не проходило ничего мимо. Ещё во времена php4 все провали ddd и прочие технологии с java-asp, потому что литература по архитектуре была исключительно для этих языков. С тех пор появились более удобные инструменты как в самом языке, так и в сторонних библиотеках. Сейчас очередная волна, которая загнала язык в могилу, так как мы утратили преимущества — быстро, дешево, легкое в поддержке и маштабировании. Мы пришли на территории java-.net, с куда более ущербным языков в плане ООП.
Мы спорили о том, что DDD убьёт PHP ещё во время бет symfony 2, с тех пор практически все перешли к javascript или devops. При этом в большом мире начали уходить от энтерпрайзщины и спрингов, появился котлин.
В этом и весь ад DDD, у каждого своё понимание, кто чего понахватался из большой синей книги, а то и вовсе из статей в интернете. Я пока не видел ни одного нормального проекта с DDD, который было бы легко поддерживать и расширять, потому отношу его к антипаттернам. И отсутствие интруменов для DDD ставлю в плюс Laravel.
Доработка сетапа нужна везде, но именно в laravel и yii она требуется меньше, так как фреймворк из коробки содержит кучу приятныхз фишек, о чём собственно и статья. Когда ты садишься работать за симфони после ларочки, то чувствует себя вообще голым, разве что визитки с таким сетапом разрабатывать, нет очередей, редиса и т.д.
Про DDD и гексогоналку. Мне казалось, что суть этих технологий как раз в отсутствии привязки к стораджам и всяким eloquent или doctrine. Мне кажется вторая даже вреднее, так как люди тешат себя иллюзией о правильной архитектуре, а по сути вместо спагетти кода пишут лазанью.
Про документацию вы правы, там примеры демонстрируют ТОЛЬКО конкретный инструмент и не связаны друг с другом. Но так везде, в доке по php даже есть приписка про этот момент. Но есть laracast демонстрирующий хорошие практики. В доке был ещё пример полноценного приложения, но его найти не могу.
Ну а в остальном ваши придирки субьективны и зависят от разработчика. У меня за спиной десяток проектов с laravel и пяток с symfony, в ларавеле ниже порог входа и куча говнокода от авторов не осилевших доку до конца, в симфони же беспощадная слоёная архитектура от авторов не осилевших php и в поддержке они на порядок сложнее, даже хуже битрикса.
Если не заморачиваться и отвечать время от времени, то это прекрасный результат. Как любят писать эйчары — этого достаточно, чтобы войти в 5% лучших пользователей ресурса, да и количество ответов на первый взгляд заставляет думать, что чел в чём-то шарит.
Я не против того, чтобы ответить самому можно было, но эти ответы не должны учитываться в рейтинге пользователей. Тем более ответы у него не верные и будут только путать других пользователей ресурса, которые не проверят кто задавал и кто отвечал на вопрос.
Лучше бы тостер починили, а то там рейтинг легко обузится, т.к. авторы вопросов могут сами же себе отвечать и выбирать ответ как верный. Вот яркий пример о я чём писал в саппорт пол года назад https://toster.ru/user/BonBonSlick/answers
Да и с хабром та же ерунда, комментируешь, получаешь плюсы, а какая-то обидчивая гадость сливает тебе карму, портя рейтинг.
Очень необъективные рейтинги, чтобы включать их в резюме.
Я в начальном комментарии указал пару проблем, но вся статья хреновая, а главное вредная.
Именно потому, я не хочу делиться опытом, потому что мои советы тоже могут быть вредными за пределами контекста. Надо опираться на серьёзную литературу, где рассмотрена куча разных кейсов, она не раз уже упоминалась.
К тому же в php есть готовые решения вроде doctrine-propel, которые значительно лучше поделки автора, который даже php знает с оговорками.
Да почитайте вы их, там есть реализации с кодом, плюс в посте выше я писал о Нильссоне, у него практики ещё больше. Но вы даже с терминами не разобрались, а пытаетесь делиться «опытом».
Карнеги хорош, кода хочешь навешать лапши на уши. Здесь же профессиональный ресурс, где люди обмениваются знаниями и опытом, а не заводят новых друзей. В отношении вас я умышленно применил агрессию и троллинг, дабы заставить вас усомниться и освежить знания.
Зачем писать? Есть книги Эвайнса и Фаулера и куча статей от этих же авторов — это райт вэй. Надо их внимательной читать, а не набравшись по вершка и статьям лепить свои велосипеды.
Почему удалась? Статья ужасная и вредная для прочтения. Не дай о кто-то прочтёт, не дойдёт до комментариев и будет это воспринимать как райт вэй. Автору надо подучить сам php, а затем перечитать книги на который он ссылался и почитать какого-нибудь Нильссона, чтобы увидеть практическую реализацию.
У вас всё плохо, очень плохо.
DDD вы не понимаете.
Enity — хрень с защищёнными свойствами в массиве, магическим __call и даже сеттер для айди работает с неявным поведением $this->id = $this->id == 0? $id: $this->id;
Репозиторий который не репозиторий, в котором мэппер, который почему-то не мэпит, а персистит данные.
Контекст непонятная штука, чей контракт зафиксирован в виде абстрактноо класса и не предполагает нормальную инъекцию зависимостей.
Ну и это первая половина проблемы. Вы не знаете синтаксиса php и работаете с отключёнными ошибками вроде E_NOTICE, E_DEPRECATED, потому принимаете объекты по ссылке. Даже оформление кода не по PSR и вооще пахнет временами php 4.
p.s. У меня информация о Минских компаниях, который в основном работают на запад. «Диджитал» и Битрикс конторы с дешёвой и некачественной рабочей силой я не считаю.
С новыми фичами мы лишились конкурентного преимущества — быстро и дешево. С фреймворками вроде Zend и Symfony и заморочками с типизацией время и объёмы кода стали сравнимы с Java и C#, в которых данные фичи существуют давно и реализованы не так костыльно как в PHP. И пока мы изобретаем гибернейт и играем во взрослый язык, конкуренты наоборот становятся проще и более дружественными к вебу.
А на рынке «быстро и дешево» позиции заняли nodejs и go, на подходе kotlin. Спасает ещё популярность laravel, но уровень разработчиков там печален.
У этого корабля есть другой смысл. Этот корабль символ конца эпохи имперских амбиций шведов, проиграв в той войне они сосредоточились на внутренних проблемах, а не завоеваниях Крымов, сейчас Швеция одна из лучших стран по уровню жизни при том что климатические условия далёкие от идеалов.
Если вы в своей команде будете уделять досточно времени на обучение, оптимизацию и качество процессов, то вам не помешают ни сроки, ни изменения требований. В реальной жизни не бывает идеальных условий.
REST — это архитектура предпологающая клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про вербальность GET-PUT-DELETE… как думают многие и откуда растёт миф:
Пользоваться старой REST-моделью это как заказывать пиццу, затем заказывать доставку продуктов, а затем звонить в химчистку, чтобы забрать одежду. Три магазина – три телефонных звонка.
REST не запрещает тебе сделать метод POST /doMagic {pizza: {}, address: {}, tea: {}}, и если ты пошлёшь все необходимые данные, то он закажет пиццу, доставку и включит чайник. Отличие от классического подхода то, что ты не установил адрес доставки при регистрации пользователя, а при запросе взял его сс сервера, а отправляешь его явно на /doMagic в виде сырых данных либо идентификатора по которых его можно получить из стораджа (вреде userId).
Это к тому, что GraphQL тоже является REST подходом, просто у него апи не VERB resource/:id и вам никто не мешает делать такое апи. Например мы, посылаем декораторы, чтобы сказать какие поля получить
GET /user/:id?decorators=name,address,comments.count.
Не придумывайте себе исскуственных ограничений, которые не описаны в настоящем REST.
REST — это архитектура предпологающая клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про вербальность GET-PUT-DELETE… как думают многие и откуда растёт миф:
REST не запрещает тебе сделать метод POST /doMagic {pizza: {}, address: {}, tea: {}}, и если ты пошлёшь все необходимые данные, то он закажет пиццу, доставку и включит чайник. Отличие от классического подхода то, что ты не установил адрес доставки при регистрации пользователя, а при запросе взял его сс сервера, а отправляешь его явно на /doMagic в виде сырых данных либо идентификатора по которых его можно получить из стораджа (вреде userId).
Это к тому, что GraphQL тоже является REST подходом, просто у него апи не VERB resource/:id и вам никто не мешает делать такое апи. Например мы, посылаем декораторы, чтобы сказать какие поля получить
GET /user/:id?decorators=name,address,comments.count. Не придумывайте себе исскуственных ограничений, которые не описаны в настоящем REST.
Мы спорили о том, что DDD убьёт PHP ещё во время бет symfony 2, с тех пор практически все перешли к javascript или devops. При этом в большом мире начали уходить от энтерпрайзщины и спрингов, появился котлин.
Про DDD и гексогоналку. Мне казалось, что суть этих технологий как раз в отсутствии привязки к стораджам и всяким eloquent или doctrine. Мне кажется вторая даже вреднее, так как люди тешат себя иллюзией о правильной архитектуре, а по сути вместо спагетти кода пишут лазанью.
Про документацию вы правы, там примеры демонстрируют ТОЛЬКО конкретный инструмент и не связаны друг с другом. Но так везде, в доке по php даже есть приписка про этот момент. Но есть laracast демонстрирующий хорошие практики. В доке был ещё пример полноценного приложения, но его найти не могу.
Ну а в остальном ваши придирки субьективны и зависят от разработчика. У меня за спиной десяток проектов с laravel и пяток с symfony, в ларавеле ниже порог входа и куча говнокода от авторов не осилевших доку до конца, в симфони же беспощадная слоёная архитектура от авторов не осилевших php и в поддержке они на порядок сложнее, даже хуже битрикса.
Я не против того, чтобы ответить самому можно было, но эти ответы не должны учитываться в рейтинге пользователей. Тем более ответы у него не верные и будут только путать других пользователей ресурса, которые не проверят кто задавал и кто отвечал на вопрос.
Да и с хабром та же ерунда, комментируешь, получаешь плюсы, а какая-то обидчивая гадость сливает тебе карму, портя рейтинг.
Очень необъективные рейтинги, чтобы включать их в резюме.
Не раз работал и работаю с женщинами-программистами, не замечал никакой зависимости между полом и кодом.
Именно потому, я не хочу делиться опытом, потому что мои советы тоже могут быть вредными за пределами контекста. Надо опираться на серьёзную литературу, где рассмотрена куча разных кейсов, она не раз уже упоминалась.
К тому же в php есть готовые решения вроде doctrine-propel, которые значительно лучше поделки автора, который даже php знает с оговорками.
Карнеги хорош, кода хочешь навешать лапши на уши. Здесь же профессиональный ресурс, где люди обмениваются знаниями и опытом, а не заводят новых друзей. В отношении вас я умышленно применил агрессию и троллинг, дабы заставить вас усомниться и освежить знания.
DDD вы не понимаете.
Enity — хрень с защищёнными свойствами в массиве, магическим __call и даже сеттер для айди работает с неявным поведением $this->id = $this->id == 0? $id: $this->id;
Репозиторий который не репозиторий, в котором мэппер, который почему-то не мэпит, а персистит данные.
Контекст непонятная штука, чей контракт зафиксирован в виде абстрактноо класса и не предполагает нормальную инъекцию зависимостей.
Ну и это первая половина проблемы. Вы не знаете синтаксиса php и работаете с отключёнными ошибками вроде E_NOTICE, E_DEPRECATED, потому принимаете объекты по ссылке. Даже оформление кода не по PSR и вооще пахнет временами php 4.
И ещё куча ног торчит из стога.