Embedded, мать его

Как это, руководить проектом (пусть даже студенческим) по разработке мелкого устройства на микроконтроллере? Да очень просто:

— вчера ты шутишь про «быстрые китайские чопперы» (не мотоциклы);
— сегодня — разбираешься в нюансах работы gdbserver поверх TCP;
— завтра — еще какая-нибудь ебала вылезет.

Впрочем, now it’s official — удалось прикрутить к Blackmagic Debug Probe поддержку TCP, причем нормально, а не как в ctxLink:

Дальше в планах — дальше допиливать обещанный как-то в комментах «отладчик с мониторингом энергопотребления для устройств Интернета вещей, … сочетающий в себе свойства Segger J-Link Pro, Blackmagic Debug Probe и Unwired Devices Energymon». Скорее всего, даже заопенсорсим устройство (прошивку уж точно) — хотя есть у меня обоснованные сомнения касательно всякого Open-source hardware.

Ну и в качестве развлечения — быстрый китайский чоппер (на этот раз мотоцикл):

Из твиттера про инженерию

Увидел тут в твитере пост, где некая сеньорита фронтенда считала «новым и интересным» чтение ебаной документации к очередному блядскому стейт-менеджеру. Охуел и подумал — господи, какой же пиздец, когда люди считают это «новым и интересным»! Что сука характерно: как только некий класс софта получает общее название (да хоть «стейт-менеджер» этот), выбор между разными представителями этого класса определяется в первую очередь не «функциональными» соображениями, а абсолютно субьективными вещами вроде «моды» — и это еще сравнивают с инженерией! После такого отказываюсь причислять программистов к инженерам, потому что инженерии в сборке очередного программного поделия не больше, чем в поклейке танчиков из набора фирмы «Звезда».

Никогда не читайте истории успеха

Особенно — в исполнении русских бизнесменов. И нет, я сегодня не о вылезших из анекдотов про «новых русских» красномордых жлобах с турецкой золотой цепочкой, которые дают ценные советы по ведению бизнеса прямиком из тех лет, когда они начинали, а ты слушаешь и думаешь — ну господи, что ты несешь, от этих твоих «советов» работники в ужасе разбегутся, а потом еще и придет налоговая и даст пиздюлей. Впрочем, аргументированно возражать тоже не получится — потому что главный аргумент расказчика выражается фразой «если ты такой умный, где твои деньги?» Нет, можно быть вполне себе милым московским мальчиком с написанным на лице ВМК МГУ, и носить не малиновый пиджак, а интеллигентский свитерочек — но давать советы такого же космического масштаба и космической же глупости. Вот, например, Максим Лапшин, руководитель Flussonic, распедаливает нам, чем баг отличается от фиче-реквеста:

https://levgem.livejournal.com/508738.html

И разумеется, Максим считает себя очень умным, а описанную по ссылке жесть — несомненно правильной, и доказывается это тем, что у Flussonic’а клиенты есть и даже готовы платить за такое жлобское отношение — но что же мы узнаем из приведенного текста?

А узнаем мы очень простую вещь — «продукт» Flussonic полностью соответствует фразочке «A design without specifications cannot be right or wrong, it can only be surprising!» — а все потому, что в фирме у Лапшина писать хоть какую-то документацию для разрабатываемого софта не принято, чай, клиент не барин, сам поймет, баг это или фича. И действительно, в отсутствии спецификаций они различаются только субьективным отношением, «эмоциональной оценкой клиента». Добавляем к этому еще парочку «антипаттернов» уровня «документация делается техписом», «сотрудник поддержки, который заведомо ниже квалификации чем разработчик или продакт» (кстати, видите тут совершенно неприкрытый снобизм по отношению ко всем «непрограммистам» с «заведомо низкой квалификацией»?) — ну и видим, собственно, что ни при каких обстоятельствах принимать во внимание мнение Лапшина о том, «как должно быть», попросту нельзя.

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

