Ищу партнера: веб-приложение для совместного проектирования баз данных

Привет!

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

Я люблю базы данных. Но я не люблю средства их проектирования. Обычно, это одно из двух: или enterprise решения с миллионом возможностей за миллионы денег, или невнятные open source поделки. Моя цель — сделать классное веб-приложение, позволяющее проектировать БД распределенным командам разработчиков. Классное значит:

1. Продуманный и приятный интерфейс в стиле Basecamp, а не в стиле SAP.
2. Хранение модели в облаке, а не в виде файлов на локальных машинах. Это даем возможность всегда иметь актуальную версию модели под рукой.
3. Совместная разработка. Члены команды могут одновременно модифицировать модель базы — изменения, сделанные одним участником сразу видны всем остальным (почти как Google Docs).
4. Forward- и reverse-инжиниринг, нахождение различий между двумя состояниями модели, миграции.

Что есть?
Разработка началась 4 месяца назад. Пишу на Python — Django/Flask. Работаю над проектом рано утром и по субботам. За это время написал ядро — создание модели (Postgres, для начала), получение актуального состояния, redo/undo, обработка конфликтов, проверка модели на логическую корректность, кэширование etc.) и стандартную обмотку — авторизацию, роли и т. д.

Что надо? Кого ищу?
Рабочий прототип надо. :) В связи с тем, что состояние модели нужно синхронизировать сразу на нескольких клиентских машинах и рисовать ER-диаграммы в браузере, сервер-сайда, который я полностью беру на себя, мало.

Я ищу партнера, обладающий уникальным сочетанием интереса к базам данных и крутых навыков front-end разработки (слышал мнение, что таких не бывает, но попытка не пытка). Стремление к минимализму и перфекционизм — must have.

Кто я такой?
26 лет, тех/тимлид в небольшой команде. Java — 7 лет, Python — 2 года. Опыта в бизнесе нет, зато гонор и уверенность в победе — есть (говорят, отчасти компенсирует ;)).

Skype: borismarchenko

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А liquibase (www.liquibase.org) не решает пробему синхронихации модели БД? Или я не правильно понял, о чем идет реч?

И еще комментарий. На сколько мне известно при использовании подхода Domain Driven Design и ORM, схема БД уходит на второй план — в основном нужно продумать связи и зависимости между объектами, а замапить єти связи на модель БД — єто тривиально.

Часто продумывание связей и зависимостей делается сразу в физической модели. Она отличается от логической тем, что построена но правилам определенной СУБД, а не по абстрактным правилам. Но в этом ее преимущества — поддерживать такую модель в актуальном состоянии намного проще (это можно делать (полу)автоматически).

В DDD большая часть продумываестя именно на этапе проектирования доменной модели. А положить ее на схему БД (индексы, праймери и внешние ключи и тд ип), как по мне, задача — именно, что тривиальная.
Я вижу приимущества вашего тула именно, как инструмента для обсуждения и визуализации модели в распределенных командах.
Думаю у ликвибейса можно позаимстовать идею читаемых базонизависимых скриптов (ченйджсетов), что бы организовать удобную версионность.

Да, за ссылку на Ликвибейс спасибо. Возможно, удастся упростить жизнь за счет этой тулзы (зависит от лицензии, конечно).

Синхронизации с чем? Liquibase не дает возможность строить визуальную модель БД и обсуждать ее в команде разработчиков.

Синхронизации с чем?
Синхрониазции модели базы (таблици, связи, индексы...) на всех инстансах, где проранилась liquibase миграция. Согласен. Визуалзации нет.

Отличная идея! Я как раз недавно искал нечто похожее. Воспользовался бесплатными онлайн тулзами. Их кстати довольно много. не знаю как вы будете с ними конкурировать. Основная фича, имхо, должна быть — сгенерить из диаграммы SQL и из SQL — диаграммы. Тем более что сделать это довольно просто. В тех тулзах я так и не нашел этой фичи.

Синхронизация модели и базы необходима для того, чтобы после начального проектирования модель не выбрасывалась в урну. Генерация SQL действительно задача несложная, а вот парсинг скрипта — намного более сложная. Поэтому я планирую реализовать reverse-engineering посредством т. н. проксирующего скрипта, который будет строить описание схемы, обращаясь к системным таблицам (которые более-менее стандартизированы), и отсылать ее на сервер. Скрипт можно будет установить в локальном окружении, не допускающем обращений извне. Результат работы скрипта будет доступен для проверки, таким образом пользователь будет уверен, что приложение не вытащит никакаие приватные данные.

С синхронизацией все понятно. Ваш проект — Ваши приоритеты. Я исхожу из своего опыта использования.
Даже не думайте городить свой велосипед по парсингу скрипта. я уверен, что уже есть все готовое. Нужно лишь собрать по кусочкам.

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

А проводил маркетинговое исследование, будут-ли за это платить?

Я просил людей заполнить эту форму: docs.google.com/...3dXWUE6MQ#gid=0 На вопрос, будут ли они платить за понравившийся продукт такого рода 40% ответило положительно. Конечно же, точный ответ на этот вопрос я получу с первым долларом, но я уверен, что вероятность высока.

