Hardcore у п'ятницю: Перша ремарка про перфоманс блокчейн систем

#testing #performance #blockchain

Цього тижня я тільки-но почав досліджувати питання перфомансу блокчейн систем. А саме - як та що вимірювати.
Ось що я встиг зрозуміти.

Блокчейн систему (як дуже спеціалізований вид розподілених систем) не можна тестувати та вимірювати звичайними метриками та засобами до яких ми звикли. Тобто не буде дуже правильно ставити питання “скільки TPS (transaction per second) може витримати система?” (а люди все ще запитують)

Чому? Бо блокчейн веде себе зовсім по-іншому. В звичайній системі (наприклад у веб додатку) більшість запитів повинні отримати відповідь через деякий час. Чим більше запитів від користувачів, тим більше ресурсів бекенду задіяні в обробці цих засобів.
Для того, щоб обробляти більше запитів - ми просто додаємо більше “машин” для обробки. (Наприклад автоматично через auto-scaling).

В блокчейні такий підхід не працює.
Кожен вузол в блокчейні може обробляти деяку кількість запитів. Причому запити в блокчейні - це звичайні транзакції. Коли транзакцій стає більше, ніж влазить у mempool вузла, нові транзакції не будуть оброблятись.

Вузлу треба час, багато часу:
- Вузлу треба час, щоб зрозуміти - чи може він створити новий блок в PoS
- Або вузлу треба час, щоб підібрати потрібний хеш для блоку в PoW консенсусі.
- Треба час, для того, щоб згідно алгоритму обрати з пулу транзакції та створити новий блок.
- Вузлу треба час, щоб обмінятися з іншими вузлами інформацією про новий блок.
- Вузлу треба час, щоб вирішити конфлікти, якщо одночасно створені декілька блоків.
- Вузлам в системі потрібен час, щоб більшість з них погодились на новий блок.

В окремому випадку потрібно зачекати, поки транзакція стане “стабільною”. Це може бути N блоків поверх того, в якому ця транзакція опинилась або інший варіант алгоритму. Тільки після цього можна відправити дійсно правдивий респонс користувачеві про те, що його транзакція успішна.

То ж підвищити швидкість обробки транзакцій (тобто “перфоманс” блокчейну) не можливо простим додаванням більшої кількості вузлів. Бо вузлам потрібен час, щоб комунікувати між собою та досягти консенсусу.

Один з варіантів оцінки швидкості - це наскільки швидко буде транзакція оброблена, включена в блок та стане стабільною. Тобто block propagation time.

Попереду в мене ще багато відкриттів. Продовжую дослідження.

Збір 10 млн грн на борти Shark

DOU та KOLO організовують збір на 5 БПЛА Shark для найкращої туристичної компанії - 15-тої окремої бригади артилерійської розвідки. Пропоную долучитись до збору та допомогти нашій розвідці.

100+ Computer Science Concepts Explained

#engineering #video

Для тих, хто досі відчуває "синдром самозванця" - маю коротеньке відео, яке допоможе закрити деякі прогалини в знаннях computer science.
Це не замінник університету та навіть хорошим курсам.
Але ... допоможе не переживати щодо базових технічних знань на співбесіді.

Книжкове: Demystifying Public Speaking

#books #review

Минулого тижня я прочитав книгу "Demystifying Public Speaking" за авторством Lara Hogan.
Далі коротко розкажу чому та кому цю книжку варто читати.

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

Ця книга з категорії - "як би я хотів її прочитати років десять тому". В книзі дуже мало води та дуже багато практичних порад. До того ж - книга невелика, тому її можна швидко прочитати.

Що ви дізнаєтесь з книги:
- усі хвилюються перед виступом - це нормально
- як знайти тему для доповіді навіть якщо "нема про що розповідати"
- як підготуватися до доповіді та як збирати корисний зворотній зв'язок
- алгоритм "тренувань" доповіді перед великою конференцією
- як правильно писати Call For Papers
- як оформлювати слайди та інші матеріали
- як правильно відповідати на питання з залу
- багато іншого та купу посилань на різні статті та відео

Чого в книзі ви не знайдете?
- прикладів крутих доповідей (є декілька, але мало)
- постановки голосу, роботи з аудиторією, storytelling, різні підходи к презентаціям
- як вести воркшопи та інші типи доповідей на більше 45 хвилин

Про що робити доповідь?

#speaking

Нотатки з книги Demystifying Public Speaking.

Так, де взяти тему для доповіді (особливо першої)?
Можна розповісти базову доповідь про підхід або інструмент (intro to ...)
Або ...

Задумайтесь, на що ви витрачаєте більшість часу на роботі? Це також може бути вашою темою.

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

