Сразу вспоминается некий сайт liveidea.ru, у которого была практически идентичная концепция. Почти дословно с вашей. На словах выглядело всё тоже красиво, но в итоге сайт превратился в набор непонятных и неинтересных материалов от «стартаперов». Теперь сайт вообще закрылся. Думаю, вам стоит почитать в сети упоминания об их деятельности и сделать выводы :)
picasaweb, многие другие сервисы google, просто многие современные сервисы с интерфейсом на ajax — используют якоря для разделения контента и нормальной навигации. Например site-with-picrues.com/album/25#33 будет одной картинкой, а site-with-picrues.com/album/25#35 — другой. Конечно, у хороших сервисов есть и постоянные урлы на каждый ресурс без якорей, но пользователи, не обделённые яваскриптом просматривают их именно с якорями.
Это есть неправильная реализация наследования. Неправильно писать код можно многими способами. Наследование в этом плане не лучше и не хуже чего-то другого.
>это изменение должно делаться сразу для обоих величин
Именно поэтому квадрат не является прямоугольником. Если бы квадрат являтся прямоугольником, то все утверждения(контракты), верные для прямоугольника были бы верны для квадрата. Например, контракт "если мы установим ширину в 20 а длину в 10 то ширина будет равна 20 а длина 10" выполняется для прямоугольника, но не выполняется для квадрата. Поэтому квадрат не является прямоугольником с точки зрения наследования.
Строгое понятие "является" не совпадает с жизненным. В жизни квадрат является прямоугольником, а при наследовании - не является, потому что у прямоугольника можно изменить длину и ширину, а у квадрата нельзя.
Точно так же приведённая в примере карточка не является приведённым в примере ключом.
Приводя пример ключа и карточки ты нарушаешь один из принципов, который в этой книге также написан - [открытое] наследование применяется, когда наследник "является" предком. В приведённом тобой примере магнитная карточка не "является" ключом, потому что (из твоих слов) ключ при открывании выполняет операции, которые карточка выполнять не должна. И если при переопределении метода "открыть" мы упускаем важное изменение информации, значит карточка никак не может "являться" ключом, и значит наследование этого метода здесь использовать нельзя. Нужно либо делать его закрытым либо вообще не наследовать. То же самое касается других типов карточки - они не "являются" ключами, и поэтому их нельзя наследовать.
И всё, что я написал выше ни в коем разе не означает, что наследование - плохо или что-то там нарушает. Это значит, что наследование нужно применять там, где оно нужно. И в статье нет ни одного довода относительно того, что наследование нарушает инкапсуляцию. Там есть доводы относительно неправильное наследование нарушает инкапсуляцию. А приравнивание двух этих фраз - обычный софизм.
Принципиальное отличие в том, что это другой тип сервиса. Bestpersons - это аггрегатор аккаунтов по типу FriendFeed (хотя и с меньшими возможностями). MetaID хотя и предоставляет возможность создать ленту своих записей с разных аккаунтов, но этот функционал не является ни необходимым ни определяющим для сервиса.
Оценки, основанные на предыдущих оценках других материалов этим человеком. Сейчас они обычно неявно используются в рекомендательных системах (last.fm, netflix, ...). Т.е. в общем случае берутся оценки человеком других материалов, ищутся люди, которые оценивали те материалы похоже и на основе их оценок нынешнего материала расчитывается "персонализированная оценка". Конечно, тут может быть много разных механизмов. Не только на основе оценок "близких по вкусу" людей, но, например, на основе тематик и оценок материала по тематикам. Ну или других подсчётов.
Пользователь должен быть у себя и ни у кого больше. В моём случае неважно на какой платформе будет пользователь - он сможет пользоваться сервисами MetaID (теми, которыми захочет), не создавая у нас аккаунт.
>Поэтому все тут знают о том, что ты планируешь использовать большие сервисы (социалки к примеру) и именно для них ты пишешь краулер
Вот те на. Все знают, а мне ничего не доложили. Прямо сейчас краулер не знает ни про один конкретный сайт, он работает на общих принципах. Добавить распознавание конкретных сайтов не проблема, но это часто не требуется. А как написать универсальный-умный краулер можно почитать, например, в моём блоге )
>Примеры с Твиттерами и Диггами - не имеет ни малейшего отношения к данному проекту
А я вот считаю, что имеют. И аудитория твиттера и её размер никак не влияет на то, что они используют семантические технологии)
>Вот Википедию краулить и графы строить - другое дело
Этого добра немало в сети - поищи.
Лучше просто показывать количество голосов за и против и не извращаться. Пусть пользователи сами оценивают, насколько им важны эти за и против. Делая систему оценки запутаннее многого не добьёшься.
А на качество оценки больше всего повлияет, на мой взгляд, разделение её по нескольким критериям (это уже предлагали здесь и это есть на некоторых сайтах). Т.е. статья смешная - кликаешь плюс к юмору, умная - плюс у уму.. ) 3-4 таких категории сделают оценки статей куда понятнее. Нынешняя хабровская годится только для отсеивания мусора. Для ранжирования статей она подходит плохо (по крайней мере с моей точки зрения, потому что, видимо, мои критерии оценивания отличаются от "большинтва":)
А вообще, будущее за персонализированными оценками. Нужно много ресурсов для этого - да, нужны сложные алгоритмы, но качество системы оценки, использующей твои предыдущие оценки, будет несоизмеримо выше нынешних +/-
Я не обещал конкретных сроков, потому что они будут разными для разных тестеров. Сперва сервис будут тестировать те, кому он может принести больше пользы - владельцы сайтов/блогов, использующих семантические данные (hCard, SIOC, FOAF) и просто люди, у которых много аккаунтов на разных сайтах, с которыми будет удобно работать через ЛИС.
Также есть дополнительные модули для хранения, например, истории сообщений в БД (mod_archive, mod_logdb, ещё парочка).
Ещё для взаимодействия внешних сервисов с ejabberd можно использовать XML-RPC в связке с дополнительными административными модулями.
Именно поэтому квадрат не является прямоугольником. Если бы квадрат являтся прямоугольником, то все утверждения(контракты), верные для прямоугольника были бы верны для квадрата. Например, контракт "если мы установим ширину в 20 а длину в 10 то ширина будет равна 20 а длина 10" выполняется для прямоугольника, но не выполняется для квадрата. Поэтому квадрат не является прямоугольником с точки зрения наследования.
А реализует амбарный замок интерфейс ключ или не реализует - определяется исключительно тем, как программист определит абстракцию предметной области.
Точно так же приведённая в примере карточка не является приведённым в примере ключом.
И всё, что я написал выше ни в коем разе не означает, что наследование - плохо или что-то там нарушает. Это значит, что наследование нужно применять там, где оно нужно. И в статье нет ни одного довода относительно того, что наследование нарушает инкапсуляцию. Там есть доводы относительно неправильное наследование нарушает инкапсуляцию. А приравнивание двух этих фраз - обычный софизм.
>Поэтому все тут знают о том, что ты планируешь использовать большие сервисы (социалки к примеру) и именно для них ты пишешь краулер
Вот те на. Все знают, а мне ничего не доложили. Прямо сейчас краулер не знает ни про один конкретный сайт, он работает на общих принципах. Добавить распознавание конкретных сайтов не проблема, но это часто не требуется. А как написать универсальный-умный краулер можно почитать, например, в моём блоге )
>Примеры с Твиттерами и Диггами - не имеет ни малейшего отношения к данному проекту
А я вот считаю, что имеют. И аудитория твиттера и её размер никак не влияет на то, что они используют семантические технологии)
>Вот Википедию краулить и графы строить - другое дело
Этого добра немало в сети - поищи.
А на качество оценки больше всего повлияет, на мой взгляд, разделение её по нескольким критериям (это уже предлагали здесь и это есть на некоторых сайтах). Т.е. статья смешная - кликаешь плюс к юмору, умная - плюс у уму.. ) 3-4 таких категории сделают оценки статей куда понятнее. Нынешняя хабровская годится только для отсеивания мусора. Для ранжирования статей она подходит плохо (по крайней мере с моей точки зрения, потому что, видимо, мои критерии оценивания отличаются от "большинтва":)
А вообще, будущее за персонализированными оценками. Нужно много ресурсов для этого - да, нужны сложные алгоритмы, но качество системы оценки, использующей твои предыдущие оценки, будет несоизмеримо выше нынешних +/-