Пару месяцев назад я рассказал вам о своем фреймворке для работы с различными брокерами сообщений — Propan.

Тезисно повторю: это идейный наследник FastAPI, но для написания асинхронных микросервисов (привет, Kombu). Он настолько облегчает взаимодействие с брокерами сообщений, что данный архитектурный паттерн переходит из разряда

слишком сложно, это для хайлоад, некогда разбираться

в разряд

а давай отдадим нашему стажеру сервис, он по документации разберется

Иногда полезно оглянуться назад, подвести черту и сложить в одну кучу все, что накопилось за время работы. И вот этот момент настал и для Propan. Я просто хочу вам рассказать о тех важных изменениях, которые я внедрил за прошедшие два месяца и планах на будущее.

Сейчас ваш фидбек очень важен, так как PropanV2 находится в активной работе и любое из ваших предложений сейчас может повлиять на него.

Что было

Напомню основные фичи, которые были представлены на момент первой статьи:

• Сериализация входящих сообщений с помощью Pydantic

• Поддержка RabbitMQ, Nats, Redis Pub/Sub через идентичные интерфейсы

• Собственная CLI с хотрелоадом, шаблоном проектов, воркерами и тд и тп

• In-memory тесты

• Поддержка RPC over MQ

Что стало

Pydantic

Наверное, все слышали о релизе PydanticV2, написанном на Rust. Это все тот же самый Pydantic, но в 3-40 раз быстрее.

Раз уж мы строим свой инструмент на базе Pydantic, то мы просто обязаны внедрить поддержку нового релиза, причем следуя лучшим практикам! Поэтому Propan теперь поддерживает как PydanticV2, так и PydanticV1. Устанавливайте любой — не ошибетесь.

AsyncAPI

Раз уж мы следуем за FastAPI, то не можем упустить и такую важную особенность, как автоматическое генерирование документации проекта. Правда FastAPI использует OpenAPI схему, которая подходит только для HTTP сервисов.

Поэтому Propan автоматически генерирует для вас схему AsyncAPI, созданную специально для асинхронных сервисов.

Вы можете как сгенерировать отдельный файл и передать его другой команде, так и развернуть документацию как статичную HTML страницу (swagger-like), чтобы предоставить всем смежным командам удобный доступ.

Новые брокеры

Добавлена поддержка Kafka, SQS и NatsJS. Если вы ждали поддержку чего-то из этого для того, чтобы начать использовать Propan — можете больше не ждать, просто используйте!

Другие изменения

Добавлен функционал Middlewares, Routers для разделения приложения на подключаемые модули, добавлена возможность кастомизировать сериализацию (например через protobuf), добавлено примерно миллиард (по моим субъективным ощущениям) страниц документации, исправлено N+1 критичных и не очень багов, а также внесены еще какие-то там другие изменения.

Community

За это время проект вырос с 70 звезд на гите до 300, прирос парой part-time контрибуторов, засветился в PythonBytes подкасте, был взят на вооружение несколькими компаниями (как минимум 2 из них привлекали меня для консультации по внедрению) и получил внушительное количество позитивного фидбека от пользователей.

Дальнейшие планы

Если проект существует больше одного месяца — это уже легаси, правильно? А что мы делаем с легаси? — Переписываем!

Так как Propan существует уже целых 4 месяца, то мной было принято волевое решение полностью переписать его на новую архитектуру. Как оказалось, на старую просто не ложатся некоторые из запланированных фич.

Но не стоит бояться! Абсолютно все тесты старой версии отрабатывают также и на новой, а общее количество тестов удвоено (значит новая версия в 2 раза лучше, верно?).

Этот мажорный релиз зафиксирует архитектуру Propan и будет вводиться очень осторожно и постепенно, поддерживая обратную совместимость везде, где только возможно. Его бета версия планируется на начало сентября, так что у вас есть время предложить свое видение того, какого функционала не хватает фреймворку, а также повлиять на уже принятые решения.

Заключение

Если вы работаете с брокерами сообщений, но еще не пробовали Propan — самое время это исправить. Фреймворк активно развивается, растет день ото дня, а ошибки, с которыми сталкиваются пользователи в процессе эксплуатации исправляются в тот же день.

В процессе работы над проектом ни один разработчик от выгорания кажется не пострадал. Но, тем не менее, мне нужен ваш фидбек чтобы продолжать так же активно работать над тем, чтобы делать экосистему Python лучше.

Также мне нужно ваше видение о том, каким должен быть инструмент для работы с брокерами сообщений, поэтому буду рад любому фидбеку на тему PropanV2.

Ссылки

Тут вы можете поставить звезду
Propan: https://github.com/Lancetnik/Propan

Тут вы можете включиться в обсуждение
Propan discord: https://discord.gg/ChhMXJpvz7

А тут вы можете посмотреть на свежий драфт
PropanV2: https://github.com/Lancetnik/Propan/tree/v2/examples

Что нового в iOS 17 beta 4, какого цвета ожидаются новые Apple Watch Ultra, какие банковские приложения вернулись в App Store и когда выйдет Death Stranding на Mac, а также подробности об Apple Vision Pro, слухи о новинках и многое другое. Новый выпуск дайджеста за неделю уже здесь, погнали к новостям!

iOS 17 beta 4 и visionOS 1.0 beta 2 вышли для разработчиков

На прошлой неделе стали доступны новые бета-версии систем для разработчиков. Стабильности по словам установивших их, не особо прибавилось, даже более того – сборка для macOS Sonoma beta 4 не у всех ровно установилась и компьютер просто бесконечно перезагружается. В остальном, новшества есть, а сборки до сих пор пока не выходили в публичный тест (и похоже, это случится на этой неделе). Сейчас доступны следующие сборки для разработчиков:

• iOS 17.0 Beta 4 (21A5291h)

• iPadOS 17.0 Beta 4 (21A5291h)

• watchOS 10.0 Beta 4 (21R5320i)

• tvOS 17.0 Beta 4 (21J5318f)

• HomePod OS 17.0 Beta 4 (21J5318f)

• macOS Sonoma 14.0 Beta 4 (23A5301g)

• Studio Display 17.0 Beta 4 (21A5291h)

• visionOS 1.0 beta 2 (21N5207f)

Что нового в iOS 17 beta 4?

Apple прокачала редактирование обоев – теперь система ещё лучше распознает портретные фото и лучше отделяет и заменяет задний фон. Добавлены новые варианты оформления: градиентный фон, плавный фон, плавный монохромный фон, оверпринт, студия и цветной фон.

