форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Диалог с администрацией проекта
Изначальное сообщение		[ Отслеживать ]

"Свои сообщения на мыло"	+/–
Сообщение от nuclight (ok) on 08-Янв-11, 21:41
Можно ли сделать галочку в профайле, чтобы свои собственные сообщения тоже отправлялись на почту? Тогда в почтовом клиенте при выстраивании тредов пропусков не будет.
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Свои сообщения на мыло"	+/–
Сообщение от Maxim Chirkov (ok) on 09-Янв-11, 20:26
> Можно ли сделать галочку в профайле, чтобы свои собственные сообщения тоже отправлялись > на почту? Тогда в почтовом клиенте при выстраивании тредов пропусков не > будет. Идея понятна, сделаю.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Свои сообщения на мыло"	+/–
	Сообщение от nuclight (ok) on 27-Янв-11, 14:05
	>> Можно ли сделать галочку в профайле, чтобы свои собственные сообщения тоже отправлялись >> на почту? Тогда в почтовом клиенте при выстраивании тредов пропусков не >> будет. > Идея понятна, сделаю. То ли еще не сделано, то ли у меня глаз замылен, не найду...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Свои сообщения на мыло"	+/–
	Сообщение от Maxim Chirkov (ok) on 30-Янв-11, 22:09
	> То ли еще не сделано, то ли у меня глаз замылен, не > найду... Еще не сделал. То изменение будет сделано вместе с запланированной переработкой метода хранения профилей. Хотел сделать на прошлые выходные, потом перенес на эти, но опять времени не хватило :-(
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Свои сообщения на мыло"	+/–
	Сообщение от nuclight (ok) on 06-Фев-11, 20:32
	>> То ли еще не сделано, то ли у меня глаз замылен, не >> найду... > Еще не сделал. То изменение будет сделано вместе с запланированной переработкой метода > хранения профилей. Хотел сделать на прошлые выходные, потом перенес на эти, > но опять времени не хватило :-( Хм, а что там такое страшное планируется?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Свои сообщения на мыло"	+/–
	Сообщение от Maxim Chirkov (ok) on 06-Фев-11, 20:42
	> Хм, а что там такое страшное планируется? Хочу поменять метод хранения пользовательской базы, перейти на более надежный метод хэширования паролей и упростить репликацию изменений на другой сервер. Сейчас структура парольной БД фиксирована, планирую использовать для каждой записи сериализированный хэш, чтобы можно было любые поля добавлять налету. Дополнительные поля, которые пришли в голову: - род занятий (программист, администратор, специализация....) - место работы - публичный email - jabber/icq - участие в открытых проектах - Флаг "скрыть аватар" - RSS личного блога - Open ID - флаг отправки на еmail собственных сообщений
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Свои сообщения на мыло"	+/–
	Сообщение от nuclight (ok) on 06-Фев-11, 21:01
	>> Хм, а что там такое страшное планируется? > Хочу поменять метод хранения пользовательской базы, перейти на более надежный метод хэширования > паролей и упростить репликацию изменений на другой сервер. Сейчас структура парольной > БД фиксирована, планирую использовать для каждой записи сериализированный хэш, чтобы можно > было любые поля добавлять налету. Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним полем может и удобнее, но скорее получается NoSQL какой-то, и будут проблемы, если захочется по этим произвольным полям организовать поиск - в РСУБД как-то удобнее. Это я на "Социум Друзья: в разработке Интересы: в разработке" поглядел, но и по нижецитированным двум полям поиск, вполне возможно, будет полезен (например, ткнуть на название проекта как на тег и получить список участвующих в нем юзеров opennet). > - род занятий (программист, администратор, специализация....) > - участие в открытых проектах Здесь, вероятно, нужен список - более одного значения за раз. > - место работы > - публичный email Здесь тоже возможно списком (предыдущие места, например), хотя не так важно.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Свои сообщения на мыло"	+/–
	Сообщение от Maxim Chirkov (ok) on 06-Фев-11, 21:24
	> Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним > полем может и удобнее, но скорее получается NoSQL какой-то, и будут NoSQL и есть. В форуме и пользовательских страницах SQL не используется, там memcachedb, местами BerkeleyDB и текстовые списочные индексы. > проблемы, если захочется по этим произвольным полям организовать поиск - в > РСУБД как-то удобнее. По неиндексированному полю наружу я все равно выборку не выпущу, а если индекс создавать, то особой разницы нет, как хранятся данные. >> - род занятий (программист, администратор, специализация....) >> - участие в открытых проектах > Здесь, вероятно, нужен список - более одного значения за раз. Планирую просто открытым текстом заполнение всех полей сделать. Привязка к проектам будет через группы и ключевые слова.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Свои сообщения на мыло"	+/–
	Сообщение от nuclight (ok) on 06-Фев-11, 22:22
	>> Хмм, а ALTER TABLE не проще? Оно, конечно, для репликации с одним >> полем может и удобнее, но скорее получается NoSQL какой-то, и будут > NoSQL и есть. В форуме и пользовательских страницах SQL не используется, там > memcachedb, местами BerkeleyDB и текстовые списочные индексы. Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума - вроде бы где-то еще используется? >> проблемы, если захочется по этим произвольным полям организовать поиск - в >> РСУБД как-то удобнее. > По неиндексированному полю наружу я все равно выборку не выпущу, а если > индекс создавать, то особой разницы нет, как хранятся данные. Так ведь в случае хэша получится практически полнотекстовый поиск, разве индексы это обрабатывают, тем более, какие индексы в NoSQL? >>> - род занятий (программист, администратор, специализация....) >>> - участие в открытых проектах >> Здесь, вероятно, нужен список - более одного значения за раз. > Планирую просто открытым текстом заполнение всех полей сделать. Привязка к проектам будет > через группы и ключевые слова. Я имею в виду, это поле могло бы как раз перечнем ключевых слов и быть.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Свои сообщения на мыло"	+/–
	Сообщение от Maxim Chirkov (ok) on 06-Фев-11, 23:03
	> Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума - > вроде бы где-то еще используется? Здесь есть некоторые заметки по организации работы системы пользовательских страниц https://docs.google.com/View?docID=0AdYdqXYYpYuuZGY1d245emJf... > Так ведь в случае хэша получится практически полнотекстовый поиск, разве индексы это > обрабатывают, тем более, какие индексы в NoSQL? Ну, NoSQL - это лишь довольно общее название для кучи разных технологий и методов. MongoDB например умеет довольно интересные вещи, хотя я в силу исторических причин использую пока memcachedb. Индексы отдельно создаются, как упорядоченные списки ссылок на хэш-структуры. В простейшем случае что-то похожее на "ключ:N" => "[массив из M ссылок]", где N - это номер блока индекса, в котором находится не более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса, в 99% случаях будет считан только один блок с самыми свежими элементами).
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Свои сообщения на мыло"	+/–
	Сообщение от nuclight (ok) on 07-Фев-11, 00:09
	>> Интересно.А где-нибудь можно почитать, как устроен opennet.ru? И движок этого форума - >> вроде бы где-то еще используется? > Здесь есть некоторые заметки по организации работы системы пользовательских страниц https://docs.google.com/View?docID=0AdYdqXYYpYuuZGY1d245emJf... Бегло просмотрел, ох и много там всего... Вопрос больше был по истории, скорее :) Но много интересного, правда, что приоритетнее, неясно (выделенное красным?). Я про рейтинг прокомментирую (это уже работающая сейчас формула?), там есть "(число статей, новостей, заметок) * 10" - считаю, что у них должен быть разный коэффициент. Ну, скажем, 1 статья = 2 заметки = 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель, страницы же со статьями могут посещать и несколько лет. Точные коэффициенты можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл подсказывает, что всё-таки их вклад различается как минимум на порядок. > Ну, NoSQL - это лишь довольно общее название для кучи разных технологий > и методов. MongoDB например умеет довольно интересные вещи, хотя я в > силу исторических причин использую пока memcachedb. Индексы отдельно создаются, как упорядоченные > списки ссылок на хэш-структуры. > В простейшем случае что-то похожее на "ключ:N" => "[массив из M ссылок]", > где N - это номер блока индекса, в котором находится не > более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса, > в 99% случаях будет считан только один блок с самыми свежими > элементами). А как определятся, в каком блоке N находится ключ?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Свои сообщения на мыло"	+/–
	Сообщение от Maxim Chirkov (ok) on 07-Фев-11, 09:35
	> Бегло просмотрел, ох и много там всего... Вопрос больше был по истории, > скорее :) Но много интересного, правда, что приоритетнее, неясно (выделенное красным?). > Я про рейтинг прокомментирую (это уже работающая сейчас формула?), Нет, там общий принцип отражен. В деталях формула давно переделана. > там есть "(число статей, новостей, заметок) * 10" - считаю, что у них должен > быть разный коэффициент. Ну, скажем, 1 статья = 2 заметки = > 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель, > страницы же со статьями могут посещать и несколько лет. Точные коэффициенты > можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл > подсказывает, что всё-таки их вклад различается как минимум на порядок. Можно было учитывать в рейтинге число просмотров, но практика показывает, что самое популярное часто не самое полезное/качественное. В конце года собрался сделать сводную новость с самым интересным за год, сделал выборку самых посещаемых и комментируемых новостей и ужаснулся, там было совсем не то, что хотелось бы видеть в итогах. Что касается коэффициента для контента, то это скорее стимулирующий фактор. >> В простейшем случае что-то похожее на "ключ:N" => "[массив из M ссылок]", >> где N - это номер блока индекса, в котором находится не >> более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса, >> в 99% случаях будет считан только один блок с самыми свежими >> элементами). > А как определятся, в каком блоке N находится ключ? Задача в основном сводится к упорядоченному по времени/релевантности выводу, соответственно для вывода определенной страницы мы можем рассчитать номер блока зная общее число элементов в индексе и число элементом в одном блоке.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Свои сообщения на мыло"	+/–
	Сообщение от nuclight (ok) on 07-Фев-11, 22:01
	>[оверквотинг удален] >> 20 новостей. Обоснование - новости актуальны в лучшем случае несколько недель, >> страницы же со статьями могут посещать и несколько лет. Точные коэффициенты >> можно по анализу логов подбирать, конечно, но это трудоемко, здравый смысл >> подсказывает, что всё-таки их вклад различается как минимум на порядок. > Можно было учитывать в рейтинге число просмотров, но практика показывает, что самое > популярное часто не самое полезное/качественное. В конце года собрался сделать сводную > новость с самым интересным за год, сделал выборку самых посещаемых и > комментируемых новостей и ужаснулся, там было совсем не то, что хотелось > бы видеть в итогах. > Что касается коэффициента для контента, то это скорее стимулирующий фактор. Именно как стимулирующий фактор он и должен быть, ага. Я имел в виду не вычисление на ходу из числа просмотров, а сделать эту операцию разово, исключительно для оценки коэффициентов. Просто соотношение 1:2:10 полезности статей/советов/новостей - взято с потолка. Можно было бы взять несколько статей, про которые известно, что полезные, взять, скажем, соответствующие им новости, и посчитать сравнительную посещаемость за несколько лет. Можно, конечно, и не анализировать, а определить из соображений идеала "должно быть вот так" для пущей стимуляции. >>> В простейшем случае что-то похожее на "ключ:N" => "[массив из M ссылок]", >>> где N - это номер блока индекса, в котором находится не >>> более M-элементов (нужно, чтобы производительность обработки не зависела от размера индекса, >>> в 99% случаях будет считан только один блок с самыми свежими >>> элементами). >> А как определятся, в каком блоке N находится ключ? > Задача в основном сводится к упорядоченному по времени/релевантности выводу, соответственно > для вывода определенной страницы мы можем рассчитать номер блока зная общее > число элементов в индексе и число элементом в одном блоке. Всё же не совсем понимаю. Вот пользователь ввёл слово для поикса, это "ключ". Его надо подать на вход хэша, но там для входа нужен "ключ:N", уже другая строка.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема