Как и обещал в ветке "А не кажется ли вам что все создано до нас" начал новую.

Тема задана в "теме".

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

Для начала, те кто выссказывался ЗА создание такого ресурса... как вообще... как вы реально думаете работать над этим. Если не передумали еще :).

Нарооод! Это не утопия! Поверьте.
Мысть материальна, а время камень точит.

Пусть даже ЭТОТ не закончится чем то большим и красивым. Но движение будет.

Принцыпы проекта:
1) Никто ничего не скрывает
2) Проект целиком и полностью открыт (и опубликован)
3) Все идеи приходят людям в головы одновременно и неча тут фиговым листком прикрываться
4) Главная ценность проекта в осязаемой РЕАЛИЗАЦИИ!

Уважаемый guest_20040621, Ваш пост стоит того чтобы комментировать его по частям. Я без сарказма.
guest_20040621Alexsalog, у Вас энтузиазм закончился или Вы ответы обдумываете?Нет, просто я живу в другом часовом поясе. Вот Вам и коммуникации... которые не проблема.
guest_20040621Представьте, что через пару недель в Вашем распоряжении сервер с нормальным пакетом для коллективной работы. Что Вы с ним делать будете? Хранить в Subversion заметки? Сервер для коллективной работы... Он уже есть в моем распоряжении. Форум. Вот этот. Как не смешно. Но вероятно отсюда погонят и придется плестись на forge.
guest_20040621 Коммуникации и код - вещи даже не десятые по счету. Это не просто, а очень просто. За деньги или open source - не принципиально. Собственно идеи есть? Есть.
guest_20040621 Вы в курсе основных тенденций разработки? В курсе, какие свободные пакеты для учетных систем есть? Их недостатки и преимущества? Ограничения реализаций? Популярность? Посмотрел в общей сложности 4 пакета. Два из них платных=коммерческих=закрытых. Плюс собственный 15 летний опыт работы с разными системами и общением с очень многими разными пользователями и т.д. и т.п.
guest_20040621Модель продвижения таких продуктов Вы себе отчетливо представляете? Или просто есть абстрактное желание начать, а дальше видно будет? Есть желание начать. Есть желание не сидеть в своем болотце и не лепить местечковую и ограниченную поделку.
Ок. Я тогда расскажу и покажу что я себе представляю.
Видите ли. Недаром я критиковал систему программирования в и уровень абстракций одной известной и замечательной программы (/оглядывается/)... Ибо это ствол и ветки на котором потом растут листики частных реализаций. Цель я сформулировал ранее, хотя и не выделил её жирным. Цель исходит из основного недовольства: мне не нравится 1С НЕ как продукт несущий безусловное благо огромному количеству её пользователей. Мне не нравится 1С изнутри - с точки зрения разработчика. Процедурный язык а-ля клиппер... Дефалтное (за тебя все подумали - успокойся) решение интерфейса, органичения тут и там. Я НЕ МОГУ себя заставить программировать на этом.
Возможно есть иной выход, чем будоражить занятых людей на популярном форуме: сходить к психоаналитику. Но мне больше нравится "перейти речку". А не упаковывать свои пусть и комплексы, а может и не комплексы, судя по тому что мои "предощущения" не оригинальны - в маленькую коробочку и оставлять там гнить. Я хочу что-то СДЕЛАТЬ. И одним из условий этого "что-то" является работа в среде подобных (единомышленников) а не "утешительное" творчество в скорбном одиночестве дома. :)

Идеи есть. Для начала вот это сайт (я сделал). Это частично то, о чем я думаю: gather-point.by.ru

LamazoidПредлагаю начать с ЦЕЛИ Проекта (только нетакой - догнать и обогнать 1Ц ), например:
Создать продукт который позволит учитывать следующие области человеческой деятельности..... Да, без цели никуда. И именно в этом момент - сейчас могут начаться трудности. Ибо сейчас выяснится что каждый чего то хотел и пока цель не была произнесена, казалось что все вместе. Но после ясной и конкретной формулировки цели выяснится что каждый произносил СЛОН, но представлял что то свое. Итак, мой "слон" это...
>НЕ конкретная ПРИКЛАДНАЯ система.
Это:
> СРЕДСТВО РАЗРАБОТКИ, ориентированное на работу с прикладными данными, вводимыми пользователями и документами .

