Агов агов! Ми трішки пропали, але сподіваємось, що ви ще нас не забули! 💛

Сьогодні хочемо поділитись розширеними типами (utility types) в TypeScript, які вам точно стануть у пригоді! Дану тему найкраще розповісти за допомогою прикладів, тому написали статтю в зручному форматі!

Читати статтю

Пссс: чекаємо в коментарях утиліти, які не були згадані в статті, але ви їх знаєте і використовували!

Що таке SyntheticEvent?

Різноманіття браузерів може підловити вас у будь-який момент. Наприклад, коли вам потрібно обробити клік користувача по кнопці. Адже навіть події (Event) можуть відрізнятись у різних браузерах.

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

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

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

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

Читати документацію

#interview

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

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

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

Розповідати можна багато, але краще просто спробуйте.

Відкрити Project Manager
Відкрити Bookmarks

#tips

Як часто вам приходиться працювати з регулярними виразами? Думаю, не часто, але shit happens і деколи проект змушує вас написати декілька регулярок для валідації або з інших потреб. Не сумуйте. Звісно, є Stack Overflow, де ви зможете знайти готові (я не вірю, що хтось пише їх власноруч). Але ми ще хочемо поділитись з вами крутим сайтом, де ви зможите протестити регулярки. Редактор підказує, де помилка у вашому записі і розписує, що означає той чи інший символ. Також даний сайт має багато інших приколюх, тому зберігайте і користуйтесь!

Відкрити сайт

Успіхів 💛

#tips

Repository types

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

Серед наявних підходів можна виділити три:

- Monorepo - весь код зберігається в одному репозиторії. Зазвичай в кореневій папці є кілька вкладених, де власне вже розділені всі частини проекту. Цікаво те, що деякі великі компанії (такі як Google) з величезними проектами використовують саме monorepo.
- Polyrepo - це коли для кожної частини проекту свій репозиторій.
- Hybridrepo - це мікс обох підходів. Наприклад, мобілка та веб в одному репозиторії, а бекенд в іншому.

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

Monorepo може добре працювати з залежностями, адже при правильому управлінні можна шарити одні і ті ж бібліотеки між різними частинами. Те саме стосується і самого коду. Якщо у частинах проекту використовується одна мова програмування, велика ймовірність, що у вас буде якийсь спільний код. Існують навіть спеціальні інструменти для ефективнішої роботи з monorepo, наприклад, turborepo (дуже багато repo 😄).

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

А якому способу віддаєте перевагу ви? Особисто мені більше подобається розділяти проект на кілька репозиторіїв.

Turborepo in 2 minutes

#experience

Що таке Git Hooks?

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

Git-хуки (або гачки) створені десь для цього. Вони виконують користувацький скрипт перед чи після певної події, наприклад, pre-commit, pre-push, post-commit.

На співдесідах часто можуть запитувати, яке ж практичне застосування цих речей. І особисто мій улюблений підхід - це використання pre-commit та pre-push.

Налаштовувати їх дуже зручно за допомогою husky. Ви можете просто вказати команду на певний хук, а файли вже генеруються самі. На pre-commit я люблю запускати prettier для форматування та eslint для пошуку проблем у коді. А щоб не проганяти ці речі через увесь проект, додайте lint-staged, щоб робити це тільки у файлах, з якими ви працюєте. На pre-push я віддаю перевагу запуску тестів, які вже запевнять, що, як мінімум, ви нічого не зламали.

Все описане вище було для JavaScript середовищ. А тут є інструмент для загальних рішень - pre-commit. Хоча, якщо трішки почитати, можна все зробити вручну.

І ще, по секрету скажу, що можна пропустити запуск цих хуків, якщо додати --no-verify до своєї команди. Тільки ніколи так не робіть, а якщо і зробите, то нікому не розказуйте 😉

Читати більше

#interview

#todo поділитись улюбленим мемом, пов'язаним з ІТ 😉

Як естімейтити правильно?

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

Давайте розберемо деякі з них:

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

Не недооцінюйте маленькі таски. Навіть заміна тексту не займає 5 хв. Ну фактично так і є, АЛЕ потрібно створити нову бренчу, виправити той самий текст, перевірити чи в правильному місці ви це зробили, закомітити, запушити, створити PR, почекати поки хтось апрувне і вже потім померджати. Тепер не виглядає таск на 5 хв?

Розбивайте таски якомога детальніше. Якщо таск займає більше певного часу (зазвичай, він обговорюється на проекті), його треба розбивати. І навіть якщо вас ніхто не змушує це робити, для кращого естімейту завжди потрібно розбивати таск якомога детальніше. Наприклад, візьмемо ту саму сторінку логіну. У вас є форма, яку потрібно наверстати. Можливо, у вас немає компонентів інпута, кнопки, чекбокса, тоді їх також потрібно додати (краще за все їх винести в ui kit і запропонувати замовнику/PM зробити їх на початку, щоб потім не повертатись до таких компонент). Також потрібно додати запит і валідацію - це також можна винести окремо.

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

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

#experience

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

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

Відкрити сайт

А поки ще раз нагадуємо вам донатити на ЗСУ 💛

#tips

Що таке one-liner?

Чим менше коду - тим краще

One-liner - це короткий однострічковий код. Якщо при використанні даного підходу не втрачається простота і читабельність, то думаю, що це класне і лаконічне рішення. На Medium знайшли статтю, в якій ви можете знайти для себе кілька хороших прикладів.

Також додаємо один від себе, який досить часто використовуємо в роботі:

const fullName = (...names: string[]) => names.filter(Boolean).join(' ');

А своїм корисним one-liner діліться з нами в коментарях!

Читати статтю

#article

Чому Ви вирішили змінити місце роботи?

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

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

По-перше, можна пояснити зміну роботи побутовими проблемами: незручний графік, застарілі технології, незручне розташування офіса.

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

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

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

АЛЕ в будь-якому разі не робіть таких помилок:

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

Успіхів 💛

#interview

Prisma

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

На днях мені довелось сетапити бекенд і я стикнувся з питанням ORM.

До цього я користувався TypeORM та трішки Sequalize. Цього разу вирішив спробувати Prisma і зараз готовий поділитись першими враженнями. Поки вони тільки позитивні.

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

АЛЕ я стикнувся з однією проблемкою. Я використовую Nest.js фреймворк і так як Prisma генерує саме типи в Typescript, використати їх для валідації та генерації Swagger не вийде. Проте, здається жодна ORM не надає такого функціоналу, тому важко назвати це недоліком. З наданими типами ви з легкістю зможете створити потрібні класи.

Раджу обовʼязково звернути увагу на Prisma, адже це дійсно крутий інструмент 😉

Читати більше

Псс: а ще цікаво, чи багато у нас тут людей, яким цікава тема бекенду?

#experience