Мой топ 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. Читается достаточно легко и что самое главное - автор строит сложные концепции на основе простых. Никаких функторов и хвостовой рекурсии на первой странице).
#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)
Coursera
Coursera Plus | Unlimited Access to 7,000+ Online Courses
Invest in your professional goals with Coursera Plus. ...
Что нужно знать, чтобы тестировать блокчейн?
#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. Уязвимости и проблемы блокчейнов в целом и смарт-контрактов в частности
#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. Уязвимости и проблемы блокчейнов в целом и смарт-контрактов в частности
Telegram
Test Engineering Notes
Что такое консенсус в распределенных системах?
#distributedsystems #blockchain
Представим, что у нас есть система из четырех сервисов (S1, S2, S3 и S4). Так же есть пользователи (U1, U2, U3), которые делают запросы к сервисам.
Предположим, что есть два…
#distributedsystems #blockchain
Представим, что у нас есть система из четырех сервисов (S1, S2, S3 и S4). Так же есть пользователи (U1, U2, U3), которые делают запросы к сервисам.
Предположим, что есть два…
Структурные свойства протоколов консенсуса (в блокчейне)
#blockchain
В своей научной работе авторы выделяют такие структурные свойства протоколов консенсуса:
1. Тип узла в системе
2. Тип структуры - то, как узлы структурированы в системе
3. Механизм работы консенсуса
По типам структуры различают блокчейн системы с одной или несколькими группами (committees), принимающими решения.
В системах с одной группой принимающей решения вход в группу может быть как открытым для всех, так и закрытым. По конфигурации группа может быть статически зафиксированной или динамической (например меняться со временем).
В блокчейнах, где блоки могут создавать несколько независимых групп узлов важную роль играет топология организации групп. Они могут быть как равноправными, так и часть иерархии (с разными полномочиями).
Механизм работы консенсуса может основываться на принципе лотереи (может быть как полностью случайной так и вероятностной), голосования или также на возрасте коина, которым располагает пользователь.
#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 (сколько энергии тратится системой для достижения консенсуса)
#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. У компании полезный технический (не маркетинг!) блог или ютуб канал с кучей полезных ресурсов, которые помогают комьюнити.
Я видел много примеров, когда технический бренд привлекает действительно много кандидатов. И много крутых специалистов. Конечно это не означает, что все кандидаты будут подходящими. Но по крайней мере время на начальный поиск людей может сократиться. Дальше уже дело за интервью.
В заключение скажу, что вижу много примеров, когда люди закрывают позиции довольно быстро. Значит - не все еще потеряно на нашем текущем "горячем" ИТ рынке.
Удачи в поисках скилловых кандидатов!
#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%).
#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 - Национальном институте стандартов и технологий США). Таких тестов - пятнадцать. Среди них - частотные тесты, дискретное преобразование Фурье, апериодические тесты, тесты линейной сложности. Но в большинстве случаев, они нанравлены на поиск повторяющихся шаблонов в последовательности.
В комментарии я приведу пример визуального теста.
А как вы тестируете случайность?
#testing
Ситуация
Представим: вы пришли на собеседование на позицию инженера по тестированию. И тут, вам дают приложение с применением math.Random (или сайт Random.org) и спрашивают - как проверить, что числа, которые генерирует приложение - случайны?
Что такое генерация случайных чисел?
В общем случае, генерация случайных чисел - это процесс, который с помощью устройства (или алгоритма) генерирует последовательность чисел или символов. Последовательность будет случайной, если каждое ее значение, полученное при генерации нельзя точно предсказать до момента генерации.
Классическим примером является подрасывание монеты или тасование игральных карт.
Как получают генераторы случайных чисел?
Кроме генераторов случайных чисел, есть еще и генераторы псевдослучайных чисел (в которых числа только выглядят случайными, но генерируются по строго определнному алгоритму). Такой алгоритм можно "взломать" и дальше предугадывать числа в последовательности.
Если добавить с генератору псевдослучайных числе аппаратный источник случайности - то уже можно получить достаточно случайные величины.
Источником случайности может быть любой физический процесс, который сложно смоделировать на уровне знаний.
Например: состояние часов или серийный номер оборудования, разные шумы с видео или аудио входов, хаотическая турбулентность воздуха при поиске данных на HDD дисках, движение мышкой.
Так как же правильно протестировать генератор случайных чисел?
Самый простой вариант теста, это сгенерировать N чисел подряд и убедиться, что они не повторяются (при условии, если диапазон чисел достаточно большой).
Но достаточно ли такого теста? Помогут ли вам в этом случае техники тест дизайна?
В реальности - недостаточно. Т.к. даже генераторы псевдослучайных чисел могут иметь очень большой шаг повторения и "казаться" случайными на первый взгляд.
Поэтому применяются такие варианты тестов:
1. Визуальный. На основе чисел делаем большое bitmap изображение и смотрим нет ли повторений и закономерностей.
2. Статистические тесты случайности (используются NIST - Национальном институте стандартов и технологий США). Таких тестов - пятнадцать. Среди них - частотные тесты, дискретное преобразование Фурье, апериодические тесты, тесты линейной сложности. Но в большинстве случаев, они нанравлены на поиск повторяющихся шаблонов в последовательности.
В комментарии я приведу пример визуального теста.
А как вы тестируете случайность?
NIST
National Institute of Standards and Technology
NIST promotes U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.
👍1
Как правильно задавать вопросы?
#softskills
Каждый день на работе нам приходится задавать вопросы.
Мы задаем вопросы, когда мы на старте карьеры. Мы задаем вопросы, когда приходим на новую работу или проект. А как тест инженеры мы постоянно задаем вопросы вроде "А что если эта хреновина в системе вдруг упадет или перезагрузится?".
Почему одни люди с готовностью отвечают на вопросы (даже самые тривиальные) и могут это делать буквально часами. Почему другие - раздражаются на любой вопрос, отсылают вас в Гугл или "сдувать пыль" со старых статей на Confluence?
В своей статье, Julie Evans дает набор техник как сделать ваши вопросы удобнее и лучше для отвечающего. Далее - коротко о статье.
Что такое хороший вопрос? Этот тот вопрос, на который легко ответить.
Какие техники помогают сделать вопросы легче для отвечающего?
1. Озвучьте то, что уже знаете. Озвучьте факт или объясните как вы понимаете концепцию и добавьте "не так ли / я прав?"
2. Задавайте вопросы, где ответ - это факт. В идеальном случае отвечающий должен по вашему вопросу понять, что вы уже знаете и помочь найти то, что вы не знаете. Чем более открытый вопрос вы задаете, тем он более сложный. И ответ на него может занять очень много времени.
3. Будьте готовы сказать о том, чего вы не знаете. Вы работаете с большим количеством людей. У каждого человека разный опыт, скиллы, глубина знаний. Не бойтесь переспросить отвечающего, если вы не слышали или не понимаете термины, которые звучат в ответе. В противном случае, вы только наберетесь кучи новых терминов и не будете знать, что они означают. Такая информация (если не записана) очень быстро забывается.
4. Определите термины которых вы не знаете. Когда вы только приходите на новый проект - вас может "захлестнуть" обилие новых терминов (как технический так и бизнес). Хороший совет - собирать эти термины в своего рода личный вики (словарь) и постепенно искать значения для каждого.
5. Проведите подготовку перед тем, как спросить. Не важно джуниор вы или синьйор, перед тем, как задать вопрос или попросить помочь с дебагом - соберите как можно больше информации самостоятельно. Отсутствие предварительной подготовки со стороны задающего вопрос - частая причина, почему тех лиды и синьйоры не любят отвечать на вопросы новичков.
6. Решите кого спрашивать.
Задайте себе такие вопросы:
- Сейчас самое время задать вопрос для этого человека?
- Сколько времени займет ответ на ваш вопрос? Может стоит забронировать отдельный митинг с нужным человеком, чем отвлекать его/ее сейчас?
- Обладает ли этот человек нужным уровнем знаний для ответа на вопрос? Не слишком ли он синьйорный для вашего вопроса? Может лучше задать вопрос не лиду, а другому инженеру - и таким образом укрепить его знания в момент ответа.
А как вы задаете вопросы?
#softskills
Каждый день на работе нам приходится задавать вопросы.
Мы задаем вопросы, когда мы на старте карьеры. Мы задаем вопросы, когда приходим на новую работу или проект. А как тест инженеры мы постоянно задаем вопросы вроде "А что если эта хреновина в системе вдруг упадет или перезагрузится?".
Почему одни люди с готовностью отвечают на вопросы (даже самые тривиальные) и могут это делать буквально часами. Почему другие - раздражаются на любой вопрос, отсылают вас в Гугл или "сдувать пыль" со старых статей на Confluence?
В своей статье, Julie Evans дает набор техник как сделать ваши вопросы удобнее и лучше для отвечающего. Далее - коротко о статье.
Что такое хороший вопрос? Этот тот вопрос, на который легко ответить.
Какие техники помогают сделать вопросы легче для отвечающего?
1. Озвучьте то, что уже знаете. Озвучьте факт или объясните как вы понимаете концепцию и добавьте "не так ли / я прав?"
2. Задавайте вопросы, где ответ - это факт. В идеальном случае отвечающий должен по вашему вопросу понять, что вы уже знаете и помочь найти то, что вы не знаете. Чем более открытый вопрос вы задаете, тем он более сложный. И ответ на него может занять очень много времени.
3. Будьте готовы сказать о том, чего вы не знаете. Вы работаете с большим количеством людей. У каждого человека разный опыт, скиллы, глубина знаний. Не бойтесь переспросить отвечающего, если вы не слышали или не понимаете термины, которые звучат в ответе. В противном случае, вы только наберетесь кучи новых терминов и не будете знать, что они означают. Такая информация (если не записана) очень быстро забывается.
4. Определите термины которых вы не знаете. Когда вы только приходите на новый проект - вас может "захлестнуть" обилие новых терминов (как технический так и бизнес). Хороший совет - собирать эти термины в своего рода личный вики (словарь) и постепенно искать значения для каждого.
5. Проведите подготовку перед тем, как спросить. Не важно джуниор вы или синьйор, перед тем, как задать вопрос или попросить помочь с дебагом - соберите как можно больше информации самостоятельно. Отсутствие предварительной подготовки со стороны задающего вопрос - частая причина, почему тех лиды и синьйоры не любят отвечать на вопросы новичков.
6. Решите кого спрашивать.
Задайте себе такие вопросы:
- Сейчас самое время задать вопрос для этого человека?
- Сколько времени займет ответ на ваш вопрос? Может стоит забронировать отдельный митинг с нужным человеком, чем отвлекать его/ее сейчас?
- Обладает ли этот человек нужным уровнем знаний для ответа на вопрос? Не слишком ли он синьйорный для вашего вопроса? Может лучше задать вопрос не лиду, а другому инженеру - и таким образом укрепить его знания в момент ответа.
А как вы задаете вопросы?
Julia Evans
How to ask good questions
Asking good questions is a super important skill when writing software. I’ve gotten way better at it over the years (to the extent that it’s something my coworkers comment on a lot). Here are a few guidelines that have worked well for me!
Протоколы консенсуса в блокчейне: 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 (Трагедия общества). За решение задачи валидатор (майнер) получается плату за создание блока и процент от каждой транзакции. Плата за создание блока уменьшается в два раза каждые четыре года. Эти две платы и есть главными "стимулами", почему люди майнят крипту. В Биткоине технически "зашито", что плата за блок в какой-то момент станет равна нулю.
Трагедией общества в экономической теории называют процесс, когда каждый участник стремится максимизировать только свою прибыль путем истощения ресурса общественного пользования. В контексте Биткоина, когда плата за блок станет равна нулю, валидаторы будут стремиться включить как можно больше транзакции (и получить процент от каждой из них). Со временем, процент платы за транзакцию может стремиться к минимуму. Таким образом стимул майнить - пропадет вообще.
#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. (в комментарии).
В завершение хотел бы поделиться несколькими таблицами, которые описывают различные свойства косенсусов Proof Of Work. (в комментарии).
Советы для собеседующихся на тест инженера (автоматизатора)
#softskills #interview
Мы все ходим собеседования. А некоторые из нас даже их проводят.
Сегодня я поделюсь парой советов о том что делать и что не делать при прохождении собеседования для тестировщика или автоматизатора.
Что делать:
1. Расcказывайте о влиянии на бизнес и процессы, а не о конкретных задачах, которые вы делали. Все пишут юай или апи тесты. И фиксят падающие тесты тоже многие. Продумайте успешные реальные примеры как автоматизация помогает на вашем проекте: дает быстрый фидбек, приносит пользу команде, находит регрессионные проблемы.
2. Честно отвечайте на вопрос: "вы сами писали это решение по автоматизации и поднимали CICD процессы?". Бывают случаи, когда синьором становятся просто за "выслугу лет". То есть инженер пришел на все готовое и поддерживал его лет пять. Такой навык тоже полезен, но так же важно для опытного инженера умение строить автоматизацию с нуля (хотя бы в домашних условиях).
3. Будьте готовы к вопросу - "Почему вы писали именно эти тесты (делали эту работу именно так)?".
4. Не забудьте спросить о текущем состоянии проекта и дальнейших планах на развитие. Этот вопрос со стороны кандидата помогает понять - зачем вообще идти работать в этот конкретный проект? Понимают ли люди зачем тестирование и автоматизация?
5. Будьте готовы к вопросы об архитектуре вашего приложения и фреймворка. Синьор, который вообще не интересуется тем, как работает приложение, происходит деплой, какие виды тестов пишут разные инженеры в компании - это скорее всего или недостаток опыта, или "зашоренность" взглядов и отсутствие стратегического мышления.
Что лучше НЕ делать:
1. Выкладывать ваш фреймворк с предыдущей работы на Github. Встречался несколько раз с таким. Особенно прекрасно выглядят пароли для тестовых или "боевых" баз данных в открытом виде в проперти файлах. Такое лучше вообще не делать.
2. Продолжать интервью, если у вас проблемы со связью. Лучше извиниться и перенести звонок. Или подключиться по запасному каналу связи.
3. Говорить: "Я вообще не знаю, как работает этот код - просто скопировал со StackOverflow". Конечно же, все мы рано или поздно лезем на SO в поисках ответов. Но по крайней мере - разбирайте как код работает, перед тем как сделать Ctrl+C / Ctrl+V.
4. Указывать в вашем резюме все возможные технологии и библиотеки, на которых вы писали от силы полтора теста. Сам так делал в начале своей карьеры:). Просто помните, что по каждой технологии или языку программирования у вас в резюме могут задать вопрос.
#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/
Linkedin
Andersen Lab on LinkedIn: QA & Soft Skills - 2 in 1 meetup!
It's freezing outside, but at Andersen,…
It's freezing outside, but at Andersen,…
QA & Soft Skills - 2 in 1 meetup!
It's freezing outside, but at Andersen, it’s hot again! We are happy to announce a new free meetup - QA & Soft Skills. The…
It's freezing outside, but at Andersen, it’s hot again! We are happy to announce a new free meetup - QA & Soft Skills. The…
Как правильно отвечать на вопросы?
#softskills
В одной из прошлых заметок мы говорили о том, как правильно задавать вопросы. Но задать вопрос - это лишь пол-дела. Вторая половина - это умение грамотно отвечать на вопросы.
И опять у Julie Evans есть замечательный пост на эту тему. Далее я кратко опишу основные моменты из поста.
Если вопрос не достаточно понятный, задайте уточняющие вопросы.
Обычно новички задают очень непонятные или нечеткие вопросы (или не умеют правильно их задавать). Попробуйте перефразировать и уточнить вопрос. Узнайте более детальную информацию о том, что интересует задающего вопрос. Спросите, что привело их к данному вопросу.
Определите, что они уже знают.
Крайне полезная техника при работе с людьми любого уровня (как с инженерами, так и с менеджерами). Перед тем как отвечать на вопрос, попробуйте узнать, что уже знает задающий. Причем более эффективно будет не просто спросить "Знаешь ли ты технологию (термин) Х?", а "Насколько ты знаком с Х?".
Укажите на документацию.
Если ответ на вопрос действительно можно легко найти в документации - укажите на него. Не просто "посылайте в Гугл-Вики (RTFM)", а хотя бы укажите приблизительно, в каком разделе искать ответ. Этот прием не поможет, если документация безнадежно устарела или таковой у вас на проекте просто нет.
Напишите (обновите) документацию, если нужно.
Вы можете дать ответ и обновить документацию сами. Или, как вариант, поручить обновление документации человеку, который вопрос и задавал.
Поясните, что вы сделали.
Если на вопрос "Как ты сделал это?" вы просто отвечаете "Уже пофиксил, обнови ветку (перезагрузи страницу)" - это не принесет много пользы задающему. Гораздо лучше будет пройтись вместе по этапам инвестигейта/фикса и пояснить что и ПОЧЕМУ вы сделали.
Решите проблему, лежащую в основе.
Иногда полезнее будет не ответить на технический вопрос сразу, а докопаться до изначальной проблемы и решить ее.
Уточните - "Это ответило на твой вопрос?".
Это поможет определить понял ли человек ответ на вопрос. Но нужно быть осторожным. Иногда джуниору проще сказать "Да, я понял", чем признать, что признать что не знает многого из ответа.
Предложите сессию парного программирования (тестирования).
Крайне полезная техника для менторинга или онбординга. Можно даже делать сессии парного программирования вида "девелопер + тест инженер".
Не нужно выглядеть удивленным! Это - самый простой способ понизить самооценку человека и отбить у него желание задавать вопросы (развиваться).
Например: - "Ты не подскажешь, что такое JSON?” - "Как? Ты что, не знаешь даже, что такое JSON?"
Не делайте так. (Вслух я такого никогда не говорил, но в мыслях проскакивало и не раз. Важно понимать, что опыт у всех разный и люди все разные.).
С другой стороны, если вы наняли человека на позицию миддл-синьор, а он снова и снова задает базовые вопросы - подумайте как ему помочь на следующем ревью (или на 1-1). Быть может назначить ментора, отправить на курс или еще что-нибудь.
Очень советую прочесть оригинальный пост. Примеров и пояснений там намного больше.
#softskills
В одной из прошлых заметок мы говорили о том, как правильно задавать вопросы. Но задать вопрос - это лишь пол-дела. Вторая половина - это умение грамотно отвечать на вопросы.
И опять у Julie Evans есть замечательный пост на эту тему. Далее я кратко опишу основные моменты из поста.
Если вопрос не достаточно понятный, задайте уточняющие вопросы.
Обычно новички задают очень непонятные или нечеткие вопросы (или не умеют правильно их задавать). Попробуйте перефразировать и уточнить вопрос. Узнайте более детальную информацию о том, что интересует задающего вопрос. Спросите, что привело их к данному вопросу.
Определите, что они уже знают.
Крайне полезная техника при работе с людьми любого уровня (как с инженерами, так и с менеджерами). Перед тем как отвечать на вопрос, попробуйте узнать, что уже знает задающий. Причем более эффективно будет не просто спросить "Знаешь ли ты технологию (термин) Х?", а "Насколько ты знаком с Х?".
Укажите на документацию.
Если ответ на вопрос действительно можно легко найти в документации - укажите на него. Не просто "посылайте в Гугл-Вики (RTFM)", а хотя бы укажите приблизительно, в каком разделе искать ответ. Этот прием не поможет, если документация безнадежно устарела или таковой у вас на проекте просто нет.
Напишите (обновите) документацию, если нужно.
Вы можете дать ответ и обновить документацию сами. Или, как вариант, поручить обновление документации человеку, который вопрос и задавал.
Поясните, что вы сделали.
Если на вопрос "Как ты сделал это?" вы просто отвечаете "Уже пофиксил, обнови ветку (перезагрузи страницу)" - это не принесет много пользы задающему. Гораздо лучше будет пройтись вместе по этапам инвестигейта/фикса и пояснить что и ПОЧЕМУ вы сделали.
Решите проблему, лежащую в основе.
Иногда полезнее будет не ответить на технический вопрос сразу, а докопаться до изначальной проблемы и решить ее.
Уточните - "Это ответило на твой вопрос?".
Это поможет определить понял ли человек ответ на вопрос. Но нужно быть осторожным. Иногда джуниору проще сказать "Да, я понял", чем признать, что признать что не знает многого из ответа.
Предложите сессию парного программирования (тестирования).
Крайне полезная техника для менторинга или онбординга. Можно даже делать сессии парного программирования вида "девелопер + тест инженер".
Не нужно выглядеть удивленным! Это - самый простой способ понизить самооценку человека и отбить у него желание задавать вопросы (развиваться).
Например: - "Ты не подскажешь, что такое JSON?” - "Как? Ты что, не знаешь даже, что такое JSON?"
Не делайте так. (Вслух я такого никогда не говорил, но в мыслях проскакивало и не раз. Важно понимать, что опыт у всех разный и люди все разные.).
С другой стороны, если вы наняли человека на позицию миддл-синьор, а он снова и снова задает базовые вопросы - подумайте как ему помочь на следующем ревью (или на 1-1). Быть может назначить ментора, отправить на курс или еще что-нибудь.
Очень советую прочесть оригинальный пост. Примеров и пояснений там намного больше.
Telegram
Test Engineering Notes
Как правильно задавать вопросы?
#softskills
Каждый день на работе нам приходится задавать вопросы.
Мы задаем вопросы, когда мы на старте карьеры. Мы задаем вопросы, когда приходим на новую работу или проект. А как тест инженеры мы постоянно задаем вопросы…
#softskills
Каждый день на работе нам приходится задавать вопросы.
Мы задаем вопросы, когда мы на старте карьеры. Мы задаем вопросы, когда приходим на новую работу или проект. А как тест инженеры мы постоянно задаем вопросы…
Видео моего доклада с Andresen Meetup
#video #softskills #career
14 декабря я принял участие в митапе от компании Andresen. Это был мой первый опыт онлайн конференции - когда нужно говорить в камеру, сидя за столом и без людей в аудитории.
Для тех, кто хочет узнать о том, какие я вижу проблемы современного тестирования - мой доклад уже доступен на Youtube.
#video #softskills #career
14 декабря я принял участие в митапе от компании Andresen. Это был мой первый опыт онлайн конференции - когда нужно говорить в камеру, сидя за столом и без людей в аудитории.
Для тех, кто хочет узнать о том, какие я вижу проблемы современного тестирования - мой доклад уже доступен на Youtube.
YouTube
QA & Soft Skills Meetup (rus)
As part of the IT Community, we hold free meetups featuring top speakers from Andersen and invited experts for IT specialists across various technologies.
Speakers:
Alexander Romanov is a Test and Deployment Engineer at IOHK.
Topic: “Problems of modern testing”…
Speakers:
Alexander Romanov is a Test and Deployment Engineer at IOHK.
Topic: “Problems of modern testing”…
Ответы на вопросы после доклада
#softskills #hardskills #career
После моего доклада, в чате задали ряд вопросов. На все вопросы онлайн ответить не было возможности, поэтому отвечаю здесь, в виде заметки.
1. Дайте пару советов как быть: проект достаточно расширился. команда QA тоже расширилась. работы много. как быть в курсе всех изменений и не зашиваться?
Если вопрос был о том, чтоб быть в курсе изменений в КУА в компании: проводите еженедельные созвоны с командой. Обсуждайте там изменения в процессах тестирования, уроки преодоления проблем, новые проекты или инструменты. Обычно этот процесс “ведет” QA Manager или QA Lead. Но вы тоже может взять это в свои руки.
Если вопрос был о том, откуда черпать новости мира тестирования. Разумеется времени на то, чтобы сидеть в чатах или бесконечно смотреть видео с конференций никогда нет.
Что я делаю, чтобы быть в курсе новинок в мире тестирования:
- Слушайте подкасты о тестировании (QA Guild, Test Guild Podcast, The Testing Show, Podlodka, другие).
- Подпишитесь на каналы (Automation Remarks, Burnout SDET , Engineering Readings или твиттер интересующих вас специалистов.
- Используйте агрегатор блог постов по тестированию от Ministry of Testing
2. В итого проще QA перейти в другую компанию на желаемый участок чем перейти внутри компании Почему компания не сохраняет хорошего специалиста ?
На любом этапе вашей профессиональной карьеры только вы ответственны за то, чтобы работать на интересном проекте, получать достойную ЗП и развиваться. Если у вас есть возможность учиться и расти - то менять компанию смысла нет. Если вы чувствуете “потолок” - можно пойти на несколько собеседований и узнать, что делается на рынке труда. Заодно и узнаете, достаточно ли Ваших текущих знаний.
Процесс повышения внутри компании может быть прозрачным, а может быть тернистым и неочевидным. В любом случае, если вы хотите изменить проект, получить новую должность - первый человек с кем можно и нужно пообщаться - это ваш непосредственный начальник.
3. Насколько важна и популярна сертификация ISTQB в странах СНГ?
ISTQB иногда требуют некоторые аутсорс проекты при работе на Германию. (При переезде за рубеж тоже может пригодится). В целом в мире и СНГ особенно - ISTQB сертификат никак не добавит знаний и не заменит вам навыков и опыта.
4. Есть ли явное преимущество у QA с сертификатом ISTQB перед коллегами с таким же опытом без сертификата (в первую очередь при получении работы и в ЗП)?
На позицию трейни сертификат может быть преимуществом при прочих равных. Но тут стоит понимать, что получить сертификат и понять и усвоить информацию из Syllabus - это две большие разницы. Foundation Level вполне можно получить, просто “зазубрил” термины, как в университете на экзамене. Но будет от такой зубрежки толк - это большой вопрос.
На позициях уровня миддл и выше - сертификат ISTQB не играет роли. Играет роль ваш опыт и навыки. (Разве что, сертификаты Advanced Test Manager на позиции менеджера, и то - зависит от компании).
5. Какие виды автоматических тестов бывают?
Очень хорошо описал различные виды тестов (в целом и микросервисной архитектуре) - Мартин Фаулер. Можете посмотреть тут и тут.
#softskills #hardskills #career
После моего доклада, в чате задали ряд вопросов. На все вопросы онлайн ответить не было возможности, поэтому отвечаю здесь, в виде заметки.
1. Дайте пару советов как быть: проект достаточно расширился. команда QA тоже расширилась. работы много. как быть в курсе всех изменений и не зашиваться?
Если вопрос был о том, чтоб быть в курсе изменений в КУА в компании: проводите еженедельные созвоны с командой. Обсуждайте там изменения в процессах тестирования, уроки преодоления проблем, новые проекты или инструменты. Обычно этот процесс “ведет” QA Manager или QA Lead. Но вы тоже может взять это в свои руки.
Если вопрос был о том, откуда черпать новости мира тестирования. Разумеется времени на то, чтобы сидеть в чатах или бесконечно смотреть видео с конференций никогда нет.
Что я делаю, чтобы быть в курсе новинок в мире тестирования:
- Слушайте подкасты о тестировании (QA Guild, Test Guild Podcast, The Testing Show, Podlodka, другие).
- Подпишитесь на каналы (Automation Remarks, Burnout SDET , Engineering Readings или твиттер интересующих вас специалистов.
- Используйте агрегатор блог постов по тестированию от Ministry of Testing
2. В итого проще QA перейти в другую компанию на желаемый участок чем перейти внутри компании Почему компания не сохраняет хорошего специалиста ?
На любом этапе вашей профессиональной карьеры только вы ответственны за то, чтобы работать на интересном проекте, получать достойную ЗП и развиваться. Если у вас есть возможность учиться и расти - то менять компанию смысла нет. Если вы чувствуете “потолок” - можно пойти на несколько собеседований и узнать, что делается на рынке труда. Заодно и узнаете, достаточно ли Ваших текущих знаний.
Процесс повышения внутри компании может быть прозрачным, а может быть тернистым и неочевидным. В любом случае, если вы хотите изменить проект, получить новую должность - первый человек с кем можно и нужно пообщаться - это ваш непосредственный начальник.
3. Насколько важна и популярна сертификация ISTQB в странах СНГ?
ISTQB иногда требуют некоторые аутсорс проекты при работе на Германию. (При переезде за рубеж тоже может пригодится). В целом в мире и СНГ особенно - ISTQB сертификат никак не добавит знаний и не заменит вам навыков и опыта.
4. Есть ли явное преимущество у QA с сертификатом ISTQB перед коллегами с таким же опытом без сертификата (в первую очередь при получении работы и в ЗП)?
На позицию трейни сертификат может быть преимуществом при прочих равных. Но тут стоит понимать, что получить сертификат и понять и усвоить информацию из Syllabus - это две большие разницы. Foundation Level вполне можно получить, просто “зазубрил” термины, как в университете на экзамене. Но будет от такой зубрежки толк - это большой вопрос.
На позициях уровня миддл и выше - сертификат ISTQB не играет роли. Играет роль ваш опыт и навыки. (Разве что, сертификаты Advanced Test Manager на позиции менеджера, и то - зависит от компании).
5. Какие виды автоматических тестов бывают?
Очень хорошо описал различные виды тестов (в целом и микросервисной архитектуре) - Мартин Фаулер. Можете посмотреть тут и тут.
Automation Remarks
QA Guild Podcast - первый русскоязычный подкаст об автоматизации
QA Guild Podcast официалочка
6. Как мотивировать себя на изучение и набираться опыта в новых технологиях, если не используешь их в работе на текущем проекте (не знаешь, как применить, платный софт и т.д.)?
Мотивация изучать новое - это глубоко индивидуальная штука. Кого-то мотивируют новые проекты или продукт, помогающий людям. Кого-то - новая должность и больше денег.
Если вы хотите принести больше пользы бизнесу на текущем проекте - то лучше изучать языки программирования и инструменты, которые используются у вас. Тогда и применять их тоже сможете сразу.
Любое изучение новой информации без практики и закрепления - бесполезно. Забудется через 2-3 месяца - и придется учить все заново.
Поэтому если хотите изменить сферу деятельности (перейти в автоматизацию, разработку и тд) - то лучше или заранее определить путь перехода с менеджером и двигаться по нему внутри компании. Или - учить базовые навыки и переходить в другую компанию (возможно с понижением ЗП первое время) - и сразу применять там полученные знания.
7. Если ты какой никакой разработчик, но из за малого опыта и не самого хайпового языка тебя никуда не берут кроме стажировок с мутными перспективами, без оплаты - стоит ли идти в QA?
Тест инженер с хорошими навыки программирования довольно быстро будет прогрессировать в карьере автоматизатора. Ведь и там и там нужно писать грамотный, расширяемый и чистый код. Выучить библиотеки для тестирования - не составит труда.
Другой вопрос - понравится ли вам работа в тест инженерии. Если взять работу автоматизатора - то в 80% случаев это будет добавление новых тестов или исправление старых. И постоянная борьба за “зеленый пайплайн”. Основные “клиенты” вашей работы будут или менеджеры или команда. С пользователями взаимодействовать вы не будете.
Опять таки - есть работа девелоперов, где вы также не будете особо коммуницировать с пользователями (если это не продукт). Будет имплементация нового функционала.
Если смотреть с позиции дальнейшего релокейта - то у девелоперов найти работу зарубежом получается лучше (вариантов выбора больше).
Решайте сами, что вам ближе - создание нового, или проверка старого и разработка инструментов. И то, и другое направление может быть сложным, интересным и хорошо оплачиваться. Плюс никто не мешает переходить из одного направления в другое.
Мотивация изучать новое - это глубоко индивидуальная штука. Кого-то мотивируют новые проекты или продукт, помогающий людям. Кого-то - новая должность и больше денег.
Если вы хотите принести больше пользы бизнесу на текущем проекте - то лучше изучать языки программирования и инструменты, которые используются у вас. Тогда и применять их тоже сможете сразу.
Любое изучение новой информации без практики и закрепления - бесполезно. Забудется через 2-3 месяца - и придется учить все заново.
Поэтому если хотите изменить сферу деятельности (перейти в автоматизацию, разработку и тд) - то лучше или заранее определить путь перехода с менеджером и двигаться по нему внутри компании. Или - учить базовые навыки и переходить в другую компанию (возможно с понижением ЗП первое время) - и сразу применять там полученные знания.
7. Если ты какой никакой разработчик, но из за малого опыта и не самого хайпового языка тебя никуда не берут кроме стажировок с мутными перспективами, без оплаты - стоит ли идти в QA?
Тест инженер с хорошими навыки программирования довольно быстро будет прогрессировать в карьере автоматизатора. Ведь и там и там нужно писать грамотный, расширяемый и чистый код. Выучить библиотеки для тестирования - не составит труда.
Другой вопрос - понравится ли вам работа в тест инженерии. Если взять работу автоматизатора - то в 80% случаев это будет добавление новых тестов или исправление старых. И постоянная борьба за “зеленый пайплайн”. Основные “клиенты” вашей работы будут или менеджеры или команда. С пользователями взаимодействовать вы не будете.
Опять таки - есть работа девелоперов, где вы также не будете особо коммуницировать с пользователями (если это не продукт). Будет имплементация нового функционала.
Если смотреть с позиции дальнейшего релокейта - то у девелоперов найти работу зарубежом получается лучше (вариантов выбора больше).
Решайте сами, что вам ближе - создание нового, или проверка старого и разработка инструментов. И то, и другое направление может быть сложным, интересным и хорошо оплачиваться. Плюс никто не мешает переходить из одного направления в другое.
Как получить максимум пользы от разговора с экспертом?
#softskills #learning
Эта неделя получилась более “легкой” в плане тем. Хардкор и технические темы продолжим уже на следующей неделе. А пока я хотел бы поделиться парой интересных моментов, которые я узнал из книги Рона Фридмана “Разгадка гениальности”. Конкретнее - мы поговорим о получении знаний от эксперта. Эта заметка отчасти продолжает темы о вопросах и ответах.
Предположим, вы - начинающий тест инженер и на конференции (или митапе) у вас появилась возможность побеседовать с экспертом в той или иной области. Причем важно получить как можно больше полезного для себя из этого разговора.
Рон Фридман утверждает. что эксперт - не всегда равен хорошему учителю. Любой эксперт, который достаточно глубоко погрузился в предметную область - всегда мыслит абстрактно. У него нет понимания о том, что вы уже знаете, а что нет. 70% знаний эксперт не сможет рассказать вам, потому что не поймет важны ли они для вас или нет.
Так какие же вопросы вы можете задать эксперту, чтобы получить максимум пользы для себя? (Мы не берем в расчет тот случай, когда у вас уже заготовлены крайне конкретные специфические вопросы по инструменту или библиотеке).
Вопросы можно разделить на несколько категорий:
1. О пути - как эксперт достиг успеха (и напомнить ему время, когда он был новичком).
a. “Кого вы читали / смотрели / изучали, чтобы научиться это делать?“
b. “Какие ошибки вы совершили в начале?“
c. “На что вы бы хотели затратить меньше времени, когда учились? Что оказалось неважным?“
2. О процессе - детали работы, подход эксперта к делу, конкретные шаги достижения результатов.
a. “Что вы делаете вначале? Что потом? А после этого?“
b. “Откуда вы берете идеи и стратегии?“
c. “Как вы планируете работу?“
d. “Как вы планируете свой день?“
3. Об открытиях - сравнение с тем, что знаешь сейчас и в начале пути.
a. “Вспомните, что вас больше всего удивило?“
b. “Что бы вы хотели знать, когда начинали?“
c. “Какие неожиданные для вас факторы оказались критически важными для успеха?“
Конечно, эти вопросы можно часто услышать от журналистов в различных интервью. Но ведь разговор с экспертом, особенно если у вас ограниченное время, - это и есть своего рода интервью. С одной лишь разницей - этим интервью управляете вы. И вы сами можете строить его как вам нужно - и получить те информацию, что будет полезна именно вам.
Надеюсь, теперь разговоры в кулуарах конференций или чатах онлайн трансляций будут приносить вам чуть больше пользы.
Удачи в получении новых знаний!
#softskills #learning
Эта неделя получилась более “легкой” в плане тем. Хардкор и технические темы продолжим уже на следующей неделе. А пока я хотел бы поделиться парой интересных моментов, которые я узнал из книги Рона Фридмана “Разгадка гениальности”. Конкретнее - мы поговорим о получении знаний от эксперта. Эта заметка отчасти продолжает темы о вопросах и ответах.
Предположим, вы - начинающий тест инженер и на конференции (или митапе) у вас появилась возможность побеседовать с экспертом в той или иной области. Причем важно получить как можно больше полезного для себя из этого разговора.
Рон Фридман утверждает. что эксперт - не всегда равен хорошему учителю. Любой эксперт, который достаточно глубоко погрузился в предметную область - всегда мыслит абстрактно. У него нет понимания о том, что вы уже знаете, а что нет. 70% знаний эксперт не сможет рассказать вам, потому что не поймет важны ли они для вас или нет.
Так какие же вопросы вы можете задать эксперту, чтобы получить максимум пользы для себя? (Мы не берем в расчет тот случай, когда у вас уже заготовлены крайне конкретные специфические вопросы по инструменту или библиотеке).
Вопросы можно разделить на несколько категорий:
1. О пути - как эксперт достиг успеха (и напомнить ему время, когда он был новичком).
a. “Кого вы читали / смотрели / изучали, чтобы научиться это делать?“
b. “Какие ошибки вы совершили в начале?“
c. “На что вы бы хотели затратить меньше времени, когда учились? Что оказалось неважным?“
2. О процессе - детали работы, подход эксперта к делу, конкретные шаги достижения результатов.
a. “Что вы делаете вначале? Что потом? А после этого?“
b. “Откуда вы берете идеи и стратегии?“
c. “Как вы планируете работу?“
d. “Как вы планируете свой день?“
3. Об открытиях - сравнение с тем, что знаешь сейчас и в начале пути.
a. “Вспомните, что вас больше всего удивило?“
b. “Что бы вы хотели знать, когда начинали?“
c. “Какие неожиданные для вас факторы оказались критически важными для успеха?“
Конечно, эти вопросы можно часто услышать от журналистов в различных интервью. Но ведь разговор с экспертом, особенно если у вас ограниченное время, - это и есть своего рода интервью. С одной лишь разницей - этим интервью управляете вы. И вы сами можете строить его как вам нужно - и получить те информацию, что будет полезна именно вам.
Надеюсь, теперь разговоры в кулуарах конференций или чатах онлайн трансляций будут приносить вам чуть больше пользы.
Удачи в получении новых знаний!
Протоколы консенсуса в блокчейне: Proof Of Stake
#blockchain #consensus #distributedsystems
Продолжаем разбирать научную работу по протоколам консенсуса в блокчейне.
Хотя Proof Of Work алгоритмы и используются во многих существующих блокчейнах, у них есть ряд серьезных недостатков.
В попытке эти недостатки преодолеть был предложен немного иной подход к генерации и валидации новых блоков в сети. Этот протокол называется - Proof Of Stake (или доказательство ставки, PoS).
В чем суть протокола?
Ключевая идея PoS протокола в том, что те узлы, которые хотят участвовать в генерации нового блока, должны доказать, что располагают определенным количеством монетом на счете. Кроме того, они отдают часть монет в залог (на специальный адрес) как гарантию того, что будут вести себя честно. Если узел будет пробовать систему обмануть - эти монеты будут для него утеряны. Те, кто поставил ставку - принимают участие в “лотерее” на право генерировать блок. Остальные участники сети такого права не имеют. Стимул для генерации блоков сохраняется тем же, что и всегда - это fee с каждой транзакции в блоке.
Какие преимущества протоколов Proof Of Stake:
- Энергоэффективность. Никаких огромных затрат на решение сложных математических задач не нужно.
- Стойкость к централизации. Поскольку задачи решать не нужно, нет нужды покупать дорогое оборудование для майнинга или объединяться в пулы для решения задач.
- Явная экономическая безопасность. Любой, кто попытается взломать систему потеряет свою ставку. Плюс дополнительно, может быть отстранен от создания блоков в будущем.
Какие есть различные виды протоколов?
Главная задача в PoS протоколах - это как выбрать узел, который будет генерировать блок (среди тех, кто сделал ставку). На текущий момент существует несколько подходов к этому - Chained, BFT, Delegated.
Chained PoS. Обычно используется комбинация протоколов PoW и PoS. Узлы, для майнинга по протоколу PoW могут выбраны как случайно, так и в зависимости от других параметров узла (например времени. сколько узел владеет монетами в сети). Примеры - PeerCoin, Casper FFG,
BFT PoS. Узлы для генерации блока выбираются псевдо-случайно, но за них должно проголосовать больше двух третей участников. Примеры - Tendermint, Casper TFG, Ouroboros-BFT
Delegated PoS. Обычные узлы в сети могут делегировать право генерации блока другим узлам в обмен на некоторую плату в будущем. Примеры - EOS, Tron, Tezos, Lisk.
А какие есть проблемы и векторы атак у Proof Of Stake протоколов консенсуса?
1. Если количество узлов валидаторов не достаточно большое, можно легко выполнить атаку 51%.
2. Эффект богатства. Если алгоритм будет основан только лишь на ставке - то принимать участие в генерации новых блоков сможет лишь меньшинство у которого есть средства на счету.
3. Nothing-at-stake (NAS) атака. Во время форка в сети, злоумышленник может попытаться добавить новый блок во все возможные форки для того, чтобы увеличить вероятность добавления своего блока.
4. Bribing (short-range, SR) атака. Злоумышленник может “подкупить” других участников сети, чтобы они добавляли блоки в нужный форк.
5. Long-range (LR) атака. Злоумышленник может попробовать “переписать” историю блокчейна начиная с ранних блоков.
6. Coin-age accumulation (CAC) атака. Злоумышленник ждет пока возраст коинов будет достаточно большой, чтобы сделать форк и провести Double Spend атаку.
7. Pre-computing (PreCom) атака. Если алгоритм недостаточно случайный, злоумышленник может создать несколько блоков (подобрав алгоритм генерации) и потом разом отправить их сеть.
8. Cartel formation (CAF) атака. Возможность картельного сговора между узлами, генерирующими блоки в сети.
#blockchain #consensus #distributedsystems
Продолжаем разбирать научную работу по протоколам консенсуса в блокчейне.
Хотя Proof Of Work алгоритмы и используются во многих существующих блокчейнах, у них есть ряд серьезных недостатков.
В попытке эти недостатки преодолеть был предложен немного иной подход к генерации и валидации новых блоков в сети. Этот протокол называется - Proof Of Stake (или доказательство ставки, PoS).
В чем суть протокола?
Ключевая идея PoS протокола в том, что те узлы, которые хотят участвовать в генерации нового блока, должны доказать, что располагают определенным количеством монетом на счете. Кроме того, они отдают часть монет в залог (на специальный адрес) как гарантию того, что будут вести себя честно. Если узел будет пробовать систему обмануть - эти монеты будут для него утеряны. Те, кто поставил ставку - принимают участие в “лотерее” на право генерировать блок. Остальные участники сети такого права не имеют. Стимул для генерации блоков сохраняется тем же, что и всегда - это fee с каждой транзакции в блоке.
Какие преимущества протоколов Proof Of Stake:
- Энергоэффективность. Никаких огромных затрат на решение сложных математических задач не нужно.
- Стойкость к централизации. Поскольку задачи решать не нужно, нет нужды покупать дорогое оборудование для майнинга или объединяться в пулы для решения задач.
- Явная экономическая безопасность. Любой, кто попытается взломать систему потеряет свою ставку. Плюс дополнительно, может быть отстранен от создания блоков в будущем.
Какие есть различные виды протоколов?
Главная задача в PoS протоколах - это как выбрать узел, который будет генерировать блок (среди тех, кто сделал ставку). На текущий момент существует несколько подходов к этому - Chained, BFT, Delegated.
Chained PoS. Обычно используется комбинация протоколов PoW и PoS. Узлы, для майнинга по протоколу PoW могут выбраны как случайно, так и в зависимости от других параметров узла (например времени. сколько узел владеет монетами в сети). Примеры - PeerCoin, Casper FFG,
BFT PoS. Узлы для генерации блока выбираются псевдо-случайно, но за них должно проголосовать больше двух третей участников. Примеры - Tendermint, Casper TFG, Ouroboros-BFT
Delegated PoS. Обычные узлы в сети могут делегировать право генерации блока другим узлам в обмен на некоторую плату в будущем. Примеры - EOS, Tron, Tezos, Lisk.
А какие есть проблемы и векторы атак у Proof Of Stake протоколов консенсуса?
1. Если количество узлов валидаторов не достаточно большое, можно легко выполнить атаку 51%.
2. Эффект богатства. Если алгоритм будет основан только лишь на ставке - то принимать участие в генерации новых блоков сможет лишь меньшинство у которого есть средства на счету.
3. Nothing-at-stake (NAS) атака. Во время форка в сети, злоумышленник может попытаться добавить новый блок во все возможные форки для того, чтобы увеличить вероятность добавления своего блока.
4. Bribing (short-range, SR) атака. Злоумышленник может “подкупить” других участников сети, чтобы они добавляли блоки в нужный форк.
5. Long-range (LR) атака. Злоумышленник может попробовать “переписать” историю блокчейна начиная с ранних блоков.
6. Coin-age accumulation (CAC) атака. Злоумышленник ждет пока возраст коинов будет достаточно большой, чтобы сделать форк и провести Double Spend атаку.
7. Pre-computing (PreCom) атака. Если алгоритм недостаточно случайный, злоумышленник может создать несколько блоков (подобрав алгоритм генерации) и потом разом отправить их сеть.
8. Cartel formation (CAF) атака. Возможность картельного сговора между узлами, генерирующими блоки в сети.
Telegram
Test Engineering Notes
Протоколы консенсуса в блокчейне: Proof Of Work
#blockchain #consensus #distributedsystems
Протоколы консенсуса в блокчейне согласно Md Sadek Ferdous и другим авторам научной работы, можно поделить на три большие группы: Proof Of Work, Proof Of Stake и гибридные.…
#blockchain #consensus #distributedsystems
Протоколы консенсуса в блокчейне согласно Md Sadek Ferdous и другим авторам научной работы, можно поделить на три большие группы: Proof Of Work, Proof Of Stake и гибридные.…
Протоколы консенсуса в блокчейне: есть ли жизнь за пределами Proof Of Work и Proof Of Stake?
#blockchain #consensus #distributedsystems
Ранее мы кратко разобрали две большие группы протоколов консенсуса в блокчейне - Proof Of Work и Proof Of Stake.
Но кроме этих двух доминирующих групп, существует множество других идей (как теоретических, так и практических) о том, как сделать протоколы консенсуса лучше (а быть может хуже).
Вот лишь несколько интересных протоколов:
Proof Of Research. Это гибрид между Proof Of Stake и Proof of BOINС (Berkeley Open Infrastructure for Network Computing). BOINC это распределенная вычислительная платформа, ресурсы которой исследователи могут использовать для больших вычислений. Платформа объединяет ресурсы многих вычислительных машин пользователей по всему миру. Исследователям нужно скачать специальный софт на свою машину и принять участие в вычислении некоторой научной задачи. В награду, пользователь получает некоторое количество внутренней валюты - GridCoin.
Proof Of Burn. Суть протокола в том. что для генерации блока надо выслать (”сжечь”) некоторое количество монет на специальный адрес. Взамен - ты получаешь возможность сгенерировать следующий блок в цепочке и получить за это награду.
Proof Of Stake-Velocity. Очень необычный протокол. В некоторых вариантах Proof Of Stake берется в расчет время держания монет на определенном адресе. В PoSV же ключевую роль играет насколько активно совершаются действия с монетами.
Proof Of Cooperation. Право на генерацию нового блока получает специальный узлы - Certified Validating Nodes. Эти узлы выбираются на основе их “активности” в комьюнити.
Proof of Importance. Приоритет на генерацию нового блока отдается тем узлам, которые имеют больше всего входящих и исходящих транзакций.
В комментарии к заметке я приведу несколько интересных таблиц, где исследователи сравнивают протоколы по безопасности, производительности и структуре.
На этом краткий экскурс в мир протоколов консенсуса в блокчейне завершен. В следующий раз мы поговорим о других, не менее интересных концепциях.
Разобрав базовые вещи, мы подойдем вплотную к вопросам тестирования и верификации блокчейн и других распределенных систем.
#blockchain #consensus #distributedsystems
Ранее мы кратко разобрали две большие группы протоколов консенсуса в блокчейне - Proof Of Work и Proof Of Stake.
Но кроме этих двух доминирующих групп, существует множество других идей (как теоретических, так и практических) о том, как сделать протоколы консенсуса лучше (а быть может хуже).
Вот лишь несколько интересных протоколов:
Proof Of Research. Это гибрид между Proof Of Stake и Proof of BOINС (Berkeley Open Infrastructure for Network Computing). BOINC это распределенная вычислительная платформа, ресурсы которой исследователи могут использовать для больших вычислений. Платформа объединяет ресурсы многих вычислительных машин пользователей по всему миру. Исследователям нужно скачать специальный софт на свою машину и принять участие в вычислении некоторой научной задачи. В награду, пользователь получает некоторое количество внутренней валюты - GridCoin.
Proof Of Burn. Суть протокола в том. что для генерации блока надо выслать (”сжечь”) некоторое количество монет на специальный адрес. Взамен - ты получаешь возможность сгенерировать следующий блок в цепочке и получить за это награду.
Proof Of Stake-Velocity. Очень необычный протокол. В некоторых вариантах Proof Of Stake берется в расчет время держания монет на определенном адресе. В PoSV же ключевую роль играет насколько активно совершаются действия с монетами.
Proof Of Cooperation. Право на генерацию нового блока получает специальный узлы - Certified Validating Nodes. Эти узлы выбираются на основе их “активности” в комьюнити.
Proof of Importance. Приоритет на генерацию нового блока отдается тем узлам, которые имеют больше всего входящих и исходящих транзакций.
В комментарии к заметке я приведу несколько интересных таблиц, где исследователи сравнивают протоколы по безопасности, производительности и структуре.
На этом краткий экскурс в мир протоколов консенсуса в блокчейне завершен. В следующий раз мы поговорим о других, не менее интересных концепциях.
Разобрав базовые вещи, мы подойдем вплотную к вопросам тестирования и верификации блокчейн и других распределенных систем.
Telegram
Test Engineering Notes
Протоколы консенсуса в блокчейне: Proof Of Work
#blockchain #consensus #distributedsystems
Протоколы консенсуса в блокчейне согласно Md Sadek Ferdous и другим авторам научной работы, можно поделить на три большие группы: Proof Of Work, Proof Of Stake и гибридные.…
#blockchain #consensus #distributedsystems
Протоколы консенсуса в блокчейне согласно Md Sadek Ferdous и другим авторам научной работы, можно поделить на три большие группы: Proof Of Work, Proof Of Stake и гибридные.…
Впечатления от книги “Understanding Distributed Systems”
#review #books
В этом году я наконец-то одолел монументальный труд Мартина Клепманна - “Designing Data-Intensive Application”. Но чем больше я погружаюсь в тему распределенных систем и возможных проблем с ними - тем более инетересно разбираться как они работают изнутри. Поэтому я стараюсь читать и другие хорошие книги по теме.
По моим внутренним ощущениям, книга Клепманна будет достаточной сложной для неподготовленного читателя. Вы или будете продираться через массу ссылок на научные работы и гугление терминов или благополучно “забьете” (и оставите книгу до лучших времен).
Но что если я скажу, что есть книга на тему распределенных систем - не такая сложная, как Клепманн, но и не так поверхностно, как многие блоги или ютуб видео?
Такая книга существует. Это - “Understanding Distributed Systems” автора Roberto Vitillo.
Вчера я как раз завершил ее чтение и хочу поделиться впечатлениями.
Что в книге такого хорошего?
Автор рассказывает о том, что такое современные распределенные системы (а они вокруг нас!) и из каких частей они состоят. Концепции и термины грамотно подаются читателю как раз в том порядке, чтобы задуматься “а можно ли сделать этот подход или часть системы еще лучше?”.
Что самое главное - текст практически лишен “воды” - только описание работы системы и практические советы по использованию в реальной жизни.
В книге вы найдете информацию о том как коммуницируют системы, какие подходы координации узлов существуют.
Очень много внимания уделяется вопросами репликации, шардинга данных и повышению отказоустойчивости систем.
В завершение, автор кратко рассказывает о подходах к тестированию и деплою таких больших систем. (Практикующие тест инженеры не удивятся пирамиде автоматизации, но для начинающих или разработчиков - то что нужно).
Книга будет интересной, если вы:
- автоматизатор или SDET, которому надоело писать FindBy’и и есть желание наконецто получить целостностное представление о работе современных приложений;
- тест инженер, который хочет понимать как могут “сбоить” даже самые “простые” приложения;
- разработчик уровня джуниор - миддл, который желает выглянуть за пределы кода и паттернов в более реальный мир;
- инженер, который не получил таких фундаментальных знаний в университете (по какойто причине) и хочет заполнить пробелы в знаниях;
- готовитесь к system design interview;
- читатель, который не осилил Клепманна сразу, но хочет вернуться к нему потом);
Книга не принесет пользы, если вы:
- матерый инженер или исследователь распределенных систем и прочли Клепманна и много других научных работ по теме.
- инженер, который хочет глубоко и методичного погружения в тему. Для этого есть другие книги.
Если у Клепманна было 10 из 10, то тут могу поставить 8 из 10. По простоте и доступности изложения напомнила мне Leading Quality.
#review #books
В этом году я наконец-то одолел монументальный труд Мартина Клепманна - “Designing Data-Intensive Application”. Но чем больше я погружаюсь в тему распределенных систем и возможных проблем с ними - тем более инетересно разбираться как они работают изнутри. Поэтому я стараюсь читать и другие хорошие книги по теме.
По моим внутренним ощущениям, книга Клепманна будет достаточной сложной для неподготовленного читателя. Вы или будете продираться через массу ссылок на научные работы и гугление терминов или благополучно “забьете” (и оставите книгу до лучших времен).
Но что если я скажу, что есть книга на тему распределенных систем - не такая сложная, как Клепманн, но и не так поверхностно, как многие блоги или ютуб видео?
Такая книга существует. Это - “Understanding Distributed Systems” автора Roberto Vitillo.
Вчера я как раз завершил ее чтение и хочу поделиться впечатлениями.
Что в книге такого хорошего?
Автор рассказывает о том, что такое современные распределенные системы (а они вокруг нас!) и из каких частей они состоят. Концепции и термины грамотно подаются читателю как раз в том порядке, чтобы задуматься “а можно ли сделать этот подход или часть системы еще лучше?”.
Что самое главное - текст практически лишен “воды” - только описание работы системы и практические советы по использованию в реальной жизни.
В книге вы найдете информацию о том как коммуницируют системы, какие подходы координации узлов существуют.
Очень много внимания уделяется вопросами репликации, шардинга данных и повышению отказоустойчивости систем.
В завершение, автор кратко рассказывает о подходах к тестированию и деплою таких больших систем. (Практикующие тест инженеры не удивятся пирамиде автоматизации, но для начинающих или разработчиков - то что нужно).
Книга будет интересной, если вы:
- автоматизатор или SDET, которому надоело писать FindBy’и и есть желание наконецто получить целостностное представление о работе современных приложений;
- тест инженер, который хочет понимать как могут “сбоить” даже самые “простые” приложения;
- разработчик уровня джуниор - миддл, который желает выглянуть за пределы кода и паттернов в более реальный мир;
- инженер, который не получил таких фундаментальных знаний в университете (по какойто причине) и хочет заполнить пробелы в знаниях;
- готовитесь к system design interview;
- читатель, который не осилил Клепманна сразу, но хочет вернуться к нему потом);
Книга не принесет пользы, если вы:
- матерый инженер или исследователь распределенных систем и прочли Клепманна и много других научных работ по теме.
- инженер, который хочет глубоко и методичного погружения в тему. Для этого есть другие книги.
Если у Клепманна было 10 из 10, то тут могу поставить 8 из 10. По простоте и доступности изложения напомнила мне Leading Quality.