Шура Люберецкий

На сайте одной иностранной софтверной фирмы системы “галера” над кнопочкой “Apply for a job” написано: “LIFE’S TOO SHORT TO WORK IN A BORING COMPANY!”.

Не говорите, что вас не предупредили.

В одном девайсе на микроконтроллере с ядром Cortex-M4 (без F) понадобилось сделать цифровой фильтр для сигнала с АЦП. Фигня вопрос! – подумал я – ведь под рукой есть библиотека CMSIS-DSP, в которой присутствует все необходимое для БИХ-фильтров, работающих с числами с фиксированной запятой. Быстренько закинул параметры фильтра в Iowa Hills IIR Filter Designer, пересчитал коэффициенты получившегося фильтра Баттерворта в q31, погонял это вот все на тестовых сигналах – а вот с реальными вышел неприятный конфуз – даже “почти стабильный” сигнал на выходе фильтра непристойно колбасило.

Вверху исходный, нефильтрованный сигнал, внизу – ужас, получавшийся на выходе фильтра.

Признаюсь сразу – я лошара, и первым же делом стоило проверить, что действительно приходит с АЦП – но по опыту использования фильтров из CMSIS-DSP мне казалось, что такой фигни быть не должно. Начал искать проблемы в “железе”, и мог бы зайти по этому пути далеко, пока случайно не отключил один из фильтров (ФВЧ с частотой среза 1 Гц при частоте дискретизации около килогерца). И что бы вы думали? Сигнал волшебным образом пришел в норму!

Оказывается, что фильтры с переменными формата q31 при таких соотношениях между частотой среза и частотой дискретизации численно неустойчивы, и надо использовать q63 – в документации CMSIS-DSP это отражено примерно такими словами:

These filters are particularly useful when implementing filters in which the singularities are close to the unit circle. This is common for low pass or high pass filters with very low cutoff frequencies.

Но что значит “close”, что значит “very low”? Как понять, когда 16- или 32-битных коэффициентов не хватает? К сожалению, я как-то не припомню литературы по всяким там численным методам, где подробно разбирались бы вот такие вопросы, связанные с вычислительной устойчивостью. Может, кто-нибудь что-то подскажет?

Для того, чтобы смотреть записанные в Influx данные, я, особо не заморачиваясь, взял Grafana. Потыкался в настройки – и обнаружил среди интересных фишек Influx HTTP API, позволяющее делать запросы к базе данных прямо из браузера – точнее, из выполняющегося в браузере Javascript. Удобно? Не то слово!

А если подумать немного дальше – то при таком подходе не нужна и Grafana. Достаточно статики в виде нескольких HTML-страниц, чуточку CSS и Javascript, чтобы делать те же самые запросы к HTTP API и отображать графики. Развивая мысль чуть дальше – в нежно мной любимом CC3200 есть встроенный веб-сервер. В общем, понятно, к чему я клоню? В одном из девайсов возникла необходимость показывать на подключенном по WiFi ПК данные от датчиков устройства – разумеется, в виде графиков. Нарисовалось вот такое ТЗ “чисто для фронтенда”:

Разработать одностраничное приложение, которое раз в секунду “стучится” на определенный URL, забирает оттуда данные (несколько числовых рядов) в виде JSON, и отображает их в виде графиков (например, на canvas из HTML5). Для определенности – предположим, что каждую секунду отдается 8 “рядов” по 250 точек каждый, а на графиках надо отображать данные за последние 5 секунд.

Разумеется, есть и ограничения – их два: во-первых, нельзя обращаться к каким-либо внешним ресурсам, а во-вторых – страничка вместе со всеми ресурсами (изображения, CSS, скрипты) должна “весить” не более 512 кБ.

Ну и вопрос: в какой объем можно уместить что-то такое, применяя современные подходы к фронтенду?

А вот в магистратуре университета Бремена предлагается курс Language and Gender с таким вот описанием:

In this course, gender is singled out as one of the most important (and problematic) categories used to distinguish between groups of people and abused as a basis for discrimination.

Содержание, видимо, описывается тремя словами – а мужики-то не знали!

Говорят, что в исходниках Linux слово “fuck” заменили на “hug”.

Ну в общем вы поняли.

Зашел на сайт “Отраслевого союза Нейронет“. Охуел от увиденного настолько, что минут 20 мог говорить только матом.

