Вероятно вы слышали о "Школе синтеза цифровых схем". Здесь учат цифровой логике и программированию ПЛИС. Каждый желающий может записаться на курсы школы и пройти обучение. Филиалы школы есть во многих городах.

Школа готовит программу лабораторных работ для изучения FPGA. Они опубликованы на Github: https://github.com/yuri-panchul/basics-graphics-music

Особенность этих лабораторных работ в том, что они адаптированы для совершенно разных FPGA плат, платы от разных производителей, используется разная ёмкость FPGA чипов, разные вендоры FPGA.

Мы сделали форк этих лаб https://github.com/marsohod4you/basics-graphics-music и адаптировали лабораторные работы на нашу плату Марсоход3GW2.

Дальше я немного расскажу о некоторых учебных работах.

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

Я рискую тем, что спровоцирую open-source сообщество, но решил поделиться некоторыми своими взглядами. Хотя есть контрпримеры к большинству моих слов, не все пункты применимы к каждому проекту, и я несколько упускаю из виду различные виды "свободного" и "открытого", я надеюсь, что мне удалось выкристаллизовать некоторые ключевые моменты.

Подскаст, посвященной это теме размещен в SoundCloud.

TLDR: Большая часть этой статьи может быть подытожена двумя выводами: (1) бесплатное программное обеспечение с открытым исходным кодом может быть очень хорошим, но оно плохо справляется с тем, что мы пытаемся сделать; и большая часть причины в том, что (2) открытый исходный код распределяет разработку среди небольших, самостоятельно собирающихся групп, которые по отдельности решают части общей задачи, но масштабная, единая разработка требует централизованного контроля и постоянных усилий.

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

WLJS Notebook - это приложение, похожее на Jupyter и Mathematica. Пользовательский интерфейс сделан на Electron, а сервер работает на Wolfram Language. Т.е. это не очередная оболочка для Jupyter, а полностью самостоятельное приложение. Более подробно о проекте можно почитать в предыдущих статьях: Wolfram Language JavaScript Frontend и Open-source блокнот Wolfram Language или как воссоздать минимальное ядро Mathematica на Javascript. В этой статье я постараюсь рассказать о том, чего мы достигли за последнее время. Мы добавили новую функциональность, исправили множество ошибок оптимизировали взаимодействие с сервером и ускорили выполнение кода в интерфейсе. И конечно же внесли множество изменений в пользовательский интерфейс и улучшили графику. Обо всем этом подробнее под катом!

Если вы посмотрите на общую раздутость современного софта, загружаемые 100 гигабайтные игры, ежегодную Nvidia X090 дающую +20% год от года, и 20-ядерные процессоры, то со стороны может показаться, что оптимизация производительности неважно чего, будь то игры или другой софт, казалось бы, утратила свою актуальность. В эпоху безнаказанной производительности аппаратной части можно расплескивать хоть половину этой мощи, и пользователь этого даже не заметит. Это все может и верно, если вы не делаете игру. Почему же тогда на этих двадцати ядрах, фризит и тормозит (хорошо что не вылетает часто) игра выпущенная два года назад?

Почему тормозит я вам не скажу: возможно разработчики, которые делали её (на не самом новом движке, надо сказать) просто делали игру и не задумывались о рядовых игроках, которые сидят на пятилетнем железе, хотя даже пятилетнее железо уделывает приставки текущего поколения. Возможно это другая причина - когда твоя рабочая машина с 64 гибайтами оперативки и 4080 на борту тянет редактор, то беспокоиться об игроках можно начинать после патча первого дня.

При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает. Или звуковая подсистема, так она вообще своей отдельной жизнью живет в своих приоритетных тредах, мы просто кидаем туда меседжи с настройками и номером фрейма, чтобы засинхронизировать это с картинкой. Это сложно, но решаемо, но звук не привязан к картинке.

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

Замечания о математике, алгоритмах и методах, применяемых при компьютерной симуляции флюидов (например, огня и дыма) в режиме реального времени.

Исходный код к этой статье выложен на GitHub.

Огонь как явление очень интересен с точки зрения компьютерной графики. Раньше огонь было принято имитировать. Например, в фильме «Властелин колец» Питера Джексона для изображения огня использовались спрайты с огромным количеством дыма (на тот момент симуляция флюидов обходилась слишком дорого, даже при бюджете блокбастера). Когда требовалось моделировать огонь в режиме реального времени, например, в видеоиграх, использовались почти исключительно нефизические подходы.

Всем привет! Эта статья - про очень простой алгоритм маскирования данных при пересылке по протоколу WebSocket. Но рассказать я хочу не про сам алгоритм, а про путь оптимизации, который я прошел, чтобы сделать его эффективным. Я до сих пор уверен, что можно еще лучше и если так, то надеюсь уважаемые читатели мне подскажут! Приступим...