PS Найдите максимум «антипаттернов» в вот этом слащаво-рекламном тексте: https://web.archive.org/web/20170207041400/vc.ru/p/flussonic-tv

Ростех не мой, я только разместил объяву!

Репостнул в околопрограммистском чатике умеренно ватнической среднелюдоедской направленности вопрос (не мой), нет ли среди присутствующих кого-то, имеющего опыт конфигурации Ardupilot или чего-то аналогичного для ростеховского проекта. Один из программистов чатика мгновенно порвался и два дня фонтанировал бессвязными фразами про FPV-дроны, глушилки GPS, распилы, Мавики, СВО, Ланцеты, «они пилят, а там люди гибнут» и прочее в том же духе, перемежая это оскорблениями в адрес незнакомых ему людей.

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

Кто-то в лесу сдох

Издательство ДМК внезапно выпустило две более-менее вменяемых книги про встраиваемые системы. Во-первых, сначала я наткнулся на «Реверс-инжиниринг встраиваемых систем» Алексея Усанова. Не сказал бы, что раскрыты какие-то глубины этого процесса — но если рассматривать книгу, как каталог ссылок на всякие полезные материалы — то сойдет. В целом — нормальное дополнение к какому-нибудь учебному курсу по программированию встраиваемых систем — «как на ваше устройство смотрит недоброжелатель :)».

Во-вторых, поизучав другие издания на сайте, нашел перевод учебника Даниэле Лакамеры «Архитектура встраиваемых систем» — в отличие от массы литературы «по STM32», сводящейся к пересказу даташита вперемешку с многочисленными скриншотами из Cube MX, здесь описывают среду разработки с использованием gcc и make, работу с памятью «на низком уровне», немного затрагивают внешние сетевые интерфейсы и многозадачность — в общем, подходящий набор для того, чтобы не пугаться любого более-менее современного микроконтроллерного проекта, отличающегося от «а мы тут быстренько что-то под ардуину налабали».

На фоне того, что издают по программированию для разного мелкого embedded на русском языке (всякие там «77 бесполезных проектов на ардуине») — внезапно уровень очень неплох. Прямо даже задаешься вопросом — что же случилось (и кажется, логотип YADRO на обложке второй книги намекает, кому это может быть нужно).

Чем программист отличается от андроид-разработчика

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

https://mbr.livejournal.com/655769.html

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

Понятно, что эти задачи надо как-то делегировать — но в голове у такого персонажа всегда есть мысль — «да делать там нечего, я бы сам за недельку-другую осилил, вот только некогда и руки не доходят». Если вдруг это ощущение «давненько я не брал в руки шашек» удачно совпадает с двухнедельным перерывом в текучке — то может сесть и сделать, может быть, слегка старомодно (давно вы видели десктопную разработку на Delphi? А некоторые до сих пор могут!) — но работать будет. Если же такого перерыва не предвидится — то делегировать придется под ворчание о том, что делать там нечего, да и вообще, зажрались эти программисты, два месяца собираются над такой ерундой работать!

В запущенном случае, это, конечно, принимает некоторую форму снобизма, особенно, если времени освежать знания не было, в духе «а нахера тут Cortex-M, ща я на PIC’овском ассемблере сбацаю, учись, студент, пока я жив!» — но в целом такой типаж повторяется с поразительной регулярностью, вот и топикстартер в той теме про андроид-приложение к нему относится.

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

https://itvdn.com/ru/blog/article/250-about-android

Знания собственно платформы — минимальные, зато уделяется масса внимания «работе с сетью» — точнее, работе с операциями семейства CRUD через какой-нибудь REST API. В сочетании с неумением читать документацию — прекрасный кадр для решения простых повторяющихся задач, вроде «приложения со списком рецептов» из того же опросника. Что-то за пределами привычного круга задач моментально выбивает из колеи — примерно как описано по первой ссылке. С другой стороны, одинаковые «приложения» по рецепту «архитектура MVVP, работаем с REST API через Retrofit, получаем JSON, конвертируем в понятный вид с помощью Moshi» тоже кем-то востребованы, клиенты есть.

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

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

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

