Ещё такой вопрос возник при прочтении. В случае, если у нас есть две разных реализации интерфейса, как контейнер с автоматическим разрешением зависимостей различает, какую именно использовать? Я правильно понимаю, что чистого решения у этой проблемы нет, и мы в итоге всё равно указываем конкретный класс - только не при вызове, а где-то в конфигурации?
Большое спасибо за статью! Особенно порадовало упоминание Yii3.
Но не могу удержаться от небольшого замечания, тем более, что этот код уж очень диссонирует с толковостью остальной статьи своей вопиющей бессмысленностью. Да, я про try/catch/echo $e->getMessage(). С большой натяжкой его наличие можно оправдать отключённым при разработке информированием об ошибках. Но в этом случае человеку надо садиться учить самые основы, а не внедрение зависимостей. А если информирование об ошибках включено - как это и должно быть - то этот кусок кода становится полностью бессмысленным, поскольку РНР прекрасно выведет сообщение об ошибке и без каких-либо телодвижений со стороны разработчика.
Плюс опять же непонятно, зачем заведомо ухудшать информативность сообщения об ошибке, вырезая из неё такую информацию, как место возникновения ошибки, трассировка стека и тип исключения. Зачем было городить разные типы исключений на каждый чих, если мы всё равно информацию о типе не используем?
Ну и в довершение надо всегда помнить, что такой блок зачастую переезжает из примеров в прямиком в продакшен, где становится уже попросту вредным, вываливая внутренние ошибки клиенту.
Я понимаю, что PHPStorm, как и другие анализаторы, постоянно дёргает за штаны, "Караул, неотловленное исключение, всё пропало!". Но на мой взгляд, это одна из инспекций, которая приносит гораздо больше вреда, чем пользы - приводя к такому вот подходу, "написать абы что, лишь бы мамка не ругалась". Надо не вестись, а наоборот, укорачивать этой инспекции ручки в настройках, ну или хотя бы аннотациями.
Ну в целом не нужно быть ясновидящим, чтобы предсказать дыры в коде у новичка, на ходу учившего язык в перерывах между перебиранием карточек. Тут скорее будет сюрпризом, если дыр не окажется.
Насчёт прокачал, кстати, большие сомнения. Нормальный сервер для SQL не осилил, ограничился огрызком. Ну и нежелание выкладывать код, кстати, вполне объяснимо. У таких гениев со "своим MVC фреймворком" обычно дыра на дыре - от SQL инъекций до LFI и XSS. В общем, так же как с английским.
Me: "Я написал свою версию MVC фреймворка с блекджеком и роутингом, что значительно повлияло на скорость работы приложения. Кроме того, я реализовал кэширование на стороне фронтенда, что помогло сократить количество запросов к серверу и позитивно сказалось на производительности. Also me: "Мой сервер с apache едва справляется с текущей нагрузкой" ¯\(ツ)/¯
Это позволило быстро разрабатывать прототипы приложений, не загружая множество различных зависимостей, как в случае с Laravel, что значительно повлияло на скорость работы приложения.
ОМГ, снова этот детский лепет. Загрузка зависимостей у него влияет и на скорость разработки приложения (которая получается сравнимой с парой минут, требуемых на загрузку. Да с такой скоростью этот вундеркинд скоро выкинет всех нас из профессии!) и - внезапно - на скорость работы приложения. Видимо этот гений полагает, что зависимости загружаются каждый раз снова при каждом обращении к приложению
ОМГ, реклама убогого приложения с дизайном из 90-х под соусом "я выучил английский!" Ага-ага, ультра-модным способом из позапрошлого века - перекладыванием карточек.
Да ещё и с неграмотными переводами. "Случайно" тут переводится корявым программистским "randomly" а не человеческим "accidentally". Но главное даже не это, а давно всем известные минусы этого способа - полное отсутствие грамматики и многозначность слов в английском, когда одно и то же слово (взятое само по себе) может быть и существительным, и прилагательным, и глаголом, и наречием. Не говоря уже о совсем разных смыслах слова, как, например, log или sound. Так и будет счастливый финалист этой программы, обвешанный медальками геймификации, читать по складам - "Бревно в"...
А можно вас попросить рассказать подробнее про эти самые полиморфные отношения? А то статья, которая сводится к строчке "вот тут происходит вся магия", вызывает некоторое разочарование. И наводит на мысли о рекламном характере. При том что рекламируемый проект явно интересный, но тогда уж и стоило бы писать статью именно о нём?
Это какое-то уже запредельное лицемерие, уровня анекдотов. Бить себя пяткою в грудь, "в рамках поддержки оупен соурсе!" и давать ссылку на зип файл в телеграмчике. Причём внутри - "MVP", то есть собранное на коленке из гуана и палок. Судя по языку, чувак уже лет 15, как переквалифицировался из программистов в чиновники и сейчас емудля каких-то личных целей нужно показать пучок статей на хабре, "я маститый ойти журнолист".
Да какая некросеть. Сеть как раз нормально напишет. А здесь он взял кусок инструкции для пользователей и тупо вставил в текст, написанный, якобы, от первого лица.
Я знаю насколько там всё ужасно, поэтому мнения о плохом коде не интересы
Тут другое интересно - а читателям-то какой интерес смотреть на школьный говнокод? И зачем эти ностальгические сопли в хабе РНР? Это скорее в какой-нибудь читальный зал. В общем, статья прекрасно резюмируется заключительной фразой
Творите, создавайте, компьютерная наука это всего лишь чтобы огурцы ложкой банка майонеза
В целом неплохо, но немного сумбурно и местами шероховато.
strlen() считает байты
а только что говорили, что на считает, а показывает уже посчитанное :)
Строки в PHP — не массивы: доступ через [] опасен для Unicode.
Хромает логика: то, что доступ опасен, следует не из того, что строки - это не массивы. А из байтовой натуры оператора []. Вместо двоеточия лучше поставить точку, а ещё лучше разнести в список.
Многие функции, применяемые к массивам, нельзя применить к строкам.
Вот тут даже интересно стало. "Многие" заведомо означает некоторые всё-таки можно. Это какие например?
В какой-то мере я с вами согласен. Но вот не надо было пол-статьи писать про то, какая бяка эти исключения. Потому что решение выглядит не составлением логической цепочки, а борьбой с try..catch.
Плюс, если вы "не против" "предусмотренной" обработки ошибок, то надо было четко описать их сосуществование. А сейчас статья выглядит как "давайте сделаем из пыхи голанг в плане обработки ошибок", а "предусмотренная" обработка сводится к всё тому же try-catch вокруг любого вызова, который может выбросить исключение.
Ещё такой вопрос возник при прочтении. В случае, если у нас есть две разных реализации интерфейса, как контейнер с автоматическим разрешением зависимостей различает, какую именно использовать? Я правильно понимаю, что чистого решения у этой проблемы нет, и мы в итоге всё равно указываем конкретный класс - только не при вызове, а где-то в конфигурации?
Большое спасибо за статью! Особенно порадовало упоминание Yii3.
Но не могу удержаться от небольшого замечания, тем более, что этот код уж очень диссонирует с толковостью остальной статьи своей вопиющей бессмысленностью. Да, я про try/catch/echo $e->getMessage(). С большой натяжкой его наличие можно оправдать отключённым при разработке информированием об ошибках. Но в этом случае человеку надо садиться учить самые основы, а не внедрение зависимостей. А если информирование об ошибках включено - как это и должно быть - то этот кусок кода становится полностью бессмысленным, поскольку РНР прекрасно выведет сообщение об ошибке и без каких-либо телодвижений со стороны разработчика.
Плюс опять же непонятно, зачем заведомо ухудшать информативность сообщения об ошибке, вырезая из неё такую информацию, как место возникновения ошибки, трассировка стека и тип исключения. Зачем было городить разные типы исключений на каждый чих, если мы всё равно информацию о типе не используем?
Ну и в довершение надо всегда помнить, что такой блок зачастую переезжает из примеров в прямиком в продакшен, где становится уже попросту вредным, вываливая внутренние ошибки клиенту.
Я понимаю, что PHPStorm, как и другие анализаторы, постоянно дёргает за штаны, "Караул, неотловленное исключение, всё пропало!". Но на мой взгляд, это одна из инспекций, которая приносит гораздо больше вреда, чем пользы - приводя к такому вот подходу, "написать абы что, лишь бы мамка не ругалась". Надо не вестись, а наоборот, укорачивать этой инспекции ручки в настройках, ну или хотя бы аннотациями.
"Некто, напоминающий быка (в смысле мускулистого телосложения)". Про (не)вежливость тут нет ничего.
Если вы про bull verb (1) : to advance forcefully, то, во-первых, это глагол.
В том смысле, что он всегда играет на повышение? Или просто кто-то, сочиняя эту историю, запутался в незнакомом языке?
Элементарно, Ватсон! Вот предыдущее поделие этого же персонажа. Разумеется, про контекстное экранирование он даже не слышал.
Ну в целом не нужно быть ясновидящим, чтобы предсказать дыры в коде у новичка, на ходу учившего язык в перерывах между перебиранием карточек. Тут скорее будет сюрпризом, если дыр не окажется.
Насчёт прокачал, кстати, большие сомнения. Нормальный сервер для SQL не осилил, ограничился огрызком. Ну и нежелание выкладывать код, кстати, вполне объяснимо. У таких гениев со "своим MVC фреймворком" обычно дыра на дыре - от SQL инъекций до LFI и XSS. В общем, так же как с английским.
ШТА? Хабр задумывался для кудахтания "я тут накорябал на коленке супер-прогу, которая учит неграмотному английскому, но вам её не покажу", серьёзно?
Me: "Я написал свою версию MVC фреймворка с блекджеком и роутингом, что значительно повлияло на скорость работы приложения. Кроме того, я реализовал кэширование на стороне фронтенда, что помогло сократить количество запросов к серверу и позитивно сказалось на производительности.
Also me: "Мой сервер с apache едва справляется с текущей нагрузкой" ¯\(ツ)/¯
ОМГ, снова этот детский лепет. Загрузка зависимостей у него влияет и на скорость разработки приложения (которая получается сравнимой с парой минут, требуемых на загрузку. Да с такой скоростью этот вундеркинд скоро выкинет всех нас из профессии!) и - внезапно - на скорость работы приложения. Видимо этот гений полагает, что зависимости загружаются каждый раз снова при каждом обращении к приложению
ОМГ, реклама убогого приложения с дизайном из 90-х под соусом "я выучил английский!" Ага-ага, ультра-модным способом из позапрошлого века - перекладыванием карточек.
Да ещё и с неграмотными переводами. "Случайно" тут переводится корявым программистским "randomly" а не человеческим "accidentally". Но главное даже не это, а давно всем известные минусы этого способа - полное отсутствие грамматики и многозначность слов в английском, когда одно и то же слово (взятое само по себе) может быть и существительным, и прилагательным, и глаголом, и наречием. Не говоря уже о совсем разных смыслах слова, как, например, log или sound. Так и будет счастливый финалист этой программы, обвешанный медальками геймификации, читать по складам - "Бревно в"...
Ну вот как раз свежий пример. Чувак на сложных щах пишет библиотеку для экономии памяти. Тесты, композер, все дела.
А внутри
"Ненуачо? Генератор жи!"
А можно вас попросить рассказать подробнее про эти самые полиморфные отношения? А то статья, которая сводится к строчке "вот тут происходит вся магия", вызывает некоторое разочарование. И наводит на мысли о рекламном характере. При том что рекламируемый проект явно интересный, но тогда уж и стоило бы писать статью именно о нём?
Это какое-то уже запредельное лицемерие, уровня анекдотов. Бить себя пяткою в грудь, "в рамках поддержки оупен соурсе!" и давать ссылку на зип файл в телеграмчике. Причём внутри - "MVP", то есть собранное на коленке из гуана и палок. Судя по языку, чувак уже лет 15, как переквалифицировался из программистов в чиновники и сейчас емудля каких-то личных целей нужно показать пучок статей на хабре, "я маститый ойти журнолист".
Да какая некросеть. Сеть как раз нормально напишет. А здесь он взял кусок инструкции для пользователей и тупо вставил в текст, написанный, якобы, от первого лица.
Мне так нравится это "например". "Вчера был у любимой бабули на деньрождении, подарил ей подарок (например утюг или салфеточку на телевизор)".
Но самое безумное в этой статье, конечно - это выбор хабов.
Тут другое интересно - а читателям-то какой интерес смотреть на школьный говнокод? И зачем эти ностальгические сопли в хабе РНР? Это скорее в какой-нибудь читальный зал. В общем, статья прекрасно резюмируется заключительной фразой
Хаб РНР тут явно лишний. Статья "какие мы молодцы, подписывайтесь на наш канал" к разработке не имеет никакого отношения.
В целом неплохо, но немного сумбурно и местами шероховато.
а только что говорили, что на считает, а показывает уже посчитанное :)
Хромает логика: то, что доступ опасен, следует не из того, что строки - это не массивы. А из байтовой натуры оператора []. Вместо двоеточия лучше поставить точку, а ещё лучше разнести в список.
Вот тут даже интересно стало. "Многие" заведомо означает некоторые всё-таки можно. Это какие например?
В какой-то мере я с вами согласен. Но вот не надо было пол-статьи писать про то, какая бяка эти исключения. Потому что решение выглядит не составлением логической цепочки, а борьбой с try..catch.
Плюс, если вы "не против" "предусмотренной" обработки ошибок, то надо было четко описать их сосуществование. А сейчас статья выглядит как "давайте сделаем из пыхи голанг в плане обработки ошибок", а "предусмотренная" обработка сводится к всё тому же try-catch вокруг любого вызова, который может выбросить исключение.