К старой системе прилагаются старые программисты, которым работать с запросами гораздо проще чем делать вызовы REST API
Звучит как абсурд. В вашей задаче может быть смысл, но не понимаю где можно найти программиста, для которого интеграция REST - сложная задача сама по себе. + есть же готовые библиотеки
Ну и вы же ответ от модели будете ждать в транзакции, а они бывают не быстрые...
короткий пароль перебирается, хэш сравнивается. По этому хэш pan банковских карт хранить надо также шифрованным, например, особенно рядом с маской. Мало цифр + алгоритм луна сужает доступные. Короче перебор возможен
вы просто не видите всю ситуацию целиком. Возможно визуальных инструментов хватает для конкретно ваших задач, что не делает их достаточными для большинства случаев. И уж тем более вы не сталкивались с ситуацией
"тут почти как надо, только мой инструмент не позволяет мелочь X"
"чтооо?! почему 2 мемяца разработки?! Оно же работает ПОЧТИ как надо, нужна всего 1 кнопка!!!"
Универсальные решения или позволяют решить узки спектор задач, или на столько сложны, что зачастую проще написать свое решение узкой задачи, чем настраивать монстров.
Айтишных контор слишком много что-бы описанный вами заговор был возможным. Если продукт действительно нужен платежеспособной аудитории - он бы был успешен
Есть знакомые, которых ГУБОПиК РБ убедил в том, что они не дурачки, и 2 пароль знают.... хотя до задержания они говорили ровно как вы. Я бы на вашем месте не слишком надеялся на такие схемы
Там ещё и по налогам выгодно выйти, если не живёте там, и прочих проблем там хватает, в том числе, с внешней политикой, но это же классическое "а там негров линчуют". Автор же не заявлял, что в других странах нет смысла выходить с гражданства.
С ООП головного мозга сложность - вообще не проблема, что и показал автор.
Неужели вы не видели примеров, когда нужно создать фабрику через билдер, в фабрику передать аргументы каждый своим билдером, а результатом будет новый билдер, который надо передать...
В общем-то слепое следование догматам никогда ни к чему хорошему не приведёт
У меня обычно микросервисы не честные, например. Связанны через БД.
У каждой данные в своей схеме, но естественно с fk, чтобы не ходить в чужие схемы внаглую, обычно делаю view в схеме сервиса.
Много головной боли по поводу консистентности снимается. При этом приложения маленькие, логика изолирована, горизонтальное масштабирование возможно.
Ведь главная проблема микросервисов не сетевые задержки, а распределенные транзакции, эвеншал консистанси и косяки с этим связанные. Система усложняется кардинально.
В общем кактусы есть, нету колючек.
Плюс в том, что базовая часть "микро" сервисов превратилась в библиотеки, подключаемые к конкретному проекту и немного кастомизируемая под конкретные задачи. Например профиль, или Api Gateway.
а зачем обкладываться дополнительными, протекающими абстракциями, нюансы которых надо знать в дополнение к знаниям о работе БД и SQL (а иначе вы не сможете анализировать проблемы производительности и строить адекватную схему БД), когда уже есть старый добрый SQL?
А будет какое-то обоснование "сервисы должны взаимодействовать только через интерфейсы"? Что-то кроме "так правильно"? Бесполезный Heder Interface просто повторяющий паблик-методы это же так чистокодно!
К старой системе прилагаются старые программисты, которым работать с запросами гораздо проще чем делать вызовы REST APIЗвучит как абсурд. В вашей задаче может быть смысл, но не понимаю где можно найти программиста, для которого интеграция REST - сложная задача сама по себе. + есть же готовые библиотеки
Ну и вы же ответ от модели будете ждать в транзакции, а они бывают не быстрые...
Я "уже" документирую вручную.
К сожалению автогенерация не учитывает всех нюансов DTOх, типа сериалайзеров и т.д.
вопрос в том, действовал ли AI полностью автономно и какой промпт/тз давали
короткий пароль перебирается, хэш сравнивается. По этому хэш pan банковских карт хранить надо также шифрованным, например, особенно рядом с маской. Мало цифр + алгоритм луна сужает доступные. Короче перебор возможен
и часто в crudах новые алгоритмы изобретают?
и алгоритм он новый выдать может
вы просто не видите всю ситуацию целиком. Возможно визуальных инструментов хватает для конкретно ваших задач, что не делает их достаточными для большинства случаев. И уж тем более вы не сталкивались с ситуацией
"тут почти как надо, только мой инструмент не позволяет мелочь X"
"чтооо?! почему 2 мемяца разработки?! Оно же работает ПОЧТИ как надо, нужна всего 1 кнопка!!!"
Универсальные решения или позволяют решить узки спектор задач, или на столько сложны, что зачастую проще написать свое решение узкой задачи, чем настраивать монстров.
Айтишных контор слишком много что-бы описанный вами заговор был возможным. Если продукт действительно нужен платежеспособной аудитории - он бы был успешен
Центробанки и биток скупают
Есть знакомые, которых ГУБОПиК РБ убедил в том, что они не дурачки, и 2 пароль знают.... хотя до задержания они говорили ровно как вы. Я бы на вашем месте не слишком надеялся на такие схемы
Там ещё и по налогам выгодно выйти, если не живёте там, и прочих проблем там хватает, в том числе, с внешней политикой, но это же классическое "а там негров линчуют". Автор же не заявлял, что в других странах нет смысла выходить с гражданства.
ну, это же шутка, я надеюсь, никто же не станет писать такое в проде
С ООП головного мозга сложность - вообще не проблема, что и показал автор.
Неужели вы не видели примеров, когда нужно создать фабрику через билдер, в фабрику передать аргументы каждый своим билдером, а результатом будет новый билдер, который надо передать...
В общем-то слепое следование догматам никогда ни к чему хорошему не приведёт
могут быть вариации же.
У меня обычно микросервисы не честные, например. Связанны через БД.
У каждой данные в своей схеме, но естественно с fk, чтобы не ходить в чужие схемы внаглую, обычно делаю view в схеме сервиса.
Много головной боли по поводу консистентности снимается. При этом приложения маленькие, логика изолирована, горизонтальное масштабирование возможно.
Ведь главная проблема микросервисов не сетевые задержки, а распределенные транзакции, эвеншал консистанси и косяки с этим связанные. Система усложняется кардинально.
В общем кактусы есть, нету колючек.
Плюс в том, что базовая часть "микро" сервисов превратилась в библиотеки, подключаемые к конкретному проекту и немного кастомизируемая под конкретные задачи. Например профиль, или Api Gateway.
а зачем обкладываться дополнительными, протекающими абстракциями, нюансы которых надо знать в дополнение к знаниям о работе БД и SQL (а иначе вы не сможете анализировать проблемы производительности и строить адекватную схему БД), когда уже есть старый добрый SQL?
солидарен, тоже пользуюсь подпиской Bitwarden, удобство - супер
а ещё есть kotlin скрипты...
зависит от языка, Mockito в java/kotlin позволяет делать моки даже финальных классов
А будет какое-то обоснование "сервисы должны взаимодействовать только через интерфейсы"? Что-то кроме "так правильно"? Бесполезный Heder Interface просто повторяющий паблик-методы это же так чистокодно!
а маки современные разве умеют в ntfs?! В чем универсальность?
Не оговорены минусы:
1)Отсутствие возможности передать null
2)Тут зависит от экосистемы, но для java/kotlin плагины гугла генерируют весьма и весьма своеобразные DTO, с которыми работать крайне многословно
так вы по своей воле нарушили границы другого государства (предполагаю вы ездили не через Украину и без получения разрешения), ситуация иная.
П.С. Видимо после этого комента карма профиля уже не даст ничего писать, прощайте! 😅