Что значит “тестировать блокчейн”?

#testing #blockchain
Блокчейн - это “хайповая тема” последних лет. Каждый второй делает свою криптовалюту, каждый третий открывает криптовалютный обменник на углу.
Чтобы получше понять, зачем этот самый блокчейн нужен, очень рекомендую статью Вастрика на эту тему

Но что значит “тестировать блокчейн” ? Насколько глубокими и техническими должны быть знания тест инженера для работы с такими системами? Давайте разберемся вместе.

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

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

Связь с блокчейном на бекенде происходит через API запросы. Часто это не HTTP REST API, а что-то более специфическое, такое как gRPC.
API может быть как сторонней системой вообще, так и просто узлом блокчейн сети, который развернут внутри системы.
Кроме того, остальные подходы к тестированию и автоматизации приложений - сохраняются:
- функциональное и нефункциональное тестирование
- UI / API тесты (и автотесты)

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

Основной аспект при тестировании - это использование специальных тестовых (TESTNET) блокчейн сетей для проведения транзакций. В таких сетях валюта технически такая же, как и реальная - но не стоит ничего.

Кроме того, могут быть еще и специфические виды кошельков в виде отдельных электронных устройств. А это отдельный интересный мир embedded девайсов.

Тестирование смарт контрактов и прочего DeFi.
Смарт контракты - это программный код, который релизует некую бизнес логику и загружен на блокчейн. Чаще всего под смарт контрактами имеют в виду код на языке Solidity в блокчейне Ethereum.

Тут подходы к тестированию как стандартные, так и необычные:
- юнит тесты
- функциональные тесты
- тесты безопасности

Необычность тестирования в том, что как только код отправлен в блокчейн (“задеплоен на прод”) - он начинает работать сразу. Его крайне сложно “остановить”. А уж удалить и “передеплоить” - так вообще невозможно.

Тестирование криптовалютных бирж
Биржы это обычно веб (или мобайл) приложения, который позволяют завести там аккаунт и заниматься торговлей и конвертацией разных криптовалют.
Очень похожи по своей сути на обычные сайты по банкингу и работе с валютой.

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

Как “быстро” проверить gRPC сервис?

#grpc #testing #tools
HTTP API приходится тестировать часто. Можно быстро сделать запрос с помощью cURL. Можно написать пару тестов на Java+RestAssured. Можно не усложнять - и использовать Postman.

Но что делать, когда надо быстро проверить работу сервиса, а он работает не по HTTP, а по gRPC? Как быть?

Postman судя по всему довольно криво поддерживает gRPC.
Генерировать клиент на основе протобафа и писать почти полноценный сервис для проверки одного-двух запросов - слишком долго и сложно.

На помощь приходит простой и удобный инструмент - grpcurl Он позволяет делать запросы на Ваши сервиса очень похоже, как бы Вы делали это с помощью cURL.
Перед использованием, убедитесь, что reflection включен на серверной стороне. Иначе, работать запросы не будут.

Для тех, кто не хочет связываться с терминалом - есть UI надстройка для grpcurl - gRPCox.

Почему gRPC тестировать несколько сложнее, чем обычный HTTP REST?

#grpc #testing
АПИ тестирование и автоматизация уже давно не “магия”. Львиную долю АПИ, которое проходится тестировать составляет HTTP REST. Изредка “завозят” что-то посложнее - например веб сокеты.

Когда тестировщик проводит проверку АПИ, тесты сводятся к следующим шагам:
1. Отправь один запрос (GET, POST, PUT, DELETE, etc) на сервер
2. Получи один ответ от сервера (в разумное время)
3. Проверь содержание ответа

Как валидация будет происходить (cURL’ом, Postman’ом, кодом) - не так важно.

В случае с gRPC ситуация несколько усложняется:
- данные передаются в бинарном виде. Значит просто так в консоли браузера запросы не посмотришь. (Нужен прокси).
- передача данных между клиентом и сервером в виде унарных запросов (один запрос - один ответ) - это лишь один из возможных вариантов коммуникации

