#партнерський_допис
Хотіли дізнатися, що у LLM під капотом? Чим визначається їхня "поведінка"? На які метрики звертати увагу для визначення якості та потенціалу різних моделей, і як застосовувати ці знання для створення надійних, керованих і масштабованих рішень?

Fwdays Academy запрошує на воркшоп Deep Dive into LLM APIs від Олександра Краковецького!

Навчіться працювати з LLM як з інструментом: інтегрувати, конфігурувати та будувати повноцінні технічні рішення на їх основі.

Коли: 15 та 16 грудня, 18:30–21:00
Де: Онлайн, Zoom (запис буде доступний)
Реєстрація та деталі: https://bit.ly/4irJPbP

ПРОМОКОД НА 10%: Babich

Ментор: Олександр Краковецький, AI Expert, CEO в DevRain, CTO в DonorUA, автор книг про генеративний штучний інтелект.

Почніть впевнено працювати з LLM APIs разом з Fwdays Academy!

P.S. 100% коштів за розміщення допису спрямовано на потреби ЗСУ.

То який же він — розробник майбутнього? Відео вже доступне.

Приємного перегляду!

https://www.youtube.com/watch?v=oyswnHaq_3E

Не забудьте душнити в чаті ;)

Запостив я отакий шорт на ютубі в підтримку останнього відео і отримав у коментарях наступний діалог:

Коментатор: а в кінці місяця, без тікетів , вирішити хто працював ,а хто штани протирав?
Я: Бгггг. Чи це серйозне питання було?)
Коментатор: так серйозне,валідую інформацію. а чому це так вас дзивувало? я не айтівець, але бачив відео що стікери портібні. читав жарти що сеньйор без стікера не працбє)

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

***
Тут як. Колись дійсно тікети в джирі багато хто використовував для обліку робочого часу. Я сам таку практику застав. Відверто — це херня. Бо це нічого не дає, крім можливості підкручувати собі години.

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

Це дозволяє уникати непорозумінь "а чому це і це не зроблено? а чому це і це зроблено так?". Бо в такому випадку є джерело правди, з яким мають бути ознайомлені усі учасники робочого процесу. Тобто коли умовний менеджер починає шось там вимахуватись, перед ним ставиться аргументу — "ти бачив документ до початку роботи". Така собі страховка.

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

Але в даному фрагменті мається дещо інше на увазі. Тут Артем казав про ситуацію, коли ми маємо безініціативного виконавця, який ніби й буде робити задачу, але тільки тоді, коли ХТОСЬ інший ЙОМУ зробить тікет. Вирішить за нього усі питання, уточнить незрозумілості, і на тарілочці подасть фінальний документ. І аж тоді наш програміст підніме дупцю і піде шось там кодірувать.

Колись такий підхід працював. Зараз — не дуже. Чому? Бо нам потрібна відчутно менша за розміром команда ініціативних людей, які можуть самостійно розібратися в домені, контексті задачі, які можуть самотужки налагодити потрібну комунікацію, які можуть керувати невизначеністю. На противагу команді видатних кодогенераторів, які пальцем не ворухнуть, поки їх не натицяють носом в усе готове.

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

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

Якось так.

***
Ви вже подивилися це відео? Це просто відвал сраки, наскільки воно вийшли цікаве та круте.
https://www.youtube.com/watch?v=oyswnHaq_3E

Таска в жирі — страва традиційної айтішної кухні. Може мати шкідливий вплив на тиск та призводити до передчасного вигоряння.

Рецепти є різні — від ситного наїдку з описом, естімейтами, коментарями і навіть фігмою до пісної таски, у яку додають лише сухий тайтл.

Іноді повну миску тасок в жирі ще називають беклогом.

#html_in_action
Автодоповнення списків використовується в користувацьких інтерфейсах давно. Проте в більшості випадків для цього застосовуються кастомні, доволі складні компоненти. Але в HTML5 існує нативний елемент, який забезпечує такий функціонал без JavaScript, виключно засобами HTML.

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

Виглядає це так:

<label for="city">Місто</label>
<input list="cities" name="city" id="city"/>

<datalist id="cities">
  <option value="Київ" />
  <option value="Львів" />
  <option value="Харків" />
  <option value="Одеса" />
</datalist>

