Снова попиарюсь

Сейчас так и делается, только таймзону для куки (в данном случае для сессии) ты выбираешь в настройках.

Совок же. Зачем выбирать вручную то что можно поставить автоматически? Некоторые еще позволяют DST включать и выключать. Не иначе как чтобы юзер чувствовал себя повелителем времени.

Я же говорю, относительный формат у меня реализовать сложно из-за реализации кэширования.

Кто хочет - ищет способ, нутыпонил :)

В теги time прописывается UTC date и меняется на клиенте жабаскриптом по селектору.

Мне придётся всем кэшам установить время жизни в минуту, что понижает их эффективность в разы.

Кеши не нужны. Компилированные темплейты выплевывают страницы достаточно быстро.

Зачем выбирать вручную то что можно поставить автоматически?

Нельзя, нет такого в HTTP. А отсылать жаваскриптом на сервер таймзону и там её сохранять непонятно когда — это костыль.

В теги time прописывается UTC date и меняется на клиенте жабаскриптом по селектору.

Так и делал, заметно мигало при смене. Правда я менял на всех сразу после загрузки страницы, возможно стоит на каждом отдельно при его загрузке. Подскажешь как?

Кеши не нужны. Компилированные темплейты выплевывают страницы достаточно быстро.

Ты видел, какие там у меня темплейты и как посты грузятся? Там много запросов в базу могут быть из-за сложности связей между моделями. Взять хотя бы то, что в одном треде у разных постов могут быть разные треды из-за фичи мультитредовости.

Нельзя, нет такого в HTTP. А отсылать жаваскриптом на сервер таймзону и там её сохранять непонятно когда — это костыль.

Ну костыль, но работает же, если правильно сделано. Кука на сервере нигде не хранится. Она каждый раз заново парсится из заголовка. Ведь нет разницы, откуда именно смещение возьмется.

Так и делал, заметно мигало при смене. Правда я менял на всех сразу после загрузки страницы, возможно стоит на каждом отдельно при его загрузке. Подскажешь как?

Тут не подскажу. У меня время сразу правильное делается, и потом только апдейтится. К тому же после первой загрузки потом весь рендеринг на клиенте продолжается. Поэтому проблемы изначально нет.

Ты видел, какие там у меня темплейты и как посты грузятся? Там много запросов в базу могут быть из-за сложности связей между моделями. Взять хотя бы то, что в одном треде у разных постов могут быть разные треды из-за фичи мультитредовости.

Не смотрел, сорри, не до этого. Написал на основе личного опыта, т.к. сейчас тоже с форумом ковыряюсь. Данные должны быть отделены от темплейтов. Тогда все будет мягко и шелковисто. Включая рендеринг на клиенте.

Данные должны быть отделены от темплейтов.

А они и отделены. Но в темплейте рендерится по темплейту на каждый пост, и для каждого поста дёргается его тред (который не обязательно один на всех).

Ну дык за отображение даты отвечают хелперы темплейтов, а не модели которые треды извлекают. В темплейты время всегда приходит в UTC. Если сильно хочется кеши делать - надо их на данные втыкать, а темплейты каждый раз заново проигрывать.

У меня теплейты 30% ресурсов отъедают. Экономия не стоит тех вагонов гимора, который приплывет при попытке закешировать темплейты (вьюмодели).

Если сильно хочется кеши делать - надо их на данные втыкать

Там задолбаешься кэшировать всё подряд, кучи many-to-many

Но я над этим подумаю. Может ты и прав, нужно оптимизировать запросы в базу и кэшировать результаты некоторых из них.

Там задолбаешься кэшировать всё подряд, кучи many-to-many

Вопрос дизайна данных и бизнес-логики. Если фазы выгребания и рендеринга полностью изолированы, то фиолетово что кешировать - HTML или исходный JSON. Если все вперемешку - тогда остается либо переделывать либо страдать.

Если все вперемешку - тогда остается либо переделывать либо страдать.

Если у меня в шаблоне поста идёт обращение к треду — это вперемешку? ИМХО вполне логично. Но в этот момент выгребается связь пост-тред.

Советую позырить видео по BEM, там в каком-то очень хорошо рассказывалось про слои абстракций, и что к чему относится.

Все проблемы начинаются, когда в бизнес-логику суют вещи, которые должны делать вьюмодели. Например, в сиквеле джоинить юзеров на посты. Надо отдельно фетчить посты, отдельно юзеров. А переклеивает пусть темплейт (вьюмодель).

Для этого надо либо в явном виде выделять вьюмодели (что обычно западло), либо использовать навороченные шаблонизаторы типа jade, где можно слегка покодить.

Если у меня в шаблоне поста идёт обращение к треду — это вперемешку? ИМХО вполне логично. Но в этот момент выгребается связь пост-тред.

Если данные локальные - это нормально. Тогда темплейт выступает в качестве вьюмодели, которая отвечает за презентацию данных. А если фетчатся из базы - это ахтунг.

Не понял твоих описаний. Можно с примерами?

Например, в сиквеле джоинить юзеров на посты.

Что в этом плохого, если джанга позволяет делать select_related или как его там? В итоге я могу почти весь тред достать одним запросом.

У меня как-то так: https://github.com/nodeca/nodeca.forum/blob/master/client/forum/blocks/posts_...

Все данные есть, но лежат отдельно.

Так медленнее. Я получаю все посты с картинками одним запросом, а если вручную, то для каждого поста был бы отдельный запрос на картинку (картинка это сложная модель с кучей полей и хранится отдельно).

Что в этом плохого, если джанга позволяет делать select_related или как его там? В итоге я могу почти весь тред достать одним запросом.

Плохого в этом то, что это новый вид данных, который усложняет бизнес-логику. Например, то же кеширование :) . Ну и резко вырастают шансы, что при редактировании шаблонов понадобится сервер подкручивать.

А что усложняется? В коде ничего не изменилось, просто ORM'у меньше запросов делать. Вернее, в коде изменилось то, что там где это делается указан список подгружаемых «вместе» моделей.

Так медленнее. Я получаю все посты с картинками одним запросом, а если вручную, то для каждого поста был бы отдельный запрос на картинку (картинка это сложная модель с кучей полей и хранится отдельно).

Картинки вообще-то браузер «фетчит», совершенно отдельно. Поэтому достаточно просто ID, по которому в шаблоне делается и ссылка на превьюшку и на оригинал.

Будем считать что вопрос был про юзеров. Естественно, их надо сначала собрать, а потом зафетчить одним запросом, а не на запросу на пост.

В третий раз эта маняотговорка уже не так смешно звучит.

Картинки вообще-то браузер «фетчит», совершенно отдельно.

Я же сказал, там сложная модель. Не буду описывать подробно, просто считаем что каждый пост [теоретически] связан с многими картинками, которые состоят из многих полей и собственно ссылки на картинку для браузера.

А первые два когда были?

А что усложняется? В коде ничего не изменилось, просто ORM'у меньше запросов делать.

Ну во-первых, нужен ORM, а он раз в 10 медленнее DSL. На запись ORM использовать действительно актуально. На чтение - слишком накладно.

Во-вторых, композитные данные - это абсолютно новая сущность. И надо держать в голове, что шаблон работает не с простыми юзерами и постами, а с какой-то новой херней. А когда появятся блоги - там будет еще одна новая херня, вместо старых-добрых юзеров.

Плюс не получится сделать универсальных штук типа «прокешировать юзеров» или «прокешировать посты». Потому что с момента как ты их объединил - получилась более сложная монолитная штука, где правила инвалидации кеша усложнились на порядок.

Во-вторых, композитные данные - это абсолютно новая сущность. И надо держать в голове, что шаблон работает не с простыми юзерами и постами, а с какой-то новой херней. А когда появятся блоги - там будет еще одна новая херня, вместо старых-добрых юзеров.

Зачем держать это в голове, если работает со всем ORM, а разработчику вообще пофиг, в каком виде оно досталось и сколько запросов при этом склеили в один?

В предыдущем треде и когда-то на твоей параше.

Ну во-первых, можно собрать ID-шники постов, и зафетчить для них картинки чохом. Во-вторых, можно задизайнить URL-бакеты так, чтобы шв картинки хватало «для всего».

Ведь чтобы показать страничку, рендереру не нужно знать все особенности картинок. Ему нужны только ссылки. По id картинки такие ссылки генерить вполне реально. id картинок можно хранить вместе с постом - типа, денормализация.

Зачем держать это в голове, если работает со всем ORM, а разработчику вообще пофиг, в каком виде оно досталось и сколько запросов при этом склеили в один?

Чтобы в один прекрасный момент не обнаружить, что на кеши потрачено больше усилий, чем сэкономлено на ORM. Сложные данные требуют сложный кеш.

Нельзя. Если не хранить размер превью, страница будет мограть при загрузке. Если не хранить размер самой картинки, не будут работать попапы. Если не хранить хеш, не будет дедупликации.

Нельзя.

Ну у меня-то получилось :)

Если не хранить размер превью, страница будет мограть при загрузке.

Размер превьюхи стандартный, поэтому можно задать прямо в CSS. Просто не надо упарываться на тему что вертикальным фоткам нужна вертикальная превьюшка. И все сразу станет легко и просто.

Если не хранить размер самой картинки, не будут работать попапы.

Дык это при сохранении поста пишется, прямо в разметку, превьюшка там или нет, в data-* и т.п. Можно разметку текста хранить в 2 форматах - исходном и обработанном (сам текст, без обертки). Снимает кучу проблем на выборке.

