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

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

@Enleur мы тут вчера немного обсуждали тему валидации. Со 2ым пунктом разобрались и все достаточно легко. Насчет первого пообсуждали чутка и всеравно не пришли к единому мнению. Интересно твое мнение, как ты поступаешь в 1 случае?

я сущности не валидирую в основном. валидирую DTO обьекты, а на основе них уже меняются сущности

я сущности не валидирую в основном. валидирую DTO обьекты, а на основе них уже меняются сущности

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

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

или в промежуточном состоянии, что тоже не окей

и что еще хуже будет замаплена 1к1 на форму

А как насчёт варианта проверки old <=> new entity?

Я себе планирую делать и дто валидацию, и по разнице сущностей в итоге

Привет! Я HR 8bitgroup, мы недавно проводили митап с symfoniacs. Может кто помнит. Я в поиске опытных разработчиков Symfony к нам в штат. Успешная рекомендация оплачивается 1 разраб = 25-50к, от уровня грейда Мидл-Синьор-Тимлид Команда от 3-х спецов =100к Наши плюсы - возможен быстрый рост. За год можно вырасти до Тимлида. У нас много проектов. Ниже подробное описание.

Наши плюсы - возможен быстрый рост :D

плюсов больше нет

плюсов больше нет

Ну почему нет) у нас есть плюсы) подробное описание дала

Ну почему нет) у нас есть плюсы) подробное описание дала

"как мы работаем" не описывает как вы работаете, это скорее условия в которых вы работаете.

каков уровень команды

сколько людей

как будет происходить "рост до тимлида"

У нас можно попробовать себя в роли Лида, если такого ещё не было.

p.s. спрашиваю потому что видел прицеденты когда рост до тимлида происходил без какого-либо роста)

как будет происходить "рост до тимлида"

год прошёл - тимлид

А можно ей бан?

"как мы работаем" не описывает как вы работаете, это скорее условия в которых вы работаете.

ну вроде никто не описывет в вакансии, подробности именно процесса. Максимум укажут кнабан/скрам и т.д

Ненавижу когда Эйчары врываются со своими плюшками галеры в чаты

ну вроде никто не описывет в вакансии, подробности именно процесса. Максимум укажут кнабан/скрам и т.д

ну вот прекрасный момент обсудить все с HR

Ненавижу когда Эйчары врываются со своими плюшками галеры в чаты

ну выйди из чата)

Ну камон

Сергей сегодня добрый)) разрешает HR'м писать вакансии

"scrum адаптирован" - под что?)

каков уровень команды

Команда 50 спецов пецов, деление с привязкой к проектам и по частям Backend, FE, QA. Возможность попробовать силы в разных проектах. Опытная и сильная команда. Scrum адаптирован, скрипты. Jira. Нагрузки.

Ненавижу когда Эйчары врываются со своими плюшками галеры в чаты

ну пиши тогда админу донос на нее в письменной форме

Команда 50 спецов пецов, деление с привязкой к проектам и по частям Backend, FE, QA. Возможность попробовать силы в разных проектах. Опытная и сильная команда. Scrum адаптирован, скрипты. Jira. Нагрузки.

окей, на одном проекте какая команда в среднем. длительность проектов

ну пиши тогда админу донос на нее в письменной форме

привет)

Сергей сегодня добрый)) разрешает HR'м писать вакансии

Спасибо )

я на последнем митапе от них зонтик выиграл)

с симфони лого))

Спасибо )

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

перед удалением все ж перенаправить надо

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

в шапке пыхи же

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

https://t.me/fordev

https://t.me/fordev

перед удалением все ж перенаправить надо

Они там уже были)

p.s. спрашиваю потому что видел прицеденты когда рост до тимлида происходил без какого-либо роста)

Сначала надо прокачивать скилы, сопровождает тимлид и техдир. Делимся знаниями. О том, как работаем, подходы в работе рассказывали на митапах, можно в записи посмотреть наших докладчиков. У нас группы по бэкенду по 3/4 разработчика с привязкой к одному большому или нескольким проектам. Все-высокие нагрузки. Мы разрабатываем рекламные сети в основном. Но есть и смежные проекты типа скидочных приложений с криптокошельком например. Работаем с 2012г. Предпочитаем командую работу.

перед удалением все ж перенаправить надо

Спс

Сначала надо прокачивать скилы, сопровождает тимлид и техдир. Делимся знаниями. О том, как работаем, подходы в работе рассказывали на митапах, можно в записи посмотреть наших докладчиков. У нас группы по бэкенду по 3/4 разработчика с привязкой к одному большому или нескольким проектам. Все-высокие нагрузки. Мы разрабатываем рекламные сети в основном. Но есть и смежные проекты типа скидочных приложений с криптокошельком например. Работаем с 2012г. Предпочитаем командую работу.

ну, удачи в поисках)

окей, на одном проекте какая команда в среднем. длительность проектов

3-4 разраба в команде в среднем, Фронт отдельно. Проекты от 0.5 до длительных более года

Scrum используем в облегчённой версии, те не следуем строго всем догмам методологии, но есть скрам-мастер

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

https://t.me/php_jobs

не дурно

меня больше всего в вакансиях умиляет "гибкое начало с 8 до 11" ;) и часто встречаю такое... прям анархия ;)