— так что сливаются под более-менее благовидным предлогом, мол, очень сложно.

Про принципы

Решил узнать, стою ли я чего-то, как «программист под Android», скорее всего, срежусь на первом же вопросе, про «основные принципы ООП»:

https://itvdn.com/ru/blog/article/250-about-android

С другой стороны, при чем тут Организация Освобождения Палестины?

А в этот раз — не про студентов

Скажу только, что такой говнокод пишет не Хундай, там ISO 26262 пока еще чтут :)

uint32_t cur_timestamp, last_timestamp;

cur_timestamp = GET_SECONDS() & UINT16_MASK;
last_timestamp = storage->timestamp;

if (last_timestamp + TIME_DELTA > cur_timestamp) {
    return;
} else {
    // do something
    storage->timestamp = (uint16_t) cur_timestamp;
}

Студентов я за такое бил по рукам спрашивал — а что будет с вашей программой через 71 минуту (когда так мучили 32-битный микросекундный таймер) или через 49 дней (таймер миллисекундный на этот раз, но те же 32 бита)? 16-битный счетчик секунд, кажется, это кококомбо, тут все встанет раком через 18 часов, это уже достаточно много, чтобы не заметить проблему при тестировании, но при этом достаточно мало, чтобы она ебала мозг в эксплуатации.

Про экономическую эффективность

Два дня протирал штаны в экзаменационной комиссии в Московском Институте Элегантных Мужчин (ныне являющемся частью Высшей Школы Этого-самого), защищались магистерские работы по специальности «Инфокоммуникационные технологии и системы связи». Уровень — в принципе, такой же, как и в прошлом году — из полутора десятков работ на «отлично» без вопросов тянули хорошо если четыре. Остальное было в диапазоне от весьма унылых «инженерных» работ («четверка с плюсом» в прыжке), причем местами студент даже с трудом понимал, что и зачем он делал, до уровня «в качестве диплома пытаются защитить акт покупки китайских датчиков с алиэкспресса» (почти точная цитата, только вот тут даже «облака» не было). За последнее в этот раз ставили «тройку с минусом», хотя, в принципе, будь у вуза яйца покрепче — надо было бы выгонять с неудом.

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

Конечно, мои взгляды на рынок труда попахивают трудовой теорией стоимости, почерпнутой из пересказов Карла Маркса и Адама Смита — но среди выпускников за эти два дня я не увидел практически никого, кто мог бы «производить продукт», стоящий этак тысяч 300-400 в месяц (не забываем про все, что кырла-мырла относил к «прибавочной стоимости»). Более того, поразмыслив над одной из работ, я понял, что эта ваша айтишечка глубоко убыточна, но что самое страшное — никто из участников в принципе не осознает глубины этой дыры.

Собственно, работа родилась из простой гипотезы — в дождь количество заказов в службе экспресс-доставки возрастает, а количество доступных курьеров падает — поэтому надо как-то автоматически распознавать, когда в районе конкретного центра формирования заказа идет дождь, и принимать какие-то решения на основании этого (скажем, увеличивать минимальный чек для заказа, чтобы не «гонять раба» с одной бутылкой колы). Разумеется, для проверки этого предположения — а оно само по себе довольно сомнительно — никак нельзя воспользоваться, скажем, данными сторонних сервисов, типа того же Яндекса — поэтому была разработана и даже представлена в качестве дипломной работы очередная универсальная система перемещения данных слева направо:

Разумеется, сразу был предусмотрен жуткий хайлоад — ведь 3000 центров формирования заказов, в каждом из которых стоит метеостанция, раз в секунду отправляющая данные о погоде, это не ишак чихнул, тут все эти названия и аббревиатуры однозначно нужны! Кстати, если чуть-чуть подумать мозгом — то этот «раз в секунду» совершенно не нужен, достаточно, к примеру, раз в 10 минут — и тогда весь ваш хайлоад усыхает до 5 RPS. Это, кстати, было первое предложение от комиссии :)

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

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

