Проект: Microboard.io — доска для рисования в Jira  Публичный пост
26 января 2021  2438
Microboard.io - доска для рисования в Jira

В чем суть?

Рисовалка бордов типа Miro в виде плагина для Jira.

Откуда все пошло вообще?

Все началось с того, что я поставил Miro у себя на работе. Просто, чтобы рисовать схемки.
Никто не знал, что эта софтина нас так засосет. Прошел год и мы в ней накрепко погрязли.
Если раньше было ноушн, то по прошествии полугода все на него забили и начали клепать себе доски, доски досок, карточки на досках. Созваниваться с досками, делать презы на досках и вести на досках трекинг задач.

В общем, вляпались в это хуже некуда.

Все бы ничего, но меня всегда смущали две вещи:

  • Дороговато. Хотя это такое: раз используем, значит оптимально, тут им прям респект, умеют отжимать деньги. Но все равно дороговато на уровне всего остального.
  • Хреновый функционал для проектного менеджмента и прочих айтишных ребят в больших компаниях. Мы не смогли полноценно проинтегрироваться с джирой, поэтому гонять туда-сюда таски это прям боль. Формально интеграция существует, но много кривых сценариев и общее ощущение, что это сделано на отъебись. В итоге нам пришлось оставить такие богомерзкие плагины как structure и portfolio и платить за них дополнительно, хотя я бы с радостью с них съехал, если бы miro включала в себя подобный функционал.

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

Пока в какой-то ясный летний послековидный день не наткнулся на пост Miro в блоге о том, что у них более 5 млн пользователей. В голове сразу сработал калькулятор. Взяв средний чек в 10$ и долю платящих в 20% я вывел, что они делают 10m MRR на изи, а скорее всего намного больше (MRR - monthly recurring revenue).
Т.е. в месяц это та сумма, которую я вряд ли могу заработать за жизнь, даже если буду великолепным и успешным продакт менеджером.
И вообще, это де-факто лярдовая компания уже сейчас, хотя они публично это не светят и вообще, стараются не выпячивать свой успешный успех.

ЗАВИСТЬ

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

И тут встал первоочередной вопрос.

Нет, не то, как сделать. Сделать это дело техники.

Как это продавать?

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

Значит нужно искать нишу

И тут же возникла следующая мысль.

Что если сконцентрироваться на интеграции всего этого безобразия с джирой? Закрыть потребности кровавого энтерпрайза разной степени кровавости, в котором я живу всю сознательную жизнь?
Распространяться через стор джиры и всяких сисадминов.

Здесь можно конкурировать пиаром, а не развесистыми маркетинговыми бюджетами, плюс какими-то уникальными фичами для отдельных крупных клиентов.
Т.е. оставить хипстерам, учителям и прочим домохозяйкам рисование на доске типа по приколу - пусть все пользуются миро.

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

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

До кучи, я знаю как минимум несколько человек из разных банков, которые не могут использовать миро, т.к. оно хостится только в амазоне и не может быть размещено в их приватном облаке. Им бы тоже, наверное, зашло.

В общем, нормальная гипотеза. Рабочая.

Дальнейшие азы продакт-менеджмента учат тому, что нужно пойти фигачить проблемные интервью, или рекламу там дать и половить лидов. В b2b это та еще задачка.
Поэтому к счастью, у нас обнаружился конкурент, который пронюхал ту же самую модель раньше нас и мы решили действовать иначе. "К счастью?" Я упоролся? Вовсе нет, сейчас объясню.
Знакомьтесь - Whiteboards for Jira

Они уже в продакшене и делают примерно то же самое, что подумалось сделать мне. Релизнулись в августе 2020 года.

Почему же наличие конкурента это счастье? Дело в том, что теперь не нужно тестировать спрос самим. Без лишних телодвижений нам стали более менее понятны базовые показатели спроса и монетизации.
Достаточно посмотреть число их платящих клиентов, оно открыто - 263 штуки на момент написания статьи (чуваки уже не в бете и эти клиенты платят им каждый месяц). Если в среднем там по 10 человек в команде, а человек стоит 2.5 доллара, то это 6,5k MRR. Ну, допустим в 2 раза меньше. Все равно будет 3к. Для старта нас устроит.

