Тег ‘программирование’

Про malloc() и фрагментацию памяти

А вот чуваки придумали, как можно сильную фрагментацию памяти использовать для собственной выгоды – и сократили ее потребление Firefox’ом на 16%, заменив обычный системный malloc() на собственную реализацию:

https://arxiv.org/abs/1902.04738

Development and Deployment of Multiplayer Online Games

Посмотрел “бета-версию” будущей книжки Development and Deployment of Multiplayer Online Games: from social games to MMOFPS, with stock exchanges in between.

dnd-of-mog

Разумеется, она не столько про мультиплеерные игры, сколько про распределенные системы “вообще” – к таковым можно отнести, например, всякие там биржевые системы (автор, Сергей Игнатченко, упоминается тут, как один из разработчиков торговой системы РТС). Рассматривается буквально все – от нюансов программирования на C++ (вплоть до всевозможных заблуждений) до архитектуры “в целом“. Очень понравились главы про сетевое взаимодействие, выбор между TCP и UDP, некоторые неочевидные нюансы этих протоколов.

Сейчас вышел на бумаге первый том (из планируемых 9), почти готов второй, третий – в состоянии бета-версии (все три есть на Leanpub).

Боятся знать

Вот в твиттере @FelixTheBest – замечательный тред про программистов на C/C++ в сравнении с программистами на Java и Python, и в нем есть занятная формулировка:

люди, которые не знают C/C++ и даже боятся знать

Похоже, слова “боится знать” наилучшим образом описывают одного знакомого мне чувака, который прекрасно пишет что-то на Qt и современном C++ (это что-то в стиле, описанном в видеоролике Stop Teaching C) – но при этом панически боится plain C как “старого и низкоуровневого” языка. Собственно, это даже отвратило его от ардуины – так как там пропагандируется в лучшем случае C with classes. В общем, утащу себе определение.

Адитья Бхаргава, Грокаем алгоритмы

Мельком просмотрел тут одну детскую книжку по “алгоритмам”.

bhargava-algorithms

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

Возможно, это и неплохо для детской книги – даже очень талантливый и старательный семи-восьмиклассник вряд ли будет настолько усидчив, чтобы самостоятельно разрисовать что-то вроде диаграммы стековых вызовов для несложной рекурсивной функции, а здесь она приведена в готовом виде – но есть несколько “сюжетов”, которые при таком подходе очень сильно “повисают в воздухе”. Особенно почему-то досталось O-нотации, которая здесь изложена в виде “как ее понимает средний программист” (а уж подсчет сложности тривиальной сортировки – O(n2) – во второй главе – это просто песня!).

Кратенькое резюме такое – неплохо для семиклассника, читающего под одеялом с фонариком журнал Ксакеп, для взрослого человека скорее бесполезно, в качестве справочника заменяется любым cheatsheet-ом вроде такого:

https://algs4.cs.princeton.edu/cheatsheet/

Вот люди электросчетчик сделали

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

energymon

Разумеется, это “не только счетчик” – раз уж тут стоит микроконтроллер, то его стоит “загрузить” дополнительными задачами, так что здесь есть еще “мост” USB-UART и совместимый с CMSIS-DAP отладчик (а заодно можно использовать устройство в качестве электросчетчика в домике Барби, по масштабу подходит идеально). Это все крутится под управлением довольно нетривиальной прошивки – тут вам и срабатывающий раз в 3 микросекунды АЦП, и выдаваемые с периодичностью в 10-100 миллисекунд данные об энергопотреблении, и обновляемый раз в секунду экранчик – в общем, от написанной в стиле “бесконечный цикл” прошивки DAP42 здесь получается практически настоящая, но очень маленькая RTOS.

Да, не все пока работает идеально гладко (тем более, что основной упор при разработке делался на мониторинг энергопотребления, а мост USB-UART и отладчик – это “бонусы”) – но исходники открыты и выложены на гитхаб, так что при желании в них можно покопаться (чем я и занимаюсь сейчас, пытаясь добиться работы этого всего в полном объеме с некоторыми микроконтроллерами TI):

https://github.com/unwireddevices/dap42

Больше всего мне интересно, конечно, другое – рано или поздно в любом проекте на микроконтроллере “вырастает” несложная RTOS (собственно, с UMDK-ENERGYMON это уже случилось). А вот в какой момент там появится “заново написанная, неспецифицированная, глючная и медленная реализация половины языка Common Lisp”? Впрочем, парсер консольных команд уже есть.