Методы коммуникации в gRPC, которых нет в HTTP REST:

- Server Streaming RPC. Клиент отправляет один запрос серверу, а в результате получает поток ответов. Клиент в этом случае сам решает, читать ли до конца потока или до наступления иного события (таймаута по времени или наличия специфического поля в ответе)

- Client Streaming RPC. Клиент формирует поток сообщений и отправляет на сервер. После обработки сообщений, сервер возращает лишь один ответ клиенту.

- Bidirectional streaming RPC. Обе стороны (клиент и сервер) отправляют друг другу потоки сообщений. Потоки независимы, потому клиент и сервер могут обрабатывать сообщения паралелльно (как захотят).

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

Потоки и тестирование производительности
Из-за того, что потоки могут быть как на стороне клиента, так и на стороне сервера - усложняется не только функциональная часть тестирования.
Не все инструменты нагрузочного тестирования могут “из коробки” работать с потоками в gRPC. Например такие инструменты как k6.io или ghz работают только с единичными запросами и ответами в gRPC. Gatling и JMeter из коробки вообще не поддерживают gRPC - но хотя бы имеют плагины для такой функциональности.

Что такое консенсус в распределенных системах?

#distributedsystems #blockchain
Представим, что у нас есть система из четырех сервисов (S1, S2, S3 и S4). Так же есть пользователи (U1, U2, U3), которые делают запросы к сервисам.

Предположим, что есть два вида запросов: первый записывает данные в систему, а второй читает их.

Когда пользователь делает запрос, он не знает, на какой именно сервис попадет этот запрос. То же происходит и при чтении данных.

Вполне может случиться ситуация, когда пользователь U1 делает запрос на запись (set x = 10) на сервис S1, в это же время пользователь U2 делает запрос на запись (set x = 20) на сервис S3. Возникает вопрос - какое значение x получит пользователь U3 при отправке запроса на S4?

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

Ошибка при работе с Shadow DOM в Chrome 96+ (Selenium 3 и 4)

Утром открыл юай тесты и оказалось, что все они начали падать по неведомой причине.

Ошибка вот такая:
“java.lang.ClassCastException: class com.google.common.collect.Maps$TransformedEntriesMap cannot be cast to
class org.openqa.selenium.WebElement (com.google.common.collect.Maps$TransformedEntriesMap and
org.openqa.selenium.WebElement are in unnamed module of loader 'app')“

Оказалось, что Chrome поменял механизм работы с shadow DOM элементами и так просто закастить их в WebElement нельзя.

Вот тут - Titus описал как это можно побороть. Как раз попробую сегодня.

Мой топ 5 ИТ книг в 2021

#books
Designing Data-Intensive Applications (M. Klepmann)
Монументальный труд по современным распределенным системам. Читается сложно (на русском даже сложнее чем на английском).
Прокачивает знания с теоретической и (немного) практической сторон. Хорошим подспорьем к книге будет бесплатный курс от автора на Youtube.
Книга будет очень полезна, если вы работаете над сложными распределенными системами. По тестированию тут не так много, но зато почти каждая концепция дается с позиции “как это может не работать и упасть”.

Блокчейн и децентрализованные системы (П. Кравченко, Б. Скрябин)
Книга имеет три части и была создана в первую очередь, как учебное пособие по блокчейну для университетов.
Самый главный плюс книги в том, что она не упрощает концепции - а объясняет их так, как они работают.
Просто must-have если вы стартуете в блокчейн проектах и хотите знать “как это работает изнутри”.
Внимание, тут есть немного математики.

Leading Quality (R. Cummings-John, O. Peer)
Очень небольшая, но крайне полезная книга о том, как “драйвить” качество в организациях. Вроде бы многое из сказанного и так знаешь - но мысли сформулированы лаконично и почти без воды.
Книга хорошо ставит “продуктовое” мышление.
После нее просто хочется идти и менять свой проект к лучшему).
И да, тут не будет кокретных инструментов, техник тест-дизайна и всего прочего. Это книга про общий подход и мышление.

