Був оце ж учора на «факап-вечорницях» від Brainstack. Трохи поділився з глядачами тим, як штучний інтелект так підставив мій PR, що я наловив пісюнів коментарів від інжиніринг-менеджерки. Або як я власноруч втопив офер мрії, коли на дзвінку з рекрутеркою видав три відра крінжі. Було весело.

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

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

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

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

В розробці це так само важливо, як і будь-де. Бо якщо на дрібних косяках не робити саморефлексію, то одного дня пройоб таки стане факапом рівня "Срака-мотика". А воно нам треба?

А зараз я трошки відступлю від теми. Учора в готелі випадково ввімкнув «Аполон-13» з Томом Генксом. Ніколи його не бачив, і тут раптом втягнувся по самі вуха. Фільм крутий, але ще цікавіша сама історія програми.

Першою дісталася Місяця одинадцята місія — «Аполон-11». А все, що було до того, для стороннього глядача — одна суцільна низка невдач. «Аполон-1» взагалі закінчився трагедією: під час випробувань на стартовому майданчику згорів увесь екіпаж. Інші місії зі сторони теж могли виглядати невдачами: то не злітали, то вибухали, то ламалися по дорозі.

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

До речі, не завжди наші факапи — саме наші. Причина, що призвела до майже катастрофи з "Аполон-13"? Одна маленька бракована котушка в електричній схемі в системі подачі кисню.

Тож, по-перше, сприймайте робочі пройоби не як кінець світу, а як шанс вирости.

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

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

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

По-друге, я до вас по ділу. Маю запит від Житомирського військового інституті імені С.П. Корольова допомогти придбати деякий інвентар для забезпечення навчального процесу для майбутніх офіцерів. До речі, так, на відео — частина підготовки курсантів.

Так от, щоб була можливість і далі проводити таку підготовку, ми з вами можемо швиденько зібрати кошти на наступне:

Граната Pyrosoft РГД Pyro-5
90₴ × 120шт = 10 800₴

Димова граната Pyrosoft П-18 “Актив”
190₴ × 60шт = 11 400₴

Дим страйкбольний M18 White
105₴ × 60шт = 6 300₴

Разом 28 500₴

🔗 Банка
send.monobank.ua/jar/AeXQ6YRf2X

💳 Карта
5375411202918178

Дякую за кожну гривню і цьом вам у лобіка!

P.S. У мене вже є на руках відеозвіти з попередніх зборів на РЕБ та на Mavic, дістанусь хати — викладу.

Ну, тестування так тестування. В коментарях підказали розказати про good enough test.

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

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

Так от, що тестую? Критичні точки. Я не покриваю 100% коду тестами, це безглуздо. Зазвичай я тестую happy path і unhappy path. А едж-кейси покриваються окремо, в разі, якщо зловлять якусь багу. У нас взагалі практика така — зафіксав багу, додав тест.

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

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

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

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

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

Якщо я тестую свій хук, мої тести не мають перевіряти інші хуки, вони їм мають довіряти. Якщо я тестую UI-компонент, я маю перевірити чи все на місці, і чи все натискається.

Умовно, якщо у мене в компоненті кнопка, яку натискаєш, і там щось показується, то я тестуватиму це так:

На рівні стейту: чи зміниться фінальний стан після виклику певної функції;
На рівні UI:
1. Чи викличе кнопка певний колбек
2. Чи покаже юайка певний елемент, якщо у вхідному стані є відповідне значення

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

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

Зокрема після останнього оновлення Cursor та ChatGPT мені довелось переробляти інструкції, і все одно ця жалізяка продовжує ігнорувати певні вказівки. Наприклад, у мене чітко прописано "НЕ МОКАЙ НІЧОГО, СКАТИНЯКА", але воно мокає ВСЕ. Доводиться руцями чистити. Але то таке, приїду, займусь тим питанням, буду тюнити далі.

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

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

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

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

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

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

То як, 👍 чи не 👍?

🔗 Банка
send.monobank.ua/jar/AeXQ6YRf2X

💳 Карта
5375411202918178

Там 8,5к лишилось зібрати

Ну та шо ж, шукайте мене тут, пофоткаємось-пообіймаємось ;)

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

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

Чому? Даю маленьку підказку: Лондон із зе кепітал оф Ґрейт Брітан.

Все, побіг робити роботу, будьте чемні.

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

Ну типу щоб замість "Ой, так всьо було добре, ой так добре, ти така няшечка, така бусінка, […купа тексту…], але ми рухаємось з іншим кандидатом" було прямо — "Ви не пройшли. Ось фідбек від інтерв'юєра. Гарного дня, успіхів".

Розведіть якогось срачика в коментарях, поки я тут намагаюсь всі справи позакривати перед завтрашнім етером зі співбесідою, про яку ви ще нічого не знаєте ;)

До речі, долучайтеся до чату
для обговорень напряму: @babichdevchat

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

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

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

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

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

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

@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

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

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