Драма в десяти коммитах

Кажется, сегодня был свидетелем драмы, выраженной в гитовских commit message.

В общем, сдавала мне студентка некое задание, этакий hello world для встраиваемых систем, только он у нее не запускается и не компилируется. Я помню, что вносил в основной репозиторий проекта, с которым они работают, некие правки, и без задней мысли решил посмотреть git log — не забыла ли девочка их подтащить?

В логе — прекрасная картина, последние пара коммитов девочкины, относительно свежие, дальше идут подписанные мужским именем и прямо видно, как у человека нарастала экспрессия — вплоть до «fucking shit fixed!!11». Поинтересовался, конечно, что это за чувак, выяснилось, что студенткин молодой человек. И в общем меня волнует одно — а почему он в марте что-то делал, а в апреле и мае девочка пользовалась Stackoverflow и ChatGPT? Неужели они расстались из-за ебучей Riot OS?

ChatGPT и программирование

Увидел сегодня очень показательный пример того, как ChatGPT «пишет» программы. В общем, очередной раз читаю курс по программированию всяких встраиваемых устройств, и ближе к концу семестра, осознав весь зашитый в формулу для оценок фашизм, нарисовалась студентка с желанием сдать все и сразу, включая задания, по которым дедлайн уже прошел. Решил посмотреть код — и заподозрил неладное. Но сначала — давайте я покажу его вам в слегка сокращенном виде, найдете ли вы здесь какие-то ошибки?

#include <stdio.h>
#include "periph/i2c.h"
#include "periph/gpio.h"
#include "periph_conf.h"
#include "bme280.h"

int main(void)
{
    /* Инициализация датчика BME280 */
    bme280_t bme280_dev;
    int bme280_res = bme280_init(&bme280_dev, I2C_DEV(0), BME280_I2C_ADDRESS);
    if (bme280_res != 0) {
        printf("Ошибка инициализации BME280: %d\n", bme280_res);
        return 1;
    }

    /* Получение и вывод показаний датчиков */
    while (1) {
        /* Получение показаний BME280 */
        bme280_measure(&bme280_dev);
        float bme280_temperature = bme280_temp_comp_2(&bme280_dev, bme280_dev.temperature);
        float bme280_humidity = bme280_humid_comp(&bme280_dev, bme280_dev.humidity);
        float bme280_pressure = bme280_pres_comp(&bme280_dev, bme280_dev.pressure);

        printf("BME280: температура=%.1f°C, влажность=%.1f%%, давление=%.1f мбар\n",
            (double)bme280_temperature, (double)bme280_humidity, (double)bme280_pressure);
        }
        xtimer_sleep(5);
    }

    return 0;
}

Меня сразу смутил используемый для работы с датчиком (банальный BME280) API — он очень отдаленно напоминал реализованный в Riot OS, не говоря уж о библиотеке для Arduino или ARM mbed, или о «фирменном» бошевском драйвере. Но еще больше удивил соседний файл (с кодом, который якобы написан той же самой студенткой!), где работа с датчиком выглядела примерно так (опять же, в максимально сокращенном виде):

#include "xtimer.h"
#include "bme280.h"

#define BME280_DEV  I2C_DEV(0)

static bme280_t dev_bme280;

int main(void)
{
    int8_t res;
    res = bme280_init(&dev_bme280, BME280_DEV);
    if (res != BME280_OK) {
        puts("Could not initialize BME280 sensor");
        return 1;
    }

    while (1) {
        float temperature_bme280;
        bme280_read_temperature(&dev_bme280, &temperature_bme280);
        printf("BME280 temperature: %0.1f C\n", temperature_bme280);
        xtimer_sleep(5);
    }

    return 0;
}

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

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