How Technology Works (DK)
Энциклопедия о том, как работают технологии и устройства вокруг нас. Не только компьютеры и спутники, но бытовые приборы, сельскохозяйственная техника, медицинское оборудование.
Очень хотел бы, чтобы такая книга попалась мне в руки в школьные годы.
Информация балансирует на грани между “совсем просто” и “нужно знания физики и электроники, чтобы понять”.
А еще, книга здорово поможет объяснить детям как и почему работают устройства вокруг.
P.S. Если читать на английском языке - можно здорово обогатить свой словарный запас.

Functional Programming, Simplified (Alvin Alexander)
Отличная книга для тех, кто хочет "вьехать" в фунциональное программирование на Scala. Читается достаточно легко и что самое главное - автор строит сложные концепции на основе простых. Никаких функторов и хвостовой рекурсии на первой странице).

Ось тут Курсера на місяц коштує всього 1 доллар. (Тільки сьогодні 29.11.21)

Что нужно знать, чтобы тестировать блокчейн?

#distributedsystems #blockchain

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

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

Что же нужно знать и понимать, чтобы тестировать блокчейн (базово)?

1. Хеширование
2. Немного криптографии (ассиметричной)
3. Протоколы консенсуса и их виды
4. Распределенные системы и способы коммуникации между узлами в сети
5. Модели транзакции: UTxO (Bitcoin) или account-based (Ethereum)
6. Из чего состоят транзакции и как хранятся (привет Merkle деревья :) )
7. Типы блокчейнов (Mainnet vs Testnet, открытые и закрытые)
8. Виды кошельков и принципы их работы
9. Смарт-контракты (зачем они нужны)

В случае, если вы используете смарт-контракты:

10. Языки программирования смарт-контрактов - Solidity, Plutus (если вам нужно будет это тестировать)
11. Инструменты локального развертывания тестовых блокчейнов
12. Инструменты тестирования смарт контрактов
13. Уязвимости и проблемы блокчейнов в целом и смарт-контрактов в частности

Структурные свойства протоколов консенсуса (в блокчейне)

#blockchain
В своей научной работе авторы выделяют такие структурные свойства протоколов консенсуса:

1. Тип узла в системе
2. Тип структуры - то, как узлы структурированы в системе
3. Механизм работы консенсуса

По типам структуры различают блокчейн системы с одной или несколькими группами (committees), принимающими решения.

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

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

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

Свойства безопасности и производительности протоколов консенсуса в блокчейне

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

На какие свойства безопасности консенсуса обращают внимание?

- authentication (аутентифицирован ли узел, принимающий участие в протоколе консенсуса)
- non-repudation (есть возможность у узла отрицать факт отправления транзакции)
- censorship resistance (стойкий ли протокол к цензуре)
- attack vectors (может ли протокол противостоять различным векторам атак - denial of service, sybil attack, nothing at stake и другие)

Что касается производительности, то выделяются такие свойства:

- fault-tolerance (какое максимально количество вышедших из строя узлов может выдержать протокол)
- throughput (количество транзакций в секунду)
- scalability (способность сохранять производительность при условии роста числа узлов)
- latency (finality) (время от момента, когда транзакция предложеня к включению в блок до момента достижения консенсуса по ней во всей сети)
- energy consumption (сколько энергии тратится системой для достижения консенсуса)

Проблемы найма на "горячем" ИТ рынке (с точки зрения инженера)

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

"Ищем много месяцев и нет результатов", "Приходят люди без скиллов и просят много денег", "Куда катится ИТ рынок?", "Кандидаты не отвечают на письма", "Никто не хочет идти к нам работать".

За 10 лет в украинском ИТ я был как на стороне интервьюера, так и на стороне кандидата. Все пункты ниже основываются только лишь на моем опыте. Ваш опыт может быть совершенно другим.

