AutotestЯк

Народ, збираю мітап-тусу в Києві 22–23 серпня — про лайфхаки, інсайти та рецепти агентної оркестрації. Формат — unconference / open space: максимально пряме спілкування, програма народжується прямо по ходу. На старті слоту збираємо питання з аудиторії — і гайда їх розгрібати, стрімлячи практичну складову в реальному часі й організовуючи воркшопи на ходу. Фокус на офлайні; для тих, хто не в Києві, буде стрім для учасників. Два дні (а може два по 0,75, а може один повний — ще думаю), з перервами на перекуси/обіди — їжа прямо на місці, входить у вартість. Що привезу. Останні пів року я будую "агентну систему оркестрації". Чесно — цілі високі і красиві, реальність скромніша :) але сетап уже живий і робочий: — оркеструю всю свою роботу (3–5 паралельних треків-проектів) у межах трьох підписок Max 20x на Claude Code + ChatGPT Pro 5x (Codex) + SuperGrok; — моделі ганяються як на нативних харнесах, так і на "чужих", і навіть на "чистих" без системного промпту: GPT-5.6 Sol їздить як codex, claudex (Sol на харнесі Claude Code) і pi-sol (чиста Sol); те ж саме з Grok — grok build, claugrok, pi-grok. Останній — темна конячка: найстрогіша модель з усіх, незамінна там, де треба над-задротське рев'ю алгоритмів і правил через призму абсолютної коректності; — вся диспетчеризація по цих моделях/агентах іде автоматично з головної сесії — за типом роботи та обставинами; — сесії самі стежать за своїм бюджетом контексту, самі зберігають стан у потрібні моменти, самі флагають місця, де обов'язкове око людини, самі визначають, яке рев'ю і від кого потрібне, і самі входять в "економічний режим", коли тижневі вікна добігають кінця; — пакет неочевидних інсайтів (з тестів) про форми правил для різних моделей. Наприклад, Opus 5 провалює partial antecedent у прозі: правило каже "перед пушом у main зроби X" — Опус бачить у транскрипті "pushed" і вважає X зробленим, не перевіривши, куди саме був пуш. Псевдокод у процедурній частині правил це лікує — а без нього оркеструвати на Opus 5 доволі ризиковано; — пайплайн генерації документації на проект — з улюбленою деталлю: записали живу зустріч-срач з розробниками, збудували з того запису персони цих девів — і далі тестували дизайн документації, ганяючи його проти цих персон :) — і ще є персона живого крутого дева, яка пише мені CRM :) — збудована з півсотні його опублікованих принципів. Наступний етап — уже в процесі — персони самого себе :) Окремо для QA-люду: чимала частина цієї кухні — це, по суті, мій QA та SDET досвід, застосований до роботи агентів. Багатомодельне адверсарійне рев'ю, увага до строгості моделей у ролі рев'юера, фундаментальні принципи розробки та автоматизації, застосовані до процедурних артефактів оркестрації — правил, протоколів, чеклістів для агентів. Хех, це я так виправдовую свій QA досвід, намагаючись побудувати місток до QA спільноти 🤡 — насправді ж, у себе в голові я добряче знецінюю мою власну QA-ну експертність. Але я схильний перегинати, тому — подискутуємо наживо 🙂. Я планував спершу довести все це до красивого публічного стану — але це ще надовго, а щось корисне можна забрати на озброєння вже зараз. Та й мені жива критика зараз цінніша за відполірованість 😇 Тому й вирішив не тягнути. По оплаті — формат "відповідальний соціалізм" (що це таке — нижче 👇): заявлена ціна 700 грн/год (годин буде від 8 до 16 — ще думаю). Чесно: через експромтний формат я й сам не певен, що подія витягне заявлену ціну :) — це радше умовний ідеал: вийде класно — саме таку ціну я вважаю чесною і справедливою; будуть косяки — відповідальний соціалізм усе вирівняє. ☝️ Бо платити можна стільки, скільки можеться і відчувається по отриманій цінності, і коли зручно — наперед, у день, або "потім колись" (нагадуватимемо м'яко). Сподіваюсь, хоч на їжу та оплату простору назбираємо 😇 Будуть ще спікери — домовимось і поділимось "заробленим". Спікерство, до речі, відкрите: не обов'язково підписуватись наперед — можна відстендапити прям у моменті, якщо випаде нагода. Відгукується? Пишіть у коменти: бажаний формат (онлайн/офлайн) і що саме хотіли б отримати (чи чим поділитись) — теми та питання збираю вже зараз. P.S. Реєстрація поки — фактично коментами під цим постом. Я хочу спочатку пристрілятись, зрозуміти скільки людей збирається саме на офлайн. А далі вже і в приват кожному написати зможемо і окремо буде пост з посиланням на реєстрацію через якусь форму.

