Комментарии 70
очень интересно, что на бекенде?
Вот, посмотрите: mindapps.ru/product/tech/used. Все внешние компоненты там перечислены, остальное — своё.
Пардон, http://mindapps.ru/product/tech/used — лишняя точка в адресе
ссылка привела на 404
уточните пожалуйста
уточните пожалуйста
Круто. Всемирный Управлятор Всем Миром. Неслабая работа на бэкенде была сделана, вероятно.
А можно вам пару вопросов задать?
1. Что используется для онтологического описания сущностей? Какое-то готовое решение OWL+RDF или самописные классификаторы?
2. Что с производительностью?
А можно вам пару вопросов задать?
1. Что используется для онтологического описания сущностей? Какое-то готовое решение OWL+RDF или самописные классификаторы?
2. Что с производительностью?
Вы разоблачили мои тайные планы. :)
1.
В настоящей версии реализация классовой модели собственная. Иначе бы оно, видимо, и не получилось — у нас довольно своеобразная структурно-объектная модель, адаптированная под задачи платформы. Наверное, будет интересно на Хабре рассказать, как-нибудь. Поэтому стандартные OWL/RDF описания нам сейчас не подойдут. Видимо, нужно будет сделать импорт/экспорт, чтобы задействовать готовые схемы. Но это будет не в ближайшей версии системы.
С другой стороны, в повестке дня стоит организация общего каталога классов. Чтобы разные приложения могли использовать стандартные пакеты классов, помимо собственных локальных — и через это взаимодействовать. Следует ли здесь опереться на OWL, или пойти своим путём — пока не определился. Технически проще делать своё.
2.
По производительности ситуация следующая. Вообще она должна быть _очень_ высокой: вся обработка ведётся в оперативной памяти, а система специально оптимизирована как на уровне модели, так и реализации. Узким местом является ORM — через firebird он может притормаживать на поднятии нужных объектов в память. Впрочем, это может проявляется только на больших объёмах единовременно выбираемых данных и вообще устранимо. Если прикрутить какую-нибудь специализированную СУБД, то с производительностью будет полное счастье.
1.
В настоящей версии реализация классовой модели собственная. Иначе бы оно, видимо, и не получилось — у нас довольно своеобразная структурно-объектная модель, адаптированная под задачи платформы. Наверное, будет интересно на Хабре рассказать, как-нибудь. Поэтому стандартные OWL/RDF описания нам сейчас не подойдут. Видимо, нужно будет сделать импорт/экспорт, чтобы задействовать готовые схемы. Но это будет не в ближайшей версии системы.
С другой стороны, в повестке дня стоит организация общего каталога классов. Чтобы разные приложения могли использовать стандартные пакеты классов, помимо собственных локальных — и через это взаимодействовать. Следует ли здесь опереться на OWL, или пойти своим путём — пока не определился. Технически проще делать своё.
2.
По производительности ситуация следующая. Вообще она должна быть _очень_ высокой: вся обработка ведётся в оперативной памяти, а система специально оптимизирована как на уровне модели, так и реализации. Узким местом является ORM — через firebird он может притормаживать на поднятии нужных объектов в память. Впрочем, это может проявляется только на больших объёмах единовременно выбираемых данных и вообще устранимо. Если прикрутить какую-нибудь специализированную СУБД, то с производительностью будет полное счастье.
1. Оччччень интересно, рассказывайте давайте. А ну быстро! :)
2. Если замеры перформанса — не NDA, то на них тоже хотелось бы поглядеть )
Спасибо, буду ждать
2. Если замеры перформанса — не NDA, то на них тоже хотелось бы поглядеть )
Спасибо, буду ждать
1. Заказ принят. Я когда-нибудь соберусь с мыслями. :)
2. По-настоящему производительность будет смысл тестировать, когда в системе поддержим обработку данных. Без этого не очень интересно: нахомячит поступающие транзакции в оперативку быстро, а потом будет в фоне лить в БД… А как проводить комплексный тест, в т.ч. с фактором поднятия данных, честно говоря пока не думал.
2. По-настоящему производительность будет смысл тестировать, когда в системе поддержим обработку данных. Без этого не очень интересно: нахомячит поступающие транзакции в оперативку быстро, а потом будет в фоне лить в БД… А как проводить комплексный тест, в т.ч. с фактором поднятия данных, честно говоря пока не думал.
Демо дистрибутив ныхт арбайтен :-(
А попробовать очень хочется…
А попробовать очень хочется…
> аботает под основными браузерами: FireFox, Chrome, Interner Explorer 7.0.
Chromium 4.0.260 — не запустилось
что значит «Дистрибутив для Windows»?
Chromium 4.0.260 — не запустилось
что значит «Дистрибутив для Windows»?
Чёрное окошко, хлоп, и кажется ничего не произошло, а жаль…
«Дистрибутив для Windows» проверен под Windows XP. Должен работать, но не проверялся, под Windows 2k и выше.
Сервер повис, исправили, перезапустили — однако хабраэффект. :) Он больше не будет.
Сервер повис, исправили, перезапустили — однако хабраэффект. :) Он больше не будет.
тоесть ето бинарник?
Подвисал бинарник. Проверили Хромом 4.0.259, в частности, online.mindapps.ru:84 — всё работает.
НЛО прилетело и опубликовало эту надпись здесь
Мило, этак Вы СалесФорса в шкаф отправите :)
Скажите а что с условиями использования?
Скажите а что с условиями использования?
Спасибо, стараемся. :)
Лицензия там есть.
Если вкратце, то сейчас это демо-версия, и пользуйтесь для личных и ознакомительных целей наздоровье. Если надумаете на её основе делать публичный или коммерческий проект — напишите письмо, договоримся. JS веб-движка пока переиспользовать нельзя, хотя по-хорошему их надо бы выделить в отдельный open source проект.
Когда доделаем то, что отделяет нас от продукта (в первую очередь, вычислительная часть и отчётность) — лицензия будет другая, коммерческая.
Лицензия там есть.
Если вкратце, то сейчас это демо-версия, и пользуйтесь для личных и ознакомительных целей наздоровье. Если надумаете на её основе делать публичный или коммерческий проект — напишите письмо, договоримся. JS веб-движка пока переиспользовать нельзя, хотя по-хорошему их надо бы выделить в отдельный open source проект.
Когда доделаем то, что отделяет нас от продукта (в первую очередь, вычислительная часть и отчётность) — лицензия будет другая, коммерческая.
Ну, PaaS с нуля ни один успешно пока не стартанул, так что отправлять SF на покой рановато :)
Для оттачивания платформы нужны пользователи, и стабильный доход. Таков был рецепт SF. Удачи ребятам из MindApps, надеюсь что их продуктом можно будет пользоваться, и найдутся смельчаки.
Я вот пробовал Iceberg (http://www.geticeberg.com/), и понимаю почему нет популярности. Непросто, ох непросто.
Для оттачивания платформы нужны пользователи, и стабильный доход. Таков был рецепт SF. Удачи ребятам из MindApps, надеюсь что их продуктом можно будет пользоваться, и найдутся смельчаки.
Я вот пробовал Iceberg (http://www.geticeberg.com/), и понимаю почему нет популярности. Непросто, ох непросто.
Забавно, пользоваться (и настраивать под себя) SF я смог минут за 40… и до сих пору пользуюсь уже не первый год. А вот с MindApps как то не сложилось…
Вот все таки, то что в SF не отнимешь, это СОВЕРШЕННАЯ ПРАКТИЧНОСТЬ. нет ничего «просто так», а то что есть можно сразу использовать… не зря сигналщики глаголили «Делайте половину но на 100%»
Вот все таки, то что в SF не отнимешь, это СОВЕРШЕННАЯ ПРАКТИЧНОСТЬ. нет ничего «просто так», а то что есть можно сразу использовать… не зря сигналщики глаголили «Делайте половину но на 100%»
когда началась загрузка демо версии я сначала подумал что в gmail захожу :)
и при загрузке контента(сам лоадер) уже в самой демке тоже очень gmail напоминает(красненькая подстилка, белыми буквами, а главное на том же месте)…
ну эт я так (; а вообще интересно, выделю время посмотрю более детально
и при загрузке контента(сам лоадер) уже в самой демке тоже очень gmail напоминает(красненькая подстилка, белыми буквами, а главное на том же месте)…
ну эт я так (; а вообще интересно, выделю время посмотрю более детально
Очень интересное и перспективное направление. Жаль, что под Вистой посмотреть не получается (какие-то рекомендации?).
И, если возможно, как собираетесь продукт развивать? Только платформу или свои приложения выпускать будете (какие)?
И, если возможно, как собираетесь продукт развивать? Только платформу или свои приложения выпускать будете (какие)?
Ок, спасибо за информацию, посмотрим.
Мы хотим развивать продукт в следующих направлениях:
1. Как платформу.
2. Как сеть создания и предоставления контента mindapps.ru/product/sys/content
3. Сами решения, хотя бы для начального наполнения будущего каталога-репозитория.
В число контента, который мы хотим сделать сами — это шаблонные решения CRM, склад и SCM… может быть, HRM. Впрочем, нам гораздо интереснее, чтобы решения рисовали партнёры — специалисты с соответствующей прикладной компетенцией. Нам самим лучше сосредотачиваться не на этом.
Сейчас у нас некоторая CRM-зарисовка выложена здесь. Видите, отчётов с обработкой данных нет, поэтому есть только средства ввода и непосредственного простмотра данных. Так что это не CRM, но что-то похожее. :)
Мы хотим развивать продукт в следующих направлениях:
1. Как платформу.
2. Как сеть создания и предоставления контента mindapps.ru/product/sys/content
3. Сами решения, хотя бы для начального наполнения будущего каталога-репозитория.
В число контента, который мы хотим сделать сами — это шаблонные решения CRM, склад и SCM… может быть, HRM. Впрочем, нам гораздо интереснее, чтобы решения рисовали партнёры — специалисты с соответствующей прикладной компетенцией. Нам самим лучше сосредотачиваться не на этом.
Сейчас у нас некоторая CRM-зарисовка выложена здесь. Видите, отчётов с обработкой данных нет, поэтому есть только средства ввода и непосредственного простмотра данных. Так что это не CRM, но что-то похожее. :)
Меня как «специалиста с соответствующей прикладной компетенцией» и заинтересовала разработка. А в какой стадии сейчас работа с партнёрами и какие планы? И сроки по созданию социально-сетевого ресурс разработчиков, если можно.
На первый взгляд очень и очень неплохой потенциал у платформы. Возник вопрос: у свойства класса задается тип «объект», как определяется при этом тип связи объекта (агрегация/ассоциация)?
Получится ассоциация. Сама платформа поддерживает и агрегацию, для неё этого разные типы данных (рефа/мультирефа и парта/мультипарта), но агрегация сейчас не вынесена на язык схем — чтобы не запутывать не сильно искушённого пользователя, и уберечь от ошибок изменений.
Т.к. если поменять задним числом класс объекта у агрегации, получится… хм… не очень хорошо, надо отдельно разруливать.
Т.к. если поменять задним числом класс объекта у агрегации, получится… хм… не очень хорошо, надо отдельно разруливать.
Спасибо, а большой смысл тогда в таком качественном и проработанном визуальном редакторе классов? «Парт/мультипарт» свойства очень часто востребованы. Видимо нужно при смене типа выводить предупреждения о последствиях. А включать агрегацию можно понятной опцией — «удалять объекты вместе с родителем».
Сейчас учавствую в разработке фреймворка веб приложений, с автогенерацией «пользовательского» интерфейса, но без интерфейса «не программистов»
И еще хотел узнать, те свойства которые имеют тип «рефа» объекта, в интерфейсе выводятся в выпадающем списке, что если их будет несколько тысяч?
Сейчас учавствую в разработке фреймворка веб приложений, с автогенерацией «пользовательского» интерфейса, но без интерфейса «не программистов»
И еще хотел узнать, те свойства которые имеют тип «рефа» объекта, в интерфейсе выводятся в выпадающем списке, что если их будет несколько тысяч?
Спасибо за совет, возможно так и сделаем.
Насчёт проработанности редактора классов — очень приятно, но Вы всё же преувеличиваете. Это наш стандартный виджет mind map'ы. Мы его просто применили к объектам-описателям классов, вывели нужные атрибуты, и подкрасили подсказками. Создание виджета — да, много крови унесло.
Сначала хотели, чтобы «парты»-агрегаты рисовались бы прямо вглубь класса. Но это показалось страшно — не думая наколотят поддерева, а потом в ссылки как рефакторить? В общем, тут ещё думаем.
У нас предусмотрено несколько методов визуализаций выбора («Метод выбора» на рефе в редакторе форм):
1. Инкрементальный, когда по одному полю можно вводить символы, и отправляется поисковый запрос, сужающий список
2. Поисковый, когда по нескольким полям можно ввести подстроки или значения, и затем найти результаты.
3. «Открытый», визуализируется сразу радиокнопками.
Если данных много, то список бьётся на странички. Партиями по 50 штук, если не путаю, но этот параметр задаётся в сервере.
Насчёт проработанности редактора классов — очень приятно, но Вы всё же преувеличиваете. Это наш стандартный виджет mind map'ы. Мы его просто применили к объектам-описателям классов, вывели нужные атрибуты, и подкрасили подсказками. Создание виджета — да, много крови унесло.
Сначала хотели, чтобы «парты»-агрегаты рисовались бы прямо вглубь класса. Но это показалось страшно — не думая наколотят поддерева, а потом в ссылки как рефакторить? В общем, тут ещё думаем.
У нас предусмотрено несколько методов визуализаций выбора («Метод выбора» на рефе в редакторе форм):
1. Инкрементальный, когда по одному полю можно вводить символы, и отправляется поисковый запрос, сужающий список
2. Поисковый, когда по нескольким полям можно ввести подстроки или значения, и затем найти результаты.
3. «Открытый», визуализируется сразу радиокнопками.
Если данных много, то список бьётся на странички. Партиями по 50 штук, если не путаю, но этот параметр задаётся в сервере.
НЛО прилетело и опубликовало эту надпись здесь
Нам нужно было, чтобы логика интерфейса соответствовала логике поставленных перед ним задач. А специфика была такая:
1. Поддержка нашего XML-протокола. Страница или её фрагмент передаётся описателем метаданных + блок соответствующих данных. Интерфейс должен построится по этому описанию автоматически.
2. Требование компонентно-виджетной организации. Любой структурный элемент — скаляр, список или единичный объект — должны мочь отображаться назначенным на него виджетом. Который написан по общим правилам, подключается и используется. Для того, чтобы веб-интерфейс мог расширяться независимо от нас.
3. Требование минимизации нагрузки на сервер. Что можно, должно обрабатываться на клиенте без запросов.
4. Компоненты составления схем — это стандартные виджеты, семантика которых определена метаданными. Т.е. интерфейс составления схем — это обычные списка объектов, только визуализированные по-хитрому.
Мы анализировали несколько AJAX-библиотек, на памяти DOJO, а также использование Flash. Остановились на своём движке. Правда, времени на него в результате ушло сильно больше, чем планировалось, пару раз сильно всё переделывали… Но это уже отдельаня история.
А стилистику отображения можно поменять, это не очень сложно. У нас самих дизайн получился такой, как получился. Может быть, когда-нибудь потом подключим скины.
1. Поддержка нашего XML-протокола. Страница или её фрагмент передаётся описателем метаданных + блок соответствующих данных. Интерфейс должен построится по этому описанию автоматически.
2. Требование компонентно-виджетной организации. Любой структурный элемент — скаляр, список или единичный объект — должны мочь отображаться назначенным на него виджетом. Который написан по общим правилам, подключается и используется. Для того, чтобы веб-интерфейс мог расширяться независимо от нас.
3. Требование минимизации нагрузки на сервер. Что можно, должно обрабатываться на клиенте без запросов.
4. Компоненты составления схем — это стандартные виджеты, семантика которых определена метаданными. Т.е. интерфейс составления схем — это обычные списка объектов, только визуализированные по-хитрому.
Мы анализировали несколько AJAX-библиотек, на памяти DOJO, а также использование Flash. Остановились на своём движке. Правда, времени на него в результате ушло сильно больше, чем планировалось, пару раз сильно всё переделывали… Но это уже отдельаня история.
А стилистику отображения можно поменять, это не очень сложно. У нас самих дизайн получился такой, как получился. Может быть, когда-нибудь потом подключим скины.
Честно говоря, дело не в дизайне интерфейса, а в юзабилити.
С одной стороны, всё понятно — ориентация на аналогичные продукты, ограничения среды.
Тем не менее, очень напрягают странные названия ряда сущностей и абсолютно неинтуитивные реакции на ряд действий.
С одной стороны, всё понятно — ориентация на аналогичные продукты, ограничения среды.
Тем не менее, очень напрягают странные названия ряда сущностей и абсолютно неинтуитивные реакции на ряд действий.
НЛО прилетело и опубликовало эту надпись здесь
подскажите MindApps это перерождение NetApps?
Это очень здорово! На Вашем сайте есть RSS или рассылка? Обязательно буду следить за ходом проекта.
Сколько человек разрабатывало?
Сколько времени потратили до текущего момента?
И главный вопрос: а где хранятся пользователские данные? Рядом с метамоделью, т.е. в некой Вашей структуре?
Сколько времени потратили до текущего момента?
И главный вопрос: а где хранятся пользователские данные? Рядом с метамоделью, т.е. в некой Вашей структуре?
В команде 5 человек (до июня было 4). Один на прошлой неделе в армию ушёл, так что сейчас опять четыре.
Смотря с какого момента. Наша история довольно сложная. Нынешняя стадия началась в ноябре прошлого года.
Все данные хранятся в одном месте — в Едином Дереве. Обладатели дистрибутива могут с консоли подать команду #dump и посмотреть в корне бинарника файл dump.xml, как оно там структурировано. Метаданные являются обычными данными, только «системных» классов, на которых навешено специальное поведение. А сама память-дерево мапится на базу данных, и хранится в ней. Структура таблиц соответствует структуре объектов — до тех пор, пока это возможно.
Смотря с какого момента. Наша история довольно сложная. Нынешняя стадия началась в ноябре прошлого года.
Все данные хранятся в одном месте — в Едином Дереве. Обладатели дистрибутива могут с консоли подать команду #dump и посмотреть в корне бинарника файл dump.xml, как оно там структурировано. Метаданные являются обычными данными, только «системных» классов, на которых навешено специальное поведение. А сама память-дерево мапится на базу данных, и хранится в ней. Структура таблиц соответствует структуре объектов — до тех пор, пока это возможно.
Структура таблиц соответствует структуре объектов — до тех пор, пока это возможно
Поясните пожалуйста. Структура таблиц создается автоматом, я так понимаю, но после определенного момента сложности — происходит что? И собственно что является тем порогом сложности?
Из више сказанного: планируется навес функционала на существующую БД или наоборот — возможность расширять автосгенерированную структуру?
Поясните пожалуйста. Структура таблиц создается автоматом, я так понимаю, но после определенного момента сложности — происходит что? И собственно что является тем порогом сложности?
Из више сказанного: планируется навес функционала на существующую БД или наоборот — возможность расширять автосгенерированную структуру?
Ну, если сделать имя объекта длиннее 30 символов, оно не войдёт в SQL-ную таблицу. Имя таблицы будет изуродовано с привлечением MD5. Далее, списочные стуркутры сейчас хранятся в отдельных табличках, они тоже имеют особую структуру. Далее, есть намерения не хранить скаляры по-отдельности, а упаковывать в блобы. Это должно увеличить быстродействие, но уменьшить возможность прямого использвоания таблиц. Ну и т.д. Пока всё сделано довольно минималистически.
Самому вручную изменять автосгенерированную БД категорически не советую. Отвалится чего-нибудь — не поймаете. :) Подцепляться к ранее имевшимся БД — в принципе, это можно сделать. Проблема будет в определении изменений данных — а тут либо полное сканирование, либо утомительная привязка через триггеры. Так что наиболее простым вариантом является реализация регулярного пересканирования существующих таблиц с экспортом «дельты» в MindApps. Т.е. поддержание на стороне MindApps адекватного образа Вашей системы.
Самому вручную изменять автосгенерированную БД категорически не советую. Отвалится чего-нибудь — не поймаете. :) Подцепляться к ранее имевшимся БД — в принципе, это можно сделать. Проблема будет в определении изменений данных — а тут либо полное сканирование, либо утомительная привязка через триггеры. Так что наиболее простым вариантом является реализация регулярного пересканирования существующих таблиц с экспортом «дельты» в MindApps. Т.е. поддержание на стороне MindApps адекватного образа Вашей системы.
дизайн на google wave похож…
К Вам десяток SugarCRM можно загрузить, чтоб работало и автоматически переключалось? Не нужны эти карты памяти, мы лучше на PHP.
Я не понял вопрос — что значит «переключалось»? Да, десяток приложений — запущенных серверов — на одном сервере работает легко. Нам вот в Агаве вырезали кусок облака 500мб x 500мГц — там сейчас пять инстанс системы работает, и ничего, далеко пока до насыщения.
Карты памяти интересны не сами по себе, а как элемент методики. Направленной на быстроту и безошибочность изменений системы управления. Никого не агитируем на переход с PHP. Пока, во всяком случае. :)
Карты памяти интересны не сами по себе, а как элемент методики. Направленной на быстроту и безошибочность изменений системы управления. Никого не агитируем на переход с PHP. Пока, во всяком случае. :)
Интерфейс у вас адски плохой, уж не обижайтесь, но это майкрософт в своем худшем проявлении, Access, меню Пуск и проводник нервно курят в сторонке.
Юзабилити тоже на очень низком уровне ((
И да, вы декларируете идею «программировать без программистов», а как вы думаете, что говорят слова «майндлет», «виджет» и UML-диаграммы не-программисту? Правильно, ничего. Более того, что будет делать ваша рисовалка форм, когда понадобиться что-то сделать нестандартное, шаг влево, шаг вправо? Будете добавлять свой скриптовый язык?
Ну и отдельно я бы покритиковал используемые технологии — С++ с его потенциальными багами и утечками памяти, FireBird (это однопользовательская встроенняа БД, со всеми минусами, так?) и Windows.
Я понимаю, что нелегко наверно было все это писать, но лично я не верю в возможность создания чего-то хорошо работающего через GUI. Максимум, что получится — помесь Visio с экселем/аксессом, только с веб-интефрйесом. Не знаю. тянет ли это на гордое звание «информационной системы».
Юзабилити тоже на очень низком уровне ((
И да, вы декларируете идею «программировать без программистов», а как вы думаете, что говорят слова «майндлет», «виджет» и UML-диаграммы не-программисту? Правильно, ничего. Более того, что будет делать ваша рисовалка форм, когда понадобиться что-то сделать нестандартное, шаг влево, шаг вправо? Будете добавлять свой скриптовый язык?
Ну и отдельно я бы покритиковал используемые технологии — С++ с его потенциальными багами и утечками памяти, FireBird (это однопользовательская встроенняа БД, со всеми минусами, так?) и Windows.
Я понимаю, что нелегко наверно было все это писать, но лично я не верю в возможность создания чего-то хорошо работающего через GUI. Максимум, что получится — помесь Visio с экселем/аксессом, только с веб-интефрйесом. Не знаю. тянет ли это на гордое звание «информационной системы».
Спасибо. Я отвечу по пунктам.
1.
Уровень юзабилити мы старались сделать по возможности максимально высоким. Что получилось — вынесено на ваш суд. Поэтому, буду очень признателен за конструктивную критику. Неудобно сделать то и то, некравсиво выглядит это, совершенно непонятно здесь и т.п. А ещё лучше — «в этом месте предлагаю сделать так-то». Иначе мне не очень понятно, что делать с такой информацией, кроме что посыпать голову из пепельницы.
2.
«Майндлет» и «виджет» используются на этапе представления концепта технологии. Как бы я без них обошёлся в представлении того, что есть? В продуктовом варианте их можно прикрыть ветошью. Во-вторых, они не являются обязательными для использования. Виджет назначается только для нестандартной кастомизации. Mindlet — для выкладывания фрейма на сайт. Если это не нужно/не понятно — использовать не обязательно. Будут обычные операции со стандартными таблицами.
UML мы не используем — слишком сложно, кухарке не осилить. Нам надо проще.
Если нужно сделать нестандартное, есть два пути:
1. Настройка виджетов. Каждый виджет поддерживает кучу форматов, которые задают разные режимы отображения, настраивают внешний вид и т.п. Сейчас ими пользоваться не очень удобно, т.к. надо держать под рукой справочник виджетов и их форматов. Будем переделывать на контекстный выбор из списка.
2. Если ни один виджет требуемое делать не может — его можно написать и подключить. А потом использовать в других приложениях.
Т.е., набор виджетов должен, по идее, закрывать всё пространство ситуаций возникающих потребностей размещения элементов. Если в пространстве «дырка», не прикрытая виджетом, его нужно сделать и включить как элемент методики.
Своего скриптового языка не планируется.
3.
C++ — потому что он самый быстрый и переносимый. Для платформы производительность критична. FireBird — потому, что он свободный. В принципе можно подключить любую базу, дело нехитрое. Под Линукс скомпилируемся и выложим дистрибутив, попозже.
1.
Уровень юзабилити мы старались сделать по возможности максимально высоким. Что получилось — вынесено на ваш суд. Поэтому, буду очень признателен за конструктивную критику. Неудобно сделать то и то, некравсиво выглядит это, совершенно непонятно здесь и т.п. А ещё лучше — «в этом месте предлагаю сделать так-то». Иначе мне не очень понятно, что делать с такой информацией, кроме что посыпать голову из пепельницы.
2.
«Майндлет» и «виджет» используются на этапе представления концепта технологии. Как бы я без них обошёлся в представлении того, что есть? В продуктовом варианте их можно прикрыть ветошью. Во-вторых, они не являются обязательными для использования. Виджет назначается только для нестандартной кастомизации. Mindlet — для выкладывания фрейма на сайт. Если это не нужно/не понятно — использовать не обязательно. Будут обычные операции со стандартными таблицами.
UML мы не используем — слишком сложно, кухарке не осилить. Нам надо проще.
Если нужно сделать нестандартное, есть два пути:
1. Настройка виджетов. Каждый виджет поддерживает кучу форматов, которые задают разные режимы отображения, настраивают внешний вид и т.п. Сейчас ими пользоваться не очень удобно, т.к. надо держать под рукой справочник виджетов и их форматов. Будем переделывать на контекстный выбор из списка.
2. Если ни один виджет требуемое делать не может — его можно написать и подключить. А потом использовать в других приложениях.
Т.е., набор виджетов должен, по идее, закрывать всё пространство ситуаций возникающих потребностей размещения элементов. Если в пространстве «дырка», не прикрытая виджетом, его нужно сделать и включить как элемент методики.
Своего скриптового языка не планируется.
3.
C++ — потому что он самый быстрый и переносимый. Для платформы производительность критична. FireBird — потому, что он свободный. В принципе можно подключить любую базу, дело нехитрое. Под Линукс скомпилируемся и выложим дистрибутив, попозже.
Поставил огромный и толстый плюс.
Давно на Хабре не было таких красивых разработок.
Завтра будем тестировать в офисе. Если всё красиво, ждите предложений)
p.s. как планируете АПИ для сторонних сервисов?
Давно на Хабре не было таких красивых разработок.
Завтра будем тестировать в офисе. Если всё красиво, ждите предложений)
p.s. как планируете АПИ для сторонних сервисов?
Спасибо!
Для сторонних сервисов уже сейчас есть API через XML, правда в собственном внутреннем формате. Описывается внешний сервис с несколькими «точками», на каждую назначается форма, как при составлении майндлета. К «точке» можно обращаться снаружи, либо она сама может инициировать обмен. Приведение форматов XML проводится на нашей стороне с помощью назначаемого на «точку» XSL. Если интересно, то изладим раздел доки на сайт, сейчас там этого нет.
А вообще-то, планируем тут сделать две вещи.
1. Поддержать стандартные протоколы, типа SOAP/WSDL. Майндлет мог бы выдавать соответствующие описания. Правда, мы пока не слишком погружены в этот вопрос, тут надо отдельно разбираться.
2. Мы хотим поддержать и опубликовать собственный XML-протокол обмена информацией — между источниками инфорамции, т.е. ядрами MindApps и совместимыми приложениями. Инкрементальный, типа RSS, только приспособленный для интеграции структурных данных. Это откроет замечательные перспективы по интеграции всего чего можно.
Для сторонних сервисов уже сейчас есть API через XML, правда в собственном внутреннем формате. Описывается внешний сервис с несколькими «точками», на каждую назначается форма, как при составлении майндлета. К «точке» можно обращаться снаружи, либо она сама может инициировать обмен. Приведение форматов XML проводится на нашей стороне с помощью назначаемого на «точку» XSL. Если интересно, то изладим раздел доки на сайт, сейчас там этого нет.
А вообще-то, планируем тут сделать две вещи.
1. Поддержать стандартные протоколы, типа SOAP/WSDL. Майндлет мог бы выдавать соответствующие описания. Правда, мы пока не слишком погружены в этот вопрос, тут надо отдельно разбираться.
2. Мы хотим поддержать и опубликовать собственный XML-протокол обмена информацией — между источниками инфорамции, т.е. ядрами MindApps и совместимыми приложениями. Инкрементальный, типа RSS, только приспособленный для интеграции структурных данных. Это откроет замечательные перспективы по интеграции всего чего можно.
Это очень круто! Добавил mindapps в список потенциальных конкурентов, так как сам принимаю участие в разработке похожего продукта, по крайней мере с схожими целями:)
Вы у меня теперь в списке с такими платформами как
* zoho
* dabbledb
* app2you
* long jump
* force.com
* novabit nucleus
* caspio
Спасибо за идею интеграции части системы через iframe, возьмем на заметку!
А как собираетесь зарабатывать деньги? поделитесь вашей стратегией? Вот я считаю, что сама по себе такая платформа не сильно востребована, т.к. требует заметных усилий по разьяснениям как пользоваться, людем не совсем понятно (не айтишникам, да и тем не всем) что с ней делать, большинство просто не видит потенциала.
Думаю, что начинать надо со стандартных продуктов, основанных на собственной платформе и иметь преимущество быстрого расширения благодаря ей. И только после начальной «раскрутки» именно конкретных продуктовых сервисов предлагать саму платформу как сервис.
Вы у меня теперь в списке с такими платформами как
* zoho
* dabbledb
* app2you
* long jump
* force.com
* novabit nucleus
* caspio
Спасибо за идею интеграции части системы через iframe, возьмем на заметку!
А как собираетесь зарабатывать деньги? поделитесь вашей стратегией? Вот я считаю, что сама по себе такая платформа не сильно востребована, т.к. требует заметных усилий по разьяснениям как пользоваться, людем не совсем понятно (не айтишникам, да и тем не всем) что с ней делать, большинство просто не видит потенциала.
Думаю, что начинать надо со стандартных продуктов, основанных на собственной платформе и иметь преимущество быстрого расширения благодаря ей. И только после начальной «раскрутки» именно конкретных продуктовых сервисов предлагать саму платформу как сервис.
Это у вас хороший список, правильный. Спасибо :)
У нас в списке есть netsuite.com с языком SuiteFlex, и ещё был cogheads.com. Проект Cogheads был симпатичным, очень похож на упомянутый geticeberg, быстро рос, но… закрылся.
По стратегии. Имеет смысл предлагать и приложения, и платформу (как инструмент управления в нашем случае), и продвигать создание контента. Как оно сработает — не знаю, посмотрим.
По стратегии. Имеет смысл предлагать и приложения, и платформу (как инструмент управления в нашем случае), и продвигать создание контента. Как оно сработает — не знаю, посмотрим.
а вы вкурсе, что Coghead не совсем закрылся, а был куплен SAP?
Спасибо, пропустил новость, почитал.
Как пишут, SAP купил IP, взял к себе персонал и перестал предоставлять сервис. Довольно жёстко, на мой вкус.
Кстати, похожая история была с покупкой года три назад BusinessObjects'ом симпатичного стартапа nsite.com. Тоже составление приложений в онлайне через drag-n-drop. После этого про них перестало быть слышно. А потом SAP купил и BusinessObjects. :)
Как пишут, SAP купил IP, взял к себе персонал и перестал предоставлять сервис. Довольно жёстко, на мой вкус.
Кстати, похожая история была с покупкой года три назад BusinessObjects'ом симпатичного стартапа nsite.com. Тоже составление приложений в онлайне через drag-n-drop. После этого про них перестало быть слышно. А потом SAP купил и BusinessObjects. :)
Коллеги, добавился видеоролик, показывающий составление процессных приложений.
Упс, промахнулся: видеоролик.
Исправлен дистрибутив, который не всегда работал. У кого он не запускался — попробуйте снова, пожалуйста.
Что могу сказать… Часок поигрался. Сделай небольшую систему для Школы. Ученики, учителя, уроки. Не понял нескольких вещей:
— как всё таки права сделать. Не смог добиться того, что бы учитель создавал уроки, а ученик их мог только видеть
— что делает кнопка Экспорт приложения? При нажатии на неё идёт загрузка и всё. Никаких изменений.
— расскажите немного подробнее про лицензию и сотрудничество с вами, если есть идея использования вашего продукта в неком проекте, как возможность (интеграция)
— исходники фронтенда будут?
— как всё таки права сделать. Не смог добиться того, что бы учитель создавал уроки, а ученик их мог только видеть
— что делает кнопка Экспорт приложения? При нажатии на неё идёт загрузка и всё. Никаких изменений.
— расскажите немного подробнее про лицензию и сотрудничество с вами, если есть идея использования вашего продукта в неком проекте, как возможность (интеграция)
— исходники фронтенда будут?
1. Нужно завести отдельные операции для учителя и для ученика. Затем, нужно запустить операцию «Администрирование», и на ней, сверху, нажать кнопку «Должности».
Создать отдельные должности для учителя и ученика, наполнив их нужными операциями. Остальное можно не трогать.
После этого завести соответствующих пользователей, не забыв назначить им нужную Должность. Вуаля. Если хотите, чтобы ученики заходили без имени, то ззаводите пользователя anonymous без пароля.
Вообще про администрирование написано в доке, — но эти разделы написаны в жуткой спешке, сейчас переделываем.
2. Кнопка Экспорт создаёт в каталоге MindApps/syslog/export xml-файл, в котором содержатся Ваши схемы. Если будете создавать новую базу, то файл экспорта можно поместить в отдельный каталог и загружать командой load. Т.е. распространяемой логикой приложения сейчас является именно файл экспорт. См. файлы @go (запуск без базы) или @install (создание базы) в MindApps/bin — загрузка Вашего каталога с экспортом должна быть между load install и load start. Сейчас на этом месте стоит загрузка примеров приложений — майндлетов (каталог comments) и тестового процесса (process).
3. Лицензия прилагается к дистрибутиву, а также доступна на сайте внизу страницы: Соглашение об использовании. Комментарий по её духу я давал в этом топике выше.
Насчёт использвоания в проекте — я «за», и готов поддержать чем в наших силах. Конечно, для этого надо бы знать подробнее, что за проект. Пишите, пожалуйста, на avk@myvision.ru, в личку, форму на сайте или куда Вам удобно.
4. JS-ники веб-интерфейса в поджатом виде лежат в каталоге MindApps/website. Роботом вырезаны пробелы, лишние переводы строк и комменты. Знакомство с исходными «необработанными» текстами для будущих писателей виджетов, скорее всего, будет просто необходимо. Когда они будут выложены в доступ, я напишу.
Создать отдельные должности для учителя и ученика, наполнив их нужными операциями. Остальное можно не трогать.
После этого завести соответствующих пользователей, не забыв назначить им нужную Должность. Вуаля. Если хотите, чтобы ученики заходили без имени, то ззаводите пользователя anonymous без пароля.
Вообще про администрирование написано в доке, — но эти разделы написаны в жуткой спешке, сейчас переделываем.
2. Кнопка Экспорт создаёт в каталоге MindApps/syslog/export xml-файл, в котором содержатся Ваши схемы. Если будете создавать новую базу, то файл экспорта можно поместить в отдельный каталог и загружать командой load. Т.е. распространяемой логикой приложения сейчас является именно файл экспорт. См. файлы @go (запуск без базы) или @install (создание базы) в MindApps/bin — загрузка Вашего каталога с экспортом должна быть между load install и load start. Сейчас на этом месте стоит загрузка примеров приложений — майндлетов (каталог comments) и тестового процесса (process).
3. Лицензия прилагается к дистрибутиву, а также доступна на сайте внизу страницы: Соглашение об использовании. Комментарий по её духу я давал в этом топике выше.
Насчёт использвоания в проекте — я «за», и готов поддержать чем в наших силах. Конечно, для этого надо бы знать подробнее, что за проект. Пишите, пожалуйста, на avk@myvision.ru, в личку, форму на сайте или куда Вам удобно.
4. JS-ники веб-интерфейса в поджатом виде лежат в каталоге MindApps/website. Роботом вырезаны пробелы, лишние переводы строк и комменты. Знакомство с исходными «необработанными» текстами для будущих писателей виджетов, скорее всего, будет просто необходимо. Когда они будут выложены в доступ, я напишу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стартап: операционная веб-платформа MindApps