Learn to code

Пишут, что в Штатах “альтернативно правые” издеваются над уволенными из всяких там Баззфидов и прочих Хаффингтон Постов журналистами, предлагая им “научиться программировать”:

https://thinkprogress.org/learn-to-code-decoded-the-campaign-against-laid-off-journalists-is-harassments-new-frontier-20725ddd480a/

И вот такой у нас Industrial IoT

Извините, но я снова про немцев. Оказывается, Dr. Ing. Michael Schoeffler на гитхабе пишет про себя так:

I’m a research engineer working in the field of Industrial IoT.

Парочка примеров кода от инженера-исследователя, работающего в индустриальном IoT:


void loop() {
  if (Serial.available() > 0) {
    byte incomingByte = 0;
    incomingByte = Serial.read(); // read the incoming byte:
    if (incomingByte != -1) { // -1 means no data is available
      lcd.setCursor(0, 0); // set cursor to first row
      lcd.print("I received: "); // print out to LCD
      lcd.setCursor(0, 1); // set cursor to secon row
      lcd.print(incomingByte); // print out the retrieved value to the second row
    }
  }
}

О существовании буквы “я”, конечно, в индустриальном IoT можно не задумываться.


long hexstr_to_value(char *str, unsigned int length) { // converts a hexadecimal value (encoded as ASCII string) to a numeric value
  char* copy = malloc((sizeof(char) * length) + 1);
  memcpy(copy, str, sizeof(char) * length);
  copy[length] = '\0';
  // the variable "copy" is a copy of the parameter "str". "copy" has an additional '\0' element to make sure that "str" is null-terminated.
  long value = strtol(copy, NULL, 16);  // strtol converts a null-terminated string to a long value
  free(copy); // clean up
  return value;
}

malloc() на микроконтроллере – это, несомненно, очень индустриально.


accelerometer_x = Wire.read()<<8 | Wire.read(); // reading registers: 0x3B (ACCEL_XOUT_H) and 0x3C (ACCEL_XOUT_L)

Я бы еще вписал где-нибудь в этой программе i++ + ++i.

А вы говорите Bosch, настоящее немецкое качество и все такое.

Про немецкие компьютерные науки

Нет, не пугайтесь, бложик пока еще не захвачен [info]vit_r. Но вот набрел на пару интернетовских страничек немецких, так сказать, “компьютерных ученых” – и мне они показались в некотором роде заслуживающими внимания.

Случай первый – Dr. Christian M. Meyer, читает в многострадальном TU Darmstadt (вот им сейчас икается, наверное) курс под названием типа “XML и цифровые публикации”. По факту – это довольно плохой курс по Perl с немного непонятным назначением – вот зачем “компьютерным филологам” знать о тонкостях написания CGI-скриптов? А ведь это, с точки зрения герра Майера, важнейшая вещь в “цифровых публикациях”. Впрочем, он весьма разносторонний человек, помимо науки, увлекается фотографией, любит путешествовать, и даже написал какой-то дурной детектив. Но все впечатление убивается буквально одной ссылкой – оказывается, он со-основатель и управляющий партнер в фирме HESCOM-Software. Всего в фирме числятся три человека – так что о весомости этих титулов можно похихикать. Но с другой стороны – а вдруг эта фирма занимается чем-то удивительно высокотехнологичным и уникальным? И следующий же щелчок мышкой развеивает эту иллюзию – фирма лепит интернет-магазины в стиле середины 2000-х, а заодно продает две программки для составления каталогов книг и антиквариата. Не знаю, как вы, а я бы особо не афишировал, что являюсь в такой шараге “управляющим партнером”.

Случай второй – Dr. Ing. Michael Schoeffler пишет, что работает в исследовательском отделе компании Robert Bosch GmbH, а в свободное от работы время на серьезнейших щщах пишет в своем бложике “как прикрутить чего-нибудь к ардуине” (вот от методов работы с ультразвуковым датчиком я даже подохуел слегка). Нет, я, конечно, видел и отечественных кандидатов технических наук, но к работе с ардуиной в стиле кружка “юный радиогубитель” они скатываются обычно по мере приближения к маразму, а здесь на фотографиях мы видим вполне себе молодого человека.

В общем, даже священные войны Олега Артамонова с разработчиками RIOT OS (которые сидят в Берлине) на таком фоне выглядят как-то по-другому.