В приложении Сообщения, для iMessage произошёл очередей редизайн иконок интерфейса отправки вложений:

Для macOS 14.0 Sonoma beta 4 новшеств не столь много, но замечены исправления в анимациях Виджетов, AirPlay, а также интерфейсах системных окон приложений, есть и исправления ошибок с пропадающими и слишком резких движениях иконок при перемещении иконок новых Интерактивных Виджетов на рабочем столе.

Apple также выпускает Safari Technology Preview 175 для macOS

Внутри доработка новых функций для веб-приложений, уведомлений, исправления для расширений и улучшения производительности, а также ряд многочисленных исправлений по части API, WebKit и многое другое.

Выпущена и новая сборка обновления ПО для AirPods Pro 2 – firmware 6.0 Beta 2 (6A5262e), уже доступна разработчикам для установки и только на эту модель наушников. Но даже здесь есть новшество – при установленной бета-версии для AirPods Pro 2 на iOS 17 beta 4 при подключении наушников появляется меню настройки персонализации громкости звука на каждом из наушников:

Вышла и новая бета-версия visionOS 1.0 beta 2, содержит дополнения в виде SDK для Simulator – в нём можно просматривать написанные приложения наглядно.

Внутри, например, найдено видео с инструкцией по замене на Vision Pro уплотнителей при необходимости выбора другого размера (например, вместо S установить L).

А ещё умельцы покопавшись в коде системы обнаружили, что аккумуляторов для Vision Pro существует три разных версии!

Внутри ПО для обеспечения питания и работы внешних батарей гарнитуры найдены три кода моделей: A2781 (считается основным аккумулятором, поставляемым в комплекте), а также A2988 и A2697 – дополнительные версии, которые предположительно имеют больший объём батареи для длительного использования Vision Pro.

Apple начала процесс раздачи Vision Pro Developer Kit

С конца июля, как и обещали – в Apple начали принимать заявки на комплекты разработчиков Vision Pro

Чтобы подготовить приложения к запуску нового App Store на Vision Pro, компания обеспечит раздачу тестовых образцов, в составе которых разработчики получат:

• Помощь в настройке устройства и адаптации приложений от экспертов Apple;

• Два дополнительных запроса в Поддержку на уровне кода, чтобы устранить любые проблемы с кодом.

Уже сейчас можно отправить заявку на комплект разработчика Vision Pro на сайте Apple Developer. Для этого вам нужно быть владельцем учетной записи в программе Apple Developer, предоставить подробную информацию о навыках разработки вашей команды и существующих приложениях, а также согласиться с условиями. 

Приоритет будет отдан заявителям, создающим приложение, которое использует преимущества функций и возможностей visionOS.

В Apple Store начнут принимать заказы на отсутствующие в наличии товары, а в США будет доступна покупка техники без налогов

Apple скоро начнёт принимать заказы в оффлайн-магазинах даже на товары, отсутствующие в наличии, с оплатой прямо в магазине и последующей доставкой по удобному адресу. 

Так компания попытается разгрузить склады от слишком больших товаров, например Mac. Это, кстати, решение проблемы с местом для хранения в магазинах с небольшими хранилищами всех необходимых разнообразий аксессуаров для Vision Pro (линзы, оголовья, ремешки, уплотнители и прочее).

Также эта мера позволит получить гравировку на устройстве при заказе даже в самом магазине, ведь раньше для подобных услуг сотрудники Apple Store предлагали заказывать именно на сайте.

А в американских магазинах Apple уже стартовали «Налоговые каникулы». Tax holidays – это способ для магазинов в США стимулировать расходы на категории продуктов, которые они считают необходимыми или желательными для граждан. В онлайн и оффлайн-магазинах Apple акция будет традиционно доступна в 10 штатах с конца июля по начало сентября в Алабаме, Арканзасе, Флориде, Массачусетс, Миссури, Нью-Джерси, Нью-Мексико, Южной Каролине, Теннесси и Западной Вирджинии.

Максимальный лимит покупки по акции достигает $3000, распространяется на всю технику Apple. Подробнее на сайте компании.

Слухи: новый цвет WATCH Ultra, где ещё будут производиться часы, а также подробности о новой кнопке действия на iPhone 15

Уже множество слухов твердит о том, что iPhone 15 Pro и 15 Pro Max будут стоить дороже, разница в цене составит от 100 до 200 долларов в США. Новая цена пока утверждается внутри компании и дорожающие компоненты для iPhone подталкивают компанию к решению всё же поднять цены. Ранее на одном из квартальных отчётов Тим Кук сказал, что думает о том, что клиенты готовы действительно потратиться для получения лучшего, что они смогут себе позволить в той или иной категории. Это можно отнести как к вопросу цены на Vision Pro, так и к ранним размышлениям о повышении цены на iPhone 15 Pro.

Но зато это будут телефоны с самыми тонкими рамками за всю историю – всего 1,5мм и этого Apple пытается добиться даже стимулируя поставщиков компонентов для нового устройства. В новых iPhone 15 Pro будут использоваться дисплеи по новой технологии LIPO – low-injection pressure over-molding, то есть, литьё под низким давлением, что позволит уменьшить рамки дисплея.

Позднее подобная технология LIPO планируется применяться и в будущих iPad, а это уже совсем интересный слух, ведь сейчас рамки у планшетов достаточно жирные.

Пришли подробности о другой топовой фишке iPhone 15 – Action button, кнопке, которая как ожидается, дебютирует в этом году вместо рычажка беззвучного режима.

Она уже получила упоминание в коде последней беты iOS 17. Новая программируемая кнопка сможет выполнять одно из 9 выбранных пользователем действий: выполнять запуск функций Универсального Доступа, команд, запускать камеру или сразу делать снимок по нажатию, активировать фонарик, переключать режимы фокусирования, вызывать «лупу», запускать запись голосовых заметок или переключать режим на беззвучный (мы уже знаем, что вы выберете из этого 😁)

А в коде watchOS 10 beta найдено упоминание некоторых новых регионов производства: Бразилия и Индия – похоже, в этих странах ожидается запуск производства WATCH, например, SE 2-го поколения:

По слухам, в этом году могут наконец выйти WATCH Ultra в тёмном титановом корпусе, правда пока не ясно – это будут полноценные WATCH Ultra 2-го поколения или просто новый цвет. Однако ожидание целевой аудиторией подобной версии ультра-часов уже давно известно, имеются даже концепты:

В App Store вернулось несколько приложений, а ещё известна дата выхода Death Stranding на Mac

Анонсированная на WWDC23, игра Death Stranding Director’s Cut для Mac – станет доступна 2 декабря!

Кроме того, в российском App Store на прошедшей неделе произошло внезапное возвращение нескольких востребованных приложений. Начнём с банковских: спустя несколько месяцев для загрузки из магазина снова стало доступно оригинальное приложение для клиентов банка ВБРР – VBRR Mobile

Для клиентов Альфа-Банка также радостная новость – в App Store появилось новое замаскированное приложение «Деньги в порядке», скорее устанавливайте, пока доступно!

Спустя несколько месяцев после внезапного удаления, вернулось в российский (и только) App Store приложение для спортивных болельщиков – Sports.ru

Остальные дополнительные приложения холдинга пока не вернули, но иностранные редакции издания (Tribuna и Sports Казахстан) уже давно выпустили отдельные приложения для своих порталов. Само приложение Sports.ru было удалено из-за связи с попавшим под персональные санкции владельцем медиахолдинга, теперь же на условиях ограничения регионами распространения, судя по всему, его удалось вернуть.

Для клиентов страховой группы СОГАЗ также есть новость – уже давно в App Store, оказывается, появилось новое приложение взамен удаленного, теперь оно называется «Здоровье и страхование», не теряйте.

Будем держать вас в курсе других изменений в App Store, как в рамках этого дайджеста, так и в наших соцсетях:

Twitter / 𝕏 / Telegram / VK

Информационная служба «Хабра» посетила первое заседание экспертов по технологиям дистанционного электронного голосования (ДЭГ). Заседание проходило при участии специалистов из «Ростелеком», представителей Центральной избирательной комиссии РФ, специалистов «Криптонит» и специалистов «КриптоПРО». Модератором заседания был Алексей Лукацкий. Само заседание выложено на Youtube‑канале компании «Криптонит».

Открыл заседание модератор, известный блогер и бизнес‑консультант по безопасности Positive Technologies Алексей Лукацкий. Он рассказал, как будет проходить заседание и какие вопросы на нём будут освещаться.

Темы, обсуждаемые на заседании:

— технологии ДЭГ и их особенности;

— обеспечение информационной безопасности и осуществление устойчивости ДЭГ к кибератакам;

— возможные варианты дальнейшего развития систем ДЭГ.

После вступительного словам модератора выступал Иван Киреев из Управления инновационных технологий в избирательном процессе ЦИК России. Он рассказывал об изменениях в порядке ДЭГ в 2023 году. В частности, электронное голосование проводилось с 2020 года в рамках эксперимента, систему разработало ПАО «Ростелеком». До 2022 года технология электронного голосования применялась только в рамках определённых выборов. В марте 2022 года в закон «Об основных гарантиях избирательных прав и права на участие в референдуме граждан Российской Федерации» от 12.06.2002 N 67-ФЗ были внесены поправки, связанные с ДЭГ. Также в 2022 году был принят порядок голосования с применением дистанционной системы. В 2022 году в выборах с применением ДЭГ участвовало 7 регионов, в 2023 году — 25. Причём в 2022 году, чтобы подвести итоги, ЦИК дожидалась окончания голосования во всех регионах, а это три часовых пояса. В 2023 году часовых поясов уже будет пять, поэтому были приняты «точечные» изменения регламента голосования. Теперь итоги ДЭГ по завершению голосования на конкретном участке.

Далее взял слово главный архитектор системы ДЭГ в «Ростелекоме» Юрий Сатиров. Его доклад был посвящен техническому развитию ДЭГ за три года. Начал Юрий с рассказа о том, как создавалась система ДЭГ, как она эволюционировала и в каком состоянии она находится сейчас.

В 2020 году была создана первая версия системы с нуля. При создании системы разработчики использовали протоколы тайного голосования, используемые в криптографии, а точнее остановились на одном протоколе — Хе‑Су. Этот протокол был взят за основу. Именно термины и технологии, используемые в протоколе, были взяты для дальнейшего создания ДЭГ. Например, из протокола была взята процедура анонимизации. Как заявил Сатиров, в ДЭГ нет сложной системы запутывания и разъединения, в ДЭГ есть подход подпись вслепую ключа подписи избирателя.

Однако «Ростелеком» добавили и другие криптографические механизмы. Разработчики решили не расшифровывать индивидуальные бюллетени, они решили производить операции над зашифрованными данными или гомоморфное шифрование. Однако для того, чтобы было понять, правильно ли заполнение бюллетень или нет, нужно использовать другой механизм. Для этого было использовано доказательство с нулевым разглашением. Это процедура представляет собой разделение ключей на несколько частей для держателей ключей. Вот такая системы была создана в 2020 году.

В 2020 году также был проведён тест системы в Ярославской области. В тесте участвовало 30 тысяч человек. В 2021 году вышла статья On the (in) security of ROS от криптографов из Google и Беркли. При этом у статьи не было широкой огласки. Однако, по словам Юрия Сатирова, это был «взрыв бомбы». В этой статье доказывалось, что, если брать криптографический протокол и внедрить его в информационную систему, где есть не один пользователь (как Алиса и Боб в стандартной схеме), а несколько, то в таком случае выясняется, например, что при реализации протокола слепой подписи, если у нарушителя есть возможность открыть какое‑то количество параллельных сессий, возникает возможность получить ещё одну подпись, то есть ещё один бюллетень. Статья была основана на 256 параллельных сессиях и в ней атака вполне была осуществима на обычных ноутбуках.

Для разработчиков ДЭГ статья означала полную перестройку используемых криптографических механизмов. И в итоге «Ростелеком» ушёл от слепой подписи Шнора к слепой подписи RSA 4096 с добавлением хеш‑функции Стрибог.

Далее в 2021 году разработчики убрали сложнопроверяемые механизмы и приступили к решению вопроса процедуры анонимизации со слепой подписью. И на конец 2021 года была найдена нужная подпись под названием Abe.

