Что общего у мазка кистью и траекторией движения робота? На первый взгляд ничего. Один — порыв души, след мгновения, другой — холодный расчёт. Но можно ли найти точку их соприкосновения?
Сегодня мы показываем пет-проект Антона Чистякова, менеджера проектов в Яндексе. Он навайбкодил на Python софт, который позволяет коллаборативному роботу-манипулятору (uFactory Lite 6) самостоятельно пройти весь путь художника: от смешивания красок до финального штриха на холсте.
P. S. Антон — не волшебник, а только учится, и поэтому просит не ругать его код
Этот пост — часть спецпроекта «Наши любимые петы». Ранее мы рассказывали про другие личные проекты яндексоидов: инструмент для передачи данных по сети и среду для автоматизации маркировки напитков.
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍3🔥3
На прошлой неделе мы собрали в зале 120 питонистов! Обсудили с ними главные технические изменения в Python за год и разобрались, что происходит с культурой и экспертизой в сообществе. Поговорили про 3.14, PEP’ы и Rust в CPython, а ещё поделились прогнозами.
Благодарим экспертов:
А ещё спасибо всем, кто был с нами офлайн и онлайн, участвовал в дискуссии и задавал вопросы!
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥3🤔2👍1🌚1
Долгий процесс со множеством состояний, таймеров и внешних событий создаёт много сложностей при разработке. Раньше для такой системы нужны были не просто танцы с бубном, а целый концерт: стейт‑машина с полудюжиной состояний, очереди и воркеры, обработчики на каждое событие и блокировки от race conditions.
С этой проблемой мы столкнулись и в процессинге Яндекс Еды. Жизненный цикл заказа от оплаты до доставки — яркий пример такой распределённой логики. Но в итоге решение мы нашли. И весьма элегантное.
e, err := w.prepareExecutor(ctx, req)
if err != nil {
return nil, err
}
if err := e.CreateAndPay(); err != nil {
return e.HandleResult(err)
}
if err := e.InitializeNativeDelivery(); err != nil {
return e.HandleResult(err)
}
if err := e.WaitForOrderConfirmation(); err != nil {
return e.HandleResult(err)
}
if err := e.WaitDelivery(); err != nil {
return e.HandleResult(err)
}
return e.HandleResult(nil)
Теперь это выглядит как одна линейная функция-воркфлоу. Она читается как описание бизнес-логики, но при этом гарантированно выполняется от начала до конца. А ещё она переживает падения сервисов и временные сбои зависимостей.
А ещё в статье мы разбираем:
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🥴4🙈4💊1
Есть способы защиты, которые можно использовать в продуктовом коде уже после релиза. Это харденинг — система, которая позволяет находить и предотвращать различные ошибки и уязвимости. Например, выходы за границу буфера, обращения по невалидному адресу, переполнения целочисленной переменной и так далее.
Для C/C++ это особенно актуально. Так, 70% уязвимостей в Microsoft и критических багов в Chromium — ошибки памяти, а из них 70% — это 0-day. Некоторые госучреждения и вовсе рекомендуют избегать C++ в пользу более безопасных языков.
С этой атаки началась практическая эксплуатация уязвимостей памяти. Злодей переполняет буфер, перезаписывает локальные переменные и адрес возврата. После этого он кладёт на стек вредоносный код и изменяет адрес возврата так, чтобы процессор начал выполнять его после выхода из функции. Это часто приводит к получению полного контроля над системой.
В этой атаке вместо размещения своего кода злоумышленник перезаписывает адрес возврата на стандартную библиотечную функцию, которая уже присутствует в памяти. На 32-битных системах аргументы для неё также передаются через стек, поэтому хакер может заставить программу выполнить команду в обход запрета на выполнение кода в стеке.
Атакующий находит короткие последовательности инструкций, которые заканчиваются командой возврата ret. Путём переполнения буфера на стеке создаётся целая цепочка таких адресов, после чего начинаются прыжки туда-сюда. В результате хакер получает доступ к шеллу.
Эта угроза связана с переполнением буфера, расположенного не на стеке, а в динамической памяти — куче. Это позволяет перезаписать данные соседнего буфера и контролировать критичные для программы переменные. А ещё так можно испортить метаданные аллокатора.
А весь плейлист целиком с другими докладами C++ Zero Cost Conf 2025 найти можно тут:
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍2