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

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

а ну если так то да, тогда норм

ну вот расскажи как тебе помогают эти штуки для аутентификации?

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

fos rest постремнее, да... не скажу, что он очень нужен.... но и не особо мешает в общем...

не без проблем, конечно, но ничего глобально проблемного

У тебя модели в сваггере есть?

Я тоже с jms и fos rest не испытывал проблем, наверное задач таких нет, но вот как столкнусь (если столкнусь), тогда и буду выкидывать старые инструменты и брать новые. Пока что это все колосально экономит время как на разработку так и на поддержку.

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

Подскажите как решить такую проблему.

у меня в конструктор ApiAuthenticationProvider предается зависимость UserProviderInterface $userProvider. При определении сервиса эта зависимость просто удаляется

Я тоже с jms и fos rest не испытывал проблем, наверное задач таких нет, но вот как столкнусь (если столкнусь), тогда и буду выкидывать старые инструменты и брать новые. Пока что это все колосально экономит время как на разработку так и на поддержку.

а когда говоришь о экономии, есть реальная статистика и сравнение с другими вариантами?)

и невозможно сделать replace

а когда говоришь о экономии, есть реальная статистика и сравнение с другими вариантами?)

Экономия как минимум в том, что что то другое надо изучать и ковырять, а тут готовое решение с кучей примеров и ответов на стековерфлов. Я уверен, что на го я бы апи пилил и быстрее и качественнее, но проверять сильно затратно?

Экономия как минимум в том, что что то другое надо изучать и ковырять, а тут готовое решение с кучей примеров и ответов на стековерфлов. Я уверен, что на го я бы апи пилил и быстрее и качественнее, но проверять сильно затратно?

ну то есть экономия чисто в воображении и реальной статистики нет. Принято

ну то есть экономия чисто в воображении и реальной статистики нет. Принято

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

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

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

если что я использовал и fos rest и jms и т.д

и за 6 лет попробовал как минимум 3 совсем разных подхода

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

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

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

Это сугубо ваша статистика положенная на ваш опыт, а то что это будет так у всех у вас тоже статистика имеется?

Кому то sf вообще неудобен весь и что теперь? :) Так что надо отталкиватся от решения задачи, а не от как бы задачу подстроить под инструмент. Но это мое имхо))

Это сугубо ваша статистика положенная на ваш опыт, а то что это будет так у всех у вас тоже статистика имеется?

если под "ваш" это команда с которой я работаю - то да. Статистика - сухие цифры по стоимости разработки и внесению изменений. За время пока я "балуюсь" разными подходами их уже человек 30 попробовало вместе со мной. И это не "мнение одного члоевека", мы типа комндой такие вопросы решаем

Кому то sf вообще неудобен весь и что теперь? :) Так что надо отталкиватся от решения задачи, а не от как бы задачу подстроить под инструмент. Но это мое имхо))

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

меня лишь это задевает

утверждения без проверки

если под "ваш" это команда с которой я работаю - то да. Статистика - сухие цифры по стоимости разработки и внесению изменений. За время пока я "балуюсь" разными подходами их уже человек 30 попробовало вместе со мной. И это не "мнение одного члоевека", мы типа комндой такие вопросы решаем

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

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

опять же это все голые предположения и т.д.

и я не говорю о "правильности", я лишь говорю про "вымышленную экономию"

по моей статистике именно варианты как ты работаешь с json и сериализуешь/десериализуешь вообще не влияют хоть сколько нибудь на производительность команды

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

факт

и у меня были проблемы когда простой crud который хорошо ложится на jms превращается... в не простой круд

и я не говорю о "правильности", я лишь говорю про "вымышленную экономию"

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

который уже очень плохо ложится на jms

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

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

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

Экономит, до тех пор пока зказчик не топнул ножкой и не сказал, что нужно вот такую бизнес-логику реализовать. Причем срок - вчера.

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

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

а срок всегда вчера

бизнес не забоит то как ты делаешь проект

ага

а на больших проектах и послать нельзя

и в итоге сидят ребята с рваной жопой на решении которое долго переделать

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

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

Экономит, до тех пор пока зказчик не топнул ножкой и не сказал, что нужно вот такую бизнес-логику реализовать. Причем срок - вчера.

А может и не топнет, а может там вообще приложение будет использовать сам заказчик 5 минут, а может 100500 человек, давайте сначало задачу обозначим а потом будем решение придумывать, а не наоборот

и когда кто-то говорит о "экономит время" должно следовать "по сравнению с тем-то тем-то"

все верно - для каждой ситуации - свое решение

А может и не топнет, а может там вообще приложение будет использовать сам заказчик 5 минут, а может 100500 человек, давайте сначало задачу обозначим а потом будем решение придумывать, а не наоборот

слабые предположения это одно из тех вещей по которым проваливаются проекты

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

Да, сравниваю от найтив JsonResponse и сборки ручками

Да, сравниваю от найтив JsonResponse и сборки ручками

как именно происходит "сборка ручками"?)

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

слабые предположения это одно из тех вещей по которым проваливаются проекты

А как же YAGNI ?

А как же YAGNI ?

ну так ты как раз и нарушаешь)

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

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

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

добро пожаловать в рынок лэндингов

Почему? Если я не знаю что будет в будущем, то мне лучше использовать то, что будет быстро сделано в настоящем, разве нет?

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

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

иначе работает простые факторы психологии, мы плохи в выражении своих желаний и мыслей

Он же гласит, что не надо пытаться угадать будущее.

и еще хуже в интерпритации требований

ERROR: S client not available

именно по этому развивается вся эта agile движуха

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

Так не бывает. :)

Он же гласит, что не надо пытаться угадать будущее.

+1 я видел как угадывающие программисты годами затягивали сроки и не сдавали проекты

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

Требования меняются. Это бизнес. Какие-то решения не работают. Их надо менять.

+1 я видел как угадывающие программисты годами затягивали сроки и не сдавали проекты

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

Разве? :)

ну не ты

он

"Тебе это не понадобится" - и подразумевается что "все будет хорошо"

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

я делаю ставку что этого до определенного момента будет достаточно

А если не будет, то решай проблемы по мере поступления.

я делаю ставку что этого до определенного момента будет достаточно

а что потом?

вот прошло пол года и для проекта этого уже недостаточно

переписать все?

а что потом?

а потом новые требования и новые разработки

а потом новые требования и новые разработки

к тебе приходит проект с jms где тупо круд

Ну задел должен быть. Но фос юзер не будет проблемой заменить же.

и вот тебе надо сделать механизм ревизий специфичный с апрувами изменений

Ну задел должен быть. Но фос юзер не будет проблемой заменить же.

вообще-то будет)

переписать все?

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

Сеоиалайзер конечно сложнее будет заменить, но тоже можно.

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

я не делаю предположений и оставляю пространство для моневра

вообще-то будет)

Наверно у меня не было какой-то ядреной авторизации. :)

Наверно у меня не было какой-то ядреной авторизации. :)

да нет. банальность. Тебе надо запилить в fos user bundle фичу что бы пользователи при смене пароля например не могли заюзать тот который они уже юзали 5 раз подряд

и потом добавить к этому словарик с популярными паролями

типа черного списка

Вот тут я и заменю его на самодельный. :)

у меня это будет 1 новый сервис и строк 10 кода, а у тебя боль с конфигурацией