#думки_вголос
З кожним роком стає усе важче боротися з "гімно мале"-mentality. Ну тобто коли ти весь такий поважний і вкритий мохом дивишся на умовних 25-річних синьйорів і бухтиш собі під носа "ну який ти в сраку синйьор, ти ж жизні не видів, де там того синьйора взяти".

Проте накладати власний досвід на чужий — часто справа невдячна. Бо це я в 25 і на мідла не стягував, адже почав в 24. А якщо людина почала кар'єру в дев'ятнадцять років, і при цьому сумлінно працювала, в не тільки тасочки закривала, то чому вона не може здобути за цей час необхідний досвід? Може. І здобуде.

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

І взагалі, чому мати дітей в 22 можна, а бути синьйором в 25 не можна? Отож.

Головне при цьому бути не "паперовим" синьйорами, і розуміти, що це не лише личка, в й відповідальність.

Гарних вихідних!

@babichdev

Жарт безсовісно спертий у @dobermanko

#css_in_action
Ну що, поцентруємо трошки div? У мене тут вчора в Threads попросили, то як я можу відмовити? А то все архітектури, гуд інаф коде. Одним словом, донт пуш зе хорсес, треба й ділом зайнятись. Тож…

ЦЕНТРУЄМО ГОРИЗОНТАЛЬНО
Margin

.el { 
  margin: 0 auto;
  width: ...;
}

Працює, коли елемент має обмежену ширину. Не працює для інлайнових елементів.

Для інлайнових блоків

.parent { text-align: center; }
.el { display: inline-block; }

Класичний спосіб для вирівнювання inline або inline-block елементів. Батьківський text-align впливає лише на інлайн-контент.

Flexbox

.parent {
  display: flex;
  justify-content: center;
}

Найстабільніший спосіб для X-центрування. Важливо памʼятати, що align-items за замовченням stretch, тому вертикаль може "роздувати".

Grid

.parent {
  display: grid;
  justify-items: center;
}

Просто, сучасно, стильно, молодіжно.

Absolute + transform

.el {
  position: absolute;
  left: 50%;
  // або
  inset-inline: 50%;
  transform: translateX(-50%);
}

100% надійність. Потрібен position: absolute|fixed. Підтримка inset-inline чудова у всіх сучасних бравзерах (навіть Safari).

justify-self

.el { justify-self: center }

Працює у Grid. Не працює в Flex (бо цим керує сам контейнер). Працює поза grid в блочних контекстах, але тільки в Chrome та Edge. Firefox і Safari цю поведінку ігнорують, сподіваюсь, тимчасово.

ЦЕНТРУЄМО ВЕРТИКАЛЬНО
Flexbox

.parent {
  display: flex;
  align-items: center;
  height: ...;
}

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

Grid

.parent {
  display: grid;
  align-items: center;
}

Просто, сучасно, стильно, молодіжно.

Absolute + transform

.el {
  position: absolute;
  top: 50%;
  // або
  inset-block: 50%;
  transform: translateY(-50%);
}

Це ж було вже.

align-self

.el { align-self: center; }

Працює поки лише всередині flex та grid. Всередині flex це вертикально, якщо flex-direction: row, якщо це column, то вирівнювання буде по горизонталі. Очікується підтримка в блочних контекстах.

Table-cell

.parent {
  display: table-cell;
  vertical-align: middle;
}

Дідівський спосіб, не позбавлений недоліків. Багатьох недоліків.

ЦЕНТРУЄМО ЦЕНТРАЛЬНО
Flexbox

.parent {
  display: flex;
  align-items: center;
  justify-content: center;
  height: ...;
}

Один із найнадійніших способів. Потрібна висота в контейнера.

Grid

.parent {
  display: grid;
  place-items: center;
}

Найменше коду. Повна підтримка. Але потрібен grid.

Absolute + transform

.el {
  position: absolute;
  top: 50%;
  left: 50%;
  // або
  inset: 50%;
  transform: translate(-50%, -50%);
}

Найнадійніший варіант з абсолютним позиціонуванням. inset — скорочений запис для top/right/bottom/left усіх разом. Боже, як я мріяв колись про цю властивість…

place-self

.el { place-self: center; }

Працює тільки всередині grid. Поза ним — частково підтримується в Chromium, але не в Safari чи Firefox.

