Во-первых, Оверсан сам спровоцировала накопление задолженности за полгода. Никто не мешал после первого месяца неплатежей подать в арбитраж, ограничить канал на Макхост и выпустить бюллетень для клиентов Макхоста. Например, тут на хабре.
Во-вторых, поворачивая рубильник, Оверсан и РНИИ КП прекрасно знали, что лишают доступа к их законным ресурсам десятки тысяч «непричастных». Нанося прямой урон их бизнесу и репутации.
Мне сложно оценить юридическую допустимость такого отключения «третьих лиц», но это, вообще-то, есть проявление полной безответственности и отсутствия деловой этики. Кроме блюдения буквы договора, надо, вообще-то, понимать последствия своих действий для людей. Не на острове ведь живут.
На мой неюридический взгляд, действия компании Оверсан попадают под это: www.zakonrf.info/uk/274. Размещённые сайты, очевидно, попадают под понятие «охраняемая законом информация», т.к. по праву являются собственностью их владельцев.
Преднамеренное блокируя доступ к законно размещённым сайтам, Оверсан напрашивается на уголовку.
Фактически вопрос звучит так: можно ли (и нужно ли) детей заставлять. И если да, то почему, а если нет, то тем более почему. Не в пионерлагере, разумеется, а в жизни. ;)
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. Роботом вырезаны пробелы, лишние переводы строк и комменты. Знакомство с исходными «необработанными» текстами для будущих писателей виджетов, скорее всего, будет просто необходимо. Когда они будут выложены в доступ, я напишу.
Спасибо, пропустил новость, почитал.
Как пишут, SAP купил IP, взял к себе персонал и перестал предоставлять сервис. Довольно жёстко, на мой вкус.
Кстати, похожая история была с покупкой года три назад BusinessObjects'ом симпатичного стартапа nsite.com. Тоже составление приложений в онлайне через drag-n-drop. После этого про них перестало быть слышно. А потом SAP купил и BusinessObjects. :)
Насчёт проработанности редактора классов — очень приятно, но Вы всё же преувеличиваете. Это наш стандартный виджет mind map'ы. Мы его просто применили к объектам-описателям классов, вывели нужные атрибуты, и подкрасили подсказками. Создание виджета — да, много крови унесло.
Сначала хотели, чтобы «парты»-агрегаты рисовались бы прямо вглубь класса. Но это показалось страшно — не думая наколотят поддерева, а потом в ссылки как рефакторить? В общем, тут ещё думаем.
У нас предусмотрено несколько методов визуализаций выбора («Метод выбора» на рефе в редакторе форм):
1. Инкрементальный, когда по одному полю можно вводить символы, и отправляется поисковый запрос, сужающий список
2. Поисковый, когда по нескольким полям можно ввести подстроки или значения, и затем найти результаты.
3. «Открытый», визуализируется сразу радиокнопками.
Если данных много, то список бьётся на странички. Партиями по 50 штук, если не путаю, но этот параметр задаётся в сервере.
Получится ассоциация. Сама платформа поддерживает и агрегацию, для неё этого разные типы данных (рефа/мультирефа и парта/мультипарта), но агрегация сейчас не вынесена на язык схем — чтобы не запутывать не сильно искушённого пользователя, и уберечь от ошибок изменений.
Т.к. если поменять задним числом класс объекта у агрегации, получится… хм… не очень хорошо, надо отдельно разруливать.
По срокам — примерно в феврале, плюс-минус. Без готовой платформы и ресурса-репозитория привлекать кого-либо рано, разве что для начального ознакомления (что я и делаю:). Буду рад обсудить с Вами соображения по почте, avk@myvision.ru
Ну, если сделать имя объекта длиннее 30 символов, оно не войдёт в SQL-ную таблицу. Имя таблицы будет изуродовано с привлечением MD5. Далее, списочные стуркутры сейчас хранятся в отдельных табличках, они тоже имеют особую структуру. Далее, есть намерения не хранить скаляры по-отдельности, а упаковывать в блобы. Это должно увеличить быстродействие, но уменьшить возможность прямого использвоания таблиц. Ну и т.д. Пока всё сделано довольно минималистически.
Самому вручную изменять автосгенерированную БД категорически не советую. Отвалится чего-нибудь — не поймаете. :) Подцепляться к ранее имевшимся БД — в принципе, это можно сделать. Проблема будет в определении изменений данных — а тут либо полное сканирование, либо утомительная привязка через триггеры. Так что наиболее простым вариантом является реализация регулярного пересканирования существующих таблиц с экспортом «дельты» в MindApps. Т.е. поддержание на стороне MindApps адекватного образа Вашей системы.
У нас в списке есть netsuite.com с языком SuiteFlex, и ещё был cogheads.com. Проект Cogheads был симпатичным, очень похож на упомянутый geticeberg, быстро рос, но… закрылся.
По стратегии. Имеет смысл предлагать и приложения, и платформу (как инструмент управления в нашем случае), и продвигать создание контента. Как оно сработает — не знаю, посмотрим.
Для сторонних сервисов уже сейчас есть API через XML, правда в собственном внутреннем формате. Описывается внешний сервис с несколькими «точками», на каждую назначается форма, как при составлении майндлета. К «точке» можно обращаться снаружи, либо она сама может инициировать обмен. Приведение форматов XML проводится на нашей стороне с помощью назначаемого на «точку» XSL. Если интересно, то изладим раздел доки на сайт, сейчас там этого нет.
А вообще-то, планируем тут сделать две вещи.
1. Поддержать стандартные протоколы, типа SOAP/WSDL. Майндлет мог бы выдавать соответствующие описания. Правда, мы пока не слишком погружены в этот вопрос, тут надо отдельно разбираться.
2. Мы хотим поддержать и опубликовать собственный XML-протокол обмена информацией — между источниками инфорамции, т.е. ядрами MindApps и совместимыми приложениями. Инкрементальный, типа RSS, только приспособленный для интеграции структурных данных. Это откроет замечательные перспективы по интеграции всего чего можно.
1.
Уровень юзабилити мы старались сделать по возможности максимально высоким. Что получилось — вынесено на ваш суд. Поэтому, буду очень признателен за конструктивную критику. Неудобно сделать то и то, некравсиво выглядит это, совершенно непонятно здесь и т.п. А ещё лучше — «в этом месте предлагаю сделать так-то». Иначе мне не очень понятно, что делать с такой информацией, кроме что посыпать голову из пепельницы.
2.
«Майндлет» и «виджет» используются на этапе представления концепта технологии. Как бы я без них обошёлся в представлении того, что есть? В продуктовом варианте их можно прикрыть ветошью. Во-вторых, они не являются обязательными для использования. Виджет назначается только для нестандартной кастомизации. Mindlet — для выкладывания фрейма на сайт. Если это не нужно/не понятно — использовать не обязательно. Будут обычные операции со стандартными таблицами.
UML мы не используем — слишком сложно, кухарке не осилить. Нам надо проще.
Если нужно сделать нестандартное, есть два пути:
1. Настройка виджетов. Каждый виджет поддерживает кучу форматов, которые задают разные режимы отображения, настраивают внешний вид и т.п. Сейчас ими пользоваться не очень удобно, т.к. надо держать под рукой справочник виджетов и их форматов. Будем переделывать на контекстный выбор из списка.
2. Если ни один виджет требуемое делать не может — его можно написать и подключить. А потом использовать в других приложениях.
Т.е., набор виджетов должен, по идее, закрывать всё пространство ситуаций возникающих потребностей размещения элементов. Если в пространстве «дырка», не прикрытая виджетом, его нужно сделать и включить как элемент методики.
Своего скриптового языка не планируется.
3.
C++ — потому что он самый быстрый и переносимый. Для платформы производительность критична. FireBird — потому, что он свободный. В принципе можно подключить любую базу, дело нехитрое. Под Линукс скомпилируемся и выложим дистрибутив, попозже.
Я не понял вопрос — что значит «переключалось»? Да, десяток приложений — запущенных серверов — на одном сервере работает легко. Нам вот в Агаве вырезали кусок облака 500мб x 500мГц — там сейчас пять инстанс системы работает, и ничего, далеко пока до насыщения.
Карты памяти интересны не сами по себе, а как элемент методики. Направленной на быстроту и безошибочность изменений системы управления. Никого не агитируем на переход с PHP. Пока, во всяком случае. :)
В команде 5 человек (до июня было 4). Один на прошлой неделе в армию ушёл, так что сейчас опять четыре.
Смотря с какого момента. Наша история довольно сложная. Нынешняя стадия началась в ноябре прошлого года.
Все данные хранятся в одном месте — в Едином Дереве. Обладатели дистрибутива могут с консоли подать команду #dump и посмотреть в корне бинарника файл dump.xml, как оно там структурировано. Метаданные являются обычными данными, только «системных» классов, на которых навешено специальное поведение. А сама память-дерево мапится на базу данных, и хранится в ней. Структура таблиц соответствует структуре объектов — до тех пор, пока это возможно.
Во-вторых, поворачивая рубильник, Оверсан и РНИИ КП прекрасно знали, что лишают доступа к их законным ресурсам десятки тысяч «непричастных». Нанося прямой урон их бизнесу и репутации.
Мне сложно оценить юридическую допустимость такого отключения «третьих лиц», но это, вообще-то, есть проявление полной безответственности и отсутствия деловой этики. Кроме блюдения буквы договора, надо, вообще-то, понимать последствия своих действий для людей. Не на острове ведь живут.
Преднамеренное блокируя доступ к законно размещённым сайтам, Оверсан напрашивается на уголовку.
Создать отдельные должности для учителя и ученика, наполнив их нужными операциями. Остальное можно не трогать.
После этого завести соответствующих пользователей, не забыв назначить им нужную Должность. Вуаля. Если хотите, чтобы ученики заходили без имени, то ззаводите пользователя 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. Роботом вырезаны пробелы, лишние переводы строк и комменты. Знакомство с исходными «необработанными» текстами для будущих писателей виджетов, скорее всего, будет просто необходимо. Когда они будут выложены в доступ, я напишу.
Как пишут, SAP купил IP, взял к себе персонал и перестал предоставлять сервис. Довольно жёстко, на мой вкус.
Кстати, похожая история была с покупкой года три назад BusinessObjects'ом симпатичного стартапа nsite.com. Тоже составление приложений в онлайне через drag-n-drop. После этого про них перестало быть слышно. А потом SAP купил и BusinessObjects. :)
Насчёт проработанности редактора классов — очень приятно, но Вы всё же преувеличиваете. Это наш стандартный виджет mind map'ы. Мы его просто применили к объектам-описателям классов, вывели нужные атрибуты, и подкрасили подсказками. Создание виджета — да, много крови унесло.
Сначала хотели, чтобы «парты»-агрегаты рисовались бы прямо вглубь класса. Но это показалось страшно — не думая наколотят поддерева, а потом в ссылки как рефакторить? В общем, тут ещё думаем.
У нас предусмотрено несколько методов визуализаций выбора («Метод выбора» на рефе в редакторе форм):
1. Инкрементальный, когда по одному полю можно вводить символы, и отправляется поисковый запрос, сужающий список
2. Поисковый, когда по нескольким полям можно ввести подстроки или значения, и затем найти результаты.
3. «Открытый», визуализируется сразу радиокнопками.
Если данных много, то список бьётся на странички. Партиями по 50 штук, если не путаю, но этот параметр задаётся в сервере.
Т.к. если поменять задним числом класс объекта у агрегации, получится… хм… не очень хорошо, надо отдельно разруливать.
Самому вручную изменять автосгенерированную БД категорически не советую. Отвалится чего-нибудь — не поймаете. :) Подцепляться к ранее имевшимся БД — в принципе, это можно сделать. Проблема будет в определении изменений данных — а тут либо полное сканирование, либо утомительная привязка через триггеры. Так что наиболее простым вариантом является реализация регулярного пересканирования существующих таблиц с экспортом «дельты» в MindApps. Т.е. поддержание на стороне MindApps адекватного образа Вашей системы.
По стратегии. Имеет смысл предлагать и приложения, и платформу (как инструмент управления в нашем случае), и продвигать создание контента. Как оно сработает — не знаю, посмотрим.
Для сторонних сервисов уже сейчас есть API через XML, правда в собственном внутреннем формате. Описывается внешний сервис с несколькими «точками», на каждую назначается форма, как при составлении майндлета. К «точке» можно обращаться снаружи, либо она сама может инициировать обмен. Приведение форматов XML проводится на нашей стороне с помощью назначаемого на «точку» XSL. Если интересно, то изладим раздел доки на сайт, сейчас там этого нет.
А вообще-то, планируем тут сделать две вещи.
1. Поддержать стандартные протоколы, типа SOAP/WSDL. Майндлет мог бы выдавать соответствующие описания. Правда, мы пока не слишком погружены в этот вопрос, тут надо отдельно разбираться.
2. Мы хотим поддержать и опубликовать собственный XML-протокол обмена информацией — между источниками инфорамции, т.е. ядрами MindApps и совместимыми приложениями. Инкрементальный, типа RSS, только приспособленный для интеграции структурных данных. Это откроет замечательные перспективы по интеграции всего чего можно.
1.
Уровень юзабилити мы старались сделать по возможности максимально высоким. Что получилось — вынесено на ваш суд. Поэтому, буду очень признателен за конструктивную критику. Неудобно сделать то и то, некравсиво выглядит это, совершенно непонятно здесь и т.п. А ещё лучше — «в этом месте предлагаю сделать так-то». Иначе мне не очень понятно, что делать с такой информацией, кроме что посыпать голову из пепельницы.
2.
«Майндлет» и «виджет» используются на этапе представления концепта технологии. Как бы я без них обошёлся в представлении того, что есть? В продуктовом варианте их можно прикрыть ветошью. Во-вторых, они не являются обязательными для использования. Виджет назначается только для нестандартной кастомизации. Mindlet — для выкладывания фрейма на сайт. Если это не нужно/не понятно — использовать не обязательно. Будут обычные операции со стандартными таблицами.
UML мы не используем — слишком сложно, кухарке не осилить. Нам надо проще.
Если нужно сделать нестандартное, есть два пути:
1. Настройка виджетов. Каждый виджет поддерживает кучу форматов, которые задают разные режимы отображения, настраивают внешний вид и т.п. Сейчас ими пользоваться не очень удобно, т.к. надо держать под рукой справочник виджетов и их форматов. Будем переделывать на контекстный выбор из списка.
2. Если ни один виджет требуемое делать не может — его можно написать и подключить. А потом использовать в других приложениях.
Т.е., набор виджетов должен, по идее, закрывать всё пространство ситуаций возникающих потребностей размещения элементов. Если в пространстве «дырка», не прикрытая виджетом, его нужно сделать и включить как элемент методики.
Своего скриптового языка не планируется.
3.
C++ — потому что он самый быстрый и переносимый. Для платформы производительность критична. FireBird — потому, что он свободный. В принципе можно подключить любую базу, дело нехитрое. Под Линукс скомпилируемся и выложим дистрибутив, попозже.
Карты памяти интересны не сами по себе, а как элемент методики. Направленной на быстроту и безошибочность изменений системы управления. Никого не агитируем на переход с PHP. Пока, во всяком случае. :)
Смотря с какого момента. Наша история довольно сложная. Нынешняя стадия началась в ноябре прошлого года.
Все данные хранятся в одном месте — в Едином Дереве. Обладатели дистрибутива могут с консоли подать команду #dump и посмотреть в корне бинарника файл dump.xml, как оно там структурировано. Метаданные являются обычными данными, только «системных» классов, на которых навешено специальное поведение. А сама память-дерево мапится на базу данных, и хранится в ней. Структура таблиц соответствует структуре объектов — до тех пор, пока это возможно.