В 2022 году ДЭГ применялась, как уже говорил представитель ЦИК Иван Киреев, в 7 регионах в единый день голосования. Как утверждает Сатиров, именно 2022 год дал толчок для развития ДЭГ. Во‑первых, вышла статья двух исследователей Тессаро и Жу о реализации слепой подписи на эллиптических кривых. Она дала рабочее решение для ДЭГ. Во‑вторых, благодаря статье Тессаро‑Жу и последующим исследованиям от компаний «КриптоПро», «Ростелеком» и «Криптонит», появился документ под названием «Модель угроз и нарушителя для анализа криптографических механизмов ДЭГ». Документ рассказывает о моделях угроз и нарушителях в части криптографии. В итоге к концу 2022 года разработчики пришли к выводу, что ДЭГ можно рассматривать как единое сложное криптографическое СКЗИ.

Ну и в 2023 году прорыв, совершённый в 2022 году, был закреплён программно‑аппаратными СКЗИ. Все эти комплексы сертифицированы ФСТЭК и ФСБ, и допущены к единому дню голосования.

В конце выступления Сатиров рассказал о специальном чемодане, используемом для генерации ключей. Первичная генерация ключей, которая будет происходить в комиссии, будет происходить с помощью аппаратного датчика случайных чисел.

Потом Сатиров немного раскрыл рассказ Киреева о регламенте голосования по ДЭГ в 24 регионах:

— у каждого региона будет разная продолжительность голосования (где два дня, где‑то три дня, а завершиться одинаково в 20:00 по местному времени в воскресенье);

— в 2023 году исходные данные будут загружаться со всеми параметрами, а потом в автоматическом режиме каждый час будет стартовать голосование и для каждого пояса будут отдельные ключи;

— для обеспечения прозрачности и доверия к системе, используется распределённый реестр по технологии блокчейна. Блокчейн будет отображать все действия всех участников по исполнению функции ДЭГ.

Протокол ДЭГ будет публиковаться на сайте электронного голосования, его можно будет скачать и ознакомиться.

После выступления Сатирова, было выступление руководителя лаборатории криптографии компании «Криптонит» Василия Шишкина. Его выступление посвящено проведённому исследованию надёжности криптографических механизмов ДЭГ. Результаты «Криптонит» опубликовала в своём блоге на Хабре. Всего в системе ДЭГ семь криптографических механизмов «Криптонит» проверяла три. Первой была схема аддитивно‑гомоморфного шифрования, вторая — доказательство с нулевым разглашением, третья — доказательство принадлежности интервалу.

В ходе работ тестирующие занимались разработкой математических моделей и анализом стойкости этих механизмов. Кроме того, специалисты компании «Криптонит» занимались разработкой и формированием документации в экспертные организации.

К сентябрю 2021 года были разработаны модели и проведён анализ стойкости схемы аддитивно‑гомоморфного шифрования. К ноябрю 2022 всё то же самое проведено с доказательством с нулевым разглашением и доказательством принадлежности интервалу. Разработка документации и отчётности продолжает и по настоящее время.

Шишкин подробнее рассказал для чего используются, исследуемые его компанией, механизмы. Доказательство принадлежности интервалу используются для доказательства корректности содержимого бюллетеня. Схема аддитивно‑гомоморфного шифрования обеспечивает конфиденциальность вычислений. Для получения суммы голосов не надо расшифровывать каждый бюллетень, достаточно сложить шифр текста и суммарный шифр бюллетеней даст общее количество голосов. Доказательство с нулевым разглашением нужно для доказательства корректности суммы голосов.

Далее Шишкин рассказал свойства системы безопасности шифрования:

— конфиденциальность (злоумышленник не получит никакой нетривиальной информации об открытом тексте);

— неподатливость (злоумышленник не построит по заданному наборы шифртекстов новый шифртекст, чтобы пройти корректность шифрования);

— корректность (злоумышленник не сформирует шифротекст, дающий возможность корректно расшифровать открытый текст).

После представителя компании «Криптонит» выступили сразу два сотрудника компании «КриптоПРО» — заместитель генерального директора Станислав Смышляев и начальник отдела криптографических исследований Евгений Алексеев. Они продолжили рассказ о проведённом исследовании надёжности криптографических механизмов ДЭГ.

Первым выступал Станислав Смышляев, его коротенькое выступление было посвящено развитию науки и непосредственно криптографии. Вторым выступал Евгений Алексеев. Он продолжил рассказа о тестировании механизмов криптографии, используемых в ДЭГ. Специалисты компании «КриптоПРО» исследовали ещё три механизма — подпись вслепую, разделение секрета с доверенным дилером и схема обязательств.

Подпись вслепую — это расширение классической электронной подписи в сторону увелечения предоставляемых свойств. Клиент взаимодействует с подписывающим и подпись он может получить только от подписывающего. Кроме того, с этой подписью подписывающий не сможет узнать, что он подписал. В качестве подписи в РФ использует подпись RSBS (ядро подписи представляет собой схема Тесарро‑Жу, озвученная Юрием Сатировым).

Разделение секрета с доверенным дилером — схема, где есть доверенный дилер, генерирующий общий ключ и распределяющий компоненты ключа по участникам. Компоненты сделаны таким образом, что определённое количество участников могут собрать ключ, а уже меньшая группа нет. В системе ДЭГ такая схема используется для разделения ключей одного из компонентов шифрования бюллетеней и за счёт этого обеспечивается конфиденциальности итогов голосования.

И последнее — схема обязательств. В этой схеме также есть заявитель и проверяющий. Заявитель для определённых данных генерирует обязательства и отдаёт проверяющему По этому обязательству проверяющий не должен ничего узнать о значении некоторых персональных данных избирателей. Также тот кто генерировал это обязательство не может изменить или поменять данные, указанные в обязательстве. Для проверки этих механизмов были сформированы модели безопасности с учётом особенностей применения механизмов, далее формирование математических моделей и оценка стойкости механизмах в сформированных моделях. Для всех механизмов были получены оценки стойкости, при которых реализации модели угроз предельно малы.

Последним выступающим был политолог, эксперт независимого общественного мониторинга Владислав Фёдоров. Его рассказ был посвящён опыту применения ДЭГ в России и за рубежом.

Фёдоров выступал онлайн и рассказал о своём видении электронного голосования. По словам эксперта, есть четыре направления исследования электронного голосования — юридические, социологические, политические и технические. Фёдоров уточнил, что фокус внимания первого заседания на технической составляющей криптографии, обеспечения сохранности данных и так далее, фокус внимания эксперта больше сконцентрирован на влияния ДЭГ на политические процессы.

Фёдоров перечислил страны лидеры по ДЭГ — это Индия и Бразилия. Сейчас в более чем 40 странах используется система ДЭГ. Из 40 стран на общенациональном уровне ДЭГ используют — Эстония, Россия и Швейцария. На региональном уровне дистанционное голосование используют порядка 10 стран и для граждан‑избирателей, живущих за рубежом.

