Вторая неделя марта 2020 была худшей в году, как для биткоина, так и для фондового рынка. Тогда цена биткоина упала с уровня $9200 ниже $4000.

Обвал в «черный четверг» 12-го марта привел к ликвидациям позиций на сотни миллионов долларов. Тем не менее, спустя 3 месяца открытый интерес (далее — ОИ) по фьючерсам на биткоин практически полностью восстановился до объемов, предшествующих краху. В связи с этим важно понимать, что означает восстановление ОИ для главной криптовалюты и всего рынка.

Почему произошел мартовский обвал?

Оглядываясь назад, очевидно, что резкое падение ОИ по фьючерсам на биткоин было вызвано продажами институционалов, которые должны были разгрузить риск по своим портфелям. Так, на CME в один день ОИ упал с $210 млн до $113 млн, на BitMEX — с $1253 млн до $565 млн. Эта распродажа произошла после такого же падения на фондовом рынке. Одновременный крах биткоина способствовал корреляции между двумя рынками, выведя ее на новый уровень.

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

В частности, на CME наблюдался наплыв трейдеров, которые всего за два месяца смогли разогнать ОИ со $113 до $379 млн. Аналогичное резкое увеличение ОИ произошло и на бирже Bakkt. Платформа Grayscale также не осталась в стороне, поскольку за 3 месяца ею скуплено 33% всех намайненных BTC. Все это в совокупности и приводит к увеличению цены биткоина и росту ОИ на всех платформах. Из указанного выше графика видно, что BitMEX, OKEx, Binance, Huobi и CME внесли наибольший вклад в восстановление открытого интереса.

Что означает восстановление ОИ?

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

Опубликованное изменение открытых позиций с 16 июня по 23 июня, показало, что хедж-фонды нарастили короткие позиции с 9,7 тысяч BTC до 11,9 тысяч BTC, в то время как частные трейдеры увеличили длинные позиции с 7,8 тысяч BTC до 9,0 тысяч BTC. Уже не впервые эти игроки находятся по разные стороны рынка.

Набор коротких позиций институционалами и неспособность биткоина закрепиться выше 10000 USD могут и дальше способствовать развитию коррекции первой криптовалюты.

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

Все ли вы знаете об Android Jetpack?

Кирилл Розов, Mobile Lead, Replika / Android Broadcast

Android Jetpack развивается невероятными темпами и уже есть в любом современном Android-приложении. Сейчас сложно представить разработку без этого набора библиотек. Уследить за всеми новинками непросто, поэтому я сделаю обзор последнего API и будущего библиотеки AndroidX.

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

Приглашаю послушать доклад практикующих Android-разработчиков. Вы узнаете, как сделать интеграцию Dagger 2 c Fragment (без Hilt) и какие API из KTX представляют опасность для использования.

Шаблоны проектирования Server Driven UI

Никита Русин, Platform lead, «БюроБюро»

Расскажу про подход к проектированию и реализации максимально гибкого клиент-серверного протокола с фокусом на API и кейсах его использования. На проектах часто встречаются задачи создать формы платежей или экраны чеков. Подобные экраны с динамическим контентом и логикой невозможно адекватно реализовать без SD UI.

Тема наиболее актуальна в разработке мобильных и десктопных приложений из-за более сложного и растянутого процесса обновления пользователей. Но доклад будет полезен всем разработчикам обоих концов, как новичкам так и тем, у кого есть серьёзный опыт в проектировании API (для вдохновения или приятного чувства, что в интернете кто-то неправ).

Разберём:

• Что такое Hypermedia API и Server Driven UI.
• Каким образом при небольшой подготовке можно клепать 100500 информационных экранов в день, не меняя клиентский код.
• Способы реализации SD UI на сервере и на клиенте вместе с простыми примерами на Python и Kotlin.
• Как подготовиться к тому, чтобы на SD UI реализовывать целые пользовательские сценарии/новые разделы без изменений кода клиента.

Будут простые примеры без привязки к конкретной платформе и фреймворку. Так что не важно, каких животных и еду вы предпочитаете.

---

Вместе со зрителями обсуждать доклады будут модераторы Юрий Новак, ведущий системный аналитик в компании «РТ Лабс» (Иннополис) и Александр Симоненко, технический директор «Технократии» (Казань).

Начинаем 2 июля в 17:00

Регистрация — напомним о встрече за пару часов

Ссылка на трансляцию

Телеграм-чат митапа

До встречи!

