IT-професії майбутнього і збірка лендинга

Сьогодні ти збираєш усе, що зробив за модуль, в одну сторінку

Тема 8 · урок 1 з 2 · передостанній урок модуля · 120 хвилин

Дванадцять уроків ти складав продукт по частинах. Бриф, дані ринку, економіка, айдентика. Потім пітч, база знань, беклог, форма відгуків і автозвіт. Кожна з цих частин лежить у ~/www/ окремим файлом.

Сьогодні вони вперше стають одним лендингом. Це та сторінка, яку побачить людина, що прийшла за адресою твого продукту. Про сам продукт вона не знає нічого.

На першому уроці ти завів index.html порожнім каркасом із трьома секціями. Сьогодні він наповнюється. Не переписується з нуля, а добудовується.

Різниця тут не косметична. За сторінкою, яку збирали 13 уроків, стоять твої власні дані. За сторінкою, зверстаною за вечір, — нічого.

Після уроку ти вмієш

• розказати про вісім ролей у команді продукту: що людина в кожній ролі робить у понеділок о 9:40;
• показати на своїх власних файлах, роботу якої ролі ти вже виконував;
• писати заголовок сторінки, після якого за пʼять секунд зрозуміло, що це й для кого;
• збирати index.html із семи секцій на спільному brand.css, без жодного мертвого посилання;
• ставити на сторінку числа, які вона сама забирає з market.csv, tasks.json і звіту, а не вписані руками.

Слова hero, соціальний доказ і fetch поки нічого не означають — розберемо кожне тоді, коли воно знадобиться.

Хід уроку

Вісім ролей: понеділок, 9:40

Не «займається розробкою програмного забезпечення», а що людина реально відкриває на екрані в перші пів години робочого дня

Означення професій нічого не пояснюють: у них усі слова однакові. Різницю видно тільки в роботі. Що людина відкриває, кого питає, що віддає далі. І за що з неї спитають, коли зламається.

У таблиці стоять слова, яких ти ще не зустрічав. Розберемо їх по черзі. Майже кожне виявиться тим, що ти вже робив руками, тільки названим інакше.

База даних — програма, яка зберігає рядки й швидко знаходить потрібні. Твій ~/data/responses.csv — та сама ідея, тільки в одному файлі й без пошуку. Коли рядків стає мільйон, файлом уже не обійтися.

Питання до бази ставлять не мишкою, а текстом: «покажи всі відгуки з оцінкою нижче 3 за минулий тиждень». Мова, якою пишуть такі питання, зветься SQL. Ти робив те саме командою awk по CSV.

Сирі відповіді аналітик нікому не показує. Він робить дашборд — одну сторінку, де кілька графіків оновлюються самі. Твій report.html з уроку 12 — це найпростіший дашборд.

А конверсія в його рядку — це частка відвідувачів, які зробили те, чого від них чекали. Зайшло двісті людей, форму заповнили шестеро — конверсія 3%. Наступного дня при тих самих двохстах заповнили троє: конверсія впала вдвічі, і треба шукати чому.

Дизайнер малює екрани не в редакторі на своєму компʼютері, а у Figma. Вона працює прямо в браузері, тому макет можна відкрити вдвох одночасно. Розробник бере з нього точні розміри й кольори, а не міряє на око.

Щоб екрани не розʼїжджалися, кольори, шрифти й відступи записують один раз в окремий файл. Такий набір спільних домовленостей зветься дизайн-системою, а одне записане в ній значення — токеном. Твій brand.css із рядками var(--brand-…) — це вона і є, у мініатюрі.

API — адреса, за якою по дані приходить не людина, а програма. Замість сторінки вона забирає голі числа. Твій ~/www/data/feedback-stats.json — найпростіший API, який буває: одна адреса, два числа.

git памʼятає історію файлів: хто, коли і що змінив. Якщо сьогоднішня правка все зламала, вчорашню версію повертають однією командою. Тека «лендинг_фінал_3» після цього не потрібна.