Йо, сходіть хтось на парті хард в Києві 18го, розкажіть що там цікавого, бо у мене ніяк не вийде... 18.04.26 Кийов - Party Hard #11 Найкулураніша конференція для QA та всіх інших айтівців! Локація настільки класна, що аш дуууже треба багато людей! Деталі тут: https://partyhard.com.ua/

«Покеляйте ваші CLAUDE.md!» – кричить радісно Тео після виходу нещодавнього Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?... Радісно бо "а я давно казав", але ж і доволі клікбейтно, бо насправді там уся історія про "умійте їх готувати" 😇. У будь якому випадку прокричав супер корисно, бо власне і поділився своїми інсайтами, а я вже тут ділюсь своїм їх конспектом ↙️. 🦉 Ключовий підхід: не генеруйте claude.md зі старту і не напихуйте туди купу ваших побажань, починайте без нього. Ідея — дописувати туди щось тільки тоді, коли агент почав тупити й не вийшло за допомогою архітектури самого фреймворку/коду зробити так, щоб він не тупив. По суті Тео (не знаю чи свідомо) референсить супер мною коханий ґайдлайн, що формулював ще Скот Мейерс: «Make interfaces easy to use correctly and hard to use incorrectly». 💰 Рецепт: можна залишити в claude.md тільки інструкцію, щоб агент дописував у цей файл якісь пропозиції у всіх випадках, коли в нього стаються затупи при роботі з кодом, і тоді, типу, рев'ювити кожну таку пропозицію. ☝️ Конкретно у Тео (якщо я правильно його зрозумів) статистика така, що 1 із 5 таких пропозицій він залишає в claude.md, а в 4 із 5 просто бачить, що це треба на рівні коду змінити архітектуру. Пару трюків: - 💰 розуміючи, що агент схильний "забагато всього враховувати", можна час від часу брехати йому, щоб він не відволікався, типу: "ми ще не в проді, не думай про кінцевих юзерів, просто зарев'юй схему БД і запропонуй, що змінити, щоб досягти того-то..." - 💰 якщо є кроки 1, 2, 3, і агент тупить над кроком 2, просіть його одразу зробити крок 3 — тоді він у більшості випадків вибереться з порочного кола. А що по самому гучному дослідженню? – Хех, ну... доволі примітивне, але зате дало привід гарному обговоренню на Хакер Ньюз з якого можна понатягти ще кучу інсайтів. В коментах залишу самері яке мені нагенерив Клод. Можете поділитись вашими персональними інсайтами яких там нема, а я побіг видалятичистити свій CLAUDE.md 😇

