Делали уже. Когда сфера вдруг лопается, она создает гигантское облако пузырьков в воде. Все что попало в это облако - лодки, пловцы, просто "проваливаются" на несколько метров вниз, под воду. Получается, надо тотально запрещать судоходсво в этом районе.
Вот это самомнение! Упомянуты какие-то крайние абстрактные случаи без единого примера. Без них создается устойчивое впечатление что автор получил психологическую травму и действительно не умеет работать с базой.
Объектность - это фундаментальное свойство нашего мира, поэтому от ОО подхода никуда не деться. Покажите мне у молотка метод Забить гвоздь. Процессору вообще пофиг, ООП нужно только человеку, который не может удержать фокус внимания больше чем на 7 объектах. ООП зависит от свойств человеческого мозга, а не от реальности.
Условия банков для бизнесов очень сильно отличаются. Поэтому и не надо пытаться предсказать непредсказуемое, реальность Вас удивит.
Тогда давайте Вы не будете мне рассказывать, как его вести. Манипуляции уровня детского сада. Уход от темы, апелляция к авторитету. Не стыдно такое на хабре писать -((
Красивая сказка. В реальности оказалось, что interest_rate меняется динамически в зависимости от ставки ЕЦБ и смысла иметь это поле в таблице CLIENTS нет вообще никакого, там оно только историю изменений засирает. Но так как поле уже есть, а физически удалять поля из таблицы в системе 24*7 это то еще приключение, будет оно висеть вечно, как памятник глупости и самонадеянности...
Oracle RDBMS вообще не монолит - изменения кучи вещей не приводят к необходимости тотальной перекомпиляции - добавление почти всего, изменения тела пакетов и т.д. Для всего остального есть Edition-Based Redefinition.
Монолит - это когда для КАЖДОГО изменения надо пересобирать весь проект, без альтернативы . Видел 1 раз в жизни, это был jar на несколько гигов.
Да, но промпты будут писать аналитики-консультанты, они же будут придумывать данные для тестов, общаться с бизнесом, быть прослойкой , чистые программисты здесь не нужны. Для упоротых 5% случаев будут привлекать фрилансера - узкого специалиста, как впрочем, делают уже сейчас.
"Пожалуйста создай класс который построит балковую диаграмму на основе данных из testDuration.json. Каждая балка должна быть построена как среднее выполнения каждого теста за день. Максимум 30 балок на диаграмме. Подписи снизу в формате dd-mm-yyyy. Вертикальная ось в секундах. результатом должна быть картинка в jpeg."
Это ужасное ТЗ , за которое программист съел бы мне мозг. Не определен размер картинки, надписей, в файле с данными данные по всем тестам в перемешку. ChatGPT создал пару классов, с возможностью опционально исключать failed тесты, сам добавил надписи на график, и самое главное не стал засовывать внутрь чтение из файла. Все за 20 сек и оно заработало сразу.
Уже на этом уровне ChatGPT покрывает 70% задач написания кода.
Ошибки в файлах он тоже прекрасно ищет и исправляет по описанию из тикетов.
Полноценный программист - вымирающий вид. То же ChatGPT уже сейчас пишет неплохой код при подробном детализированном ТЗ - пользуюсь каждый день результатом в целом доволен- особенно если включать туда еще и test cases. Ближайшее будущее за консультантами, которые и с бизнесом могут поговорить, и код могут читать. А вы предлагаете затворничество, которое убьет зачатки когнитивных навыков.
Они. И момент под 70Нм + идеальная развесовка + передачи между мотором и колесом. Не зря все ведущие производители от мотор-колеса отказались. https://www.cube.eu/
Моторколесо на велосипеде - это поза-позавчерашний день. Да еще с весом в аж 30 кг при 422Wh ! Реально как ВАЗ-2104 и Веста. Попробовал бы автор нормальный педелек и был бы в восторге.
Реальная задача: измерять время выполнения тестов. Не должно включаться время потраченное на SSO login и на сохранение playwright скриншотов/видео. Хотелось бы сделать с помощью fixture но login не дает.
В Вашем примере логин происходит не внутри fixture, а внутри теста. И в логе будет отображаться внутри теста и засорять его. Также я не могу использовать loginUser в другой fixture, todoPage , если пользователь будет определен только на уровне теста.
К сожалению, на практике вещь досататочно бесполезная, так как в fixture нельзя передать параметры. Вот здесь хотелось бы задавать разное имя пользователя для каждого теста , но это невозможно сделать адекватным способом. test('Тест с фикстурой loginPage', async ({ loginPage })
Хак с test.use({ login: 'aloha' }) не не будет работать с несколькими тестами.
Хак с передачей парамертов через tag больше похож на злую шутку.
Делали уже. Когда сфера вдруг лопается, она создает гигантское облако пузырьков в воде. Все что попало в это облако - лодки, пловцы, просто "проваливаются" на несколько метров вниз, под воду.
Получается, надо тотально запрещать судоходсво в этом районе.
Вот это самомнение!
Упомянуты какие-то крайние абстрактные случаи без единого примера.
Без них создается устойчивое впечатление что автор получил психологическую травму и действительно не умеет работать с базой.
Вообще обычно платят за решение проблемы, а не за написание кода. Сам по себе код мало кому интересен, даже если ты Джон Ромеро.
Красивая сказка. В реальности оказалось, что interest_rate меняется динамически в зависимости от ставки ЕЦБ и смысла иметь это поле в таблице CLIENTS нет вообще никакого, там оно только историю изменений засирает.
Но так как поле уже есть, а физически удалять поля из таблицы в системе 24*7 это то еще приключение, будет оно висеть вечно, как памятник глупости и самонадеянности...
На грани, но сойдет,
https://ТеплоРасчет.рф/?rid=20250416163020yLqdyes
Oracle RDBMS вообще не монолит - изменения кучи вещей не приводят к необходимости тотальной перекомпиляции - добавление почти всего, изменения тела пакетов и т.д.
Для всего остального есть Edition-Based Redefinition.
Монолит - это когда для КАЖДОГО изменения надо пересобирать весь проект, без альтернативы . Видел 1 раз в жизни, это был jar на несколько гигов.
Да, но промпты будут писать аналитики-консультанты, они же будут придумывать данные для тестов, общаться с бизнесом, быть прослойкой , чистые программисты здесь не нужны.
Для упоротых 5% случаев будут привлекать фрилансера - узкого специалиста, как впрочем, делают уже сейчас.
"Пожалуйста создай класс который построит балковую диаграмму на основе данных из testDuration.json.
Каждая балка должна быть построена как среднее выполнения каждого теста за день. Максимум 30 балок на диаграмме. Подписи снизу в формате dd-mm-yyyy. Вертикальная ось в секундах. результатом должна быть картинка в jpeg."
Это ужасное ТЗ , за которое программист съел бы мне мозг. Не определен размер картинки, надписей, в файле с данными данные по всем тестам в перемешку.
ChatGPT создал пару классов, с возможностью опционально исключать failed тесты, сам добавил надписи на график, и самое главное не стал засовывать внутрь чтение из файла. Все за 20 сек и оно заработало сразу.
Уже на этом уровне ChatGPT покрывает 70% задач написания кода.
Ошибки в файлах он тоже прекрасно ищет и исправляет по описанию из тикетов.
Полноценный программист - вымирающий вид. То же ChatGPT уже сейчас пишет неплохой код при подробном детализированном ТЗ - пользуюсь каждый день результатом в целом доволен- особенно если включать туда еще и test cases.
Ближайшее будущее за консультантами, которые и с бизнесом могут поговорить, и код могут читать. А вы предлагаете затворничество, которое убьет зачатки когнитивных навыков.
Они. И момент под 70Нм + идеальная развесовка + передачи между мотором и колесом.
Не зря все ведущие производители от мотор-колеса отказались. https://www.cube.eu/
Моторколесо на велосипеде - это поза-позавчерашний день. Да еще с весом в аж 30 кг при 422Wh ! Реально как ВАЗ-2104 и Веста.
Попробовал бы автор нормальный педелек и был бы в восторге.
Аквариумисты давно пользуются. Против водорослей и бактерий хорошо помогает.
Вот на основе этого комментария надо было бы статью делать.
Реальная задача: измерять время выполнения тестов. Не должно включаться время потраченное на SSO login и на сохранение playwright скриншотов/видео. Хотелось бы сделать с помощью fixture но login не дает.
В Вашем примере логин происходит не внутри fixture, а внутри теста. И в логе будет отображаться внутри теста и засорять его.
Также я не могу использовать loginUser в другой fixture, todoPage , если пользователь будет определен только на уровне теста.
К сожалению, на практике вещь досататочно бесполезная, так как в fixture нельзя передать параметры.
Вот здесь хотелось бы задавать разное имя пользователя для каждого теста , но это невозможно сделать адекватным способом.
test('Тест с фикстурой loginPage', async ({ loginPage })
Хак с test.use({ login: 'aloha' })
не не будет работать с несколькими тестами.
Хак с передачей парамертов через tag больше похож на злую шутку.
Ага, в отеле на 35 номеров -)))