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

Здесь я хочу поделиться «прохождением» этой «игры», под названием Демка для ПЭВМ «Микроша». В процессе чтения статьи может показаться, что всё просто и очевидно. Это всё так, когда есть документация и описание всех подводных камней. Когда каждый подводный камень ищешь сам, то это всё превращается в невероятно сложный квест.

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

Правила игры

Для того Чтобы вписать всё в некоторые рамки, для себя определил правила игры. Прежде чем я о них расскажу, для начала надо дать представление об особенностях ПЭВМ «Микроша».

В «Микроше» установлен микропроцессор КР580ВМ80А, работающий на тактовой частоте 1,77 МГц, быстродействие которого составляет всего 300 тыс. оп/с (грубо 300 кГц!). Это достаточно мало даже для тех лет. Например, первый микроконтроллер AVR AT90S1200 просто мейнфрейм в сравнении с этим процессором (хотя рассматривать их в одной линейке не совсем корректно). У него хотя бы каждая операция выполнялась за один такт, была команда умножения и таймер генерировал прерывания. Однако, это возлагает на меня дополнительную ответственность за то, чтобы код должен быть оптимальным и быстрым, чтобы успевать работать с этой скоростью.

Оперативной памяти всего 32 килобайта, в которую нужно втиснуть и код и данные. Как оказалось впоследствии, 32 кБ — это очень и очень мало.

Формат изображения: при отображении алфавитно-цифровой информации — 25 строк по 64 символа в каждой, при выводе псевдографической информации — 128 точек по горизонтали и 50 точек по вертикали. Плюс-минус строка снизу и сверху, необходимо всё уместить в этом объёме. При этом градаций цвета не предусмотрено. Изображение выводится на ЭЛТ монитор, и не всегда возможно вывести всё что ты хочешь, например, сплошная заливка белым — не работает.

Звук представляет собой программируемый один канал таймера КР580ВИ53. Таким образом можно играть мелодию по одной ноте, как новичок, играя одним пальцем. Никаких аккордов или одновременных нот.

Резюмируя, демка должна быть загружена с аудиокассеты и воспроизводиться именно на отечественном ЭЛТ-мониторе. Никаких аппаратных доработок в ПЭВМ вводить нельзя (ни расширять память, ни добавлять аудиоканалов, ни добавлять цветов). Хотя всё это, без сомнения, хотелось попробовать сделать. Но таковы были внесённые ограничения, которые определяли правила разработки.

Из бонусов, которые я себе позволил: разработка может вестись на обычном ПК, используя любые языки программирования, любые эмуляторы и технические решения, но так чтобы конечная программа работала уже на «Микроше».

Основной источник знаний

Что удивительно, основным источником сакральных знаний по программированию «Микроши» стала его документация. Этим может похвастаться не каждый отечественный ПЭВМ. Документация очень хорошо написана, приведено множество примеров, каждый из которых можно применить на практике.

Книжечка оказалась так мной зачитана, что пришлось даже делать ей ремонт и покупать обложку.

С чего же начать?

Опыта разработки демок у меня не было от слова совсем как и более-менее вменяемого опыта разработки для ЭВМ на базе процессора i8080 (игры с «Волшебным чемоданом» не в счёт). Поэтому начал искать информацию, кто же делал аналогичные проекты, хотя бы для «Радио-86РК», и в результате наткнулся на статью «Псевдо 3D-демо для Радио-86РК«. Публикация оказалась весьма полезной и определила дальнейший вектор моей разработки.

Изначально планировал написать письмо её создателю с вопросами о том, как же всё работает, но по ходу быстро разобрался сам и даже набросал на питоне свой конвертер картинок из pgm-файлов для получения растрового изображения. В результате у меня получилась вот такая демка:

На видео видно, что используется либо пустой, либо закрашенный символ, при этом псевдографика не используется вовсе. Сперва, я даже начал дорабатывать эту демку, чтобы добавить полную поддержку псевдографики, так чтобы изображение было не 64х25, а 128х50 точек. Но, в какой-то момент понял, что эту демку уже кто-то писал, уже кто-то делал. При этом я был уже далеко не первым, кто мучает данное решение, и мне стало скучно. Решил, что пускай не мой код не будет шедевром демостроя, однако реализую всё так, как умею, с теми эффектами, которые понял и осознал сам, плюс заодно чему-то смогу научиться. И, оглядываясь назад, это было единственно правильным решением, хотя путь оказался очень тернист.

Принял решение сделать по такому сценарию:

1. Начальная сцена, приветствия хабра. Начинает играть музыка.
2. Смена кадра, некоторая анимация, которая переводит к следующей сцене.
3. Какая-то простая псевдо-3D сценка, которая отображает логотип компании.

По графике: решил использовать псевдографику 128х50 точек (на деле оказалось больше, подробности ниже), которая рисуется из символов. Для отображения 3D сцены решил использовать методику разницы фреймов, идею которой позаимствовал в первой демке у begoon. Хотя, конечно, круто было бы всё обсчитывать в рельном времени. Однако, посмотрев как «быстро» работает расчёт синусов в реализации в исходной демке (ввести g и нажать Enter), отказался от этой затеи — это всё очень медленно. Поэтому пускай не очень элегантно, но решение оказалось вполне рабочим.

Предварительная подготовка

Как вы уже помните по предыдущим моим публикациям (например), для сборки я использую транслятор zasm, на выходе которого получается rom-файл. Но для того чтобы его загрузить либо в эмулятор, либо на сам ПЭВМ «Микроша», необходимо его преобразовать в формат RKM. Описание формата нашёл на этой веб-странице:

В моём случае начальный адрес был равен нулю, конечный адрес файла в памяти — это размер выходного rom-файла. Данные файла — это собственно говоря содержимое самого rom-файла. Самое сложное было разобраться, как производить расчёт контрольной суммы. Очень-очень долго искал код, как посчитать контрольную сумму для ПЭВМ «Микроша», ведь формула расчёта контрольной суммы для моего компьютера отличается от формулы расчёта для Радио-86РК. На помощь пришёл Вячеслав Славинский, который скинул код генерации звукового файла для различных платформ и там как раз был пример, посвящённый «Микроше». Осознав, что же там делается, реализовал свой вариант на си.

Если отбросить шелуху, то код, формирующий из rom-файла RKM выглядит следующим образом:

write_byte_to_file(file_out, 0); write_byte_to_file(file_out, 0); write_byte_to_file(file_out, (uint8_t)(filesize >> 8 & 0x00FF)); write_byte_to_file(file_out, (uint8_t)(0x00FF & filesize)); while  ( ( x = fgetc( file ) ) != EOF ) { write_byte_to_file(file_out, (uint8_t)(0x00FF & x)); if (i++ % 2 == 0) { csm_lo ^= (uint32_t)0x00FF & x; } else { csm_hi ^= (uint32_t)0x00FF & x; } } write_byte_to_file(file_out, csm_hi); write_byte_to_file(file_out, csm_lo);

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

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

Скорее всего я изобрёл велосипед, который уже давно есть, но мне это тоже было полезно и интересно понять и разобраться. Обращаю внимание, как я уже сказал, алгоритм расчёта контрольной суммы для «Микроши» и «Радио-86РК» различается!

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

