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 Да, тут есть, от чего охуеть!

Опенсорс без понимания

Вот очень показательная заметка на хабре:

https://habr.com/ru/post/681614/

Наглядно показывает уровень деградации буквально одним-единственным предложением:

Сейчас же, когда QMK, наконец, добавили поддержку данного контроллера, в нашем распоряжении 2mb+ встроенной памяти, на которые мы можем «подгрузить» все полезные фишки для повышения продуктивности и удобства.

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

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

Bertsekas, Gallager, Data Networks

Есть на всяких околоайтишных специальностях в вузах предмет под названием «Сети передачи данных» или как-то типа того, где про модель OSI рассказывают, TCP/IP всякое, маршрутизацию и тому подобные вопросы. Есть по нему масса учебников — Олиферы всякие, Таненбаум книжку написал, Куроуз-Росс, Горальски, Стивенс — в общем, на любой вкус, айтишники любят. Содержание в целом более-менее стандартное — вот вам модель OSI, вот вам кучка протоколов с каждого из уровней, вот так работает маршрутизация… — разница в нюансах, где-то больше теории, где-то добавляется практика какая-то. В целом, конечно, это в основном беллетристика и перечисление готовых сетевых протоколов, которые кем-то придуманы — а понимать, почему это все работает — это не вашего айтишного ума дело.

А есть старая (1993 год! а первое издание даже издательство «Мир» в 1989 году перевело) книжка Бертсекаса и Галлагера: http://web.mit.edu/dimitrib/www/datanets.html. Чем она отличается? На первый взгляд, все начинается довольно культурно — модель OSI в первой главе с описанием ее уровней, дальше — немного про всякие протоколы (в основном представляющие собой чисто исторический интерес, из более-менее актуального во второй главе можно назвать только TCP) — но вот в третьей и четвертой главе начинается самое веселье! Внезапно плотность формул на страницу текста становится запредельной, возникает «тяжелая» математика — прежде всего тервер и слупы, но мало не покажется.

К чему это я? Поучаствовал на днях в одном мини-сраче по поводу «высшего айтишного образования», в духе «стоит ли идти на физтех, когда в любом говновузе научат тому же». Так вот, разница между выпускником условного мехмата/физтеха/ВМК и выпускником «айтишной» специальности состоит в том, что первый поймет и книжку Бертсекаса и Галлагера, и «беллетристику» Таненбаума или Курроуза, весь необходимый математический аппарат для этого у него есть. «Айтишник» же, зубривший Олиферов — омерзительный на самом деле учебник, где авторы пытаются трескучими формулировками показать свое «превосходство» над читателем — попросту не сможет осознать проблемы, которые у Бертсекаса разбираются.

Нет, многим, возможно, никогда не потребуется лепить управление очередями, алгоритмы множественного доступа или маршрутизации — но когда за это пытаются браться «чистые айтишники», получается крайне печально. Скажем, посмотрел на днях на Meshtastic — протокол организации mesh-сетей на основе «физики» LoRa. Мало того, что сам по себе протокол толком не документирован — так еще и реализация производит впечатление «слышали звон, да не знают, где он». Элементарнейший пример — используемый алгоритм конкурентного доступа явно сделан «по мотивам» используемой в WiFi distributed coordination function, которая неплохо обоснована с теоретической точки зрения — но упрощен настолько, что утрачена вся суть исходного алгоритма. Да, он выглядит довольно просто — но за этой простотой стоит довольно строгий анализ, и «лишнего» в нем нет. Вишенка на торте — этот важнейший элемент протокола нигде толком не документирован, и для того, чтобы понять, как он работает, приходится лезть в исходники.

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

Про google-driven programming

Вообще я конечно догадываюсь, как обиженка из предыдущей записи нашел мой блог — в интернетах катастрофически мало написано про 6LoWPAN поверх Bluetooth Low Energy, а в особенности — с использованием RIOT OS (кажется, кроме нескольких абзацев официальной ридмишки, которая тоже не дает ответов на все вопросы, ничего толкового нет). Ну чтож, будем помаленьку исправлять.

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

Казнить нельзя помиловать

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

Где-то месяц назад wannabe-программисту встраиваемых систем была выдана не очень сложная задача — разобраться чуть-чуть с сетевым стеком 6LoWPAN over BLE в RIOT OS, немножко автоматизировать его работу и все такое прочее.

Три недели назад чуваку был задан вопрос: все ли просто, все ли понятно, нет каких-либо вопросов? Ответ — разумеется, все просто, все понятно, вот прямо сейчас все сделаю!

Еще неделю спустя задача не выполнена, зато чувак объявился с великолепной идеей — а давайте перейдем на mbed OS, уж там-то все точно просто и понятно, вот даже API References and Tutorials подробные есть (но работает это поверх «обычного» IEEE 802.15.4, а не моднейшего BLE)! Это уже не «звоночек», это гораздо хуже — но в общем сроки пока не горят, ничего ужасного не произойдет, если он недельку потыркается в mbed, нужного там не обнаружит и с позором вернется туда же, откуда начал.

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