Чем же еще мне нравится этот конкурент?
Дело в том, что его продуктом пользоваться неприятно.
Он херово работает. Лагает, тормозит, не держит большого числа элементов на доске.
Все потому, что сделан на HTML, а не на canvas, как Miro. И даже при всем при этом, чуваки зарабатывают 6к баксов в месяц. А что, если сделать лучше, так и зарабатывать наверное можно больше?

Это стало рабочей гипотезой номер два.

И вот теперь уже можно поговорить о технологиях

Итак, гипотеза звучит так: сделать аналог miro для энтерпрайза который использует Jira и распространяться через Atlassian marketplace

При этом есть конкурент, который уже работает в этой нише и подтвердил спрос реальными клиентами.
И есть миллион конкурентов самой miro - т.е. разнообразные доски для рисования.

Теперь вернемся и подумаем, почему же к miro наблюдается такое привыкание. Так, что она проникла в нашу организацию и вытеснила ноушн, а ничто другое нет?

Я вижу следующие предпосылки

  1. Скорость и удобство интерфейса. Звучит слишком по-хипстерски, но это реально самая отзывчивая и удобная софтина из всех аналогичных. Совместная работа, когда изменения от других людей подтягиваются мгновенно и без проблем. Тупо приятно работать. А когда это делаешь ежедневно - это важно.
  2. Хорошие виральные механизмы (легко шарить другим людям, одновременное редактирование досок). В общем, подсел один человек -> подсаживается вся организация.
  3. Есть не только графические примитивы, но и базовые инструменты для продакт и проджект-менеджмента, а так же создания документации. Mindmap, CJM, Jira cards, Rich text.

Что же из этого нужно реализовывать в MVP, если следующая цель - загрузить в стор какую-то минимальную версию?

Пункт 3, пожалуй, мимо. Так как требует углубления в детали. У нас просто нет столько времени. Да и вряд ли он возможен без базового функционала

Пункт 2 будет обеспечиваться самой механикой взаимодействия с джирой. Сделаем то, чтобы доску можно было эмбедить в описание issue. Таким образом все кто в нее зайдут - смогут ознакомиться с плагином и начать в нем что-то делать. Используя Jira API это сделать достаточно просто.

Остается пункт 1. Нам нужно сделать базовый функционал, но чтобы им было приятно пользоваться. Так же приятно, как миро. И не так убого и лагающе, как у конкурента.

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

Что ж, это достаточная идейная база для старта.

Страх и ненависть Canvas

Так уж получилось, что я имею чутка опыта в написании вещей на канвасе, а так же в гибридных технологиях, типа canvas + react. Просто в свое время писал игрушки для веба в качестве хобби.

И то что я успел понять - канвас это быстро у клиента, но офигенно сложно в разработке. Нужно задействовать миллион хаков и самые настоящие алгоритмы (о боже), чтобы решать казалось-бы простые и стандартные задачи, типа вывода rich text.

Почитайте, как с этим развлекались в miro.

Тем не менее, если мы хотим скорости и приятности в работе, то у канваса нет альтернатив. HTML не подходит для динамической сущности досок и начинает выдавать меньше 10 fps даже в простейших случаях. На драг&дропе, ресайзе и других динамических вещах это уже начинает серьезно бесить.

При этом сейчас не обязательно все писать на голом канвасе. Для него есть высокоуровневые библиотеки, упрощающие работу. Например Pixie.
Или Konva, которую мы пока взяли за основу, так как для нее есть экспериментальная трансляция в реакт и реализация многих высокоуровневых событий.

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

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

Поиск команды

Про себя я могу сказать то, что идей у меня как у дурака фантиков. Причем встречаются вполне неплохие.

А вот времени писать код лично - нет совсем. Да и особых ресурсов тоже.

Поэтому сейчас я в принципе не начинаю каких-либо проектов, пока не найду людей, которые бы захотели это делать вместе.
А чтобы найти таких людей - просто вбрасываю идеи в разговоре, когда вижу, что человек может быть потенциально заинтересован или подходит по профилю.
Разговоров у меня в жизни много, так что это работает.
Так и тут.
В разговоре с одним знакомым , обмолвился идеей и рассказал подробности. Ему понравилось. Так у проекта появились seed инвестиции и потенциальный руководитель продаж :) Кстати, он есть в клубе

Осталось дело за разработкой. В первую очередь нам нужен был способный фронтендер, который смог бы выстроить скелет MVP приложения.
Не скажу, что найти человека было легко. Вастрик сносил наш пост, VC.ru сносили наш пост, походу вселенная подумала, что мы спамеры и продаем гербалайф. Под впечатлением, я даже написал тут длинное нытье о сложностях поиска людей.
Но каким-то образом мы все-таки отыскали к нам в команду третьего человека - Сашу.
И принялись пилить прототип. Точнее Саша принялся, а мы усиленно даем советы и хеджируем его жизненные риски оплачиваем доширак.

Чем можем похвастаться?

Пока еще мало чем. Shame on us, тут люди вон за три дня бизнесы запускают и выкидывают идеи, если не могут сделать прототип за 2 недели. Походу мы так не умеем и уже идет четвертый месяц, а мы все пилим.

Есть демка с зумом доски, трансформером текста и отсутствием сохранения состояния и синхронизации (в движке это уже есть, но с багами и не допилено).

https://alexandr-panchenko.github.io/board-builds/PLUG-47/

Вообще же, сейчас делаем MVP, в котором будет следующее:

  1. Возможность рисовать текст, стрелочки и прямоугольные примитивы, с "бесконечным" зумом и произвольным масштабированием элементов. Важное условие - не должно быть заметных глазу/мешающих лагов интерфейса. WYSIWYG для текстовых полей. В общем, смотрим как работает miro и пытаемся сделать 5% оттуда, но чтобы эти 5% были не хуже.
  2. Реализовать базовые сценарии взаимодействия с джирой. Линковка тасок, синхронизация туда-сюда, показывание снэпшотов доски в самой джире. Вот это все.
  3. Синхронизация стейта доски между клиентами в реальном времени. Чтобы два синьора могли что-то набрасывать прямо во время митинга.

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

Какие технические грабли уже успели собрать (до бизнесовых пока не добрались)

  • Рич текст на канвасе оказался реально сложным. Убили месяц и решили дальше пока не усугублять, оставив только обычный текст.
  • Сложной оказалась синхронизация стейта досок между клиентами. Мы используем библиотеку fluid от MIcrosoft. Она работает, но ловили ряд непонятных багов. Хотя в принципе - работает, уже хорошо. Пока отставили в сторону, но будем доделывать дальше.

Бизнесовая цель у нас выйти на 10к-100к MRR. По нашей оценке это должно быть реально.
Мы понимаем, какой функционал нам нужен для старта и далее. Есть деньги на еду для разработчика и на команду в дальнейшем.

Зачем этот пост?

Сюда я хочу постить апдейты, чтобы осталось для истории. Ну и получать обратную связь, если будет что показать.

Так же приветствуются мнения, что мы дураки, все делаем не так и у нас ничего не получится :) Но за конструктивные комментарии заранее спасибо.

Связанные посты
30 комментариев 👇

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

Привлекли первый раунд инвестиций.

Доску тыкать тут https://alpha.microboard.io/

За это время концепция поменялась из доски с интеграцией в Jira в доску, которая заточена под интеграции в любые сложные системы, при этом обладает UX не хуже Miro.
Короче, конкурируем на этой поляне с оупенсорсом и вполне успешно.

Если интересно подробнее - тыкните плюсик, будьте ласка, а то непонятно, интересно ли это кому-то читать, или нет :)

А вообще, ищем фронтендеров с опцией в фуллстек. Рассматриваем всех, в пределах 3к евро/300к рублей месяц гросс. Стек typescript/react/canvas/node. Фуллремоут. Кому интересно - пишите в телегу.

  Развернуть 1 комментарий

Апдейт за неделю с 25 января (хотели уже делать примитивы, но провозились с работой тачпада, корректным скроллом и масштабированием).

Слово Саше:

Написать особенное поведение браузера при масштабировании или прокручиванием содержимого - это задача, хоть и не типичная, но и не сложная на первый взгляд.
Разработка первого прототипа проходит быстро, вот он вроде-бы уже и работает, плавно масштабируется и перемещается. Все загружают его на свои разные компьютеры, с разными устройствами вместо мыши, разными операционными системами и браузерами.
И тут начинается - у кого масштаб увеличивается в 400 раз быстрее, у кого при масштабировании исчезают все кнопки, у кого совсем не работают жесты. Если разработка первого прототипа занимает несколько дней, то на решение всех возникших в нём проблем уходят недели.

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

Вот к примеру несколько относительно не сложных вопросов. Дебаггер для ответа на них не нужен. Как узнать когда пользователь крутит колесо мыши? Двигает по тачпаду двумя пальцами вверх/вниз? А вправо/влево? Двигает пальцем вдоль правого края тачпада? Вдоль нижнего края? Масштабирует щипком?

Нужно слушать события. Какие? Вот несколько правдоподобных вариантов на выбор: wheel mousewheel touchstart touchmove touchend scroll DOMMouseScroll MozMousePixelScroll msContentZoom gesturestart gesturechange gestureend MSGestureStart MSGestureChange MSGestureEnd

Лучший вариант - wheel, для всего кроме щипка. Последние 9 - не стандартные и работают не во всех браузерах. scroll мы отключим, так как экран мы прокручиваем по-своему по-особому.
Тач-события - не смотря на название, не срабатывают для тачпада, они для тачскрина, а тачпад для браузера - это как мышь, жесты на тачпаде - это прокрутка колеса. mousewheel - нестандартное, хотя 5 лет назад им все пользовались, но теперь его заменило стандартное событие wheel.

Значит слушаем мы только wheel, а как мы отличаем жесты? Читаем свойства события. Если MouseEvent.ctrlKey - значит пользователь масштабирует щипком на тачпаде. Ну или с зажатым ctrl крутит колесо мыши, двигает двумя пальцами вверх/вниз по тачпаду, двигает вдоль левого края тачпада. События в браузере такие же загадочные многозначные и открытые для интерпретации как фильмы Дэвида Линча.
Если MouseEvent.shiftKey - значит пользователь двигает двумя пальцами вправо/влево по тачпаду или двигает вдоль нижнего края тачпада. Ну или с зажатым shift делает всё, что может вызвать wheel событие. Кстати, как можно определить, что использует пользователь: мышь или тачпад? - Никак, спросить у пользователя.

Как уже видно, чтобы заметить щипок нужно слушать wheel событие, но это только для щипка на тачпаде. Если щипок выполняется на тачскрине, то нужно слушать тач-события, считать количество прикосновений и замечать изменения расстояния между ними.

Сегодняшний билд -https://microboard.io/public/trackpad.html, прикрутили корректную работу с тачпадом (выбор режима тачпад или мышь скрыт за шестеренкой справа-вверху).

  Развернуть 1 комментарий

@glebkudr, Не ожидал, что в 2021 году программисту надо смотреть, как реагирует софт на прокрутку скролла.

  Развернуть 1 комментарий

@glebkudr, интересно. Вроде же делали pointer events специально как максимально низкоуровневое апи для тач, мышки, стилусов и всего на свете.

Ещё про рич-текст на канвасе хотел отписаться — когда-то делал, показалось не особенно сложным, если речь именно про рендеринг текста с разными свойствами шрифта / underline / etc.

  Развернуть 1 комментарий

Это может полететь в варианте self-hosted, когда хочется использовать Миро, но нельзя, потому что данные окажутся где-то в неизвестном облаке.

То есть вам скорее всего имеет смысл первым делать и продвигать плагин для Jira Server и ориентироваться на те компании, где безопасники запрещают Миро, ибо всё должно быть под своим контролем. Все эти банки и т.п. Там сразу будут тысячи пользователей, а не единицы-десятки тех, кто в облачной Джире.