Далее эксперт перечислил преимущества ДЭГ:

— возможность голосования со смартфона;

— отсутствие привязки к месту (не надо идти на конкретный участок) и, как следствие этого, экономия времени;

— расширение сроков голосования;

— экономию ресурсов и средств (изготовление бюллетеней, оплата труда членов комиссии и так далее).

Фёдоров уточнил, что играет роль политический запрос от различных формаций о теме доверия к подсчёту голосов людьми. Поэтому ДЭГ выполняет функции независимого счётчика без ангажированности к какой‑либо политической силе. В Эстонии система ДЭГ развивалась 15 лет и в 2023 году на парламентских выборах было больше электронных избирателей (51%), чем офлайн‑избирателей.

По мнению Фёдорова, по сравнению с другими странами в РФ есть широкие возможности для общественного наблюдения за электронным голосованием, а также для наблюдения различными политическими силами за системой. Система ДЭГ никак не влияет на явку избирателей и, если посмотреть на другие страны с ДЭГ, то в этих странах система обеспечивает прирост явки избирателей за счёт перечисленных ранее преимуществ.

После выступления Фёдорова, была сессия вопросов от представителей СМИ и интернет‑изданий, их я освещать не буду, посмотреть можно здесь.

Данное заседание было интересно тем, что в нём рассказывались интересные механизмы криптографии, используемые в системе голосования. Да, как человек, не глубоко разбирающийся в вопросе, я не всё понимал. Однако был удивлён, например, использованию технологии блокчейн в позитивном ключе. Ведь буквально год‑два назад разговоры про блокчейн‑заработок от NFT до криптовалют были практически везде. Но ажиотаж спал и технология ушла обратно свою нишу.

Довольно интересно будет послушать второе заседание комиссии, если на нём также будет много технических деталей.

Чем проще система — тем она эффективнее. Здесь не нужен художественный вкус или особая одарённость. Красота появляется сама собой, если система спроектирована без лишних деталей. Хороший пример таких интерфейсов дают рабочие инструменты. Молоток, ножовка, электропила. Всё это создано не для красоты, а чтобы идеально ложиться в руку и эффективно выполнять свою функцию. О красоте думают в последнюю очередь, но в итоге дизайн профессиональных инструментов зачастую вызывает искреннее восхищение. Ничего лишнего.

Такие же правила действуют в компьютерных интерфейсах. Чем проще — тем лучше. В этом смысле интересно посмотреть на новое поколение Linux-приложений в современном стиле с адаптацией под смартфоны (на КДПВ некоторые примеры), а также на свежие UI-фреймворки, которые продвигают современный стиль разработки.

▍ Когда лоутек-интерфейсы проще и удобнее

Как мы уже говорили, чем проще система — тем она эффективнее. Вот примеры лоутек-интерфейсов, передающих информацию с помощью светодиодных индикаторов или самых простых дисплеев (матричные или семисегментные индикаторы). В них часто используются физические органы управления, кнопки или тумблеры.

Вообще, тактильный фидбек работает лучше, чем визуальный контакт через GUI на экранах высокого разрешения. Часто действует парадоксальное на первый взгляд правило: чем более высокотехнологичен интерфейс — тем менее он эффективен. Все эти анимации и пошаговые визарды только затрудняют восприятие простых, банальных вещей, внося лишнюю сложность.

Физические ограничения простых интерфейсов (например, экранов низкого разрешения) не мешают дизайнерам а, наоборот, позволяют сконцентрироваться на самом важном:

Вот другой пример скрытых интерфейсов на окружающих вещах, которые органично вписываются в дизайн. Они не выделяются и не заметны, пока не понадобятся. Например, индикатор может появиться в тот момент, когда на него посмотришь, или когда человек появляется рядом:

Аналогичные правила в разработке ПО. Чем проще и понятнее UI — тем лучше. Изыски, украшательства, лишние элементы затрудняют взаимодействие.

▍ Новая волна Linux-приложений. Современные интерфейсы

Были времена, когда Linux-приложения уступали по эстетическим качествам не только macOS, но даже Windows-программам. Мало кто знает, но графические интерфейсы в Unix существовали практически с первых дней, ещё до появления X Window System (1984). Каждый вендор придумывал что-то своё. Например, Suntools/SunView от Sun Microsystems (1983). У компании Silicon Graphics было проприетарное рабочее окружение Iris WorkSpace (1983) с графическим интерфейсом. И так далее. Даже после появления X Window эти вендоры не забросили свои разработки, а реализовали их поверх Х, как OpenWindows от Sun, или создали новые, как Common Desktop Environment (CDE).

Окружение SunView на SPARCstation 4 под SunOS 4 (слева) и десктоп CDE (справа)

Некоторые из этих экспериментов весьма неплохи. Но сейчас другая эпоха. И кажется, что новым трендом становится универсальный дизайн для конвергентных Linux-приложений, который подходит для настольных и мобильных устройств.

Нравится нам это или нет, но мода на универсальный дизайн для всех платформ дошла и до Linux. В качестве примеров можно привести Phosh, Wayland-оболочку GNOME для мобильных устройств с новой версией библиотеки libadwaita, UI-фреймворк Kirigami в KDE, а также Maui Shell, универсальную графическую оболочку для десктопов, планшетов и смартфонов (X11/Wayland).

Maui Shell

Судя по всему, это становится новым стандартом UX/UI для универсальных Linux-приложений.

Kirigami в KDE

Общая кодовая база для настольных/мобильных систем имеет ряд преимуществ перед нативной разработкой отдельно для каждой платформы:

• Синхронизация функциональности между платформами, что способствует общему улучшению UX и цельности дизайна.
• Популяризация Linux-смартфонов, таких как PinePhone, которые работают как десктопы при подключении большого монитора.
• Упрощение разработки и поддержки.
• Улучшение безопасности за счёт уменьшения количества багов (в связи с упрощением поддержки).
• Более качественный дизайн, не перегруженный элементами, как в старых нативных приложениях.

По мнению некоторых специалистов, сейчас происходит своеобразная конвергенция между платформами, поскольку экраны смартфонов по разрешению уже приблизились к обычным мониторам, а сами смартфоны можно использовать как КПК, ноутбук или десктоп, если подключить клавиатуру и внешний дисплей:

PinePhone в корпусе с клавиатурой похож на КПК

Есть мнение, что libadwaita и Kirigami — это одно из самых значительных улучшений в дизайне приложений за всю историю Linux. Наконец-то программы на Linux стали выглядеть действительно стильно и современно.

Некоторые примеры:

Программа Ensembles для работы со звуком

А это современные линуксовые редакторы Setzer и Porto для редактирования документов LaTeX и Jupiter, соответственно:

Внедрение современных, универсальных интерфейсов в KDE, GNOME, Nitrux, Elementary и Jingling с фокусом на тачскрины и мобильные устройства вдохнула новую жизнь в десктопный Linux, который в 2023 году поставил исторический рекорд по количеству пользователей на десктопах. Вместо угловатых интерфейсов прошлых десятилетий Linux становится чуть ли не самой модной и современной системой, судя по GUI современных приложений. Они уже не уступают, а во многом превосходят коммерческое ПО на той же MacOS.

Судя по всему, экосистема десктопного Linux вновь начала развиваться бурными темпами. Впереди самое интересное. Возможно, через пару сотен лет никто и не вспомнит, что в мире существовали какие-то проприетарные ОС, они будут интересовать только цифровых археологов.

Говорят, что сейчас лучшее время для разработки сайтов за всю историю интернета. Поднять свой личный сайтик — отличный повод познакомиться с фронтендом, проверить свой вкус на вёрстке и дизайне. То же самое можно сказать про разработку графических интерфейсов. Некоторые товарищи даже изучают ассемблер путём написания UI.

Для создания красивых интерфейсов вовсе не нужно привлекать профессиональных дизайнеров.

▍ Фреймворки для красивых GUI

На сегодняшний день создана куча фреймворков и полезных инструментов для рисования простых и элегантных интерфейсов, если вы обычный программист и не хотите залезать в дебри создания GUI «по науке».

Написание приложения под Linux сегодня просто как никогда: достаточно открыть тот же GNOME Builder, набросать в IDE основную логику в готовых шаблонах на любом языке программирования и в пару кликов настроить графический интерфейс, который будет выглядеть стильно и современно:

GNOME Builder

Среди фреймворков тоже появляются интересные новинки. Например, фреймворк Slint 1.0 ориентирован на разработку нативных GUI для разных платформ. Написанный на Rust, он позиционируется как инструмент нового поколения с автодополнением кода, с компилятором, который транслирует и оптимизирует описание UI (файлы .slint) в нативный код под любую платформу. Вот один и тот же интерфейс после компиляции под Windows, Linux и macOS:

В этом фреймворке UI программируется декларативным языком с продвинутым синтаксисом для описания любых элементов дизайна:

Что касается веб-разработки, можно упомянуть VanJS, который позиционируется как самый маленький в мире реактивный UI-фреймворк. Он позволяет разработать простенький сайт всего за час без использования React и JSX. Простейшее демо выглядит так:

Здесь смысл в минимальном размере фреймворка, чтобы не увеличивать задержку при загрузке страниц. Да и в принципе каждому перфекционисту приятно использовать оптимальный (самый маленький и быстрый) продукт в своём классе:

Для массовки упомянем ещё Arwes: веб-фреймворк для создания футуристических Sci-Fi-интерфейсов, пропаганды продвинутой науки и технологий, киберпанка и научной фантастики. Разработан в стиле Cyberprep (киберпанк-утопия, без власти корпораций, с праздным счастливым населением) и Synthwave (стиль синтетической музыки), а также вселенных Star Citizen, Halo и TRON: Legacy, вот примеры сайтов:

В общем, для использования таких фреймворков вовсе не обязательно иметь художественное образование и высокий эстетический вкус. Сегодня сделать красивый UX/UI для своей программы или веб-приложения как никогда просто.

А лоутек-примеры на окружающих вещах показывают, что эффективные интерфейсы не обязательно должны быть сложными и бросаться в глаза. Скорее наоборот, они незаметные и максимально простые. Дизайн определяет, как вещь работает, а не как она выглядит.

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх 🕹️

В комментариях к предыдущим публикациям поступали запросы рассмотреть формулировки оптимизационных задач и подходы к моделированию, которые позволяют учесть волатильность данных. В этой публикации рассмотрю один из вариантов учета неопределенности в данных в концепции робастной оптимизации.

Рассуждение будет построено на основе классической задачи Диеты Стиглера, добавим немного неопределенности и рассмотрим, как с ней бороться. Обратим внимание на два противоборствующих фактора: затраты на диету и степень удовлетворенности ограничений при различных сценариях отдельно.

В чем проблема?

Неопределенность. Интуитивно человек/сотрудник приходит к своему механизму работы с неизвестностью. То, насколько он справляется с этой задачей, по большей части определяет его успех. Трейдинг — рынок акций/валюты/крипты — крайне волатилен и трудно предсказуем. Но есть люди/компании, которые учитывают эту неопределенность лучше остальных.

Что насчет алгоритмов? Рассмотрим некоторые варианты учета неопределенности в теории прикладного мат.моделирования и оптимизации.

Худший сценарий (worst-case). Еще Дейл Карнеги писал, чтобы избавиться от тревожности, нужно представить худший исход и принять его. Как ни странно, этот подход присутствует в литературе по исследованию операций (прикладная математика). Подход предполагает использовать для оценки наихудший сценарий, например, закладывать минимальную цену продажи товара или минимальный ожидаемый спрос.

С другой стороны, можно сказать, что стакан наполовину полон. Тогда в игру вступает наилучший сценарий. Он позволяет получить оценку сверху.

Имея на руках наихудший, наилучший и еще какие-нибудь промежуточные сценарии, появляется возможность сформировать средний или средне-взвешенный сценарий, который будет отражать некоторую ожидаемую картину. В то же время, ожидаемая картина может быть далека от каждого отдельно взятого сценария.

Наихудший, наилучший или ожидаемый сценарий освещают одну сторону проблемы. Результат решения задачи оптимизации, построенного на таких данных, будет генерировать аналогичные однобокие картины. Такие решения несут в себе некоторую пользу, но по большей части они неадекватно моделируют происходящий процесс.

В попытках приблизиться к реальности разработаны подходы, которые позволяют учитывать неопределенность непосредственно внутри оптимизационной модели. Речь пойдет о робастной оптимизации.

Отмечу, что моделировать неопределенность будем посредством набора дискретных сценариев с учетом вероятности их реализации. Анализ проведу на основе известной академической задачи — диета Стиглера.

