Разделение рейтинга на номинации — такая идея давно существует. Не знаю, может где используется. Вчера читал обсуждения тем по рейтингу на Хабре и там такое предлагалось. Но я как лучше и правильнее сделать рейтинг вообще не обсуждаю здесь. Моя идея относится к другому — как многократно ускорить тестирование и подбор наилучшего рейтинга, не нагружая при этом пользователей лишней работой. Причем не обязательно только коэффициент в формуле менять, можно и сами формулы разные пробовать. И всё это одновременно. В этом пафос.
Речь о параллельном использовании сразу нескольких разных систем рейтингования, которые могут отличаться допустим лишь значением коэффициента в формуле, по которой рейтинг расчитывается. Но на пользователях это никак не отразится, поскольку они будут видеть только одну систему. Смысл в том, что вы таким образом в невидимом режиме можете обкатывать разные варианты и выбирать лучший. Вместо того чтобы делать это последовательно — сделали одну систему — посмотрели, плоховато, изменили, посмотрели, тоже плоховато и так далее. Во-первых пользователи не поймут, если вы будете всё время менять систему, во-вторых это слишком долго.
«Доступ к публикации ограничен». На мой взгляд ограничение на топик с таким названием на контентном ресурсе нереально абсурдно. А переписать я думал, да, но совсем не потому что меня заботит проблема моего рейтинга. А потому что писал про одно, а наиболее интересная на мой взгляд мысль получилась иной, и её нужно вывести в заголовок.
Что до вас, то мне нравится контент вашего блога, потому и подумал что вряд ли вы минусовали. Есть у меня уверенность, что люди, которые пишут хороший контент, совсем не склонны кого-нибудь минусовать. Но проверить это со стороны простого пользователя действительно невозможно из-за анонимности голосов. Критерий Поппера не выполняется :)
Кстати, интересно что было б, если голоса не были анонимными. Наверно срач поднялся б вообще запредельный…
Любопытно было б взглянуть на блоги этих пользователей… Какой выдающийся контент они сами сгенерировали. И чему он соответствует по всей строгости критериев. Но мне эта тема совершенно неинтересна. Говорю лишь ради вас, т.к. не понимаю чего лично вы упиаетесь.
Подумал насчет Поппера, наверное, этот критерий действительно относится к теориям, т.е. когда неизвестная реальность чем-то моделируется. А здесь имеем дело не с теорией, а с предложением, технологией. Эти типы сущностей критерию Поппера действительно не удовлетворяют.
Да что за «все вытекающие» такие? На любом ресурсе разработчики считают счастьем, если пользователи предлагают какие-то улучшения. Их за это не бъют по рукам, а всячески стимулируют, даже если предложения окажутся бесполезными. То что тема рейтингов на Хабре больная я подозревал, но не подозревал что проблема настолько запущена. Да, и прекрасный способ её решения — это вообще не говорить об этом? Лучше сразу признайтесь, что не правы, а то спрошу каким образом моя теория не удовлетворяет критерию Поппера.
Вы б тогда так и написали — ценность любого топика, в котором слова «рейтинг» и «Хабр» будут стоять рядом, в контексте Хабра будет всегда стремится к нулю (точнее уходить в минус). Почему, это уже другой вопрос. Вам, видимо, неинтересный. Мне впрочем тоже.
OpenMinded, если это так, вы могли бы дать какое-либо разумное объяснение тому, почему мой пост оказался отхабренным? Я не в обиде на Хабр, просто мнение интересно, раз вы хорошо понимаете суть Хабра.
Дык собственно пост вообще не о Хабре и его проблемах. Просто некая идея относительно рейтингов как таковых. Хабр упомянут лишь как удобный пример. Он остался бы удобным примером, даже если б в нем была прекрасная система рейтингования.
Отчасти подобное я уже слышал от программистов в дискуссии под этим постом и под постом Виктора Ронина (см. выше). Более того, когда я сам начал думать, как мог бы выглядеть этот «язык социо-программирования для чайников», то меня понесло в сторону далеко не только операций над объектами и связями: vrus.habrahabr.ru/blog/72368/ И это еще учитывая, что думал-то я не сильно, в процессе написания конца упомянутой статьи, т.е. минут 15-20 :) На самом деле опасения того, что для создания реальных проектов язык (либо некий пользовательский интерфейс) может сильно усложниться, эти опасения и я разделяю. Я просто не дошел до стадии подробного продумывания этого интерфейса и хотел окончательно прояснить для себя все аспекты на уровне пока только идеи.
Но вот на уровне этой самой идеи мои возражения на возражения программистов по-прежнему остаются в силе. Во-первых, целиком согласен с правилом, что простота и доступность обратно пропорциональны возможностям. Поэтому, скорей всего и особенно в простейшем начальном варианте, возможности создания полноценных проектов для пользователей будут действительно невелики. Но даже эта невеликость может оказаться большим шагом вперед в сравнении с тем что они имеют сейчас в смысле возможностей пользовательских настроек на конкретных сервисах. Тем более что речь не идет о сервисе, который позволяет только создавать проекты. У среды «объекты-связи» есть и другие преимущества, о чем я кратко изложил здесь startuppoint.ru/blog/startup-ideas/32249.html Все они в сумме могут давать синергетический эффект. Так что даже если ограничиться CRUDингом, степень нишевости продукта трудно определить заранее.
На самом деле мои примеры создания проектов не совсем честные, поскольку я хотел заодно показать, хотя бы в принципе, что здесь возможна «налоговая» схема монетизации. Если это убрать, то проекты из примеров всё еще останутся проектами, хотя и любительскими. И отпадет необходимость вычисления правил суммы уплаты за создание объекта «Квартира». Но что касается вычисления прав на выполнение операций — это да, надо подумать. Тем более что думать мне в этом направлении трудно, не будучи программистом. Пока только встречный вопрос программисту — ведь операции языков высокого уровня в действительности представляют собой в машинных кодах не одну элементарную операцию, а некое множество? Операция «write» воспроизводит слово человеческого языка и понятна человеку, но не процессору. Не возможна ли здесь некая аналогия, когда операции делегирования полномочий будут понятны простому пользователю, но их внутренняя кухня будет зашита на каком-то более низкоуровневом по отношению к нему языке веб-программирования? В общем, здесь проблема, да. Мне сейчас трудно сказать, насколько нерешаемая.
Про реакцию на ошибки я совсем не понимаю. Что например является ошибкой соединения с БД с точки зрения пользователя (особенно пользователя CRUDинга)?
Программы для управления СУРБД, которых обыватели боятся как огня? Ну да, пусть они есть. Скажу по секрету как обыватель, вся проблема в названии :) Известное же дело, что сервис должен быть понятен пользователю веб-сервиса за три секунды, желательно из одного только названия, как одноклассники.ру. Поэтому я и позиционировал гипотетический сервис как «Социальный лифт» со слоганом Сделай себе имя! (теперь понимаю, что всё это плохо. Пока новое рабочее название — проект «Контексты». Хотя тоже может быть плохо… Подумаю еще). Кстати, возможно, более в тему — недавно попалась ссылка на презентацию по графовым базам данных: thesz.livejournal.com/1120142.html
Касательно квалификаций по созданию онтологий — ну здесь то же самое, что и вышеразобранное сравнение «настоящего программирования» с «массово-пользовательским». Т.е. лучше обычному веб-пользователю иметь какой-то инструмент и возможность, чем не иметь никакого. Особенно если речь о коллективном создании онтологий, непротиворечиво совмещенном с процессом общения и прочим флудом.
Короче, можно так обозначить философию моего гипотетического интернет-ресурса: простое и универсальное средство со всеми издержками универсальности, т.е. с небольшими возможностями, но это как раз попадает на целевую аудиторию — ресурс для массового пользователя, для которого эти возможности очень даже большие.
Косвенным путем получил еще один отклик, который уместно опубликовать здесь:
Не знаю… на мой взгляд идея исключить программиста из процесса программирования определенно интересна и очень похожа на идею исключить строителей и процесса строительства.
По написанному по ссылке у меня сразу появляются два вопроса (главным образом — по поводу претензий на кодирование):
1. Каким образом пользователь системы сможет (и сможет ли) определять логику домена (предметной области)?
Проблема заключается в том, что далеко не все данные являются явными и вносимыми в систему пользователем, многие данные (например цены) часто вычисляются динамически на основе других данных в системе. В том же примере про квартиры — каким образом и где будут определяться правила вычисления суммы уплаты за создание объекта «Квартира»?
Кстати, вычисления прав на выполнение операций это тоже касается.
2. Как и где пользователь сможет (и сможет ли) определять реакцию системы на ошибки?
Здесь я имею ввиду не столько ошибки ввода данных пользователем, сколько ошибки соединений с БД, обращения к ФС, ошибки рассинхронизации данных. Если системой пользуются несколько пользователей, то неизбежны условия гонок (аналогичные тем, что возникают в многопоточном программировании). В некоторых случаях их можно опускать, но при росте системы это может кончится плачевно (для электронной коммерции — полным провалом системы).
Ответы на эти два вопроса, на мой взгляд, во многом определяют потолок развития инфраструктуры проектов. Замечу, кстати, что простота и доступность системы неквалифицированному пользователю обратно пропорциональны возможностям, предоставляемым системой.
Если ограничиться исключительно CRUDингом (Create/Read/Update/Delete) данных и построением различных их таксономий, то получится нишевый продукт… остается вопрос популярности. Кстати, программы, позволяющие определять «типы» объектов, определять связи и «типы» связей между ними, определять полномочия других пользователей на выполнение операций на ними уже на самом деле есть — это программы для управления СУРБД (за исключением БД MySQL, возможности которой, мягко говоря, ограничены). Обычные обыватели почему-то боятся их как огня.
Еще, что мне приходит в голову — сходство с основами Семантического Веб… в принципе, он предоставляет многие из описанных возможностей «из коробки». Но примечательно то, что на сегодняшний день считается, что для создания онтологии требуется квалификация специалиста выше, чем для ОО-анализа и проектирования. Курсивное замечание из предыдущего абзаца в какой-то мере справедливо и тут — есть программа Protégé, редактор онтологий.
PS
В общем, как мне кажется, такого рода затеи очень часто приводят к попыткам изобретения велосипеда. Яркий пример — дырявый PHP (Personal Home Page), на котором должен был быть способен программировать любой не-программист. А с CMS Битрикс можно играть в «найди пять отличий от СУРБД»… по факту последняя просто оказалась подсистемой в CMS, что явно не сопутствует доступности и простоте.
С другой стороны, конечно, можно ожидать упрощения работы с Семантическим Веб, но ниже какой-то определенной планки он не опустится, необходимость работы с метаданными и их понимания останется точно.
Не очень понял. Но это скорей в копилку того, что у людей множество своих мыслей по организации рейтинга имеется, а реализоваться этой творческой силе некуда.
Это по сути вопрос о сервисе, в рамках которого такие вещи используются. В принципе наверно разные варианты можно помыслить. Например форум с вот этими дополнительными возможностями. Тогда работу будет проделывать модератор.
А если помыслить некую новую платформу для общения, «несоциальную» сеть, то проблема в том, что люди не всегда и не особо любят ставить теги к своим топикам и уж тем более к комментариям. Или тем более еще и какие-то непонятные связи. Это им лишняя нагрузка. Значит нужна заинтересованность. Я эту заинтересованность вижу в том, что в такой сети сообщества по интересам будут формироваться вокруг тематических тегов-узлов, а поэтому если автор производит контент-объекты, ему выгодно связать их наиболее точно с релевантными узлами-тегами, чтобы подключиться к максимальному объему релевантной аудитории.
А сколько времени для представления идей в субботу? Судя по расписанию, 2 часа, поделенные на количество представляющих? Последнее ведь заранее не известно? Или есть какой-то опыт, сколько обычно людей приходит?
Речь о параллельном использовании сразу нескольких разных систем рейтингования, которые могут отличаться допустим лишь значением коэффициента в формуле, по которой рейтинг расчитывается. Но на пользователях это никак не отразится, поскольку они будут видеть только одну систему. Смысл в том, что вы таким образом в невидимом режиме можете обкатывать разные варианты и выбирать лучший. Вместо того чтобы делать это последовательно — сделали одну систему — посмотрели, плоховато, изменили, посмотрели, тоже плоховато и так далее. Во-первых пользователи не поймут, если вы будете всё время менять систему, во-вторых это слишком долго.
Что до вас, то мне нравится контент вашего блога, потому и подумал что вряд ли вы минусовали. Есть у меня уверенность, что люди, которые пишут хороший контент, совсем не склонны кого-нибудь минусовать. Но проверить это со стороны простого пользователя действительно невозможно из-за анонимности голосов. Критерий Поппера не выполняется :)
Кстати, интересно что было б, если голоса не были анонимными. Наверно срач поднялся б вообще запредельный…
Вы б тогда так и написали — ценность любого топика, в котором слова «рейтинг» и «Хабр» будут стоять рядом, в контексте Хабра будет всегда стремится к нулю (точнее уходить в минус). Почему, это уже другой вопрос. Вам, видимо, неинтересный. Мне впрочем тоже.
Но вот на уровне этой самой идеи мои возражения на возражения программистов по-прежнему остаются в силе. Во-первых, целиком согласен с правилом, что простота и доступность обратно пропорциональны возможностям. Поэтому, скорей всего и особенно в простейшем начальном варианте, возможности создания полноценных проектов для пользователей будут действительно невелики. Но даже эта невеликость может оказаться большим шагом вперед в сравнении с тем что они имеют сейчас в смысле возможностей пользовательских настроек на конкретных сервисах. Тем более что речь не идет о сервисе, который позволяет только создавать проекты. У среды «объекты-связи» есть и другие преимущества, о чем я кратко изложил здесь startuppoint.ru/blog/startup-ideas/32249.html Все они в сумме могут давать синергетический эффект. Так что даже если ограничиться CRUDингом, степень нишевости продукта трудно определить заранее.
На самом деле мои примеры создания проектов не совсем честные, поскольку я хотел заодно показать, хотя бы в принципе, что здесь возможна «налоговая» схема монетизации. Если это убрать, то проекты из примеров всё еще останутся проектами, хотя и любительскими. И отпадет необходимость вычисления правил суммы уплаты за создание объекта «Квартира». Но что касается вычисления прав на выполнение операций — это да, надо подумать. Тем более что думать мне в этом направлении трудно, не будучи программистом. Пока только встречный вопрос программисту — ведь операции языков высокого уровня в действительности представляют собой в машинных кодах не одну элементарную операцию, а некое множество? Операция «write» воспроизводит слово человеческого языка и понятна человеку, но не процессору. Не возможна ли здесь некая аналогия, когда операции делегирования полномочий будут понятны простому пользователю, но их внутренняя кухня будет зашита на каком-то более низкоуровневом по отношению к нему языке веб-программирования? В общем, здесь проблема, да. Мне сейчас трудно сказать, насколько нерешаемая.
Про реакцию на ошибки я совсем не понимаю. Что например является ошибкой соединения с БД с точки зрения пользователя (особенно пользователя CRUDинга)?
Программы для управления СУРБД, которых обыватели боятся как огня? Ну да, пусть они есть. Скажу по секрету как обыватель, вся проблема в названии :) Известное же дело, что сервис должен быть понятен пользователю веб-сервиса за три секунды, желательно из одного только названия, как одноклассники.ру. Поэтому я и позиционировал гипотетический сервис как «Социальный лифт» со слоганом Сделай себе имя! (теперь понимаю, что всё это плохо. Пока новое рабочее название — проект «Контексты». Хотя тоже может быть плохо… Подумаю еще). Кстати, возможно, более в тему — недавно попалась ссылка на презентацию по графовым базам данных: thesz.livejournal.com/1120142.html
Касательно квалификаций по созданию онтологий — ну здесь то же самое, что и вышеразобранное сравнение «настоящего программирования» с «массово-пользовательским». Т.е. лучше обычному веб-пользователю иметь какой-то инструмент и возможность, чем не иметь никакого. Особенно если речь о коллективном создании онтологий, непротиворечиво совмещенном с процессом общения и прочим флудом.
Короче, можно так обозначить философию моего гипотетического интернет-ресурса: простое и универсальное средство со всеми издержками универсальности, т.е. с небольшими возможностями, но это как раз попадает на целевую аудиторию — ресурс для массового пользователя, для которого эти возможности очень даже большие.
Не знаю… на мой взгляд идея исключить программиста из процесса программирования определенно интересна и очень похожа на идею исключить строителей и процесса строительства.
По написанному по ссылке у меня сразу появляются два вопроса (главным образом — по поводу претензий на кодирование):
1. Каким образом пользователь системы сможет (и сможет ли) определять логику домена (предметной области)?
Проблема заключается в том, что далеко не все данные являются явными и вносимыми в систему пользователем, многие данные (например цены) часто вычисляются динамически на основе других данных в системе. В том же примере про квартиры — каким образом и где будут определяться правила вычисления суммы уплаты за создание объекта «Квартира»?
Кстати, вычисления прав на выполнение операций это тоже касается.
2. Как и где пользователь сможет (и сможет ли) определять реакцию системы на ошибки?
Здесь я имею ввиду не столько ошибки ввода данных пользователем, сколько ошибки соединений с БД, обращения к ФС, ошибки рассинхронизации данных. Если системой пользуются несколько пользователей, то неизбежны условия гонок (аналогичные тем, что возникают в многопоточном программировании). В некоторых случаях их можно опускать, но при росте системы это может кончится плачевно (для электронной коммерции — полным провалом системы).
Ответы на эти два вопроса, на мой взгляд, во многом определяют потолок развития инфраструктуры проектов. Замечу, кстати, что простота и доступность системы неквалифицированному пользователю обратно пропорциональны возможностям, предоставляемым системой.
Если ограничиться исключительно CRUDингом (Create/Read/Update/Delete) данных и построением различных их таксономий, то получится нишевый продукт… остается вопрос популярности. Кстати, программы, позволяющие определять «типы» объектов, определять связи и «типы» связей между ними, определять полномочия других пользователей на выполнение операций на ними уже на самом деле есть — это программы для управления СУРБД (за исключением БД MySQL, возможности которой, мягко говоря, ограничены). Обычные обыватели почему-то боятся их как огня.
Еще, что мне приходит в голову — сходство с основами Семантического Веб… в принципе, он предоставляет многие из описанных возможностей «из коробки». Но примечательно то, что на сегодняшний день считается, что для создания онтологии требуется квалификация специалиста выше, чем для ОО-анализа и проектирования. Курсивное замечание из предыдущего абзаца в какой-то мере справедливо и тут — есть программа Protégé, редактор онтологий.
PS
В общем, как мне кажется, такого рода затеи очень часто приводят к попыткам изобретения велосипеда. Яркий пример — дырявый PHP (Personal Home Page), на котором должен был быть способен программировать любой не-программист. А с CMS Битрикс можно играть в «найди пять отличий от СУРБД»… по факту последняя просто оказалась подсистемой в CMS, что явно не сопутствует доступности и простоте.
С другой стороны, конечно, можно ожидать упрощения работы с Семантическим Веб, но ниже какой-то определенной планки он не опустится, необходимость работы с метаданными и их понимания останется точно.
А если помыслить некую новую платформу для общения, «несоциальную» сеть, то проблема в том, что люди не всегда и не особо любят ставить теги к своим топикам и уж тем более к комментариям. Или тем более еще и какие-то непонятные связи. Это им лишняя нагрузка. Значит нужна заинтересованность. Я эту заинтересованность вижу в том, что в такой сети сообщества по интересам будут формироваться вокруг тематических тегов-узлов, а поэтому если автор производит контент-объекты, ему выгодно связать их наиболее точно с релевантными узлами-тегами, чтобы подключиться к максимальному объему релевантной аудитории.