Ну так коммерческий опыт - это одно, а опыт в тестовом проекте это другое.
Опыт, пусть даже коммерческой, разработки за пару дней? Это прям такие волшебные дни должны быть.
Просто мне кажется что проблема в другом - хочется две вещи и обучение за счет работодателя и возможность свалить в любой момент. И захочет ли работодатель оплачивать курсы при таком раскладе?
Ну и если у тебя много собесов и под каждое ты будешь учить технологии
Как я вижу толковых разработчиков не шатает в духе "пойду или на Phyton или на С писать". Как правило стек уже есть или запланирован. Так что не такой большой разброс технологий и будет. Вы же сами написали
"Из-за этого толковые разработчики не могут найти работу, так как стек с прошлого места работы немного не совпадает..."
варианты доучиться его в процессе, если технология учится за пару дней, не рассматривается.
Если "технология учится за пару дней" то почему "толковые разработчики" не могут просто выучить ее за пару дней до собеса? Или все же не пару дней, а пару недель, да еще желательно с курсами?
Странный какой-то этот Дима. Зачем он в первом варианте платит НДФЛ? Неужели чтобы цифра потерь была страшнее чем в последнем варианте? Да не, ерунда какая-то.
А вы хотите чтобы в примере было 50 сущностей, у каждой по 100 свойств? Внимание вопрос - сколько новичков в этой теме дочитало бы такую статью и хоть что-то поняли.
Насчет примера - так я как раз и говорю, что наличие поддержки async в валидаторе сомнительное дело. Понятно, что можно написать обращение к БД или API и синхронно, но это через API валидации не закроешь.
// involve custom userService for specific logic
v.ErrorIf(async m => await userService.IsUserExistAsync(m.Email),
"User already registered", m => m.Email);
Бегать в базу при валидации дорогое удовольствие (хотя бы потому, что после этого запросто может быть еще одна проверка, но уже без обращения к БД. И тогда будет просто трата ресурсов).
Тут вроде как речь про валидацию, а в примере проверка бизнес правила. Как мне кажется, стоит разделять валидацию и проверку бизнес правил. В результате, запрос, который не проходит валидацию, всегда не сможет ее пройти. А вот для бизнес правил результат проверки зависит от текущего состояния системы.
И такое разделение хорошо ложиться на CQRS: command и query валидируется (правлиа можно положить рядом с ними), а бизнес правила проверяются в соответствующих сервисах.
а работник не может использовать созданный им код без разрешения работодателя.
Мне всегда было интересно что это значит. Ну вот работик передал код, где есть строка c "for (i=0; i<max; i++) { ... }". Значит ли что он не может больше писать циклы for? :)))
Утрирую конечно, но вопрос в том, с какого момента начинается "запрещенный к использованию" код? Да и вообще что это такое?
Ок, давайте по порядку тогда
1) По поводу «текущего вида»: это RC2. Считать текущим видом RC1 после 17 мая неправильно. Более того, с января (как я помню) разработчики рассказывали про грядущие изменения. И для кого это произошло внезапно — ну ССЗБ. Более того еще есть и open source на GitHub.
2) По поводу «неизвестно когда»: разработчики обещали RC2 в мае, RTM в конце июня. Первую часть обещания они сдержали. Ждем вторую.
Тогда вопросов нет. Удачи в развитии вашего решения.
Давайте перефразирую - можно ли выделить какую-то фичу, ради который стоит перейти на это решение с opencode и других консольных инструментов?
А можно коротко - в чем главная фича перед использованием opencode или других консольных агентов, когда можно не зависеть от IDE.
Опыт, пусть даже коммерческой, разработки за пару дней? Это прям такие волшебные дни должны быть.
Просто мне кажется что проблема в другом - хочется две вещи и обучение за счет работодателя и возможность свалить в любой момент. И захочет ли работодатель оплачивать курсы при таком раскладе?
Как я вижу толковых разработчиков не шатает в духе "пойду или на Phyton или на С писать". Как правило стек уже есть или запланирован. Так что не такой большой разброс технологий и будет. Вы же сами написали
"Из-за этого толковые разработчики не могут найти работу, так как стек с прошлого места работы немного не совпадает..."
Если "немного не совпадает" то каши не будет.
Если "технология учится за пару дней" то почему "толковые разработчики" не могут просто выучить ее за пару дней до собеса? Или все же не пару дней, а пару недель, да еще желательно с курсами?
Странный какой-то этот Дима. Зачем он в первом варианте платит НДФЛ? Неужели чтобы цифра потерь была страшнее чем в последнем варианте? Да не, ерунда какая-то.
Автор не прав и не ошибается - он набрасывает. Уже первый пункт звучит как - давайте мусор сразу кидать на пол, все равно будет грязно.
А как можно "нечаянно" заменить Role в
publicrecord UserDto(stringId,stringRole,stringEmail);А вы хотите чтобы в примере было 50 сущностей, у каждой по 100 свойств? Внимание вопрос - сколько новичков в этой теме дочитало бы такую статью и хоть что-то поняли.
Насчет примера - так я как раз и говорю, что наличие поддержки async в валидаторе сомнительное дело. Понятно, что можно написать обращение к БД или API и синхронно, но это через API валидации не закроешь.
А только меня напрягает такой код как в примере.
Бегать в базу при валидации дорогое удовольствие (хотя бы потому, что после этого запросто может быть еще одна проверка, но уже без обращения к БД. И тогда будет просто трата ресурсов).
Тут вроде как речь про валидацию, а в примере проверка бизнес правила. Как мне кажется, стоит разделять валидацию и проверку бизнес правил. В результате, запрос, который не проходит валидацию, всегда не сможет ее пройти. А вот для бизнес правил результат проверки зависит от текущего состояния системы.
И такое разделение хорошо ложиться на CQRS: command и query валидируется (правлиа можно положить рядом с ними), а бизнес правила проверяются в соответствующих сервисах.
Мне всегда было интересно что это значит. Ну вот работик передал код, где есть строка c "for (i=0; i<max; i++) { ... }". Значит ли что он не может больше писать циклы for? :)))
Утрирую конечно, но вопрос в том, с какого момента начинается "запрещенный к использованию" код? Да и вообще что это такое?
«Пора убить веб» habrahabr.ru/post/338880
Забавно ведь :)
А «красота» разве не эмоция? Чем плохи эмоции? Ваше раздражение вот тоже эмоция. Причем она дала букв больше, чем «красота» :)
Выдохните, проведите без политики недельку или две. А то везде она вам мерещится.
А с исходным посылом я согласен — «красота». Визуально презентация мне понравилась. И пусть некоторых политически ангажированных от этого плющит.
1) По поводу «текущего вида»: это RC2. Считать текущим видом RC1 после 17 мая неправильно. Более того, с января (как я помню) разработчики рассказывали про грядущие изменения. И для кого это произошло внезапно — ну ССЗБ. Более того еще есть и open source на GitHub.
2) По поводу «неизвестно когда»: разработчики обещали RC2 в мае, RTM в конце июня. Первую часть обещания они сдержали. Ждем вторую.
Это как? Вернутся в прошлое и выключат свет? )