На відміну від select, datalist не обмежує вибір, а лише підказує наявні співпадіння. Користувач же може ввести довільне значення у поле вводу. На валідацію datalist теж не впливає.

При виборі елемента списку в інпут буде підставлено значення з атрибуту value і викликано стандартні події поля вводу, тому немає технічної можливості дізнатися, як саме значення було введено.

Одним з очевидних недоліків використання datalist є його закрита інтеграція в бравзер: ми не можемо впливати ані на його поведінку, ані на зовнішній вигляд списку підказок, коли він показується. Хоча, дивлячись на те, як цього року реалізували стилізацію нативних селектів, я маю обережний оптимізм і щодо datalist.

Перевага ж очевидна — це швидке, нативне рішення, яке не потребує підключення стороннього коду для відображення підказок, і якщо ваша форма не є складною, і для вас головне, щоб вона була максимально простою та ефективною в імплементації — datalist є беззаперечним вибором.

Щодо відмінності поведінки в бравзерах, тут, звичайно, доведеться прийняти стан справ як є.

Наприклад, Chromium та Webkit бравзери зараз покажуть і значення з атрибуту value, і текст між тегами option у випадайці. А от Firefox покаже лише підпис. Взагалі, саме у Firefox datalist має доволі обмежену імплементацію. До прикладу, логіка пошуку по списку суттєво відрізняється, якщо у option є і атрибут value і текст.

Тому треба враховувати, який саме досвід ви хочете надати користувачу: якщо це усі можливі свистілки і перділки, то доведеться тягнути якесь стороннє рішення на купі дівів. Якщо ж мета просто показати список підказок, то datalist задовольняє цю потребу майже на 100%.

Ну або вішайте табличку "Найкраще працює в Chrome/Edge", ми це вже проходили.

Що почитати:
MDN: <datalist>

Що почитати душнілам:
HTML Living Standard — <datalist>

@babichdev

P.S. Якщо не поставите вогник чи серденько — я дуже засмучусь. Ви ж не хочете, аби я засмутивсь? Правда? ПРАВДА?

#анонс
Товариство, тут в четвер буде просто зашкалююча концентрація крутості на одному стримі )

Я йду в гості на ютуб, до Сергія Немчинського. Ви тільки погляньте, в якій компанії проведемо час: будуть і Артем Биковець, і Ілля Климов! Згадаємо, яким був IT-2025 — що здивувало, що дратувало, що смішило. Трішки зазирнемо в 2026-й, поділимось відчуттями, прогнозами й думками.

Одним словом — потеревенимо. Приходьте.

18 грудня, о 15:00

Стрим буде за ооооось цим посиланням:
https://www.youtube.com/watch?v=Jeudw2EeDrI

#css_in_action
Поставити box-sizing: border-box і забути. Ну якось так сьогодні виглядає перший рядок CSS на проєкті. Але чи всі знають, що це таке та на що впливає? Давайте глянемо.

box-sizing визначає, в який спосіб буде розраховано значення розмірів у box model – тобто як бравзер рахує фактичний розмір елемента в макеті. Давайте пригадаємо, з чого складаються фактичні виміри:

— content: розміри вмісту всередині елемента;
— padding: внутрішні відступи між вмістом та бордером;
— border: товщина рамки навколо елемента;

Ці три значення й визначають фінальний розмір. А от як саме — визначає та сама box model.

За замовчуванням усі блочні елементи використовують content-box, і це означає, що властивість width застосовується до content box, тобто до внутрішньої зони.

Таким чином фінальний розмір визначається формулою:

total = content + padding + border;

де content це значення width або height, залежно від виміру. Саме тому, якщо задати елементу width: 100px, padding: 4px та border-width: 1px ми отримаємо фактичну ширину в 110 пікселів.

А що робить border-box? Він змінює підхід до розрахунку. І тепер формула набуває іншого вигляду:

content = total - padding - border;

Тепер width описує розмір усього елемента, а внутрішній content автоматично підлаштовується.

Чому ми надаємо перевагу саме border-box? Причина проста: розміри стають передбачуваними. Якщо ми кажемо, що ширина має бути 100 пікселів, вона й буде 100 пікселів, незалежно від падінгів та бордерів.

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

