2135
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
Снова о необходимости архитектурных схем
Продолжим пост об архитектурных схемах с более практической стороны.
– Как-то так повелось, что мы используем C4 model. Не нагромождённая и достаточно лаконичная. Если вдруг кому-то кажется, что C4 – это какая-то новомодная модель, спешу разочаровать. Придумана она была почти 20 лет назад.
– C4 model не предусматривает никакой описательной части, поэтому ко всем архитектурным схемам у нас имеется тезисное описание всех компонентов, изображённых на схеме.
– C4 несложная, но глаз может замылиться, а всё ли сделано правильно? На этот случай на официальном сайте есть чеклист (там же можно скачать pdf), по которому можно быстро проверить вашу схему на соответствие правилам и адекватность.
– Хотя я очень люблю делать схемы в визуальных редакторах, но понимаю, что реюзабельность такого творчества страдает, поэтому правильно готовить такие схемы в виде кода. Хорошим решением будет Structurizr. Опенсорсная селфхостед штуковина. Помимо самих схем, там же можно документировать своё решение.
– По моему опыту очень полезной может оказаться Deployment диаграмма. Её можно немного извратить, отойти от канонов и получить примерно такое изображение. Особенно удобно, когда существует целый зоопарк самых разнообразных сервисов. Все они в разных закрытых сетевых контурах, с разными командами поддержки. Кто-то должен предоставить вам кубер, кто-то базы, кто-то s3. Что-то будет в Harvester, что-то в Proxmox. Такая диаграмма поможет разобраться во всём этом и как-то структурировать. А новый девопс на вашем проекте скажет за такое большое человеческое спасибо.
#devfm #systemdesign #tools
Всячески стараюсь увеличить свою насмотренность и почитываю не совсем профильные, но интересные канальчики. И вот среди них Кнопочка.
Автор пишет о всевозможных исследованиях в сфере дизайна и текстов. Такие знания бывают очень полезны, когда нужно опровергнуть авторитетную точку зрения очень авторитетного спеца 😄
Если читаете что-то подобное, интересное – поделитесь, очень интересно.
#edu
Как построить систему быстрых дашбордов
На практике встречал проекты, где с мониторингом какие-то непонятки: то дашборды налеплены абы как и не используются, то они вообще не строятся, то невозможно ничего найти, то мониторинг в целом отсутствует.
Практически направленная статья от ребят из озона. Сначала автор описывает признаки дашборда здорового человека: читаемость, стабильность и скорость загрузки, согласованность данных.
Дальше всё по делу:
– Мониторьте мониторинг – важно не только наблюдать за данными, но и следить за тем, как быстро они обрабатываются. Таким образом можно выявить медленные проблемные запросы и оптимизировать их.
– Проектируйте дашборды правильно – разделяйте дашборды на общие и внутренние, ограничивайте запросы квотами, старайтесь не загружать все данные сразу, много быстрых запросов лучше, чем один тормознутый.
– Банально, ноооо делайте оптимальные запросы и храните данные тоже оптимально. В этой части приводятся полезные советы для счастливчиков, которые используют ClickHouse.
В общем, статью очень рекомендую, из неё можно узнать, в какие конкретно стороны стоит копать, какие конкретно улучшения можно делать, чтобы ваш мониторинг работал хорошо и был полезен.
У нас уже была на обзоре статья на тему мониторинга, загляните и туда.
#skills
Всё ли так просто с ретраями?
На первый взгляд ретраи кажутся простым способом улучшить отказоустойчивость. Что может пойти не так? Ребята из Яндекса написали на эту тему большую и захватывающую статью.
Автор ретроспективно на конкретных примерах показывает результаты применения простого ретрая с фиксированной задержкой, ретрая с экспоненциальной задержкой, ретрая с джиттером.
В итоге приходит к выводу, что ретраи хороши при единичных ошибках или кратковременных сбоях. Однако, при затяжном или массовом сбое ретраи только увеличивают нагрузку на сервер, что приводит к замедлению восстановления после сбоя.
Для решения этих проблем и повышения отказоустойчивости в статье выделяется три способа:
– retry budget – ограничивает количество ретраев в зависимости от количества успешных запросов
– circuit breaker – полностью отключает ретраи, если процент ошибок превышает заданный порог
– deadline propagation – в запросе содержится таймаут, после которого сервер может прекратить обработку запроса
Ссылочка на код, чтобы самостоятельно поэкспериментировать.
В столь же интересном формате у нас был обзор на статью об идемпотентности.
На эту же тему стоит посмотреть видео.
#skills #systemdesign
Всё в той же статье про порядок столбцов в Postgres автор использует термин bike-shedding.
Представьте себе ситуацию: группа людей собралась обсудить важный проект, например, строительство атомной электростанции. Вместо того, чтобы сосредоточиться на ключевых вопросах безопасности и эффективности, они тратят часы на обсуждение цвета велосипедной стоянки. Звучит абсурдно? Это и есть "bike-shedding" — термин, описывающий склонность тратить много времени на обсуждение простых и незначительных деталей, оставляя без должного внимания действительно важные задачи. Подобные вопросы привлекательны ещё потому, что обычно не требуют глубоких знаний и каждому есть что сказать, а за неверное решение не будет никакой ответственности.
Честно, очень люблю этот термин, он на уровне с bus factor ёмко выражает проблематику.
С моей точки зрения, вовремя подмечать такое и возвращать разговор в нужное русло — супер важный навык, который можно и нужно тренировать. Поэтому часто его проговариваем с ребятами, которые ведут разные встречи от груминга до общения с бизнесом.
#edu #teamwork
Инструмент для анализа узких мест базы данных
В статье из предыдущего поста автор приводит некоторые вспомогательные запросы для анализа порядка столбцов в таблице. Могу порекомендовать удобную тулзу postgres_dba, которая проведет проведет анализ и выдаст рекомендации, где и сколько потенциально можно сэкономить.
Также с помощью с неё можно посмотреть: коннекты, медленные запросы, неиспользуемые индексы, битые индексы, различные статистики и ещё всякое разное.
Мы обновили подборку всех наших постов по базам данных. Там много интересного.
UPD: в комментарии рассказали о еще одном полезном инструменте.
#tools #database
Недавно у нас был пост-стенание о том, куда христианину податься, если слак забанил. Там прошло бурное и плодотворное обсуждение. В отдельном посте расскажем о нашем выборе. Он, вероятно, своеобразный, но таковы обстоятельства. Пока тестируем.
В подкасте я упоминал, что мы по привычке пользуемся связкой Jira и Confluence. Но у ребят стало всё сильно сложнее с self-hosted — вроде бы, они вообще его убрали. Ну и платить им тоже проблемно.
Оно пока работает и кушать не просит, но в фоне мы начали смотреть на альтернативы. Расскажите, пожалуйста, чем вы пользуетесь на практике для ведения задач проектов и документации? Чем довольны, чем нет?
#tools #devfm
Мой взгляд на новые фичи python3.10-3.12
Cмотрим на полезные нововведения в питоне последних лет — улучшенные f-строки, дополнения к исключениям, объединение нескольких with, pattern matching. Лёгкая статья на пикабу / VC / vk, код примеров на гитлабе. А какие фичи прочно вошли в ваш код?
#devfm #python
Пятничное развлекательное
Два с половиной года парень делает обзоры на сервисы для ведения заметок в поисках того самого… идеального. В его коллекции уже больше сотни обзоров. Я, признаться, даже не представлял, что можно найти столько более-менее вменяемых сервисов. В общем, есть на что позалипать.
Сам я уже 10 лет использую TickTick, как для заметок, так и для таск трекинга. В целом, он меня устраивает. В порыве любопытства у меня, конечно, были попытки пересесть на что-то новое, но всё заканчивалось неудачей. Да и когда столько информации любовно собрано в одном месте, пересесть на что-то другое сложновато. Должно быть что-то ну оооочень классное.
Расскажите, что вы используете? Насколько это удобно? Есть ли какая-то система или принципы, которым вы следуете?
#fun #edu
Google design docs
Перед тем как разрабатывать что-то серьёзное – расскажи, как ты это будешь делать. Для этого существуют design docs.
В статье рассказывается о том как, устроены design docs в гугле.
Это такой достаточно верхнеуровневый документ, по которому можно быстро понять, какую проблему мы решаем, зачем её решаем, как её решаем, и почему не решаем иначе. Также документ позволяет на ранних этапах понять основные проблемы, с которыми столкнёмся, а ещё шарить знания в рамках компании.
Автор говорит, что в целом нет каких-то жёстких правил по составлению подобных документов, но указывает набор важных аспектов, которые нужно покрыть:
– Контекст документа
– Цели
– Собственно, дизайн, который должен включать некую системную диаграмму, апишки, хранилища данных, а также ограничения, в которых проектируется система
– Альтернативные решения – супер важный раздел, который расскажет о других рассмотренных решениях и причинах, почему эти решения отбросили
Важный момент: не нужно фанатично на всё клепать доки. Об этом также не стоит забывать. Если задача прямая, как железная дорога, то не стоит мудрить.
#systemdesign
Оффтоп: включили на канале платные реакции, чтобы вы могли нас поддержать. Уверены, это именно то, чего вы все ждали! :D
Прекрасная статья ARCHITECTS, ANTI-PATTERNS, AND ORGANIZATIONAL FUCKERY, написанная по мотивам треда в твиттере. Название говорит само за себя.
Очень рекомендую к прочтению.
Свою позицию я выражу двумя цитатами из этой же статьи: «It treats architecture is a job to be done, not a role to be occupied.» и «Don’t become that sad architect. Be an engineer. Own your own code in production. This is the way.»
#systemdesign
Когда cron уже не хватает
Иногда классического cron не хватает, и есть замечательная альтернатива – fcron.
Для моей задачи нужны были хитрые условия запуска с определенной частотой и определенным количеством раз, которые fcron позволяет конфигурировать.
Но у него в целом более разухабистый функционал, чем у классического cron: с зависимостью задач друг от друга, выполнением задач по условиям, с более гибкой настройкой расписания.
#tools
llama.ttf is a font file which is also a large language model and an inference engine for that model.Для рабочего взаимодействия мы обычно использовали слак. Но настал тот день, когда слак добрался до нас – до злых рюсских (цитата по BadComedian) и заблокировал всё и сразу.
Но пост не об этом. Пост о том, насколько важен качественный и удобный канал общения.
Одно время одна из команд по определенным причинам вела рабочее общение в телеграмме. Но потом было принято волевое решение перевести ребят в слак. Скооооолько было стенаний, что слак неудобный. И вообще доколе?! – спрашивали они.
И вот теперь случилось обратное, мы временно вернулись в тг, пока присматриваем альтернативу. И скоооолько сейчас стенаний, что невозможно пользоваться телеграммом. Доколе?! – спрашивают они.
Самое важное, пожалуй, это наличие тредов, когда ты можешь очень изолированно в общем потоке обсудить конкретную проблему, не теряется контекст, нет параллельных сообщений на другие темы. И наличие грамотных уведомлений. Ты получаешь уведомление, если конкретно тебя тегнули (или весь канал), либо если кто-то пишет в треде, где тебя тегали или ты писал сообщения.
По сути, ты получаешь только то, что реально к тебе относится. Также есть специальное место, где всё это можно удобно посмотреть.
Пользуясь случаем, расскажите, что вы применяете на работе?
Я смотрю в сторону mattermost. Кто знает насколько там быстро упираешься в необходимость платить? Слышал также про zulip, на вид как слак.
#tools #devfm
GraphQL
GraphQL предлагает заманчивую концепцию. По сути, это язык для запросов данных, который позволяет клиентам получать только нужные им поля без лишней информации. Он использует одну точку доступа для всех запросов и чётко определяет структуру данных, что делает обмен информацией между клиентом и сервером более быстрым и удобным.
Автор в своей статье рассказывает, какие нежданчики можно встретить при использовании этой технологии.
Проблема накручивания авторизации и rate limits – в graphql это решается сложнее, чем в rest. Также описана security проблема, при которой парсинг самого обычного запроса может привести к OOM на сервере.
В конце статьи автор предлагает набор критериев, когда вам эта технология не нужна, а также рассказывает об альтернативах, которые он видит.
В общем статья любопытная. Сам я эту технологию в production не трогал. У меня сложилось впечатление, что GraphQL – классный, когда у тебя очень-очень много клиентов, вот тогда раскрывается весь его потенциал.
#skills
Боль от распухающей базы данных
Интересный кейс от ребят из Figma. Некоторое время назад они сидели на одной жирной Postgres.
Чтобы дать себе время на разработку целевого решения, ребята сначала подстелили сначала соломку:
– Накинули железа (ну конечно, а что ещё остается делать)
– Создали несколько read реплик
– Добавили PgBouncer в свою архитектуру
– Для новых фичей стали стараться использовать отдельные базы
Шардирование оказалось очень трудоёмким, так как требовало значительных изменений в архитектуре. Поэтому ребята двинули в сторону партицирования, когда таблицы с высокой нагрузкой выносятся в отдельные базы.
Самая интересная задача тут – мигрировать данные без даунтайма.
Сделано это было в несколько шагов:
1. Подготовили клиентские приложения для работы с несколькими базами данных.
2. Настроили логическую репликацию таблиц для копирования данных из одной базы в другую. Тут, кстати, ещё интересный нюанс, логическая репликация может занимать ооооочень продолжительное время из-за долгого обновления индексов, поэтому на целевой бд индексы были удалены перед началом копирования и восстановлены после завершения копирования.
3. Короткая пауза активности на основной бд для полной синхронизации данных.
4. Назначение целевой бд как основной и перенаправление запросов к ней.
В общем, отличная статья в копилку насмотренности технологических решений.
На тему миграций без даунтайма у нас был отдельный практический пост.
#skills #database
Для чего нужны архитектурные схемы
Один из наших стартапных продуктов дозрел до того, чтобы для него подготовили архитектурную схему. По результату, я даже удивился, насколько всё стало разухабисто.
В недавнем диалоге обсуждали, для чего конкретно нам нужна архитектурная схема? Конечно, кроме того, что это просто красиво.
Пост как раз об этом.
Онбординг. Обычно технический онбординг мы начинаем с архитектурной схемы. Это позволяет новому сотруднику посмотреть на систему с высоты птичьего полета, начать ориентироваться, кто на ком стоял. Тут же можно бегло рассказать о каждом компоненте, внешних зависимостях и способах их взаимодействия. Причем это работает не только с разработчиками. Приходит к тебе нагрузочник и говорит, ну, давай рассказывай, что у вас тут. И перед тем, как кидаться в него жирной пачкой документации, ты такой опа: давай пробежимся по архитектуре, расскажу тебе, как всё устроено.
Обсуждение работ со смежными командами. Обычно разрабатываемая система работает не в соло. И есть соседние сервисы, с которыми нужно интегрироваться. Первичные обсуждения всегда удобно делать с наглядной картинкой.
Обсуждение и планирование больших фичей. Когда планируется разработка чего-то сложного, затрагивающего многие компоненты/сервисы. Опять же, можно собраться с командой разработки, аналитиками, обсудить и зафиксировать первичные договорённости. Эта же картинка будет полезна, когда перед стартом разработки будет презентоваться окончательное решение. При разработке разухабистых фичей, кстати, могут быть полезны design docs.
Напоминалка о сложности. Да, для этого также нужна архитектурная схема, просто чтобы помнить о комплексности, о потребности в людях на хозяйстве, о невозможности реализовать фичу в маленькие сроки реализации, о наличии вооот такого сервиса, о котором уже никто и не помнит.
О том, как документировать архитектуру у нас был отдельный пост.
#devfm #systemdesign #edu
Замечательный подкаст от Andrew Huberman на тему Optimal Protocols for Studying & Learning.
Насущная тема, как усвоить ту или иную информацию лучше и быстрее. Автор, опираясь на различные исследования, даёт практические советы на эту тему.
В подкасте автор затрагивает тему сна (хе-хе, банально), прерываний, чередования активностей, объяснения материала другим людям.
Особое внимание уделяется проверке своих знаний, как способа лучше усвоить материал. Это самая интересная часть подкаста. Приводятся интересные исследования на тему того, что полезнее: много раз повторить один и тот же материал, или изучить один раз и потом проверить себя?
Дальше интереснее: если проверять себя, то когда это лучше сделать: сразу, через некоторое время или через достаточно продолжительное время? Если тема сна всем понятна, то выводы, к которым приходят в этих исследованиях не всегда очевидны. В общем, рекомендую!
Для особо дотошных на сайте подкаста приведены исследования, которые упоминаются в видео.
На эту тему мы уже рекомендовали очень известный курс Learning How to Learn.
#edu
Micro — консольный редактор с человеческим лицом
Иногда приходится работать с текстовыми файлами на каком-нибудь серваке, где нет любимых графических текстовых редакторов.
Для этих целей давно использую micro – легковесный редактор с поддержкой мышки, а главное – с привычными горячими клавишами.
В нашем бесплатном курсе cli-for-dev есть урок про редакторы nano, mcedit, gedit, vim. В центре внимания горячие клавиши. Скоро допишем туда про micro.
P.S. Vim`оводам пост, конечно, будет неактуален 😄
#tools
Пятничное развлекательное
Дождались! В качестве пятничного развлекательного у нас настолка. В первом посте такого рода не будем советовать банальности, а посоветуем недавно локализованную игру — zoollywood.
С виду такая мимимишная игра с пингвинчиками, для победы в которой нужно по определённым правилам двигать своих пингвинов и размещать яйца на игровом поле. На деле все превращается в захватывающую, агрессивную баталию с пожиранием яиц соперника и желанием запустить фигурку пингвинчика в лоб оппонента. Особенно, когда противник делает какую-нибудь гадость, играя карту с руки и ломая твой стройный и продуманный путь к победе.
Игра рассчитана на двух игроков. В ней простые правила и механика, однако разнообразные дополнительные персонажи и препятствия на поле сильно повышают реиграбельность. Ещё из приятностей — игра качественно сделана и очень приятные миниатюры персонажей.
Если заинтересовались, то лучше взять побыстрее, а то тираж закончится и всё, тю-тю.
#fun
Порядок имеет значение
Захватывающая статья посвящена оптимизации хранения данных в Postgres. Оказывается, порядок столбцов в таблице влияет на занимаемое место на диске. Вот такие вот дела.
Идея в том, что Postgres использует выравнивание данных. Это приводит к добавлению дополнительных байт между столбцами для чтения и записи данных. Именно этого и нужно пытаться избегать.
В статье на конкретных примерах демонстрируется, как меняется размер данных в зависимости от порядка столбцов. Отдельное внимание уделяется NUMERIC и TEXT. Эти типы данных требуют особого подхода, так как имеют переменную длину.
В итоге, для оптимизации хранения данных нужно располагать столбцы в таблице по порядку: от больших типов данных (BIGINT, TIMESTAMPTZ) к меньшим (INT, SMALLINT, BOOLEAN) и завершать переменными типами (NUMERIC, TEXT).
Вообще звучит неплохо. Благодаря подобным махинациям можно сэкономить до 10% памяти.
#database #skills
Уходя уходи
Небольшая статья, раскрывающая достаточно непопулярную тему. Вот решили вы покинуть свою любимую компанию. Что делать, чтобы аккуратно передать все дела? С какого конца подойти? Ведь помимо основных и понятных зон ответственности, наверняка, есть много мелочей, которые даже сложно представить. Автор даёт понятный набор действий, который нужно проделать.
На самом деле это упражнение стоит проделывать и не уходя с работы. Подобное пригодится перед отпуском или для поиска мест, где у вас bus factor равен единице.
#edu
uv: Unified Python packaging
У авторов линтера ruff, которым мы активно пользуемся и всем советуем, вышло большое обновление ещё одной интересной их тулзы – uv: Unified Python packaging. Такой же, как другие пакетные менеджеры, только лучше. Ну, по крайней мере, так заявляют авторы.
В целом, как и с ruff, главные фичи – совместимость с другими пакетными менеджерами и скорость.
Подробнее можно почитать в их блоге.
На какой-нибудь пет проект обязательно затащу его, посмотреть поближе.
#tools
TimescaleDB для хранения временных рядов
В статье ребята рассказывают, как и почему они выбрали TimescaleDB для хранения time series данных. По сути, это такая надстройка над Postgres.
TimescaleDB они сравнивают с ныне популярным ClickHouse и не столь популярным QuestDB. В статье приводятся бенчмарки, важные для решения задачи. В реальных задачах немаловажными являются не только технические, но и бизнесовые аргументы, такие как наличие экспертизы – их авторы также упоминают.
В общем неплохая статья для развития насмотренности.
А ещё именно для подобной задачи хорошо подойдет практика написания design doc.
#database
Проводим ретро с помощью parabol
У нас был подкаст на тему ретро, как мы его проводим и зачем. Там же мы упоминали, что проводим ретро в миро, используя некий шаблон.
А теперь хотим поделиться просто замечательным инструментом для проведения ретро – parabol. Последние несколько ретро в разных командах проводили именно там.
Супер понятный инструмент, ведущий вас по процессу:
– накидывание поинтов (возможно, анонимное)
– таймер как помощник отслеживания времени
– группировка поинтов по темам
– голосование за актуальные темы
– накидывание задач по каждой теме с назначением исполнителя
– выгрузка результатов в различных форматах
Из плюсов: можно выбрать разные шаблоны, можно проводить и организовывать не только ретро, есть встроенные гайдлайны, как проводить ретро – очень удобно, если никогда этого не делали.
Разумеется, есть платная версия, но для проведения ретро командой хватит бесплатной.
#tools
Идеальный скрипт на bash 2
Bash всё также ужасен и также распространён. Сняли продолжение хорошо зашедшего видео.
Когда в bash использовать [], а когда [[]]?
Как лучше писать в if, привычные < и > или непривычные -lt, -gt?
Кавычки вокруг переменных в bash — можно ли опускать? Ответы в 11-минутном видео. Текстовая расшифровка видео тут.
#youtube #skills #devfm
Пятничное развлекательное
Абсолютно замечательный сайт, где можно посмотреть внешний вид разных известных приложений десятилетие назад.
Можно, например, глянуть:
– Youtube из 2012
– Skype из 2011
– Airbnb из 2010
#fun
Советы руководителю от руководителя
Эта статья прекрасна своей простотой и очевидностью, но она затрагивает очень важные аспекты.
Автор касается многих тем, особенно мне откликнулись эти:
– ты, как руководитель, не должен быть незаменим, думай о bus factor.
– старайся давать своим сотрудникам чуть больше, чем даёт кампания. Мне кажется, это очень важно. По этой части я, например, некоторым своим ребятам покупал copilot, пробивал билеты на highload++, или отстаивал необходимость повышения зп. Очень приятно создавать комфортные условия для классных ребят.
– поддерживай связь с людьми, с которыми по какой-то причине перестаешь работать. Приведу цитату автора: "С работы ты можешь унести только две вещи: опыт и связи. Цени эти вещи."
#edu #teamwork
Книга "Думай медленно... Решай быстро" от лауреата Нобелевской премии по экономике – Даниэля Канемана
Недавно второй раз перечитал эту замечательную книгу и хочу её посоветовать всем, кто ещё не читал.
Главная идея книги вращается вокруг двух систем мышления, которые автор называет Система 1 и Система 2. Система 1 работает быстро и интуитивно, часто полагаясь на автоматические реакции и ассоциации. Система 2, напротив, медленная и аналитическая, требующая больше усилий и времени для обработки информации. Канеман показывает, как эти системы взаимодействуют и как часто наша интуиция может нас подводить из-за различных когнитивных искажений.
Что особенно ценно в этой книге, так это её практическая применимость. Автор приводит множество примеров из реальной жизни и результаты психологических экспериментов, которые иллюстрируют, как мы принимаем решения в разных ситуациях — от повседневных задач до сложных финансовых выборов. Он объясняет, почему мы склонны к ошибкам в оценке рисков и вероятностей и как наши эмоции могут влиять на рациональные решения.
Книга поможет лучше понять механизм своего мышления, повысить осознанность в принятии решений и избежать распространённых ошибок. Также позволит вам лучше понять себя и других, а также научиться принимать более взвешенные и обоснованные решения в различных сферах жизни.
#books
🚀 Автор @sberlogabig приглашает Вас в неформальный проект.
Минимальные требования – навыки Python или хорошие знания теории групп (в идеале GAP, SAGE). Загрузка несколько часов в неделю. Задача проекта – применить машинное обучение к теории групп. Целью проекта является статья в хорошем журнале, участники – соавторы.
Если Вам интересно участие – напишите @alexander_v_c (Александр Червов, к.ф.-м.н. мехмат МГУ, 25 лет math&DS, Kaggle, Scholar, Linkedin).
Чат для обсуждений
Вводный доклад
Пояснения по RL части
Краткая суть задачи - нахождение пути на графе от вершины А до вершины Б, но размер графа 10^20-10^50 – обычные методы не применимы. Решение пазла типа Кубика Рубика. Задача близка к прошедшему конкурсу Каггл Санта 2023. Математически – разложение элемента группы по образующим. Математические пакеты, которые частично могут решать эту задачу – GAP, SAGE.
Достигнутые результаты - уже сейчас мы можем за минуты делать то, что авторы работы DeepCube делали за 40 часов на многих GPU.