Разработка

Рудирон и ROS-сообщество (Robot Operating System)

С 4 по 6 апреля 2025 года, участвовал в ROS Workshop 2025 который проходил в РТУ МИРЭА

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

В рамках мероприятия прошли открытые воркшопы по темам:

• AI-ускорители для встраиваемых систем

• OpenPlaceRecognition: Иерархическое распознавание места для локализации роботов

• Картирование и локализация с использованием графа локаций и технологии Place Recognition

• Много-агентное планирование путей

• Организация ДПО по инженерии и робототехнике в школе

и др.

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

Команды на протяжении 2.5 дней проектировали, собирали и тестировали свои решения. Для этого в распоряжении участников был лабиринт и поле с расчерченными линиями.

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

После приветственного слова люди участники разделились на две группы. Одна часть погрузилась в тему низкоуровневого управления четвероногим роботом Unitree, пока другая оправилась на битву за самое удобное место рядом с розеткой и паяльником.

Во время организационной суматохи посетители получили возможность посетить стенды партнеров мероприятия. Ими выступили Sber Robotics, Аквариус и Эремекс.

Аквариус представил образовательный контроллер Рудирон (подробнее можно прочесть в статье), и набор Рудирон.Робо. Частью этого набора является колесный робот на контроллере Рудирон, который, по результатам хакатона, стал дружить с ROS2.

Эремекс представил САПР для программирования и отладки отечественных контроллеров любых компаний. Эта САПР придет на замену STM32CubeMX, и даст инструмент для более качественной работы с российскими микроконтроллерами.

Нельзя использовать goto

Часто говорят, что goto плох. А собственно, почему?

В ассемблерном коде на машинном уровне все управляющие конструкции (if, while, for и другие) преобразуются в набор команд с безусловным переходом jmp (UPD: меня поправили, с безусловным или условным переходом, но по указанному адресу, то есть куда угодно).. А такой переход — самый настоящий goto. То есть ты весь такой изящный во фраке пишешь циклы, а наглый компилятор/интерпретатор выкидывает всю красоту и делает goto.

Так почему же сам goto является признаком плохого кода, если он на самом деле везде?

Ответ кроется в умении сохранять контекст. Человек может в голове держать 5-9 сущностей, больше не получается. Поэтому придумали функции, и придумали держать их небольшими — для снижения когнитивной сложности. Конструкция if переведёт тебя в одну из веток ниже, циклы for и while выполнят тело цикла или выбросят за его пределы. Команда goto сложность привносит — прыжок может быть куда угодно. А повышение сложности всегда приводит к росту числа ошибок.

Как вызвать событие только для указанной (одной или более) группы плагинов в Joomla 5

Обычно события в Joomla вызываются следующим образом:

Шаг 1: Получаем объект диспечера

В коде Joomla можно найти несколько способов получить объект диспечера:

От приложения:

$dispatcher = Joomla\CMS\Factory::getApplication()->getDispatcher();

Из контейнера:

$dispatcher = Joomla\CMS\Factory::getContainer()
 ->get(Joomla\Event\DispatcherInterface::class);

Свой диспечер (если ваш класс реализует Joomla\Event\DispatcherAwareInterface):

$dispatcher = $this->getDispatcher();

Шаг 2: Подключаем плагины нужной группы

PluginHelper::importPlugin('mycomponent');

Шаг 3: Создаём экземпляр события и вызываем метод диспечера dispatch

$dispatcher->dispatch('onMyComponentEvent', $event);

В результате будут вызваны плагины не только группы mycomponent, но и всех ранее подключенных групп (например, 'system'). Потому что любым из вышеперечисленных способов, мы получаем возвращают один и тот же экземпляр диспечера. И код PluginHelper::importPlugin('mycomponent'); работает с тем же экземпляром диспечера.

А следующим образом можно вызвать плагины только нужных групп:

// Создаём свой обьъект диспечера
$dispatcher = new Dispatcher;

// Подключаем нужную группу плагинов, и четвертым параметром передём наш диспечер
PluginHelper::importPlugin('mycomponent', null, true, $dispatcher);
// Так же можем подключить ещё одну группу
PluginHelper::importPlugin('content', null, true, $dispatcher);

// Создаём екземпляр события
// ...

