Тоже вчера после яка пробовал найти эту информацию, но похоже что нет.
Вообще, сразу в голову пришли некоторые кейсы, которые невозможны сейчас, но были бы интересны. Для этого нужна пара фич:
1. Активация навыка по расписанию.
2. Кроссплатформенная персонификация пользователя
П. 2 можно обойти если в диалоге пользователь сам будет себя как то идентифицировать.
А 1 нужен для кейса типа «учу слова». Загружаем список слов в навык (в обход алисы) и даем задание алиса проверяй меня 2 раза в день. И алиса 2 раза начинает диалог сама просит дать перевод для каждого слова по списка в случайном порядке.
Небольшое предложение по развитию — сделать кроме списка счетов список (желательно дерево) статей затрат/прибылей. И транзакции сделать замкнутыми на счета и статьи. Тогда можно буд ет строить отчет на что от кого потрачены деньги. Новые транзакции которые не удалось автоматически отнести к статье вешать в нераспределено. Ну и далее шаблоны для смс для управления автоматическим разнесением. И будет сказка. Ах да на яблоко еще портировать )
Спасибо за статью! Как раз продумываю веньиляцию в квартире и хочу сделать автоматическое управление заслонками в зависимости от со и температуры (много со сосем с улицы, холодно гоним через батарею, мало со и холодно гоним через батарею с улицы не сосем, жарко и много со сосем с улицы и гоним через кондей, жарко и мало со просто работает кондей)
Остальные компании не такие известные, да и самих кейсов написано достаточно, чтобы их все все равно никто не прочитал :) А писать их требует времени. Собственно, еще есть кейсы из производства и так далее. Если полазите найдете еще несколько компаний.
Я рад, что могу развеять мнение. Продукт был создан не под Юлмарт, не для Юлмарта и не вместе с Юлмартом. Собственно, Юлмарт был нашим крупнейшим клиентом какое-то время, но и до него и без него мы оставались бы прибыльными (и остаемся).
ПС Изменения в концепции развития у нас происходят на регулярной основе. Рынок достаточно консервативный и мы пробуем разные стратегии. И новые изменения уже не за горами :)
Кризис способствовал тому, что пришлось отказаться от полок, витрин, продавцов-консультантов и многого другого, что делало бы Юлмарт похожим на конкурентов
Не то, чтобы прямо это было сознательным решением руководства. Просто модель была полностью скопирована с ультры.
Инсайдеры всей ситуации обещают написать полное описание этой эпопеи, но пока связаны морально-этическими обязательствами.
Да, на сап в итоге миграция так и не произошла. Не то, чтобы текущее положение Ю вызвано этим переходом, но в этом конкурентном бизнесе (еком) все затраты, не приносящие денег, ведут в пропасть.
B-tree index и не не будет работать, а эффективность его использования будет падать. А битмап вполне себе прокатит. Уточняю, просто чтобы не возникало обреченности :)
Подозреваю вы под словами селект может менять данные понимаете его реализацию select for update. При последовательном чтении строк действительно происходит пометка блока с зачитанными строками чтобы можно было реализовать select for update skip locked. Но такой паттерн это реализация очередей как правило и там не требуется апдейтов обычно, и проблем нет. Это про оракл.
А поясните, что значит версии не восстанавливаются и почему чтение радикально дешевле чем в оракле? В оракле есть три уровня изоляции и в пг вроде тоже read commited read dirty и serializable
Третий реально требует поиска блока нужной версии в анду, а read committed позволяет просто найти оригинальную версию блока в анду причем его адрес в самом блоке и записан так что там небольшие потери. А как постгрес действует?
Я думаю, что для перечисленных вариантов с джойнами база выполнит запрос с меньшим числом операций чем вы это проделаете в своей программе на яве. Либо, вы умеете делать Все оптимизации которые делаются в базе и пишите их каждый раз когда надо вытащить данные. Но даже если так, запрос будет быстрее потому что
— при выполнении можно зачитать данные только из индекса (например для выполнения exists
— не произойдет конфликта согласованности данных только если вы не используете уровень изоляции serializable что дорого
— у базы есть статистика о кардинальности связей и она может применя разные
алгоримы для соединения таблиц
— база кеширует данные таблиц и индексов в памяти
Это просто 4 фактора что на вскидку в голову пришли.
В итоге чтении данных потребуется меньше операций чтения с диска (что на самом деле является единственной проблемой при чтении как в задаче с поиском) причем меньше не в константу раз а лучше.
Ненадо так сокращать, ибо between работает по разному Иногда как интервал иногда как отрезок. Это я про разные базы. И эта экономия в три кнопки потом вльется в труднонаходимый косяк.
srp вроде как не совсем повторяет указанную схему, про него я читал, но «по диагонали».
Надо будет внимательно прочитать схему, если это то что я спрашиваю.
Немного оффтопик, но есть ли реализации схемы zero knowlege proof для вебприложений?
Схема выглядит примерно так. Пользователь генерирует открытый закрытый ключ, открытый сохраняется на сервере закрытый у пользователя. При авторизации клиент обращается к серверу, тот генерит случайный текст, возвращает клиенту. Клиент шифрует закрытым ключем и передает серверу. Сервер открытым ключем дешифрует сообщение и сравнивает с оригинальным. Если совпало — успех.
Участвовать могут и 100 компаний. Блокчейн то как тут помогает?
Вот если вы в блокчейне будете вести остатки товаров, и привлечете к нему некий фактор принуждения, то тогда сможете реализовать контракт, когда принадлежность товара передается в одну сторону, а деньги в другую. Если физической поставки не происходит вы обращаетесь к фактору принуждения (полицию) и она разбирается. Правда, все равно не понятно, чем это от аккредитива банка будет отличаться.
Как алисе передать этот голос? Разве в апи есть такое?
Понятно что можно в календарь, но тогда магия алисы как то тускнеет, вау
эффекта не возникает.
А хочется чтобы прямо как в фантастических фильмах. Если говорить о суровой реальности то консоль то и поудобнее может будет.
Вообще, сразу в голову пришли некоторые кейсы, которые невозможны сейчас, но были бы интересны. Для этого нужна пара фич:
1. Активация навыка по расписанию.
2. Кроссплатформенная персонификация пользователя
П. 2 можно обойти если в диалоге пользователь сам будет себя как то идентифицировать.
А 1 нужен для кейса типа «учу слова». Загружаем список слов в навык (в обход алисы) и даем задание алиса проверяй меня 2 раза в день. И алиса 2 раза начинает диалог сама просит дать перевод для каждого слова по списка в случайном порядке.
Ну или аналогичные по сути кейсы.
Я рад, что могу развеять мнение. Продукт был создан не под Юлмарт, не для Юлмарта и не вместе с Юлмартом. Собственно, Юлмарт был нашим крупнейшим клиентом какое-то время, но и до него и без него мы оставались бы прибыльными (и остаемся).
ПС Изменения в концепции развития у нас происходят на регулярной основе. Рынок достаточно консервативный и мы пробуем разные стратегии. И новые изменения уже не за горами :)
Не то, чтобы прямо это было сознательным решением руководства. Просто модель была полностью скопирована с ультры.
Инсайдеры всей ситуации обещают написать полное описание этой эпопеи, но пока связаны морально-этическими обязательствами.
Да, на сап в итоге миграция так и не произошла. Не то, чтобы текущее положение Ю вызвано этим переходом, но в этом конкурентном бизнесе (еком) все затраты, не приносящие денег, ведут в пропасть.
Ulmart никогда не был основным клиентом. Даже не был первым. И уже несколько лет не является крупнейшим. Так что будем продолжать развивать продукт.
Я про информацию из вашей статьи.
А поясните, что значит версии не восстанавливаются и почему чтение радикально дешевле чем в оракле? В оракле есть три уровня изоляции и в пг вроде тоже read commited read dirty и serializable
Третий реально требует поиска блока нужной версии в анду, а read committed позволяет просто найти оригинальную версию блока в анду причем его адрес в самом блоке и записан так что там небольшие потери. А как постгрес действует?
— при выполнении можно зачитать данные только из индекса (например для выполнения exists
— не произойдет конфликта согласованности данных только если вы не используете уровень изоляции serializable что дорого
— у базы есть статистика о кардинальности связей и она может применя разные
алгоримы для соединения таблиц
— база кеширует данные таблиц и индексов в памяти
Это просто 4 фактора что на вскидку в голову пришли.
В итоге чтении данных потребуется меньше операций чтения с диска (что на самом деле является единственной проблемой при чтении как в задаче с поиском) причем меньше не в константу раз а лучше.
Надо будет внимательно прочитать схему, если это то что я спрашиваю.
Схема выглядит примерно так. Пользователь генерирует открытый закрытый ключ, открытый сохраняется на сервере закрытый у пользователя. При авторизации клиент обращается к серверу, тот генерит случайный текст, возвращает клиенту. Клиент шифрует закрытым ключем и передает серверу. Сервер открытым ключем дешифрует сообщение и сравнивает с оригинальным. Если совпало — успех.
Вот если вы в блокчейне будете вести остатки товаров, и привлечете к нему некий фактор принуждения, то тогда сможете реализовать контракт, когда принадлежность товара передается в одну сторону, а деньги в другую. Если физической поставки не происходит вы обращаетесь к фактору принуждения (полицию) и она разбирается. Правда, все равно не понятно, чем это от аккредитива банка будет отличаться.