Кожна з тем може містити в собі історію, натхнення, демонстрацію або новий підхід для вирішення старої та відомої проблеми.

На останок шарю з вами цікавий worksheet-cхему для генерації ідей для доповіді.

П'ятничне: Про унікальний підхід до розробки у Valve

#testing #video

Коротке відео про те, як у ігровій компанії Valve підходять до тестування та як це тестування впливає на подальшу розробку.
Це наче Shift-right тестування практично з першого дня роботи.

⚡️Доброї П'ятнички друзі!

💡Сьогодні з анонсом нового продукту!
Разом із Олександром Романовим aka Test Engineering Notes ми запускаємо новий подкаст про тестування - ⏳"Testing Minutes".
Формат подкасту - це зосереджена інфа по темі без зайвої води і балачок з прикладами.
Перші наші епізоди будуть як раз на гарячі теми - це про резюме, співбесіди та навички.

Послухати перший епізод тут:
📌 Епізод 1: Де тестувальник пише резюме

Будемо чекати вашого фідбеку. Як вам такий формат, інформація. Та пропонуйте ваші теми, про які б хотіли дізнатися у коментарях!

✍️ Підписатися на подкаст

Про час на навчання та книжки

#books #learning

Про час на навчання

В кожного з нас є вільний час. Час, який можна приділити навчанню. В когось більше, в когось менше. Але як його знайти?

Можна знайти трохи часу поміж робочими задачами. Можна почати робочий день трохи раніше. Або скоротити обід та непотрібні теревені за кавою з колегами. (Але не завжди. Подекуди такі розмови дуже важливі та є головним джерелом НОВИХ думок!)
Якщо не виходить вчитися НА роботі (в чому я сумніваюся), можна вчитися ПІСЛЯ роботи.

Ба більше - можна вчитися ще й ПІД ЧАС роботи. Для цього лишень потрібно приділити трохи часу та записати, чому ви навчилися при виконанні тієї чи іншої робочої задачі. Це може бути цікавий баг, це може бути команда unix або закручений запит у базу даних, які ви не знали до того. Це може бути особливість системи, яку ви тестуєте. Чи порядок конфігурації окремого компоненту.

Згадайте це - та запишіть у нотатки. Коли ви зробите запис то краще запам'ятаєте інформацію. А ще - запис залишиться артефактом, який можна буде шукати при потребі.

Про книжки

В сучасному інтернеті дуже багато інформації: професійна література, курси, доповіді, блоги. Крім того, існують ще дослідницькі роботи та дописи в різних телеграм каналах). А скільки нового додається кожного дня!
Все прочитати хочеться, але не вистачає часу. І це цілком нормально. Потрібно робити вибір.

Як обрати дійсно корисну книгу для читання? Можна прочитати відгуки, можна запитати в людей в чатах чи на форумах.

А можна почати читати та зрозуміти - чи підходить ця книга вам саме зараз. Для мене головний показник користі від книги - це кількість нотаток, які я роблю при читанні книги. Якщо їх багато навіть на початку книги - значить "відкриттів" буде ще більше й надалі. Можна продовжувати читати.

Якщо ж ви прочитали розділ чи два - та для вас усе зрозуміло й не виникає бажання запам'ятати та занотувати думки автора - сміливо відкладайте таку книжку. Бо час - це наш найцінніший ресурс, який неможливо відновити.

Вдалого усім навчання та читання!

P.S. Цей допис навіяний книжками, що я читаю зараз та кількістю нотаток з них.
P.P.S. Тим, хто дочитав до цього моменту - пропоную підбірку тестових даних для перевірки input string параметрів.

Ines Sombra, Fastly Testing in a Distributed World

Короткі нотатки з доповіді про тестування розподілених систем

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

Які помилки можуть бути?
- Deadlock - система не може виконувати функцій взагалі
- Livelock / starvation - система працює над чимось, але не над тим, що потрібно
- Under specification - отримали месседж який не очікували отримати

Як тестують розподілені системи дослідники?

Формальне тестування
- Формальні методи (human assisted proofs) - TLA+, COQ, ISABELLE
- model checking - TLA+, MODIST, SPIN
- "Полегшені" формальні методи - ALLOY, SAT

Інші наукові підходи
- Top-Down. Ін'єкція помилок із застосуванням генераторів вхідних значень
- Bottom-up. Ін'єкція помилок керованих походженням.
- White / black box testing

"Testing Minutes: Епізод, де тестувальник пише резюме" - де слухати?

Ми тут з Артемом запустили yet another подкаст.
На прохання слухачів, викладаємо перший епізод подкасту на Youtube.
Усі лінки на платформи також зібрані в одному посиланні.

Усі побажання та коменти залишайте під відео, або під цим постом)
Дякую, що слухаєте.

Інтерв'ю для Web3 Test Series

#testing #blockchain

Нещодавно я дав коротеньке інтерв'ю для Web3Tests ком'юніті про те, що таке тестування у світі блокчейну та Web3, а також - що там по інструментам в наявності.

⚡️Епізод 2: Де тестувальник йде на співбесіду
Продовжуємо випуск наших подкастів. На цей раз пройшлись по воронці найму та різних видів співбесід.

Послухати епізод тут:
🎧 Подкаст платформи
📺 YouTube

✍️ Підписатися на подкаст

#podcast #testingminutes

Benchmarking: You're Doing It Wrong

#testing #performance #video

Сьогодні ранок вівторка, навкруги літо та спека, але цікавих матеріалів менше не стає.
Тому пропоную переглянути доповідь по дуже базовим речам з тестування навантаження. Більше про підходи та про те, чому такий вид тестування складний.

На дату не дивіться - бо такі відео довго залишаються актуальними.

Cheatsheet команд Linux

#linux #tools

Доброго ранку.
Знайшов для вас підбірку основних команд Linux. Можна проглянути та знайти ті, про які ви ще не чули.
А можна залишити в якості швидкого довідника.

Всім вдалого та продуктивного дня!

EARLY COMPUTER ART IN THE 50’S & 60’S

#curious #engineering

Сьогодні пропоную трохи відпочити та подивитись на еволюцію комп'ютерного арту - починаючи з дев'ятнадцятого століття та дотепер.

А ще, можна заповнити зарплатну анкету від DOU. Це допоможе трохи краще зрозуміти, чи актуальна у вас ЗП чи ні.

⚡️Епізод 3: Де тестувальник визначає актуальні навички

Вийшов новий епізод подкасту Testing Minutes. У цьому епізоді, я з Олександром розмірковую, які навички потрібно прокачувати сучасному тестувальнику, щоб не пасти задніх на сучасному ринку праці

🎧 Слухати подкаст тут
📺 Дивитися подкаст тут

PS. Ми дуже вдячні за ваш фідбек, і його активно використовуємо для того, щоб підвищити якість подкасту. Тому так само будемо вдячні вам за зворотній зв'язок в майбутньому. Не зупиняйтесь ;)

#testingminutes #podcast

Про ще один вид ручної праці та засоби його покращення

#ai #curious

Всім доброго ранку понеділка. За вікном в мене дощ, але це ніяк не привід зменшувати допитливість до світу технологій та тестування.

AI зараз усюди. Але щоб цей інтелект працював, йому треба навчатися на даних. В ідеалі - підготовлених.
Деякі компанії користуються послугами аутсорсерів щоб проаналізувати та розмітити дані вручну. Потім ці оброблені дані вже використовують для тренування AI моделей.

Але деякі аутсорсери пішли далі та застосували "автоматизацію" ...

Коли навчання варте зусиль?

#learning #skills

У бізнесі має місце дилема: чи розробляти якийсь інструмент всередині компанії чи купити вже готовий на ринку?

В пересічного інженера можуть виникнути подібні дилеми:
- Ви працюєте деякий час тест інженером або інженеркою та хочете навчитись автоматизації тестування.
- Ви пишете автотести деякий час та замислюєтесь - чи вчити отой модний новий фреймворк чи мову програмування.
- Ви - лід чи менеджер та розмірковуєте - чи варто самому навчитись роботі з новим інструментом чи найняти нову людину, яка вже буде мати необхідні навички.

Тобто, з навчанням новому у Вас є варіанти:
- Можна опанувати навичку самому
- Можна найняти когось іншого (делегувати)
- Можна НЕ навчатись взагалі

Які ж питання можна собі задати, коли Ви вагаєтесь чи вчити щось нове чи ні?
1. Як швидко я очікую, що практика навички буде легшою із часом? Є навички, де прийнятний результат можна отримати доволі швидко. А є такі, де треба витратити місяці та роки на опанування.
2. Як часто я буду користуватися цією навичкою? Все залежить від контексту. Якщо ця навичка допоможе зрости у кар’єрі - вона варта. Якщо ж ви не будете практикувати цю навичку - то вона швидко забудеться.
3. Чи буду я отримувати задоволення від практики навички (чи захоплює ця навичка мене)? Не треба вчитись чомусь, якщо ви не отримуєте хоча б найменшого задоволення від практики цієї навички. Навчання через “не можу” рідко буває ефективним.

Більше про те, чи варто навчатись можна почитати в оригінальній статті - When is Learning Worth the Effort?