• 0
    Я согласен, что стандарт — хорошо. Ещё одно стандартное апи помимо ресурсооринтированного это здорово, лучше, чем изобретать самому декораторы. Но это не делает его не REST-ом, например можно использовать прокси-кэш.
    Что же такое этот GraphQL?
  • 0
    Да, для REST есть ограничения, чтобы считаться RESTful, но среди них нет ничего про заголовки, урлы и т.д., что является лишь одной из реализаций, но не обязательным условием. Да и заголовков, урлы — это протокол передачи данных, это HTTP нужны метод, ури, заголовки… Вместо http может быть другой протокол, это одно из требований слоёностии REST.
    Что же такое этот GraphQL?
  • +3
    Уже не раз сталкивался с этой проблемой, разработчики не знают что такое 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 и GraphQL
  • 0
    Уже не раз сталкивался с этой проблемой, разработчики не знают что такое 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.

    Что же такое этот GraphQL?
  • 0
    Да не проходило ничего мимо. Ещё во времена php4 все провали ddd и прочие технологии с java-asp, потому что литература по архитектуре была исключительно для этих языков. С тех пор появились более удобные инструменты как в самом языке, так и в сторонних библиотеках. Сейчас очередная волна, которая загнала язык в могилу, так как мы утратили преимущества — быстро, дешево, легкое в поддержке и маштабировании. Мы пришли на территории java-.net, с куда более ущербным языков в плане ООП.
    Мы спорили о том, что DDD убьёт PHP ещё во время бет symfony 2, с тех пор практически все перешли к javascript или devops. При этом в большом мире начали уходить от энтерпрайзщины и спрингов, появился котлин.
    Laravel — экосистема, а не просто PHP-фреймворк
  • 0
    В этом и весь ад DDD, у каждого своё понимание, кто чего понахватался из большой синей книги, а то и вовсе из статей в интернете. Я пока не видел ни одного нормального проекта с DDD, который было бы легко поддерживать и расширять, потому отношу его к антипаттернам. И отсутствие интруменов для DDD ставлю в плюс Laravel.
    Laravel — экосистема, а не просто PHP-фреймворк
  • –1
    Доработка сетапа нужна везде, но именно в laravel и yii она требуется меньше, так как фреймворк из коробки содержит кучу приятныхз фишек, о чём собственно и статья. Когда ты садишься работать за симфони после ларочки, то чувствует себя вообще голым, разве что визитки с таким сетапом разрабатывать, нет очередей, редиса и т.д.

    Про DDD и гексогоналку. Мне казалось, что суть этих технологий как раз в отсутствии привязки к стораджам и всяким eloquent или doctrine. Мне кажется вторая даже вреднее, так как люди тешат себя иллюзией о правильной архитектуре, а по сути вместо спагетти кода пишут лазанью.

    Про документацию вы правы, там примеры демонстрируют ТОЛЬКО конкретный инструмент и не связаны друг с другом. Но так везде, в доке по php даже есть приписка про этот момент. Но есть laracast демонстрирующий хорошие практики. В доке был ещё пример полноценного приложения, но его найти не могу.

    Ну а в остальном ваши придирки субьективны и зависят от разработчика. У меня за спиной десяток проектов с laravel и пяток с symfony, в ларавеле ниже порог входа и куча говнокода от авторов не осилевших доку до конца, в симфони же беспощадная слоёная архитектура от авторов не осилевших php и в поддержке они на порядок сложнее, даже хуже битрикса.
    Laravel — экосистема, а не просто PHP-фреймворк
  • 0
    Не стоит баги и охлократию выставлять как контролируемое саморегулирующееся сообщество.
    Вводим рейтинг участника «Хабра» и «Тостера» на «Моём круге»
  • 0
    Если не заморачиваться и отвечать время от времени, то это прекрасный результат. Как любят писать эйчары — этого достаточно, чтобы войти в 5% лучших пользователей ресурса, да и количество ответов на первый взгляд заставляет думать, что чел в чём-то шарит.
    Я не против того, чтобы ответить самому можно было, но эти ответы не должны учитываться в рейтинге пользователей. Тем более ответы у него не верные и будут только путать других пользователей ресурса, которые не проверят кто задавал и кто отвечал на вопрос.
    Вводим рейтинг участника «Хабра» и «Тостера» на «Моём круге»
  • 0
    Лучше бы тостер починили, а то там рейтинг легко обузится, т.к. авторы вопросов могут сами же себе отвечать и выбирать ответ как верный. Вот яркий пример о я чём писал в саппорт пол года назад https://toster.ru/user/BonBonSlick/answers

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

    Очень необъективные рейтинги, чтобы включать их в резюме.
    Вводим рейтинг участника «Хабра» и «Тостера» на «Моём круге»
  • +13
    [сарказм]Мужики тоже думают одним местом, может потому зачастую код у нас получается х**вый?[/сарказм]

    Не раз работал и работаю с женщинами-программистами, не замечал никакой зависимости между полом и кодом.
    Компетентность не имеет пола: о гендерном балансе и тренде развития женского кодинга
  • 0
    Я в начальном комментарии указал пару проблем, но вся статья хреновая, а главное вредная.
    Именно потому, я не хочу делиться опытом, потому что мои советы тоже могут быть вредными за пределами контекста. Надо опираться на серьёзную литературу, где рассмотрена куча разных кейсов, она не раз уже упоминалась.
    К тому же в php есть готовые решения вроде doctrine-propel, которые значительно лучше поделки автора, который даже php знает с оговорками.
    Решение проблем организации бизнес-логики в PHP или как пойти своим путем
  • +1
    Да почитайте вы их, там есть реализации с кодом, плюс в посте выше я писал о Нильссоне, у него практики ещё больше. Но вы даже с терминами не разобрались, а пытаетесь делиться «опытом».

    Карнеги хорош, кода хочешь навешать лапши на уши. Здесь же профессиональный ресурс, где люди обмениваются знаниями и опытом, а не заводят новых друзей. В отношении вас я умышленно применил агрессию и троллинг, дабы заставить вас усомниться и освежить знания.
    Решение проблем организации бизнес-логики в PHP или как пойти своим путем
  • 0
    Зачем писать? Есть книги Эвайнса и Фаулера и куча статей от этих же авторов — это райт вэй. Надо их внимательной читать, а не набравшись по вершка и статьям лепить свои велосипеды.
    Решение проблем организации бизнес-логики в PHP или как пойти своим путем
  • 0
    Почему удалась? Статья ужасная и вредная для прочтения. Не дай о кто-то прочтёт, не дойдёт до комментариев и будет это воспринимать как райт вэй. Автору надо подучить сам php, а затем перечитать книги на который он ссылался и почитать какого-нибудь Нильссона, чтобы увидеть практическую реализацию.
    Решение проблем организации бизнес-логики в PHP или как пойти своим путем
  • +1
    У вас всё плохо, очень плохо.
    DDD вы не понимаете.
    Enity — хрень с защищёнными свойствами в массиве, магическим __call и даже сеттер для айди работает с неявным поведением $this->id = $this->id == 0? $id: $this->id;
    Репозиторий который не репозиторий, в котором мэппер, который почему-то не мэпит, а персистит данные.
    Контекст непонятная штука, чей контракт зафиксирован в виде абстрактноо класса и не предполагает нормальную инъекцию зависимостей.

    Ну и это первая половина проблемы. Вы не знаете синтаксиса php и работаете с отключёнными ошибками вроде E_NOTICE, E_DEPRECATED, потому принимаете объекты по ссылке. Даже оформление кода не по PSR и вооще пахнет временами php 4.

    И ещё куча ног торчит из стога.
    Решение проблем организации бизнес-логики в PHP или как пойти своим путем
  • +3
    Ссылка на этот вопрос ходит как мем и имеет мало общего с количеством людей реально застрявших в виме.
    Stack Overflow вывел из Vim уже больше миллиона пользователей
  • 0
    Интересует будущее Vue, где можно почитать о планах? За последние годы я переел этих тайпскриптов, флоу, вебпаков и *-cli. Сейчас в отпуске свой пет проект начал писать на первом angular, без всяких обвесок и вдруг вспомнил, что люблю программирование.
    Vue выглядит как неплохая альтернатива angular1, да и схожесть упрощает освоение, но она же пугает, как бы авторы не пошли по тому же пути c предпроцессорами, типизацией и функциональщиной.
    Vue.js для сомневающихся. Все, что нужно знать
  • 0
    Ну да, того самого мифического страшного водопада, где всё спланировано и разбито на участки на годы вперёд не было. Он как бандеровцы, придуманный враг, чтобы продавать аджайл.
    Be Agile. Как уйти от Waterfall
  • +1
    В китайских денди для валейбола с изображения был баг с очередностью опроса джойстиков: опрашивался первый, если была нажата кнопка, то выполнялось действие для первого игрока, а затем опрашивался не второй, а снова первый. Сидя на первом джойстике можно было заспамить кнопку и у второго игрока не было шансов.
    В реальной жизни та же проблема, спамеры побеждают, потому что не передают ход по очереди, а стреляют цепочками зачастую противоречивых требований.
    Правильная коммуникация на примере волейбола
  • +1
    >> $components = $this->components();
    Ну почему не заюзать нормальный DI с явной инъекцией нужных объектов, а не таскать каштаны голой рукой из огня.
    Новый быстрый старт с PHPixie: строим цитатник коммит за коммитом
  • +1
    Нет, потому недокументированными методами и не нужно пользоваться, они могут быть удалены без предупреждения. Я даже пример привёл.
    Краткий обзор нововведений в Laravel 5.4
  • +2
    Важно ни его наличие в коде, а наличие в документации. Вот пример из неё
    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

    Краткий обзор нововведений в Laravel 5.4
  • +1
    Пока этого нет в документации, использовать не советуется, т.к. Тейлор любит убирать незадокументированные фичи, в текучем релизе есть такие поломки BC.
    Краткий обзор нововведений в Laravel 5.4
  • +4
    Видимо вы об этом
    Краткий обзор нововведений в Laravel 5.4
  • 0
    Сейчас и для angular 2 есть NativeScript http://docs.nativescript.org/angular/start/introduction.html
    Как Ionic 2 помогает мне вникнуть в angular 2
  • +1
    Основные изменения произошли в инфраструктуре и головах разработчиков, которые начали этой инфраструктурой пользоваться. Ускорили производительность, улучшили синтаксис, много изменений внутри, но ничего принципиально нового, что бы вывело язык на новый уровень не случилось. А вот то, что начали пользоваться компосером и фреймворками сильно всё поменяло, хотя ещё и во времена php4 были pear, pecl, seagull, cakephp и т.д.

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

    Блеск и нищета php. Эволюция языка от 4.x к 7.1
  • +6
    Неужели так важно знать каким to do менеджером и какой читалкой пользуется человек, если он сам работает по 10-15 часов, ещё и других уговаривает?
    Почему бы не учиться эффективной работе у тех, справляется своими делали в рабочее время и никого не должен уговаривать поработать.
    Как работают ИТ-специалисты. Даниил Пивоваров, Vscale
  • +2
    Уровень сложности может определить только сам читающий. Не вижу проблемы, чтобы новички читали сложные тексты, пусть они и поймут только 30%, но зато будут знать куда расти.
    Другая беда, что сейчас развелось специалистов, насмотревшихся простых видеокурсов, но так и не дошедших до серьёзной литературы и не подозревающих о ней.
    Идея для Хабра: уровни сложности статей
  • –2
    Ну что за гадкая привычка молча лепить минус и портить карму, отпишитесь хоть почему. Я же привёл аргументированную точку зрения, если надо ещё докину аргументов и ссылок.
    Почему я бы не стал использовать Rails для нового проекта
  • –1
    Какой-то бред, зачем-то приплели сюда facebook, хотя этим самым hiphop никто не пользуется, сообщество ускоряет язык и без мордокниги. Nodejs и Go концептуально другие языки, а не замена ruby, копаться в асинхронных запросах то ещё удовольствие.
    Ну и самое важное, что он рассматривает язык с точки зрения нагрузки(он стал третьим по посещаемость сайтом на Rails), а этот кейс далеко не критичен для большинства проектов, тем более узкие места всегда можно затюнить.

    Пришлось саппортить один проект на рельсах, норм фреймворк, много полезных фич, которые перенимают фреймворки с других языков, не стоит торопиться его хоронить.
    Почему я бы не стал использовать Rails для нового проекта
  • +1
    Проблема водопадной модели в том, что большинство знает о ней только как об антиподе гибкой методологии и судят не удосужившись даже ознакомиться с первоисточниками. Вроде этого
    http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

    Водопадная модель лишь определяет этапы необходимые для разработки, определяет порядок их следование. Но при этом разрешает возвращение на любой из предыдущих этапов вплоть до сбора новых требований и составления нового плана. Это полноценная итерационная система, которая гораздо гибче идиотских фиксированных спринтов в скраме.
    Be Agile. Как уйти от Waterfall
  • 0
    Agile — набор принципов и ценностей. Под них подходит куча методологий, в том числе и водопадная модель.
    Скрам хотя и называют аджайл фреймворкам, но он рпотиворечит аджайл принципам, я уже выше описал пару из них.
    В манифесте написано
    >>Работающий продукт важнее исчерпывающей документации;
    Что это как не приоритезация, которая говорит, что приоритет у документации должен быть ниже работающего продукта. Этот принцип прекрасно кладётся на водопадну модель, т.к. в то время документации уделялось слишком много внимание, а зачастую компании и вовсе блокировали следующую фазу до окончания документрирования.

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

    Во вторых, если у объекта есть вложенные объекты и вы их меняете, то мутирует и исходный объект.
    Глупые трюки с ES6
  • 0
    Object.assign не имеет отношение к иммутабельности, он копирует объекты, да ещё по своим витиеватым правилам, советую быть очень осторожным с ним. https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Object/assign
    Глупые трюки с ES6
  • 0
    Как же надоели эти аджайл укурки, которые наезжают на водопадную модель даже не ознакомившись с наработками хотя бы на уровне ройсовской модели. Принципы аджайла писаны с оглядкой на водопад и не заменяют его, а меняют приоритеты.

    А вот скрам как раз нарушает аджайл принцыпы, так как жёстко регламентирует процесс (вроде дейли статус-митингов). Спринты обычно имеют жёсткие рамки и мешают реагировать на изменения. При этом скрам вовсе не говорит о методиках вроде документации на которую выставляются приоритеты в аджайл манифесте. Скрам просто примазался к модному термину.
    Be Agile. Как уйти от Waterfall
  • 0
    Насколько я знаю, майкрософт занималось проблемой управления с помощью голоса и видео ещё в 90-х годах, так что это ещё кто в начале пути. У меня недавно умерла люмия и теперь пользуюсь андродом, очень не хватает cortana, гугловская поделка значительно уступает в распозновании, особенно бесят её попытки угадать, а не просить повторить команду.
    Битва титанов голосовой коммерции
  • +6
    Думаю ссылка в статьях на госпожу Мариссу Мейер доказывает всю нелепость аргументов против удалёнки. Своими методами она убила то, что оставалось от yahoo.
    В её случае всё понятно, она симпатичная женщина, умеющая хорошо говорить, потому личный контакт для неё важен, т.к. при удалёнке оценивали только результат, а они плачевны. А так Мариса всё ещё на коне.

    Я уже и не вспомню когда последний раз работал на проекте, где все работники сидят в одном офисе, сложные проекты всегда распределённые. Сидя в офисе ты всё равно де-факто — удалёнщик.
    5 причин, по которым работодатели не любят удалёнщиков (и 4 способа получить работу в любом случае)
  • +2
    Вы же в курсе, что ракеты, как практически и любой сложный современный продук так и создаются — детали делаются в разных местах, а затем собираются в единый продукт. В поисках идеального тз, вы не получите не продукта, ни тз. А вот если один продукт разобьёте на кучу мелких, то всё станет гораздо проще. А для простого продукта тз можно писать прямо на ходу, а то и постфактум.
    Каким должно быть ТЗ на Корпоративную ИС?
  • +2
    Вывод. Хотите познакомиться с профессией, идите работать в настоящую ИТ компанию, потому что курсы и фриланс — это безалкогольное пиво с резиновыми женщинами.
    Как я шел к Java-программированию и прошел мимо