Какие же главные блокеры в найме я вижу:

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

2. Вы (или Ваш заказчик) хотите найти единорога на 100% соответствующего описаниям вакансии. Очень часто при составлении описания вакансии, заказчик хочет включить сразу все инструменты и процессы, которые есть или даже будут (может быть) в будущем в компании. В результате, процесс поиска кандидата превращается в "поиск Святого Грааля", который работал со свсеми технологиями и фреймворками ровно указанное количество лет.

3. Ваш процесс собеседования кардинально отличается от работы. Я видел много примеров, когда кандидата гоняли по жестким алгоритмам и прочему Computer Science - а в результате приходилось потом просто тестировать руками. Не вижу мануальном тестировании ничего плохого (сам занимаюсь), но плохо когда кроме мануального тестирования нет возможности улучшать процессы или инструменты и применять инженерные навыки. Синьйоры и выше не будут 100% времени проходить регрешн. Для этого есть крауд-тестирование.
Тут же стоит и "больная мозоль" - тестовое задание. О нем я поговорю как-нибудь в следующий раз.

4. У Вашей компании отсутствует или слабо развит технический бренд. Очень много компаний "забивает" на технический бренд - а зря. Именно бренд может помочь Вам найти крутого специалиста не имея зарплатного бюджета выше рынка. Задайте себе вопрос - как Вы можете заинтересовать кандидата, кроме ЗП?. Я вижу такие варианты:
1. В компании работают топовые специалисты и очень интересно поработать с ними (и поучиться их уникальному опыту)
2. Компания делает продукт, который помогает обществу или просто находится "на острие технологий".
3. В компании очень много open-source инструментов, которые можно развивать в рабочее время.
4. У компании полезный технический (не маркетинг!) блог или ютуб канал с кучей полезных ресурсов, которые помогают комьюнити.
Я видел много примеров, когда технический бренд привлекает действительно много кандидатов. И много крутых специалистов. Конечно это не означает, что все кандидаты будут подходящими. Но по крайней мере время на начальный поиск людей может сократиться. Дальше уже дело за интервью.

В заключение скажу, что вижу много примеров, когда люди закрывают позиции довольно быстро. Значит - не все еще потеряно на нашем текущем "горячем" ИТ рынке.

Удачи в поисках скилловых кандидатов!

Что такое хеширование и как его тестировать?

#blockchain #hashing
Изучая блокчейн, буквально в каждом втором предложении вы будете слышать если не про распределенные системы и консенсус, то про хеширование и хеш-функции.

Что такое хеширование?
Хеширование - это процесс "превращения" массива данных произвольной длины в битовую последовательность фиксированной длины с помощью хеш-функции. Например, текст "Test Engineering Notes" после применения функции SHA-256 будет иметь вид dc3101f57c983aa68499306de0e60cb7266e3b1ae2235a84aa0d727f0f07b18f

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

Зачем это?
Хеширование используется в просто огромном количестве мест в ИТ: это эти ваши HashMap и HashЧто-Либо еще (привет любимые вопросы на собеседованиях), получение уникальных айди обьектов, хранение паролей, вычисление контрольных сумм, создание электронно-цифровых подписей,
В блокчейне тоже используется хеширование, но с помощью криптографических хеш-функций.

Что такое "хорошая" криптографическая хэш-функция?
1. Стойкость к коллизиям. Идеальная хеш-функция позволяет преобразовать данные в уникальный результат. Если два разных набора данных дают на выходе один и тот же результат - 'это называется коллизия.
2. При наличии хэша H трудно найти такое сообщение M, чтобы hash(M) = H.
3. При наличии сообщения M трудно найти другое сообщение N, чтобы hash(M) = hash(N).

