"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson

#testing #distributedsystems #video
Слушаю тут прекрасный курс по распределенным отказоустойчивым системам. В одной из лекций рекомендовали посмотреть видео про тестирование распределенных систем в FoundationDB.

Для справки, FoundationDB - это оупен-сорсная NoSQL база данных с ACID транзакциями уровня Serializable. Позволяет хранить отсортированные пары ключ-значение в виде произвольных последовательностей байтов.

Доклад конечно слегка старый (2014 год - еще до того, как их купила Apple), но все-таки было любопытно увидеть как подходят к вопросу тестирования в больших распределенных база данных.

Несколько ключевых мыслей из доклада:
- Багов в распределенных БД очень много. (Неожиданно!)

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

- Ребята заморочились и до того, как писать код своей БД, они написали симуляцию своей базы данных и на ней гоняли огромное количество тестов. И даже написать свое расширение для C++ под названием Flow. Это дополнение позволяло писать псевдо-многопоточный код, который бы выполнялся в рамках одного реального физического потока.

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

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

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

- Интересно, что они даже нашли пару багов в third-party системах (ZooKeeper и Linux).

Очень рекомендую этот доклад к просмотру. Даже если у вас (как и у меня) C++ - это далеко не сильная сторона. Его тут немного. Что важнее - идеи и размышления докладчика.
В дополнение, немного о процессе тестирования описано и на странице самого проекта.

Подходы к верификации распределенных систем (by Caitie McCaffrey)

#distributedsystems #testing

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

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

1. Статическая верификация системы:

- Formal Verification. Подход, при котором на специальном языке (TLA+, Coq) описывается система и ее параметры. Кроме того, формируются ряд утверждений о корректности работы системы. Потом это описание проверяется автоматическими инструментами анализа.
По сути, это математическое доказательство того, что ваша система (на глобальном уровне) будет работать так, как предполагается. Такой подход дал хорошие результаты при проектировании AWS сервисов, таких как S3.
Главным минусом такого инструмента является то, что для написания таких математических доказательств нужен определенный опыт и знания. (Такое не нагуглишь по-быстрому).

- Model Checking. Тоже формальный метод, который проверяет граф состояний системы и позволяет найти проблемные места. Но т.к. состояний в больших системах может быть очень большое количество - то такой метод перебора может занимать много времени. Автор статьи приводит пару примеров инструментов (Spin, MaceMC, MoDIST), но они существуют в виде приложений к научным работам. Поэтому я не знаю насколько они применимы в реальной жизни.

2. Динамическая верификация системы:

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

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

- Unit and Integration Tests. Куда уж без старых добрых тестов. О важности таких тестов я недавно писал в анализе научной работы об ошибках в распределенных системах.

3. Техники внедрения неисправностей.

- Random Model Checkers. В некоторых случаях полезно применить разные библиотеки по property-based тестирования. Например QuickCheck или ScalaCheck. В таких инструментах вместо зафиксированных инпутов, вы просто описываете некое множество вариантов значений. А дальше библиотека при каждом запуске тестов, генерирует новые инпуты и проверяет, что система работает корректно и с ними.

- Netflix Simian Army. Тут целый набор полезных инструментов для симуляции отказов в как отдельных узлов, так и целых кластеров или даже availability zones в облаках.

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

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

Как я читаю книги

#books #learning
В одном из комментариев под постом с итогами 2021 года, меня спросили, как я успел прочесть 40 книг (по работе и художественных). В сегодняшней легкой заметке я расскажу пару моментов, которые помогают лично мне читать книги (и черпать нечто полезное из них).

Выбирайте книги в соответствии с целями
Все книги по всем интересным темам прочесть невозможно. Можно, конечно, как Билл Гейтс устраивать себе “Think Week” или даже “Think Month”. (Уехать в одиночку, без гаджетов, в уединенный домик на природе и читать :)).

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

Чередуйте профессиональную литературу и книги “для души”
Такой подход помогает “разгружать” мозги после тяжелой технической литературы. Фантазию отлично стимулирует научная фантастика, фэнтези, даже хороший качественный детектив.
Научно-популярные книги помогают расширить кругозор - ведь жизнь, кроме IT, существует.

Составьте план на день, неделю и включите чтение в каждодневную рутину
Иногда дел столько, что спасает только включение чтения отдельной задачей в список дел на день. Это может быть даже 15-30 минут в день. Важно только, чтобы у Вас было "мыслетопливо", чтобы обработать знания из книги.

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

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

Находите время для чтения
Безусловно свободного время у каждого очень мало. Хочется успеть все и даже больше. Не буду тут “открывать Америку” и скажу просто, что важно делать выбор в зависимости от Ваших приоритетов. Плюс - есть ли у вас
Еще при чтении поможет отключать гаджеты и читать строго отведенное время. Или просто просыпаться немного раньше и читать. (Мне помогает).

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

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

Бросайте книгу если она читается трудно или оказалась неинтересной вам.
То что книга включена в кучу must-read списков вовсе не означает, что она подойдет лично Вам в данный момент Вашей карьеры. Кабанчика я начинал читать и бросал несколько раз. И только спустя несколько лет я вернулся к ней и с огромным удовольствием ее прочел. То же касается в моей случае первой “Дюны” Герберта.

А иногда книга может быть просто отвратительной, полной "воды" или переливания из пустого в порожнее. Или Вы, например, уже “выросли” из книг категории “туториал с официального сайта в формате книги”. Такие книги лучше бросать и не тратить на них времени.

А как читаете книги вы?

[Для тест инженеров] Пару интересных митапов января

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

- 15.01.22 будет проходить AD Software Testing Online Meetup #8. Anton Yakutovich в очередной раз собирает СДЕТов и им сочувствующих для обсуждения интересных технических тем. На этом митапе я буду говорить о проблемах современного тестирования, а Sergey Shaikin расскажет об эффективной работе с логами в Кибане. Доклады будут на английском.

- В тот же день (15.01.22) можно сходить на митап от UniEd - ''Selenide - просто пишем тесты''. Это ивент для совсем джуниоров в автоматизации и тех, кто хочет ими стать.

- 26.01.22 для начинающих и продолжающих автоматизаторов можно заглянуть на воркшоп от Артура Шевченко, посвященный репортингу с Allure в GitLab’e.

А какие митапы в январе хотите посетить вы?

Что такое симметричное шифрование (простыми словами)?

#security #blockchain #cryptography

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

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

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

Самый простой симметричный шифр?
Шифр Цезаря - в котором каждая буква исходного сообщения заменяется на букву алфавита с каким-то сдвигом относительно начала. Например буква A со сдвигом 3 будет превращена в букву D. (И да, этот шифр назван в честь Гая Юлия Цезаря, потому что активно применялся еще теми самыми римлянами для шифрования писем). Но такой шифр крайне просто взломать.

Что же в современном мире?
В современном мире конечно буквы в алфавите не двигают. Обычно используют побитовую операцию XOR (исключающее или) и огромное количество битовых преобразований, перемешиваний, подстановок на протяжении многих раундов.
Что такое XOR (^)? Коротко: если биты A и B разные, то A ^ B = 0. Иначе A ^ B = 1.
Почему XOR? Например - 123 ^ 45 = 86. (где пусть 123 - исходный текст, а 45 - ключ). Тогда 86 это зашифрованный текст. А если сделать вот так: 86 ^ 45 = 123 (исходный текст!). МАГИЯ!

Примеры алгоритмов шифрования?
AES, 3DES, RC2, Blowfish, RC4 и множество других.

Где используется шифрование?
Для шифрования данных пользователя и его карт при банковских транзакциях. Для шифрования данных на диске.
Комбинации симметричного и асимметричного шифрования используют в SSL/TLS, в защищенных мессенджерах.

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

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

Для желающих узнать чуть больше, есть классные видео объяснения симметричных шифров и даже AES.
А для тех, кто хочет погрузиться в захватывающую историю шифров, взломов - крайне рекомендую "Книгу Шифров".

База знаний по тестированию блокчейна

#blockchain #testing

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

Хочу сегодня поделиться более подробной картой знаний. Надеюсь она поможет вам немного лучше представить объём знаний и темы. В заметках на этом канале я планирую постепенно рассказать о большинстве пунктов. Хотя бы на уровне понимания “как это работает” (а самое главное - как это тестировать).

Дополнительно, я веду подборку статей, видео и научных работ по тестированию блокчейна (и постепенно их читаю).

Давайте вместе узнавать что такое блокчейн (и другие распределенные) системы и где они обитают 🙂

Как быть более эффективным тест инженером

#softskills #career
Многие тестировщики (особенно уровня миддл. синьор) часто жалуются, что ИТ индустрия “сломана”, “мы такие крутые спецы, делаем крутые штуки - а злые менеджеры не повышают”, “не повышают - пойду трясти офферы” и прочее. Сам был таким когда-то, чего скрывать.

Вместо того, чтобы трясти оффером и быстро уходить из компании, можно понять, как увеличить бизнес ценность и влияние своей работы на бизнес.
В начале месяца, Cindy Sridharan написала просто отличную статью на эту тему “know how your org works (or how to become a more effective engineer)”.

Вот кратко тезисы из статьи:
1. Важно понимать, что премии, повышения дают не просто “за крутые штуки”, а за то, что имело большую ценность для бизнеса.

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

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

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

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

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

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

8. Изучайте, какого рода культура в вашей организации - “top-down” или “bottom-up”.

9. Самый главный скилл, приносящий ценность - это умение быстро и успешно разбираться в бардаке (и уметь с этим жить). Очень редко когда можно будет прийти и построить абсолютно все с нуля. Обычно, нужно преодолеть “какой умный человек писал этот фреймворк!” - и жить с этим дальше, постепенно улучшая и переписывая его.

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

Интересные каналы и ресурсы для изучения нового (или закрытия “пробелов” в знаниях)

#learning
Так как я сейчас немного занят прохождением курсов на Coursera, технического и хардкорного контента на этой неделе было мало. На следующей неделе исправлюсь!).
Плюс, я не хочу делать слишком простые или маленькие заметки - все-таки мы тут не о простых вещах говорим.
Поэтому сегодня мы немного поговорим об обучении интересному.

Работая в IT так или иначе надо постоянно обучаться. Это может быть новый инструмент, новый продукт, новый язык программирования.
Сайтов с курсами (платными и бесплатными) существует огромное множество. Все о них слышали, знают, используют. Какие-то ресурсы хороши, какие-то - сомнительного качества. Но кроме платных и бесплатных ресурсов для обучения конкретным инструментам, есть еще интересные каналы на Youtube. Сегодня я хочу поделиться небольшой подборкой. Может вам будет что-то из этого полезно.

Интересные ресурсы (и да, они на английском):

- 5 Levels of Difficulty (плейлист от Wired). Приглашенный эксперт раскрывает выбранную концепцию на пяти различных уровнях сложности: дошкольник, школьник, студент, выпускник ВУЗА, взрослый). Помимо интересного объяснения, дает множество идей о том, как одну и ту же тему можно донести в зависимости от количества знаний у человека.

- Explain me like I’m 5. Это целый сабреддит с такими вопросами и ответами (по сути - обьяснение сложного - простыми словами). Можно даже гуглить отдельные вопросы с префиксом - ELI5. Например - ELI5: Why are the polar ice caps melting? Кроме того, Фейсбук в таком формате говорит о своих оупен-сорс библиотеках.

- Khan Academy (и на русском). Просто отличный канал, в котором можно найти уроки не только по компьютерным наукам, но и другим предметам школьной программы. Можно посмотреть, как учат математику в школах в США (и даже разобраться в темах и предметах, которые в школе преподавали плохо). Видео от автора реально используют как материал в школах.

- Computerphile. Довольно хардкорный канал, в котором подробно разбирают множество терминов и концепций из Computer Science.

- Internet-class. Короткие видео по различным вещам из компьютерных технологий. Правда новых видео автор уже к сожалению не выпускает.

Я намеренно не указывал никаких каналов посвященных тестированию или определенным языкам программирования - т.к. их вы и так, я думаю, видели немало.

А какие у вас любимые интересные ресурсы для изучения нового?

Ура! Нас уже 300!
Спасибо, что читаете. И спасибо за комментарии и фидбеки.

Обзор специализации "Decentralized Finance (DeFi): The Future of Finance" на Coursera

#learning #course
В декабре прошлого года я благополучно забыл отменить месячную подписку на Coursera. В итоге плата за месяц снялась и мотивация по максимуму использовать подписку возросла.
Поэтому я решил пройти интересную специализацию: Decentralized Finance (DeFi): The Future of Finance.

Почему именно эту специализацию? Хотелось узнать больше о применениях блокчейна вне концепции криптовалют. (А применения в целом очень и очень много - не только в финансах).

Состав специализации:
1. Курс "DeFi: Infrastructure": отличное изложение истории финансов - от централизованных к централизованным; базовое объяснение о том, как работает блокчейн, что такое stablecoin и dApps; много обсуждаются плюсы, минусы и мифы о блокчейне и DeFi.

2. Курс "DeFi: Primitives": описывается как работают транзакции, какие есть виды токенов; показаны интересные финансовые инструменты на блокчейне (Loans, Swaps, Flash Loans, Automated Market Makers); рассказывается базовая работа с кошельками в Ethereum и еще больше о технических аспектах блокчейн систем.

3. Курс "DeFi: Deep Dive": весь курс посвящен описанию различных продуктов в сфере DeFi - MakerDAO, Compound, Aave, Uniswap, Yield Protocol, dYdX, Synthetix; показаны даже механизм создания аналога ETF - только для токенов.

4. Курс "DeFI: Opportunities and Risks": весь курс обсуждаются различные типы рисков, эксплоитов и уязвимостей в современных блокчейн системах - как технических, так и экономических.

Плюсы специализации:
- курс очень свежий (актуален на 2021 год)
- много информации по финансовым инструментам (как они работают, какие плюсы и минусы их использования)
- базово обсуждается технические моменты работы блокчейна (очень понравилось описание создания публичных адресов в Bitcoin и Ethereum)

Минусы специализации:
- не ждите технической глубины при объяснении работы блокчейна (эту информацию придется черпать из других источников)
- не ждите программного кода и так же не ждите советов по инвестированию в крипту)
- базовые знания по финансам могут пригодиться (плюс довольно много финансовых терминов на английском, внезапно! :))))
- не хватило практики (оценка знаний просто в виде тестов)

Выводы:
Мне специализация понравилась. Для себя я почерпнул много нового (особенно по разным DeFi продуктам).
Некоторые концепты дались “с трудом” - пришлось гуглить самому. Но углубляться в эту сферу дальше у меня интерес есть).

Как начальный курс по блокчейну наверное не подойдет. Есть курсы на Юдеми получше.

Книги и курсы по блокчейну для начинающих

#blockchain #course #books

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

Приведу список ресурсов. Все, что в списке я читал-проходил сам (за 2021й) - поэтому могу кратко рассказать о своих впечатлениях.

Книги:

- Mastering Blockchain - отличная книга для старта и погружения в тему. Охватывает и историю блокчейна, и как он работает, и как применяется.
- Blockchain and decentralized systems - превосходная книга (учебное пособие для университетов) о том, что такое блокчейн с технической точки зрения. Дает очень много нужной и главное - современной информации. Некоторые разделы содержат математические формулы. Для тех, кому лень читать книгу - есть бесплатная запись курса.
- Grokking Bitcoin - книга исключительно о Биткоине и том, как он работает. Основная крутая “фишка” книга - это то, как автор постепенно из маленьких слоев и строительных блоков строит блокчейн с нуля.
- КРИПТВОЮМАТИКА 2.0 - довольно поверхностная книга, но читается легко. По крайней мере после ее прочтения вы начнете на очень базовом уровне разбираться в основных “словах и терминах” блокчейна.

Курсы на Coursera:

- Blockchain Specialization - базовая специализация по блокчейну. Очень легко и непринужденно доносит основные концепции и термины.
- Blockchain Scalability and its Foundations in Distributed Systems. Об этом курсе я писал не так давно развернутый отзыв.
- Decentralized Finance (DeFi): The Future of Finance Specialization. Обзор здесь.

Курсы на Udemy:

- Blockchain and Bitcoin Fundamentals - неплохой курс по базовым моментам блокчейна и Биткоина.
- Blockchain Advanced Level: Uses Beyond Bitcoin - уже больше информации о внутренних механизмах Биткоина
- Blockchain A-Z™: Learn How To Build Your First Blockchain - отличный обзорный курс. Мне понравился (даже удивительно, что такой контент на Udemy). Фишка курса - возможность самому написать мини-блокчейн на Python.
- Ethereum Blockchain Developer Bootcamp With Solidity (2022) - хороший курс по Solidity и смарт контрактам. (Прохожу его сейчас).

[Простыми Словами] Что такое асимметричное шифрование?

#security #blockchain #cryptography

Зачем нужно?
Зачем вообще нужно асимметричное шифрование, если уже и так можно очень хорошо зашифровать и расшифровать текст с помощью симметричного?

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

А может есть способ так обменяться ключом, чтобы злоумышленник, который перехватил и сообщение и ключ - все равно не мог расшифровать сообщение?
Над этой проблемой трудились в прошлом веке многие, но решение пришло в голову Утфилду Диффи и Мартину Хеллману в 1970х годах прошлого века. Как результат - они создали протокол Диффи-Хеллмана.
Подобная идея кстати приходила еще и Ральфу Мерклу (о его наработках и их применение в блокчейне я расскажу позже).

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

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

В асимметричной шифровании используются давно ключа (вместо одного): открытый и закрытый. С помощью открытого ключа отправитель шифрует сообщение. С помощью закрытого ключа получатель производит расшифровку. Открытый ключ отправитель пересылает получателю по сети (незащищенной).

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

Примеры алгоритмов?
- RSA. Основывается на сложности разложении больших простых чисел на множители.
- Digital Signature Algorithm (DSA). Основывается на сложности вычисления дискретных логарифмов.
- Elliptic Curve Digital Signature Algorithm (ECDSA). Тоже алгоритм с вычислением дискретных логарифмов, но уже в группе точек на эллиптической кривой, Используется, например, для подписи транзакций в блокчейн системах.

Где используется в современном мире?
- SSL / TLS. С помощью асимметричного шифрования две стороны конструируют и обмениваются ключом, который потом используют для симметричного шифрования сообщений между собой.
- Digital Signatures - проверка целостности и подлинности данных.
- SSH
- PGP - набор утилит для шифрования
- S/MIME - стандарт шифрования и подписи в электронной почте
- Blockchain! При создании аккаунта в любом кошельке для блокчейна, вы генерируете пару из приватного и публичного ключей. На основе публичных ключей в дальнейшем генерируются публичные адреса (на которые Вам присылают криптовалюту или токены).

Как протестировать асимметричный алгоритм шифрования?
Как и в случае с симметричным шифрованием, злоумышленник знает алгоритм шифрования. Плюс - злоумышленник даже знает открытый ключ.
Вся защита состоит в том, что на brute-force перебор всех возможных значений ключа у злоумышленника уйдет очень много времени и вычислительных ресурсов.
Поэтому чем длиннее ключ - тем шифрование менее подвержено взлому. В современных системах даже алгоритм RSA с ключом в 1024 бит уже не считается достаточно надежным. Лучше брать 4096 бит.

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