Заставка демо

После того как я научился конвертировать rom-файлы в rkm, захотелось сразу сделать что-то прикольное и красивое. Простейший хелло-ворд было понятно как написать, поэтому нужно что-то масштабное.

В «Руководстве пользователя» на «Микрошу» есть такой замечательный пример:

Он слишком прост, примитивен и не интересен. Хотелось сделать что-то этакое.

И тут я вспомнил про такой жанр, как ASCII-арт. Пошёл на сайт patorjk.com и начал подбирать наиболее подходящий вариант.

Мне понравилось, что тут использованы unicode-символы, которые аналогичны имеющимся в микроше: полный блок, верхний полублок, нижний полублок. И уже можно как-то проверить возможности псевдографики. Сохраняю всё это в текстовый файл и начинаю думать, как его конвертировать в формат «Микроши». Для начала создал файл ruvds.txt содержит просто скопированный текст с этими символами.

Содержимое текстового файла.

Для конвертации в формат «Микроши» набросал небольшую программу, на си. Планирую выводить как текст: вызовом функции программы «Монитор».

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

#include <stdio.h> #include <stdlib.h> #include <wchar.h> #include <errno.h> #include <locale.h>   int main(void) { setlocale(LC_ALL, "en_US.utf8"); FILE *fp = fp = fopen("ruvds.txt", "r"); if(!fp) { perror("Can't open file for reading"); return EXIT_FAILURE; } wint_t wc; errno = 0; while ((wc = fgetwc(fp)) != WEOF) { //putwchar(wc); switch (wc) { case L'▄': //0x14 //putchar('_'); printf("14h, "); break; case L'▀': //0x03 //putchar('-'); printf("03h, "); break; case L'█': //0x17 //putchar('*'); printf("17h, "); break; case L' ': //putchar(' '); printf("' ', "); break; case L'\n': printf("0dh, 0ah\n\tdb "); } } printf("0dh, 0ah, 7, 0"); fclose(fp); return 0; }

После компиляции, в результате выполнения получим вот такую петрушку:

0x0D — это просто символ возврата каретки ака '\r', а 0x0A — символ перевода строки ака '\n'.

Далее можно набросать простейшую программу, для вывода на экран. Она проста как валенок:

puts    equ 0F818h org 0 lxi h, msg call puts loop: jmp loop

Загружаем в регистр h расположение сообщения и вызываем подпрограмму системного монитора для вывода на экран. Само сообщение начинается с символа 0x1F — он очищает экран и помещает курсор в нулевую позицию. Далее идёт текст сообщения, и как в си, строка должна заканчиваться нулём.

Пример загружаемого сообщения msg

msg: db 1fh, 0dh, 0ah db ' ', ' ', ' ', 14h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 14h, ' ', ' ', ' ', 14h, 17h, ' ', ' ', ' ', ' ', 17h, 14h, ' ', ' ', 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 14h, ' ', ' ', ' ', ' ', ' ', 14h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 0dh, 0ah db ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', 03h, 17h, 17h, 17h, ' ', ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, 0dh, 0ah db ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 03h, ' ', 0dh, 0ah db ' ', 14h, 17h, 17h, 17h, 14h, 14h, 14h, 14h, 17h, 17h, 03h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', ' ', ' ', ' ', 0dh, 0ah db 03h, 03h, 17h, 17h, 17h, 03h, 03h, 03h, 03h, 03h, ' ', ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 03h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 0dh, 0ah db 03h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', 17h, 17h, 17h, 0dh, 0ah db ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, ' ', ' ', ' ', 14h, 17h, 17h, 17h, ' ', ' ', ' ', ' ', 14h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, 0dh, 0ah db ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 03h, ' ', ' ', ' ', 03h, 17h, 17h, 17h, 17h, 17h, 17h, 03h, ' ', ' ', 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 03h, ' ', ' ', ' ', 14h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 17h, 03h, ' ', 0dh, 0ah db ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', 17h, 17h, 17h, ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', 0dh, 0ah db 0dh, 0ah, 0dh, 0ah db "demka specialxno dlq HABR", 0dh, 0ah db "ideq i realizaciq DLINYJ", 0dh, 0ah, 0dh, 0ah db 0dh, 0ah, 0dh, 0ah, 0dh, 0ah, 0dh, 0ah db 0dh, 0ah, 0dh, 0ah, 0dh, 0ah,0dh, 0ah, 0dh db "bolx{aq blagodarnostx MAN OF LETTERS", 0dh, 0ah db 0

Далее собираем программу zasm, конвертируем ранее написанным конвертером в формат RKM.

zasm --asm8080 ruvds.asm && convert_rkm ruvds.rom

Ну а теперь можно попробовать, как же это выглядит, пускай хотя бы на эмуляторе.

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

В реальном железе, тоже всё работает отлично. К сожалению, монитор «Электроника» оказался подсевшим и с дрожащим изображением, но на нём всё вполне нормально работает.

Тест на реальном железе.

Символы псевдографики «Микроши»

Как можно вспомнить, ПЭВМ использует псевдографику, для вывода изображений на экран. В «Руководстве пользователя» в самом начале есть табличка соответствия символов псевдографики.

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

Внимательный читатель может обратить внимание, что одного символа не хватает (кого я обманываю, кто внимательно читает статьи). А именно символа '▜'. При этом как я не пыжился вывести через программу «Монитор» мне этого сделать не удалось. И в «Руководстве пользователя» его нет. Так, что-то тут не чисто, обещают все символы, но его вывести нельзя что ли?

В интернете гуляет другая картинка, с демонстрацией символов ПЭВМ.

И там, на седьмой позиции присутствует этот символ. Но согласно документации 0x07 — это вывод звукового сигнала.

Как оказалось, есть другой способ отображения информации, более быстрый, минуя программу «Монитор» — это запись непосредственно в видеопамять и тогда всё будет работать. И когда начал писать в видеопамять, то данный символ с успехом отображается! На поиск ответа куда подевался символ, я потратил несколько дней.

Пару слов об устройстве видеопамяти

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

Видеопамять располагается по адресам 0x76D0-0x7FFF в оперативной памяти ПЭВМ, и занимает 2352 байта. Расположение этой области памяти определяется настройками контроллера прямого доступа к памяти (ПДП) КР580ВТ57, который считывает эту область памяти и передаёт данные в контроллер дисплея КР580ВГ75, который, в свою очередь, берёт соответствующее изображение символа из своего ПЗУ и отображает его на экране. В этой демке контроллер ПДП мне конфигурировать не пришлось (хотя я представляю как), и адреса и размер видеопамяти остаётся прежним.

Таким образом, просто записываем данные в область памяти, и получаем отображение их на дисплее. Но есть один нюанс, если внимательно почитать документацию, спеки на ПЭВМ, то везде пишут, что количество выводимых символов у «Микроши» 64х25 или общее 1600 штук, а память имеет размер 2352 байта, как это? Обратимся к документации.

