Чтобы выложить товар на полку, нужно отсканить код. После этого его можно погасить только через продажу на кассе этого же юрлица либо списать при просрочке,порче и т.д. И тоже через тоже самое юрлицо.
Можно попробовать развернуть схему работы с proto. Редактировать proto-файл руками, не генерировать. Через декоратор класса указывать путь к proto-файлу и имя реализуемого grpc-сервиса, через декоратор метода указывать реализуемый grpc-метод. В декораторе модели указывать путь к proto-файлу и имя message в нём.
Получается, proto-файл генерируется новый при изменениях. А как быть клиентам вашего сервиса? py-клиенты не могут использовать вашу либу, т.к. чтобы им сгенерировать идентичный proto-файл, клиент сам должен быть сервисом. Таким образом, используя вашу библиотеку, могут общатся только одинаковые сервисы?
Я думал, что protobuf предполагает другую схему работы - proto-файл единственный источник правды для всех сервисов и клиентов на любых языках. Вдумчиво меняем proto -> генерируем клиентов/серверы.
У вас же, простое добавление поля в модель ведёт к критическим изменениям протокола.
В регистратуре районной поликлиники такая картотека была. По первой букве фамилии вроде отсекали. Плюс вся картотека была разложена в ячейки по году рождения. Или наоборот, не помню уже - давно это было.
На карточке был список активных записей к врачам, может ещё какая инфа. Довольно быстро находили нужную карточку.
И Вы только что реализовали паттерн "стратегия", только другими инструментами
Хотя, нет, не совсем
Я привёл, условно, три куска кода из трёх разных проектов. Их пишут разные команды. Сам аутентификатор пилит четвертая.
Получается конкретно на месте у меня нет функции login. Есть экземпляр Auth, там могут быть даже какие-то предустановленные стратегии. Я его могу как есть использовать, + могу что-то своё добавить.
Можно добавлять/заменять/настраивать стратегии по месту. При этом авторы аутентификатора и самих стратегий не зависят друг от друга и работают в рамках контракта (интерфейс Strategy)
//web
if (isRU) {
auth.use('fb', new FBStrategy({...proxySettings}));
auth.use('vk', new VKStrategy());
}
//desktop
if (isDesktop) {
auth.use('account', new LDAPStrategy({dc: 'dc.acme.com'}));
}
//mobile
if (isMobile) {
auth.use('account', new AndroidAccountsStrategy());
}
Собственно, в статье есть ссылка на pasport.js, как пример, для которого написано куча стратегий. Можно комбинировать их под свои потребности.
Если код используется в одном месте, то так проще. Если нужно переиспользовать, причём с разными настройками по месту, то вариант со стратегиями более удобен.
Скорость деплоя это конечно хорошо, а как на счёт скорости работы? Есть сравнение производительности итогового продукта?
Ищите на алике "HM65 itx"
Недорогие платы с 988 сокетом, питанием 12В и уже с LVDS и питанием инвертора.
Может космическое излучение
https://habr.com/ru/companies/first/articles/667208/
Тут скорее смещение не "из жилых в нежилые", а "из Европы в страны третьего мира"
Нужно собирать этот мусор в космическую свалку. Космические бомжи будут строить из него свои орбитальные станции.
Этого не знаю, логично предположить, что нет. Но нужно помнить в какой стране мы живём :)
Чтобы выложить товар на полку, нужно отсканить код. После этого его можно погасить только через продажу на кассе этого же юрлица либо списать при просрочке,порче и т.д. И тоже через тоже самое юрлицо.
Нет, коды одноразовые
Круто! Но есть одно "но" - при беге на дорожке волосы не развеваются по ветру :)
Можно попробовать развернуть схему работы с proto. Редактировать proto-файл руками, не генерировать. Через декоратор класса указывать путь к proto-файлу и имя реализуемого grpc-сервиса, через декоратор метода указывать реализуемый grpc-метод. В декораторе модели указывать путь к proto-файлу и имя message в нём.
Получается, proto-файл генерируется новый при изменениях. А как быть клиентам вашего сервиса? py-клиенты не могут использовать вашу либу, т.к. чтобы им сгенерировать идентичный proto-файл, клиент сам должен быть сервисом. Таким образом, используя вашу библиотеку, могут общатся только одинаковые сервисы?
Я думал, что protobuf предполагает другую схему работы - proto-файл единственный источник правды для всех сервисов и клиентов на любых языках. Вдумчиво меняем proto -> генерируем клиентов/серверы.
У вас же, простое добавление поля в модель ведёт к критическим изменениям протокола.
В регистратуре районной поликлиники такая картотека была. По первой букве фамилии вроде отсекали. Плюс вся картотека была разложена в ячейки по году рождения. Или наоборот, не помню уже - давно это было.
На карточке был список активных записей к врачам, может ещё какая инфа. Довольно быстро находили нужную карточку.
Надо спросить ИИ, может он знает.
Я по заголовку подумал, что нейросетке дали КВ трансивер и свой позывной, а тут генератор музыки.
А на системах централизованного отопления специально пытаются сломать, проводя опресовки для выявления слабых мест.
Можно залить верх эпоксидкой, и сшлифовать текстолит до самой меди :) Получится ещё меньше
И Вы только что реализовали паттерн "стратегия", только другими инструментами
Хотя, нет, не совсем
Я привёл, условно, три куска кода из трёх разных проектов. Их пишут разные команды. Сам аутентификатор пилит четвертая.
Получается конкретно на месте у меня нет функции login. Есть экземпляр Auth, там могут быть даже какие-то предустановленные стратегии. Я его могу как есть использовать, + могу что-то своё добавить.
Можно добавлять/заменять/настраивать стратегии по месту. При этом авторы аутентификатора и самих стратегий не зависят друг от друга и работают в рамках контракта (интерфейс Strategy)
Собственно, в статье есть ссылка на pasport.js, как пример, для которого написано куча стратегий. Можно комбинировать их под свои потребности.
Если код используется в одном месте, то так проще. Если нужно переиспользовать, причём с разными настройками по месту, то вариант со стратегиями более удобен.
Вы инкрементирующий десятичный счётчик яблок с массивом путаете :)