DevTools — панель, яка відкривається в браузері клавішею F12. У ній видно розмітку сторінки, помилки в консолі й кожен запит до сервера. Туди заглядають першими, коли сторінка виглядає не так, як задумано.

Автотести — програма, яка натискає кнопки замість людини й звіряє результат з очікуваним. Сто перевірок вона проганяє за хвилину. Людина руками — за день, і на пʼятдесятій втрачає увагу.

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

Саме таке викладання нової версії й називають деплоєм. Якщо після деплою все посипалося, DevOps відкочує версію: повертає на сервер попередню, ту, що працювала. Тому це швидко — три хвилини, а не переписування коду.

А моніторинг — служба, яка щохвилини сама відкриває твій сайт і перевіряє, чи він відповідає. Не відповів двічі поспіль — DevOps дістає повідомлення о третій ночі. Саме тому uptime з уроку 1 узагалі є що рахувати.

Головний хід уроку: ти вже пробував шість ролей із восьми

«Професії майбутнього» — незручна назва теми: те, про що йдеться, ти робив руками останні три місяці

Про IT-ролі зазвичай розповідають як про далекий вибір: колись, після школи, треба буде щось обрати. Але робота ролі — це не диплом, а набір дій.

І майже кожну з цих дій ти вже виконував. Масштаб був інший, зарплати й замовника не було. Але сама робота — та сама.

Картка ролей: не «ким бути», а «що з цього було не в тягар»

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

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

Що змінює автоматизація і як через це обирати

Обережно: нижче немає передбачень. Є те, що вже видно, і те, чого ніхто не знає

Правило, яке діяло весь модуль: AI пише чернетку — ти перевіряєш, правиш і відповідаєш за результат. Це і є коротка відповідь на питання «чи замінить ІІ програмістів».

Зникає не робота, а її склад. Менше набирання тексту. Більше постановки задачі, перевірки й відповідальності за наслідки.

Перевір на власному досвіді. На уроці 12 ІІ міг написати тобі report.sh за двадцять секунд. А ось три речі довелося зробити тобі. Вирішити, що середній рейтинг рахується без тестових рядків. Помітити, що «Експорт» і «експорт» — та сама функція. І перевірити три рядки вручну.

Робота не зникла. Вона перемістилася з набирання на перевірку.

Що росте, а що змінюється

Нижче — не пророцтво, а прогноз статистичного бюро. Він показує, скільки робочих місць у цих групах професій очікують у США за 2023–2033 роки. Країна інша, ринок інший, та й прогнози регулярно не збуваються. Читай це як напрям стрілки, а не як обіцянку.

Джерело — Бюро статистики праці США, розділ Occupational Outlook Handbook; посилання в секції «Джерела». Всесвітній економічний форум у звіті Future of Jobs 2025 оцінює: до 2030 року зміняться близько 39 % ключових навичок працівників. Це і є головна цифра розділу. Вона каже не «професії зникнуть», а «зміст професій поїде».

Як обирати, щоб не обирати навмання

1. Дивись на дію, а не на назву. «Хочу бути продактом» — це назва. «Мені подобається вирішувати, що робити першим, і сперечатися про це» — це дія, яку можна перевірити вже цього тижня.
2. Перевіряй, що подобається на третій раз. Перша палітра — цікаво завжди. Питання в тому, чи цікаво доганяти контраст до 4,5:1 впʼяте.
3. Мода — найгірший критерій. Коли ти вийдеш на ринок, модною буде інша роль: між твоїм вибором і першою роботою — роки, а хвиля живе коротше.
4. Роль не назавжди. Перехід «QA → розробник», «аналітик → продакт», «підтримка → QA» — звичайний шлях, а не поразка.
5. Одна навичка спільна для всіх восьми ролей — вміти поставити задачу словами й перевірити результат. Ти тренував її щоуроку, коли працював з AI-редактором.

Перші пʼять секунд: що людина встигає зрозуміти

Лендинг оцінюють не так, як твою роботу оцінює вчитель. Його не читають — його швидко переглядають і закривають

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

Другий. Більшість відвідувачів ідуть зі сторінки в перші 10–20 секунд. Лишаються тільки ті, хто за цей час побачив чітко названу користь для себе.