Постановка задачи: Диета Стиглера

Несколько слов о задаче.

• Старая — 1944г.;

• Одна из первых задач, к решению которой применялся симплекс метод;

• Находится в портфеле базовых Examples большинства LP-солверов.

Если считаете свою работу рутинной, после следующего факта, возможно, переосмыслите это:

В 1947 году Джек Ладерман использовал симплекс-метод (тогда еще недавнее изобретение!) для определения оптимального решения. Потребовалось 120 человеко-дней девяти клерков на настольных калькуляторах, чтобы получить ответ.

О чем. В 1943 году Национальным исследовательским советом США были предложены диетические нормы (RDA) для «активного» мужчины весом 70 кг. С другой стороны, Джордж Стиглер задался вопросом о минимальной стоимости продуктов, которые позволят удовлетворить предложенные нормы (проблема студента). Рассматривался список из 77 продуктов питания и 9 питательных веществ (с входными данными можно ознакомиться здесь). В данных приведено содержание питательных веществ в продуктах на 1$.

Математическая постановка задачи

— разнообразие доступных продуктов ();

— множество питательных веществ ();

— содержание питательного вещества в единице продукта ;

— нормативная суточная доза питательного вещества ;

— вещественная переменная, затраты на покупку продукта ;

Ограничения:

• Удовлетворение суточной потребности в каждом из питательных веществ:

Целевая функция:

• Минимизация стоимости корзины продуктов:

Программную реализацию модели выполним на python в OR-Tools и решателем GLOP. Детали реализации опущу, т.к. более подробно разбирал построение и оптимизацию в других публикациях (задача о назначениях, задача планирования расписаний).

import pandas as pd import numpy as np from ortools.linear_solver import pywraplp  # Загрузка данных по нормативам и продуктам df_nutrients_norm = pd.read_csv("https://raw.githubusercontent.com/Lozkins/mos/master/data/03_diet_nutrients_limits.csv", sep=";") df_products = pd.read_csv("https://raw.githubusercontent.com/Lozkins/mos/master/data/03_diet_products.csv", sep=";", encoding="cp1251")  # Реализация модели # Инициализируем солвер solver = pywraplp.Solver.CreateSolver('GLOP')  # Бесконечность ) infinity = solver.infinity()  # Инициализация переменных в DataFrame df_products["var_id"] = np.ogrid[:df_products.shape[0]] df_products["var"] = df_products["var_id"].apply(lambda x: solver.NumVar(0.0, infinity, f"x_{x}"))  # Ограничение: Удовлетворение суточной потребности в каждом из питательных веществ for nutrient in df_nutrients_norm.itertuples():   var_sum = sum(df_products[nutrient.name] * df_products["var"])   solver.Add(var_sum >= nutrient.min)  # Целевая функция: Минимизация стоимости корзины продуктов solver.Minimize(sum(df_products["var"]))  # Решаем status = solver.Solve()  # Извлекаем результат if status == pywraplp.Solver.OPTIMAL:   daily_cost = solver.Objective().Value()   print(f'Затраты на продукты в день = {round(daily_cost, 3)}$')   print(f'Затраты на продукты в год = {round(daily_cost * 365, 3)}$')  df_products["sol"] = df_products["var"].apply(lambda x: x.solution_value())  # Обработка результата filt_diet = df_products["sol"] > 0 df_diet = df_products[filt_diet].copy()

В ценах 1939 года минимальная стоимость продуктов, которая удовлетворяет минимальным нормам питания (1940-ых гг.), составляет 0.109$ в день или 39.662$ в год. Эти результаты похожи на результаты, полученные другими исследователями (например, в этой работе). Что касается продуктов и совокупных затрат на их приобретение, получили следующее:

Пункт о разнообразии питания в модель не закладывали, предполагается всю жизнь на сушеной фасоли сидеть. По продуктам есть одно расхождение. Наша модель выбрала «Печень», в то время как у других получилось «Сгущенное молоко». О предположениях возникновения такого расхождения можете написать в комментах.

Перейдем к целевой части статьи — неопределенность.

Добавим немного неопределенности

Концепцию робастной оптимизации и схему демонстрации на примере задачи Диета Стиглера позаимствую из этой работы.

Будем рассматривать два вектора робастности:

• Решение, «близкое» к оптимальному решению каждого отдельно взятого сценария, будем называть робастным решением (solution robust).

• Решение, которое «почти» для любого отдельно взятого сценария является допустимым, будем называть робастным на уровне модели (model robust).

Откуда берется неопределенность? В магазинах на полках присутствует несколько сортов яблок, например: «Гало», «Сезонные», «Гренни Смит», «Гольден», «Белый налив» и др. Каждый из этих сортов имеет свой состав, даже внутри одного сорта состав питательных веществ может отличаться (собран в начале лета или конце; рос на солнце или в тени). Какой состав питательных веществ яблока считать эталонным? С одной стороны, мы можем расширить список продуктов всеми сортами яблок, что не решит проблему с волатильностью веществ внутри сорта. Или создать несколько наиболее вероятных сценариев состава яблок и принимать решение на основе нескольких исходов в данных.

Расширяем условие задачи. В нашем примере с Диетой Стиглера мы видим доминирование сушеной фасоли в решении. Кроме того, сушеная фасоль вносит значительный вклад в восполнении кальция. В целях простой интерпретации результатов рассмотрим неопределенность содержания кальция в темно-синей фасоли.

Пусть имеем 13 равновероятных сценариев содержания кальция в сушеной фасоли за доллар. Отмечу, так как состав продуктов приведен на 1$, то сценарии, в том числе, отражают неопределенность цены (не только состав).

Если рассмотреть наихудший сценарий , тогда получим решение, удовлетворяющее всем ограничениям для любого из сценариев. Но будет ли оно самым экономным/оптимальным для каждого из остальных сценариев в отдельности? Что если мы допустим незначительные нарушения по некоторым из сценариев, но при этом сформируем более оптимальную диету, т.е. повышаем робастность решения за счет снижения робастности модели. Одна из реализаций такого компромисса следующая:

— множество рассматриваемых сценариев;

— индекс кальция в списке питательных веществ;

— индекс сушеной фасоли в списке продуктов;

— вероятность реализации сценария ;

— содержание кальция в сушеной фасоли по сценарию ;

— вещественная переменная, размер дефицита содержания кальция в диете по сценарию ;