Есть ограничения - нельзя сделать динамический контент, например «показывать только тем кто зарегистрирован больше года назад». Но это не особо нужная штука. А остальное делается через CSS.

Если не хранить хеш, не будет дедупликации.

Не совсем понял, что имеется в виду. Если речь о дедупликации картинок, когда 100 юзеров постят одного и того же котика, то это актуально только для ОЧЕНЬ больших фотохостингов, на других вероятность совпадений нулевая (единичные случаи не считаем). Я прикидывал у себя профит дедупликации, в итоге решил что проще потерять немного места, чем усложнять архитектуру.

Форумные балалайки - это набор компромиссов между эффективностью и фичами. Иначе не будет быстро работать. У меня кешируются права доступа и разметка текстов. Пока хватает.

А я где-то говорил, что я прямо такой белый и пушистый и в толксы не хожу? :-)

Размер превьюхи стандартный

Нет, пропорции. При заявленном 200x300 можно из-за пропорций получить 200x295 например. Если не указать это в атрибутах, страница не сможет сразу расставить пустые места под все фотки и будет прыгать.

Дык это при сохранении поста пишется, прямо в разметку

Это пишется в базу, а уже при рендеринге в разметку.

Если речь о дедупликации картинок, когда 100 юзеров постят одного и того же котика, то это актуально только для ОЧЕНЬ больших фотохостингов, на других вероятность совпадений нулевая (единичные случаи не считаем).

И всё же я его сделал, просто ради интереса. Хотя у меня есть сомнения, что md5 для этого подходит.

страница не сможет сразу расставить пустые места

Запили div фиксированного размера, а уже туда img миниатюру.

Нет, пропорции. При заявленном 200x300 можно из-за пропорций получить 200x295 например.

В таком подходе мало профита. Выгоднее обрезать «лишнее» чтобы превьюхи были строго одинаковыми. Смотрится это тоже симпатичнее.

Это пишется в базу, а уже при рендеринге в разметку.

Если разметка каждый раз заново генерируется из исходной (того что юзер набрал), это будет дорого на продакшене.

И всё же я его сделал, просто ради интереса. Хотя у меня есть сомнения, что md5 для этого подходит.

Если коллизии не приемлимы, то не подходит, надо sha256/512.

Выгоднее обрезать «лишнее» чтобы превьюхи были строго одинаковыми.

Я не хочу портить картинки.

Если разметка каждый раз заново генерируется из исходной (того что юзер набрал), это будет дорого на продакшене.

Разметка текста сообщения сохраняется (то что теги нарендерили), но не разметка всего поста.

Если коллизии не приемлимы, то не подходит, надо sha256/512.

А в них что, не будет коллизий? При любом хеше меньше размера файла они будут по идее.

Your IP address has been banned. Contact the administrator
Autoban: spam bot

Открыл первый раз.

Тоже тор?

Всем прекрасно понятно, кто ты. :-)

Я не хочу портить картинки.

Дык оригиналы не портятся. Это только для превьюшек делается.

Основная нагрузка на форум - прочитать страницу с тонной постов и тонной превьюшек. Все, что связано с этими кусками, есть смысл делать оптимально.

А в них что, не будет коллизий? При любом хеше меньше размера файла они будут по идее.

У md5 плохое распределение. У sha хорошее. Поэтому на md5 иногда бывают коллизии в реальной жизни. На sha и т.п. вероятность только теоретическая (зависит лишь от длины ключа).

заметно мигало при смене

У меня не мигало. Пора апгрейдиться :}

Правда от количества повторений не зависит :}

Маняправда от маняколичества маняповторений не зависит :}

Пофиксил тебя там. Я понимаю, что ты привык к гнилым шрифтам, как на твоей родной сырнопараше, но все-таки.

Товарищ норкоман, правило font: medium sans-serif означает взять шрифт без засечек с системы. У тебя браузер и/или система прогнила, лечись :}

Ой, все.

Слив засчитан :}

Как можно бороться с автоматизированным флудом без капчи? Очень уж не хочется её вводить, много подводных камней.

Пока не придумал ничего умнее, чем давать 30-секундную задержку в том числе и перед первым постингом (если сессии ещё нет). Так можно отвадить ботов, которые с сессиями работать не умеют вообще. А для тех что умеют будет время чтобы их забанить по IP.

Просто нужно как минимум 6 модераторов, в разных часовых поясах.

Количество модераторов должно зависеть от количества пользователей. Если тебя будут вайпать одновременно с 300 айпишников, то даже 6 модераторов небыстро справятся.

Просто нужна фича, когда замаркированные сообщения, кроме как с ip адреса, с которого написано сообщение не видно. И просто встань например на cloudflare уже.

Кто там хотел разворачивать картинки в посте, теперь для этого есть настройка.

Круто конечно, только нафиг оно сдалось?