#todo знайти баг та виправити помилку 🤓

UAParser.js 🧑‍💻

Іноді буває корисно дізнатися трохи більше про відвідувача вашого веб-сайту: який у нього браузер, операційна система чи навіть сам пристрій. Багато такої інформації міститься у User-Agent, і її можна отримати як на клієнті, так і з HTTP-заголовків запиту.

Але навряд чи ви захочете вручну розбирати щось таке:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36

Бібліотека UAParser.js допоможе вам розібрати User-Agent і витягти інформацію про браузер, процесор, пристрій та операційну систему.

👉 Відкрити посилання

#library

Welcome!

Let's practice our English! So...

❤️ How do you plan to spend Valentine’s Day?

Have a nice #english_friday ❤️

#how_to увімкнути автоформатування коду.

👉 VS Code
👉 JetBrains

WebP to PNG 🥴

У нашому проєкті виникла потреба генерувати PDF-файли. Для цього ми використовуємо бібліотеку react-pdf - інструмент для створення PDF. Працювати над таким типом завдань — це ще той квест, тому краще оминайте такі задачі.

Нам потрібно вставляти динамічні зображення (на даний момент підтримуємо лише JPG, PNG та WebP). Ми розчарувалися, коли виявилося, що PDF не підтримує формат WebP, а обробка таких зображень була надзвичайно необхідною.

Тому ми обрали, мабуть, найпростішу та найшвидшу стратегію — відмалювати WebP-зображення на canvas і отримати з нього PNG. Виглядає код приблизно так:

function toPNGUsingCavas(src: string) {
  const image = new Image()

  const { promise, resolve, reject } = Promise.withResolvers<string>()

  image.onload = function () {
    const canvas = document.createElement('canvas')
    canvas.width = image.naturalWidth
    canvas.height = image.naturalHeight

    const context = canvas.getContext('2d')
    if (!context) {
      reject(new Error('Could not get canvas context'))
    } else {
      context.drawImage(image, 0, 0)
      resolve(canvas.toDataURL('image/png'))
    }
  }

  image.onerror = reject

  image.src = src

  return promise
}

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

#experience

Sunsetting create-react-app 👋

Закінчилася ціла епоха! Найпопулярніший спосіб створення React-застосунків від минулої п’ятниці офіційно вважається застарілим. Команда React ухвалила таке рішення, оскільки create-react-app має обмеження, які вже вирішені в багатьох інших інструментах.

Цікаво, що саме в п’ятницю @Yurets7777 написав у чаті, що помітив, як create-react-app не спрацював.

Пишіть у коментарях, яким способом тепер будете створювати React-застосунки!

👉 Відкрити посилання

#news

#todo написати функцію на будь-якій мові програмування, яка приймає об'єкт/словник/map, де:
- ключ — текст,
- значення — число або вкладений об'єкт/словник/map за тим самим правилом.

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

Наприклад:
{ "a": { "b": 1, "c": 2 }, "d": 3 } => { "a.b": 1, "a.c": 2, "d": 3 }

PS: вважаємо, що однакових ключів не виникає.

Welcome!

Let's practice our English! So...

👉 What’s the best or worst piece of tech advice you’ve ever received?

Have a nice #english_friday 💛

📩 Відправили листа – а потім згадали, що не прикріпили файл? Або випадково надіслали клієнту замість файлу з комерційною пропозицією мемчик з котиком? 🐱

На жаль, У Gmail немає чарівної кнопки "Редагувати" чи "Видалити", але можна додати невелику затримку перед відправкою. Це ваш шанс передумати та виправити помилку.

#how_to додати затримку перед відправкою електронного листа в Gmail:

1. Натискаєте іконку налаштувань;
2. Натискаєте кнопку "Переглянути всі налаштування";
3. Шукаєте "Скасувати надсилання";
4. Змінюєте значення на 30 секунд.

Тепер у вас буде час врятувати свою репутацію – або хоча б уникнути фейспалму від власного ж листа 😅

Сьогодні три роки, як Україна бореться за своє майбутнє. Три роки болю, втрат, мужності й незламності. Ми не будемо багатослівними – просто подякуємо.

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

Цей день болючий, але він про силу. Про тих, хто не здався. Про Україну, яка вистоїть!

#todo написати функцію, яка приймає масив об'єктів і рядок key. Функція має повернути масив, у якому залишаться лише перші унікальні об'єкти за значенням переданого ключа.

Наприклад:

[
  { id: 1, name: "Alice" },
  { id: 2, name: "Bob" },
  { id: 1, name: "Charlie" }
]
"id" =>
[
  { id: 1, name: "Alice" },
  { id: 2, name: "Bob" }
]

Welcome!

Let's practice our English! So...

👉 Would you rather work remotely forever or always in an office? Why?

Have a nice #english_friday 💛

git config --global user.name "Linus Torvalds"
git config --global user.email "torvalds@linux-foundation.org"

#how_to підписати commit за допомогою GPG-ключа 🔑

👉 Відкрити коротку інструкцію
👉 Відкрити детальну інструкцію від GitHub

PS: Ми не збираємо жодної інформації про вас і, тим більше, нікуди її не передаємо (як хтось міг подумати, @Yurets7777). Нам просто цікаво більше дізнатися та краще зрозуміти людей, які тут зібралися 😅💛

"Неофіційні" правила в команді 👀

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

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

2. Ділити завдання на менші частини.
Оскільки це стартап, таски бувають дуже різними — від "підправити стилі таблички" до "розробити мобільний застосунок". Якщо завдання велике, намагаємось розбити його хоча б на backend і frontend або на окремі модулі. Адже якщо PR містить 100+ змінених файлів, його дуже складно перевірити — це займає купу часу, а якість рев’ю від цього тільки страждає.

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

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

Розкажіть, які "неофіційні" правила є у вас у команді? 💛

#experience