Шпаргалка по Git на каждый день

#testing #git

Система контроля версий Git применяется на многих современных проектах. Знать и уметь с ней работать - это уже must-have не только для разработчика, но и для тест инженера.

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

Мало кто задумывался, но Git по факту представляет собой распределенную систему реплицированного лога.

Git имеет достаточно широкий набор команд. Но базово, нужно знать и уметь совсем немного. Для кого-то удобнее работать с Git через IDE, но для “старой гвардии” - приведу шпаргалку базовым командам на каждый день.

- git init Создает новый репозиторий в текущей папке.

- git clone Клонирует репозиторий в текущую папку

- git add (git add -A) Добавляет файлы в текущий коммит

- git commit -m “Commit message” Позволяет сохранить текущее состояние репозитория в виде коммита с определенным сообщением.

- git log. Получить историю коммитов в репозитории.

- git pull origin branch_name Синхронизирует состояние ветки локального репозитория с remote.

- git push origin branch_name Отправляет локальные изменения в текущей ветке на сервер.

- git branch Позволяет работать с ветками: выводить список текущих веток и создавать или удалять их.

- git checkout branch_name Переход из текущей ветки в указанную branch_name. git checkout -b branch_name - позволяет создать новую ветку и сразу перейти в нее.

- git fetch Обновляет сведения об изменениях в remote.

- git rebase branch_name (или в отдельных случаях git merge). Сливает изменения с branch_name в текущую ветку. О том, в разница между merge и rebase - тут.

- git reset —hard Отменить все изменения в локальном репозитории и вернуться к исходному коммиту.

Базовый набор действий с Git в виде иллюстраций можно посмотреть в моем блоге.

Запись моего доклада с митапа Ministry of Testing Abu Dhabi

#video #testing #talk
Это становится для меня традицией зимой принимать участие в митапе от Ministry of Testing Abu Dhabi.
В этом году я рассказывал о проблемах современного тестирования.
В прошлый раз мой доклад был про контрактные тесты.

Спасибо организатору митапа Антону - за то, что пригласил. Надеюсь, не последний раз принимаю участие в таком мероприятии.

О пользе “огурцов” в рационе тест инженера

#testing #automation #fun
Тема “Behavior Driven Development” подхода и инструментов будоражит умы тестировщиков и автоматизаторов уже много лет. Сообщество делится на два лагеря. Первые говорят о том, что: BDD “не работает!”, “не нужно!”, и “лишние абстракции и слои!”. Вторые парируют в ответ: “Вы неправильно используете BDD!”, “У нас работает!”, “Вы все врете!”.

