Next.js fallback 'blocking' 🧱

На проєкті ми використовуємо Next.js і деплоїмо застосунок на Vercel. І в певний момент проєкт перестав деплоїтись на сервер (при тому, що build проходив без проблем). Жодних деталей помилки ми знайти не могли, просто unknown error. Найвеселіше те, що спроба збілдити і задеплоїти старіші коміти теж викидала помилку.

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

getStaticPaths дозволяє повернути параметр fallback, який може бути false, true або "blocking". Якщо ви повернете false, тоді всі шляхи, які не повернулись з цієї функції будуть повертати 404. А от якщо повернути "blocking", то Next.js спробує зарендерити цю сторінку при першому запиті, і у разі успіху, збереже її у кеші. Отож, тепер ми генеруємо невелику кількість сторінок, проте, як тільки хтось спробує відкрити сторінку, яка ще не згенерована, але дані для якої існують, Next.js одразу створить все необхідне.

#experience

Короткий відгук про Ghostty 👻

В цілому я задоволений і, швидше за все, буду використовувати його як основний (до цього я використовував WezTerm).

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

theme=catppuccin-mocha
font-family=Monaspace Krypton Var
font-variation=wght=300
window-padding-x=0
title=" "
macos-titlebar-proxy-icon=hidden
cursor-style-blink=false
shell-integration-features=no-cursor
keybind=cmd+t=unbind

#experience

Nix ⚙️

Минулого року ми відкрили для себе Nix. Спочатку було важко зрозуміти, що це таке, але воно виглядало досить незвично, тож ми вирішили дослідити, як це можна використати.

Nix — це інструмент для менеджменту пакетів і налаштувань. У нашому розумінні це ціла екосистема, адже тут є своя мова, застосунок та навіть операційна система. Якоюсь мірою це схоже на npm та package.json у JavaScript чи venv у Python.

Щодо NixOS — це операційна система на основі Linux, створена на базі менеджера пакетів Nix. Фактично вся система може бути налаштована та (головне!) відтворена за допомогою певного набору конфігураційних файлів.

Ми поки що тільки пробуємо його використовувати — наразі встановили лише на Raspberry Pi. У планах також налаштувати систему на macOS за допомогою nix-darwin. Має вийти доволі цікаво, адже тоді за допомогою кількох файлів можна буде відтворити всі налаштування на іншому комп'ютері.

Можливо, хтось із вас уже використовував Nix? Діліться своїм досвідом! 💛

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

#experience

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