работает нормально

У DI extra можно отрубать как то по директориям

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

переписал с systemd -работает огонь

У DI extra можно отрубать как то по директориям

сейчас проверил - DIExtra в AppKernel нет

и работает нормально

это нужно только для админки

которая кстати такое себе

Админка там как круд обычный?

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

ну и отложенные задачи из коробки

для новых проектов, особенно middle size + явно не советовал бы, потому что мейнтейнера не достать, для небольших проектов уже существующих - лучшее из имеющегося

JMSJobQueueBundle кто нибудь юзает?

юзаю вместо него bernard

Юзал JMSJobBundle Нет в нем ничего подозрительного :) Кроме самой идеи хранить очередь в базе, конечно

Bernard намного лучше в этом смысле, ибо storage agnostic, но реализация не очень (вместо нормальных интерфейсов какая-то муть, не описанная толком в документации)

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

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

ну или доработать что-то что найду на гитхабе еще

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

RabbitMQ, Redis

я beanstalkd юзаю

RabbitMQ != очередь задач

ну то есть я кролика юзаю как замену вэбхукам

типа надежная маршрутизация и доставка сообщений

Я понимаю, что он не очередь сам по себе, а брокер, просто видел бандл под это дело

есть просто работа с amqp

а что ты делаешь с ним - пофигу

есть еще http://nsq.io/

но это именно для оргенизации шины данных между сервисами например

для синхронизации данных скажем

ну мол как замена кролику

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

От создателя Redis он

Может кому пригодится, кстати: http://queues.io

да. хорошая подборка

блин я совсем разучился работать без ORM

(

решил ради эксперемента поработать чисто с dbal и хз как организовать код

давно такого тупняка небыло

Кстати, а вы тестите формтайпы?

Кстати, а вы тестите формтайпы?

а зачем?

Вот она, собствено

По-хорошему надо всё тестировать, конечно, чтобы code coverage 100% (я даже работал в проекте, где так было – это очень удобно)

http://symfony.com/doc/current/form/unit_testing.html

а так - какой-нибудь позитивный кейс

Кстати, а вы тестите формтайпы?

не юзаю форм тайпы - но если бы юзал - то всеравно нет смысла их покрывать юнит тестами. Дата трансформеры, листенеры и т.д. смысл покрывать есть

интеграционным

По-хорошему надо это делать. Работал в проекте одном, там был code coverage 100% - это просто прекрасно с точки зрения удобства и надежности разработки.

Что-то телеграм залип и перепутал порядок сообщений

Мне кажется в кукбуке была статья про это

/stat@combot

@kozlice читал этот раздел, да)

combot.org/chat/-1001091570538

Ага)

Дуров, верни мессаджинг в реал-тайме

а зачем?

Тут есть много кейсов. Например, если в FormType набор полей зависит от ролей пользователя

Тут есть много кейсов. Например, если в FormType набор полей зависит от ролей пользователя

а почему не сделать несколько отдельных классов в таком случае?

Если более детально: есть некая сущность, у которой, скажем, 20 полей, и 2 из них могут править только админы, если это присылает обычный юзер – просто игнорируем

Тут есть много кейсов. Например, если в FormType набор полей зависит от ролей пользователя

короч любой кейс где есть логика в форм тайпах)

Да

Если более детально: есть некая сущность, у которой, скажем, 20 полей, и 2 из них могут править только админы, если это присылает обычный юзер – просто игнорируем

тут лучше два форм тайпа, один расширяет другой

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

тестировать всякие трансформеры можно

Если они будут расширять, то это надо в контролере делать условие "если админ, то TypeA, если нет – то TypeB". Получается как-то сложнее даже

Если они будут расширять, то это надо в контролере делать условие "если админ, то TypeA, если нет – то TypeB". Получается как-то сложнее даже

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

SRP-compatible вроде

Тоже вариант

ERROR: S client not available

Если они будут расширять, то это надо в контролере делать условие "если админ, то TypeA, если нет – то TypeB". Получается как-то сложнее даже

зато теперь формы не знают о контексте использования

а условия их контроллеров легко удаляются в стратегию

я такую ошибку с трансформерами для фрактала сделал

аля

есть 20 полей и только админам надо экспоузить еще 2

сразу было вроде бы удобно

но через 2 месяца это все превратилось в ад

по итогу в проекте все еще есть десяток трансформеров с логикой внутри

Да, тут есть варианты альтернативные как решить. Но возвращаясь к вопросу писать ли тесты к форм тайпам - я бы даже в случае когда логики нет это делал. Если coverage 100% и git push нельзя сделать без этого, не боишься ничего поломать случайно где-то в темном углу. Обновление зависимостей перестает быть болью

Да, тут есть варианты альтернативные как решить. Но возвращаясь к вопросу писать ли тесты к форм тайпам - я бы даже в случае когда логики нет это делал. Если coverage 100% и git push нельзя сделать без этого, не боишься ничего поломать случайно где-то в темном углу. Обновление зависимостей перестает быть болью

а что бы ты проверял?

coverage 100% - это и геттеры\конструкторы покрыты?

coverage 100% - это и геттеры\конструкторы покрыты?

coverage 100% можно сделать без единого ассерта, толку от этого нет. Так же не стоит забывтаь что 100% коверадж кода != 100% коверадж тест кейсов

это пожалуй один из самых бесполезных показателей

поэтому я люблю phpspec, там этого нет

поэтому я люблю phpspec, там этого нет

есть же плагин)

Проверял бы, что форма возвращает isValid == true и объект имеет ожидаемые значения

но там сложно тестить ненужное)

Проверял бы, что форма возвращает isValid == true и объект имеет ожидаемые значения

а причем тут формы?

$validator->validate($invalidData)

В API удобно использовать: берешь входящие данные из request (которые просто assoc array)

И через форму популируешь поля сущности

В API удобно использовать: берешь входящие данные из request (которые просто assoc array)

я валидирую сам этот assoc array

ну то есть логика такая

для кого ты делаешь валидацию входящих данных в API?

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

Валидацию я обычно через аннотации делаю

Валидацию я обычно через аннотации делаю

пофигу, вопрос что ты валидируешь, входящие данные (запрос) или же промежуточный результат

Поэтому удобнее через FormType

Поэтому удобнее через FormType

ты просто скажи зачем ты делаешь валидацию

с какой целью

убедиться что клиент прислал то что надо или же убедиться что ты не накосячил?

клиенту полезнее первое и это он не получит когда валидируются сущности