Найди друга по любимым артам
На многих популярных ресурсах рекомендуются друзья, основываясь на ваших общих интересах. До сих пор я не встречал ничего подобного в брони-фандоме, и я решил это исправить. На данный момент функционал программы очень простой, но эффективный — вы вбиваете свой ник, и он показывает список брони, у которых больше всего похожих артов в избранном на Дерпибуре:
github.com/Sasha-Flyer/brony-finder
Если у вас нет возможности установить Python или вы не можете работать с такими большими даннами, как база Буры — напишите прямо в пост, я сделаю поиск по вашему нику и скажу, с кем вы, возможно, подружитесь. (сайт и дополнительный функционал появятся, если будет интерес к идее)
Вывод программы крайне простой:
Чем ближе значение к единице, тем больше у вас общих интересов.
github.com/Sasha-Flyer/brony-finder
Если у вас нет возможности установить Python или вы не можете работать с такими большими даннами, как база Буры — напишите прямо в пост, я сделаю поиск по вашему нику и скажу, с кем вы, возможно, подружитесь. (сайт и дополнительный функционал появятся, если будет интерес к идее)
Вывод программы крайне простой:
['Tyler_Cunn', 0.7647058823529411] ['SPltFYre', 0.7428571428571429] ['Coffee_Pie', 0.7297297297297297] ['Bananaphone', 0.7058823529411765] ['LiquidFireN2X', 0.7027027027027027] ['Nicknak', 0.6944444444444444] ['billybutt72', 0.6857142857142857] ['PrivateSkittles', 0.6857142857142857] ['Rainbow Z', 0.6857142857142857]
Чем ближе значение к единице, тем больше у вас общих интересов.
87 комментариев
Если отмести некрофилию, то один такой точно есть. И я его знаю
P.S. кстати. Само слово гуро вне поней вроде как применяется к расчленёнке с эротическим подтекстом. Не стоит ли это тогда считать тем же самым, что и некрофилия?
Слушай, а вот ХЗ. Я под гуро в принципе насилие понимаю, не обязательно с сексуальным подтекстом как при некрофилии. Например, садист-убийца, но не насильник, творит гурятинку, но некрофилией не занимается.
И меня смутило это
Описывается как вообще конкретно эротическая расчленёнка. То есть, получается, что гуро и гримдарк — это разные вещи, если исходит из этого. Расчленёнка, но разного назначения. Но опять же ниипу. Где-то пишут, что это изначально эрогуро, просто сокращено. А где-то, что есть два направление — гуро и эрогуро. Кому верить — хз
Ну, я иной позиции придерживаюсь. Эрогуро для меня более узкий подвид гурятинки. Но я не профессор в этом деле, могу и ошибаться. :D
Хз, мне второе слово больше нравится
00 — юзеру совершенно не интересен этот тег
01 — у юзера есть немного артов с этим тегом
10 — юзеру определенно нравится этот тег
11 — юзер фанатеет от этого тега
И затем эти данные будут побитово сравнится со всеми предпочтениями всех пользователей, и будут показаны юзеры, у которых больше всего полных совпадений.
Друзей — сомневаюсь, разве что заклятых врагов. :D
содрочильников
(introvert lives matter)хоть совпадение всего 6%, в общем интересы совпадают с твоими. У вас определнённо есть общие вкусы
Я знаю, что он фавит кучу фута-луны, ы
— ты сознательно исключаешь низкорейтинговые изображения. Да, понятно, что это аппаратное ограничение (про него ниже), но ценность совпадений у абсолютного топа ничтожна (еще тысячи людей поставили фавы, ну и толку с этой инфы?), в то время как ценность совпадения у картинки, которую зафавали вы вдвоем стремится чуть ли не к бесконечности (ну либо это твой твинк). На самом деле не совсем к бесконечности, а то программа рискует зашипперить за 2 единственных фава вхлам заминушенной кривой пикчи в пеинте;
— после прошлого нужно учитывать и возраст изображений, и желательно дату регистрации/активности юзера, чтобы хоть примерно прикидывать вероятность того, что вы видели примерно одинаковый набор картинок и отреагировали одинаково;
— фавы — не единственная точка пересечения, которая технически доступна. Можно опираться еще на фильтр/вотчлист (правда легально это можно делать только в одностороннем порядке, вторую сторону можно только попытаться предсказать по тем же самым фавам), но, опять-таки, не в текущей реализации;
— ты выше писал про теги — это работающий сценарий, но нужно учитывать, что все теги нужно воспринимать по-разному:
— — разброс по фавам в тегах вида solo female, solo male, straight, gay… может тебе дать инфу об ориентации. Если ты делаешь приложение для знакомств, это чертовски важный пункт, лол;
— — доли по персонажам — тоже весьма важный показатель, позволяет выцепить «любимую пони». Тут сложности, как это трактовать, потому что есть риск подраться за вайфу;
— — доли по артерам — просто вкусовщина;
— — и это я перечислил что-то около четверти тегов, а еще есть целый вагон, который тоже дает инфу для размышлений.
По реализации, скажем прямо: качать 18 гигов данных — невероятно пососно, и никакое одиночество не сподвигнет на такое наверное. Скорость работы этого дела… эх.
— тебе дали в руки гребанную БД. Ну используй ее, наконец, они созданы для этой фигни. Самый простой вариант: взять этот дамп, каким-нибудь скриптом выдавить дамп поменьше, с исключительно нужными тебе данными (там будет менее 100 мб, я тебе гарантирую), набросать на коленке приложение с каким-нибудь SQLite под капотом — и оно заведется даже на тапке, и будет работать значительно быстрее. Правда, для сколь либо серьезного анализа все равно придется повозиться, но текущим методом ты это не сделаешь;
— у тебя есть целая бура с целой апишкой с возможность гонять целый апикей, который дает еще кучу информации. Проверить пересечение фавов с конкретным человеком можно даже руками, и это займет не более минуты. Сложно будет проверить пересечение со всеми, да, тут ты уже рискуешь огрести по хлебалу от байта;
— целый простор для промежуточных решений между этими двумя крайностями: от сервера с некоторым кэшем и частью данных, до приложения, которое умеет само ломиться на буру.
Ну и таки нужно учитывать, что все-таки вкусы людей разные, и не стоит на этом слишком акцентироваться. Почти ни у кого из моих друзей вкусы к контенту не совпадают нормально.
не знаю как тебе, но мне было бы очень приятно, если бы такое кто-то неиронично мне написал.
У меня нет 100гб оперативки, сорри… и работать будет в 10 раз дольше.
Можно сделать более грубый подсчет (например, учитывать только последние 3 цифры в айди арта), но в таких случаях погрешность поиска будет еще выше, чем исключение низкорейтинговых артов. Я считаю что 300-400 — это адекватная мера ограничения. Понятное дело, что чем выше рейтинг, тем выше шанс, что юзер проголосовал за арт просто потому что он популярный, именно поэтому я не ставлю ограничения в 1к+. Я ещё подумаю как это можно будет оптимизировать, но в лучшем случае удастся опустить значение с 300 до 250, и то не факт.
Я уверен, что поиск по тегам будет более точным — программа будем смотреть не на сами арты, а на теги этих артов. И будет искать юзеров, у кого точно такие же предпочтительные теги.
Думаю выгоднее всего будет исключать вообще из поиска тех юзеров, которые не заходили на Буру определенное время. только вот… хранится ли эта графа открыто и если да, то какой срок выбрать? Месяц, год?..
по сути это и есть теги. которые я описал выше.
Я буду теги воспринимать относительно. 2 бита на один тег:
00 — у юзера 0% этого тега в избранном.
01 — у юзера до 1% тега в избранном
10 — у юзера до 5% тега в избранном
11 — у юзера 5% и более этого тега в избранном.
далее все теги побитово умножаются и считается количество единиц. С кем больше всего единиц — с тем у вас наиболее похожие взгляды на теги. или есть более качественные идеи, при условии обязательного ограничения в 1-2 бита на тег?
Потому что ты unicum Саша Флаер! :D
пойми какое дело… если у юзера 10к артов в избранном, и всего 1 гейский — это еще не повод заносить юзера к геям.
Я это и делаю! я вычленяю самуцю нужную информацию, удаляю арты ненужные, удаляю юзеров у которых 0 избранных, и оставляю в итоге только самую полезную инфу.
api будет работать в одностороннем порядке. Это будет эффективно если сервис окажется супер-популярным, и многие будут давать мне свой ключ. Тогда да, эта статистика может помочь.
У меня есть идея закешировать попарно вообще всех юзеров после загрузки каждого дампа. Но это будет занимать уйму времени.
Ты выплевываешь не бд, а какую-то неиндексируемую медленную хрень. Идея в том, чтобы ты родил дамп по-меньше, который сможет жрать полноценная бд, которая работает быстро и не будет жрать тысячи оперативы. Это именно личный практический опыт, нормальная бд не давится от десятков миллионнов записей и не зажирает всю оперу.
Я описал механизм предсказаний, и даже в одностороннем инициативном порядке это поможет.
Она открыта, но вроде в дамп не попадает
Это будет очень плохо работать с тегами артеров, которые имеют в среднем невысокие значения, и даже до 10% может быть погрешность. Нужно именно рожать какую-то комплексную логику, не завязанную на битах.
я храню все данные либо в dict(), в котором используется хеш-индексация, либо array.array, который является с++ массивом с индексацией через указатели, где длина каждого элемента массива четко определена. Получение элемента по индексу в обоих случаях работают как o(1), как и в базе.
Чтобы программа работала как сервер, быстрота должна быть в приоритете — либо ты за считанные секунды считываешь всё с оперативки, либо делаешь запрос к базе чтобы получить сотни тысяч фавов, которые явно займут время. Я уже на 100% уверен, что прогу придется переписать на с++, чтобы сэкономить в два раза оперативу, и тем самым получив возможность снова нагрузить её в два раза, снизив минимальный порог рейтинга.
И оно будет работать на ебучем тапке настолько быстро, что тебе даже мысли не придет переходить на плюсы.
ты ведь понимаешь, что придется пробежаться по всем юзерам, подставив их имена в user2? Один этот запрос — да, быстро. но когда тебе придется сделать этот запрос 300к раз — ну, такое…
— хранить вагон данных в опере на продуктиве оправдано пожалуй только для ну нереально жирных математических рассчетов с огромным количеством данных, которые адски просядут на чем угодно еще, и которые выполняются однократно;
— любой руководитель, когда будет стоять перед выбором «отгрохать веб-сервис, который выплюнет ответ за миллисекунды, но потребляет сотни гигов оперы», либо «отгрохать веб-сервис, который влезет в полгига оперы списанного десять лет назад сервера и выдает ответ на 10 секунд дольше» выберет второе…
— потому что ты делаешь веб-сервис разового использования. Вероятность того, что пользователь в том же месяце воспользуется им повторно ничтожна. Если ему придется подождать не 5 секунд (учитывай время полета пакетов по сети), а 15 секунд, он не очень обидится;
— ты сам же влетишь в это ограничение, когда начнешь развивать логику. Оставь оперу для высокоуровневых вычислений, выборку возложи на системы, которые созданы для этого.
Я понимаю, что когда речь идет про десятки и сотни гигабайт — то выбор всегда будет в пользу базы. Но в контексте единиц гигабайт, разница между оперативкой и ssd ничтожно мала в абсолютных значениях.
ls -l ещё тоже нельзя написать (можешь в предпросмотре проверить) (зато rm -rf /* почему-то можно)
Собственно, именно такими лазейками Табун и хакнули летом 2016 года. Думаю админы не хотят лишний раз испытывать судьбу.
И получать информацию ajax запросом.
Т.е. поднимаешь постгрес и в нем базу данных с дерпибуры (там в начале написано как поднять). Меняешь скрипт для работы с базой данных, а не с файликами. Это должно очень хорошо повысить скорость работы.
А потом просто делаешь страничку, на которой поле для ввода ника и кнопка «найти похожих пользователей», или что-то такое.
При нажатии на кнопку делается запрос к скрипту, он естественно занимает время (хоть и меньше чем 6 минут), на странице пока анимация того что скрипт делает свою работу. И когда данные готовы выводишь их.
Можно если пользователь уже ушел со страницы на другую проиграть звук, например.
ты уверен, что он будет занимать меньше времени, чем если хранить все данные в c++ в формате std::map<int, std::vector>
Табун не дает дописать int в вектор… тупо стирает оттуда, втф
Проверить как минимум стоит, оно не особо сложно делается )
Кстати, Флаер, не хочешь ещё одну полезную для брони идейку подкину?
Про поиск поней по цвету шёрстки и гривы на базе вот этого списка.
Я бы сам накодил, но некогда, плюс там много нетривиальностей — например, список создаётся на этой странице динамически, и потому каким-нибудь fetch-ем его не получить (вероятно, нужно пилить юзерскрипт и запускать его по кнопке на уже сгенерённой странице); или то, что jQuery не умеет нормально сортировать по численным значениям; или то, что нужно каким-нибудь хитрым алгоритмом вычислять цветовую дистанцию от выбранного цвета. Очевидно, надо пользователю предлагать выбор из небольшого количества цветов — порядка восьми, типа красный, жёлтый, зелёный, циан, синий, фиолетовый, белый, чёрный, но я не уверен, что дистанция будет адекватно вычисляться простым трёхмерным расстоянием типа sqrt((r-r0)^2 + (g-g0)^2 + (b-b0)^2).
Если вдруг тебе такая штука будет интересна — то думаю, многим бы результат пригодился бы =)
Если не интересна — не страшно, когда-нибудь сам напишу, наверное
HSV для такого должен неплохо подойти
в rgb — не особо. чтобы евклидова метрика «работала» тебе нужно перцептивно равномерное цветовое пространство. можно попробовать lab, там есть проблемы, но для твоих целей должно быть ок. ещё можно использовать квазиметрику (нет симметричности) $\delta E$. и то и другое уже реализовано в chroma js.
держи, scitwi.gitlab.io/color-matcher
работает в хроме и, предположительно, в фф
Спасибо тебе огромное, что довёл эту идею до реализации, я думаю, не только мне, но и многим другим эта вещь тоже пригодится =)