Пів року тому я закінчив інтерв'ювити серію кандидатів на топову сеньйорно-лідуючу позицію. Проінтерв'ювив біля 20 крутющих кандидатів. І один з них... Мене вмовив на те щоб викласти запис в паблік на його каналі, запис, який, зовсім не планувався до викладання, а був призначений для внутрішньої оцінки кандидата іншими членами команди. Може я ще встигну про це пожалкувати, хто зна:) А поки – рекомендую вам пошукати на ютубі відосик з назвою "Приклад крутої співбесіди на позицію Senior AQA" 😇, ще й краще шукати саме по тексту "співбесіда на позицію Senior AQA". Заодно подізнаєтесь кучку моїх секретиків в плані проведення інтерв'ю. Значна частина інтерв'ю це реальне код-рев'ю демо проекту на playwright, де, певен, щось цікаве та й знайдете, та ще й можете самі себе протестувати, ставити на паузу, аналізувати код, і потім звірятись з тим що озвучує кандидат, і що озвучу в кінці я у своєму власному відгуку на код. P.S. прям, не полініться, пошукайте самостійно без прямих посилань щоб допомогти автору підняти відео в рекомендаціях

Треба допомога:) Ми з командою час від часу проводимо співбесіди для наших клієнтів, і я люблю понадавати якихось реальних задачок на співбесіді, наприклад, провести повноцінне код рев'ю якогось фреймворку з тестами на Web UI. І от у мене є такі приклади проектів на веб, але немає на апі :). Треба такий проект щоб якби не все там було "ідеально", щоб було що порев'ювити. Може хтось може поділитись своїм, чи "друга" проектом на гітхабі з апі-тестами? Той проект який мені найбільше сподобається – тому ще й прийшлю відповідне код-рев'ю персонально від себе :)

#діскорд 18:00 сьогодні буде остаточний розйоб Playwright MCP сервера Та порівняємо Windsurf/Cursor з JetBrains IDEs + Julia https://discord.gg/JeeAakd5?event=1364312617640001657

Тільки помітив cyborg тести @xotabu4-a 😇. Ще не закопувався, але вже пахне тим напрямком про який я фантазував весь свій час у тестуванні. Попросив свою команду швиденько глянути, і чекнути що там і як, враховуючи те що ми наразі на прикладі тестомата студентам своїм синхронізацію автотестів з ТМС показуємо. Нижче репорт по кіборг-тестам з легким порівнянням на тестомат від Олени Долженко. А свої коментарі/короткі-враження залишу в коментарі до посту. =============== "ТMS не потрібні" — ніби поки занадто гучно сказано, як можна зробити висновок з цієї презентації... Є в Тестоматі, наприклад, зручні можливості, які не покриваються цією новою "кіборг"-тест-лібою: - UI для зручного менеджменту тестів, клікаючи по кнопках — фільтрувати, сортувати, присвоювати теги, прив’язувати Jira-тікети, і потім ці теги прилетять і в код автотестів при синхронізації. - створювати тест-плани за тегами, фільтрами і запускати їх з UI на віддаленому CI-сервері. - Тестомат підтримує багато мов і тестових фреймворків, а ця нова ліба поки тільки JS+Playwright. Це в рамках порівняння лише того функціоналу Тестомату, який був нам потрібен у рамках курсу, і відповідно досліджувався. Можливо, у Тестомату ще є багато фіч, якими ми ще не користувалися... Щодо мануальних тестів — "кіборг"-варіант особисто мені на підставі власного досвіду з менеджменту мануальних тестів сподобався тим, що: - всі тести — і мануальні, і автоматизовані — зможуть жити в одному проєкті під гітом. Писати, редагувати, рефакторити мануальні можна в улюбленій IDE з усіма її зручностями і фішками. Можна виносити мануальні степи в змінні, методи, робити з ними PO, щоб зручно перевикористовувати тощо. - можна міксувати степи в одному тесті — автоматизовані, наприклад, прекондішени, посткондішени або самі деякі степи, плюс мануальні степи, де виконання скрипта призупиняється і керування браузером передається тестувальнику, який вручну робить те, що неможливо автоматизувати (наприклад, перевірка якості відеодзвінків, де логін, початок дзвінка можна автоматизувати, а степ, де треба перевірити, як чутно та видно відео, — вже мануальний, або щоб вручну пройти капчу). Що варто було б прояснити на практиці згодом, коли буде вже реліз: - для комплексного репортингу (і мануальні, і автоматизовані — в одному репорті) використовується окремий сервер — його треба піднімати та обслуговувати самостійно. І, мабуть, знадобляться значні ресурси, адже записується відео кожного рану, стан браузера на кожному степі, логи консолі... - ніби ліба буде опенсорсною, тільки AI (за бажанням) платно, поки без подробиць. На сайті лише форма запису у вейт-лист. Окремо зауважено в подкасті - не "злетить" з мобільними тестами, не буде повного крос-браузер, крос-ОС, обмежена версіями браузерів самого Playwright. UPDATE від @xotabu4: «Доречі, після підкасту вже поінвестигейтив - з мобільними тестами взлетить, просто не буде такого класного репортингу» 🫶🏻