Тут открывается очень тонкий момент, что фактически реальный размер экрана составляет 78х30 символов. Только первые три строки у нас должны быть чёрными, и с каждой стороны по 7 символов должны быть чёрными, и снизу 2 строки должны быть чёрными.

Схема разбивки памяти для размещения изображения.

Такая странная структура имеет свой смысл, как мне поведали в чате «Ретрокомпьютеров«, то это связано с особенностями микросхемы видеовыхода КР580ВГ75. Данная микросхема не генерирует синхроимпульсов, и формально этим должна заниматься внешняя схема. В ПЭВМ «Микроша» такой схемы нет, и микросхема ВГ75 настраивается таким образом, чтобы формировать эту «рамку» за экраном. В отсутствии синхроимпульсов телевизор воспринимает её, как синхроимпульс (хотя последний должен быть «чернее чёрного», видимо, цепляется за перепад «белое-черное»).

Тут есть главный вопрос, у нас есть поле размером 70х30, вместо поля 64х25, возможно ли использовать его? Оказалось возможно, правда не все мониторы его отображают целиком, но вполне. С некоторыми особенностями. Например, нельзя заливать всё целиком белым цветом, или хотя бы половину. Надо следить, чтобы хотя бы на половине строк была чёрная рамка. Но сей грязный хак с успехом у себя провернул. Хотя впоследствии и пособирал граблей.

Итого, получается, если с псевдографикой, то поле для рисования выходит 140х60 пикселей, уже можно даже жить! Разумеется, по краям, в особенности по углам, из-за особенностей ЭЛТ-мониторов не всё будет видно, но всё равно это веселее.

Основная анимация

▍ Теория

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

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

Когда я поставил себе эту задачу, то моя тетрадка начала обрастать кучей треугольников с формулами, как же это реализовать и пересчитать. В результате получилось следующая вариация, после того как смог себе это всё представить.
У нас есть три оси: X, Y, Z:

• Ось Z — виртуальная, она направлена к зрителю от монитора, с ней и будет основная магия.
• Ось X — это горизонтальная ось, столбцы, направлена как обычно слева направо.
• Ось Y — это строки, растёт она из левого верхнего угла монитора вниз.

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

Пример эффекта вращения.

Если мы поворачиваем относительно оси Y, то координаты оси Y у нас не меняются, необходимо только каждый раз рассчитывать новую координату X’. При этом нужно помнить, что если в одну и ту же точку попадает и чёрная и белая точка, то мы её окрашиваем в белый цвет. Таким образом, когда угол ɑ = 90 , то мы должны получить на выходе сплошную белую линию, размером в 1 пиксель.
Формула пересчёта координаты X’ достаточно простая.

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

▍ Конвертер

Идею конвертера позаимствовал у begoon. Поскольку необходимо конвертировать в символы псевдографики, то я сделал полный холст, равный виртуальному разрешению. Один константный холст содержит картинку, которую мы будем вращать. Другой полный холст содержит картинку, на которую будет производиться пересчёт в зависимости от угла. Размеры холстов соответственно:

#define SCREEN_WIDTH 156 #define SCREEN_HEIGHT 60

В качестве светящегося белого пикселя в массиве типа char у меня применён символ 'X', а в качестве чёрного — пробел.

Далее два других холста, на которые будет уже идти конвертация в символы псевдографики, и уже с ними будет идти основная обработка: будет вычисляться изменения между холстами (diff), и они будут сохраняться в ассемблеровский файл (по какому адресу памяти, какой символ изменился). Размеры этих холстов соответственно:

#define M_SCREEN_WIDTH 78 #define M_SCREEN_HEIGHT 30

Чтобы каждый раз не запускать симулятор «Микроши», или вообще сам ПЭВМ, набросал небольшой эмулятор дисплея, на который выводил результат в псевдографике. Вообще, каждый уважающий себя демосценер пишет свой эмулятор — это правило (сарказм). Для этого заморочился и подобрал символы unicode, которые соответствуют символам на ПЭВМ «Микроша» Получилось 15 символов (16 — пробел):

'▘', '▝', '▀', '▗', '▚', '▐', '▜', '▖', '▌', '▞', '▛', '▄', '▙', '▟', '█'

Принцип отрисовки достаточно прост, с помощью ESC-последовательностей очищаю экран и далее в зависимости от расположения в двумерном массиве 'X' и ' ', выбираю подходящий символ.

#define ESC "\033" #define home() printf(ESC "[H") #define clrscr()printf(ESC "[2J")  ... void print_image(char ** image) { int i, j; home(); clrscr(); for (i = 0; i < SCREEN_HEIGHT; i+=2) { for (j =0; j < SCREEN_WIDTH; j+=2) { if ((image[i][j]   == 'X') && (image[i][j+1]   == ' ') && \ (image[i+1][j] == ' ') && (image[i+1][j+1] == ' ')){ printf("%lc", TOP_LEFT_POINT); }  if ((image[i][j]   == ' ') && (image[i][j+1]   == 'X') && \ (image[i+1][j] == ' ') && (image[i+1][j+1] == ' ')){ printf("%lc", TOP_RIGHT_POINT); } ... } putchar('\n'); } }

Аналогичный код конвертации в холст с псевдосимволами, только #define соответствует символу на «Микроше».

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

#define Y1 (SCREEN_HEIGHT/2) #define X1 (SCREEN_WIDTH/2) void line (char ** canvas, double degree_axix_of_rotation) { double k = tan((180.0 - degree_axix_of_rotation) * M_PI / 180.0); if ((degree_axix_of_rotation > 45.0)  && (degree_axix_of_rotation < 135.0)) { for (int y = 0; y < SCREEN_HEIGHT; y++) { int x = (int)((y - Y1)/k + X1 + 0.5); if ((x >= 0) && (x <= SCREEN_WIDTH)) { canvas[y][x] = 'X'; } } } if ((degree_axix_of_rotation <= 45.0) || (degree_axix_of_rotation >= 135.0)){ for (int x = 0; x < SCREEN_WIDTH; x++) { int y = (int)(k * (x - X1) + Y1 + 0.5); if ((y >= 0) && (y <= SCREEN_HEIGHT)) { canvas[y][x] = 'X'; } }s }  }

Если рисовать линию с шагом 3 градуса, предыдущую линию не стирать, то получится вот такая вот красота.

Функция вращения картинки ещё проще, чем функция рисования вращающейся линии.

void rotate(char ** image, char ** canvas, double r_degree) { for (int y = 0; y < SCREEN_HEIGHT; y++) { for (int x = 0; x < SCREEN_WIDTH; x++) { int xnew = (int)((X1 - x) * cos ((180 -r_degree) * M_PI / 180.0) + X1 + 0.5); if (canvas[y][xnew] != 'X') { canvas[y][xnew] = image[y][x]; } } } }

Формула применена та же, просто добавлено округление. image — это указатель на исходную картинку, canvas — на выходной холст, и градус поворота. В результате, на ПК у меня получилось очень реалистичное вращение, если вращать с шагом 1 градус. Пардон за артефакты съёмки.

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

zasm --asm8080 microsha_demo.asm   in file frames.asm: 88:      ^ segment  size out of range: 0 assembled file: microsha_demo.asm     90996 lines, 1 pass, 0.4046 sec.     1 error

Проще говоря: программа не лезет в 64 кБ, то есть, бесконечных мультиков смотреть не получиться. И придётся даже такую простенькую анимацию оптимизировать, чтобы уместить со всеми хотелками в оперативной памяти. При этом в моём случае они не влезли аж в 64к адресуемой памяти, а в ПЭВМ «Микроша» всего 32 килобайта!

Заключение первой части

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

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

P/s — кликабельная картинка из шапки

Защита критической инфраструктуры — скучная бумажная безопасность, офисная работа. Это распространенный стереотип, который верен лишь отчасти. Перед подготовкой документов инфраструктуру обследуют. И все бы ничего, но иногда предприятие находится где-нибудь между Сургутом и Нижневартовском.

Бастион специализируется на безопасности АСУ ТП, так что за свою карьеру я побывал на многих промышленных производствах. Сегодня расскажу, как проводятся такие обследования, с какими сложностями связаны, и какие проблемы обнаруживаются на объектах.

Основная задача на начальном этапе — обследовать объект и выявить недостатки. Конечно, многое понимаешь из документов, но далеко не все. Ситуация на бумаге и на предприятии может обстоять по-разному, поэтому приходится собирать команду и ехать в командировку.

Обычно на производство выезжает команда из трех человек, которые делят обязанности. Один сотрудник обследует сетевую инфраструктуру, второй смотрит сервера и АРМы и снимает с них информацию. Третий — берет интервью у технических специалистов и разбирается, как они действуют в тех или иных ситуациях.

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

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

О предприятиях и том, как попасть на территорию

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

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

Получение допуска на производство — отдельное мероприятие.

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

• Каждый раз приходится оформлять уйму бумаг и проходить досмотр: оставлять личную технику и переписывать серийные номера с рабочей.

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

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

И вот ты расхаживаешь по предприятию в килограммовых ботинках, а ходить приходится много и долго. Обследование с двух десятков установок АСУ ТП может длиться до трех недель.

Нефтяные заводы неплохо автоматизированы. Электроника там делится на три уровня. Нижний — полевой уровень, он включает в себя всевозможные датчики и контрольно-измерительные приборы. Информация с них передается на средний уровень — на программируемые контроллеры. Верхний уровень, уровень операторов — это сервера и автоматизированные рабочие места, те самые АРМы.

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

Большая часть сетевого оборудования находится в серверной и на операторских станциях в цехах. Там же установлены АРМы, а контроллеры разбросаны по узловым точкам предприятия. Чтобы быстрее найти и обойти все необходимое, мы берем в качестве провожатых местных инженеров, специалистов по АСУ ТП, безопасников и разделяемся.

Обследование сетевого оборудования

Один из нас отправляется осматривать сетевое оборудование. Его задача —  актуализировать карту сети, проверить как настроены коммутаторы и межсетевые экраны, проверить изолирована ли сеть. В идеале сеть АСУ ТП не может взаимодействовать с корпоративной и даже не должна физически выходить за пределы предприятия.

Конечно, первым делом мы запрашиваем схемы инфраструктуры объекта, на которых отражена структура АСУ ТП, но эти документы не всегда вовремя обновляются.

Приходишь в серверную и видишь, что из коммутатора торчат лишние провода. Спрашиваешь: «Что это?»

— Ну это с другой… мы используем этот коммутатор на две…

— Но на схеме же не обозначено!

— Так и не будет обозначено. Это новый… Мы просто сюда воткнули.

И ты такой: «Ну понятно…». И идешь искать, куда тянется эта витая пара.

О том, где находится железо, стоит поговорить отдельно. Иногда серверные располагаются в зданиях 70–80-х годов постройки с аутентичными почти что антикварными шкафами, в которые набили современную технику. Не везде под оборудование выделяют отдельное помещение. Тогда операторская и серверная оказываются в одной комнате, разделенной тонкой перегородкой. Однако, в первую очередь мы обращаем внимание на то, есть ли там окна, оборудовано ли помещение кондиционированием, СКУД, видеонаблюдением.

Осмотр автоматизированных рабочих мест

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

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

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

Опрос сотрудников

Интереснее всего работать непосредственно с сотрудниками предприятия. Мы задаем им буквально сотни вопросов. Часть из них адресовано руководству:

• Ведет ли предприятие арбитражные споры?

• Имеются ли информация, которая может заинтересовать иностранные спецслужбы?

• Разрабатывают ли сотрудники прикладные программы?

• Кем осуществляется ремонт средств обработки информации?

• И так далее.

Руководство компании прямо заинтересовано в том, чтобы нам помочь, так что все это выясняется быстро, однако многие вещи можно узнать только «на местах»:

• Использует ли персонал флешки и прочие съемные носители информации? Кто имеет к ним доступ?

• Имеет ли доступ к средствам обработки информации обслуживающий персонал (уборщицы, техники и т. д.)?

• Присвоена ли каждому оператору АРМ персональная учетная запись?

• Действительно ли соблюдается парольная политика?

• Как действуют операторы в случае инцидента?

Большинство рядовых сотрудников охотно отвечает на вопросы, но изредка бывает и так, что посторонним не рады. Спрашиваешь про АСУ ТП, а оператор отвечает, что придет другой инженер — у него и спрашивайте, а я его заменяю и ничего не знаю.

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

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

Попадаются и просто очень тревожные специалисты.

А зачем вы это делаете? А что вы будете проверять? А что нам что-то будет за это? А нас за это лишат годовой премии? А если вы что-то обнаружите, вы будете писать про это в отчете? Может быть, мы с вами как-то договоримся?

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

Правда в том, что это необоснованное беспокойство. Мы не заинтересованы в том, чтобы писать кляузы и доносы. Допустим, Иванов Иван Иванович сидит на АРМ из-под администратора. Так нельзя делать, но мы не будем писать, что Иванов плохой. В результате, в отчете появится рекомендация — поменять пароли администратора на АРМах, убедиться, что их знает только администратор, который обслуживает эти машины. Все.

Подведение итогов

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

• Чаще всего встречаются проблемы с антивирусной защитой. Она либо отсутствует, либо не настроена, либо базы не обновляются.

• Распространены огрехи, связанные с учетными записями и паролями: сотрудники часто работают из-под администраторов или годами используют один и тот же пароль, компьютеры не блокируются при бездействии.

• Бывает так, что межсетевые экраны установлены, но не настроены и впустую переводят электричество. 

• Не всегда предусмотрены четкие процедуры реагирования и устранения последствий компьютерных инцидентов.

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

Это вопрос приоритетов. Немедленное устранение уязвимости в системе безопасности предприятия может означать большую потерю денег, чем инцидент.

Промышленные производства работают непрерывно и задержки в их работе обходятся очень дорого. Счет идет на миллионы рублей и, как правило, наверстать потери ударным трудом невозможно. Поэтому некоторые АСУ ТП до сих пор работают на базе Windows XP, которая не поддерживается и потому издали напоминает решето.

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