Решил проверить догадку самостоятельно и задал ChatGPT вот такую задачу: Write a C language program for RIOT OS that uses a BME280 sensor connected by I2C bus, reads temperature, pressure and humidity values from the sensor and outputs them into UART each 10 seconds. Also, if the temperature is higher than 100 degrees Fahrenheit, a LED connected to one of GPIO pins must be switched on. When the temperature lowers, the LED is switched off.

Я думаю, вы уже догадались, что было ответом — правильно, третий вариант API! (но с градусами Фаренгейта я хорошую подставу придумал):

#include "bme280.h"
#include "periph/gpio.h"
#include "periph/i2c.h"
#include "periph/uart.h"
#include "xtimer.h"

#define I2C_DEV     (I2C_DEV(0))
#define BME280_ADDR (0x76)

#define LED_PIN     (GPIO_PIN(PORT_A, 5))
#define LED_ON      (0)
#define LED_OFF     (1)

static bme280_t dev;
static gpio_t led;

static void init(void)
{
    i2c_init(I2C_DEV);
    bme280_init(&dev, I2C_DEV, BME280_ADDR);
    uart_init(UART_DEV(0), 115200, UART_FLAG_NONE);
    gpio_init(LED_PIN, GPIO_OUT);
}

int main(void)
{
    init();

    while (1) {
        bme280_read_fixed(&dev);

        printf("Temperature: %ld.%02lu C\n", dev.temperature / 100, dev.temperature % 100);
        printf("Pressure: %lu.%02lu hPa\n", dev.pressure / 100, dev.pressure % 100);
        printf("Humidity: %lu.%02lu %%\n", dev.humidity / 1024, (dev.humidity * 100) / 1024 % 100);

        if (dev.temperature > 100 * 100) {
            gpio_write(led, LED_ON);
        } else {
            gpio_write(led, LED_OFF);
        }

        xtimer_sleep(10);
    }

    return 0;
}

Но вот что интересно — так это время, которое пройдет между написанием кода и обнаружением наебалова. Принято считать, что одна из сложностей в эмбеддеде всех мастей — это долгий цикл обратной связи между написанием кода и получением результата — работает/не работает/надо переделать. Так вот, для наебалова в таком вот духе он сокращается до одной команды в консоли — наберите make flash и тут же, не отходя от кассы, получите тугую струю ссанины в ебало в виде совершенно невнятных ошибок компилятора. А вот если у вас модный язык вроде Javascript или Python — то с вот таким синтаксически корректный бредом можно долго и плодотворно заниматься debugging into existence. Программист программировает, получька капает.

Будующее такое яркое.

Сертификация скрам-мастера, уровень бог

Придумалось тут несколько вопросов, кто ответит на все правильно — может считать себя гуру agile!

1. В ходе очередного сеанса груминга (взаимного почесывания, как принято у приматов) скрам-мастер обнаружил, что является impediment to a team’s progress. Должен ли он, как честный человек, застрелиться, или можно ограничиться заявлением об увольнении?

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

3. То же самое, но теперь от скрам-мастера беременны три тестировщицы. Надо ли жениться сразу на трех, как велит Аллах?

4. То же самое, но беременны тимлидесса, аналитесса и тестировщица. Скрам-мастер уже женат на четырех тестировщицах из заданий 2 и 3, брать больше четырех жен Аллах не велит.

5. За какое время Scrum Team из 9 женщин родит ребенка?

6. Скрам-мастер перетрахал всю команду. Может ли он после этого выполнять роль Product owner’а?

7. Почему на должность скрам-мастеров и коучей по agile охотнее берут женщин?

Про «государственный гитхаб»

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

https://www.forbes.ru/tekhnologii/486349-zamglavy-mincifry-maksim-parsin-ne-hotim-izolacii-no-nam-nuzen-svoj-repozitorij