Ограничения:

  1. Удовлетворение суточной потребности в каждом из питательных веществ, кроме кальция:

  2. Оценка дефицита кальция по каждому из сценариев:

  3. Выполнение минимального содержания кальция, как минимум, для наилучшего сценария:

Целевая функция:

• Минимизация стоимости корзины продуктов в компромиссе с ожидаемым дефицитом кальция в диете:

Вес используется для балансирования размера ожидаемого дефицита и затрат. Если положить , то будем решать задачу наилучшего сценария. Если присвоить очень большое значение (сдвигаем акцент на выполнение ограничений), то будем решать задачу наихудшего сценария. Выбор данного параметра зависит, в первую очередь, от экспертной оценки и целей использования модели.

Ограничения типа (2) выполняют функцию оценки отклонения содержания кальция в диете от норматива по каждому из сценариев:

В свою очередь, важным является ограничение (3). Если его не добавлять в модель и положить , то модель может безнаказанно исключить кальций из рассмотрения. Во-первых, дефицит не будет штрафоваться при достаточно малых , во-вторых, экономия на затратах за счет исключения питательного вещества из рассмотрения. Добавление ограничения (3) делает снова актуальным учет норм по кальцию.

Почему сценарий наилучший? Это сценарий, когда сушеная фасоль содержит больше всего кальция в сравнении с другими сценариями. Следовательно, меньшим кол-вом фасоли можно закрыть потребность в кальции, а это приводит к снижению стоимости. Наилучший сценарий берется для того, чтобы была возможность ухудшать решение по затратам и улучшать по валидности (удовлетворению нормам) в разрезе каждого из сценариев в отдельности.

import pandas as pd import numpy as np from ortools.linear_solver import pywraplp  # Загрузка данных по нормативам и продуктам df_nutrients_norm = pd.read_csv("https://raw.githubusercontent.com/Lozkins/mos/master/data/03_diet_nutrients_limits.csv", sep=";") df_products = pd.read_csv("https://raw.githubusercontent.com/Lozkins/mos/master/data/03_diet_products.csv", sep=";", encoding="cp1251")  # Сценарии содержания кальция в сушеной фасоли lst_scenarios = [9.5, 9.75, 10, 10.25, 10.5, 11, 11.25, 11.4, 11.5, 11.75, 12, 12.25, 12.5] dct_scenarios = {idx + 1: val for idx, val in  enumerate(lst_scenarios)}  # Уровень компромиса w = 0.0498 s_cnt = len(dct_scenarios)  # Инициализируем солвер solver = pywraplp.Solver.CreateSolver('GLOP')  # Бесконечность ) infinity = solver.infinity()  # Инициализация переменных в DataFrame df_products["var_id"] = np.ogrid[:df_products.shape[0]] df_products["var"] = df_products["var_id"].apply(lambda x: solver.NumVar(0.0, infinity, f"x_{x}"))  # Переменные оценки нарушений dct_slack_vars = {i: solver.NumVar(0.0, infinity, f"e_{i}") for i in dct_scenarios}  # Ограничение: Удовлетворение суточной потребности в каждом из питательных веществ for nutrient in df_nutrients_norm.itertuples():   if nutrient.name == "Calcium (g)":     # Фильтруем фасоль     filt_navie = df_products["Commodity (rus)"] == 'Фасоль темно-синяя, сушеная'     # Ограничения для каждого сценария     for s_id, volume in dct_scenarios.items():       # Подменяем значение из сценария       df_products["Calcium (g)"] = np.where(filt_navie, volume, df_products["Calcium (g)"])        var_sum = sum(df_products[nutrient.name] * df_products["var"])       solver.Add(var_sum + dct_slack_vars[s_id] >= nutrient.min)     solver.Add(var_sum >= nutrient.min)   else:     var_sum = sum(df_products[nutrient.name] * df_products["var"])     solver.Add(var_sum >= nutrient.min)  # Целевая функция: Минимизация стоимости корзины продуктов в компромиссе # с ожидаемым нарушением ограничения по содержанию кальция в диете solver.Minimize(sum(df_products["var"]) + w / s_cnt * sum(dct_slack_vars.values()))  # Решаем status = solver.Solve()  # Извлекаем результат if status == pywraplp.Solver.OPTIMAL:   df_products["sol"] = df_products["var"].apply(lambda x: x.solution_value())   daily_cost = df_products["sol"].sum()   print(f'Затраты на продукты в день = {round(daily_cost, 3)}$')   print(f'Затраты на продукты в год = {round(daily_cost * 365, 3)}$')    # Суммарные нарушения   dct_slack_val = {key: var.solution_value() for key, var in dct_slack_vars.items()}   total_slack = sum(dct_slack_val.values())   print(f'Ожидаемый дефицит = {total_slack / s_cnt}g')

Обратимся к результатам эксперимента с подставлением различных значений . На графиках ниже представлена ошибка или дефицит кальция по соответствующему сценарию для определенного уровня .

Видим, что при увеличении снижается кол-во случаев дефицита кальция — повышается робастность модели. При только у сценария нет нарушений и этот случай имеет наименьшие затраты — робастное решение.

Рассмотрим поведение общих затрат и размер дефицита кальция в зависимости от . Разброс по затратам составляет от 0.107$ до 0.113$ в день (~5%), ожидаемый дефицит кальция от 0г до 0.08г (~10% от нормы кальция 0.8г).

Как выбрать ? У измерительных приборов есть погрешность при замерах с которой приходится мириться. Аналогичной методикой можно воспользоваться и здесь, предварительно оценивая границы допустимого ожидаемого нарушения. Например, ограничить ожидаемую ошибку 0.02г (составляет 2,5% от нормы), это будет соответствовать . При таких допущениях, в бюджет на питание можно закладывать 0.1093$ в день (если вернуться в тот самый 1939г). Немного дороже, чем в исходной линейной постановке, зато надежно (робастно).

Заключение

Разобрали принцип работы робастной оптимизации на урезанном кейсе Диеты Стиглера для случая неопределенного содержания кальция в сушеной фасоли. Несложными манипуляциями можно масштабировать подход на все питательные вещества и на все продукты, а так же на другие задачи. Отмечу, что это один из подходов к учету и обработке неопределенности данных.

Ссылки

• Справка по задаче Диета Стиглера;

• Версия статьи в Jupyter notebook.

Предыдущие материалы:

• Модель назначения машин такси на заявки;

• Модель планирования расписаний сотрудников;

• Задача мостов Кенигсберга.