Го тестити virtuoso.qa на стрім https://youtube.com/live/UqiuIw9AsL0 !!!

Ми автоматизуємо тести не для тестувальників ✋🏻, а для розробників 🦾. Ціль не у тому щоб допомогти з мануальною рутиною тестувальникам на стадії тестування, а у тому щоб помогти розробникам не пропустити дефекти, які вони «тільки що наробили» і от от хочуть уже перевести таску в done чи ready for test... ну а далі «класичний пінг-понг» між тестерами і девами 🏓... Тут можна довго придиратись до формулювань, адже з якого це дива взагалі ділити на «це тестування» а це «ще не тестування». Так і є... Але тут трюк в акценті. Якщо трошки змінити кут зору, то можна почати бачити оптимізації там, де раніше вони були не очевидні. Якщо ми починаємо більше думати про розробників, максимально «ближче до них» впроваджувати автоматизацію і інтегрувати її саме у «життя девів», то починає виявлятись що навіть меншою кількістю покриття ми досягаємо більшого в плані якості. Деви тупо починають «менше робити багів». І в цю ж тему відповідно до розгляду куча практик від розподілу покриття по піраміді до банального включання навіть end-to-end тестів у репу самої апки. Ясно що виключення є скрізь, але, можливо... і враховуючи принцип YAGNI - це «енд ту енд тести окремо від коду проекту є виключенням ніж навпаки». Раз уже наш клієнт - це деви, то чому б і тести не «тримати поближче до них»... Про от це «ближче до того де воно використовується» – ось ця гарна стаття https://kentcdodds.com/blog/colocation 😉 Цікавий термін co-location... Вперше почув) Зазвичай це cohesion-ом обзиваю, та й оригінально з появою React-у саме цей термін і використовули як селлінг поїнт його підходу «вью та логіка вью разом», але щось є у ко-локації - якось більш прямо говорить про що воно 😎

Який потрібен софт, щоб допомогти громаді самоорганізуватися та почати вирішувати свої проблеми? Один з проектів, які можна обрати на Міському таборі для підлітків від школи Майбутні на весняних канікулах — це розробка таск-менеджера для громад. Ми зберемо команду підлітків для розробки таск-менеджера, який зможе використовувати будь-яка політична спільнота — від шкільного самоврядування до об'єднаної територіальної громади. В режимі хакатону розробимо і запустимо продукт та почнемо тестувати його прямо на таборі. Як громада може визначити свої проблеми і потреби? Хто в громаді може взятися за пошук рішення? До вирішення яких задач треба залучати державу, а з якими проблемами можна впоратися своїми силами? Який сервіс і софт потрібні, щоб громада самоорганізувалася? А що потрібно окрім софту? — це питання, над якими працюватимемо. Проєкт будемо створювати за ментороством політологів, правників та власне мене, Яші Крамаренко 😇 🗓️ Міський табір триватиме на весняних канікулах з 25-29 березня в приміщенні школи на Подолі. Опис інших проєктів і реєстрація на табір на сайті🕹️