Что здесь самое интересное и даже революционное? Выкладывать свой код в опенсорс на условиях «открытой государственной лицензии» приглашают всех, и в первую очередь «иные ФОИВы, государственные внебюджетные фонды, органы власти субъектов федерации, госкорпорации». Это, конечно, прекрасно — но нужен еще один, или даже полтора шага. Во-первых, хорошо бы приравнять публикацию кода в «государственном» репозитории к регистрации РИД в смысле статьи 1262 ГК РФ, а во-вторых — надо еще мозги переформатировать тем, кто за регистрацию РИД в организациях отвечает.

Вот у меня такой, скажем, примерчик есть (правда, мне все лень доделать до «отчуждаемого» состояния, то есть ридми с примерами использования написать) — сделал я со своей студенткой в прошлом году кусок сетевого стека 6LoWPAN over BLE на Андроид, в вузе (МИЭМ НИУ ВШЭ) начали капать на мозги по поводу того, что раз в результате дипломной работы создан РИД, результат интеллектуальной деятельности, надо бы его зарегистрировать. Что мне и всем остальным дает эта регистрация? Маленький FAQ написали вот тут:

https://wiki.miem.hse.ru/ru/Projects/rid

Это все означает, что за 10 000 рублей (ну такое, сходить авторским коллективом в ближайший к МИЭМу кабак «Строгинская гавань» и за вечер пропить) программу предлагается похоронить в вот этой братской могиле:

https://www.hse.ru/info/patent

Я ооочень сомневаюсь в каких-либо перспективах коммерческого использования любой из перечисленных там «программ для ЭВМ» — и вот спрашивается, нахера мне это? Нет, иные преподы может и живут этим, регистрируя студенческие курсачи, но…

Я вот даже согласен на то, что денег мне не заплатят, и даже на то, что на российском гитхабе оно будет под брендом того же МИЭМ лежать, лишь бы общедоступно (ну и лицензии типовые, вроде CeCILL французской). Во всяком случае, в опенсорсе перспектив у проекта будет больше, чем в списке результатов интеллектуальной деятельности на сайте ВШЭ.

UPD Прочитал тут постановление Правительства РФ № 1804 от 10.10.2022 и приложение к нему — «Открытую государственную лицензию» — на удивление приличная permissive licence, не особо хуже какой-нибудь MIT’овской.

The Leprechauns of Software Engineering

Вообще, троллинг программистов — это легко и приятно. Вот вчерашний, например, был снова пойман на очередной глупости — сначала начал рассуждать, что goto пользоваться никак нельзя, а потом, после прямо заданного вопроса «а break, continue, try-catch ты используешь?» начал громко орать, что это совсем другое и никак нельзя эти конструкции сравнивать. Самое смешное — вроде бы в подтверждение своих слов он притащил известную статью Дейкстры, про «Go To Statement Considered Harmful«, и на этом стало понятно, что он ее не читал, от слова совсем.

Если совсем коротко ее пересказать — то дело в том, что процесс выполнения «структурной» программы (где используются только условные операторы и циклы) описывается крайне просто — фактически лишь номером строки исходного кода, инвариантами циклов и условиями выхода из тех же циклов. Это очень сильно упрощает формальные методы анализа, за которые топил Дейкстра, и которые при желании можно показать семиклассникам (собственно, «через Дейкстру» они в школьную программу и попали). Применение же goto делает такой простой анализ практически невозможным, описать состояние программы, написанной с использованием goto, получится лишь перебором всех возможных путей выполнения. Если подумать — то всевозможные break, continue, обработка исключений, наконец, точно так же усложняют рассуждения о выполнении программы. Попробуйте написать инвариант несложного цикла, в котором может быть выкинуто исключение! А если это исключение еще и обрабатывается «на уровень выше»?