меня больше всего в вакансиях умиляет "гибкое начало с 8 до 11" ;) и часто встречаю такое... прям анархия ;)

про гибкий конец тоже можно)

имхо - удобно

про гибкий конец тоже можно)

не надо про гибкий конец ((

имхо - удобно

оно то удобно, если твоя команда приходит примерно в одинаковое время для максимизации взаимодействия.

оно то удобно, если твоя команда приходит примерно в одинаковое время для максимизации взаимодействия.

6 часов полного взаимодействия с командой - обычно достаточно

подскажите, где чатик по пхп? Я добрался до причины segfault с gc...

если на протяжении дня требуется больше часа "взаимодействия" - что-то явно не то с планированием ;)

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

p.s. спрашиваю потому что видел прицеденты когда рост до тимлида происходил без какого-либо роста)

Ты видел, а я был таким прицедентом) было забавно

подскажите, где чатик по пхп? Я добрался до причины segfault с gc...

https://bugs.php.net/

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

ну попробуй просто с бектрейсом сунуться

если на протяжении дня требуется больше часа "взаимодействия" - что-то явно не то с планированием ;)

я не о том что бы ВСЮ команду посадить рядом что бы они общались весь день, я к тому что бы чуть что можно было быстро решить проблему. Ты же понимаешь о чем я. А так да, 6-ти часов взаимодействия более чем хватает.

https://bugs.php.net/

унылые они там, сломали молча совместимость в рефлексии 7.0 => 7.1 и фиксить не хотят. боль.

с бектрейсом ещё покомпиливать с dbgsymbols

да и трабла где-то в php-ds

ERROR: S client not available

я не о том что бы ВСЮ команду посадить рядом что бы они общались весь день, я к тому что бы чуть что можно было быстро решить проблему. Ты же понимаешь о чем я. А так да, 6-ти часов взаимодействия более чем хватает.

т.е. отвлечь коллег, переключить их со своего контекста на свой и решать проблему ;) я понимаю... но это так, миф, не должно такого быть... если у тебя проблема, которую ты не можешь решить - таск система в твоем распоряжении. А если проблемы такие, что "нужно срочно иначе а-а-а-а", то это уже не скрам ;) 1-2 часа, причем жестко фикстированных, типа с 3 до 5 - вполне должно хватать

ну в идеальном мире, да... но hr же нам его пытается показать ;)

т.е. отвлечь коллег, переключить их со своего контекста на свой и решать проблему ;) я понимаю... но это так, миф, не должно такого быть... если у тебя проблема, которую ты не можешь решить - таск система в твоем распоряжении. А если проблемы такие, что "нужно срочно иначе а-а-а-а", то это уже не скрам ;) 1-2 часа, причем жестко фикстированных, типа с 3 до 5 - вполне должно хватать

чего быть не должно? все должны составить идеальный план и что бы небыло никаких проблем? big upfront design?

ну под big я имею ввиду на 2 недели например напроектировать ближайшие

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

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

взаимодействие qa <-> dev?

взаимодействие dev <-> product owner?

и почему это dev <-> dev не могут на дэйли договориться поработать вместе?

джира, не? ;)

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

джира, не? ;)

окей. У тебя есть баг в джире и ты не можешь его воспроизвести

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

это затруднительно если человек который нужен уходит через 2 часа домой а второй еще 6 часов будет тусить

короч, ты как всегд ниочем

это затруднительно если человек который нужен уходит через 2 часа домой а второй еще 6 часов будет тусить

нужно больше двух часов? договорились, или один в этот день пораньше пришел, или другой попозже ушел

окей. У тебя есть баг в джире и ты не можешь его воспроизвести

я его возвращаю с комментариями "не могу воспроизвети"

я его возвращаю с комментариями "не могу воспроизвети"

и вы играете в пинг понг вместо того что бы решить вопрос

так делают большинство

и все в сумме то что ты в упрощенном виде описываешь снижает деливери

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

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

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

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

если так - то нет, это не так ;) глубоко...

если так - то нет, это не так ;) глубоко...

перефразирую, я не это имел ввиду и незачем искажать то что я говорю и операться в дискуссии исключительно на свои предположения не проверив их

а если следовать твоей логики, то qa должен найдя баг нестись к разработчикам "ребята, я баг нашел! посмотрите быстрее"

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

а если следовать твоей логики, то qa должен найдя баг нестись к разработчикам "ребята, я баг нашел! посмотрите быстрее"

нет, речь идет о маленьком проценте кейсов. БОльшую часть из которых можно решить на дэйли. И что бы дэйли был не в середине рабочего дня - лучше что бы люди приходили максимально в одно время (может с разбежкой в 2 часа) дабы быстрее дать возможность выстроить план работ. Или же опять же чатики и т.д. как способ координации. Я не предлагаю "бросать все", я предлагаю варианты при которых тебе не придется ждать день для получения ответа. Хотя иногда так и будет.

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

ясно понятно. У нас с тобой совершенно разный вижен эффективной работы команды

а что плохого в митинге в середине дня?

а что плохого в митинге в середине дня?

не, я уже подумал что в целом это не важно когда он

главное что бы этот митинг не ломал контекст сильно

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