Потому что если Миро разрешено (у нас тоже Jira + Miro), то я не вижу смысла пристраивать какой-то очередной плагин. Вообще для Джиры почти нет годных плагинов, по моему опыту: 9 из из 10 это ограниченные поделки. Потому у меня сразу предубеждение: я лучше буду использовать полноценное Миро и ставиты ссылку в Джире на доску из описания тикета или даже из отдельного поля и это будет good enough. Зато я использую полноценный Миро и не заморачиваюсь с очередным корявым плагином.

  Развернуть 1 комментарий

@zahhar, ставиты ссылку в Джире на доску из описания тикета

Конечно, в итоге все так и делают. И даже карточки линкуют. Но это супер-неудобно. И миро стоит в 2 раз дороже, чем сама джира :) Поэтому даже при наличии миро, в джире есть ему конкурент.

А так да, основная мысль на рост - попробовать залезть в энтерпрайз. Единственный нюанс - прямо сейчас джира останавливает поддержку серверной версии и аппов для нее. В 2021 году и далее будет только датацентр + облако. Нужно еще будет поресерчить наши возможности в этом аспекте.

Вообще для Джиры почти нет годных плагинов, по моему опыту: 9 из из 10 это ограниченные поделки

Знаю несколько команд, которые при этом делают на них от 100к до миллиона долларов в год. Понятно, что это микробизнес, но и даже это уже приятно :) У нас используется больше десятка разнообразных плагинов.

  Развернуть 1 комментарий

Классная статья, спасибо :)

Дальнейшие азы продакт-менеджмента учат тому, что нужно пойти фигачить проблемные интервью, или рекламу там дать и половить лидов.

Меня всегда такой подход очень веселит при мыслях b2b, удачи любителям нарисовать lean canvas и "покастдевить".

Пара вопросов (не доебаться, а почелленджить):

  1. Вы учитывали ограничения JIRA API при проработке юзкейсов?
  2. Я не очень понял пойнт про конкуренцию с Miro. То есть теоретически вменяемая интеграция с Джирой в их исполнении если не убивает ваш продукт, то точно откусывает часть пользователей. Насколько велики шансы, что она не случится? И если случится, то чем соревноваться? Ценой и заточенностью под проектный менеджмент?
  Развернуть 1 комментарий

@angelooooook,

  1. Пока мельком глянули, кажется что у нашего конкурента (whiteboards for jira) все получается из того, чтобы мы хотели делать. Т.е. как минимум основной функционал взлетабелен.
  2. Я ребятам из Миро рассказывал про свои хотелки еще пару лет назад =) Они до сих пор не сделали ничего в эту сторону и судя по их развитию приоритеты совсем другие. Они, кажется, идут сейчас вширь. Но даже крутая интеграция миро в джиру не ломает нам сценарий stand alone инсталляции для крупняка, который боится за безопасность данных. Миро так не умеет и вряд ли в это пойдет, а мы можем предоставить такой продукт на рынке.
  Развернуть 1 комментарий

@glebkudr, удачи! Кейс хороший.
В современных интернетах можно заработать, выпустив абсолютно все что угодно, тем более что вы таргетите не price-sensitive рынок :) Озвученная экономика звучит правдоподобно, мне кажется, что точно можно больше.

  Развернуть 1 комментарий

Тем временем, мы все пилим, а Miro стоит $17 млрд.

Но есть и хорошая новость. Нашли рынок на десятки миллионов долларов и несколько корпоративных клиентов, которые готовы установить нашу систему, как только мы ее доделаем.

Да, Карл, мы протестили спрос и он есть, мы готовы активно продавать, как только будет что.

Нам все еще нужны крутые разработчики в партнерство.

На этот раз не только фронт, но и бэк - нужно пилить сервер, в т.ч. с прицелом на коробочное решение для корпоратов.

Если вы хотите вписаться в какой-то стартап, но не знаете в какой, то вписывайтесь к нам.

Бизнес и продажи это именно то, где дохнут стартапы, а у нас это наоборот - сильная сторона.

В технологии нет космоса, все абсолютно реально.

Теперь нужно просто сделать и вместе заработать кучу денег :)

  Развернуть 1 комментарий

