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

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

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

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

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

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

Принцыпы проекта:
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 счету.
Фирштейн?Не до конца. Пока не понимаю, что именно будет движком при таком подходе. И физически - где это благолепие храниться будет?
Движком будет то что предлагается создать! Елки!