В таких случаях мы рекомендуем модернизировать АСУ ТП в следующее технологическое окно. Так или иначе, примерно раз в год на производстве начинается масштабное плановое техобслуживание оборудования. Тогда можно остановить систему, поменять датчики, перенастроить ПЛК. Это тот самый момент, когда можно заняться информационной безопасностью без влияния на работу технологических цепочек.

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

Когда мы рассказываем о релокейте, то обычно пишем про одну, максимум две-три страны. Сегодня у нас более необычная история — герой этой статьи Андрюс пришел в IT еще в конце 80-х, в 2009 уехал из Литвы в Швецию, и с тех пор успел поработать и подолгу пожить в половине европейских стран. Для нас он расскажет, чего примерно ждать от релокейта в ту или иную страну, и куда стоит переезжать, если ищешь карьерного роста, спокойной жизни или быстрой интеграции в общество. Передаем ему слово.

Немного обо мне: от телефонии в Литве до Швеции, Испании и всего остального мира

Моя дорога в IT началась еще в конце 80-х в СССР, когда самого понятия IT не существовало. Я учился в компьютерной школе и изучал языки программирования, закончил школу как раз в год распада СССР. Потом в 90-е поступил в ВУЗ учиться на программиста, но работать пошел в коммерческий сектор. А во второй половине 90-х заинтересовался и начал работать в новой на тот момент индустрии — интернет-телефонии.

В 97 году эта область была, как сейчас криптовалюты — хайповая, с супербыстрыми сумасшедшими доходами. Себестоимость минуты звонка была центов 5–15, а продавали ее от доллара и выше.

В те времена полноценных колл-центров еще не было, а решения для интернет-телефонии только зарождались. К концу 90-х я немного отошел от «железа» и стал писать софт для этих колл-центров. Тогда я пользовался Bash и Perl. Работал с Linux, который в то время был довольно кривой и очень уязвимый.

В 2006–2007 годах мне для работы понадобилось уже что-то посерьезнее. Я стал изучать Ruby, которым потом пользовался много лет. Он понравился мне больше, чем Python, за счет красивого синтаксиса и активного сообщества.

В тот момент я еще работал в Литве. В 2008 случился мировой финансовый кризис, предприятие, где я работал, собралось банкротиться, и я решил уезжать. Тем более что рынок в этой стране был очень маленький, и серьезной работы просто не было. С удаленкой тоже были сложности: индустрия только зарождалась, вакансий было крайне мало.

В итоге я уехал в Швецию, где очень долго работал в телекоммуникационной компании Bahnhof. В то время они хостили Викиликс, а хостинг их располагался в бывшем бункере военных сил Швеции. Выглядело колоритно:

В 2012 компания стала сокращать издержки, и мой контракт не продлили. Мне пришло приглашение из Испании, я переехал и стал заниматься тем же — разрабатывал решения для колл-центров, правда, уже в роли проектного менеджера. Так я проработал два года, а потом остался в Испании и стал работать оттуда удаленно во многих странах мира, периодически путешествуя в офисы — на тот момент полная удаленка еще не была популярна. Великобритания, Дания, Германия, Нидерланды, Бельгия — в этих странах я бывал подолгу. Заезжал в Канаду и США, а во скольких странах бывал в качестве туриста — не перечесть.

Почему мы долго жили в Испании и какие плюсы и минусы есть у этой страны

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

Про Испанию я могу рассказать много интересного:

Испания (как и Португалия) — страна довольно сонная. В стране много мигрантов из Латинской Америки, Марокко, пенсионеров из других стран Европы. А вот доходы тут не такие уж высокие. Поэтому я считаю страну прекрасной для жизни, только если вы работаете удаленно или у вас есть пассивный доход. Работать именно в Испании может быть не такой уж хорошей идеей. Возможным исключением может быть работа в IT-компаниях, где в основном говорят по-английски и культура работы не национальная.

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

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

Бизнес-активности довольно мало. Что-то есть в Барселоне и Мадриде, в индустрии телекома — еще и в Малаге.

Много русскоговорящих. Так было на момент нашего переезда в конце 2012, позже миграционный поток из России и Украины только рос. Также сейчас наблюдается крупная волна беженцев из Украины. Поэтому тут много русско-ориентированного бизнеса и услуг, что довольно удобно: легко найти врача, няню, парикмахера или даже школу. Плюс за счет этого в Испании легче найти качественный сервис — местные услуги часто худшего качества либо элементарно непривычны, в отличие от услуг от жителей стран бывшего СССР.

Климат на юге и правда чудесный. Если не дай бог наступают дождливые дни, ты тоскуешь уже на второй день. В Аликанте, где я жил, +14 °С зимой — уже холодно. Ну и, разумеется, пляж, море, солнце и пальмы. Природа тоже красивая — кроме моря есть еще и горы.

Здесь нет сверхдоходов, серьезного развития ИТ и какой-то особенно насыщенной культурной жизни, но в целом это хорошая приятная страна, в которой можно комфортно и недорого жить.

Куда податься IT-инженеру с большими амбициями

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

Мне самым удачным вариантом кажется Великобритания. Она сильно аффилирована с США, и культурный код здесь скорее как в Америке, чем как в Европе. Много крупных ИТ-компаний и стартапов, серьезные перспективы роста — здесь легко как начать карьеру, так и двигаться вверх, набирая опыт, связи и серьезные строчки в резюме. Плюс здесь можно неплохо зарабатывать.

Из нюансов — получить ВНЖ в Британии довольно непросто, если только ты не гражданин одной из стран Британского Содружества, либо ЕС. Россиянам придется поработать над миграционными документами. Поэтому для старта карьеры страна может не подойти — у опытного специалиста шансы все-таки получить рабочую визу выше.

Что не так с Германией как со страной для работы

Германия популярна у российских ИТ-инженеров потому, что активно выдает рабочие визы гражданам СНГ. Но по факту она уступает Великобритании — меньше развита цифровая экономика и далеко не так много стартапов.

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

Если сравнивать разные города, то мне больше всего по душе пришелся Берлин. Здесь более смешанная культура и выше шанс попасть не в такую «формализованную» компанию. Но если сотрудники в основном немцы, то ничего не поможет — культура работы будет все же немецкой.

Правда, у такого формализма есть и плюсы. Например, в Великобритании довольно много овертаймов, у них принято перерабатывать. А в Германии все строго по правилам: если сказано, что в неделе 40 рабочих часов, значит, будет 40.

Что важно понимать при частых переездах

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

Раньше адаптация у меня занимала много времени — особенно долго я привыкал к Испании, которая стала одной из моих первых «новых» стран. Я никак не мог смириться, что все очень медленно, а бюрократии гораздо больше, чем в Литве. Сейчас адаптация проходит уже за несколько недель, и я очень быстро принимаю любые особенности страны, в которую приезжаю.

Тут важно правильно себя настроить. Люди здесь живут так десятки, если не сотни лет, и ничего с этим не поделаешь. Нужно либо успокоиться и принять, либо собирать вещи и уезжать — мир вокруг не изменится от того, что вы будете недовольны.

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

Какие у меня планы на будущее

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