На стрімі промайнуло – як набиратись досвіду щоб знайти першу роботу, але здається там я не резюмував мій основний лайф хак: «шукати цікаві оупенсорс проекти чи альфа/бета-версій цікавих апок і гайда тестить, заводить баги». Можна самотужки, навіть в незалежностів від команди таких апок - пройти весь цикл, від декомпозиції функціоналу і побудови функціональної карти + чеклістів, написанню простого власного тест плану (що я буду тестить (скоуп)? як (принципи)? чим (інструменти)? коли?), і аж до автоматизації відповідних сценаріїв, власного прослідковування покриття, заведенню багів і спілкуванню з командою, перепровіркою фіксів, регресії на релізах... І ось вчора список таких апок для першого досвіду поповнився https://github.com/diia-open-source 😉

Го тестити virtuoso.qa на стрім https://youtube.com/live/UqiuIw9AsL0 !!!

AI-Powered Test Automation, це вам не півники смоктунці полизувать) У цю середу, 13го березня о 19:00, обскакаємо virtuoso.qa, і подивимось де він на шкалі між мустангом 🐴 і ... поні 🐎 (нехай всі поні мене пробачать... 😇) Посилання на live stream скину уже…

AI-Powered Test Automation, це вам не півники смоктунці полизувать) У цю середу, 13го березня о 19:00, обскакаємо virtuoso.qa, і подивимось де він на шкалі між мустангом 🐴 і ... поні 🐎 (нехай всі поні мене пробачать... 😇) Посилання на live stream скину уже в середу десь там за годинку до старту... або підпишіться на канал у ютубі щоб не пропустити, канал зветься так само як цей, шукайте autotestyak 😉

«А хто лідує цей проект? В плані якості... 🤔 Ніхто? А, ну самі розбирайтесь, знаю я ваші ці стартапи, коли звалюють усе на одного джуна чи мідла» От не один раз я вже чув таке від тестувальників в контексті вибору нового проекту для роботи. Чомусь багатьох умовно молодих по досвіду інженерів – лякає «повна организація процесу QA з нуля, та ще й коли ти один»... Мені це завжди було важко зрозуміти, бо у самого завжди слина текла на такі проекти – це ж скільки простору для само-розвитку і головне «зробити все саме так як хочеться, і щоб ніхто зверху палки в колеса не вставляв» 😇 А ще – не пам'ятаю щоб коли потрапляв у такі ситуації (а на відсотків 90 лиш в такі я і потрапляв) – то я використовував для власне налаштування процесу щось інше окрім здорового глузду та відкритої структурної комунікації з розробниками для спільного вирішення ключових питань. Раптом дивним чином виявляється, що достатньо взяти відповідальність, проаналізувати проблеми, щиро поділитись ними з іншими членами, сформувати потреби, набрейнстормити по ним варіанти вирішення і дуже швидко звичайна логіка допомагає знайти оптимальне рішення... Не читаючи 100500 книжок по QA, не залучаючи супер-мега консультантів, і так далі 🤡 нЄ? Давайте от сходимо на TechMeetup від QArea і послухаємо що Артем Григоренко розкаже з цього приводу? Навіть так, саме ви (поки я навіть пости тут постити не встигаю) сходите послухаєте Артема, а тут у коментарях поділитесь зі мною інсайтами, і можливо подискутуєте зі мною по темі:) 🙏🏻 Всі виручені кошти від даного заходу будуть передані на підтримку ЗСУ або інші благодійні цілі. 7 березня о 18:00 👉 https://tech-meetups.qarea.org/more-details-organization-of-the-quality-assurance-process

Ще 14го листопада мій хороший товариш та продакт менеджер (довоєнний бо з початку доброволець) оголошував збір з ціллю в 250к. За десяток днів, хлопцям ще не вистачає біля 70к на очі в небі. Давайте допоможемо чим зможемо 🎯 🔗Посилання на банку https://send.monobank.ua/jar/7xUq6azYSD 💳Номер картки банки 5375411210427436