До речі, колись у Firefox існував ще експериментальний padding-box, в якому значення width задавало суму content та padding, лишаючи border поза формулою. Але це не прижилося. Може й на краще.

І ще важливо, що margin ніколи не входив, не входить і, сподіваюсь, не входитиме до box-model, адже це не вимір елемента, а його відступ від навколишніх елементів в макеті.

border-box у стандарті зʼявився не відразу, перші робочі драфти було опубліковано на початку 00-х. А от широкої підтримки це значення набуло десь так в 2012 році.

Цікавий факт: саме така поведінка box model була в IE5-IE6, але не через прогресивне мислення розробників бравзера, а через банальний баг. І багато хто вважав, що така поведінка є інтуїтивнішою, ніж стандартна.

Не буду робити висновків, але хто зна, може ми б і не мали border-box взагалі, або мали б його набагато пізніше, якби не цей баг в IE. І вкотре бравзер, який чомусь прийнято гейтити, змінив веброзробку на краще.

Що почитати
MDN: box-sizing

***
@babichdev

#анонс
Товариство, пишемо новий покдаст!

Цієї суботи, 20 грудня, о 19:00 відбудеться запис нового випуску подкасту "Подкаст у нас вдома", на якому разом з Уляною Білінською-Шута поговоримо про "Американську мрія: як працює найм в США".

Будемо говорити про американський ринок не тому, що туди «обовʼязково треба йти», а тому що саме там найчіткіше видно, як працює зрілий tech-найм. У США довші процеси, вища конкуренція й більша ціна помилки, тому рішення про найм рідко ухвалюють навмання. Цей ринок швидко знімає ілюзії й показує, що компаніям важливо не лише що ти знаєш, а як ти думаєш, говориш і береш відповідальність.

Для багатьох українських спеціалістів складність США — не в рівні знань, а в очікуваннях і підході до інтервʼю. Тому ця розмова не про релокацію чи мрію переїзду, а про розуміння системи: як читають кандидатів, чому відмовляють сильним інженерам і які сигнали насправді мають значення. Навіть якщо ви ніколи не плануєте працювати в США, цей досвід допомагає тверезіше дивитись на будь-який зрілий ринок.

Моя гостя —Senior Manual Quality Assurance Engineer, ex- Uber,ex- Linkedin. 7 років назад з юристки перевчилась на тестувальницю у Кремнієвій Долині, і з тих пір працює в професії. Також, Уляна — QA Mentor і допомагає як новачкам, так і досвідченим QA рухатися карʼєрною драбиною.

Запис відбудеться онлайн, посилання на студію прикріплено до події в календарі. Додавайте собі, буду радий бачити усіх вас!

ДОДАТИ ПОДІЮ СОБІ В КАЛЕНДАР

@babichdev

#css_in_action

Для майже останнього допису у цьому році я обрав тему, про яку збирався розповісти дуже давно. І от, 9 грудня цього року, непомітно для усіх, сталася моя особиста подія року у веброзробці.

Firefox нарешті додав підтримку @scope.

Проблема ізоляції селекторів в CSS стара як світ. В першу чергу через те, що механізм каскаду не передбачає ізоляції, лише перевизначення. Специфічність, порядок, !important врешті решт.

Люди всіляко намагалися це вирішити, кидаючись з крайнощі в крайнощі — то богопротивний БЕМ, то дияволоугодний CSS-in-JS.

Аж ось, 2021 року, зʼявилася цікава специфікація — @scope. Вона окреслювала механізм "області видимості" стилів, який давав можливість дійсно ізолювати селектори. Перша реалізація не забарилася, і вже 2023 року підтримка зʼявилася у Chrome/Edge, з наступного року у Safari, ну а до Firefox її нам підвезли майже під ялиночку.

Чому це важливо? По факту, механізм @scope працює не на ізоляцію селекторів, а на їхню область видимості. За замовчуванням усі селектори в CSS глобальні. А от @scope дозволяє сказати, що .noscript всередині .card поводиться ось таким чином. І якщо ми визначаємо певне "обмежене" правило, то стилі будуть застосовуватися виключно до елемента всередині області видимості. А поза нею до такого ж селектора — не будуть.

Працює воно, з однієї сторони, просто, з іншої — не дуже. Давайте поглянемо на простий приклад:

<div class="card">
  <h2 class="noscript">Превіт</h2>
