Ну в целом не нужно быть ясновидящим, чтобы предсказать дыры в коде у новичка, на ходу учившего язык в перерывах между перебиранием карточек. Тут скорее будет сюрпризом, если дыр не окажется.
Насчёт прокачал, кстати, большие сомнения. Нормальный сервер для 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 вокруг любого вызова, который может выбросить исключение.
автору надоело отлавливать тонну кастомных исключений между слоями приложения
...и поэтому он решил написать тонну неубираемого кода по обработке ошибок.
Удобство исключений в том, что в 90% случаев их ловить не обязательно. То есть в коде нет вообще никакой обработки ошибок, ни с try, ни без. А
конструкция по типу try { .. } catch (Exception $e) { ..$e->getMessage() }
-- это очевидный говнокод, с которым надо бороться не переменой синтаксиса (чтобы теперь на каждый чих писать не try, а if ($result->error)), а выпиливанием бессмысленных try...catch из кода.
Просто удивительно, как автор не замечает этой иронии. Это напоминает мне историю с logicless шаблонами: придумываем несуществующую проблему, потом придумываем гениальное решение для неё, получаем код хуже исходного, и ничтоже сумняшеся пишем победную статью, в которой заявляем полное превосходство своего метода над существующим.
Спасибо за статью. Но не удержусь от пары замечаний.
Ошибку валидации вряд ли нужно логировать. Это, по сути, не ошибка, а совершенно ожидаемое поведение. Да, там останется только перевыброс исключения. И как раз на этом стоит остановиться поподробнее
Код не станет сложнее, если Exception поменять на ServiceValidationException и DomainValidationException, но зато станет куда более логичным и приближённым к реальности. А сейчас смотришь, и не понимаешь, почему ошибка, к примеру, соединения базы данных возвращает 400, а не 500 статус
И вот тут как раз и объяснить, почему вы меняем DomainValidationException на ServiceValidationException
Ну и совсем уж по мелочи
ошибку "Не корректная сумма денег" надо заменить на "Некорректная валюта" (и в целом надо бы вычитать на грамматические ошибки и опечатки)
проверка на empty($this->value) не имеет смысла, её стоит убрать
Во-первых, не у меня, а у автора статьи. Во-вторых, это требует нулевого порога входа и делается один раз копипастой. В-третьих, любой шаблонизатор требует инициализации и начальной конфигурации, то есть конкретно этот ничем не отличается от всех других. Ну разве что привязкой к модели, но её делать не обязательно.
И главное - верстальщик-то здесь при чём? Который к этим "премудростям" не имеет ни малейшегоо отношения. Подключение и инициализация движка - это на 100% работа бэкендера.
Ради чего всё это?
Вы так и не предложили альтернативу, в которой "всего этого" нету.
Юзеркейс: верстальщик в гробу видал этот ваш SSR и желает всё отрендерить на VUEjs.
В этом случае шаблоны вообще не при чём, а весь вывод делается в том самом Vue. Это отдельный юзкейс. Смешивающего серверную шаблонизацию и SSR гения, который героически решает задачу создания json из переменных шаблона вы себе выдумали сами, к данной статье он не имеет отношения. Ну или если вам реально приходилось с этим сталкиваться в жизни, я вам искренне сочувствую, но нормальные люди отправляют json сразу с сервера. Поэтому снова прошу не путать свой печальный опыт с предметом статьи.
Если вы про 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 вокруг любого вызова, который может выбросить исключение.
...и поэтому он решил написать тонну неубираемого кода по обработке ошибок.
Удобство исключений в том, что в 90% случаев их ловить не обязательно. То есть в коде нет вообще никакой обработки ошибок, ни с try, ни без. А
-- это очевидный говнокод, с которым надо бороться не переменой синтаксиса (чтобы теперь на каждый чих писать не
try, аif ($result->error)), а выпиливанием бессмысленных try...catch из кода.Просто удивительно, как автор не замечает этой иронии. Это напоминает мне историю с logicless шаблонами: придумываем несуществующую проблему, потом придумываем гениальное решение для неё, получаем код хуже исходного, и ничтоже сумняшеся пишем победную статью, в которой заявляем полное превосходство своего метода над существующим.
Спасибо за статью. Но не удержусь от пары замечаний.
Ошибку валидации вряд ли нужно логировать. Это, по сути, не ошибка, а совершенно ожидаемое поведение. Да, там останется только перевыброс исключения. И как раз на этом стоит остановиться поподробнее
Код не станет сложнее, если Exception поменять на ServiceValidationException и DomainValidationException, но зато станет куда более логичным и приближённым к реальности. А сейчас смотришь, и не понимаешь, почему ошибка, к примеру, соединения базы данных возвращает 400, а не 500 статус
И вот тут как раз и объяснить, почему вы меняем DomainValidationException на ServiceValidationException
Ну и совсем уж по мелочи
ошибку "Не корректная сумма денег" надо заменить на "Некорректная валюта" (и в целом надо бы вычитать на грамматические ошибки и опечатки)
проверка на empty($this->value) не имеет смысла, её стоит убрать
Во-первых, не у меня, а у автора статьи. Во-вторых, это требует нулевого порога входа и делается один раз копипастой. В-третьих, любой шаблонизатор требует инициализации и начальной конфигурации, то есть конкретно этот ничем не отличается от всех других. Ну разве что привязкой к модели, но её делать не обязательно.
И главное - верстальщик-то здесь при чём? Который к этим "премудростям" не имеет ни малейшегоо отношения. Подключение и инициализация движка - это на 100% работа бэкендера.
Вы так и не предложили альтернативу, в которой "всего этого" нету.
В этом случае шаблоны вообще не при чём, а весь вывод делается в том самом Vue. Это отдельный юзкейс. Смешивающего серверную шаблонизацию и SSR гения, который героически решает задачу создания json из переменных шаблона вы себе выдумали сами, к данной статье он не имеет отношения. Ну или если вам реально приходилось с этим сталкиваться в жизни, я вам искренне сочувствую, но нормальные люди отправляют json сразу с сервера. Поэтому снова прошу не путать свой печальный опыт с предметом статьи.