Чи прям так playwright 🎭 швидше за SElenium ⚛️? 🤔 Ми 🎭 використовуємо на деяких проектах вже давно, але я так ніразу і недобігав реально зрівняти швидкість. І от – припекло🤡 А то Рома от останнім часом «кричить» що «селеніум тепер тільки для бабуїнів» (це моя дуууже вільно-перекручена інтерпретація сенсу, ги) а я якось для себе ще крапок над і не розставив... ну бо 🎭 тільки під web, бо API все ще формувався, до сих пір доволі не консистентний місцями, часом радикально стрибав у інший бік (слава богу що правильний – це я про page.locator замість усього іншого). І от я вже почав переживати що я зовсім не в тренді... Не солідно 🙂 Так от, ми тут поки дуже простенький End-to-End на TodoMVC апку запустили, типу всі види операцій по черзі проробити у сценарії. На 10тьох ранах (так, так, знаю що мало, але грець з ним) – Мінімальна різниця в часі – 11% відсотків усього! Опа опа, такий вже прям і швидший? 🙂 ... Це я так інтригу тримаю... Ну ок, таки є стрибки і аж до 64%. І середня різниця виходить – 35%, що вже не так і мало... Але тут є ще один цікавий нюанс... Зрівнювали ми не з чистим SElenium а саме з SelenideJS, тобто селенідоподібним врапером обмазаним зсередини розумними неявними очікуваннями а ззовні лінивими елементами – що самі по собі давлять на гальма поверх чистого селеніуму (все заради добра, стабільності тестів, і все таке, але зараз не про це), і якраз от ця різниця десь приблизно і лежить в залежності від ситуації між 25 і 75 відсотками (це я знаю бо тестив не раз всі свої селени/селеніди в порівнянні з селеніумом). Виходить цікавий висновок – саме в порівнянні з чистим селеніумом ймовірно не на так багато плейврайт і швидше 🤡 Але якщо порівнювати його з чимось типу селенідів що = селеніум + окрім усього + вбудовані очікування на кожен чих, то отримуємо вже щось типу 35% на користь плейврайту... І дуже може бути що якраз ці 35 відсотків і пов'язані з тим що плейрвайт більш ефективно саме "неявно чекає", адже саме в цьому вся фішка його движку, який побудований на набагато ефективніших з точки зору "комунікації" вебсокетах а не http як селеніум... Тепер питання – чи дійсно того як чекає плейврайт – достатньо? чи настільки ж він стабільний з коробки як селеніди? І якщо так, чи можемо ми на боці селенідів таки зменшити відставання від 35% до чогось хоча б близького до спостереженого мінімуму в 11% у наших тестах...? P.S. Далі буде ще серія постів про плейврайт та його порівнянь з селенідами, включно по нюансам синтаксису, тому stay tuned 😉 Для тих хто любить спойлери – по нашим останнім зрівнянням – 🎭 хоч і не так красиво і консистентно але по суті дублює синтаксис селенідів, що означає що навіть врапер довкола плейврайту не особливо то вже зараз і потрібен... Хоча у мене руки все ще чухаються його доробити 🙂

Йо! Поки я дописую статтю по Optional вже більше місяця 🙈, давайте допоможемо Миколі зібрати на бандаж для 71-шої окремої єгерської бригади 🦾 🎯Ціль: 25 000.00 ₴ 🔗Посилання на банку https://send.monobank.ua/jar/3ftMx9cUQ9 💳Номер картки банки 5375 4112 0936 1141

