А їду я, якшо шо, до Чернівців.

Буду на події FE Hills розказувати куди запхати ШІ на співбесіді.

Тож, якщо ви цими днями в Чернівцях і досі на взяли квиток — ну та я й не знаю, шо на це сказати.

Беріть квиточок і до зустрічі завтра!

https://www.it-cluster.cv.ua/fe-hills

#css_in_action
Бравзер читає CSS-селектори справа наліво.
Це загальновідомий факт, який, однак, потребує певного пояснення. По-перше, треба розуміти, коли це стається, а по-друге — чи завжди так.

Цей процес відбувається між етапом коли побудовані DOM та CSSOM та етапом render-tree. Це так званий style computation — крок, під час якого бравзер визначає, які стилі до якого елемента застосовуються. І саме тоді йому потрібно знайти відповідність між селектором та елементос в DOM.

Чому ж справа наліво? Усе просто — це зменшує кількість кандидатів для перевірки. Якби бравзер йшов селектором зліва направо, тобто зверху вниз DOM-деревом, йому б довелось перевіряти все дерево повністю. Натомість він відразу відсікає невідповідні кінцеві "листки" дерева, і прямує вгору від цільового елементу, який визначається найправішим простим селектором.

Погляньмо на приклад:

.card p ~ a.button

Тут бравзер відразу шукатиме усі a.button, потім пройдеться його попередніми сусідами, які є p, і для кожного з них знайде безпосереднього батька з класом .card. Що примітно, бравзер навіть не "шукатиме" ці елементи, бо побудує індекс за тегами й класами ще на етапі побудови DOM-дерева. Тому розпочне пошук відразу з потрібних вузлів.

Якби ми йшли зліва направо, то бравзер мусив би перебирати усі .card, незалежно від того, чи містять вони p, потім — усі p в таких .card, незалежно від того, чи є у них сусідні a.button.

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

А на цьому місці прийшов час поставити вподобайку та поширити допис. Хіба нє?

Взагалі, метчинг запускається доволі часто, коли постає потреба перезапустити style-calculation, наприклад, коли змінюються CSS-правила. Наприклад, на додачу до вище згаданого, коли ми змінюємо атрибути елементу з попереднім селектором (в цьому прикладі p або .card). Чи коли змінюється структура DOM: переміщення, додавання, видалення вузлів, а також коли є динамічні псевдокласи.

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

Важливо памʼятати, що DOM API не використовує саме цей рушій, але окремі операції можуть виглядати схоже. Наприклад, closest() ззовні може нагадувати рух селектором справа наліво, бо йде вгору по дереву. Проте під капотом він просто розбиває комплексний селектор на частини й викликає matches() на кожному предку. matches() же працює через Selector API, а не через CSS matching, тому алгоритм там зовсім інший.

Той же querySelector прямує вниз деревом, а селектор перебирає зліва направо. І операції з DOM використовують Selector API, а не іпмлементацію CSS-рушія, тож і алгоритми, і оптимізації, і підходи загалом можуть суттєво відрізнятись.

Загалом цей підхід спрямований не на якесь там "прискорення селекторів", а для забезпечення контрольованості інвалідації стилів. Завдяки такому напрямку браузер не перевіряє весь DOM, а працює локально — що й дозволяє CSS залишатися ефективним навіть на велетенських деревах.

Однак це не означає, що тепер можна видихнути і писати селектори на 15 складових. Треба памʼятати, що бравзеру однак доводиться виконувати титанічний обсяг роботи, особливо в умовах високодинамічних інтерфейсів. І якщо ми йому в цьому допоможемо, пишучи максимально прості селектори, він на нас точно не образиться.

Що почитати:
📖 The truth about CSS selector performance

@babichdev

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

Growth Factory проводитиме воркшоп "Як почати працювати напряму із замовниками і стартувати власний IT-бізнес", на якому Олег Мелешко, засновник Incode Group (≈200 людей) та фулстек-розробник, покаже, як виглядає шлях від першого проєкту до власної команди з 10 людей і компанії.

На цьому воркшопі ви дізнаєтеся:
— З чого реально починається сервісна IT-компанія і що робити в перший місяць;
— Як знайти свій перший проєкт, якщо вас ніхто не знає;
— Як діяти, щоб вирости до 5–10 людей у команді;
— Перші рішення та фреймворки, які запускають бізнес;
— Як має виглядати процес роботи;

А ще разом створите просту CRM для управління проєктами, якою можна буде користуватися хоч просто вже.