Начать с МОДЕЛИ приложения сразу заявив ОГРАНИЧЕНИЯ и БАЗОВЫЕ АБСТРАКЦИИ.
Базовые абстракции я вижу (не предлагаю, а вижу) такие (уже говорил):
gather-point.by.ru

Я ДИКО ИЗВИНЯЮСЬ - ПЕРЕПУТАЛ ИМЯ СОБСТВЕННОГО САЙТА!!! :)
У нас тут утро, извините!!!!

Сайт gather-point. nm .ru

Ссылка: gather-point.nm.ru

asdfghjkl AlexsalogСсылка: gather-point.nm.ru
Я дико извиняюсь - это вот те самые идеи, не дающие спать спокойно? Если не секрет, какого плана систему планируется получить на выходе?

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

Отвечаю: система - средство разработки . Это есть и в теме (обратите внимание )и это сказано мной прямым текстом в 3 поста назад.

Ствол и ветки. На которых листики нарастут позднее общественным трудом. Метафора такая. Я уже повторяюсь.

Отчетливо заданные правила в самом начале, достаточно обобщающие абстракции и разработанные классы как раз и дают в итоге "мощное и универсальное" средство разработки.

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

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

MSF. Курс. Там с этого начинали. Оччень полезно.

И даже допускаю что у кого то представленная "модель" вызовет тошноту.
Как у меня вызывает тошноту 1С.

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

Задача разбивается на 2 подзадачи:
1) На основе метаданных представляющих собой преимущественно описание ОТНОШЕНИЙ между данными и отношений данных и пользователей (роли) - построение интерфейса.
2) На основе метаданных описывающих сами данные и метаданных описывающих другие отношения между данными, задающих правила сопостваления различных сущностей вводимых в систему - построение выборок - сырья для аналитических отчетов.

Ключевое слово - отношения . В противоположность процедурному программированию известной системы (/опять затравленно оглянулся/). Отношения в данном контексте - более развитое и изощренное средство чем Relations в Delphi ли, в С# ли касательно таблиц и ДатаСетов.

Отношения - сущность функционального или целеого программирования.

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

asdfghjklб) базовые абстракции как бы это... "неоптимальны".
Представленный вариант не единственный из насуропленных мной в Visio и тетрадках дома.
Иногда рисуешь рисуешь и потом тынц сущность замкнулась на себя.

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

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

asdfghjkl AlexsalogКлючевое слово - отношения . ...
Отношения - сущность функционального или целеого программирования. AlexsalogВместо того чтобы держать "отношение" в голове и реализовывать его в программе в различных местах пытаясь сохранть его согласованность и целостность, предлагается ввести такую сущность в модель , прямо или косвенно включив её в состав метаданных и механизмы среды исполнения.Слово хорошее, механизм применения хочется увидеть.
Вы его уже видели и не раз. Я ж говорю - ничего нового.
Свойство Color компонента Panel - яркий пример применения такого подхода. Задав один раз целевое отношение : <Panel должен быть всегда красным>, мы далее полагаемся на МЕХАНИЗМ, который скрыт в реализации класса Panel, который все это обеспечивает.
Задав отношение Parent_Id=Id мы обеспечиваем отношение один ко многим, а интерфейс (если это включено в возможности соответсвующих компонент) обеспечивает перерисовку о обновление подчиненных списков при движении по MasterTable.

А теперь представьте что данный подход развивается и усугубляется... и ведь при разработке соответсвующей спецификации средств описания таких отношений и весь пресловутый бухучет может быть воспроизведен в некой учетной системе без единого оператора процедурного языка. Исключительно на ОТНОШЕНИЯХ. Представьте какой это дает плюс, когда возникает потребность в откручивании пленки учета назад и когда нужно понять как получился такой итог к книге покупок и почему он не идет с оборотом по 19 счету.
Фирштейн?