Звідси єдина вимога до верхньої частини сторінки. За пʼять секунд і без прокрутки має бути зрозуміло що це, для кого і що тут робити. Усе інше — докази, дорожня карта, команда — нижче, для тих, кого зачепило.

Заголовок, який пояснює, проти заголовка, який інтригує

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

Сім секцій і звідки взявся кожен блок

Нічого нового писати не треба: майже все вже лежить у ~/www/ з попередніх уроків

Лендинг — не ще один документ поруч із дванадцятьма попередніми. Це вхід до них: коротко головне, а деталі — посиланням на сторінку, яку ти вже зробив. Тому робота сьогодні здебільшого не «написати», а «дістати, скоротити й зшити».

Три способи потрапити на лендинг

Третій спосіб із таблиці — живі дані — тримається на трьох джерелах, по одному на секцію. Перше джерело — data/market.csv з уроків 3 і 4. Секція numbers бере з нього кількість потенційних користувачів і складає її вже під час відкриття сторінки.

<section id="numbers">
  <h2>Ринок і економіка</h2>
  <p>Потенційних користувачів у сегментах: <b id="n-users">—</b></p>
</section>

<script>
fetch('data/market.csv')
  .then(r => { if (!r.ok) throw new Error(r.status); return r.text(); })
  .then(text => {
    const rows = text.trim().split('\n').slice(1);        // без заголовка
    const users = rows.reduce((s, line) => s + Number(line.split(',')[1] || 0), 0);
    document.getElementById('n-users').textContent = users.toLocaleString('uk-UA');
  })
  .catch(() => {
    document.getElementById('n-users').textContent = 'дані тимчасово недоступні';
  });
</script>

Друге джерело — твій власний звіт. report.html уже лежить поруч і оновлюється сам за cron. Щоб дістати з нього числа, познач їх у bin/report.tpl.html ідентифікаторами — і лендинг прочитає готову сторінку як документ:

<script>
fetch('report.html')
  .then(r => { if (!r.ok) throw new Error(r.status); return r.text(); })
  .then(html => {
    const doc = new DOMParser().parseFromString(html, 'text/html');
    const val = id => (doc.getElementById(id) || {}).textContent || '—';
    document.getElementById('f-count').textContent = val('r-count');   // скільки відгуків
    document.getElementById('f-avg').textContent   = val('r-avg');     // середня оцінка
  })
  .catch(() => { document.getElementById('f-count').textContent = '—'; });
</script>

Третє джерело — data/tasks.json з уроків 9 і 10. Секція roadmap читає його тим самим fetch і показує, скільки задач із карти вже зроблено. Код майже не відрізняється: інше імʼя файлу й інші поля, з яких беруться числа.

Збирач лендинга: що в тебе вже є і що з цього вийде

Відміть артефакти, які реально лежать у ~/www/. Нижче збереться каркас майбутньої сторінки — з попередженнями про порожні місця й готовим кодом

Відмічай чесно: не «я збирався зробити», а «файл лежить на сервері й відкривається за посиланням». Збирач не знає, що в тебе на сервері, — він показує наслідок твоїх галочок. Якщо позначити все підряд, він видасть красивий каркас із мертвими посиланнями, і на уроці 14 це побачить автоперевірка.

team.html: ролі, потрібні продукту, і чесна позначка своєї

Сторінка про команду — не про кількість людей, а про те, яка робота в продукті існує і хто її зараз робить

Інвестор, учитель і будь-яка доросла людина дивляться твій проєкт із двома питаннями в голові. Перше: чи розумієш ти, з чого складається робота над продуктом. Друге: що з цього ти справді робиш сам.

Саме сторінка команди й відповідає на обидва. Друге питання важливіше — на ньому шкільні проєкти падають найчастіше.

Чому чесність тут вигідніша за «команду з десяти людей»

