С 1 августа Google прекращает поддержку Firefox 3.5, IE7 и Safari 3

> С выходом IE10 прекратится и поддержка XP
Прекратиться поддержка IE на XP, ставь любой новый не IE и работай

С 1 августа Google прекращает поддержку Firefox 3.5, IE7 и Safari 3

На западе она не распространена

С 1 августа Google прекращает поддержку Firefox 3.5, IE7 и Safari 3

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

К вопросу об инвалидации кеша

1. С количеством комментариев возможно много вариантов:
— счётчик денормализуется и храниться в посте, минус — новые посты будут часто менятся и стираться из кеша.
— счётчик будет получаться для каждого поста на странице отдельным запросом

select count(*) from comment where post_id = <post_id>;


такие запросы будут инвалидироваться только тогда когда надо, сами посты будут инвалидироваться независимо, т.е. значительно реже, чем в первом случае. Минус много запросов, но если они, как правило, будут браться из кеша, то это нормально.
— вариация на тему, считать комментарии сразу для всех постов на странице:

select post_id, count(*) from comment 
where post_id in (<post_id1>, <post_id2>, ...) group by 1;


Минусы — такие запросы будут чаще инвалидироваться, чем в предыдущем варианте, более сложная реализация и промахи при изменении списка постов на странице.

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

К вопросу об инвалидации кеша

Грубо говоря, инвалидатор — что-то, что инвалидирует, или помогает инвалидировать.

Я инвалидаторами называю структуры {условие на модель} -> {список ключей, которые нужно сбросить при выполнении условия}, описанные в статье.

К вопросу об инвалидации кеша

Данные выдаются из кеша в том же виде, что выдаёт ORM в том случае если кеш не используется, таким образом кеширование прозрачно для пользователя ORM-а, ему собственно всё равно откуда пришли данные из кеши или из базы. Обычно это модели или списки моделей, но могут быть и словари/хеши/просто списки.

Кешируется то, что запрашивается, т.е. если вы пользователь ORM-а запрашивает всё сразу, то и в кеш ляжет 100000 записей, если постранично, то будет ложиться отдельными блоками с одними и теми же инвалидаторами, ну и в случае чего сброшены будут все вместе.

К вопросу об инвалидации кеша

Для краткости буду обозначать запросы q1,...,q6.

Очевидно, q1 должен инвалидироваться при любом изменении в таблице, ему будет соответствовать инвалидатор с пустой схемой (схема — список полей). q2 и q3 содержат join-ы, как их обрабатывать я в статье не упоминал. Можно огрод городить, но на данный момент я просто игнорирую условия на приджойненные таблицы, т.е. такие запросы могут инвалидироваться чаще, чем необходимо. q4,q5,q6 — запросы с простым условием равенства поля, как раз то, с чем описанная система справляется лучше всего.

Вот набор инвалидаторов, который формируется после выполнения q1-q6:

"": -- (пустая схема)
    q1, q3
user_id = ?:
    1: q2
status = ?:
    "rejected": q4
    "new": q5
    "accepted": q6


Теперь происходит обновление строки, при обновлении важны все колонки, а не только те, которые меняются, причём необходимо знать и старое и новое состояния объекта/ряда. Приходиться перед update-ом и delete-ом выбирать ряд, за всё приходится платить (впрочем ORM может делать это и так, чтобы удалять/обновлять зависимые объекты, например).

Итак мы выбираем объект

{id: 105, user_id: 2, title: "old title", status: "new", time_added: "..."}

и обновляем его до

{id: 105, user_id: 2, title: "new title", status: "accepted", time_added: "..."}

Подставляем старый объект в схемы, получаем "", user_id=2, status="new", подставляем новый, получаем "", user_id=2, status="accepted". Собирая всё вместе, видим что надо сбросить q1,q3,q5 и q6.

К вопросу об инвалидации кеша

Видимо, неправильно, потому как не надо. Напишите свой пример в терминах sql и я напишу как он будет инвалидироваться.

Основы и заблуждения насчет JavaScript

Это не заморочка, это как раз простейший вариант прототипного наследования. Заморочки с конструкторами и new как раз выглядят странно на фоне такой стройной концепции. Начало статьи страдает от этого — пример с дедом, отцом и сыном непонятен и не совсем верен.

> И вдруг Дед решил: «надоело мне ходить зеленым — хочу стать сними», смутировал (изменил прототип своего класса)
Какого класса? В js нет классов. И, вообще, мы тут про прототипное наследование говорим, вроде )

Стройно так — дед меняет себя и так как он прототип отца, а отец прототип сына, то эти двое тоже меняются и т.д.

Основы и заблуждения насчет JavaScript

Прототип объекта — это тот объект, от которого он наследуется.
F.prototype — не прототип F, прототип F — Function.prototype. Прототип (new F) — F.prototype.
Правда, запутанно?

Основы и заблуждения насчет JavaScript

И ещё, особо смущающая вещь:

function F(){}
F.prototype = {x: 1}; // прототип F здесь не присваивается


Вторая строчка не присваивает прототип объекта F (функции). Она означает какой прототип будет у объектов созданных с помощью new F().

Основы и заблуждения насчет JavaScript

Автору стоило бы начать с того или хотя бы упомянуть, что в Javascript-е есть и чистое прототипное наследование без конструкторов:

a = {x: 1}
b = Object.create(a) // a.x === 1, b.x === 1
a.x = 2              // a.x === 2, b.x === 2
b.x = 3              // a.x === 2, b.x === 3
c = Object.create(b) // a.x === 2, b.x === 3, c.x === 3
// c.__proto__ == b, b.__proto__ = a, a.__proto__ = Object.prototype

После этого видно, что конструкторы костыль

Основы и заблуждения насчет JavaScript

Потому что, создатели Javascript-а недостаточно смелы были, чтоб оставить чистое прототипное наследование и добавили классоподобие.

Минус на минус дает…

Всем кто так ратует за prepared statements стоит ознакомиться с тем как Postgre планирует запросы, а он в этом довольно хитёр и использует статистическую информацию о распределении значений в колонках таблиц, чтобы составить лучший план. При использовании prepared statements конкретные значения параметров недоступны и поэтому план может быть не лучшим, что в итоге будет приводить к худшей производительности, чем просто серия обычных строковых команд.

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

Nginx + uWSGI + Django, один из вариантов запуска

можно сделать

cd /usr/local/etc/rc.d
perl -pe 's/(["{ ])uwsgi/$1your_project/g' uwsgi > your_project
chmod +x your_project

и скрипт готов

Nginx + uWSGI + Django, один из вариантов запуска

Можно

Пора завязывать использовать символы табуляции в коде

Код читается много чаще, чем пишется. Поэтому это стоит того.

Пора завязывать использовать символы табуляции в коде

Дело не только терминале и точно не в мониторе. Просто, длинные строчки плохо читаются.

Пора завязывать использовать символы табуляции в коде

В данном случае надо использовать пробелы в любом случае, иначе при изменении размера таба всё поплывёт. Так что пример неудачный.

Django — обработка ошибок в ajax-формах

Ну да, где ajax, там и JSON. Просто как удобный формат передачи. Но, во-первых, кастомная вёрстка, следовательно не подходит общий метод показа ошибок, плюс для простеньких форм, джанго форма тоже излишня, можно просто вьюху написать, так будет и короче и логичнее (ни к чему лишние сущности). И, таким образом, ничего не остаётся из вашей статьи.

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