asdfghjkl AlexsalogПредставлен вариант как бы наиболее беспроблемный. в части чрезмерного абстрагирования.
Скажите свое слово. Где не оптимально. Как оптимально.В свете нижеизложенного - уже никак, боюсь.Как хотите.
asdfghjkl AlexsalogРеализовав СРЕДСТВО разрабоки клиентской части. Пока ДА.
Структур и сохраненные процедуры можно проектировать и другими средствами.
То есть ПОКА я бы не включал это в проект, а то уж очень размахнемся.
Есть же общее правило для проектов: определите границы.
То есть пока да: средство разработки десктопного клиента базы данных.В-о-о-т. Т.е. идеология среды - а давайте клиентскую часть сбацаем навороченную, а потом с БД её повяжем когда-нибудь. В двухзвенном исполнении, а чего. Я все правильно излагаю?Да. Считаю, что надо начать с двухзвенной и отработать главные механизмы построения GUI. USER INTERFACE. DESKTOP DATABASE CLIENT. Скажите, Вы себе не верите (глазам) или меня проверяте на вменяемость(одинаковость ответов)? Я все это уже написал. Трехзвенку приладить не проблема если с самого начала предусмотреть абстракцию DataBase Mediator. То есть пререписывается только это.

asdfghjkl AlexsalogА теперь представьте что данный подход развивается и усугубляется... и ведь при разработке соответсвующей спецификации средств описания таких отношений и весь пресловутый бухучет может быть воспроизведен в некой учетной системе без единого оператора процедурного языка. Исключительно на ОТНОШЕНИЯХ. Представьте какой это дает плюс, когда возникает потребность в откручивании пленки учета назад и когда нужно понять как получился такой итог к книге покупок и почему он не идет с оборотом по 19 счету.
Фирштейн?Не до конца. Пока не понимаю, что именно будет движком при таком подходе. И физически - где это благолепие храниться будет?
Движком будет то что предлагается создать! Елки!

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

asdfghjkl AlexsalogДвижком будет то что предлагается создать! Елки!Не надо нервничать, все только начинается. ))) И даже до меня доходит, хоть и не всегда сразу. )))Прошу прощения.
asdfghjkl AlexsalogДа. Считаю, что надо начать с двухзвенной и отработать главные механизмы построения GUI. USER INTERFACE. DESKTOP DATABASE CLIENT. Скажите, Вы себе не верите (глазам) или меня проверяте на вменяемость(одинаковость ответов)? Я все это уже написал. Трехзвенку приладить не проблема если с самого начала предусмотреть абстракцию DataBase Mediator. То есть пререписывается только это.Я тоже могу быть невменяемым, не исключайте и этого )))
Подход интересный у Вас к построению среды. С гуя я бы точно не начал, например.
Видите ли. Я считаю что n-звенность важна. Но это технологический аспект определящий методы обращения с большими масивами данных, т.е. где они будут храниться и обрабатываться и куда передаваться.

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

asdfghjkl AlexsalogА храниться оно будет в файлах на жестком диске. Чесс слово.Это серьезно? И все настройки бухучета с анализом чего не так на 19-м счете тоже?Если у нас есть отношения с помощью которых были вычесленны итоги по КП и по 19 счету в отдельности, то можно обратным ходом раскрутить строчки БД, которые образовали эти итоги и сопоставить их по некому условию.
При процедурном подходе, зачастую построение обратной функции невозможно.

Отсюда, можно сформулировать требования к отношениям:

1) Целевое отношение само по себе и каждый вид целевого отношения должна "понимать" среда и соответственно сама среда и есть ограничитель на количество видов отношений. Среда.. - конечная сущность она не может понимать что угодно. Это не человек. Поэтому одним из ограничителей "проекта" может быть разработка достаточно полной и красивой системы видов целевых отношений как данных так и объектов интерфейса. Это и будет зерно "проекта". Определяющая модель.

2) "Отношение" всегда обратимо. Имеет обратную функцию. Двунаправленно. Что опредъявляет особые требования к структуре описания отношений.