Эта публикация вызвана необходимостью дать возможность обучаемым изучать и моделировать процессы шифрования/расшифрования и дешифрования последнего стандарта США. Ознакомление с имеющимися публикациями в сети не соответствуют программе обучения в силу их поверхностного подхода, неполноты изложения, и отсутствия должной строгости. Например, нигде не встречается выбор и задание примитивного элемента, формирующего поле, без чего работу и подготовку специалиста, особенно криптоаналитические явления и процессы, организовать и моделировать невозможно. В этой работе используется описание, несколько отличное от оригинала AES, представленного FIPS PUB 197. Здесь описывается шифр AES, с использованием матриц над GF(2⁸), но примечания работы сохраняются, т. е. шифр реализуется над конечным расширенным полем GF (2⁸). На русском языке достаточно полная и доступная версия шифра изложена Зензиным О.С. и Ивановым М.А.

Математические основы стандарта шифрования AES США

AES – блочный шифр с длиной блоков равной 128 битам, и шифр поддерживает ключи длиной $$, равной 128, 192 или 256 бит. AES – это шифр с итерационным ключом: состоит из повторного применения раундового преобразования состояния блока State шифруемого текста. Число раундов шифра обозначается $$ зависит от длины ключа ($$ для ключа 128 битов, $$ для ключа 192 бита и $$ для ключа 256 бит).

Шифр AES преобразует исходное состояние блока, обозначаемое символом S (State) и принадлежащее множеству матриц {M4(GF(2⁸))} (то есть S є{M4(GF (2⁸))} – матрица 4 × 4 байта, с ее элементами (коэффициентами) в GF (2⁸)), к другому шифрованному состоянию в {M4 (GF (2⁸))}.

Пример 1. Блок данных длиной в 128 = 4·32, 4 слова по 32 разряда представляется квадратной таблицей байтов из 4-х строк и 4-х столбцов. Каждая строка содержит байты из 4-х разных 32 разрядных слов, а столбец – байты одного и того же 32-разрядного слова. Весь квадрат образован 4×4 = 16 байтами, которые могут обрабатываться как самостоятельные единицы.

Именно такой подход к представлению данных определяет и обеспечивает байт-ориентированную структуру шифра и обработку данных. Ключ шифра K расширяется в $$ подключей, обозначаемых матрицей Ki ={M4(GF(2⁸))}, принадлежащей множеству {M4 (GF(2⁸))}, (i = 0, 1, …, Nr). Перестановка элементов в матрице S, возникающая при операции сдвига строк обозначена символом р(х).

Представление данных, выбранное для элементов поля GF(2⁸)

В шифре AES используется байтовая структура данных. Представление, выбранное в [1] из векторного пространства GF(2⁸), соответствующего полю GF(2⁸)[X]/< φ(x) >, где φ(x) – неприводимый многочлен,

$$

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

Таблица 1. Соответствие десятичных, шестнадцатеричных, двоичных чисел и многочленов

В работе используются четыре представления для обозначения каждого элемента расширенного поля в GF(2⁸), которые являются эквивалентными одно другому.

Представление данных, используемых в шифре AES

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

1. 212₁₀, десятичным видом – числом в 10-ой системе счисления.

2. {11010100}b, представление элементов сообщения двоичным вектором – элементом векторного пространства GF(2⁸) двоичных векторов,

3. $$, многочленное представление – элементом поля Галуа GF [2⁸], соответствующим двоичному вектору,

4. {D4}₁₆, – шестнадцатеричное представление – числом в 16-системе счисления,

⊕ – операция поразрядного суммирования векторов из GF(2⁸) по mod2 (без переноса 1 в старший разряд).
⊗ – операция умножения элементов (векторов, многочленов, чисел) из поля GF(2⁸)

Алгоритм стандарта AES и шифра RIGNDAEL оперирует с байтами информации, которые отождествляются с элементами конечного поля Галуа GF(2⁸). Степень расширения простого поля GF(2) равна 8. Все элементы расширенного поля при представлении их многочленами имеют показатель степень не более семи (≤ 7).

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

В рассматриваемом алгоритме примитивный элемент задан (его порядок должен быть равен порядку мультипликативной группы поля), а многочлен фиксирован и имеет вид φ(x). Не располагая этими характеристикам, работать со стандартом не получится

$$

или 1{1b} в 16-ричной форме.
Шестнадцатеричная запись неприводимого многочлена 1{1b} использует 9 разрядов и многочлен φ(x) не принадлежит полю GF(2⁸).
Таблица П1 представления элементов поля GF(2⁸) (в конце текста в Приложении).
В таблице П1 размещены все элементы поля в порядке возрастания показателя степени примитивного элемента (α = 00000011₂ = 3₁₀), мультипликативный порядок которого равен 255.

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