Какие хеш-функции есть?
Самые известные - MD4, MD5, SHA-1, RIPEMD-160, BLAKE, Whirlpool. В блокчейне часто используются SHA-256, SHA-3 (Keccak) - как наиболее стойкие. Но в каждом новом "революционном" блокчейне стараются придумать и "новую" хеш-функцию. И доказать, что их функция "the best of the best of the best".

Как это тестировать?
Один из главных показателей качества хеш-функций - это вероятность получения коллизий.

Обычно тестируется равномерность распределения хеш-значений с помощью критерия Хи-квадрата. По сути сравнивается фактическое распределение элементов с ожидаемым (равномерным) распределением. Отношение в пределах доверительного интервала должно быть в диапазоне 0.95 - 1.05.

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

Как тестировать случайность?

#testing
Ситуация
Представим: вы пришли на собеседование на позицию инженера по тестированию. И тут, вам дают приложение с применением math.Random (или сайт Random.org) и спрашивают - как проверить, что числа, которые генерирует приложение - случайны?

Что такое генерация случайных чисел?
В общем случае, генерация случайных чисел - это процесс, который с помощью устройства (или алгоритма) генерирует последовательность чисел или символов. Последовательность будет случайной, если каждое ее значение, полученное при генерации нельзя точно предсказать до момента генерации.
Классическим примером является подрасывание монеты или тасование игральных карт.

Как получают генераторы случайных чисел?
Кроме генераторов случайных чисел, есть еще и генераторы псевдослучайных чисел (в которых числа только выглядят случайными, но генерируются по строго определнному алгоритму). Такой алгоритм можно "взломать" и дальше предугадывать числа в последовательности.
Если добавить с генератору псевдослучайных числе аппаратный источник случайности - то уже можно получить достаточно случайные величины.

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

Так как же правильно протестировать генератор случайных чисел?
Самый простой вариант теста, это сгенерировать N чисел подряд и убедиться, что они не повторяются (при условии, если диапазон чисел достаточно большой).
Но достаточно ли такого теста? Помогут ли вам в этом случае техники тест дизайна?

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

Поэтому применяются такие варианты тестов:

1. Визуальный. На основе чисел делаем большое bitmap изображение и смотрим нет ли повторений и закономерностей.
2. Статистические тесты случайности (используются NIST - Национальном институте стандартов и технологий США). Таких тестов - пятнадцать. Среди них - частотные тесты, дискретное преобразование Фурье, апериодические тесты, тесты линейной сложности. Но в большинстве случаев, они нанравлены на поиск повторяющихся шаблонов в последовательности.

В комментарии я приведу пример визуального теста.

А как вы тестируете случайность?

Как правильно задавать вопросы?

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

Почему одни люди с готовностью отвечают на вопросы (даже самые тривиальные) и могут это делать буквально часами. Почему другие - раздражаются на любой вопрос, отсылают вас в Гугл или "сдувать пыль" со старых статей на Confluence?

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

Что такое хороший вопрос? Этот тот вопрос, на который легко ответить.

Какие техники помогают сделать вопросы легче для отвечающего?

1. Озвучьте то, что уже знаете. Озвучьте факт или объясните как вы понимаете концепцию и добавьте "не так ли / я прав?"

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

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

4. Определите термины которых вы не знаете. Когда вы только приходите на новый проект - вас может "захлестнуть" обилие новых терминов (как технический так и бизнес). Хороший совет - собирать эти термины в своего рода личный вики (словарь) и постепенно искать значения для каждого.

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

6. Решите кого спрашивать.
Задайте себе такие вопросы:
- Сейчас самое время задать вопрос для этого человека?
- Сколько времени займет ответ на ваш вопрос? Может стоит забронировать отдельный митинг с нужным человеком, чем отвлекать его/ее сейчас?
- Обладает ли этот человек нужным уровнем знаний для ответа на вопрос? Не слишком ли он синьйорный для вашего вопроса? Может лучше задать вопрос не лиду, а другому инженеру - и таким образом укрепить его знания в момент ответа.

А как вы задаете вопросы?