---
Ну от якось так можна відцентрувати div в липні місяці 2025 року. Можливо ви знаєте ще якийсь чудернацький спосіб, то обовʼязково розкажіть про нього в коментарях. До речі, приєднуйтесь до чату, як іще будемо ділитися глупими мемами про джаваскрипт?

MDN: CSS Box Alignment Module Level 3

@babichdev

#про_співбесіди
Сир, сирок і race condition
Ви шукаєте "сирок", а бачите "сир". Ні, це не випадок в "Сільпо", а цілком собі питання на технічному інтервʼю.

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

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

Отже, питання:

У вас є табличка з пошуком, і якщо в пошуку спочатку набрати "сир", а потім швиденько дописати "-ок", то таблиця усе одно відображатиме список і сирів і сирків. Чому так може бути?

Відповіді, звичайно, я отримую доволі різноманітні, проте серед найчастіших є одна умовно невірна, і одна — вірна.

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

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

Схема проста: запит на “сир” пішов першим, але довго обробляється. Тим часом користувач встиг дописати “-ок”, і запит на “сирок” пішов другим — але відповів швидше. У результаті інтерфейс спочатку показує правильний список, а потім перезаписується старішою, але пізнішою відповіддю. Особливо легко це проґавити, якщо показується лише один індикатор завантаження.

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

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

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

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

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

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

Тож, якщо ваш колега знову "пакращить" відповідь на інтервʼю — покажіть йому цей кейс ;)

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

@babichdev

#нове_відео
Хто такі синьйори?

Цей подкаст чекав на свій зірковий час ще із січня, і ось нарешті ви маєте змогу послухати, як ми з Нікітою Галкіним розбираємо тему, що давно потребувала відвертої розмови. Що таке синьйорність? У чому вона проявляється? Як не сплутати її з фреймворковою експертизою? І що взагалі чекає після?

Ходіть дивитися і приємного перегляду!

Хто такий Senior Software Developer? | Подкаст з Нікітою Галкіним

І не забудьте поширити це відео серед усіх родичів і знайомих.

Зловив ) Дякую!

#про_співбесіди
У мене вчора трошки пригоріло від одного допису в Threads. Якщо коротко: історія про співбесіду, де кандидат класно відповідає на питання, розповідає кейси, і взагалі повний метч. Але аж тут, при завершенні тімлід раптом питає: "А що більше, 5² чи 2⁵?' Кандидат розгубився, просить калькулятор. І висновок мене вбив: "Це не про математику. Це про базову уважність, реакцію, спокій під тиском."

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

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

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

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

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

Підсумовуючи, залишу просто дуже влучну цитату з коментарів: "В гуглі всі знають, чому люки круглі, але чомусь досі пишуть код з null exception".

Все, ніби випустив пару. Не будьте душні, одним словом.

@babichdev

Товариство, хто хоче стати зіркою наступної співбесіди на ютубі? Яка, до речі, відбудеться наступної пʼятниці, 1 серпня.

Заповнюйте анкету і хапайте нагоду попозоритись показати свої знання в прямому етері!

https://forms.gle/T8SKFTpuCbY1vK8E6

Чекаю на ваші заявки до вечора неділі. Всім гарного вечора пʼятниці!

#партнерський_допис
Товариство, а ви чули? ШІ стукає в наші таски! І як він змінить роботу фронтенд-розробників у найближчі роки — говоримо на панельній дискусії appflame talks!

📅 31 липня, 18:00–20:00, онлайн
Спікери з appflame, WIX, Softsich. Модератор — щиро ваш Бабіч.
Ця подія — і для розробників і тімлідів, які хочуть розуміти, куди рухається індустрія.

Поділимося практичними кейсами та інструментами, що варто використовувати вже сьогодні!

🔗 Реєстрація: http://bit.ly/4lszyfW

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

Одним зі способів подолати цю проблему є фіксування розмірів елементів зображень, наприклад, задаючи в HTML width та height. Однак, якщо у вас адаптивний дизайн, і картинки мають динамічні розміри, цей підхід просто не спрацює.

І тоді людство згадало про так чудову річ, як пропорції, і почало "резервувати" місце під зображення, поки сам файл вантажиться. Найнадійнішим способом тривалий час був так званий padding-top hack — коли за допомогою внутрішнього відступу, абсолютного позиціонування і такоїто матері вдавалось таки забезпечити сталі пропорції. Але якою ціною?

<div class="box">
  <img class="fixed-ratio">
</div>

