Лига программистов

AppWrite, SupaBase, Directus, Strapi - не понравились

AppWrite

Есть всё, кроме массового импорта. Мощнейшая вещь.

Но настройка его сложна для новичка, и жрет о 2-4гб оперативки на сервере.

SupaBase

Крутая штука, не допёр как сделать авторизацию 🤣

И тоже с настройкой были траблы.

Плюс мне не нравится HTTP Basic Авторизация по захардкоженным credentials в конфиге прокси сервера.

За то импорт и экспорт нормальный есть

Directus

Очень крутая штука, особенно его Flows.

Стал сильно продуманнее за прошедшие полгода с моей встречи с ним.

Но все так же документация меня вымораживает. Много не раскрытых тем, и скрытых, не упомянутых ограничений.

Например условная нода логики в тех же Flow - не поддерживает тупую проверку входных данных на их наличие... Не уверен что мне когда-либо понравится это. И так же во flows много других ограничений, хотя задумка улетная.

В остальном это комбайн для супер быстрого старта, толком даже без настроек, всё мышкой можно сделать.

Ограничения так же можно обойти, сделав простое расширение, я так пол логики в прошлом проекте сделал, но теряется весь шарм легкости и наглядности. 🥲

Думаю ребята в нужном направлении двигаются, и их время просто ещё не настало, держу звезду на гитзабе за них.

Strapi

HeadlessCMS, да. Крутая, да. Популярная? А вот хз-хз.

Вроде раньше много где встречал про неё статьи, и на гитхабе звезд куча насыпано.

НО КАК? Как может не быть у такой популярной CMS функционала для импорта/экспорта, хотя бы банального!?

Он справделивости ради есть в официальном маркете расширений, но... На прошлую версию 😖 Не без обратной совместимости 😩

Ну я его тоже оставил откисать.

FilamentPHP

Тяжелая артилерия из TALL Stack компонентов и не то что целой системы, а уже целой ЭКОсистемы для любого рода панелей, да еще и на базе Laravel 😤

Ну это козырь был.

Я пытался, честно, вот даже описал что меня останавило, и на каждый из вариантов я потратил минимум 4 часа времени.

Думал ребята допили свои проекты, обещающие супер быстрый старт, но везде какие-то проблемы...

В итоге я все же снова взял в работу этот стэк для бэка. Нельзя на нем не сделать бэк. Ну нет ограничений, сколько бы я не придумывал.

Меня просто удивляет продуманность этого Filament. Баги есть, не без них, конечно. Как оказалось без ошибок ни то, что люди, роботы не справятся 🙃 (Отсылка к нейросетям)

Тут я за пару дней уложился извернуться и не сорвать сроки, а сделано:

• Админка

• Бизнес логика

• Token Based Авторизация по API
  (пришлось потратить полдня, чтобы разобраться в этой теме, так как я её намеренно игнорировал последние 3 года)

• API c аутентификацией по токену

• Расширение для хрома на WXT + React (TanStack Router, Query, Store)

• Для расширения хромовского - я вообще только с WXT работал и голым React, чисто для верстки.

К сожалению - опять не пригодился Background скрипт, так что всё ещё познать вполне не удастся разработку расширений...

Но с TanStack я не работал. Как-то раз для крипто проекта пытался его настроить и за целый день - так и не вышло. Сейчас же скажу - это мастхэв! Очень крутая штука!

Ну и отказался от Tailwind и SCSS в пользу CSS Modules в паре с clsx. И я не сказал бы, что стили писать долго. В моем случае я заказы беру вообще без дизайна и предпочтений, так что 50-80% от них пишет нейросеть, а я просто не претендую на произведение искусства 😆

Кто работал с этими комбайнами, опишите свой опыт, мб я чего не догоняю...
Конкретно с AppWrite - разбираться не стал в силу ограничения по срокам, а supabase по инерции последним выбыл.

Фича A -> 3 дня

Фича B -> 1 день

Дело в том, что тестирование очень часто находит ошибки в новой фиче, что вызывает еще один цикл исправлений (дополнительный Dev Effort), и еще один цикл тестирования/перетестирования. И чем больше объем тестирования конкретной фичи, тем дольше цикл перетестирования. А чем более сложная фича (не равно емкости Dev Effort), тем больше циклов исправлений и перетестирования ожидается.

Можно предложить укладывать циклы тестирования и перетестирования в изначальный Dev Effort в Story Points, но Capacity команды Тестирования не входит в команду Dev, поэтому так не получится.

Поэтому мы решили попробовать следующий подход. Команда тестирования на стадии прототипирования фичи (до начала разработки), пишет предварительные тесты для покрытия этой фичи, и должна давать отдельную оценку Test Effort, включающую риски по возможным багам, и их переработкой.

Чтобы эту оценку не путать и не складывать с Dev Effort, мы решили сделать ее не цифровой, а символьной, в размерах маек S, M, L, XL.

Мы долго думали, должна ли шкала оценки быть нелинейной (фибоначи например), как Dev Effort в Story Points. И решили, что в этом не необходимости. Дело в том, что заказчик (PM), хочет знать, когда он получит фичу в Прод, и при планировании спринта у него есть выбор, состоящий из Dev Effort и Test Effort, который либо "влазит" в спринт, либо нет. Тогда при планировании сразу понятно, что с большой вероятностью будет доставлена, а что потребует больше одного спринта.

Получилась вот такая схема:

То есть, чтобы впихнуть L фичу, надо отдать ее тестировщикам в конце первой недели спринта. Для M, S во вторник, четверг второй недели соотеcтвенно. Для XL зарелизить в рамках одного спринта шансов нет!

А как у Вас с этой проблемой?