Ненормальное программирование *

Поговорим о том кто такие Python-разработчики, чем они занимаются и как ими вообще стать? В этой статье будет информация о...

В интернете много статей о том, как создавать простых bash-телеграм ботов. Часто это сводиться к вечному циклу, который раз в несколько секунд дергает tg-api. А что, если у меня хотелок больше чем может предоставить такое решение?

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

Это история, о попытке поизвращаться создать небольшой, но удобный инструмент для написания ботов, удовлетворяющих моим требованиям.

Статья о том, как я во время каникул писал-писал язык для описания конфигураций, да и переборщил с объёмом

В 2019 году я ступил на путь разработки электроники. Моим первым устройством является Орнамент-8. Не судите строго.

- Орнамент-8 это устройство, способное реализовывать сложные конечные автоматы.
- Переход конечного автомата из одного состояния в другое определяется патчем, соединением входов и выходов ячеек Орнамента.
- Каждая из 8 ячеек Орнамента представляет собой моновибратор.
- Если моновибратор запустить, он будет удерживать высокое состояние в течение периода времени, задаваемого потенциометром TIME.
- В момент перехода моновибратора (далее ячейка) из высокого состояния в низкое происходит генерация триггера.
- Этот триггер способен запустить любую другую ячейку Орнамента, кроме самой себя. Для этого необходимо соединить тригерный выход с тригерным входом.
- Если триггер приходит на вход уже активной ячейки, он не поглощается, а поступает на тригерный выход PASS>. Этот выход реализует логику: если ячейка активна -> пусть триггер активирует другие ячейки.
- Помимо тригерных входов и выходов каждая ячейка имеет аналоговый выход, сигнал на котором пропорционален времени активации ячейки от 0 до 1 в зависимости от параметра TIME. Если моновибратор сравнить с наполняющимся сосудом, то аналоговый выход (CV>) показывает уровень жидкости в этом сосуде.
- Каждая ячейка имеет вход для управляющего напряжения (>CV). Приложенное к этому входу напряжение управляет коэффициентом, увеличивающим значение параметра TIME установленного потенциоментром. Приложение управляющего напряжения к >CV можно представить как растяжение времени в системе координат ячейки.

Кажется, что Орнамент-8 это какой-то странный артефакт, упавший из космоса. Зачем он нужен? Что с ним делать? Кто и почему придумал такую странную систему правил?

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

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

После того как я собрал систему на самом первом процессоре от Intel (4004), логичным, в каком-то смысле, шагом было перейти к Intel 8008. Концепция проекта та же - компилируем ассемблерный код на обычном ПК, отправляем скомпилированный бинарник на системную плату через USB, а современный микроконтроллер (stm32) эмулирует ПЗУ и ОЗУ для реального 50-летнего процессора, вставленного в DIP-сокет.

Вполне возможно собрать систему на аутентичных микросхемах, но такое решение проигрывает в удобстве использования - вместо запуска одной команды на ПК нужно будет постоянно перепрограммировать ПЗУ. Да и для меня основной интерес представляет сам процессор, а не его обвязка.

Так же как и в случае с 4004, моя плата эмулирует максимально возможный объем памяти, который нативно адресуется процессором. В данном случае, это 16Кб с некоторыми нюансами (об этом отдельно расскажу ниже).

И, конечно же, было занятно сравнить 4004 и 8008 в небольшой нишевой задачке. Да, сравнение весьма условное и какие-либо выводы по нему сделать сложно, но всё равно результаты вышли интересными.

Стоим мы как-то раз в курилке с коллегами, обсуждаем новый полис в GOAP и планируем расход задач на неделю, пару тасок решили кинуть в обезьянку, две ноды вернуть из ада депрекейта и настроить для работы с новым бт, а одну вернуть мастеру - пусть сам свои фланкинги ковыряет, раз уж он их и заимплементил, а еще две сжечь, а еще надо выделить время, чтобы покопать TSA, потому что новый GD сломал пару вейтов, и теперь хуман ходит не в тот ковер. Еще одну придется собирать из г..на и палок частей других нод, потому что дизайнеру нужно вчера, а времени на инвестигейт нет, покрасим её в фиолетовый, чтобы в билд не пробралась. А программеры с соседнего проекта, не аишные, смотрят на нас круглыми глазами и иногда посмеиваются. И вот я сажусь заполнять таски в jira, и понимаю чему удивлялись мои коллеги, потому что придется все эти короткие термины разжевать в таске. Давайте я дам названия терминов, а вы их попробуете объяснить сами, до раскрытия спойлера? Интересный должен игродевовский квиз получиться :) КДПВ просто прикольная, C++ тут нет.

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

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

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

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

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

Продолжаем разговор об игрушечном компиляторе мной придуманного простейшего языка wend. На этот раз мы добрались до определённой вехи: наконец-то будем генерировать не питоновский код, а ассемблерный.

Ну а когда оно заработает, предлагаю решить задачу: как сэмулировать побитовые операции and-not-xor-or при помощи четырёх арифметических.

Среди многочисленных демосценерских конкурсов, которые традиционно входят в программу различных demo party, незаслуженно недооценённым, на мой взгляд, является конкурс процедурной графики (procedural graphics). Смысл этого специфического вида компьютерного творчества — формирование статичного изображения при помощи короткой программы. Стандартные ограничения на размер — 4кб, 1кб, 256 байт.

Связана недооценка, думаю, с тем, что конкурс одновременно не вполне понятен как тем, кто любит демки (поскольку процедурная графика статична), так и тем, кто любит картинки (т.к. процедурная графика не позволяет нарисовать что хочешь). И всё же, его популярность хоть и медленно, но растёт.

Первые работы во многом были вызваны интересом к теме трассировки лучей (raytracing). Сам по себе алгоритм довольно простой, но требует много вычислений, поэтому работы стали возможны, когда распространились компьютеры с, во‑первых, достаточно высокой производительностью и, во‑вторых, с достаточным количеством отображаемых цветов (или, хотя бы, градаций серого). Я порылся на pouet и нашёл одну из первых работ в категории «procedural graphics» — Digital Phantasy by EG:

Приветствую всех!

Сегодня я вам представлю свои наработки по способу инжекта 64-битных DLL библиотек в процессы WOW64, сам который считал невозможным. Любителей потрогать внутренности Windows приглашаю под кат.

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

Как и зачем я это сделал, и как дошёл до жизни такой, я поведаю в этой статье.

Внимание, в статье есть много скриншотов!

Для наилучшего восприятия выделим основные пункты изложенного материала:

1.    Для чего необходимо сжатие информации и увеличение плотности записи.
2.    Проблемы в покорение хаоса, нерешенные математиками и ими же созданные.
3.    Простое решение проблемы сжатия абсолютно любого бинарного кода.
4.    Пути и методы дальнейшего развития сжатия бинарного кода.

Мне тут на днях попеняли, что, мол, я не в курсе, "что из esm до сих пор нельзя собрать бандл без транспиляции". Ну что я могу сказать... я действительно не в курсе :) На мой взгляд, es-модули придумали как раз для того, чтобы загружать по мере необходимости JS-код непосредственно в браузер, и собирать модули в бандлы - это, ну... как гладить кошку против шерсти.

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