@glebkudr, что-то у вас сайт не работает. Даж демку не глянуть!

  Развернуть 1 комментарий

@Mysh, чекнем, спасибо. Пока внешний сайт не самое главное, так что да, может отваливаться. Я обновил ссылку в посте - можно на нее тыкать.

  Развернуть 1 комментарий

Результаты к 8 февраля.

Глеб:

Хотели сделать примитивы и начать стрелочки. Не сделали, вместо этого провозились с группировкой и наследованием свойств фигур. Снова взяли примитивы. Будем ограничиваться прямоугольником и кругом. Самый большой вопрос - стрелочки, не хочется, чтобы провозились еще и с ними. Очень страдаю от нашей медленной скорости. Не знаю, что мы еще можем выкинуть, чтобы хоть какой-то базовый функционал был.

Записал видяшку, чем мне, например, не нравится работа с тасками в миро.
Декомпозируешь маиндмэп. В какой-то момент решаешь разбить задачи на таски и засунуть их в джиру. Все ок, только теперь они никак не привязаны к структуре и работать с этим нереально. Получается просто доска для рисования, а не инструмент для ведения проектов (не будешь же вручную выравнивать таски после любого изменения дерева).
https://gyazo.com/285f763ab229542671a603ed4954bf73

Саша:

Удобные абстракции могут сохранить много времени, а плохие заставят много времени потерять. Удобные абстракции, часто легче найти, чем придумать. Только увидев несколько решений похожих конкретных задач можно абстрагироваться и найти общее решение.

Вот например добавили на доску текст и логику для его перетаскивания. Добавили фигуры, логика перетаскивания - такая же. Скоро нужно будет добавить группы фигур и текстов. К ним опять нужно будет добавить такую же логику. Тут возникает вопрос - если и текст, и фигуры можно перетаскивать в группе, так зачем на них нужна логика перетаскивания? Для группы достаточно и одного элемента. Теперь любой элемент на доске находиться как минимум в своей собственной группе, и перетаскивается вместе с ней.

Или вот мы рисуем фигуры. Пишем отдельные функции для рисования каждой фигуры. Квадрат задаём верхней левой точкой, шириной и высотой, круг - центром и радиусом, треугольник - тремя прямыми, фигуру посложнее - несколькими кривыми и т.д. Через некоторое время нам нужно найти кратчайшее расстояние от точки до фигуры, но у нас нет данных о координатах границ фигур, и нужно писать функции для поиска кратчайшего расстояния до каждой фигуры. Тут возникает вопрос, а что если бы мы сразу задавали каждую фигуру как набор кривых линий? Тогда у нас была бы только одна функция для рисования произвольного набора кривых линий и одна функция для поиска расстояния до произвольного набора кривых линий, и если нам потребуется ещё какая-то функция, то мы её тоже напишем только один раз, и так сколько бы новых кривых мы ни добавили.

В обоих случаях начальное решение казалось логичнее и проще, а конечное пришло и показало свою эффективность только в процессе.

  Развернуть 1 комментарий

@glebkudr,

Тут возникает вопрос, а что если бы мы сразу задавали каждую фигуру как набор кривых линий?

Просто обеспечить фигуры нужными utility functions же?
Ну вот есть у нас class Rect extends Shape {}, class Circle extends Shape {}, class Triangle extends Shape {} — пишем

Rect.prototype.toLines = function () {
    return [line(this.x, this.y, this.x + this.width, this.y), ...];
}

Circle.prototype.toLines = function() {
    const lines = [];
    const approxStep = 0.1;
    let lastPoint = [this.center.x, this.center.y - this.radius];
    for (let i = 0; i < Math.PI * 2; i += approxStep) {
    	const nextPoint = [this.center.x + this.radius * Math.sin(i), this.center.y - this.radius * Math.cos(i)]; // или как-то так, лень сейчас представлять знаки и порядок
    	lines.push(line(lastPoint[0], lastPoint[1], nextPoint[0], nextPoint[1]));
    	lastPoint = nextPoint;
    }
    return lines;
}

А потом в Shape закидываем ориентированную на неё функцию для расстояния.

  Развернуть 1 комментарий