Протоколы консенсуса в блокчейне: Proof Of Work

#blockchain #consensus #distributedsystems
Протоколы консенсуса в блокчейне согласно Md Sadek Ferdous и другим авторам научной работы, можно поделить на три большие группы: Proof Of Work, Proof Of Stake и гибридные.

Сегодня мы разберемся, какие бывает протоколы типа Proof Of Work (PoW).

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

За решение задачи валидатор (майнер) получается плату за создание блока и процент от каждой транзакции. Плата за создание блока уменьшается в два раза каждые четыре года.

Сложность задачи в системе постоянно подстраивается - чтобы время на ее решения всегда в среднем занимала определенное количество времени (в Биткоине это 10 минут).

Какие есть различные виды протоколов?
PoW протоколы консенсуса можно поделить на Compute-bound, Memory-Bound и Chained.

Compute-bound Proof Of Work. Алгоритмы этой группы используют вычислительные мощности процессора для решения сложной задачи. Начиналось все с использования обычных CPU, потом продолжили майнить на видеокартах с большим GPU. Как результат эволюции - были придуманы устройства специально для майнинга - ASIC (Application-specific Integrated Circuit).

Примеры алгоритмов консенсуса это Hashcash (предложен для борьбы со спамом) и Nakamoto consensus (используется в Bitcoin).

Memory-Bound Proof Of Work. На заре Биткоина Compute-bound алгоритмы давали возможность майнить любому человеку почти на любом достаточно современном компьютере. Сейчас участвовать в майнинге может далеко не каждый. Для майнинга надо закупаться спец устройствами за большие деньги.

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

Примеры таких алгоритмов: CRYPTONIGHT, SCRYPT, EQUIHASH, ETHASH/DAGGER (используется в Ethereum), NEOSCRYPT.

Chained Proof Of Work. Суть "связанных" алгоритмов консенсуса заключается в применении нескольких хеш функций подряд. Это повышает стойкость к взлому хеш функций (например с помощью квантовых вычислений). Да и подбирать такие хеши с помощь ASIC устройств очень сложно.
Примерами связанных алгоритмов являются - X11/X13/X15, Lyra2RE, Magnificent 7.

А какие у них есть проблемы у Proof Of Work протоколов консенсуса?

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

Централизация майнинга. Для современного майнинга нужны колоссальные ресурсы. Люди понимают это, потому соединяются в группу "pools" для повышения вероятности получить нужный хеш быстрее. Такие пулы майнеров огромны и уже стремятся к централизации. До недавнего времени, большинство крупных пулов было сосредоточено в Китае.

Tragedy of commons (Трагедия общества). За решение задачи валидатор (майнер) получается плату за создание блока и процент от каждой транзакции. Плата за создание блока уменьшается в два раза каждые четыре года. Эти две платы и есть главными "стимулами", почему люди майнят крипту. В Биткоине технически "зашито", что плата за блок в какой-то момент станет равна нулю.
Трагедией общества в экономической теории называют процесс, когда каждый участник стремится максимизировать только свою прибыль путем истощения ресурса общественного пользования. В контексте Биткоина, когда плата за блок станет равна нулю, валидаторы будут стремиться включить как можно больше транзакции (и получить процент от каждой из них). Со временем, процент платы за транзакцию может стремиться к минимуму. Таким образом стимул майнить - пропадет вообще.

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

В завершение хотел бы поделиться несколькими таблицами, которые описывают различные свойства косенсусов Proof Of Work. (в комментарии).

Советы для собеседующихся на тест инженера (автоматизатора)

#softskills #interview
Мы все ходим собеседования. А некоторые из нас даже их проводят.
Сегодня я поделюсь парой советов о том что делать и что не делать при прохождении собеседования для тестировщика или автоматизатора.

Что делать:

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

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

3. Будьте готовы к вопросу - "Почему вы писали именно эти тесты (делали эту работу именно так)?".

