оно проецируется и на приложени в целом, если сильно упороться и задаться желанием)

ну я к тому что SOLID спокойно можно применять как на уровне проекта/подсистемы так на уровне отдельных функций, не то что файлов (которые в целом в php воспринимать как модуль вполне можно). Идея ж в том что бы каскад изменений уменьшить) а это проще на файлах)

вот только в этом случае такое ограничение приведет к тому что по одной причине надо будет трогать больше файлов)

занятно что если классы объявляются без нэймспейса то тебе не обязательно соблюдать PSR-0/PSR04

ну то есть в целом достаточно предложить новый стандаррт автозагрузки (который фолбэчит до имя нэймспейса -> имя файла) и тогда вообще можно будет волшебные вещи делать

ну то есть в целом достаточно предложить новый стандаррт автозагрузки (который фолбэчит до имя нэймспейса -> имя файла) и тогда вообще можно будет волшебные вещи делать

Отдельный файл - отдельный неймспейс?

Отдельный файл - отдельный неймспейс?

ну типа сначала по имени класса файл ресолвим и затем по нэймспейсу

поскольку composer умеет строить кэш - оверхэд незначительный

а если в php8 сделают prefetch кода то вообще изи бризи. Сегодня можно просто инклудить все файлы в src директории например и все будет работать. Если у тебя соблюдается правило что объявление символов (классы и функции) и сайд эффекты (обработка запроса, вывод в консоль) в разных файлах, что собственно сейчас дефолт

весь нюанс в слове "если")

весь нюанс в слове "если")

не особо, есть opcache

вспомним молодсть, времена зф1) будем собирать 1 монстрофайлик :)

кстате никто с doctrine/annotation 1.6 не регал кастомные анотации ? в версии 2.0 будут масштабные изменения, а в версии 1.6 регать все через AnnotationRegistry есть ли какой способ чтобы работало и версии 1.6 и в 2.0 ?

Нужны идеи :) Есть легаси http апи, нужно как-то документировать. Как бы это сделать так, что бы исключить расхождение кода и апи? Вижу пока какой-то продукт с валидатором и сажать в каждый метод его вызов

вот этв штука норм. обычно если правишь код, правишь каменты заодно http://apidocjs.com/

не вижу возможности валидировать тут... и свои типы хотелось бы описывать

не вижу возможности валидировать тут... и свои типы хотелось бы описывать

json api

у тебя не много вариантов

а там дальше raml, api blueprint, swagger

json schema то есть

ну мне скорее продукт нужен, который даст более-менее из коробки валидировать входные данные

ну мне скорее продукт нужен, который даст более-менее из коробки валидировать входные данные

то есть ты хочешь волшебную штуку которая все сгенерит из кода? найдешь поделись))))

наоборот, описать руками и потом на основе этой схемы валидировать массив данных, что бы если не внес параметр в апи - не смог его увидеть в коде

как иначе избежать рассинхронизации я не вижу...

наоборот, описать руками и потом на основе этой схемы валидировать массив данных, что бы если не внес параметр в апи - не смог его увидеть в коде

описание похоже на swagger

а что он позволяет сделать? ну про описание понятно, что потом на php можно сделать с его описанием посредством его sdk?

т.е. я понимаю, что он может стабы сгенерить по апи, но мне они в общем не очень помогут... я уж скорее все же наделаю DTO, обвешу jms + nelmo и усе

т.е. я понимаю, что он может стабы сгенерить по апи, но мне они в общем не очень помогут... я уж скорее все же наделаю DTO, обвешу jms + nelmo и усе

ну нелмио поверх того же сваггера и работает, так-то)

вся разница в том, где ты схему описываешь и как её визуализируешь) в сваггере это тёплый ламповый jsonчик, в нелмио аннотации)

ну главное что он анотации читает те же, что и jms, идея как бы в этом

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

ну у меня аннотации не прижились. Человеки постоянно забывали менять аннотации :(

у тебя есть экшончек и портянка на 2 листинга с описанием. Чёт такое себе) пугающе выглядит

ну не поменял анотацию - не получил нужный тип данных в DTO...