Апдейт от 15 февраля.

  1. Сделали фигуры состоящие из безье кривых. Новые фигуры оказалось можно задать и сохранить прямо в интерфейсе. Интерфейс рисования минимальный, кривые рисуются автоматически через последовательность точек, редактировать кривые нельзя (передвигать или удалять точки нельзя, масштабировать стандартным трансформером можно будет, см. п. 5). Такой инструмент разработчика.
  2. Сделали базовые стрелки между фигурами. Стрелка ищет кратчайшее расстояние от своей конечной точки до фигуры (перпендикуляр к касательной). Когда все фигуры заданы безье кривыми, то поиск ближайшей точки на кривой - всего одна функция, которую мы взяли готовую из библиотеки для расчёта безье кривых. Это оказалось сильно проще, чем прописывать всю логику для каждого типа фигур отдельно. Та же библиотека рассчитывает квадрат вмещающий фигуру, а у него мы берём центр.
  3. Стрелки из одной кубической кривой (там 4 точки, концы плюс 2 контроля, которые нужны, чтобы линия подходила к фигуре перпендикулярно). Точно пока не пишем стрелки из нескольких кривых.

...Мы здесь

Далее планы:

  1. Дописываем стандартный трансформер (поведение для фигур, поведение для групп фигур и текста) с прошлой среды. Из всех работ трансформер оказался самым сложным. Это пока закончит работу над фигурами и стрелками.
  2. Нужно заменить textarea на contenteditable div, чтобы держать фокус редактора текста в пределах экрана. Тогда же можно заполнить контекстную плашку.
  3. Включаем синхронизацию с сервером.
  4. Делаем сущность - карточка из джиры. Рендер карточки делаем из уже написанных элементов (текста и фигур), и помещаем её в стандартный контейнер (группу), положение карточки (на самом деле положение группы) сохраняется на доске, как обычно - через флюид, но содержание карточки для рендера, подгружаем отдельно от флюида. В результате содержание карточки на доске одновременно может редактировать только один пользователь и содержание загружается и сохраняется в соответсвии с правами пользователя в джире, но контейнер карточки видят и могут передвигать все - во флюиде у нас нет прав пользователей.
  5. Делаем сущность перетаскивания карточки на сущности доски и назад. Добавляем возможность сворачивать группу в значок и разворачивать при нажатии на него. Добавляем возможность объединять группы перетаскиванием друг на друга.
  6. Релизим альфу/тестим имеющийся функционал на живых пользователях
  Развернуть 1 комментарий

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

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

Сделал репозиторий публичным https://github.com/keyten/ime, можно потыкать, утащить любое количество кода или логики, вот редактирование кривых Безье например

Есть ещё https://github.com/keyten/Graphics2D, там какое-то количество математики (если вам нужно писать функции типа пересечений полигонов или что-то такое, порой там можно найти такое), и https://github.com/keyten/apartment-editor/tree/main/src (просто редактор планировок на SVG, там вряд ли много интересного есть, но вдруг пригодится что)

  Развернуть 1 комментарий

@ikeyten, огонь, спасибо!

Мы уже много твиков понаделали, под капотом сильно больше, чем снаружи 🤦‍♂️ Но не бросаем 🙂

  Развернуть 1 комментарий

@glebkudr, удачи с проектом, он классный)

Даже жаль, что я сейчас сижу со своим пет-проектом помимо основной работы (которая тоже важна из-за возможности получить гражданство), и нет столько времени, чтобы даже интересоваться, нужны ли вам ещё фронты

  Развернуть 1 комментарий

формальная интеграция Miro с Jira это ты про https://miro.com/marketplace/jira/ или про https://help.miro.com/hc/en-us/articles/360017572414-Jira-Add-on?

  Развернуть 1 комментарий

@Kir,

  1. Это очень куце реализует небходимые сценарии в жизни проджекта.
  2. Это хорошая штука и ее вайтбордс склонировали, мы тоже будем клонировать, но ее мало, т.к. того что в первом пункте сейчас откровенно мало и неудобно.

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

  Развернуть 1 комментарий