Я люблю базы данных. Но я не люблю средства их проектирования.
А в чем тогда выражается ваша любовь к БД?

Реляционные БД просты и мощны одновременно. В этом их элегантность.

Это да. А в чем выражается ваша любовь к базам данных? :)

Я люблю простые и элегантные решения. Примените транзитивность. :)

Какую проблему будет решать этот продукт? Как выглядит «идеальный» пользователь? Где искать потенциальных пользователей? Сколько будет стоить такой продукт? SaaS?

Это не наезд, это чеклист. Вообще идея ок, вспоминается balsamiq.

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

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

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

Монетизация по модели подписок, как в Balsamiq, Basecamp, GitHub. Стоимость пока не знаю, повесим ценник, посмотрим, как будут брать, повесим другой.

Сорри, неточно выразился. Ты описываешь «типичного пользователя» продукта, у которого уже есть 100к+ юзеров. Опиши как будут выглядеть первые 10 пользователей. Такие общие описания (технический специалист в распределенной команде) означают что ты его не знаешь. :-)

// тест: если под описание подходит больше 100 человек в мире это плохое описание (бесполезное)

Я читал о том, что должен знать, какого цвета Бьюик у моего пользователя и насколько агресивно он его водит. В теории действительно важно знать, в какую десятку целиться, но на практике... скажи, если бы ты сейчас создавал DOU, как бы ты описал идеального пользователя при условии, что под описание подходит 10 человек в Украине?

если бы ты сейчас создавал DOU

Хз. ДОУ за 6 лет так оброс разными фичами, что я не могу ответить. Я сейчас делаю
djinni.co и потенциального пользователя могу описать довольно четко: сеньор в большой компании, с з/п от $3k, который хочет уйти в другую компанию, но не хочет, чтобы о его решении свалить узнали раньше времени.

ОК, это не 10 человек. Но думаю точно меньше 1000. :-)

Спасибо за пример. Хорошая задумка с Джинни, успехов в реализации!

Спасибо за ссылку, Макс, почитываю 37signals, о бальзамике тоже очень интересно будет почитать.

Вообще идея ок, вспоминается balsamiq
Balsamiq это класс.

Надо было сегодня на хакатон приходить. :-) В принципе, еще можно завтра на демо зайти.

дык, девушку свою с аватарки программить научите, и будет вам счастье

Нее — она творческая. ;)

Приведенные системы или не проходят никаких acceptance test’ов по юзабилити в моем понимании, или являются системами для создания диаграмм без возможности взаимодействия с реальной БД. Вообще исследование рынка на предмет конкуренции было простым — я спросил у десятка коллег, какие классные средства проектирования они используют. «Хм» и задумчивое выражение лица показались мне достаточным ответом.

я спросил у десятка коллег, какие классные средства проектирования они используют
А вы уверены что вообще используют? Я вот ЕРД и прочей мути не рисовал с ВУЗа. Всякие РоР и тд умеют генерить схему БД (не картинку) по коду. Сугубо ИМХО — такое средство никому не надо.
Но в общем желаю вам удачи в ваших начинаниях.

Я спрашивал у тех, кому приходилось проектировать, конечно. Но самый главный опыт — разработка БД в нашей команде при содействии других команд из 3 стран. Вот там почувствовал, что порой очень нужно. Так что чешим там, где чешится.

Имхо, партнера коммерсанта надо искать, а не технаря-фротендщика. А так онлайн CASE cистема — в принципе можеть быть интересной темой.

И еще непонятно, зачем джангу и фласк смешивать.

Я думаю, что в небольшой команде не должно быть выделенных менеджеров и «сейлзов», не обладающих техническим опытом. Коммерсант здесь — одна из ролей. Да и не сделает ничего коммерсант, если продукта не будет.

Более легковестный Flask для API и бизнес-логики, Django для рендеринга страниц только. Решил сразу отделить, но не считаю, что это обязательное козырное решение.

Я думаю, что в небольшой команде не должно быть выделенных менеджеров и «сейлзов», не обладающих техническим опытом.
Речь не о выделенном «сейлзе», речь о человеке который умеет строить бизнес (это совсем параллельно ИТшным навыкам)

И чем бы постройщик бизнеса занимался в ближайшие пару месяцев?

И чем бы постройщик бизнеса занимался в ближайшие пару месяцев?
Строил бизнес? Искал инвесторов, думал как и кому это можно продать и тд.

Мне кажется, что пока нет ничего готового, такой человек нужен не сильно, в Prom.ua кажется не было ничего (никого) подобного и вроде как пришли к успеху и инвесторам. (Правда у меня такое личное мнение, что чем меньше людей — тем лучше, в идеале вообще 0 или 1 человек, но на самом деле теоретически правильно минимум 2). Еще есть разные инкубаторы, которые по идее могут помочь людям с идеей или прототитом советами или деньгами.

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

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

Выкинь джангу, пока не поздно :)

Энергичный молодой человек. Ретвитнул (чем могу...) Искренне Желаю Успехов!

Підписатись на коментарі