у тебя видимо много всего на вход шло, а не запакованное в одно DTO?

дтошка в дтошке)

так откуда портянка то

полное описание кодов ответов, групп, тегов и т.д.

зато народ не забывает поправить

а, ясно... ну да в общем, но воспринимай этот контроллер как часть документации, а не кода :) пусть он просто проксирует все экшены в реальный контроллер... ооо... идея

я и так под анализатор код пишу) не хватало ещё опуститься на столько, что бы под документирование код писать...)

а что за анализатор?

а если на основе "документации" генерировать тесты которые говорят актуальна ли твоя "документация" и соответствует ли поведение кода, той документации, по такому принципу они все вроде работают просто какие то тулзы параметры из json,yml берут, а какие то из анотаций и уже когда документация корректно поверх нее генерировать пользовательскую доку

а что за анализатор?

psalm

а если на основе "документации" генерировать тесты которые говорят актуальна ли твоя "документация" и соответствует ли поведение кода, той документации, по такому принципу они все вроде работают просто какие то тулзы параметры из json,yml берут, а какие то из анотаций и уже когда документация корректно поверх нее генерировать пользовательскую доку

лишь бы не работать

"генериться тесты" - это проигрышь. Ну мол, если у тебя достаточно инфы для генерации тестов значит ты можешь просто статически убедиться что у тебя на уровне типов все ок

что логичнее и явно удобнее

я сколько не пытался родить что-то что бы не писать тесты апи больше убедился что тесты api в целом либо бесполезны либо это надо делать по другому (json schema руками описанная или сгенеренная а тесты руками и желательно что бы это была просто валидация респонсов в контексте e2e а не тупо тесты api - так покрытие больше)

ну тут вопрос в том что код одно возвращает, а ручное описание в анотации или json говорит что будет по другому соответственно чтобы не было расхождений надо проверить то что написано в доке а это генерить тест другой вариант на основе теста генерить доку - но такова я не видел нигде

условно есть 3 вещи 1. Реализация 2. Документация 3. Тесты что документация соответсвует реализации мы хотим меньше писать и один из этих пунктов генерировать (ну кроме реализации надеюсь понятно) получается мы либо на основе реализации и ее анотаций создаем доку и проверяем реализацию тестами или на основе тестов доку и тестами проверяем реализацию, ну я пока с набега как то так вижу и кому то удобней одно кому то другому в случае если документация без тестов висит как .... в проруби, то это лишь вопрос времени когда на ее актуализацию забьют и не будут поддерживать - имхо мб есть абстрактные парни которые так не делают

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

psr/logger -> monolog

elk/graylog - перегруз имхо я вообще находил какие-то ui для логов монолога и даже пробовал запустить - но они устарели там

psr/logger -> monolog

Мне бы больше про архитектуру или "бест практис" в плане логгирования) За стандарты и монолог знаю)

Может кто-то даст совет по собственному опыту)

ну зависит от приложения и важности

в catch добавляй логирование исключений

был опыт по настройке отправки некоторых событий на email

Логировать в контроллере? исключения, например

а потом чеовек уволился уведомления слалилсь но ему на почту, поэтому их надо еще и читать

Логировать в контроллере? исключения, например

нет, ну зависит от приложения конечно, но обычно обработка ошибок отдельное место

еще используй ротацию логов - но это совсем капитанство

нет, ну зависит от приложения конечно, но обычно обработка ошибок отдельное место

Я так понимаю, хендлеры ошибок - то самое место

ERROR: S client not available

еще надо подключать мониторинг чтобы логи не загружали сервера и место не заканчивалось особенно если пишутся прямо на том же сервере где и прод

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

пишу всё подряд в stdout и счастлив :)

ну да хорошая практика Guzzle client логировать и всякие soap клиенты

Иногда цепочки вызовов функций логирую

Чтобы прям вообще было понятно что происходит

Иногда цепочки вызовов функций логирую

stack trace ?

еще надо подключать мониторинг чтобы логи не загружали сервера и место не заканчивалось особенно если пишутся прямо на том же сервере где и прод

