Всем привет! Мы хотим продолжить серию постов на тему “где используются эти ваши странные языки программирования”. В прошлый раз мы рассказали про Лисп, а сегодня продолжим разговор про функциональные языки и обратим внимание на Haskell.  Он является основным языком разработки в Typeable и, конечно, мы не смогли пройти мимо такой темы.

Haskell — чистый функциональный язык программирования общего назначения. Среди его отличительных особенностей можно выделить строгую статическую типизацию, ленивые вычисления, алгебраические типы данных и серьёзную теоретическую основу. Это относительно молодой язык, он появился в 1990 году, но уже оказал значительное влияние на другие языки и на теорию языков программирования в целом.

Недавно у нас был пост про полезные утилиты, написанные на Haskell, но все они нацелены на использование технически подкованными людьми. Сегодня же приведём примеры прикладного использования из различных индустриальных областей.

Продолжение истории с электросаксофоном, написанной в прошлом году.

Год прошел, решил рассказать, что за это время произошло. А произошло многое:

• Электросакс изменился до неузнаваемости

• Из Pet-проекта превратился в продукт для рынка, выпущена первая лимитированная серия, выполняются предзаказы.

• И вообще, теперь он называется SAXILENT.

Как это произошло? Смотрите под катом!

Итак, наш бизнес идет отлично, шляпы продаются, количество сотрудников увеличивается, формируются отдельные подразделения: маркетинг, продажи, логистика. Потребность в своих собственных корпоративных сервисах становится все сильнее. Для них мы арендуем дополнительное помещение, покупаем пару серверов с виртуализацией, чтобы было все как у людей, и получаем небольшого размера центр обработки данных (ЦОД). Соответственно, создаем ядро нашей корпоративной сети на базе стека хороших коммутаторов. Количество сотрудников значительно выросло и для обеспечения стабильной связи мы организуем инфраструктуру Wi-Fi с точками доступа и контроллером для управления.

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

Несколько лет назад сделал себе на Arduino блок мониторинга питания дачного котла от UPS. Как показала практика, связка Arduino MEGA + шилд на SIM900 со стандартными библиотеками работает очень нестабильно. Периодически всё зависает, само перегружается и т.д. Отладить это невозможно, поэтому стал искать другие варианты. В результате решил всё переделать на современных технологиях: взял за основу STM32 Bluepill, приобрел на али модуль SIM800L, но самое главное – весь код решил написать на Rust, купился на обещания его высокой надёжности. Что из этого получилось читайте дальше.

ПЛИС и Verilog - естественная платформа для обучения будущего проектировщика процессоров, так же как Си и микроконтроллеры - естественная платформа для обучения будущего программиста встроенных систем.

И один, и другой путь начинается с мигания огоньками на недорогой плате, но дальше пути расходятся. Встроенный программист смотрит в сторону самоуправляющихся авто, с задачами на RTOS и распознаванием ситуации с помощью AI в GPU. Проектировщик микросхем на уровне регистровых передач смотрит в сторону групп, разрабатывающих CPU, GPU, NPU и сетевые чипы, но какие упражнения он может делать между миганием огоньками и трудоустройством в Интел?

Недавно на Хабре проскакивала новость о Magnit Tech++ Meet Up, и в ней упоминалась задачка, которая меня заинтересовала. В оригинале задачка формулируется так:

Определена функция с сигнатурой:

void do_something(bool a, int b, std::string_view c)

Определить функцию, принимающую в произвольном порядке аргументы типов bool, int, std::string_view и вызывающую функцию do_something с переданными параметрами в качестве аргументов.

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

Привет, Хабр!

Предлагаю вашему вниманию первую из серии статей о производстве установок для присоединения кристаллов и поверхностного монтажа для многокристальной и многоуровневой сборки изделий электронной техники.

В процессе обратной разработки прошивок иногда возникает задача по ее эмуляции, например, для фаззинг тестирования или детального изучения поведения в динамике. На практике обычно для этого хватает фреймворков avatar2, unicorn, qiling и подобных. Однако они поддерживают далеко не все платформы и имеют ряд ограничений для решения таких задач. При разработке эмулятора PLC я столкнулся с тем, что ни один фреймворк для эмуляции не поддерживал требуемую платформу.

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

Привет!

Представляем вашему вниманию дорожную карту для изучения языка программирования C++. Идея дорожной карты возникла после проведения десятков собеседований молодых разработчиков, которые претендовали на роль Junior Developer C++, но обладали довольно слабой подготовкой по различным причинам.

Заинтересовавшихся приглашаем к прочтению статьи, а также ознакомиться с дорожной картой.

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

"Генерация случайных чисел слишком важна, чтобы оставлять ее на волю случая" - Роберт Р. Кавью

Как-то поздним летним вечером мне пришлось разобраться, как устроены генераторы случайных чисел в Windows и Linux. Собственно, в этой статье я попробую привести саккумулированную информацию, и преподнести её максимально простыми словами, без необходимости лезть в исходники, туториалы и статьи.

В чем главное отличие между FPGA-хоббистом, ностальгирующим по КР580ИК80 на пенсии - и начинающим микроархитектором, ориентированным на будущее трудоустройство в передовую процессорную компанию или сфинансированный венчурными капиталистами стартап?

Три слова: понимание концепции конвейера. Молодым профессионалом, не старым хоббистом.

Это наглядно видно, если вы погуглите тексты про FPGA для начинающих. Если текст пишет программист, которому захотелось потрогать FPGA чисто для разнообразия, он как правило до конвейера не доходит. Помигает лампочками, поговорит про конечные автоматы и может начнет встраивать какую-нибудь FPGA-реализацию старого 8-битного процессора.

(Некоторые из таких людей даже пишут книги - вот некий Роберт Дунне реализовал процессор конечным автоматом с состояниями fetch/decode/execute, но до конвейера не дожал)

Все это происходит потому, что понимание работы конвейера как правило требует некоего мозгового усилия, типа толчка штанги. И если мозг уже поставлен десятилетиями программирования на Си и ассемблере, он упирается, потому что это ему контринтуитивно.

Но это надо преодолеть, поскольку если вы прийдете интервьироваться в какой-нибудь AMD на позицию юного проектировщика, вас будут спрашивать не как помигать лампочками и засунуть Радио РК-86 в Xilinx, а как стоя перед интервьирующим написать на доске на языке описания аппаратуры Verilog - конвейерную реализацию какого-нибудь умножения со сложением. Или сделать это на компьютере отрезанном от интернета, так что вы даже не cможете нагуглить решение - вот садисты, а?

Именно этому вопросу будет посвящено следующее занятие Сколковской Школы Синтеза Цифровых Схем.

Я продемонстрирую несколько экспериментов с сигналами, в которых обнаруживаются не совсем очевидные вещи. В качестве примеров я выбрал обработчики сигналов SIGINT и SIGABRT. Обработчик SIGINT вызывается асинхронно, в ответ на нажатие клавиш CTRL+C. Обработчик SIGABRT вызывается в ответ на необработанную исключительную ситуацию, но не всегда. Я объясню особенности, возникающие в зависимости от способа генерации сигналов и наличия отладчика.