В 0:22 в ночь перед небольшим «интеграционным тестированием» системы в чатик прилетает вопрос в духе «а как какать»? По-хорошему, такой вопрос должен был возникнуть еще четыре недели назад — но не будем о старых обидах. Тут, конечно, повезло, что я чатик еще читал — так что в 4:44 в гит-репозитории проекта появилось решение где-то половины той задачи, состоящее из какой-то адовой копипасты и собственного кривого кода arduino-style.

В принципе, чел сам кузнец своего счастья — и накопленные за месяц 4 часа работы ему еще аукнутся, но хуже другое — по факту на данный момент, за 24 часа до демонстрации промежуточных результатов, имеем абсолютно неработоспособную часть системы, показывать собственно и нечего. Разумеется, героическим ударным трудом (в основном моим :) ) работоспособная демонстрашка завтра будет — но хотелось бы узнать, в каком месте поставить запятую в заголовке.

UPD После легкого попинывания (с предъявлением протокола совещания недельной давности) сегодня утром чел доделал к обеду оставшуюся часть задачи, итого наработав на 8 часов (ну а мне работать меньше, это хорошо). Другой вопрос, когда он вообще спит?

Ебаный блядский андроид

Изучаю тут реализацию 6LoWPAN over BLE для Android, выяснилось следующее:

— в 7 и 8 версиях есть недокументированный способ открыть сокет уровня L2CAP (через джавовскую рефлексию, описано в дипломной работе этого самого Wieland’а), в 9 версии рефлексия для некоторых «системных» классов запрещена (в том числе и для BluetoothDevice), в 10 версии это API сделано публичным;
— начиная с 6 версии Android не дает узнать MAC-адрес «своего» Bluetooth-адаптера, обходные пути нагугливаются на стековерфлоу, но постепенно закрывались гуглом, начиная с версии 8.1 закрыты все;
— MAC-адрес постоянно и непредсказуемо меняется ради «прайваси» пользователя;
— для того, чтобы начать сканирование BLE-устройств, надо включить «геолокацию», что неудобно для пользователя и в принципе выглядит подозрительно (тут у нас приложенька для фитнесс-браслета, нахуя ей геолокация?).

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

Вдогонку предыдущему — про психопатов

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

Так вот, если айтишнег хоть на секундочку одобряет саботаж в исполнении обиженного психопата — приглядитесь к нему, с большой вероятностью он сам такой же. Если он хоть чуть-чуть, но примеряет на себя поступок этого чувака — сделайте все, чтобы он не мог одной-единственной командой git commit мелко поднасрать, тем самым «отомстив» или «проучив» кого-то. Считайте каждого программиста потенциальным саботажником и держите свой код в безопасности.

Ну и на закуску — изрядный портрет этого вашего «айти-специалиста» из одной хорошей книжки:

Типичный профессиональный системный администратор – человек, в реальном мире ничего из себя не представляющий (даже далеко не всегда высокооплачиваемый), но в мире виртуальном – царь и бог. Подобное двоякое положение сильно способствует развитию комплексов неполноценности и стремлению компенсировать в виртуальности свою ничтожность в реальном мире. Поскольку речь идет о молодом человеке, значительную часть времени вынужденном проводить за компьютером (иначе профессионализм не приобрести), данный комплекс часто усугубляется половой неудовлетворенностью. Теперь представьте, что может натворить такой системный администратор с болезненным желанием продемонстрировать свою власть.

Про опенсорс и айтишников-обиженок

Весь день сегодня обсуждают выходку одного американского программиста, автора двух джаваскриптовых библиотек, который обиделся на весь мир, а особенно на компании из Fortune 500, использующие эти библиотеки — и подумать только, неспособные предложить непризнанному гению скромную six-fugure salary! Что же сделал непризнанный гений? Да просто испоганил эти библиотеки, «сломав» тысячи использующих их приложений (а в мире современной так называемой «разработки» принято подтягивать зависимости из этих ваших интернетов):

https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/

Обсуждать действия чувака неинтересно, ну разве что в порядке наброса сообщу, что он одним-единственным коммитом наработал на 273 статью УК РФ (да, я серьезно, его можно привлечь по российским законам вот прямо сейчас, внимательно читайте статью 12, пункт 3). Неинтересны и способы защиты от таких обиженок — каждому, у кого в голове что-то покрепче творожка, должно быть понятно, что тащить зависимости из интернет-помоек можно только в том случае, если финальный результат вас мало волнует.

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

В «большом» мире все как раз более-менее гладко и понятно — сложились какие-то адекватные модели поведения в диапазоне от «наши штатные сотрудники на зарплате с 9 до 18 работают над linux kernel» до «я ученый, я пишу статьи, а с кодом делайте что хотите», есть более-менее внятные модели заработка на опенсорсе — от платной поддержки до «коммерческого» форка. А вот в мире мелких npm-овских библиотек так и живет эта самая мифология об «энтузиастах». Впрочем, это не мешает «энтузиастам» и их единомышленникам всячески плакать в духе «если бизнес использует наш опенсорс, он должен нам донатить!» Во-первых, дика сама идея, что пользователи «должны» делать что-то, выходящее за рамки лицензии (никто же не стоял с пистолетом и не заставлял вас выкладывать ваш код под MIT Licence, придуманной совсем для другого?), во-вторых, единственно возможный «вклад бизнеса в опенсорс» состоит в следующем, записывайте:

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

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