что имеешь в виду?

что имеешь в виду?

ну например настроил ты такой логирование все работает

а потом бац туда куда пишиши логи закончилось там место

много логов или дебил какой в debug перевел запись логов

и забыл переставить назад

и соответственно места нет могут быть ошибки или долгая запись и тормаза на проде

stack trace ?

Что и с какими параметрами вызывала. К примеру чтобы по ид заявки, можно было видеть что с ней происходило

а потом бац туда куда пишиши логи закончилось там место

Да, а ещё над следить за сроком хранения логов

ну тут вопрос в том что код одно возвращает, а ручное описание в анотации или json говорит что будет по другому соответственно чтобы не было расхождений надо проверить то что написано в доке а это генерить тест другой вариант на основе теста генерить доку - но такова я не видел нигде

ну тут анализаторы типа psalm чуть-чуть погут помочь если подрастут. Они типа удостоверяться что типы в аннотациях и в коде совпадают. дальше уже можно будет проверять по типам соответствие схеме или вообще эту схему генерить, но естественно это будет не так гибко и не так надежно на данном уровне развития

обширная тема конечно

Логировать в контроллере? исключения, например

обычно в листенерах по kernel.exception

Я через рефлексии как-то хотела написать автоматический генератор для доков апи

Но в итоге решили взять готовое и не мучиться

обычно в листенерах по kernel.exception

А в них уже проверять тип исключения? Ну я имею в виду листенеры, которые заточены под определенные виды исключений

а вот кстати такой нубский вопрос про тестирование апи. Тестируется ли изменение стейта приложения при запросах к апи или только респонс? Например добавление яблок в коробку - вернулось что-то позитивное, типа 200, но яблоки в БД в реальности не добавились. Если тестировать стейт приложения - тогда ошибка будет найдена, если нет - тогда не будет. Хотя можно наверное стейт отдельно тестировать, на уровне application service =\

если яблоки не были добавлены, а апи вернуло 200, значит код чем-то дурным пахнет. Не нужно тестировать базу данных. Если сказано "положить" и данные корректны, она схоронит.

а вот кстати такой нубский вопрос про тестирование апи. Тестируется ли изменение стейта приложения при запросах к апи или только респонс? Например добавление яблок в коробку - вернулось что-то позитивное, типа 200, но яблоки в БД в реальности не добавились. Если тестировать стейт приложения - тогда ошибка будет найдена, если нет - тогда не будет. Хотя можно наверное стейт отдельно тестировать, на уровне application service =\

Если сохраняемый объект может быть с невалидными данными - то я бы протестировал, как система может среагировать на них

если яблоки не были добавлены, а апи вернуло 200, значит код чем-то дурным пахнет. Не нужно тестировать базу данных. Если сказано "положить" и данные корректны, она схоронит.

А что если была ситуация когда разработчик при сличение веток затер метод flush()? Все исполнялось коректно, но апишка не сохраняла сущность, хотя в респонсе приходил 200 и сама обновленная сущность Хоть в бд она уже не сохранялась В таком случае это дело уже не тестов?

если яблоки не были добавлены, а апи вернуло 200, значит код чем-то дурным пахнет. Не нужно тестировать базу данных. Если сказано "положить" и данные корректны, она схоронит.

Просто бывают же ошибки типа добавил 2 яблока вместо одного или забыл сохранить uow просто =\

А что если была ситуация когда разработчик при сличение веток затер метод flush()? Все исполнялось коректно, но апишка не сохраняла сущность, хотя в респонсе приходил 200 и сама обновленная сущность Хоть в бд она уже не сохранялась В таком случае это дело уже не тестов?

такое закрывается e2e тестами, сопряжёнными с ректальной карой

такое закрывается e2e тестами, сопряжёнными с ректальной карой

а почему они сопряжены с такой зверской формой экзекуции?)

а почему они сопряжены с такой зверской формой экзекуции?)

by design)

А ещё... А ещё... Можно проверять не изменилось ли состояние остальной части БД после определённой операции, ведь тут тоже может быть ошибка, oh wait! :D