Можно ли узнать высоту и ширину двумерного массива без цикла?

RedDokC2: используйте автодополнение консоли или IDE. Оно от таких ошибок избавит

Сборка php файлов в Gulp --- TypeError: Cannot read property 'php' of undefined?

вот этот объект path и является пустым.
gulp я не знаю

Можно ли узнать высоту и ширину двумерного массива без цикла?

console.log(arr.length)

Присмотритесь

Как выучить/понять ООП паттерны?

Как заучивание паттернов даст понимание ООП?

Вы и все кому понравился ваш ответ — ООП не понимают.

Как выучить/понять ООП паттерны?

ООП чтением github не понять. Наоборот, говнокодером процеурщиком станешь.

Как выучить/понять ООП паттерны?

И как звучит проблема, которую решает ООП? )

Как перейти к следующей фунции?

Написать return?

Можно ли использовать docker чтобы разрабатывать кроссплатформенные приложения?

Алексей: WSL и Wine приложения совершенного разного уровня. WSL это posix доступ к ядру. А win32доступ это ntldr. А wine это эмуляция.
С 7ки все сьедут достаточно быстро. Потому что закручивают гайки и заходят через ентерпрайз мс

Годную и понятную статью по DI и сервис контейнерам?

Основная статья: Не используй di контейнеры в php, если не используешь стороннние реализации некого функционала.
Все контейнеры в Фреймворках в пхп реализованы не верно. Жёсткая связность это хорошо!

Можно ли использовать docker чтобы разрабатывать кроссплатформенные приложения?

Алексей: вы похоже не в курсе, что docker как и linux уже нативны с windows 10 )

Можно ли использовать docker чтобы разрабатывать кроссплатформенные приложения?

SomeName SomeSurName: вы делаете её в докере. А докер запускается и в линуксе и в винде

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

По существу моего вопроса вы не ответили.

Ответил по существу. Но я не понимаю, почему вы не понимаете ответ. Возможно у нас с вами разный уровень понимания задачи программирования.
Скорее всего вы в самом начале профессии — программист

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

fpinger вот видите, вы не понимаете, что использование статиков в архитектуре приложение, это костыль.
Помимо того, что статик автоматически увеличивает сочленение, так в вашем случае он уменьшает связность, ибо возвращает не экземпляр класса от которого вызван.
Уменьшение связности, это штука, которой нужно опасаться как огня. Она на степень увеличивает сложность приложения.

Что бы не сойти с ума от сложности, разработчикам IDE приходится придумывать плагины для поддержки тех или иных Фреймворков. Чем более функциональный плагин нужен для IDE, тем дальше framework от ООП. Чем дальше от ООП, тем меньше теоретической основы за framework'ом.
Чем меньше теоретической основы, тем больше ошибок заложено в архитектуре.
Чем больше ошибок в архитектуре, тем менее гибкие и масштабируемые системы, с приемлемой сложностью можно писать.
Приемлемая сложность приложения, это сложность:
- средняя цикломатическая сложность приложения не превышает 15. А лучше не превышает 10
- не должно быть наследования более 3х уровней.
- не должно быть методов с более чем 6ю аргументами
- не должно быть методов с более чем 120 строк.
Вообще, критериев оценки сложностей навалом, но я привел наиболее важные и базовые.
А как только я вижу статики в базовой архитектуре фремворка, то я уже знаю ряд задач/проблем, которые кроме как превышением вышеперечисленных критериев не решить. Одна из них, это RBAC.

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

Где здесь утечка памяти?

Эти снимки кучи ничерта не помогают.
Самое интересное, что при снимках кучи он оставляет ссылки на инстансы объектов в предыдуших снимках. И даже не текущее приложение будет течь в профайлере :)

Нормальный профайлер только в Microsoft Edge

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

fpinger:

Ниже я изменил реализацию с учётом ваших желаний. Простая реализация с привязкой к сессии. Кроме того добавил немного кода модели.

$cart = Cart::bySession($session_id)
                ->firstOrCreate(['session' => $session_id]);

Вы заменяете один статик другим и говорите, что все исправили.

Бизнесу нужны быстрые решения. Для этого нужно искать золотую середину, а не быть снобом.

Вы делаете даже в элементарных примерах кучи допущений, которых в рамках ООП быть не должно. Даже простые примеру имеют ужасающую сложность приложений.
Что говорить, когда вы начнёте чуть сильнее увеличивать количество функционала. Это превратится в ад.

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

Влад Токарев:

Роутинг, работа с БД, да и все остальное останется.

Ну как так то. Мы же договорились, что статики это плохо и использовать нельзя. И вы предлагаете их тут же и оставить %)

Нет никаких готовых решений для построения сложных Enterprise приложений

Есть Фреймворки, которые декомпозируют задачу разработки сложных модульных приложений на составные части. Так же знают о специфике веб-приложений и представляют абстракции для того, что бы нивелировать сложности веб-специфики (сделать прозрачным её).
Как я уже говорил это Pyramid.

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

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

По-моему можно сделать как угодно, как раз Laravel позволяет делать все, что угодно, вклиниваясь в любую часть работы.

Я не вижу каким это образом он это позволяет. Приведите пример, как вы организуете передачу соединения с БД в экшен и сделаете проверку прав на то, что пользователь имеет право получать данные для определённого company_id (задача, когда пользователь является работником компании, и только по ней имеет право получать данные).
Я вижу только один путь, который представляет вам Laravel — это использовать статические методы внутри экшенов.