У нас был ARM Cortex M4F с частотой 120 МГц, 256 килобайт SRAM, мегабайт флеша, 6 килобайт EEPROM, а еще восемь UART, четыре QSSI, десять I2C, USB 2.0, встроенный Ethernet и два контролера CAN. Не то, чтобы все это было нужно в готовом устройстве, но раз начал коллекционировать Launchpad’ы, то иди в своем увлечении до конца. Единственное, что меня беспокоило – это Ethernet. В мире нет ничего более беспомощного, безответственного и безнравственного, чем Ethernet на микроконтролере. И я знал, что довольно скоро мы в это окунёмся.

А если серьезно – чем отличаются TM4C1294NCPDT и MSP432E401Y?

Увидел тут ролик, где студенты ВШЭ протестуют против решения Ученого совета ВУЗа о “блокирующих оценках” (можно почитать , если кому интересно):

Что хочу сказать? Это действительно не МГУ – так как МГУшное “Положение о курсовых экзаменах и зачетах” всякой мелочной ерунды, в отличие от вышкинского “Положения об организации промежуточной аттестации…“, не содержит.

Очень хорошо выглядят комиксы про Дилберта, перемежаемые контекстной рекламой Texas Instruments.

https://ria.ru/incidents/20181128/1533721369.html

Чуваки, а вам не кажется, что “компьютерные серверы”, торчащие голой жопой в интернет, в 2018 году делать как-то не очень модно?

UPD Подоспело продолжение:

https://www.mskagency.ru/materials/2840255

Интересно, они поймали вирус-шифровальщик (приползает на машины с Windows и открытым RDP на следующие сутки) или обычный спам серии “I have your password”?

Технический университет Дармштадта, середина семестра. На лекции по “системам обработки естественного языка” (краткий пересказ документации к библиотеке NLTK) рассматривается вот такой пример:

В аудитории присутствует где-то десять будущих компьютерных филологов и полторы сотни будущих компьютерных программистов. С филологами ладно, в конце концов, вся эволюция вычислительной техники была направлена на то, чтобы даже филолог мог решать свои профессиональные задачи (”Есть ли в русском языке слово, содержащее три е подряд?”) с помощью компьютера – а вот программиста, который бы предложил вот так искать слова, соответствующие последовательности нажатий кнопок на клавиатуре мобильного телефона, 20 лет назад просто избили бы ногами в подворотне. Десять лет назад все обошлось бы косым взглядом с легким налетом “пассивной агрессии”. Сейчас такое можно показывать студентам и никто, кажется, не считает этот подход зазорным.

Почитал тут всякого про хранение временных рядов (time series), послушал подкаст про Akumuli и пощупал ручками Influx DB. Что хочу сказать?

Почти во всех проектах такого рода первый же рассматриваемый “юзкейс” – это мониторинг серверов (с неизменным киданием говна в сторону RRDtool). В рамках того же подхода довольно неплохо чувствуют себя всякие “классические” SCADA-системы и модный IoT (провести границу между ними уже проблематично). А вот когда начинается что-то нестандартное (с точки зрения разработчиков) – то тут “тушите свет”.

Я вот, например, ругался на то, что datetime в SQL неспособен хранить данные с “разрешением” меньше секунды. Любая нормальная TSDB, конечно, поддерживает запись временных меток с хорошей дискретностью – милли-, микро- и даже наносекунды. Но вот возьмем line protocol из Influx DB и попробуем записать несколько подряд идущих значений:

steering,tag1=some,tag2=shit value=1.51 1542646126000000000
steering,tag1=some,tag2=shit value=1.46 1542646126010000000
steering,tag1=some,tag2=shit value=1.40 1542646126020000000
steering,tag1=some,tag2=shit value=1.34 1542646126030000000
steering,tag1=some,tag2=shit value=1.31 1542646126040000000
steering,tag1=some,tag2=shit value=1.28 1542646126050000000
steering,tag1=some,tag2=shit value=1.26 1542646126060000000
steering,tag1=some,tag2=shit value=1.23 1542646126070000000
steering,tag1=some,tag2=shit value=1.20 1542646126080000000
steering,tag1=some,tag2=shit value=1.17 1542646126090000000
steering,tag1=some,tag2=shit value=1.14 1542646126100000000
...ну и так далее

Я взял “живые” данные из автомобильной (точнее, “автосимуляторной”) телеметрии (датчик угла поворота руля) с частотой дискретизации в 100 Гц. Полный набор тегов я писать, конечно же, не хочу – скажу только, что их может быть довольно много. Для записи же каждого значения тут требуется передать аж 60 байт (HTTP API позволяет сэкономить несколько байт из временной метки, но в целом получается примерно столько же). Пусть контролируемых параметров – десяток (это, кстати, довольно мало), а частота оцифровки – все те же 100 Гц – и мы непринужденно получаем требуемую скорость обмена данными аж в 480 кБит/с.