Висновок 1: Optional<User>.empty() не те ж саме що Optional<Address>.empty() ... в той час як null один і той самий що в User | null що в Address | null. А раз той самий, то потенційно, чисто випадково, навіть при «Null Safety» можна передати отриманий null від функції що повертає нулабл адресу до функції що очікує нулабл юзера o_O Хех... Ну... ключове слово «потенційно» і воно ще й залежить віж того про яку мову програмування мова йде... У #java от – доволі жорстка система типів і вона буде страхувати нас у таких випадках... Наприклад, якщо у нас є метод @Nullable String getStreetFrom(@Nullable User user), що витягує з юзера адресу (якщо вона не null) а потім витягує з адреси вулицю, то #java хоч і дозволить скомпілювати //java System.out.println(getStreetFrom(null)); Але у більш реалістичній ситуації – не пропустить, якщо ми переплутаємо таки юзера з адресою: //java Address adressToBeInitLater = null; // ... і якщо ми забудемо ініціалізувати змінну, залишивши там null, // то все одно отримаємо System.out.println(getStreet(adressToBeInitLater)); // COMPILE ERROR! Тобто на практиці #java все таки вміє розрізняти null-и для змінних різного типу. Але не всі такі розумні... – #typescript от не завжди вміє:) У тій же ситуації код в #typescript скомпілюється без помилок: //typescript function getStreetFrom(user?: User): string | undefined {/*...*/} // ... let adressToBeInitLater: Address | null = null // ... і якщо ми забудемо ініціалізувати змінну, залишивши там null, // то ніхто нас не попередить про це... getStreetFrom(adressToBeInitLater) // <- COMPILED OK o_O а от з Optional такого б точно не було: //typescript import { Option } from 'prelude-ts'; // ... function getStreetFrom(user: Option<User>): Optional<string> {/*...*/} //... let adressToBeInitLater: Option<Address> = Option.none() // ... і якщо ми забудемо ініціалізувати змінну, getStreetFrom(adressToBeInitLater) // <- COMPILE ERROR 🙂 І це були тільки квіточки... Далі буде найцікавіший раунд, де Optional таки надає «Null Safety» тумаків, який все ще пропускатиме потенційні баги з нуллами. to be continued...

Резюмуємо – виходить, якщо «прості null-и» це – > все що завгодно може бути null і я не можу прослідкувати де МАНnull'ЯК вискочить і відрубає мені щось... десь... і я ще й одразу не зрозумію де саме... А «альтернатива null-aм» це – > тепер за умовченням null не може бути ніде, а там де може – треба явно це вказати, щоб потім при використанні ми були змушені ОДРАЗУ ПЕРЕВІРИТИ (найпримітивніше – через if або тернарний оператор) То для механізму Optional цією вказівкою є: * тип Коробка з МОЖЛИВО ЩОСЬ в середині (в мовах зазвичай записується як Optional<ЩОСЬ> чи Option<ЩОСЬ> чи Maybe<ЩОСЬ> чи Maybe ЩОСЬ), що відповідно може дати два представника такого типу – або Коробка з чимось типу ЩОСЬ (як то в #java – Optional<String> maybeText = Optioinal.of("some real text")`) або поки Коробка з нічим (Optional<String> maybeText = Optional.empty()) а для механізму «Null Safety» цією вказівкою є: * тип ЩОСЬ або null (найчастіше в мовах це записується як ЩОСЬ | null чи ЩОСЬ?, де, насправді, знак питання ?, зазвичай, є просто синтаксичним цукором ака шорткатом для `| null`) З цікавого... 🧐 – у #python замість знаку питання використовується тип Optional[ЩОСЬ], але насправді це не повноцінний тип, а лише «позначка» для тайп-чекерів, щоб вони застосували саме механізм Null-Safety (а не Optional!), тобто все ще мається на увазі випадок ЩОСЬ | None (в #python замість null використовується `None`) 🧐 А ще дивніше... – у #swift, де знак питання ? є синтаксичним цукором не для ЩОСЬ | null, а для Optional(ЩОСЬ) о_О. Тобто в мові під капотом живе якраз механізм Optional але синтаксис як у Null Safety 😄 Так от☝🏻– Ось це Коробка з МОЖЛИВО ЩОСЬ в середині vs ЩОСЬ або null – і є ключовою відмінністю, яка і визначає потенціал і можливості кожного з підходів... Які висновки ми можемо зробити з цього? Що випливає з того що Optional це саме коробка? 1. Раз це коробка під щось конкретне, то ми можемо розрізняти пусті коробки! Пуста коробка для сірників і пуста коробка для телефону – це зовсім різні коробки! 2. Раз це коробка, то значить можна вкласти одну коробку в іншу;) Розберемо ці висновки детальніше в наступних постах...