Я использовал BDD инструменты в автоматизации на разных проектах. Это был Specflow (C#), Cucumber (Java, Scala), Thucydides (Serenity) + JBehave, встроенный BDD в Rest Assured, Gauge (Java). Кроме тех, что перечислил - есть еще много инструментов и оберток, использующих подходы BDD на разных языках и платформах.

Почему же у многих инженеров “полыхает” при этом слове - BDD? Или все-таки BDD может нести прохладу и силу Земли? Давайте разберемся. Все совпадения с реальными людьми и проектами прошу считать вымыслом. У вас на проекте, конечно, все по-другому и все работает.

Как “продают” BDD заказчику?
- вся команда будет следовать парадигме BDD (когда собирается 3-amigo митинг - и тестер, девелопер и бизнес аналитик вместе пишут эти самые сакральные сценарии, понятные для всех. И так происходит на каждую задачу в беклоге)!
- менеджеры и сам заказчик сможет писать бизнес-сценарии, которые потом будут автоматизироваться!
заказчик, да и вообще люди из бизнеса, смогут понимать, что тестировалось и что не работает - просто просматривая отчет!
- тестировщики смогут легким движением руки писать сценарии и безболезненно автоматизировать их!
все участники команды смогут понимать тесты и писать их (и девелоперы, и даже вон тот бородатый девопс если нужно)!
- в отдельных случаях получаем еще красочные отчеты (привет, Serenity)!
- можно легко сменить тестовый фреймворк и оставить сценарии без изменений!

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

2. Если BDD процесс все же запустился, то написание, расширение и поддержку Gherkin сценариев отдают в руки тест инженеру. В итоге, или инженер занимается бесконечным “пинг-понгом” и выяснением требований с заказчиком, или пишет сценарии сам. На просьбы сделать ревью сценариев обычно получает отписку “мне ок, давайте деливерить, schnell, schnell!”.

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

4. На результаты автотестов и отчеты, заказчик первое время смотрит. Может быть даже хвалит то, как все понятно. Но со временем, заказчику становится важным только то, какие риски есть для релиза. (Что по сути нормально).

5. Приглашенный автоматизатор или сам тест инженер быстро понимают, что слой BDD добавляет только больше “боли” в поддержке. Сценарии растут, становятся монструозными полотнищами из 30+ шагов. Вроде шаги хочется и переиспользовать, но это не так-то просто. Автоматизатор терпит (и поглядывает на рыночек за окном). А там - HR манят сказочными офферами на новые проекты без BDD).

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

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

8. Заказчик счастлив. Команда ликует. Менеджмент открывает шампанское!

9. И только где-то в другой компании, поседевший автоматизатор продолжает вздрагивать при звуках - “Given, When, Then...”

О пользе “огурцов” в рационе тест инженера (Продолжение)

Так ли плох BDD? Может мы его неправильно “варим”?

Есть ведь успешные кейсы! Многие зарубежные продуктовые компании успешно используют подход BDD. Так команды маленькие, в одной локации. Бизнес заинтересован в понятных сценариях. Если тестеры что-то неясно - он пойдет и быстро “дернет” аналитика в соседней комнате и уточнит детали. Менеджмент реально смотрит детали отчетов, думает над бизнес-сценариями каждой фичи. В JIRA тикете описание идет сразу в формате Gherkin.

Не только Gherkin! Кроме того, есть такие инструменты, которые дают ту же абстракцию как и Cucumber, но не вкладывают ограничений в виде Given-When-Then. Например тот же Gauge. В нем сценарии можно писать в вольном стиле. Можно даже хранить тест-кейсы в виде Markdown файлов - и выгружать в TMS по надобности.

Текст может быть полезен! Плюс, в отдельных случаях (я сам видел и участвовал), при грамотном использовании этой текстовой “надстройки” и data-driven подхода - можно добиться того, что тест инженеры с минимальными знаниями автоматизации - смогут писать огромное количество новых тестов быстро “копируя” шаги и подставляя новые данные в тест. (Можно даже для одного текстового сценария сделать запуск на разных браузерах и даже платформах).

Так хорош или плох этот BDD? Вам решать:) Но я думаю, что все зависит от того - как использовать инструмент и процесс. Применять ли инженерный подход для устранения “боли” - или “продолжать есть кактус”. Искать способы применения инструмента в команде - а если таковых нет - устранять боль и двигаться дальше.

А что вы думаете о BDD?

HTTP/3 - что это такое и как это изменит HTTP?

#web #http
Сегодня хочу поделиться интересным докладом о новом этапе развития протокола HTTP - "HTTP/3 is next Generation HTTP. Is it QUIC enough?".
Теперь он будет работать не на TCP(TLS 1.2+) поверх IP, а на QUIC + UDP (TLS 1.3) поверх IP.

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

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

[Простыми словами] Что такое цифровая подпись?

#security #blockchain #cryptography

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

Довольно часто при передаче сообщений между двумя сторонами нужно решить две большие задачи:
1. Как получателю быть уверенным, что сообщение отправлено именно отправителем?
2. Как получателю быть уверенным, что сообщение не было изменено злоумышленником во время передачи?