Вроде бы немного в наше время гигабитных каналов и всего такого, и жить с этим в принципе можно – но давайте прикинем, сколько data points влезет в канал со скоростью 1 Гбит/с (Gigabit Ethernet на коленке я еще могу представить). Получится что-то около 2 миллионов в секунду – и это уже попадает в категорию Probably unfeasible (на русский это переводится довольно прикольно – “Возможно, невозможно”) в руководстве по выбору “железа”. Может быть, именно поэтому – как бы вы не пыжились, а пропихнуть в Influx столько данных все равно проблематично – об этом и не задумываются?

Немного больше о совершенно неуместной избыточности и многословности такого рода текстовых форматов подумал автор Akumuli – там хотя бы можно писать наблюдения, относящиеся к одному и тому же моменту, не повторяя всякий раз метку времени и теги. Но блин, я в своей попытке сделать TSDB после трех бутылок пива первым же делом реализовал “наколеночный” бинарный протокол (на основе CoAP – официально это расшифровывается Constrained Applications Protocol, но мне кажется, что Co обозначает Contiki в смысле “из говна и палок”), который позволял писать те самые 2-3 миллиона data points в секунду поверх обычного стомегабитного Ethernet.

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

Вот возникает иногда вопрос – а зачем нужны всякие “профессиональные этические кодексы”, когда они состоят в основном из очевидных истин? За ответом можно пройти в комментарии вот сюда:

https://tonsky.livejournal.com/318292.html#comments

и посмотреть на резвящихся кодописов (не “инженеров”, боже упаси!), яростно нарушающих Software Engineering Code of Ethics одним лишь фактом своего существования.

Как последовательный феминист, скажу: @vasilenkos ошибается. Орать матом можно на мужчин и женщин, белых и негров, скорбных умом и просто безруких; даже одноногих чернокожих небинарных гендерфлюидов материть можно.

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

Подумалось вот, что 24/7 может значить не только “24 часа в сутки, 7 дней в неделю”, но и “24 дня в месяц, 7 часов в день”.

Дошел до ближайшей разливайки и купил вкусного пива, поэтому вместо очередной записи “запретите им” будет немного полезных и даже местами добрых советов. А начну с того, что в ЖЖшной френдленте у fritzmorgen увидел доклад Boston Consulting Group про то, как к 2025 году обустроить Россию (да, вот это и называется “внешним управлением”), а у kouzdra – обсуждение учебника Куранта и Роббинса по математике. Ну так вот – раз я добрый, то не буду особо матерно комментировать вот эту картинку за авторством BCG:

Доклад, по большей части, представляет собой обычный набор благоглупостей про “экономику знаний” – и как положено, утверждает, что “все большее проникновение алгоритмов и компьютерных решений будет вести к переориентации потребностей рынка труда на «человеческое в человеке»: творческое начало, культурные аспекты, индивидуальные и коллективные ценности, а также универсальные «компетенции XXI века», которые не смогут компенсировать цифровые технологии” – список этих “универсальных компетенций” представлен на рисунке. Как обычно, пишется что-то про “метапредметное” образование, которое должно развивать вот эти самые “универсальные компетенции”.

“Когнитивные” и “социально-поведенческие” навыки – это, пожалуй, то, что раньше называлось “воспитанием” – а вот про правый нижний угол картинки я бы хотел сказать отдельно. Под заголовком “цифровые навыки” перечислены следующие пункты:

• программирование
• разработка приложений
• проектирование производственных систем
• обработка и анализ данных

Можно, конечно, поворчать про то, почему эти навыки отнесены к “цифровым”, и что же тогда такое “аналоговые” навыки – но я хочу обратить внимание на то, что немалая часть современных модных “цифровых навыков” – это банальная математика (и чуть-чуть информатики) в объеме программы, скажем, среднего технического вуза, и без ее знания вы проиграете даже няшному котику (который в совершенстве владеет доброй половиной soft skills).

Можно ли понять несложный, в общем-то, учебник по модному нынче “глубокому обучению“, не владея матанализом и линейной алгеброй в объеме хотя бы пары семестров? Читатель, не знающий математики, “сломается” уже на словах “стохастический градиентный спуск”. Не менее модные “большие данные”? По большому счету, их “анализ” сводится к довольно элементарной статистике. В идеале, конечно, не лишним будет понимание, какие данные являются “большими”. Методы вроде Principal Components Analysis? В основе там лежит банальнейшая линейная алгебра.

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

