В сети часто возникают разговоры на тему «Python best IDE — does it really exist?». Для примера — недавний Q&A в группе Python community на LinkedIn (к сожалению, просмотр возможен только для пользователей группы). Если вкратце, то мир вертится вокруг:

• Eclipse + PyDev — похоже, что самое популярное из свободных решений.
• Komodo IDE — по отзывам отличное средство, но не free.
• WingIDE — лучший autocompletion для Python, но опять-таки non-free.
• Eric — IDE на Qt и QScintilla, пробовал только на Windows, видно недопробовал — показалась неудобной. Если у кого есть полезная информация и ссылки — поделитесь, пожалуйста, в комментариях.
• NetBeans 6.5 — готовится к выходу встроенная поддержка Python в этой IDE версии 6.5, ждем с нетерпением!
• Vim — для фанатов Vim ничего лучше быть, понятно, не может — после обработки напильником, правда.
• Emacs — аналогично Vim — для пользователей, которые много времени проводят в Emacs, он дает лучший user-experience при разработке на любом языке.

Если первые четыре решения предоставляют IDE для Python прямо из коробки, то последние два требуют определенных настроек. Для Vim не знаю, но для Emacs надо потратить не меньше 6 часов поисков по интернету и экспериментов перед тем как будет получена удобная и (очень) функциональная среда для Python.

Что до меня, то весьма долгое время я работал с Eclipse + PyDev — вполне работоспособное решение. Но после окончательного переезда с Windows в Ubuntu (всем ставить шрифты Liberation в Убунте!), я решил таки завершить начатое уже давно — начать использовать Emacs не только как GTD-органайзер, IRC-клиент и редактор «когда не хочется запускать Eclipse».

История данных шести часов под хабракатом (история предполагает, что читающие хоть немного знакомы с Emacs и Python, а также носит Ubuntu(Debian)-specific оттенок, когда дело касается установки пакетов).

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

Кто-то освежит память, кто-то сверится как с чек-листом, а кто-то заинтересуется и прочтет книгу. Т.к. пост получился достаточно объемным, можно добавить его в закладки и периодически к нему возвращаться.

Это шпаргалка раскрывающая раздел «Интеграция Selenium тестов» статьи Настройка Jenkins для django проекта с нуля. А именно как запускать Selenium тесты на удалённом сервере Jenkins у которого нет монитора и форточек.

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

Я уже некоторое время ковыряю TDD и задача постоянного контроля качества для меня становится всё актуальней. Особенно при пополнении команды новыми разработчиками.

Сначала я запускал тесты руками: save, switch, $ nosetests. Потом к тестам добавились проверялки качества кода и пришлось всё засунуть в скрипт:
pyflakes *.py
pep8 *.py
pylint *.py
nosetests

