Как я взломал 40 сайтов за 7 минут (перевод)

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

FizzBuzz, или почему программисты не умеют программировать

неудержался чтобы не откапать мамонта в истори

for i in ("FizzBuzz" if i % 3 + i % 5 == 0 else "Fizz" if i % 3 == 0 else "Buzz" if i % 5 == 0 else i for i in xrange(100)):
    print i

Django-orm в поисках LEFT JOIN

Да, сигнатура была изменена, но точно не скажу в какой версии.

Django-orm в поисках LEFT JOIN

upd: ошибочка вышла в локальном примере. будет 9 запросов. 1 основной, 4 на получение id переводов и 4 на получение самих переводов.
было: Page.objects.filter(id=1).prefetch_related('content', 'title', 'description', 'keywords').first()
стало: Page.objects.filter(id=1).prefetch_related('content__translations', 'title__translations', 'description__translations', 'keywords__translations').first(), что равносильно 1му варианту только без отложенной разгузки.

Django-orm в поисках LEFT JOIN

prefetch_related даст нехилую нагрузку на бд как по количеству запросов к бд так и по объему самих данных.
Работает он предельно просто: сначала выполняется основной запрос, а потом на уровне питон кода для всех RelatedObjects генерит новый запрос на выборку всех связанных объектов. В случае с моделью Page описанной в статье получается 5 запросов к бд. 1 на выборку самой Page и еще 4 на получение Translations для каждого переводимого поля. Теперь представим что в этих полям мы храним «оч.многобуквенные» данные для большого количества языков. Лично я бы предпочел множество запросов с меньшим объемом возвращаемых данных (может и зря)
page.filed.translations.filter(lng='ru').first()