Сейчас я работаю в телекоммуникационной компании в Бельгии, и живу здесь же. Занимаюсь тем, что называют DevOps — почти не программирую, но помогаю с автоматизацией тестирования и доставкой кода на прод.

Планы на будущее у меня не определены. Документы для жизни в Бельгии я сделал, но вполне вероятно, что уже осенью мы отсюда уедем. Сюда мы перебрались, чтобы поддержать дочь — она поступила учиться в вуз в Нидерланды, это рядом, около часа езды. Сейчас видим, что она справляется — а значит, мы можем поехать куда-то еще. Точно не в Испанию, точно не в Литву, но куда конкретно — пока не решили.

P.S. Хотите свободы работать где хочется? Обязательно подключайте наш телеграм-бот. Задаете желаемую должность и зарплату, и к вам приходят вакансии от топовых компаний. Не нужно ни резюме, ни портфолио, настройка занимает меньше 30 секунд.

Привет, Хабр! Меня зовут Проскин Роман, я четыре года работаю с Tarantool — разрабатываю и эксплуатирую высоконагруженные и высоконадёжные приложения. Хочу рассказать о своем опыте в этой сфере, поделиться советами и подсветить ошибки, которые допускал в работе.

Кратко о том, что такое Tarantool

Обычно говорят, что Tarantool — это база данных и сервер приложений в одном флаконе. Я хочу немного скорректировать: Tarantool — это платформа для работы с вашими данными в оперативной памяти. Именно за счёт этого Tarantool такой быстрый. Мы недавно завезли поддержку ARM М1 на Apple и получили там 2 миллиона транзакций в секунду.

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

Внутреннее устройство Tarantool

Схематично оно выглядит следующим образом:

Здесь мы видим разные компоненты:

• Бинарный протокол iProto для работы с пользовательскими запросами.

• Event loop, где выполняется основная бизнес-логика приложения и работа с данными. 

• Arena — хранилище данных. В основном оно работает в оперативной памяти, но часть информации хранит на диске — снимки данных и журнал изменений, так называемый WAL-лог. 

• Relay. Этот компонент связан с репликацией данных, когда мы объединяем экземпляры Tarantool в наборы реплик и делаем копию наших данных. 

Важно понимать, что все экземпляры одинаковые. Ранее мы писали про Cartridge — это кластерное решение на Tarantool. То есть кластерным приложением называются наборы экземпляров; хоть они и одинаковые, но могут выполнять разную бизнес-логику. 

Развёртывание Tarantool

Подход к развёртыванию Tarantool отличается от Oracle: сначала мы разрабатываем приложение, тестируем и только потом развёртываем в прод. 

Вот пример: сначала мы получаем ТЗ на нашу задачу, разрабатываем и тестируем локально на MacBook:

Затем подключаем CI-системы: Jenkins, GitLab CI, Github actions. Потом проводим статический анализ кода, и после этого собираем и развёртываем в тестовые контуры. Там проверяем, например, интеграцию с внешними сервисами и работу с реальными данными: на случай, если условный Oracle пришлёт ерунду в JSON или вообще бинарные данные. 

После проверки мы подключаем мониторинг и запускаем нагрузку. Теперь смотрим, как наше приложение соответствует нефункциональным требованиям: отвечает ли оно нагрузке и SLA. И только после того, как точно удостоверились, что все функциональные и нефункциональные требования закрыли, развёртываем в эксплуатацию.

Реальный пример

По описанной выше схеме мы развёртывали в телекоме. Но если бы можно было просто выстроить схему и через 20 минут после коммита выкатывать приложение в прод, то всё было бы идеально. Однако важно помнить, что процесс цикличный, и на финише не заканчивается.

У нас был проект на 1,5 ТБ в оперативной памяти. Необходимо было резервирование, поэтому нам выдали два ЦОДа: один был активным, туда приходили все пользовательские запросы; а другой — резервным, он использовался для развёртывания и отказоустойчивости. Каждый ЦОД состоял из трёх физических серверов с 24-ядерными Xeon. На каждом сервере стояло 18 экземпляров Tarantool. У них была одинаковая структура, но разная бизнес-логика. Ещё было три роутера, которые обрабатывали запросы и маршрутизировали их в кластере, и 15 хранилищ данных. 

Фейлы в развёртывании

Теперь поговорим о самом интересном — о том, что пошло не так. 

Начнём с того, что в начале проекта мы развёртывали вручную. Конечно, мы не враги себе и сразу сделали Ansible Playbook, но запускали всё равно вручную, без CI. В итоге развёртывание растягивалось на день, потому что мы были заняты другими важными делами или нужно было искать людей и выбирать время. В итоге CI мы всё-таки сделали.

Развёртывание сильно растянулось. На старте у нас было условие: развёртываться за 20 минут, чтобы сервис во время обновления не простаивал дольше. Иначе сразу происходили автоаварии, оповещения, звонки руководству. Сначала у нас было не 15 экземпляров, а 9. Потом данных стало больше, а мы такого серьёзного роста не ожидали. И в итоге продолжительность развёртывания увеличилась просто потому, что нужно было 500 ГБ подтянуть в оперативку. Tarantool использовал все 48 ядер, и всё равно не успевал за 20 минут. Нам приходилось оправдываться, что у пользователей всё нормально, они даже не видят обновления — ведь есть резервный ЦОД. Но было неприятно.

Не получалось быстро встроить другие инфраструктурные моменты в наш playbook. В старых версиях был один большой playbook, у которого разные этапы развёртывания разделялись тегами, по которым мы запускали эти этапы вручную. В итоге иногда понадобилось создавать директории в других местах, запускать экземпляры с помощью не systemd, а супервизора. Мы не смогли быстро встроить эти и другие инфраструктурные моменты в playbook и пришлось создавать тикет на коллег, который долго это реализовывали. В итоге Ansible-Cartridge в проекте сейчас модульный. 

Разрастание логов. Это случилось, когда я уже ушёл из проекта. Однажды мне написал руководитель и сказал, что сервис недоступен, ничего не работает. Выяснилось, что лог одного экземпляра вырос до 1 ТБ. Он лежал рядом с данными на одном mount и Tarantool не мог создавать новые файлы изменений, просто не работал на запись. Мы нашли коллег из инфраструктуры, которые помогли разделить файлы, и всё заработало.

Злая шутка от мониторинга. Это тоже было, когда я ушёл из проекта. Снова всё сломалось, но с логами в этот раз был порядок. Оказалось, что мониторинг открыл кучу подключений по HTTP и не закрывал их. Пришлось добавить в настройку принудительное закрытие. 

Пять правил работы с Tarantool

Не забывайте про телеметрию. Кажется, что метрики и логи собирают все. Но на самом деле про это постоянно забывают или откладывают на потом. Мониторить нужно:

• Бинарный протокол iproto. Смотрите количество входящих подключений и объём трафика.

• HTTP-запросы, связанные с бизнес-логикой. Тоже отслеживайте количество запросов и ошибки. 

• Lua-память. Это выделенная системой память под наш интерпретатор. Например, не надо делать бесконечные циклы или создавать огромные таблицы, просто выделенные 2 ГБ закончатся и Tarantool упадёт. 

