Накопилось несколько маленьких заметок/советов про python и django, которые на отдельные топики не тянут, поэтому публикую все сразу.

Под катом:

• как упростить код вьюх ровно в 2 раза
• легкий способ рисования графиков
• почему Ian Bicking воскликнул «Cool!»
• приложения для ВКонтакте на django за 5 минут
• хорош ли pymorphy?
• пара фишек насчет выкладки пакетов на pypi
• что общего между декораторами и with-контекст-менеджерами
• принимаем оплату на django-сайтах
• показываем Яндекс.Карту для заданного адреса

Эта статья — частичный перевод одной интересной статьи с sqlite.org, в которой подробно рассматривается реализация транзакций в SQLite. На самом деле я очень редко работаю с SQLite, но тем не менее мне очень понравилось это чтиво. Поэтому если хотите просто развить кругозор — будет интересно почитать. Первые две секции не включены в перевод, так как там нет ничего интересного, да и мне лень их набивать (пост и так огромный).

3.0 Однофайловый коммит

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

3.1 Начальное состояние

Состояние системы, когда соединение с БД только что было поднято, поверхностно изображено на рисунке справа. Справа показана информация, которая хранится на энерго-независимом носителе. Каждый прямоугольник — это сектор. Синий цвет говорит о том, что этот сектор содержит оригинальные данные. Посередине изображён дисковый кеш операционной системы. В самом начале нашего примера кеш холодный, это изображено белым цветом. На левой части рисунка — содержимое оперативной памяти процесса, который использует SQLite. Соединение с БД только что было открыто, и никакой информации прочитано не было.

Мы в Alconost предоставляем услуги создания и ведения контекстной рекламы и, по долгу службы, иногда занимаемся разработкой посадочных страниц (landing pages). Мы были очень рады найти и перевести статью, в которой автор изложил все требования, которым такая страница должна соответствовать. Но есть в этой статье и большой минус. Пунктов аж 50, каждый можно отметить в чеклисте, но после доступен лишь результат в баллах, которым можно разве что похвастаться перед друзьями.

Мы против таких способов анализа информации. Потому каждый желающий может скачать подготовленную нами гуглотаблицу, ответить на вопросы “Да” или ”Нет”, отфильтровать ответы и получить результат и план действий.

Те, кому в гуглотаблицу не хочется, просим под кат. Там перевод.

Очень многие выбирают Django за его простоту. Код на Django прост и лаконичен, мы меньше думаем о костылях и больше о бизнес-логике.

Gevent тоже выбирают из-за того, что он простой, очень шустрый и не несёт за собой callback hell.

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

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



То что вы делаете, называется интеграционным тестированием. Современные приложения достаточно сложны и содержат множество зависимостей. Интеграционное тестирование проверяет, что несколько компонентов системы работают вместе правильно.

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Решил все-таки написать статью про SQLite, в которой хочу обобщить свой 3-х летний опыт использования этой БД под Windows. Вижу, что тема популярная, но информации мало.

Часть 2
Часть 3

Небольшая вводная.

Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка в SQLite и ответов на них (поскольку информации очень много и так хоть немного проще ее структурировать).

Часть 1
Часть 3

В этой части будут затронуты непростые вопросы использования SQLite через работу с его программным интерфейсом (API).

Первая часть — вводная.
Вторая часть — быстрый старт.

Третья часть — тонкости и особенности.

Как известно, в Django предусмотрен очень лёгкий и простой механизм уведомления разработчиков о возникающих проблемах. Когда проект развёрнут на локальном компьютере и в настройках DEBUG имеет значение True, то отчёты об ошибках просто выводятся в виде HTTP-ответа, в виде удобной страницы с возможностью копирования traceback'а.

Если же это production-сервер, и DEBUG имеет значение False, то отчёты по умолчанию отправляются по электронной почте всем, кто указан в настройке ADMINS (кстати, если вы используете SMTP-сервер, то письма могут не приходить, так как SMTP-сервер не принимает адрес root@localhost — в этом случае просто укажите любой другой адрес, который будет принимать ваш SMTP-сервер, с помощью настройки SERVER_EMAIL).

