"я ограничен $120-ми на все запросы к API в месяц" - https://github.com/abetlen/llama-cpp-python Вот (возможно) можно попробовать для демо версии или для прода, если качество приемлемое.
Чтобы иметь возможность реализовывать вашу бизнес-логику на бекенде и ваш пользователь не открывал вам ключ, вы можете сделать так, чтобы запросы к апиай чата-джипити отправлял программный клиент (фронтенд), например браузер. Бекенд может "просить" фронтенд выполнить тот или иной запрос. Это можно сделать с помощью подхода Inversion Of Control - бекенд отправляет сообщение фронтенду с тем или иным заданием, фронтенд выполняет задание и отсылает ответ обратно бекедну. Запрограммированить это можно с помощью SSE + REST или WebSocket. Монетизацию можно делегировать какому-нибудь стороннему облаччному сервису - можно погуглить на эту тему или спросить у чатаджипити, как лучше поступить или синтегрировать вашу программу, например с пейпалом или страйп или другим пеймент провадером и продавать ваш продукт по подписке.
Можно попробовать сделать проксирование запросов. С серверной стороны (бекенда) можно посылать команды клиенту выполнить тот или иной запрос к овпенэйай и отправить запрос на ваш сервер. Как пример, сервер отправляет команду на клиента с помощью Server Sent event, клиент обращается в openai api и затем возвращает результат серверу путем REST вызова на вашему бекенду. Таким образом вы делегируете клиенту обращение к апиай чата джипити не имея доступа к клиентским ключам. Это один из других возможных способов как, например запуск прокси на локальном компьютере пользователя в виде веб сервера или написания расширения для гугл-хрома. Что касается монетизации, вы можете рассмотреть продажу вашего сервиса путем размещением вашего апиай на каком-нибудь апиай-маркетплейсе или монетизацию через рекламу или донаты.
Да, можно выгрузить набор данных из базы данных используя язык запросов SQL, потом сохранить данные в формате CSV и открыть в Excel с целью последующего анализа.
Указанные выше операции являются ручными, то есть, чтобы получить новый Excel файл, нужно пподелать эту работу снова. Если нужно сформировать набор данных состоящий из нескольких выборок, то нужно сделать больше работы. Когда необходимо что-то сделать еще с полученными данными или послать данные кому-то или делать задачу на регулярной основе, в голову приходит мысль автоматизировать процесс подготовки данных.
Идея сервиса автоматизировать и упростить процесс получения данных.
В ядро сервиса заложена функциональность пост-обработки полученных данных, например очистка описаний товаров от HTML тегов и другое.
При необходимости предоставлять данные "наружу" можно сделать простейший сайт, использующий ресурсы сервиса выгрузок. Есть идея создать "хранилище моделей выгрузок". В таком случае сайт делать не придется: создали модель и расшарили ееобходимый URL потребителям данных.
Данный сервис отличается от "других плагинов", тем, что позволяет определять свою логику выгрузки с использованием языка запросов SQL. SQL запрос является шаблоном, с возможностью менять части запроса динамически, в зависимости от логики вашей выборки. На базе данного сервиса вы можете создать много вариантов выборок данных, которые соответствуют вашим правилам. Результаты выгрузки данных из вашего магазина или из магазина вашего заказчика может являться входными данными для дальнейших преобразований данных.
Да, сервис делает выгрузку товаров, и не только товаров и их зависимостей, а вообще любую выборку данных, находящихся в базе данных магазина через API. Отличается от "обычного модуля экспорта" возможностью задавать алгоритм выгрузки на языке SQL. Нужно тем пользователям (и программистам), которым гибкости "обычного модуля выгрузки" не хватает, там где удобнее, легче и проще (с точки зрения программиста) использовать SQL. Сервис представляет из себя ETL движок. Как происходит Выгрузка. На первом шаге задается один или более SQL запросов. На втором шаге определяются поля и их типы (строка, число, дата, время). На третьем шаге задаются условия связи наборов данных определенных на первом шаге. Такой подход позволяет облегчить работу программиста. Управлять полями можно программно - запрос с описанием шаблона и его параметров представлен в виде JSON. Почему это на шаг впереди, чем "обычный REST API"? Это следующий шаг после получения данных по REST. Сервис на себя берет функцию ETL, программист определяет "что нужно получить", а не "как обработать результаты, возвращенные через 'обычный' REST". Это не бесплатно. На текущий день пользование сервисом стоит $10 за 500 выгрузок в месяц. Если есть дополнительные вопросы, или что-то не ясно пожалуйста спрашивайте.
1) Улучшенный дизайн выглядит подозрительно с точки зрения создания юнит-тестов. У вас есть юнит-тесты? Не интеграционные, а именно юнит-тесты. Написание тестируемого кода накладывает "ограничения" на дизайн. Отсутствие репозитория сразу бросается в глаза, как это тестировать.
2) Декоратор, который приведен в статье мог использоваться для "быстрого фикса", с последующим рефакторингом, то есть возвращению обратно к простому дизайну.
3) Стиль дизайна определяется плотностью запросов реализации новых фич (требоаний, реквариментов), выше плотность - больше паттернов/компонентов. Чем размельченнее код, тем время внедрения новых фич в код более линейно, или даже еще лучше. Характер заказчика играет в этом роль.
4) Граница между разными сервисами проходит там, где можно выделить независимую и заменяемую часть логики.
5) "потому что ты не знаешь непосредственно, какой конкретно код будет исполняться. Тебе сначала нужно проверить, какие реализации существуют в интерфейсе, а затем разобраться, какая конкретно применяется во время исполнения." - интерфейс вводится для того, чтобы "не знать", какая будет реализация - важен контракт использования.
Преимущества REST: простота, ориентация на человека. За это любят REST. Бинарные протоколы и до этого существовали, например Hessian. Более сложные технологии до этого существовали, например "Веб Сервисы". Чтобы работать с рест не обязательно использовать "Стороннее программное обеспечение", но есть инфраструктура, делающая REST "больше чем протокол". Простота, не зависимость, открытость для людей и машин - главная идея REST.
11.1: JUnit-тесты очень желательны. Можно не делать 100% покрытие, только основные сценарии - junit тесты надо писать без поднятия контекста. С поднятием контекста - это лучше относить к интеграционным тестам. Почему? Потому, что тесты с контестом работают медленно, лучше мказать медленно поднимается контекст. Тесты дата-лейера тем более это интеграционные тесты. Как писать на спринге и не поднимать его в юнмт тестах? надо использовать библиотеку моков, например мокито.
10.2: Проверяйте входные данные Primary Key при create/update в контроллерах. - этим может заниматься база данных, а Джава (слой данных) возбуждать исключение и возврвщать клиенту, например "бэд реквест". Без блокировки не существующих записей (да, это можно сделать) это не сделать консистентно, либо нужно изменять уровень изоляции транзакций, а это уменьшает масштабируемость приложения. Проще на это не обращать внимание, за вас сделает эту работу база данных и джпа/спринг.
8.2: Я предпочитаю четкое разделение ролей на основе URL. Например, для админа URL содержит /admin - спорное утверждение, не имеющее отношения к праыильному выполнению тестового задания.
7.6: Таблицы я предпочитаю именовать в единственном числе. Исключение - users, т. к. user - зарезервированное слово - order и другие также лучше в множественном.
7.5: Поля базы case insensitive, не пишите camelStyle - в обратных одинарных кавычках для мариядэбэ или майскл кейс сенситив, для оракла в двойных кавычках уейс сенситив, для мсскл в квадратных скобках кейс сенситив. поля можно указать в маппинге сущьностей. Поля кейс сенситив...
6.4: Обновление в базе делается через update - не стоит смешивать JPA и DAO. апдейт делать не надо и сейв загруженного POJO также не надр - достаточно лишь изменить поля на необходимые значения, остальную работу сделает JPA. JPA и есть "паттерн".
Вот здесь можно попробовать некоторые: https://chat.lmsys.org/
"я ограничен $120-ми на все запросы к API в месяц" - https://github.com/abetlen/llama-cpp-python Вот (возможно) можно попробовать для демо версии или для прода, если качество приемлемое.
Чтобы иметь возможность реализовывать вашу бизнес-логику на бекенде и ваш пользователь не открывал вам ключ, вы можете сделать так, чтобы запросы к апиай чата-джипити отправлял программный клиент (фронтенд), например браузер. Бекенд может "просить" фронтенд выполнить тот или иной запрос. Это можно сделать с помощью подхода Inversion Of Control - бекенд отправляет сообщение фронтенду с тем или иным заданием, фронтенд выполняет задание и отсылает ответ обратно бекедну. Запрограммированить это можно с помощью SSE + REST или WebSocket. Монетизацию можно делегировать какому-нибудь стороннему облаччному сервису - можно погуглить на эту тему или спросить у чатаджипити, как лучше поступить или синтегрировать вашу программу, например с пейпалом или страйп или другим пеймент провадером и продавать ваш продукт по подписке.
Можно попробовать сделать проксирование запросов. С серверной стороны (бекенда) можно посылать команды клиенту выполнить тот или иной запрос к овпенэйай и отправить запрос на ваш сервер. Как пример, сервер отправляет команду на клиента с помощью Server Sent event, клиент обращается в openai api и затем возвращает результат серверу путем REST вызова на вашему бекенду. Таким образом вы делегируете клиенту обращение к апиай чата джипити не имея доступа к клиентским ключам. Это один из других возможных способов как, например запуск прокси на локальном компьютере пользователя в виде веб сервера или написания расширения для гугл-хрома. Что касается монетизации, вы можете рассмотреть продажу вашего сервиса путем размещением вашего апиай на каком-нибудь апиай-маркетплейсе или монетизацию через рекламу или донаты.
Автор, почему вы не писали объектно ориентированный код? Выглядит подозрительно...
Для обучения достаточно colab, достаточно любой карты поддерживпющей cuda...
За версионностью следит стстема контроля версий.
В тестах свои пропертис отдельные
идея такого подхода держать настройки в одном месте для разных инстансов
Алексей,
спасибо за ваш вопрос.
Да, можно выгрузить набор данных из базы данных используя язык запросов SQL, потом сохранить данные в формате CSV и открыть в Excel с целью последующего анализа.
Указанные выше операции являются ручными, то есть, чтобы получить новый Excel файл, нужно пподелать эту работу снова. Если нужно сформировать набор данных состоящий из нескольких выборок, то нужно сделать больше работы. Когда необходимо что-то сделать еще с полученными данными или послать данные кому-то или делать задачу на регулярной основе, в голову приходит мысль автоматизировать процесс подготовки данных.
Идея сервиса автоматизировать и упростить процесс получения данных.
В ядро сервиса заложена функциональность пост-обработки полученных данных, например очистка описаний товаров от HTML тегов и другое.
При необходимости предоставлять данные "наружу" можно сделать простейший сайт, использующий ресурсы сервиса выгрузок. Есть идея создать "хранилище моделей выгрузок". В таком случае сайт делать не придется: создали модель и расшарили ееобходимый URL потребителям данных.
AlexeyUral,
Данный сервис отличается от "других плагинов", тем, что позволяет определять свою логику выгрузки с использованием языка запросов SQL. SQL запрос является шаблоном, с возможностью менять части запроса динамически, в зависимости от логики вашей выборки. На базе данного сервиса вы можете создать много вариантов выборок данных, которые соответствуют вашим правилам. Результаты выгрузки данных из вашего магазина или из магазина вашего заказчика может являться входными данными для дальнейших преобразований данных.
DenKuzmin, спасибо ваш за вопрос.
Да, сервис делает выгрузку товаров, и не только товаров и их зависимостей, а вообще любую выборку данных, находящихся в базе данных магазина через API. Отличается от "обычного модуля экспорта" возможностью задавать алгоритм выгрузки на языке SQL. Нужно тем пользователям (и программистам), которым гибкости "обычного модуля выгрузки" не хватает, там где удобнее, легче и проще (с точки зрения программиста) использовать SQL. Сервис представляет из себя ETL движок. Как происходит Выгрузка. На первом шаге задается один или более SQL запросов. На втором шаге определяются поля и их типы (строка, число, дата, время). На третьем шаге задаются условия связи наборов данных определенных на первом шаге. Такой подход позволяет облегчить работу программиста. Управлять полями можно программно - запрос с описанием шаблона и его параметров представлен в виде JSON. Почему это на шаг впереди, чем "обычный REST API"? Это следующий шаг после получения данных по REST. Сервис на себя берет функцию ETL, программист определяет "что нужно получить", а не "как обработать результаты, возвращенные через 'обычный' REST". Это не бесплатно. На текущий день пользование сервисом стоит $10 за 500 выгрузок в месяц. Если есть дополнительные вопросы, или что-то не ясно пожалуйста спрашивайте.
1) Улучшенный дизайн выглядит подозрительно с точки зрения создания юнит-тестов. У вас есть юнит-тесты? Не интеграционные, а именно юнит-тесты. Написание тестируемого кода накладывает "ограничения" на дизайн. Отсутствие репозитория сразу бросается в глаза, как это тестировать.
2) Декоратор, который приведен в статье мог использоваться для "быстрого фикса", с последующим рефакторингом, то есть возвращению обратно к простому дизайну.
3) Стиль дизайна определяется плотностью запросов реализации новых фич (требоаний, реквариментов), выше плотность - больше паттернов/компонентов. Чем размельченнее код, тем время внедрения новых фич в код более линейно, или даже еще лучше. Характер заказчика играет в этом роль.
4) Граница между разными сервисами проходит там, где можно выделить независимую и заменяемую часть логики.
5) "потому что ты не знаешь непосредственно, какой конкретно код будет исполняться. Тебе сначала нужно проверить, какие реализации существуют в интерфейсе, а затем разобраться, какая конкретно применяется во время исполнения." - интерфейс вводится для того, чтобы "не знать", какая будет реализация - важен контракт использования.
Здесь пример как работать с AVX из Java https://github.com/QuasarByte/jdk16-vector-api-vs-gpu-vs-cpu-benchmark
Преимущества REST: простота, ориентация на человека. За это любят REST. Бинарные протоколы и до этого существовали, например Hessian. Более сложные технологии до этого существовали, например "Веб Сервисы". Чтобы работать с рест не обязательно использовать "Стороннее программное обеспечение", но есть инфраструктура, делающая REST "больше чем протокол". Простота, не зависимость, открытость для людей и машин - главная идея REST.
ОБЯЗАТЕЛЬНО: запусти
mvn test- ошибок быть не должно - mvn verify тоже ошибки быть не должно при запуске интеграционных тестов.11.1: JUnit-тесты очень желательны. Можно не делать 100% покрытие, только основные сценарии - junit тесты надо писать без поднятия контекста. С поднятием контекста - это лучше относить к интеграционным тестам. Почему? Потому, что тесты с контестом работают медленно, лучше мказать медленно поднимается контекст. Тесты дата-лейера тем более это интеграционные тесты. Как писать на спринге и не поднимать его в юнмт тестах? надо использовать библиотеку моков, например мокито.
10.2: Проверяйте входные данные Primary Key при
create/updateв контроллерах. - этим может заниматься база данных, а Джава (слой данных) возбуждать исключение и возврвщать клиенту, например "бэд реквест". Без блокировки не существующих записей (да, это можно сделать) это не сделать консистентно, либо нужно изменять уровень изоляции транзакций, а это уменьшает масштабируемость приложения. Проще на это не обращать внимание, за вас сделает эту работу база данных и джпа/спринг.8.2: Я предпочитаю четкое разделение ролей на основе URL. Например, для админа URL содержит
/admin - спорное утверждение, не имеющее отношения к праыильному выполнению тестового задания.7.6: Таблицы я предпочитаю именовать в единственном числе. Исключение - users, т. к. user - зарезервированное слово - order и другие также лучше в множественном.
7.5: Поля базы case insensitive, не пишите camelStyle - в обратных одинарных кавычках для мариядэбэ или майскл кейс сенситив, для оракла в двойных кавычках уейс сенситив, для мсскл в квадратных скобках кейс сенситив. поля можно указать в маппинге сущьностей. Поля кейс сенситив...
6.4: Обновление в базе делается через
update- не стоит смешивать JPA и DAO. апдейт делать не надо и сейв загруженного POJO также не надр - достаточно лишь изменить поля на необходимые значения, остальную работу сделает JPA. JPA и есть "паттерн".