Но люди думать не хотят, люди хотят пользоваться своими заблуждениями, при необходимости подкрепляя их ссылками на «научную» литературу, которой даже толком не читали. Примерно о том же — и книга Leprechauns of Software Engineering, посвященная разбору популярных — настолько популярных, что их массово тиражируют даже в учебных курсах — утверждений о процессе разработки ПО, которые по факту оказываются либо слабо обоснованными, либо вообще «о противоположном». Сколько раз вы слышали, скажем, о «методологии водопада»? А ведь это такое удобное чучелко для битья, когда рассказывают про всякий Agile! Но если полезть копаться в литературе — то окажется, что «водопад» — в том виде, в каком он был описан впервые, в статье 1970 года — это совсем не то, что вы себе представляете.

Автор докапывается до происхождения мифов о «10x-программисте», о «конусе неопределенности», о «стоимости изменений» на этапах разработки и тестирования — и всякий раз оказывается, что фундамент у этих известных вещей крайне шаткий, местами в первоисточниках написано вообще что-то в духе «а эту картинку мы нарисовали, потому что нам так кажется». Дальше красивая, но не обязательно верная, концепция обрастает несколькими цитированиями — и вперед, она уже тиражируется на правах общеизвестной истины.

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

Унижаем программистов

Объяснял программисту в одном чатике разницу между тестированием и формальной верификацией кода, для пущего издевательства притащил книжку для семиклассников — «Программирование: вводный курс» за авторством Д. Школьника, Н. Авданина и А. Суханова, и более того — издевался, приводя в качестве примера третью (!) программу в этой книжке — 1.3 на вот этом развороте:

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

Знакомые всем лица!

Кажется, вопрос, что происходит с ОС Riot, можно считать решенным:

https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap

Список авторов проекта RFC выглядит ужасно знакомым — с той лишь разницей, что товарищ Cenk Gündoğan ушел в Huawei.

Про embedded этот ваш

Случайно зашел на Synopsys OpenHub — а точнее, на страничку, посвященную операционной системе Riot, и увидел там вот такую картинку, график contributors per month, или сколько человек отправляют коммиты в этот проект:

Ого, подумал я — проект, похоже, загибается, и надо бы вовремя спрыгнуть с мертвой лошади! А какие у нас есть альтернативы? ARM mbed? После довольно впечатляющих успехов в 2018-2020 году проект по количеству участников скатился до уровня чего-то маргинального, с десятком активных участников во всем 2022 году!

Zephyr OS, при всей его накачке со стороны Linux Foundation, выглядит чуть бодрее — но и то с 2022 «контрибьюторы» начали разбегаться (да и в общем если вычеркнуть историю до 2014, то от того же Riot график станет неотличим):

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

Короче, вопрос — что случилось с «микроконтроллерными» операционными системами, почему опенсорсному embedded примерно в 2020 прикрыли краник с финансированием, и в какую сторону бежать?

О кросс-платформенности

HomeAssistant, написанный на Python сервер «умного дома» — официально предлагается либо в виде образа виртуальной машины, либо в виде контейнера для docker, отличные от x86/x64 архитектуры сводятся к Raspberry Pi (с Raspbian, другие дистрибутивы не поддерживаются). Установка на «голый Linux» крайне не рекомендуется и официально приравнена к извращениям (заодно приводится какой-то ебнутый список зависимостей).

Fossil SCM, система контроля версий + вики + … (и SQLite вместе с ними), написана на C, представляет собой один-единственный исполняемый файл, компилируется под любую архитектуру — хоть Windows на x64, хоть Linux на ARM (даже кросс-компиляция для Synology DSM прокатывает), поддерживает несколько вариантов запуска в качестве веб-сервера, от standalone до разных вариантов CGI, в последнем варианте работает на любом shared-хостинге.

Не кажется ли вам, что что-то здесь неправильно?

Про программистов опять

Поучаствовал в очередном мини-срачике о том, что о нас знают всякие гуглы и яндексы. Собеседник-программист отстаивал мнение, что ничего особенного они там не сохраняют, обосновывая все это богатым жизненным опытом — таким примерно:

Все данные нигде и никогда не хранятся. Чем больше ты хранишь тем меньше период. У нас на хайлоаде в прошлом месте где я работал логи забивали 2 Тб за неделю. И ротация логов была такой что дальше уже затирались старые.

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

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

Прокручивание рекламы — задача крайне интересная, без шуток. Достаточно посмотреть, например, свежие научные статьи на тему Thompson sampling, rank-1 bandits и тому подобных штук, или хотя бы на список публикаций и мест работы вот таких интересных чуваков:

https://bkveton.com/

Если уж совсем времени нет — то прочитайте хотя бы введение и раздел MovieLens Experiment вот этой статьи:

https://proceedings.mlr.press/v54/katariya17a/katariya17a.pdf

— а потом попробуйте ответить себе на вопрос, сколько может «стоить» перенос точки перегиба вот такого графика с отметки 500к хотя бы на 50к, на порядок левее:

В общем, если совсем коротко — то успех любого из интернет-гигантов зависит от того, насколько успешно он показывает рекламу в зависимость от предпочтений пользователя. А для того, чтобы эти самые предпочтения пользователя определить — может служить буквально вся его история. Хранить ее не так дорого — вот возьмем хотя бы пример выше и посмотрим, сколько стоит двухтерабайтный жесткий диск в московской рознице — недорого, можно найти меньше, чем за 5 тысяч рублей. Щедро накинем вдвое и предположим, что хранение 2 Тб логов за неделю от 40 тысяч пользователей обойдется той конторе всего в 10 тысяч рублей. Сумма смешная, и это говорит нам об одном — весь этот «хайлоад» не приносит и одного лишнего рубля в месяц с пользователя. Гуглы же, фейсбуки и яндексы, я уверен, вполне себе способны просто за счет лучшего анализа поведения пользователей этот рубль совершенно честно заработать — хотя бы за счет более «подходящей» рекламы, на которую пользователь нет-нет, а все же нажмет.

PS Проанализируйте с этой точки зрения следующее высказывание того же программиста:

Я вот в компании предложил кликхаус поднять чтобы аналитика быстрее в 5 раз считаться начала. Ну мне тонко намекнули, то что я разобрался сам это хорошо, но вот больше никто разбираться не будет. И так серверов субд уже три типа и четвертый нахер не нужен. Это притом что кост тут был только людям разобраться.

Почему «аналитика быстрее в 5 раз» никому не нужна?

А подскажите всякой жести

Узнал, что уже скоро мне придется прочитать первокурсникам магистратуры аж 20 (!) лекций про «Аппаратные платформы интернета вещей и киберфизических систем» (а потом нарезать это на 40 экзаменационных билетов, в каждом из которых по два вопроса, плюс придумать несколько вопросов «с подъебкой») — в общем, задача довольно нетривиальная (если учесть, что курс по программированию микроконтроллеров «с нуля» состоит из 8-10 лекций). Просто так лить воду не хочется, поэтому надо добавить в курс невероятной жести. Пока обдумываю следующие сюжеты:

— ЦОС в диапазоне «а вот у нас красивый Матлаб и мы получим коэффициенты для фильтра Чебышева 6 порядка» до «а это убогий Cortex-M3 и мы на нем будем делать этот фильтр в целочисленной арифметике!»;
— сети Петри/communicating sequential processes/что-то еще в этом духе, зайдет к разговору про безопасность, которая safety, и всякие там IEC 61508;
— фильтр Калмана и многочастичный фильтр — «как правильно использовать 6D-акселерометр»;
— Distributed Coordination Function в IEEE 802.11 и 802.15.4 — в первом случае это уже классика, во втором — есть мелкие подлые изменения, но очень показательные в плане отличия IoT от банальщины вроде этих ваших вайфаев;

Чего бы еще найти в категории «экзотика, но полезно»?

PS По заслуживающим доверия сведениям, магистры пришли в ужас при виде выписанной на доске формулы, описывающей ПИД-регулятор.

PS/2 Да, тут есть, от чего охуеть!