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

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

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

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

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

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

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

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

#experience

Aerospace Script 🪟

Window manager — це програма, яка керує вікнами ваших застосунків: їхнім розташуванням і розміром.

Серед таких програм (або схожих до них) можна виділити:
- Linux: i3, Hyprland;
- MacOS: Magnet, Rectangle, Yabai, Amethyst.

Зараз я тестую Aerospace. І в один момент я зрозумів, що мені дечого не вистачає.

#how_to втикати відосіки під час роботи, якщо у вас один монітор: двічі натискаєте праву клавішу на відео в YouTube та натискаєте Picture in Picture.

Проблема в тому, що через використання WM я розділяю вікна на різні воркспейси, а вікно Picture in Picture залишається тільки на одному з них. Оскільки fixed-режиму для вікон немає, єдиний варіант — змусити вікно автоматично переміщуватися під час зміни воркспейсу.

Ось як це зробив я:

exec-on-workspace-change = [
  '/bin/bash/', '-c',
  'aerospace move-node-to-workspace --window-id $(aerospace list-windows --monitor focused --app-bundle-id com.google.Chrome --format "%{window-id} %{window-title}" | awk "\$0 ~ /Picture in Picture/ {print \$1}") $AEROSPACE_FOCUSED_WORKSPACE'
]

#experience

Я тепер Vibe coder 💅

Нещодавно @Yurets7777 розповідав у чаті, що замовник хоче почути пояснення від тих, хто не використовує Cursor: як вони планують залишатися такими ж продуктивними, як ті, хто працює з ним?

ШІ настільки швидко розвивається, що важливо навчитися ефективно ним користуватися. Тож я вирішив спробувати й встановив Cursor, зараз тестую Free Trial.

Перше, що варто відзначити: Cursor побудований на базі VS Code. Тому, якщо ви працювали у VS Code, звикнути до нього буде легко. Передбачено імпорт налаштувань, хоча у мене виникли труднощі з перенесенням профілів. У VS Code я використовував різні конфігурації для різних проєктів, але перенести їх у Cursor не вдалося. Я спробував вручну відтворити налаштування, але зіткнувся з іншою проблемою: при відкритті не-default профілю всі параметри постійно скидалися. Загалом, останнім часом я працював у Neovim, тому перехід дався непросто.

Ще не до кінця розібрався з робочим процесом у Cursor. Тут є кілька режимів (chat, agent…), і підказки буквально вискакують на кожному кроці, навіть коли їх не просиш. Поки що ретельно перевіряю кожну зміну, яку він пропонує, і досить часто доводиться вказувати, що виправити. Також не до кінця зрозумів, як краще з ним працювати: давати одразу велику задачу й доопрацьовувати її частинами чи самому продумувати загальну схему, а потім просити імплементувати окремі шматки?

Загалом, враження поки змішані. Для мене ШІ — це інструмент, яким можна користуватися, але точно не той, що зробить усю роботу за мене. Водночас здається, що Cursor (разом із Windsurf, Trae та іншими) задає правильний напрямок. Vibe coder-ом я поки точно бути не хочу, але намагаюся знайти оптимальний спосіб інтеграції ШІ у свій робочий процес.

Подивимося, як ця технологія розвиватиметься далі.

А ви вже тестували щось подібне? Діліться враженнями! 💛

#experience

NixOS config 🔩

Раніше ми вже трохи розповідали, що таке Nix.

Мені було цікаво попрацювати з цим, і, нарешті, знайшлось трохи часу. Щоб не мучити Raspberry (бо на ньому зараз Pi-hole), я створив віртуалку і тестую все на ній.

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

1. Придумати, як нормально поставити .config/. Швидше за все, треба буде просто клонувати git-репозиторій, але потрібно ще розібратись.
2. Налаштувати GUI. Хочу спробувати i3 - чув про нього багато, але жодного разу не користувався.

Після цього думаю буде достатньо практики, щоб перенести це і на основний компʼютер. Загалом, поточний прогрес можна глянути тут. Багато натхнення і "позиченого" коду від Mitchell Hashimoto.

А якщо комусь цікаво або хтось уже мав справу з Nix - буду радий обговорити ⬇️

#experience

Як передати проєкт? 🎁

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

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

2. Передача доступів.
Тут усе просто: ми надали повні доступи до всіх сервісів і впевнились, що нові розробники змогли ними скористатися.

3. Коротка документація.
Чому коротка? Бо в нас її майже не було 🙂 Ми описали ключові речі: які фреймворки, бібліотеки та методи стилізації використовуються, як працюємо зі стейтом, формами, базою даних. Додали інформацію про інфраструктуру: де сервери, як білдиться проєкт, який сервіс відповідає за авторизацію тощо.
Окрему увагу приділили відомим багам, ризикам, технічному боргу, а також запропонували кілька ідей для покращення. Чесно кажучи, знаючи, у що це все виросте — ми б будували проєкт зовсім інакше 😅

4. Handover session.
На окремому дзвінку обговорили ключові частини проєкту та пояснили, на що звертати увагу. Зокрема, зараз у застосунку є waitlist, який частково потрібно обробляти вручну.
А ще це була просто тепла розмова з командою, яка підхоплює розробку. Ми раді завершити участь на хорошій ноті 💛

#experience