Так выглядит избыточность

Коды избыточности* широко применяются в компьютерных системах для увеличения надёжности хранения данных. В Яндексе их используют в очень многих проектах. Например, применение кодов избыточности вместо репликации в нашем внутреннем объектном хранилище экономит миллионы без снижения надёжности. Но несмотря на широкое распространение, понятное описание того, как работают коды избыточности, встречается очень редко. Желающие разобраться сталкиваются примерно со следующим (из Википедии):

Меня зовут Вадим, в Яндексе я занимаюсь разработкой внутреннего объектного хранилища MDS. В этой статье я простыми словами опишу теоретические основы кодов избыточности (кодов Рида — Соломона и LRC). Расскажу, как это работает, без сложной математики и редких терминов. В конце приведу примеры использования кодов избыточности в Яндексе.

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

* Под термином «коды избыточности» в статье подразумевается инженерный термин «erasure codes».

С каждым годом курсовые для моих студентов становятся все объемнее. Например, в этом году одним из заданий была разработка метеостанции, ведь только ленивый не делает метеостанции, а студенты они по определению не ленивые, поэтому должны её сделать. Её можно быстро накидать в Cube или собрать на Ардуино, но задача курсового не в этом. Основная задача — самостоятельно, с нуля разобраться с модулями микроконтроллера, продумать архитектуру ПО и, собственно, закодировать все на С++, начиная от регистров и заканчивая задачами РТОС. Кому интересно, здесь пример отчета по такому курсовому

Так вот, появилась небольшая проблема, а именно, бесплатный IAR позволяет делать ПО размером не более 30 кБайт. А это уже впритык к размеру курсового в неоптимизированном виде. Анализ кода студентов выявил, что примерно 1/4 часть их приложения занимает FreeRtos — около 6 кБайт, хотя для того, чтобы сделать вытесняющую переключалку и управлялку задачами хватило бы, наверное… да байт 500 причем вместе с 3 задачами (светодиодными моргунчиками).

Эта статья будет посвящена тому, как можно реализовать Очень Простой Планировщик(он же SST), описанный в статье аж 2006 года и сейчас поддерживаемый Quantum Leaps в продукте Qp framework.

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

Я попробую показать как можно реализовать такой планировщик самому. Чтобы не сильно перегружать статью, рассмотрю переключение контекста на CortexM0 у которого нет аппаратного модуля с плавающей точкой.

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

Введение

Не утихают споры о том, нужны ли юнит-тесты вообще, а если нужны — то как именно их писать. Сначала писать код или сначала писать тесты? Допустимо ли нарушать инкапсуляцию при тестировании или же можно трогать только публичное API? Сколько процентов кода должно быть покрыто тестами?

Тестирование во встраиваемых системах тоже порождает немало споров. Точки зрения разнятся от "покрытие должно быть 100% + нужны испытательные стенды" до "какие еще тесты, я программу написал — значит все работает".

Я не хочу начинать холивар и вооще стараюсь придерживаться некоего разумного баланса. Поэтому для начала предлагаю рассмотреть самые "низко висящие" плоды, которые позволяет сорвать юнит-тестирование применительно к embedded-разработке.

Оглавление

Прежде чем фича попадет на прод, в наше время сложных оркестраторов и CI/CD предстоит пройти долгий путь от коммита до тестов и доставки. Раньше можно было кинуть новые файлы по FTP (так больше никто не делает, верно?), и процесс «деплоя» занимал секунды. Теперь же надо создать merge request и ждать немалое время, пока фича доберётся до пользователей.

Часть этого пути — сборка Docker-образа. Иногда сборка длится минуты, иногда — десятки минут, что сложно назвать нормальным. В данной статье возьмём простое приложение, которое упакуем в образ, применим несколько методов для ускорения сборки и рассмотрим нюансы работы этих методов.

Мои требования к идеальному движку:

• Желательно self-hosted — я пережил много закрытий сервисов, от narod.ru до google+ и точно знаю, что рано или поздно все протухает, поэтому надежнее всего держать контент у себя. Также посты могут удалять по каким-то фейковым жалобам или по DMCA, как это происходит на Medium и LiveJournal.
• Возможность подключения своего домена — мне нужен сайт-визитка со всеми проектами и ссылками в одном месте, где можно разместить портфолио, резюме, контакты.
• Минимум телодвижений и интерфейса — в идеале интерфейса CMS вообще не должно быть видно, админская панель не нужна, посты должны редактироваться, создаваться и просматриваться в одном месте.
• Полноценный WYSIWYG редактор — поддержка разметки Markdown и обработка её в реальном времени, подсветка кода, вставка картинок из буфера обмена.
• Нормальные комментарии — возможность оставлять анонимные комментарии и авторизовываться через максимум соц. сетей для персонифицированных комментариев.
• Минималистичный внешний вид — я не хочу заниматься версткой и темами, подходящее оформление должно быть из коробки.

Доброго здравия всем!

Карантин заставил меня проводить все свое время дома, в том числе и свободное время, и хотя дома есть куча дел, я умело спихнул их на сына, а сам решил наконец-то доизучать среду разработки Clion от JetBrains, тем более, что в релизе 2020.1 появилась поддержка IAR toolchain.

Все кому интересен пошаговый гайд и куча картинок велком…

TDD для микроконтроллеров. Часть 1: Первый полет
TDD для микроконтроллеров. Часть 2: Как шпионы избавляют от зависимостей
TDD для микроконтроллеров. Часть 3: Запуск на железе

В первой части нашего цикла статей мы начали освещать тему эффективности применения методологии TDD для микроконтроллеров (далее – МК) на примере разработки прошивки для STM32. Мы выполнили следующее:

1. Определили цель и инструменты разработки.
2. Настроили IDE и фреймворк для написания тестов.
3. Написали тест-лист для разрабатываемого функционала.
4. Создали первый простой тест и запустили его.

Во второй статье мы описали процесс разработки платформонезависимой логики по методологии TDD.

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

Подробности – под катом.

• Обрабатываются только 32-битные ключи и такие же значения.
• Хэш-таблица имеет фиксированный размер.
• И этот размер должен быть равен двум в степени.

В этой статье я хочу рассказать про свой проект импульсного (TOF) Open Source лидара — о том как я его делал, и каких результатов удалось добиться.

Вместо введения

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