Скрипт запускать каждый раз ужасно лениво, поэтому небольшая оболочка на inotifywait стала запускать тесты и проверки после каждого сохранения:
while true; do
inotifywait -e modify project/*.py -qq; clear
./do_tests
done

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

Кроме того довольно тяжело следить за коллегами, которые тоже могут что-то сделать и забыть прогнать тесты, в результате в репозитории лежит битый код, не прошедший code review и при очередном pull может внезапно начаться clusterfuck.

И тут очень вовремя kmmbvnr@lj выпустил скринкаст, в котором он демонстрировал интеграцию тестирования для django-проектов с сабжем Jenkins (бывш. Hudson). Посмотрел я на все эти красоты, графики и отчёты и тоже захотел чтобы всё само пело и играло. Но у него django-jenkins, как и следует из названия, встраивается в джангу и генерит отчёты используя хитрую систему. Мой проект до джанги не дорос и скорее всего не дорастёт — это достаточно тривиальное WSGI-приложение, которое правда стремительно разрастается. Пришлось поднимать всё с нуля.

Воскресенье я на это убил, но в целом всё довольно прямолинейно и теперь у меня есть симпатичные отчёты:



Что внутри?

Всем привет.

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

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

В качестве новой системы был выбран Jenkins, о его установке и настройке для django-проекта и пойдет речь в этой статье. Кто заинтересовался, добро пожаловать под кат.

Основное средство общения в нашей компании — это шашлыки чат Skype. Статус «в сети» означает присутствие на рабочем месте. Иногда ждёшь кого-то, начальству не напишешь «зайди плиз срочно» — в общем, уведомление о появлении в сети определённого человека было бы полезно.

В Skype для Linux нет такой «галочки» для отдельных контактов (думаю, что и пользователи других ОС с этим знакомы). Зато есть неоспоримое преимущество — почти безграничные возможности командной строки:

Прежде всего, хочу сказать, что я читал на хабре много топиков о развертывании радио, но ни один не дал мне исчерпывающей информации.
Я решил все сделать сам. Это не какой-то проект или стартап, а просто just4fun. Возможно, это покажется полезным для вас.
Итак, я использовал только свободное ПО в развертывании радио-стрима, так что пользователи window$ и ma o$ могут дальше не читать ;). Хотя нет, все же прочитайте, возможно это откроет вам GNU/Linux с новой стороны.

Вот казалось бы сейчас, как никогда должна быть масса крутых IDE для разработки на Django. И они есть — взять хотя бы PyCharm или PyDev. Но мне они никогда не нравились. Я всю свою карьеру Python-разработчика пользовался SciTE + Scintilllua (вот мой конфиг, если кому нужен) и был вполне доволен. Но черт меня дернул попробовать VIM с Emacs и я уже не смог вернуться на SciTE. Нет, это отличный редактор, но большую часть работы я пишу код и уже не могу представить, как можно было работать в текстовом редакторе с мышкой или каждый раз тянуть руку к стрелкам, чтобы перейти на новую строку, а потом к End, чтобы перейти в конец строки. Оставалось мне только по-минимуму настроить свой VIM для удобной разработки на Django.

Вступление

Здравствуйте, уважаемые читатели! Для многих джанго-разработчиков не секрет, что с версии 1.3+ вместо используемых ранее generic views нам необходимо начинать использовать class based views. А с 1.4+ версии generic views вообще могут стать deprecated. Информация про class based views (далее CBV) в интернете довольно скупа (а в рунете и подавно). Нет, конечно есть превосходные статьи, в том числе тут на хабре. Одна из статей была опубликована буквально на днях. Но я отношусь к той категории людей, что привыкли все изучать на практике и данный топик написан для таких же людей.
В качестве практического задания мной был выбран классический вариант — создание блога. Для того, чтобы использовать возможности CBV по максимуму мы немного усложним задачу. Пусть это будет не просто блог, а блог, с возможностью публиковать приватные статьи, недоступные неавторизованным пользователям.
Дальнейшие рассуждения подразумевают, что читатель ознакомлен с фреймворком Django и имеет навыки в создании проектов.

Признак того, что объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция».

Каждый раз когда из написанного класса вы создаёте всего один экземпляр, используете только раз и тут же выбрасываете, следует думать: «ой, надо бы это отрефакторить! Можно сделать проще, намного проще!»

Перевод доклада Джэка Дидриха, одного из ключевых разработчиков языка Питон. Доклад прозвучал 9 марта 2012 на конференции PyCon US.

Приветствую всех.

Недавно наш хабраколлега опубликовал интересную статью об адаптивной разметке.
Уже не далеко то время, когда мы будем уделять верстке под все разрешения намного больше внимания, нежели делаем это сейчас. Посему считаю нужным подходить к этому периоду подкованным в данном вопросе, ну или хотя бы иметь четкое представление, что это такое и с чем его едят. Запасаемся смартфонами и таблетками.

Доброго времени суток!

Наряду со статьей "iPhone: MiTM атака из кармана", родилась почти аналогичная статья про Android.

Мы уже знаем, на что способен iPhone. Уступает ли ему Android?

Было рассмотрено около 25 боевых приложений. Хочу предоставить вам результат маленького исследования. Многие приложения даже не запустились, некоторые подвесили телефон намертво, но некоторые даже работали!

Весь софт тестировался на телефоне LG Optimus, с версией Android 2.3.

Итак, краткий обзор боевого софта на Android:

HTML5 Canvas – очень обширная тема со многими “вкусностями”, о многих из которых уже писали и ещё будут писать. Поэтому, я хочу немного рассказать в этой статье, только об одной маленькой, и как на первый взгляд может показаться банальной темой – работа с текстом. Я хочу показать, что с ним почти также можно работать, как с обычным текстом в вебе, т.е. позиционировать, накладывать стили и градиенты, а также писать многострочные предложения легко и без проблем.

Исходные данные — вы строите некий сервис, и узнаете, что будете получать данные из вне в определенном формате.
Предположим что это будет JSON, структуру его определяете не вы, и вообще вот она:

Мы с другом решаем пойти в поход от Сан Франциско до Лос Аджелеса, чтобы заскочить в гости к нашим друзьям на Ньюпорт Бич. Посмотрим на карту и примерно прикинем путь по берегу:



Путь займёт около 400 миль, в день мы можем пройти 4 мили в час по десять часов, так что придём мы туда примерно через 10 дней. Мы звоним друзьям и бронируем столик на 6 вечера в воскресенье.

Доброго времени суток!

Представляю вашему вниманию обзор, установку и настройку замечательного пакета iRedMail на базе Debian Lenny.

Как-то давно я уже писал об этом, но немного скудно и сумбурно. После я решил расширить список инструментов в обзоре, добавить статье структуры, учесть критику (большое спасибо Lefty за советы) и отправил ее на конкурс на СекЛаб (и опубликовал ссылку, но по всем понятным причинам ее никто не увидел). Конкурс закончен, результаты объявили и я с чистой совестью могу ее (статью) опубликовать на Хабре.

Бесплатные инструменты пентестера веб-приложений

В данной статье я расскажу о наиболее популярных инструментах для пентестинга (тестов на проникновение) веб-приложений по стратегии «черного ящика».
Для этого мы рассмотрим утилиты, которые помогут в данном виде тестирования. Рассмотрим следующие категории продуктов:

1. Сетевые сканеры
2. Сканеры брешей в веб-скриптах
3. Эксплойтинг
4. Автомазация инъекций
5. Дебаггеры (снифферы, локальные прокси и т.п.)

В Django версии 1.3 были представлены class-based views — способ описания view в виде классов. Документация, однако, касается только generic views, не описывая общую технику написания «вьюх» в виде классов. Начав использовать generic views и затем пытаясь изменить их поведение, я постепенно дошел до того момента, когда мне пришлось смотреть исходный код, чтобы понять, как что-то сделать. Поэтому я решил написать этот текст. Цель его — объяснить, как использовать class-based view и чем это может быть полезно.

Некоторое время назад озадачился поиском способа развертывания проектов Django, к которому предъявлялись два требования:

1. Удобное управление запуском/остановкой/перезапуском нескольких проектов на одном хосте
2. Поддержка разных виртуальных сред для разных проектов

По второму пункту мой выбор склонился в пользу Nginx + uWSGI. По первому же, из рассмотренных мною вариантов больше всего понравились обвязки для uWSGI в Debian.

Сам я не очень люблю заголовки вроде «Покемоны в собственном соку для чайников\кастрюль\сковородок», но это кажется именно тот случай — говорить будем о базовых вещах, работа с которыми довольно часто приводить к купе набитых шишек и уйме потерянного времени вокруг вопроса — «Почему же оно не работает?». Если вы до сих пор боитесь и\или не понимаете Юникода — прошу под кат.