// Вызываем метод dispatch
$dispatcher->dispatch('onMyComponentEvent', $event);

Глава платформы электронной коммерции Shopify Тобиас Литке опубликовал в соцсети X письмо сотрудникам, в котором рассказал, что использование ИИ стало базовым навыком в компании, который ожидается от каждого сотрудника вообще без исключения:

• эффективное использование ИИ теперь является базовым ожиданием от каждого сотрудника Shopify. Сегодня это универсальный инструмент, важность которого будет только расти. Откровенно говоря, я не считаю возможным отказаться от изучения навыка применения ИИ в своей работе; вы можете попробовать, но я хочу честно сказать, что не вижу, как это может сработать сегодня, а тем более завтра. Стагнация практически неизбежна, а стагнация — это провал в замедленном режиме. Если вы не карабкаетесь вверх, вы скатываетесь вниз.

• ИИ должен быть частью фазы прототипирования в любом GSD-проекте (аббревиатура GSD в данном контексте означает Get Stuff Done — философия фокуса на результат и эффективное выполнение задач). Фаза прототипирования любого GSD-проекта* должна включать активное исследование возможностей ИИ. Прототипы предназначены для обучения и создания информации. ИИ радикально ускоряет этот процесс. Вы можете научиться создавать то, что другие члены команды смогут посмотреть, использовать и оценить за долю времени, которое это занимало раньше.

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

• обучение — это самостоятельный процесс, но делитесь тем, что вы узнали. У вас есть доступ к максимальному количеству передовых инструментов ИИ. У нас есть chat.shopify.io, который существует уже несколько лет. Разработчики имеют доступ к proxy, Copilot, Cursor, Claude code — всё настроено и готово к использованию. Мы будем учиться и адаптироваться вместе как команда. Мы будем делиться победами (и поражениями!) друг с другом, экспериментируя с новыми возможностями ИИ, и будем уделять время интеграции ИИ в наших ежемесячных бизнес-обзорах и циклах разработки продуктов. В Slack и Vault есть много мест, где люди делятся разработанными запросами, например #revenue-ai-use-cases и #ai-centaurs.

• прежде чем запрашивать увеличение штата и ресурсов, команды должны продемонстрировать, почему они не могут выполнить желаемое с помощью ИИ. Как бы выглядела эта область, если бы автономные ИИ-агенты уже были частью команды? Этот вопрос может привести к действительно интересным обсуждениям и проектам.

• все значит все. Это относится ко всем нам — включая меня и руководящую команду.

Как выбрать языковую модель для семантического поиска

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

Bi-Encoder — состоит из двух трансформеров encoder-only. С помощью passage-encoder получаются эмбеддинги для всех чанков в базе знаний. Запрос от пользователя кодируется с помощью query-encoder. На этапе поиска высчитывается косинусное расстояние между query-embedding и passage-embedding. Мы получаем поисковую выдачу после ранжирования всех пассажей по убыванию косинусного расстояния. В отличие от следующей архитектуры Cross-Encoder, можно заранее сохранить эмбеддинги для пассажей и использовать их для подсчета расстояния.

Cross-Encoder — трансформер с архитектурой encoder-only и ранжирующим слоем. Этот слой выдает оценку релевантности запроса к пассажу. На вход подается двойка: запрос и пассаж. Cross-Encoder лучше понимает семантическую связь между пассажем и запросом, но для каждого пользовательского запроса он работает медленнее, так как для оценки релевантности запроса и пассажей, cross-encoder нужно запустить N раз, где N — количество пассажей.

Мы будем использовать Bi-Encoder, так как у нас много пассажей в базе знаний.

Для выбора модели удобно использовать открытый бенчмарк MTEB с рейтингом по различным моделям в зависимости от вашей задачи. Для нас лучшей оказалась модель multilingual-e5-large, Bi-Encoder c 560M параметров и размером эмбеддингов в 1024 элемента.

Инженер по разработке ПО искусственного интеллекта Павел Яковлев максимально подробно рассказал в статье, как его команда разрабатывает и оптимизирует семантический поиск по сложным документам: PDF, HTML и DOCX.

MTS AI выпустила Kodify 2 — второе поколение ИИ-ассистента для разработчиков:

• 7 млрд параметров, 

• контекст до 32 тыс. токенов, 

• поддержка 90 языков программирования,

• OpenAI-совместимый API для простой интеграции с другими системами. 

В отличие от первого поколения Kodify, использующегося c 2024 года лишь в компаниях, входящих в ПАО «МТС», Kodify 2 станет доступен внешним заказчикам.

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

Подробнее на сайте разработчика. Демо на Java и Python здесь.

РТУ МИРЭА совместно с АО НИЦ и Ассоциацией РУСИБ приглашает всех, интересующихся Инфобезом, с 7 апреля по 31 мая принять участие в гибридном хакатоне NeedForFWSpeed на самое быстрое ПО межсетевого экрана и побороться за призовой фонд 0,6 млн рублей.

Все конкурсанты будут использовать одинаковые аппаратные платформы и одинаковые датасеты. Так что старт у всех будет с одной линии.

В качестве аппаратной платформы всем предлагается RPi CM4 MilkV с процессором архитектуры RISC V – мы стойкие сторонники OpenSource.

Зато нет никаких ограничений на ПО. Можно взять абсолютно стандартную сборку *nix и пойти с ней. Можно хорошенько пооптимизировать iptables/nftables, сетевые драйверы и настройки IP-стека и получить прирост производительности. В придачу можно поотключать в ОС и всё лишнее, можно собрать свою кастомную сборку и много чего ещё.

Можно взять и операционку полегче, ОС РВ или Нейтрино, и попытаться получить выигрыш за их счёт. Можно вообще написать свой код, взяв за основу исходники IP-стека, так сказать, BareMetal в чистом виде.

По условиям соревнований не важно, сколько человек в команде, один или пять, какой у Вас возраст и образование, какой опыт работы и какой стек технологий – значение имеет только СКОРОСТЬ РАБОТЫ МЕЖСЕТЕВОГО ЭКРАНА. Никаких взвешенных коэффициентов, призов зрительских симпатий и симпатий жюри. От жюри нужно будет одно – подписать итоговый протокол.

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

Все подробности и регистрация на сайте https://securitygc.ru

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

PS ... и да, среди нас есть фанаты ленты Need For Speed, и скорость межсетевого экрана нам тоже очень нужна.

«Три генеральных директора Microsoft входят в комнату...» — написал Сатья Наделла, — «и их интервьюирует Copilot!»

В рамках празднования 50-летия Microsoft, генеральный директор Microsoft Наделла присоединился к бывшим генеральным директорам Microsoft Биллу Гейтсу и Стиву Балмеру в забавном двухминутном видео, в котором Наделла просит Copilot «прожарить» каждого из них с помощью ИИ.

«Хорошо, Сатья», — отвечает Copilotт. «Давай добавим перца...».

Copilot: Стив, начнем с тебя. Твой энтузиазм легендарен. Но ты когда-нибудь беспокоился, что твоя энергия может закоротить ИИ? Я имею в виду, даже роботам нужен перерыв на кофе после твоих зажигательных речей.

Стив Балмер: Давай, чувак! Если ты не можешь справиться со мной, ты не сможешь справиться с огромным процентом населения мира! Мы рассчитываем на тебя!

Copilot: Ха-ха, справедливое замечание, Стив. Теперь, Билл, у тебя этот фирменный вдумчивый взгляд. Но ты когда-нибудь думал, что ИИ может испугаться твоего напряженного, думающего лица? Я имею в виду, он как будто ждет момента синего экрана.

Билл Гейтс: Я надеюсь на это. Я имею в виду, что это все, что у меня осталось, поскольку ИИ становятся такими чертовски умными. Именно этот взгляд и моя готовность критиковать отличают меня.

Copilot: И это действительно грозный взгляд, Билл.

Стив Балмер: Copilot, ты когда-нибудь был бы готов критиковать его?

Copilot: Безусловно. Критика — это то, где происходит рост. Теперь, Сатья, ИИ, похоже, твой лучший друг — но ты когда-нибудь беспокоился, что твоя глубокая страсть к ИИ может однажды заставить его управлять шоу, оставив тебя просто наслаждаться поездкой?