• Нехватка выделенной RAM-памяти. Если мы дошли до 80 %, то нужно задуматься о добавлении новых экземпляров или увеличении количества серверов, о решардинге данных, перекладывании в другие хранилища. 

• Фрагментация. При работе с диском следите за свободным местом, чтобы логи не съели всё доступное пространство. 

• Если мы используем репликацию, — а её тоже нужно использовать, — то следим за тем, чтобы данные были актуальны и отставание репликации не сильно увеличивалось. На дашборде это выглядит так:

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

Делайте маленькие экземпляры. Напомню, что у нас было 1,5 ТБ в оперативной памяти и несколько ЦОДов. Тогда сколько копий данных нужно делать для резервирования, на сколько кусков разбивать данные? В нашем проекте было 48 потоков на сервер и доступно 758 ГБ RAM. Экспериментальным путём мы пришли к тому, что нужно разбивать на куски по 30 ГБ и делать копии кратно количеству ЦОДов. Это удобно при развёртывании. Почему именно 30 ГБ? Есть ограничение сверху. У нас были огромные экземпляры, которые не успевали подниматься с диска после обновления. Мы искали золотую середину, чтобы вписываться в физическую инфраструктуру и укладываться по времени. 

Также было ограничение снизу: на два экземпляра Tarantool надо три ядра, то есть 1,5 ядра на экземпляр, которых у нас было 48. Нам нужно было ещё разместить агент сбора телеметрии, написанный на Java, а также роутеры. Нам нельзя было слишком , уменьшать размеры инстансов, чтобы не увеличивать их количество, поэтому пришли к 30 ГБ. А для вашей инфраструктуры может быть другая золотая середина. 

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

Расскажу про  кластер в одном из моих текущих проектов. Он содержит 3 ТБ данных, 500 экземпляров Tarantool с учётом резервирования, и обрабатывает 400, а то и 800 тысяч пользовательских запросов. SLA — недоступность не дольше часа в год. Как это развёртывать и обновлять, чтобы клиенты не заметили? Есть два способа:

1. Развёртывать по плечам. Если у нас несколько ЦОДов, из которых один активный и принимает пользовательские запросы, а другие мы можем обновлять в любом порядке, нам нужен механизм переключения. Это удобно, потому что мы целиком обновляем все серверы, не нужно гадать, всё ли мы обновили или какой-то экземпляр остался на старой версии. К тому же это быстро: в нашей инфраструктуре 45 экземпляров обновлялись за 60 минут, по 15–20 минут на один ЦОД. 

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

Это приводит к тому, что развёртывание замедляется, потому что меньшее количество экземпляров поднимется быстрее: 5 штук за за 10 минут, а не за 20. Если инстансов 45, то для полного обновления нужно выполнить процедуру 9 раз. Это растягивается на полтора часа, поэтому обязательно нужно несколько ЦОДов, чтобы использовать механизм обновления без простоя.

Не обновляйтесь вручную. Используйте CI, Jenkins, GitLab actions. Или Ansible-Cartridge — роль для Ansible, которая содержит 33 отдельных playbook, 33 операции, которые можно сделать с кластером на Tarantool. Что она умеет? В зависимости от вашей инфраструктуры она может работать с rpm-пакетами, с deb-пакетами и универсальными tgz — просто архивами, которые распаковываются в нужную директорию. Эта роль умеет создавать unit-файлы для systemd, с  помощью которых можно останавливать, запускать и перезапускать экземпляры. Ещё она умеет работать оркестратором, настраивать кластер Tarantool Cartridge. Умеет настраивать шардирование данных с помощью vshard. Благодаря Ansible-Cartridge можно настроить механизм обновления по плечам или пачками, пример описан на GitHub. Также можно исполнять произвольный код внутри экземпляров, и многое другое. 

Обновляйтесь почаще. Хотя бы раз в квартал. Релизный цикл Tarantool укладывается в три месяца, выходят новые основные версии, багфиксы, фичи. Желательно покрывать хотя бы багфиксы. Вот скриншот реального случая:

Как только я пришёл в Tarantool, одной из моих первых задач стало написание сервера сбора статистики. Я его благополучно написал на Lua, развернул в Docker на одном из наших серверов, и он там два года крутился. Потом ко мне приходит коллега и говорит, что надо обновиться. А я уже не помню, где поднято сервер и как в него залогиниться. Ав общем случае за полгода из команды может уйти человек, который единственный владеет подобной информацией.

Заключение

Напоследок подытожу пять правил работы с Tarantool:

1. Обязательно собирайте не только метрики, но и логи.

2. Разбивайте данные на небольшие фрагменты кусочкам. Не пытайтесь запихнуть 1,5 ТБ в 10 экземпляров Tarantool, ничего хорошего из этого не выйдет. 

3. Обновляйте приложение без простоя. 

4. Используйте Ansible-Cartridge. 

5. Обновляqntcm почаще. Ставьте новые версии хотя бы раз в квартал.

Скачать Tarantool можно на официальном сайте, а получить помощь — в Telegram-чате.

История о том, как IT-решение может увеличить эффективность

Привет! Я Алексей Василенко, руководитель направления PHP в AGIMA. Четыре года назад работал с компанией, которая занималась b2b-продажами. В основном продавали товары для активного отдыха. Палатки, лодки, моторы, спальные мешки — всё, что пригодится туристу в походе. Ребята позвали меня поработать над их сайтом. Он казался им неудобным и малоэффективным. Но в итоге оказалось, что неудобным и малоэффективным был весь бизнес-процесс в компании. За 3 года мы не просто переделали сайт. Мы полностью поменяли подход к работе, увеличили количество заказов в 2 раза, а эффективность бизнеса — в 3. И всё это силами IT-отдела. Текст о том, как технологические решения влияют на доходы и клиентский сервиc.

Что было сначала

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

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

1. Заходишь на сайт купить палатку. Зарегистрироваться нельзя. Через форму отправляешь данные менеджеру.

2. Получаешь на почту доступ. Снова заходишь на сайт.

3. Скачиваешь бланк заказа. Это экселевский файл.

4. Заполняешь бланк.

5. Отправляешь бланк в отдел продаж.

6. Ждешь. Статуса заказа не знаешь.

А вот та же система изнутри:

1. Менеджер отдела продаж получает заявку покупателя.

2. Вручную вносит его данные в 1С.

3. Вручную заводит пользователя на сайте.

4. Вручную отправляет доступ на электронную почту покупателя.

5. Получает от него бланк заказа на почту.

6. Вручную вносит заказ в 1С.

Весь процесс на схеме:

Позже мы подсчитали, что один менеджер за день оформлял всего 10–12 заказов. Больше не успевал. Товары и цены обновлялись на сайте каждый день в 6 утра. И тоже вручную. Если покупатель заказывал товар после обеда, то мог только надеяться, что он по-прежнему есть на складе.

Еще два важных звена в этой схеме — отделы закупок и логистики. Новый товар у поставщиков и производителей закупали на основе месячных отчетов. Если в прошлом месяце купили 10 тысяч удочек, то в следующем месяце наверняка купят столько же — надо заказать. Отдел логистики через 1С WMS контролировал доставку товара от производителей на склады и из складов покупателям. 

