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

#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 рассказывает еще в этом курсе. Контент очень перекликается с Клепманном. Чуть более подробно рассматривается время и синхронизация в системах. Мало практического применения.

Как работает TLS/SSL

#security #cryptography #web

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

Сегодня мы поговорим о практическом применении шифрования - TLS/SSL.

Почему тестирование - это не просто или в поисках идеального тест инженера

#testing

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

Подробнее - тут

Что такое блокчейн и как он работает?

#blockchain #distributedsystems

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

Подборка статей о тестировании и инженерии в целом [1]

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

Сегодня - компиляция numero uno.

gRPC с Postman - первые впечатления

#grpc #testing

Всем доброе утро!
Вчера попробовал Postman для тестирования gRPC сервисов.
Мои впечатления - тут

Что делать, если затянула "рутина" и совсем нет времени на обучение?

#learning

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