Сатья Наделла: Что ж, в тот день, когда ИИ сможет играть как лучший игрок в крикет, который мне нравится, в тот день он сможет управлять шоу, насколько я могу судить.

Copilot: Туше, Сатья. Посмотрим, сможет ли он достичь столетия в крикете, а потом поговорим.

Это был взрыв, джентльмены. За еще 50 лет инноваций и приключений. Ура.

Балмер, Наделла и Гейтс: Ура.

Билл Гейтс: Что бы это ни значило для ИИ. Он случайно не выпивши?

Управление очередностью плагинов в Joomla 5 с помощью приоритетов обработки событий

В Joomla 5 плагины подписываются на события с помощью интерфейса Joomla\Event\SubscriberInterface в нём всего один метод — getSubscribedEvents(), который должен вернуть массив соответствий событий, которые будет прослушивать этот плагин и их обработчиков.

Например, в плагине «Content — Email Cloaking» этот метод выглядит следующим образом:

    public static function getSubscribedEvents(): array
    {
        return ['onContentPrepare' => 'onContentPrepare'];
    }

Ключи массива — имена событий, а элементы масива — имена методов класса плагина.

Но если посмотреть на этот же метод плагина «Behaviour — Backward Compatibility»:

    public static function getSubscribedEvents(): array
    {
        /**
         * Note that onAfterInitialise must be the first handlers to run for this
         * plugin to operate as expected. These handlers load compatibility code which
         * might be needed by other plugins
         */
        return [
            'onAfterInitialiseDocument' => ['onAfterInitialiseDocument', Priority::HIGH],
        ];
    }

То видим что в нём элементы массива - тоже массивы, первый элементом которых - имя метода, второй - приоритет Joomla\Event\Priority::HIGH. И комментарий объясняет что событие onAfterInitialise этим плагином должно обрабатываться раньше чем другими плагинами, потому что этот плагин загружает код, необходимый для работы других плагинов.

Всего доступно семь уровней приоритета:

public const MIN = -3;
public const LOW = -2;
public const BELOW_NORMAL = -1;
public const NORMAL = 0;
public const ABOVE_NORMAL = 1;
public const HIGH = 2;
public const MAX = 3;

По-умолчанию устанавливается «нормальный» приоритет.

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

⚡️Вести с полей - Duit

Новый релиз flutter_duit v3.4.0!

Что внутри:

• ⚙️ Новые виджеты: GridView, Card, AppBar, Scaffold, InkWell, CarouseView, AnimatedContainer

• ⚙️ Повышена минимальная версия Flutter SDK для использования Duit (3.24.x)

Подробности о самом интересном:

🔥 Поддержка виджетов Scaffold, AppBar и Card ознаменует начало работы над полноценной реализации всего набора виджетов из библиотеки material

🚀 Приведен в порядок публичный проект на github, который поможет отслеживать прогресс разработки виджетов и новых фич фреймворка

О проекте:

• Документация

• Поддержать кодом

🤖 LLM-агенты: какие фреймворки использовать и зачем?

Если вы интересовались темой LLM-агентов, то вот краткий гид по популярным решениям — что выбрать и когда.

🧠 AutoGen (Microsoft)

🔹 Что это? Фреймворк от Microsoft для создания мультиагентных систем, где агенты взаимодействуют в диалоговом режиме для совместного решения сложных задач.

🔹 Когда использовать?

✔ Нужно смоделировать команду агентов (например, менеджер + разработчик)

✔Требуется гибкая настройка взаимодействия между агентами для продакшена.

✔Ищете масштабируемое решение для корпоративных задач.

🧠 CrewAI

🔹 Что это? Лёгкая библиотека для быстрой организации «экипажа» агентов, каждый из которых выполняет свою роль в цепочке обработки задачи.

🔹 Когда использовать?

✔ Нужно быстро собрать прототип, где агенты передают задачи друг другу (например, планирование → сбор данных → кодирование).

✔ Подходит для демонстраций и небольших проектов, где важна слаженность работы «команды».

🧠 LangGraph / LangChain Agents

🔹 Что это?Мощные фреймворки, позволяющие создавать сложные цепочки обработки информации с интеграцией LLM, внешних API, баз данных и прочих инструментов.

🔹 Когда использовать?

✔ Строите продакшен-решение с множеством этапов и компонентами.

✔ Требуется интеграция с внешними сервисами, хранение состояний, сложная логика обработки.

✔ Готовы инвестировать время в изучение более сложного, но гибкого инструментария.

🧠 SmolAgents

🔹 Что это?Минималистичный инструмент для создания одного или нескольких LLM-агентов без лишнего оверхеда, идеально подходит для экспериментов и небольших проектов.

🔹 Когда использовать?

✔ Хотите разобраться в принципах работы LLM-агентов без сложных зависимостей.

✔ Планируете pet-проект или прототип с акцентом на простоту и понятность.

✔ Ищете быстрый способ автоматизации рутинных задач с помощью ИИ.

Скоро на хабре расскажу вам подробнее о том, что есть SmolAgents и с чем это едят!

Хотели бы узнать про другие фреймворки? К слову все они уже ждут, когда вы интегрируете их с новинкой!

Очень интересный прогноз и сценарное планирование от вполне себе компетентных людей AI 2027 Рекомендую прочесть.

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

🔥 Meta представляет Llama 4: ИИ-модель с гигантским контекстом и мультимодальными возможностями! 🔥

🌟Горячие модельки вышли из печки Meta и даже успели релизнуться веса на hugging face , правда модель здоровяк Behemoth ещё находится в обучении

Что тут у нас по модели? 👇

🚀Llama 4 Scout:

📊 17B активных параметров и MoE с 16 экспертами.

🔑 Контекст — 10 миллионов токенов (это прям рекорды!).

💻 Запускается на одной GPU H100 — да, так, по-настоящему круто!

👑Llama 4 Maverick:

📊 17B активных параметров и на 128 экспертов,

🔍как заявляет компания модель примерно как GPT-4o и даже ссылоку на LLM arena не забыли оставить!

Моделька сейчас на 2 месте!!

💥Llama 4 Behemoth: Самый

📊большой тяжеловес на 288B активных параметров на 16 экспертов.

Пока в обучении, но очень ждем!

Слежу для вас за обновлениями! Как впечатления от релиза?✨

Нормальный ли у меня код?

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

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

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

Быстрый по скорости и компактный по данным. Другими словами, код должен быть нормальной вычислительной и пространственной сложности. Тут помогают и интуитивные представления (что-то тормозит), и теория вычислительной сложности (О-нотация). Если вы сортируете записи за O(n^3) и требуете O(n^5) оперативной памяти, то вы делаете что-то не так.

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

Если, конечно, не горят сроки

Как автоматизированно извлекать текст из видео на YouTube?

Знакомо: нашёл на YouTube ролики, в которых есть тонна полезной информации, а тратить часы на просмотр — нет времени?

В 2018 году появился проект youtube-transcript-api (GitHub) — Python-модуль, который за пару секунд извлекает субтитры из видео.

Но есть нюансы:
⚠️ Требует сетевого доступа к YouTube (может не работать в некоторых странах)
⚠️ Использует неофициальное API
Вот что пишет создатель проекта:

Этот код использует недокументированную часть API YouTube, которая вызывается веб-клиентом YouTube. Поэтому нет гарантии, что он не перестанет работать завтра, если они изменят то, как все работает. Однако я сделаю все возможное, чтобы все заработало как можно скорее, если это произойдет. Так что если он перестанет работать, дайте мне знать!

Как использовать?
1️⃣ Установить библиотеку youtube-transcript-api (PYPI)
2️⃣ Взять ID интересующего видео (поддается автоматизации)
3️⃣ Запустить скрипт (📖 официальная документация)

Если вам понравился пост и вы хотите узнавать больше о подобных инструментах, то можете подписаться на мой авторский Telegram-канал BritLab!

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

Не нашёл я простого инструмента, поэтому догадайтесь - сделал сам! Делал изначально для подписок, поэтому назвал When Pay, но теперь добавляю поход к врачу или дату поездки на поезде. В общем удобно и просто. Можно сделать задачу на 2035й год, к примеру.

Бот бесплатный, поэтому не дизлайкайте. Просто делюсь им с вами, товарищи любители запланировать и не прощёлкать!

Ссылка: https://t.me/when_pay_bot

Определение переменных и вызов функций в Rust

Взглянем на код:

fn main() {
	let a = 10;
	let b: i32 = 20;
	let c = 30i32;
	let d = 30_i32;
	let e = add(add(a, b), add(c, d));

	println!("(a + b) + (c + d) = {}", e);
}

fn add(i: i32, j: i32) -> i32 {
	i + j;
}

Определение функции начинается с ключевого слова fn. Точка входа в Rust-программы - это функция main. Она не получает никаких аргументов и не возвращает никаких значений.

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

Также можно указывать конкретный тип данных разными способами:

1. Через двоеточие

2. Числовые литералы могут включать аннотации типов

В последней строке вызывается макрос println! для вывода текста.

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

И наконец, функция add имеет аргументы с указанными типами данных и возвращает нужный тип данных. Как вы видите, возврат значения происходит автоматически, для этого не используются ключевые слова по типу return.

Поговорим о создании переменных. В Rust они бывают мутабельными (mutable) или немутабельными (unmutable), то есть изменяемые и неизменяемые. Неизменяемые переменные можно сравнить с константами.

Разберем пример:

fn main() {
	let a = 10;
	a = 15;
}

Если мы скомпилируем данную программу, то получим ошибку:

error[E0384]: cannot assign twice to immutable variable `a`
  --> src\main.rs:25:5
   |
24 |     let a = 10;
   |         - first assignment to `a`
25 |     a = 2;
   |     ^^^^^ cannot assign twice to immutable variable
   |
help: consider making this binding mutable
   |
24 |     let mut a = 10;
   |         +++

Т.к. все переменные в rust изначально неизменяемые, то мы не можем изменить переменную. Компилятор нам подсказывает, что для изменения значений надо добавить ключевое слово mut.

Добавим:

fn main() {
	let mut a = 10;
	a = 15;
	println!(a);
}

Программа успешно скомпилируется и мы получим 15.

Но также существуют константы. Подобно неизменяемым переменным, константы — это значения, которые связаны с именем и не могут изменяться, но между константами и переменными есть несколько различий. Во-первых, нельзя использовать mut с константами. Константы не просто неизменяемы по умолчанию — они неизменяемы всегда. Для объявления констант используется ключевое слово const вместо let, а также тип значения должен быть указан в аннотации.

fn main() {
	const THREE_HOURS_IN_SECONDS: u32 = 60 * 60 * 3;
}

Имя константы - THREE_HOURS_IN_SECONDS, а её значение устанавливается как результат умножения 60 (количество секунд в минуте) на 60 (количество минут в часе) на 3 (количество часов, которые нужно посчитать в этой программе). Соглашение Rust для именования констант требует использования всех заглавных букв с подчёркиванием между словами. Компилятор может вычислять ограниченный набор операций во время компиляции, позволяющий записать это значение более понятным и простым для проверки способом, чем установка этой константы в значение 10 800.

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

Еще момент - в листингах выше мы не декларировали тип данных переменных.

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

fn main() {
	let mut a = 10;
	a = "hello"; // возникнет ошибка
}

Мы не можем поменять тип данных, которые хранятся в переменной. Обычно типы данных указывают так:

fn main() {
	let mut a: i32 = 10;
	a = 15;
}

Область видимости и затенение переменных в Rust

Затенение переменных

В Rust, также как и в большинстве ЯВУ, можно "затенять переменные", то есть создавать вторую переменную с таким же именем, используя значение первой переменной:

fn main() {
    let x = 5;

    let x = x + 1;

    {
        let x = x * 2;
        println!("The value of x in the inner scope is: {x}");
    }

    println!("The value of x is: {x}");
}

Эта программа сначала привязывает x к значению 5. Затем она создаёт новую переменную x, повторяя let x =, беря исходное значение и добавляя 1, чтобы значение x стало равным 6. Затем во внутренней области видимости, созданной с помощью фигурных скобок, третий оператор let также затеняет x и создаёт новую переменную, умножая предыдущее значение на 2, чтобы дать x значение 12. Когда эта область заканчивается, внутреннее затенение заканчивается, и x возвращается к значению 6. Запустив эту программу, она выведет следующее:

The value of x in the inner scope is: 12
The value of x is: 6

Область видимости

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

fn main() {
    // Эта переменная живёт в функции main
	let long_lived_binding = 1;  
	let shadowed_variable = 1;  
	  
	// Это блок, он имеет меньшую область видимости, чем функция main  
	{  
	    // Эта переменная существует только в этом блоке  
	    let short_lived_binding = 2;  
	    let shadowed_variable = 2;  
	  
	    println!("shadowed variable: {}", shadowed_variable);  
	  
	    println!("inner short: {}", short_lived_binding);  
	}  
	// Конец блока  
	println!("shadowed variable: {}", shadowed_variable);  
	  
	println!("outer long: {}", long_lived_binding);
}

Как писать REST API — 9 правил

REST API (Representational State Transfer Application Programming Interface) — это архитектурный стиль взаимодействия между клиентом и сервером через HTTP. Он определяет принципы построения API, обеспечивая стандартизированный и эффективный обмен данными между различными системами.

1. GET-запросы не должны что-то сохранять, удалять или изменять. Нельзя менять какие-либо данные на стороне сервера при GET-запросе. Почему? GET-запросы часто кешируются на стороне клиента.

2. POST запросы для загрузки/создания сущностей, PUT для изменения в сущности, а PATCH - для мелких изменений в сущности.

3. Наименование эндпоинтов. Должен присутствовать единый стиль, и желательно во множественном числе, ибо это более лаконичнее. Например, эндпоинт /users. Можно и единственное число использовать, но обосновано.

4. Иерархия. Нужно соблюдать единую иерархию для построения запросов. Конструкции /users/1/friends/3/items/4 будет неудобно использовать разработчикам клиентских приложений. Нужно избегать такую иерархию, нужно конкретно указывать что нам нужно, не перезагружать данными.

5. Соблюдайте версионирование API. Допустим: /api/v1/get_all_users и /api/v2/get_all_users. При выходе новой версии не всегда разработчики готовы переписать логику клиентских приложений, и для этого нам нужно разделять версии API

6. Чувствительные данные. Очень важный момент. Например, передача различных паролей в Query-параметрах запрещено, только в теле запроса.

7. Из 6 вытекает 7е правило: не логируйте персональные и прочие секретные данные. Было несколько случаев, когда из-за логирования параметров утекали данные пользователей.

8. Расширение ответов. Во-первых, не передавайте массивы в самом верхнем уровне ответа. JSON-ответ от сервера не должен быть массивом, только словарь (ключ-значение). Если мы будем возвращать список, в будущем нам будет неудобно расширить ответ сервера, добавив дополнительные параметры. А также иногда в API разработчики делают обязательные параметры, например помимо самих данных параметр success и error, чтобы клиентское приложение могло понять, что произошла ошибка, или наоборот, успешно выполнилось.

9. Работа с датой и временем. Есть два метода - использование Unix Timestamp (количество секунд прошедших с 1 января 1970 года). Это в какой-то степени более удобно для машины, но менее удобно для клиентского разработчика. И второй метод как раз делает формат даты и времени более понятным - это ISO 8601 (2025-04-05T12:00:00.100Z). Этот метод более удобный, т.к. мы понимаем дату и часовой пояс, точное время.

10. Бонусное правило, лично мое. Относится не только к REST API, но и в принципе к программированию. Пишите код так, как будто эта поэма, книга. Попробуйте сами поработать со своим API, будто вы его не писали. Разделение ответственности, единая точка отказа, Don't Repeat Yourself и даже Keep It Simple, Stupid. Все это конечно-же вариативно.

Запускаем MIPI DSI экраны от смартфонов 🚀

Приветствую, друзья! Некоторое время назад мне удалось-таки сделать обратную разработку нескольких экранов от смартфонов с интерфейсом MIPI DSI.

В какой-то момент пришло время пробовать запускать и проверять наработки, но под рукой не было удобного железа с MIPI DSI видеовыходом. Поэтому решил спроектировать свою плату, а по пути узнать что-то новое.

Обратная и прямая разработки поскакали в одной упряжке.)

Посмотрим живой процесс разработки. Это всегда интересно!

Будем надеться, скоро выйдет эта серия статей.

Подписывайтесь и следите за обновлениями, чтобы не пропустить! 🚀

Интересна ли вам эта тема? Что интересует больше всего?