thislike.me
32 subscribers
173 photos
67 videos
8 files
300 links
В общем и целом, так как приходится пересылать информацию из разных источников, решил делать это здесь. Все что мне интересно, буду публиковать в нем
Download Telegram
Шпаргалка по паттернам

Источник - добрый человек перевёл на русский язык
https://www.appsmith.com - интересное low code решение, можно развернуть у себя

пару кейсов
- можно сделать админку для своего решения имея в наличии только бекенд api или даже вообще без него, сразу делать запросы напрямую в базу данных
- сделать прототип проекта, убийцу calendly например
- различные бекофисные приложения для учета или дашборды

имеет много интеграций
pocketbase.io - это серверная часть с открытым исходным кодом, состоящая из встроенной базы данных (пока что только SQLite) с подписками в реальном времени, встроенным управлением пользователями, удобным пользовательским интерфейсом панели инструментов и простым REST-API.

для меня это как раз то чем хотелось заменить strapi, потому что реализовано на go

можно использовать как готовое решение или встраивать в свое приложения

интересно будет последить за развитием этого решения 👍
https://github.com/inbucket/inbucket - сервис тестирования электронной почты, написан на go. Встроены HTTP, SMTP, POP3 и хранилище.

кажется ранее в нем были проблемы с кодировкой из кириллицы...возможно проблема уже исправлена
https://github.com/adnanh/webhook - легковесный сервис вебхуков для запуска shell скриптов, написан на го, есть так же в облачном варианте

но это не все...

https://github.com/hookdeck/hookdeck-cli - замена ngrok от той же команды
🔥1
https://www.youtube.com/playlist?list=PLDyvV36pndZFHXjXuwA_NywNrVQO0aQqb - слегка "продвинутый" курс по Git
репозиторий на основе которого можно быстро реализовать crud роуты

gin, gorm (postgres),swagger уже в коробке

подойдет когда надо за час подготовить что то на коленке....

https://github.com/ElegantSoft/go-crud-starter
🤔 Сколько орехов нужно собрать, чтобы получилась целая куча?

Парадокс кучи - это логический парадокс, сформулированный Евбулидом еще век до н.э

в одном известном советском мультике герои хорошо разгоняют эту темы https://www.youtube.com/watch?v=sDRJhAWMRIM

- Десять это куча?
- Да! Десять это куча
- А два?
- Два, это мало...

и в итоге приходят к выводу...
- Куча - это когда ешь, ешь, больше не хочешь, и ещё осталось, а если не осталось - то это не куча...

А в одном посту выдвинули теорию:
- Куча не может быть плоской! Любое множество предметов не может являться кучей, не зависимо от их количества, пока они находятся в пределах одной плоскости.

Ну и разбор ситуаций уже в плоскости разработки и межсервисной архитектуры. Было разработано 5 взаимодействующих между собой сервисов, участвовал в этом лишь один разработчик. В таких условиях 5 это будет куча. Но если команда бы состояла из 10 разработчиков, 5 сервисов уже не выглядят как кучей, куча тут количество участников в команде 😅
🔥1
Про CustDev - есть интересная история про проверку гипотезы

Часть 1.
Однажды участвовал с командой разработки в интенсиве где надо было реализовать некий предоставленный заказчиком функционал. Нам попался Авито, у них было желание на старте пандемии внедрить функционал видеозвонков в свои объявления, ну типа так будет безопасно для продавца и покупателя, время не будут тратить, вроде все причины которые были на сказаны

наставник команды как раз предложил вообще первое время отказаться от желания начинать реализовывать функционал, а провести как раз исследование, и если получиться протестировать выдвинутые гипотезы

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

