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

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

В одном девайсе на микроконтроллере с ядром 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 – заболевание, передаваемое половым путем.

Вот подумалось тут

Разбирая непрочитанные закладки в браузере, наткнулся на “заложенную” статью о Progressive Web Applications. Я некоторое время назад задумался о простеньком веб-приложении, умеющем работать в “оффлайне” – точнее, способном сохранить введенные в форму данные и затем синхронизировать их с сервером, так что краем глаза увидев “рекламу” концепции Progressive Web Application, подумал – это как раз то, что нужно! Вот сегодня наконец-то руки дошли до погуглить, что это такое и как они делаются – и если честно, я немного офигел.

Идея, если подумать – очень простая. Немалая часть “приложений” для Android или iOS – это несложные обертки над каким-нибудь API, работающим поверх обычного HTTP. Некоторые вообще не парятся и отрисовывают весь пользовательский интерфейс в WebView или как он там называется, и даже реализуют “содержательную” часть приложения на браузерном JavaScript. Так вот, зачем плодить такого рода “приложения”, если можно сохранить на устройстве “главную страницу” сайта (или “приложения”) вместе с необходимым JavaScript и прочими ресурсами (CSS, картинки и так далее)? PWA – это небольшой набор средств, позволяющих добавить специально оформленную веб-страничку в список “приложений” на устройстве с Android или iOS. К этому добавляется возможность зарегистрировать в системе некоторый код на JavaScript для фонового выполнения – эта штука называется ServiceWorker – и готово!

Примерно тот же набор фактов вперемешку с основными принципами разработки “прогрессивных веб-приложений” излагается обычно на паре страниц мелким текстом, засоренных “птичьим языком” про “rich mobile experience”, “new level of quality” и тому подобную ерунду. В худшем случае все сводится к этой самой ерунде, а технические детали опускаются совсем.

Вот мне интересно – в других, отличных от веба разделах того, что обычно называют “информационными технологиями”, отношение количества вот такого буллшита к техническим деталям обычно немного ниже. А почему?

Мнение нормального человека об этой вашей ардуине

Хочу заметить – пишет не “электронщик” ни разу:

Arduino тупиковая ветвь учёбы. Счётные палочки мейкерства. Есть чуваки, умудряющиеся этими палочками пейзажи рисовать, зажав коленом, но такой фанатизм не для всех.

https://felixit.blog/2018/10/02/pro-arduino/

О профессиональной этике

Полистал тут книжечку Modern Assembly Language Programming with the ARM Processor by Larry D. Pyeatt, в частности, главу про арифметику с фиксированной запятой. В этой главе упоминается про известный случай с заглючившей системой Patriot, а в одном из упражнений предлагается обсудить это, исходя из положений Software Engineering Code of Ethics And Professional Practice.

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

Code of Conduct здорового человека

Крайне рекомендую к внедрению в опенсорсных проектах:

https://github.com/unwireddevices/RIOT/blob/loralan-public-2018.07/CODE_OF_CONDUCT.md

UPD Не все понимают, чем он так хорош – смотрите в сравнении с “Code of Conduct курильщика”.

Еще кого-нибудь обосру – на очереди TU Darmstadt

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

http://www.ke.tu-darmstadt.de/lehre/archiv/ws0607/ai1/material/

Технический университет Дармштадта – это вам не кот чихнул, а, как подсказывает нам Педивикия, “один из наиболее известных технических университетов, является членом TU 9″. Вводный курс по “общей информатике” читает профессор Йоханн Фурнкранц – может, он действительно большой специалист по “искусственному интеллекту”, но преподавать не умеет от слова совсем.

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

Вопрос первый стоимостью 10 баллов – про память компьютера Commodore C64. Мгновенно отсекает студентов, не слышавших слова типа “шина адреса” и “шина данных” – ну или привыкших думать над вопросом, а не мгновенно переводить все встреченные числа в двоичный вид. Теоретически, ответ на этот вопрос можно найти в лекциях – на 6 слайде лекции про фон-Неймановскую архитектуру немножечко рассказывается о разрядности данных и адреса, но многие ли студенты будут в состоянии это запомнить, понять и применить на экзамене?

