В этом посте я постараюсь максимально доступно описать весь процесс создания простого плазмоида на Python.
Я постараюсь показать, что написание своих виджетов - это просто, быстро и полезно!
Для понимания сути происходящего неплохо бы предварительно познать сам Python, поставить KDE ;-), PyKDE, PyQt и поддержку питоновского скриптового движка для плазмы (пакет plasma-scriptengine-python в deb-based дистрибутивах).
Наш первый плазмоид будет выполнять простую функцию: показывать карму пользователя welinux.ru, имя которого было введено в соответствующее поле.

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

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

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

1 2 3 4

pyflakes *.py pep8 *.py pylint *.py nosetests

Скрипт запускать каждый раз ужасно лениво, поэтому небольшая оболочка на inotifywait стала запускать тесты и проверки после каждого сохранения:

1 2 3 4

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-приложение, которое правда стремительно разрастается. Пришлось поднимать всё с нуля.

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



Что внутри?

Для тех кто не в курсе - GreedyTorrent это специальный прокси сервер, подкручивающий ваш upload на торрент-трекерах...

Переходим к более практической части. Хардкодом побаловались, далее по плану идёт раздача файлов.

В предыдущей части мы сделали инстурменты для тестирования серверного кода без участия сокетов. Но это получился самый тривиальный из видов тестов ­— Smoke Test. Сервер запрос обработал, но что именно произошло остаётся загадкой.

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

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

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

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

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

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

Многие уже писали себе «сайты» или планируют ими заняться, но при этом плохо представляют себе что же это такое - сайт. Серия постов посвящена построению с нуля учебного (а не супер-быстрого или супер-фичастого) сервера, на примере которого, постараемся разобрать разные практические вопросы из жизни разработчика. Первая, вступительная, часть публичная т.к. возможно многим будет интересно «как это всё устроено». Код на питоне, но это практически псевдокод на английском, поэтому ни у кого тут сложностей возникнуть не должно. Остальные части скорее всего будут показываться только для участников питоноблога.

Сайт это такой многослойный торт, напичканый самыми разными видами крема кода. Давайте посмотрим, что происходит, когда пользователь набирает в браузере http://example.com/ и зачем.

В Ruby сообществе давно модно использовать альтернативный синтаксис для основных языков веб-разработки: HTML, CSS и JavaScript.

• Для HTML документов используется синтаксис HAML.
• 
  
• Для CSS используются LESS, SASS или CleverCSS. Из них SASS самый продвинутый, к и так огромной куче возможностей можно добавить фреймворк Compass, который содержит много полезных функций, миксинов и имеет поддержку популярного CSS фреймворка BluePrint.
• 
  
• Вместо JavaScript люди пишут скрипты на CoffeeScript - альтернативном синтаксисе яваскрипта. CoffeeScript похож по синтаксису на Python и имеет много заимствований "синтаксического сахара" из Ruby и Python.

К сожалению, о том, как организовать поддержку этих технологий в Django-проектах практически не пишут. Я попытался реализовать поддержку сразу трех технологий в одном проекте и столкнулся с ошибками. После нескольких часов копаний в коде я исправил ошибку в webassets (основная библиотека для поддержки этих технологий) и добавил некоторые функции в hamlish (к сожалению после этого он стал зависим от Django, поэтому я не стал его форкать, а сохранил прям в проекте).

Итак, встречайте - django-hsc-skel!
Основа для Django-проектов с поддержкой HAML, SASS (+Compass) и Coffee-Script]

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

Поэтому вот такая задачка для питона: напишите реализацию сортировки quicksort.

Я не буду тут рассказывать этот алгоритм, найдите его сами. Это и будет первым уроком. Гугл ваш другл отныне и до конца статьи.
Замечу только, что не надо использовать list comprehensions, это очень неэффективно.

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