Ну в том что написано особой разницы нигде почти нет. Но рассмотрены очень базовые вещи. Не рассмотрен очень важный аспект валидации массивов данных в форме. Где придется делать цикл и валидировать каждый элемент отдельно, а где есть для этого специальные возможности. Ну и всякие условные валидации, а так же расширяемость. Вот там либы будут отличаться уже сильнее
Как разобрать сложный XML-файл и не утонуть в собственном коде
Не увидел у вас сложных xml файлов, а вот ваш класс имеет отвратительный код (вложенность, длина метода, стиль кодирования, мусорный эхо дебаг внутри класса), и еще более сложную в чтении структуру с кэлбеками обработчиками.
ЗЫ длинную запись array уже так давно не видел, спасибо понастальгировал)
статью по диагонали читали? автор же пишет что они используют github.com/joho/godotenv и .env файл
Историю изменений такого обычно не ведут (это же всякие пароли и т.п.)
Помимо наличия уровней логирования при вызове логера есть еще и уровень у самого логера выставляя который мы пропускаем запись всего что ниже. Это позволяет нам иметь разную детализацию логов на разном окружении. Я хочу видеть Debug при разработке локально, но не хочу на стейдж сервере (или открытой бетте). Я хочу видеть Warning на стейдж сервере, но на продакшене не хочу. А помимо этого логгеров может быть не один (stdout и sentry например), вызываемые по цепочке, и я хочу там разный уровень логирования. Именно по этому и нужны уровни Warning И Critical (Fatal). Больше уровней — больше пространства для маневра.
Ах да, и эти уровни это стандарт дефакто, на большинстве систем и языков они есть. Снова кто то из го разрабов хочет быть не таким как все...
позволил нам уже более четырех лет поддерживать высокий темп разработки, легко вводить в работу новых разработчиков и не замедляться с течением времени
и
с таким подходом Code Review проходит дольше обычного. Даже маленькие задачки могут задержаться на несколько дней
чёт какой то диссонанс у меня вызывают эти два предложения.
Так же в начале была озвучена например проблема легаси кода, но как ее решает конвенция непонятно, собственно никак.
Надеюсь перейдя на личности вы потешили свое эго и чувствуете себя лучше)
Что же до остального. Не должен никто лазить в хранилище просто так. Или вы все ограничения бизнес логики реализовываете на стороне бд или у вас двойные стандарты. А целостность при падениях приложения обеспечивается использованием транзакций. Вы ведь и так их должны использовать например для защиты целостности при записи в бд. Так что снова двойные стандарты (целостность существования записей вы поддерживаете приложением а целостность отсутствия данных почему то не можете)
В вашем примере каждый член enum это экземпляр класса, если я правильно понимаю. А смущает именно фраза "каждый член enum это отдельный класс"
Вообще в php давно пользуюсь https://github.com/myclabs/php-enum
который как раз позволяет в контроль тайпхинтингом
"Автор оригинала: Raj Chandel", ясно понятно)
забавно что в статьи нет единственного что там должно быть —
htmlspecialchars($v, ENT_QUOTES, 'UTF-8', true);Ну в том что написано особой разницы нигде почти нет. Но рассмотрены очень базовые вещи. Не рассмотрен очень важный аспект валидации массивов данных в форме. Где придется делать цикл и валидировать каждый элемент отдельно, а где есть для этого специальные возможности. Ну и всякие условные валидации, а так же расширяемость. Вот там либы будут отличаться уже сильнее
В Laravel так же есть такой синтаксис
И помимо этого и указанного выше есть через анонимные функции и инстансы Rule класса.
Просто цитата дня
За счёт Хайпа (простите не удержался)
Не увидел у вас сложных xml файлов, а вот ваш класс имеет отвратительный код (вложенность, длина метода, стиль кодирования, мусорный эхо дебаг внутри класса), и еще более сложную в чтении структуру с кэлбеками обработчиками.
ЗЫ длинную запись
arrayуже так давно не видел, спасибо понастальгировал)да… это точно про Laravel)
Простите, просто глаз зацепился. Безотносительно основной части сообщения.
статью по диагонали читали? автор же пишет что они используют github.com/joho/godotenv и .env файл
Историю изменений такого обычно не ведут (это же всякие пароли и т.п.)
А то что у вас используется
"github.com/joho/godotenv"это несчитово?Мы используем например
"github.com/crgimenes/goconfig"А смысл? Запрашивай джейсон и будет в ответе тебе джейсон. Не понятно желание форса.
тот код что написан в методах контроллера в статье и так короткий. Для чего контроллер делать еще тоньше?
Помимо наличия уровней логирования при вызове логера есть еще и уровень у самого логера выставляя который мы пропускаем запись всего что ниже. Это позволяет нам иметь разную детализацию логов на разном окружении. Я хочу видеть Debug при разработке локально, но не хочу на стейдж сервере (или открытой бетте). Я хочу видеть Warning на стейдж сервере, но на продакшене не хочу. А помимо этого логгеров может быть не один (stdout и sentry например), вызываемые по цепочке, и я хочу там разный уровень логирования. Именно по этому и нужны уровни Warning И Critical (Fatal). Больше уровней — больше пространства для маневра.
Ах да, и эти уровни это стандарт дефакто, на большинстве систем и языков они есть. Снова кто то из го разрабов хочет быть не таким как все...
Обычно на nginx ставят для статики метку кэша очень большую. И тогда на сервер даже запросы не идут.
миграции и deployer
и
чёт какой то диссонанс у меня вызывают эти два предложения.
Так же в начале была озвучена например проблема легаси кода, но как ее решает конвенция непонятно, собственно никак.
Implode.io крут для пользователей Laravel фреймворка.
Надеюсь перейдя на личности вы потешили свое эго и чувствуете себя лучше)
Что же до остального. Не должен никто лазить в хранилище просто так. Или вы все ограничения бизнес логики реализовываете на стороне бд или у вас двойные стандарты. А целостность при падениях приложения обеспечивается использованием транзакций. Вы ведь и так их должны использовать например для защиты целостности при записи в бд. Так что снова двойные стандарты (целостность существования записей вы поддерживаете приложением а целостность отсутствия данных почему то не можете)
за целостностью вполне в состоянии следить само приложение. И не размазывать ответственность между собой и хранилищем.
Тогда и нужно это писать в корректных терминах с ссылками на статьи возможно и указанием возможных других решений, а не в таком дилетантской стиле