Разумеется, ничего не мешает также написать свой logging handler (обработчик журналирования) и сохранять отчёты об ошибках в любом нужном виде — создавать задачу в баг-трекере, например.

Тем не менее, если для вас важна безопасность ваших пользователей, то возникает вполне закономерный вопрос — как сделать так, чтобы отчёты об ошибках были для них безопасны? То есть как сделать, чтобы никакая личная информация в них не сохранялась, и не отправлялась кому-либо по почте (ведь дело даже не в том, что кто-то из разработчиков может вести себя недобросовестно, а скорее в том, что подобную информацию вообще лучше не сохранять где-либо за пределами сервера — ведь почтовый ящик и взломать могут, а сервер обычно защищён лучше).

Несколько лет назад я начал преподавать свой любимый язык python школьникам. И возникла такая задача: рассказать про объектную модель, но что бы это было не скучно и как можно нагляднее. И тут меня не сразу, но осенило — пчёлы!

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

Вебсокеты — это прогрессивный стандарт полнодуплексной (двусторонней) связи с сервером по TCP-соединению, совместимый с HTTP. Он позволяет организовывать живой обмен сообщениями между браузером и веб-сервером в реальном времени, причем совершенно иным способом, нежели привычная схема «запрос URL — ответ». Когда два года назад я присматривался к этому стандарту, он был еще в зачаточном состоянии. Существовал лишь неутвержденный набросок черновика и экспериментальная поддержка некоторыми браузерами и веб-серверами, причем в Файрфоксе он был по умолчанию отключен из-за проблем с безопасностью. Однако теперь ситуация изменилась. Стандарт приобрел несколько ревизий (в том числе без обратной совместимости), получил статус RFC (6455) и избавился от детских болезней. Во всех современных браузерах, включая IE10, заявлена поддержка одной из версий протокола, и есть вполне готовые к промышленному использованию веб-серверы.

Я решил, что настало время попробовать это на живом проекте. И теперь делюсь, что из этого вышло.

В этой статье я расскажу о внутреннем устройстве популярного сервиса облачного хранения Dropbox. В частности, будет затронуто устройство протокола Dropbox, а также показана статистика его использования в некоторых странах Европы. Кроме этого, я сравню его с другими сервисами, такими как iCloud, Google Drive и SkyDrive.

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

Текст основан на научной статье “Dropbox изнутри: Изучаем сервисы облачного хранения” (Inside Dropbox: Understanding Personal Cloud Storage Services). PDF

Привет всем!
Я учу английский и всячески упрощаю этот процесс. Как-то мне потребовалось получить список слов вместе с переводом и транскрипцией для определенного текста. Задача не была сложной, и я принялась за дело. Чуть позднее был написан скрипт на python, все это умеющий, и даже умеющий чуть больше, поскольку мне захотелось получить еще и частотный словарь из всех файлов с английским текстом внутри. Так вышел маленький набор скриптов, о котором я и хотела бы рассказать.
Работа скрипта заключается в распарсивании файлов, выделении английских слов, нормализации их, подсчете и выдачи первыx countWord слов из всего получившегося списка английских слов.
В итоговом файле слово записывается в виде:
[число повторений] [само слово] [перевод слова]

О чем будет дальше:

1. Мы начнем с получения списка английских слов из файла (используя регулярные выражения);
2. Дальше начнем нормализовывать слова, то есть приводить их с естественной формы в тот вид, в котором они хранятся в словарях (тут мы немного изучим формат WordNet);
3. Затем мы подсчитаем количество вхождений у всех нормализованных слов (это быстро и просто);
4. Дальше мы углубимся в формат StarDict, потому что именно с помощью него получим переводы и транскрипцию.
5. Ну и в самом конце мы куда-нибудь запишем результат (я выбрала файл формата Excel).