Фреймворк остается самим собой, просто не используется часть его функций

Т.е. фреймворк расширяется и изменяется согласно требованиям разрабатываемого приложения.

Ещё раз прочитайте определение Фреймворка вдумчиво. Фреймворк предоставляет методику написания приложения на нём и вызывает ваш код (который написали вы).
Если же вы отключаете часть функциональности Фреймворка, то для вас он уже не является таким строго по определению. Вы начинаете его использовать как библиотеку.
Соответственно, вы уже не используете методику, которая предоставляется данным решением.
С вероятностью 99.9% вы просто придумываете свою методику, которая представляет из себя вкусовщину основанную на вашем личном эмпирическом опыте, т.е. говнокод.
Соответственно, уже ничего путного не выйдет.

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

fpinger: супер! Серьёзно — супер.
А теперь можно конкретно поговорить про насущие проблемы больших проектов.

Вы уже из-за подхода Laravel начали во всю использовать статики: Card::change Log::error
Это абсолютно не рашсряемо. Если у вам нужно подменить логгер в зависимости от окружения. Задача, кстати, очень частая, когда подменяют именно логер.
Card::change - вы жестко завязались на метод change который что-то делает.

Проблема целостности логики приложения — тут не видно ни связи текущего пользователя с корзиной. Потенциальная уязвимость того, что вы можете привязать товар ни к той корзине. Если один экшен, это не так критично. А представьте, если таких мест десятки. Как пример амазон. Там различных способов работы с корзиной кучи.

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

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

Теперь возвращаемся к коду. В CartChange много чего завязано на какие то ассоциативные массивы и куча публичных методов Я не понимаю как это работает. Это вообще процедурное программирование. Тут нет реализации каких то интерфейсов, для понимания, что можно передать, а чего нельзя. Это сплошное нарушение SOLID, так как CartChange нарушает принцип единой ответственности. Он предоставляет различные данные разной с разной природой.

Даже передавать разный request для каждого action попахивает. Меняем строчку в роутинге и вам приходит другой объект. Потенциальное место огрести кучу неявных ошибок.

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

Влад Токарев:

Еще раз, не предлагаю я ВСЕ выбросить, просто утверждаю, что некоторые вещи, особенно фасады, надо выбросить.

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

Проблема Laravel в рамках темы обсуждения в том, что в документации нет информации о том, где хранить логику,

Строго говоря, он предлагает это делать в контроллерах (https://laravel.com/docs/5.4/controllers)

Instead of defining all of your request handling logic as Closures in route files, you may wish to organize this behavior using Controller classes. Controllers can group related request handling logic into a single class. Controllers are stored in the app/Http/Controllers directory.

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

Я изначально написал, что в рамках данного Фреймворка аспектоориентированная задача, аля RBAC будет решена на основе private и protected методов класса. По другому это вы не сделаете.

Вчитайтесь в термин Фреймворк. Поймите его.

«Фреймворк» отличается от понятия библиотеки тем, что библиотека может быть использована в программном продукте просто как набор подпрограмм близкой функциональности, не влияя на архитектуру программного продукта и не накладывая на неё никаких ограничений. В то время как «фреймворк» диктует правила построения архитектуры приложения, задавая на начальном этапе разработки поведение по умолчанию — «каркас», который нужно будет расширять и изменять, согласно указанным требованиям.

Другим ключевым отличием «фреймворка» от библиотеки может быть инверсия управления: пользовательский код вызывает функции библиотеки (или классы) и получает управление после вызова. Во «фреймворке», пользовательский код может реализовывать конкретное поведение, встраиваемое в более общий — «абстрактный» код фреймворка. При этом, «фреймворк» вызывает функции (классы) пользовательского кода

Как только вы выбрасываете часть Фреймворка, он, по сути, становится либо другим Фреймворком(самопалом) либо библиотекой.

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

Влад Токарев:

конечно от этого всего,

Зачем тогда этот Фреймворк брать вообще?

контроллер максимально простой

Очень простой. Жаль, что логики нет никакой. Давайте что-то во флоу laravel, где есть хотя бы обработка формы и работа с БД. А то пустые контроллеры, вообще не показательны ни для одного Фреймворка.

zugo в своем ответе написал описал проблематику

Проблематика такого ответа в том, что вы не понимаете что такое в принципе Фреймворк(см выше)
И если всё выбросить из Фреймворка и использовать свои подходы, то это — не использование Фреймворка.

оффтопят, предлагая другие инструменты.

Я тут пишу лишь потому, что хочу молодые умы отвадить от использования плохих практик и заставить учить не Фреймворки, а парадигмы и концепции.
Проблема многих в том, что нет понимания что такое ООП и какие из принципов данной парадигмы
следствия следуют. Что такое SOLID.
По одному только принципу Open-Close написана целая книжка у Бертрана Мэйера. Где все это ещё увязывается с GRASP. Принцип подстановки Барбары Лисков, так вообще чистая математика.

Но люди читают про Фреймворки и используют понятия нравится/не нравится. А нужно смотреть на теорию.
Видишь, что основа Фреймворка в статиках — значит писали его любители. Ничего приличного не выйдет, если следовать принципам заложенным в данном решении.
И т.д. и т.п.

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

Михаил Шатилов: посмотрел. Это ж, вроде, CMS, а не Фреймворк