Участь у воркшопі безкоштовна. Реєструйтесь та почніть робити перші кроки до власного IT-бізнесу: https://bit.ly/4pBgxd0

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

#думки_вголос
Часто, коли мова йде про сучасний стан на ринку, звучить думка про джунів та їхню нелегку долю. І, хоч я й згоден із тим, що ситуація далека від бажаного стану речей, маю одне зауваження. Річ у тім, що відчутна частка як роботодавців, так і кандидатів, чомусь досі керуються поняттям джуна, яке вже дуже застаріло.

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

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

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

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

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

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

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

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

І так, як би не було прикро, наздоженуть його далеко не усі. Це теж треба враховувати. Багато з нас, навіть ті, хто в індустрії вже давно, просто не витримають темпу.

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

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

Головне не сидіть камінцем на тому, чого ринок вже не чекає.

Якось так.

@babichdev

Ринок може вже й не чекає чогось, а от я на ваші вподобайки чекаю.

Так, товариство, дрон, на який ми збирали, а саме DJI Mini 4 Pro для 115-ї бригади, вже дістався адресатів та почав виконувати свої завдання.

Остаточна вартість дрона склала 48 154 гривні.

Дякую усім, хто долучився до збору бодай гривнею!

P.S. Розіграш в банці я вже провів, напишу про переможця, щойно ця людина мені відкриє контакти та я з нею звʼяжусь. Нагадую, що розігрував я ось таке Lego. Дуже сподіваюсь, що його таки заберуть, і не доведеться його розігрувати ще раз. І ще раз. І ще.

Товариство, наступного тижня робимо Ламповий мітап у Львові!

11 грудня,
Відкриваєм двері о 18:30
Початок о 19:00

Цього разу тема вечора — "Ані слова про ШІ". Поговоримо трошки про карʼєру, трошки про дизайн, трошки зачепимо розробку.

Чи буде цікаво? Та певно. Чи буде весело? Ну, нам нудно не було. Чи буде лампово? Беззаперечно. І піца спільнокоштом теж буде.

А теми виступів зʼявляться дещо згодом. Разом із дорожчими квитками. Тому не зволікайте та беріть ту ранню пташечку.

https://secure.wayforpay.com/payment/lampa_2

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

День 4 грудня 1995 року припадав на понеділок. Швидше за все, я провів його в школі, сидячи за партою в авдиторії, на дверях якої висіла табличка "2-А". І хіба міг знати маленький Сергійко, що саме того дня відбулася подія, без якої, по суті, він би не сидів оце зараз і не писав би ці рядки до власного каналу "Дивовижний світ веброзробки"?

Бо 4 грудня 1995 року було опубліковано документ, що став неймовірно важливою віхою в історії інтернету — офіційний прес-реліз від Netscape та Sun Microsystems, в якому ті оголосили про презентацію мови JavaScript, її інтеграцію в браузер та загальну стратегію «open Internet platform».

Цього дня цікава забавка від Netscape, створена буквально на колінці, зробила перший впевнений крок до світового домінування. Бо саме завдяки цьому прес-релізу JavaScript вийшов у великий світ та почав ставати невідʼємною частиною інших бравзерів.

Ця подія, по суті, цементувала JavaScript як публічну технологію, а не внутрішній продукт компанії і відкрила шлях до того, аби мова стала основою відкритої вебплатформи.

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

Звичайно ж, цей шлях важко назвати спокійним та комфортним. Радше буремним та непередбачуваним. JavaScript пережив і роки майже повної стагнації, і період різкого перезапуску, після якого мова перейшла на щорічний реліз-цикл, завдяки чому мова нарешті отримала передбачуваний розвиток.

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

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

Однак, як і 30 років тому, сніжинки на сайті усе одно можна запустити.

З офіційним 30-річчям, JavaScript!

@babichdev

Товариство!
Я проведу 4 індивідуальні технічні співбесіди для junior–senior фронтенд-розробників у грудні.

Як це відбувається і що ви отримаєте?

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

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

3. Проводимо співбесіду. Базовий усний фідбек — одразу на дзвінку.

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

Вартість — 200$.

Якщо вам важливо тверезо й неупереджено оцінити свій рівень та зрозуміти подальший напрям — надсилайте заявку.

Форма:
forms.gle/5R5TPTKUmzUMnz6p9

P.S. Це не ютуб )

#партнерський_допис
Товариство, завтра, 10 грудня, компанія Growth Factory та Ед Мяус запрошують вас на практичний воркшоп, де ви можете закласти фундамент для вашої IT-компанії.