PS Для желающих рассказать в комментах об АБС фирмы Bosch – ссылка на статью в “Авторевю” у меня уже есть: https://autoreview.ru/articles/po-dorogam-i-bez-nih/otkat-patriota

Вот кстати вынесу из комментов

[info]sanches вспоминает, как раньше трава была зеленее – в чем я с ним абсолютно согласен, ибо прохожу как раз по нижней возрастной границе указанного им поколения – “люди, начиная где-то от 30+ и далее везде, – сильно, сильно старше. Которые успели застать вот эту вот революционную вакханалию, – когда каждый год появлялось что-то принципиально новое.” В комментариях, правда, почему-то перешли к теме дороговизны российского интернета – что является очередным странноватым мифом. В Москве и ближайших окрестностях честный домашний безлимит стоит от 400 рублей (около 6-7$) в месяц, мобильный интернет – что-то около 1$ за гигабайт (с мест сообщают, что есть вариант неслыханной щедрости – 992 рубля в месяц за безлимитный домашний и мобильный интернет на хорошей скорости – соответственно 100 и 4,1 Мбит/с).

Интереса ради посмотрел цены у провайдеров в Берлине (Европа, все дела) и Нью-Йорке. Берлин “обрадовал” тарифными планами от 15 евро в месяц за “безлимит” 16 Мбит/с или мобильными тарифами с абонентской платой 25 евро в месяц (в это включено 2-3 Гб интернет-трафика). В Нью-Йорке со скоростями получше – рекламируются тарифы от 155 Мбит/с до 1 Гбит/с (мелким шрифтом, правда, написано – experienced speeds may vary) по цене, соответственно, от 30 до 50 долларов в месяц. Сотовые же операторы в Америке дерут 30 долларов за тариф с включенными 6 Гб интернет-трафика (на самом деле там 3 Гб, и это “спецпредложение”).

В общем, не первый раз уже вижу мнение, что у нас в России отсталое IT, а вот на Западе – там ух! – и тарифы на интернет это только одно из его проявлений. Сам лично наблюдал некоторую разницу в восприятии одной и той же программы для планшета, когда она “мимикрировала” под иностранную и когда позиционировалась как отечественная. Да даже больше скажу – совершенно банальная электронная приблуда, Bluetooth-адаптер для датчика пробега, вызвала откровенное удивление, когда я сказал, что собрана она в России вот этими самыми руками (хотя зачем я зачеркиваю? все правда). Так вот, разочек попробовал осознать “место России в мировом IT” в комментариях у [info]32bit_me – и приведу здесь этот комментарий с минимальными правками (в первой его версии я безбожно забыл про Южную Корею):

Ах, это вечная русская тяга к самоуничижению :) Если разговор заходит об IT – то “сравниваться” надо с “англоязычными странами” (какими именно, кстати? не проще ли вместо двух десятков букв написать всего три – США?), “Индией, Китаем или даже Японией”. В разговоре про автомобили – никак не обойтись без сравнения “Жигулей” и БМВ, ну и так далее.