Второе задание на 12 баллов проверяет склонность к зубрежке и начетничеству, которую многие преподаватели путают с освоением предмета. Вопрос – “что такое дигитализация и почему это важно для современных компьютеров?” Прилежный студент-отличник должен встать по стойке “смирно” и бодро оттарабанить заученное: “Современные компьютеры – это цифровые компьютеры и вся информация, как то: символы, тексты, изображения, музыка, видео и так далее должна быть преобразована в цифровую форму, то есть представлена последовательностью из нулей и единиц!” Просто прекрасен вопрос о том, является ли Java интерпретируемым или компилируемым языком. Интересно, можно ли на экзамене сказать про JIT-компиляцию, или профессор выпадет в осадок?

Задание третье, 8 баллов – таблицы истинности. Ну тут сложно придумать что-то совсем нехорошее. Единственная претензия с моей стороны – вот такие обозначения для всяких там дизъюнкций и конъюнкций только запутывают. Одна и та же операция может обозначаться аж тремя способами (”как в математике”, буковками – OR, AND, NOT, и “как в Java” – &&, ||, !) – не многовато ли?

Задание четвертое аж на 15 баллов. Тут начинается “программирование”. О том, как оно изучается – надо сказать отдельно. Быть может, и неплохо вводный курс программирования начинать с “робота” типа того, который был в учебнике Кушниренко (вообще, “гонять робота по клетчатой доске” – прекрасный способ продемонстрировать “содержательное” программирование, не прибегая к математике типа метода Ньютона или даже квадратных уравнений), но “немецкий” Karel J. Robot – это что-то чудовищное.

Во-первых – может быть, многие уже забыли, но Си-подобный синтаксис – это полная дикость для человека, видящего его в первый раз. Хуже может быть только какой-нибудь APL (и то не факт). Немецкий “робот” – это довольно тонкая “обертка” над языком Java, соединенная с редкостно уебищной IDE. Вы удивитесь, но у живого человека возникают проблемы с тем, надо или не надо ставить точку с запятой после for(…) или if(…), где ставить и где не ставить какие скобки (их, напомню, в Си и других языках с похожим синтаксисом аж три сорта), ну и так далее. В любом редакторе кода для “кушниренковского” (в широком смысле – отношу сюда и разработанного в 57 школе “Робота“) эта проблема решалась тем, что все конструкции языка программирования вводились через контекстное меню (что-то типа Code Snippets во “взрослых” IDE) – здесь же не умеющих программировать студентов оставляют наедине с ущербным текстовым редактором (кажется, даже без подсветки синтаксиса). Зато полдесятка слайдов в лекции по работе с Karel J. Robot и задание в одной из контрольных посвящены всевозможным “орфографическим” ошибкам – что как бы намекает на основные сложности.

Впрочем – и это будет второй и главной претензией к содержанию курса – он вовсе не рассчитан на “не умеющих программировать”. Первый же пример кода в этом курсе появляется во второй лекции (слайд 21). Вы уже знаете, что такое переменная, массив, цикл? Тогда вам остается только покивать головой “Ja, Ja” в ответ на объяснения со следующего слайда. Не знаете? Это ваши проблемы. Я почти не шучу – “программирование” начнется в лекциях по Karel J. Robot и новые понятия будет появляться в бешеном темпе. Прекрасно, если вы что-то слышали про условный оператор и циклы в любом языке программирования. Не слышали? У вас есть три слайда, чтобы разобраться.

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

Столько же баллов “стоит” и задание номер 5 – элементарная задача по работе с массивами. Единственная сложность, видимо – “программирование на бумаге”.

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

Что же видим по итогам двух семестров (в техническом университете, хочу заметить)? Проверяемый уровень знаний соответствует примерно российскому ЕГЭ по “информатике”, да еще и отягощен бездумным изучением Java. В курсе не разбирается ни одного хоть сколько-то нетривиального алгоритма (видимо, из-за нехватки времени). Да что там говорить, когда в лекции “Что такое методы” примерно половина слайдов уделена вопросу, чем метод класса (то есть с ключевым словом static) отличается от метода объекта!

Теперь – маленькая вишенка на торте. Напомню, что этот курс читается всем специальностям, где предусмотрена “информатика”, в частности – магистрам по специальности “компьютерная лингвистика“. Два семестра из четырех отводится на этот лютый онанизм, предназначенный скорее для будущих “профессиональных программистов на Java” – и лишь в третьем семестра ВНЕЗАПНО в программе появляется Python с NLTK. Хочется спросить – а почему бы не начать с того же питона? Но нет, сначала надо вынести мозг при помощи Java, а затем немногим выжившим – показать их настоящий профессиональный инструмент.

UPD Первая лекция третьего семестра у компьютерных лингвистов начинается со сравнения Java и Python в духе “в Java ужас-ужас и непонятно, а в Python все очень легко и просто”:

java-vs-python

Вопрос о целесообразности изучения Java в течение двух первых семестров остается открытым.

Заодно – начинать с Java, говорят, вредно и для будущих программистов. Во всяком случае, мучения джависта, пытающегося осознать “модель RAM” из первой же главы книжки Кормена я как-то наблюдал лично.

Быдлохабр, часть очередная

https://habr.com/post/423889/

В комментариях перепись говнокодеров.

Да, если у вас тормозит (сюрприз, да?) страничка хабра с тысячей комментов – то содержательную часть публикации оттуда можно прочитать у автора (на английском, правда):

http://tonsky.me/blog/disenchantment/

Онлайн-IDE с чятиком

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

Первый – https://codeinterview.io, он же https://www.remoteinterview.io. Платный, но для моих задач вроде как подходит и демо-версия. Довольно большой выбор языков программирования, есть unix shell и видеочат. Текстовый чат отсутствует. Платная версия дорогая – 500-1000 $ в год, или 5 $ за каждое “собеседование”. Мне кажется, что “для двоих” можно завести одно такое “собеседование”, заплатив 5 $ один раз, или же пользоваться бесконечно оформляемым на разные левые email-ы free trial.

Второй – https://codebunk.com, в отличие от предыдущего варианта, для интерпретируемых языков прикручено окошко с REPL, есть текстовый и видеочат. По-моему, демо-режим поддерживает только одного работающего пользователя. Заметно дешевле предыдущего варианта – 9 $ в месяц.

Гугл выдает еще https://coderpad.io/ – опять же, позиционируется, как инструмент для проведения программистских собеседований, есть компилятор и видеочат, стоит от 50 $ в месяц, free trial на 7 дней – но у меня заработало не во всех браузерах.

Что нибудь еще подобное есть?

Чтобы глупость каждого видна была

Вот, например, некий Михаил Плаксин, доцент из пермского филиала ВШЭ кидает понты в фейсбуке:

plaksin

Ну в целом никто его за язык не тянул – так что “уважаемые оппоненты” пошли на сайт ВШЭ в раздел “Преподаватели и сотрудники” и откопали там страничку доцента с его многочисленными работами, частью даже выложенными для скачивания:

https://www.hse.ru/org/persons/4200771#sci

Продираться через всякий ТРИЗ и прочую “ТРИЗформатику” малоинтересно – а вот получить представление, как большие специалисты по преподаванию информатики что-то рассказывают детям, удалось:

https://yadi.sk/i/gWwvY-h3HDKA0Q

Докопаться, конечно, тут можно буквально до всего – от странных представлений автора о точности вычислений до использования в примерах древнего Turbo Pascal – но тут же есть еще один глобальнейший “косяк”. Приведена куча примеров “неточных” вычислений – и никоим образом не объясняется, что же происходит “на самом деле” (и вообще – написать обширный текст о машинной арифметике и ни разу не намекнуть на IEEE 754 – нужен талант). Что вынесет из этой статьи читатель? “Компьютер считает не всегда точно, что с этим делать и кто виноват – неизвестно”. Неужели именно этого и добивался всеми силами автор?

Understanding the Digital World: What You Need to Know about Computers, the Internet, Privacy, and Security

Оказывается, Брайан Керниган (один из авторов языка программирования C и операционной системы Unix) еще не впал в маразм и недавно (в 2017 году) написал книжку с подзаголовком “что нужно знать о компьютерах, Интернете, приватности и безопасности”.

understanding-the-digital-world

Основное содержание книги – что-то вроде конспекта курса лекций по “Введению в Computer Science”, или CS 109 в университете Принстона (кстати, очень полезно посмотреть задания и лабораторные по этой ссылке). Примерно 3/4 книги повторяют более раннюю “D is for Digital: What a well-informed person should know about computers and communications”, но здесь добавлен новый материал по криптографии, безопасности и тому подобным вопросам.

Если вам интересно, что действительно должно быть в нормальном современном учебнике по “Основам информатики и вычислительной техники” – посмотрите эту книгу и упражнения к ней.

Hadoop против Unix shell

Прикольно как – обработка одного и того же набора данных модными современными инструментами (Amazon EMR и mrjob) занимает 26 минут, а простыми средствами Unix shell – 12 секунд.

https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html

“Наивное” решение средствами все той же командной строки обрабатывает те же данные за 70 секунд – что уже вполне терпимо.