Comments 16
Конечно будет удобно программировать мышкой, не вникая даже на каком языке вы пишете. Но с другой стороны порог вхождение в программирование станет таким низким… что хорошо написанный и оптимизированный код будет встречаться еще реже чем сейчас.
ну вот скажите это вам пришло в голову самому или списали :)? ну а если серьезно, мы уже порядка двух лет развивает примерную концепцию "объекты + связи + сервисы". Относительно «Кодирование без кода» пока не получится, возможно в дальнейшем, когда будет набор взаимосвязанных клиент-серверных компонентов (таблицы, формы, прочее..). Однако, кодирование тут не такое как обычно, отпадает необходимость реализации вторичного функционала, разработчик сосредотачивается только на бизнес логике которая и делает его приложение уникальным, сосредотачивается на реализации «цимуса».
кстати клонирование приложений тоже имеется ;). Спасибо за статью, рад что есть единомышленники…
Честно, я сам придумал :) Первый пост на эту тему — «Социум как сеть» опубликовал больше года назад. Но если кто-то придумал раньше, я только за. Потому что придумал я это чисто по той причине, что нет сейчас в инете сервиса, который меня бы как пользователя удовлетворял.
Однако сейчас вопрос в другом — действительно ли вы обеспечили «экстремально низкий порог вхождения», как утверждаете там у себя. На мне это проверять — самое то, поскольку я, с одной стороны, в теме, по крайней мере касательно общих идей, с другой стороны — не программист и вообще не знаю технической стороны, даже Друпалом и Вордпрессом не владею.
Однако сейчас вопрос в другом — действительно ли вы обеспечили «экстремально низкий порог вхождения», как утверждаете там у себя. На мне это проверять — самое то, поскольку я, с одной стороны, в теме, по крайней мере касательно общих идей, с другой стороны — не программист и вообще не знаю технической стороны, даже Друпалом и Вордпрессом не владею.
относительность всегда присутствует, платформа пока для программистов, если нет в этом знаний никаких, то и не сварить каши. Вопрос в том, что уровень познаний и кол-во выполняемых работ для старта относительно низкий, но ненулевой :). Хотя развитие зачастую идет в сторону нуля. На данный момент заложена основа на базе которой уже можно будет построить ИДЕ для домохозяек, нужны просто руки, которые сделают наборы компонентов. Главное в архитектуре это изначально заложенно.
Идеи визуализации ЯП носятся в воздухе со времен становления UML, да и ERD весьма похоже… Если на то пошло, могу напомнить, что SQL тоже задумывался как прикладной язык для простых исполнителей, а никак не для программистов/администраторов БД.
Контраргумент, коротко — количество подразумеваемых (надеюсь все понимают, что просто сделать как сказал заказчик — это не то же самое, как сделать с учетом его ожиданий) связей и эффектов почти неизбежно приведут к тому, что язык станет перегружен и, в итоге, бесполезен не обученным пользователям. А если для его использования потребуется его долго упорно изучать — в чем его отличие от остальных ЯП?
Мысль на это — плюшки получит тот, кто придумает как из конкретного «примера», который все же пользователь может сделать не вникая в язык, сгенерировать общий «код», устраняя возникающие по ходу такого абстрагирования противоречия.
Контраргумент, коротко — количество подразумеваемых (надеюсь все понимают, что просто сделать как сказал заказчик — это не то же самое, как сделать с учетом его ожиданий) связей и эффектов почти неизбежно приведут к тому, что язык станет перегружен и, в итоге, бесполезен не обученным пользователям. А если для его использования потребуется его долго упорно изучать — в чем его отличие от остальных ЯП?
Мысль на это — плюшки получит тот, кто придумает как из конкретного «примера», который все же пользователь может сделать не вникая в язык, сгенерировать общий «код», устраняя возникающие по ходу такого абстрагирования противоречия.
Мой месидж красной нитью через все посты — это подход к теме семантического веба не со стороны машин, а со стороны людей, делание проекта в классических канонах того, что теперь требуют от интернет-стартапов относительно их ориентации на свою аудиторию. Поэтому пиарю свою идею проекта под названием «Социальный лифт» со слоганом «Сделай себе имя!» — чтобы массовому пользователю было сразу понятно, зачем ему идти на этот сайт. Осмелюсь утверждать, что в этом человеко-ориентированном и веб-базированном подходе к семантическим технологиям заключается мое изобретение, поскольку глупо было бы утверждать, что я придумал саму модель объекты + связи. С технической стороны к ней как раз уже не то чтобы многие, но подходили. Пожалуй, даже heruvim со своей командой здесь не первый — я в прошлом посте давал ссылки.
Что до визуализации, то я её как раз не очень представляю в массовом веб-сервисе. Скорее что-нибудь похожее на Семантическую вики — там ведь тоже есть типизованные связи (хотя вроде нет типизованных объектов — за ненадобностью, т.к. все объекты по сути одного типа — «Энциклопедическая статья»). Впрочем, меньше всего продумывал этот вопрос. Просто я излагаю не то что полностью продумал со всех сторон, я пока в процессе…
Что до визуализации, то я её как раз не очень представляю в массовом веб-сервисе. Скорее что-нибудь похожее на Семантическую вики — там ведь тоже есть типизованные связи (хотя вроде нет типизованных объектов — за ненадобностью, т.к. все объекты по сути одного типа — «Энциклопедическая статья»). Впрочем, меньше всего продумывал этот вопрос. Просто я излагаю не то что полностью продумал со всех сторон, я пока в процессе…
Концептуальная сложность — люди не могут легко работать со сложными вещами (осбенно портят картинку мета-уровни). Либо описание тривиально/неполно, либо работать с ним сложно. Это одна из главных причин, по которым онтологии еще не захватили мир и не сделали всех счастливыми. То есть «семантические интернеты» призваны разгрузить человека от рутины, но оказалось что для этого нужно сначала найти достаточное количество человек, которые в эту рутину уйдут с головой.
Еще раз напомню про SQL — он тоже задумывался как очень человекоориентированный. В результате он получил ужасные системные недостатки, из-за которых его использование без нецензурной лексики иногда затруднительно.
Про визуализацию: позволю себе предположить, что это вызвано текущей привычкой. Программа <--> исходный текст (даже если без текста как такового — хотя тут возникает вопрос как именно пользователь будет указывать свое пожелание создать какой-либо объект или связь). Недостаток в том, что текст одномерен и любая его структурность вызывается либо стилистикой (при этом возможно создание древовидных структур) либо ссылками внутри самого текста. Предметная область же почти всегда довольно сложная пространственно-временная система — выражать ее через линейный, по сути, текст очень громоздко и непонятно.
И да, дейтсвия пользователя («press any key») — это тоже элемент линейной структуры. По сути, это просто утилитарный язык.
Еще раз напомню про SQL — он тоже задумывался как очень человекоориентированный. В результате он получил ужасные системные недостатки, из-за которых его использование без нецензурной лексики иногда затруднительно.
Про визуализацию: позволю себе предположить, что это вызвано текущей привычкой. Программа <--> исходный текст (даже если без текста как такового — хотя тут возникает вопрос как именно пользователь будет указывать свое пожелание создать какой-либо объект или связь). Недостаток в том, что текст одномерен и любая его структурность вызывается либо стилистикой (при этом возможно создание древовидных структур) либо ссылками внутри самого текста. Предметная область же почти всегда довольно сложная пространственно-временная система — выражать ее через линейный, по сути, текст очень громоздко и непонятно.
И да, дейтсвия пользователя («press any key») — это тоже элемент линейной структуры. По сути, это просто утилитарный язык.
Мне кажется, перечисленные в начале четыре первые операции находятся в границах доступного массовому пользователю в рамках какого-то простого интерфейса. Хотя я не думал, какого именно. Собственно, массовый пользователь и не создает проектов, он просто общается. А в этом плане интерфейс вообще может быть примитивный, например, для любого текстового объекта будет кнопка «комментировать», по которой связь между постом и комментарием создаётся автоматически. Укажут какой-нибудь тег (связь) — хорошо, не укажут — ну и ладно, объект останется в одиночестве посреди океана объектов и не попадет в сообщество родственных объектов, где он мог бы быть как-то полезен и оценен. Т.е. фишка в том, что указывать связей больше и релевантней, а также точнее типизовать объекты будет выгодно в плане социальной самореализации, для получения доступа к максимальному количеству релевантной аудитории. Это — клиенто-ориентированный подход, задействование силы Web 2.0 не только для производства контента, но и для его структурирования.
А кто захочет структурировать более сложные вещи и тем более создавать проекты, тот, вероятно, разберется с чуть более сложным интерфейсом. Как это люди сейчас делают, изучая даже языки программирования.
А кто захочет структурировать более сложные вещи и тем более создавать проекты, тот, вероятно, разберется с чуть более сложным интерфейсом. Как это люди сейчас делают, изучая даже языки программирования.
для safright
Теперь более четко понял вашу мысль.
Настоятельно рекомендую подумать про интерфейс и способности пользователей ;)
Несколько мыслей, основанных на паре лет изучения, прежде всего, концептуальных вопросов, но и методологию и интерфейсы затрагивал — уж больно они важны:
— создать полноценный язык, понятный простому пользователю — невозможно. Проблема в том, что пользователю сложен не язык, а творческая и семантическая нагрузка, заложенная в его использовании. То есть тыкать кнопочки и создавать эти элементы сможет почти любой, а вот собирать их хоть во что-то осмысленное уже не будут, даже если показать простой и красивый пример решения реальной проблемы;
— заданный заранее, ограниченный язык (желательно — без семантической/творческой нагрузки — оставить готовые, тщательно подобранные категории и заранее определить тип добавляемого в них контента) спустя небольшое время может быть освоен даже откровенно слабым пользователем;
— «язык» — это не только результат действий пользователя (для примера — исходники), но и сами действия (работа в IDE). Этот факт только-только осознается, так что здесь есть большой простор для реализации (опять же для примера могу вспомнить статью на хабре, где в исходники встроили виджеты). В совокупности с нелинейной (не текстовой) структурой онтологий это создает очень неоднозначную проблему.
Надеюсь, это даст пару новых направлений вашим размышлениям =)
Настоятельно рекомендую подумать про интерфейс и способности пользователей ;)
Несколько мыслей, основанных на паре лет изучения, прежде всего, концептуальных вопросов, но и методологию и интерфейсы затрагивал — уж больно они важны:
— создать полноценный язык, понятный простому пользователю — невозможно. Проблема в том, что пользователю сложен не язык, а творческая и семантическая нагрузка, заложенная в его использовании. То есть тыкать кнопочки и создавать эти элементы сможет почти любой, а вот собирать их хоть во что-то осмысленное уже не будут, даже если показать простой и красивый пример решения реальной проблемы;
— заданный заранее, ограниченный язык (желательно — без семантической/творческой нагрузки — оставить готовые, тщательно подобранные категории и заранее определить тип добавляемого в них контента) спустя небольшое время может быть освоен даже откровенно слабым пользователем;
— «язык» — это не только результат действий пользователя (для примера — исходники), но и сами действия (работа в IDE). Этот факт только-только осознается, так что здесь есть большой простор для реализации (опять же для примера могу вспомнить статью на хабре, где в исходники встроили виджеты). В совокупности с нелинейной (не текстовой) структурой онтологий это создает очень неоднозначную проблему.
Надеюсь, это даст пару новых направлений вашим размышлениям =)
Спасибо за дискуссию, safright.
> Настоятельно рекомендую подумать про интерфейс и способности пользователей ;)
Конечно, конечно! Этого-то я и боюсь — на этапе конкретного пользовательского интерфейса рассыпется вся идеологическая конструкция. Шутю.
— Что до творческой и семантической нагрузки — тоже есть правда в ваших словах. Это проблема культуры, которая имеет инерцию и всё заметно новое в ней может развиваться лишь постепенно, создавая новую культуру и новую инерцию. Кто вел блоги 10 лет назад? Но и простой пользователь образца 2000 г. отличается от простого пользователя образца 2010. Вероятно, это также вопрос правильной раскрутки. Как сказал бывший рулевой Хабра, Хабр отлично пришелся в ИТ-тусовке, но Автокадабра совсем не имела того же эффекта в тусовке автолюбителей.
— Не уверен в точном понимании вашего термина «язык», но думаю, что фактически любой сервис это оно и есть — заданный шаблон, в котором явно или по умолчанию (по позиционированию самого сервиса) заданы все типы связей между объектами, которые может создавать пользователь (выбор типов объектов тоже ограничен). Эта ограниченность и шаблонность как раз для облегчения нагрузки на пользователя. Поэтому видим современный вариант развития — пользователям предоставляются готовые форматы — блог, форум, соцсеть, интернет-магазин и т. п., если они хотят встроить их в какие-то собственные проекты. Даже сами проекты и те предлагаются стандартные, как например пользовательские порталы в сервисе Flexum. В семантической сети всё может быть изрядно по-другому, это другой подход. Вероятно, в связи с этим способы правильной раскрутки особенно важны…
> Настоятельно рекомендую подумать про интерфейс и способности пользователей ;)
Конечно, конечно! Этого-то я и боюсь — на этапе конкретного пользовательского интерфейса рассыпется вся идеологическая конструкция. Шутю.
— Что до творческой и семантической нагрузки — тоже есть правда в ваших словах. Это проблема культуры, которая имеет инерцию и всё заметно новое в ней может развиваться лишь постепенно, создавая новую культуру и новую инерцию. Кто вел блоги 10 лет назад? Но и простой пользователь образца 2000 г. отличается от простого пользователя образца 2010. Вероятно, это также вопрос правильной раскрутки. Как сказал бывший рулевой Хабра, Хабр отлично пришелся в ИТ-тусовке, но Автокадабра совсем не имела того же эффекта в тусовке автолюбителей.
— Не уверен в точном понимании вашего термина «язык», но думаю, что фактически любой сервис это оно и есть — заданный шаблон, в котором явно или по умолчанию (по позиционированию самого сервиса) заданы все типы связей между объектами, которые может создавать пользователь (выбор типов объектов тоже ограничен). Эта ограниченность и шаблонность как раз для облегчения нагрузки на пользователя. Поэтому видим современный вариант развития — пользователям предоставляются готовые форматы — блог, форум, соцсеть, интернет-магазин и т. п., если они хотят встроить их в какие-то собственные проекты. Даже сами проекты и те предлагаются стандартные, как например пользовательские порталы в сервисе Flexum. В семантической сети всё может быть изрядно по-другому, это другой подход. Вероятно, в связи с этим способы правильной раскрутки особенно важны…
Виктор Ронин сделал некоторые комментарии к этому тексту в обсуждении своего поста у себя в блоге: victorronin.com/2010/06/09/kod-eto-zlo/
Косвенным путем получил еще один отклик, который уместно опубликовать здесь:
Не знаю… на мой взгляд идея исключить программиста из процесса программирования определенно интересна и очень похожа на идею исключить строителей и процесса строительства.
По написанному по ссылке у меня сразу появляются два вопроса (главным образом — по поводу претензий на кодирование):
1. Каким образом пользователь системы сможет (и сможет ли) определять логику домена (предметной области)?
Проблема заключается в том, что далеко не все данные являются явными и вносимыми в систему пользователем, многие данные (например цены) часто вычисляются динамически на основе других данных в системе. В том же примере про квартиры — каким образом и где будут определяться правила вычисления суммы уплаты за создание объекта «Квартира»?
Кстати, вычисления прав на выполнение операций это тоже касается.
2. Как и где пользователь сможет (и сможет ли) определять реакцию системы на ошибки?
Здесь я имею ввиду не столько ошибки ввода данных пользователем, сколько ошибки соединений с БД, обращения к ФС, ошибки рассинхронизации данных. Если системой пользуются несколько пользователей, то неизбежны условия гонок (аналогичные тем, что возникают в многопоточном программировании). В некоторых случаях их можно опускать, но при росте системы это может кончится плачевно (для электронной коммерции — полным провалом системы).
Ответы на эти два вопроса, на мой взгляд, во многом определяют потолок развития инфраструктуры проектов. Замечу, кстати, что простота и доступность системы неквалифицированному пользователю обратно пропорциональны возможностям, предоставляемым системой.
Если ограничиться исключительно CRUDингом (Create/Read/Update/Delete) данных и построением различных их таксономий, то получится нишевый продукт… остается вопрос популярности. Кстати, программы, позволяющие определять «типы» объектов, определять связи и «типы» связей между ними, определять полномочия других пользователей на выполнение операций на ними уже на самом деле есть — это программы для управления СУРБД (за исключением БД MySQL, возможности которой, мягко говоря, ограничены). Обычные обыватели почему-то боятся их как огня.
Еще, что мне приходит в голову — сходство с основами Семантического Веб… в принципе, он предоставляет многие из описанных возможностей «из коробки». Но примечательно то, что на сегодняшний день считается, что для создания онтологии требуется квалификация специалиста выше, чем для ОО-анализа и проектирования. Курсивное замечание из предыдущего абзаца в какой-то мере справедливо и тут — есть программа Protégé, редактор онтологий.
PS
В общем, как мне кажется, такого рода затеи очень часто приводят к попыткам изобретения велосипеда. Яркий пример — дырявый PHP (Personal Home Page), на котором должен был быть способен программировать любой не-программист. А с CMS Битрикс можно играть в «найди пять отличий от СУРБД»… по факту последняя просто оказалась подсистемой в CMS, что явно не сопутствует доступности и простоте.
С другой стороны, конечно, можно ожидать упрощения работы с Семантическим Веб, но ниже какой-то определенной планки он не опустится, необходимость работы с метаданными и их понимания останется точно.
Не знаю… на мой взгляд идея исключить программиста из процесса программирования определенно интересна и очень похожа на идею исключить строителей и процесса строительства.
По написанному по ссылке у меня сразу появляются два вопроса (главным образом — по поводу претензий на кодирование):
1. Каким образом пользователь системы сможет (и сможет ли) определять логику домена (предметной области)?
Проблема заключается в том, что далеко не все данные являются явными и вносимыми в систему пользователем, многие данные (например цены) часто вычисляются динамически на основе других данных в системе. В том же примере про квартиры — каким образом и где будут определяться правила вычисления суммы уплаты за создание объекта «Квартира»?
Кстати, вычисления прав на выполнение операций это тоже касается.
2. Как и где пользователь сможет (и сможет ли) определять реакцию системы на ошибки?
Здесь я имею ввиду не столько ошибки ввода данных пользователем, сколько ошибки соединений с БД, обращения к ФС, ошибки рассинхронизации данных. Если системой пользуются несколько пользователей, то неизбежны условия гонок (аналогичные тем, что возникают в многопоточном программировании). В некоторых случаях их можно опускать, но при росте системы это может кончится плачевно (для электронной коммерции — полным провалом системы).
Ответы на эти два вопроса, на мой взгляд, во многом определяют потолок развития инфраструктуры проектов. Замечу, кстати, что простота и доступность системы неквалифицированному пользователю обратно пропорциональны возможностям, предоставляемым системой.
Если ограничиться исключительно CRUDингом (Create/Read/Update/Delete) данных и построением различных их таксономий, то получится нишевый продукт… остается вопрос популярности. Кстати, программы, позволяющие определять «типы» объектов, определять связи и «типы» связей между ними, определять полномочия других пользователей на выполнение операций на ними уже на самом деле есть — это программы для управления СУРБД (за исключением БД MySQL, возможности которой, мягко говоря, ограничены). Обычные обыватели почему-то боятся их как огня.
Еще, что мне приходит в голову — сходство с основами Семантического Веб… в принципе, он предоставляет многие из описанных возможностей «из коробки». Но примечательно то, что на сегодняшний день считается, что для создания онтологии требуется квалификация специалиста выше, чем для ОО-анализа и проектирования. Курсивное замечание из предыдущего абзаца в какой-то мере справедливо и тут — есть программа Protégé, редактор онтологий.
PS
В общем, как мне кажется, такого рода затеи очень часто приводят к попыткам изобретения велосипеда. Яркий пример — дырявый PHP (Personal Home Page), на котором должен был быть способен программировать любой не-программист. А с CMS Битрикс можно играть в «найди пять отличий от СУРБД»… по факту последняя просто оказалась подсистемой в CMS, что явно не сопутствует доступности и простоте.
С другой стороны, конечно, можно ожидать упрощения работы с Семантическим Веб, но ниже какой-то определенной планки он не опустится, необходимость работы с метаданными и их понимания останется точно.
Отчасти подобное я уже слышал от программистов в дискуссии под этим постом и под постом Виктора Ронина (см. выше). Более того, когда я сам начал думать, как мог бы выглядеть этот «язык социо-программирования для чайников», то меня понесло в сторону далеко не только операций над объектами и связями: vrus.habrahabr.ru/blog/72368/ И это еще учитывая, что думал-то я не сильно, в процессе написания конца упомянутой статьи, т.е. минут 15-20 :) На самом деле опасения того, что для создания реальных проектов язык (либо некий пользовательский интерфейс) может сильно усложниться, эти опасения и я разделяю. Я просто не дошел до стадии подробного продумывания этого интерфейса и хотел окончательно прояснить для себя все аспекты на уровне пока только идеи.
Но вот на уровне этой самой идеи мои возражения на возражения программистов по-прежнему остаются в силе. Во-первых, целиком согласен с правилом, что простота и доступность обратно пропорциональны возможностям. Поэтому, скорей всего и особенно в простейшем начальном варианте, возможности создания полноценных проектов для пользователей будут действительно невелики. Но даже эта невеликость может оказаться большим шагом вперед в сравнении с тем что они имеют сейчас в смысле возможностей пользовательских настроек на конкретных сервисах. Тем более что речь не идет о сервисе, который позволяет только создавать проекты. У среды «объекты-связи» есть и другие преимущества, о чем я кратко изложил здесь startuppoint.ru/blog/startup-ideas/32249.html Все они в сумме могут давать синергетический эффект. Так что даже если ограничиться CRUDингом, степень нишевости продукта трудно определить заранее.
На самом деле мои примеры создания проектов не совсем честные, поскольку я хотел заодно показать, хотя бы в принципе, что здесь возможна «налоговая» схема монетизации. Если это убрать, то проекты из примеров всё еще останутся проектами, хотя и любительскими. И отпадет необходимость вычисления правил суммы уплаты за создание объекта «Квартира». Но что касается вычисления прав на выполнение операций — это да, надо подумать. Тем более что думать мне в этом направлении трудно, не будучи программистом. Пока только встречный вопрос программисту — ведь операции языков высокого уровня в действительности представляют собой в машинных кодах не одну элементарную операцию, а некое множество? Операция «write» воспроизводит слово человеческого языка и понятна человеку, но не процессору. Не возможна ли здесь некая аналогия, когда операции делегирования полномочий будут понятны простому пользователю, но их внутренняя кухня будет зашита на каком-то более низкоуровневом по отношению к нему языке веб-программирования? В общем, здесь проблема, да. Мне сейчас трудно сказать, насколько нерешаемая.
Про реакцию на ошибки я совсем не понимаю. Что например является ошибкой соединения с БД с точки зрения пользователя (особенно пользователя CRUDинга)?
Программы для управления СУРБД, которых обыватели боятся как огня? Ну да, пусть они есть. Скажу по секрету как обыватель, вся проблема в названии :) Известное же дело, что сервис должен быть понятен пользователю веб-сервиса за три секунды, желательно из одного только названия, как одноклассники.ру. Поэтому я и позиционировал гипотетический сервис как «Социальный лифт» со слоганом Сделай себе имя! (теперь понимаю, что всё это плохо. Пока новое рабочее название — проект «Контексты». Хотя тоже может быть плохо… Подумаю еще). Кстати, возможно, более в тему — недавно попалась ссылка на презентацию по графовым базам данных: thesz.livejournal.com/1120142.html
Касательно квалификаций по созданию онтологий — ну здесь то же самое, что и вышеразобранное сравнение «настоящего программирования» с «массово-пользовательским». Т.е. лучше обычному веб-пользователю иметь какой-то инструмент и возможность, чем не иметь никакого. Особенно если речь о коллективном создании онтологий, непротиворечиво совмещенном с процессом общения и прочим флудом.
Короче, можно так обозначить философию моего гипотетического интернет-ресурса: простое и универсальное средство со всеми издержками универсальности, т.е. с небольшими возможностями, но это как раз попадает на целевую аудиторию — ресурс для массового пользователя, для которого эти возможности очень даже большие.
Но вот на уровне этой самой идеи мои возражения на возражения программистов по-прежнему остаются в силе. Во-первых, целиком согласен с правилом, что простота и доступность обратно пропорциональны возможностям. Поэтому, скорей всего и особенно в простейшем начальном варианте, возможности создания полноценных проектов для пользователей будут действительно невелики. Но даже эта невеликость может оказаться большим шагом вперед в сравнении с тем что они имеют сейчас в смысле возможностей пользовательских настроек на конкретных сервисах. Тем более что речь не идет о сервисе, который позволяет только создавать проекты. У среды «объекты-связи» есть и другие преимущества, о чем я кратко изложил здесь startuppoint.ru/blog/startup-ideas/32249.html Все они в сумме могут давать синергетический эффект. Так что даже если ограничиться CRUDингом, степень нишевости продукта трудно определить заранее.
На самом деле мои примеры создания проектов не совсем честные, поскольку я хотел заодно показать, хотя бы в принципе, что здесь возможна «налоговая» схема монетизации. Если это убрать, то проекты из примеров всё еще останутся проектами, хотя и любительскими. И отпадет необходимость вычисления правил суммы уплаты за создание объекта «Квартира». Но что касается вычисления прав на выполнение операций — это да, надо подумать. Тем более что думать мне в этом направлении трудно, не будучи программистом. Пока только встречный вопрос программисту — ведь операции языков высокого уровня в действительности представляют собой в машинных кодах не одну элементарную операцию, а некое множество? Операция «write» воспроизводит слово человеческого языка и понятна человеку, но не процессору. Не возможна ли здесь некая аналогия, когда операции делегирования полномочий будут понятны простому пользователю, но их внутренняя кухня будет зашита на каком-то более низкоуровневом по отношению к нему языке веб-программирования? В общем, здесь проблема, да. Мне сейчас трудно сказать, насколько нерешаемая.
Про реакцию на ошибки я совсем не понимаю. Что например является ошибкой соединения с БД с точки зрения пользователя (особенно пользователя CRUDинга)?
Программы для управления СУРБД, которых обыватели боятся как огня? Ну да, пусть они есть. Скажу по секрету как обыватель, вся проблема в названии :) Известное же дело, что сервис должен быть понятен пользователю веб-сервиса за три секунды, желательно из одного только названия, как одноклассники.ру. Поэтому я и позиционировал гипотетический сервис как «Социальный лифт» со слоганом Сделай себе имя! (теперь понимаю, что всё это плохо. Пока новое рабочее название — проект «Контексты». Хотя тоже может быть плохо… Подумаю еще). Кстати, возможно, более в тему — недавно попалась ссылка на презентацию по графовым базам данных: thesz.livejournal.com/1120142.html
Касательно квалификаций по созданию онтологий — ну здесь то же самое, что и вышеразобранное сравнение «настоящего программирования» с «массово-пользовательским». Т.е. лучше обычному веб-пользователю иметь какой-то инструмент и возможность, чем не иметь никакого. Особенно если речь о коллективном создании онтологий, непротиворечиво совмещенном с процессом общения и прочим флудом.
Короче, можно так обозначить философию моего гипотетического интернет-ресурса: простое и универсальное средство со всеми издержками универсальности, т.е. с небольшими возможностями, но это как раз попадает на целевую аудиторию — ресурс для массового пользователя, для которого эти возможности очень даже большие.
Sign up to leave a comment.
Кодирование без кода