А ведь это все лезет и в “чистую гуманитарщину”. Digital Humanities – слово, конечно, ругательное, и в приличном обществе вызывает снисходительные усмешки – но посмотрите хотя бы картинки отсюда:

https://handbuch.tib.eu/w/DH-Handbuch/Tools#Stilometrische_Textanalyse

Вроде бы предмет называется “компьютерная филология” – но без знания математики остается лишь пользоваться готовыми инструментами (даже без понимания их ограничений), чему по большей части и посвящен остаток главы. Циники от естественных наук уже предлагают гуманитариям заняться p-хакингом – “мы применяли к текстам различные методы анализа, пока на тридцатом заходе не нашли доказывающий, что Слово о полку Игореве написано Сократом, p < 0.05" (впрочем, я и без всякого p-хакинга готов доказать, что Тохтамыш сжег Белый дом в 1993 году).

Короче говоря - что делать? Мой ограниченный жизненный опыт подсказывает "нулевое" решение - закончить мехмат - пусть он "и вообще ни к чему не готовил“, но какой-то багаж знаний, позволяющий легко понимать вот эту всю “обработку и анализ данных”, после него остается даже сейчас. Можно попробовать это решение “упростить” – так что перечислю те области человеческого знания, без которых data science будет просто модным баззвордом.

Начну, пожалуй, с “чистой” математики. Сложно представить себе “анализ данных” без хотя бы базовых представлений о теории вероятностей и математической статистике. Не менее сложно (хотя это уже со стороны может показаться и не таким очевидным) – без владения линейной алгеброй. Тот же “метод главных компонент”, по сути, практически тривиален. Ну и разумеется – никуда не деться от математического анализа, пусть даже и в сильно сокращенном и урезанном виде. В общем, получается программа того, что во всяких говновузах называется “высшей математикой” (кажется, туда обычно входят еще и дифференциальные уравнения – ну и ладно) – только вот “сдать и забыть” это все не получится.

Но! Вся эта математика, если мы говорим о “цифровых технологиях”, довольно бесполезна – так что не надо забывать и о “цифровой грамотности” на пару с программированием. Не можешь рассказать, что происходит, когда в адресной строке браузера набираешь google.com и нажимаешь Enter – давай до свидания :) Не можешь написать на любом языке программирования код для перемножения двух матриц – аналогично. В “цифровую грамотность”, разумеется, стоит включить и понимание того, что такое “большие” данные, а заодно – и представления о вычислительной сложности. Если сократить это до какого-то разумно минимального объема – то, пожалуй, это ужмется до эквивалента пары семестров – изучения какого-нибудь языка программирования и курса по алгоритмам и структурам данных.

В общем, если вы не владеете математикой в объеме пары курсов средненького технического вуза, а компьютером владеете на уровне “печатаю двумя пальцами в Microsoft Word” – то ваше место в скором будущем займет несложный скрипт на Perl, робот или даже котик.

Я думал, что угарно шучу про IoT – а тем временем ИнСАТ коварно подкрался и нанес ответный удар:

https://masterscada.insat.ru/news/?id=76412

Вот предположим, есть некая система сбора данных с кучки всяких разнородных датчиков – всяких там газоанализаторов, электро- и теплосчетчиков и прочей такой ерунды. Работает все по проводам, под управлением одной из “отечественных SCADA-систем”, частично по Modbus, частично – с использованием самописных драйверов. Данные от датчиков складываются в БД MSSQL (которая во всех документах проходит под сокращением БДСМ – “База данных системы мониторинга”, а вовсе не то, о чем вы все подумали) и отображаются ужасно кривым веб-приложением.

Ну вроде бы понятно, что это нифига не IoT, а порнография какая-то – поэтому придумалось несколько шагов, как сделать это более модным:

• заменить немодный уже Ethernet и RS-485 между датчиками и системой сбора данных на какой-нибудь радиоканал типа LoRa или там, не знаю, 6LoWPAN;
• выкинуть SCADA, поставить какой-нибудь mqtt-брокер;
• в качестве базы данных использовать MongoDB или что-то в этом духе;
• да, и перенести все в “облако”!
• самописный веб-интерфейс заменить на какой-нибудь там freeboard.io;
• всем разработчикам выдать вейпы и гироскутеры;
• гренки переименовать в croûton.
• ???
• PROFIT!!!!

Так вот, на каком шаге немодная промавтоматика превращается в IoT?

“Коррозия металла”, альбом “Компьютер-Гитлер”, 1997 год. Атлична-атлична!