Как раз группы, мне кажется — не лучший вариант реализации графа интересов. Проблема груп в том, что они имеют чёткие границы. Ты либо участник группы, либо нет. Публикация либо в одной группе, либо в другой. К тому же интересов может быть много, и просматривать группы по каждому интересу тяжело.
По хорошему публикация должна относится с различными весовыми коэффициентами к той или иной теме/интересу/группе. Различные вещи тоже интересуют человека в различной степени. На основе этого нужно генерировать единую ленту для человека.
Замыкание в своих кругах приводит к одному весьма неприятному последствию. В какой-то момент один круг неожиданно сталкивается с другим и начинаются войны.
Войны мало кому нравятся, по этому лучше дружить всем миром. Только социальной сети для этого не достаточно. В идеале это должно быть Всемирное Сообщество :)
Надумана ли проблема о которой говорит Максим или нет — не так важно. Можно не концентрироваться на причинах, а смотреть только на следствия.
Хэш-теги в Твиттере, Френдфиде и т.д. были первыми движениями в сторону «графа интересов». Помимо Quora можно упомянуть пиарившийся недавно Hobius идеологически противопоставляющий себя традиционным «социальным сетям». И, конечно же, Facebook: список увлечений и интересов с недавнего времени задаётся в нём не текстом через запятую, а списком сущностей, каждая из которых имеет свою страницу на Фейсбуке.
Т.е. это движение уже происходит. Это уже тренд по факту. Только мало кто на данный момент пытался это явление чётко сформулировать и провести анализ: от чего это происходит и куда движется.
В Blitz очень много логики вывода перекладывается на контроллер. Конечно он быстрее всего чего можно (так как на C), но он почти ничего не умеет делать. С горем пополам мне удалось реализовать на нём подобие наследования с одним уровнем вложенности, это хотя бы немного упростило процесс разработки…
В общем, сейчас я считаю использование Blitz неорпавданным даже для высоконагруженных проектов. Не представляю себе систему, в которой работа с БД происходла бы быстрее генерации страницы из скомпилированного шаблона.
Совершенно верно. Я недавно пытался сформулировать ряд внешних призаков по которым можно сказать «да, это — сообщество». У меня вышло так:
1. Зарождение собственной культуры: внутренних традиций, сленга, этико-моральных норм, etc. («это вы на mail.ru идите со своими смайликами, они их любят. А у нас тут принято разговаривать человеческим языком»)
2. Выделение общепризнанных лидеров («как говорил когда-то известный всем NickName...»)
3. Появление исторического сознания и общественной рефлексии («такое уже было пару раз, вспомните хотя бы послендюю историю с NickName — неужели она ничему вас не научила?»)
Повторюсь, я имел целью найти только «внешние» формальные признаки игнорируя внутренние (такие как осознание общности о котором вы говорите или наличие общей объединяющей цели/идеи или интересов).
Честно говоря мне не очень нравится sqlalchemy. И Джанговский ORM меня не до конца устраивает. Я вот уже месяц собираюсь написать свою надстройку над Джанговским ORM :)
На самом деле у подобного подхода есть любопытное преимущество: такие цепочки можно применять к любым объектам не изменяя их функциональности. Т.е. для image в этом примере не нужно добавлять методы к классу картинки, а scale, rotate, mirrow, invert могут быть универсальными для работы с разными типами.
Так вполне может быть. Но вот залезать в глобальное пространство имён с функциями типа where, order, invert как-то некрасиво. Скорее, в реальности будет что-то типа:
from super.image.processor import i
image | i.scale(640, 960, crop = True) | i.rotate(PI/2) | i.mirrow(...) | i.invert()
in_bulk я использую когда связка происходит по первичному ключу, но это не всегда так. Пример из жизни: фильм можно оценить и/или написать не него отзыв. На странице фильма нужно вывести список лучших отзывов вместе с оценками тех, кто их написал. Лучшие отзывы определяются голосованием, а значит нужно выбрать ещё и голоса текущего пользователя за отзывы. Как я это делаю:
Получаю несколько лучших отзывов
Выбираю из полученного списка первичные ключи и id пользователей
Получаю голоса выбранных пользователей и добавляю их в список отзывов. Тут связка отзыв.user_id→оценка.user_id
Получаю и связываю голоса текущего пользователя за отзывы. Связка отзыв.id→оценка.object_id
Ну и, заодно, выбираю самих авторов отзывов, т.к. INNER JOIN генерируемый select_related() почти всегда даёт filesort в MySQL. Связка отзыв.user_id→пользователь.id. И только в этом случае мне подходит in_bulk()
С именнованными кортежами я поэкспериментировал. Модифицировать ваш код, так чтобы он мог группировать по ключу у меня не вышло, но, самым неприятным оказался тот факт, что в namedtuple нельзя добавить новые поля…
Я часто использую такой подход для оптимизации выборок (вместо join-ов):
1. Получаем список объектов
2. Пробегаемся по списку и набираем необходимые id-шники связанных объектов
3. Получаем связанные объекты используя SELECT… IN (id, ...)
4. Прицепляем связанные объекты к исходному списку (либо во view, либо непосредственно в темплейтах)
Соответственно в 3-ем пункте мне нужны записи сгруппированные по определённому полю. Я до сих пор не выработал удобный подход для подобных манипуляций. Может быть вы что-то подскажете?
Понятно, что моделируя поток воды из крана вы моделируете лишь внешние проявления, никто не будет пытаться создать с помощью программы реальный поток воды :)
Я говорю как раз о том, что есть реальные эмоции, а есть их внешние проявления которые можно худо-бедно смоделировать потугами интеллекта. И мне казалось что вы, как раз, считаете EQ просто прокаченным свойством того же IQ либо списываете его на бессознательные процессы психики («инстинкты»), в то время как EQ предполагает как раз высокую степень осознанности в области контроля, считывания / понимания и синтеза / передачи эмоций. Если я вас просто не понял — извиняюсь за базар :)
А я предлагаю вам взглянуть на иную точку зрения в котоорой эмоции — это явление несводимое ни к интеллекту, ни к тому, что вы называете «инстинктами». Вы наверняка представляете себе сложность и ресурсозатратность эмулирования физических процессов програмным способом, но, тем не менее, в реальном мире эти процессы происходят почти без затрат. Открыл кран — вот тебе турбулентность — попробуй рассчитай динамику каждой частицы и, одновременно, преломление / отражение света? Так и в человеке есть нечто для эмоций работающее по малоизвестным ещё нам принципам. Попытка смоделировать его работу логикой равносильна по сложности и полноценности приводимому выше примеру про турбулентность. И аутизм как раз является замечательным этому подтверждением.
У вас я вижу 2 базовых вектора — инстинкт и интеллект. Советую вам расширить картину мира с плоскости хотя бы до 3-х мерного варианта. Само существование описаных в статье отклонений как бы намекает людям о том, что мир многомернее чем многие привыкли думать.
Представьте себе сложноеиустройство с огромным количеством проводов. Вы изучаете его отключая некоторые из них и наблюдая за реакцией. Без этого не работает — ага это питание. Без этого работает, но становится не способным сложить 2+2. А без этого способности к сложным математическим вычислениям возрастают, но теряется умение считывать и транслировать эмоции, математический аппарат способен заменять утраченную функцию, но некачественно и с огромными затратами. Что это значит? Значит есть какой-то специальный модуль занимающийся эмоциями, есть иные принципы, нежели те, что изучает формальная логика, есть EQ, помимо IQ. Понимаете о чём я?
Согласен, такая же первая мысль была.
Я думаю что из поиска это в скором пропадёт, а +1 будет просто внедряться на страницы как Facebook Like. И это, имхо, очень хорошее решение.
По хорошему публикация должна относится с различными весовыми коэффициентами к той или иной теме/интересу/группе. Различные вещи тоже интересуют человека в различной степени. На основе этого нужно генерировать единую ленту для человека.
Войны мало кому нравятся, по этому лучше дружить всем миром. Только социальной сети для этого не достаточно. В идеале это должно быть Всемирное Сообщество :)
Хэш-теги в Твиттере, Френдфиде и т.д. были первыми движениями в сторону «графа интересов». Помимо Quora можно упомянуть пиарившийся недавно Hobius идеологически противопоставляющий себя традиционным «социальным сетям». И, конечно же, Facebook: список увлечений и интересов с недавнего времени задаётся в нём не текстом через запятую, а списком сущностей, каждая из которых имеет свою страницу на Фейсбуке.
Т.е. это движение уже происходит. Это уже тренд по факту. Только мало кто на данный момент пытался это явление чётко сформулировать и провести анализ: от чего это происходит и куда движется.
В общем, сейчас я считаю использование Blitz неорпавданным даже для высоконагруженных проектов. Не представляю себе систему, в которой работа с БД происходла бы быстрее генерации страницы из скомпилированного шаблона.
1. Зарождение собственной культуры: внутренних традиций, сленга, этико-моральных норм, etc. («это вы на mail.ru идите со своими смайликами, они их любят. А у нас тут принято разговаривать человеческим языком»)
2. Выделение общепризнанных лидеров («как говорил когда-то известный всем NickName...»)
3. Появление исторического сознания и общественной рефлексии («такое уже было пару раз, вспомните хотя бы послендюю историю с NickName — неужели она ничему вас не научила?»)
Повторюсь, я имел целью найти только «внешние» формальные признаки игнорируя внутренние (такие как осознание общности о котором вы говорите или наличие общей объединяющей цели/идеи или интересов).
На самом деле у подобного подхода есть любопытное преимущество: такие цепочки можно применять к любым объектам не изменяя их функциональности. Т.е. для image в этом примере не нужно добавлять методы к классу картинки, а scale, rotate, mirrow, invert могут быть универсальными для работы с разными типами.
И неудобство правда рядом:
Так вполне может быть. Но вот залезать в глобальное пространство имён с функциями типа where, order, invert как-то некрасиво. Скорее, в реальности будет что-то типа:
А это уже не так элегантно.
Забавно выходит :)
С именнованными кортежами я поэкспериментировал. Модифицировать ваш код, так чтобы он мог группировать по ключу у меня не вышло, но, самым неприятным оказался тот факт, что в namedtuple нельзя добавить новые поля…
А как бы сделть так, чтобы получать не список, а словарь, где ключом являлось бы значение заданного поля?
Типа:
Я часто использую такой подход для оптимизации выборок (вместо join-ов):
1. Получаем список объектов
2. Пробегаемся по списку и набираем необходимые id-шники связанных объектов
3. Получаем связанные объекты используя SELECT… IN (id, ...)
4. Прицепляем связанные объекты к исходному списку (либо во view, либо непосредственно в темплейтах)
Соответственно в 3-ем пункте мне нужны записи сгруппированные по определённому полю. Я до сих пор не выработал удобный подход для подобных манипуляций. Может быть вы что-то подскажете?
Я говорю как раз о том, что есть реальные эмоции, а есть их внешние проявления которые можно худо-бедно смоделировать потугами интеллекта. И мне казалось что вы, как раз, считаете EQ просто прокаченным свойством того же IQ либо списываете его на бессознательные процессы психики («инстинкты»), в то время как EQ предполагает как раз высокую степень осознанности в области контроля, считывания / понимания и синтеза / передачи эмоций. Если я вас просто не понял — извиняюсь за базар :)
Представьте себе сложноеиустройство с огромным количеством проводов. Вы изучаете его отключая некоторые из них и наблюдая за реакцией. Без этого не работает — ага это питание. Без этого работает, но становится не способным сложить 2+2. А без этого способности к сложным математическим вычислениям возрастают, но теряется умение считывать и транслировать эмоции, математический аппарат способен заменять утраченную функцию, но некачественно и с огромными затратами. Что это значит? Значит есть какой-то специальный модуль занимающийся эмоциями, есть иные принципы, нежели те, что изучает формальная логика, есть EQ, помимо IQ. Понимаете о чём я?
Я думаю что из поиска это в скором пропадёт, а +1 будет просто внедряться на страницы как Facebook Like. И это, имхо, очень хорошее решение.