Предположим, в неком интернет-сервисе имеется такой функционал: пользователь может 1) создать объект, 2) определить тип объекта, 3) создать связь между двумя объектами, 4) определить тип связи, 5) определить полномочия других пользователей на выполнение этих операций.
Что этот функционал позволит делать пользователям?
— Общаться. Общение представляет собой цепочку объектов, грубо говоря, текстового типа, связанных отношением (связью) типа «источник-отклик».
— Структурировать контент – устанавливать связи между различными объектами и множествами. В том числе строить онтологии различных предметных областей.
— Создавать свои сервисы и проекты. Об этом ниже на примерах.
Пример 1. Предположим, некий риелтор хочет сделать проект по недвижимости в городе N. Он создает объект типа «Множество» с дополнительным типом «Сервис». Или «Авторский проект». Или еще как-нибудь назвать, это сейчас не важно. Важно, что внутри этого множества данный пользователь будет определять полномочия других пользователей на выполнение операций. Итак, внутри этого множества автор проекта создает еще несколько множеств с типом «Коммерческая недвижимость», «Квартиры», «Участки» и т. п. Внутри «Коммерческой недвижимости» будут созданы множества с типом «Офисы», «Магазины», «Склады» и т. п. «Квартиры» будут поделены на множества по количеству комнат, по районам, по признаку старый дом или новостройка и т. п. Отметим заодно – одни и те же объекты можно одновременно объединить в разные множества. Т.е. автор не будет мучаться, по какому признаку выстроить общую иерархию, а выстроит все иерархии по всем известным ему признакам. Не знаю, можно ли это назвать онтологией предметной области, но определенно эта структура отразит реальные взаимосвязи в той области, где автор проекта компетентен. (Правда, проблема всё равно останется в том, что именно увидят пользователи на экране, но это отдельный вопрос). Эту структуру автор создает сам, но другим пользователям, допустим, он разрешит создавать объекты типа «Комментарий» и связывать их с любым из вышеуказанных объектов и друг с другом. Все комментарии, связанные с конкретным объектом, можно объединить в множество с типом «Обсуждение». Далее автор создает множество с типом «Квартиры на продажу». Другие пользователи могут создавать внутри него объекты с типом «Квартира», но за деньги (плата за размещение объявления). В свою очередь «корневой» сервис берёт некоторый процент с доходов автора нашего гипотетического сервиса по недвижимости. (Есть соображения против этой модели монетизации, так что её нужно еще правильно применять. Об этом было в другом моём посте).
Пример 2. Ярослав Грешилов сделал проект Библа. Но ему нехватает средств, чтобы развивать этот сервис, наращивать функционал. И он обратился к пользователям с предложением скинуться на проект, если они хотят видеть в нем доработанными какие-то вещи. Не знаю, какие именно вещи; на мой взгляд там недостает возможности комментировать и обсуждать книги. Посмотрим, что фактически сделано: внутри множества с названием «Библа» пользователи могут создавать множества с типом (условно) «Пользовательские страницы», состоящие в свою очередь из четырех типов множеств, объединяющих объекты с типом «Книга», — «Прочитал», «Хочу прочитать», «Сейчас читаю», «У меня есть», а также множество типа «Соседи», состоящее из объектов типа «Пользователь». Книги в некоторых множествах связаны с объектами типа «Короткая рецензия», либо «Пояснение». Если бы Ярослав делал свой проект в нашем гипотетическом сервисе, для добавления возможности комментировать книги или рецензии не нужно было б менять программный код и платить программисту. Он просто разрешил бы пользователям создавать объекты с типом «Комментарий» и связывать их с объектами «Книга» или «Рецензия». Предположим, Библа зарабатывает на рекламе книжных магазинов. Некоторый процент от этих доходов, опять же, снимался бы в пользу «корневого» сервиса.
Библа связана с творческим объединением 13:37 (видимо, в это самое время им пришла идея объединиться), которое объединяет несколько людей и проектов. В частности, проекты по путешествиям и фильмам. Не хотелось бы вдаваться в подробности, просто замечу, что структура может быть похожей на Библу – фильмы можно поделить на «Посмотрел», «Хочу посмотреть», «Сейчас смотрю», «У меня есть» и так же составить множество «Соседи». То же с путешествиями, т.е. с географическими местами – «Посетил», «Хочу посетить», «Сейчас нахожусь» и традиционные «Соседи». Конечно, это отчасти шутка, поскольку разные области имеют разную специфику.
Есть еще пара примеров, которые хотелось расписать подробней, т.к. они содержат специфичекие преимущества описанной модели «объекты + связи». Это я сделаю следующими постами.
Замечания и пояснения.
Здесь намеренно сказано не обо всём и упрощено, чтобы сосредоточиться на сути. Кроме того, понятно, что любая стандартизация и унификация при производстве проектов имеет как плюсы, так и минусы. Проект, сделанный традиционным способом, может быть лучше с точки зрения дизайна и прочего, а также быть лучше заточенным под высокие нагрузки. Кроме того, если вы предоставляете сервис для бизнес-проектов, это накладывает высокие требования к стабильности и надежности работы этого сервиса.
Как видим, тип «множество» встречается постоянно и везде, так что его создание даже можно выделить в отдельную, шестую операцию. Но не включил, т.к. хотелось выразительного минимализма. Собственно говоря, тип (класс) сам по себе является множеством, объединяющим «типичные» элементы из какой-либо области.
Минимализм ведет к тому, что создание проектов становится доступным обычным пользователям. От них не требуется быть программистами и даже не требуется освоить Drupal или WordPress. От них требуется только использовать компетенции в их собственных профессиональных областях. Отсюда и название поста — Кодирование без кода. Еще можно было назвать Программирование без программирования. Это программирование, хотя и не в традиционном понимании, потому что программируются взаимосвязи между различными сетевыми ресурсами — информационными, интеллектуальными и прочими, программируются социальные взаимодействия людей. Кода нет, поскольку дело сводится к некому пользовательскому интерфейсу. Я понимаю, что дъявол кроется в деталях и, возможно, не всё так просто. Об этом интерфейсе я планирую думать, когда закончу определенную связную серию постов.
Как видим на примере Библы, не только создание проектов упрощается, но и их изменение и развитие упрощается. А это важно уже не только для обычных пользователей.
Заметим, что типы, определенные как «Пользователь» и «Комментарий», являются общими для двух совершенно разных проектов – по недвижимости и по книгам. Т.е. общая среда является основой для стандартизации и унификации типов. Что упростит поиск и структурирование. Например, очевидно, что другой проект по недвижимости в другом городе будет содержать те же типы «Квартира» и прочее. И можно будет легко связать в одно множество все объекты типа «Квартира» во всех городах страны, если нам это для чего-нибудь понадобится. Кроме того, шуточный пример с объединением 13:37 показывает, что в какой-то мере унифицировать можно не только типы, но и типичные структуры, множества и отношения между ними. Похоже на то, когда из всего разнообразия всемирной литературы выделяют всего несколько типичных сюжетов.
Как сказано в начале, модель «объекты + связи» позволяет не только создавать свои проекты, но и заниматься тем, чем пользователи привыкли заниматься в интернете, и даже большим – структурировать материалы. Связанные с этим перспективы интересны и тут можно разного интересного сказать, особенно с учетом, что всё это вместе происходит в общей среде. Но как показывает опыт моих прошлых постов, разговор обо всём сразу сбивает с толку аудиторию. Поэтому в данном тексте я решил сосредоточиться только на аспекте, связанном с производством проектов.
Хотя на самом деле здесь уместно было б продолжить аналогии с некоторыми концепциями программирования, типа инкапсуляции и сокрытия данных при взаимодействии пользовательских множеств с общей средой. Сокрытие, потому что есть мысль среди устанавливаемых пользователем полномочий включить операцию «определение видимости объектов для других пользователей». В таком подходе внешнее взаимодействует с внутренним только через некоторый интерфейс. Пользователь определяет, кто может создавать и/или видеть объекты и связи в его пространстве, уточнять, какие именно это объекты/связи, их конкретные множества либо типы. А также делить свое пространство на подпространства и определять правила отдельно для них; делегировать полномочия по установлению правил другим пользователям и т. п. Но для полноценного развития этой темы мне нехватает компетенций.
Что можно еще добавить? Например то, что в такой среде легко клонировать проекты. Это тоже открывает тему для разговора.
Что этот функционал позволит делать пользователям?
— Общаться. Общение представляет собой цепочку объектов, грубо говоря, текстового типа, связанных отношением (связью) типа «источник-отклик».
— Структурировать контент – устанавливать связи между различными объектами и множествами. В том числе строить онтологии различных предметных областей.
— Создавать свои сервисы и проекты. Об этом ниже на примерах.
Пример 1. Предположим, некий риелтор хочет сделать проект по недвижимости в городе N. Он создает объект типа «Множество» с дополнительным типом «Сервис». Или «Авторский проект». Или еще как-нибудь назвать, это сейчас не важно. Важно, что внутри этого множества данный пользователь будет определять полномочия других пользователей на выполнение операций. Итак, внутри этого множества автор проекта создает еще несколько множеств с типом «Коммерческая недвижимость», «Квартиры», «Участки» и т. п. Внутри «Коммерческой недвижимости» будут созданы множества с типом «Офисы», «Магазины», «Склады» и т. п. «Квартиры» будут поделены на множества по количеству комнат, по районам, по признаку старый дом или новостройка и т. п. Отметим заодно – одни и те же объекты можно одновременно объединить в разные множества. Т.е. автор не будет мучаться, по какому признаку выстроить общую иерархию, а выстроит все иерархии по всем известным ему признакам. Не знаю, можно ли это назвать онтологией предметной области, но определенно эта структура отразит реальные взаимосвязи в той области, где автор проекта компетентен. (Правда, проблема всё равно останется в том, что именно увидят пользователи на экране, но это отдельный вопрос). Эту структуру автор создает сам, но другим пользователям, допустим, он разрешит создавать объекты типа «Комментарий» и связывать их с любым из вышеуказанных объектов и друг с другом. Все комментарии, связанные с конкретным объектом, можно объединить в множество с типом «Обсуждение». Далее автор создает множество с типом «Квартиры на продажу». Другие пользователи могут создавать внутри него объекты с типом «Квартира», но за деньги (плата за размещение объявления). В свою очередь «корневой» сервис берёт некоторый процент с доходов автора нашего гипотетического сервиса по недвижимости. (Есть соображения против этой модели монетизации, так что её нужно еще правильно применять. Об этом было в другом моём посте).
Пример 2. Ярослав Грешилов сделал проект Библа. Но ему нехватает средств, чтобы развивать этот сервис, наращивать функционал. И он обратился к пользователям с предложением скинуться на проект, если они хотят видеть в нем доработанными какие-то вещи. Не знаю, какие именно вещи; на мой взгляд там недостает возможности комментировать и обсуждать книги. Посмотрим, что фактически сделано: внутри множества с названием «Библа» пользователи могут создавать множества с типом (условно) «Пользовательские страницы», состоящие в свою очередь из четырех типов множеств, объединяющих объекты с типом «Книга», — «Прочитал», «Хочу прочитать», «Сейчас читаю», «У меня есть», а также множество типа «Соседи», состоящее из объектов типа «Пользователь». Книги в некоторых множествах связаны с объектами типа «Короткая рецензия», либо «Пояснение». Если бы Ярослав делал свой проект в нашем гипотетическом сервисе, для добавления возможности комментировать книги или рецензии не нужно было б менять программный код и платить программисту. Он просто разрешил бы пользователям создавать объекты с типом «Комментарий» и связывать их с объектами «Книга» или «Рецензия». Предположим, Библа зарабатывает на рекламе книжных магазинов. Некоторый процент от этих доходов, опять же, снимался бы в пользу «корневого» сервиса.
Библа связана с творческим объединением 13:37 (видимо, в это самое время им пришла идея объединиться), которое объединяет несколько людей и проектов. В частности, проекты по путешествиям и фильмам. Не хотелось бы вдаваться в подробности, просто замечу, что структура может быть похожей на Библу – фильмы можно поделить на «Посмотрел», «Хочу посмотреть», «Сейчас смотрю», «У меня есть» и так же составить множество «Соседи». То же с путешествиями, т.е. с географическими местами – «Посетил», «Хочу посетить», «Сейчас нахожусь» и традиционные «Соседи». Конечно, это отчасти шутка, поскольку разные области имеют разную специфику.
Есть еще пара примеров, которые хотелось расписать подробней, т.к. они содержат специфичекие преимущества описанной модели «объекты + связи». Это я сделаю следующими постами.
Замечания и пояснения.
Здесь намеренно сказано не обо всём и упрощено, чтобы сосредоточиться на сути. Кроме того, понятно, что любая стандартизация и унификация при производстве проектов имеет как плюсы, так и минусы. Проект, сделанный традиционным способом, может быть лучше с точки зрения дизайна и прочего, а также быть лучше заточенным под высокие нагрузки. Кроме того, если вы предоставляете сервис для бизнес-проектов, это накладывает высокие требования к стабильности и надежности работы этого сервиса.
Как видим, тип «множество» встречается постоянно и везде, так что его создание даже можно выделить в отдельную, шестую операцию. Но не включил, т.к. хотелось выразительного минимализма. Собственно говоря, тип (класс) сам по себе является множеством, объединяющим «типичные» элементы из какой-либо области.
Минимализм ведет к тому, что создание проектов становится доступным обычным пользователям. От них не требуется быть программистами и даже не требуется освоить Drupal или WordPress. От них требуется только использовать компетенции в их собственных профессиональных областях. Отсюда и название поста — Кодирование без кода. Еще можно было назвать Программирование без программирования. Это программирование, хотя и не в традиционном понимании, потому что программируются взаимосвязи между различными сетевыми ресурсами — информационными, интеллектуальными и прочими, программируются социальные взаимодействия людей. Кода нет, поскольку дело сводится к некому пользовательскому интерфейсу. Я понимаю, что дъявол кроется в деталях и, возможно, не всё так просто. Об этом интерфейсе я планирую думать, когда закончу определенную связную серию постов.
Как видим на примере Библы, не только создание проектов упрощается, но и их изменение и развитие упрощается. А это важно уже не только для обычных пользователей.
Заметим, что типы, определенные как «Пользователь» и «Комментарий», являются общими для двух совершенно разных проектов – по недвижимости и по книгам. Т.е. общая среда является основой для стандартизации и унификации типов. Что упростит поиск и структурирование. Например, очевидно, что другой проект по недвижимости в другом городе будет содержать те же типы «Квартира» и прочее. И можно будет легко связать в одно множество все объекты типа «Квартира» во всех городах страны, если нам это для чего-нибудь понадобится. Кроме того, шуточный пример с объединением 13:37 показывает, что в какой-то мере унифицировать можно не только типы, но и типичные структуры, множества и отношения между ними. Похоже на то, когда из всего разнообразия всемирной литературы выделяют всего несколько типичных сюжетов.
Как сказано в начале, модель «объекты + связи» позволяет не только создавать свои проекты, но и заниматься тем, чем пользователи привыкли заниматься в интернете, и даже большим – структурировать материалы. Связанные с этим перспективы интересны и тут можно разного интересного сказать, особенно с учетом, что всё это вместе происходит в общей среде. Но как показывает опыт моих прошлых постов, разговор обо всём сразу сбивает с толку аудиторию. Поэтому в данном тексте я решил сосредоточиться только на аспекте, связанном с производством проектов.
Хотя на самом деле здесь уместно было б продолжить аналогии с некоторыми концепциями программирования, типа инкапсуляции и сокрытия данных при взаимодействии пользовательских множеств с общей средой. Сокрытие, потому что есть мысль среди устанавливаемых пользователем полномочий включить операцию «определение видимости объектов для других пользователей». В таком подходе внешнее взаимодействует с внутренним только через некоторый интерфейс. Пользователь определяет, кто может создавать и/или видеть объекты и связи в его пространстве, уточнять, какие именно это объекты/связи, их конкретные множества либо типы. А также делить свое пространство на подпространства и определять правила отдельно для них; делегировать полномочия по установлению правил другим пользователям и т. п. Но для полноценного развития этой темы мне нехватает компетенций.
Что можно еще добавить? Например то, что в такой среде легко клонировать проекты. Это тоже открывает тему для разговора.
