- Свои сообщения на мыло,
 Maxim Chirkov, 20:26 , 09-Янв-11 (1)> Можно ли сделать галочку в профайле, чтобы свои собственные сообщения тоже отправлялись
> на почту? Тогда в почтовом клиенте при выстраивании тредов пропусков не
> будет.Идея понятна, сделаю.
- Свои сообщения на мыло, nuclight, 14:05 , 27-Янв-11 (2)
>> Можно ли сделать галочку в профайле, чтобы свои собственные сообщения тоже отправлялись
>> на почту? Тогда в почтовом клиенте при выстраивании тредов пропусков не
>> будет.
> Идея понятна, сделаю.То ли еще не сделано, то ли у меня глаз замылен, не найду...
- Свои сообщения на мыло, Maxim Chirkov, 22:09 , 30-Янв-11 (3)
> То ли еще не сделано, то ли у меня глаз замылен, не
> найду...Еще не сделал. То изменение будет сделано вместе с запланированной переработкой метода хранения профилей. Хотел сделать на прошлые выходные, потом перенес на эти, но опять времени не хватило :-(
- Свои сообщения на мыло, nuclight, 20:32 , 06-Фев-11 (4)
>> То ли еще не сделано, то ли у меня глаз замылен, не
>> найду...
> Еще не сделал. То изменение будет сделано вместе с запланированной переработкой метода
> хранения профилей. Хотел сделать на прошлые выходные, потом перенес на эти,
> но опять времени не хватило :-( Хм, а что там такое страшное планируется?
- Свои сообщения на мыло, Maxim Chirkov, 20:42 , 06-Фев-11 (5)
> Хм, а что там такое страшное планируется?Хочу поменять метод хранения пользовательской базы, перейти на более надежный метод хэширования паролей и упростить репликацию изменений на другой сервер. Сейчас структура парольной БД фиксирована, планирую использовать для каждой записи сериализированный хэш, чтобы можно было любые поля добавлять налету. Дополнительные поля, которые пришли в голову: - род занятий (программист, администратор, специализация....)
- место работы
- публичный email
- jabber/icq
- участие в открытых проектах
- Флаг "скрыть аватар"
- RSS личного блога
- Open ID
- флаг отправки на еmail собственных сообщений
- Свои сообщения на мыло, nuclight, 21:01 , 06-Фев-11 (6)
>> Хм, а что там такое страшное планируется?
> Хочу поменять метод хранения пользовательской базы, перейти на более надежный метод хэширования
> паролей и упростить репликацию изменений на другой сервер. Сейчас структура парольной
> БД фиксирована, планирую использовать для каждой записи сериализированный хэш, чтобы можно
> было любые поля добавлять налету.Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним полем может и удобнее, но скорее получается NoSQL какой-то, и будут проблемы, если захочется по этим произвольным полям организовать поиск - в РСУБД как-то удобнее. Это я на "Социум Друзья: в разработке Интересы: в разработке" поглядел, но и по нижецитированным двум полям поиск, вполне возможно, будет полезен (например, ткнуть на название проекта как на тег и получить список участвующих в нем юзеров opennet). > - род занятий (программист, администратор, специализация....)
> - участие в открытых проектах Здесь, вероятно, нужен список - более одного значения за раз. > - место работы
> - публичный email Здесь тоже возможно списком (предыдущие места, например), хотя не так важно.
- Свои сообщения на мыло, Maxim Chirkov, 21:24 , 06-Фев-11 (7)
> Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним
> полем может и удобнее, но скорее получается NoSQL какой-то, и будут NoSQL и есть. В форуме и пользовательских страницах SQL не используется, там memcachedb, местами BerkeleyDB и текстовые списочные индексы. > проблемы, если захочется по этим произвольным полям организовать поиск - в
> РСУБД как-то удобнее. По неиндексированному полю наружу я все равно выборку не выпущу, а если индекс создавать, то особой разницы нет, как хранятся данные. >> - род занятий (программист, администратор, специализация....)
>> - участие в открытых проектах
> Здесь, вероятно, нужен список - более одного значения за раз. Планирую просто открытым текстом заполнение всех полей сделать. Привязка к проектам будет через группы и ключевые слова.
- Свои сообщения на мыло, nuclight, 22:22 , 06-Фев-11 (8)
>> Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним
>> полем может и удобнее, но скорее получается NoSQL какой-то, и будут
> NoSQL и есть. В форуме и пользовательских страницах SQL не используется, там
> memcachedb, местами BerkeleyDB и текстовые списочные индексы.Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума - вроде бы где-то еще используется? >> проблемы, если захочется по этим произвольным полям организовать поиск - в
>> РСУБД как-то удобнее.
> По неиндексированному полю наружу я все равно выборку не выпущу, а если
> индекс создавать, то особой разницы нет, как хранятся данные. Так ведь в случае хэша получится практически полнотекстовый поиск, разве индексы это обрабатывают, тем более, какие индексы в NoSQL? >>> - род занятий (программист, администратор, специализация....)
>>> - участие в открытых проектах
>> Здесь, вероятно, нужен список - более одного значения за раз.
> Планирую просто открытым текстом заполнение всех полей сделать. Привязка к проектам будет
> через группы и ключевые слова. Я имею в виду, это поле могло бы как раз перечнем ключевых слов и быть.
- Свои сообщения на мыло, Maxim Chirkov, 23:03 , 06-Фев-11 (9)
> Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума -
> вроде бы где-то еще используется?Здесь есть некоторые заметки по организации работы системы пользовательских страниц https://docs.google.com/View?docID=0AdYdqXYYpYuuZGY1d245emJf... > Так ведь в случае хэша получится практически полнотекстовый поиск, разве индексы это
> обрабатывают, тем более, какие индексы в NoSQL? Ну, NoSQL - это лишь довольно общее название для кучи разных технологий и методов. MongoDB например умеет довольно интересные вещи, хотя я в силу исторических причин использую пока memcachedb. Индексы отдельно создаются, как упорядоченные списки ссылок на хэш-структуры.
В простейшем случае что-то похожее на "ключ:N" => "[массив из M ссылок]", где N - это номер блока индекса, в котором находится не более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса, в 99% случаях будет считан только один блок с самыми свежими элементами).
- Свои сообщения на мыло, nuclight, 00:09 , 07-Фев-11 (10)
>> Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума -
>> вроде бы где-то еще используется?
> Здесь есть некоторые заметки по организации работы системы пользовательских страниц https://docs.google.com/View?docID=0AdYdqXYYpYuuZGY1d245emJf... Бегло просмотрел, ох и много там всего... Вопрос больше был по истории, скорее :) Но много интересного, правда, что приоритетнее, неясно (выделенное красным?). Я про рейтинг прокомментирую (это уже работающая сейчас формула?), там есть "(число статей, новостей, заметок) * 10" - считаю, что у них должен быть разный коэффициент. Ну, скажем, 1 статья = 2 заметки = 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель, страницы же со статьями могут посещать и несколько лет. Точные коэффициенты можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл подсказывает, что всё-таки их вклад различается как минимум на порядок. > Ну, NoSQL - это лишь довольно общее название для кучи разных технологий
> и методов. MongoDB например умеет довольно интересные вещи, хотя я в
> силу исторических причин использую пока memcachedb. Индексы отдельно создаются, как упорядоченные
> списки ссылок на хэш-структуры.
> В простейшем случае что-то похожее на "ключ:N" => "[массив из M ссылок]",
> где N - это номер блока индекса, в котором находится не
> более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса,
> в 99% случаях будет считан только один блок с самыми свежими
> элементами). А как определятся, в каком блоке N находится ключ?
- Свои сообщения на мыло, Maxim Chirkov, 09:35 , 07-Фев-11 (11)
> Бегло просмотрел, ох и много там всего... Вопрос больше был по истории,
> скорее :) Но много интересного, правда, что приоритетнее, неясно (выделенное красным?).
> Я про рейтинг прокомментирую (это уже работающая сейчас формула?), Нет, там общий принцип отражен. В деталях формула давно переделана. > там есть "(число статей, новостей, заметок) * 10" - считаю, что у них должен
> быть разный коэффициент. Ну, скажем, 1 статья = 2 заметки =
> 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель,
> страницы же со статьями могут посещать и несколько лет. Точные коэффициенты
> можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл
> подсказывает, что всё-таки их вклад различается как минимум на порядок. Можно было учитывать в рейтинге число просмотров, но практика показывает, что самое популярное часто не самое полезное/качественное. В конце года собрался сделать сводную новость с самым интересным за год, сделал выборку самых посещаемых и комментируемых новостей и ужаснулся, там было совсем не то, что хотелось бы видеть в итогах.
Что касается коэффициента для контента, то это скорее стимулирующий фактор. >> В простейшем случае что-то похожее на "ключ:N" => "[массив из M ссылок]",
>> где N - это номер блока индекса, в котором находится не
>> более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса,
>> в 99% случаях будет считан только один блок с самыми свежими
>> элементами).
> А как определятся, в каком блоке N находится ключ? Задача в основном сводится к упорядоченному по времени/релевантности выводу, соответственно для вывода определенной страницы мы можем рассчитать номер блока зная общее число элементов в индексе и число элементом в одном блоке.
- Свои сообщения на мыло, nuclight, 22:01 , 07-Фев-11 (12)
>[оверквотинг удален]
>> 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель,
>> страницы же со статьями могут посещать и несколько лет. Точные коэффициенты
>> можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл
>> подсказывает, что всё-таки их вклад различается как минимум на порядок.
> Можно было учитывать в рейтинге число просмотров, но практика показывает, что самое
> популярное часто не самое полезное/качественное. В конце года собрался сделать сводную
> новость с самым интересным за год, сделал выборку самых посещаемых и
> комментируемых новостей и ужаснулся, там было совсем не то, что хотелось
> бы видеть в итогах.
> Что касается коэффициента для контента, то это скорее стимулирующий фактор.Именно как стимулирующий фактор он и должен быть, ага. Я имел в виду не вычисление на ходу из числа просмотров, а сделать эту операцию разово, исключительно для оценки коэффициентов. Просто соотношение 1:2:10 полезности статей/советов/новостей - взято с потолка. Можно было бы взять несколько статей, про которые известно, что полезные, взять, скажем, соответствующие им новости, и посчитать сравнительную посещаемость за несколько лет. Можно, конечно, и не анализировать, а определить из соображений идеала "должно быть вот так" для пущей стимуляции. >>> В простейшем случае что-то похожее на "ключ:N" => "[массив из M ссылок]",
>>> где N - это номер блока индекса, в котором находится не
>>> более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса,
>>> в 99% случаях будет считан только один блок с самыми свежими
>>> элементами).
>> А как определятся, в каком блоке N находится ключ?
> Задача в основном сводится к упорядоченному по времени/релевантности выводу, соответственно
> для вывода определенной страницы мы можем рассчитать номер блока зная общее
> число элементов в индексе и число элементом в одном блоке. Всё же не совсем понимаю. Вот пользователь ввёл слово для поикса, это "ключ". Его надо подать на вход хэша, но там для входа нужен "ключ:N", уже другая строка.
|
Версия для распечатки
Свои сообщения на мыло, 