4. Не забудьте спросить о текущем состоянии проекта и дальнейших планах на развитие. Этот вопрос со стороны кандидата помогает понять - зачем вообще идти работать в этот конкретный проект? Понимают ли люди зачем тестирование и автоматизация?

5. Будьте готовы к вопросы об архитектуре вашего приложения и фреймворка. Синьор, который вообще не интересуется тем, как работает приложение, происходит деплой, какие виды тестов пишут разные инженеры в компании - это скорее всего или недостаток опыта, или "зашоренность" взглядов и отсутствие стратегического мышления.

Что лучше НЕ делать:

1. Выкладывать ваш фреймворк с предыдущей работы на Github. Встречался несколько раз с таким. Особенно прекрасно выглядят пароли для тестовых или "боевых" баз данных в открытом виде в проперти файлах. Такое лучше вообще не делать.

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

3. Говорить: "Я вообще не знаю, как работает этот код - просто скопировал со StackOverflow". Конечно же, все мы рано или поздно лезем на SO в поисках ответов. Но по крайней мере - разбирайте как код работает, перед тем как сделать Ctrl+C / Ctrl+V.

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

Завтра (14.12.21) я буду рассказывать немного о проблемах современного тестирования на митапе Andersen Lab. Приходите) https://www.linkedin.com/posts/andersen-softwaredev_qa-soft-skills-2-in-1-meetup-its-freezing-activity-6867084229293969408-6yYM/

Как правильно отвечать на вопросы?

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

И опять у Julie Evans есть замечательный пост на эту тему. Далее я кратко опишу основные моменты из поста.

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

Определите, что они уже знают.
Крайне полезная техника при работе с людьми любого уровня (как с инженерами, так и с менеджерами). Перед тем как отвечать на вопрос, попробуйте узнать, что уже знает задающий. Причем более эффективно будет не просто спросить "Знаешь ли ты технологию (термин) Х?", а "Насколько ты знаком с Х?".

Укажите на документацию.
Если ответ на вопрос действительно можно легко найти в документации - укажите на него. Не просто "посылайте в Гугл-Вики (RTFM)", а хотя бы укажите приблизительно, в каком разделе искать ответ. Этот прием не поможет, если документация безнадежно устарела или таковой у вас на проекте просто нет.

Напишите (обновите) документацию, если нужно.
Вы можете дать ответ и обновить документацию сами. Или, как вариант, поручить обновление документации человеку, который вопрос и задавал.

Поясните, что вы сделали.
Если на вопрос "Как ты сделал это?" вы просто отвечаете "Уже пофиксил, обнови ветку (перезагрузи страницу)" - это не принесет много пользы задающему. Гораздо лучше будет пройтись вместе по этапам инвестигейта/фикса и пояснить что и ПОЧЕМУ вы сделали.

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

Уточните - "Это ответило на твой вопрос?".
Это поможет определить понял ли человек ответ на вопрос. Но нужно быть осторожным. Иногда джуниору проще сказать "Да, я понял", чем признать, что признать что не знает многого из ответа.

Предложите сессию парного программирования (тестирования).
Крайне полезная техника для менторинга или онбординга. Можно даже делать сессии парного программирования вида "девелопер + тест инженер".

Не нужно выглядеть удивленным! Это - самый простой способ понизить самооценку человека и отбить у него желание задавать вопросы (развиваться).
Например: - "Ты не подскажешь, что такое JSON?” - "Как? Ты что, не знаешь даже, что такое JSON?"
Не делайте так. (Вслух я такого никогда не говорил, но в мыслях проскакивало и не раз. Важно понимать, что опыт у всех разный и люди все разные.).

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

Очень советую прочесть оригинальный пост. Примеров и пояснений там намного больше.

Видео моего доклада с Andresen Meetup

#video #softskills #career

14 декабря я принял участие в митапе от компании Andresen. Это был мой первый опыт онлайн конференции - когда нужно говорить в камеру, сидя за столом и без людей в аудитории.

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