$$

Пример 2. Элемент расширенного поля GF(2⁸) задан в виде двоичного вектора:

$$

Описание многочленом этого элемента имеет вид:

$$

Если доопределить значения ai двоичными значениями, i = 0(1)7, например, так $$ = {11000001}₂, то получим многочлен

$$

так как $$

Шестнадцатеричное представление этого элемента α₁₆ = {с1}={11000001}, а десятичное

α₁₀ = $$ = 128 + 64 + 1 = 193₁₀.

При выбранном примитивном элементе поля степенное представление
α_i ={с1}= α¹⁷⁸.
Входим в таблицу П1 элементов поля GF(2⁸) со значением α¹⁷⁸ и в соответствующих столбцах для этой строки находим описанные представления, а также другие характеристики этого элемента поля. Для понимания возможных преобразований с элементами поля рассмотрим операции с его элементами в деталях.

Суммирование элементов поля GF(2⁸)

Сложение в рассматриваемом поле представляет операцию поразрядного суммирования значений разрядов слагаемых без переноса единицы в старший разряд. Это операция исключающего ИЛИ (EXOR – EXLUSIV OR) часто обозначается просто XOR. В модулярной арифметике такое сложение называется суммированием по модулю два (mod2).

Пример 3. Выберем в качестве операндов многочлены
$$
$$
Двоичное представление суммы многочленов по модулю два имеет вид
[A(x)⊕B(x)]mod2 = {11000001}⊕ {00001101} = {11001100};

16-ричное представление {c1}⊕{0D}={cc}sub>16=α⁵⁵;
степенное представление α¹⁷⁸ + α²³⁸ = α⁵⁵· {α¹²³ + α¹⁸³} = α⁵⁵· 1 = α⁵⁵.

Представление многочленами
$$
Заметим, что при сложении операндов степень многочлена результата не
увеличивается, и необходимость приведения его по модулю неприводимого многочлена поля φ(x) не возникает. Коэффициенты результата приводятся по модулю два, т. е. все четные коэффициенты обращаются в нуль.

В полях характеристики 2 действия сложения и вычитания операндов равнозначны. Для каждого элемента поля в аддитивной группе обратным к нему (противоположным) является он сам. Так, для элемента (а) противоположным является (-а), так как а + (-а) = 0. Нулевой элемент (единица аддитивной группы поля, нейтральный элемент) в шестнадцатеричном виде – это {00}₁₆.

Умножение элементов поля GF(2⁸)

Операция обычного умножения операндов (в отличие от модулярного ⊗) обозначается точкой между операндами, или знак умножения вообще опускается, когда не возникает опасности разночтения. Операнды в двоичном представлении умножаются по обычным правилам «столбиком». Будем перемножать те же, что и ранее операнды.

Пример 4. Умножение операндов в двоичном представлении
А(х)· В(х) = {c1}·{0d}

Остаток от деления получает вид двоичного, многочленного и 16-ричного представлений (как элемент поля)
R(x) = 01011 1010₂ = $$= {ba}₁₆. Старший разряд остатка равен нулю и не учитывается.
Степенное представление здесь не приводим, но по таблице П1 его можно найти.

Остаток от деления на неприводимый многочлен φ(x) в его двоичном представлении результата умножения операндов принимаем в качестве произведения операндов как элементов поля GF(2⁸).

Выполним умножение операндов в представлении многочленами.

