Указано число человек (хостов) в день, а не число запросов (хитов), а учитывая, что это социальная сеть число запросов смело можно увеличивать на порядки
Смотря что иметь в виду под изучением. Бегло ознакомиться, как реализуются «кроссязыковые» конструкции (ветвления, циклы, описания классов и т. п. ) желательно, конечно, изучить сначала. А вот вникать в различия списков и кортежей, в тонкости реализации итераторов и генераторов, изучать все стандартные библиотеки и т. д. совсем не обязательно чтобы запустить сайт на джанго.
Написал много абзацев в ответ на «или вы порицаете..?», но стёр. Их смысл был в том, что по ссылке должны переходить читатели материалов/статей/комментов, а использование ссылок для наращивания «ссылочного» является: а) не этичным; б) нарушением соглашений и правил тех поисковых систем (гугл и яндекс), с которыми (соглашениями/правилами) я имел честь ознакомиться.
Как-то не думал об использовании хабра в такой струе, максимум как об источнике естественных (то есть лично кликающих по ссылкам) посетителей. Теперь, после вашего вопроса, на наиболее вопиющие (лично по моему мнению, без всяких формальных критериев) случаи использования ссылок для наращивания «тИЦ», или «PR», или ещё чего, буду писать абузы гуглу и яндексу. Остальные «сеошники» на хабре, которые использовали «изобретенный» вами приём ( но не обращая на него мое внимание), будут, надеюсь, вам благодарны за это.
Шаред-хостинги разные бывают, на некоторых тысячу уников и без всяких ООП не зайдут. если хостер раньше акк не заблокирует. А на некоторых и ddos незаметно пройдёт
LAMP без всякой оптимизации (дефолтные для debian настройки апача, мускула, пехепе, без акселераторов и прочих кешов) с не самой легкой PHP CMS (в дебаг конфиге — с отключенным кешированием и полным логгированием) на 200 Мб обрабатывает 1,5 запроса в секунду (по ab ). Тюнингом (lighttpd/nginx, fastcgi php c xcache, файловое кеширование в CMS и т. п.) думаю можно значительно ускорить, чего для тестирования вполне достаточно.
По времени разработки, по-моему, проще реализовать из двух таблиц:
article:
id:…
current_version_id:…
… #не версионнируемые поля
article_version:
id:…
article_id:…
timestamp:…
title:…
body:…
… #другие версионнируемые поля
По крайней мере не надо думать о получении неуникального id, а довериться СУБД
Вообще, по-моему, минимальное время разработки получается при полной нормализации БД, а денормализация (или не до конца доведённая нормализация) это уже оптимизация других параметров (или раздолбайство :) )
Пробовал в файерфоксе использовать «всегда открывать ссылки в новой вкладке», оказалось, что намного чаще нужно оставаться в одной вкладке/окне, чем открывать новое. Решил что проще принудительно все ссылки в том же вкладке открывать по умолчанию, а в новой по колесу, с контролом или через меню, не полагаясь на мнение разработчиков сайта
Пробовал через конфиги, но что-то не срослось с копипастом «абстрактного» примера из доков. Плюс очень, имхо, нечитабельно: простому CRUD контроллеру нужно 7 url'ов (если исходить из принципа «одно реальное действие — один метод Action»), 3 из которых с параметром id/slug/… 30+ длинных строк на один контроллер, да ещё все в одном глобальном .ini файле (вроде можно делать что-то вроде инклуда, но это опять разбираться надо где и как) — поддерживать такие конструкции, имхо, тяжеловато, в коде пускай строк не меньше, но куда читабельней
Мне, когда гуглил про роутинг, как-то попадались, как потом оказалось, примеры к старым версиям, то есть механику роутера я понял по этим статьям, но вот как её запустить… Сейчас вот дебагером ползаю по цепочке index.php -> вызов действия, чтобы найти лучшее место для работы с get/post параметрами, модифицирующими тело запроса до его прихода в контроллер.
Спасибо, кстати, за ссылку на туторил — сижу читаю
rewrite ^/(.*)$ http:// www.$domain/$1 permanent; #(тут пробел убрать между // и www)
server_name ~^www\.(?<domain>\w\.\w\.\w)$;