</div>
<h2 class="noscript">Світ</h2>

@scope (.card) {
  .noscript { color: lime }
}
.noscript { color: red }

.noscript всередині .card буде зеленого кольору, ззовні — червоного. Як бачите, навіть якщо ми маємо перевантаження стилів нижче у файлі, усе одно будуть застосовані відповідні кольори.

Логічне питання: може це тому, що @scope додає специфічности? Але відповідь — ні, не додає. Ви можете перевірити це в Dev Tools.

Хоча зі специфічністю таки є нюанс — якщо я замість просто .noscript напишу h2.noscript в останньому правилі поза @scope, то цей стиль таки перебʼє наш зелений колір. "Специфічність, безсердечна ти сука", як сказав би Шелдон Купер.

Можна, звичайно ж, написати звично:

.card .noscript { … }

Але. В такий спосіб зʼявиться додаткова специфічність, якої зі @scope немає. Специфічність селектора в @scope визначається самим селектором, а не специфічністю селектора, яким задається область видимості. Тому навіть така конструкція матиме специфічність (0,1,0):

@scope (#card.override) {
  .noscript { color: lime }
}

На відміну від #card.override .noscript, яка матиме специфічність (1,2,0).

А ще області видимості можна задавати явно і початок, і кінець:

@scope (.parent) to (.child) { ... }

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

Я особисто використовую @scope для стилізації своїх компонентів. Це дозволяє уникати складного "ізоляційного" коду, а також використовувати різні "утилітарні" класи без обмазування їх специфічністю.

Таким чином я можу спокійно мати щось на кшталт:

<h2 class="size-xxl"></h2>
<div class="card size-xxl"></div>

і описувати ось цей size-xxl всередині відповідного скоупа в один простий селектор замість бавитися у "Вгадай специфічність":

@scope (:is(h1, h2, h3)) {
  .size-xxl { … }
}
@scope (.card) {
  .size-xxl { … }
}

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

@scope в цілому дозволяє писати чистіший та зрозуміліший CSS, а також явно керувати правилами застосування селекторів. Це дуже важливий момент — не специфічністю, а саме тим, чи буде селектор застосовано взагалі. Це дуже суттєва різниця, яку необхідно дуже чітко зрозуміти.

Що почитати:
MDN: @scope

Що почитати душнілам:
W3C: Scoping Styles: the @scope rule

Вогник, серденько, цьом у лобіка.

@babichdev

#партнерський_допис
Ринок ІТ зараз турбує багатьох — особливо питання, як у ньому не потонути й усе-таки дійти до офера.

Саме про це Вікторія Захарова проведе завтра, 23 грудня, практичний воркшоп на 2–3 години. Буде про конкретні речі:

— Як поводитися та як готуватися в процесі пошуку: аналіз ринку, резюме, супровідні листи, профіль в LinkedIn, нетворкінг;

— Що робити зі своїми емоціями: звідки взяти дисципліну, як не зневіритися в пошуку а також які софт-скіли взагалі очікуються роботодавцями;

— Практичні поради, зведені у воркбук: як ним користуватися, аби були дійсні зміни і як їх контролювати.

Якщо коротко — це спроба зібрати цілісну картину пошуку роботи: від старту до офера з урахуванням реалій ринку 2026 року.

Корисно буде і тим, хто тільки починає пошук, і тим, хто вже давно в процесі.

Зустріч безоплатна, реєстрація тут:
https://bit.ly/workshop_strategy2026

🗓 Коли: 23 грудня о 19:00
📌 Формат: Google Meet + підтримка в Telegram
⌛️ Тривалість: 2–3 години


P.S. 100% коштів за розміщення допису спрямовано на потреби ЗСУ.

Зі святами, товариство!

Я люблю Різдво за те, що це для мене, в першу чергу, саме сімейне свято — ще одна нагода зібратися разом за столом і провести час в колі найближчих людей.

Скільки б ми не зосереджувалися на роботі, розвитку професійних навичок, як би ми не прагнули нових здобутків і досягнень в кар'єрі, важливо пам'ятати — це не найголовніше в житті.

Я ціную те, що поруч зі мною найдорожчі моєму серцю: сім'я, друзі, та й ви, мої любі ).

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

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

З Різдвом та Новим роком!

Побачимось після свят ;)