И еще про Code of Conduct

Будет и у [info]eddy_em праздник — разработчики Rust посрались по поводу CoC и будет теперь у нас два раста — просто Rust и ПедеRust!

https://habr.com/ru/news/t/590869/

Еще несколько слов про отечественное айти-образование

Я все никак не соберусь и не напишу обещанные «многабукв» про околоайтишное образование — но вот еще маленький фактик в копилку. Как я уже писал, жизнь свела меня с первокурсниками магистратуры одного из считающихся неплохими московских вузов — и тем удивительнее обнаруживать у них катастрофические пробелы в знаниях! Например, на прошлой неделе выяснилось, что многим из них совершенно незнакомо слово «mutex» — хотя казалось бы, что курс под названием «Операционные системы» им читали в бакалавриате. Что должен подумать самоучка, читавший книжки Таненбаума? Неплохо, мы можем говорить на одном языке!

Но нет, «Современные операционные системы» Таненбаума включены в программу того курса лишь как необязательное дополнительное чтение, лектор рассказывает в основном об администрировании ALT Linux, а рекомендованный учебник пестрит определениями вроде «Менеджеры ресурсов: этот слой состоит из мощных функциональных модулей, реализующих стратегические задачи по управлению основными ресурсами вычислительной системы» (и как подсказывает коллега [info]matritcasiberia, это «определение» является общепринятым в российском образовании). Определение шикарно в своей бессмысленности — впрочем, подозреваю, что родилось оно из обвешивания прилагательными вполне невинной фразы «Этот слой состоит из модулей, управляющих ресурсами системы». Если «вычислительная система» еще как-то сюда вписывается, то пояснить, чем «мощные функциональные модули» отличаются от не мощных и тем более от немощных не смогут, наверное, даже авторы учебника (или многих учебников — фразочка растиражирована буквально в каждой «рекомендованной» минобразования книге!).

Естественно, «выхлоп» от подобного ПТУшного (и даже хуже) курса в вузе — примерно нулевой. Даже навыков администрирования ALT Linux не хватает, например, для понимания несложных инструкций по работе в консоли Ubuntu, а о вопросах, имеющих отношение к функционированию ядра ОС и даже простых многопоточных программ (что такое планировщик? зачем нужны примитивы синхронизации?) студенты не имеют вообще никакого представления.

Возникает вопрос — а зачем тратить четыре года жизни в бакалавриате, когда иной «колледж» (читай, ПТУ) за три года научит гораздо лучше?

Introduction to Embedded Systems — A Cyber-Physical Systems Approach

Прекрасная, просто замечательная книжка.

Во введении и первой главе наивного читателя заманивают рассказами про «интернет вещей», «киберфизические системы», «индустрию 4.0» и прочий набор стандартных баззвордов. Читатель уже ждет, когда же ему расскажут про то, как на Ардуине и Распберри сделать очередной умный дом — но тут же в главе 2 ему выкатывают второй закон Ньютона, на пальцах объясняют кусочки термеха, пишут всякие дифференциальные уравнения, а немногих выживших добивают преобразованием Лапласа. Дальше, конечно, становится немного полегче, всякая там дискретная математика и конечные автоматы особого полета фантазии не требуют, а местами даже предлагают написать немного кода на Си. Перевернуть свое представление о встраиваемых системах можно по ссылке:

https://ptolemy.berkeley.edu/books/leeseshia/

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

Теоретикам и практикам контроля версий

А вот вопрос созрел. Предположим, есть у нас вполне себе обычный IoTшный проект, состоящий из множества взаимосвязанных частей:

— схемотехника и печатная плата нескольких похожих устройств, библиотека компонентов для Eagle или DipTrace;
— прошивки — несколько, своя для каждого устройства (скорее всего, на базе Riot OS или Contiki, и возможно, с доработками самой ОС — то есть с ней обычно притаскивают целиком ее репозиторий);
— приложение для Android или какой-то там Progressive Web App;
— вебовский бекенд (скорее всего, на Django).

«Команда» — ну, по человеку (или по «полчеловека») на каждую из частей, проект новый, каждый взаимодействует с «соседями» (схемотехник-эмбеддер-фронтендер-бекендер). Вносят ли доработки в соседние части — возможно теоретически, но вряд ли.

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

А как бы вы организовали контроль версий и трекинг задач в таком проекте? Интересуют все аспекты — от используемых инструментов до «оргмер».

А вот вам еще сказочка для самых маленьких программистов

Лежит файл, в том файле SQL-дамп, в SQL-дампе поле с JSON, в JSON-е NaCl-овский криптоконтейнер, в криптоконтейнере protobuf, а в protobuf’е смерть Кащеева.