Сьогодні нічого нового не будуємо. Перевіряємо, що збудоване ціле, показуємо його людям і вчимося говорити про чужу роботу так, щоб з цього був толк.
За тринадцять уроків у твоєму ~/www/ накопичилося більше
десятка файлів. Кожен із них колись працював. Ключове слово тут —
колись.
Останні два уроки ти правив спільні стилі, переносив файли й переписував головну сторінку. Частина того, що працювало у вересні, зараз лежить зламана. І ти про це не дізнаєшся, поки не перевіриш.
Слова регресія, пітч і Demo Day поки нічого не означають — розберемо кожне тоді, коли воно знадобиться.
| Частина | Хв | Що робиш | Чим закінчується |
|---|---|---|---|
| Регресія | 25 | проганяєш перевірки уроків 1–7 разом і лагодиш червоне | вердикт «готовий до показу» |
| Аудит перед виступом | 15 | 360 px, alt, <label>, контраст, title, description, og:image | лендинг не соромно відкрити з проєктора |
| Demo Day | 50 | пітчиш 3 хв, відповідаєш на питання 2 хв, слухаєш інших | kb/demo-day.md — картка результатів |
| Зворотний звʼязок | 20 | пишеш два структуровані відгуки чужим командам | kb/feedback-given.md |
| Підсумок модуля | 10 | дивишся, з чого почав і чим закінчив | посилання в портфоліо |
kb/feedback-given.md важить стільки ж, скільки власний
лендинг. Уміння сказати чужій команді щось корисне — окрема навичка.
На роботі вона знадобиться раніше, ніж уміння верстати.
Тому за відгук «класно, все сподобалось» бал сьогодні поки не поставлять:
у ньому немає нічого, з чим інша команда могла б щось зробити. Допиши до
нього конкретику — і він зарахується.index.html,
kb/demo-day.md, kb/feedback-given.md.
Усе важке для виступу лишається на твоєму компʼютері й показується
з екрана: скріншоти, згенеровані ілюстрації, запис демонстрації.
Це те саме правило, що діяло всі чотирнадцять уроків.Перевірка не того, що ти щойно зробив, а того, що ти зробив раніше і вважаєш готовим
Регресія — це коли те, що працювало, перестало працювати після зміни в іншому місці. Регресійна перевірка — повторний прогін старих перевірок після нових змін. Вона не шукає помилок у сьогоднішній роботі: для цього є звичайна перевірка. Вона питає одне — чи не зачепив я ліктем те, що стояло поруч.
Слово «гниття» тут не для настрою. У програмуванні є усталений термін software rot. Код лежить незмінний, а працювати перестає. Бо змінюється все навколо нього: сусідні файли, шляхи, версії, дані.
Твій проєкт псується так само. Три способи зробити це ти вже випробував особисто.
| Що ти зробив | Що зламалося | Коли це помітно |
|---|---|---|
підправив колір у brand.css під новий hero | верстка brief.html: він бере той самий токен і став нечитабельним | ніколи — ти не відкривав бриф два тижні |
переніс нотатку в підтеку kb/market/ | вікі-посилання [[competitors]] у трьох інших нотатках стали битими | коли вчитель клікає посилання на захисті |
переписав report.tpl.html під новий вигляд | report.sh не знаходить плейсхолдер і генерує звіт із порожніми числами | через добу, після наступного запуску cron |
склав дані «щоб було під рукою» в ~/www/data/ | responses.csv з іменами людей віддається по HTTP кожному охочому | у найгірший момент |
Учора під новий hero ти поміняв --brand-bg у brand.css
зі світлого на темний. Лендинг виглядає чудово. Що найімовірніше вже зламано,
хоча ти цього ще не бачив?
Тому що під час виступу ти не можеш полагодити нічого, а після виступу лагодити вже пізно
Логіка тут дуже проста. Поломка існує з учорашнього вечора незалежно від того, знаєш ти про неї чи ні. Питання лише в тому, хто побачить її першим — ти за сорок хвилин до показу чи журі на екрані проєктора. У першому випадку в тебе є двадцять хвилин і термінал. У другому — тридцять секунд і сто очей.
До твого виступу пʼятнадцять хвилин. Прогін показав два червоні пункти:
kb/index.html має три биті посилання і og:image
віддає 404. Полагодити встигаєш одне. Що робиш?
У справжніх командах ніхто не сприймає червону перевірку як особисту образу. Червоне означає рівно одне: зламане знайшли раніше, ніж його побачив користувач.
У великих проєктах роблять так само, тільки без кнопки. Зміну там не накопичують тижнями, а заливають маленькими порціями — по кілька рядків за раз.
Після кожної такої порції машина сама повторює всі старі перевірки, а не тільки нову. Такий автоматичний прогін зветься безперервною інтеграцією. Твоя кнопка «Перевірити мою роботу» — та сама ідея, тільки натискаєш її ти.
Логіка та сама, що з бекапом. Бекап не означає, що ти поганий адміністратор. Він означає, що диски виходять з ладу.
Так само й регресія. Вона не про те, що ти поганий розробник. Вона про те, що між файлами є звʼязки, і людина не тримає всі їх у голові. Твої сім файлів повʼязані щонайменше девʼятьма стрілками — і це ще маленький проєкт.
Однокласник каже: «Нащо ганяти перевірки уроків 1–7? Я їх уже здав на зелене, оцінки стоять». Що з цим не так?
Так виглядає прогін check11 8 — фінальної
перевірки, яка повторює все, що ти здавав із першого уроку
Кожен рядок — окрема перевірка з окремим доказом. Доказ — це не думка системи, а конкретний вивід: код відповіді, кількість знайдених рядків, порахований коефіцієнт.
Червоний рядок каже дві речі. Що саме зламалося і на якому уроці цей файл робився. Шукати причину треба там, а не в сьогоднішньому лендингу.
Натисни «Прогнати все». Чотири пункти впадуть — так буває майже в кожного, хто два уроки поспіль правив спільні файли. Полагодь кожен і прожени повторно: внизу зʼявиться вердикт.
Демонстраційний режим: доказами тут служать типові виводи
команд, складені для уроку. На сервері ці самі дванадцять пунктів рахує
check11 8 від твого імені й пише результат
у ~/.progress/11-8.json. Стан пульта зберігається у браузері —
сторінку можна закрити.
Пульт нічого магічного не робить. Кожен його рядок — це одна команда, яку ти можеш виконати сам у своїй SSH-сесії ще до прогону.
grep -oh "\[\[[^]]*\]\]" ~/www/kb/*.md | sort -u
і звірка списку з реальними іменами файлів. Витік приватних даних:
curl -o /dev/null -s -w "%{http_code}\n" http://91.219.61.4/s/<логін>/data/responses.csv
— тут правильна відповідь 404, а не 200. Якщо 200 — файл із іменами
людей лежить у веб-корені, і це найгірший пункт із усіх дванадцяти.Пульт показав червоний пункт «контраст тексту до тла 4,22:1». Ти цей
brand.css робив на уроці 5 і тоді все було зелене. Де шукати
причину?
Регламент однаковий для всіх, таймер на екрані, після третьої хвилини зупиняють на півслові
Зупиняють не через суворість. Інакше перші три команди зʼїдають урок, а останні виступають у порожньому класі. Рівний регламент — це чесність до тих, хто виступає останнім.
Звідси практичний висновок. Перше речення має бути найважливішим, бо останнього може й не бути.
Найгірша конфігурація — обидва говорять по черзі «щоб порівну». Слухач витрачає увагу на перемикання між голосами замість змісту. Робочий розподіл виглядає так:
| Роль | Що робить під час пітчу | Що робить на питаннях |
|---|---|---|
| Голос | говорить усі три хвилини, дивиться на людей, а не на екран | відповідає першим, коротко |
| Руки | клікає, відкриває вкладки, тримає таймер у полі зору — і мовчить | показує потрібну сторінку, доповнює тільки фактами й числами |
| Якщо ти один — усе це робиш сам, тому вкладки відкриваються заздалегідь, а не під час виступу. | ||
На репетиції пітч виходить 4 хвилини 20 секунд. Треба вкластися у три. Що правильно вирізати?
Жива демонстрація — найсильніший і найризикованіший інструмент виступу одночасно
Живе завжди переконливіше за скріншот: скріншот можна намалювати, а працюючу сторінку — ні. Але саме в цю хвилину проти тебе працює все одразу.
Мережа класу тримає тридцять пристроїв. Проєктор має іншу роздільну здатність. Потрібна вкладка не відкрита. А сервер відповідає повільніше, ніж удома.
Правило вибору просте: живим показують те, що доводить головне твердження пітчу. Усе інше — на слайді.
Скажімо, твоє твердження — «дані на лендингу справжні й оновлюються самі». Тоді живим має бути саме це. Відкрив сторінку, показав число, додав відгук через форму, перезавантажив — число змінилося. А меню, кольори й підвал показувати живими не потрібно.
| Живим | На слайді (скріншот у deck.html) |
|---|---|
| відкриття лендинга з мережі за реальною адресою | процес верстки, кодова база, структура тек |
| один наскрізний сценарій користувача до кінця | усе, що вимагає більше трьох кліків |
число, яке підтягується з market.csv | таблиця з 40 рядками — її ніхто не прочитає з проєктора |
| сторінка звіту, згенерована сьогодні вночі | сам скрипт і crontab — про них розповідають словами |
| — | усе, що ти жодного разу не пробував на цьому проєкторі |
Запасний план — не ознака невпевненості, а частина підготовки. Виглядає він так, від найдешевшого до найдорожчого:
deck.html. Пʼять кадрів того самого
сценарію, зроблені вдома на спокійно працюючій сторінці. Дек лежить
на сервері й теж відкритий у вкладці.~/www/. Та сама папка на твоєму
ноутбуці: відкривається з файла й працює без інтернету. Живі дані
не підтягнуться — і про це чесно кажуть уголос.Твоє головне твердження: «звіт генерується сам щоночі, числа справжні». Мережа в класі ледь жива. Що показуєш живим?
Питання ставлять не щоб завалити, а щоб перевірити, чи стоїть за словами робота
Питання після пітчу — це не іспит на ерудицію. Журі перевіряє одне: чи ти сам робив те, про що розповідаєш. Тому найкращі відповіді однакові за формою — факт із твого проєкту плюс місце, де його можна перевірити. Три речення, не більше.
| Питання | Слабка відповідь | Сильна відповідь |
|---|---|---|
| Звідки це число? | «Ми приблизно порахували» | «З data/market.csv: 42 відповіді, зібрані з 3 до 10 жовтня. Ось сторінка аналітики, число рахується на льоту» |
| Чому саме ви це зробите? | «Ми дуже мотивовані» | «За два місяці ми вже опитали 42 людини, зібрали робочу форму й звіт. Ми не плануємо — воно вже працює за цією адресою» |
| Хто ваш конкурент? | «У нас немає конкурентів» | «Найсильніший конкурент — звичка нічого не робити: люди просто стоять у черзі. Із сервісів — шкільний чат, там теж домовляються» |
| Скільки це коштує? | «Ну, сервер недорогий» | «Постійні витрати 5,87 $ на місяць, за маржі 2 $ це 3 продажі, щоб вийти в нуль. Число з калькулятора уроку 1, лежить у analytics.html» |
| Що у вас не вийшло? | «Та все вийшло» | «Перша форма мала 11 полів — її заповнили двоє з двадцяти. Скоротили до 4, дійшло 14 відповідей» |
| Питання, відповіді на яке ти не знаєш | вигадати на місці | «Не знаю. Перевірю за responses.csv і скажу до кінця дня» |
Числа у стовпці «сильна відповідь» — приклад формату,
а не твої дані. У тебе будуть свої, з твого market.csv
і твого калькулятора.
Журі: «Ви кажете, що вашою формою скористалися 14 людей. Скільки з них — не ваші однокласники?» Ти цього не рахував. Найкраща відповідь?
Проєкт без жодної невдачі означає одне з трьох: не пробували, не помітили або приховують
Коли команда каже «у нас усе вийшло», досвідчений слухач чує не успіх, а відсутність перевірки. Будь-яка гіпотеза про людей — «їм це потрібно», «вони заповнять форму», «вони зрозуміють кнопку» — розбивається об реальність щонайменше раз. Якщо не розбилася жодного разу, гіпотез просто не перевіряли.
Розповідь про невдачу — це не самокритика і не вибачення. Це доказ, що ти працював із реальністю, а не з уявою. Тому формулюють її не як зізнання, а як ланцюг із чотирьох ланок:
| Звучить як | Що чує журі |
|---|---|
| «У нас усе вийшло» | нічого не перевіряли на живих людях |
| «Нам не вистачило часу» | не планували; часу не вистачає всім |
| «Ідея класна, просто люди не зрозуміли» | звинувачують користувача — виправляти нічого не будуть |
| «Форма на 11 питань не працює: дійшли 2 з 20. Скоротили до 4 — стало 14 з 20» | команда вміє помічати провал і переробляти |
Ти хочеш вставити в пітч блок про невдачу. Який із варіантів спрацює найкраще?
Відгук — це не оцінка. Це інформація, з якою автор може щось зробити завтра вранці
Перевірка проста: чи може автор після твоїх слів зробити конкретну дію. «Класно, мені все сподобалось» — дії немає.
А тепер інший відгук. «У секції numbers число підтягується
з CSV — я оновив дані у себе й побачив, як воно змінилося». Тут дія є.
Автор тепер знає, що ця частина працює, і не викине її під час наступної
правки.
Різниця між двома цими відгуками зводиться до трьох речей. Ось вони — за ними ж перевіряй і власний текст, перш ніж надсилати.
roadmap»; не «дизайн», а «контраст підпису під діаграмою».
Якщо не можеш назвати місце — ти говориш про враження, а не про роботу.<img> порожній alt» — можна, за пʼять хвилин.market.csv — найсильніше місце пітчу,
наступного разу він її спокійно спростить «щоб не морочитись».
Похвала без назви місця («молодці, круто») цієї роботи не робить —
вона нічого не зберігає.kb/feedback-given.md. Праворуч — чотири
найпоширеніші способи витратити чужі дві хвилини даремно.Команда показала лендинг, де вся аналітика — картинка, вставлена замість живих даних. Ти це помітив. Як сказати?
Найдорожча помилка автора — витратити дві хвилини зворотного звʼязку на пояснення, чому так вийшло
Перше бажання, коли чуєш зауваження, — пояснити. «У нас не було часу», «це тимчасово», «ти не так зрозумів». Виглядає це безневинно, а робить одразу дві погані речі.
Перша: воно зʼїдає час, який тобі виділили на слухання. Друга: воно показує людині, що говорити далі немає сенсу. Другого зауваження від неї ти вже не почуєш — а воно могло бути найціннішим.
| Крок | Що робиш | Фраза |
|---|---|---|
| 1 | дослухуєш до кінця, не перебиваєш | — |
| 2 | перепитуєш, якщо не зрозумів, про що саме йдеться | «Правильно розумію: ти про підпис під діаграмою, а не про саму діаграму?» |
| 3 | записуєш дослівно, не переформульовуючи | — |
| 4 | дякуєш і йдеш далі, не сперечаючись | «Дякую, записав» |
| 5 | потім, уже без глядачів, вирішуєш, що з цим робити | — |
Ключове — пункт 5. Ти не зобовʼязаний виконувати кожен відгук: частина порад суперечить одна одній, частина — про смак, частина просто помилкова. Ти зобовʼязаний тільки зрозуміти й записати. Рішення лишається за тобою, і «подумав і не роблю, ось чому» — цілком нормальна відповідь.
kb/demo-day.md — це той самий
формат Markdown із front-matter, що й решта твоєї бази знань.Тобі кажуть: «Кнопка “Залишити відгук” губиться, я її не знайшов». Ти впевнений, що кнопка на видноті — просто людина неуважна. Що робиш у цю секунду?
Спершу вибираєш, що сказати, з чотирьох варіантів — потім пишеш свій і перевіряєш його на конкретність
Кожен випадок — реальна ситуація Demo Day. Прочитай опис, обери репліку. Після вибору відкриються всі чотири з розбором. Ти побачиш, який із них конкретний, який загальний, який образливий і який просто не по суті. Правильний варіант завжди один, але помилки тут корисніші за влучання.
Ти вже сказав команді, що в них їде верстка на телефоні. Друга команда після тебе каже те саме. Автор відповідає: «та ні, у мене на телефоні все нормально». Що це означає для автора?
Пиши так, ніби автор прочитає це завтра без тебе поруч. Бо так
і буде: kb/feedback-given.md лишається в базі знань.
Сторінка перевірить три речі. Чи названо конкретне місце. Чи є справжнє питання. І чи немає оцінних ярликів. Коли зберуться два відгуки, вона складе готовий файл.
Перевірка конкретності тут груба: сторінка шукає назву місця, знак питання й оцінні ярлики. Вона не вміє оцінити, чи відгук розумний — це зробить людина, якій ти його даси. Стан обох тренажерів зберігається у браузері.
kb/feedback-given.md має front-matter із title,
tags і date — рівно як нотатки уроку 7,
інакше kb/index.html його не підхопить, а перевірка бази
знань почервоніє. Файл текстовий, кладеться по FTP у ~/www/kb/
і зберігається в UTF-8.Виконуй по черзі. Галочки зберігаються — сторінку можна закрити й повернутися після виступу.
~/www/ їдуть три текстові файли:
фінальний index.html, kb/demo-day.md
і kb/feedback-given.md. Скріншоти й записи демонстрації
на сервер не заливаються — учитель дивиться їх з твого екрана.check11 8, друга частинаТі самі дванадцять пунктів, що в пульті, згорнуті у вісім критеріїв оцінки. Спроби не обмежені — але останній прогін має бути до твого виступу.
Команда та сама, що й на уроці 13: перевірка check11 8 одна
на два уроки. Там вона дивилася на лендинг і team.html — це була
перша частина. Сьогодні до неї додається регресія тем 1–7: перевірка обходить
усе, що ти здавав раніше.
Демонстраційний режим: результат згенеровано для показу.
На сервері ця кнопка запускає check11 8 від імені учня
і читає ~/.progress/11-8.json.
regression_1_7 і наскрізний no_media блокують
оцінку. Перший — тому що «лендинг гарний, а бриф лежить» не є готовим
продуктом. Другий діє з першого уроку: у ~/www/
і ~/upload/ не має бути .mp4 .mov .avi .mkv .webm
.mp3 .wav .flac і файлів понад 2 МБ.http://91.219.61.4/s/<логін>/, а не з локального файла —
видно в адресному рядку;market.csv, tasks.json
і агрегату відгуків;kb/demo-day.md і твої записи
зауважень, зроблені під час чужих виступів;Прогін показав: 11 пунктів зелені, червоний один — brief.html
віддає 500 після твоїх учорашніх правок. Лендинг при цьому бездоганний.
Яка оцінка виходить за логікою check11 8?
Це те, що бачить учитель, коли виставляє оцінку.
| Складник | Вага | Результат |
|---|
index.html, який ти створив
на першому уроці порожнім, сьогодні відкривають із проєктора.На першому уроці ти вперше набрав ssh і побачив рядок
запрошення, який нічого не пояснював. Питання тоді були приблизно такі.
Чому папка називається www? Чому Index.html —
це не той самий файл, що index.html? І навіщо комусь три
цифри в правах доступу?
Сьогодні за цією адресою працює твій продукт. Ось із чого він складається.
Лендинг, де числа тягнуться з файлів, а не вписані руками. Сторінка
аналітики з маржею й точкою беззбитковості. Айдентика, зібрана на
токенах brand.css.
База знань із нотаток, повʼязаних між собою. Форма, яка приймає відгуки від живих людей. І звіт, який щоночі переписує себе сам, за розкладом cron. Плюс дванадцять перевірок, які скажуть тобі, що саме з цього зламалося.
| Було на уроці 1 | Є на уроці 14 |
|---|---|
порожня тека ~/www/ | сімнадцять повʼязаних файлів, кожен із них хтось відкриє |
| «сайт» — це коли красиво | сайт — це адреса, код відповіді, дані й людина, яка ним користується |
| числа беруться з голови | числа беруться з market.csv і перевіряються |
| помилку шукають очима | помилку шукає перевірка, а ти читаєш доказ |
| «я зробив, здав, забув» | «я зробив, і воно досі працює — я щойно перевірив» |
Найважливіше тут — не список технологій. Найважливіші дві звички. Перша: прогнати перевірки до того, як роботу побачать інші. Друга: сказати про чужу роботу щось конкретніше за «класно».
Інструменти за кілька років зміняться. Ці дві звички лишаться при тобі. А адресу свого продукту клади в портфоліо — сторінка працює й після уроку.
check11 8 ще раз і додати
рядок у CHANGELOG.md: що зогнило за тиждень
і що ти з цим зробив. Проєкт, який ніхто не чіпає, теж гниє —
просто повільніше.Усе, що можна перевірити, має посилання. Решта підписана як приклад або як правило нашого курсу.
alt і що в ньому писати —
MDN · <img>og:title, og:image —
ogp.mecurl -o /dev/null -s -w "%{http_code}" — як дістати
лише код відповіді —
curl.se · manpageКоефіцієнт контрасту 4,22:1 у пульті регресії порахований
автором сторінки за формулою WCAG для пари #6E7A86
на #101418 — це приклад того, як «трохи світліший сірий»
виводить сторінку за межу 4,5:1. Усі виводи команд у пульті, числа
відгуків, суми витрат і назви команд — навчальні приклади, складені
для цього уроку: на твоєму акаунті вони будуть свої. Регламент
«3 хвилини пітчу + 2 хвилини питань», ваги оцінки і формула відгуку
«сильне — питання — пропозиція» — правила нашого курсу, а не галузевий
стандарт. Повний список джерел із поясненнями —
у файлі urok-14-джерела.md поруч із цією сторінкою.