Результати пошуку
Знайдено 447 результатів із порожнім запитом
- Нова ера IDE: як Cursor перетворив автодоповнення на повноцінного ШІ-напарника
Ринок помічників для кодування переповнений учасниками, оскільки це одна зі сфер, де технологія штучного інтелекту приносить дохід. Водночас жоден з інструментів не збирав стільки захоплених відгуків розробників, як Cursor — IDE, заточена під роботу з ШІ. Ним користуються інженери з Midjourney, Perplexity, Shopify і OpenAI та про нього говорять лідери галузі. Андрій Карпаті, колишній керівник ШІ в Tesla та дослідник OpenAI зізнався , що із переходом на Cursor+3.5 Sonnet основною мовою його програмування стала… англійська. У цьому матеріалі розбираємося, що таке Cursor, його особливості та як він працює «під капотом». Артур Середа, Front-end Developer в Promova та Руслан Терехов, Full Stack Team Lead в Universe Group поділилися враженнями від інструменту та досвідом, чи можна в ньому програмувати природною мовою. Що таке Cursor Cursor — це інтелектуальний редактор коду, розроблений компанією Anysphere. Він є «форком» Visual Studio Code, продукту Microsoft з відкритим вихідним кодом. Cursor інтегрує штучний інтелект, зокрема моделі GPT-4 та Claude 3.5 Sonnet, безпосередньо в процес написання коду, щоб допомогти розробникам швидше писати, аналізувати й змінювати код. «Наша місія — зробити програмування на порядок швидшим, веселішим і креативнішим», — цю думку Майкл Труелл, один з фаундерів Cursor, повторює знову і знову у різних інтервʼю, фокусуючись на слові «веселий». На його думку, програмування десятирічної давнини було нудним — суцільні шаблони та бойлерплейти. Натомість сучасні технології дозволяють повернутися до справжнього інженерного креативу та швидко реалізовувати круті ідеї. За даними IDC , до 2028 року кількість розробників збільшиться до 57,8 млн. Cursor обрав перспективний ринок інструментів для розробників, який має високу конкуренцію (CodiumAI, Continue і Tabnine тощо) та сталого лідера — згідно з опитуванням розробників StackOverflow за 2023 рік, 73,6% розробників надавали перевагу Visual Studio Code. Чи були у Cursor шанси конкурувати з лідером серед IDE? Команда Anysphere, що складалася з п’яти осіб, крім могутнього конкурента обрала також амбітну мету — реалізувати значно більше функцій у короткий термін. Історія створення 2020 року OpenAI опублікувала проривне дослідження, відоме як «Закони масштабування» . У тексті йшлося про спостереження, що продуктивність великих мовних моделей можна значно покращити без значних змін в архітектурі. Для цього потрібно масштабувати всього три показники — обчислювальні ресурси, обсяг даних для навчання і розмір моделі. Ця переломна подія надихнула чимало розробників обрати майбутній напрям роботи. Серед них було четверо старшокурсників Массачусетського технологічного інституту — Майкл Труелл, Суале Асіф, Арвід Луннемарк і Аман Сенгер. Через два роки вони заснували компанію Anysphere та створили прототип Cursor. Співзасновники Cursor: Аман Сенгер, Арвід Луннемарк, Суале Асіф і Майкл Труелл Під час навчання в MIT вони стали близькими друзями. «Ми були прихильниками чистого Vim та терміналу. Але нам так кортіло спробувати Copilot, що довелося перейти на VS Code — єдиний редактор, де був доступний цей ШІ-інструмент», — згадують фаундери під час інтервʼю з Лексем Фрідманом. Під час навчання Труелл і Сенгер взяли участь у програмі Neo Scholars — наставницькому проєкті для студентів технологічних спеціальностей від компанії Neo, яка також керує акселератором і венчурним фондом. Саме вона стала першим інвестором Anysphere. Команда зосередилася на створенні інструментів для розробників. Наприкінці 2022 року вони отримали ранній доступ до GPT-4 та зрозуміли, що ШІ стане ще потужнішим. Тому варто переосмислити, як штучний інтелект інтегрується в процес редагування коду. Так виникла ідея створення IDE Cursor, — але не чергового розширення для VS Code, а окремого редактора. «Коли люди думають про «штучний інтелект плюс кодування», вони зазвичай асоціюють його з автозаповненням. Ми вважаємо, що GitHub Copilot та інші вже зробили це достатньо добре, зосередились на інших функціях — пошук і виправлення помилок, а також запитання та відповіді на основі коду», — ділився Арвід Луннемарк. Восени 2023 року компанія закрила початковий раунд у розмірі $8 млн під керівництвом OpenAI Startup Fund. Прибуток та база користувачів швидко зростали. Якщо у квітні 2024 річний виторг складав $4 млн, то у жовтні — $48 млн. У серпні 2024 компанія залучила $60 млн у межах раунду фінансування серії A з оцінкою $400 млн. Серед інвесторів — Andreessen Horowitz, Thrive Capital, OpenAI, Джефф Дін, Ноам Браун, а також засновники Stripe, GitHub, Ramp, Perplexity та OpenAI. Всього за 4 місяці фаундери оголосили про залучення $100 млн у раунді серії B з оцінкою вже в $2,6 млрд. Також восени 2024 року компанія оголосила про придбання одного з конкурентів — Supermaven, контекстно-орієнтований інструмент з автодоповнення коду. З чого складається Cursor Коли система працює з кодом, вона повинна мати доступ до контексту, щоби правильно розуміти, що відбувається у вашому проєкті. Cursor може бачити багато рядків коду чи файлів одночасно та розуміти, як взаємодіють різні частини вашої кодової бази. Хоча система отримує велику кількість інформації, вона не генерує стільки токенів — це означає, що модель не повинна створювати багато нового тексту або коду, а швидше використовує наявний контекст для виконання операцій, таких як пошук, редагування чи інтерпретація коду. Cursor використовує специфічний підхід, а саме розріджені моделі. MoE (Mixture of Experts) — це підхід машинного навчання, який поділяє модель штучного інтелекту на окремі підмережі (або «експертів»), кожна з яких відповідає за певне завдання або тип задач. Кожен «експерт» у системі MoE навчається на певному типі даних або завдань, що дозволяє йому стати фахівцем у своїй області. Наприклад, аналіз помилок, рефакторинг, автодоповнення. MoE допомагає системі швидко знаходити та застосовувати відповідні частини контексту без надмірного навантаження на ресурси. Замість того, щоб генерувати велику кількість нових токенів для кожної операції, модель вибирає найбільш релевантний контекст і на його основі виконує потрібну задачу. Завдяки такій архітектурі моделі MoE можуть масштабуватися до дуже великих розмірів, зберігаючи при цьому ефективність. Що вміє Cursor Composer Це розширена функція, яка допомагає досліджувати код, писати нові функції та змінювати існуючий код, не виходячи з робочого процесу. Composer дозволяє створювати файли та редагувати декілька файлів одночасно, що значно прискорює розробку. Під час створення підказки можна посилатися на файли — наприклад, знімки екрана, схеми бази даних і навіть текстові файли. Активувати Composer можна з допомогою клавіш Command+I, після взаємодіяти з ним у двох режимах: Normal та Agent. У режимі Normal можна шукати відповіді по кодовій базі та документації, використовувати вебпошук, створювати та редагувати файли, а також отримувати розширені команди за допомогою символу @. Режим Agent надає можливість автоматично отримувати релевантний контекст, виконувати команди у терміналі, створювати та змінювати файли, здійснювати семантичний пошук по коду та виконувати операції з файлами. Cursor Tab — автодоповнення «на стероїдах» Ця функція спеціально розроблена для покращення автодоповнення коду та передбачення наступних редагувань. Cursor Tab не лише вставляє код у поточному місці курсора, але й пропонує повне редагування навколо нього, а також передбачає, куди користувач, ймовірно, захоче перемістити курсор далі. Це дозволяє швидко вносити зміни та підвищує ефективність кодування. «Ніби поруч є дуже швидкий колега, завжди готовий допомогти та знає, що ви хочете зробити далі. Але можна зробити цю концепцію ще амбітнішою: не просто передбачати символи після курсору, а фактично весь наступний крок», — так пояснював роботу цієї функції Майкл Труелл. Agent Mode Cursor може працювати в напівавтоматичному режимі, де він не лише генерує підказки, але й виконує цілі завдання. Наприклад, «згенеруй CRUD-операції для цього API». Cursor створить код, необхідні маршрути, і навіть перевірить коректність виконання. Покращений контекст В Cursor є можливість з допомогою анотацій посилатися на різні джерела даних, зокрема файли, папки, документацію або навіть на всю кодову базу. Основна ідея в тому, що Cursor дозволяє зв'язувати різні елементи вашого проєкту (код, файли, вебсторінки) в єдиний контекст, що полегшує навігацію та роботу з ними. Спілкування будь-де Більшість сучасних помічників програмування ШІ обмежуються двома функціями: завершення коду в редакторі та окреме вікно чату, яке забезпечує розмовний інтерфейс, подібний до ChatGPT. В Cursor є можливість викликати поле введення чату будь-де — у редакторі коду, на бічній панелі чи у вікні термінала. Для цього потрібно обрати блок та натиснути Command+K, щоб переписати чи змінити його, або натиснути Command+L. Робота в терміналі Особливістю Cursor є можливість працювати безпосередньо в терміналі через вікно чату, використовуючи природну мову. Вам не потрібно пам'ятати складні синтаксиси або шукати приклади команд — ви просто описуєте те, що хочете зробити, а Cursor генерує відповідні команди для виконання в терміналі. Наприклад, ви можете сказати «створи Docker контейнер для цього проєкту», і Cursor згенерує і введе всі необхідні команди для створення контейнера прямо в термінал, без ручного введення. Редагування коду природною мовою Cursor також дозволяє вносити зміни до коду через текстові запити природною мовою. Наприклад, «зміни цю функцію так, щоб вона підтримувала асинхронність». Вибір моделей Cursor надає доступ до таких моделей, як Claude 3.5 Sonnet і GPT-4o. Також розробники можуть підключити свої облікові записи та підписки, щоб використовувати моделі від Anthropic, Microsoft Azure, OpenAI та Google. Також є можливість перемикати моделі, залежно від завдань. Claude 3.5 Sonnet у Cursor Я протестував Cursor на власних pet-проєктах, а згодом спробував інтегрувати у роботу. Найбільш разюча відмінність від того ж Copilot — здатність індексувати кодову базу. Copilot цього не вміє, відповідно не бачить нюансів та залежностей, не може запропонувати глобальне рішення. А Cursor все це може. Це може бути корисно, коли в команду приходить нова людина і знайомиться з проєктом. Cursor може швидко проіндексувати кодову базу і відповісти на питання. Загалом цей інструмент чудово справляється з типовими задачами — щось швидко наверстати, прикрутити якусь логіку тощо. Але з вузькими нетиповими завданнями можуть виникати труднощі. Також далеко не всі його пропозиції є релевантними — часто після них у коді щось ламається. Тому важливо все уважно перевіряти, але це правило актуальне при роботі з будь-якими ШІ. Кейс: я вирішив спробувати зробити Chrome-екстеншн, який дозволяв скрапити дані з сайту за певними тегами. Раніше я такого не робив, тому цілком поклався на допомогу Cursor. В результаті за 4-5 годин базовий екстеншн був готовий. За весь час я нічого не гуглив і навіть не відкривав API документацію, а також майже не писав сам код, керуючи ним виключно через чат. У Твітері діляться, що тепер можна за 30 хвилин, поки їдеш в Uber, з допомогою чату створити MVP якогось продукту, — і в цьому справді щось є. Сам VS Code мені ніколи не подобався, тому я повернувся до комбінації WebStorm + Copilot. Водночас, якби мені потрібно було швидко створити якийсь простий застосунок, я б спробував реалізувати його через Cursor AI — це потенційно могло б зекономити час на розробку. Порада: Cursor може працювати просто з коробки, але раджу не нехтувати заповненням конфігураційного файлу .cursorrules. Це дає налаштовувати поведінку ШІ-асистента, визначає правила, за якими він аналізує кодову базу, відповідає на запити та пропонує зміни. З ним результат буде значно кращим. На GitHub є репозиторій з безліччю прикладів таких файлів — можна знайти подібний проєкт і скопіювати. Зазвичай я працюю з продуктами JetBrains. Але порівняно з ними у Cursor значно краща інтеграція з контекстом проєкту. Інші AI-асистенти, в тому числі Copilot, не так глибоко аналізують локальні файли проєкту. Вони не завжди правильно розуміють зв’язки між компонентами та логіку самого проєкту. Cursor же виконує більш детальний аналіз, працює з типами даних та загальною архітектурою. Ще одна крута фіча — він не просто аналізує файли, а й може одразу створювати нові. Наприклад, якщо попросити написати тест, він не тільки згенерує код, а й автоматично створить новий файл. Ба більше, він покаже зміни у вигляді умовного пул-реквеста, де можна переглянути результат і вирішити, чи приймати його. Загалом Cursor допомагає із рутинною роботою та дослідженнями. Типова задача для нього — генерація структур даних. Це корисно, коли потрібно швидко створити структури для Go. Наприклад, якщо в документації є опис формату даних, його можна скопіювати та попросити Cursor згенерувати відповідні структури. Це особливо зручно, коли структура містить сотні полів, які вручну копіювати — справжній біль. Ще одне завдання — підготовка інфраструктури для тестів. Можна сказати: «Я планую писати юніт-тести для таких-то компонентів, підготуй мені оточення», і Cursor згенерує все необхідне — конфігураційні файли, тестове середовище, початкові тести. Потім можна або вручну доопрацьовувати, або дати ще один запит на написання тестів для конкретної функції. Якщо після рефакторингу або змін у функціоналі потрібно оновити тести, можна просто сказати: «Ось оновлений файл, адаптуй тести під нього», і Cursor запропонує зміни. Це значно економить час, особливо при роботі з великою кодовою базою. Також Cursor може допомогти з рефакторингом: перевіряє код, вказує на проблемні місця і навіть пропонує альтернативні варіанти. Якщо додати конкретний контекст, його аналіз стає набагато точнішим. Наприклад, якщо працюєш над високонавантаженим парсером, можна написати: «Ось функція, яка обробляє великі масиви даних. Як її оптимізувати для хайлода?» Тоді Cursor змінює підхід і пропонує конкретні поради, наприклад, зменшити алокацію пам’яті, оптимізувати роботу з потоками, уникати зайвих копіювань даних. Кейс: колега працював у Cursor над задачею створення вебзастосунку для виведення інформації на телевізори. Він просто зайшов у Cursor і написав промпт: «Згенеруй два проєкти: перший — фронтенд на React, який виводить такі-то дані», і Cursor одразу створив проєкт, який запустився і працював. Потім він продовжив: «Напиши бекенд для цього фронтенду, який бере дані з таких-то джерел і віддає їх у потрібному форматі», і Cursor створив бекенд, який колега задеплоїв без особливих змін. Це підтверджує, що Cursor можна використовувати для швидкої генерації простих вебзастосунків, як фронтенду, так і бекенду. Порада: важливо не зловживати автоматичною генерацією коду, оскільки він може містити помилки або неточності. Варто тестувати такі рішення на реальних даних і перевіряти їхню відповідність до вимог. Якщо додати більше контексту про структуру даних, він може дати ще кращий результат.
- Вертикальний серіал за мотивами книжки української авторки бʼє рекорди в США та Європі
Вертикальний серіал «Молода еліта», знятий за мотивами книги Стефанії Лін, у січні став найпопулярнішим проєктом на стримінговій платформі My Drama від української медіакомпанії HOLYWATER . Усі фільмування проходили в Україні, а головні ролі виконали Марина Бойко та Богдан Рубан. Серіал переглянули вже понад 10 млн разів. У серпні 2024 року HOLYWATER спільно з видавництвом Vivat запустила проєкт «ПИШИ» , спрямований на популяризацію творів українських romance-авторів на міжнародній арені. З 444 отриманих, історія Стефанії Лін стала основою для нового вертикального серіалу. Сюжет розповідає про дівчину-сироту, яка вступає до Академії молодої еліти. Її історія — це боротьба за гідність, самореалізацію та любов у світі привілейованих. «Співпраця з HOLYWATER — справжня магія втілення історії на екрані. Я створила книгу, вклавши в героїв душу, а HOLYWATER вдихнули в неї нове, ще цікавіше життя. Це дещо більше, ніж просто екранізація, адже це перший український вертикальний серіал. Я щаслива бачити, як історія оживає та резонує з глядачами у США та Європі. Їхні враження — найбільша винагорода для мене та тих, хто працював над проєктом «Молода еліта» в Україні і вклав у кожну мить частинку прекрасного», — говорить Стефанія Лін, переможниця проєкту «ПИШИ» та авторка книги «Молода еліта». Вертикальні серіали — формат контенту, адаптований для смартфонів, що відповідає темпу життя й звичкам сучасної аудиторії. Кожна серія триває до двох хвилин, з динамічним сюжетом, насиченими емоціями та клиффхенгерами. Ринок вертикальних серіалів швидко зростає. У 2023 році його обсяг у Китаї сягнув $5,3 млрд, а до 2026 року прогнозується зростання до $14 млрд. HOLYWATER адаптує тренд для західного ринку, створюючи контент і нові формати для взаємодії з американською та європейською аудиторіями. «У 2020 році я створив HOLYWATER з місією розкривати потенціал людей. Я хочу допомогти українським креаторам реалізувати себе через наші платформи. Використовуючи наші технології, ми переклали книжку англійською, протестували її серед аудиторії та перетворили на сценарій. Згодом цей сценарій став серіалом, який увійшов до числа наших найпопулярніших проєктів», — Богдан Несвіт, CEO & співзасновник у HOLYWATER. HOLYWATER випускає «Молоду еліту» та My Drama на український ринок вже 18 лютого. Цей та багато інших серіалів на платформі отримають українську озвучку, а для всіх українців, що перебувають на території України, доступ буде безплатним протягом місяця. Компанія прагне познайомити українців із форматом відеостримінгу, що бʼє рекорди у всьому світі. Застосунок можна завантажити у App Store та Google Play , а стежити за оновленнями в Instagram @ holywater.tech .
- Що таке Web3 та чи є у нього шанси стати новим інтернетом
Коли ви вперше дізналися про біткойн? І що саме ви почули? Що це інноваційна технологія, яка змінить інтернет? Або ж це були чутки про перших криптомільйонерів, які раптово розбагатіли на віртуальних грошах. Все це — частина правди про криптовалюту, складника більшої концепції, Web3. Останнім часом про неї усе більше говорять у ЗМІ, а найбільші інвестиційні фонди світу роблять ставку на цю нішу. HBJ поговорив із General Partner фонду 3X Capital Дмитром Фоменним та розповідає про особливості суперечливої технології. Що таке Web3 Web3 — це загальна назва ініціатив, пов’язаних зі створенням наступного «покоління» інтернету, що базуватиметься на блокчейні. Технологія має змінити способи зберігання, обміну та володіння інформацією. Так, якщо сучасний інтернет (Web2) базується на централізованих платформах на кшталт Google, Facebook, Amazon, то ключова особливість Web3 — децентралізація. Це означає, що єдиного власника чи контролера даних і сервісів немає, а продукти працюють на основі блокчейну — розподіленої бази даних, яка зберігається в мережі комп'ютерів, а не на одному сервері. Основні поняття сфери Web3: Криптовалюти — цифрові активи, які використовуються для обміну та оплати в децентралізованих системах. Вони стали першою всесвітньо популярною реалізацією блокчейн-технологій. NFT (Non-Fungible Token) — особливий тип криптовалюти, який є невзаємозамінним. Кожен NFT може представляти унікальний цифровий елемент — картини, відео, музику, ігрові предмети — та підтверджує право власності на цифрові об’єкти. DAO (Decentralized Autonomous Organizations) — це спільнота людей, які управляють цифровим проєктом без керівників. Замість директора чи правління рішення ухвалюють учасники голосуванням, а всі правила закладені в смартконтракти — програми на основі блокчейну, які автоматично виконують умови, якщо учасники їх дотримуються. DeFi (Decentralized Finance) — альтернативна фінансова система, яка дозволяє проводити фінансові операції (кредити, обмін, страхування) без банків або інших посередників. Усі процеси також виконуються через смартконтракти. Концепція блокчейну зародилася 1991 року, коли вчені Стюарт Хабер та В. Скотт Сторнетта започаткували перший блокчейн-проєкт. Їх розробкою стала система для маркування часу в цифрових документах, завдяки чому їх неможливо було змінити чи підробити. Утім, справжньої популярності ідея набула 2009 року, коли на тлі фінансової кризи з’явилася перша криптовалюта — біткойн. Стюарт Хабер та В. Скотт Сторнетта Його творець — це людина або група людей під псевдонімом Сатоші Накамото. Справжнього імені того або тих, хто розробив першу децентралізовану систему на основі блокчейну, досі не знають. У ній право власності на біткойни відстежувалося в загальнодоступному реєстрі. Щоб здійснити переказ, мережа перевіряла транзакцію, а майнери ( це люди, які «добувають» криптовалюту, розв’язуючи складні математичні задачі для підтвердження транзакцій у блокчейні — ред .)отримували складну математичну задачу — знайти спеціальний код (хеш) для нового блоку. Блок — це набір підтверджених транзакцій, які додаються до ланцюга блокчейну. Перший майнер, який знаходив правильний код, додавав блок у систему й отримував винагороду у вигляді нових біткоїнів. Чому ринок Web3 стає актуальнішим останнім часом Web3 — це циклічний ринок, і нині ми на початку нового зростання, вважає Дмитро Фоменний, General Partner в 3X Capital. «Але цього разу все відчувається інакше. Якщо раніше було багато галасу та незрілих технологій, то зараз Web3 справді працює. Layer 2 ( протокол, який розгортають над основним блокчейном. Його використовують для збільшення швидкості транзакцій і зменшення комісій, розвантажуючи основну мережу — ред. ) більше не просто ідея — тепер це технологія, яку масово використовують. Deutsche Bank, до прикладу, будує свій Layer 2. Користуватися нею стало набагато зручніше, і тепер людям не потрібно розбиратися в складних налаштуваннях чи зберігати мнемонічні фрази для доступу до своїх коштів», — говорить інвестор. Нещодавно президент США Дональд Трамп оголосив назви п'яти цифрових активів, які планують включити в новий стратегічний резерв криптовалют США. Йдеться про біткойн, Ethereum, XRP, Solana і Cardano. Через це ринкова вартість кожної з криптовалют різко зросла. Так, біткойн став коштувати на 11% більше — понад $94 000, а Ethereum подорожчала на % — її ціна становить близько $2500. Перші дзвіночки цієї тенденції відчувалися ще минулого року. На противагу своєму попереднику Джо Байдену, за каденції якого регуляторні органи прискіпливо контролювали галузь, нинішній президент США налаштований підтримувати її. Так, він організував круглий стіл з криптобізнесменами й навіть випустив власні коіни. Еволюція інтернету У нової концепції було двоє попередників: Web1 — інтернет, де можна лише читати. Перша версія мережі існувала з кінця 1990-х до початку 2000-х років. Тогочасні сайти здебільшого були односторінковими та статичними, а користувачі могли переглядати сторінки, але не залишати коментарі чи взаємодіяти з ними. Поява мови розмітки HTML та URL-адреси дали людям змогу переміщатися між статичними сторінками, однак революцію спричинили не вони. Web2 — епоха взаємодій та централізації. На початку 2000-х років інтернет почав змінюватися, стаючи дедалі інтерактивнішим. З’явилися перші соціальні мережі Facebook, Twitter і Tumblr, які дали людям змогу спілкуватися між собою. Водночас користувацький досвід змінювали YouTube, Вікіпедія та Google. Крім того, Web2 стала також епохою централізації. Творці BigTech-індустрії, якою ми її знаємо сьогодні, вчасно побачили перспективну нішу й пізніше змогли одержати величезні прибутки, збираючи дані користувачів і продаючи таргетовану рекламу. Завдяки цьому компанії пропонували свої послуги «безкоштовно», хоча користувачі не завжди усвідомлювали, до яких наслідків призводить подібна угода. Втім, вони також змогли заробляти — наприклад, як інфлюенсери. Web3 ж пропонує новий концепт — повну трансформацію цифрового середовища, де контроль над їхніми даними та онлайн-ідентичністю буде в руках самих користувачів. Так, учасники мережі одержать право голосу та зможуть брати участь в ухваленні рішень, що впливають на розвиток платформи. Web3 надає користувачам не просто можливість читати та писати, але й володіти часткою в мережі. Основні інструменти та платформи у Web3 Одним з фундаментальних елементів Web3 є Ethereum — криптовалюта і блокчейн-платформа одночасно. Запущена 2015 року, вона дає розробникам змогу створювати децентралізовані додатки (dApps) та смартконтракти. Саме на Ethereum будується безліч криптовалют та NFT, а ще — розквітає децентралізована фінансова сфера. Ethereum вже використовується для створення токенізованих фондів. Не лише BlackRock, але й багато інших фінансових інституцій впроваджують рішення на базі Ethereum. Список таких організацій постійно зростає, говорить Дмитро Фоменний. Для зберігання та обміну файлами в децентралізованому середовищі використовується IPFS (InterPlanetary File System) . Ця мережа дозволяє відмовитися від централізованих серверів, забезпечує більшу стійкість до цензури та підвищує безпеку даних. Щоби різні блокчейни могли ефективно взаємодіяти, існує протокол Polkadot . Він створює «мережу мереж», де блокчейни обмінюються даними та функціями, розв'язуючи проблему ізоляції. Фонд 3X Capital запускає «Let's Try ICP» Hackathon — перший онлайн хакатон для блокчейну ІСР. Більше деталей можна дізнатися за посиланням . Переваги Web3 Контроль над даними користувачів. У Web2 дані, створені користувачами, контролюються та використовуються технологічними гігантами. Web3, побудований на блокчейні, повертає контроль над даними користувачам. Вони зможуть вирішувати, якими даними ділитися з організаціями, та отримувати за це винагороду. Ба більше, децентралізовані застосунки (dApps) у Web3 не підлягають контролю чи обмеженням. Нові можливості для монетизації (NFT, DeFi). Web3 трансформує монетизацію, використовуючи технологію блокчейн, щоб уможливити пряму взаємодію між авторами та їхньою аудиторією. Цей децентралізований підхід ставить на перше місце право власності, дозволяючи авторам зберігати контроль над своєю роботою та досліджувати масштабовані моделі заробітку. «Найбільш успішні моделі монетизації Web3, як і Web2 — це двосторонні маркетплейси та комісії за транзакції. Великі гравці, такі як CEX, DEX, Uniswap і Coinbase, отримують стабільний дохід, стягуючи невеликий відсоток з кожної транзакції, за умови великого обсягу торгів. SaaS-модель не така популярна у Web3 через технічні складнощі та проблеми UX. Ще один цікавий підхід — будівництво екосистеми навколо інтелектуальної власності. Це те, що роблять Pudgy Penguins ( це NFT-проєкт, який поєднує колекціонування, супровідні товари та підприємництво — ред. ). Вони перейшли від простої NFT-колекції до бізнесу, схожого на Disney. Disney створює персонажів, а потім заробляє на ліцензуванні, мерчі, фільмах, субсеріалах. Pudgy роблять те саме: їхні іграшки продаються у Walmart у США, вони мають маркетплейс, де креатори можуть заробляти на створених ними пінгвінах, отримуючи роялті. Це вже не просто NFT. Вони створюють реальний ринок, який масштабуватиметься через фізичний та цифровий простір. І це дуже цікава бізнес-модель у Web3, бо люди починають просувати платформу, коли створили щось на базі неї й таким чином стають її амбасадорами», — розмірковує Дмитро Фоменний. Децентралізація як спосіб уникнення цензури. Завдяки децентралізації у Web3, інформація зберігається на численних комп'ютерах у мережі, а не на одному центральному сервері. Це робить практично неможливим видалення або зміну даних без згоди більшості учасників мережі. Наприклад, якщо уряд або компанія спробує заблокувати певний вебсайт або видалити публікацію, ця інформація залишиться доступною через інші вузли мережі. На базі децентралізації побудовані кілька проєктів. Наприклад, Radicle, децентралізована альтернатива GitHub , що дає зацікавленим сторонам змогу брати участь в управлінні своїм проєктом. Або Gitcoin — через цю платформу розробники можуть отримувати криптовалюту за роботу над Open Source -проєктами. Недоліки Web3 Технологія є непрактичною та дорогою. Чи справді блокчейн стане тією технологією, яка визначить майбутнє інтернету — поки що питання. Грейді Буч, головний науковий співробітник IBM Research з програмної інженерії, вважає криптовалюти «катастрофою програмної архітектури». Він пояснює: будь-яка технологія має свої компроміси, а децентралізована система може обробляти лише кілька транзакцій за хвилину — мізерно мало, якщо порівнювати з централізованим аналогом на кшталт Amazon Web Services. Через це децентралізація не спрощує технологію та не робить її доступнішою для пересічних користувачів — вона навпаки ускладнює її та робить менш доступною, вважає Буч. У цю нішу важко потрапити. Навіть інвесторам. «Web3 — має свої унікальні характеристики: іншу динаміку, принципи та швидкість розвитку. Якщо ви звикли до венчурного капіталу, Web3 може здатися хаосом. Тут відсутні стандартні фінансові звіти, на оцінку проєкту дуже впливає спільнота, а тренди змінюються за лічені місяці. Щоб уникнути ризику втрати грошей, потрібно постійно тримати руку на пульсі: стежити за стартапами, тестувати сервіси, розуміти екосистеми (Ethereum, Solana, ICP тощо). А найважливіше — ухвалювати швидкі рішення, адже тут немає часу для тривалих перевірок (due diligence) протягом місяців, як це може бути у традиційних інвестиційних фондах. Для розробників ситуація простіша. Якщо ви володієте мовами Solidity, Rust чи Move, то знайти роботу в Solana, Ethereum або Aptos не буде складно. Але є і блокчейни, як ICP, де треба кодити на Python, C++, JavaScript — що знижує поріг входу», — каже Дмитро Фоменний. У Web3 дуже погана репутація. Опоненти стверджують, що попри гучні заяви про демократизацію та розширення можливостей, Web3 — це насправді просто спекуляція, яка має на меті збагатити й так багатих людей. У них є привід так думати: перші 0,01% власників біткоїнів володіють 27% всього валютного фонду. Кількість скандалів та викриттів на цьому ринку важко порахувати. Чого тільки коштує справа FTX — найбільшої криптовалютної біржі у світі, чий крах призвів до втрати мільярдів доларів користувачів. Приклади стартапів, що вже використовують Web3 Основним інструментом, через який бренди експериментують з Web3, стали NFT. Про використання невзаємозамінних токенів заявляли як глобальні Microsoft, TikTok, Meta, Nike, Adidas, Gucci, Coca-Cola, так і українські «Планета Кіно» та HOLYWATER . Ось ще кілька прикладів , зазначених у звіті McKinsey Technology Trends Outlook. У 2022 році компанія Nike, яка придбала Web3-студію RTFKT у 2021 році, запустила власну платформу Web3 під назвою .Swoosh, яка пропонує клієнтам NFT на основі блокчейну. Платформа .Swoosh створена як центр для запуску нових продуктів і як простір, де користувачі можуть ділитися дизайнами віртуального одягу. У листопаді 2022 року JPMorgan Chase здійснив свою першу транскордонну блокчейн-транзакцію в рамках Project Guardian, партнерства з DBS Bank. Транзакція включала токенізовані депозити в сінгапурських доларах і японських єнах. Компанія Securitize, що спеціалізується на цифрових цінних паперах, разом із глобальною інвестиційною фірмою KKR запустила токенізований інвестиційний фонд на блокчейні Avalanche. Токенізація дозволяє залучати більше індивідуальних інвесторів до приватного капіталу, оцифровуючи операції та знижуючи мінімальний поріг інвестицій. Кіберспортивний і лайфстайл-бренд 100 Thieves запропонував фанатам NFT у вигляді діамантового намиста, якщо вони створять цифровий гаманець на платформі протягом 75 годин. Понад 300 000 осіб скористалися цією можливістю та отримали NFT. У портфелі 3X Capital також є кілька перспективних стартапів, розповідає Дмитро Фоменний. 1. Prediction Markets. «Це, по суті, покращена версія Polymarket, який вже має мільярдні обороти. Люди роблять прогнози на вибори, спортивні події, економічні тенденції. Але цей стартап має специфічний фокус щодо ігрової індустрії й технічні фічі, які дають йому конкурентну перевагу», — говорить інвестор. 2. Маркетплейс для MEV на Solana. «Зараз цей ринок монополізований — JITO обробляє 80% всіх транзакцій і торік заробив понад $1,5 млрд. Але стартап, у який ми інвестували, створює більш відкриту платформу, яка дозволить більшій кількості учасників заробляти на MEV». 3. Фізичні NFC-карти для Web3. «Альтернатива Ledger, яка робить підписання транзакцій простішим і безпечнішим. Це фізична картка, яку можна використовувати для підтвердження транзакцій у блокчейні». 4. Booking.com для цифрових номадів. «Платформа для подорожей, орієнтована на Web3-користувачів. Дозволяє бронювати житло, отримувати додаткові бонуси, збирати NFT за подорожі та інтегрується з криптогаманцями». 5. DeFi-інфраструктура для кращих умов кредитування. «Стартап пропонує технологічне рішення для оптимізації процесу кредитування та надання ліквідності у DeFi. Це дозволяє користувачам отримувати вигідніші умови, зменшуючи "спред" між відсотками за кредитом та відсотками за надання ліквідності, які зазвичай отримує платформа. Навіть незначна економія в 1-2% на цьому величезному ринку може призвести до значних прибутків для стартапу завдяки масштабуванню. «Web3 стає все більш практичним, і саме такі проєкти роблять його ближчим до масового використання», — додає Дмитро Фоменний. Перспективи розвитку Web3 Фахівці платформи незалежних досліджень 101Blockchains виділяють кілька основних трендів розвитку Web3: Масове впровадження децентралізованих додатків (dApps). Завдяки своїй здатності підвищувати прозорість і безпеку в різних сферах, таких як фінанси, ігри, ланцюги поставок і охорона здоров'я, децентралізовані додатки (dApps) ставатимуть все більш популярними. dApps будуть ще більш інтегровані в екосистему Web3 у майбутньому, завдяки зручним інтерфейсам, що полегшать перехід від Web2 до Web3. Штучний інтелект і Web3. Поєднання ШІ та Web3 відкриває нові можливості для створення інтелектуальних і ефективних децентралізованих систем. Це включає автоматизацію смартконтрактів, створення NFT за допомогою ШІ та покращення виявлення шахрайства в DeFi. Зміни в регулюванні. У 2025 році посилення регулювання цифрових активів і блокчейну стане важливою темою. Хоча більш суворі правила можуть спричинити певні труднощі, вони також сприятимуть розвитку Web3. DeFi 2.0: Розумніші й безпечніші фінанси. Завдяки вдосконаленим протоколам та покращеному управлінню ліквідністю, децентралізовані фінанси стануть більш безпечними та доступними. Ці вдосконалення сприятимуть інтеграції традиційних фінансових систем з децентралізованими. Соціальні мережі Web3. Децентралізовані соціальні мережі на кшталт BlueSky дозволять користувачам більше контролювати свої дані, відкриють нові можливості для монетизації та зменшать цензуру. Це має дати новий поштовх економіці творців, де токенізовані винагороди допомагають справедливіше розподіляти доходи. Однак є і протилежні думки. Web3 вважають закритим клубом, до якого складно доєднатися. Аби досягти успіху, Web3 має наслідувати приклад попередніх технологічних зрушень і бути простим у використанні. Саме таким було покоління Web2. Успіх Web3 не має залежати від глибокого розуміння технології блокчейн, а користувацький досвід має бути інтуїтивним. Інакше кажучи, нове покоління інтернету не просто створювати можливості для володіння унікальними об’єктами мистецтва, а вирішувати проблеми. З цим поки що можуть впоратися хіба що криптовалюти.
- Vim — кіберпанковий редактор чи альтернатива сучасній IDE
«Коли вперше відкриваєш Neovim — ніби сідаєш в болід F1. З одного боку, це швидкий, потужний автомобіль, а з іншого — а де тут кнопка cтарт?» — говорить Іван Кучер, Back-End Developer в Universe Group . Декілька років тому він спробував популярний форк Vim і залишився. На його думку, попри перші складнощі та довге звикання, це найшвидший редактор коду, і його можна кастомізувати під себе. У цьому матеріалі розбираємося, як зʼявився Vim, а також розповідаємо про його попередника та сучасний форк Neovim. Зʼясовуємо, чому методи редагування 1970-х років досі залишаються популярними, та що змушує розробників витрачати тижні на опанування цього інструменту. Пояснюємо, як влаштовані команди, що робить його справді швидким та ділимося корисними ресурсами для вивчення. Розробники з бізнесів екосистеми Genesis пояснили, в чому полягає філософія Vim, поділилися улюбленими фічами та порадами, з чого почати вивчення. Модальне редагування Що може бути складного в редагуванні файлів? Механіка проста: перемістити курсор у потрібне місце та набрати текст. Для навігації використовуємо скрол миші, тачпод, стрілки. Для справжніх «ніндзя» є гарячі клавіші, щоби перестрибувати рядками чи абзацами. Проте у 1970-х роках клавіатури виглядали зовсім по-іншому — на них не було стрілок. Миші були щойно запатентованим експериментальним девайсом, який стане популярним лише у наступному десятилітті. Побачити повний текст на моніторі було неможливо через обмежені ресурси компʼютерів. Їхня оперативна памʼять вираховувалася у кілобайтах, тому робота у графічних інтерфейсах була дуже ресурсозатратною, і доводилося працювати лише з окремими рядками. І найстрашніше — Ctrl+C / Ctrl+V на той час ще не вигадали. Тоді для редагування тексту використовували спеціальні команди — сьогодні вони виглядають дивно, проте досі широко вживаються. Чому ж 2025 року, коли створені найзручніші миші, тачпади та способи навігації текстом, розробники досі використовують методи 70-х років? Все просто — тоді вигадали найшвидший спосіб навігації у тексті — модальне редагування. В чому полягає його суть: За замовчанням, натискання клавіш передбачає не введення тексту, а виконання команд, якими можна рухатись по коду та змінювати його (видаляти, копіювати, вставляти тощо). Для набору тексту потрібно перейти у спеціальний режим. «Більша частина роботи з кодом — це внесення змін, а не написання нового коду. Розробники мусять переходити з файлу у файл, знаходити потрібні рядки, редагувати. В той час як звичайне редагування оптимізоване для набирання нового коду, модальне — для внесення змін», — пояснює Марк Мотлюк, Software Engineer в Genesis . Все почалося з Vi Датою народження редактору Vim вважається 1991 рік, проте ця історія бере початок 1976 року. Цього року Білл Джой, легендарний інженер та співзасновник Sun Microsystems, створив текстовий редактор Vi для операційної системи Unix. За легендою, Джой створив його всього за один вікенд, проте Vi був справжнім проривом. Клавіатура, на якій Білл Джой написав Vi. Джерело: спільнота Vim на Reddit Він пропонував переключатися між командним і режимом вставки з допомогою клавіатури. Це дозволяло виконувати операції редагування набагато швидше, ніж у багатьох інших текстових редакторах того часу, де кожна операція потребувала кількох кроків. Завдяки своїй ефективності, Vi швидко став стандартним редактором у багатьох Unix-системах. Далі редактор продовжував розвиватися через появу різних клонів та покращених версій. Одним із перших був Stevie (ST Editor for VI Enthusiasts), створений Тімом Томпсоном у для комп'ютера Atari ST. Еволюція модальних редакторів коду 1988 року нідерландський програміст Брам Муленар придбав комп'ютер Amiga та шукав версію редактора Vi для цієї платформи. Так і не знайшовши, він звернув увагу на Stevie та на його основі розпочав розробку власної версії. В процесі він покращив продуктивність та додав нові функції, такі як багаторівневе скасування дій. Перший публічний реліз «Vi IMitation» відбувся 1991 року, а згодом редактор був перейменований на «Vi IMproved» (Vim) та підтримував роботу на різних платформах, включаючи MS-DOS та Unix. Наступні 30 років Муленар присвятив розвитку та вдосконаленню Vim, сформувавши навколо нього велике комʼюніті. В репозиторії на GitHub, який зʼявився 2015 року, Муленар особисто вніс переважну кількість змін — понад 16 тисяч комітів. Він працював над Vim майже щодня. Наприклад, так виглядав 2020 рік Брама — жодного дня без комітів. Активність Брама Муленара в репозиторії Vim Після його смерті 2023 року комʼюніті продовжило роботу над редактором. Розробку очолив Крістіан Брабандт , Версія 9.1.658, випущена 2024 року, була присвячена памʼяті Брама Муленара. Сьогодні Vim має вбудовану підтримку для понад 200 мов програмування та форматів файлів, а також підтримує чимало плагінів, які легко встановлюються та дозволяють керувати додатковими модулями, адаптуючи редактор під потреби користувача. «Я довго користувався Linux, і мені подобалася ідея максимального налаштування системи. Так я відкрив для себе Tiling Window Managers — мінімалістичне середовище, яке автоматично керує вікнами без зайвих елементів UI. Vim мене зачепив саме цим підходом: мінімалізм, жодного зайвого — тільки код на весь екран», — ділиться Марк Мотлюк. Neovim Спільнота Vim активно розвивалася, створюючи безліч плагінів, документації та освітніх матеріалів, які допомагають новачкам освоїти редактор та розкрити його потенціал. Водночас останнє слово завжди залишалося за Брамом Муленаром, який особисто приймав рішення щодо нових функцій та змін. Часом це обмежувало інших контриб'юторів, і вони створювали форки. Так, 2014 року бразильський програміст Тіаго де Арруда запропонував патч для підтримки багатопоточності Vim, проте його відхилили. Тоді він створив нову версію редактора з покращеними можливостями — Neovim . Основні його покращення включали вбудовану підтримку Language Server Protocol (LSP), асинхронного введення/виведення та можливість використання скриптів на мові Lua через інтерпретатор LuaJIT. «Завдяки вбудованій підтримці LSP, Neovim легко налаштувати під різні мови програмування. Це значно спрощує процес порівняно з Vim, де це потрібно було конфігурувати вручну. Крім того, вони пришвидшили редактор, додавши асинхронні операції та підтримку для плагінів, які тепер працюють паралельно і не конфліктують один з одним» — каже Іван Кучер. «Одним з недоліків Vim, на мою думку, був скриптинг. Vimscript виглядав дуже дивно, це незручна й незрозуміла мова. В Neovim для написання скриптів замість нього використовується Lua, — з нею значно приємніше працювати та кастомізувати редактор під себе», — розповідає Антон Уваренко, Golang Developer в Promova . З моменту свого створення Neovim продовжує активно розвиватися, залучаючи спільноту розробників для впровадження нових функцій та покращень. Спільнота r/neovim на Reddit налічує понад 119 000 учасників, а репозиторій Neovim на GitHub має понад 86 000 зірок (Vim має 37 000). У результатах опитування Stack Overflow популярність Neovim щороку зростає. У звіті 2024 року Neovim викликає найбільше захоплення у розробників серед усіх редакторів — 83%. Як працює Neovim Магія швидкості роботи у Neovim полягає у таких факторах: Легковажність. Порівняно з VS Code, який працює на базі Electron, та продуктів JetBrains, які написані на Java та використовують JVM, Neovim займає мінімум пам'яті. Він не потребує потужних системних ресурсів комп'ютера та працює навіть у найпростіших терміналах та серверних середовищах. Модальність. У ньому є декілька режимів, які дозволяють виконувати будь-які операції без необхідності перемикатися між мишкою та клавіатурою. Режими: Normal mode – для навігації та редагування. Insert mode – дозволяє вводити текст, як у звичайному редакторі. Visual mode – дає змогу виділяти текст для подальшої обробки. Command-line mode – для виконання команд. Комбінації клавіш. Майже всі операції виконуються за допомогою комбінацій клавіш. Користувачі витрачають мінімум часу на пошук меню або інструментів. Навігація. Vim та його похідні мають потужні механізми пошуку і переміщення по тексту. За допомогою команд на кшталт / або ? можна швидко знайти текст, а комбінації клавіш, як f і t, дозволяють переміщатись до конкретних символів у рядку без зайвих рухів. Макроси. Якщо потрібно виконати повторювану задачу, можна записати макрос, який виконується за одну команду. «Перша спроба працювати у Neovim викликала багато фрустрації: важко було виконати навіть базові операції. Але залишається відчуття, що можна робити все набагато швидше, тому пробуєш знову і знову. І коли звикаєш, починаєш розганятися — і все стає набагато простішим, — згадує Антон Уваренко. — Серед найбільш корисних функцій: макроси, які дуже допомагають автоматизувати монотонні завдання (наприклад, прописувати повторювані теги чи виконувати певні дії на конкретних рядках коду) та пайпінг (дозволяє передавати дані з термінальних команд в редактор Vim та застосовувати їх до буфера). Це корисно, наприклад, для роботи з JSON файлами, коли потрібно обробити їх і привести до більш зручного вигляду». Як влаштовані команди Переміщення курсора відбувається за допомогою клавіш h, j, k та l (цей підхід зберігся з 1970-х). Спершу здається, що команди визначаються рандомним способом, але насправді це досить зрозуміло. Vim працює за логікою природної мови: дієслово (verb) + уточнення (modifier) + іменник (noun). Це базова модель, яка забезпечує фундаментальну логіку роботи у Vim, але на більш складному рівні додаються регістри, макроси, розширені модифікатори та мапінги, що значно збільшує можливості Vim. Брам Муленар на лекції з ефективного редагування текстів пояснював : «Уявіть, що ви написали код, і вас попросили змінити назву функції. Ви перевіряєте весь файл та виправляєте — це нудно, довго і створює ризик помилок. А тепер уявіть, що таких назв — десять. Або сто. Що, якби ви могли зробити це натисканням кількох клавіш? У цьому і полягає філософія Vim — знайдіть операцію, яку часто повторюєте, налаштуйте її так, щоб вона виконувалася за пару натискань, — і ви миттєво станете швидшими». Спільнота Neovim створила плагіни для автоматизації будь-якої рутини, розповідає Дай Зионг Ле, Head of Engineering у HOLYWATER . «Питання, що можна оптимізувати у своїй роботі в Neovim привело мене до зручного плагіну. Якщо ти постійно працюєш з певними файлами, можна забіндити кожен з них на окрему кнопку, та швидко перемикатися. Це зручніше, ніж постійно шукати ці файли через пошук чи переходити між вкладками. Крім того, при переході ти знаходишся в тому самому місці, де зупинився — наприклад, в одному файлі на початку, а в іншому в кінці», — каже Зионг. Налаштування та дистрибутиви Використовувати Vim/Neovim у його базовому сирому вигляді — це досить погана ідея, вважає Марк Мотлюк. «Щоби зробити його зручним середовищем для роботи, потрібно чимало фічей докрутити власноруч, написавши величезні конфіги. Вони можуть ламатися через оновлення чи несумісність плагінів. Менеджерити ці речі власноруч — досить складна задача», — пояснює він. Дистрибутив — це конфігурація, створена іншим розробником. Фактично це набір комбінацій клавіш, плагінів та інших налаштувань. NvChad — один з найпопулярніших дистрибутивів Neovim. Крім нього є LazyVim, LunarVim, AstroNvim. «Я спробував кілька з них і вибрав AstroVim через його зручні дефолтні налаштування й AstroNvim Community Repository — збірки плагінів для різних цілей. Зараз я використовую його для всього», — каже Марк. «Я натрапив на YouTube на відео, де один хлопець показував, як налаштував NeoVim під веброзробку, зокрема для TypeScript, Node і так далі. Він створив крутий репозиторій, де зібрав усі ці конфігурації з плагінами, і навіть надав PDF із хоткеями, як це працює і як налаштовується. Це був ідеальний старт для мене, — згадує Іван Кучер. Водночас, на його думку, використання чужих конфігурацій не допоможе, якщо ви не вивчили базовий функціонал і як ним користуватись. Дай Зионг Ле вперше дізнався про Neovim в лайф-кодингах технічних блогерів: «Мене вразило, як швидко вони пишуть код та орієнтуються в терміналі. Тоді я почав досліджувати цей інструмент і заглиблюватися в нього». На його думку, швидкість не з'явиться, поки не налаштуєш цей редактор під себе. «Під кастомізацією я маю на увазі розуміння свого робочого процесу, як ти запускаєш сервер, налаштовуєш середовище, працюєш із вікнами та іншими інструментами, та автоматизацію цих етапів», — вважає Зионг. Ще одна суперсила Neovim — робота в терміналі та підтримка мультиплексії (можливість відкривати декілька термінальних вікон одночасно). Завдяки цьому можна працювати з кількома проєктами в одному терміналі, зберігаючи при цьому фокус. «Таке поєднання всіх цих інструментів створює потужну екосистему, де можна використовувати різні командні інструменти одночасно, як-от термінальний мультиплексор, команди Linux для підрахунку рядків, пошуку і так далі. Якщо вивчити цю систему, вона значно спрощує роботу і навіть прискорює її», — пояснює Зионг. За його словами, у всіх редакторах є підказки для коду, можливість переходити між методами чи переглядати сигнатури функцій, але не всі розуміють, як це працює. «Коли ти налаштовуєш Neovim, ти так чи інакше зіштовхуєшся з цими механізмами та більше дізнаєшся про те, як це працює на глибшому рівні, як взаємодіють внутрішні механізми, і це дійсно цікаво». Як вивчити Neovim Перший крок в опануванні модального редагування — навчитися друку десятьма пальцями. Наприклад, з допомогою ресурсу Keybr . Навчання базовим командам для переміщення по тексту, видалення, копіювання та вставки. Для цього є декілька корисних ресурсів, які навчають у форматі гри. Наприклад, Vimified та Vim Adventures . Встановлення Vim-плагіну у знайоме середовище. «Відразу почати працювати у Vim складно, бо продуктивність падає до нуля. Але якщо просто використовувати Vim-режим для редагування в інших середовищах — це досить зручно», — пояснює Марк. У цьому режимі варто відпрацювати основні команди навігації. Vim працює в терміналі, тому важливо опанувати основи роботи з командним рядком, щоб ефективно використовувати всі можливості редактора. Встановіть плагіни, які допоможуть вам покращити роботу з Vim — автодоповнення, підсвітки синтаксису та лінтингу. Використовуйте готові дистрибутиви. Практикуйтеся на реальних проєктах чи вивчайте додаткові матеріали — статті, відео. Вивчайте розширені можливості Vim та кастомізуйте редактор під себе, щоби створити оптимальне середовище. Корисні ресурси: https://keybr.com/ https://www.vimified.com/ https://vim-adventures.com/ https://danielmiessler.com/blog/vim https://vimforreactdevs.com/ https://github.com/leerob/vim-for-react-devs Водночас варто прагматично ставитися до цього інструменту. «NeoVim чи Vim — це не золотий грааль, який вирішить всі проблеми. Якщо ви працюєте у VSCode або WebStorm, у вас все оптимізовано і налаштовано, нічого не заважає, і ви задоволені перфомансом, то немає сенсу переходити на інший редактор», — вважає Іван Кучер. Що далі Хоча комʼюніті Vim/Neovim постійно додає плагіни та фічі з використанням ШІ (автокомпліт, копайлот, чат з ШІ тощо), навряд ці продукти висунуть нові ідеї застосування ШІ. «Avante — плагін, який приносить ідеї Cursor у Neovim. Він дозволяє виділяти код, запитувати ШІ про нього або просити внести зміни. Хоча ШІ-функції у Vim точно будуть розвиватися, глобально він залишається нішевим. Його розвиток не буде таким стрімким, як, наприклад, у Zed, у якому нещодавно додано модель, яка передбачує наступний крок розробника — ділиться Марк. — Проте я не думаю, що Vim зникне. Він стабільний, у нього є велика база користувачів, і це те, що буде популярним ще довго». Neovim схожий на нескінченну конструкцію Lego, яку ви можете формувати та налаштовувати на свій розсуд, і саме тому люди повертаються до цієї концепції сьогодні.
- High Bar for Talent: дайджест технічних вакансій
У новій підбірці вакансій ми зібрали пропозиції для технічних спеціалістів: Front-end та Back-end, Android та iOS, Flutter та Node.js девелоперів різних ґрейдів. Від команди, яка створює інструменти для контент-креаторів, до компаній, що працюють у сфері AI та ML розробки, Lifestyle та Social Discovery — кожна з позицій має свої унікальні завдання та можливості для розвитку. Гортайте вакансії, щоби знайти ту, що відповідає вашому досвіду та амбіціям. Flutter Developer (Suitsme) — вакансія закрита SUITSME — FemTech компанія, що створює цифрові продукти, які допомагають жінкам пізнавати та проявляти себе. Команда, яка розвиває продукт FABU, шукає Flutter Developer з досвідом створення та розгортання Flutter-додатків для iOS та Android. Кандидат має знати принципи ООП, UI/UX дизайн, інтеграцію API та бібліотек, а також володіти усною та письмовою англійською. Основні задачі включають розробку мобільного застосунку, інтеграцію з SDK та оптимізацію продуктивності. Android Developer (PlantIn) — вакансія закрита PlantIn — це українська продуктова IT-компанія з екосистеми Genesis, яка будує продукти на основі власних ML-технологій. Її застосунки об’єднують понад 35 мільйонів користувачів, серед яких PlantIn для догляду за рослинами та CoinIn для ідентифікації монет. Компанія шукає Android Developer для розвитку функціоналу PlantIn та запуску нового Android-застосунку CoinIn. Основні задачі: створення та підтримка мобільних продуктів на Kotlin, інтеграція Jetpack Compose, робота з API та SDK, оптимізація архітектури, а також співпраця з командами бекенду, дизайну та QA. Вимоги: 3+ роки досвіду, знання Android SDK, Jetpack Compose, Gradle та практичний досвід публікації застосунків у Google Play. Golang Developer (JustDone) — вакансія закрита Boosters — це українська продуктова компанія, яка створює EdTech та life-improvement продукти для мільйонів користувачів у всьому світі. Компанія шукає Golang Developer для роботи над JustDone — платформи для створення контенту завдяки генеративному ШІ. Основні задачі включають реалізацію backend-рішень на Go, участь у проєктуванні функціоналу, впровадження нових технологій та пошук оптимальних технічних рішень. Вимоги: щонайменше 1 рік досвіду з Golang, знання реляційних баз даних, розуміння асинхронного програмування та клієнт-серверної архітектури. Досвід роботи з платіжними системами буде перевагою. Node.js Back-end Developer (HOLYWATER) HOLYWATER — це українська технологічна компанія в екосистемі Genesis, що створює персоналізовані світи для понад 20 мільйонів користувачів. Її продукти, як-от My Drama, My Passion та AI Companion, є лідерами у своїх нішах у США та Європі, поєднуючи інновації AI із креативністю авторів. Компанія шукає Middle Node.js Backend Developer для масштабування застосунків і розробки нового функціоналу. Основні задачі: реалізація нового функціоналу, рефакторинг коду, створення автоматизованих тестів, інтеграція з реляційними та нереляційними БД (Postgres, DynamoDB), а також робота з GraphQL, NestJS, Docker і AWS. Вимоги: від 3 років досвіду у бекенд-розробці, знання TypeScript, контейнеризації та CI/CD. Front-end Developer (OBRIO) OBRIO шукає талановитого Front-End Developer для команди Growth, який допоможе оптимізувати та покращувати продукти, забезпечуючи найкращий користувацький досвід. Основними завданнями будуть створення нового функціоналу, удосконалення існуючого вебзастосунку, розробка рішень для підвищення конверсії, а також участь в обговореннях нових технологій. Вимоги : досвід роботи з React.js, Next.js і Redux, знання TypeScript, HTML, CSS, робота з Figma та Zeplin, досвід роботи з API та Git. Node.js Developer (OBRIO) Команда OBRIO шукає Back-end Developer, який допоможе втілювати новий функціонал для підвищення активності користувачів платформи Nebula. У цій ролі ви будете співпрацювати з кросфункціональною командою, пропонувати технічні рішення для покращення процесів, розробляти нові функції, вдосконалювати архітектуру проєкту, покращувати системи аналітики та стабільності продукту. Вимоги: від 1 року досвіду, навички управління базами даних та системами обміну повідомленнями, знання PostgreSQL/MySQL, Redis, RabbitMQ. Mobile QA Engineer (Universe Group) — вакансія закрита Universe Group — це продуктова IT компанія, що створює мобільні додатки та вебплатформи для покращення якості життя людей. Компанія розвинула три успішні бізнеси (Guru Apps, Forma, Wisey) і має власний R&D-центр з аудиторією у 83,5 млн користувачів зі 180 країн. Команда GuruApps шукає Mobile Manual QA Engineer для тестування та підвищення якості iOS-додатків. Серед завдань — тестування нових і існуючих функцій мобільних застосунків, створення та оновлення тестової документації, тестування backend (REST API), участь у релізах, плануванні продукту та спілкуванні з продуктовою командою. Вимоги: від 1 року досвіду в тестуванні, знання API, досвід роботи з iOS пристроями, навички роботи з Postman, Jira, Confluence, знання SDLC, розуміння клієнт-серверної архітектури та REST API. Senior iOS Developer (Lift) — вакансія закрита Команда Lift шукає Senior iOS Developer для роботи з обробкою відео (від найнижчого до верхнього рівня), розробки нового функціоналу та інтеграції up-to-date технологій. Від кандидата очікують знання Swift, досвід роботи з багатопоточністю, тестами, а також розуміння алгоритмів і структур даних. Бонусом буде знання SwiftUI, UDF архітектури, Metal/OpenGL та досвід створення кастомних UI. Партнерські компанії DevOps Engineer (Quarks) — вакансія закрита Quarks — українська компанія, що створює продукти в галузі Social Discovery та онлайн-знайомств, зокрема міжнародну платформу Kismia. Команда шукає досвідченого DevOps Engineer автоматизації та покращення процесів розробки та релізів, забезпечення безпеки та захисту інфраструктури. Основні завдання включають розробку та підтримку багатопроєктного середовища, створення CI/CD конвеєрів, автоматизацію процесів, забезпечення безпеки та усунення несправностей. Необхідний досвід: понад чотири роки на аналогічній посаді, знання Linux, CLI, сценаріїв Bash/Python, систем логування та моніторингу. Стек технологій: Kubernetes, Terraform, Ansible, Jenkins, MySQL, PostgreSQL, ELK, Grafana, Prometheus, Kafka. Що почитати за темою: 180+ питань на співбесіду Golang для Junior, Middle та Senior Великий перелік поширених питань з теорії та практики для спеціалістів різних ґрейдів — Junior, Middle, Senior. Він буде корисним для підготовки до технічного інтервʼю та допоможе виявити прогалини в знаннях. 180+ питань на співбесіду DevOps для Junior, Middle, Senior Що питають на співбесіді у DevOps інженерів? Залежно від специфіки роботи компанії, питання різняться, проте є спільні теми. Ми зібрали великий перелік поширених питань для спеціалістів різних ґрейдів — Junior, Middle, Senior. Він буде корисним для підготовки до співбесіди, щоби виявити прогалини у знаннях. 70+ питань та кейсів для iOS Developer від Team Lead в Universe Розповідаємо, які питання ставлять iOS-розробникам різних ґрейдів. iOS Team Lead компанії з екосистеми Genesis поділився своїм підходом до проведення інтервʼю, пояснив, чому не питає у кандидатів про ООП та іншу фундаментальну теорію, як формуються вимоги до вакансії, та чому найефективніше будувати розмову навколо технічних інтересів. 6 міфів про Machine Learning. Спростовує ML Engineer в PlantIn Машинне навчання (Machine Learning) традиційно сприймають, як надскладну технологію, доступну лише технічним гігантам рівня Facebook та Google. Насправді сьогодні можливостями машинного навчання можуть користуватися навіть маленькі компанії без окремих датасайнс-команд. Тимур Болотюх, Machine Learning Engineer компанії PlantIn розповів про найпоширеніші міфи, які існують серед спеціалістів цієї сфери.
- High Bar for Talent: дайджест вакансій для маркетологів
Шукаєте нові можливості? В маркетингові команди українських ІТ-компаній, продуктами яких щодня користуються мільйони людей у всьому світі, шукають User Acquisition Manager різних грейдів, PPC, Creative Marketing та інших спеціалістів. Від масштабування рекламних кампаній та управління мільйонними бюджетами до розробки креативних концепцій та SEO-стратегій — кожна позиція дає можливість розвиватися разом з амбітними проєктами та впливати на їхнє зростання на глобальних ринках. User Acquisition Manager (Keiki) — вакансія закрита Keiki — українська продуктова компанія, що створює інтерактивні освітні застосунки для дітей 2-8 років. Команда шукає User Acquisition Manager для оптимізації рекламних кампаній на вебворонках. Основні завдання: масштабування реклами в META, аналіз результатів і конкурентів, управління бюджетами, співпраця з дизайнерами, продуктовою та аналітичною командами. Вимоги: 1+ рік у performance-маркетингу, досвід роботи з META, англійська Upper-Intermediate. Плюсом буде досвід із TikTok та вебпродуктами. User Acquisition Manager (SUITSME) SUITSME — це фешн-гра, розроблена під егідою Genesis. Команда шукає User Acquisition Manager для створення та оптимізації кампаній на Facebook, Pinterest, TikTok і рекламних мережах (Applovin, Ironsource тощо). Основні завдання: аналіз результатів, управління бюджетами, тестування гіпотез, взаємодія з клієнтськими менеджерами платформ. Вимоги: 1+ рік у User Acquisition, досвід з Facebook і Google Ads, знання рекламних мереж, аналітичні навички, рівень англійської — Intermediate+. Перевагою буде досвід роботи з TikTok і Pinterest. User Acquisition Manager (OBRIO) — вакансія закрита Команда OBRIO шукає User Acquisition Manager для масштабування рекламних кампаній для продукту Nebula, який має понад 60 мільйонів користувачів у 50+ країнах. Завдання: управління багатомільйонними бюджетами в Meta Ads, A/B тестування, робота з аналітичними інструментами (Tableau, Amplitude), співпраця з креативною командою. Вимоги: 2+ роки досвіду на схожій посаді, аналітичний підхід, рівень англійської Upper-Intermediate+. Плюсом буде досвід із Google, TikTok та копірайтингом. PPC Specialist / Google Ads First (FORMA) — вакансія закрита FORMA — бізнес у складі Universe Group , який створює SaaS-продукти для роботи з документами. Компанія шукає User Acquisition Manager для створення та масштабування маркетинг-стратегії нового продукту з бюджетами до $1 млн/місяць. Основні завдання: запуск рекламних кампаній у Google Ads з нуля, аналітика та оптимізація метрик (CPA, ROMI, LTV), A/B тестування, побудова стабільного маркетинг-юниту. Вимоги: 2+ роки досвіду з Google Ads, аналітичні навички, досвід роботи з бюджетами від $100 тис./місяць. Перевагою буде досвід роботи з AI та медійними кампаніями. SEO Specialist (Justdone) — вакансія закрита Boosters — українська продуктова компанія, яка створює EdTech і life-improvement продукти для 30 мільйонів користувачів у світі. Компанія шукає SEO Specialist для розвитку Justdone — AI Writing Assistant. Основні завдання: створення SEO стратегії для різних локалей, лінкбілдинг, оптимізація сторінок, технічні аудити, робота з органічним трафіком і конверсією. Вимоги: 4+ роки досвіду в SEO, зокрема 1,5 року з англомовними ринками, знання SEO-інструментів (Ahrefs, Semrush), Google Analytics і Search Console. Creative Marketing Specialist (HOLYWATER) — вакансія закрита HOLYWATER — технологічна компанія, що створює персоналізовані світи для 20+ мільйонів користувачів. Компанія шукає Middle Creative Marketing Specialist для пошуку точок росту продукту та генерації ідей для рекламних креативів. Основні завдання: аналіз ринку реклами та конкурентів, організація брейнштормів та тестування маркетингових гіпотез, генерація ідей для рекламних креативів, співпраця з контент-командою. Вимоги: 1+ рік досвіду на позиції Creative Marketing Specialist, вміння працювати в команді, орієнтація на результат, знання інструментів моніторингу ринку, англійська Upper Intermediate+. User Acquisition Manager (Promova) — вакансія закрита Компанія Boosters шукає User Acquisition Manager для залучення нових користувачів до платформи Promova. Основні завдання: управління рекламними кампаніями на платформах Facebook, TikTok, Snapchat, Pinterest та ін., аналіз і тестування нових креативів та налаштувань таргетингу, управління великим рекламним бюджетом, аналіз ринку і конкурентів, а також пошук можливостей для покращення unit economics. Вимоги: 1 рік досвіду в performance marketing, досвід роботи з рекламними платформами (Facebook Ads, TikTok Ads, Google Ads), сильні аналітичні навички, знання Google Sheets, Excel, англійська Upper Intermediate. Що почитати про роботу маркетлога Міфи про продакт-маркетинг. Спростовує Product Marketing Manager в Universe Group PMM — роль, яка викликає чимало непорозумінь. Хтось вважає, що це лише про маркетинг, інші впевнені, що PMM — це те саме, що Growth чи Product Manager. Дмитро Цапій, Product Marketing Manager в Universe Group, спростовує поширені міфи про цю роль, а також про трактування метрик, підходи до побудови воронок, продуктову аналітику та конверсії. 120 питань на співбесіду з маркетологом. Питання та поради від CMO Promova Як проходить співбесіда з маркетологами різних грейдів у продуктових ІТ-компаніях та які питання їм ставлять? Катерина Боровська, CMO Promova поділилася найголовнішими якостями, які шукають у кандидатах, чому інтервʼюер перевіряє вміння заперечувати менеджеру, яка одна з найголовніших вимог до сеньйора, а також чим відрізняються інтервʼю для різних напрямів маркетингової команди. Як оптимізувати конверсію на кожному етапі маркетинг-воронки Оптимізація конверсії — це комплексний процес з кількома складниками. Він передбачає і запуск нових воронок, і покращення сталої конверсії у покупку, і збільшення кроків, які ведуть до підвищення кількості користувачів та покупок на продукті. Тому процес роботи з нею потрібно розглядати на трьох різних етапах — відповідно до того, де знаходиться воронка. На кожному з них робота з конверсією буде відрізнятися, а команда матиме свої «болі». Про них у своїй колонці розповідає Єгор Воробйов, Product Marketing Lead у Promova (Boosters). Ґайд продуктовими метриками із CPO Lift Іллею Алістратенко Продуктові метрики — кількісні показники, що допомагають зрозуміти, як користувачі взаємодіють з продуктом, наскільки продукт затребуваний, а також оцінити поточний стан бізнесу. Скільки і які метрики потрібно відстежувати — залежить від розміру компанії, фази її розвитку та особливостей продукту. Як обрати метрики? Розповідає Ілля Алістратенко, CPO української компанії Lift з екосистеми Genesis, що розробляє застосунки для контент-креаторів.
- Новий офіс Genesis у Львові: фото з відкриття
В березні 2025 року Genesis відкрила офіс у Львові. Продукти, що розвиваються в екосистемі, зростають, тож команди планують активно наймати фахівців у Львові. У новому офісі працюватимуть близько 100 людей, згодом далі їхня кількість зростатиме. У ньому також буде лекторій, де проводитимуть освітні заходи від компанії. «Ми бачимо у Львові значний потенціал для розвитку продуктових команд, оскільки тут сформована сильна IT-спільнота та базуються потужні профільні університети. Відкриття офісу дозволить нам бути ближчими до місцевих фахівців та сприяти розвитку продуктового IT», — коментує Володимир Многолєтній, співзасновник та CEO Genesis. Нині в офісі вже працюють команди продуктів компаній OBRIO (Nebula ) , Promova , Boosters , HOLYWATER , EverHelp, Lift, VP 6037, talеntC та співробітники Genesis Head Office. Команди найматимуть фахівців, що базуються у Львові, до своїх місцевих представництв. «За три роки великої війни Львів став одним із центрів українського IT. Ми прагнемо поглибити зв’язок із місцевою професійною спільнотою й розширити свої освітні програми, щоби більше людей дізналися про можливості роботи над IT-продуктами», — говорить Олексій Ніщик, Chief Growth Officer. Уже в березні Genesis організовує ц у Львові, що стане ще одним кроком у зміцненні співпраці між компанією та місцевою IT-екосистемою. До запуску офісу компанія уже співпрацювала з львівськими закладами вищої освіти , зокрема, з Українським католицьким університетом (УКУ), де партнерство охоплює спільні освітні проєкти й дисципліни, а також — з викладачами Львівського національного університету (ЛНУ) та Львівської політехніки (ЛП) щодо навчальних програм. Від 2022 року Genesis є членом Львівського IT Кластеру.
- 6 міфів про Scrum у продуктових командах. Спростовує Product Lead в Quarks
Scrum — найпопулярніший Agile-фреймворк для розробників. Згідно з дослідженням , ним користуються близько 84% організацій у світі. Чи підходить він усім бізнесам? Scrum справді прискорює розробку або ж численні церемонії та додаткові ролі ускладнюють життя інженерів? Ця методологія працює лише цілісно чи може бути адаптована до вимог продуктових команд? Чи можна оцінювати його ефективність за кількістю релізів? Сергій Матчук, Product Lead команди Kismia в Quarks , партнерській компанії Genesis, спростував найпоширеніші міфи про Scrum та поділився, як адаптувати цей фреймворк до цілей продуктової команди. > Scrum — цілісний фреймворк, який не працює при неповній імплементації всіх складових > Впровадження Scrum потребує збільшити кількість менеджерів > Scrum передбачає забагато церемоній, які забирають більше часу ніж сама розробка > Система оцінки завдань у Scrum створена для посилення контролю над розробниками > Реліз — останній етап та спосіб вимірювання ефективності у Scrum > Scrum підходить усім командам Методологія Scrum першочергово націлена на організацію процесу розробки проєкту. Цей фреймворк дає команді можливість ефективно і планово релізити зміни у продакшн, і робити це швидко, але він не забезпечує позитивного впливу на продукт. Для ефективних результатів він має бути адаптований до цілей і специфіки бізнесу. Складовими класичного Scrum є кросфункціональні команди, відповідні ролі, церемонії, артефакти та правила. Його автори наголошують, що усі компоненти методу не підлягають змінам та працюють лише цілісно. Тож як його тоді адаптувати? Як це працює в Quarks Quarks створює продукти та технології у сфері social discovery, серед яких флагманом є Kismia, міжнародна платформа для онлайн-знайомств. Щоби ефективно розвивати цей комплексний кросплатформенний продукт, команда Kismia експериментувала з інструментами та обрала окремі практики з базових складових фреймворку Scrum: Створили три кросфункціональні команди, які відповідають за окремі платформи (iOS, Android та Web), є автономними та самостійними. До кожної команди входить два розробники та QA. Також у сервісному форматі з командою працює бекенд-інженер який закриває потреби всіх команд. У команді немає ролі продакт-овнера, але є роль продакт-менеджера який відповідає за розвиток платформи та взаємодію з командою інженерів і продуктовими спеціалістами, такими як дизайнер, продакт-аналітик. Окрім цього в Quarks є інші продуктові та технічні команди, з якими регулярно взаємодіє команда Kismia. Застосували спринти — короткі ітерації тривалістю два тижні, протягом яких створюється готовий до релізу інкремент продукту. У кожної команди свій релізний цикл і процес. Як його організовувати визначає сама команда. Організували єдиний продуктовий роудмап. У кожної кросфункціональної команди є свій беклог з точки зору платформи. В межах спринту ним керує сама команда розробки, беручи до уваги пріоритети від продуктового менеджера та продуктовий роудмап. Визначили зрозумілу ціль — завдання, на якому команда фокусується протягом спринту. Альтернатива цілі спринту — запуск експериментів, про які домовляється команда розробки та продуктовий менеджер. Водночас усі команди мають один контекст, бачення та єдиний вектор розвитку. Попри те, що команда Kismia імплементувала не цілісний фреймворк «з коробки», а його окремі складові, такий підхід забезпечує ефективну роботу команди, системний цикл релізів та запуск експериментів на трьох платформах. Канонічний Scrum передбачає, що до кросфункціональної команди обовʼязково має входити продакт-оунер та скрам-майстер. Продакт-оунер відповідає за пріоритезацію завдань, які треба виконати протягом спринту, а також за цінність продукту, комунікацію зі стейкхолдерами, збір вимог та донесення до команди бачення кінцевого продукту. Скрам-майстер слідкує за дотриманням практик та правил методології. Як це працює в Quarks Найважливіша концепція Scrum — ідея автономних та самоорганізованих команд. Фактично усі додаткові ролі, церемонії та артефакти створені саме для того, щоби зробити їх більш самостійними. Водночас команда розробки у продуктових компаніях зазвичай добре розуміє цілі та бізнес-контекст. Досвідчений спеціаліст може самостійно організувати процес розробки та взаємодію з QA чи іншими інженерами. Він добре розуміє бізнес-контекст, ціль та ролі в команді, тому йому не потрібен посередник, який водитиме його «за руку» та вирішуватиме усі питання. Залучаючи до команди таких сильних людей, Quarks змогли відмовитися від зайвих ролей — продакт-овнера та скрам-майстра. У такому підході значно складніше наймати, адже до кандидата висувається більше вимог — комунікаційні навички, продуктове мислення тощо. Проте це працює ефективніше. Зокрема, можна уникати «менеджерських трикутників». Коли в одного інженера виникає питання до іншої команди, він не іде до свого менеджера, щоби той звернувся до іншого менеджера, а спрямовує свої питання одразу на колегу з технічної команди. Це більше розвиває спеціалістів, дає їм свободу та автономність. Команда розробки максимально залучена до продуктового процесу, розуміє цілі, пріоритети, обмеження та залежності. Отримуючи всі відповіді на етапі планування та при формуванні продуктових вимог, вони самостійно планують скоуп спринту, запускають його, і рухаються протягом двох тижнів. Продуктовий менеджер керує беклогом і пріоритетами. Він відповідає за продуктову частину продукту, а саме за експерименти, що мають позитивний вплив на продукт, його цінність для користувача та бізнесу. Зазвичай до церемоній Scrum входять: рефайнмент, планування спринту, дейлі-стендапи, спринт-ревʼю та ретроспектива. Рефайнмент. Зустріч, на якій учасники опрацьовують беклог продукту та розбирають завдання. Планування. Відбувається на початку кожного спринту для визначення цілі та завдань, які команда має виконати протягом наступного періоду. Дейлі-стендапи. Щоденні короткі зустрічі, що відбуваються протягом спринту. Кожен член команди розповідає про свій прогрес, завдання і будь-які проблеми, які заважають роботі. Спринт-ревʼю проводять у кінці кожного спринту. На ньому команда підбиває підсумки та презентує результати стейкхолдерам. Ретроспектива. Зустріч для аналізу минулого спринту, виявлення проблем та можливостей покращити процеси. Проходять у кінці спринту. Часто розробники скаржаться, що такі зустрічі проходять неефективно: обговорення можуть тривати годинами, що призводить до виснаження команди. Як це працює в Quarks Церемонії не мають відбуватися лише заради дотримання правил Scrum. Важливо берегти час команди, а не збирати усіх з будь-якої нагоди, щоби послухати менеджера. В Quarks усі зустрічі та церемонії мінімізовані за тривалістю та кількістю учасників. Наприклад, рефайнмент займає не 2 години, а 30-40 хвилин. Команди розробки щодня проводять дейлі-стендапи, вони проходять без менеджерів. Основна зустріч, з якої починається підготовка до спринту — рефайнмент. На ній розробники розбирають плани на наступний спринт чи ітерацію, і впевнюються, що до завдань немає питань. Окремої зустрічі з планування, на яку збирають всю команду, не проводять. Після рефайнменту відповідальні за платформи дивляться оцінки завдань, сформований скоуп, пріоритети менеджерів та запускають спринти. Ретроспективи проводять періодично, щоби виявити проблеми у процесах на стику взаємодії. Команда самостійно вирішує, коли провести таку зустріч та може її пропустити, якщо ні в кого немає зауважень щодо ефективності роботи чи результатів спринту. Щоби Scrum працював повноцінно, важливо мати хорошу технологічну базу — йдеться про CI/CD, пайплайни та внутрішні інструменти для підвищення ефективності та автоматизації. Якщо вони якісно налаштовані, частково зникає потреба у додаткових процесах, ролях та церемоніях. Одна з практик Scrum — оцінка складності завдання під час планування спринту. Це допомагає команді розробників прогнозувати, скільки часу та ресурсів знадобиться для виконання конкретної роботи. Є чимало підходів, як оцінити завдання, один з яких — сторипоінти. Часто вони не виражені у конкретних годинах чи днях, а відображають відносну складність чи обсяг роботи порівняно з іншими завданнями. У деяких компаніях за кількістю виконаних сторипоінтів оцінюють загальну ефективність команди. Вважається, коли число запланованих та виконаних завдань відрізняється, це свідчить про неякісне планування або проблеми у процесах. Як це працює в Quarks Кількість сторипоінтів не має бути інструментом контролю чи звітності перед продуктовим менеджером або іншими стейкхолдерами. Це інструмент, який допомагає команді правильно запланувати навантаження та підтримувати динаміку розробки. Якщо виникають проблеми з ефективністю в команді чи окремих людей, за сторипоінтами можна шукати проблеми у процесах. Проте щойно команда розробки в Quarks вийшла на певний рівень ефективності, це стало їхнім внутрішнім інструментом. Вимірювання результату спринту — те, чого продуктовій команді не вистачає у Scrum. Традиційно останнім етапом та фінальною точкою в спринті вважається реліз. Як це працює в Quarks Натомість у продуктовій розробці це тільки початок процесу, адже в результаті релізу нового функціоналу чи змін команда збирає нову інформацію, інсайти, робить висновки, а потім вирішує, чи має цінність той функціонал, який зробила. Експерименти та тестування гіпотез складають основу роботи продуктової команди. Водночас лише 30% ідей мають цінність для бізнесу і користувачів та залишаються в продукті назавжди. Тому командам точно не варто фокусуватися виключно на кількості та частоті релізів. Scrum допомагає системно випускати релізи, але він не впливає на те, скільки з них матимуть вплив на продукт та наскільки він буде успішним. В Quarks ефективність того чи іншого процесу у команді оцінюють за: динамікою релізу змін (Time to market); якістю продукту з точки зору наявності дефектів чи проблем; ефективністю змін та впливу на продукт; задоволеністю команди: наскільки їй комфортно працювати в такому процесі. Scrum — найпопулярніший Agile-фреймворк, проте насправді він підходить далеко не всім командам. Наприклад, деяким сервісним компаніям завдання від замовника можуть приходити частіше ніж раз на спринт. Також Scrum не підійде тим командам, де є залежності в процесах та потреба додаткової взаємодії або комунікації. Ці проблеми вирішуються такими фреймворками, як Safe чи lEss, але вони додають ще більше церемоній та додаткових ролей. Scrum не буде ефективним в забюрократизованих компаніях, де команда не зможе бути повністю автономною, а чекатиме на погодження від стейкхолдерів. Загалом, цей фреймворк може бути дієвим для багатьох проєктів, але важливо враховувати контекст та потреби. Якщо методологію неможливо адаптувати, варто розглянути інші підходи. Як це працює в Quarks Обираючи будь-який фреймворк, важливо, щоби не команда адаптувалася під нього, а навпаки: підібрати такі практики, з якими всім буде комфортно працювати та досягати цілей. Як і всі інші процеси, цю методологію треба регулярно переглядати та безперервно покращувати через зворотний фідбек команди. Ключове завдання менеджера — зібрати сильну команду, надати їй весь необхідний контекст й інструменти для роботи та допомогти стати автономною. Якщо це вдалося, можна далі експериментувати з методологіями та обирати ті практики, які допоможуть команді бути ефективнішою. Отже, варто памʼятати, що Scrum народився в 1990-х роках. Деякі з його концепцій просто неможливо імплементувати сьогодні. Наприклад, mobling programming — групове програмування, коли в команди є один монітор та одна клавіатура, які передаються по колу, а код пишеться колективно. Або ідея co-located-команд — коли усі мають сидіти за одним столом в одній кімнаті, щоби уникати зайвих листів та чатів та вирішувати усі питання одразу. Кожна команда має брати лише найкращі практики, які відповідають її поточним проблемам та цілям, та уникати сліпого впровадження церемоній та ролей заради дотримання правил.
- 5 порад керівнику від CEO Duomo Артема Копанєва
У масштабній освітній програмі Genesis StartUp Academy 2.0 together with Meta взяли участь 50 підприємців-фаундерів з усього світу. Менторські сесії, зустрічі з топовими підприємцями, можливість залучити інвестиції, та звичайно — навчання від практиків. Про різні етапи створення, управління та масштабування технологічного бізнесу учасники дізнавалися на лекціях від найкращих фахівців Genesis, Meta та інших компаній. Редакція блогу публікує конспект однієї з найзатребуваніших лекцій програми — «Управління командою» від CEO Duomo Артема Копанєва. Віднайдіть правильну мотивацію Мотивація співробітників дійсно сприяє розвитку бізнесу, коли вона обрана на правильному рівні. Ви можете обирати з трьох варіантів: Матеріальна мотивація — гроші й бенефіти Я не прибічник того, що для мотивації компанія має обов'язково платити вище за ринок. Стартап має надихати людей своєю візією та амбіціями. Якщо ви маленька компанія і переплачуєте співробітникам, це не дуже ефективний шлях залучення людей у команду. У такому випадку вони будуть відчувати себе лише робітниками: зробили роботу — отримали гроші. Набагато краще, коли люди бачать, що вони є частиною справжнього ком'юніті, яке працює спільно над чимось дуже важливим. На перших кроках бізнесу ідея та візія продукту чи компанії важить більше, ніж матеріальні заохочення. Особиста мотивація Професійне зростання, набуття нових навичок, досвіду, робота з класними людьми. З цих переваг робота із суперпрофесіоналами — найкраща мотивація. Насправді саме це допомагає людям швидше вчитися, зростати та досягати кращих результатів. Соціальна мотивація Якщо цілі, місія та бачення компанії збігаються із цінностями й цілями людини, це найкраща мотивація, яку вона може отримати. Кожному члену команди важливо розуміти, як його особисті цілі поєднуються із загальною візією компанії — чи це отримання нових навичок або бажання стати частиною великої історії. Важливо створити переконливу історію, яка допоможе залучати людей. Варто завжди пам'ятати, що найкращі фахівці можуть отримати будь-яку позицію, яка їм сподобається. Тому, якщо хочете створити команду топгравців, зверніть увагу на амбіції та цілі, які ваша компанія може задовольнити. Великі гроші й бенефіти A-players отримають будь-де, а от класна візія — це те, чим ви маєте вирізнятися, і те, що допоможе вам їх залучити. Підвищення Якщо співробітник претендує на підвищення, або ж менеджер вирішує, що хтось із команди має змінити позицію, варто ухвалювати рішення, враховуючи декілька факторів. Кого треба підвищувати? Співробітника, що має серйозні досягнення. Важливо, що тут йдеться про досягнення у вашій компанії, а не в попередній. Наприклад, якщо людина щойно прийшла, і ви одразу підвищуєте її на сеньйорну позицію через її попередні досягнення — це погана ідея. Так ви лише демотивуєте співробітників, які показали класні результати у вашій компанії, і це може призвести до внутрішніх конфліктів. Співробітника, який готовий до підвищення — як із точки зору навичок, так і з точки зору репутації в компанії. Людину, що відповідає культурі компанії, розділяє її цінності, знаходиться на тому ж рівні, що й компанія. Наприклад, людина з корпорації навряд чи підійде стартапу, і навпаки. Співробітника, що сам ініціює підвищення. Буває, що компанія підвищує людину, яка не хотіла цих змін. Класичний приклад — розробник, який досяг високих професійних успіхів, але не хоче бути менеджером. Запитайте у людини, чого вона хоче. Якщо виявиться, що вона не рада підвищенню — це не червоний прапорець або поганий знак. Сприймайте це лише як вказівку на те, що співробітник знає, що він хоче робити, і варто дати йому цю можливість. Абсолютно нормально, коли в компанії є люди, які експертні у своїй сфері, але не керують командами. Реалізуйте підвищення максимально прозоро та зрозуміло для компанії та самого працівника. В комунікації з людиною узгодьте всі очікування, дізнайтесь, яких ресурсів вона потребуватиме на новій позиції. Підвищення — складний виклик у будь-якому випадку, тому надайте всю необхідну підтримку. У комунікації для команди окресліть причини підвищення, нові сфери відповідальності співробітника. Наприклад, коли ми підвищуємо людину, я зазвичай надсилаю імейл на всіх співробітників, що дотичні до людини, де розповідаю про її досягнення, обов'язки на новій позиції. Крім того, прошу підтримати колегу у новій ролі та всіляко допомагати їй адаптуватися. Якщо замість листа ви зробите оголошення на зустрічі all hands — теж ок. Без звільнень не обійтись Одна з ключових помилок менеджерів — не звільняти тих, хто показує низький рівень перформансу. Це спричиняє дві проблеми. По-перше, залишаючи цих людей, ви знижуєте загальний рівень виконання задач. По-друге, ті, хто справляється зі своїми завданнями, демотивовані колегами, у яких не виходить досягати поставлених цілей. Водночас звільнення не має бути сюрпризом для людини. Якщо співробітник показує низький перформанс, приділіть йому увагу, дізнайтеся, чому так стається. Якщо людина певний час не досягає своїх цілей, ви маєте це з нею обговорити, запропонувати підтримку, допомогу, можливо, додаткові ресурси. Крім того, частіше перевіряйте проміжні результати. В Genesis ми практикуємо випробний період (2-3 місяці) для тих колег, у кого є складнощі з перформансом. Ми обговорюємо, в чому проблема, і визначаємо час, протягом якого вона має вирішитись. Комунікуйте прозоро Більшість проблем у комунікації компанії стаються саме через недостатню прозорість, а не через надмірну комунікацію. В режимі стартапу це нормально комунікувати багато, обговорювати ідеї та виклики разом із командою. Саме прозорість комунікації значним чином впливає на мотивацію або демотивацію співробітників. Передусім, це доступ до інформації про бізнес-метрики. Всі великі технологічні компанії надають співробітникам доступ до всіх бізнес-показників. По-друге, це чітка і зрозуміла трансляція візії компанії, пояснення дій і рішень менеджменту. Чим «молодша» стадія розвитку компанії, тим більшу роль це відіграє. Найкраще про це розповідати на зустрічах all-hands. One-on-one Прозору та послідовну комунікацію забезпечують також зустрічі one-on-one (або чекпойнти). Це ключове зобов'язання менеджера. Я раджу проводити чекпойнти з усіма, хто безпосередньо вам підпорядковується, щотижня або хоча б раз на два тижні. Ця регулярна зустріч проводиться не лише для менеджера, щоби зрозуміти, як людина перформить, а й для співробітника. На ній він має змогу адресувати менеджеру свої виклики й потреби, питання, які його турбують. Обов'язковий пункт для ефективного чекпойнту — перевірка статусів по задачах, які виконує співробітник, обговорення його стратегічних планів і цілей. Менеджер має поцікавитись, чи комфортно людині зараз в компанії, чи достатньо їй ресурсів, чи вона мотивована. Крім цього, варто обмінятися новинами або апдейтами по компанії або відділу. Критерії ефективного one-on-one: регулярність; якісна підготовка — як із боку менеджера, так і з боку співробітника; відкритість — на чекпойнті можна обговорити все, що турбує. Не забувайте делегувати Бізнес — командний спорт, тому ви маєте постійно розвивати співробітників та робити їх сильнішими. Делегування задач — один з ефективних інструментів для цього. До того ж делегування вдосконалює структуру компанії та додає працівникам більше мотивації. Керівник, своєю чергою, не витрачає час на поточні задачі, а може зосередитись на розв'язанні стратегічних питань. Замість висновків. 5 розповсюджених помилок менеджера Недостатньо чітко сформульовані цілі та критерії оцінки кожного співробітника; не звільняти low-перформерів. Це знижує загальний рівень якості роботи та вмотивованості в компанії; не приділяти увагу комунікації — як загальній, так і особистій. Іноді це здається нудним, але варто регулярно робити ці речі, бо вони впливають на розвиток компанії загалом; брак можливостей росту для співробітників (відсутність делегування, недостатнє розширення обов'язків та відповідальності). Варто приділити увагу і дійсно поцікавитись, чого хочуть ключові люди в компанії, які їх довгострокові цілі; вибудовувати структуру, базуючись лише на інтересах компанії і не беручи до уваги довгострокові інтереси співробітників. Чотири книжки для менеджерів «Високоефективний менеджмент», Ендрю Гроув «Ефективний керівник», Пітер Друкер «Принципи», Рей Даліо «Ми — те, що ми робимо», Бен Хоровіц
- Що таке DDD: як працює, та як впровадити
Ідея про те, що системи програмування мають базуватися на конкретній предметній області, здається очевидною, проте коли розробник Ерік Еванс зібрав докупи усі патерни, методи та нюанси подібного підходу, вийшла ґрунтовна фундаментальна праця на півтисячі сторінок. Він назвав нову розробницьку філософію Domain-Driven Design (DDD) або предметно-орієнтоване проєктування. У цьому матеріалі ми з’ясовуємо, що таке DDD, чи актуальна методологія зараз, які основні концепції варто знати перед тим, як з нею працювати, які переваги та недоліки є у запропонованого Евансом підходу. Розібратися у предметно-орієнтованому проєктуванні нам допоміг Андрій Попов, Back-end Tech Lead в AMO , одній з компаній екосистеми Genesis. Андрій керує бекенд-командою у проєкті з розробки застосунку в галузі Health&Fitness. Загалом він має більш ніж десятирічний досвід в IT, працював в нішах Education та Betting, де зокрема застосовували концепції предметно-орієнтованого дизайну. Що таке DDD, і чому він потрібен у сучасній розробці Domain-Driven Design — це підхід до розробки, відповідно до якого створення систем програмного забезпечення базується на домені, тобто на предметній області, в якій працює компанія. Таких доменів може бути один або декілька — залежно від комплексності конкретного бізнесу. Прикладом бізнесу, де поєднано кілька доменів, може бути великий ecommerce-проєкт, залізниця, пошта, фінансова організація тощо. У великих проєктах часто буває так, що розробники концентруються тільки на тій частині бізнес-логіки, з якою вони безпосередньо працюють. Через це виникає низка труднощів. Окремі члени команди не бачать повну картину того, що відбувається в коді, і, відповідно, не можуть врахувати специфіку системи, не бачать найбільш вдалі архітектурні рішення, й фокусуються на цікавих з точки зору розробки, але другорядних з точки зору бізнесу завданнях. DDD допомагає ці проблеми усунути. Предметно-орієнтоване проєктування передбачає, що кожен у команді має цілісне уявлення про код, про домен та про бізнес-процеси. Цього досягають, зокрема, завдяки моделі предметної області, яку розробляють на початку, та єдиній мові, якою комунікують всі стейкхолдери. Тоді й розробники, і бізнес мають однакове бачення системи — і необхідність у постійній синхронізації та ґрумінгах зникає. Важливо, що DDD — це не конкретна технологія чи методологія. Це набір правил та підходів, які полегшують процес розробки. У сучасному програмуванні все більше девелоперських команд відмовляється від монолітів на користь мікросервісів — і DDD стає їм у пригоді: допомагає визначити межі кожного мікросервісу, основні концепції, агрегати та пов’язану з ними бізнес-логіку. Завдяки цьому розробники мають змогу зробити більш структурний та масштабований код. У предметно-орієнтованому проєктуванні є два рівні — тактичний та стратегічний. Розберемося з основними поняттями для кожного з них. Основні поняття DDD У основі терміну лежить поняття предметної області ( domain ) — це галузь, у якій працює організація. На початку в особливостях цієї галузі може бути важко орієнтуватися, однак з часом усі залучені до проєкту розбираються в усіх нюансах. Втім, створити всеохопну модель будь-якого складного бізнесу не вийде, тому в доменах виділяють subdomains — предметні підобласті, що ранжуються відповідно до їхньої фактичної функціональності. Субдомени дають змогу швидше визначити різні частини предметної області, необхідні для вирішення конкретного завдання. Серед них виділяють змістове ядро ( core domain ) — найбільш важливий субдомен. По суті, це унікальна ціннісна пропозиція, яка вирізняє конкретний бізнес. Саме на ній мають фокусуватися найкращі розробники та саме у неї слід спрямовувати найбільше інвестицій — адже core domain напряму впливає на отримання прибутку та успіх бізнесу. Натомість деякі інші аспекти бізнесу є важливими, але не ключовими. Тоді їх відносять до службової підобласті ( supporting subdomain ). Більшість таких юнітів мають спеціалізацію. Якщо ж її немає, а підобласть потрібна для всього бізнесу — вона називається неспеціалізованою ( generic subdomain ). Одна з найважливіших концепцій доменно-орієнтованого проєктування — це ubiquitous language або усеохопна мова. Фактично, це набір термінів для конкретної команди, в створенні якого беруть участь усі дотичні до проєкту люди — програмісти, експерти предметної області, аналітики тощо. Структурним одиницям коду, таким як класи, методи, змінні чи назви, присвоюють конкретні назви, які базуються на моделі домену. Завдяки цьому код стає чітким та зрозумілим для всіх. «Єдина термінологія, якою оперують бізнес і команда розробки, дозволяє усувати прогалини у взаєморозумінні. Наприклад, зараз ми в AMO ми робимо застосунок для тренувань. У нас не імплементовано DDD у чистому вигляді, однак є деякі технічні елементи концепції з тактичних патернів. Крім того, ми ввели Ubiquitous Language, наскільки це було можливо. Так, кожен має точно знати, що значить тренування, з чого воно складається тощо. У теорії створити та імплементувати таку мову просто, одна на практиці цей процес доволі складний. Потрібна людина, яка буде стежити за її застосуванням. Ідеально, якщо це людина, яка працює на перетині розробки та бізнесу, наприклад, дата- чи бізнес-аналітик», — каже Андрій Попов. В межах предметної області сенс певного терміна або поняття може відрізнятися. Існує певна межа — і за нею поняття єдиної мови набувають конкретного контекстного значення. Така межа називається обмеженим контекстом ( bounded context ). Це ще одна критично важлива характеристика DDD, яка полягає в тому, що на різних рівнях проєкту можуть використовуватися декілька моделей зі своїми єдиними мовами. Завдяки bounded context зв’язки між моделями зменшуються — і це теж запобігає складному та заплутаному коду. Bounded Context дозволяє дублювати моделі в різних командах, щоб кожна могла вільно змінювати цю модель у себе, незалежно від іншої. Тактичний рівень DDD Аби реалізувати специфічний bounded context, на тактичному рівні використовують низку шаблонів. На відміну від стратегічного моделювання, яке фокусується на загальному управлінні бізнесом, такі шаблони використовують для ітеративної розробки. Сутності ( entity ) використовують, коли потрібно змоделювати унікальні поняття, або ті, що відрізняються від інших об’єктів у домені. Їх можна визначити за певним ключовим атрибутом або комбінацією атрибутів, що не залежать від інших характеристик. Якщо ж для об'єкта не важлива індивідуальність, і для його визначення достатньо власних атрибутів, його вважають об'єктом-значенням ( value object ). Їх легше створювати та підтримувати, тому розробники намагаються використовувати об’єкти-значення частіше, ніж сутності. Значні зміни в стані домену відображають події ( domain event ). Вони використовуються для передачі змін і запуску дій між різними частинами системи. Модулі ( module ) можуть бути організовані навколо конкретних концепцій домену та містять класи, функції чи компоненти, що відповідають за обробку логіки та даних, пов'язаних з конкретною концепцією предметної області. Агрегат або сукупність ( aggregate ) — це кластер пов’язаних між собою сутностей та об’єктів значення, які розглядаються як єдине ціле. Вони забезпечують узгодженість та цілісність змін у своїх межах. Фабрики ( factory ) існують, щоби відтворювати інші об’єкти, а сховища ( repository ) надають інтерфейс для доступу та керування агрегатами. Зв'язок між сутностями DDD У яких випадках потрібен DDD DDD призначене для створення моделей доменів зі складною бізнес-логікою. Це означає, що найкраще концепція підійде для вузьких специфічних ніш — наприклад, фінтех або e-commerce. «Канонічне предметно-орієнтоване проєктування містить дуже багато понять, патернів та підходів. Використовувати їх усі у стартапі або проєкті, запущеному з нуля, важко й не доцільно», — коментує Андрій Попов. Коли команді варто обирати перехід на DDD? Наприклад, якщо це складна ніша з багатьма окремими сутностями. «Раніше я працював саме над таким проєктом. DDD імплементували з нуля, оскільки ніша передбачає багато складних для розуміння сутностей. Потрібно було пильно стежити за правильністю термінології, тому ми зробили окрему сторінку з глосарієм, де було пояснення багатьох специфічних для ніші понять. Була навіть відповідальна людина — бізнес-аналітик, який транслював вимоги конкретно під цю область, а програмісти намагалися писати код відповідно до бізнес-правил», — говорить Андрій Попов. Як імплементувати DDD у себе в проєкті Імплементувати методологію може бути складно. На цьому шляху є декілька челенджів. «Найперше — розробникам може бути банально нецікаво працювати з новою концепцією. Буває так, що термінологію прописує бізнес-команда — і технічним фахівцям потрібно до неї звикати. А означає, що треба повністю змінювати стиль роботи, і витрачати додаткові час та енергію на щось іще, окрім написання коду. З іншого боку — перехід на нові правила може не цікавити сам бізнес, бо на це потрібно виділяти час, ресурс, призначати відповідальну особу, яка буде за всім стежити», — підкреслює Андрій Попов. Однак, з часом DDD перестає уповільнювати роботу команди й тільки полегшує розробку. «Нещодавно ми запустили ще один проєкт в ніші Health and Fitness. Мене призначили лідом, дали невеличку команду. Я одразу вирішив, що ми будемо використовувати глосарій з термінологією, інакше буде плутанина і люди не розумітимуть, що і як влаштовано в коді. Поки що тільки цим словником важко обмежуватися, адже під час написання абстракцій чи алгоритмів все одно доводиться щось додумувати. Втім, ми уже маємо певний каркас, завдяки якому розробники та бізнес краще одне одного розуміють. Це, знову таки, не канонічне предметно-орієнтоване проєктування — здебільшого ми послуговуємося суто технічними речами, такими як фабрики, репозиторії, сервіси, доменні моделі тощо. Однак подібний підхід все одно покращує чистоту коду, й сам процес розробки стає комфортнішим», — розповідає розробник. Переваги DDD покращує чистоту та структурованість коду; розробники та бізнес говорять однією мовою — що дозволяє уникнути хаосу та плутанини; архітектура точно відображає бізнес (предметну область) та враховує його специфічні особливості; автономна робота над різними частинами системи забезпечує кращу масштабованість; у великих проєктах з кількома технічно незалежними командами DDD чітко декларує способи їхньої взаємодії; компоненти та бібліотеки, які створюють у межах DDD, можна використовувати у майбутніх проєктах — що заощаджує час розробників. Недоліки DDD на початку DDD суттєво уповільнює робочий процес; розробникам чи бізнесу можуть не подобатися нові правила, що призведе до опору та конфліктів; ускладнення коду (якщо до нього «притягнути» зайві пункти методології); збільшення кодової бази через специфічні технічні рекомендації; DDD вимагає залучення кваліфікованих експертів предметної області та досвідчених розробників, тому може бути ресурсомістким; деякі інструменти та фреймворки можуть не вписуватися в принципи DDD, а це ускладнить реалізацію функціонала. DDD для кар’єри Розробникам рівня сеньйор з амбіціями стати тимлідами точно корисно мати в резюме рядок про знання принципів DDD, говорить Андрій Попов. Не факт, що ці знання згодяться у роботі, оскільки не всі (навіть великі) проєкти застосовують DDD. Однак обізнаність у цьому підході покаже і рівень досвіду, і менеджерські амбіції. «Будь-які додаткові знання стануть плюсом. А якщо людина прагне до керівної посади, їй варто розумітися не лише на технічних патернах, а й на стратегічних речах, зокрема, комунікації між командами та бізнесом. Втім, на початку кар’єри краще присвятити час заглибленню у технічні нюанси розробки обраною мовою», — уточнює Андрій. Корисні матеріали Весь теоретичний матеріал з DDD зібраний у трьох канонічних виданнях — синій, червоній та зеленій книзі. Книжки для вивчення DDD Синьою книгою називають працю Еріка Еванса «Предметно-орієнтоване проєктування: структуризація складних програмних систем» . Еванс — основоположник концепції DDD, тож у книзі він ґрунтовно пояснює, як включити ефективне доменне моделювання у розробку ПЗ. Автор не описує конкретні технології, пропонуючи натомість підходи, інструменти та методи, які полегшать розробку ПЗ у складних доменах. «Цю книжку варто прочитати хоча б тому, що це першоджерело знань про DDD. Однак не розраховуйте, що буде легко: вона доволі специфічна, я зміг дочитати її лише з третього разу», — каже Андрій. «Новачки навряд чи зможуть одразу застосувати методології, про які пише Еванс. А от якщо ви розробник зі значним комерційним досвідом та працювали з великими замовниками у незнайомій для вас царині — то ця книга точно стане в пригоді». Червона книга — це «Реалізація методів предметно-орієнтованого проєктування» , яку написав Вон Вернон. На відміну від попереднього «підручника», де описуються фундаментальні принципи DDD, у виданні американського архітектора програмного забезпечення є більш практичні поради. Він із самого початку знайомить читачів з проблемами реальної розробки й показує, як їх вирішити за допомогою методів та шаблонів DDD. Зелену книгу , «Предметно-орієнтоване проєктування: найголовніше» , також написав Вон Вернон. З усіх трьох вона найпростіша для сприйняття. По суті, це короткий довідник з основними концепціями DDD та простими прикладами з досвіду Вернона, на яких видно переваги підходу. Загалом, DDD — це, швидше, звід рекомендацій, ніж суворий набір правил. Тимліди технічних команд можуть обирати лише деякі рекомендації з цього підходу — і процес не поламається. Але навіть декілька інструментів предметно-орієнтованого проєктування дадуть змогу простіше допрацьовувати, змінювати та тестувати застосунок у майбутньому.
- 30+ корисних YouTube-каналів для технічних спеціалістів
YouTube — одна з найзручніших платформ для того, аби залишатися в курсі останніх трендів: відео, практичні кейси та лекції дозволяють не лише навчатися, а й заглиблюватися у спеціалізовані теми. У цьому матеріалі ми зібрали добірку найкращих YouTube-каналів для технічних спеціалістів і розділили їх на категорії для зручності: для розробників, тестувальників, DevOps-інженерів, спеціалістів з Data Science та інших фахівців IT-сфери. Збережіть ті, що можуть вам знадобитися. Розробка (Software Development): front-end, back-end, full-stack freeCodeCamp Тематика: Веброзробка, основи JavaScript, React, HTML, CSS Тип контенту: Безкоштовні курси, покрокові уроки, лайвкодинг, ґ айди для розробників будь-якого рівня Чому варто дивитися: freeCodeCamp — одна з найбільших безкоштовних платформ для вивчення веброзробки. Тут можна отримати ґрунтовні знання від основ до рівня впевненого спеціаліста. Особливо корисно для тих, хто хоче з нуля освоїти програмування або прокачати навички у фронтенді та бекенді. Traversy Media Тематика: Веброзробка, програмування Тип контенту: Відеоуроки з HTML, CSS, JavaScript, а також бекенд-технологій (Node.js, Python, PHP). Огляд популярних фреймворків (React, Vue). Чому варто дивитися: Канал підходить як для початківців, так і для досвідчених розробників. Тут зібрані актуальні туторіали та структуровані пояснення сучасних технологій, що допоможуть у навчанні та роботі. Fireship Тематика: Огляд трендів у веброзробці та програмуванні Тип контенту: Короткі динамічні відео (5–10 хв) про нові фреймворки, технології, тренди в індустрії та практичні поради з оптимізації коду Чому варто дивитися: Fireship пропонує швидкий формат навчання — замість годинних лекцій тут стислий і насичений контент. Канал допоможе швидко зорієнтуватися в новинках та освоїти технології ефективніше. The Net Ninja Тематика: Фронтенд і бекенд-розробка для початківців і middle-розробників Тип контенту: Серії відеоуроків з JavaScript, Vue.js, React, Node.js, TypeScript, Firebase, MongoDB, PHP, MySQL, Laravel, React Native, Flutter Чому варто дивитися: Канал має чітко структуровані плейлисти з покроковим поясненням. Чудовий вибір для тих, хто любить вчитися за планом і хоче глибоко освоїти веброзробку. Academind Тематика: Бекенд-розробка, основи та практичні приклади роботи з Node.js, MongoDB, GraphQL Тип контенту: Глибокі туторіали, пояснення складних концепцій, повні курси Чому варто дивитися: Канал надає структуроване навчання сучасним бекенд-інструментам. Корисний як для новачків, так і для тих, хто прагне поглибити знання про серверні технології. From A to QA 🇺🇦 Тематика: Програмування, тестування, інженерний менеджмент Тип контенту: Огляд IT-сфери, навчальні матеріали Чому варто дивитися: Канал веде Артур Шевченко, Director of Engineering в Yalantis, — він ділиться знаннями не лише про код, а й про менеджмент у розробці та тестуванні. Codevolution Тематика: Full-stack розробка з акцентом на бекенд Тип контенту: Покрокові ґ айди із Node.js, REST API, GraphQL, Docker Чому варто дивитися: Практичні відео, що допомагають глибше зрозуміти роботу бекенду та принципи побудови серверних додатків. Aleksandr Sugak 🇺🇦 Тематика: Практичний досвід у розробці Тип контенту: Реальні кейси, приклади коду Чому варто дивитися: Жодного клікбейту — лише стисла подача важливої інформації із практики. Автор ділиться своїм 15-річним досвідом, а також показує як вирішує ті чи інші задачи, демонструючи роботу в редакторі коду. JavaScript Січ 🇺🇦 Тематика: JavaScript, фронтенд-розробка Тип контенту: Навчальні курси, практичні поради, огляди бібліотек Чому варто дивитися: Канал чудово підходить для тих, хто хоче розібратися в JavaScript та сучасних технологіях для фронтенду — всі відео збережені в «Трансляціях». Сергій Бабіч та Дивовижний світ веброзробки 🇺🇦 Тематика: Фронтенд-розробка Тип контенту: Навчальні відео, практичні кейси Чому варто дивитися: Сергій ділиться власним досвідом у сфері веброзробки. Тут можна знайти огляди HTML, CSS, питання та обговорення співбесід, а також надихаючі розмови з IT-фахівцями. Девелопери з Projector 🇺🇦 Тематика: Фронтенд-розробка Тип контенту: Короткі відео-уроки українською мовою, пояснення базових понять Чому варто дивитися: Тут просто і зрозуміло пояснюють, як працює веброзробка. Навчання ведуть практикуючі розробники та куратори курсів у Projector. KRUHLYK 🇺🇦 Тематика: PHP, Laravel, Full-Stack розробка Тип контенту: Практичні поради, ґ айди із Laravel та PHP, розбір best practices Чому варто дивитися: Автор має 15-річний досвід у компаніях Ciklum, Takeaway.com , 1+1 Media. На каналі можна знайти матеріали з оптимізації коду, API, Livewire та інших технологій. Кодимо солов’їною 🇺🇦 Тематика: Фронтенд-розробка Тип контенту: HTML, CSS, JS, Astro, React, Next.js, Vue, Angular Чому варто дивитися: Просте та зрозуміле пояснення основ фронтенду без зайвої «води». Автор також створив курс, який допомагає швидко увійти у фронтенд-розробку. Web X In UA 🇺🇦 Тематика: Веброзробка, новини IT Тип контенту: Освітні та інформаційні відео Чому варто дивитися: Канал для всіх, хто хоче дізнаватися про новинки веброзробки українською мовою. Тестування (QA) Ministry of Testing Тематика : Ручне та автоматизоване тестування, QA-ком’юніті. Основний тип контенту : Поради, вебінари, практика, статті, подкасти, сертифікації. Чому варто стежити : Ministry of Testing – це не просто YouTube-канал, а ціле міжнародне ком’юніті тестувальників. Його місія — підтримка та розвиток професії тестування ПЗ через освітній контент та взаємодію спільноти. Тут публікуються матеріали про нові тренди, технічні аспекти тестування, конференції, сертифікації та інші можливості для розвитку QA-фахівців. Канал буде корисним як новачкам, так і досвідченим інженерам, які хочуть тримати руку на пульсі індустрії. Angie Jones Тематика : Автоматизація тестування, кар'єрні поради для QA-інженерів. Основний тип контенту : Туторіали, гайди, кращі практики автоматизації, розбір реальних кейсів у тестуванні. Чому варто стежити : Енджі Джонс — експертка у сфері тестування, яка ділиться своїм досвідом у автоматизації тестування, розповідає про кар'єрний ріст у QA та пояснює сучасні підходи до забезпечення якості ПЗ. Її матеріали корисні для тестувальників будь-якого рівня, особливо для тих, хто хоче розвиватися в напрямку автоматизації. qa семпай 🇺🇦 Тематика : Автоматизація тестування, основи QA, інженерія тестування. Основний тип контенту : Відеоуроки з тестування та автоматизації, корисні поради, кар'єрні рекомендації. Чому варто стежити : Канал містить детальні матеріали, які допоможуть розширити знання та навички у тестуванні ПЗ. Тут можна знайти як базові концепції, так і складні технічні аспекти, що стосуються автоматизації тестування. Попелюха 👾 Тестування ПЗ 🇺🇦 Тематика : Тестування програмного забезпечення (manual + automation), кар'єра QA. Основний тип контенту : Україномовний курс із тестування ПЗ, відео про роботу тестувальників, гайди з технологій, корисна теорія та практика. Чому варто стежити : Канал орієнтований як на початківців, так і на професіоналів. Тут можна знайти пояснення теорії доступною мовою Веде канал Наталія Попелишко — Senior .Net Test Automation із 5-річним досвідом та авторка чотирьох курсів із тестування. HOT testing 🇺🇦 Тематика : Тестування програмного забезпечення. Основний тип контенту : Авторські відео від Олександра Хотемського, Quality Practice Lead у Doxy.me , про тестування, автоматизацію та підходи до забезпечення якості. Чому варто стежити : Канал містить унікальні авторські матеріали, що допомагають глибше зрозуміти сферу тестування. DevOps та Cloud-технології TechWorld with Nana Тематика : DevOps-інструменти, хмарні технології, CI/CD. Основний тип контенту : Покрокові туторіали з Docker, Kubernetes, Terraform, AWS, GitOps, а також практичні гайди з автоматизації DevOps-процесів. Чому варто стежити : Авторка каналу, DevOps-спеціалістка Нана Янашіа, створює доступні, структуровані та інформативні відео. Вона пояснює складні концепції простими словами, доповнюючи матеріал візуалізаціями та реальними прикладами використання. Це ідеальний канал для тих, хто хоче поглибити свої знання про інфраструктуру та автоматизацію розгортання додатків у хмарних середовищах. The DevOps Toolkit Тематика: Практичне використання DevOps-інструментів. Основний тип контенту: Туторіали з Jenkins, Ansible, Kubernetes, Docker, розбір найкращих практик DevOps. Чому варто стежити: Канал орієнтований на розв’язання реальних завдань та надання практичних порад. Автор не лише навчає користуватися популярними DevOps-інструментами, а й пояснює, як вони взаємодіють між собою, допомагаючи будувати ефективні CI/CD-процеси. DevOps Directive Тематика : DevOps-культура, автоматизація, інтеграція. Основний тип контенту : Відео про CI/CD, моніторинг, хмарні платформи, поради з налаштування DevOps-процесів. Чому варто стежити : Канал допомагає розібратися в ключових аспектах DevOps не лише технічно, а й з точки зору організації роботи команди. Тут є матеріали як для початківців, так і для досвідчених інженерів, які хочуть покращити процеси автоматизації у своїх проєктах. ДевОпс Українською 🇺🇦 Тематика: Практика DevOps, автоматизація інфраструктури. Основний тип контенту: Налаштування CI/CD, інструменти для автоматизації, робота з хмарами, контейнери, пайплайни, Docker, Kubernetes, Terraform. Чому варто стежити: Це один із небагатьох каналів, що розповідає про DevOps українською мовою. Тут можна знайти детальні інструкції та практичні кейси, які допоможуть DevOps-інженерам ефективніше працювати з хмарними технологіями та автоматизувати розгортання програмних продуктів. DevOps talks at OpsWorks 🇺🇦 Тематика : DevOps, хмарні технології, автоматизація процесів, AWS, Kubernetes. Основний тип контенту : Інтерв’ю з експертами, аналітичні огляди нових технологій, практичні гайди та огляди актуальних рішень у DevOps. Чому варто стежити : Канал охоплює широкий спектр тем, пов’язаних із DevOps, і пропонує матеріали як для початківців, так і для досвідчених фахівців. Тут можна знайти не лише технічні туторіали, а й глибокі дискусії щодо майбутнього DevOps та його ролі в сучасному IT-середовищі. Data Science, AI/ML StatQuest with Josh Starmer Тематика : Просте пояснення складних тем у Data Science. Основний тип контенту : Детальні відео про статистику, машинне навчання, алгоритми кластеризації та регресії, пояснення математичних основ AI. Чому варто стежити : Автор подає складний матеріал у легкому та зрозумілому форматі, що ідеально підходить для тих, хто тільки починає працювати у сфері Data Science. Відео супроводжуються інтуїтивними поясненнями без надмірної термінології, що робить навчання ефективним і цікавим. 3Blue1Brown Тематика : Математика, алгоритми, візуалізація. Основний тип контенту : Унікальні візуалізації складних тем у математиці, алгоритмах, нейронних мережах та інших концепціях, що використовуються у сфері AI/ML. Чому варто стежити : Завдяки високоякісній анімації та наочним поясненням ви зможете інтуїтивно осягнути математичні принципи, що лежать в основі штучного інтелекту. Чудовий ресурс для тих, хто хоче поглибити розуміння основних принципів AI/ML через математичну базу. Sentdex Тематика : Практичні проєкти у сфері AI/ML. Основний тип контенту : Туторіали на Python, проєкти з машинного навчання, нейронних мереж та обробки природної мови, застосування ML у реальних сценаріях. Чому варто стежити : Канал орієнтований на практичне навчання та дає змогу зануритися у розробку ШІ-систем, працюючи з кодом. Автор пояснює складні концепції через демонстрацію реальних проєктів, що робить навчання цікавим та корисним для початківців і досвідчених інженерів. Krish Naik Тематика : Машинне навчання, Data Science. Основний тип контенту : Покрокові гайди, туторіали, пояснення складних концепцій у простій формі, аналіз реальних бізнес-кейсів. Чому варто стежити : Автор, маючи понад 10 років досвіду у сфері ШІ, не лише розповідає про технології, а й пояснює, як вони використовуються у реальних продуктах. Канал стане корисним як для новачків, так і для професіоналів, які хочуть поглибити знання та дізнатися більше про практичне застосування AI/ML у бізнесі. Ганна Пилєва: дивовижний data-світ 🇺🇦 Тематика : Data Science, аналітика даних, кар’єра в ІТ. Основний тип контенту : Навчальні відео, аналітичні розбори, практичні поради для аналітиків даних, пояснення ключових концепцій Data Science простою мовою. Чому варто стежити : Авторка, амбасадорка Python і спеціалістка з Machine Learning, ділиться власним досвідом, допомагає розібратися у професійних навичках та мисленні, необхідному для успішної кар’єри в аналітиці даних. Тут ви знайдете багато корисної інформації про розвиток у сфері Data Science, програмування та використання ШІ у реальних проєктах. Нікіта Тимошенко | Аналіз даних українською 🇺🇦 Тематика : Аналіз даних, Data Science. Основний тип контенту : Розбір популярних інструментів для аналізу даних, практичні кейси, огляд українських інновацій у сфері Data Science. Чому варто стежити : Один із небагатьох каналів українською мовою, що присвячений аналізу даних. Допоможе зрозуміти, як працювати з сучасними аналітичними інструментами, а також розібратися у специфіці Data Science в українських реаліях. AI HOUSE 🇺🇦 Тематика : Штучний інтелект, машинне навчання, наукові відкриття, ком’юніті AI/ML. Основний тип контенту : Інтерв’ю з експертами, огляди інновацій, подкасти, освітні відео про AI та машинне навчання, обговорення технологічних тенденцій. Чому варто стежити : AI HOUSE — це найбільша ШІ-спільнота в Україні, яка об’єднує фахівців, інженерів, дослідників та підприємців у галузі штучного інтелекту. Канал стане чудовим джерелом інформації про останні розробки в AI, а також про можливості розвитку, навчання та побудови кар’єри в цій сфері. Тут проводяться мітапи, конференції, AI-школи та інші освітні заходи, що сприяють розвитку AI-екосистеми в Україні. Архітектура та системний дизайн Gaurav Sen Тематика : Алгоритми, архітектура програмного забезпечення, оптимізація систем. Контент : Розбір алгоритмів, структур даних, AI для ігор, системний дизайн масштабованих систем. Чому варто стежити : Глибоке занурення у теми, які необхідні для професійного зростання інженера-програміста. The Roadmap Тематика : Комп’ютерні науки, веброзробка, системний дизайн. Контент : Добірка найкращих онлайн-лекцій з програмування, баз даних, full-stack розробки. Чому варто стежити : Структурований підхід до навчання, що допоможе ефективно розібратися у сучасних технологіях. Кар’єра та розвиток в IT TechLead Тематика : Інсайди про роботу в техногігантах (Google, Meta), поради для IT-спеціалістів. Контент : Відео з особистими історіями, бізнес-підходи до кар’єри розробника, практичні поради щодо фінансів та продуктивності. Чому варто стежити : Канал від колишнього Tech Lead Google, що поєднує технічні знання та підприємницький досвід. Alexander Solovyov 🇺🇦 Тематика : Технічні співбесіди, конференції, розвиток у сфері технологій. Контент : Глибокі огляди технічних тем, експертні інтерв’ю, аналітика IT-індустрії. Чому варто стежити : Практичні знання для тих, хто прагне зростати в технологічній сфері та вдосконалювати навички. Канали допоможуть вам отримати цінну інформацію про кар'єру в IT, розібратися у тенденціях ринку та покращити свої професійні навички.
- Ґaйд із ШІ-термінів для розробників
Сучасні досягнення в штучному інтелекті відбуваються настільки швидко, що, здається, єдине, що рухається швидше — це безліч нових термінів та сленгових слів, які потрібно розшифровувати. Якщо ви досі не розрізняєте терміни «відкриті ваги» та «відкритий код», або не можете розібратися з таким поняттям як ШІ-дистиляція, не переживайте — цей глосарій допоможе. Редакція High Bar Journal склала основні терміни зі словника ШІ-термінів, який підготувало видання The Information . Дистиляція (Distillation): процес перенесення можливостей великої моделі в меншу. Дистиляція — це коли велика модель (так званий «вчитель») навчає більш компактну модель — «учня». Цей процес вимагає значних обчислювальних потужностей, оскільки потрібно одразу запускати обидві моделі. Водночас цей процес дозволяє зберегти потужність великої моделі в той час, як та працює з більш компактною. Таким чином, значно зменшується розмір моделі та витрати ресурсів. Існує припущення, що DeepSeek використовував дистиляцію для створення моделі R1, «запозичивши» роботу OpenAI, що порушує їхні умови використання. Парадокс Джевонса (Jevons Paradox): технології, що роблять використання ресурсів ефективнішим, можуть призвести до підвищення попиту на них. Термін був уведений британським економістом Вільямом Стенлі Джевонсом у 19-му столітті, коли він помітив, що при більш ефективному використанні певних ресурсів (наприклад, вугілля на той час) попит на них може навіть зростати. В сучасному контексті, наприклад, компанія DeepSeek використала більш ефективні чипи ШІ для тренування своєї моделі, при цьому їй вдалося використати менше чипів, ніж компаніям типу OpenAI. Однак, як зазначив CEO Microsoft Сатья Наделла, це не означає, що попит на чипи знизиться, навпаки, він може зрости, оскільки нові технології стимулюють ще більше інвестицій у чипи та інфраструктуру. Відкриті ваги (Open weights): параметри моделі, які можна безкоштовно використовувати. Коли компанія випускає відкриті ваги, це означає, що будь-хто може скористатися її моделлю. Відкриті ваги — це як «розпаковані» параметри, які дозволяють працювати з моделлю, але не охоплюють саму модель або дані для її тренування. Це не зовсім те ж саме, що й «відкритий код» , коли доступні всі елементи: і код, і дані для тренування моделі. Наприклад, компанії Meta, Mistral AI та DeepSeek вже випускали відкриті ваги для своїх моделей. Мікс експертів (Mixture of Experts): модель, яка активує лише деякі частини моделі залежно від задачі, що дозволяє економити ресурси. Цей підхід дозволяє зменшити витрати на обчислювальні потужності, оскільки не всі параметри моделі працюють одночасно. Тільки деякі спеціалізовані частини (експерти) активуються в процесі роботи моделі, а решта залишаються пасивними. В результаті, з однією такою моделлю можна працювати дешевше. Альтернатива — це «щільні моделі», де всі параметри моделі працюють одночасно, і це часто призводить до значно вищих витрат обчислювальних ресурсів. Параметри (Parameters): більшість моделей ШІ складається з мільярдів параметрів, що визначають її поведінку. Кожна модель ШІ має свої параметри, які визначають, як вона буде реагувати на різні запити. Параметри «налаштовуються» під час навчання моделі знову і знову, допоки модель не виконає успішно певне завдання. Зазвичай, модель оцінюється за кількістю параметрів. Наприклад, Meta має модель Llama 405b з 405 мільярдами параметрів. Вважають що великі моделі працюють краще, але вони не завжди є оптимальними, оскільки займають більше пам’яті та потребують більше обчислювальних потужностей. Міркування (Reasoning): коли модель може «думати» більше, щоби сформулювати більш точні відповіді. Міркування — це можливість моделі не просто давати миттєві відповіді, а обробляти дані поетапно, формуючи «послідовність роздумів». OpenAI розпочала тренування моделей, щоби вони могли «міркувати» поетапно, і у своїх моделях серії o1 навіть приховує ці процеси мислення, щоб уникнути їх дистиляції. Навчання з підкріпленням на основі зворотного зв’язку від людини (Reinforcement learning from human feedback — RLHF): люди вчать моделі бути більш корисними та адекватними. Навчання з підкріпленням (Reinforcement Learning, RL) — це коли людина оцінює відповіді моделі та вказує їй, що саме потрібно змінити. Наприклад, якщо є два варіанти відповіді — один ввічливий, а інший — грубий, то людина вибирає той, що їй подобається, і ця інформація допомагає моделі підлаштовуватись під уподобання користувача. Закони масштабування (Scaling laws): чим більше параметрів і даних, тим краще працює модель. Чим більша модель, тим більше можливостей вона має. Наприклад, в мовних моделях перехід від GPT-3 до GPT-4 призвів до відкриття нових можливостей, як-от створення поезії чи розгадування загадок. Однак, існує припущення, що подальше додавання нових даних чи параметрів не дає таких значних покращень, як раніше. Обчислення під час тестування (Test-time compute): обчислювальні потужності використовуються для вдосконалення моделі під час взаємодії з користувачем. Тестування — це коли модель після навчання тестується ще більше, щоб покращити свої результати. У випадку з новими моделями OpenAI o1 цей процес використовує спеціальні обчислювальні потужності для того, щоб модель могла довше «думати», перш ніж дати кінцеву відповідь. Дані для навчання (Training data): тексти, зображення, відео тощо, що використовуються для тренування моделей ШІ. Навчання моделей на даних — це основа для того, щоби вони могли вирішувати складні завдання. Спочатку моделі вчаться передбачати текст на основі величезної кількості даних, а потім їх «шліфують» на більш конкретних наборах даних, включаючи посилене навчання з людським зворотним зв'язком, щоби зробити їх ще точнішими та кориснішими. Трансформер (Transformer): архітектура, що використовується в сучасних LLM. Метод був представлений у статті Google Attention Is All You Need (2017). Трансформери здатні ефективно враховувати контекст, що зробило їх основою для LLM. Окрім тексту, вони використовуються і для генерації зображень, а також керування роботами. Технології ШІ розвиваються шалено швидко, і ці нові терміни просто неможливо обійти. Відкриті ваги, дистиляція, розуміння та інші — ці концепти стають дедалі важливішими для розробників, і розуміння їх допоможе вам краще розбиратися в сучасних тенденціях ШІ та їхніх можливостях.