https://slinkov.ru/openforum/vsluhforumID4/386.html Можно ли сделать галочку в профайле, чтобы свои собственные сообщения тоже отправлялись на почту? Тогда в почтовом клиенте при выстраивании тредов пропусков не будет.<br> https://slinkov.ru/openforum/vsluhforumID4/386.html#12 Mon, 07 Feb 2011 19:01:28 GMT &gt;[оверквотинг удален]<br>&gt;&gt; 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель, <br>&gt;&gt; страницы же со статьями могут посещать и несколько лет. Точные коэффициенты <br>&gt;&gt; можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл <br>&gt;&gt; подсказывает, что всё-таки их вклад различается как минимум на порядок.<br>&gt; Можно было учитывать в рейтинге число просмотров, но практика показывает, что самое <br>&gt; популярное часто не самое полезное/качественное. В конце года собрался сделать сводную <br>&gt; новость с самым интересным за год, сделал выборку самых посещаемых и <br>&gt; комментируемых новостей и ужаснулся, там было совсем не то, что хотелось <br>&gt; бы видеть в итогах.<br>&gt; Что касается коэффициента для контента, то это скорее стимулирующий фактор.<br><br>Именно как стимулирующий фактор он и должен быть, ага. Я имел в виду не вычисление на ходу из числа просмотров, а сделать эту операцию разово, исключительно для оценки коэффициентов. Просто соотношение 1:2:10 полезности статей/советов/новостей - https://slinkov.ru/openforum/vsluhforumID4/386.html#11 Mon, 07 Feb 2011 06:35:42 GMT &gt; Бегло просмотрел, ох и много там всего... Вопрос больше был по истории, <br>&gt; скорее :) Но много интересного, правда, что приоритетнее, неясно (выделенное красным?). <br>&gt; Я про рейтинг прокомментирую (это уже работающая сейчас формула?), <br><br>Нет, там общий принцип отражен. В деталях формула давно переделана.<br><br>&gt; там есть "(число статей, новостей, заметок) * 10" - считаю, что у них должен <br>&gt; быть разный коэффициент. Ну, скажем, 1 статья = 2 заметки = <br>&gt; 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель, <br>&gt; страницы же со статьями могут посещать и несколько лет. Точные коэффициенты <br>&gt; можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл <br>&gt; подсказывает, что всё-таки их вклад различается как минимум на порядок.<br><br>Можно было учитывать в рейтинге число просмотров, но практика показывает, что самое популярное часто не самое полезное/качественное. В конце года собрался сделать сводную новость с самым интересным за год, сделал выборку самых посещаемых и комментиру https://slinkov.ru/openforum/vsluhforumID4/386.html#10 Sun, 06 Feb 2011 21:09:30 GMT &gt;&gt; Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума - <br>&gt;&gt; вроде бы где-то еще используется?<br>&gt; Здесь есть некоторые заметки по организации работы системы пользовательских страниц https://docs.google.com/View?docID=0AdYdqXYYpYuuZGY1d245emJfMjJndnN0cTljMg <br><br>Бегло просмотрел, ох и много там всего... Вопрос больше был по истории, скорее :) Но много интересного, правда, что приоритетнее, неясно (выделенное красным?).<br><br>Я про рейтинг прокомментирую (это уже работающая сейчас формула?), там есть "(число статей, новостей, заметок) * 10" - считаю, что у них должен быть разный коэффициент. Ну, скажем, 1 статья = 2 заметки = 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель, страницы же со статьями могут посещать и несколько лет. Точные коэффициенты можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл подсказывает, что всё-таки их вклад различается как минимум на порядок.<br><br>&gt; Ну, NoSQL - это лишь довольно общее название для кучи ра https://slinkov.ru/openforum/vsluhforumID4/386.html#9 Sun, 06 Feb 2011 20:03:12 GMT &gt; Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума - <br>&gt; вроде бы где-то еще используется?<br><br>Здесь есть некоторые заметки по организации работы системы пользовательских страниц https://docs.google.com/View?docID=0AdYdqXYYpYuuZGY1d245emJfMjJndnN0cTljMg<br><br>&gt; Так ведь в случае хэша получится практически полнотекстовый поиск, разве индексы это <br>&gt; обрабатывают, тем более, какие индексы в NoSQL?<br><br>Ну, NoSQL - это лишь довольно общее название для кучи разных технологий и методов. MongoDB например умеет довольно интересные вещи, хотя я в силу исторических причин использую пока memcachedb. Индексы отдельно создаются, как упорядоченные списки ссылок на хэш-структуры.<br>В простейшем случае что-то похожее на "ключ:N" =&gt; "[массив из M ссылок]", где N - это номер блока индекса, в котором находится не более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса, в 99% случаях будет считан только один блок с самыми свежими элементами).<br><br><br><br> https://slinkov.ru/openforum/vsluhforumID4/386.html#8 Sun, 06 Feb 2011 19:22:50 GMT &gt;&gt; Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним <br>&gt;&gt; полем может и удобнее, но скорее получается NoSQL какой-то, и будут <br>&gt; NoSQL и есть. В форуме и пользовательских страницах SQL не используется, там <br>&gt; memcachedb, местами BerkeleyDB и текстовые списочные индексы.<br><br>Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума - вроде бы где-то еще используется?<br><br>&gt;&gt; проблемы, если захочется по этим произвольным полям организовать поиск - в <br>&gt;&gt; РСУБД как-то удобнее.<br>&gt; По неиндексированному полю наружу я все равно выборку не выпущу, а если <br>&gt; индекс создавать, то особой разницы нет, как хранятся данные.<br><br>Так ведь в случае хэша получится практически полнотекстовый поиск, разве индексы это обрабатывают, тем более, какие индексы в NoSQL?<br><br>&gt;&gt;&gt; - род занятий (программист, администратор, специализация....) <br>&gt;&gt;&gt; - участие в открытых проектах <br>&gt;&gt; Здесь, вероятно, нужен список - более одного значения за раз.<br>&gt; Планирую просто открытым текстом заполнение всех поле https://slinkov.ru/openforum/vsluhforumID4/386.html#7 Sun, 06 Feb 2011 18:24:04 GMT &gt; Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним <br>&gt; полем может и удобнее, но скорее получается NoSQL какой-то, и будут <br><br>NoSQL и есть. В форуме и пользовательских страницах SQL не используется, там memcachedb, местами BerkeleyDB и текстовые списочные индексы. <br><br>&gt; проблемы, если захочется по этим произвольным полям организовать поиск - в <br>&gt; РСУБД как-то удобнее.<br><br>По неиндексированному полю наружу я все равно выборку не выпущу, а если индекс создавать, то особой разницы нет, как хранятся данные.<br><br>&gt;&gt; - род занятий (программист, администратор, специализация....) <br>&gt;&gt; - участие в открытых проектах <br>&gt; Здесь, вероятно, нужен список - более одного значения за раз.<br><br>Планирую просто открытым текстом заполнение всех полей сделать. Привязка к проектам будет через группы и ключевые слова.<br> https://slinkov.ru/openforum/vsluhforumID4/386.html#6 Sun, 06 Feb 2011 18:01:31 GMT &gt;&gt; Хм, а что там такое страшное планируется?<br>&gt; Хочу поменять метод хранения пользовательской базы, перейти на более надежный метод хэширования <br>&gt; паролей и упростить репликацию изменений на другой сервер. Сейчас структура парольной <br>&gt; БД фиксирована, планирую использовать для каждой записи сериализированный хэш, чтобы можно <br>&gt; было любые поля добавлять налету.<br><br>Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним полем может и удобнее, но скорее получается NoSQL какой-то, и будут проблемы, если захочется по этим произвольным полям организовать поиск - в РСУБД как-то удобнее. Это я на "Социум Друзья: в разработке Интересы: в разработке" поглядел, но и по нижецитированным двум полям поиск, вполне возможно, будет полезен (например, ткнуть на название проекта как на тег и получить список участвующих в нем юзеров opennet).<br><br>&gt; - род занятий (программист, администратор, специализация....) <br>&gt; - участие в открытых проектах <br><br>Здесь, вероятно, нужен список - более одного значения за раз.<br><br>&gt; - мес https://slinkov.ru/openforum/vsluhforumID4/386.html#5 Sun, 06 Feb 2011 17:42:07 GMT &gt; Хм, а что там такое страшное планируется?<br><br>Хочу поменять метод хранения пользовательской базы, перейти на более надежный метод хэширования паролей и упростить репликацию изменений на другой сервер. Сейчас структура парольной БД фиксирована, планирую использовать для каждой записи сериализированный хэш, чтобы можно было любые поля добавлять налету. <br><br>Дополнительные поля, которые пришли в голову:<br><br>- род занятий (программист, администратор, специализация....)<br>- место работы<br>- публичный email<br>- jabber/icq<br>- участие в открытых проектах<br>- Флаг "скрыть аватар"<br>- RSS личного блога<br>- Open ID<br>- флаг отправки на еmail собственных сообщений<br> https://slinkov.ru/openforum/vsluhforumID4/386.html#4 Sun, 06 Feb 2011 17:32:59 GMT &gt;&gt; То ли еще не сделано, то ли у меня глаз замылен, не <br>&gt;&gt; найду...<br>&gt; Еще не сделал. То изменение будет сделано вместе с запланированной переработкой метода <br>&gt; хранения профилей. Хотел сделать на прошлые выходные, потом перенес на эти, <br>&gt; но опять времени не хватило :-( <br><br>Хм, а что там такое страшное планируется?<br>