Пример 5. Умножение операндов элементов поля в многочленном представлении
А(х) ⊗ В(х) = {c1}⊗{0d}
A(x) ⊗ B(x) = $$(moddφ(x),2) =
=(x¹⁰+$$(moddφ(x),2) =
=(x¹⁰+$$(moddφ(x),2).

Здесь символ (moddφ (x),2) обозначает приведение по двойному модулю: многочлен по модулю φ(x), а его коэффициенты по модулю два, т.е. четные коэффициенты обнуляются. Получившаяся степень (deg(A(x)⊗ B(x)) =10) результата произведения выводит (этот многочлен — результат) за пределы поля. Чтобы результат принадлежал полю, его приводят (редуцируют, делят) по модулю неприводимого многочлена. Выполним такое деление обычным способом (уголком)

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

– остаток отделения на φ(x) принадлежит полю GF(2⁸), и его принимаем в качестве окончательного результата $$ модулярного умножения.

Иначе умножение A(x)⊗B(x) представимо как
$$ = {ba}₁₆=α¹⁶¹,
где R(x) остаток и degR(x)< deg φ(x).
Степенное представление для получения произведения элементов поля самое удобное.
A(x)· B(x) = α¹⁷⁸· α²³⁸ = α^(178+238) = α⁴¹⁶ = α¹⁶¹α²⁵⁵ =α¹⁶¹ = {ba}₁₆.

Для любого ненулевого элемента β поля справедливо β·1 =β. Мультипликативной единицей в GF(2⁸) является элемент {01}₁₆ =α²⁵⁵.
Все вычисленные произведения для различных представлений операндов эквивалентны (преобразуются в один элемент поля со значением {ba}₁₆).

Наряду с обычным (классическим) рассмотрением операции умножения элементов в двоичном поле существует более удобная схема. Именно такая схема и реализована в стандарте AES.

Рассмотрим сущность этого способа умножения

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

Умножим его на $$ и получим $$. Этот результат не принадлежит полю GF(2⁸) степень его многочлена больше 7 и его необходимо привести по модулю φ(x) = 1{1b}, после чего такое произведение станет элементом поля GF(2⁸).

С этой целью определяют значение $$, если $$ то результат уже принадлежит полю, если же $$, то достаточно вместо деления выполнить лишь вычитание A(x)x – φ(x) или операцию XOR для произведения A(x)x с φ(x).

В этом случае при записи A(x) в сдвиговом регистре умножению на x полинома A(x), т.е. $$ соответствует сдвиг полинома A(x) на один разряд в сторону старших разрядов (влево, т.е. увеличение вдвое) и, если требуется, применяется операция XOR с неприводимым многочленом поля 1{1b}₁₆ =φ(x).

В алгоритме стандарта шифрования введена операция (функция) xtime( ), которая по существу и выполняет умножение полинома на х, так как это описано ранее. Многократное применение xtime обеспечивает умножение на x⁸. Далее вычисляя сумму различных степеней, можно получить результат умножения произвольных элементов поля GF(2⁸).

Пример 8. Перемножим многочлены A(x) = {c1}₁₆ и B(x) = {11}₁₆, используя их 16-ичные представления и представляя суммой {11} ={10⊕01}.
{c1}⊗{11}={11000001}⊗{00010001}={c1}⊗{10⊕01}={a4}⊕{c1}=01100101 ={65}₁₆.

Детализируем все действия. Элемент х в поле GF(2⁸) имеет представление
x = {02}₁₆=(00000010)₂.
{c1}⊗{11}={c1}⊗{10}⊕{c1}⊗{01}= α¹⁷⁸· α¹⁰⁰⊕α¹⁷⁸· α⁰={a4}⊕{c1}, так как α¹⁷⁸· α¹⁰⁰=α^{(178+100-255)}=α²³={a4}

Тогда умножение на него приводит просто к сдвигу первого операнда на 1 разряд влево.
{c1}⊗ {02} = xtime{c1} = 11000001⊗ 00000010= 110000010 — 9-ти разрядное двоичное число. Этот результат выходит за пределы нашего поля. Его возвращают вычитанием неприводимого многочлена поля φ(х), преобразуя в элемент поля. Итоговый результат 10011001 = {99}

$$

{c1}⊗ {04} = xtime(99) = 10011001⊗ 00000010 =100110010 — 9-ти разрядное двоичное число. Этот результат выходит за пределы нашего поля. Его возвращают вычитанием неприводимого многочлена поля φ(х), преобразуя в элемент поля. Итоговый результат 00101001 = {29}

$$

Очередной шаг процедуры
{c1}⊗ {08} = xtime(29) = 00101001⊗ 00000010 = 0101 0010 = {52}.
Здесь результат не суммируем с φ(x), так как коэффициент $$.

И еще один шаг
{c1}⊗ {10} = xtime(52) = 01010010⊗00000010 = 10100100 = {a4}₁₆.
Здесь также не суммируем с φ(x), так как коэффициент $$.
Таким образом, найдено значение первого слагаемого в сумме для исходного
выражения, где второе слагаемое равно {c1}₁₆.
Теперь находим окончательно
{c1}⊗ {11} = {c1}⊗ {10}⊕ {c1}⊗ {01} = {a4} ⊕ {c1} =10100100⊕ 11000001 = {65} или

$$

проверка обычным умножением (степенное представление)
A(x)∙ B(x) = {c1}∙{11} = α¹⁷⁸∙α⁴ = α¹⁸²
(по таблицам находим в строке для α1¹⁸²) α¹⁸² соответствует {65}₁₆.

Еще большего эффекта при производстве вычислений можно достигнуть, если укрупнить элементы, с которыми выполняются манипуляции. Так в криптоалгоритме RIJNDAEL используются 32-разрядные (4-х-байтовые) слова. Составляющие байт разряды не анализируются по отдельности. Такой подход позволяет 4-байтовому слову в соответствие поставить многочлен А(х) степени не более трех, и коэффициенты которого лежат в поле GF(2⁸).

Операция умножения таких слов
$$ и
$$,
где $$єGF(2⁸), i = 0(1)3, выполняется по модулю многочлена степени не более четырех. Взятие результата произведения по модулю неприводимого многочлена степени 4 обеспечивает всегда получение результата произведения, как элемента поля.

В качестве такого многочлена выбран многочлен $$. Он имеет наиболее простую запись, и для него справедливо
$$.
Последнее свойство оказывается очень полезным при вычислениях.
Для рассматриваемых многочленов операция сложения выполняется аналогично (XOR поразрядное по mod2)
$\$inline\$A(x)\oplus \; B(x)\; =\; (a\_3\oplus \; b\_3)\; x^3\; \oplus \; (a\_2\oplus \; b\_2)\; x^2\; \oplus \; (a\_1\oplus \; b\_1)x\; \oplus \; (a\_0\oplus \; b\_0)\$inline\$$.

Умножение многочленов.
$\$inline\$A(x)\otimes \; B(x)\; =\; C(x)\; =\; (c\_6x^6\; \oplus \; c\_5x^5\; \oplus \; c\_4x^4\oplus \; c\_3x^3\; \oplus \; c\_2x^2\; \oplus \; c\_1x^1\; \oplus \; c\_0)\; mod(x^4+1)\$inline\$$.
Коэффициенты $$ определяются из соотношений
$$,
$$,
$$,
$$,
$$,
$$,
$$.

Окончательно результатом D(x) умножения ⊗ двух многочленов по модулю $$ будет
$\$inline\$D(x)\; =\; A(x)\otimes B(x)\; =\; d\_3x^3\; \oplus \; d\_2x^2\; \oplus \; d\_1x\; \oplus \; d\_0\$inline\$$, где
$$,
$$,
$$,
$$,
или более кратко в векторно – матричной записи,

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

Приложение

Таблица П1 — расширенного поля, неприводимый многочлен φ(х)=Р (х), примитивный элемент α=3₁₆

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

С чего всё начиналось

Собирались мы как-то с братом и его другом вместе в Припять съездить нелегалом, это была ещё давняя мечта, которая ждала своей реализации, но так и не дождалась (Но об этом позже). Когда мы уже подготовили практически всё что нужно, оказалось что ни у кого не было хотя бы простенького индикатора радиации. Посмотрев на площадке объявлений я мало чего нашёл, всё было в основном либо очень далеко, либо очень дорого, так и пришла идея попробовать сделать свой из того что было под рукой, а всё что у меня было, это ардуинка, счётчик (СТС-5) и много всякой рассыпухи. Так, как всё нужно было сделать в течении месяца, я стал искать уже готовые проекты, чтобы не изобретать велосипед, и нашёл максимально простенький проект на радиолюбительском сайте. Главной проблемой была намотка трансформатора, собственно из за чего я и забросил это дело. В Припять мы так и не поехали, потому что обострилась политическая обстановка.

Возобновляя старый проект

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

Начало разработки

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

Хьюстон, у нас помехи

Как понятно из заголовка, появились ужасные помехи по питанию и не только. Когда напряжение приближалось к 400 вольтам, на ножке прерывания начиналась полная вакханалия. Прерывание постоянно срабатывало, и я просто не мог понять долгое время в чём была эта проблема. Изменение частоты шим не помогало, конденсаторы по питанию тоже. Я уже начал отчаиваться, но решение пришло внезапно, когда я поднёс палец к ножке прерывания. Прибор сразу стал функционировать нормально, до того момента, пока я не уберу палец. И тут я вспомнил завет давнего приятеля: «Везде ставь керамику». После того как я поставил керамический конденсатор на 100нФ между прерыванием и землёй, проблема ушла. На то, чтобы разобраться с этой проблемой у меня ушла куча времени, но этот урок я запомню на долго. Собственно керамические конденсаторы в итоге я поставил везде, где только можно, и всё заработало как надо.

Разработка платы

Плату я разрабатывал в редакторе EasyEda, потому-что сразу решил заказывать платы с Китая. Скажу честно, редактор удобный и интуитивно понятный. Для меня, человека, который всегда делал платы в SprintLayout, эта программа была просто чем-то за гранью фантастики.
Теперь к сути. Я хотел сделать прибор как можно меньше, и выбрал размер 50х100 мм, что в каком то плане многовато и можно было уместить на меньшем размере. Первые варианты я решил делать на семи-сегментных индикаторах, что было огромной ошибкой, так, как они были крайне не информативные, и было достаточно сложно отобразить на них то, что хотел я. Следующим в моём списке был дисплей от nokia 5110. Этот вариант меня более чем удовлетворил.

Главные его плюсы это:

1. Не требует подсветки днём.
2. Низкое энергопотребление.
3. Простота в использовании.

Но собственно были и проблемы. Дисплей требует 3.3 вольта питания, и желательно 3.3 вольта логику, а микроконтроллер работает от 5 вольт. Проблема решилась 10 кОм резисторами и линейным стабилизатором.

Ядром устройства является микроконтроллер atmega328p-mu. Я выбрал именно, потому-что судя по даташиту он более живучий.

Устройство является автономным и работает от аккумулятора li-ion, по-этому на плате была разведена микросхема tp4056 и маломощный повышающий dc-dc преобразователь на 5 вольт на микросхеме me2108a50.

В итоге плата приняла следующий вид:

Зачем оно нужно если можно купить?

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

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

1. Напряжение счётчика
2. Время счёта
3. Ошибка

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

Себестоимость прибора выходит 500 руб. если заказывать детали с Китая и около 1000 рублей, если закупать в местных радиодеталях. Конечно я не учёл стоимость счётной трубки, т.к. её цена на барахолках обычно не превышает 500 руб.

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

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

Как видно по фото, плата ещё не собрана до конца, так как я не нашёл некоторые компоненты в моём городе и нужно ждать их с Китая.

Резюмируя

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

Надеюсь я вам помог, и мой проект заинтересовал вас. Прилагаю ссылки на репозиторий с прошивкой и на проект печатной платы:

github.com/AdamFull/Dosimeter-SQUICK
easyeda.com/AdamFull/geigercounter_nokia

Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, Terraform, Packer, рисовать NALSD и строить IaC, как мы применяли практики экстремального программирования для управления инфраструктурой компании, и что из этого вышло.

В Додо Пицце больше 600 пиццерий в 13 странах мира, а большая часть процессов в пиццериях управляется с помощью информационной системы Dodo IS, которую мы сами пишем и поддерживаем. Поэтому надёжность и стабильность системы важны для выживания.

Сейчас стабильность и надёжность информационной системы в компании поддерживает команда SRE (Site Reliability Engineering), но так было не всегда.

Предыстория: параллельные миры разработчиков и инфраструктуры

Много лет я развивался как типичный fullstack-разработчик (и немного scrum-мастер), учился писать хороший код, применял практики из Extreme Programming и старательно уменьшал количество WTF в проектах, к которым прикасался. Но чем больше появлялось опыта в разработке ПО, тем больше я осознавал важность надёжных систем мониторинга и трейсинга приложений, качественных логов, тотального автоматического тестирования и механизмов, обеспечивающих высокую надёжность сервисов. И всё чаще стал заглядывать «через забор» к команде инфраструктуры.

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

Этот культурный и технологический разрыв вызывает не только недоумение, но и проблемы: на стыке разработки, инфраструктуры и бизнеса. С частью проблем в инфраструктуре сложно бороться из-за близости к «железу» и относительно слабо развитых инструментов. Но остальное вполне можно победить, если начать смотреть на все свои Ansible-плейбуки и Bash-скрипты как на полноценный программный продукт и применять к ним те же требования.

Бермудский треугольник проблем

Однако я начну издалека — с проблем, ради которых все эти пляски нужны.

Проблемы разработчиков

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

• собрали классную команду;
• за полгода написали удобное и красивое приложение;
• подкрепили торжественный запуск «вкусными» промоакциями;
• и в первый же день благополучно упали под нагрузкой.

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

Но эту кнопку никто не нажал: команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение. Они решили, что следить за продакшеном «некритичного» сервиса — обязанность команды приложения. А разработчик бэкенда (это был его первый проект в Додо) решил, что в крупных компаниях этим занимаются ребята из инфраструктуры.

Тем разработчиком был я. Тогда я вывел для себя очевидное, но важное правило:

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

Сейчас это не сложно. В последние годы появилось огромное количество инструментов, которые позволяют программистам заглянуть в мир эксплуатации и ничего не сломать: Prometheus, Zipkin, Jaeger, ELK стек, Kusto.

Тем не менее у многих разработчиков до сих пор есть серьёзные проблемы с теми, кого называют инфраструктурой/DevOps’ами/SRE. В итоге программисты:

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

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

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

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

Проблемы инфраструктуры

Сложности есть и «на другой стороне».

Сложно управлять десятками сервисов и окружений без качественного кода. У нас в GitHub сейчас больше 450 репозиториев. Часть из них не требует операционной поддержки, часть мертва и сохраняется для истории, но значительная часть содержит сервисы, которые нужно поддерживать. Им нужно где-то хоститься, нужен мониторинг, сбор логов, единообразные CI/CD-пайплайны.

Чтобы всем этим управлять, мы ещё недавно активно использовали Ansible. В нашем Ansible-репозитории было:

• 60 ролей;
• 102 плейбука;
• обвязка на Python и Bash;
• тесты в Vagrant, запускаемые вручную.

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

Причина крылась в том, что этот код не использовал многие стандартные практики в мире разработки ПО. В нём не было CI/CD-пайплайна, а тесты были сложными и медленными, поэтому всем было лень или «некогда» запускать их вручную, а уж тем более писать новые. Такой код обречён, если над ним работает более одного человека.

Без знания кода сложно эффективно реагировать на инциденты. Когда в 3 часа ночи в PagerDuty приходит алерт, приходится искать программиста, который объяснит что и как. Например, что вот эти ошибки 500 аффектят пользователя, а другие связаны со вторичным сервисом, конечные клиенты его не видят и можно оставить всё так до утра. Но в три часа ночи программистов разбудить сложно, поэтому желательно самому понимать, как работает код, который ты поддерживаешь.

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

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

Проблемы бизнеса

У бизнеса тоже есть две большие проблемы, которые нужно решать.

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

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

• с одной стороны, для решения таких задач нужны программисты с глубокими знаниями инфраструктуры;
• с другой стороны, нужны operations (назовём их баззвордом DevOps), которые умеют программировать на хорошем промышленном уровне;
• с третьей стороны, бизнесу нужен баланс между надёжностью и доступностью этих систем и их стоимостью.

И что с этим делать?

Как решить все эти проблемы? Решение мы нашли в книге «Site Reliability Engineering» от Google. Когда прочли, поняли — это то, что нам нужно.

Но есть нюанс — чтобы всё это внедрить нужны годы, и с чего-то надо начинать. Рассмотрим исходные данные, которые у нас были изначально.

Вся наша инфраструктура почти полностью живет в Microsoft Azure. Есть несколько независимых кластеров для прода, которые разнесены по разным континентам: Европа, Америка и Китай. Есть нагрузочные стенды, которые повторяют продакшн, но живут в изолированной среде, а также десятки DEV-окружений для команд разработчиков.

Из хороших практик SRE у нас уже были:

• механизмы мониторинга приложений и инфраструктуры (спойлер: это мы в 2018 думали, что они хорошие, а сейчас уже всё переписали);
• процессы для дежурств 24/7 on-call;
• практика ведения постмортемов по инцидентам и их анализ;
• нагрузочное тестирование;
• CI/CD-пайплайны для прикладного софта;
• хорошие программисты, которые пишут хороший код;
• евангелист SRE в команде инфраструктуры.

Но были и проблемы, которые хотелось решить в первую очередь:

Команда инфраструктуры перегружена. На глобальные улучшения не хватало времени и сил из-за текущей операционки. Например, мы очень долго хотели, но не могли избавиться от Elasticsearch в своём стеке, или продублировать инфраструктуру у другого облачного провайдера, чтобы избежать рисков (тут могут посмеяться те, кто уже пробовал в мультиклауд).

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

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

Онбординг SRE-команды

Чтобы решить эти проблемы и как-то начать двигаться в сторону SRE, мы запустили проект онбординга. Только это был не классический онбординг — обучение новых сотрудников (новичков), чтобы добавить людей в текущую команду. Это было создание новой команды из инженеров инфраструктуры и программистов — первый шаг к полноценной структуре SRE.

На проект мы выделили 4 месяца и поставили три цели:

1. Обучить программистов тем знаниям и навыкам, которые необходимы для дежурств и операционной деятельности в команде инфраструктуры.
2. Написать IaC — описание всей инфраструктуры в коде. Причём это должен быть полноценный программный продукт с CI/CD, тестами.
3. Пересоздать всю нашу инфраструктуру из этого кода и забыть про ручное накликивание виртуалок мышкой в Azure.

Состав участников: 9 человек, 6 из них из команды разработки, 3 из инфраструктуры. На 4 месяца они должны были уйти из обычной работы и погрузиться в обозначенные задачи. Чтобы поддерживать «жизнь» в бизнесе, ещё 3 человека из инфраструктуры остались дежурить, заниматься операционкой и прикрывать тылы. В итоге проект заметно растянулся и занял больше пяти месяцев (с мая по октябрь 2019-го года).

Две составляющие онбординга: обучение и практика

Онбординг состоял из двух частей: обучения и работы над инфраструктурой в коде.

Обучение. На обучение выделялось минимум 3 часа в день:

• на чтение статей и книг из списка литературы: Linux, сети, SRE;
• на лекции по конкретным инструментам и технологиям;
• на клубы по технологиям, например, по Linux, где мы разбирали сложные случаи и кейсы.

Ещё один инструмент обучения — внутреннее демо. Это еженедельная встреча, на которой каждый (кому есть, что сказать) за 10 минут рассказывал о технологии или концепции, которую он внедрил в нашем коде за неделю. Например, Вася поменял пайплайн работы с Terraform-модулями, а Петя переписал сборку образов на Packer.

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

Практика. Вторая часть онбординга — создание/описание инфраструктуры в коде. Эту часть разделили на несколько этапов.

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

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

Написание кода. Сюда входило само написание кода, создание CI/CD-пайплайнов, тестов и построение процессов вокруг всего этого. Мы написали код, который описывал и умел создавать с нуля нашу дев-инфраструктуру.

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

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

Практики Extreme Programming в инфраструктуре

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

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

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

Всё могло бы сложиться хорошо, но так не бывает.

Технические и антропогенные проблемы на пути

В рамках проекта было два вида проблем:

• Технические: ограничения «железного» мира, недостаток знаний и сырые инструменты, которыми приходилось пользоваться, потому что других нет. Это привычные любому программисту проблемы.
• Человеческие: взаимодействие людей в команде. Общение, принятие решений, обучение. С этим было хуже, поэтому нужно остановиться подробнее.

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

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

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

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

Но избежать этого столкновения невозможно. Если позовёте в проект сильных программистов и слабых инженеров инфраструктуры, то у вас будет однонаправленный обмен знаний. Наоборот тоже не работает — одни проглотят других и всё. А вам нужно получить некую смесь, поэтому нужно быть готовым к тому, что «притирка» может оказаться очень долгой (в нашем случае мы смогли стабилизировать команду лишь спустя год, попрощавшись при этом с одним из самых сильных в техническом плане инженеров).

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

Итоги онбординга

По итогам проекта онбординга (он завершился в октябре 2019 года) мы:

• Создали полноценный программный продукт, который управляет нашей DEV-инфраструктурой, с собственным CI-пайплайном, с тестами и прочими атрибутами качественного программного продукта.
• Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE. Теперь они могут потушить пожар на проде, проконсультировать команду программистов по НФТ, или написать свою библиотеку для разработчиков.
• Сместили майндсет в сторону идей SRE. Не только у участников проекта онбординга, но и у тех программистов из продуктовых команд, которые теперь могут разговаривать с нами на одном языке.
• Сильно устали: и те, кто участвовал в онбординге, и те, кто участвовал в дежурствах.

Вместо выводов: инсайты, не наступайте на наши грабли

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

Инфраструктура пока в прошлом. Когда я учился на первом курсе (15 лет назад) и начинал изучать JavaScript, у меня из инструментов были NotePad ++ и Firebug для отладки. C этими инструментами уже тогда нужно было делать какие-то сложные и красивые вещи.

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

Для меня, как энтерпрайз-разработчика, использовать на проде такие вещи – абсурд. Но других просто нет.

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

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

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

Часто под кодом скрываются обычные конфиги и DSL. При этом вся логика происходит где-то глубже, куда нет доступа. Это сильно меняет подход к коду, тестированию и работе с ним.

Не бойтесь пускать разработчиков в инфраструктуру. Они могут привнести полезные (и свежие) практики и подходы из мира разработки ПО. Пользуйтесь практиками и подходами от Google, описанными в книге про SRE, получайте пользу и будьте счастливы.

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

PPS: Эта статья написана по моему выступлению на DevOpsConf осенью 2019 года. С тех пор прошло довольно много времени, и теперь уже точно понятно, что всё было не зря: тойл теперь не съедает бОльшую часть времени инженеров, наша команда теперь может реализовывать крупные долгосрочные проекты по улучшению инфраструктуры в широком смысле, а программисты почти не жалуются на безумных DevOps-инженеров, которые только мешают жить.

PPPS: В этом году конференция, посвящённая DevOps-практикам, будет называться DevOps Live 2020. Изменения коснутся не только названия: в программе будет меньше докладов и больше интерактивных обсуждений, мастер-классов и воркшопов. Рецепты о том, как расти и перестраивать процессы с помощью DevOps-практик. Формат также изменится — два блока по два дня и «домашние задания» между ними.

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