[quot asdfghjklНе надо самого себя загонять в жёсткие рамки. Может сформулировать так "разработка механизма создания видов целевых отношений"? А потом фигачить их хоть сотнями, вот тут уже себя тормозить надо.[/quot]

А это и есть разработка внутренностей исполняемой среды, которая по идее с каждой новой версией становится все более умной и быстродействующей. И главное "понимающей".

Вообще надо отделить, что разрабатывается на native средстве типа C++, Delphi или C#, а что надстройке через метаданные.

Слишком много переносить в метаданные значит распрощаться с быстродействием.
Другой вариант Плагины....
Понимаете?

anonimouseНевозможно построить гениальную вещь, беря за основу (уже) банальную, попсовую и даже пошлую идею. Идей пошлее чем в одной одной известной системе я не встречал. Однако взлетела.

Ну хорошо, пусть идея банальная. А реализации этого есть?, раз уж все так попсово.
Попсу вон на каждом шагу поют. На то она и попса.
Я видел пока что: Конструктор форм+Скриптовый язык.
В бОльшей части случаев.
Вот это попса.

И потом, я так понимаю, что Вы мне как культурно отсталому и не намекнете на новые горизонты новизны? Интересно же!

anonimouseКогда за цель берется "сделать как * и даже лучше"
Как где, кстати?
Вы это все просто так сказали? Подколоть или подразнить, я не понял (другие слова тут просто не разрешены).

iscrafm AlexsalogНачать с МОДЕЛИ приложения сразу заявив ОГРАНИЧЕНИЯ и БАЗОВЫЕ АБСТРАКЦИИ.
Базовые абстракции я вижу (не предлагаю, а вижу) такие (уже говорил):
gather-point.NM.ru
Вы нарисовали модель упрощенную ISCRA Framework :) только это уже не нужно разрабатывать. На это уже 5 лет потрачено.У вас платформа нехило стоит. В каждом киоске не продается :) . В инете как Firebird не скачаешь :). И самое главное! нет лицензии для учебных заведений! :).
Демо я кое как запустил, но новое Содержание так добавить и не смог. Низзя видимо. Крюгом пираты.
А так я бы с удовольствием перешел с C# :). Лабал бы всякие програмулины для бухов. Не мучаясь от неполноценности и тупо истраченного времени на разбор постыней кодов с нетипизированнымим переменными, как кое-где... ;-)
Но это я пока так думаю. Я еще и поработать не смог толком в Вашей среде.

Lamazoid Думаю необходимо уходить от среды . НЕобходимо чтобы более менее продвинутый пользователь сам мог создавать объекты и налаживать взаимодействие между ними (некоторые зачатки этого я реализовал в своей программе) Пользователь вообще не должен видеть код.
Я имел ввиду среда исполнения. Не среда разработки.
Когда Ваш пользователь определяет взаимодействие между созданными объектами (у которых есть что то внутри - типа структуры и свойств каждого элемента) это тоже самое сказать что он задает целевые отношения между ними.
Ну и вот. Я надеюсь в одном направлении мыслим. Терминология разная.

авторПростите мне мою серость, Alexsalog, но, посмотрев на gather-point.nm.ru, не очень понял, в чем фишка. "Cпецификации средств описания таких отношений" существуют в достаточном количестве. И применяются давно и успешно.
О, да, да. Щас. Применяется в толстых книжках по построению структур баз данных.
Но в Аксапте и 1С основой исполнения является последовательность выполняемых выражений.
К понятию целевое отношение это никак не вяжется.

LamazoidА не зная что сделать пытаемся выбрать способ реализации - неитересно получается.

Не знаю как кто, а я платформу.
Plazma вот написана (мне ссылку дали - видели), но видимо на Java. На этом средстве разработки.
Это готовая реализация чего то уже прикладного, возможно и невероятно полезного, но уже конкретная "вещь". А я говорю о средстве разработки! Мне другого пока не надо.

LamazoidА если Вы пишите платформу - то посмотрите скока их создано - и какие из них не обхаиваются программистами. А почему например не обхаивают так сильно VB или С# и их разработчиков?
Хорошие языки (среды). Не могу обхаивать. Не то что... ну да ладно.
А если есть свои классы "под себя", то можно очень быстро писать.
Ну да и ладно. Я так и делал :).

И многие так делают. Ну нет так нет.

anonimouseНо перспективен в отличие от...
Пойду застрелюсь :).

anonimouse авторНе самая плохая характеристика

Гы.Гы.

Нашли-же, чем обнадежить :)

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

Вот с такими пальцАми и чисто конкретным мышлением.

Я в бизнес не прусь.

guest_20040621> По большому счету абсолютно пофиг, как именно они описаны. Вот если бы автор начал с асинхронной service bus (или message bus), - да, это было бы и актуально, и интересно.

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

Послушайте, вот форка мы не знаем и бутстрапа.

Ну так расскжите, если это имеет отношение к прикладной области, а не системным изыскам.

LamazoidДумаю необходимо уходить от среды . НЕобходимо чтобы более менее продвинутый пользователь сам мог создавать объекты и налаживать взаимодействие между ними (некоторые зачатки этого я реализовал в своей программе)

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

Я што то не представляю.

Тоже - подробнее можно?