@glebkudr, я там еще ссылку докинул=)
https://help.miro.com/hc/en-us/articles/360017572414-Jira-Add-on тоже кривота?

  Развернуть 1 комментарий

@Kir, откаментил =)

  Развернуть 1 комментарий
Рустам Хафизов Предприниматель, продаю керамическую плитку 1 февраля 2021

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

@glebkudr как у вас прогресс, вышли уже в паблик?

  Развернуть 1 комментарий

@Kir, ты будешь смеяться, но все еще пилим 😬 Но кажется уже скоро. При этом куча пресейла уже и интереса в тч от крупняка, но уперлись в разработку ☹️

Четкие фронтендеры готовые в канвас нам все еще помогут. И еще помогут бэкендеры, у которых есть понимание как делается он премиз софт для корпоратов, всякие интеграции с AD и прочие закидоны крупных компаний.

  Развернуть 1 комментарий

Сайт не работает =/

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

По моему опыту всегда страдают - 1) версионирование/трекинг изменений, 2) процесс комментирования, согласования и вся вот эта корпоративная бюрократия разных отделов. Про связи между тысячей абстракций уже упомянул - это капец как важно.

P.S. На чем у вас бэк? Вашей маме джавист не нужен? Переобучаемый.

  Развернуть 1 комментарий

@raserei, сайт не поднимали, нет смысла пока. Но делаем 🙂
Бэка у нас как такового почти нет, там где есть - там нода. А вообще, может скоро кто-то и понадобится.

А напиши плз про сценарии комментирования и всего такого? Вроде в миро это сделано, версионирование в виде истории редактирования в наличии, а что еще?

  Развернуть 1 комментарий

@glebkudr,
Я толком не пользовалась миро, это скорее мысли на тему "на что бы я как арх смотрела, если бы мне нужно было принести новый продукт в компанию и с ним работать".

  1. Версионирование - это не просто история. Это а) возможность сослаться на конкретную версию документа, б) возможность комментировать конкретную версию, как следствие в) возможность считать какую-то версию текущей или, что не менее важно, устаревшей.
  2. Комментирование и аппрув. В среднем сценарии в кровавом энтерпрайзе до сих пор выглядят примерно так:
    1. Человек-архитектор/аналитик/you name it (далее - Автор) рисует документ
    2. Автор запускает процесс согласования документа - то есть, должны прийти всякие согласующие (владельцы систем, инфраструктурщики, безопасники, etc) и документ заапрувить и/или прокомментировать.
    3. Документ, соответственно, правится автором несколько раз, пока все причастные не станут счастливы.
    4. Когда финальная версия документа заапрувлена, все это уходит в разработку.
    5. Дальше самое интересное. Иногда (всегда), после того как проект уже запущен, какая-то часть ландшафта может поменяться (шаги те же). И надо как-то иметь возможность отличать текущую версию, которую все согласовали, проектируемую (на которую может быть важно смотреть твоим коллегам, проектирующим что-то рядом, потому что в большой конторе не все в курсе, что там происходит в соседнем отделе) и устаревшую.

То есть, нужны не просто комменты, а именно ревью-процесс и жизненный цикл документа. Есть много подходов работы с этим безобразием (например, immutable ADR - "решили сделать X", но он не покажет тебе текущее состояние ландшафта, когда ты проектируешь что-то новое), но все равно все сводится к тому, что у документа должна быть строчка, где все подписываются кровью, что согласны вот ровно с этой версией, а значит пилят все так, как в ней написано. А если документ потом переделали - аппрува под ним не стоит, и все это видят.

  Развернуть 1 комментарий

В общем, я сейчас в поиске проекта, в который можно было бы вписаться в свободное время и потенциально переключиться на него в будущем (правда, не в России). Так что, могу записаться в лист ожидания бэкендеров. Один фиг сейчас хочу изучить JS + TS)

  Развернуть 1 комментарий

тут вам конкурента завезли https://obsidian.md/canvas
тестировал оффлайн версию, где все локально хранится, и был приятно удивлен качеством первой версии

  Развернуть 1 комментарий

@AntonLantsov, а обсидиан есть ли для корпоратов или чисто сингл юз?

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб