Робимо свою базу даних за допомогою інструментів Linux

#linux

Коротка, але дуже цікава стаття про те, як можна створити базу даних за допомогою нативних інструментів Linux - grep, cut, awk, sort, head, tail та join.

The end of the "Self-Taught Programmer"

#video

Невеличке відео, про те, що в сучасному світі стає все складніше "увійти в айті" з нуля та без профільної освіти. Якщо 5 років тому можна було дійсно за 3 місяці "залетіти", то зараз:
- вимоги вище
- вакансій менше
- конкуренція на усіх рівнях вища! (Бо на ринку повно кандидатів з досвідом)

Якщо буде два кандидати, з однаковими скілами, але в одного буде освіта інженерна (а в іншого - ні) - то скоріш за все візьмуть першого.
Але наявність профільної освіти != гарантії потрапити на роботу.

Звичайно, все ще можна потрапити в АйТі. Але процес навчання стає набагато довшим та складнішим.

Sad, but true.

Це - геніальний хід (якщо правда). Браво, DeepSeek 😀

Обережно з coding інтервʼю

Тільки вчора говорили в Діскорді про задачі на інтервʼю, тестові завдання.

А тут виявляється, шо є варіант отримати собі під час співбесіди небезпечний код, який буде шукати гаманці та намагатись поцупити вашу крипту)

Partner Chains Development Lifecycle: Our CI Evolution

#testing #automation #blockchain

Колеги з команди поділились історією розвитку нашого CI.

Наша система залежить від довжини епохи основного блокчейну. На різних енвайроментах вона різна - від 24 годин до 5 днів!

Спочатку в нас була кастомна модифікація блокчейну з довжиною епохи в 2 години.

На наступному етапі ми працювали із Cardano Preview, де епоха становить 24 години. Підтримувати CI стало набагато простіше, але тестувати - ніт. Будь-які модифікації в нашій системі можна побачити ... через 48 годин. Більшість автотестів була - "почни тест, перевір що результати два дві тому були коректні, зроби нові зміни, зафіксуй їх в тестовій базі даних". Це ... працювало, але дуже довго.


Як покращення, ми взяли тестову версію головного блокчейну (як тільки-но зʼявилась), закинули усі компоненти в Docker та запускаємо їх docker-compose. Тепер результати автотестів не треба чекати 48 годин - а тільки 15 хвилин. Це суттєво краще та зручніше.

⚡️ Episode 49: Software testing and quality culture for airlines with Simon Prior

Тестуванням для інтернет магазинів та мобільних банків вже нікого не здивуєш.

Тому в цьому епізоді подкасту ми розмовляємо з Simon Prior про тестування та культуру якості в ... авіакомпанії easyJet. Як там тестують? Як організують команди? В чому складності?

Дивитись та слухати:

🔸 Youtube
🔹 Spotify
🔸 Apple

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

Дякуємо вам!

Підтримати подкаст можна через: 🏦 База від Монобанку

#testingminutes | @a_grygorenko | Test Engineering Notes

Пост для тих, хто хоче стати QA Lead

У мого колеги з подкасту Testing Minutes, Артема Григоренко, відкрито запис на лютневий потік "Шлях до QA Leader" - курс для тих, хто хоче вирости з інженера в гарного лідера QA команди.

Чому цей курс може бути цікавим? Там буде багато корисної інформації, практичної роботи, запрошених лекторів. Навіть тим, хто вже працює лідом курс зможе донести щось нове.

Програма курсу оновлюється та доповнюється постійно. Я це знаю, бо сам цей курс пройшов 😀

📅 Коли початок? 17 лютого

💎Бронь місця - $200 (Можна оплатити частинами або через компанію👌)

Залишились питання або готові почати? Пиши в Telegram: @artem_grygorenko або шукай на сайті: grygorenko.tech

🎙 Testing Minutes: ваші запитання — наші відповіді! 🔥
Хотіли щось у нас спитати? Саме час! ;)

Ми готуємо новий епізод Testing Minutes і вирішили: а давайте відповімо на ваші запитання!

Можливо у вас було таке, що слухали наш подкаст і думали: “От би спитати їх про це…”? Або просто цікаво дізнатися щось про нас, нашу роботу, думки чи факапи?

Заповніть формочку нижче і чекайте на наступний епізод:
https://forms.gle/93VqjTCJK5cRGD7J6

Про інформацію й знання

Іноді ми використовуємо слова інформація та знання як одне й те ж, хоча це різні поняття.

Інформація - це "сирі" дані в поточному контексті. Для прикладу, факт того, що Microsoft купила якусь компанію з мільярд доларів - це лише інформація. Інформації в сучасному світі вдосталь.

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

Питання інформації й знань також дотичне до вибору будь-яких тренінгів й курсів:

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

Хороший курс може суттєво пришвидшити ваше навчання й бути наче тим підвісним містком між незрозумілими концепціями та усвідомленим застосуванням.

Тестування просте, казали вони ...

⚡️Голосуємо за тих, хто розвиває тестування в Україні!

Цього року DOU Awards повертається із новими номінаціями. Ви можете підтримати своїм голосом багато корисних проєктів та людей, що рухають індустрію вперед.

В категорії "Вони надихають" можна проголосувати за наступних кандидатів, яких ви напевне знаєте:

- Артем Григоренко з каналу "Нотатки суворого QA"
- Артур Шевченко з каналу "From A to QA"
- Саша Хотемський з каналу "Hot Testing"
- Роман Марінський з "QA Club Lviv"

🪤Важливо! Обрати можна лише трьох! То ж обирайте тих, хто вам більше подобається.

Або ж можна запустити цей скрипт й він згенерує вам імена трьох кандидатів випадковим чином.

import random
from itertools import combinations

candidates = ["Arthur", "Oleksandr", "Roman", "Artem"]
combos = list(combinations(candidates, 3))
random_combo = random.choice(combos)
print(random_combo)

В FAANG (Big Tech) компаніях немає тестувальників

Дуже часто чую думку, що в у технологічних лідерах ринку зовсім немає тестувальників. Усі - тільки менеджери та програмісти. І всьо.

Але ось знайшов лінку, де можна подивитись інформацію про вакансії тестувальників в Apple, Amazon, Nvidia.
Так, це вакансії з Долини. Але можна подивитись на вимоги та бажані навички.

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

Модель отримання навичок братів Дрейфус

#thinking #learning

Коли ми навчаємось чи навчаємо когось (як ментор чи на курсах), треба розуміти як люди взагалі отримують нові навички. Одна з моделей, яка може розповісти про це - це модель Стюарта та Губерта Дрейфусів. Згідно з цією моделлю, кожен студент проходить крізь пʼять різних етапів: новачок, просунутий початківець, компетентний спеціаліст, досвідчений спеціаліст та експерт.

Етап 1 - Новачок

У новачків немає або дуже мало досвіду. Новачки навіть не стільки вчаться, скільки хочуть виконати конкретну задачу в моменті часу. Новачкам потрібні рецепти (покрокові інструкції).
Проблема з рецептами в тому, що вони позбавлені контексту. То ж неможливо зробити "універсальні рецепти на усі випадки".

Етап 2 - Просунутий початківець

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

Етап 3 - Компетентний спеціаліст

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

Етап 4 - Досвідчений спеціаліст

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

Етап 5 - Експерт

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

Гаразд, але що з того?

- Більшість людей знаходяться на рівні просунутий новачок
- Новачкам потрібні люди, які б їх направляли та давали зворотній звʼязок
- Продуктивність експертів падає, якщо підходи й правила єдині для всіх рівнів
- Користуйтесь правила та гайдами для новачків, залиште інтуїцію для експертів
- Експерти не завжди найкращі вчителі, бо вони мислять паттернами, які подекуди не можуть пояснити іншим
- Кожна наша окрема навичка рухається згідно моделі Дрейфусів. То ж можна "прокачувати" навички наче окремі гілки героя в RPG
- Не достатньо просто практикуватись 10000 годин. Треба розбивати практику на конкретні задачі потрібної складності, мати постійний зворотній звʼязок щоб виправляти помилки одразу
- Для швидкого прогресу потрібно оточувати себе більш експертними людьми в команді
- Ми вчимося краще коли спостерігаємо та імітуємо. То ж сесії парного тестування чи програмування можуть стати у нагоді

Сьогодні просто цікава ілюстрація важливих навичок тест інженера. Тобто це не тільки інструменти та автоматизація ... (З матеріалів Satisfice.com)

Замість пірамід та трикутників ... Наглядний приклад, що пояснює різницю між рівнями тестування (від Wayne Roseberry)

Automated Accessibility Testing at Slack

#testing #automation

Якщо комусь не вистачає матеріалів з accessibility тестування - маю вкрай цікаву статтю. В ній розповідають як такий вид тестування виконують в Slack.
Цікаво, як завжди.

Як пишуть код в NASA

#engineering

Знайшов коротенький документ, що описує вимоги до написання коду в NASA. Тобто це "код для rocket science 🚀".

10 правил для safety-critical коду (на мові С):

1. Користуйтеся тільки простими конструкціями управління
2. Усі цикли повинні мати фіксований ліміт
3. Не користуйтесь динамічною памʼяттю після ініціалізації (привіт, Javanoscript!)
4. Функції не повинні перевищувати 60 строк (як максимум)
5. Не більше двох ассертів на функцію
6. Обʼєкти даних повинні створюватись на мінімально можливому рівні видимості
7. Результат non-void функцій перевіряє фукнція, що їх викликає; валідність вхідних параметрів перевіряється всередині кожної функції
8. Користування пре-процессорами та макросами повинно бути вкрай обмеженим
9. Посилання (pointers) повинні бути обмежені також
10. Весь код повинен бути компільованим, з першого дня розробки з усіма можливими перевірками на рівні компілятора. Усі помилки компіляції (навіть типу "warning") повинні бути виправлені одразу. Код повинен бути протестований як мінімум раз на день (більше - краще) з усіми можливими аналізаторами та із нульовою кількістю помилок.

Кожен може розробити калькулятор! (та де калькулятор краще - Android чи IOS)

#engineering

Цікавезна історія, в якій Hans-J. Boehm, що працював над власними версіями garbage collector та деякими частинами стандарту С++, отримав задачу написати ... калькулятор.
Здається, задача вкрай проста. Але це не так.

P.S. Hans навіть написав дослідницьку роботу про цей досвід - Towards an API for the Real Numbers

AI tools and how they kill learning

#ai #tools #learning

Написав невелику статтю на тему того, як сучасні інструменти зі штучним інтелектом вже зараз впливають на наше навчання. Та на навчання людей, що тільки починають в ІТ.

А як ви думаєте - чи легше стало дійсно навчитись новому з ШІ - чи складніше?

⚡️ Епізод 50: Відповідаємо на питання підписників

Чи потрібен Гітхаб для тестувальника? Які найголовніші навички QA, що приносять більше грошей? Чи переходити в розробку (бо там більше платять)? Коли AI замінить усіх? В цьому епізоді подкасту, Артем та Олександр відповідають на питання від підписників.

Дивитись та слухати:

🔸 Youtube
🔹 Spotify
🔸 Apple

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

Дякуємо вам!

Підтримати подкаст можна через: 🏦 База від Монобанку

#testingminutes | @a_grygorenko | Test Engineering Notes