опросы проводили на своих, было порядка 200 респондентов, результаты по верхам:
- многие не готовы звонить по видеосвязи, из опрошенных 15-20% согласились что возможно попробовали бы этот функционал.
- новые гипотезы были найдены, но их реализация была интересна малому кругу лиц, и была дорога по времени для внедрения (деловой костью, как маски в видеосервисах, для например собеседований 🤷‍♂️)
👍1
Часть 2.
Все таки было решено еще провести тестирование гипотезы:
- создать несколько объявлений, продавали собаку, квартиру, холодильник, макбук за очень низкую цену чтоб больше звонков словить )))
- в объявления писали что готовы показать товар по видеосвязи, об этом просили сразу написать в сообщении если готовы посмотреть, чтоб не тратили сове и мое время
- договорились что если кто то нам пишет и готов созвониться, надо добить его по нашей механике и кинуть ему ссылку на аля https://calendly.com/ где будут указаны свободные слоты чтоб пользователь там это указал

результаты:
- в основном люди говорили нет, давай я сейчас приеду и прям сразу заберу
- на звонок согласились человек 10
- 5-6 все таки даже смогли забронить время в сервисе
- и в назначенное время созвонились лишь 3е
👍1
Часть 3.
В итоге мы реализовали минимальный функционал, но заявили что видеозвонки вообще не нужны на площадке объявлений типа Авито

И вот результат спустя 2.5 года, такое есть у них в объявлениях, вот как оно выглядит

типа да, продавец готов показать по видеозвонку, только вы там сами как-нибудь это обсудите между собой
👍1
Порылся в своих конспектах по этой теме:
1. Риск ценности. Продукт должен решать какую-то задачу и не быть бесполезным. (пример - провальная копия "фейсбука для своих") (в нашем кейсе - маски точно не нужны).
2. Риск юзабилити. Стоит делать некоторый определенный набор минимальных функций. Сделать полностью жизнеспособный продукт - скорее всего мы не успеем. Но при этом нужно сделать чтобы было понятно как использовать этот продукт. Для чего на какую кнопку нажать.
3. Технический риск. Мы ограничены во времени. Не стоит включать очень сложные технологии. Мы должны уложиться в период времени, который нам выделен.
4. Риск бизнес-модели. Если что-то разрабатываем - нужно разбираться в этой сфере. Например, чтобы не засудили. Работа с персональными данными. Другой риск здесь - финансовая составляющая. Сервис должен быть окупаемым.
👍1
Не говорите о своем продукте в том плане что - "вы хотите эту фичу?" В ответ скажут - "О, круто". Вы воспринимаете как похвалу и потратите кучу времени на что-то бесполезное.

Не давите на собеседника. И опрашивайте тех кому это интересно.

Решит ли мой продукт проблему?

"Полюбите плохие новости". Когда клиент критикует - это хорошо, потому что вы еще в процессе разработки, а не закончили продукт. Клиент почувствует своё участие.

Фича полезная - забронировать видеозвонок. Возможность отложенного вызова. Указание времени для видеозвонка. "Мне удобно показать товар - с 19:00 до 23:00"

Продукт нужно выпускать не на всю клиентскую базу сразу.

Оценка фич. Два варианта.
1. Простой график (по осям простая-сложная и ценная-не ценная). Оценивать следует командой от 1 до 5.
2. Через экселевский файл.
👍1
https://autostrada.dev сервис, с помощью которого можно легко сделать готовый каркас проекта для JSON API или веб-приложения на go...находится в стадии открытого бета-тестирования и активной разработки...

сразу можно получить сервис с авторизаций, сессиями, миграциями, отправкой писем на почту
https://loom.com - сервис для записи видео с экрана и говорящей головы 😂 позиционирует себя как решение для отмены совещаний, не надо собираться чтоб всем что-то показать или провести специальное демо, включил, записал, и отправил ссылку на видео.

из кейсов:
- провести маркетинговую демонстрацию, когда надо ее сделать на определенную организацию и только под нее
- пошарить примеры инженерии, записать видео с запуском сервиса например
- записать видео бага
- асинхронные встречи команд

есть ряд аналогов https://clickup.com/blog/loom-alternatives/

хороший вариант для стартапа в текущих условиях 🤔