Вот довольно точная схема всего бизнес-процесса:

Как приводили систему в порядок

Первое, что мы сделали, поговорили с сотрудниками всех отделов и провели опрос среди покупателей. Составили список самых активных пользователей сайта и подготовили для них анкету. Сначала разослали ее по электронной почте, но никто не отвечал. Поэтому заменили анкетирование на обзвон. Каждому, кто согласился ответить на вопросы, делали персональную дополнительную скидку в 1% на месяц.

Эта идея оправдала себя. Обзвон помог определить, что не нравится пользователям:

1. Много ручной работы при оформлении заказа.

2. Неизвестно, что осталось на складе, а что нет.

3. Нельзя следить за статусом заказа.

4. Срок отгрузки товара меняется.

Список этих проблем лег в основу нашего бэклога. А опрос сотрудников помог понять проблемы и нарисовать общую схему всех процессов в компании (см. первую схему в статье). Когда она была готова, начали придумывать, как ее улучшить и сократить. Делали мы это частями: сначала склады, потом продажи. Процесс был непростой — на всё ушло почти 3 года.

Ядром новой системы решили сделать 1С. Выбрали ее, потому что она уже долго работала и в ней хранились все нужные данные. Перекинули ее на более производительный сервер с широким каналом и уже вокруг нее строили новый автоматизированный бизнес-процесс.

Начали со складов. Построили работу так, чтобы данные из 1С попадали в WMS без участия программистов. Из WMS на склады вся информация тоже улетала в автоматическом режиме. Там кладовщики терминалами пропикивали отгруженный товар. И информация возвращалась обратно в 1С за доли секунды. Отдел логистики тоже начал работать с 1С. Проще говоря, теперь между 1С и складом не было никаких лишних остановок.

Что сделали с сайтом

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

• Сделали удобную регистрацию пользователей

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

пользователь вводил свой ИНН > система проверяла его через Dadata > поля заполнялись автоматически > клиент дополнял или исправлял данные в форме > заявка готова

Со стороны заказчика система тоже работала автоматически:

проверяла ИНН через Dadata > регистрировала нового контрагента > регистрировала новое контактное лицо > создавала договор > привязывала к нему базовые персональные скидки > выгружала на сайт договор и информацию о клиенте

В итоге на сайте создавался новый пользователь. Система отправляла ему письмо с логином и паролем. После авторизации покупатель видел всю актуальную информацию по ассортименту: цены, что осталось на складах и персональные скидки.

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

• Усовершенствовали каталог

Теперь он обновлялся автоматически: раз в 3 минуты система сверяла товары на витрине с 1С и уточняла ассортимент. Покупатель видел, какой товар остался на складе, практически в реальном времени. А если ему было неудобно работать с сайтом, он мог сам выгрузить себе весь каталог.

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

Но главная наша находка — система работы со складами. Мы ввели в системе 3 категории складов:

• оперативные,

• удаленные,

• склады поставщиков.

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

Оперативные склады располагались рядом с метро. Забрать заказ оттуда можно было уже через 15 минут после оформления заказа, а хранились там самые популярные товары. Особенность была в том, что аренда этих складов была самой дорогой. Поэтому персональная скидка уменьшалась на 2%. Для оптовых закупок это могла быть существенная сумма.

Удаленные склады находились в Московской области. Там хранились все товары, но срок доставки составлял 1–3 дня. Нам было выгодно доставлять отсюда —  поэтому персональная скидка для покупателя действовала в полном объеме. 

Но самым выгодным для нас был третий вариант — товары со склада поставщика. Здесь мы не тратим денег на аренду вообще. Поэтому к персональной скидке прибавлялось 2%. Однако срок доставки был от 5 дней.

Пользователь выбирал удобный вариант — а дальше всё делала система.

• Разработали личный кабинет

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

Вот какие еще функции были в личном кабинете:

• В личный кабинет можно было выгрузить документы из 1С. Например, счет. Затем его оставалось только распечатать и оплатить в банке.

• К одному кабинету прикреплялось несколько юрлиц. Чтобы добавить новое, достаточно было ввести ИНН. Для нового юрлица создавался новый договор с собственной системой скидок.

• В кабинет можно было добавить своих сотрудников. У каждого был свой логин и пароль.

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

Итоговая схема

Мы переключали все отделы компании на 1С. Закупки у поставщиков и производителей теперь проходили в полуавтоматическом режиме. В полуавтоматическом — потому что не все поставщики дали нам свои API для формирования заказа. С ними работали по старинке. А тем, к которым у нас был доступ, заказы падали почти без участия отдела закупок. Для них мы написали подобие PI-системы.

Отдел продаж мы полностью отделили от сайта. Теперь они работали только с самыми крупными клиентами: Ozon, Wildberries, Lamoda. Обычные пользователи к ним обращались, только если возникали какие-то проблемы. А когда проблем не было, покупатель просто приходил на сайт и оформлял заказ. Тот напрямую через 1С пролетал в WMS, а оттуда на склад. Склады собирали посылку и сообщали об этом. Через секунду актуальное количество товара отображалось на сайте. 

Схема выглядела так:

Замечу на полях, что сотрудники компании не сразу прониклись новыми идеями. Пока мы внедряли систему, приходилось постоянно обучать их работе с Kanban-досками и включать в новые процессы. Мы объясняли, в чем плюсы новых решений, почему важно обновлять статус задач, как эффективнее общаться. Сопротивления было много.

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

Какие результаты

1. Мы стали обрабатывать больше заказов в день, а штат сократили. Менеджеров по продажам стало меньше в 5 раз, кладовщиков — в 2 раза. При этом выручка увеличилась в 1,5 раза. 

1. Средний чек сократился, но тому были объяснимые причины. Раньше, когда заказы делать было неудобно, покупатели старались набрать максимальное количество товаров за один раз. Теперь же такой необходимости не было.

2. Теперь мы могли отгружать товар в день заказа. При старой системе все склады были в Московской области. Но после обновления системы мы сняли несколько складов в Москве, рядом с метро. Там мы хранили товары категории А — самые популярные и маржинальные. Теперь у покупателя была возможность прийти на склад, заказать товар с телефона и уже через 15 минут его получить. В старой схеме это было невозможно.

3. Клиенты теперь могли оформлять заказы напрямую со складов поставщика. Ждать такие приходилось 5 дней, в то время как с наших складов — не более 3. Но нам было выгодно продавать с чужих складов, потому что, если его склад позволял оформить заказ в автоматическом режиме, то мы в процессе доставки даже не участвовали, а прибыль получали.

Отправной точкой этого процесса было желание просто обновить устаревший сайт. Но в итоге компания улучшила клиентский сервис и доходы. По нашим подсчетам, дневная выручка увеличилась в 1,5 раза, а количество заказов — в 2,5. А мы вынесли для себя важный урок: нельзя недооценивать влияние сайта на бизнес-процессы. Даже маленькие технологические решения дают реальные плоды. Этим надо пользоваться.