В мире python существует довольно много различных приложений "супервизоров" предназначенных для запуска веб-приложений: uWSGI, gunicorn, gevent, twisted web и т.д. Однако, пожалуй, наиболее производительным и гибким супервизором является uWSGI. В этом посте я расскажу как запустить ваше Flask приложение под uWSGI. Конечно же, настроим nginx для проксирования запросов и отдачи статического контента.

Однажды, работая с git репозиторием вы можете случайно отправить (закомитить) в репозиторий свои личные логины, пароли или SSH ключи. Конечно, с помощью git rm можно удалить файл, но файл так же будет присутствовать в истории. К счастью есть утилиты которые позволяют удалить файл из git репозитория полностью. В это статье описано как использовать BFG Repo-Cleaner и git-filter-branch для полного удаления файла из git репозитория.

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

Сколько лет пишу на django, и только недавно внезапно обнаружил, что у неё оказывается есть встроенные стредства для дампа и последующего восстановления схемы базы данных. Это бывает довольно полезно, когда надо по быстрому кому-то передать дамп с тестовыми данными чтобы воспроизвести проблему, или просто передать фикстуры.

Я люблю статические блогие и веб-сайты. Они простые и быстрые, но это все таки простые статические страницы. Если с комментариями все довольно просто, и можно использовать disqus, то с формой обратной связи все несколько сложнее. К счастью и в этом случае можно обойтись без полноценного сервера.

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

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

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

Для тех, кто не знаком с Flask - это небольшой фреймворк написанный на языке python c весьма большим сообществом, и множеством модулей на все случаи жизни. В отличии от, скажем, Django, Flask не навязывает определенное решение той или иной задачи. Вместо этого, он предлагает использовать различные сторонние или собственные решения по вашему усмотрению. Я ни в коем случае не хочу сказать, что Django плохой фреймворк. Просто в некоторых случаях Django вынуждает писать много лишнего кода попутно залезая все глубже и глубже во внутренности самого фреймворка. Так что flask - это лишь ещё один инструмент, подходящий под определенные задачи.

Disclaimer: в этой статье нет ничего принципиально нового и неизвестного. Все это общеизвестные практики, только собранные в одном месте. Эта статья ориентирована в основном на тех, кто не знаком с flask и новичков.

pg_dump - это утилита позволяющая делать бэкап базы данных из postgresql. Она сохраняет в файл набор SQL команд которые полностью воссоздают структуру исходной базы данных. Для последующего восстановления из подобного файла достаточно psql которая почти всегда идет в комплекте с самим postgresql.

С помощью pg_dump, вы можете сделать бэкап базы данных в текущий момент времени, и в дальнейшнейм развернуть его без каких либо проблем. Для тех, кто раньше работал с mysql, pg_dump может показаться весьма знакомым. С mysql в поставке идет аналогичная утилита под названием mysqldump.

В этой небольшой статье мы рассмотрим несколько полезных примеров использования pg_dump.

Как я уже писал, недавно я переехал с Wordpress на статический генератор блогов Pelican. Так как обработку комментариев на стороне сервера сделать нельзя, я перенес все комментарии в disqus. На старом блоге в боковом меню у меня отображались последние комментарии, и я хотел чтобы после переезда на новую блог платформу они сохранились. К счастью, у disqus есть API с помощью которого можно это реализовать.

Довольно давно я хотел перевести этот блог на самописный движок. Я даже написал несколько на Django и на flask, но не один из них так и не довел до конца ввиду отсутствия времени, и более приоритетных задач. Со временем я, разумется, понял что занятие это совершенно бессмысленное, и решил оставить Wordpress. И все даже было относительно хорошо, и я мирился с его задумчивостью, разного рода глюками и багами, пока после очередного обновления Wordpress страницы не начали генерироваться в среднем по 5 секунд. Я даже не стал разбираться в чем дело. За то временя сколько я использую Wordpress, мне столько раз нужно было что-то поправлять в нем, что я уже сбился со счета, и мне это порядком надоело. В общем, я решил что пора переходить на какую-то другую платформу.

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

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

Вот далеко не полный список преимуществ которые предоставляют статические генераторы блогов:

• Производительность - быстрее, чем отдача статического контента уже не может быть ничего;
• Дешевая масштабируемость - за пару минут блог размещается на Amazon S3 и стоить это будет считанные центы. Если ссылка на какую либо запись окажется на хабре, то S3 с легкостью выдержит такую нагрузку и стоить это будет все те же копейки;
• Легко найти где разместить блог - не обязательно держать отдельный сервер ради блога. Можно разместить на Github pages, Amazon S3 или даже в Dropbox;
• Безопасность - нет риска взлома блога. Собственно и ломать то нечего. Не нужно следить за обновлениями, за новыми дырами в безопасности популярных блог платформ;

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

Из статических блог-платформ сейчас наиболее популярная - Jekyll, но его я сразу отмел так как Ruby мне не очень по душе. Я довольно неплохо знаю Python, поэтому начал искать статические блог-платформы на нем, и, в итоге, остановился на Pelican.