Цей воркшоп — логічне продовження минулого майстеркласу "Як почати працювати напряму із замовниками і стартувати власний IT-бізнес".

Ед Мяус — підприємець з 20+ річним досвідом, фаундер IT-компанії MeGaDev, Grade. app, інвестор та адвайзер у 15+ компаніях.

На воркшопі ви:

1) Оберете назву для своєї IT-компанії, нішу та послуги;
2) Дізнаєтесь, як запустити сторінку компанії у LinkedIn і налаштувати LinkedIn фаундера/компанії під чек клієнта;
3) Навчитесь формувати канали залучення клієнтів;
4) Пропишете ваші сильні сторони як IT-фаундера;
5) Підготуєте основу для першої виручки.

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

https://bit.ly/3XIAbb3

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

#мислення_розробника
Патерни! О, скільки в цьому слові… Сльози, плач, нерозуміння, довгі ночі, червоні очі, лемент і крик…

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

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

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

Щодо доцільности вивчення високих матерій умовними джунами, маю відразу зазначити, що у мене для вас погані новини (вкотре), і нинішній джун, який дійсно потрібний ринку, це приблизний відповідник мідла пʼяти–семирічної давности за рівнем теоретичних знань. Це не привід заломувати руки і лементувати, а навпаки — привід задуматись, по-перше, а чи так воно вам то все треба, а по-друге, усвідомити що воно таки треба і почати системно вчити.

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

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

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

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

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

Тож вчіть патерни, любі мої початківці. Але спочатку прочитайте інструкцію із застосування.

@babichdev

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

Будемо говорити про те, як пройти ATS і AI-фільтри, які бувають фатальні помилки в рекрутингу і як вони впливають на кандидатів, як зрозуміти зрілість компанії та її реальні наміри, і як адаптуватися до стилю співбесід в США, Європі та ЛатАМ.

У мене в гостях буде Ольга Базуріна — Global Talent Acquisition Manager з десятирічним досвідом рекрутингу в США, Європі, Україні та LATAM, яка будує та масштабує технічні й C-level команди для компаній рівня Fortune 500. Вона — співвласниця міжнародної рекрутингової агенції та експертка з HRTech і Talent Intelligence, яка поєднує технічну експертизу, бізнес-орієнтований підхід і створює стандарти оцінки команд.

Традиційно під час запису ви зможете ставити свої запитання, бешкетувати в чаті і, звичайно ж, отримати нагоду виграти подарунки за донат на ЗСУ.

Запис планується на 18:00.

Запишіть собі десь, посилання на студію я опублікую в каналі в суботу.

Ще раз:

Запис подкасту "Шлях крізь найм: як пройти машини, людей і очікування"
13 грудня, 18:00
Онлайн

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

Доброго ранку.
На Ламповий мітап №2 у Львові лишилося усього 8 квитків.

Цього разу — ні слова про ШІ.

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

— Еля Неплохова поділиться тим, як насправді працює LinkedIn та поділиться порадами щодо оформлення профілю, щоб ваша сторінка була привабливою для рекрутерів і піднімалась у пошуку.

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

https://secure.wayforpay.com/payment/lampa_2

Зустрінемось СЬОГОДНІ, 11 грудня в офісі компанії Sigma Software на вул. Науковій, 7д.
Двері відкриваємо о 18:30.
Приходьте, буде цікаво, весело і точно буде лампово! Як і обіцяли.

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

ПРЕМʼЄРА

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

Чому код — це лише результат, а не цінність сам по собі; чому вузька спеціалізація дедалі частіше стає обмеженням; як AI впливає на роботу інженера і що в цій реальності справді має значення. Мислення, відповідальність, робота з контекстом, здатність вчитися й ухвалювати рішення — замість простого користування інструментами.

Про це та багато чого іншого я говорив з Артемом Биковцем (@agile_bykovets_smpl) — одним із найбільш досвідчених практиків і тренерів Agile & Scrum в Україні, який працює з Agile з 2010 року, з OKR — з 2015-го, консультує компанії від індивідуального рівня до C-level, заснував конференції Simplicity Day, є гостьовим лектором КМБШ і постійно експериментує з новими форматами, зокрема стендап-комедією.

ПРЕМʼЄРА ВІДЕО
Сьогодні, 12 грудня,
19:00

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

Тисніть дзвіночка і приємного перегляду ;)

#партнерський_допис
Хотіли дізнатися, що у 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