AmdY AmdY

Знаете какой самый популярный вопрос по тегу laravel в местном тостере? Про неймспейсы, люди не понимают почему у них не работает как в примерах Foo::bar();

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

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

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

Да сcc..., странные результаты.
Вот сравнение за 5 лет php, nodejs и javascript trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F060kv,%2Fm%2F0bbxf89,%2Fm%2F02p97
Популярность php уходит и его вытесняют другие языки.
Но даже это не важно, беспокоят именно хорошие проекты с хорошей оплатой, их стало значительно меньше.

Понятное дело, что умирать он будет долго, вон даже Fortran, COBOL до сих пор используются в проде. Но с новыми проектами с нормальными бюджетами уже туго, это сильно бросается в глаза.
Даже простая проверка трендов это демонстрирует. trends.google.com/trends/explore?date=all&q=%2Fm%2F060kv

Я говорю о проектах с нормальным бюджетом, где 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.

И ещё куча ног торчит из стога.

Ссылка на этот вопрос ходит как мем и имеет мало общего с количеством людей реально застрявших в виме.

Интересует будущее Vue, где можно почитать о планах? За последние годы я переел этих тайпскриптов, флоу, вебпаков и *-cli. Сейчас в отпуске свой пет проект начал писать на первом angular, без всяких обвесок и вдруг вспомнил, что люблю программирование.
Vue выглядит как неплохая альтернатива angular1, да и схожесть упрощает освоение, но она же пугает, как бы авторы не пошли по тому же пути c предпроцессорами, типизацией и функциональщиной.

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

>> $components = $this->components();
Ну почему не заюзать нормальный DI с явной инъекцией нужных объектов, а не таскать каштаны голой рукой из огня.

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

Важно ни его наличие в коде, а наличие в документации. Вот пример из неё

The share method has been removed from the container. This was a legacy method that has not been documented in several years. https://laravel.com/docs/5.4/upgrade#upgrade-5.4.0

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

Видимо вы об этом

Сейчас и для angular 2 есть NativeScript http://docs.nativescript.org/angular/start/introduction.html

Основные изменения произошли в инфраструктуре и головах разработчиков, которые начали этой инфраструктурой пользоваться. Ускорили производительность, улучшили синтаксис, много изменений внутри, но ничего принципиально нового, что бы вывело язык на новый уровень не случилось. А вот то, что начали пользоваться компосером и фреймворками сильно всё поменяло, хотя ещё и во времена php4 были pear, pecl, seagull, cakephp и т.д.

Очень хотелось бы чтобы улучшилась асинхронность, многопоточность, появился loop, библиотеки стали неблокирующими, но глядя на костыли с какими добавляются новые фичи, думаю продолжу при надобности подтыкать проект на других языках nodejs, go. Может и не надо делать универсальный инструмент.

Неужели так важно знать каким to do менеджером и какой читалкой пользуется человек, если он сам работает по 10-15 часов, ещё и других уговаривает?
Почему бы не учиться эффективной работе у тех, справляется своими делали в рабочее время и никого не должен уговаривать поработать.

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

Ну что за гадкая привычка молча лепить минус и портить карму, отпишитесь хоть почему. Я же привёл аргументированную точку зрения, если надо ещё докину аргументов и ссылок.

Какой-то бред, зачем-то приплели сюда facebook, хотя этим самым hiphop никто не пользуется, сообщество ускоряет язык и без мордокниги. Nodejs и Go концептуально другие языки, а не замена ruby, копаться в асинхронных запросах то ещё удовольствие.
Ну и самое важное, что он рассматривает язык с точки зрения нагрузки(он стал третьим по посещаемость сайтом на Rails), а этот кейс далеко не критичен для большинства проектов, тем более узкие места всегда можно затюнить.

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

Нет, он совсем не про то. Даже если вы просто копируете объект через assign, то получаете его уже мутированную копию
>> Метод Object.assign() копирует из исходных объектов в целевой объект только перечисляемые и собственные свойства. Он использует внутренний метод [[Get]] на исходных объектах и внутренний метод [[Put]] на целевом объекте, так что он также вызывает геттеры и сеттеры.

Во вторых, если у объекта есть вложенные объекты и вы их меняете, то мутирует и исходный объект.

Object.assign не имеет отношение к иммутабельности, он копирует объекты, да ещё по своим витиеватым правилам, советую быть очень осторожным с ним. https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Object/assign