<style>
.box {
  position: relative;
  width: 100%;
  padding-top: 56.25%; /* 9 / 16 = 0.5625 → 56.25% */
  overflow: hidden;
}

.fixed-ratio {
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
}
</style>

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

Як і будь-який хак, цей підхід має свої плюси і мінуси. Мінусів зазвичай більше. Я не буду заглиблюватися в них, але таку конструкцію дуже легко вивести з ладу: тут тобі і overflow: hidden, і неявна висота, і абсолютне позиціонування.

Хто не поставить серденько — втратить доступ до каналу через 3… 2… 1…

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

.fixed-ratio {
  aspect-ratio: 16 / 9;
}

Можна задати й по старому, одним значенням, якщо вам дуже подобається знущатися над колегами:

.fixed-ratio {
  aspect-ratio: 1.77777778;
}

А, що ще важливо — очевидно, що aspect-ratio працює для усіх блочних елементів, не лише для зображень.

Частиною Baseline ця властивість є з вересня 2021 року, а це означає, що ви можете спокійно використовувати її у ваших продакшн-проєктах. Якщо ви досі не пишете під IE, звичайно.

Для себе я цей підхід відкрив приблизно у той же час, але використовував доволі обережно, зазвичай у пет-проєктах, але зараз підтримка сучасних CSS-фіч пришвидшилась, тож уже немає сенсу триматись за хаки

🌐 MDN: aspect-ratio

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

@babichdev

Товариство, хочу вам нагадати, що триває збір на Mavic для 184 навчального центру.

І ще хочу нагадати, що Росія — кончена країна кончених людей. Якщо, звичайно, вам не вистачає її власних нагадувань.

Дякую за кожну гривню.

***
На Mavic для 184 навчального центру

🎯 Ціль: 80 000 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

Доступність, семантика, дизайн-системи: існують.
В той же час Threads:

Опитування!

Tailwind — ви за чи проти?

Голосуйте донатами та вказуйте в примітках на чиїй ви стороні. Один голос — 5 гривень.
Завтра спробую підбити підсумки.

https://send.monobank.ua/jar/AeXQ6YRf2X

P.S. Донати йдуть на збір на Mavic для 184 навчального центру.

Ох, вже ті новачки з шилом в дупі!

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

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

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

По-перше, в команді має бути нормальний онбординг. Я не говорю зараз про те, коли вам видають ноутбук, пароль до корпоративної пошти і роблять один дзвінок з HR на пів години на тему "шо ти голова".

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

По-друге, ніхто не забороняє вам вносити пропозиції. Саме так — вносити пропозиції. Не вриватися з бойовим криком "Міша, всьо хуйня, по новой давай!", а аргументовано запропонувати зміни. Так, я знаю, це набагато складніше, ніж плодити купу ПР, які розходяться з командними правилами бо "мені так зручніше". Ну і це не так захопливо, як сваритися на дейліках з тімлідом, визнаю.

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

Команда теж має бути відкрита до таких пропозицій. Не варто будувати робочі процеси за принципом "мій дід надвір ходив, то й ми будем". Якщо ви не хочете бути завалені "законодавчим спамом", визначте чіткі правила для таких випадків: який формат пропозала, яка аргументація, за і проти. І розглядайте не для галочки, а дійсно сприймайте це як потенційні покращення.

Ці поради я даю з власного досвіду. Коли я тільки прийшов до нинішньої компанії, мені надзвичайно не сподобався стиль написання коду. Однак цього разу замість відразу підіймати кіпіш, я під час одного з дзвінків запропонував внести пропозицію, промацав ґрунт, так би мовити. І коли команда погодилась, я засів за створення монументального документу, де детально розписав недоліки (на мій погляд) поточного стану справ та переваги (на мою думку) іншого підходу, зачепивши не просто сам код, а й, до прикладу, вплив на підходи в тестуванні.

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

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

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

@babichdev

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

@babichdevchat

Долучайтеся.

Співбесіда з трейні наживо вже за кілька хвилин!
Готуйте пиво, чай, чи що кому до смаку і гайда до перегляду!
https://youtube.com/live/nRf43EVT2Ow

Що ж, за підсумками учорашньої співбесіди було прийнято рішення зробити рубрику "Бабіч знов спозоривсь на ютубі" регулярною, і вже в понеділок чекайте на детальний розбір теми "Приведення типів та оператор + в JavaScript "