• Питання ставлять точкові. «Хто з них писав скрипт звіту?» — і вигадана команда розсипається за одне речення.
• Разом із командою знеціняться й реальні числа. Якщо вигадана людина, під сумнівом і твої 4,6 із 5, і обсяг ринку — а вони справжні.
• «Роблю сам» — це сильна позиція, а не слабка. Один учень, який зробив дані, дизайн, форму й автозвіт, — це достатньо, щоб на це дивилися серйозно.
• Порожня роль показує зрілість. «Бекенду немає, тому відгуки поки в CSV, і при 500 відгуках це перестане працювати» — це діагноз власного продукту.

<article class="role">
  <h2>Аналітик</h2>
  <p class="what">Готує дані ринку, рахує юніт-економіку і стежить,
     щоб кожен висновок на лендингу спирався на число з market.csv.</p>
  <ul class="skills">
    <li>чистка й перевірка CSV</li>
    <li>зведені таблиці та вибір діаграми під питання</li>
    <li>маржа й точка беззбитковості</li>
  </ul>
  <!-- позначка своєї ролі: її шукає автоперевірка -->
  <p class="me">Цю роль виконую я — Данило К., 11-А</p>
</article>

Збірка з частин: один brand.css, одна навігація, нуль мертвих посилань

Девʼять сторінок стають продуктом тоді, коли в них спільні кольори, спільна навігація й жодного посилання на 404

У тебе в ~/www/ накопичилося девʼять сторінок, зроблених у різні тижні й у різному настрої. Сьогодні вони мають виглядати як один сайт. Для цього потрібні рівно три речі: спільні кольори, спільна навігація й перевірені посилання.

1. Кольори тільки в одному файлі

Правило з уроку 5 тепер стає технічною вимогою. У власному CSS лендинга не має бути «сирих» кольорів на кшталт #0b7285. Усе йде через var(--brand-…).

Причина не в естетиці. На Demo Day ти вирішиш, що акцент занадто блідий. Один рядок у brand.css має перефарбувати всі девʼять сторінок. А якщо кольори розповзлися по файлах, правити доведеться девʼять місць — і два ти забудеш.

2. Навігація однакова на всіх сторінках

Один і той самий блок посилань угорі кожної сторінки. Людина, яка відкрила analytics.html із пошуку, має за один клік потрапити на головну. Порядок посилань теж однаковий — інакше сторінки виглядають як чужі одна одній.

3. Перевірка посилань перед здачею

Перевіряй у SSH-сесії на сервері, а не у PowerShell на своїй машині. Причина проста: у Windows PowerShell 5.1 curl — це інше імʼя команди Invoke-WebRequest. Ключі справжнього curl там не працюють. А на сервері один рядок перевіряє всі сторінки одразу.

А цей рядок покаже, куди насправді веде кожне посилання з лендинга — зокрема ті, які ти встиг забути:

Приклади виводу складені як типові для навчального сервера — на твоєму акаунті список буде свій.

Чек-лист перед здачею

Це вже портфоліо

Портфоліо — не «колись потім». Це посилання на працюючу сторінку, за яким видно, що людина довела справу до кінця. У тебе воно вже є. Сайт відкривається з мережі за постійною адресою. Дані в ньому справжні. А історія роботи лежить у CHANGELOG.md і теці kb/.

Практика: збираємо лендинг і пишемо team.html

Виконуй по черзі. Галочки зберігаються — сторінку можна закрити й повернутися.

Автоперевірка check11 8, перша частина

Система робить реальний запит на твій сабдомен і читає розмітку. Далі вона обходить усі посилання. А потім підміняє значення в джерелі даних — щоб побачити, чи сторінка справді жива. Спроби не обмежені.

Демонстраційний режим: результат згенеровано для показу. На сервері ця кнопка запускає check11 8 від імені учня і читає ~/.progress/11-8.json.

Що вчитель дивиться на екрані

• DevTools, вкладка Network: чи справді йдуть запити до market.csv, tasks.json і звіту — і що відповідає сервер;
• вигляд у 360 px: немає горизонтального скролу, кнопка в hero не виїжджає за екран;
• team.html: ти показуєш свою позначку і вголос кажеш, яку роль виконуєш і чого в команді немає;
• будь-які згенеровані ілюстрації для hero — вони лишаються на твоїй машині й на сервер не заливаються.

Шкала виконання

Це те, що бачить учитель, коли виставляє оцінку.

Домашнє завдання

1. Довести лендинг до стану «усі сім секцій наповнені реальним змістом»: під кожним заголовком є текст, а не порожнє місце.
2. Прогнати чернетку пітчу на 3 хвилини вголос із секундоміром по deck.html — і скоротити те, що не вкладається.
3. Дописати в ~/www/kb/ нотатку my-role.md: яку роль ти виконував у продукті, що з цієї роботи сподобалося, а що ні, і чому. Три-чотири речення, чесно.

Звідки взяті факти й числа

Кожне число, яке ти можеш перевірити, має посилання. Прогнози ринку праці позначені окремо: це прогнози, а не факти.

• Враження про сторінку формується приблизно за 50 мілісекунд — експеримент Ліндґаард та ін., Behaviour & Information Technology, 2006. tandfonline.com · Attention web designers: you have 50 milliseconds
• Більшість відвідувачів ідуть зі сторінки в перші 10–20 секунд; затримуються ті, кому за цей час показали чітку користь — Nielsen Norman Group. nngroup.com · How long do users stay on web pages?
• Люди не читають сторінку, а переглядають її; F-подібний патерн і «десять слів, які прочитають напевно» — Nielsen Norman Group. nngroup.com · F-shaped pattern, nngroup.com · How users read on the web
• Прогноз зайнятості 2023–2033 у США: data scientists +36 %, фахівці з інформаційної безпеки +33 %, розробники ПЗ разом із QA-аналітиками й тестувальниками +17 %, веброзробники й цифрові дизайнери +8 %, фахівці підтримки користувачів +6 %, усі професії разом +4 % — Бюро статистики праці США, Occupational Outlook Handbook. bls.gov · Computer and Information Technology Occupations, bls.gov · Employment Projections. Це прогноз для ринку США, а не для України, і прогнози переглядаються щороку.
• До 2030 року зміниться близько 39 % ключових навичок працівників — World Economic Forum, Future of Jobs Report 2025. weforum.org · Future of Jobs Report 2025
• Більшість розробників уже користуються ІІ-інструментами або планують це, але довіра до точності відповідей значно нижча за поширеність — щорічне опитування Stack Overflow. survey.stackoverflow.co · AI section
• Опис ролей у продуктовій команді: продакт-менеджер відповідає за «що і навіщо», проєктний — за «як і коли» — довідник професій і опис ролі. atlassian.com · What is a product manager, bls.gov · Software developers, QA analysts, and testers
• DevOps і SRE як окремі ролі; що робить інженер надійності — відкрита книга Google. sre.google · Site Reliability Engineering, вступ
• Семантичні секції, <section> з id, заголовки без стрибків рівнів — MDN. developer.mozilla.org · section, developer.mozilla.org · h1–h6
• fetch, перевірка response.ok і те, що мережева помилка й код 404 обробляються по-різному — MDN. developer.mozilla.org · Using the Fetch API
• DOMParser: розбір готового HTML як документа — MDN. developer.mozilla.org · DOMParser
• Контраст тексту не нижче 4,5:1 — WCAG 2.2, критерій 1.4.3. w3.org · Contrast (Minimum)
• Мета-теги Open Graph для превʼю посилання — специфікація. ogp.me
• Коди відповіді 200, 403, 404 — RFC 9110, розділ 15. datatracker.ietf.org · RFC 9110
• У Windows PowerShell 5.1 curl — псевдонім Invoke-WebRequest, а не справжній curl — документація Microsoft. learn.microsoft.com · Invoke-WebRequest

Приклади виводу команд (коди 200 і 404, список посилань), назва продукту «Розклад гуртків», числа у плашках доказів і картки в team.html складені як типові навчальні приклади — на твоєму акаунті вони будуть свої. Відсотки в картці ролей рахуються за формулою, описаною прямо під нею, і не є психологічним тестом. Повний список джерел із поясненнями — у файлі urok-13-джерела.md поруч із цією сторінкою.