Здравствуйте.

В предыдущей статье, мы познакомились с настройкой связки nginx + apache в режиме хостинга и репозиториями dotdeb.
В этой статье мы познакомимся с настройкой backend: PHP, MySQL.

В части PHP мы познакомимся со следующими темами:
— общая настройка PHP
— правильная настройка PHP + Postfix для отправки писем через внутренний SMTP сервер посредством функции mail(),
— настройка кеширования кода и/или данных на основе APC.

В части MySQL я попробую раскрыть базовые моменты повышения производительности, ибо по умолчанию сервер MySQL настроен очень не эффективно.

Кто заинтересовался, добро пожаловать под кат

— документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++ и распространяется в рамках лицензии Creative Commons.

В последнее время становится довольно популярной и восстребованой. И вот возникла идея использовать ее в связке с фреймворком Django. Собственно о чем далее и пойдет речь.

Оптимизация настроек всегда дело тонкое и выставить именно те параметры, которые дадут максимальную производительность, зачастую можно только уже в процессе работы приложения, когда уже есть статистика нагрузки и видны узкие места.
Но очень полезно сделать и первичную оптимизацию при запуске СУБД. В этом посте рассмотрены пути автоматической оптимизации MySQL и PostgreSQL утилитами mysqltuner и pgtune.

Недавно я запустил сайт backgrounddating.com и написал об этом здесь, на Хабрахабре. Разумеется, я уже тогда рассказал о некоторых технических деталях реализации этого проекта, но об одной из возможностей сайта я бы хотел написать отдельно, тем более, что документации (как на русском, так и на английском) на эту тему в Интернете пока что довольно мало. Итак, речь пойдёт о чате в реальном времени между двумя пользователями. Задача состоит в том, чтобы любой пользователь мог отправлять другим пользователям сообщения, и, если у получателя сообщения открыт чат с этим пользователям, то он сразу же видел входящие сообщения (а в ином случае он мог прочитать сообщения позже: то есть при открытии чата загружается история последних сообщений).

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

Сразу уточню, что это не единственный способ реализовать подобное. Вы можете использовать другой асинхронный веб-сервер (например node.js), можете использовать другую очередь сообщений (или вообще её не использовать, если вам подходят особенности такого варианта: с пользователями одного канала обязательно общается один и тот же worker веб-сервера). Я даже не утверждаю, что этот вариант самый лучший (но в данном случае он подошёл лучше всех). В конце концов, мы здесь вообще не будем рассматривать костыли (long polling, Flash) для старых браузеров (а это почти все версии IE, например), не поддерживающих веб-сокеты, и даже не будем рассматривать возможность подключаться из тех браузеров, которые уже поддерживают протокол WebSocket, но не стандартизированную версию (RFC 6455), а одну из устаревших. О том, как можно включить поддержку устаревшей версии «draft 76» (она же «hixie-76»), смотрите в документации Tornado.

Добрый день. Постараюсь рассказать о сложных формах в Django. Все началось, когда в моем дипломе понадобилось сделать форму, которая состояла бы из других форм. Ведь если у вас есть две формы, которые вы используете, и тут понадобилась другая, которая является просто контейнером тех двух, вы же не будете создавать новую, копируя в неё все поля из старых, это очень тупо. Поэтому надо как-то их объединить. В свое время было FormWizard в Django, но он был крайне не удобным так что в новой версии её переделали на WizardView. Django конечно MVC, но я в статье все как можно детально постараюсь продемонстрировать, а потом уже можно все сжать используя ModelForm и циклы в шаблонах.
Поглядим на наши модели, ничего особенного, но чтобы было понятней, продемонстрируем.

Недавно встала задача дать пользователям удобный инструмент редактирования данных. Хотелось, чтобы пользователи сразу видели результат и не прыгали между несколькими страницами для редактирования и просмотра. Немного погуглив, нашли отличное приложение django-inplaceedit, которое позволяет реализовать наглядное редактирование данных.