Прототип Scribe

Мировая статистика говорит, что английским владеет примерно 1,4 миллиарда человек, но носителей среди них всего 380 миллионов. То есть статистически семь из десяти читателей англоязычной документации — не носители языка.

Если мы хотим, чтобы наша английская документация хорошо выполняла свою функцию — эффективно доносила знания о продукте до читателя — мы должны предъявить к ней уникальное требование, которое обычно не предъявляем к документации на русском:

Документация должна быть написана так, чтобы даже тот, кто плохо знает язык, мог ей воспользоваться.

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

Асинхронность... Как много в слове этом! Асинхронность считается одной из сложных тем программирования вообще. Не все просто в этом вопросе. В интернете периодически появляются различные статьи, туториалы по тем или иным вопросам асинхронности. Из последнего дельной статьей я считаю вот этот материал. Собственно, эта статья и послужила последней каплей, переполнившей моё терпение. Мною сделана попытка взглянуть на асинхронность, проблемы и сложности, связанные с ней, совершенно под другим углом. Выводы, я бы сказал, напрашиваются весьма радикальные. Итак, поехали!

Метод конечных элементов (МКЭ) применяют в задачах упругости, теплопередачи, гидродинамики — всюду, где нужно как-то дискретизировать и решить уравнения сплошной среды или поля. На Хабре было множество статей с красивыми картинками о том, в каких отраслях и с помощью каких программ этот метод приносит пользу. Однако мало кто пытался объяснить МКЭ от самых основ, с простенькой учебной реализацией, желательно без упоминания частных производных через каждое слово.

Мы напишем МКЭ для расчёта упругой двумерной пластины на прочность и жёсткость. Код займёт 1200 строк. Туда войдёт всё: интерактивный редактор, разбиение модели на треугольные элементы, вычисление напряжений и деформаций, визуализация результата. Ни одна часть алгоритма не спрячется от нас в недрах MATLAB или NumPy. Код будет ужасно неоптимальным, но максимально ясным.

Размышление над задачей и написание кода заняли у меня неделю. Будь у меня перед глазами такая статья, как эта, — справился бы быстрее. У меня её не было. Зато теперь она есть у вас.

Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software, и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО.

Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков, а простые продукты импортируют 1600 зависимостей неизвестного происхождения. Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно.

В этом посте я сделаю краткий обзор ужасного уровня безопасности современного ПО, а затем порассуждаю о том, почему он настолько плох. Также я упомяну нормативные/юридические аспекты, которые могли бы снова сделать качество ПО приоритетным. Наконец, я расскажу о написанном мной полезном ПО , позволяющем доказать, что сегодня по-прежнему можно разрабатывать минималистичное и простое ПО, остающееся современным.

Надеюсь, этот пост станет моральной поддержкой для страдающих программистов и технологов, стремящихся улучшить ситуацию. Дело не только в вас, и мы не просто страдаем от ностальгии: ПО сегодня действительно очень странное.

Технологии разработки развиваются, но качество приложений по-прежнему оставляет желать лучшего. Почему?

Кто у нас там насегодня за главного? Денис? Алексей?

Давайте поговорим по-честному. Мы все прекрасно понимаем, что СММ и генеративный контент сводят Хабру в могилу. Я не люблю просто блеять о проблемах, и хотел бы предложить решение. Давайте сделаем что-то, чтобы разобраться с раком, убивающим Хабру.

Редкая птица долетит до середины Днепра, не каждый разработчик осилит все паттерны в WL. Нет ему равных языков в паттерн-матчинге. Чуден и необычен язык этот. Изобилует он точками, подчеркиваниями, да запятыми так, что в глазах рябит, да разум мутнеет.

В этой статье я постараюсь сделать как можно более подробный обзор на механизм сопоставления с образцом в Wolfram Language (WL) и покажу реальные примеры, где я сам и мои товарищи его активно используют. А также я поделюсь всеми неочевидными тонкостями работы с шаблонами, с которыми лично я столкнулся в процессе написания кода на WL. По возможности я буду приводить примеры на других языках программирования - на Python и C#. Это позволит всем, кто не знаком с WL лучше понять код и сравнить синтаксис.

Продолжая тему самодельного простого интерфейса https://habr.com/ru/articles/769986/ , как всегда, интереса ради и просто так, разработал концепцию сети на описанном ранее протоколе нижнего уровня. Представленная сеть, может быть пригодна для связи между несколькими ПЛИС внутри печатной платы (ПП); связи между ПП внутри блока, а также связи отдельных блоков с длиной линии передачи между узлами сети до 50м, а может и более.