А если посмотреть на общий уровень “развитых стран” (https://en.wikipedia.org/wiki/Developed_country – в любом из вариантов), да еще и присовокупить к ним Китай и Индию? Сколько из них имеют свой интернет-поисковик, забарывающий на локальном рынке Google? Социальные сети круче Facebook? Где есть СУБД, до разработчиков которой можно донести необходимость внедрения закладок от АНБ/алгоритмов шифрования ГОСТ/”великого китайского файрволла”? Кто балуется утопическими проектами типа “русской/китайской/etc” ОС или “собственной” (в кавычках, потому что тут можно зайти далеко, вплоть до идей чучхе) электроники?

Тех, кто может осилить вот такой full-stack, похоже, нет вовсе; в той или иной степени – это будут США, Южная Корея, Китай и Россия; возможно – Евросоюз совместными усилиями, насчет Японии сказать ничего не могу, в плане Индии – очень сильно сомневаюсь. По-моему, быть даже в такой “семерке” вполне достойно – а может, речь идет и о тройке лучших.

Как говорится, discuss.

О смягчении нравов, продолжение

Поиграл тут еще с некоторыми примерами от NLTK. Был неприятно удивлен производительностью и тем, как эта штука жрала память, урча маянезиком. Я пока особо не лез во внутренности nltk.probability.FreqDist (подозреваю, что во всем виноват этот класс), но кажется, это довольно примитивная обертка над обычным ассоциативным массивом – так что я удивлен вдвойне тем, что на небольшом, в общем-то, наборе данных отожралось 2-3 гигабайта памяти “на ровном месте”. Задача в целом довольно тупая – надо найти в тексте наиболее часто встречающиеся последовательности из нескольких подряд идущих букв (это называется “символьные N-граммы” и иногда даже используется).

Задача в общем-то тривиальная, и на любом нормальном языке программирования решается почти элементарно – я оценил бы простое решение (без поддержки Unicode, только для одного-двух языков, etc) на plain C где-то в пару часов работы. Расход памяти – небольшой, сравнимый с объемом данных – думаю, что в мегабайт даже можно уложиться. Скорость работы – ну не знаю, сколько там времени надо на проход по массиву? Ну да, я понимаю, что показывать NLTK программистам нельзя – но вот я уже как-то сомневаюсь, что с его помощью можно решать задачи филологов.

Но самое важное – запускали мы это на Macbook Air 2015, кажется, года – и до вчерашнего дня его хозяйка не знала, какой там стоит процессор и сколько памяти. Для любых нормальных человеческих задач (ну там сайтики, кино, музыка) их в целом хватало. И вот с одной стороны, конечно, хорошо, что сейчас, в 2018 году, о том, что такое процессор, и сколько в твоем ноутбуке оперативной памяти, и даже о том, зачем она нужна, можно не задумываться. А с другой – даже эти невероятные по меркам двадцатилетней, скажем, давности (да, я такой старый, что у меня еще остались недоигранные партии в HoMM II) ресурсы все равно тратятся каким-то диким образом. Какой-нибудь примитивный байесовский классификатор (их с середины 90-х используют для определения, является ли email спамом или нет) требует для своего функционирования несусветных объемов памяти, а работает неприлично медленно.

А вот посоветуйте, что почитать

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

raskolbas

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

Признаюсь сразу – я лошара, и первым же делом стоило проверить, что действительно приходит с АЦП – но по опыту использования фильтров из 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 кБ.

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

Free hugs

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

free-hugs

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

О смягчении нравов

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

task64

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

Кто про что, а я снова про time series

Почитал тут всякого про хранение временных рядов (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 одним лишь фактом своего существования.

Я добрый сегодня

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

competence

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

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

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

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

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

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

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

dh-pca

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

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

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

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

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

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

К предыдущим двум записям

Еще одна часто игнорируемая область знаний “настоящего” программиста – умение оценивать необходимые для решения поставленной задачи вычислительные мощности. Ну да, нейросетка для MNIST на микроконтроллере за 7 $ на первый взгляд – это круто. Но с другой стороны – помните такие древние-древние наладонники Palm?

palm-pilot-1000

У них было поле для “рукописного” ввода букв и цифр – правда, с использованием упрощенного алфавита Graffiti, но как минимум цифры там были довольно похожи на “настоящие”. При этом распознавание рукописного ввода с тачскрина прекрасно жило даже на самых дохлых Palm с 128 кБ ОЗУ и 512 кБ ПЗУ (в которых помещалась операционная система и кучка необходимых приложений). Тактовая частота процессора составляла всего лишь 16 МГц. Согласитесь, что то же самое распознавание цифр на микроконтроллере с тактовой частотой под 100 МГц, 320 кБ ОЗУ и 1,5 Мб Flash уже не выглядит невероятным прорывом?

А модное нынче распознавание речи? В один голос Google, Amazon и Яндекс рассказывают нам о невероятной сложности их “голосовых помощников” – мол, “Чтобы обработать речь, нужно сделать много расчетов, поэтому то, что вы говорите, передается на серверы Яндекса и распознается там.” При этом внутри “умной колонки” стоит неслабый процессор (неназванный Quad-core ARM Cortex-A53 @ 1 GHz (12000 MIPS)), 1 Гб ОЗУ и 8 Гб ПЗУ. Неслабо так, да? А тем временем, роясь в куче хлама, я недавно нашел пиратский диск конца 90-х с кучкой программ для распознавания речи – и я точно помню, что что-то оттуда работало на моем тогдашнем Pentium 120 МГц с 16 Мб ОЗУ и Windows 95, и вполне неплохо.

Вот вроде бы кажется, что “большие данные”, “нейросети” и все такое – это невероятно сложно и доступно только “технологическим гигантам” – но с другой стороны, посмотрите на исследования в области искусственного интеллекта и машинного обучения конца 80-х. Результаты могут быть довольно впечатляющими даже по нынешним временам, а бюджеты и вычислительные мощности даже в самых продвинутых проектах – смешные. Поневоле задумаешься – а вдруг всякие “умные колонки”, голосовые помощники, система Android и так далее – это просто инструменты для сбора данных? Во всяком случае, это укладывается в логику статьи “For Google, you’re neither the consumer nor the product. You’re a data point”:

https://rakhim.org/2018/09/you-are-a-data-point/

Ну и естественно, стоит задуматься, как все это сочетается с представлениями о приватности и безопасности.

Суровый программизм

Вот читаю я, допустим, статейку про проект uTensor – совместимую с TensorFlow реализацию нейросетей для ARM Cortex M3 или M4.

https://towardsdatascience.com/why-machine-learning-on-the-edge-92fac32105e6

Штука прикольная – пусть и на “топовых”, но все-таки на недорогих и довольно доступных микроконтроллерах позволяет, например, распознавать рукописный ввод:

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

Ну, для начала – математика. Для понимания хотя бы MIT’овского учебника по Deep Learning желательно иметь представление о линейной алгебре, теории вероятностей, возможно, о каких-то началах функционального анализа. Да, некоторые отрывочные сведения из этих дисциплин приведены в первой части этого учебника (так часто делают в американских учебниках – так как нет гарантий, что слушатели курса по машинному обучению перед этим действительно прослушали несколько курсов по математике) – но их явно недостаточно. Если ориентироваться на программу мехмата, например – это 2-3 курс, если безжалостно ужимать – то все равно необходимо 3-4 семестра одной только математики.

Программирование тут не менее суровое. Даже если предположить, что с Python (в объеме, необходимом для TensorFlow) человек, умеющий немного программировать на C, сможет разобраться самостоятельно – все равно здесь, как и в любом проекте с использованием микроконтроллеров, требуется отличное знание C и даже немного – C++ (даже если говорить о нем, как о C with classes – все же нужно понимать “цену” тех или иных возможностей C++). Не знаю, стоит ли в обязательные общие требования к программисту включать знания классических алгоритмов – но в целом в критичных к производительности задачах это оказывается само собой разумеющимся требованием. Тут у нас нет многоядерного процессора и гигабайтов оперативки. В “профессиональном обучении” программиста это где-то год.

Дальше – микроконтроллерная специфика. Да, “входной порог” в программирование для микроконтроллеров сейчас (благодаря все той же ARM mbed) сводится “до уровня базовых знаний C/C++ и электроники в масштабе «подключить светодиод в нужной полярности»” (c) – но для понимания штук типа CMSIS-NN желательно уже иметь представление об архитектуре ARM, всякого рода оптимизациях, DSP-инструкциях (зря что ли мы берем Cortex-M4?) и прочей такой вот низкоуровневой ерунде – возможно, вплоть до программирования на ассемблере. Электроника, нужная для такого проекта, разумеется, тоже довольно далеко ушла от “подключить светодиод в нужной полярности”.

В общем, если представить учебники по каждой из дисциплин – тут “вырисовывается” книжная полка с десятком книжек страниц по 300 каждая (это минимум – некоторые особенно “хорошие” учебники по некоторым разделам computer science приближаются к полутора тысячам страниц). Можно, конечно, возразить с аргументами в духе разделения труда – мол, не обязательно специалисту по deep learning знать нюансы архитектуры ARM, да и математика ему не особо нужна, и вместо одного “универсала” тут можно взять трех-четырех выпускников трехмесячных курсов. Но с другой стороны – над ними все равно должен быть какой-то руководитель – который должен иметь представление не только о технических аспектах, но еще и направлять процесс разработки.

И заметьте – все это только для того, чтобы можно было пальчиком провести по тачскрину, а на дисплее отобразилась бы введенная цифра. Но, конечно, всегда есть и более простой путь – “еще три года назад Антон был простым раздолбаем, а сегодня он Senior Developer в Luxoft” (c). Сеньер-формошлепом, наверное, быть неплохо :)

Внезапно осознал

namespace std в C++ – это не сокращение standart, это сокращение sexually transmitted disease – заболевание, передаваемое половым путем.