Продвигаете страницу в поиске, вкладываете деньги, ждете несколько месяцев — и (в идеале) выходите на первую страницу. Казалось бы, жизнь удалась. Но посетителей не так много, как хотелось бы. А все дело в колдунщике, который завис на нулевой позиции и забирает ваш трафик.

Невольно хочется сказать: «Zed SEO is dead, baby». Но рано опускать руки. Не получается побороть — возглавьте. Рассказываем, как занять свое место на позиции №0 и перестать делиться трафиком с конкурентами.

Обмен версиями

Обмен ключами

Andrew Godwin опубликовал DEP 0009: Async-capable Django 9 мая, а 21 июля он был принят техническим советом Django, так что можно надеяться, что к выходу Django 3.0 успеют сделать что-нибудь интересное. Он уже упоминался где-то в комментариях Хабра, но я решил донести эту новость до более широкой аудитории путём его перевода — в первую очередь для тех, кто, как и я, не особо следит за новостями Django.

Асинхронный Python разрабатывался много лет, и в экосистеме Django мы экспериментировали с ним в Channels с ориентацией в первую очередь на поддержку вебсокетов.

По мере развития экосистемы стало очевидно, что, хотя нет насущной необходимости расширять Django для поддержки отличных от HTTP протоколов, таких как вебсокеты, поддержка асинхронности даст много преимуществ для традиционной model-view-template структуры Django.

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

Переменные окружения для Python проектов

При разработки web-приложения или бота мы часто имеем дело с какой-либо секретной информацией, различными токенами и паролями (API-ключами, секретами веб-форм). "Хардкодить" эту информацию, а тем более сохранять в публично доступной системе контроля версий это очень плохая идея.

# Плохая практика. Не делай так.
API_KEY = 'very_secret_password'

Конфигурационные файлы

Самый простой путь решения данной проблемы, это создание отдельного конфигурационного файла со всей чувствительной информацией и добавление его в .gitignore. Минус такого подхода в том, что в гит нужно держать ещё и шаблон конфигурационного файла и не забывать его периодически обновлять.

# Уже лучше.
from config import API_KEY
app = Flask(__name__)
app.config['API_KEY'] = API_KEY

Переменные окружения

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

$ export FLASK_APP=hello.py
$ flask run
 * Running on http://127.0.0.1:5000/

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

Когда я начинал изучать автоматизацию тестирования, не мог понять — “что такое Page Object и как его реализовать на Python + pytest?”. Штудируя интернет, нашел реализацию на других языках и фреймворках: обучающие статьи, которые были непонятны для меня. Поэтому решил написать этот разбор. Идея — показать реализацию на Python + pytest и объяснить ее доступным языком.

Что такое Page Object

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

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

Почему двенадцать?

Если вы посмотрите на клавиатуру, то увидите, что в каждой октаве содержится 12 полутонов.
В случае фортепиано это всего лишь значит, что между, например, "до" первой октавы и "до" второй октавы расположено 11 клавиш. Вместе с одним из "до" (например, до второй октавы) мы получим 12 клавиш: до#, ре, ре#, ми, фа, фа#, соль, соль#, ля, ля#, си, до.

Но почему 12?

Может быть это просто случайность? Вот нравилось нашим предкам число 12, у них везде 12: 12 месяцев, 12 знаков зодиака, 12 колен Израилевых, 12 апостолов,… и здесь решили, пусть будет 12, и так и повелось. Или все же здесь есть объективный закон, и это число не случайно?

В этой статье я попытаюсь продемонстрировать, что это не случайность. Достаточно общие требования, вполне естественные для современной (западной) музыки, с математической необходимостью приводят нас к числу 12. Интересно, что причиной почему у нас появляется это значение является свойство другого числа (см. в конце статьи). Можно даже сказать, что оно то и лежит в основе современного звучания.

Описание атаки

7 октября 2019 года директор отдела исследований PortSwigger (производителя BurpSuite) опубликовал исследование о новых подходах к HTTP Request smuggling. С их помощью он заработал на bugbounty около $70000. В этой заметке мы коротко выясним суть атаки, инструментарий, а также методики исследования веб серверов, подверженных этой уязвимости.