Обе эти задачи решаются с помощью механизма цифровой подписи (digital signatures).

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

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

Примеры алгоритмов цифровой подписи?
RSA-PSS, DSA, ECDSA, Rabin signature, Schnorr signature.

Как цифровая подпись используется в блокчейне?
Каждый раз, когда вы в кошельке совершаете новую транзакцию, “под капотом” транзакция подписывается вашим ключом. В дальнейшем в блокчейне можно проверить - кто создал ту или иную транзакцию.
В Bitcoin изначально использовался алгоритм ECDSA. Буквально пару лет назад этот алгоритм заменили и сейчас транзакции можно подписывать с помощью алгоритма Шнорра. У него есть ряд весомых преимуществ - особенно для мультиподписи транзакций. Сам алгоритм очень интересный - расскажу о нем подробнее в следующих заметках.
В Ethereum сейчас используется ECDSA, Cardano - Ed25519.

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

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

Шифруем и подписываем данные с gpg и Mailvelope

#blockchain #security #cryptography
В прошлых заметках мы говорили о шифровании (тут и тут), а также о цифровой подписи.
Но одно дело просто узнать о концепции - а другое дело - “пощупать” своими руками.

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

gpg
Открытый стандарт шифрования OpenPGP существует в двух имплементациях PGP и GPG (GnuPG). Если первая - закрытая, то вторую любой пользователь установить на свой компьютер (как в Unix так и в Windows).
Установка утилиты описана - здесь.
Что можно делать с ее помощью:
- генерировать ключи (публичные и приватные): gpg --gen-key
- смотреть какие ключи уже импортированы: gpg --list-keys (а также - gpg --list-public-keys и gpg --list-secret-keys)
- импортировать свои ключи из внешних источников: gpg --import public_key.txt
- экспортировать свои ключи (в файл): gpg --export -a "email" > pub.asc (или gpg --export-secret-key -a "email" > priv.asc). Без перенаправления в файл - можно просто вывести в консоль текст ключа.
- выкладывать свои ключи на открытые сервера ключей для распространения: gpg --keyserver pgp.mit.edu --send-keys KEY_ID
- зашифровать и подписать сообщение для заданного получателя: gpg --encrypt --sign --armor -r samplerecipient@mail.com message.txt
- дешифровать данные: gpg --decrypt message.txt.gpg
- ставить цифровую подпись на сообщение: gpg —detach-sign message.txt
- проверять подлинность подписи: gpg —verify message.txt.sig

Mailvelope
Если утилита командной строки - слишком “дедовский” способ для вас - то есть отличный выход. Можно установить плагин Mailvelope для Google Chrome (есть также для Firefox и Edge). С его помощью можно делать то же самое, что и с gpg - только в браузере и с приятным и удобным интерфейсом.
О том как установить и настроить этот плагин можно почитать тут.

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

А вы шифруете свои сообщения?

Учим теорию распределенных систем бесплатно, без регистрации и смс

#distributedsystems #learning #course

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

Сегодня я хотел бы порекомендовать отличный (и бесплатный!) курс по распределенным системам от Мартина Клепманна. (А он между прочим автор того самого Кабанчика). Осторожно - все на английском!

Курс преподается в University of Cambridge.

Что полезного можно узнать из курса?

- что такое распределенные системы и как узлы могут коммуницировать между собой

- канонические теоретические задачи от двух генералов до Византийских.

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

- понятие репликации и кворумов, а также алгоритмы броадкаста сообщений

- алгоритмы консенсуса - от самых простых до еще более простых (RAFT)

- как функционирует Google Spanner и разные средства для коллаборации между пользователями

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

Более упрощенно и живо о распределенных системах говорит Chris Colohan в этом курсе.

Более академично (и слегка монотонно) Lindsey Kooper рассказывает еще в этом курсе. Контент очень перекликается с Клепманном. Чуть более подробно рассматривается время и синхронизация в системах. Мало практического применения.