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

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

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

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

#співбесіди #непрошені_поради

Гммм, а може це спробувати таку забаву на ютубі — такий собі Еліас по розробці? Що думаєте?

@babichdev

Вітайте наступного спікера конференції React+ fwdays’25 🤩

Сергій Бабіч — Senior Frontend Developer, DataRobot
15 років у веб розробці, 8 років у спікерстві.

🎤 Доповідь: "useLess"

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

👉 Приєднуйтесь до події, щоб почути цю доповідь!

Товариство, починаємо уже за 5 хвилин!
Хутко готуйте чай, смаколики та душні жартики і гайда до перегляду!

https://youtube.com/live/71vmmVRdjX4

Дивлюсь, вам дуже сподобалося слово "обфускація". Що ж, тоді варто розповісти вам про неї, а заодно дізнатися, чим воно відрізняється від мініфікації.

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

Мініфікація стискає файл: вирізає пробіли, коментарі, перенос рядків, а імена змінних і функцій зводить до мінімуму. При цьому структура не змінюється. У JavaScript це особливо ефективно, адже форматування й відступи йому байдуже (окрім крапок з комою). Якщо змінна чи функція експортується за межі модуля, її ім’я лишається незмінним, аби уникнути плутанини. У результаті файл стає меншим і швидше вантажиться з сервера, хоча на швидкість виконання це не впливає. Це як написати: «Првт,звтрбдшшлк.взмпв» — сенс той самий, просто треба вміти читати.

У обфускації ж інша мета — максимально ускладнити можливість реверс-інжинірингу, тобто покликана не дати розібратися, що ж відбувається у вашому коді. Це може бути корисним, коли ви пишете якийсь супер-пупер унікальний алгоритм, за який берете гроші. Ну або зловмисний скрипт.

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

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

Наприклад, банальний Hello, world!

function hi() {
  console.log("Hello World!");
}
hi();

може перетворитися на ось такого кракена:

function _0x2925(_0x542d0a,_0x2c3c78){var _0xa1e55d=_0xa1e5();return _0x2925=function(_0x292568,_0x3c856f){_0x292568=_0x292568-0x1ac;var _0x3c7a1b=_0xa1e55d[_0x292568];return _0x3c7a1b;},_0x2925(_0x542d0a,_0x2c3c78);}(function(_0x4d614b,_0x34a9e8){var _0x209520=_0x2925,_0x55e423=_0x4d614b();while(!![]){try{var _0x1f7119=-parseInt(_0x209520(0x1b6))/0x1+-parseInt(_0x209520(0x1af))/0x2*(-parseInt(_0x209520(0x1b2))/0x3)+-parseInt(_0x209520(0x1b1))/0x4+parseInt(_0x209520(0x1ad))/0x5+parseInt(_0x209520(0x1b7))/0x6*(-parseInt(_0x209520(0x1ac))/0x7)+parseInt(_0x209520(0x1ae))/0x8*(parseInt(_0x209520(0x1b5))/0x9)+parseInt(_0x209520(0x1b0))/0xa;if(_0x1f7119===_0x34a9e8)break;else _0x55e423['push'](_0x55e423['shift']());}catch(_0x259b9c){_0x55e423['push'](_0x55e423['shift']());}}}(_0xa1e5,0xdb2b8));function _0xa1e5(){var _0x135cc9=['1630085KNrFJy','5633484gfXmBA','7uZhyxi','8869945iTvxpi','661592MxYeut','314PMTrKl','19727980eYXqzm','5305732XTxbqH','18414OMZNhs','Hello\x20World!','log','9OSzIcJ'];_0xa1e5=function(){return _0x135cc9;};return _0xa1e5();}function hi(){var _0x3be6dc=_0x2925;console[_0x3be6dc(0x1b4)](_0x3be6dc(0x1b3));}hi();

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

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

Тож наступного разу, коли зустрінете у коді монстра з десятками _0x123abc, не поспішайте кликати екзорциста. Може, це просто «Hello world», який вирішив переодягнутись у костюм пінгвіна і хоче вкрасти ваші паролі.

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

Питання тут: https://forms.gle/mVfdFLGFnRY6fvbMA

Запис співбесіди тут: https://youtube.com/live/71vmmVRdjX4

І не кажіть, шо я вам не казав.

#партнерський_допис
Любе товариство, шановна громадо, якщо ви раптом чекали на офлайн-мітап, присвячений JavaScript і кар’єрному розвитку, та ще й у Львові — маю для вас новини!

25 вересня відбудеться Fwdays JS Meetup Lviv, на якому ми з вами зможемо послухати виступи від чудових спікерів! А саме:

— Валентин Лапотков поділиться власним досвідом переходу з JavaScript на Go і порівняє підходи до асинхронного програмування, архітектуру застосунків, роботу з базами даних та інструменти.

— А Олександр Зіневич розповість нам свою точку зору на шлях розвитку після досягнення рівня синьйор-інженера. А розказати Сашку є що, адже він пройшов путь від від Junior Engineer до керівника Node.js Department.

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

Сподіваюся зустрітися там і з вами!

РЕЄСТРАЦІЯ БЕЗКОШТОВНА

Реєстрація ось тут: https://bit.ly/4lVMPwW

Чат fwdays, де можна поспілкуватися й слідкувати за усіма їхніми анонсами тут: https://news.1rj.ru/str/+Qjomfxavcbr7QyQu

Я зробив собі боляче класами.
Що мені подобається в JavaScript, так це можливість писати код як в чисотму ООП стилі, так і суто в функціональному. А для поціновувачів є можливість змішувати обидва підходи.

Зараз я працюю над однією цікавою задачею — переношу графік з монолітного репозиторію в окреме репо для графіків. Рендеряться вони, очевидно, за допомогою d3. І от в тому репозиторії усі графіки зроблені класами. Очевидно, спочатку я вирішив — чому ні? Дай-но я й собі свій графік зроблю красивим класом.

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

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

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

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

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

З усього цього я, правда, зробив висновок, що це не ООП поганий, а мені варто покращити й підтягнути свої знання в ньому. Буду відвертим, мене дуже дратувало те, що я не міг просто й прозоро скласти в голові таку собі діаграму класів та описати для себе, як вони спілкуються.

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

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

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

@babichdev

#думки_вголос

От і мерч підвезли

Доброго ранку, товариство!
Мене тут Mate Academy запросили трохи попсувати крові своїм випускникам, тож сьогодні ввечері я буду у них на ютубі робити наживо код-ревʼю командному проєкту BookStore, а віддуватися за усіх буде пан Юрій Стисло.

Ну а я у свою чергу запрошую вас приєднатися до етеру в якості глядачів і викрутити свої душнільні налаштування на 11!

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

До зустрічі о 18:00!

#css_in_action
Як часто ви помічали стрибок лейауту, коли на сторінці зʼявляється чи зникає скролбар? Це особливо помітно, коли ви показуєте кастомну модалку і при цьому блокуєте прокрутку body через overflow: hidden (а мали б через clip).

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

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

На відміну від overflow-y: scroll, gutter саме резервує місце, не відображаючи нічого, поки не зʼявиться потреба показати реальний скролбар.

У цієї властивості є два ключових значення, які дозволяють керувати її поведінкою:

— stable: резервує місце під скролбар з одного боку, в нашому випадку — з правого;
— both-edges: будучи доданим до stable, резервує місце з обох боків, врівноважуючи таким чином макет і зберігаючи центроване розміщення вмісту сторінки відносно вʼюпорту.

Без вподобайки я не дозволяю читати далі.

Є, щоправда, кілька недоліків, які варто зазначити. Найбільший із них: в Chromium зараз існує баг, коли правий відступ з both-edges залишається видимим навіть при видимому скролбарі. В Firefox усе працює чудово.

Також gutter ніяк не стилізується, він завжди прозорий, тож крізь нього буде видно тло батьківського елементу. А якщо застосувати gutter до елементу html, то ви отримаєте просто пусте місце, на яке ви взагалі ніяк не вплинете. Because fuck you, that's why.

Іншим застереженням є те, що scrollbar-gutter працює тільки з класичними "цільними" скролбарами. Якщо у вас скролбари overlay, то й сенсу задавати gutter немає.

І ще треба враховувати, що gutter має ширину системного скролбару, і змінити його розмір можна лише за допомогою scrollbar-width. Але, на жаль, ця властивість не дозволяє задати бажаний розмір в пікселях, лише з переліку auto, thin та none.

📖 MDN: scrollbar-gutter

