Comments 18
Ссылки, на более ранние посты, все же были бы не лишние.
Удивительным образом пересекается с набросками CMS, над которой я начал работать на днях, а скорее пока просто думать и прикидывать варианты реализации «на бумажке».
Как я её пока вижу: есть сущности разных типов (простые, например, «текст», «число», «дата» и другие обычные для ЯП, сложные, такие как «пользователь», «пост», «комментарий», «тег», «права доступа» и т. д., реализуемые модулями на ЯП и составные, которые формируются из простых и сложных в админке — что-то вроде наследования в ООП) и есть отношения между ними, тоже различных типов от элементарных «один-к-одному» или «многие-ко-многим» до сложных, например, «автор», «имеет право доступа», «ссылается», «подписан», логика которых реализована в модулях, а также и «семантических», которые можно создавать в админке на основе элементарных (семантику связи знает и реализует в шаблонах только её автор) и, может быть, сложных (тут ещё не думал как это может выглядеть)
Но всё это виделось именно как CMS — владелец сайта/администратор создаёт нужные типы сущностей и связей под задачу сайта (возможно хватит дефолтных, возможно нужны будут дополнительные модули, вероятно придётся использовать составные), формирует представления для них (или довольствуется автоматически сгенерированным), раздаёт права различным группам пользователей (от редакторов и модераторов сайта до анонимных пользователей, группы, естественно может создавать в любом нужном количестве и они тоже являются сущностями), формирует начальный набор сущностей (те же группы пользователей). Пользователи же сайта могут создавать контент и связи между ними только в заданных администратором рамках, то есть если у пользователя есть право создать пост блога, указать его категорию и теги, то он может это сделать, но не может добавить к посту ещё какие-то поля и/или связи, например, ссылки на географическое положение, кроме предусмотренных администратором для этого вида сущностей.
Ни о каких социальных аспектах (кроме как теоретически возможное использование в качестве движка для социальной сети, опять-таки в жёстко заданных администратором рамках) не думал Да и вообще задумка из разряда «just for fun», в лучшем случае для моего личного использования, прежде всего из-за возможных — а скорее вероятных, — проблем с производительностью (даже для простого вывода обычной текстовой/html страницы без всяких связей нужно, как мне пока видится, два запроса к БД — получение типа сущности по url и получение собственно содержимого страницы) и сложностью, имхо, освоения для администратора, не проникнувшегося духом (и буквой :) ) проекта
Как я её пока вижу: есть сущности разных типов (простые, например, «текст», «число», «дата» и другие обычные для ЯП, сложные, такие как «пользователь», «пост», «комментарий», «тег», «права доступа» и т. д., реализуемые модулями на ЯП и составные, которые формируются из простых и сложных в админке — что-то вроде наследования в ООП) и есть отношения между ними, тоже различных типов от элементарных «один-к-одному» или «многие-ко-многим» до сложных, например, «автор», «имеет право доступа», «ссылается», «подписан», логика которых реализована в модулях, а также и «семантических», которые можно создавать в админке на основе элементарных (семантику связи знает и реализует в шаблонах только её автор) и, может быть, сложных (тут ещё не думал как это может выглядеть)
Но всё это виделось именно как CMS — владелец сайта/администратор создаёт нужные типы сущностей и связей под задачу сайта (возможно хватит дефолтных, возможно нужны будут дополнительные модули, вероятно придётся использовать составные), формирует представления для них (или довольствуется автоматически сгенерированным), раздаёт права различным группам пользователей (от редакторов и модераторов сайта до анонимных пользователей, группы, естественно может создавать в любом нужном количестве и они тоже являются сущностями), формирует начальный набор сущностей (те же группы пользователей). Пользователи же сайта могут создавать контент и связи между ними только в заданных администратором рамках, то есть если у пользователя есть право создать пост блога, указать его категорию и теги, то он может это сделать, но не может добавить к посту ещё какие-то поля и/или связи, например, ссылки на географическое положение, кроме предусмотренных администратором для этого вида сущностей.
Ни о каких социальных аспектах (кроме как теоретически возможное использование в качестве движка для социальной сети, опять-таки в жёстко заданных администратором рамках) не думал Да и вообще задумка из разряда «just for fun», в лучшем случае для моего личного использования, прежде всего из-за возможных — а скорее вероятных, — проблем с производительностью (даже для простого вывода обычной текстовой/html страницы без всяких связей нужно, как мне пока видится, два запроса к БД — получение типа сущности по url и получение собственно содержимого страницы) и сложностью, имхо, освоения для администратора, не проникнувшегося духом (и буквой :) ) проекта
Спасиб, мне как раз не хватает понимания, какие проблемы могут возникнуть с технической стороны, ибо не программист. Про CMS не знаю, но всякие полудесктопные варианты реализации системы объекты-связи давно существуют — некоторый обзор содержится у меня в посте: vrus.habrahabr.ru/blog/94738/ А также в комментариях к другому посту vrus.habrahabr.ru/blog/94902/ heruvim сказал про их уже реализованный проект Hivext.
Но весь пафос моей задумки именно в реализации в виде «классического» веб-проекта, ориентированного на обычного массового пользователя. В принципе существует ведь еще семантическая Википедия, хотя я не пользовался и не вникал. Там пользователи могут создавать произвольные типы связей между объектами, но объекты не типизуются. Я так понимаю просто за ненадобностью, т.к. все они имеют один тип «энциклопедическая статья». По-видимому у них принципиальной проблемы с производительностью не было. Ну и упомянутый Metaweb, опять же.
Но весь пафос моей задумки именно в реализации в виде «классического» веб-проекта, ориентированного на обычного массового пользователя. В принципе существует ведь еще семантическая Википедия, хотя я не пользовался и не вникал. Там пользователи могут создавать произвольные типы связей между объектами, но объекты не типизуются. Я так понимаю просто за ненадобностью, т.к. все они имеют один тип «энциклопедическая статья». По-видимому у них принципиальной проблемы с производительностью не было. Ну и упомянутый Metaweb, опять же.
К Hivext смотрел вчера доки — сложно это назвать для «обычного массового пользователя», скорее для «продвинутого программиста», то есть это опять-таки платформа для разработки веб-приложений. PersonalBrain установил себе, интересная вроде штука сама по себе, спасибо за наводку.
Вот как раз с типизацией объектов, особенно для составных (введённых пользователем, а не реализованных на уровне кода) типов и связаны мои опасения насчёт производительности. Хотя, конечно, это всё относительно и при заложенной в архитектуру масштабируемости производительность легко наращивается добавлением новых серверов (при наличии соответствующих инвестиций :) ), но я пока ориентируюсь максимум на виртуальный выделенный сервер (или недорогое, а то и бесплатное «облако», например, GAE), то есть то, что может себе позволить практически каждый заинтересованный в своём сайте. Кстати, сейчас зарегался на freebase.org, где реализованы эти самые пользовательские типы и связи и даже кое-что подредактировал — ощутимо тормозит.
Для использования такой концепции обычными пользователями есть ещё одна проблема, которую надо будет решать — представление объектов пользовательских типов и связей для других пользователей. Как не крути, но для создания красивых и удобных страниц (что очень важно для бизнеса), представляющих сущности произвольного типа и их связи, пользователю надо будет осваивать работу с каким-то шаблонизатором, желательно в двух режимах — WYSIWYG для «чайников» и правка исходных кодов шаблона для более продвинутых. На том же freebase всё загнано в один табличный шаблон (насколько я успел заметить), который годится для энциклопедии или справочника, но мало пригоден для использования прежде всего в коммерческих целях. Речь идёт не о настраиваемом дизайне собственно страницы, а именно о дизайне сущностей и их связей. Правда это проблема для меня и моей CMS, при серьёзной командной разработке вполне решаемо, наверное :)
В общем, по-моему, создание прототипа такой сети вполне реально относительно малой кровью, а вот реализация как популярного проекта для обычных пользователей (которые не любят во что-то вникать, что не касается их предметной области) потребует много усилий со стороны различных специалистов, не только и не столько программистов, сколько специалистов по дизайну и пользовательским интерфейсам. Ну и соответствующих инвестиций, конечно, уже на этапе разработки — на одном энтузиазме долго не протянешь, даже при вполне реальном профите в итоге. Ну а запуск проекта потребует нехилых вложений в железо, каналы, их поддержку и т. п. (интересно сколько стоит техническая часть того же вконтакте), не говоря о маркетинге.
Вот как раз с типизацией объектов, особенно для составных (введённых пользователем, а не реализованных на уровне кода) типов и связаны мои опасения насчёт производительности. Хотя, конечно, это всё относительно и при заложенной в архитектуру масштабируемости производительность легко наращивается добавлением новых серверов (при наличии соответствующих инвестиций :) ), но я пока ориентируюсь максимум на виртуальный выделенный сервер (или недорогое, а то и бесплатное «облако», например, GAE), то есть то, что может себе позволить практически каждый заинтересованный в своём сайте. Кстати, сейчас зарегался на freebase.org, где реализованы эти самые пользовательские типы и связи и даже кое-что подредактировал — ощутимо тормозит.
Для использования такой концепции обычными пользователями есть ещё одна проблема, которую надо будет решать — представление объектов пользовательских типов и связей для других пользователей. Как не крути, но для создания красивых и удобных страниц (что очень важно для бизнеса), представляющих сущности произвольного типа и их связи, пользователю надо будет осваивать работу с каким-то шаблонизатором, желательно в двух режимах — WYSIWYG для «чайников» и правка исходных кодов шаблона для более продвинутых. На том же freebase всё загнано в один табличный шаблон (насколько я успел заметить), который годится для энциклопедии или справочника, но мало пригоден для использования прежде всего в коммерческих целях. Речь идёт не о настраиваемом дизайне собственно страницы, а именно о дизайне сущностей и их связей. Правда это проблема для меня и моей CMS, при серьёзной командной разработке вполне решаемо, наверное :)
В общем, по-моему, создание прототипа такой сети вполне реально относительно малой кровью, а вот реализация как популярного проекта для обычных пользователей (которые не любят во что-то вникать, что не касается их предметной области) потребует много усилий со стороны различных специалистов, не только и не столько программистов, сколько специалистов по дизайну и пользовательским интерфейсам. Ну и соответствующих инвестиций, конечно, уже на этапе разработки — на одном энтузиазме долго не протянешь, даже при вполне реальном профите в итоге. Ну а запуск проекта потребует нехилых вложений в железо, каналы, их поддержку и т. п. (интересно сколько стоит техническая часть того же вконтакте), не говоря о маркетинге.
Да шо ж такое седня, всё не туда тычу…
По правде меня больше всего волнует пользовательский «язык программирования». Как его реализовать, чтобы не уйти в сложность. Например, «не видеть все посты такого то автора, кроме случаев, когда они вызвали бурную дискуссию». При этом «бурная» означает число откликов больше N. Тут же нужны какие-то откровенно программерские конструкции вроде «если то». И оперирование числовыми переменными. Фактически тип — это множество. Оперирование с объектами и типами объектов, это оперирование с множествами и элементами множеств. В математическом смысле. Например, объект с типом «текстовый» и типом «пост» принадлежит множеству всех объектов, созданных данным автором, и одновременно принадлежит некоторой теме, которая по сути тоже множество. Тогда этот объект является пересечением множеств. В общем, надо думать.
Для данного случая «если то» в прямом виде не нужно, по-моему: с сущностью «пользователь» (или «фильтр», которая связана с пользователем) создаётся связь со множеством (типом) «посты» с параметрами «автор такой-то» и «число ответов/отзывов/рейтинг больше 100». «Автор» и «число ответов» выбирается из списка, «больше/меньше/равно/есть/нет» тоже", «Такой-то» — поле с автодополнением, «100» — простое поле (где нужно с ограничением на, например, натуральность).
Множества, как я вижу, это выборка по связи (возможно параметризованной), постоянной (заданной при описании сущности) или временной (фактически даже не создающейся, а формирующейся динамически на время фильтрации/поиска). Ну а обычные операции над множествами (пересечение, объединение) реализовать должно быть достаточно легко.
Множества, как я вижу, это выборка по связи (возможно параметризованной), постоянной (заданной при описании сущности) или временной (фактически даже не создающейся, а формирующейся динамически на время фильтрации/поиска). Ну а обычные операции над множествами (пересечение, объединение) реализовать должно быть достаточно легко.
Не очень понял. Возможно потому, что оперирую пока только множествами, не используя понятий «параметры» и «список», а также не вдаваясь в интерфейс.
На этом уровне мне было б понятней так: есть множество В всех пользователей, посты и комментарии которых видны (допустим, по умолчанию так). Есть другое множество Ч людей, указанных явно (черный список). Есть третье множество Р людей, получивших за свои тексты такое-то количество откликов/рейтинга. Тогда (на картинке) в белом круге В содержатся черный кружок Ч и кружок Р. Ч и Р имеют область пересечения. Тогда в операции определения видимости нужно из множества В вычесть множество Ч, у которого в свою очередь вычли пересечение с множеством Р. Сама операция определения видимости считается базовой, наряду с созданием объектов и связей и это как-то учитывается в интерфейсе.
Но может всё это и по-другому можно, я счас на ходу вряд ли толком придумаю. Даже отсюда видно, что какой-нибудь искусствовед вряд ли осилит операции с множествами.
На этом уровне мне было б понятней так: есть множество В всех пользователей, посты и комментарии которых видны (допустим, по умолчанию так). Есть другое множество Ч людей, указанных явно (черный список). Есть третье множество Р людей, получивших за свои тексты такое-то количество откликов/рейтинга. Тогда (на картинке) в белом круге В содержатся черный кружок Ч и кружок Р. Ч и Р имеют область пересечения. Тогда в операции определения видимости нужно из множества В вычесть множество Ч, у которого в свою очередь вычли пересечение с множеством Р. Сама операция определения видимости считается базовой, наряду с созданием объектов и связей и это как-то учитывается в интерфейсе.
Но может всё это и по-другому можно, я счас на ходу вряд ли толком придумаю. Даже отсюда видно, что какой-нибудь искусствовед вряд ли осилит операции с множествами.
Заметил неправильность — В в данном случае должно быть просто множеством всех пользователей.
С сущностью типа «пользователь» связана сущность типа «чёрный список», для которой задана связь «сущности имеющие такого-то автора и (имеющие рейтинг меньше 100 или число прямых комментариев меньше 10)». Когда пользователь просматривает сущности (посты) других авторов, то множество сущностей, связанных с чёрным списком вычитаются из запрошенных пользователем (базовая функциональность типа «чёрный список»).
Возникла идея — продвинутые пользователи могут создавать свои типы и связи с нестандартной функциональностью (с помощью «текстового» интерфейса для работы с множествами, например, или UML-like диаграммами), а администраторы и программисты проекта, отслеживая наиболее ресурсоемкие «произведения» могут реализовывать их в коде для снижения нагрузки на кластер и времени отклика. В принципе можно предоставить право создавать пользовательские типы и связи на нормальном языке программирования с каким-то API, предоставляемым проектом. В любом случае можно дать возможность пользователям делиться (в том числе небезвозмездно и не без комиссии проекту :) ) своими «логическими» наработками, а не только контентом. Таким образом мы получим не только производителей контента и его потребителей, но и производителей логики и для производителей контента, и для его потребителей. В общем какой-то Google App Engine «с человеческим лицом» вырисовывается :)
Возникла идея — продвинутые пользователи могут создавать свои типы и связи с нестандартной функциональностью (с помощью «текстового» интерфейса для работы с множествами, например, или UML-like диаграммами), а администраторы и программисты проекта, отслеживая наиболее ресурсоемкие «произведения» могут реализовывать их в коде для снижения нагрузки на кластер и времени отклика. В принципе можно предоставить право создавать пользовательские типы и связи на нормальном языке программирования с каким-то API, предоставляемым проектом. В любом случае можно дать возможность пользователям делиться (в том числе небезвозмездно и не без комиссии проекту :) ) своими «логическими» наработками, а не только контентом. Таким образом мы получим не только производителей контента и его потребителей, но и производителей логики и для производителей контента, и для его потребителей. В общем какой-то Google App Engine «с человеческим лицом» вырисовывается :)
Пример как раз показывает, что пути реализации возможны разные и как раз желательно в итоге найти наиболее простые и понятные для всех способы и определиться с базовыми функциональностями.
А насчет идеи согласен. У меня собственно были похожие мысли, только мне их трудно формулировать, не будучи программистом. Понятно, что массовому усредненному потребителю нужен очень ограниченный набор типов, причем которые он и создавать-то не будет, а воспользуется готовыми. Вроде «пост», «комментарий», связанные типом причинно-следственной связи «источник-отклик» (ну или «parent-child»). Он увидит пост и увидит кнопку «комментировать», и прокомментирует как обычно, а не будет создавать объект типа «комментарий» и связывать его с постом типизованной связью. По идее нужно сделать так, чтобы это обрабатывалось быстро. Потому что занимает грубо говоря 90% всей пользовательской активности — медленность пользователи не простят. И другое дело если кто-то создает свой проект, определяет новые типы, связи. Еще третье дело, если этот пользовательский проект вдруг становится популярным и начинается высокая нагрузка на данный фрагмент всей системы…
Про «лицензирование клонов» внутри системы тоже была мысля ))
Если о философии, френд мой amilner считает, что Фейсбук как открытая платформа и за счет гигантской армии пользователей теперь является единственным прибежищем для тех, кто хочет делать любые социальные приложения. А я считаю что Фейсбук, будучи соцсетью, изначально проигрывает более общей «несоциальной» сети, точнее, семантической социальной среде. Нужно строить вот эту более общую сеть и конечно с неким API.
А насчет идеи согласен. У меня собственно были похожие мысли, только мне их трудно формулировать, не будучи программистом. Понятно, что массовому усредненному потребителю нужен очень ограниченный набор типов, причем которые он и создавать-то не будет, а воспользуется готовыми. Вроде «пост», «комментарий», связанные типом причинно-следственной связи «источник-отклик» (ну или «parent-child»). Он увидит пост и увидит кнопку «комментировать», и прокомментирует как обычно, а не будет создавать объект типа «комментарий» и связывать его с постом типизованной связью. По идее нужно сделать так, чтобы это обрабатывалось быстро. Потому что занимает грубо говоря 90% всей пользовательской активности — медленность пользователи не простят. И другое дело если кто-то создает свой проект, определяет новые типы, связи. Еще третье дело, если этот пользовательский проект вдруг становится популярным и начинается высокая нагрузка на данный фрагмент всей системы…
Про «лицензирование клонов» внутри системы тоже была мысля ))
Если о философии, френд мой amilner считает, что Фейсбук как открытая платформа и за счет гигантской армии пользователей теперь является единственным прибежищем для тех, кто хочет делать любые социальные приложения. А я считаю что Фейсбук, будучи соцсетью, изначально проигрывает более общей «несоциальной» сети, точнее, семантической социальной среде. Нужно строить вот эту более общую сеть и конечно с неким API.
Пути реализации и быстродействие должны беспокоить архитекторов, программистов и администраторов, навскидку быстродействие будет очень сильно зависеть от используемой базы данных и её схемы (даже там где схемы нет :) ). Главной нагрузкой на сервер будет собственно процесс получения/записи тех данных, которые пользователь хочет видеть/сохранить. В каком виде он их получит/введёт вопрос к проектировщикам интерфейса и дизанерам. Как правило, эти функции создают относительно малую нагрузку на сервер (хотя могут ощутимо тормозить на машине клиента).
То есть для программирования сервера и создания прототипа хоть с каким-нибудь интерфейсом нужно поставить задачу в терминах предметной области (у нас сущность/объект, тип, связь и т. п.) и если задача поставлена нормально и реализована так же, то прикрутить можно любой интерфейс, от консольного до считывающего мыслеформы :) На практике не всё так красиво, конечно, полностью абстрагироваться от деталей реализации интерфейса не получится, но к этому надо стремиться :)
То есть для программирования сервера и создания прототипа хоть с каким-нибудь интерфейсом нужно поставить задачу в терминах предметной области (у нас сущность/объект, тип, связь и т. п.) и если задача поставлена нормально и реализована так же, то прикрутить можно любой интерфейс, от консольного до считывающего мыслеформы :) На практике не всё так красиво, конечно, полностью абстрагироваться от деталей реализации интерфейса не получится, но к этому надо стремиться :)
Думается, для начала нужно забыть о создании красивых и удобных страниц для бизнеса. Свести всё к минимуму. У меня даже в плане дизайна какой-то пунктик на сверхминимализме. Люблю чистый лист с двумя-тремя статичными пятнами :) Ну это ладно, мои тараканы. Буду думать над интерфейсом.
Пока что реакция народа очень сдержанная, если не сказать скептическая, у инвесторов в том числе. Не говоря уж о Хабре — здесь вообще стабильный минус. Так что минимализм и энтузиазм — вынужденная необходимость. Нужно чтоб хотя бы в принципе что-нибудь работало и подтверждало на примере какую-нибудь из прелестей, которые я теоретически указал. Может тогда больше обратят внимание. Ибо согласен — чтоб всё это на серьезном уровне сделать, нужно совсем не слабое финансирование.
Пока что реакция народа очень сдержанная, если не сказать скептическая, у инвесторов в том числе. Не говоря уж о Хабре — здесь вообще стабильный минус. Так что минимализм и энтузиазм — вынужденная необходимость. Нужно чтоб хотя бы в принципе что-нибудь работало и подтверждало на примере какую-нибудь из прелестей, которые я теоретически указал. Может тогда больше обратят внимание. Ибо согласен — чтоб всё это на серьезном уровне сделать, нужно совсем не слабое финансирование.
Слишком сложная с т.зр. пользователя система, и слишком всеохватная. Пока вы не выделите список core features и не определите фокус проекта, врядли получится привлечь к нему внимание.
А инвесторы просто не понимают сути проекта :)
А инвесторы просто не понимают сути проекта :)
Целиком согласен, я и сам не придумал нормального, простого и понятного позиционирования для такого сервиса, поэтому пока вообще отказался от этой затеи. Продолжаю держать всё это в уме, но сейчас решил зайти со стороны сервиса по массовому рейтингованию различных сущностей. И чтоб было у него понятное и простое позиционирование, говорю что хочу делать рейтинг людей по их «социальному весу». А потом уже, если это пойдет, можно будет добавлять отдельные вещи из вышеизложенного.
Sign up to leave a comment.
Проект «Контексты»