1. станет легче тем что вы порог достоверности снижаете — соот-но упрощается решение задачи. к примеру, до определенного уровня, снизив всего на несколько процентов критерий правильного срабатывания — вы уменьшаете на много процентов сложность реализации.
2. на основе собранной с инета информации, с последующим матчингом под разными срезами и сортировкой
положите в основу — слово — ПРОГНОЗ, или ПРЕДПОЛАГАЕМАЯ оценка и станет намного легче. Точно (одназначно) оценить очень трудно, однако можно с достаточно большой вероятностью правильно сформировать оценку. К примеру относительно испольнителей на фрилансе сразу можно отсеять кидалово и новичков, и наоборот сформировать группу опытных людей. Вообщем было бы желание. Акцентирую еще раз, основная мысль — использовать глобальную базу накопленной информации и знаний.
при желании это все решается матчингом :) в итоге можно даже будет знать какие есть у юзера другие подпольные фамилии :). Однако повторюсь это уже вам не простой ретинг :), такое стоит делать глобально — экспертная система, для КГБ или ЦРУ :) с реализацией SOA интерфейса для подключения в свои порталы :)
вариант интересен. Однако, я думаю профи, тратить время на сертификацию будет только если ему это очень-очень надо. Нужно сделать так чтобы автоматически определялось за счет уже ранее проделанной работы. К примеру участие в каких-то опенсорс проектах. опять же определять важность таких проектов. Ну а вообще было рульно сделать глобальную экспертную систему поиска людей и определения их навыков, знаний, прочего.
если вы зарегистрированы под одним емейлом и ником на 9000 — значит вы профи в какой-то области. Лузер не сможет этого сделать. А если гвоздолупый скрывал свои реальные данные, то это его проблемы. Нормальным профессиональным людям нечего скрывать. А если тварищ проффесионал впервые вообще вылез в инет, это как бы тоже его трудности. Ему тогда хотя бы надо получить рекомендации от других профи.
А вообще уникального решения не найти. Предлагаемый мною вариант базируется на накопленной глобальной сумме знаний. Уверен кто-то сделает такой алгоритм в ближайшее будущем. Я инфу про людей к примеру ищу через гуугль. Более менее четко видно кто есть кто и что из себя представляет. так что если это может делать человек мозгами, значит можно научить робота автоматизировать процесс.
Однако, предлагаемая идея не панацея, а так мысли на тему…
предлагаю вариант (сразу предупреждаю не для всех случаев подходит, сами определите или вам такой вариант подойдет)
рейтинг должен вычисляться автоматичсеки из интернета. Первый тупой пример реализации, который пришел в голову: по email (или имени и фамилии) давать запрос в Google, смотреть на каких страницах, сайтах встречается упоминание о данном человеке, подсчитывать кол-во встречаемых раз + вес страниц к примеру по PR или ТИЦ. Можно запрос строить в разных проекциях, к примеру со словами математика, ИТ. Т.е. чтобы определить в какой области человек больше авторитетен. Т.е. учитываться будет активность человека во всем интернете, а не в пределах нашего сайта.
реализовать возможно, причем возможно даже «фотографирование» сайтов и веб-приложений не в стартовой точке, а уже в каком то состоянии после определенных действий пользователем. Т.е. юзер зашел на сайт, чего-то понажимал, дошел до какой-то точки и ему захотелось получить изображение сайта в текущем состоянии. Нажал на закладку (букмаклет) и появился интерфейс для фотографирования сайта. Можно создавать фото-вырезки отдельных частей, областей сайта. Обычным browsershot сервисом такое не сделать.
я очень часто меняю рабочее место, наверно в наш динамический век не один я такой. да и сервис ориентирован чтобы было максимально доступно в любое время и в любом месте. я не зря уточнил что в СНИППЕТЕ. Как раз там этой функции и не хватает.
отличная идея, хороший сервис. подкину бесплатную идею по улучшению — в снипете для сбора инфы с веб-сайтов не хватает функции фото-сайта, чтобы можно было «сфоткать» нужную часть сайта.
согласен с автором, трудно переоценить перспективы облачных платформ. Хочу добавить немного: перечисленные Amazon, Azure и Google App имеют некоторые принципиальные технологические отличия в архитектуре. Это важно учитывать и это может сыграть не последнюю роль при выборе той или иной платформы. Радует что в СНГ тоже развивается своя cloud ориентированная платформа Hivext, которая имеет определенные отличия от платформ рассмотренных в статье.
а что вы ответили на 4-ый вопрос? ведь, насколько я правильно понимаю, transient значения просто необходимо руками восстанавливать? в чем заковырка вопроса?
тогда сперва создастся объект author, а потом создастся объект book c привязкой к только что созданному объекту author
Связка объектов производится по первичным ключам, у нас это ИД объектов. С вопросами сохранения целостности данных отлично справляется Hibernate. Нельзя вставить ссылку на несуществующий объект. Нельзя удалить объект не очистив ссылки на него. В случае необходимости система может также сама очистить ссылки на объект при его удалении. Т.е. целостность данных поддерживается в полном объеме.
да можно. можно создавать свои простые типы на базе стандартных системных типов, потом создавать типы с полями ранее созданных разработчиком типов. получается ссылочная архитектура. и как сказано выше можно использовать в критериях поиска правила фильтрации по вложенным типам.
2. на основе собранной с инета информации, с последующим матчингом под разными срезами и сортировкой
А вообще уникального решения не найти. Предлагаемый мною вариант базируется на накопленной глобальной сумме знаний. Уверен кто-то сделает такой алгоритм в ближайшее будущем. Я инфу про людей к примеру ищу через гуугль. Более менее четко видно кто есть кто и что из себя представляет. так что если это может делать человек мозгами, значит можно научить робота автоматизировать процесс.
Однако, предлагаемая идея не панацея, а так мысли на тему…
рейтинг должен вычисляться автоматичсеки из интернета. Первый тупой пример реализации, который пришел в голову: по email (или имени и фамилии) давать запрос в Google, смотреть на каких страницах, сайтах встречается упоминание о данном человеке, подсчитывать кол-во встречаемых раз + вес страниц к примеру по PR или ТИЦ. Можно запрос строить в разных проекциях, к примеру со словами математика, ИТ. Т.е. чтобы определить в какой области человек больше авторитетен. Т.е. учитываться будет активность человека во всем интернете, а не в пределах нашего сайта.
DefineType(appid, session, «author», {firstname:«string», lastname:«string»})
DefineType(appid, session, «book», {price:«float», name:«string», description:«string(500)», author:" author"})
тут мы создали тип author и тип book который содержит поле автор с ранее определенным типом author
далее создадим объект author
CreateObject(appid, session, «author», {firstname:«Yasya», lastname:«Pupkin»}) ---> id = 1
его ИД = 1
создадим объект book
CreateObject(appid, session, «book», {price:10.5, name:«Разработка веб-приложений», description:«о проектирование...», author:1})
как видно мы ссылаемся на объект типа author с ИД = 1
а можно и так
CreateObject(appid, session, «book», {price:10.5, name:«Разработка веб-приложений», description:«о проектирование...», author:"{firstname:«Ivan», lastname:«Petrov»}})
тогда сперва создастся объект author, а потом создастся объект book c привязкой к только что созданному объекту author
Связка объектов производится по первичным ключам, у нас это ИД объектов. С вопросами сохранения целостности данных отлично справляется Hibernate. Нельзя вставить ссылку на несуществующий объект. Нельзя удалить объект не очистив ссылки на него. В случае необходимости система может также сама очистить ссылки на объект при его удалении. Т.е. целостность данных поддерживается в полном объеме.