Тож якщо у вас досі є костилі з padding: calc(100vw - 100%) або завжди ввімкнений overflow-y: scroll — спробуйте замінити їх на scrollbar-gutter. Це той випадок, коли CSS знову пропонує нам однорядкове рішення проблеми, якій вже більше років, ніж багатьом моїм читачам.

@babichev

#css_in_action
Вітаю, товариство! Сьогодні хочу розповісти вам про нову можливість в CSS, про яку дізнався буквально вчора.

В Chromе та Edge зʼявилася підтримка властивості corner-shape, яка дозволяє змінювати форму кутиків елемента, якщо у нього заданий border-radius.

Наразі ця властивість підтримує настапні значення:

round: звичні нам круглі кутики.

bevel: фаска, прямо зрізані кутики.

scoop: круглі кутики, вирізані всередину.

notch: вирізані всередину прямокутники.

squircle: чорт-зна-шо, якісь скруглені квадрати )

Що цікаво, можна задавати форму для кожного кутика окремо:
corner-shape: round bevel bevel round;

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

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

📖 CSS Tricks: What Can We Actually Do With corner-shape?

А далі можна побавитися в пісочниці.

📖 MDN: corner-shape

Як я вже зазначив, це поки експериментальна підтримка, однак завжди варто бути готовими до забаганок дизайнерів, еге ж? )

Етер уже за пʼять хвилин!
Готуйте смаколики і гайда до перегляду!

youtube.com/live/YrzZAsMPyTw

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

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

В JS тривалий час це можна було зробити доволі обмеженому, хоча й популярному, колі випадків: map, filter, reduce та slice. Проте лишалися кейси, які, може й не такі поширені, проте, певно, критичніші.

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

Проте прийшов час відкинути геть сум та зневіру. Якщо бути точним, то цей час прийшов ще 2023 року, коли в Baseline зʼявилася скромна трійця методів масиву toSorted, toReversed та toSpliced.

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

const source = [3, 2, 7, 4];
console.log(source.toSorted());
// > [2, 3, 4, 7]
console.log(source.toReversed());
// > [4, 7, 2, 3]
console.log(source.toSpliced(3, 0, 5));
// > [3, 2, 7, 5, 4]
console.log(source);
// > [3, 2, 7, 4]

До речі, toSpliced можна (але не значить, що треба) використати, як замінник для іммутабельного push:

const push = (arr, ...args) =>
  arr.toSpliced(arr.length, 0, ...args);

console.log(push(['a', 'b', 'c'], 'd', 'e'));
// > ['a', 'b', 'c', 'd', 'e']

Тож тепер знатимете, що замість ручного створення "проксі-масивів", ви можете просто скористатися нативним методом JS, і ваш код стане ще лаконічнішим і надійнішим.

📖 MDN: toSorted
📖 MDN: toReversed
📖 MDN: toSpliced

До речі, ми додали нову порцію квитків на Лампову Співбесіду: Senior Frontend, що відбудеться офлайн у Львові наступної суботи. Я б на вашому місці не зволікав.

@babichdev

Товариство, якби хто ще не встиг взяти участь в розіграші "Питання від партнера" з останньої співбесіди Backend Engineer від Headway Inc, то виключно для вас продовжуємо термін дії форми до завтрашнього ранку.

Даєте правильну відповідь — отримуєте шанс виграти один з подарунків, що на фото. Все максимально просто.

Питання отут: https://forms.gle/K4Dkw4XVrDDk7c8B8

Запис співбесіди: https://youtube.com/live/YrzZAsMPyTw

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

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

По-друге, зненацька мене запросили виступити на IT Arena цієї пʼятниці, тож посилено готуюсь до доповіді, має вийти дуже цікаво, тим паче тема дуже близька мені зараз — "Rethinking Technical Interviews in the Age of AI". До того ж попросили виступити англійською, що теж буде цікавим досвідом. А ще я вже планую зробити відео за мотивами цієї теми.

До речі, про відео. Попри усі перешкоди (серед яких моя лінь), уже на завтра заплановано вихід відео "5 помилок на співбесідах, які можуть коштувати вам оферу". В чомусь це експериментальний досвід, і це можна вважати першим дзвіночком повернення каналу до джерел — хочу робити більше саме відео. Побачим, як воно піде.

Та й такі справи. А як минає ваш тиждень, є чим поділитись?